bgrubb1 Posted September 19, 2016 Posted September 19, 2016 I monitor house voltage from a variable received from my Brultech GEM There is a bug in the GEM (reported by several users) where it sends a wrong value ( in my case 2.33 Volts) I have attempted to change my low voltage program to ignore if the value is 2.33 Volts and since the ISY programs use integers, ignore 1 volt to 4 volts I still get a 2.33 Volt message when the bug occurs, shouldn't this logic eliminate it ?? Voltage_Low - [iD 0002][Parent 0001] If $Brultech_Voltage < 100 And ( $Brultech_Voltage < 1 Or $Brultech_Voltage > 4 ) Then Send Notification to 'Voltage Below 100 Volts' Wait 1 minute Disable Program 'Voltage_Low' Wait 10 minutes Enable Program 'Voltage_Low' Else - No Actions - (To add one, press 'Action')
stusviews Posted September 19, 2016 Posted September 19, 2016 Your program seems correct, but it won't prevent something else from sending a message. What sends you the 2.33 volt message?
PurdueGuy Posted September 19, 2016 Posted September 19, 2016 (edited) Doesn't disabling a program also stop it if it is running (and in a wait)?Since you are using a program to disable itself, and waiting, how does it ever get going again? Edited September 20, 2016 by PurdueGuy
bgrubb1 Posted September 20, 2016 Author Posted September 20, 2016 Well Based on this feedback I have discovered it's not that program causing the issue the message I received in the message I am receiving is not the message the program is supposed to send I am getting a "Variable Changed" message, not the text I have set up in alerts the log file does not seem to show the message sent at the time in the mail am I missing something ?? ..Barry
MWareman Posted September 20, 2016 Posted September 20, 2016 (edited) Doesn't disabling a program also stop it if it is running? Since you are using a program to disable itself, how does it ever get going again? I don't *think* so. There is a stop program as well... Disabled programs can still be run manually, and run from other programs. I don't see why they would stop just because triggering was disabled. Edited September 20, 2016 by MWareman
PurdueGuy Posted September 20, 2016 Posted September 20, 2016 I don't *think* so. There is a stop program as well... Disabled programs can still be run manually, and run from other programs. I don't see why they would stop just because triggering was disabled. I just created test programs. I put a wait in the first program. The second program disabled the first. When I ran Program2, it disabled Program1 which also stopped. Confirmed by Michel here: http://forum.universal-devices.com/topic/5467-stop-and-disable-for-programs-folder-enableddisable/?p=43022
MWareman Posted September 20, 2016 Posted September 20, 2016 I just created test programs. I put a wait in the first program. The second program disabled the first. When I ran Program2, it disabled Program1 which also stopped. Confirmed by Michel here: http://forum.universal-devices.com/topic/5467-stop-and-disable-for-programs-folder-enableddisable/?p=43022 Waits will get interrupted, as will loops. A program with just a set of steps (no waits or repeats) will execute 'atomically' - once triggered it will always complete. So, your test (having a wait) will terminate when the triggering condition changes. Since disabling a program is essentially just turning off triggering, this would terminate. If you have a program with no waits or repeats, it will complete even if disabled mid execution. I think... Try one program... 1) Turn light on 2) disable this program 3) Turn light off Does the light turn off? I would expect it would...
PurdueGuy Posted September 20, 2016 Posted September 20, 2016 Yes, a program with no waits will continue and finish. However, the original poster had just 1 program listed, with waits, that was disabling and enabling itself. I updated my earlier post to make it more clear.
bgrubb1 Posted September 20, 2016 Author Posted September 20, 2016 I still cant figure this one out I do not have a program or a message for a variable changing , nuch less showing me the value of the variable, althought the message says Program: Low_Voltage which is the name of the program that world trigger my message ..Barry
PurdueGuy Posted September 20, 2016 Posted September 20, 2016 Any chance you have Mobilinc Connect, and setup a push notification for when the program runs?
bgrubb1 Posted September 20, 2016 Author Posted September 20, 2016 No on Mobilinc connect, disconnected it a long time ago and use the UDI Portal now
MWareman Posted September 21, 2016 Posted September 21, 2016 With this: Disable Program 'Voltage_Low' Wait 10 minutes Enable Program 'Voltage_Low' The enable will never run. The 'Disable' followed by a wait will cause the 'Then' to terminate at the Wait.
bgrubb1 Posted September 21, 2016 Author Posted September 21, 2016 my point exactly The program should be disablled but I am still getting a message and its not the message I have in alerts
MWareman Posted September 21, 2016 Posted September 21, 2016 Silly question... '$Brultech_voltage'. Is this a State or Integer variable?
MWareman Posted September 21, 2016 Posted September 21, 2016 (edited) So, every single time the variable gets written, even if it dosnt change, will cancel the running of 'Then' (at the current wait) and reevaluate 'If'. So, the 'Then' may be cancelling before the disable is reached - if your GEM is sending more often that the initial delay (it probably is). You may need to seperate to two seperate programs for this to work. Edited September 21, 2016 by MWareman
MWareman Posted September 21, 2016 Posted September 21, 2016 (edited) Example for two programs... First: Voltage_Low - [ID 0002][Parent 0001] If $Brultech_Voltage < 100 And ( $Brultech_Voltage < 1 Or $Brultech_Voltage > 4 ) Then Run Program 'Voltage_Low_Action' (Then Path) Else - No Actions - (To add one, press 'Action') Second (disable this program - thus preventing it from any auto-triggering. This will allow it to only be triggered from your main program): Voltage_Low_Action - [ID 0003][Parent 0001] If Then Send Notification to 'Voltage Below 100 Volts' Wait 1 minute Disable Program 'Voltage_Low' Wait 10 minutes Enable Program 'Voltage_Low' Else - No Actions - (To add one, press 'Action') This will decouple the 'Wait's from the triggering events... Michael. Edited September 21, 2016 by MWareman
bgrubb1 Posted September 21, 2016 Author Posted September 21, 2016 can u elaborate please oh guru I have noted in the logs that at the time that the message triggers, the ISY is evaluating current draw from other circuits to determine if it should turn outlets or sirens off or on are you saying have one program to evaluate and call another program if the "IF" statement is true ??
bgrubb1 Posted September 21, 2016 Author Posted September 21, 2016 Will try that Thank You sir ..Barry
bgrubb1 Posted September 21, 2016 Author Posted September 21, 2016 Done, will see if this corrects the issue, thanks for the knowledge Is this a bug in the ISY ?? ..Barry
bgrubb1 Posted September 21, 2016 Author Posted September 21, 2016 another question Does calling a program that is disabled enable it ? not sure what the comment about disabling it meant Thanks again for the help ...Barry
MWareman Posted September 21, 2016 Posted September 21, 2016 Calling a disabled program does not enable it. It just runs it (based on the run branch selected - If, Then or Else). I do this a lot. Simply right-click the 'Action' program and select 'Disable'. No - it's not a bug per-se. It's a symptom of ISY being fully event driven. Natural program flows often get broken in ways you might not expect when everything is driven by events. Michael.
MWareman Posted September 21, 2016 Posted September 21, 2016 So, every single time the variable gets written, even if it dosnt change, will cancel the running of 'Then' (at the current wait) and reevaluate 'If'. So, the 'Then' may be cancelling before the disable is reached - if your GEM is sending more often that the initial delay (it probably is). You may need to seperate to two seperate programs for this to work. Small correction... writing the exact same value does not cause a retrigger... only writing a different value. So, the value would have to change - but I suspect that's the case anyway coming from the GEM. The other thing I note, on 4.5.2 writing 2.33 into a variable via the API causes a 404 error (and the integer does not get updated, program not triggered). What firmware are you running on ISY? I'm just not sure how you are getting a non-integer stored into the state value... unless you are running the alpha ISY code and/or this is a zigbee GEM integration (rather than via a Dashbox). Thanks to @larryllix for reminding me I'm not always correct!
bgrubb1 Posted September 21, 2016 Author Posted September 21, 2016 Thats part of why I am confused. Running 4.5.1 with a Dashbox feed to the ISY dont know how I am getting a non integer value and a message that I have not created to send ..Barry
Recommended Posts