Backlight level update issues

[carealtor]

I have programs to turn off the "Backlight" on all the switches in our bedroom at night.  Some of the switches correctly respond to the Backlight commands without fail every time, while others are hit and miss.  All of them are newish dual band devices and all of them always respond to on/off/dim type commands.  They are all in close proximity to each other and RF communication between them should not be an issue.  The house is newish with plastic electrical boxes.

I'm wondering if maybe the Backlight command is powerline only, and not repeated via RF, and that maybe this is the root of my problem?

[MrBill]

This doesn't answer your question, because i don't know the answer to the question asked. I would guess it's not limited to single band tho.

What I would try tho is to add a brief wait between each backlight command in the program.   2 or 3 seconds should do... It's only a guess but my guess is traffic jam.

[carealtor]

Good suggestion, but I've already tried that.  No better, no worse.  Just as flakey.

[MrBill]

19 minutes ago, carealtor said:

Good suggestion, but I've already tried that.  No better, no worse.  Just as flakey.

I'm not good at reading it but others around here are, but you should post a level 3 Event Viewer of what happens when the program runs. with description of which device ID's didn't work.

Also I assumed you tried higher wait times too.... does it only happen when the program runs automatically? or does it also happen if you just randomly run then or run else during the day... the thing I'm getting at is a lot happens when my bedtime routing runs... maybe something else is happening at that time.

[carealtor]

Okay, I added a 30 second wait between every Action and manually ran the Then part of the Program.

Here is the level 3 Event Viewer:

Mon 09/20/2021 01:58:30 PM : [        Time] 13:59:00 0(0)
Mon 09/20/2021 01:59:00 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 01:59:00 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 01:59:29 PM : [All         ] Writing 1 bytes to devices
Mon 09/20/2021 01:59:29 PM : [50 DE B1 1  ] Memory : Write dbAddr=0x0264 [19] cmd1=0x2E cmd2=0x00
Mon 09/20/2021 01:59:29 PM : [INST-TX-I2CS] 02 62 50 DE B1 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2
Mon 09/20/2021 01:59:29 PM : [INST-ACK    ] 02 62 50.DE.B1 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2 06        (00)
Mon 09/20/2021 01:59:30 PM : [INST-SRX    ] 02 50 50.DE.B1 23.8D.92 2B 2E 00           (00)
Mon 09/20/2021 01:59:30 PM : [Std-Direct Ack] 50.DE.B1-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 09/20/2021 01:59:30 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 01:59:59 PM : [All         ] Writing 1 bytes to devices
Mon 09/20/2021 01:59:59 PM : [42 9C 17 1  ] Memory : Write dbAddr=0x0264 [19] cmd1=0x2E cmd2=0x00
Mon 09/20/2021 01:59:59 PM : [INST-TX-I2CS] 02 62 42 9C 17 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2
Mon 09/20/2021 01:59:59 PM : [INST-ACK    ] 02 62 42.9C.17 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2 06        (00)
Mon 09/20/2021 02:00:00 PM : [INST-SRX    ] 02 50 42.9C.17 23.8D.92 2B 2E 00           (00)
Mon 09/20/2021 02:00:00 PM : [Std-Direct Ack] 42.9C.17-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 09/20/2021 02:00:00 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 02:00:29 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 02:00:29 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 02:00:59 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 02:00:59 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 02:01:29 PM : [All         ] Writing 1 bytes to devices
Mon 09/20/2021 02:01:29 PM : [INST-TX-I2CS] 02 62 41 D3 E9 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0
Mon 09/20/2021 02:01:29 PM : [INST-ACK    ] 02 62 41.D3.E9 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06        (00)
Mon 09/20/2021 02:01:29 PM : [INST-SRX    ] 02 50 41.D3.E9 23.8D.92 2B 2F 00           (00)
Mon 09/20/2021 02:01:29 PM : [Std-Direct Ack] 41.D3.E9-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 09/20/2021 02:01:30 PM : [INST-ERX    ] 02 51 41 D3 E9 23 8D 92 11 2F 00 00 01 0F FF 00 A2 00 23 8D 92 FF 1F 01 BF 
Mon 09/20/2021 02:01:30 PM : [Ext-Direct  ] 41.D3.E9-->ISY/PLM Group=0, Max Hops=1, Hops Left=0
Mon 09/20/2021 02:01:30 PM : [41 D3 E9 1  ] Memory : Write dbAddr=0x0264 [19] cmd1=0x2E cmd2=0x00
Mon 09/20/2021 02:01:30 PM : [INST-TX-I2CS] 02 62 41 D3 E9 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2
Mon 09/20/2021 02:01:30 PM : [INST-ACK    ] 02 62 41.D3.E9 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2 06        (00)
Mon 09/20/2021 02:01:30 PM : [INST-SRX    ] 02 50 41.D3.E9 23.8D.92 2B 2E 00           (00)
Mon 09/20/2021 02:01:30 PM : [Std-Direct Ack] 41.D3.E9-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 09/20/2021 02:01:31 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 02:01:59 PM : [All         ] Writing 1 bytes to devices
Mon 09/20/2021 02:01:59 PM : [INST-TX-I2CS] 02 62 42 EA B9 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0
Mon 09/20/2021 02:01:59 PM : [INST-ACK    ] 02 62 42.EA.B9 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06        (00)
Mon 09/20/2021 02:01:59 PM : [INST-SRX    ] 02 50 42.EA.B9 23.8D.92 2B 2F 00           (00)
Mon 09/20/2021 02:01:59 PM : [Std-Direct Ack] 42.EA.B9-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 09/20/2021 02:01:59 PM : [INST-ERX    ] 02 51 42 EA B9 23 8D 92 11 2F 00 00 01 0F FF 00 A2 00 23 8D 92 FF 1F 01 BF 
Mon 09/20/2021 02:01:59 PM : [Ext-Direct  ] 42.EA.B9-->ISY/PLM Group=0, Max Hops=1, Hops Left=0
Mon 09/20/2021 02:01:59 PM : [42 EA B9 1  ] Memory : Write dbAddr=0x0264 [19] cmd1=0x2E cmd2=0x00
Mon 09/20/2021 02:01:59 PM : [INST-TX-I2CS] 02 62 42 EA B9 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2
Mon 09/20/2021 02:02:00 PM : [INST-ACK    ] 02 62 42.EA.B9 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2 06        (00)
Mon 09/20/2021 02:02:00 PM : [INST-SRX    ] 02 50 42.EA.B9 23.8D.92 2B 2E 00           (00)
Mon 09/20/2021 02:02:00 PM : [Std-Direct Ack] 42.EA.B9-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 09/20/2021 02:02:01 PM : [All         ] Writing 0 bytes to devices
Mon 09/20/2021 02:02:28 PM : [All         ] Writing 1 bytes to devices
Mon 09/20/2021 02:02:28 PM : [42 EE 61 1  ] Memory : Write dbAddr=0x0264 [19] cmd1=0x2E cmd2=0x00
Mon 09/20/2021 02:02:28 PM : [INST-TX-I2CS] 02 62 42 EE 61 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2
Mon 09/20/2021 02:02:28 PM : [INST-ACK    ] 02 62 42.EE.61 1F 2E 00 00 07 19 00 00 00 00 00 00 00 00 00 00 B2 06        (00)
Mon 09/20/2021 02:03:02 PM : [INST-SRX    ] 02 50 42.EE.61 23.8D.92 2B 2E 00           (00)
Mon 09/20/2021 02:03:02 PM : [Std-Direct Ack] 42.EE.61-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Mon 09/20/2021 02:03:02 PM : [All         ] Writing 0 bytes to devices
 

 

The 3 devices that did not react are the ones that fired at 1:59:00, 2:00:29, and 2:00:59.  As you can see, all that is in the log at those times is "Writing 0 bytes to devices".

[MrBill]

Nice post... now we just need to wait for the users that are good at reading the event viewer.... as I mentioned.. that's not me... lol.

[kclenden]

1 hour ago, carealtor said:

As you can see, all that is in the log at those times is "Writing 0 bytes to devices".

It might be helpful if you posted your programs as well.

It's clear from the Event Viewer log that the ISY is not sending any Insteon commands at 1:59:00, 2:00:29 and 2:00:59.  My guess is that the ISY thinks the device backlight is already set at the level your program specifies and thus does not send out an Insteon command - similar to how the ISY won't send an On command if it thinks the device is already on.

So, for debugging purposes, you might try querying the devices first, and then sending the backlight command, though I don't know if the backlight level is returned as part of a query response.  You could also try setting the backlight level to an unwanted level first, and then to the actual level you desire.  If either of those things makes the process more reliable then it would seem likely that it is an issue of the ISY not sending out commands it deems unneeded to reduce powerline activity.

UPDATE: Just did a little testing and the ISY does actually send an ON command even if it thinks a device is on.  Not sure what I was thinking above...  I'll blame it on Monday.  Still, you might try the two suggestions above to see if they impact whether the ISY sends out the backlight commands.

[kclenden]

1 hour ago, carealtor said:

The 3 devices that did not react are the ones that fired at 1:59:00, 2:00:29, and 2:00:59.  As you can see, all that is in the log at those times is "Writing 0 bytes to devices".

After some testing, while I was wrong about the ISY not sending out an ON command if it thinks a device is already ON, I have confirmed that the ISY does not send out a backlight command if it thinks the device is already set at that backlight level.  I did this by creating a program that set a switch backlight to 50%.  Then I ran that program multiple times.  The first time the program is run, there is a corresponding Insteon command in the Event Viewer.  All further executions of the program result in the "Writing 0 bytes" message.  Then I manually changed the backlight level from the AC.  The next execution of the program resulted in an Insteon backlight command in the Event Viewer.

So I'm guessing that the ISY attempts to prolong the life of the memory of devices by not writing data it thinks is unnecessary.

[carealtor]

25 minutes ago, kclenden said:

After some testing, while I was wrong about the ISY not sending out an ON command if it thinks a device is already ON, I have confirmed that the ISY does not send out a backlight command if it thinks the device is already set at that backlight level.  I did this by creating a program that set a switch backlight to 50%.  Then I ran that program multiple times.  The first time the program is run, there is a corresponding Insteon command in the Event Viewer.  All further executions of the program result in the "Writing 0 bytes" message.  Then I manually changed the backlight level from the AC.  The next execution of the program resulted in an Insteon backlight command in the Event Viewer.

So I'm guessing that the ISY attempts to prolong the life of the memory of devices by not writing data it thinks is unnecessary.

Okay, then let me try to get a log when it is definitely trying to change the backlight level, but fails.

[kclenden]

1 hour ago, carealtor said:

Okay, then let me try to get a log when it is definitely trying to change the backlight level, but fails.

While that could explain how the ISY is getting out of synch with your programs, it probably won't contribute to a solution.  If the ISY tries to change the backlight level and fails, it's probably because of failed communication.  Either the device never received the original command and didn't change its backlight level, or it did receive the command, changed its backlight level, and sent an acknowledgement but the ISY never received it.  In both cases, the Event Viewer log is going to show the same thing - Insteon command sent but no acknowledgement.  The only way you'll know whether it was the command not being received by the device or the acknowledgement not being received by the ISY is to visually confirm the backlight level at the device.

[carealtor]

1 hour ago, kclenden said:

If the ISY tries to change the backlight level and fails, it's probably because of failed communication.

After playing with this for a few hours, it is obvious to me that it is a communications issue.  Manually running the programs from the console, I can see the pop up error messages about lack of communication.  I actually knew this all along, hence my original post.  But there is NO communication issue or errors with on/off/dim type commands.  So I was asking if anyone knew if, by some chance, that the Backlight command was powerline only, as this might explain my issue.

I just thought maybe, since the Backlight command is different in that there are no links with PLM involved, that maybe it's transmission was different.

[kclenden]

46 minutes ago, carealtor said:

But there is NO communication issue or errors with on/off/dim type commands.  So I was asking if anyone knew if, by some chance, that the Backlight command was powerline only, as this might explain my issue.

That I know of, the only difference between the ON/OFF/DIM commands and the Set Backlight command is that the former use a Standard-length message while the latter uses an Extended-length message.  What this means is that the ON/OFF/DIM commands send 10 bytes while the Set Backlight command sends 24 bytes.  All of the documentation that I've seen indicates that both Standard and Extended messages are broadcast by both RF and powerline.

If there is interference on the powerline, I guess it makes sense that a 24 byte message is more likely to be corrupted than a 10 byte message.  Still, I wouldn't expect the shorter messages to always make it through.  I would expect some of them to be corrupted.

[carealtor]

Follow up...

Completely unrelated, a week or more ago, I noticed that my Unifi Access Points were showing that there was a software update available.  Immediately after doing the update all the communication problems discussed above went away.  All backlights have updated perfectly every night and morning since upgrading the Unifi Access Points, one of which is in the same room.  Cause and effect?  Who knows.  But the coincidence seems too convenient to ignore.

[MrBill]

15 hours ago, carealtor said:

Who knows.

no kidding...   Wifi APs shouldn't have anything to do with... Insteon is at 915MHz so it's not even polluting the 2.4GHz airspace.   Wish there was a method to figure out cause and effect...