Issue with light brightness jumping up on motion


1) Give a description of the problem

Got a motion light (philips hue iris) in my toilet with set level. The brightness turns up if I stay in the toilet for a longer time.

2) What is the expected behaviour?

During nighttime the “ambient light” should turn on and be set to level 10.

3) What is happening/not happening?

If I stay in the toilet a bit longer the ambient light brightness turns up a bit? Also I’m sure whether the initial 10% is even set (see the logs).

4) Post a Green Snapshot of the pistonimage

5) Attach logs after turning logging level to Full

12/28/2020, 7:29:50 AM +276ms
+1ms ╔Received event [Toilet Motion sensor].motion = active with a delay of 105ms
+75ms ║RunTime Analysis CS > 18ms > PS > 5ms > PE > 52ms > CE
+78ms ║Runtime (39339 bytes) successfully initialized in 5ms (v0.3.110.20191009) (75ms)
+78ms ║╔Execution stage started
+94ms ║║Condition #20 evaluated false (11ms)
+95ms ║║Condition group #1 evaluated false (state did not change) (12ms)
+100ms ║║Comparison (enum) active changes_to (string) active = true (0ms)
+101ms ║║Cancelling condition #6’s schedules…
+102ms ║║Condition #6 evaluated true (5ms)
+103ms ║║Cancelling condition #5’s schedules…
+104ms ║║Condition group #5 evaluated true (state changed) (6ms)
+114ms ║║Comparison (time) 26990382 is_between (time) 82800000 … (time) 27000000 = true (7ms)
+116ms ║║Time restriction check passed
+117ms ║║Condition #8 evaluated true (11ms)
+118ms ║║Condition group #7 evaluated true (state did not change) (13ms)
+120ms ║║Cancelling statement #11’s schedules…
+128ms ║║Skipped execution of physical command [Toilet Ambient light].on([]) because it would make no change to the device. (4ms)
+129ms ║║Executed [Toilet Ambient light].on (6ms)
+138ms ║║Executed physical command [Toilet Ambient light].setColor([[hex: #9932CC, hue:78, saturation:61, level:50]]) (6ms)
+139ms ║║Executed [Toilet Ambient light].setColor (8ms)
+151ms ║║Skipped execution of physical command [Toilet Ambient light].setLevel([10]) because it would make no change to the device. (9ms)
+152ms ║║Executed [Toilet Ambient light].setLevel (10ms)
+159ms ║║Comparison (enum) active stays (string) inactive = false (1ms)
+160ms ║║Cancelling any timed trigger schedules for condition 16
+161ms ║║Cancelling statement #16’s schedules…
+162ms ║║Condition #16 evaluated false (7ms)
+163ms ║║Condition group #15 evaluated false (state did not change) (9ms)
+165ms ║╚Execution stage complete. (87ms)
+166ms ╚Event processed successfully (166ms)


The exact detail will vary depending on how webCoRE and the particular device handler are written, but I believe the gist of what you experience is as follows.

When you first enter the room, motion will be detected, the light will be switched on and the colour of the light will be set to Dark Orchid, which includes setting the level to 50%. This is immediately followed by the level being set to 10%. So the light will come on and immediately change down to 10% so you probably wouldn’t think anything of the level change.

The chances are that motion will go inactive for a short period while the room is occupied and then go to active again. By default, pistons use ‘command optimisation’ which means they don’t send unnecessary commands. The switch is already on so it doesn’t need switching on again. The piston will set the colour again (perhaps because the earlier level changed means it doesn’t seem to be set to Dark Orchid any more) and that sets the level up to 50%, which is the visible change of level. The level attribute is still set to 10% and so it doesn’t need setting back to 10%. So the level will stay at 50%. That is what the logs show.

I’ll have to stay a bit vague about the specifics as I haven’t worked with coloured lights. My understanding is that are multiple ways of handling colour, and no real standard way that is followed. So webCoRE might have one idea, the device handler another, and the actual bulb another one.

It might be that you can simply disable command optimisation in the piston settings. However that might result in a visible pulse of brighter light if motion gets detected.


Thanks! This clarifies a lot; realizing now that setting color like that will also set the brightness. So I believe that the issue could then sorted by setting the color and brightness directly with hue, saturation and level.