Save current scene


#1

1) Give a description of the problem
Errors when trying to capture current lighting “scene”

2) What is the expected behaviour?
Capture new lighting “scene” to global state, if any of the devices level has changed (=> new lighting scene).

3) What is happening/not happening?
Sometimes it fails to capture all lights (correctly).
Secondary: Piston gets semaphores - one for each light (off course). Don’s know if this matters at all :slight_smile:

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

5) Attach logs after turning logging level to Full


#2

My first observation is that testing for changes in the last three seconds doesn’t give you much of a foul up factor to allow for latency in the network and systems. As the piston will be firing whenever a change is reported in the level of one of the lights, it also seems a bit redundant.

I would suggest it matters rather a lot.

Your piston is going to fire every time a change in level is reported by one of the four lights. Supposing e.g. Dimmer 1 changes level and the piston fires. If e.g. White Bulb 1 also changes level while the piston is executing it will fire a second instance but politely wait for ten seconds to let the first one try and finish (the actual webCoRE code suggests ‘up to ten seconds’ but I’ve never seen the wait not be ten seconds). So when the second instance gets going again it will have been ten seconds since anything changed and so the attributes will not be captured.

If e.g. Dimmer 2 changes level during the ten second wait, a third instance will fire. If the first one is still running, it will also be delayed. If it has now finished the third instance will run immediately. This time it should capture the attributes.

Anyway, the bottom line is that if you have semaphore waits flitting around, your condition is liable to fail. Even without the semaphores, three seconds doesn’t give you much wriggle room for latency in the system.

Assuming you just want to capture the ‘scene’ when any change has been made, rather than all four lights having been changed in a frantic period of activitiy, I would suggest just replacing ‘changed in the last 3 seconds’ with ‘changes’ and letting webCoRE sort things out for you. It’ll get there in the end.

If you did want to to test for all four lights having been changed in the last three seconds, then a plan B would be needed. However I can’t immediately think of a reliable plan B.


#3

Thanks for replying! :slight_smile:

I testet several approaches. None was truly stable. I ended up making a virtual switch called “Capture Scene” which I can toggle in both pistons and when setting scenes in the ST app. In the piston, it captures the scene with a 5 second buffer (for any delay in the system). This works like a charm.

Downside: Does not capture if any single lights are adjusted directly.