search

marthoc / GarHAge

a Home-Automation-friendly ESP8266-based MQTT Garage Door Controller
MIT License
170 stars 42 forks source link

Bug: Door status is lost if Home Assistant restarts #1

Closed marthoc closed 6 years ago

marthoc commented 6 years ago

This should be taken care of by the client.publish() call in reconnect(), but when using HA's embedded broker, a restart of HA loses the door status. To do:

  1. Investigate whether this also happens with Mosquitto.
  2. Investigate whether status messages really are being published with the "retain" flag.
  3. Investigate why the client.publish() call in reconnect() doesn't update the door status in HA.
  4. Figure out a suitable workaround if this only happens when using HA's embedded broker (delay before publishing on connect/reconnect; occasionally republish status message; etc.).
marthoc commented 6 years ago

I am sure that this issue is related to this HASS issue: https://github.com/home-assistant/home-assistant/issues/8589.

In the meantime I am trying to figure out a workaround.

marthoc commented 6 years ago

A few more points:

  1. This also happens when using Mosquitto.
  2. Messages on the #/status topics are being published with the "retain" flag set.

A possible workaround is to use Home Assistant's mqtt birth_message functionality: see https://home-assistant.io/docs/mqtt/birth_will/.

This would require subscribing to the birth_message topic, and adding an elseif statement to the message callback that would listen for the birth_message topic and payload and publish status updates for both doors when HASS publishes an "online" payload to the birth_message topic.

It would also therefore require users to add the birth_message lines to configuration.yaml.

I will be pushing an update to the dev branch that does just this, along with the required configuration.yaml lines, and testing shortly.

marthoc commented 6 years ago

Workaround added to Release 1.0.1 to address this issue. Leaving issue open to properly address this in the future if the bug is fixed upstream.

marthoc commented 6 years ago

Turns out that the workaround added to release 1.0.1 didn't adequately address the problem on startup - most of the time, the Cover state was still showing "unknown" even though GarHAge was receiving the birth_message and publishing a status update in response.

I've added new documentation and released v1.0.1a with a new workaround that seems to work much better (in fact, after many many restarts in testing, I've yet to have an incorrect state in HASS since implementing it).

See the documentation re HASS Automation as Workaround.