Momentary Button Too Quick?

Hilly_2015 · 2018-01-09 08:35:03 UTC

1) Give a description of the problem

I have a ‘goodnight’ routine which I use via Alexa. Basically by saying ‘Alexa, bed time’ it toggles a virtual switch (Momentary Button Tile DTH) which should turn off all of the lights, set the location mode to ‘sleep’ and finally arm my Blink camera.

What seems to be happening is that the toggling of the button is ‘too quick’ for WebCore, so when it comes to doing the comparison part - it returns false. I then have to say the phrase again, which eventually gets it to work.

2) What is the expected behavior?

Essentially, when toggled for the first time - it should do all of the above.

3) What is happening/not happening?

Alexa responds with my correct response that I’ve set, but the webcore piston fails to do it’s bit.

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)

First Alexa call (FAIL):

+1ms	╔Received event [Night, Night!].switch = off with a delay of 75ms
+111ms	║RunTime Analysis CS > 19ms > PS > 21ms > PE > 70ms > CE
+113ms	║Runtime (38117 bytes) successfully initialized in 21ms (v0.2.101.20171227) (111ms)
+114ms	║╔Execution stage started
+121ms	║║Comparison (enum) off changes_to (string) on = false (0ms)
+122ms	║║Condition #5 evaluated false (4ms)
+123ms	║║Condition group #1 evaluated false (state did not change) (5ms)
+125ms	║╚Execution stage complete. (11ms)
+126ms	╚Event processed successfully (126ms)

Second Alexa call (SUCCESS):

|+0ms|╔Received event [Night, Night!].switch = on with a delay of 74ms|
|---|---|
|+97ms|║RunTime Analysis CS > 13ms > PS > 21ms > PE > 63ms > CE|
|+99ms|║Runtime (38118 bytes) successfully initialized in 21ms (v0.2.101.20171227) (98ms)|
|+100ms|║╔Execution stage started|
|+106ms|║║Comparison (enum) on changes_to (string) on = true (0ms)|
|+107ms|║║Cancelling condition #5's schedules...|
|+108ms|║║Condition #5 evaluated true (4ms)|
|+109ms|║║Cancelling condition #1's schedules...|
|+109ms|║║Condition group #1 evaluated true (state changed) (6ms)|
|+111ms|║║Cancelling statement #2's schedules...|
|+538ms|║║Executed physical command [Bed].off() (423ms)|
|+539ms|║║Executed [Bed].off (425ms)|
|+544ms|║║Skipped execution of physical command [Bedroom Light].off([]) because it would make no change to the device. (3ms)|
|+545ms|║║Executed [Bedroom Light].off (4ms)|
|+550ms|║║Skipped execution of physical command [Corner Lamp].off([]) because it would make no change to the device. (3ms)|
|+550ms|║║Executed [Corner Lamp].off (4ms)|
|+584ms|║║Executed physical command [Hall Light].off() (31ms)|
|+584ms|║║Executed [Hall Light].off (33ms)|
|+1773ms|║║Executed physical command [Outside Lights].off() (1187ms)|
|+1774ms|║║Executed [Outside Lights].off (1188ms)|
|+1801ms|║║Executed physical command [Porch Light].off() (25ms)|
|+1802ms|║║Executed [Porch Light].off (26ms)|
|+1808ms|║║Skipped execution of physical command [Sofa Lamp].off([]) because it would make no change to the device. (3ms)|
|+1808ms|║║Executed [Sofa Lamp].off (5ms)|
|+1813ms|║║Skipped execution of physical command [TV Backlight].off([]) because it would make no change to the device. (3ms)|
|+1814ms|║║Executed [TV Backlight].off (5ms)|
|+1818ms|║║Skipped execution of physical command [Watch TV [Harmony Activity]].off([]) because it would make no change to the device. (3ms)|
|+1819ms|║║Executed [Watch TV [Harmony Activity]].off (4ms)|
|+1865ms|║║Executed virtual command [Bed, Bedroom Light, Corner Lamp, Hall Light, Outside Lights, Porch Light, Sofa Lamp, TV Backlight, Watch TV [Harmony Activity]].setLocationMode (44ms)|
|+1867ms|║║Cancelling statement #6's schedules...|
|+2207ms|║║Executed physical command [null].on() (338ms)|
|+2208ms|║║Executed [Blink].on (339ms)|
|+2210ms|║╚Execution stage complete. (2111ms)|
|+2211ms|╚Event processed successfully (2211ms)|

rsmith179 · 2018-01-09 09:54:27 UTC

Are you sure that switch 3 is a virtual momentary button? I have a piston setup the same as yours and it works flawlessly. Based on the logs, it looks like the first time you pressed the button it changes to “off” which wouldn’t fire the piston. The second time it changed to “on” and everything else was successful. I’d double check to make sure your using the right DTH for that button you setup.

Mike1616 · 2018-01-09 12:17:11 UTC

OR…just use a regular switch and then turn it back OFF at the end of your piston.

Hilly_2015 · 2018-01-09 12:36:49 UTC

Yup. 100% positive. This is a screenshot of my virtual switch in the IDE:

Then this is what my routine looks like in the Alexa app:

@Mike1616 - Yes that’s possible, but to be honest…why should I need to? Surely the momentary switch should work as that’s what it’s designed to do? I would rather use the right tool for the job and find out where the issue lies than have to use a regular switch and then have to work round it in the piston itself.

c1arkbar · 2018-01-09 12:50:25 UTC

Momentary buttons still turn on and off. It’s usually just a real quick on and off.

This was going to be my suggestion @rsmith179

Can you confirm that there isn’t an attribute for ‘button pressed’ or something along those lines instead of switch?

Looks like you already have your actions set to never cancel?

Mike1616 · 2018-01-09 12:55:38 UTC

OK…but it’s not like I’m suggesting you use a hammer instead of a screwdriver. We’re discussing which flavor of “VIRTUAL” devices will get the job done.

Anyway @rsmith179 is right. There’s something up because in the logs it’s OFF the first time thru and then ON for the second run.

Hilly_2015 · 2018-01-09 12:57:59 UTC

This is the DTH for the Momentary Button Tile:

https://pastebin.com/e7hEPZeQ

In terms of the ‘Never Cancel’ - I’ll be honest… this was my first attempt at trying to fix the issue (my original was set to default). I’m not entirely sure whether this is required but I saw other posts suggesting that this may help so I added it just in case.

Hilly_2015 · 2018-01-09 13:00:39 UTC

True. I have no doubt that your way will solve this issue but I’m just the type of guy who likes to know why it’s broken (whether that be because of the DTH or whatever…) so I can potentially learn for next time.

If all else fails, I will just do as you say though

c1arkbar · 2018-01-09 13:10:31 UTC

Ok try changing from switch to momentary.

Also you were on the right track of thinking with never cancel. Because that is what I was thinking as well. The on and off was coming to quick and canceling all your statements.

Hilly_2015 · 2018-01-09 13:17:16 UTC

You mean try changing from momentary to switch?

Like I say, I have no doubt that changing it to a switch will work - just would be good to know the reason why the momentary doesn’t work. Even just to uncover whether I’ve uncovered a potential bug or not…

This is what my piston will look like using a switch:

Mike1616 · 2018-01-09 13:47:25 UTC

No…he literally means, change from switch to momentary. In the DTH that you have that should be an option.

Switch 3’s momentary

You could also try “On Events from Switch 3’s momentary”

Hilly_2015 · 2018-01-09 14:56:17 UTC

Forgive me, but due to my lack of ‘Groovy’ knowledge, perhaps I’m misunderstanding here - where are you suggesting I change this?

There are no options on the device itself (via the cog menu). Are you suggesting I amend the ‘Momentary Button Tile’ DTH and remove lines 48 and 49 so that is solely momentary? Or are you suggesting I amend the value on line 50 to become ‘on’ instead of ‘pushed’?

Or…are you suggesting I somehow change Line 18 on the piston to use momentary settings - how I do this I don’t know because the only options available to me in the dropdown there are ‘switch’ and ‘$status’.

Appreciate the patience.

Mike1616 · 2018-01-09 16:26:33 UTC

It was that one. So if that isn’t showing up in there then that’s not an option. So you’ll just have to use “switch”. I don’t have that DTH loaded, so I didn’t test or confirm that it was in there. I take it he didn’t either.

New thought… Here’s the problem I have with this entire thing. If the momentary is sending both an ON and an OFF command to WC and we’re presuming that the ON is happening too fast for WC to react to it, then why does it ever work the second time? Wouldn’t that also send an ON and an OFF to WC each and every time? It’s not going to be OFF the first time and then be ON the 2nd time. It’s almost like you have a momentary that is acting like a regular switch.

I would be curious from the Full logs if the switch sends both an ON and OFF to webCoRE EVERY time. Or if on consecutive events from the Alexa that it will be ON then OFF then ON then OFF, etc.

If that tuns out to be true…that it only sends ONE command to WC each time and the command it sends is the opposite of what it was before then you can still work with that…but you just need to change the piston.

Instead of saying “IF the switch turns ON” you’d say:

On Events from Switch 3’s Switch

Then your ON/OFF/ON/OFF/ON/OFF wouldn’t matter to WC…it would react every time the switch flipped.

However, if the DTH actually sends both an OFF and ON command, then I go back to my other question…why does it ever work the 2nd time?

c1arkbar · 2018-01-09 17:02:12 UTC

Sorry had to go cut some trees down. Yea I was basing my responses on the DTH. There should be an option for momentary based on the groovy code. Continuing to press forward. It seems like this is acting like a toggle instead.

Hilly_2015 · 2018-01-09 18:42:15 UTC

Delving into the IDE logs, this is what is looks like for the one that failed:

…and this is what it looks like for the one that succeeded just a few seconds later:

Very little difference from what I can tell!

Mike1616 · 2018-01-09 19:22:37 UTC

Well, there you go. That’s the answer then. It’s too fast for webCoRE to react appropriately.

The DTH sends the ON command then .010 seconds later it sends the OFF command. webCoRE is seeing the event(s) with a .074 second delay. So that’s way too fast for WC to get both commands.

So the choices that you have now would be to 1) get a new DTH that has some delay in between the ON/OFF commands being sent. 2) modify this DTH to add in some delay between the ON/OFF being sent. 3) Use the trigger “changes” instead of “changes to” as you know you’re only going to get 1 command anyway (working around the fact that it’s too fast to get both) or 4) use a regular switch and then just turn it off at the end.

bobbles · 2018-01-09 19:30:10 UTC

Bit late to the party on this but would changing the ‘Turn On’ to ‘Toggle’ work for you?
So ‘On Events’ from…
Toggle.
Bit of a hack I know.

Hilly_2015 · 2018-01-09 20:07:57 UTC

Thanks to everybody for their help with this.

I have a few other devices that use the ‘Momentary Button Tile’ DTH (security cameras for detecting motion) so I’m slightly worried that this same issue could potentially happen on pistons involving those devices as well i.e. events are potentially missed. I haven’t got the fastest of internet connections currently so I’m sure that’s forming part of the delay.

Long term I’d like to investigate adding a delay of about 5 seconds into my DTH (https://pastebin.com/e7hEPZeQ) between the on and off - that way I can use it across my various devices without fear of missing anything.

In the meantime, I’m probably just going to go down the route mentioned above and change the DTH to a switch and do a wait on the WebCore side of 5 seconds and turn off. It’ll mean changing a few pistons, but it should work.

steinauf · 2020-09-11 19:29:54 UTC

Reading this thread is surreal as I’ve been going through all of these suggestions and workarounds to fix the same issue as OP.

I’m using a very similar DTH, and it sends the ON then OFF back to back. I also have situations where webCoRE sees the off command before the ON…sometimes. The second command would end up waiting at a 10s semaphore which I find to be annoying as I sit there waiting for something to happen, though at least it did execute.

Logs where off is received before the on, and waits at semaphore (TCP=Never)

9/9/2020, 2:47:35 PM +795ms
+1ms	╔Received event [z Alexa Good Morning].switch = on with a delay of 189ms
+10137ms	║RunTime Analysis CS > 25ms > PS > 10078ms > PE > 34ms > CE
+10138ms	║Piston waited at a semaphore for 10019ms
+10140ms	║Runtime (38904 bytes) successfully initialized in 10078ms (v0.3.110.20191009) (10138ms)
+10141ms	║╔Execution stage started
+10147ms	║║Comparison (enum) on changes_to (string) on = true (1ms)
......
+10204ms	║╚Execution stage complete. (64ms)
+10205ms	╚Event processed successfully (10205ms)

9/9/2020, 2:47:35 PM +755ms
+1ms	╔Received event [z Alexa Good Morning].switch = off with a delay of 55ms
+86ms	║RunTime Analysis CS > 15ms > PS > 40ms > PE > 31ms > CE
+88ms	║Runtime (38817 bytes) successfully initialized in 40ms (v0.3.110.20191009) (87ms)
+89ms	║╔Execution stage started
+96ms	║║Comparison (enum) off changes_to (string) on = false (1ms)
+98ms	║║Cancelling condition #2's schedules...
+98ms	║║Condition #2 evaluated false (5ms)
+100ms	║║Cancelling condition #1's schedules...
+100ms	║║Condition group #1 evaluated false (state changed) (7ms)
+102ms	║╚Execution stage complete. (13ms)
+103ms	╚Event processed successfully (103ms)

I tried enabling parallelism, but that didn’t work since they both run so fast, by the time it evaluated the conditions, the switch status had already changed.

Logs when Parallelism is enabled, along with Never cancel tasks

9/11/2020, 7:09:54 AM +393ms
+1ms	╔Received event [z Alexa Good Morning].switch = off with a delay of 116ms
+115ms	║RunTime Analysis CS > 22ms > PS > 56ms > PE > 37ms > CE
+117ms	║Runtime (38810 bytes) successfully initialized in 56ms (v0.3.110.20191009) (115ms)
+118ms	║╔Execution stage started
+125ms	║║**Comparison (enum) off changes_to (string) on = false (0ms)**
+126ms	║║Cancelling condition #2's schedules...
+127ms	║║Condition #2 evaluated false (5ms)
+128ms	║║Cancelling condition #1's schedules...
+129ms	║║Condition group #1 evaluated false (state changed) (6ms)
+148ms	║╚Execution stage complete. (30ms)
+157ms	╚Event processed successfully (157ms)

9/11/2020, 7:09:54 AM +332ms
+1ms	╔Received event [z Alexa Good Morning].switch = on with a delay of 66ms
+81ms	║RunTime Analysis CS > 16ms > PS > 36ms > PE > 29ms > CE
+83ms	║Runtime (38807 bytes) successfully initialized in 36ms (v0.3.110.20191009) (81ms)
+84ms	║╔Execution stage started
+91ms	║║**Comparison (enum) on changes_to (string) on = false (0ms)**
+93ms	║║Cancelling condition #2's schedules...
+94ms	║║Condition #2 evaluated false (5ms)
+95ms	║║Cancelling condition #1's schedules...
+96ms	║║Condition group #1 evaluated false (state changed) (7ms)
+113ms	║╚Execution stage complete. (29ms)
+121ms	╚Event processed successfully (121ms)

to your point of modifying the DTH to add in some delay, I too thought that would be great, but I’ve spent some time looking only to read threads by frustrated others who were unable to do that. If anyone knows, I’d love to see how. (edit: this suggests I can just add "delay 1000" to introduce a 1 second delay between commands. i’ll try it)

using the trigger “changes” seems risky because two commands are still being sent, and i dont want my piston running twice. if i turn task cancellation policy back to default, it’s likely that the second trigger might cancel, but doesn’t help that it’s unreliable exactly which trigger shows up second.

Ideally I’d just have webCoRE read the momentary event, but as was pointed out earlier in this thread, momentary doesn’t show up in the drop down…just switch and $status. I’m not sure why, because in device setup it does ask me to select all of my momentary switches.

Paul1964 · 2020-09-11 19:45:55 UTC

I’ve not read the whole thread, however, would it be simpler to just use a normal virtual on/off switch?
Alexa would turn this on, your piston would run, and at the end just turn the switch off again, ready for the next activation. I use this for my alexa “goodnight” routine, the only difference is I turn the switch off at dusk, so I can use it to determine we’ve gone to bed. (could use home status too)