Cycling my hotwater pump based on energy meter and motion

Qwertypo · 2020-11-05 05:35:38 UTC

Ok, I presume its not a problem with this machine if it gets multiple presses while mid-cycle, I actually presume its not a problem if I press it again 30 seconds later, it should just shut the pump off again super quickly.

I will test a second piston to see how they get along changing things to @Pump_On. For the bathroom since it is only running once, I don’t really need to set it to true, and if the bathroom was just run, I really still want the laundry to trigger a series of cycles, I am really trying to limit the bathroom from running on every motion active event. Should I be using the time since last active state to limit triggers in the bathroom, while also using the global pump on variable to know when I don’t even need to bother?

Qwertypo · 2020-11-07 03:50:50 UTC

So I own a smart plug that has energy metering, so I was thinking maybe its better if for the cycling of the pump, I use the energy of the washer to start the pump on the 15 minute repeats

So at this moment I have two motion sensors I’d like to fire up one cycle, IF the laundry is not already doing a cycle, I figured a global variable might be the best way to do it? It is possible to delay the laundry cycle if the pump was recently run by a motion event?

I’ve changed the piston you made to attempt to trigger based on power, but it now seems to not be happy with the global variable. If I run it without the global it variable, it fires, but it quits when the power goes below the threshold OR the power demand changes at all, which then never resets the Pump_On variable, so it breaks itself that way. Which I don’t get because I figure it would ignore that like the motion events do when its set to never cancel.

With the global variable this is the log:

11/6/2020, 7:41:46 PM +900ms
+1ms ╔Received event [Living Room Lamp].power = 5.651 with a delay of 31ms
+68ms ║RunTime Analysis CS &gt; 15ms &gt; PS &gt; 39ms &gt; PE &gt; 13ms &gt; CE
+70ms ║Runtime (39916 bytes) successfully initialized in 39ms (v0.3.110.20191009) (68ms)
+71ms ║╔Execution stage started
+79ms ║║Comparison (decimal) 5.651 is_greater_than (decimal) 0.0 = true (1ms)
+80ms ║║Condition #2 evaluated true (6ms)
+84ms ║║Comparison (boolean) true is_not (boolean) true = false (2ms)
+85ms ║║Condition #13 evaluated false (4ms)
+86ms ║║Condition group #1 evaluated false (state did not change) (12ms)
+88ms ║║Cancelling statement #20's schedules...
+93ms ║║No action taken...
+94ms ║║Executed virtual command log (1ms)
+95ms ║╚Execution stage complete. (25ms)
+96ms ╚Event processed successfully (96ms)
11/6/2020, 7:41:45 PM +807ms
+1ms ╔Received event [Living Room Lamp].power = 5.672 with a delay of 27ms
+65ms ║RunTime Analysis CS &gt; 13ms &gt; PS &gt; 40ms &gt; PE &gt; 12ms &gt; CE
+68ms ║Runtime (39916 bytes) successfully initialized in 40ms (v0.3.110.20191009) (66ms)
+69ms ║╔Execution stage started
+77ms ║║Comparison (decimal) 5.672 is_greater_than (decimal) 0.0 = true (1ms)
+79ms ║║Condition #2 evaluated true (6ms)
+83ms ║║Comparison (boolean) true is_not (boolean) true = false (1ms)
+84ms ║║Condition #13 evaluated false (4ms)
+85ms ║║Condition group #1 evaluated false (state did not change) (12ms)
+88ms ║║Cancelling statement #20's schedules...
+93ms ║║No action taken...
+94ms ║║Executed virtual command log (1ms)
+96ms ║╚Execution stage complete. (26ms)
+97ms ╚Event processed successfully (96ms)
11/6/2020, 7:41:42 PM +812ms
+0ms ╔Received event [Living Room Lamp].power = 5.609 with a delay of 26ms
+68ms ║RunTime Analysis CS &gt; 14ms &gt; PS &gt; 42ms &gt; PE &gt; 13ms &gt; CE
+71ms ║Runtime (39915 bytes) successfully initialized in 42ms (v0.3.110.20191009) (70ms)
+72ms ║╔Execution stage started
+81ms ║║Comparison (decimal) 5.609 is_greater_than (decimal) 0.0 = true (1ms)
+83ms ║║Cancelling condition #2's schedules...
+84ms ║║Condition #2 evaluated true (8ms)
+88ms ║║Comparison (boolean) true is_not (boolean) true = false (1ms)
+90ms ║║Condition #13 evaluated false (4ms)
+91ms ║║Condition group #1 evaluated false (state did not change) (14ms)
+93ms ║║Cancelling statement #20's schedules...
+98ms ║║No action taken...
+99ms ║║Executed virtual command log (1ms)
+102ms ║╚Execution stage complete. (30ms)
+103ms ╚Event processed successfully (104ms)

This is my broken piston:

Qwertypo · 2020-11-07 05:45:26 UTC

I changed it to power rises and that seems to fix it.

My question is now, should I use a loop if I want to keep the pump running as long as the machine is running at the set interval.

Have another piston react to two motion sensors, to trigger one cycle… I assume I can just make sure that the global is false, and that be that. But is it worth making it more sophisticated to maintain the cycle time based on the previous run. Can I flag the “turn on” even or use a $state of the switch to delay the run?

Can I do something like this:

Thanks for the help

Qwertypo · 2020-11-07 06:28:51 UTC

This one kinda works, but obviously the state of the pump running gets broken on power demand changes. Getting closer though!

maybe this:

This seems to work:

So trying to pair it with a motion piston, but “stays false” is not working.

11/7/2020, 12:12:22 AM +369ms
+1ms ╔Received event [Motion Living Room].motion = active with a delay of 28ms
+68ms ║RunTime Analysis CS &gt; 13ms &gt; PS &gt; 36ms &gt; PE &gt; 18ms &gt; CE
+70ms ║Runtime (38860 bytes) successfully initialized in 36ms (v0.3.110.20191009) (69ms)
+71ms ║╔Execution stage started
+89ms ║║Comparison (enum) active changes_to (string) active = true (0ms)
+90ms ║║Cancelling condition #2's schedules...
+91ms ║║Condition #2 evaluated true (16ms)
+95ms ║║Comparison (boolean) false stays_away_from (boolean) true = true (1ms)
+97ms ║║Adding a timed trigger schedule for condition 22
+99ms ║║Cancelling condition #22's schedules...
+100ms ║║Condition #22 evaluated false (8ms)
+101ms ║║Condition group #1 evaluated false (state did not change) (27ms)
+103ms ║║Cancelling statement #20's schedules...
+108ms ║║No action taken...
+109ms ║║Executed virtual command log (1ms)
+111ms ║╚Execution stage complete. (41ms)
+112ms ║Setting up scheduled job for Sat, Nov 7 2020 @ 12:13:22 AM PST (in 59.986s)
+119ms ╚Event processed successfully (119ms)
11/7/2020, 12:11:03 AM +300ms
+0ms ╔Received event [Ventura].:ca6a2565b08141e601b2b94cbb6cf944: = @Pump_Running with a delay of 31ms
+77ms ║RunTime Analysis CS &gt; 16ms &gt; PS &gt; 42ms &gt; PE &gt; 18ms &gt; CE
+79ms ║Runtime (38884 bytes) successfully initialized in 42ms (v0.3.110.20191009) (77ms)
+79ms ║╔Execution stage started
+94ms ║║Condition #2 evaluated false (11ms)
+95ms ║║Condition group #1 evaluated false (state did not change) (12ms)
+97ms ║║Cancelling statement #20's schedules...
+102ms ║║No action taken...
+103ms ║║Executed virtual command log (1ms)
+105ms ║╚Execution stage complete. (25ms)

+106ms ╚Event processed successfully (105ms)

WCmore · 2020-11-07 13:40:57 UTC

I am tied up at the moment… Hopefully someone else can jump in…

Qwertypo · 2020-11-07 18:57:15 UTC

No rush, thanks for your help.

Push notifications aren’t working either if anyone has any ideas.

Paul1964 · 2020-11-07 19:42:59 UTC

With the new app, you need to specify store in messages for the push notification to work.

Qwertypo · 2020-11-07 19:54:39 UTC

Thanks that fixed that. Wont use that long term probably, but it helps for this debugging process.

I am noticing that subscribing to devices doesn’t work reliably, and that sometimes I need to edit and save the piston to get it to actually see the device events. Is that normal?

Qwertypo · 2020-11-07 20:29:25 UTC

So I am trying to use a LastRun Variable to compare instead of the true false change, and I can not figure out how to use the offset

It shows the offset, but when I save the statement it just uses now alone.

Trying this doesn’t work for me. The Push notification shows the times I am going for, but is false, yet the logs are showing true

Obviously I am missing something key with the date time, because the Push alert is accurate numbers, but the logs show different time format:

Comparison (datetime) 1604788731029 is_after (datetime) 52794474 = true (2ms)
Calculating (string) 'Run Pump for Motion Sat, Nov 7 2020 @ 2:38:51 PM PST is &gt; + (string) Sat, Nov 7 2020 @ 2:39:54 PM PST &gt;&gt; (string) 'Run Pump for Motion Sat, Nov 7 2020 @ 2:38:51 PM PST is &gt; Sat, Nov 7 2020 @ 2:39:54 PM PST

So for some reason it actually works with $localNow, just not with $now. Is there a better way to be doing this?

Qwertypo · 2020-11-11 05:46:16 UTC

So I am getting a lot of “Piston waited at a semaphore for” with the power meter version. It works ok, but I am feeling like it is needlessly clumsy and hoping for a refined method.

Since the power fluctuates so much, it seems like it may be better to just poll the power meter every minute or two instead of subscribing to power events? I appreciate any insight or recommendations.

This is what I am working with currently:

WCmore · 2020-11-11 13:46:28 UTC

Good observation. I try to avoid using power as a trigger whenever possible.
(and on the few cases where I use it, I make sure the piston runs top to bottom in under a second)

Qwertypo · 2020-11-11 19:41:59 UTC

How do I setup an IF statement to check the power based on time? Is this the type of thing I should do? Also, do you have any insight as to why $localNow works but $now does not?

WCmore · 2020-11-11 23:39:05 UTC

The way you did above…
(although personally, I would avoid any piston running 1440 times a day!)

Qwertypo · 2020-11-12 02:37:41 UTC

Ok, thanks

So is dialing down to 2 minutes still overkill?

What about the $now issue? It really only bothers me because the time in the Webcore interface is in the wrong time zone for debugging, but it obviously all works relative to itself.

WCmore · 2020-11-12 13:24:06 UTC

Honestly, that is entirely up to you. Just be aware that the more things that are happening at once, the more likely that other pistons may miss certain commands or triggers.

If you are curious, generally speaking my timed pistons run 1-4 times per hour… but I have a single piston for presence that runs every four minutes (when I am awake). That spam piston is short-n-sweet, so it usually completes ¼ sec after it starts up.

I rarely use $localNow… I usually use $now.
(although I often use it as an integer (crazy long number) to do my math with)

As long as the end results are satisfactory to you, then either can work.

Qwertypo · 2020-11-12 16:59:11 UTC

Nevermind what I wrote before, it actually seems to be working with my existing logic replacing for $now. I will keep an eye on it.

Summary

Thats what I expected, but for whatever reason $now in my script produces a rather short number, but looks good on the local variables list, but in the logs it producing a useless comparison, and same equation works just fine with the $localNow. I would definitely prefer to use $now if possible.

This is with $now

Comparison (datetime) 1604788731029 is_after (datetime) 52794474 = true (2ms)

Do you have any other ideas for a trigger other then a timer? Polling has definitely been reliable, but unless I keep the polling rather frequent it will take a while to catch the machine is one and start up

WCmore · 2020-11-12 18:37:14 UTC

You could use a variable in your statement:
(Every X minutes)

Then, at certain times of the day, you could do slow, casual polling:
Set variable X = 15

… and during the action, increase the polling rate.
Set variable X = 3

You’d have to decide at which event(s) to make the switches though…

Pro Tip:

It will take one “cycle” for the timer to see the new duration.