light devices status "unknowing" after reboot

[Smandurlo]

The problem

After rebooting HA, some light devices are in "unknown" status.

These ones are mqtt lights and, oddly, they are created with the same exactly options manually in yaml (different topic of course), but 1 out of 3 has the correct status on reboot.

  - platform: mqtt
    name: "Bagno"
    command_topic: "cmnd/bagno/power"
    state_topic: "stat/bagno/POWER"
    qos: 2
    payload_on: "ON"
    payload_off: "OFF"
    availability_topic: "tele/bagno/LWT"
    payload_available: "Online"
    payload_not_available: "Offline"

  - platform: mqtt
    name: "Corridoio"
    command_topic: "cmnd/corridoio/power"
    state_topic: "stat/corridoio/POWER"
    qos: 2
    payload_on: "ON"
    payload_off: "OFF"
    availability_topic: "tele/corridoio/LWT"
    payload_available: "Online"
    payload_not_available: "Offline"

  - platform: mqtt
    name: "Letto"
    command_topic: "cmnd/letto/power"
    state_topic: "stat/letto/POWER"
    qos: 2
    payload_on: "ON"
    payload_off: "OFF"
    availability_topic: "tele/letto/LWT"
    payload_available: "Online"
    payload_not_available: "Offline"

these ones are created with the xiaomi gateway integration. I already opened an issue, but I didn't get any reply: https://github.com/home-assistant/core/issues/65807#issuecomment-1031261575 maybe they are connecter

What version of Home Assistant Core has the issue?

2022.3.0

What was the last working version of Home Assistant Core?

2022.2.9

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

light mqtt

Link to integration documentation on our website

https://www.home-assistant.io/integrations/light.mqtt/

Diagnostics information

no diagnostic

Example YAML snippet

No response

Anything in the logs that might be useful for us?

no warnings/errors in the log

Additional information

No response

[probot-home-assistant[bot]]

mqtt documentation mqtt source _{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @emontnemery, mind taking a look at this issue as it has been labeled with an integration (mqtt) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

[Smandurlo]

Retain is properly configured on every device in the same way.

[Zoogara]

If this is intended (i.e. not a bug) then is there a chance the mqqt integration could have an "assumed_state:" feature added? That would allow the user to choose the state rather than always assuming "unknown".

This would be also handy for binary sensors that are also defaulting to "unknown" since 2022.2

[mcburnside]

I agree with @Zoogara on an assumed state feature. I don't want to spam MQTT traffic and poll or publish states constantly just because I may reboot my HA server once in a while.

[kpfleming]

I have about a dozen MQTT 'light' devices, none of them have ever had 'retain' set on them, with 2022.3 (and 2022.3.1) some of them show up with this 'unknown' state and the others don't. I've verified that the data being passed is identical for the working and non-working ones (except for name/address differences of course).

[kpfleming]

Correction: all of my MQTT devices do have 'retain' set for their state messages.

[DarylStark]

Same issue here with all light entries in MQTT coming from the Tasmota integration. The switch entries (setOption30 0) work fine, the light entries are all unavailable since upgrading to 2022.3

[Nightenom]

Happening for all two of my MQTT (input) number controls. However, graphs show correct values, making sense since they receive last states from a broker-send-retain-on-subscribe broadcast. The problem is then that I cannot set the values because the frontend is not accepting user input.

number:
  - platform: mqtt
    min: 35
    max: 80
    name: "CH setpoint"
    retain: true
    command_topic: "/opentherm/chsetpoint"
    step: 0.01
    unique_id: "ot.chsetpoint"
    unit_of_measurement: "°C"

[emontnemery]

After a restart, the Home Assistant MQTT integration relies on getting the state in an MQTT topic. That can be achieved either by the devices listening to Home Assistant's "birth" message, and sending a state update when that is received (zigbee2mqtt works like this, for example), or by the devices publishing their messages with the retain flag set.

If you get state unknown after a restart, and you're sure the devices to send a state update or retain their state messages, please attach diagnostic information from the MQTT config entry.

is there a chance the mqqt integration could have an "assumed_state:" feature added

That would be really confusing IMHO since there's a very big overlap with the retain flag feature in the MQTT protocol.

[devlaminckw]

Hi, I have the same issue. My I was on 2021.12 or something, just upgraded homeassistant and now all my light switches are broken. They are sonoffs with Tasmota. I've used setoption19 1 to enable the autodiscovery and then setoption30 1 so they would appear as a light in HA. Now when i use setoption30 0 i see the device as a switch. 19:00:47 CMD: setoption30 1 19:00:47 MQT: bureau_light/stat/RESULT = {"SetOption30":"ON"} 19:00:48 MQT: homeassistant/light/E074D9_LI_1/config = {"name":"Bureau","stat_t":"bureau_light/tele/STATE","avty_t":"bureau_light/tele/LWT","pl_avail":"Online","pl_not_avail":"Offline","cmd_t":"bureau_light/cmnd/POWER","val_tpl":"{{value_json.POWER}}","pl_off":"OFF","pl_on":"ON","uniq_id":"E074D9_LI_1","dev":{"ids":["E074D9"]}} (retained) 19:00:48 MQT: homeassistant/sensor/E074D9_status/config = {"name":"Bureau status","stat_t":"bureau_light/tele/HASS_STATE","avty_t":"bureau_light/tele/LWT","pl_avail":"Online","pl_not_avail":"Offline","json_attr_t":"bureau_light/tele/HASS_STATE","unit_of_meas":"%","val_tpl":"{{value_json['RSSI']}}","ic":"mdi:information-outline","uniq_id":"E074D9_status","dev":{"ids":["E074D9"],"name":"Bureau","mdl":"Sonoff Basic","sw":"9.1.0(tasmota)","mf":"Tasmota"}} (retained) 19:01:03 CMD: setoption30 0 19:01:03 MQT: bureau_light/stat/RESULT = {"SetOption30":"OFF"} 19:01:04 MQT: homeassistant/switch/E074D9_RL_1/config = {"name":"Bureau","stat_t":"bureau_light/tele/STATE","avty_t":"bureau_light/tele/LWT","pl_avail":"Online","pl_not_avail":"Offline","cmd_t":"bureau_light/cmnd/POWER","val_tpl":"{{value_json.POWER}}","pl_off":"OFF","pl_on":"ON","uniq_id":"E074D9_RL_1","dev":{"ids":["E074D9"]}} (retained) 19:01:04 MQT: homeassistant/sensor/E074D9_status/config = {"name":"Bureau status","stat_t":"bureau_light/tele/HASS_STATE","avty_t":"bureau_light/tele/LWT","pl_avail":"Online","pl_not_avail":"Offline","json_attr_t":"bureau_light/tele/HASS_STATE","unit_of_meas":"%","val_tpl":"{{value_json['RSSI']}}","ic":"mdi:information-outline","uniq_id":"E074D9_status","dev":{"ids":["E074D9"],"name":"Bureau","mdl":"Sonoff Basic","sw":"9.1.0(tasmota)","mf":"Tasmota"}} (retained)

If you need more information let me know, now sure what you mean with the diagnostic info from mqtt entry.

[devlaminckw]

Hi again. I just updated all my devices to Tasmota 11.0.0 and new the lights are all working again.

[DonKracho]

Same issue for me. I use my own ESP8266 based implementation for 15 433Mhz RF sockets. When homeassistant (core-2022.4.7) sends the MQTT Birth message my device publishes discovery messages for each device followed by the state message. Therefore there is no need to set a retain flag. Being in unknown state happens randomly for some of the devices resulting in the two flash symbols instead of one slider symbol. Once switching it changes into the slider symbol. The switching can be done externaly, e.g. via the web interface of my esp8266 device.

To me it looks like a timing issue in homassistant missing or not being ready to receive the switch state messages if they are send to early.

If I do delay the state updates by a few seconds (just tried 5s, may be far to much) everything is fine.

[DonKracho]

I noticed that delaying the ON/OFF state did not help reliable with this issue (now using core 2022.5.4). Sometimes after restarting the core it still comes up with the dual flash symbols. Because I have the source of my DIY MQTT switches I decided to update them to support the availability topic and reported them to be online directly after a discovery loop. That did fix the issue.

[kpfleming]

All of my devices are integrated via Insteon-MQTT, and have full availability topic support too, and yet some of them are still showing the dual-lightning symbols. Very strange.

[samuelbenzaquen]

Any ideas on how to solve this yet for Tasmota?

[rubin110]

I'm seeing this issue with lights from Zigbee2MQTT. After initial join of a new light, or after reboot, HA doesn't know about state until I flip the on switch. The state however is correctly reflected in Zigbee2MQTT.

Home Assistant Core 2022.6.6

[rhoddan]

same problem here. Tested qos and retain setting with no luck

• platform: mqtt
  state_topic: "sprinkler/cmd" command_topic: "sprinkler/cmd" name: sprinkler unique_id: sprinkler payload_on: "start" payload_off: "stop"

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[dnaphreak]

I noticed that delaying the ON/OFF state did not help reliable with this issue (now using core 2022.5.4). Sometimes after restarting the core it still comes up with the dual flash symbols. Because I have the source of my DIY MQTT switches I decided to update them to support the availability topic and reported them to be online directly after a discovery loop. That did fix the issue.

@DonKracho Can you detail the discovery loop you are referencing in your fix? I have MQTT devices similar to yours as well as zigbee2mqtt and tasmota devices that all have this same issue.

Currently running 2022.10.4

[danbayliss]

For Tasmota open up the console and type PowerRetain 1. This worked for me