How is it possible that status can get out of sync?

[to_lighter]

Hi gang,

 

I'm currently working to eliminate noise on my electrical wiring to improve the reliability of my Insteon network, which is controlled by an ISY99i. Occasionally I will trigger a program and one or more of the lights will not respond. However, the ISY99 thinks that the light has responded and changes the status. For example, I can click an "All Off" button and be left with one or more lights still on. When you check their status in the ISY99, the status has been changed to "Off". Other programs that are triggered when all the lights are off start up, even though quite clearly the light is still on.

 

This is behavior that I would have expected from X10 equipment, but I thought that Insteon was supposed to keep trying until it received a confirmation back from the target switch. I can see that the ISY99 might not be able to accurately communicate with a switch, but if that were the case, why would the status of the switches be updated as if the program had proceeded properly and all of the switches responded as they were supposed to? If I manually query a switch where the status is out of sync, the ISY99 will accurately correct the status.

 

It seems like the ISY99 is executing the program, sending the commands, but not waiting to see if they are received properly, and simply updates the status of the switches assuming that all has gone according to plan.

 

None of my programs send X10 commands, and I have no legacy X10 equipment.

 

All of this has left me working to identify sources of noise, so that I can increase the reliability of the first round of signaling, which is disappointing as I thought that Insteon was supposed to be more robust and eliminate many of these issues.

 

Any thoughts?

 

Cheers!

[Michel Kohanim]

Hello to_lighter,

 

For group commands, ISY predicts the outcome mostly because we were never able to get group cleanup commands to work properly (they still don't especially with the inclusion of i2). Furthermore, processing group clean up commands bugged down the PLM to the point that you could not process anything else when you turned on/off a large scene. It was a pros/cons decision and we took the fast response time path (as you can see, the status updates are immediate on your ISY and all the clients on the network).

 

We can surely revisit this decision if we do have a lot of interest from our user community.

 

With kind regards,

Michel

 

Hi gang,

 

I'm currently working to eliminate noise on my electrical wiring to improve the reliability of my Insteon network, which is controlled by an ISY99i. Occasionally I will trigger a program and one or more of the lights will not respond. However, the ISY99 thinks that the light has responded and changes the status. For example, I can click an "All Off" button and be left with one or more lights still on. When you check their status in the ISY99, the status has been changed to "Off". Other programs that are triggered when all the lights are off start up, even though quite clearly the light is still on.

 

This is behavior that I would have expected from X10 equipment, but I thought that Insteon was supposed to keep trying until it received a confirmation back from the target switch. I can see that the ISY99 might not be able to accurately communicate with a switch, but if that were the case, why would the status of the switches be updated as if the program had proceeded properly and all of the switches responded as they were supposed to? If I manually query a switch where the status is out of sync, the ISY99 will accurately correct the status.

 

It seems like the ISY99 is executing the program, sending the commands, but not waiting to see if they are received properly, and simply updates the status of the switches assuming that all has gone according to plan.

 

None of my programs send X10 commands, and I have no legacy X10 equipment.

 

All of this has left me working to identify sources of noise, so that I can increase the reliability of the first round of signaling, which is disappointing as I thought that Insteon was supposed to be more robust and eliminate many of these issues.

 

Any thoughts?

 

Cheers!

[to_lighter]

Hello to_lighter,

 

For group commands, ISY predicts the outcome mostly because we were never able to get group cleanup commands to work properly (they still don't especially with the inclusion of i2). Furthermore, processing group clean up commands bugged down the PLM to the point that you could not process anything else when you turned on/off a large scene. It was a pros/cons decision and we took the fast response time path (as you can see, the status updates are immediate on your ISY and all the clients on the network).

 

We can surely revisit this decision if we do have a lot of interest from our user community.

 

With kind regards,

Michel

 

Hi gang,

 

I'm currently working to eliminate noise on my electrical wiring to improve the reliability of my Insteon network, which is controlled by an ISY99i. Occasionally I will trigger a program and one or more of the lights will not respond. However, the ISY99 thinks that the light has responded and changes the status. For example, I can click an "All Off" button and be left with one or more lights still on. When you check their status in the ISY99, the status has been changed to "Off". Other programs that are triggered when all the lights are off start up, even though quite clearly the light is still on.

 

This is behavior that I would have expected from X10 equipment, but I thought that Insteon was supposed to keep trying until it received a confirmation back from the target switch. I can see that the ISY99 might not be able to accurately communicate with a switch, but if that were the case, why would the status of the switches be updated as if the program had proceeded properly and all of the switches responded as they were supposed to? If I manually query a switch where the status is out of sync, the ISY99 will accurately correct the status.

 

It seems like the ISY99 is executing the program, sending the commands, but not waiting to see if they are received properly, and simply updates the status of the switches assuming that all has gone according to plan.

 

None of my programs send X10 commands, and I have no legacy X10 equipment.

 

All of this has left me working to identify sources of noise, so that I can increase the reliability of the first round of signaling, which is disappointing as I thought that Insteon was supposed to be more robust and eliminate many of these issues.

 

Any thoughts?

 

Cheers!

 

Thanks Michel,

 

I for one would prefer accuracy over speed, however, it is hard to say for sure without knowing just how big a speed hit we are talking about. Is there a way to put that in as a preference option, allowing the user to change back and forth between modes?

 

Cheers!

[MikeB]

One comment I want to add is that although I also prefer accuracy over speed, with Insteon powerline commands sometimes improved speed means better accuracy overall.

 

If your powerline and/or PLM is flooded with activity, in my experience additional button presses that occur during this flood can be missed.

[to_lighter]

Thanks for all of the prompt replies.

 

I've been mulling on this through the day. I don't know the specifics of the Insteon system, so I don't understand why we have a choice of either:

 

1) Assume all commands went through - fast

or 2) Poll devices to see if commands went through - slow

 

Aren't the switches replying to the PLM to say that they received the command? This is the implication in the Insteon documentation. If that is the case, why not just program the ISY to flag those switches that responded with errors or didn't respond at all? This could potentially be fast and accurate.

 

I am the newbie, and don't have any great technical insight into this system, so I look forward to further answers for those in the know. Thanks!

 

Cheers!

[Michel Kohanim]

Hello to_lighter,

 

Apologies for not being clear. I did NOT say that we should poll. Let me clarify. PLM has two types of commands:

1. Send direct command

2. Send group command

 

If we use the "send group command", PLM will wait for all the devices to respond to the scene command. During this time, none of your other schedules/programs/timers/GUI will work. And, even if they worked, they would be 100% unreliable to the point that ISY will be out of synch probably the same (if not more) amount of time as it is now.

 

What we do instead is that we trick the PLM into thinking that we are sending a direct command but we actually change the flags in the packet that the receiving devices accept it as a group command. This way, the PLM does not waste time doing clean up and the end devices respond to group commands.

 

Now, as I mentioned before, we are very open to revisiting this scenario. This said, though, I am confident that you'll be even more disappointed because of all the schedules that fire but are NACK'ed by the PLM because it's busy cleaning up.

 

With kind regards,

Michel

 

Thanks for all of the prompt replies.

 

I've been mulling on this through the day. I don't know the specifics of the Insteon system, so I don't understand why we have a choice of either:

 

1) Assume all commands went through - fast

or 2) Poll devices to see if commands went through - slow

 

Aren't the switches replying to the PLM to say that they received the command? This is the implication in the Insteon documentation. If that is the case, why not just program the ISY to flag those switches that responded with errors or didn't respond at all? This could potentially be fast and accurate.

 

I am the newbie, and don't have any great technical insight into this system, so I look forward to further answers for those in the know. Thanks!

 

Cheers!

[to_lighter]

Thanks Michel,

 

Would it be faster/more responsive/etc if large groups were broken into smaller ones? For example, if I want to turn off 30 lights, would it be better to do 6 groups of 5 lights? I recognize that not all lights would turn off at the same time this way.

 

Also, when I was fighting noise problems in my Master Bedroom, I was only trying to turn off about 5 lights. Any lights that didn't turn off would usually turn off if I hit the button again. In that scenario, it would have been very useful for the ISY to recognize one of the lights had not responded properly, and resend the command.

 

Cheers!

[Michel Kohanim]

Hi to_lighter,

 

Interesting idea (dividing into groups) but it will require automatic creation of groups/scenes which is something I'd rather not do (causes a lot of confusion).

 

As soon as we have 2.7 out, I am going to investigate group commands again and see if there's anything we can do to alleviate the issues.

 

With kind regards,

Michel

 

Thanks Michel,

 

Would it be faster/more responsive/etc if large groups were broken into smaller ones? For example, if I want to turn off 30 lights, would it be better to do 6 groups of 5 lights? I recognize that not all lights would turn off at the same time this way.

 

Also, when I was fighting noise problems in my Master Bedroom, I was only trying to turn off about 5 lights. Any lights that didn't turn off would usually turn off if I hit the button again. In that scenario, it would have been very useful for the ISY to recognize one of the lights had not responded properly, and resend the command.

 

Cheers!