Light goes out when issued "decrease" command

[elektrinis]

So I have a script that is running a while loop with one second delay (so once per second), measuring room illuminance and trying to keep it at range of 90-100lux by adjusting light brightness up and down. It works rather well, but occasionally, like once per hour, the light suddenly goes out totally and then ramps up slowly as my script is doing its job.

Illuminance meter is a ceiling-mounted zigbee device. It’s mains powered (as part of mmWave detector) and works well, updates frequently enough.

Dimmer is of unknown brand (don’t remember, installed deep, can’t check), also on zigbee network.

I have checked traces and can’t see anything wrong there, as it’s bit useless in a while loop. I have also checked illuminance data and it only shows what’s actually happening, no issues there. Even if it showed a sudden jump in illuminance, the script would ramp down slowly, not suddenly.

I have included the part of script below, but I’m quite sure it’s okay.
Another weird part is that there is a “turned on” event at timestamp 9:29, but no turned off event just prior. From logbook it looks as if the light was off all the time.

I want to ask if anyone has experienced this and what was the issue? Perhaps the dimmer itself is interpreting something wrong?

              - repeat:
                  while: []
                  sequence:
                    - if:
                        - condition: numeric_state
                          entity_id: sensor.sensor_radar_livingtoom_illuminance
                          below: 90
                      then:
                        - device_id: c33c8251d4a871b8e613b22f8a8a9d21
                          domain: light
                          entity_id: light.lightdimmer_livingroom_ceiling
                          type: brightness_increase
                      else:
                        - if:
                            - condition: numeric_state
                              entity_id: sensor.sensor_radar_livingtoom_illuminance
                              above: 100
                          then:
                            - device_id: c33c8251d4a871b8e613b22f8a8a9d21
                              domain: light
                              entity_id: light.lightdimmer_livingroom_ceiling
                              type: brightness_decrease
                    - delay:
                        hours: 0
                        minutes: 0
                        seconds: 1
                        milliseconds: 0

[umrath (Thoralf Will)]

I’m not sure if this is related, but I have a similar situation that might explain what is going on:

When you issue the “decrease” command, it seems to not check whether the lamp is already on the lowest value and could potentially simply switch it off this way. That could trigger the effect that you described.

[elektrinis]

Yes I know what you mean.
But in my case the lamp is at almost full brightness, and then it suddenly goes off.

[tom_l]

@elektrinis

              - repeat:
                  while: []

[elektrinis]

demonstrating your smarts when, even if true, off topic.

[tom_l]

So you don’t want to know why a loop like that is a very bad idea?

And how to do it state driven instead?

[elektrinis]

I know and I don’t want to hear it here. Keep it on topic please.

[petro]

Switch.livingroom changed state and triggered an automation light living room. So how does switch.livingroom relate to this automation? Is switch.livingroom attached to your light in any way via any automation?

[elektrinis]

Good question, just noticed it.
I use switch state as a trigger. However, what’s weird, is that the switch was not operated for two hours before this. It looks like the script was just running in the loop for two hours until the light switched off due to some reason (and this was not registered), and then ramped up as it should.

Another weird thing I have noticed before is that the dimmer is reporting state off, while the light is actually on. Sometimes.

[petro]

it’s exactly 1 hour and 50 minutes. I.e. 110 minutes. Down to the second. Do you have an automation that’s triggered by switch.livingroom that has significant delays like this?

[RosemaryOrchard]

Is there a reason why you wouldn’t just use two numeric state triggers for “above 100” and “below 90”? I’d be worried that I was going to crash any machine by running a loop forever.

[elektrinis]

@petro

it’s exactly 1 hour and 50 minutes. I.e. 110 minutes. Down to the second. Do you have an automation that’s triggered by switch.livingroom that has significant delays like this?

Good catch, but looks like coincidence, as I don’t have 110 minutes anywhere, and I could not find another incident like this.

Here is some data of another occurrence today. The switch has not been touched since morning, and I see that the light has a status “turned off” at 15:01:14, while it actually did not happen, as seen from illuminance sensor. I actually don’t have a way to switch it off like that, it must be the dimmer itself sending this? And then, a couple minutes later it actually switched off and was ramped back up by the script. Also there was no change in state of occupancy_livingroom at 15:03:25, it actually happened at 14:57:02, when the script/loop was started.
Something fishy going on.

@RosemaryOrchard

Is there a reason why you wouldn’t just use two numeric state triggers for “above 100” and “below 90”? I’d be worried that I was going to crash any machine by running a loop forever.

I agree, will re-do it later. Just testing now…
While running such loop is risky, it should not crash the system if there are no memory leaks or other bugs. In my case, as seen on Traces, it’s running fine without dropping out. It just looks like something is interfering with it from outside.

[petro]

@elektrinis

It just looks like something is interfering with it from outside.

@ 15:01 something outside HA turned off the light. That’s what you have to figure out. Because it has no context, that means something outside HA or something physical adjusted the state of the switch (like a person). If you’re using z2m, i’d take a look at the topics and see if you see a state change there.

[elektrinis]

No it’s zha.
The dimmer does not have a physical interface, so I’m not sure why this is happening.

As I said, there were many instanced when HA would show incorrect status - light off, while it is actually on.

Perhaps associated: I have similar issues with two more devices:

1. xiaomi door sensor. It would respond to “identify” command by blinking light, but sensor status was not getting through. Fixed it by re-pairing.
2. wall switch. I could control it on/ff via HA, but it would not report the change of on/off status once switched physically. Fixed it by powering down.

Looks like I am having issues with my zigbee network? Is this a known issue?
The coordinator is a sonoff stick, and a total of 33 devices.

[petro]

@elektrinis

Looks like I am having issues with my zigbee network? Is this a known issue?

It could simply be your devices themselves. I’m not versed in zigbee well enough to support any further. But I do know that it’ll be either your coordinator or the device itself that is the problem.