Piston Delay Causes Wrong Execution Order when fired multiple times

#1

1) Give a description of the problem
I have a piston that gets triggered every second if a button is held.

The is a Device Handler for the Osram Smart Dim Switch here. This handler is the one that does the mutli-request is the switch is held in dim mode.

I can watch the level change (in increments of 20) in the handler logs (below). I can see the light change in the proper direction. Every once in a while as it is changing in one direction (brighter) it goes in the other. The only thing I can think of is that webcore is getting out of sync of which request to run first, so it runs the lower level after the higher.

I feel I have read about this in webcore before, but I couldn’t find it (of course) when looking now. Wondering if any one can chime in?

Is there a way to tell WEBCORE to cancel previous requests and honor the new? I get that will make the lights level bounce more, but at least it goes in the proper order.

2) What is the expected behaviour?
Webcore honors the request order of a piston triggered in multiple succession.

3) What is happening/not happening?
It appears that if a piston is fire multiple times in succession, it sometimes runs them out of incoming request order.

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

image
image.png1178Ă—993 90.6 KB

**5) Handler Log
7040-4bc5-a63e-3a12af15ea 10:58:01 PM: info Final State: on
7040-4bc5-a63e-3a12af15ea 10:58:01 PM: info Final Level: 100
7040-4bc5-a63e-3a12af15ea 10:58:01 PM: debug RELEASED
7040-4bc5-a63e-3a12af15ea 10:58:01 PM: info button held
7040-4bc5-a63e-3a12af15ea 10:58:01 PM: debug catchall: 0104 0008 01 01 0000 00 B6C1 01 00 0000 03 00
7040-4bc5-a63e-3a12af15ea 10:57:47 PM: info Final State: on
7040-4bc5-a63e-3a12af15ea 10:57:47 PM: info Final Level: 100
7040-4bc5-a63e-3a12af15ea 10:57:44 PM: info Final State: on
7040-4bc5-a63e-3a12af15ea 10:57:44 PM: info Final Level: 80
7040-4bc5-a63e-3a12af15ea 10:57:41 PM: info Final State: on
7040-4bc5-a63e-3a12af15ea 10:57:41 PM: info Final Level: 60
7040-4bc5-a63e-3a12af15ea 10:57:38 PM: info Final State: on
7040-4bc5-a63e-3a12af15ea 10:57:38 PM: info Final Level: 40
7040-4bc5-a63e-3a12af15ea 10:57:38 PM: info Final State: on
7040-4bc5-a63e-3a12af15ea 10:57:38 PM: info Final Level: 40

#2

Well, you trigger off the button push which then changes the level which is another trigger so you get multiple events constantly conflicting. Having two triggers in the same piston that are related is never a good idea. In general, one trigger per piston is a good rule to avoid conflicts like this.

#3

The push doesnnt get triggered when it is held. So there is only one trigger, but then it sends multiple level changes as it is pushed. I could thought break out the level listener from the push listener and see if that helps

#4

I see. So, where are you seeing the requests out of order? Could just be a problem with the repeat rate. When there are repeated requests like this is it possible for webcore to hung up in startup but that is beyond my knowledge. If there is any other network traffic, one of the triggers could get delayed resulting in an out of sequence event.

#5

The handler sends:
Adjust 40
Adjust 60
Adjust 80
Adjust 100

I watch the light go 40 -> 80 -> 60 and sometimes never to 100 – or it was mixed in there, and wound up ending at 60

#6

@guxdude I think you led me in the right direction. I think I was sending a roque PUSH event when LEVEL was being sent, which then was sending 2x requests. Sliding that out of the chain seems to be making this work better

#7

There is no reference in your piston above about any increments…
This piston simply matches one level to another.

There is no code here for this either…

Also, one more observation, your last IF block on lines 46-54 will never be true. Most devices never go below 1% level. If the device is turned off, the level will stay at the previous level until it turns back on.

#8

The levels are set by the handler, code is referenced @WCmore … unfortunately, the switch can go subzero on a level. There is checks in the code, to prevent it - but its a double guard

#9

What I meant was, there is no “plus 20” or “minus 20” in this piston… It simply sets the level to whever Dimmer 1 is currently at. I think you should direct your focus to whatever programming you have in place that is adjusting “Dimmer 1”. (not this piston that is only reacting to those changes)

Side note:
Spamming any command every second is bound to occasionally have hiccups or delays

#10

@WCmore I think you and I are slightly out of phase here, but I think your side note brings us closer.

As the title said, the Piston delay is causing the execution order. I get that this Piston is really simple and in your perfect words, REACTIVE

The issue is, Im trying to create a dimmer, based on an external source (it being a switch that when held, dims at +/- 20 each second). At the end of the day, I think its that webcore gets cranky being hit that hard. But unfortunately, and longer delay will make dimming a light excruciating slow.

Any other ideas on how to tackle this would be great.

#11

When I am trying to sync two devices to match, I usually try to change the “master” (quickly and smoothly). A second later, my piston picks up the change, and sets the other device to match. Something like:

IF Dimmer 1's level stays unchanged for 1 second
Then
    With @kitchenLights
    Set level to Dimmer 1's level
END IF

So, if your “external source” is changing Dimmer 1’s level, then the code above will make @kitchenLights match a second later.

In your case, since your “external source” changes every second, you may want to increase my example above to 1500ms or 2 seconds. (either that, or speed up the external source)

Ideally, the piston above will be a bit longer than the actually dim changing.