C Martin Posted March 22, 2012 Posted March 22, 2012 I noticed a "Status" condition, "Responding",that I didn't see before. What does "Responding" in the Status line do? Is there a list of new items included since 3.17? Clarence
andyf0 Posted March 22, 2012 Posted March 22, 2012 viewtopic.php?f=25&t=8359 Also checkout viewtopic.php?f=68&t=8354 for Random Variables.
C Martin Posted March 22, 2012 Author Posted March 22, 2012 Thanks Andy. Next Question: Does initiating a Status, Responding in a program actually trigger the program to check on that device? Clarence
LeeG Posted March 22, 2012 Posted March 22, 2012 "Is there a list of new items included since 3.17?" In addition to the links Andy posted the link below goes to the 3.2.1/3.2.0 topic which covers the new function, device support and fixes. viewtopic.php?f=25&t=8309
LeeG Posted March 22, 2012 Posted March 22, 2012 "Does initiating a Status, Responding in a program actually trigger the program to check on that device?" If Status does not generate communication with the device. If Status causes a Program to trigger when Status changes. This is true for all If Status, not just Responding option. A Program with an If Status is Responding would trigger when the device goes from not responding to responding.
belias Posted August 20, 2013 Posted August 20, 2013 I'm having an issue getting programs with the "Status is not Responding" to run as expected... Here's an example: If Status 'Brian's Room / Brian's TV Overheads' is not Responding Then Send Notification to 'Brian E-Mail' content 'Test Not Responding' Else - No Actions - (To add one, press 'Action') This program will evaluate True when the device goes from Responding to Not Responding (i.e. if I air-gap the switch and then query it). However, it will NOT evaluate to true on subsequent runs - even if the device is still "not-responding". For example, right now the device is showing with a red ! (because it is air-gapped), however, if I do a "Run If..." on the program, it will not evaluate to true. Any ideas? Thanks.
TJF1960 Posted August 20, 2013 Posted August 20, 2013 That is correct, it will only evaluate true when the device goes from responding to not responding. In other words the program will only evaluate true once. Once the device starts responding then stops again the program will evaluate true again, once.
oberkc Posted August 20, 2013 Posted August 20, 2013 I have never used the status condition "not responding" before, so I can only speculate. But...I expect your posted program to trigger and execute TRUE only when: a) this program will trigger only when the status actually CHANGES (responding->not or vice versa) when triggered, it changes to NOT RESPONDING I must admit, however, that I don't have a theory as to why your program did not evaluate true when you manually triggered the program (run...if)
belias Posted August 20, 2013 Posted August 20, 2013 That is correct, it will only evaluate true when the device goes from responding to not responding. In other words the program will only evaluate true once. Once the device starts responding then stops again the program will evaluate true again, once. Hmm...so then it's behaving almost as a "Control" condition rather than a "Status" condition... At least I understand it now (thank you!), but it still seems a bit more intuitive if it behaved as any other "Status" type condition. In any case thanks for the quick reply! - Brian
oberkc Posted August 20, 2013 Posted August 20, 2013 Hmm...so then it's behaving almost as a "Control" condition rather than a "Status" condition No...I find this consistent with other STATUS conditions. These all respond to any CHANGE in status. A CONTROL condition, by comparision, only responds to reciept of the expected (whether ON or OFF) command, regardless of whether this constitutes a change (receipt of two ON commands in a row would, for example, twice trigger the program, whereas only once for a STATUS). Neither will a CONTROL ON condition will trigger from receipt of an OFF command, or vice versa. Another difference is that CONTROL conditions respond only when the specified device is acted upon locally. STATUS will trigger whether initiated locally, or as a result of being a responder to another insteon device.
belias Posted August 20, 2013 Posted August 20, 2013 Hmm...so then it's behaving almost as a "Control" condition rather than a "Status" condition No...I find this consistent with other STATUS conditions. These all respond to any CHANGE in status. A CONTROL condition, by comparision, only responds to reciept of the expected (whether ON or OFF) command, regardless of whether this constitutes a change (receipt of two ON commands in a row would, for example, twice trigger the program, whereas only once for a STATUS). Neither will a CONTROL ON condition will trigger from receipt of an OFF command, or vice versa. Another difference is that CONTROL conditions respond only when the specified device is acted upon locally. STATUS will trigger whether initiated locally, or as a result of being a responder to another insteon device. Oberkc: I agree with everything above, with the addition that a STATUS condition can be queried to show the current state of the device. (For example a program with "If Status "Bedroom Light" = ON" can be run at anytime and will evaluate either True or False based on the CURRENT condition of the bedroom light). This is the part that the "Status = Not Responding" doesn't seem to follow (unless I'm missing something...). If I have a device showing a red ! (i.e. not responding), and I run the following program: If Status 'Device' is not Responding Then Send Notification to 'Brian E-Mail' content 'Not Responding' Else - No Actions - (To add one, press 'Action') It should return "True" and execute the "Then" for as long as the red ! is present. It does not do this, and according to TJF1960 this is by design. It should also (as you say) execute the "Then" anytime the device goes from Responding --> Not Responding. This works properly.
oberkc Posted August 20, 2013 Posted August 20, 2013 For example a program with "If Status "Bedroom Light" = ON" can be run at anytime and will evaluate either True or False based on the CURRENT condition of the bedroom light Yes. In my mind, this is an external "trigger" much like your earlier example where you invoked the "run if" command on that program. I agree, the program should react based on current condition if you invoke some type of external trigger or query. Like I mentioned before, I have no explanation why this does not work for you. I suspect TJF was speaking of triggers rather than evaluation, and suspect he would agree that a STATUS condition would indeed return TRUE if invoked (triggered) externally, whether manually or by another program. Still, I think this is more consistent with other STATUS conditions, rather than making it more analogous to a CONTROL condition. I think we all have the same understanding, but don't know why your program would not evaluate as TRUE when triggered externally.
apostolakisl Posted August 20, 2013 Posted August 20, 2013 Hmm...so then it's behaving almost as a "Control" condition rather than a "Status" condition No...I find this consistent with other STATUS conditions. These all respond to any CHANGE in status. A CONTROL condition, by comparision, only responds to reciept of the expected (whether ON or OFF) command, regardless of whether this constitutes a change (receipt of two ON commands in a row would, for example, twice trigger the program, whereas only once for a STATUS). Neither will a CONTROL ON condition will trigger from receipt of an OFF command, or vice versa. Another difference is that CONTROL conditions respond only when the specified device is acted upon locally. STATUS will trigger whether initiated locally, or as a result of being a responder to another insteon device. Oberkc: I agree with everything above, with the addition that a STATUS condition can be queried to show the current state of the device. (For example a program with "If Status "Bedroom Light" = ON" can be run at anytime and will evaluate either True or False based on the CURRENT condition of the bedroom light). This is the part that the "Status = Not Responding" doesn't seem to follow (unless I'm missing something...). If I have a device showing a red ! (i.e. not responding), and I run the following program: If Status 'Device' is not Responding Then Send Notification to 'Brian E-Mail' content 'Not Responding' Else - No Actions - (To add one, press 'Action') It should return "True" and execute the "Then" for as long as the red ! is present. It does not do this, and according to TJF1960 this is by design. It should also (as you say) execute the "Then" anytime the device goes from Responding --> Not Responding. This works properly. "is not" means the same things as "is" except it runs the "else" clause. You would want to write your program as follows. If Status 'Device' is Responding Then - - Else Send Notification to 'Brian E-Mail' content 'Not Responding' If you force run the program, then it will be false if it is not responding
oberkc Posted August 20, 2013 Posted August 20, 2013 If it like a "control" statement then it will only be true for the split second that a response is sent from the device and a response itself is the only trigger that could return a "true". If it is like a "status" statement then it can be tested at any time. My suspicion is that it is like a "control" statement, but I have never had occasion to use it. That is, at least, the best working theory so far. If this is the explanation for why it is not returning TRUE when manually triggered, then that aspect of this statement is unlike other STATUS statements, and more like a CONTROL statement in this regards. I would be disappointed if this proves to be the case.
apostolakisl Posted August 20, 2013 Posted August 20, 2013 If it like a "control" statement then it will only be true for the split second that a response is sent from the device and a response itself is the only trigger that could return a "true". If it is like a "status" statement then it can be tested at any time. My suspicion is that it is like a "control" statement, but I have never had occasion to use it. That is, at least, the best working theory so far. If this is the explanation for why it is not returning TRUE when manually triggered, then that aspect of this statement is unlike other STATUS statements, and more like a CONTROL statement in this regards. I would be disappointed if this proves to be the case. I just checked it. It is like "status". I am at the office so I can't pull the disconnect on one of my switches to check what happens when it is not responding. However, unlike other "Status" events, the program does not run when the status of the light changes. As far as I can tell, "status is /is not responding" is not a self-triggering clause. EDIT: I need to play with this when I get home. My remote connection keeps dropping.
LeeG Posted August 20, 2013 Posted August 20, 2013 I used this Program on 4.0.5 as a test vehicle. I am seeing the Program evaluate True with a Run (If). I don’t like Notify for the result indication. Too many possible issues. X10 statements are good as they do not require the X10 device and they generally have no adverse affect on the network. If Status 'SwitchLinc DB Dimmer v40' is not Responding Then Send X10 'A1/On (3)' Else Send X10 'A1/Off (11)' Issued a Query here with device not powered. Query issued three times. After third failure Program is triggered because of Status change and program evaluates as True (A1/On) Tue 08/20/2013 01:10:30 PM : [iNST-TX-I1 ] 02 62 1D 38 00 0F 19 00 Tue 08/20/2013 01:10:30 PM : [iNST-ACK ] 02 62 1D.38.00 0F 19 00 06 LTSREQ (LIGHT) Tue 08/20/2013 01:10:39 PM : [iNST-TX-I1 ] 02 62 1D 38 00 0F 19 00 Tue 08/20/2013 01:10:39 PM : [iNST-ACK ] 02 62 1D.38.00 0F 19 00 06 LTSREQ (LIGHT) Tue 08/20/2013 01:10:47 PM : [iNST-TX-I1 ] 02 62 1D 38 00 0F 19 00 Tue 08/20/2013 01:10:47 PM : [iNST-ACK ] 02 62 1D.38.00 0F 19 00 06 LTSREQ (LIGHT) Tue 08/20/2013 01:10:54 PM : [ 1D 38 0 1] ERR 1 Tue 08/20/2013 01:10:54 PM : [ X10] A1 Tue 08/20/2013 01:10:54 PM : [X10-RSP ] 02 63 66 00 06 Tue 08/20/2013 01:10:54 PM : [ X10] A1/On (3) Tue 08/20/2013 01:10:55 PM : [X10-RSP ] 02 63 62 80 06 Click Run (If) using Admin Console. Program evaluates to True since device is still Not Responding (A1/On) Tue 08/20/2013 01:11:07 PM : [ Time] 13:11:11 0(0) Tue 08/20/2013 01:11:07 PM : [X10-RSP ] 02 63 66 00 06 Tue 08/20/2013 01:11:07 PM : [ X10] A1 Tue 08/20/2013 01:11:07 PM : [ X10] A1/On (3) Tue 08/20/2013 01:11:08 PM : [X10-RSP ] 02 63 62 80 06 Issued another Query. Still times out because device not powered but this time program is not triggered because no change in device Status. Tue 08/20/2013 01:11:58 PM : [iNST-TX-I1 ] 02 62 1D 38 00 0F 19 00 Tue 08/20/2013 01:11:58 PM : [iNST-ACK ] 02 62 1D.38.00 0F 19 00 06 LTSREQ (LIGHT) Tue 08/20/2013 01:12:07 PM : [iNST-TX-I1 ] 02 62 1D 38 00 0F 19 00 Tue 08/20/2013 01:12:07 PM : [iNST-ACK ] 02 62 1D.38.00 0F 19 00 06 LTSREQ (LIGHT) Tue 08/20/2013 01:12:15 PM : [iNST-TX-I1 ] 02 62 1D 38 00 0F 19 00 Tue 08/20/2013 01:12:15 PM : [iNST-ACK ] 02 62 1D.38.00 0F 19 00 06 LTSREQ (LIGHT)
TJF1960 Posted August 20, 2013 Posted August 20, 2013 Sorry I am late getting back to the party, and I apologize for missing the fact that belias was trying to force run the program. If the red exclamation point is showing and he forces that program to run "if", it should evaluate as true. If the device is responding properly and a force run "if" is done the program will run false. By itself the program will only run true or false once - with each status change from responding to not responding only. But not by a query after the status has changed. belias, there must be something odd going on if you are forcing the program if and it is evaluating false when the red ! is visable, but I don't know what. edit: boy I am really late, I didn't see the last 2 post until now.
apostolakisl Posted August 20, 2013 Posted August 20, 2013 I was able to get my connection back up. Indeed it appears that "status responding" is not a self triggering clause. I turned the device on/off and querried it and the program never ran. A "run if" got a "true" result. So it is like a regular "status" statement in that it checks the current status in the ISY database upon encountering the clause. It is not however like a regular "status" statement in that it does not self trigger on every change in status. I will pull the gap on one of my switches when I get home and see what happens. I would expect a "run if" to result in a false result provided I first try to communicate with the switch so that ISY has it as not responding in its database. EDIT: after reading the above post which happened during my writing of this post, it appears that he is saying that a change in the status of responding vs non-responding is a trigger. Other changes in the status of the device are not proving to be triggers.
TJF1960 Posted August 20, 2013 Posted August 20, 2013 EDIT: after reading the above post which happened during my writing of this post, it appears that he is saying that a change in the status of responding vs non-responding is a trigger. Other changes in the status of the device are not proving to be triggers.Exactly. When the red exclamation point first turns on is the only time that program will evaluate true. When the red excalmation point disappears that is the only time that program will eval. false. Except of course for forced runs.
apostolakisl Posted August 20, 2013 Posted August 20, 2013 Indeed. If Status 'Kitchen / Kitchen Micro-Island' is Responding Then $Int_56 = 10 Else $Int_56 = 5 This program ran false upon my first action taken on the switch after the hard disconnect was pulled and true upon the first action taken on the switch when the disconnect was restored. And changing the languange to "is not" simply swapped when the "then" or "else" happened. And forcing a "run if" after the switch was already in a hard disconnect also caused the "then" or "else" to execute properly.
oberkc Posted August 21, 2013 Posted August 21, 2013 Indeed. If Status 'Kitchen / Kitchen Micro-Island' is Responding Then $Int_56 = 10 Else $Int_56 = 5 This program ran false upon my first action taken on the switch after the hard disconnect was pulled and true upon the first action taken on the switch when the disconnect was restored. And changing the languange to "is not" simply swapped when the "then" or "else" happened. And forcing a "run if" after the switch was already in a hard disconnect also caused the "then" or "else" to execute properly. This sounds exactly like every other STATUS condition, correct?
apostolakisl Posted August 21, 2013 Posted August 21, 2013 Indeed. If Status 'Kitchen / Kitchen Micro-Island' is Responding Then $Int_56 = 10 Else $Int_56 = 5 This program ran false upon my first action taken on the switch after the hard disconnect was pulled and true upon the first action taken on the switch when the disconnect was restored. And changing the languange to "is not" simply swapped when the "then" or "else" happened. And forcing a "run if" after the switch was already in a hard disconnect also caused the "then" or "else" to execute properly. This sounds exactly like every other STATUS condition, correct? Not exactly. The status of the light as far as on/off/x% does not trigger this program. Only if the status "responding/not responding" changes does it trigger.
oberkc Posted August 21, 2013 Posted August 21, 2013 OK. Fair enough. In my mind this is the same, since we were not looking for status on/off, but status responding/not. But...point taken.
apostolakisl Posted August 21, 2013 Posted August 21, 2013 I also came to notice that using the light switch as a responder in a scene does not update the responding status in ISY. I had it listed as a non-responding switch in ISY by pulling the disconnect, then using ISY to try to turn it on. Then I reset the disconnect and used another switch that it was in a scene with. The switch in question changed status (and thus presumably should have updated ISY), but ISY continued to list it as a non-responding switch until I used ISY to control it or until I directly pushed it. This was repeatable. Shouldn't ISY have recognized that it was alive when it changed status responding to that scene?
Recommended Posts