Stopping the docker container in Hass.io doesn't put sensors as unavailable

[RomRider]

Describe the bug
Shutting down the docker container (Hass.io) doesn't put monitored Classic Bluetooth devices as unavailable (maybe others too).
Note: I only have 1 instance.

To reproduce

1. Install the addon
2. Configure some classic BT devices
3. verify that they appear in HA's dev-state
4. stop the container

Relevant logs
N/A

Relevant configuration
Paste the relevant parts of your configuration below.

global:
  instanceName: Office
  integrations:
    - homeAssistant
    - bluetoothClassic
homeAssistant:
  mqttUrl: 'mqtts://xxxxxxxx'
  mqttOptions:
    username: xxxxxxxx
    password: xxxxxxxx
bluetoothClassic:
  hciDeviceId: 0
  minRssi: -20
  interval: 6
  addresses:
    - 'xx:xx:xx:xx:xx:xx'

Expected behavior
Putting sensors as unavailable when the last instance is down or when there where no updates for some time (ideally configurable).

This would help secure the solution a bit, especially if the app crashes.

Environment

• room-assistant version: [e.g. 2.0.0] 2.4.0
• installation type: [e.g. NodeJS, Docker, Hass.io]: Hass.io
• hardware: [e.g. Raspberry Pi Zero W, NUC]: NUC
• OS: [e.g. Linux, Windows, macOS]: Linux

Additional context
Add any other context about the problem here.

[mKeRix]

Distributed entities - such as Bluetooth Classic or BLE sensors - will not be marked as unavailable when shutting down by design. Since these entities are controlled from multiple instances in the room-assistant cluster model we can never be really sure if it should be unavailable. It could be that there is another instance writing to the same topics, but the instance going down wasn't aware of it because the cluster connection didn't happen for example. In this case the shutdown would trigger the entity to go unavailable and block updates from the other node.

Adding this feature would only make sense as an additional option imo, which can then be used people in single instance setups like yours or when the cluster functionality has been confirmed to be stable. Would that be enough from your point of view?

[paulrbeers]

As a follow up to mKeRix comment: I'm not even running Room-Assistant in my HA instance. I technically have it installed, but it isn't running. All the info is just passed to my MQTT server running on HA.

[RomRider]

Thanks @mKeRix.
I'm planning to add more raspi zero but I'm more in a test phase thus my point.

I've checked the mqtt_room integration and it seems that it used to give the option to put as away if no update was received after a certain delay. I understand this would require an integration on HA's side but it felt safer.
Right now I've built some stuff that checks when the last update was and notify me if it was too far back in time but I don't feel this is ideal.
It would also be possible to build a sensor template based on the one created by room assistant.

Actually there are some options but I'm wondering what is your view on that?
Simple use case:

• I'm home
• I stop mqtt (for the simulation)
• i leave
• I'm still considered as being home forever

[mKeRix]

Do you think that utilizing the expire_after attribute of MQTT sensors in Home Assistant would also be an ok solution for you? If we set that from the room-assistant side and let the leader re-post the states as a heartbeat every x seconds we could ensure that the distributed sensors also go unavailable if room-assistant is turned off, room-assistant crashes or MQTT goes down.

[RomRider]

I think that would be the best solution :)

[SeLLeRoNe]

I would have a suggestion, not sure if it was already suggested

Each node send a LWT message to room-assistant/STATUS every 1 (or 5( minutes.
As a node goes down, it should go "Unavailable" for max 1 (or 5) minutes until another live node send a new message.

Would that work in your opinion or just hammer the MQTT Server for nothing?
A

[mKeRix]

This is now implemented as such:

• local entities (e.g. cluster leader and size sensors that all instances register) are marked as unavailable if the specific instance goes down
• distributed entities (e.g. BLE and BT Classic sensors) are marked as unavailable when the leader becomes unavailable
• distributed, state-unlocked entities (e.g. Xiaomi sensors) don't have availability support and will stay available at all times

This behavior also applies in situations where the application doesn't exit gracefully or loses the MQTT connection using the will message feature. It should be a great improvement over the previous implementation. I tried out various approaches in multiple iterations and this was the best I could come up with for now - but if you have any further improvement ideas for the future don't hesitate with commenting here or opening a new issue. :)

[github-actions]

🎉 This issue has been resolved in version 2.18.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀