Support Homeassistant Restart

[TheQue42]

First off, thanks for creating this software!

One thing that would help me a bit, if it would support the mqtt messages sent during startup of the platform.

https://www.home-assistant.io/docs/mqtt/birth_will/

I've got issues with my bluetooth devices, so I am keeping quite detailed track of the state of the airthing entity sensors, and on restart of homeassistant, they go unavailable for 15-20 min (depending on refresh interval).

I would be nice if the utility would simply detect that HA has restarted, and instantly publish its latest values.

[mjmccans]

Your suggestion is a good one and I have been thinking about how to best implement it. Monitoring the Home Assistant birth and last will messages in MQTT is one way, but that could be challenging because I do not currently store the values of the last sensor values received. However, while I am not an MQTT expert by any stretch I think using retained MQTT messages would achieve the same goal. This would be easy to implement, but I believe it would be best to delete those retained messages when the addon stops. I currently do not have any "cleanup" code so I would have to have a trigger for when the addon stops. Let me think about this a bit more and see what I can do.

[mjmccans]

I have released a new version that includes a new "retain" configuration option that may do the trick for you. It defaults to 'false', but please try setting it to true and see if it works for you. If you ever want to clear the retained values you can set it back to false and the addon will send the required messages to clear the value.

[TheQue42]

Strange I didnt get a notification of these messages, or the release, but I'll try to give it a test during the weekend!

[TheQue42]

Ok, time wasnt really on my side the past few days/weeks (baby and 3yr old at home :-) ), so I never got around to testing this. However, there is another embarrasing issue, and that is that since I am not using hassio, I am actually using the repo https://github.com/mjmccans/airthings-mqtt-ha, and thats were I really should have created this ticket.
Any chance of "backporting" the logic to that repo?

Sorry about the confusion :-/

[mjmccans]

No issue at all, and I totally understand (I have three parasites / children of my own). This has actually been the kick in the pants I needed to reconcile the changes I have made to the addon with the non-addon repository. When you have a chance it would be great if you could check out the "dev" branch of the airthings-mqtt-ha repository. I have pulled across the changes made to the addon. Note that the config file format has changed, and is now in json instead of toml. If you pull the "dev" repository and run the script it should suggest a configuration file, and you can try changing the "mqtt_retain" value to "true". Please let me know if it works for you, or if you have any other issues. Thanks, and good luck with the kids!

[TheQue42]

Sorry for the non-existent feedback, but...you know...time..:-/ Anyway, I did try the concept with the retain flag, but I havent been able to thoroughly analyse the behavior in error scenarios. At least not enough to give quality feedback.
I do wonder though, since I had issues with my device once the battery got low, if there can be issues with the retain, if the container isnt able to acquire values from the device? What will be published then?

[mjmccans]

No problem at all. If the addon cannot get values from the device it should not publish anything to the mqtt broker, meaning that the retained value would continue to be the value shown in Home Assistant. However, please let me know if you do have a chance to do any testing and let me know if it works. Thank you.

[TheQue42]

But, thats just it, I dont want it to show the old value, since it makes it impossible to know that the service isn't able to fetch accurate values. If the code isnt able to get a valid value, I would personally want it to publish a bad value (or unavailable or similar so (maybe) it doesnt cause issues with statistics), so that I know that something is actually wrong.

[TheQue42]

Just as a good (or bad) example today. I've been having bluetooth issues again, ever since I updated to HA 2008.x and tried the updated bluetooth support (as well as updating to your 1.2 release that uses bleak and dbus).

But...I havent notices the issue. My radon counter has been looking fine at '1xx Bq/m3'.... until I noticed today, that this is because the airthings container isnt able to get any values, but the retain causes the old value to be displayed, instead of indicating an error.

I also realized something strange right now. The logs say:

[2022-08-08 09:27:55] INFO: Waiting 900 seconds.
[2022-08-08 09:44:35] INFO: Not able to connect to a4:da:32:28:bd:71
[2022-08-08 09:44:35] ERROR: Error getting sensor data for 'a4:da:32:28:bd:71': Could not connect to a4:da:32:28:bd:71
Traceback (most recent call last):
  File "/code/airthings.py", line 345, in get_sensor_data
    raise Exception("Could not connect to {}".format(mac))
Exception: Could not connect to a4:da:32:28:bd:71
[2022-08-08 09:44:35] INFO: Collecting sensor value messages...
[2022-08-08 09:44:35] INFO: Sending messages to mqtt broker...
[2022-08-08 09:44:35] INFO: Done sending messages to mqtt broker.
[2022-08-08 09:44:35] INFO: Waiting 900 seconds.

But I dont ever seem to enter the else branch of the code, where:

_LOGGER.error("\033[31mNo sensor values collected. and the application would exit.

[mjmccans]

I think I misunderstood your original ask and I see why the retain flag does not work well for you given the connectivity issues you have with your devices. Perhaps the best thing for your use case would be to set up an automation triggered on the homeassistant event "start" and then use the hassio.addon_restart service to restart the addon. If that works it would cause the addon to restart when Home Assistant restarts, thus causing the addon to try to get new values.

[TheQue42]

Unfortunately, I am not running hassio, but HA Container (I mixed up the repos as mentioned above).
But regardless of the HA restart issue, surely it cant be good that it cant be properly detected that the application isn't receiving good values?
A container health-check would be nice :-) (Something like https://howchoo.com/devops/how-to-add-a-health-check-to-your-docker-container)

[mjmccans]

I totally forgot that you were not using the addon so I agree that my last suggestion would not work. I could add a health check to the docker container, but that would not help those not using a docker setup and is not really what docker health checks are for (in this instance the container is still working fine, it just cannot connect to a device). Would adding a new sensor value, such as boolean "failed" or "dead", that changes when there have been a certain number of failures to contact a device or a certain amount of time has gone by since the last successful connection? I was thinking that could be more helpful because it would work for everyone, and you could run automations or display warning (such as a "stale values" display) in your Home Assistant dashboard. Let me know what you think. If that would work I can look into implementing it, but I may not be able to do it right away given competing priorities. In the meantime you could also track one of the sensors that changes frequently, like temperature or co2, and issue a warning if that value does not change for a while.

[TheQue42]

A new sensor indicating "staleness" would be superb! :-) Then I can avoid my own hacks with Flask RESTFul endpoints for running various CLI commands and checking things :-)

Related to the issue about checking a value that changes often, I have wondered about that, that using last_updated is not really useful for these mqtt sensors. Is that a limitation of the mqtt sensors themselves in HA? At least the once created by the auto-discovery mechanism?

Since if I create a "manual" mqtt sensor, there's the "force_update" that makes the last_updated work properly even if the value hasn't changed.