Why No Mail?

[Teken]

I am in the middle of cleaning up some programs in the ISY in the hopes of streamlining how it functions and operates. I have been using one basic program for awhile which indicates when the fridge is in defrost mode.

 

Somewhere down the line I made a change in the THEN section which on the surface didn't seem like a big deal. In the program listed below there is a 5 second wait period.

 

With the 5 second wait exactly as you see here the program works and fires off an e-mail alert. With the 5 second wait placed at the top of the THEN, no e-mail is sent?

 

Am I missing something obvious? 

 

If

        Status  '01 Main Left / 23 Refridgerator' > 460 Watts (Current Power)

    And $i.Refridgerator_Defrost_Status is not 1

 

Then

        Send Notification to 'GMX' content 'GEM - Fridge Defrost Cycle'

        Wait  5 seconds

        $i.Refridgerator_Defrost_Status  = 1

        $i.Refridgerator_Defrost_Status Init To 1

 

Else

   - No Actions - (To add one, press 'Action')

 

 

 

If

        Status  '01 Main Left / 23 Refridgerator' <= 1 Watts (Current Power)

    And $i.Refridgerator_Defrost_Status is not 0

 

Then

        $i.Refridgerator_Defrost_Status  = 0

        $i.Refridgerator_Defrost_Status Init To 0

 

Else

   - No Actions - (To add one, press 'Action')

 

 

 

[LeeG]

The If section is being triggered within the 5 second wait, the If is evaluated as False driving the Else.

 

Assuming $i.Refridgerator_Defrost is an Integer variable as the $i. indicates it must the the 460 watt value drops.

[Xathros]

Its not that the wattage value drops but rather it changes and does so frequently,  The change in wattage value re-triggers the program and because the value of $i.Refridgerator_Defrost_Status is now 1 after the first True evaluation, the If evaluates false and the else fires.  This is an odd situation because there is a value that is not clearly on/off used with Status.  While the outcome of testing Wattage > 460 may remain true with subsequent triggers, its the additional triggers that are tripping you up here.

 

The notification takes time to process and it appears to me that if the outcome of the If changes before notification processing is completed, the notification process is terminated.  Maybe Michel can comment on this point in particular.

 

-Xathros

[apostolakisl]

Assuming the status of the fridge wattage is changing before the 5 second wait, causing a re-trigger, and running the blank else, you should also find that the variables are not getting set. 

 

So, the question then is:

 

Is the variable getting set to 1?  ($i.Refridgerator_Defrost_Status  = 1)

 

I assume not.  So you might need to do something about that also.

 

Or, maybe the wattage reading is not dropping into false category, but rather bouncing around and re-triggering the program true, but it never gets past the 5 seconds to send the email.  Eventually the wattage falls into false range and then the else runs.  Either way, if the email isn't getting sent when after the 5 second wait, then the variables won't be getting set either.  In this case, you might see multiple emails when you put it before the 5 second wait.

[Teken]

Its not that the wattage value drops but rather it changes and does so frequently,  The change in wattage value re-triggers the program and because the value of $i.Refridgerator_Defrost_Status is now 1 after the first True evaluation, the If evaluates false and the else fires.  This is an odd situation because there is a value that is not clearly on/off used with Status.  While the outcome of testing Wattage > 460 may remain true with subsequent triggers, its the additional triggers that are tripping you up here.

 

The notification takes time to process and it appears to me that if the outcome of the If changes before notification processing is completed, the notification process is terminated.  Maybe Michel can comment on this point in particular.

 

-Xathros

 

 

Hello Xathros,

 

I believe you are tracking what my thoughts and problems are. Let me first explain why and how this program is supposed to work and what really does happen in my environment.

 

I first had to determine with a (small margin what the wattage actually was) based on fluctuations of line voltage what the defrost power was. After several weeks of simply watching defrost cycles come on / off. I was able to determine with (voltage margin) that the IF STATUS should be set no lower than 460 watts. 

 

Once the fridge settles down in defrost mode its approx 480+ watts and runs for about 19 minutes. I initially set the wait time for 30 seconds but it did not seem to operate as expected? The reason for using the Integer variable as you're aware is that I did not want to rely solely on the power value and receive endless e-mails.

 

All I needed was confirmation that it went into defrost mode, thats it.

 

As time went on your great little program which is in production now has supplemented my program. But, as a reference point I wanted to monitor the two and compare the accuracy of them both as I am still seeing odd behaviour and think some of it is due to power variations and not knowing how the ISY would reevaluate the IF STATUS if the power was changing with in that window of time.  

[Teken]

Assuming the status of the fridge wattage is changing before the 5 second wait, causing a re-trigger, and running the blank else, you should also find that the variables are not getting set.

 

So, the question then is:

 

Is the variable getting set to 1?  ($i.Refridgerator_Defrost_Status  = 1)

 

I assume not.  So you might need to do something about that also.

 

 

I have confirmed the variable did change to 1. But, will monitor it moving forward to see if that is the case in the next two days.

[Xathros]

As we have seen elsewhere, the notification process takes time.  I think you saw this with the daily report where we were resetting the daily values after the notification line in the code yet the email contained post reset values.  Inserting a delay after the notify and before the reset fixed this issue.  I came across this with my daily report as well.  I suspect a similar timing issue in this case where having the wait come first in conjunction with the 10 second update frequency from the GEM is not leaving enough time for the notify to send before the if is re-evaluated.  A very simple fix would be to move the notify to a separate program and put a RunThen in place of the notify in the current program.  Then, placement should not matter.  However, I believe it was your goal to simplify and reduce the number of programs, if that is the case, then just leave the notify as is in the current program placed ahead of the wait.

 

-Xathros

[apostolakisl]

You might put a counter as the first line to see if the program is getting re-triggered multiple times.

 

A second counter after the wait might be helpful too.  I know you already have the other variable getting set to 1 which should prevent the program from running true again, but this variable is affected by the other program which may be doing something funny based on the wattage readings it is getting.

[Teken]

You might put a counter as the first line to see if the program is getting re-triggered multiple times.

 

A second counter after the wait might be helpful too.  I know you already have the other variable getting set to 1 which should prevent the program from running true again, but this variable is affected by the other program which may be doing something funny based on the wattage readings it is getting.

 

What would be the cleanest approach to do this as a test. Keeping in mind I really wanted to clean up all of these programs to be small, compact, and have very little processing time on the ISY.

 

Throw out a sample and I will give it a try and reply back! 

[apostolakisl]

You create a couple of temporary variables just for testing. 

 

Then you put a line in your program that says

 

$i.test.variable +=1

 

Each time that line of code runs, it adds 1 to the variable and then you know how many times it ran.