How Did This Happen?

[apostolakisl]

At 3:46am this morning, I was sound asleep and suddenly the whole house music flips on. ???

 

I checked the log this am. I have a system query run at 3:45am. It read one of my kpl's as having 5 of the 8 buttons as on. Even though they were all off. They were off when I woke up this am and they were off when I went to bed. The ISY still thought they were on when I woke up.

 

I have a program that turns the whole house music on when one of those buttons turns on. So that is why the program ran and the music turned on.

 

But why did it think the buttons were on? There were no errors reported in the query. I really didn't think Insteon could read the wrong status of a device, I thought it either read it or it failed to read it.

[fitzpatri8]

Isn't there just one byte of each message devoted to a checksum? As such, an extended message could have multiple bits corrupted in such a way that the same checksum would be valid for a corrupted version as for the intended message. It would be unlikely, but it would be possible.

 

To prevent that from causing unintended operation, you should change your program trigger from button status to button control. As you found, 'status' can change based on line noise coinciding with extended messages exchanged when the ISY queries devices in the middle of the night. The Control trigger, on the other hand, requires the ISY hear a complete and intact standard length message originating from one of the keypads in question. The odds of line noise creating a complete message out of thin air aren't just unlikely, they are astronomical.

[apostolakisl]

Isn't there just one byte of each message devoted to a checksum? As such, an extended message could have multiple bits corrupted in such a way that the same checksum would be valid for a corrupted version as for the intended message. It would be unlikely, but it would be possible.

 

To prevent that from causing unintended operation, you should change your program trigger from button status to button control. As you found, 'status' can change based on line noise coinciding with extended messages exchanged when the ISY queries devices in the middle of the night. The Control trigger, on the other hand, requires the ISY hear a complete and intact standard length message originating from one of the keypads in question. The odds of line noise creating a complete message out of thin air aren't just unlikely, they are astronomical.

 

Yes, I had it that way at first, but I also wanted to be able to turn the music on from my phone and for that it has to be a "status" program.

[fitzpatri8]

You should be able to run an ISY program directly from your phone. What device is your program switching on to turn on the music-- an ApplianceLinc or an IOLinc or something else?

[IndyMike]

Lou,

 

This sounds very familiar - Have a look at Illusions thread here - Mysterious "Control Switched On" Notification

[Michel Kohanim]

Hi all,

 

Unfortunately communications with the PLM does not provide any checksum so we would not really know if this is a spurious/corrupted message.

 

Apart from a bug, I would have to assume that the result of the query returned the wrong status. I have seen this many times with KPL versions 2A through 2D (and especially 2A and 2D).

 

With kind regards,

Michel

[apostolakisl]

Hi all,

 

Unfortunately communications with the PLM does not provide any checksum so we would not really know if this is a spurious/corrupted message.

 

Apart from a bug, I would have to assume that the result of the query returned the wrong status. I have seen this many times with KPL versions 2A through 2D (and especially 2A and 2D).

 

With kind regards,

Michel

 

It is a v.2D

 

Fortunately, this is the first time this has happened in maybe 1 year or so since I got my global cache. If it happens again, I will probably just get rid of the 3am system query.

 

I have been using touch switch from my android. I don't think it has any direct control of programs. I know mobile linc is out for android but I haven't looked into that yet. I rarely use the phone, but like to have it as an option.

[Michel Kohanim]

apostolakisl,

 

I am quite surprised that this is the extent of problems you have had with your KPL 2D. I had my whole system light up like a Christmas tree and blink on/off randomly when I first installed KPL 2A and 2D.

 

With kind regards,

Michel

[oberkc]

I will probably just get rid of the 3am system query

 

Perhaps, as an alternative, you could insert a command to turn your music-controlling buttons off ahead of the query (this assumes you will never want music playing at 3am).

[IndyMike]

Isn't there just one byte of each message devoted to a checksum? As such, an extended message could have multiple bits corrupted in such a way that the same checksum would be valid for a corrupted version as for the intended message. It would be unlikely, but it would be possible.

 

To prevent that from causing unintended operation, you should change your program trigger from button status to button control. As you found, 'status' can change based on line noise coinciding with extended messages exchanged when the ISY queries devices in the middle of the night. The Control trigger, on the other hand, requires the ISY hear a complete and intact standard length message originating from one of the keypads in question. The odds of line noise creating a complete message out of thin air aren't just unlikely, they are astronomical.

 

Yes, I had it that way at first, but I also wanted to be able to turn the music on from my phone and for that it has to be a "status" program.

 

Lou,

 

Apologies for my previous post - I misread the above and thought you were using a control function.

 

Michel,

 

This is the first I've read about problems with the V.2A and V.2D KPL's reporting status. I have a number of both and have not picked them out a problem children. Is this another example of these devices not participating in the HOP communication, or something purely related to queries?

[Michel Kohanim]

Hello IM,

 

My experience with both of these versions has been related to unexplained behavior by devices linked to them as well as getting incorrect responses intermittently.

 

With kind regards,

Michel

[apostolakisl]

Hello IM,

 

My experience with both of these versions has been related to unexplained behavior by devices linked to them as well as getting incorrect responses intermittently.

 

With kind regards,

Michel

 

Well I have had at least once that a v.2c did some weird stuff. A few weeks ago I was going to bed and pushed one of the buttons that was set to turn off most of the lights in the house. Instead it turned on a completely unrelated light in the bedroom and woke my wife up. She was annoyed. That light was linked to a different button on the kpl. I think I vaguely remember a similar thing happening a year or so ago, but can't be sure. I do use that kpl every single day so these events are not common.

 

I don't recall anything else weird happening with the v.2d in which turned the music on. I have another v.2c which has never done anything weird, but I rarely use it.

[IndyMike]

Michel,

 

Thank you for the quick response. Illusion and I had focused on V.2D KPL's awhile back. We were performing device link scans (direct commands) and both saw a number of extended message transmissions in the logs. The extended message responses did not upset the link read communications - the ISY would re-issue the peek/poke command.

 

Is this the type of anomaly that occurs during group commands to upset things?

[Rob]

apostolakisl,

I am quite surprised that this is the extent of problems you have had with your KPL 2D. I had my whole system light up like a Christmas tree and blink on/off randomly when I first installed KPL 2A and 2D.

 

Interesting, first I've heard of that. I've had a few instances in the last year or so where I turned off a device linked to a secondary KPL button, ALL of the lights turned off. I just checked and it's a 2D.

 

Thanks

Rob