Jump to content

Light still on even after it reports as off - how is this possible?


502ss

Recommended Posts

So I have one dual band switch dimmer that is controlling an LED spotlight. I sometimes have issues communicating with this switch (probably for two reasons, 1: it is farthest from any other device. 2: it has LED bulbs in the sockets). I have written my programs to work around some of the communication issues. Every once in a while though the program turns the light off (where it reports off in the ISY)yet the load is still on. This of course breaks my programs because as far as the ISY is concerned it's off! How does this physically happen? I thought the insteon language prevented this from happening? Any Ideas?

 

Thanks

Jim

Link to comment
Share on other sites

ISY assumes that lights do what they are told.  If you run a query on the light it will correct.  I could be wrong on this, but my recollection is that lights in scenes do not confirm status, where lights that are directly commanded do.  So a light controlled by instructing a scene change gets an assumed state, where a direct device command reports the actual status (or failed com).

Link to comment
Share on other sites

ISY assumes that lights do what they are told.  If you run a query on the light it will correct.  I could be wrong on this, but my recollection is that lights in scenes do not confirm status, where lights that are directly commanded do.  So a light controlled by instructing a scene change gets an assumed state, where a direct device command reports the actual status (or failed com).

 

A scene cannot trigger a program.

Link to comment
Share on other sites

???  I saw no such suggestion.  Am curious what I missed.  I am also pretty certain apostolakisl knows this.

 

I suppose he is referring to the OP which talks about his programs not working because they are, I assume, at least in part, based on device status.  

 

But you are definitely correct in that I made no suggestion that a scene would trigger a program.  But a scene definitely would change the status of devices which could be a program trigger.

 

My point was that a scene command, unlike a direct command to a device, does not generate a response from the affected device(s) confirming execution of the command.  Therefore, ISY, I do believe, simply assumes it happened.  The only way for ISY to confirm execution of the scene at each device would be for a separate query to happen after the fact.

Link to comment
Share on other sites

Learn something new everyday! It just happens that this light is part of a scene with another floodlight. So the ISY will be more apt to have the state of the switch (on/off) reflect the real load of the switch if given a command directly vs. from within a scene. Might be time to just remove this scene and control both lights individually!

Link to comment
Share on other sites

I have a 2441ZTH stat that I can issue commands to, and ISY shows the parameters as changed, every time.

After a query none of the parameters have changed and all change back to their original values.

 

Some of this confirmation from the device is bunk. ISY makes some assumptions of some settings without scene usage, also.

 

This may only be device dependent.

Link to comment
Share on other sites

And for those wondering.......

 

I have programs that control these flood lights. I also have 3 variables (3 floods) that are also changed (0 to 1 or 1 to 0) depending on if the programs are turning the lights on or off.

 

I then have 3 other helper programs that compare the state of each light to the variable. If there is a mismatch between the variable and the status of the switch then the program either turns the switch on or off. It then checks again until the variable matches the state of the switch.

 

This of course works perfectly unless the switch reports it is off even though the load is still on hence my problem and the reason for my post!

Link to comment
Share on other sites

I have a 2441ZTH stat that I can issue commands to, and ISY shows the parameters as changed, every time.

After a query none of the parameters have changed and all change back to their original values.

 

Some of this confirmation from the device is bunk. ISY makes some assumptions of some settings without scene usage, also.

 

This may only be device dependent.

I have 2 of the same thermostats and they do behave very strangly sometimes! I wish they would come out with a decent native insteon tstat but that discussion is for another thread! :)

Link to comment
Share on other sites

You can run a scene test using ISY and see how many hops.  More hops means poor com.  Com quality that is great on one test, and poor at a different time indicates intermittent noise.  Poor com on all tests indicates either consistent noise or just a poor path to the device, which might be improved by adding more dual band devices on the circuit and nearby.  

Link to comment
Share on other sites

And for those wondering.......

 

I have programs that control these flood lights. I also have 3 variables (3 floods) that are also changed (0 to 1 or 1 to 0) depending on if the programs are turning the lights on or off.

 

I then have 3 other helper programs that compare the state of each light to the variable. If there is a mismatch between the variable and the status of the switch then the program either turns the switch on or off. It then checks again until the variable matches the state of the switch.

 

This of course works perfectly unless the switch reports it is off even though the load is still on hence my problem and the reason for my post!

 

You can have an ISY initiate a query.  It is sloppy to have to do that, but you might be able to improve your programs actions by adding some queries.  Just depends on the structure of your program and what you are trying to do as to whether a query would fix things.

Link to comment
Share on other sites

You can run a scene test using ISY and see how many hops.  More hops means poor com.  Com quality that is great on one test, and poor at a different time indicates intermittent noise.  Poor com on all tests indicates either consistent noise or just a poor path to the device, which might be improved by adding more dual band devices on the circuit and nearby.

 

Yeah, like I said originally this device has always been a problem child. It is out in my detached garage and is furthest away from any other dual band device. To make matters worse the floodlight has two LED bulb in the socket! :)

Link to comment
Share on other sites

In your program, are you turning the light on directly, or with a scene? Scene actions are not confirmed, the ISY will assume that it worked and indicate the state based on the last command issued.. However, if you are switching the device directly, the communication is confirmed.

 

If you are controlling it directly, one other possibility is that the switch in question has become "confused" which happens to Insteon Devices from time to time. Try a factory reset of the switch, followed by right clicking on it in the admin console and performing a "Restore Device"

 

The factory reset procedure for most switchlincs is: On your Insteon Wall Switch, press and hold the set button until the device beeps. Press and hold the set button again, then tap the set button. 

 

Paul

Link to comment
Share on other sites

You can have an ISY initiate a query.  It is sloppy to have to do that, but you might be able to improve your programs actions by adding some queries.  Just depends on the structure of your program and what you are trying to do as to whether a query would fix things.

I think I will try removing it from the scene first. If I can fix the issue of the switch reporting something different than what the load shows then my helper programs will operate as expected and make sure the lights are either on or off!

 

It's always good to understand the inner workings and how the ISY interprets things because a LED spotlight being left on is not a big deal but 200 feet of heat tape on my roof being left on is a whole different issue! I have similar helper programs written to absolutely make sure the heat tape gets turned off when it's told to!

Link to comment
Share on other sites

In your program, are you turning the light on directly, or with a scene? Scene actions are not confirmed, the ISY will assume that it worked and indicate the state based on the last command issued.. However, if you are switching the device directly, the communication is confirmed.

 

If you are controlling it directly, one other possibility is that the switch in question has become "confused" which happens to Insteon Devices from time to time. Try a factory reset of the switch, followed by right clicking on it in the admin console and performing a "Restore Device"

 

The factory reset procedure for most switchlincs is: On your Insteon Wall Switch, press and hold the set button until the device beeps. Press and hold the set button again, then tap the set button. 

 

Paul

Currently I am controlling it via a scene and from what I read here may be what's causing some of my issues. I will adjust to talk to it directly and see if things improve!

Link to comment
Share on other sites

I think I will try removing it from the scene first. If I can fix the issue of the switch reporting something different than what the load shows then my helper programs will operate as expected and make sure the lights are either on or off!

 

It's always good to understand the inner workings and how the ISY interprets things because a LED spotlight being left on is not a big deal but 200 feet of heat tape on my roof being left on is a whole different issue! I have similar helper programs written to absolutely make sure the heat tape gets turned off when it's told to!

 

If ISY fails to get a response and you have the admin console open, you will get an error message (referring to direct commands rather than scene).  But it still won't fix the fact that ISY doesn't know for sure the status.  The command might have gone through and been executed but the response was lost.  Or maybe the command didn't go through.  If the com is borderline, and you can't get better com, then you might consider adding some queries.  If it is one of those things that works 50% of the time, then adding a couple queries might get you up to 88% accurate state reporting.

Link to comment
Share on other sites

I have 2 of the same thermostats and they do behave very strangly sometimes! I wish they would come out with a decent native insteon tstat but that discussion is for another thread! :)

That is what the current discussion is about, in this  thread.

 

People   state that ISY always confirms status, after issuing a control, but my 2441ZTH stats prove that is not always true. MY stats will show whatever you commend on the manual status page and continue t show that unless a query is done or a new status is received from the stats.

 

Maybe some devices have different confirmation setups but not all signals are statuses for all devices are confirmed before showing them valid in the admin console.

 

It has also been stated by some quite knowledgeable people here, that scenes also have confirmation follow up in their protocol process. This I have never investigated the actual protocol.

Link to comment
Share on other sites

Does Heat Tape turn on consistently but not off consistently? That is a sign that its generating noise after being turned on, and and that it needs to be filtered some how..

Heat tape is working fine but I am not willing to take the chance that for some reason it doesn't and gets left on by accident (even though it might say the status is off) I got rid of the query all program a long time ago when I was having all on issues. If I want querys I will need to put them in individually

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...