Jump to content

Why doesnt this evaluate the way I think it should


bgrubb1

Recommended Posts

Posted

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')
 
 
 

 

Posted

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

Posted (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 by PurdueGuy
Posted

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

Posted (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 by MWareman
Posted

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

Posted

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...

Posted

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.

Posted

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

Posted

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.

Posted (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 by MWareman
Posted (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 by MWareman
Posted

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 ??

Posted

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.

Posted

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!  :)

Posted

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

Guest
This topic is now closed to further replies.

×
×
  • Create New...