State of lightswitch (MQTT) not preserved after restart

Configuration
,
1

Hi all

I’m out of options and will be very pleased of you can take a look into my challenge. I have a door sensor (on/off) inserted in my wall to switch all the HUE lights in the living room. Just to consolidate everything to one switch for the whole room.

The issue is when HA restarts MQTT resets the state of the door sensor. A few days ago I enabled it as a toggle, now as a separate on and off automation. Nothing helps, with the toggle the light just switches to the other state. And with the on/off automation the light always goes to the on state.

What I have did:
-played around with persistent state caching in MQTT, no result.
-tried to switch via a boolean in between the switch and the HUE bulbs, I hoped it preserve the state in the boolean. Did not work because the MQTT output simply switches to on after a reboot…

What I want is that HA remembers the state before rebooting, and restore the state afterwards. Sometimes its as simple as getting the right search syntax from a forum member. As none native speaker I can’s find any options.

After a reboot:

image
image924×76 7.13 KB

On:

alias: Woonkamer muurschakelaar licht aan
description: ""
trigger:
  - type: opened
    platform: device
    device_id: 5b5f68ebdc50a349f28d59fe7d83e531
    entity_id: f092e0031ebb174cef58f8d6526959f3
    domain: binary_sensor
condition: []
action:
  - service: input_boolean.turn_on
    data: {}
    target:
      entity_id: input_boolean.woonkamer_override
mode: single

Off:

alias: Woonkamer muurschakelaar licht uit
description: ""
trigger:
  - type: not_opened
    platform: device
    device_id: 5b5f68ebdc50a349f28d59fe7d83e531
    entity_id: binary_sensor.woonkamer_schakelaar_contact
    domain: binary_sensor
condition: []
action:
  - service: input_boolean.turn_off
    data: {}
    target:
      entity_id: input_boolean.woonkamer_override
mode: single
2

When you say “persistent state caching in MQTT” do you mean using the retain flag? This would be the normal way of handling MQTT sensors being unknown at startup.

3

Hi Michael, yes indeed I have played with the retain flag. But somehow the door (light) sensor always “flips” when got started.

4

The following single automation detects when the binary_sensor’s state changes from on → off and from off → on then sets the input_boolean to match the binary_sensor’s new state. It ignores all other state-changes like from unavailable/unknown → on/off (which might occur on startup).

alias: Woonkamer muurschakelaar licht aan uit
trigger:
  - platform: state
    entity_id: binary_sensor.woonkamer_schakelaar_contact
    from: 
      - 'off'
      - 'on'
    to: 
      - 'on' 
      - 'off'
condition: []
action:
  - service: 'input_boolean.turn_{{ trigger.to_state.state }}'
    target:
      entity_id: input_boolean.woonkamer_override
mode: single
5

@123
It seems that it fixes my problem many many many thanks, will test it once again tonight. This makes my family very happy, no more light flickering when dad is rebooting.

Another question you might have an answer to, same topic: state after reboot. I have a paging decoder which decodes messages by air. They are transmitted from my Pi to HA via MQTT or a Longlived token. The thing is when I reboot HA all these sensors have lost their previous state, and displaying as unknown. Which could take weeks before a new paging message arrives.

Could I fix that, so that the last state is preserved before a reboot?

View of missing sensors:

image
image1402×350 25 KB

Full sensor detail:

image
image1488×1027 79.3 KB

6

You’re welcome!

Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.

For more information about the Solution tag, refer to guideline 21 in the FAQ.

It needs to publish its payload as a retained message.

Because they weren’t published as retained messages. The broker doesn’t keep a copy of the topic’s payload. So when a client, like Home Assistant, disconnects from the broker and then reconnects and subscribes to the topic, the broker has no stored payload to give to the client. The client will only get the next payload that is published.

1 Like