Laundry monitor reminder - global variable subscription not triggering


#1

1) Give a description of the problem
My piston is not getting triggered on a global variable changed event subscription

2) What is the expected behavior?
When my Dryer Monitor piston completes, it sets variable @dryerNeedsOpened to true. That should (and did, for a while!) trigger this piston to start running its loop, which would continue until the dryer was opened.

3) What is happening/not happening?
The piston is NEVER executing, and all I can see in the logs are the times that I have saved / test’ed it over the last couple weeks.

4) Post a Green Snapshot of the pistonimage

Here’s the state of the @dryerNeedsOpened global variable:
image

And here’s the state of the dryer monitor piston (which seems to be working fine):

5) Attach any logs (From ST IDE and by turning logging level to Full)
11/18/2017, 10:40:09 AM +546ms +1ms ╔Received event [Home].test = 1511019609499 with a delay of 46ms +166ms ║RunTime Analysis CS > 21ms > PS > 58ms > PE > 87ms > CE +177ms ║Runtime (40746 bytes) successfully initialized in 58ms (v0.2.0fe.20171109) (175ms) +178ms ║╔Execution stage started +190ms ║║Comparison (boolean) false changes_to (boolean) true = false (6ms) +192ms ║║Condition #18 evaluated false (10ms) +193ms ║║Condition group #17 evaluated false (state did not change) (11ms) +196ms ║╚Execution stage complete. (18ms) +208ms ╚Event processed successfully (207ms) 10/26/2017, 4:01:11 PM +705ms +1ms ╔Received event [Home].test = 1509048071696 with a delay of 9ms +173ms ║RunTime Analysis CS > 19ms > PS > 58ms > PE > 95ms > CE +181ms ║Runtime (40743 bytes) successfully initialized in 58ms (v0.2.0fa.20171011) (179ms) +182ms ║╔Execution stage started +193ms ║║Comparison (boolean) true changes_to (boolean) true = false (3ms) +195ms ║║Condition #18 evaluated false (8ms) +196ms ║║Condition group #17 evaluated false (state did not change) (9ms) +199ms ║╚Execution stage complete. (17ms) +209ms ╚Event processed successfully (209ms) 10/26/2017, 4:01:01 PM +59ms +1ms ╔Starting piston... (v0.2.0fa.20171011) +308ms ║╔Subscribing to devices... +351ms ║║Subscribing to Home.webCoRE.@dryerNeedsOpened... +466ms ║║Subscribing to Jeff... +468ms ║║Subscribing to Lisa... +469ms ║╚Finished subscribing (164ms) +510ms ║Comparison (boolean) true changes_to (boolean) true = false (7ms) +512ms ║Cancelling condition #18's schedules... +513ms ║Cancelling condition #17's schedules... +522ms ║Comparison (boolean) true is (boolean) true = true (3ms) +523ms ║Cancelling condition #1's schedules... +540ms ║Comparison (string) :5ee27ea6428a8985b6603b9e3b29fbad: is (string) :5ee27ea6428a8985b6603b9e3b29fbad: = true (2ms) +542ms ║Cancelling condition #20's schedules... +543ms ║Cancelling condition #19's schedules... +558ms ║Comparison (enum) not present is (string) present = false (3ms) +579ms ║Comparison (enum) present is (string) present = true (3ms) +589ms ║Comparison (boolean) true is (boolean) false = false (2ms) +590ms ║Cancelling condition #1's schedules... +610ms ╚Piston successfully started (609ms) 10/26/2017, 3:48:07 PM +278ms +1ms ╔Received event [Home].time = 1509047288567 with a delay of -1289ms +166ms ║RunTime Analysis CS > 17ms > PS > 54ms > PE > 89ms > CE +176ms ║Runtime (40448 bytes) successfully initialized in 54ms (v0.2.0fa.20171011) (174ms) +177ms ║╔Execution stage started +189ms ║║Cancelling condition #1's schedules... +203ms ║║Comparison (enum) not present is (string) present = false (2ms) +205ms ║║Condition #8 evaluated false (9ms) +206ms ║║Condition group #5 evaluated false (state did not change) (10ms) +217ms ║║Comparison (enum) present is (string) present = true (2ms) +220ms ║║Condition #12 evaluated true (10ms) +221ms ║║Condition group #9 evaluated true (state did not change) (13ms) +224ms ║║Cancelling statement #10's schedules... +260ms ║║Executed virtual command sendSMSNotification (25ms) +270ms ║║Comparison (boolean) true is (boolean) false = false (2ms) +272ms ║║Condition #14 evaluated false (8ms) +273ms ║║Cancelling condition #1's schedules... +274ms ║║Condition group #1 evaluated false (state changed) (11ms) +277ms ║║Cancelling statement #3's schedules... +281ms ║║Executed virtual command wait (0ms) +283ms ║║Requesting a wake up for Thu, Oct 26 2017 @ 4:48:07 PM EDT (in 3600.0s) +292ms ║╚Execution stage complete. (115ms) +294ms ║Setting up scheduled job for Thu, Oct 26 2017 @ 4:48:07 PM EDT (in 3599.99s) +310ms ╚Event processed successfully (310ms) 10/26/2017, 2:48:08 PM +299ms +0ms ╔Received event [Home].time = 1509043689574 with a delay of -1275ms +166ms ║RunTime Analysis CS > 16ms > PS > 64ms > PE > 86ms > CE +177ms ║Runtime (40448 bytes) successfully initialized in 64ms (v0.2.0fa.20171011) (175ms) +178ms ║╔Execution stage started +188ms ║║Cancelling condition #1's schedules... +202ms ║║Comparison (enum) not present is (string) present = false (2ms) +203ms ║║Condition #8 evaluated false (9ms) +204ms ║║Condition group #5 evaluated false (state did not change) (10ms) +215ms ║║Comparison (enum) present is (string) present = true (1ms) +216ms ║║Condition #12 evaluated true (9ms) +217ms ║║Condition group #9 evaluated true (state did not change) (10ms) +219ms ║║Cancelling statement #10's schedules... +251ms ║║Executed virtual command sendSMSNotification (25ms) +257ms ║║Comparison (boolean) true is (boolean) false = false (2ms) +258ms ║║Condition #14 evaluated false (5ms) +260ms ║║Cancelling condition #1's schedules... +260ms ║║Condition group #1 evaluated false (state changed) (7ms) +263ms ║║Cancelling statement #3's schedules... +267ms ║║Executed virtual command wait (0ms) +268ms ║║Requesting a wake up for Thu, Oct 26 2017 @ 3:48:08 PM EDT (in 3600.0s) +273ms ║╚Execution stage complete. (95ms) +274ms ║Setting up scheduled job for Thu, Oct 26 2017 @ 3:48:08 PM EDT (in 3599.994s) +292ms ╚Event processed successfully (292ms) 10/26/2017, 1:48:09 PM +287ms +1ms ╔Received event [Home].time = 1509040090696 with a delay of -1410ms +183ms ║RunTime Analysis CS > 28ms > PS > 70ms > PE > 85ms > CE +195ms ║Runtime (40448 bytes) successfully initialized in 70ms (v0.2.0fa.20171011) (192ms) +196ms ║╔Execution stage started +206ms ║║Cancelling condition #1's schedules... +218ms ║║Comparison (enum) not present is (string) present = false (2ms) +220ms ║║Condition #8 evaluated false (8ms) +221ms ║║Condition group #5 evaluated false (state did not change) (9ms) +233ms ║║Comparison (enum) present is (string) present = true (1ms) +234ms ║║Condition #12 evaluated true (11ms) +235ms ║║Condition group #9 evaluated true (state did not change) (12ms) +237ms ║║Cancelling statement #10's schedules... +268ms ║║Executed virtual command sendSMSNotification (25ms) +275ms ║║Comparison (boolean) true is (boolean) false = false (1ms) +277ms ║║Condition #14 evaluated false (6ms) +278ms ║║Cancelling condition #1's schedules... +279ms ║║Condition group #1 evaluated false (state changed) (9ms) +281ms ║║Cancelling statement #3's schedules... +285ms ║║Executed virtual command wait (0ms) +287ms ║║Requesting a wake up for Thu, Oct 26 2017 @ 2:48:09 PM EDT (in 3600.0s) +292ms ║╚Execution stage complete. (97ms) +294ms ║Setting up scheduled job for Thu, Oct 26 2017 @ 2:48:09 PM EDT (in 3599.994s) +311ms ╚Event processed successfully (311ms)


#2

I just used your design to create a process where if my garage door is open more than 2 hours I get an initial warning, followed by another warning every hour until I close the garage door.

Ran fine in my testing (I temporarily set delays to minutes to do the testing). :slight_smile: First piston runs once. Second runs multiple times, until I closed the garage door. I have no idea if this is the best way to do this, but it worked for me and is based on your work above.

EDIT: Oops…just noticed that my global variable is now showing set to “true” when the garage door was closed after the loop piston ran two times, so the set variable to false command at the end of that piston doesn’t appear to have run when the loop piston ends. Need some help on how to set that up - I think once that is fixed this will work.

Initial piston when door is open > 2 hours

Looping piston until garage door is closed.


#3

There was a bug with global variable subscriptions awhile back, would you please try editing and re-saving the erci piston that you showed in order to set up a new subscription to that variable?


#4

I assume you’re talking to me…as an FYI, I have edited and re-saved that piston a number of times. Each time I test it again I edit the times to minutes instead of hours and then save.

But I’ll edit and save it again now.


#5

The reply was for @talz13 , I’m looking at yours now.


#6

Thanks…BTW, I edited/saved, and the log after the save doesn’t show any subscription to a variable, only to the devices (door and speaker).

NVM…the variable subscription is there, just didn’t realize it would look so different from the devcie subscriptions…end of what I assume is the subscription line in the logs below.

36 PM


#7

What’s up with the three empty if’s inside your loop, is the screenshot accurate?

if
then
    if
    then
        ...
    end if
    if
    end if
end if

#8

LOL…I imported tal13’s piston and then modified…I believe he had a number of presence checks that I didn’t want, so I deleted those actions but the empty if’s were left behind. I didn’t clean it up as I didn’t know it mattered to how the piston runs. :slight_smile:


#9

Try using @garageDoorOpen is true instead of the changes to. With that 1 hour wait I suspect that changes to no longer evaluates to true because the value hasn’t changed recently. I don’t know if the empty ifs matter or not but it looked weird


#10

Thanks, I’ll make the change and test the pistons again. I’ll delete the empty if’s as well… :slight_smile:

When I’m testing all the values are set to minutes (2 minutes open, 1 minute cycle in the loop piston) so it doesn’t seem like the wait length affects the loop piston not setting the variable back to false when it ends.

Oops - just remembered that the piston already has “garagedooropen is true” as a condition in the “only when” argument.

So the piston will start with:

if: garargedooropen is true
only when: garagedooropen is true

Just wanted to confirm that’s what you mean.


#11

Tried cleaning it up quite a bit…

Didn’t trigger piston w/it set to “garagedooropen is true” - I’ll try resetting back to “changes to open” w/the newer tighter piston and see what happens.


#12

@ipaterson

The Take 2 version of the loop piston works perfectly in terms of the looping while the door is open, and ends when the door closes, but the variable still doesn’t get reset to false at the end…I cannot figure out how to make it reset at the end of the loop/piston! Feel like a dummy, this must be something obvious…


#13

I don’t know why but I feel like verifying the same global variable is part of the issue. If you’re this, but only if you’re STILL this, do this. I don’t know, seems strange to me. Not saying it is the issue but I’d try it.

I’d try:

If ‘@Garagedoor’ is true, then put in the repeat. If it starts repeating, then the condition is no longer true it should stop the loop.


#14

Thanks, @the_cosworth, appreciate the help.

The issue isn’t that the piston won’t stop looping - it stops as soon as the garage door closes. What I can’t get the looping piston to do is reset the global variable to false…if I can’t reset the variable then the first piston that calls the looping piston never runs again.

I just can’t figure out why the set variable command at the end of the piston isn’t running.

Log from the end of the piston when i close the garage door…no mention of setting the variable to false.

28 PM


#15

The logic is strange here, what you’ve set up would theoretically wait up to an hour after the garage closes, then notify you that it’s still open, then set @garageDoorOpen = false. Can you just use an if contact changes to closed at the top level to reset that variable when the contact closes?


#16

Thanks…sorry, I should have provided a little background, I can see how it looks strange. The delay is intentional - my son often has the garage open when working on his bikes, so I don’t want to know until it’s been open for a while. I can’t use motion as he can sit quietly doing something w/a part where there is no motion for quite a while. The actual delay for the first warning from the first piston is going to be 2 hours, but this piston will be restricted to between 9AM and 4PM (his normal hobby hours). Outside of those times I get notified when the garage door is open more than 15 minutes. I’m going to add the final timing restriction after I have the rest working.

Right now the two pistons do run flawlessly in terms of messaging me while the door is open…except for the variable reset it’s perfect. :slight_smile: I get the first warning from the first piston after the door is opened for the set time, and then the second piston loops exactly as desired and sends the additional warnings at the set interval until I close the garage door.

Anyway, I will try what you suggest… thanks!


#17

VICTORY!!!

Not sure if this is what you meant, but adding the if to change the variable to false when the door closes in the first piston resolved the issue.

The second piston ends as expected and the variable is reset to false for the next run.

Excellent!


#18

Now let’s see if re-saving the piston fixes the original issue in this thread for OP @talz13


#19

Good point - wasn’t my intention to hijack his thread, I thought I was actually helping to provide a working version of his piston. Apologies to @talz13.


#20

I think I got some ideas from your posts @Danabw – I added the if statement to my washer and dryer monitor pistons to set @washerNeedsOpened and @dryerNeedsOpened to false if the value was true and the door was opened. I also changed my reminder piston to trigger on @dryerNeedsOpened stays true for 1 hour instead of using the changes to true condition and only when true restriction

One question I have is, if I trigger on something like {@dryerNeedsOpened} stays true for 1 hour, will it only trigger after the first hour, or will it repeatedly trigger each hour?