miflora sensors reported as 'Unavailable'. #30275
Comments
|
Hey there @Danielhiversen, @ChristianKuehnel, mind taking a look at this issue as its been labeled with a integration ( |
|
I have this too, I've also noticed that this issue came about with 0.103. Some findings:
workaround in cli:
I'm facing this issue on Hassio 0.103.4 on a Raspberry Pi 3b. |
|
@ChristianKuehnel I was asking for help in the forum if there are intended ways of solving this no success until now. If everybody agrees I will implement the timeout in the miflora code (sry, I'm thinking this is the wrong place) |
|
@ChristianKuehnel: please have a look at: |
|
I'm facing the exact same issues ("Failed to start discovery: org.bluez.Error.InProgress") as @talondnb. In my Home Assistant container logs via portainer I see the following information; With the Flower Care app, I can still sync the data between the sensor and my phone so I'm positive the battery isn't dead. The sensor is running on firmware 3.2.1 (latest). Edit; Edit 2; |
|
Anyone running https://github.com/home-assistant/hassos/releases/tag/3.8 yet? |
|
I'm also getting this after updating to the latest docker image of Home Assistant v0.104.3 Edit: 24 hours later, and everything has started working on it's own...? 🤷♂️ |
|
The PR above will not fix any bad-connection-problems. It will only make it less worse because you can tell HA to report values even if they are 24 hours old. Before HA 0.103 you have seen the last value received forever, even if the battery was empty for days/weeks. You can check the following: Set scan_interval: 3600 so HA will only try to scan every hour and the BT dongle led will stop flashing. the BT dongle led will start flashing Compare the behavior with the battery inserted and the flower sensor next to the BT dongle or a longer range. |
Actually, I believe that this is a culprit of the issue in Hass.io. |
|
I think my issues started with 0.104.x as well, I lowered the baudrate of my Pi 3B last sunday and no issues so far (about 56 hours later), still receiving data which matches with the values from the Flower Care app. Found it here; |
|
My miflora issues started 104 as well, before that it was working well, now it is broken |
|
@Martinvdm @xPhantomNL @Molodax which hardware do you use? HassOS or something else? |
|
Using intel nuc with docker |
|
@xPhantomNL your suggestion definitely helped (on an RPi 3Brev1.2)! |
Have you had any luck getting them working again yet? |
|
Same issues here, very annoying (5 sensors, some with new batteries after less than a year)... Edit: I completely agree with #30275 (comment) |
I've made this crude workaround which should function until a fix is in place. I'm using a Pi 3B and have had this issue since around 0.103, currently running 0.106.5. Still testing but worth trying. Edit: working well so far |
|
@talondnb thanks for the workaround! I tried it by logging in via the hassio ssh addon but the command couldn't be found (which makes sense). I then applied it on my server directly (ubuntu 18.04, via ssh) 'sudo hciconfig down/up' but my sensors are still being reported as unavailable. 😕 How do I apply these commands correctly? 🙈 PS: I can poll all my sensors very quickly and without any issues from my laptop using the miflora python lib which is also used by this component. So it MUST be related to this component and the way how it interacts with Home Assistant. 🤷♂️ |
The hciconfig command doesn't exist within the hassio ssh addon and the shell_command integration runs commands within the hassio docker host itself. To get to the host, disable protection mode in the SSH addon (the one by Frenck) and run 'docker exec -it homeassistant /bin/bash' within a ssh session. If you want to perform the same within the hassio ssh addon, simply run 'bluetoothctl power off' then 'bluetoothctl power on'. This 'reboots' the bluetooth controller and the sensors will come back within 20 minutes or so - it is not instant unfortunately. It's definitely relating to the software on homeassistant/pi. |
|
BTW, it looks like a 'hciconfig hci0 reset' might be simpler and unless it was a coincidence, brought my sensors back sooner: |
It's a trick I used for a while, and it was better than nothing, but the Bluetooth would eventually lock up and I would have to reboot the Pi (as in, the hci0 reset would be stuck as well, so nothing could be done). Sorry to be a downer, but I wouldn't get my hopes up. |
|
Ahh, didn't realise. Thanks for the insight though, I think for those like myself this is probably the best workaround for now, sigh. |
|
@talondnb thanks for clarifying but I can simply log into my host since it runs normal Ubuntu (and Hassio + docker on top of it). However, a |
|
I just realized after a restart of HA (v106.5) that I just have this (wrt. miflora) in my log (I have 6 sensors): That's it and according to the code, it seems to be stall in https://github.com/home-assistant/core/blob/0.106.5/homeassistant/components/miflora/sensor.py#L164 because every other cflow case has an output. For me it seems to be stuck at polling the first sensor but the question is why. Does anyone know (maybe @ChristianKuehnel ?) if there's a timeout for polling and to what value it is set to? According to my investigations, parameter_value() will be called which will have a cache miss, so it will invoke self.fill_cache(). In that method, there is no loop but a comment saying "wait 5 minutes before retrying": where does this (wait+retry) happen? To continue, I assume the work is done in connection.write_handle() which calls BluetoothInterface.connect() -> self._backend.connect() -> BluepyBackend.connect() (at least in my case of bluepy). I don't know what Peripheral does (and don't want to track it further down) but at least up to here, there's no waiting or retrying ... 🤔 🆘 Edit: I now also tried to do a scan and polled every sensor from the server itself (running HA and the miflora component) and that worked flawlessly. Again, it must be an issue in the HA component. |
|
Hass.io over Ubuntu 18.04 using an USB Bluetooth stick 🤔 |
|
I'm not sure how USB Bluetooth sticks are configured, and even whether the underlying problem is the same... However, did you go over the commands I recommended to @talondnb in the other thread, starting at #31657 (comment)? If the problem is an overflow due to the lack of hardware flow control, we should be able to figure out where the baud rate is set in order to lower it. |
|
@aronsky thanks for your super quick support! Both Don't know why but the formatting of the log got screwed up somehow 🤔 Does this help? |
|
Can't find anything helpful there. Do you have the output of |
|
Do you want the entire output (which is quite a lot: 264 lines)? 🙈 Here's already the output for |
|
Nah, the Bluetooth service itself isn't the one that's interesting to me - are there any other interesting entries there regarding it? For example, in the previously posted output, the service of interest to me was |
|
A bit complicated as I am connected from my mobile phone via Termux and a VPN 😆 I searched for "blue" and just found Nothing else about "blue" / "bluetooth", especially no EDIT: Anything specific you want me to search for? 🙈 |
|
Based on a few searches I made, it looks like Bluetooth over USB works differently - not via serial, so baud rate and flow control are probably irrelevant... I'm afraid that might be a different problem, maybe within miflora itself (since as you mentioned earlier, the adapter itself works). One option you could consider, in case you have a spare ESP8266/ESP32 laying around, is to flash it with ESPHome and let it handle all the BLE connections with miflora, while reporting to Home Assistant over WiFI. |
|
Thanks for your support anyway! The strange thing is that it used to work for nearly a year without issues (with the same adapter), previously on a RPi2 (with that adapter as well due to the lack of bluetooth). I thought about running a script on the system, periodically resetting the bluetooth adapter (power off -> power on) which seemed to work for me (see my post above). But yes, using dedicated hardware as bluetooth/plant gateway would be another option althought this would require running another device permanently (which I would like to avoid due to power consumption, already having a lot of devices around and my ODROID is still close enough to my mi flora sensors) 🙈 . |
|
If resetting the adapter works for you, it's a good workaround. |
|
Same issue here, worked perfect for 1 year +, now broken. Debian, Docker, HASS (USB Bluetooth). |
|
Can we await confirmation of the fix before closing the issue please? |
|
I am also very sceptical whether #31156 really solves this issue... |
|
IMHO there are two different bugs:
This works for me: |
|
#31156 did not resolve the issue. I'm running "former HASSIO" on RPI 4. |
|
Still broken here too :( |
|
i have the same issues :-( |
|
I also hat the issue yesterday and then did a update to 0.108.5 and supervisor 217 |
|
Yes, the issue isn't with the BLE controller in my case (it's always worked), it's the fact that the MiFlora integration does not appear to work. |
|
@DanielXYZ2000 |
|
@Dreamoffice Which terminal add-on are you using? use the communitiy one: |
|
im using this :-( |
|
ok. perfect with the other terminal it is working, but the sensors are still unavailbale. |
|
@DanielXYZ2000 |
|
on the console you should get: Agent registered in my config it looks like You don't need BLE_ as prefix |
|
@DanielXYZ2000
|
|
i don t know why but i can receive the values. they are still unavailable. |
|
Ups, yes platform should be miflora
|
|
I am running hass.io on an RPi 3 and also encountered my miflora sensors to be unavailable afte 104 a few minutes after hass.io was rebooted. With 0.108.3 I am still having the problem. |
Home Assistant release with the issue:
0.103.4
Last working Home Assistant release (if known):
0.102
Operating environment (Hass.io/Docker/Windows/etc.):
raspbian/virtualenv on pi4
python_version 3.7.3
Integration:
https://www.home-assistant.io/integrations/miflora/
Description of problem:
Since #29276, miflora sensors are now displayed as 'Unavailable' when they can't be reached. Since BtLE is quite unreliable, even with a good connection they are frequently displayed as 'Unavailable'.
As values tend to change slowly, a day-old stale value is preferable to 'Unavailable'.
All six of my devices are within 4m of the pi4 which runs home-assistant. Even the closest devices have gaps in the graphs where they are 'Unavailable'.
Problem-relevant
configuration.yamlentries and (fill out even if it seems unimportant):Traceback (if applicable):
Additional information:
Suggestion: Allow users to set a threshold after which the sensor is considered 'Unavailable'. Only mark the sensor 'Unavailable' if the user has configured a threshold.
The text was updated successfully, but these errors were encountered: