Can I use a Variable here?


I’m trying to improve my dishwasher complete notification. The current version works well (thanks to WCmore for help on the original)

Basically the code works by waiting until the power has dropped below 0.6w, however this happens mid cycle for 10 mins. So I have to wait 11 mins to trigger the end of cycle. So this means the notification is 11 mins after the cycle completes. I might be being picky, but would like to reduce this time.

A thought I could use a variable on the wait, replacing the 6mins in the code below
The variable would initially be set to 10 mins, but after the mid cycle activation it would be changed to 2 mins.

The question is would this work? i.e when the piston is rescheduled would the next wait use the current value of the variable.


As long as the variable is (not set) in the “define” section, then the value of the variable is determined by the code in the “execute” section. The current value will only change when the code instructs it to.


I’m not sure I’m explaining this very well.

If code at the start of the piston sets the value to a defined value, when the if statement executes, will this setup the correct wake up conditions for the piston at that point. e.g if the time is 6 mins, will the if be activated next when power has been below 0.6w for 6 mins?

Once the if has been triggered (first period of low power mid cycle) the variable will be changed to 2 min. Will the if then be setup with a 2 min of 0.6w wakeup?


As long as you remember that each trigger starts at the top, and works down thru the code… it sounds possible. You just have to be strategic into your placement of “Set variable to X

Do not do this up top in the define section.
Otherwise, it will always force that number each execution

Personal Note:
If your mid-cycle is 10 minutes, then I would probably be happy with 11 minutes.
(just look at it as “drying” time)

I believe the code “stays less than X for Y minutes” begins the timer when it first drops below. Once that trigger fires, it is very possible that it would have to rise and then drop again for any subsequent triggers to activate.

Further testing is recommended…


I agree, the extra wait could be used as drying time, but theres a challenge to make this work now! Understanding how this gets processed may be useful in the future.

I’ve quickly put this together (untested) to demonstrate what I’m looking to do.
I’m unclear whether the correct delays will be setup on the if (line 41)
I guess this may error on the first run as the variable is not yet defined.
When power triggers a cycle has started (line 24) will the later execution of line 41 set the wait to 8 mins?
when the first low power (line 41) changes the variable, will the wait be set to 4 mins, or will it still be 8 as line 41 has not been run again?

I’ll test next time I run the dishwasher.


Can you please edit your last post so your line numbers match the picture you included?


Apologies, I didn’t notice the green snapshot added a few lines at the top. I think the line references are correct now.


Thanks for that. I wanted to make sure we were talking about the same code…

True, but you can manually initialize the variable at the bottom of the piston
(just click on the pencil outside of edit mode)


This is a one-time effect.

The block starting at line 24 sets the variable to 8 when both conditions are true
The block starting at line 41 sets the variable to 4 when 2 conditions are true & 1 is false

The {low_power_wait} variable will change each time those lines execute. I think the challenge will be whether or not a single event can produce two triggers.

In other words, normally, the countdown for “stays less than X for Y minutes" begins at the instant the power drops. Once the timer is up, if the conditions are still true, then the block will execute, and the variable will change.


I just re-read your original post. I think your structure can be as simple as this:

   boolean limbo = (not set)
end define

IF Outlet 4's power stays less than 0.6W for 8 minutes
   Then Set variable {limbo} = true

IF Outlet 4's power stays less than 0.6W for 90 seconds
   {limbo} = true
      Then Send PUSH notification

IF Outlet 4's power stays less than 0.6W for 20 minutes
   Then Set variable {limbo} = false

  • The first IF captures the 8-10 minute rest in mid cycle.
  • The second IF captures the complete cycle & quickly notifies you.
  • The final IF resets the piston to prepare for the next load of dishes

I normally try to keep only one timer going at a time (per piston), but these are all subscribed to the exact same device and attribute… so… it might work with all three triggers being in the same piston. (hopefully, the overlapping timers hold up) If not, it will definitely work broken up into “mini-pistons” using a global variable.

Side Note:
I would definitely turn logging to Full when testing this…


Many thanks for all your suggestions.
I think I’ll have to stay with the original. As you decrease the time of the mid cycle, it becomes apparent that there are other mid cycles of that length.
I have logged the power usage to an excel spreadsheet, but its still quite difficult to analyse. The scale goes from 0 to 2500, even using a logarithmic scale its difficult to see the <0.6 periods. I may write a macro to analyse the data, and find the mid cycle points & their lengths. However, its a lot of trouble just to get a slightly earlier notification of the cycle completion.


I agree. Power tends to fluctuate more than we’d expect it to…


One more outside-the-box thinking:

If you always run your dishwasher on the same cycle, you may be able to base the entire piston on a simple timer. (IE: 42 minutes after cycle begins)

It would reduce your 11 minutes, and simplify your code greatly!


I thought about that, however the only programme I use is the auto one, The time it takes seems to vary though, I’m not sure what this is based on.

What I really need is some sort of AI analysis, to monitor the power logs and work out when the cycle has finished, and then use that learning. I suspect this is still some way off. I have started experimenting with this, and have a piston that can determine certain journeys have been completed by monitoring a webcore presence sensor and a state transition table.


If the variance is less than 11 minutes, it would still be an improvement, using 90% less code.

I sometimes store data into a fuel stream for a couple of days to distinguish patterns.
(essentially, doing my own analysis)

It makes it much easier to streamline the code with more precise results once I understand the actual flow of the device. (Especially when it comes to power)