Inexplicable status change

[tjkintz]

This is an installation/configuration that has been stable for over a year. Simplifying the description, I have a 2477D SwitchLinc Dimmer and a follower program that turns another light on or off depending on a status change of the 2477D. Last night the default ISY status program ran at 3:00 AM and the 2477D status was 0%. At 3:01:04 AM the status of the 2477D changed to 76% thereby causing the follower program to turn on a light. Being in a garage closet, I am sure nobody actually pushed the 2477D paddle. Was this a random glitch? Maybe the 2477D going bad? Has anyone experienced anything like this or has any reasonable explanations? 

[larryllix]

This is an installation/configuration that has been stable for over a year. Simplifying the description, I have a 2477D SwitchLinc Dimmer and a follower program that turns another light on or off depending on a status change of the 2477D. Last night the default ISY status program ran at 3:00 AM and the 2477D status was 0%. At 3:01:04 AM the status of the 2477D changed to 76% thereby causing the follower program to turn on a light. Being in a garage closet, I am sure nobody actually pushed the 2477D paddle. Was this a random glitch? Maybe the 2477D going bad? Has anyone experienced anything like this or has any reasonable explanations? 

There is a phantom 'All On' ghost that has plagued Insteon / ISY users for years now.

 

How many Insteon devices do you have?

How many links / scenes are you using in this device?

[lilyoyo1]

The all on bug generally effects all devices not just 1 so I question whether or not this comes from that bug (unless that's the only device).

 

Was the light actually or or just showing on? Is it part of any programs?

[tjkintz]

Re: how many devices do I have, I had to count; about 122 devices. It was only this device that had the anomaly. The light was not visibly on but it is a dimmer switch being used for a non-dimmable fluorescent light.  I have the on level set at 100% and it has always worked fine. I have several fluorescents controlled this way with dimmers with no problems. I did not look at the led's to see if there were somewhere in the middle and now it has been turned off programmatically so the state is 0%.

 

The switch is a member of two scenes. Neither scene has a controller; they are both controlled programmatically.

 

The switch has 5 links and they match the ISY links table.Interestingly, there were two adjacent closets with dimmers whose links tables did not perfectly match the ISY tables. Although probably not related to the problem I restored those devices from the ISY tables.

[Brian H]

If it is controlling the fluorescent light as its load.

You are asking for troubles. Even at 100% On and fastest ramp rate. There is still some changes in the AC waveform and can eventually end in the switch or lights being damaged.

You are lucky so far.

[MWareman]

This is an installation/configuration that has been stable for over a year. Simplifying the description, I have a 2477D SwitchLinc Dimmer and a follower program that turns another light on or off depending on a status change of the 2477D. Last night the default ISY status program ran at 3:00 AM and the 2477D status was 0%. At 3:01:04 AM the status of the 2477D changed to 76% thereby causing the follower program to turn on a light. Being in a garage closet, I am sure nobody actually pushed the 2477D paddle. Was this a random glitch? Maybe the 2477D going bad? Has anyone experienced anything like this or has any reasonable explanations?

The query all runs at 3am, and this will trigger all programs that have ‘status’ as a test condition - even if the status did not change (since the status of the device is updated).

 

If you want the program to evaluate only when a switch paddle is clicked, you must use ‘control’ instead of ‘status’.

[tjkintz]

MWareman. Thanks for the response but what you say is not true. I've got over two dozen programs and the way I test for a paddle click is to test status for not off. I have made several posts on testing status instead of control to avoid testing  for on/off, fast on/off, fade up/down, etc. Testing status for not off catches all transitions to some level of on. Testing status for off catches the transition from some level of on to off. The program only gets triggered when the status changes, never at 3:00AM when the Query runs. 

[MWareman]

MWareman. Thanks for the response but what you say is not true. I've got over two dozen programs and the way I test for a paddle click is to test status for not off. I have made several posts on testing status instead of control to avoid testing for on/off, fast on/off, fade up/down, etc. Testing status for not off catches all transitions to some level of on. Testing status for off catches the transition from some level of on to off. The program only gets triggered when the status changes, never at 3:00AM when the Query runs.

Testing for status triggers when the light is remotely controlled or queried (as you are seeing) as well as paddle clicks. You can test this yourself. Therefore, testing for status does trigger on paddle clicks - but not ONLY paddle clicks.

 

If you want ONLY paddle clicks, you must use control, not status.

 

To accommodate sloppy clicks as you say, you’ll have to check for ‘On’ and ‘not off’ - for each of ‘On’ ‘fast-on’, ‘dim’ etc... no way around that.

[tjkintz]

I agree with all you said except for Query. If Query triggered a program that tested status then Admin Console would show at least a last run time of 3:00 AM each day for each of those programs. It doesn't. The only time the last run time changes is when the status changes through a key press or a program changes it. That was the whole point of my original post. The program had been running without a problem for over a year. Then inexplicably that program, and only that program (I have lots more that test status), triggered. Also it didn't trigger at 3:00 AM when the Query ran, it triggered at 3:01 AM. The Query program only shows devices that have a not Off status, showing the percentage that they are on. At 3:00 the Query program did not show the device was on. At 3:01 that status changed from Off to 76% on. It wasn't the Query, a key press or a program that changed it. And it was a weird percentage to be on. It must have been some electronic hiccup. It never happened before or since on any device that tests status. 

 

Having said all this, the Query All program is a Set Scene Query, and the device is part of the scene. I have never tried a Set device Query to see if that would trigger a program that tests it status.

[MWareman]

The query goes device by device. It’s entirely possible that this device got queried at 3:01.

 

Also, there was a bug a while ago that status would trigger each and every query. I think that’s sorted now, so status will now only trigger if the query results in a change in the status of the device.

 

Is it possible that you had bad comunications and an ‘on’ message from a paddle off didn’t make it back to ISY from earlier then the query got the real status (triggering your program) at 3:01?

 

This is the kind of issue that means you really should use control if you are testing for physical operation of the paddle. There is no way to catch the edge cases with status. Status has its uses when you want to trigger on any change - even those not initiated from the paddle.

[tjkintz]

"Is it possible that you had bad comunications and an ‘on’ message from a paddle off didn’t make it back to ISY from earlier then the query got the real status (triggering your program) at 3:01?"

 

I thought of that too and took a look at the log which goes back to 1/15/2018. All the log entries show that nothing was on in the whole house at 3:00AM before the day in question (1/24/18). I agree that it could have taken until 3:01AM for the query to hit that switch. The log also shows that the switch was not used from 1/15 until 11:50 AM on 1/24. It couldn't have been a lost 'on' message but obviously some weird thing happened to get the status to 76%. I just did a manual test setting the switch to 76% to see if the light came on (reminder, I am using a dimmer switch to control strip fluorescent lights). 76% was enough to turn the lights on yet on the morning of the event, the light was not on even though the query reported a status of 76%. I think it will remain an unsolved mystery.

 

For what it is worth, the switches and programs are for the following situation:

What was once a big garage closet has been subdivided into smaller closets radiating off of a common area which I refer to as a foyer. Each smaller closet has a door, its own light and its own dimmer. The foyer also has its own light and dimmer. To prevent the smaller closet lights from being accidentally left on, I programmed the foyer dimmer as a follower of the smaller closets lights. When any of the smaller closet lights is on, the foyer light will be turned on. When the last smaller closet light gets turned off, the foyer light will turn off. In addition there is a program such that if the foyer light gets turned off, it will turn off the lights in all the smaller closets.  I don't care about the physical operation of the paddles, just if something is on or off. The follower is a simple program that has always worked fine until the event in question and has worked fine ever since.The code for the follower in the foyer is:

 

 

If

        Status  'Garage / Closets / Bike' is not Off

     Or Status  'Garage / Closets / Supplies (bulbs, etc.)' is not Off

     Or Status  'Garage / Closets / Supplies (paint, etc.)' is not Off

     Or Status  'Garage / Closets / Wine' is not Off

 

Then

        Set 'Garage / Closets / Foyer' On

 

Else

        Set 'Garage / Closets / Foyer' Off

 

 

 

[MWareman]

I don't care about the physical operation of the paddles, just if something is on or off.

 

Well, that seems like a perfectly valid and appropriate reason to trigger on status.

 

I think this one may have to be listed as a random glitch...