Can ISY compensate for lost switch transitions?

[markbrown1]

I've got several rooms in my house where there are two adjacent Switchlinc dimmers. If these are pressed close to simultaneously, it seems that messages to other devices linked to these switches are lost (thus keypad buttons that are supposed to indicate light status in remote rooms don't track). I'm no expert on the Insteon protocol, but this seems to be an issue where a device won't send status when it sees the network is busy (if true, not the best choice, but reality nevertheless).

 

So, I've been trying to write a series of programs in ISY which watch for this occurrance and correct the scenes. My basic plan was to have a program which looks for "on" or "off" control on either switch in the pair, then executes a status check command on both switches. (basically if either switch in the pair changes, assume the other might have but didn't report). Probably not relevent, but in my case these switches all control the loads. Then, separate programs compare the status of the switch to the status of keypad buttons or other linked switches, and if different set those to match the state of the switches queried in the first program.

 

Needless to say, so far I haven't been successful in getting this to work very well. Has anyone else come up with a solution to this problem? If an interesting topic, I can post the programs I've tried and describe how they've fallen short of perfection, but I'm hoping that someone else has already solved this and I can stop straining my brain and just copy another's good work.

[Michel Kohanim]

Hello Mark,

 

Apologies for a tardy reply.

 

I don't think you can mostly because the PLM, just like the other linked devices, will not receive the signal and thus ISY will not know anything about the button presses.

 

Unfortunately - and I am sure MikeB can give you more feedback - there's no solution to this problem (signals canceling each other out).

 

With kind regards,

Michel

I've got several rooms in my house where there are two adjacent Switchlinc dimmers. If these are pressed close to simultaneously, it seems that messages to other devices linked to these switches are lost (thus keypad buttons that are supposed to indicate light status in remote rooms don't track). I'm no expert on the Insteon protocol, but this seems to be an issue where a device won't send status when it sees the network is busy (if true, not the best choice, but reality nevertheless).

 

So, I've been trying to write a series of programs in ISY which watch for this occurrance and correct the scenes. My basic plan was to have a program which looks for "on" or "off" control on either switch in the pair, then executes a status check command on both switches. (basically if either switch in the pair changes, assume the other might have but didn't report). Probably not relevent, but in my case these switches all control the loads. Then, separate programs compare the status of the switch to the status of keypad buttons or other linked switches, and if different set those to match the state of the switches queried in the first program.

 

Needless to say, so far I haven't been successful in getting this to work very well. Has anyone else come up with a solution to this problem? If an interesting topic, I can post the programs I've tried and describe how they've fallen short of perfection, but I'm hoping that someone else has already solved this and I can stop straining my brain and just copy another's good work.

[markbrown1]

Michel,

 

Thanks for the response. I understand that if both switches are pressed, and neither message gets through, then the only possible fix would be to poll the switch status, which if done with any frequency would generate a lot of traffic. While I occasionally see both switch presses lost, most of the time one of the transitions does get through. So I was polling both switches whenever one changed to check if the other had too, then comparing the switch status to other devices in the scene, and if different setting the scene to match the switch. The biggest problem I ran into with this scheme (at least what I think the problem was) was that the act of polling the switches following a press (played with delays from the "control" event of 0 to 5 seconds) in fact just created another window where the status request could interfere with the second switch correctly reporting status in the first place.

 

I'm not quite ready to give up, but this is turning out to be more of a challenge than I thought, and I believe I'll have to settle for a reduction in the frequency of problems rather than a real solution. My next idea was to cut down on the status traffic by being more specific in my polling (if switch A changes, read status of switch B, and if switch B changes read status of switch A, where before I was looking for switch A or B to change, then reading the status of switches A and . Second, I was going to concede that I couldn't correct the scene too quickly without interfering with switch presses that were only slightly offset from each other, so looking at the delay before detecting inconsistency in the scene and adjusting it to something more like 10 seconds may be better. I suspect that if I looked at several days worth of event logs I would see that the time between successive switch presses is typically a few seconds or less (mostly coming from the physically adjacent switches) or a random distribution of much longer times (normal lightswitch usage patterns for non-adjacent switches)

 

In the end, of course, as long as it is possible for switch transitions to get lost, it's not possible to completely prevent inconsistent status between devices - I am just trying to reduce the frequency by as much as possible. My approach is generally similar to other threads in the forum where people are trying to keep scene status indicators correct following manual changes in the scenes. The fun of having the ISY is that I don't necessarily have to accept all of the shortcomings inherent in Insteon.

 

I really didn't expect you to have the answer (this is, after all, not a problem with your product), but I was assuming that others were bothered by the same issue, and that perhaps someone with more experience with the ISY and Insteon and/or more creativity than myself might come up with an approach with fewer side effects.

 

Thanks as always for the great support,

 

mark

[Michel Kohanim]

Hi Mark,

 

I almost wrote a code snippet then I realized that I was basically doing what you had outlined! I shall think more ...

 

With kind regards,

Michel

 

Michel,

 

Thanks for the response. I understand that if both switches are pressed, and neither message gets through, then the only possible fix would be to poll the switch status, which if done with any frequency would generate a lot of traffic. While I occasionally see both switch presses lost, most of the time one of the transitions does get through. So I was polling both switches whenever one changed to check if the other had too, then comparing the switch status to other devices in the scene, and if different setting the scene to match the switch. The biggest problem I ran into with this scheme (at least what I think the problem was) was that the act of polling the switches following a press (played with delays from the "control" event of 0 to 5 seconds) in fact just created another window where the status request could interfere with the second switch correctly reporting status in the first place.

 

I'm not quite ready to give up, but this is turning out to be more of a challenge than I thought, and I believe I'll have to settle for a reduction in the frequency of problems rather than a real solution. My next idea was to cut down on the status traffic by being more specific in my polling (if switch A changes, read status of switch B, and if switch B changes read status of switch A, where before I was looking for switch A or B to change, then reading the status of switches A and . Second, I was going to concede that I couldn't correct the scene too quickly without interfering with switch presses that were only slightly offset from each other, so looking at the delay before detecting inconsistency in the scene and adjusting it to something more like 10 seconds may be better. I suspect that if I looked at several days worth of event logs I would see that the time between successive switch presses is typically a few seconds or less (mostly coming from the physically adjacent switches) or a random distribution of much longer times (normal lightswitch usage patterns for non-adjacent switches)

 

In the end, of course, as long as it is possible for switch transitions to get lost, it's not possible to completely prevent inconsistent status between devices - I am just trying to reduce the frequency by as much as possible. My approach is generally similar to other threads in the forum where people are trying to keep scene status indicators correct following manual changes in the scenes. The fun of having the ISY is that I don't necessarily have to accept all of the shortcomings inherent in Insteon.

 

I really didn't expect you to have the answer (this is, after all, not a problem with your product), but I was assuming that others were bothered by the same issue, and that perhaps someone with more experience with the ISY and Insteon and/or more creativity than myself might come up with an approach with fewer side effects.

 

Thanks as always for the great support,

 

mark

[IndyMike]

Mark,

 

A couple of additional possibilities:

 

1) If one of the two switches is not controlling a load (part of a 3 way) you could develop a program to control the second switch through double taps (fast on) or fades. This would eliminate the interference between the two.

 

2) Again if one of the switches is not load connected, you could replace both units with a single Keypadlinc. I have a couple of locations where I've combined 4 mechanical switches (3 ways) into a single KPL. Again, since the KPL is controlling all of the outgoing signals it appears to prevent the multiple switch activation phenomena.

 

IM

[markbrown1]

IM,

 

Thanks for the suggestions. Unfortunately, in all three scenarious in my house where there are double switchlinc's, they are all controlling two loads. Otherwise, the idea of doing a double tap for one of the lights, and a single for the other is very intriguing (in fact, exactly the sort of creative suggestion I was hoping to see when I posted the question). I guess I could still pull it off by sticking an in-line device in the box and covering the second switchplate with a blank.

 

Of course, same problem with doing the keypadlinc - two loads to control. Additionally, two of the three locations are controlling fluorescent loads, so I'm reluctant to use keypadlincs. The other factor with keypadlincs is that I've really tried to avoid making them control any primary room lights, or more specifically I have maintained that when you walk into a dark room you can always just feel for a paddle switch and tap it to get some light. While the keypadlincs are very flexible and provide many interesting possibilities (I have 19 of them), they do take more "focus" from the user to get a light turned on vs. a switchlinc. However, one switchlinc and one keypadlinc would represent a pretty good solution for the room with incandescent lights, as it would be really hard to hit both a switchlink paddle and a keypadlinc button at the same time and I'd have two load-controlling switches. What to do with the other buttons . . .

 

Once again, thanks so much for the ideas. As Michel stated, there's really no way to "fix" this problem, so alternatives like those you suggested are great, since they circumvent the issue entirely.

 

mark

[Algorithm]

Mark,

 

A couple of additional possibilities:

 

1) If one of the two switches is not controlling a load (part of a 3 way) you could develop a program to control the second switch through double taps (fast on) or fades. This would eliminate the interference between the two.

 

2) Again if one of the switches is not load connected, you could replace both units with a single Keypadlinc. I have a couple of locations where I've combined 4 mechanical switches (3 ways) into a single KPL. Again, since the KPL is controlling all of the outgoing signals it appears to prevent the multiple switch activation phenomena.

 

IM

 

Hi Mark. A couple of excellent suggestions from Indy. Just a slight modification to suggestion number one: even though both of the SwitchLincs in each of your pairs is controlling a load, I think that Indy's idea can still work.

 

Consider the switches A and B. Single tap switch A to turn it on as usual. Double tap switch A to turn on load A directly and also, via a program, turn on load B. Same for off. If you want just load B on, single tap switch B as usual; double tapping switch B turns on load B directly and also, via a program, turns on load A. Same for off.

 

So, when you want just one load, use the corresponding switch as usual. When you want both loads, just double tap either switch (on or off). You will loose response time (program vs. direct), but less so than polling; and also ramp rates when double-tapped (not a consideration for relay-controlled devices such as fluorescents).

 

Having said all that, I do think your original idea has merit as long as one or the other of the two signals gets through. Please keep us informed of your progress with this or other ideas.