In chasing down some communication issues in a new house I discovered a different eisy behavior on i3 vs earlier versions.

I have a program that turns off the backlight on an i3 keypad.  The program was not always successful so I was troubleshooting using the event viewer.  What I found was that only the first time the program is run, the actual command is sent.  Subsequent attempts to run the program do not send the command again.  See the log excerpt.

Wed 01/10/2024 08:03:23 AM : [            Time] 08:03:29 2(0)
Wed 01/10/2024 08:03:23 AM : [All         ] Writing 2 bytes to devices
Wed 01/10/2024 08:03:23 AM : [INST-TX-I2CS] 02 62 60 7A 97 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0
Wed 01/10/2024 08:03:23 AM : [INST-ACK    ] 02 62 60.7A.97 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06        (00)
Wed 01/10/2024 08:03:23 AM : [INST-SRX    ] 02 50 60.7A.97 70.8F.46 2F 2F 00           (00)
Wed 01/10/2024 08:03:23 AM : [Std-Direct Ack] 60.7A.97-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Wed 01/10/2024 08:03:23 AM : [INST-ERX    ] 02 51 60 7A 97 70 8F 46 15 2F 00 00 01 0F FF 00 A2 1D 70 8F 46 FF 1F 03 9D
Wed 01/10/2024 08:03:23 AM : [Ext-Direct  ] 60.7A.97-->ISY/PLM Group=0, Max Hops=1, Hops Left=1
Wed 01/10/2024 08:03:23 AM : [60 7A 97 1  ] Memory : Write dbAddr=0x4001 [09] cmd1=0x20 cmd2=0x09
Wed 01/10/2024 08:03:23 AM : [INST-TX-I2CS] 02 62 60 7A 97 1F 20 09 00 00 00 00 00 00 00 00 00 00 00 00 00 D7
Wed 01/10/2024 08:03:23 AM : [INST-ACK    ] 02 62 60.7A.97 1F 20 09 00 00 00 00 00 00 00 00 00 00 00 00 00 D7 06        (09)
Wed 01/10/2024 08:03:24 AM : [INST-SRX    ] 02 50 60.7A.97 70.8F.46 2F 20 09           (09)
Wed 01/10/2024 08:03:24 AM : [Std-Direct Ack] 60.7A.97-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Wed 01/10/2024 08:03:24 AM : [60 7A 97 1  ] Memory : Write dbAddr=0x0264 [7F] cmd1=0x2E cmd2=0x00
Wed 01/10/2024 08:03:24 AM : [INST-TX-I2CS] 02 62 60 7A 97 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B
Wed 01/10/2024 08:03:24 AM : [INST-ACK    ] 02 62 60.7A.97 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B 06        (00)
Wed 01/10/2024 08:03:25 AM : [INST-SRX    ] 02 50 60.7A.97 70.8F.46 2F 2E 00           (00)
Wed 01/10/2024 08:03:25 AM : [Std-Direct Ack] 60.7A.97-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Wed 01/10/2024 08:03:25 AM : [INST-SRX    ] 02 50 60.7A.97 70.8F.46 23 2E 00           (00)
Wed 01/10/2024 08:03:25 AM : [Std-Direct Ack] 60.7A.97-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

<second run of program>

Wed 01/10/2024 08:03:40 AM : [All         ] Writing 0 bytes to devices

I see the same behavior on the i3 paddle as well.  If I send a different command set (turn on backlight) that is sent ok and then I can run the above program and it will send the commands one time.

I looked at an i2 device and the commands are sent every time.

Is it a bug or intentional behavior?

Thank you.

My suggestion is make this a ticket and point it to this thread. It needs to get on list to be evaluated and worked.

@tmorse305,

It looks like the Eisy is performing as I would expect it to.  When I perform a "backlight change" on a I2CS device I get the same behavior.  I believe this is the ISY "remembering" your device backlight.  If you are not changing the backlight, there is no work to do (o bytes written).

You can perform the same actions using the backlight controls on the Admin Console (on ISY994 - not sure about Eisy).

If your device is not responding to the initial change, it should be giving a NACK or a timeout.  You should be able to see this in the Logs. 

1st write (valid change)

Wed 01/10/2024 09:57:10 AM : [All         ] Writing 1 bytes to devices
Wed 01/10/2024 09:57:10 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0
Wed 01/10/2024 09:57:10 AM : [INST-ACK    ] 02 62 41.1E.09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06        (00)
Wed 01/10/2024 09:57:10 AM : [INST-SRX    ] 02 50 41.1E.09 53.BC.3A 2F 2F 00           (00)
Wed 01/10/2024 09:57:10 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Wed 01/10/2024 09:57:10 AM : [INST-ERX    ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 20 A2 00 53 BC 3A FF 1F 01 98 
Wed 01/10/2024 09:57:10 AM : [Ext-Direct  ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1
Wed 01/10/2024 09:57:11 AM : [41 1E 9 1   ] Memory : Write dbAddr=0x0264 [00] cmd1=0x2E cmd2=0x00
Wed 01/10/2024 09:57:11 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB
Wed 01/10/2024 09:57:11 AM : [INST-ACK    ] 02 62 41.1E.09 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB 06        (00)
Wed 01/10/2024 09:57:11 AM : [INST-SRX    ] 02 50 41.1E.09 53.BC.3A 2F 2E 00           (00)
Wed 01/10/2024 09:57:11 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3
Wed 01/10/2024 09:57:11 AM : [All         ] Writing 0 bytes to devices

 

2nd write (redundant change)

Wed 01/10/2024 09:57:14 AM : [All         ] Writing 0 bytes to devices
Wed 01/10/2024 09:57:14 AM : [All         ] Writing 0 bytes to devices

 

@IndyMike, thanks for your reply.  Before I wrote this up I tried it on a 2477S and it writes the update every time I change the backlight from the AC.  I have an eisy but it's hard to imagine that makes a difference.

As for expected behavior, I'm not sure I would agree with that.  I'd like to think that eisy would always send the requested commands regardless of what it might think the current state is.  I haven't checked but I'll bet it doesn't do it for on and off.  Maybe I'm missing something here.  I know the number of times you can write backlight is finite, maybe that's the logic but for me it work with a 2477S.  Maybe 2477S is an i1?

Edited January 11, 20241 yr by tmorse305

35 minutes ago, tmorse305 said:

I know the number of times you can write backlight is finite

First I've heard of that on the dual band 2477's, I sent backlight levels around 6 times per day and it's been going strong for six years.

9 hours ago, tmorse305 said:

@IndyMike, thanks for your reply.  Before I wrote this up I tried it on a 2477S and it writes the update every time I change the backlight from the AC.  I have an eisy but it's hard to imagine that makes a difference.

As for expected behavior, I'm not sure I would agree with that.  I'd like to think that eisy would always send the requested commands regardless of what it might think the current state is.  I haven't checked but I'll bet it doesn't do it for on and off.  Maybe I'm missing something here.  I know the number of times you can write backlight is finite, maybe that's the logic but for me it work with a 2477S.  Maybe 2477S is an i1?

Curious that the Eisy treats your 2477s that way.  I've tried my devices ranging from I1 through I2CS and the ISY994 only writes once.  Are you sure you are not seeing an error or Nack when you are writing the 2477S?  This could cause the ISY to write a second time when requested.

As you inferred the backlight changes are written to EEprom memory on the device.  There is a limit to the number of writes the device can undergo.  This, I had thought, was the justification for not writing redundant information.  I say redundant, because the command is device direct and is fully acknowledged by the device.  There is no guessing whether the command was received. 

Try checking commands for On/Off.  These are also device direct commands but do not involve the memory.  I think you'll find that the ISY sends the command every time (my 994 does).  If the Eisy does not send each command, that is an update.  Not wrong, just an update.

Thanks @IndyMike, confusion resolved, you're right, only a single write to the 2477S.

I have so many NS running that the log is flooded with communication from them.  Today I shut down all of the NSs to get a clean look at the activity.  I was confusing another insteon device with a similar xx.xx.xx for the 2477s.

I'll try and catch a NACK coming from the keypad.  If there is one you might think eisy would then realize that the command failed and when prompted a second time try again.  I have an Alexa routine that turns off the backlight.  If it fails I can trigger the routine again but nothing happens.  I'll run logging at bedtime to see if I can catch it.