Improving Communication

[raptor]

11 hours ago, kclenden said:

You can use the Admin Console to help troubleshoot.  In the AC choose TOOLS->DIAGNOSTICS->EVENT VIEWER.  In the Event Viewer change the LEVEL to "3. Device communications events".  With the Event Viewer open, try switching ON and OFF the troublesome devices.  After each command, look in the Event Viewer for "Std-Direct Ack]"  On those lines you'll see "Max Hops=" and "Hops Left=".

When a command is sent via Insteon it is allowed to be repeated a certain number of times.  That is defined by "Max Hops".  You can tell how many times the command was repeated before the device received it by looking at "Hops Left".  If "Max Hops" and "Hops Left" are the same, it means the device heard the command the first time.  If you subtract "Hops Left" from "Max Hops", that tells you how many times the command had to be repeated before the device heard the command.

With this information, you can try turning other devices ON/OFF (or plugging/unplugging) and then commanding the troublesome devices to see if the average "Hops Left" changes.

Tried this last night. Kept turning light on and off from the admin console and it responded every time. max hop and hop left were both 3. After 10 minutes gave up and just left it. When I triggered the all off before going to bed that one light didn't turn off. Strange thing is that in the admin console the status was off. I queried the devices and it updated the status to on. Sent command to turn off from admin console and it did. More testing to do.

[larryllix]

16 minutes ago, raptor said:

Tried this last night. Kept turning light on and off from the admin console and it responded every time. max hop and hop left were both 3. After 10 minutes gave up and just left it. When I triggered the all off before going to bed that one light didn't turn off. Strange thing is that in the admin console the status was off. I queried the devices and it updated the status to on. Sent command to turn off from admin console and it did. More testing to do.

"All Off/On" is a built in scene. Insteon scenes do not send status updates from Insteon devices and therefore ISY must assume the status.

"All On/Off" has been discontinued in newer Insteon devices. I suggest you create a program that turns each device off instead. Use  a Wait 1-2 seconds after each 2-3 Insteon device command lines, so you don't overflow the Insteon comm buffers inside ISY.

[hart2hart]

"All Off/On" is a built in scene. Insteon scenes do not send status updates from Insteon devices and therefore ISY must assume the status.
"All On/Off" has been discontinued in newer Insteon devices. I suggest you create a program that turns each device off instead. Use  a Wait 1-2 seconds after each 2-3 Insteon device command lines, so you don't overflow the Insteon comm buffers inside ISY.

I’m guessing whoever installed created a scene that turned all the their lights on it off.

I don’t remember (doesn’t mean it’s not there) the built in all on/off being accessible. It was always by accident.

[raptor]

1 minute ago, hart2hart said:

I’m guessing whoever installed created a scene that turned all the their lights on it off.

I don’t remember (doesn’t mean it’s not there) the built in all on/off being accessible. It was always by accident.

The all off is associated with the 8th button on an 8 button keypad which I believe is by default set for all on/off function.

[MrBill]

3 hours ago, raptor said:

When I triggered the all off before going to bed that one light didn't turn off.

Sent command to turn off from admin console and it did.

Where did you trigger it from the first time?   The KPL and the ISY have are different transmitters and are sending from different points on the Insteon network.  From your description it sounds like when you pressed the KPL button, the signal did reach the ISY (which changed the status) but the signal didn't reach the switch that didn't turn off.

I doubt this is an issue, but one more thing introduced in V5 firmware that didn't exist with your old ISY... (I assume your new ISY is on V5... Help > About) is there are additional link types. In non-insteon or mixed Insteon/Z-wave sometime the ISY can be a middleman.  If you upgraded this shouldn't be a problem, you should have all insteon type links... but to be sure click the Scene Name in the Tree and look at the far left side of the screen and make certain all the nodes of the scene have Link Type Insteon.

You will also see the same thing with the cursor on any of the members except the current node will say default which is confusing, so the place to check this is by clicking the Root level or scene name.

[raptor]

I triggered the all off scene from HomeSeer which sends off command to keypad H on a 8 button keypad. Presumably this is like triggering the scene directly from the ISY as HomeSeer connects directly to ISY. 

 

Firmware version 5.3.0. And yest link type are all Insteon.

[larryllix]

KPLs have so many signals from a single box that they get confused a lot with signal clashes and lose links to other devices.

Try doing a restore to the KPL, (and any other device involved/suspect). You can find this menu by right clicking on the KPL device in the device tree page of the admin console..

[lilyoyo1]

2 hours ago, raptor said:

I triggered the all off scene from HomeSeer which sends off command to keypad H on a 8 button keypad. Presumably this is like triggering the scene directly from the ISY as HomeSeer connects directly to ISY. 

 

Firmware version 5.3.0. And yest link type are all Insteon.

 

Your presumption is incorrect. If you're only triggering the Kpl button from homeseer then you are triggering that button and not the scene attached to that button. Insteon does not work like that.

I'm confused though. I thought your issue was with the Isy now you're saying that you're using  homeseer to trigger your devices!? 

What is your setup exactly as you're now adding additional information which can change things.

 

 

 

Edited August 11, 2021 by lilyoyo1

[raptor]

3 minutes ago, lilyoyo1 said:

I'm confused. I thought your issue was with the Isy now you're saying that you're using  homeseer to trigger your devices!? 

What is your setup exactly as your now adding additional information which can change things

Maybe I should have mentioned HomeSeer but HomeSeer just sends command true ISY just as if I would open the admin console and launch it from there. Whether I launch from HomeSeer, ISY or directly from the 8 button keypad I have the same issue. So don't think it has anything to do with HomeSeer

[lilyoyo1]

37 minutes ago, raptor said:

Maybe I should have mentioned HomeSeer but HomeSeer just sends command true ISY just as if I would open the admin console and launch it from there. Whether I launch from HomeSeer, ISY or directly from the 8 button keypad I have the same issue. So don't think it has anything to do with HomeSeer

It does matter because it's based on what homeseer is sending and the isy is receiving. While your issue may persist through both systems, if it's not being done properly through homeseer, you'll still have the issue once your communication issues are resolved 

[MrBill]

33 minutes ago, raptor said:

but HomeSeer just sends command true ISY just as if I would open the admin console and launch it from there.

Then you're not controlling the KPL button from HomeSeer, as mentioned on a previous page of this thread you are controlling a scene with a name that makes you think you are controlling the button-- you are actually controlling a scene.

Keep in mind that Insteon communication does not all go thru the ISY.  The ISY can be unplugged and scene's still work.  The KPL button that you pressed last night is initiating the scene from a differnt point than if the ISY turns the scene on or off.  In other words, once a scene is programed the switches are talking to each other directly.  The ISY is also listening to the chatter and keeping track of what it hears and updating device status.  

What appears to have happened last night, you pushed the keypad button and the ISY heard the signals and updated the status of the devices in the ISY, but one or more Responders in the scene didn't hear the message and respond.

[raptor]

OK so outdoor light scene just triggered. And one light didn't come one. This is programmed in the ISY as shown on picture. Is this stored in kepads as well or triggered from ISY every time. Is it sending signal to turn on key pad E or just turns on the scene and because button "E" is part of the scene it also turns on. Also the status on admin console for that light is showing as on. I assume ISY turned on the scene and changed status of all switches but one never got the message to turn on? Were is the miss communication, from keypad to switch or PLM to switch. Or do I have this all wrong? 

[kclenden]

3 hours ago, raptor said:

Is it sending signal to turn on key pad E or just turns on the scene and because button "E" is part of the scene it also turns on.

Set 'Backdoor / Backdoor KP-E Outside' On sends out a SCENE ON command.  The ISY sends out a single command and all responders in that scene see the command and turn ON to the level that was previously defined.  Which means the "E" button is coming on because it is a responder in the scene.

When the ISY sends out a SCENE ON command, the responders do not reply with a status update.  This is by design so that the powerline is not flooded with responses by what could be a very large number of devices.  Since there are no replies from the responders in the scene, the ISY just assumes they all turned on and thus changes their status accordingly.

Edited August 12, 2021 by kclenden

[kclenden]

15 hours ago, raptor said:

Tried this last night. Kept turning light on and off from the admin console and it responded every time. max hop and hop left were both 3.

This implies that in general, the communication channel between the ISY and the device is pretty reliable.

15 hours ago, raptor said:

When I triggered the all off before going to bed that one light didn't turn off. Strange thing is that in the admin console the status was off.

As mentioned in a previous reply, when a SCENE ON/OFF command is sent, no status replies come back from the controlled devices.  The ISY just assumes the devices executed the command.  This contrasts to when a DIRECT ON/OFF command is sent from the ISY to a specific device in which case the device does respond with a status update and the ISY only updates the device status after it has received the reply from the device.

[kclenden]

16 hours ago, raptor said:

I queried the devices and it updated the status to on. Sent command to turn off from admin console and it did. More testing to do.

There's a significant communication difference between ISY DIRECT vs SCENE commands.  With DIRECT commands, the ISY uses "retries" while with SCENE commands it does not.

A little bit about communication.  Insteon uses "hops" so that devices can pass along commands.  So if "max hops" is set to 3, devices can repeat the command up to three times.  This tends to amplify the command which makes it more likely the appropriate devices will receive the command.  After three repeats, however, the command is no longer repeated and if the device has not received it, the command is just lost.  This is where "retries" comes in.

With "retries" if there is no response to a command from a device, the controller sends the command again.  As with the original attempt to send the command, it will be repeated by other devices up to "max hops" number of times.

What this means is that ISY DIRECT commands have, in theory at least, a better chance at being received than SCENE commands.

To make SCENE commands more reliable, there is a GROUP Cleanup message that can be sent from the controller to each responder in the scene.  This would result in an ACK or NAK from each responder so that the controller knows whether to resend the original command.  The ISY does not use cleanup messages when it sends SCENE commands, but I think that non-ISY scenes do.

Edited August 12, 2021 by kclenden

[Brian H]

There is a Scene Test in the Tools, Diagnostics Tests list.

It turns On the Scene then Off. Showing the results of the modules going On and Off. There is a warning that programs depending an a modules state maybe effected. I believe it used a HOP of 1 for the information it was showing.

I have used it myself but have not seen it mentioned much by others.  On how well it helped them. To test communications

 

Edited August 12, 2021 by Brian H
Add information

[MrBill]

@raptor  this has been better explained by @kclenden very well.  the only thing that I can add is keep the word mesh in mind as you think about it, and remember that devices can talk to each other without the ISY... each devices talk and listens to the the communication on the powerline. 

Also keep in mind your older devices are single band, and that your 2443's are no longer doing the job they were installed for.  Updating to dual band devices in multiple areas would likely help.

[raptor]

Learned a lot in the past few days. Probably need lo learn more lol. I still want to do some more testing and will definitely be looking at adding more dual band devices. For right now for sort of a band aid I may disable that scene from the ISY and create a scene in HomeSeer to turn on each light individually(there's only 3). It seems when I turn on/off those lights from HomeSeer they work 100% of the time. Tanks to everyone for the help.

[kclenden]

11 hours ago, raptor said:

It seems when I turn on/off those lights from HomeSeer they work 100% of the time. Tanks to everyone for the help.

It's been years since I've used HomeSeer, and even then I didn't get into it really deeply.  So a couple questions.  Does your HomeSeer setup use a different PLM?  If so, it could be that the HomeSeer PLM has a better electrical path to the troublesome device(s).  It's also possible that the HomeSeer PLM sends out a stronger Insteon signal.

Next question is whether you're using a HomeSeer group to control the devices.  If so, I think there is a global "Send group cleanup messages" flag.  If that is enabled then devices that don't initially execute a group command will execute when they receive a direct group cleanup message.  Additionally, direct group cleanup messages can also configured to "retry" if they are not acknowledged.

Because group (scene) cleanup messages can tie up the powerline for a while if there are a lot of responders in the group, they are given a lower priority than other insteon messages.  What this means is that if a controller that is sending group cleanup messages detects another insteon command on the powerline, it will stop sending out group cleanup messages.  So while group (scene) commands can be almost as reliable as direct commands if cleanup messages are enabled, if there is a lot of activity on the powerline then they fall back to basically being one-way communication from the controller to the responder without any retries.

[raptor]

4 hours ago, kclenden said:

It's been years since I've used HomeSeer, and even then I didn't get into it really deeply.  So a couple questions.  Does your HomeSeer setup use a different PLM?  If so, it could be that the HomeSeer PLM has a better electrical path to the troublesome device(s).  It's also possible that the HomeSeer PLM sends out a stronger Insteon signal.

 

HomeSeer has 2 plugins. The first is Insteon plugin. That one I believe connects to a PLM and controls the lights directly. I don't use that one. I use the ISY plugin. It connects to the ISY true the network. I believe how it works is the same as triggering a light or scene from the admin console. So I don't use HomeSeer groups. Mostly trigger ISY scenes, some individual switches.

[kclenden]

14 hours ago, raptor said:

I don't use that one. I use the ISY plugin. It connects to the ISY true the network. I believe how it works is the same as triggering a light or scene from the admin console.

That's interesting, but ultimately just confuses me.  If HomeSeer is just passing commands onto the ISY to execute, it really makes no sense that scenes controlled from HomeSeer would be more reliable than when controlled directly from the ISY.  Hmmmm...

[DAlter01]

If you have a communications issue causing your problem it can be a noise generator.  I had a similar situation to you some years back where I had a few devices that were intermittantly working.  Eventually I bought an ultra wideband handheld receiver that receives 132KHZ frequency (Insteon's powerline frequency) and  just walked around the house looking for electronics that generated a lot of noise on that frequency.  It was englightening.  I found that some of my flourescent light ballasts were somewhat noisy and some LED light bulbs were extremely noisy.  Both of these items were intermitant noise generators that only caused noise when on.  All electronics in the house generated noise at 132KHZ but the above created significant more noise (static).  I only had to replace the problem LED bulbs and my comms issue was resolved.  Had that not fixed the issue I would have also replaced the ballasts.  The radio I bought was a used Yaesu VR-120 on ebay.  That radio is discontinued though.  I believe an Icom RC-I6 is essentially the same ultra wideband receiver and runs about $200.  It's a valuable tool in my view.  There may be better ways to hunt down noise generators but this worked for me.  

Edited August 14, 2021 by DAlter01

[raptor]

12 hours ago, kclenden said:

That's interesting, but ultimately just confuses me.  If HomeSeer is just passing commands onto the ISY to execute, it really makes no sense that scenes controlled from HomeSeer would be more reliable than when controlled directly from the ISY.  Hmmmm...

Let me clarify. Scenes controlled by HomeSeer have the same issue. What I meant was if I turn on the lights individually true HomeSeer or the admin console(both ultimately the same thing I believe) they always turn on/off. When triggered true a scene they failed to turn on/off sometimes. Regardless of if it was triggered true ISY or HomeSeer.  

[raptor]

51 minutes ago, DAlter01 said:

If you have a communications issue causing your problem it can be a noise generator.  I had a similar situation to you some years back where I had a few devices that were intermittantly working.  Eventually I bought an ultra wideband handheld receiver that receives 132KHZ frequency (Insteon's powerline frequency) and  just walked around the house looking for electronics that generated a lot of noise on that frequency.  It was englightening.  I found that some of my flourescent light ballasts were somewhat noisy and some LED light bulbs were extremely noisy.  Both of these items were intermitant noise generators that only caused noise when on.  All electronics in the house generated noise at 132KHZ but the above created significant more noise (static).  I only had to replace the problem LED bulbs and my comms issue was resolved.  Had that not fixed the issue I would have also replaced the ballasts.  The radio I bought was a used Yaesu VR-120 on ebay.  That radio is discontinued though.  I believe an Icom RC-I6 is essentially the same ultra wideband receiver and runs about $200.  It's a valuable tool in my view.  There may be better ways to hunt down noise generators but this worked for me.  

Thanks. I might look into that. 

[Brian H]

Another problem for power  line communications.

Is an electronic device with a capacitor across its AC power input. It is very effective at keeping the devices internal electronic noise off of the power lines. It also will absorb Insteon power line commands.

Noise is one as mentioned the other can be a signal sucker. I have a portable AC unit. That has a capacitor across its AC Input. It made one of my power  line only ApplianceLinc modules intermittent. Until I put a Dual Band module in its pass  through outlet on the front of the case.