Checking the status of a device subscribes to the device?

[deergod1]

1) Give a description of the problem
Checking light on/off subscribes to each device and causes extra events for every device tested on each button press. i.e. if I have a button that controls two switches, I get two extra events caused by changing the level of the lights.

2) What is the expected behaviour?
I only want the button events to be subscribed. The piston works perfectly except for the extra device events. It allows a simple button to provide four different states for my lights (Off, 1%, 50%, 100%) with the switch statement cases for ‘pushed’ (on/off), ‘double’ (50%), and ‘held’ (100%).

3) What is happening/not happening?
The piston fires multiple times in rapid succession. Removing only the “if on/off” for each device prevents subscribing to those extra device events, but then doesn’t allow me to check the switch before setting the level. Testing the $currentEventAttribute avoids the switch statement if it’s not the button event (only needed because of the switch events). Is there an alternate test I can do?

**4) Post a Green Snapshot of the piston![image|45x37]

5) Attach logs after turning logging level to Full
8/18/2019, 10:09:33 PM +895ms
+2ms ╔Received event [Office Desk Lamp].switch = off with a delay of 85ms
+109ms ║Runtime (41556 bytes) successfully initialized in 49ms (v0.3.10e.20190628) (105ms)
+110ms ║╔Execution stage started
+129ms ║║$currentEventAttribute is switch
+133ms ║║Executed virtual command log (5ms)
+141ms ║║Executed virtual command setState (1ms)
+143ms ║╚Execution stage complete. (34ms)
+144ms ╚Event processed successfully (144ms)
8/18/2019, 10:09:33 PM +457ms
+1ms ╔Received event [Office Couch Lamp].switch = off with a delay of 115ms
+107ms ║Runtime (41556 bytes) successfully initialized in 51ms (v0.3.10e.20190628) (104ms)
+108ms ║╔Execution stage started
+125ms ║║$currentEventAttribute is switch
+128ms ║║Executed virtual command log (4ms)
+135ms ║║Executed virtual command setState (1ms)
+137ms ║╚Execution stage complete. (29ms)
+138ms ╚Event processed successfully (138ms)
8/18/2019, 10:09:32 PM +1ms
+1ms ╔Received event [Allen’s Button].button = pushed with a delay of 87ms
+110ms ║Runtime (41547 bytes) successfully initialized in 51ms (v0.3.10e.20190628) (108ms)
+111ms ║╔Execution stage started
+161ms ║║Executed [Office Couch Lamp].setLevel (15ms)
+175ms ║║Executed [Office Desk Lamp].setLevel (13ms)
+186ms ║║$currentEventAttribute is button
+190ms ║║Executed virtual command log (4ms)
+193ms ║║Executed virtual command setState (1ms)
+195ms ║╚Execution stage complete. (84ms)
+196ms ╚Event processed successfully (197ms)
8/18/2019, 10:09:19 PM +993ms
+0ms ╔Starting piston… (v0.3.10e.20190628)
+228ms ║╔Subscribing to devices…
+270ms ║║Subscribing to Allen’s Button.button…
+286ms ║║Subscribing to Office Couch Lamp.switch…
+301ms ║║Subscribing to Office Desk Lamp.switch…
+383ms ║╚Finished subscribing (175ms)
+470ms ╚Piston successfully started (470ms)

[WCmore]

Line 33 is subscribed to White Bulb 1 and White Bulb 2’s switch. This means when either bulb turns on or off, the entire piston will run thru the code from the top to the bottom, and execute any code allowed by conditions.

So if a bulb is on, and you send a “Set level to 0”, the switch will change to off.
If the bulb is off, and you send a “Set level to 1, 50 or 100%”, the switch will change to on.

All four scenerios will re-trigger the piston from the top.
(and doubly so if both bulbs are changed)

[WCmore]

I only want the button events to be subscribed

For this bit, you can edit line 33 (lightning bolt), click on the cog, and change “Subscription method” to “Never Subscribe”. This will remove the lightning bolt.

Just keep in mind, this method will remove the only trigger from this piston.
From then on, it will only run when called from another source.

(You can make the “button presses” a trigger to combat this)

[WCmore]

Good rule of thumb for future programming?

For the most part, it is wise to:
Avoid sending commands to the device attributes that are used as a trigger in that same piston.

For example, avoid doing this:

IF Hallway's switch changes X
    Then with Hallway's switch do Y
END IF

Every trigger will fire at least twice, and a poorly written piston could cycle indefinitely.
(well, at least until you unplug the ST hub, that is)

[deergod1]

Nice! I did not know that. Going to edit right now!

[deergod1]

All four scenerios will re-trigger the piston from the top.
(and doubly so if both bulbs are changed)

Exactly. And disabling the subscription to the switches is the fix! Setting “Never subscribe” works perfectly. It still shows the event when starting the piston, but it’s grayed out and setting the lights does not fire the piston. It only fires for button presses.

8/19/2019, 11:18:04 AM +585ms
+1ms ╔Starting piston… (v0.3.10e.20190628)
+251ms ║╔Subscribing to devices…
+302ms ║║Subscribing to Allen’s Button.button…
+398ms ║║Subscribing to Office Couch Lamp…
+400ms ║║Subscribing to Office Desk Lamp…
+401ms ║╚Finished subscribing (169ms)
+485ms ╚Piston successfully started (485ms)

I continue to be impressed with the thoughtfulness put into Webcore. It’s quirky sometimes, but it’s damn impressive.

Thank you sir!!

[WCmore]

It only fires for button presses

Are you saying that the piston runs without any lightning bolts in the left margin?

I would love to see how you achieved this!!

[deergod1]

Oh, hello… I’ve been away for a bit, but, YES. That’s correct. No lightning bolts in the margin and no stray events. I call it 4-state button. It works without fail.

piston: ubd3

[WCmore]

Thanks for sharing!

[deergod1]

Here’s a full cycle of Starting the piston… lights on (1%)… 50%… 100%… then off.

I love it. Thanks again for the help!