program runs but not correctly

[proj964]

i have two very similar programs. one runs and get the right result. the 2nd runs, but doesn't get the right result. when I look at the program, it's display is very strange. The code shows the status check is for "off" but the detail below says "responding". I have deleted this line and re-added it, but that doesn't help. If I click around, sometimes the detail shows "off" and sometimes "responding". When the program fails, it should run the "then" clause, but doesn't. The other very similar program that works, simply checks for a different device in the status line. 

[paulbates]

After you deleted the line, do you press "Save Changes" on the left before re-adding it? 

I would try that.... and press "Save Changes" again after re-adding it.

Paul

[proj964]

Thanks for the idea...

Yes I have saved the changes before...doesn't appear to make a difference.

[paulbates]

Is the device Insteon, Z-wave or ?  Does the switch seem to function correctly when you turn it on and off from the admin console? What happens if you query t a few times from the admin console (leaving 3 - 5 seconds between retries)? It could be a device or communications problem.

Edit: Turn on the event viewer when trying the on/off and query above (Tools/Diagnostics/Event viewer... set to level 3 device communications)... any errors? Post results here.

Also, while you should figure out what's going on, you can probably get rid of that statement. Since the sensor and program could retrigger while the light is on already from a previous run of the program, its not clear that the statement is affecting how the program performs.

[proj964]

Thanks for helping with this problem.

Device is Insteon ToggleLinc switch. It turns on/off just fine from the admin console. Query also works just fine; see attached file screenshot. 

The device status is there so that if the switch has been turned on manually, the program doesn't cause it to be turned back off. 

[paulbates]

13 minutes ago, proj964 said:

Thanks for helping with this problem.

Device is Insteon ToggleLinc switch. It turns on/off just fine from the admin console. Query also works just fine; see attached file screenshot. 

The device status is there so that if the switch has been turned on manually, the program doesn't cause it to be turned back off. 

 

Ok. The device looks ok and it doesn't make sense that the program would switch query back and forth with status. The only other option I can think of is disabling the program, and completely recreating it, eg... it sounds like something is wrong with the content of the program within the ISY. If that works, delete the original, disabled program.

I see what you're doing with the device status, by running a separate program, it will ensure that the delay and off are run.

[proj964]

Thanks. I will try disable and recreate. 

[proj964]

Hi, I recreated the program and disabled the old one. However, this did not help out. I have
included the latest screen shot of the recreated program. Now the status line is even more
confusing; although when I re-entered it, the condition test was "off". 

I should point out that when the motion detector was an insteon device, this set of programs 
worked just fine. Changing to zwave resulted in the problem of one program running correctly
and one not. 

[paulbates]

If its an insteon dimmer then it will be 0 - 100% status.  In the case of your program, you'll want it to be 0% = off. Not sure why that changed now.

Paul

[proj964]

I will set it back to "off" which is what I put there in the first place. But note the the bottom 
panel show "responding" yet again. Isn't it possible that there is a bug somewhere in the isy994i?

[paulbates]

Yeh, can't explain that one. You should open a ticket with UDI and provide a link to this thread.

Paul

[oberkc]

Out of curiosity, how did you initially add this switch to the ISY?  What device does the ISY think it is?  Is it possible that the ISY thinks is something different that what it actually is?

 

(It is just a hunch, but I wonder if this is a possible cause of the behavior you describe.)

[proj964]

It was added to the ISY994i by address. It is and shows as a 2466S ToggleLinc

[oberkc]

Is it a dimmer or relay?  I cannot help but wonder what would happen if you remove it again, then add it by putting the ISY into linking mode, then putting the switch into linking mode.

[oberkc]

Unfortunately, I don't use 4.X software any more, and cannot compare it to what I see on my admin panel.  I recall ON and OFF program options for relay devices, not percentages, but my memory could be faulty.

[paulbates]

The S in the product number means its a relay. I have one of these (2466S) and it only presents on/off/responding for Status in a program. I would delete and readd the switch as recommended by oberkc.

Paul

[proj964]

Will remove and re-add per recommendation and report back. 

Update: I removed and added back earlier today with the status check for "off".

Did "Update" and "Save Changes".

Now it says "100%" and "responding" -- not what I put in when I added the switch back to the program. 

[oberkc]

I am out of ideas.  I have not seen a program change itself like this. 

 

[IndyMike]

On 8/5/2019 at 9:31 AM, proj964 said:

i have two very similar programs. one runs and get the right result. the 2nd runs, but doesn't get the right result. when I look at the program, it's display is very strange. The code shows the status check is for "off" but the detail below says "responding". I have deleted this line and re-added it, but that doesn't help. If I click around, sometimes the detail shows "off" and sometimes "responding". When the program fails, it should run the "then" clause, but doesn't. The other very similar program that works, simply checks for a different device in the status line. 

 

 

Hello proj964,

The lower panel is an "Action" panel for changing or adding to your program/conditions.  The fact that it shows "responding" indicates one of the options for adding to, or modifying your existing program.  Your existing program (if saved) is shown in the upper pane.  Bottom line - the lower pane is distracting you from the real problem.

 

1) Your IF statement checks the "dining room/outside light switch" status to make sure it is off.

2) Your program set the "dining room/outside light switch" to "ON".  This causes the program to re-trigger, and the "IF" statement is now false.

3) The program MAY exit before executing the remaining statements.  It's basically a race condition.

 

You could move the "dining room/outside light switch" ON statement to your "Security back timer" program to prevent the re-trigger.

 

[proj964]

IndyMike,

Thanks for the explanation.

I am not sure I understand this as the "Security - Front Lights" is an identical set of programs except it turns on/off a different Togglelinc. In all other ways, the "front" and "back" program sets are identical and the front never fails to operate as expected. Oh, and both front and back worked just fine, as is, when the motion sensor was an Insteon motion sensor (2844-222 configured as a 2842-222).

[IndyMike]

In general, you should not modify the state of your "IF" conditions within the program.  It will cause the program to re-trigger.

If you put a delay (1 sec) after the "Set dining room" statement, this program would exit 100% of the time. 

Without the delay, you have a race condition.  Hard to say if the re-trigger will take effect before you make it to calling your other program.

You may be getting "lucky" on your other program. 

Regardless, the "responding" drop down in the lower pane has no bearing on your saved program.  It is simply an option for modifying/adding to the program.

Please let us know if the modification works.  It's possible you have another race condition in your called program.

[oberkc]

1 hour ago, IndyMike said:

1) Your IF statement checks the "dining room/outside light switch" status to make sure it is off.

2) Your program set the "dining room/outside light switch" to "ON".  This causes the program to re-trigger, and the "IF" statement is now false.

3) The program MAY exit before executing the remaining statements.  It's basically a race condition.

I agree with statements 1) and 2).  I am not sure about statement 3).  My understanding is that the THEN actions would continue to completion UNLESS there was a WAIT or REPEAT action within.  Since there is no wait or repeat, I expect that this program would complete the entire THEN clause, even though the condition was retriggered and is now false.

I also agree that it is the upper pane that represents your program as it exists, and that I would not be concerned with the lower pane.  What I don't understand is why it would, without any apparent user interaction, change a condition from "is off" to "is 100%".  

[IndyMike]

Hello oberkc,

You may be correct.  My experience is from the original ISY back in 2006 (very dated).  At that time it was possible to set up a race condition in the manner that I described without a wait.  Many things have changed since that time.

I do not think we can test this without seeing the "security - back timer program".  There may be issues where communication failures/re-tries factor into the program timing.

In general, it's never advisable to modify the trigger conditions within the program.  We may need Chris to weight in on whether this specific implementation is a problem with Ver 4.7.3.  Realistically, I'm thinking he busy working on our 100's of other requests.

Sincerely,

IM

 

[proj964]

Security - Back Timer

[oberkc]

8 hours ago, IndyMike said:

In general, it's never advisable to modify the trigger conditions within the program. 

Probably a good rule-of-thumb, but I am not ready to say "never".  Still, I don't think that is the problem here.

My argument typically is the condition side of things: in most cases, I don't see a strong reason to check that a light is off before turning it on.  I see little harm in turning on a light that is already on, but a higher potential of unintended consequences by insisting checking that the light is off before turning it on.  In the case of proj964' program, I would simply eliminate the middle condition if I feared that the program is halting execution due to the condition flipping back to false.