Change light status with an automation, while lamp is cut off from current

Configuration
1

I need help to automate my zigbee lights that are controlled by Sonoff ZBMini switches.

The ZBMini is a zigbee switch hooked to the already existing physical switch. It can toggle the lights by controlling the current. Since the ZBMini itself is always connected with HASS it is normally no problem, that my zigbee lights are not while cut off from current.

But in some cases were I want to automate the status of my light using “service: light.turn_on”, it is unreliable. I seems this caused by the fact that Home Assistant doesn’t know the correct status of the controlled lights. Switching a zigbee light of by the current, means the light can’t inform Home Assistant that it is off. If I correct the status of a light via the dashboard, everything works fine.

I already tried to solve this problem by automations, that turn zigbee lights off, after ZBMini cut off the current. But Home Assistant is still not changing the status of the lights. Here is one of my non-working automations:

alias: Doppel-Aus Sofa
description: ''
trigger:
  - platform: device
    type: turned_off
    device_id: 281e8a43d60f22a7fbd0d20b9527a149
    entity_id: light.sonoff_01minizb_bd57c124_on_off
    domain: light
condition: []
action:
  - type: turn_off
    device_id: 4d36eed262c9596c865310f69bf995f6
    entity_id: light.sofa_lampe_1_ff4aa9fe_level_on_off
    domain: light
mode: single

Since I can change the status of a light manually by the dashboard, it should be possible by an automation too. But how can I proceed?

Here are some more details:

  • Home Assistant 2021.12.3 running on an Intel NUC
  • Sonoff ZBBridge flashed with Tasmota 10.0.0.4
  • ZBMINI Switches with original firmware (no Tasmota)

I already searched for a solution in this forum. The best I could find was this: Sonoff-mini with a fixed state relay
But the solution there is for the Sonoff Mini (Wifi), not the Sonoff ZBMini (Zigbee). Even if it is possible to flash the ZBMini to Tasmota, it wouldn’t be possible OTA. Since my ZBMinis are already installed behind the physical switches, it would be complicated to flash them now.

2

The changes you make on the dashboard is assumed state changes and they last untill an update from the lights can be received, then the dashboard is overridden with the real values.
The device will always have the true values and therefore trumph the values in HA.

1 Like
3

Thank you, for clarifying this. Indeed, after testing today again I can no longer find a connection between the status on the dashboard and the problem. Maybe yesterday by coincidence the problem seemed to be solvable this way.

Just now my problem seems to be gone, as long as I change only one value at a time with “service: light.turn_on”. E.g. I cannot change the brightness and and the color with just one instance of “service: light.turn_on”.

Anyway: It still would be nice if I could automatically correct the status of my lights on the dashboard. Is it somehow possible?

4

I am still looking for a solution. I can’t believe that this problem can’t be solved. There are so many smart switches used these days, that can control the off-information more reliable, than the light itself. Is there really no way to correct a wrong on-status with an automation?

5

Hi Niwi,

Did you actually found any solution ? I’ve bought some zbmini’s as well and just smashed in the same issue… it ruins the all experience… my zbmini’s can’t even fetch device info:

image

Hope that some one came up with a solution… this is very not cool behavior :frowning:

Thanks

6

I think you are misunderstanding something here.

Devices without connection to HA can not be controlled by HA.
Once the devices connect to HA again they will be way past their initial startup and probably already have turned on and set the brightness, color and so on to what it’s built-in program says.

HA can first then control it and set it to what you wish, either manually or by automation.

HA can not send the values it has listed as the device’s current values, because HA has no way to know if those values were received before and someone changed them by other ways, like phone app or manual buttons.

When the device is unreachable by HA it assumes the state of the device, which means HA might show a device as turned on and it will also have sent that command to the device, but it has no way to know that the device never received it. It will keep that state until the device report something else or something else change that assumed state.

7

From my understanding this is not correct in all cases. There are some cases were it can be useful to change the state of an device even if it cannot be controlled at the moment by Home Assistant. If you have a smart light, and a smart switch that controls the power supply of this smart light, the light must be off when the switch is off.

However, for me this is no longer a topic of interest. I changed the way my ZBMinis work. They now longer control the power supply of my lights. My lights are on power all time now and the ZBMinis only send the state of the switch to Home Assistant. This way Home Assistant always knows the correct state and the lights work more reliable.

If anybody else wants to go this way: I don’t recommend to use ZHA for integrating IKEA lights this way. They might freeze after about a week. Instead I use a hue bridge for the lights and ZHA for the ZBMinis (and many other zigbee devices).

8

It is for HA.