Why doesnt this evaluate the way I think it should

[bgrubb1]

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]

Your program seems correct, but it won't prevent something else from sending a message. What sends you the 2.33 volt message?

[PurdueGuy]

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?

[bgrubb1]

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]

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.

[PurdueGuy]

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]

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]

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]

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]

Any chance you have Mobilinc Connect, and setup a push notification for when the program runs?

[bgrubb1]

No on Mobilinc connect, disconnected it a long time ago and use the UDI Portal now

[MWareman]

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]

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]

Silly question... '$Brultech_voltage'. Is this a State or Integer variable?

[bgrubb1]

State Variable

[MWareman]

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.

[MWareman]

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.

[bgrubb1]

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]

Will try that    Thank You sir

..Barry

[bgrubb1]

Done, will see if this corrects the issue, thanks for the knowledge

Is this a bug in the ISY ??

..Barry

[bgrubb1]

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]

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]

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]

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