Simple, but I’m new

#1

Hello!!! So I’ve been working on this for the past 10 hours and cannot figure it out.

I have a button that I want to turn on a light. If the light is on, I want it to turn off. After I get that working, I want long press to turn on the light at 100% and then fade down until the press is released. Whenever I implement this first part, simple turning on and off, I get various results. Sometimes the light turns on perfectly, but won’t turn off. Sometimes the other way around. Always though, it seems to be looping, where it will turn on and off the light.

Please help, I want to like this platform, but I’m finding this simple task very challenging. Thank you!

image
B60A8220-3AE7-4838-B836-08DA113AE6D5.png1178×602 74.5 KB

#2

There’s a simple function in webCoRE that permits that in one command especially when you have a button. Toggle means exactly that. If it’s ON, turn it OFF and if it’s OFF turn it on. No need to test for anything as WC will figure out what to do and send the appropriate command.

image
image.png1178×462 19.4 KB
#3

Perfect thank you!! I was assuming I needed to add something after the toggle! Makes perfect sense!

Now that I have that, there is still the very large delay. It seems like something is pooling in the background or something…my memory always goes up every time I hit the button. If I make a code change, it’s fast again.

#4

Well, to dig into what might be happening you’d have to turn on the Logging to FULL and then post the logs. Hard to say otherwise.

#5

Gotcha, sorry I’m new at this!!

1ms ╔Received event [Laundry Room Switch].button = pushed with a delay of 182ms
+10176ms ║RunTime Analysis CS > 27ms > PS > 10117ms > PE > 30ms > CE
+10177ms ║Piston waited at a semaphore for 10018ms
+10179ms ║Runtime (37541 bytes) successfully initialized in 10117ms (v0.2.102.20180116) (10177ms)
+10180ms ║╔Execution stage started
+10197ms ║║Comparison (enum) pushed gets (string) pushed = true (8ms)
+10199ms ║║Condition #4 evaluated true (13ms)
+10200ms ║║Condition group #1 evaluated true (state did not change) (14ms)
+10202ms ║║Cancelling statement #5’s schedules…
+10218ms ║║Executed physical command [Laundry Room].on() (8ms)
+10219ms ║║Executed virtual command [Laundry Room].toggle (15ms)
+10221ms ║╚Execution stage complete. (41ms)
+10222ms ╚Event processed successfully (10222ms)
1/24/2018, 6:22:03 AM +241ms
+1ms ╔Received event [Laundry Room Switch].button = pushed with a delay of 197ms
+10147ms ║RunTime Analysis CS > 14ms > PS > 10111ms > PE > 21ms > CE
+10147ms ║Piston waited at a semaphore for 10018ms
+10149ms ║Runtime (37548 bytes) successfully initialized in 10111ms (v0.2.102.20180116) (10148ms)
+10150ms ║╔Execution stage started
+10161ms ║║Comparison (enum) pushed gets (string) pushed = true (4ms)
+10163ms ║║Cancelling condition #4’s schedules…
+10164ms ║║Condition #4 evaluated true (8ms)
+10165ms ║║Cancelling condition #1’s schedules…
+10165ms ║║Condition group #1 evaluated true (state changed) (10ms)
+10167ms ║║Cancelling statement #5’s schedules…
+10181ms ║║Executed physical command [Laundry Room].on() (8ms)
+10182ms ║║Executed virtual command [Laundry Room].toggle (12ms)
+10187ms ║╚Execution stage complete. (37ms)
+10188ms ╚Event processed successfully (10188ms)
1/24/2018, 6:22:03 AM +388ms
+1ms ╔Received event [Laundry Room Switch].button = released with a delay of 45ms
+130ms ║RunTime Analysis CS > 15ms > PS > 96ms > PE > 19ms > CE
+132ms ║Runtime (37469 bytes) successfully initialized in 96ms (v0.2.102.20180116) (131ms)
+133ms ║╔Execution stage started
+141ms ║║Comparison (enum) released gets (string) pushed = false (1ms)
+143ms ║║Condition #4 evaluated false (4ms)
+144ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+146ms ║╚Execution stage complete. (13ms)
+147ms ╚Event processed successfully (147ms)
1/24/2018, 6:22:03 AM +218ms
+0ms ╔Received event [Laundry Room Switch].button = released with a delay of 48ms
+139ms ║RunTime Analysis CS > 23ms > PS > 95ms > PE > 19ms > CE
+142ms ║Runtime (37469 bytes) successfully initialized in 95ms (v0.2.102.20180116) (140ms)
+143ms ║╔Execution stage started
+153ms ║║Comparison (enum) released gets (string) pushed = false (3ms)
+154ms ║║Condition #4 evaluated false (6ms)
+155ms ║║Condition group #1 evaluated false (state did not change) (8ms)
+158ms ║╚Execution stage complete. (15ms)
+159ms ╚Event processed successfully (160ms)

#6

Is that just a single press and release of the button?

Regardless, this is concerning…

The piston is waiting about 10 seconds before processing the pushed events.

#7

Yes, just a simple press and release. I see this on any of the pistons I create, no matter how I set them up.

I have tried to do some research as to why you would get delays in your piston execution, but I cannot find any…

#8

Any additional thoughts I can try?

#9

Can you post a snapshot and of your latest piston please?

#10

If I were to make any guesses, I’d say that WC does not like the button you have…or maybe a better way of saying it would be that they don’t appear to play together nicely.

Your button throws four events for a single press. Which means that WC has to try and interpret everything that happened in a few milliseconds. I don’t know if a cloud based rules engine is a good fit for something like that.

Now, perhaps if there was a way to modify the device type handler for this button that you have and introduce some delay into it…but I don’t know if that is a very reliable strategy either.

Buttons are quirky like that. A standard on/off switch is easy to program against as they are not as fast. But once you start doing too much in a short period of time things can start to get messed up.

#11

Awesome thank you! I installed CoRE and got things working just now!!! Thank you for your help

#12

Good catch Mike!

This issue could be a good candidate for a lockout timer. With that you could basically ignore button inputs for 1 second or more (depending on the end application), preventing the triggers from backing up like that.

At least in theory. Would need to try to see if it works.

#13

Yeah, I wonder about that. There’s certainly a difference in a piston not reacting to the events that get sent to it and a piston completely ignoring the events. To make this work you’d really need to completely ignore the events and I’m not sure they work that way. I think the piston would receive the events and try to process them even if it was going to ultimately ignore them. I’d speculate that the flood of events coming in would overwhelm the piston as it is doing now even if you put in logic to ignore most of the events.

You’re right though, testing would be needed in order to confirm exactly how all of this would work.