Changing light temperature through the day

[NReich]

1) Give a description
I’m trying to create a piston when I turn on any light(s) in my house it will change the light temperature and level of the light(s) that was turned on. If a light is already on it won’t change the color or level unless the variable is updated.

2) What is the expected behavior?
This piston works pretty well when one light is turned on at a time.

3) What is happening/not happening?
There are two problems: Frist, when I turn a group of lights most of the time there is a large delay for the last light (Usually a semaphore of 10 seconds). Second, when I turn on a group of lights sometimes a light won’t change to the @Hosue_Light_Temp or @House_Light_Brightness variable that is set.

I’m trying to write the code to be as fast as possible with little delay. I’m open to suggestions to improve this code or if there is a better way to write it.

4) Post a Green Snapshot of the piston

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

+0ms ╔Received event [RGB Bulb 3].switch = on with a delay of 94ms
+10248ms ║Piston waited at a semaphore for 10063ms
+10250ms ║Runtime (45798 bytes) successfully initialized in 10119ms (v0.2.101.20171227) (10249ms)
+10251ms ║╔Execution stage started
+10305ms ║╚Execution stage complete. (54ms)
+10306ms ╚Event processed successfully (10306ms)
1/12/2018, 1:38:34 PM +413ms
+2ms ╔Received event [RGB Bulb 2].switch = on with a delay of 164ms
+251ms ║Runtime (45731 bytes) successfully initialized in 113ms (v0.2.101.20171227) (249ms)
+252ms ║╔Execution stage started
+353ms ║║Executed [RGB Bulb 2].setColorTemperature (30ms)
+371ms ║║Executed [RGB Bulb 2].setLevel (16ms)
+497ms ║╚Execution stage complete. (244ms)
+498ms ╚Event processed successfully (497ms)
1/12/2018, 1:38:33 PM +425ms
+2ms ╔Received event [RGB Bulb 1].switch = on with a delay of 179ms
+254ms ║Runtime (45741 bytes) successfully initialized in 104ms (v0.2.101.20171227) (252ms)
+255ms ║╔Execution stage started
+385ms ║║Executed [RGB Bulb 3].setColorTemperature (31ms)
+407ms ║║Executed [RGB Bulb 3].setLevel (20ms)
+491ms ║╚Execution stage complete. (236ms)
+492ms ╚Event processed successfully (492ms)`

[Mike1616]

For starters, look into what you can do with $currentEventDevice as opposed to the way you are looping through each light to see if it just turned on. That will probably streamline things a bit.

There’s also a way to save the “matching” devices to a variable and then affect all of them together without having to loop through them as you’re doing here.

I guess what I’m saying is that you can do this whole thing w/o using a FOR loop…and that will likely be much better.

So what I’d suggest is that you break the piston down into two “triggers” with the first one being that a light turned on and the second being if Temp or Brightness changes…unless you’re always changing both of those at the same time (in whatever makes them change). Because if you’re changing both then don’t check for both as doing so will cause the piston to run more times than is necessary.

Then for your first check just say:

If switch turns on
With $currentEventDevice
Set color and brigtness
End if

For your second say:

If color (or brightness) changes
Put matching devices with a switch ON into a device variable
set color and brightness on the device variable
End if

[whoops]

Did you ever solve the semaphore issue? I tried to follow the suggestion of the only reply in here, and still I see the same behaviour, which makes it essentially unusable.

[orangebucket]

Did you ever solve the semaphore issue?

If you consider the piston in this thread you can see a new instance will be executed every time one of the light switches changes state or one of the two globals changes value.

By default, if two or more of those things happen so close together that more than one piston instance would be running at once webCoRE will try to serialise execution so only one is actually active. That is what the semaphore wait is doing. The piston is waiting for up to ten seconds to try and let an existing piston finish. Why? Just in case the pistons interfere with other, for example by setting the same variable to different values.

If you look at what the piston is doing you will see that actually if multiple piston instances all ran at the same time they wouldn’t be interfering with each other at all. In that case you could safely ‘enable parallelism’ in the piston settings and they can just run without hindrance.

So if that applies to your piston then perhaps that would help you?