September 9Sep 9 On 9/6/2025 at 1:06 PM, Blackbird said: The past week I have noticed . . . some lag with turning lights on and off. It would be interesting to get more information about this. What kind of delay are you seeing? Seconds? Minutes? Do any other commands happen in between you commanding a light on/off and it actually turning on/off? If we break down what happens when you command a device using UD Mobile it would look something like this: UD Mobile tells the Polisy to a send command to a device - this happens by sending a REST command over your network Polisy tells the PLM to send a command to a device - this happens by sending a command either via a serial or USB connection PLM sends a command to a device - this happens by sending a command over the power-line or RF Device executes the command You can see each of these things happen in the Event Viewer when it is set to Level 3. For the first, you'll see a "Create REST" line For the second, you'll see a [INST-TX-I1] line For the third you'll see a [INST-ACK] line And for the fourth, you'll see an [INST-SRX] or [INST-ERX] line By observing the timestamp in the Event Viewer, you should be able to tell where the delay is being introduced.
September 9Sep 9 Author 3 minutes ago, kclenden said: It would be interesting to get more information about this. What kind of delay are you seeing? Seconds? Minutes? Do any other commands happen in between you commanding a light on/off and it actually turning on/off? If we break down what happens when you command a device using UD Mobile it would look something like this: UD Mobile tells the Polisy to a send command to a device - this happens by sending a REST command over your network Polisy tells the PLM to send a command to a device - this happens by sending a command either via a serial or USB connection PLM sends a command to a device - this happens by sending a command over the power-line or RF Device executes the command You can see each of these things happen in the Event Viewer when it is set to Level 3. For the first, you'll see a "Create REST" line For the second, you'll see a [INST-TX-I1] line For the third you'll see a [INST-ACK] line And for the fourth, you'll see an [INST-SRX] or [INST-ERX] line By observing the timestamp in the Event Viewer, you should be able to tell where the delay is being introduced. Delay is usually seconds but I usually dont wait and keep hitting the on or off button but as I said with the shed, sometimes the command is missed all together. A few time I have noticed the bedroom light turning on by itself for no reason. I think its when i tried doing a restore or maybe when I rebooted the ISY, not sure.
September 9Sep 9 Author I just turned on my computer room light with UDmobile. turned on instantly. Then turned it off and wouldnt turn off. Tried twice. Then opened the event viewer and set to level 3 and turned the computer room light off with udmobile and it wouldnt turn off but the event viewer recognized the command then a popup came up saying couldnt connect to computer room light. Computer room light has an exclamation mark, I clicked on it in admin console and clicked off and it turned off right away and the exclamation mark went away. Now turned it back on and 15 seconds later the light comes on.
September 9Sep 9 Author The screenshot below shows me trying to turn on the computer room light with admin console. The first two lines, the lights wouldnt come on then I clicked on again and the lights came on and lines 3 through 8 popped up. Edited September 9Sep 9 by Blackbird
September 9Sep 9 20 minutes ago, Blackbird said: Sometimes a device turns on instantly using udmobile and other times I have to turn that device on 3 or 4 times before it will turn on. 20 minutes ago, Blackbird said: For example the light on my shed shuts off at sunrise and out of the past week it failed to turn off two separate days after sunrise. Both of those could be signs of a failing PLM, or they could be signs of a noisy power-line. One of the things I have found by looking at the Event Viewer on Level 3 that helps me decide whether the problem is a noisy power-line is the response that comes back from devices - [INST-SRX] and [INST-ERX]. Right after those responses, you should see a [Std-Direct-Ack] line that contains "Hops Left=". The number of hops left tells you how many times a response had to be forwarded by another device before reaching the PLM. It starts at 3 and is reduced by 1 every time it is forwarded. Once it reaches 0, the response will not be forwarded by any more devices. So a Hops Left=3 means that the response came directly from the device. Hops Left=2 means that the response had to be forwarded by another device before it got to the PLM, Hops Left=1 means the response had to be forwarded by two other devices and so on. If you are consistently seeing Hops Left=0 or 1, that means PLM to device communication is consistently relying on intervening devices for forwarding which often means line noise.
September 9Sep 9 Author 1 minute ago, kclenden said: Both of those could be signs of a failing PLM, or they could be signs of a noisy power-line. One of the things I have found by looking at the Event Viewer on Level 3 that helps me decide whether the problem is a noisy power-line is the response that comes back from devices - [INST-SRX] and [INST-ERX]. Right after those responses, you should see a [Std-Direct-Ack] line that contains "Hops Left=". The number of hops left tells you how many times a response had to be forwarded by another device before reaching the PLM. It starts at 3 and is reduced by 1 every time it is forwarded. Once it reaches 0, the response will not be forwarded by any more devices. So a Hops Left=3 means that the response came directly from the device. Hops Left=2 means that the response had to be forwarded by another device before it got to the PLM, Hops Left=1 means the response had to be forwarded by two other devices and so on. If you are consistently seeing Hops Left=0 or 1, that means PLM to device communication is consistently relying on intervening devices for forwarding which often means line noise. On the screenshot, what does that tell you?
September 10Sep 10 2 hours ago, Blackbird said: The screenshot below shows me trying to turn on the computer room light. The first two lines, the lights wouldnt come on then I clicked on again and the lights came on and lines 3 through 8 popped up. That likely indicates a failing PLM. Line 1: (T0) First command from Polisy to PLM to turn on computer room light Line 2: (T+2) Second command from Polisy to PLM to turn on computer room light Line 3: (T+5) First response from PLM to Polisy acknowledging the first command to turn on the computer room light. This is an extended response from the PLM, and my docs don't tell me what the extended data means but the last byte (33) is not 06, so the PLM did not send the ON command to the computer room light. Line 4: (T+5) Third command from Polisy to PLM to turn on computer room light Line 5: (T+5) Second response from PLM to Polisy acknowledging the second command to turn on the computer room light and indicating that it did indeed send the ON command to the computer room light Line 6: (T+5) Third response from PLM to Polisy acknowledging the third command to turn on the computer room light and indicating that it did indeed send the ON command to the computer room light. Also flagged as a duplicate acknowledgement because the Polisy has no way to associate PLM replies with the Polisy command that initiated the reply. Line 7: (T+5) The computer room light acknowledges that it received and executed an ON command from the PLM. You will note that unlike the PLM, devices will not acknowledge additional commands if those command do not change their state (i.e. the light received two ON commands in a row, but it only responded to the first one) Line 8: (T+5) Polisy's decoding of Line 7 Line 9 & 10: (T+5) Polisy updates its status for the computer room light to ON The Event Viewer shows that the delay between you presumably clicking ON in the Admin Console and the computer room light actually coming on was caused by the PLM. The PLM waited five seconds before acknowledging your first attempt to turn on the light. After that the PLM reacted instantly to the additional attempts to turn on the light. It also shows that once the PLM sent the ON command to the light, the light reacted instantly. An additional piece of information appears in line 8 (Hops Left=3). This means that the response from the light to the PLM came directly from the device. More interesting bits of info from these 10 lines is that even though you clicked ON twice before the PLM got around to responding, all three ON clicks were eventually registered by the PLM. This implies that the PLM was queueing the commands even though it wasn't doing anything with them. I don't know why the PLM waited five seconds before responding to the Polisy. I do know that Insteon devices are supposed check the power-line before sending a message so that they don't interfere with messages being sent by other devices. If there was line noise on the power-line, or the PLM circuitry that is used to make sure it is safe to send a message is failing, then the PLM would delay sending the ON command to the device, which would delay it replying to the Polisy. Edited September 10Sep 10 by kclenden
September 10Sep 10 Author 1 hour ago, kclenden said: That likely indicates a failing PLM. Line 1: (T0) First command from Polisy to PLM to turn on computer room light Line 2: (T+2) Second command from Polisy to PLM to turn on computer room light Line 3: (T+5) First response from PLM to Polisy acknowledging the first command to turn on the computer room light. This is an extended response from the PLM, and my docs don't tell me what the extended data means but the last byte (33) is not 06, so the PLM did not send the ON command to the computer room light. Line 4: (T+5) Third command from Polisy to PLM to turn on computer room light Line 5: (T+5) Second response from PLM to Polisy acknowledging the second command to turn on the computer room light and indicating that it did indeed send the ON command to the computer room light Line 6: (T+5) Third response from PLM to Polisy acknowledging the third command to turn on the computer room light and indicating that it did indeed send the ON command to the computer room light. Also flagged as a duplicate acknowledgement because the Polisy has no way to associate PLM replies with the Polisy command that initiated the reply. Line 7: (T+5) The computer room light acknowledges that it received and executed an ON command from the PLM. You will note that unlike the PLM, devices will not acknowledge additional commands if those command do not change their state (i.e. the light received two ON commands in a row, but it only responded to the first one) Line 8: (T+5) Polisy's decoding of Line 7 Line 9 & 10: (T+5) Polisy updates its status for the computer room light to ON The Event Viewer shows that the delay between you presumably clicking ON in the Admin Console and the computer room light actually coming on was caused by the PLM. The PLM waited five seconds before acknowledging your first attempt to turn on the light. After that the PLM reacted instantly to the additional attempts to turn on the light. It also shows that once the PLM sent the ON command to the light, the light reacted instantly. An additional piece of information appears in line 8 (Hops Left=3). This means that the response from the light to the PLM came directly from the device. More interesting bits of info from these 10 lines is that even though you clicked ON twice before the PLM got around to responding, all three ON clicks were eventually registered by the PLM. This implies that the PLM was queueing the commands even though it wasn't doing anything with them. I don't know why the PLM waited five seconds before responding to the Polisy. I do know that Insteon devices are supposed check the power-line before sending a message so that they don't interfere with messages being sent by other devices. If there was line noise on the power-line, or the PLM circuitry that is used to make sure it is safe to send a message is failing, then the PLM would delay sending the ON command to the device, which would delay it replying to the Polisy. I just tried to turn on the computer room light, pushed ON once with admin console and the light didnt turn on even after 5 min.
September 10Sep 10 4 hours ago, Blackbird said: I just tried to turn on the computer room light, pushed ON once with admin console and the light didnt turn on even after 5 min. That is definitely an indication of a failing PLM. The first line is your Polisy telling the PLM to turn the light ON. We know that because the 7th byte is "11" which is an ON command and the 8th byte is "FF" which is the ON Level for the light to come on at. FF means full brightness. But look at the second line which is what the PLM sent back to the Polisy to say that it has sent the requested command to the light. It should look exactly like the first line with just the "06" added to say that the PLM has accepted and sent the command to the device. It's not exactly the same. The 7th byte went from "11" to "FF" and the 8th byte went from "FF" to "00". So the PLM changed the ON command "11" to an "FF". My documentation doesn't say what a light will do if it receives an "FF" command. The third line is the response from your light saying that it has received the "FF" command and executed it. We know that the light was responding to the "FF" command and not the "11" that was originally intended by the Polisy because the 10th byte is "FF". So your PLM corrupted the original message from the Polisy before sending it on to the light. The light didn't come on because it didn't receive an ON command but instead received an "FF" command. After that sequence, do you recall what the status of your computer room light was when viewed in UD Mobile or the Admin Console? Just curious because it would tell us something about how the Polisy interpreted the response from the light saying that it had executed an "FF" command. Edited September 10Sep 10 by kclenden
September 10Sep 10 Author 8 hours ago, kclenden said: That is definitely an indication of a failing PLM. The first line is your Polisy telling the PLM to turn the light ON. We know that because the 7th byte is "11" which is an ON command and the 8th byte is "FF" which is the ON Level for the light to come on at. FF means full brightness. But look at the second line which is what the PLM sent back to the Polisy to say that it has sent the requested command to the light. It should look exactly like the first line with just the "06" added to say that the PLM has accepted and sent the command to the device. It's not exactly the same. The 7th byte went from "11" to "FF" and the 8th byte went from "FF" to "00". So the PLM changed the ON command "11" to an "FF". My documentation doesn't say what a light will do if it receives an "FF" command. The third line is the response from your light saying that it has received the "FF" command and executed it. We know that the light was responding to the "FF" command and not the "11" that was originally intended by the Polisy because the 10th byte is "FF". So your PLM corrupted the original message from the Polisy before sending it on to the light. The light didn't come on because it didn't receive an ON command but instead received an "FF" command. After that sequence, do you recall what the status of your computer room light was when viewed in UD Mobile or the Admin Console? Just curious because it would tell us something about how the Polisy interpreted the response from the light saying that it had executed an "FF" command. I didn't check the status of udmobile but admin console showed it off
September 10Sep 10 50 minutes ago, Blackbird said: I didn't check the status of udmobile but admin console showed it off That makes sense since its status was OFF before it received the "FF" command. I only asked because your screenshot was cutoff at the [INST-SRX] line. If there is a [D2D Event] record or a record with the device's address within [] that follows the [INST-SRX] line, that tells you how the Polisy interpreted the [INST-SRX} line.
September 13Sep 13 Author I switched out the PLM to my new USB PLM. Everything seems to work fine. Took me about an hour. Thanks again to all of your help!!!!!
Create an account or sign in to comment