I'm setting up an eisy in a new home.  I was looking at the event viewer to get an idea how good the communication was by checking hop counts.  See attached, I'm trying to understand the final communication in this sequence.  The device is a standalone i3 Paddle.  It looks like it turns on correctly with hops left=3.  Bu then there is an addition communication and the ack from from the switch is hops left=0.  What is that 2nd communication for and is hops left=0 in this case a sign of communication troubles?

 

Thank you

7 hours ago, tmorse305 said:

I'm setting up an eisy in a new home.  I was looking at the event viewer to get an idea how good the communication was by checking hop counts.  See attached, I'm trying to understand the final communication in this sequence.  The device is a standalone i3 Paddle.  It looks like it turns on correctly with hops left=3.  Bu then there is an addition communication and the ack from from the switch is hops left=0.  What is that 2nd communication for and is hops left=0 in this case a sign of communication troubles?

 

Thank you

It looks like you executed a "fast on" device direct command to address 60.2B.E0 telling it to go to 20% level.  To be honest, I did not realize this was possible.  I had always assumed that Fast On commands applied to 100% level.

Regardless, you did receive two valid responses.  There are times when duplicate responses are received.  The second response could be from a "repeating" device on the opposite phase of your home or "other".  I don't believe this is an issue. 

Edit: I was able to reproduce on my system.  I was repeatedly sending a "Fast ON' to a distant device in my system.  The thinking being that a distant device would be more likely to produce a Hop "Echo".  I received two duplicate responses in about 30 attempts.

Again, I think this is a simple artifact of the multiple HOP architecture of Insteon.  I would not be concerned.

 

Edited December 28, 20231 yr by IndyMike

@IndyMike, thanks for taking the time to run the experiment.  I also don't see it every time either so I think your theory about a second delayed communication is a good one.

 

Also the fast on does yield a 100% result not 20%.  The device is programmed to go to 20% with an normal on.  I was sending the fast on commands from the AC.

15 hours ago, tmorse305 said:

Also the fast on does yield a 100% result not 20%.  The device is programmed to go to 20% with an normal on.  I was sending the fast on commands from the AC.

That's rather curious.  The Insteon command tables do allow for a "Fast On' to a specific level (second to the last entry below).  I have never seen it used by the ISY994, nor do I know how to construct the command using any of the ISY994 program features.  I can manually generate the command using command line tools and dimmers will respond appropriately.

1) Your EISY event viewer shows the transmission of a "Fast On" to a level of 33(hex).  This is equivalent to 20%.

2) The PLM acknowledges the 20% on command.

3) Your target device responds and acknowledges the 20% on.

But the device goes to 100%???

I was originally impressed that the EISY would recognize that your device has a local on level of 20% and that fast on commands would sent it there.  A nice touch.

Now I'm not sure what to think.  The command looks correct.  It's possible that the device itself has an issue.  Is it very old or very new (I3)?

Nothing to be concerned about.  Just something for us dweeb tech types to mull over. 

 

Edited December 29, 20231 yr by IndyMike

Hi @IndyMike, that is interesting.  I double checked and it is definitely going to 100%.  The i3 devices are the latest versions coming from Insteon. 

Got it.  I see now that you originally stated that the device is a new I3 paddle.  The Eisy side of communications looks correct (good command syntax).  The device should be going to 20%.  Possible that the new I3 devices also have a new rule book.

We'll need to keep an eye out for that as experience with these devices grows.