proj964 Posted August 5, 2019 Posted August 5, 2019 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 Posted August 5, 2019 Posted August 5, 2019 (edited) 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 Edited August 5, 2019 by paulbates
proj964 Posted August 5, 2019 Author Posted August 5, 2019 Thanks for the idea... Yes I have saved the changes before...doesn't appear to make a difference.
paulbates Posted August 5, 2019 Posted August 5, 2019 (edited) 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. Edited August 5, 2019 by paulbates
proj964 Posted August 5, 2019 Author Posted August 5, 2019 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 Posted August 5, 2019 Posted August 5, 2019 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. 1
proj964 Posted August 6, 2019 Author Posted August 6, 2019 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 Posted August 6, 2019 Posted August 6, 2019 (edited) 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 Edited August 6, 2019 by paulbates
proj964 Posted August 6, 2019 Author Posted August 6, 2019 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 Posted August 6, 2019 Posted August 6, 2019 Yeh, can't explain that one. You should open a ticket with UDI and provide a link to this thread. Paul
oberkc Posted August 6, 2019 Posted August 6, 2019 (edited) 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.) Edited August 6, 2019 by oberkc 1
proj964 Posted August 6, 2019 Author Posted August 6, 2019 It was added to the ISY994i by address. It is and shows as a 2466S ToggleLinc
oberkc Posted August 6, 2019 Posted August 6, 2019 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 Posted August 6, 2019 Posted August 6, 2019 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 Posted August 7, 2019 Posted August 7, 2019 (edited) 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 Edited August 7, 2019 by paulbates
proj964 Posted August 7, 2019 Author Posted August 7, 2019 (edited) 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. Edited August 7, 2019 by proj964 additional details.
oberkc Posted August 7, 2019 Posted August 7, 2019 I am out of ideas. I have not seen a program change itself like this.
IndyMike Posted August 7, 2019 Posted August 7, 2019 (edited) 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. Edited August 7, 2019 by IndyMike
proj964 Posted August 7, 2019 Author Posted August 7, 2019 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 Posted August 7, 2019 Posted August 7, 2019 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 Posted August 7, 2019 Posted August 7, 2019 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 Posted August 7, 2019 Posted August 7, 2019 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
oberkc Posted August 8, 2019 Posted August 8, 2019 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. 1
Recommended Posts