Home Assistant release with the issue:
0.94.0b8
Last working Home Assistant release (if known):
0.93.2
Operating environment (Hass.io/Docker/Windows/etc.):
Hassio
Component/platform:
https://www.home-assistant.io/components/mitemp_bt/
Description of problem:
Not updating and showing Unknown temp and humidity only error is
(Updating mitemp_bt sensor took longer than the scheduled update interval 0:00:30)
Rolled back to 0.93.2 and all working fine.
Problem-relevant configuration.yaml
entries and (fill out even if it seems unimportant):
- platform: mitemp_bt
mac: '4C:65:A8:D6:61:08'
monitored_conditions:
- temperature
- humidity
- battery
**Traceback (if applicable):**
```
Additional information:
Same here...
And same here too.
Same here
No longer working here too :(
Same issue here
HASSIO 0.95.4 on Rasppbery PI 3B+ can t get state and tempreature from XIAOMI Temp. sensors. Someone could?
@jakobsons i've got 2 sensors one of them works the other one doesn't. Not sure why.
Same issue. HASS 0.95.4 with direct install on raspberry pi buster.
Switching to 0.95.4 from 0.95.0 had the same effect for me, working before, not working now :'(
Same problem here...
Any update on this ?
This message is from helpers/entity_platform.py and I wonder where the scan_interval of 30s comes from.
I am on hass 0.96.3 and the problem has been solved for me. I am on python 3.7.
Same here, Using 0.96.5
same problem here with Xiaomi BLE Temperature and Humidity sensor upgrading from 0.95.4 (working) to 0.96.5 (not working, devices "unknown")
Same problem here with 0.97.
Thanks
Same problem here with 0.97
Thanks
I have the same problem with 0.97.1
I just made the update last night (to 0.97.1) and there is still the same issue.
Having same issue here :::
2019-08-12 22:34:13 WARNING (MainThread) [homeassistant.components.sensor] Updating mitemp_bt sensor took longer than the scheduled update interval 0:00:30
Thank you to fix this on next release
Same isssue here. Sensors work for approximately 2 hours. then stop.
If I reeboot hassio, they start working again for some time.
Version 0.97.1
Any update here ? I upgraded to 0.97.2 and sensors are not working at all (even after a reboot)
I tried to update my python version in my VM but no change, inside HASS.IO version is :
python_version | 3.7.4
same issue here, it works for a while after the restart then it stops working and need another restart for it to start working again. HA 0.98.3 on HASSOS 2.12, RbPI 3b
HassOS 3.4
HA 0.98.4
Raspberry Pi 4
same issue
2019-09-06 14:15:53 WARNING (MainThread) [homeassistant.components.sensor] Updating mitemp_bt sensor took longer than the scheduled update interval 0:00:30
shows Unknown value
I have same issue:
In docker container:
bash-5.0# hcitool dev
Devices:
hci0 28:CF:E9:01:A1:66
bash-5.0# hcitool lescan
LE Scan ...
58:2D:34:34:E5:83 MJ_HT_V1
2019-09-07 23:19:04 WARNING (SyncWorker_17) [homeassistant.components.mitemp_bt.sensor] Polling error
2019-09-07 23:19:04 WARNING (SyncWorker_11) [homeassistant.components.mitemp_bt.sensor] Polling error Could not read data from Mi Temp sensor 58:2D:34:34:E5:83
2019-09-07 23:19:38 WARNING (MainThread) [homeassistant.components.sensor] Updating mitemp_bt sensor took longer than the scheduled update interval 0:00:30
conf:
sensor:
- name: Sensor
platform: mitemp_bt
adapter: hci0
median: 3
mac: '58:2D:34:34:E5:83'
Same for me, works for a few hours then stop. No solution ?
Same issue here, it works for some time after reboot and then stops. Hassio 0.98.4
Same issue, version 0.98.4 installed on docker in raspbian on RBPi3+.
I just reinstalled using 2019-07-10-raspbian-buster-lite and the updating everything.
On previous installation using the same raspbian image but done at the beginning of august everything was working fine.
Same issue, HA 0.98.5 running on a Pi 4 with hass.io.
Same issue, HA 0.98.5 running on a Pi 3 with hass.io.
same issue here, it works for a while after the restart then it stops working and need another restart for it to start working again. HA 0.98.3 on HASSOS 2.12, RbPI 3b
same for me. works for a while after reboot, then stops working until rpi is rebooted again.
HA 0.98.5 / raspbian buster / python 3.7.4 / RPI3B+
restarting HA does not change anything.
It looks like 0.99 version solved the issue.
From the 0.99 release notes:
added missing bluepy dependency for miflora (@ChristianKuehnel - #26297) (miflora docs)
updated to 0.99.2 and issue still arise unfortunately (: .
yea i also still have the same issue
also for me, nothing changed. it works flawlessly for hours, then suddenly stops receiving measurements. reboot the pi and it'll be good for a while again - it is the only solution that works for me (always does) until now.
Issue still on 0.99.3 and is not Pi related. I'm using hass.io on x64 Arch Linux install inside Proxmox KVM. Same issue, every few hours it drops completely. Restarting home assistant works for next few minutes to hours. Also tried on Pi3B+ with same result.
Me as well. Same issue. Works for a few hours, then stops. Restarting Home Assistant it usually starts working again... but only for a while.
Log Details (WARNING)
Sun Sep 22 2019 16:51:48 GMT+1200 (New Zealand Standard Time)
Polling error Could not read data from Mi Temp sensor
Home Assistant 0.98.4 installed in a Docker container. On an Intel NUC
arch x86_64
dev false
docker true
hassio false
os_name Linux
python_version 3.7.4
timezone Pacific/Auckland
version 0.98.4
virtualenv false
I don't know if it could be an indication of the problem but my hcitool lescan inside the container's shell gives this output:
bash-5.0# hcitool lescan
LE Scan ...
0F:D1:72:92:D9:5E (unknown)
58:2D:34:31:43:BF (unknown)
58:2D:34:31:43:BF MJ_HT_V1
58:2D:34:31:43:BF (unknown)
Disable scan failed: I/O error
bash-5.0#
it seems that the MI TEMP device is appearing three times
The problem still persists even with 0.99.3
Works for couple of hours and then there are no updates.
Works after a restart of HA for only a few hours.
Not good if you rely on it for heating.
Agree, I planned to do it but it is too risky. I know that there is no support team behind it, but I wonder if anyone know about it at the relevant teams.
I can not add it to https://alerts.home-assistant.io/ either.
We just report its failure after each release again and again.
I'm rather new HA user, I don't how things going on here, sorry but I'm disappointed.
I know it is a bug reporting and not a support forum, but I believe a temporary work around for this would be a ESP8266 with ESPHome. The Xiaomi BLE Temprature sensor is supported, and report to HA without using the integrated bluetooth of the Pi. I have ordered some and will report if that works.
@christopherI06 Thanks for pointing that out, this is working perfectly, range seems better also 👍
And a workaround for the ESP based workaround...
(See the "Update: Auto daily reset" part of the article.)
https://blog.quindorian.org/2019/04/home-assistant-cheap-multi-room-temperature-humidity-sensors.html/
Dang, just purchased a d1 Mini, looks like the Bluetooth tracking isn't available for that board through ESPHome.
Same issue for weeks since I updated
Updating mitemp_bt sensor took longer than the scheduled update interval 0:00:30
I have the same problem. Receiving data from the sensor stops suddenly after a few minutes/hours, only cure is to restart HA. I see this in the log with debug enabled, after this sensor data is not received anymore:
2019-10-09 14:48:50 DEBUG (SyncWorker_3) [homeassistant.components.mitemp_bt.sensor] Polling data for Nappali Temperature
...
2019-10-09 15:46:39 DEBUG (SyncWorker_3) [homeassistant.components.mitemp_bt.sensor] Polling data for Nappali Temperature
2019-10-09 15:46:39 WARNING (SyncWorker_3) [homeassistant.components.mitemp_bt.sensor] Polling error [Errno 32] Broken pipe
Exception ignored in: <function Peripheral.__del__ at 0x7fb7c8eb5950>
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 630, in __del__
self.disconnect()
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 453, in disconnect
self._writeCmd("disc\n")
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 305, in _writeCmd
self._helper.stdin.flush()
BrokenPipeError: [Errno 32] Broken pipe
2019-10-09 15:46:39 DEBUG (SyncWorker_4) [homeassistant.components.mitemp_bt.sensor] Polling data for Nappali Humidity
2019-10-09 15:46:49 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.nappali_humidity is taking over 10 seconds
2019-10-09 15:47:02 WARNING (MainThread) [homeassistant.components.sensor] Updating mitemp_bt sensor took longer than the scheduled update interval 0:00:30
...
One thing I also noticed that it seems the problem occurs only if there are multiple sensors used. Connection doesn't break with only one sensor.
I have the same problem. Receiving data from the sensor stops suddenly after a few minutes/hours, only cure is to restart HA. I see this in the log with debug enabled, after this sensor data is not received anymore:
2019-10-09 14:48:50 DEBUG (SyncWorker_3) [homeassistant.components.mitemp_bt.sensor] Polling data for Nappali Temperature ... 2019-10-09 15:46:39 DEBUG (SyncWorker_3) [homeassistant.components.mitemp_bt.sensor] Polling data for Nappali Temperature 2019-10-09 15:46:39 WARNING (SyncWorker_3) [homeassistant.components.mitemp_bt.sensor] Polling error [Errno 32] Broken pipe Exception ignored in: <function Peripheral.__del__ at 0x7fb7c8eb5950> Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 630, in __del__ self.disconnect() File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 453, in disconnect self._writeCmd("disc\n") File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 305, in _writeCmd self._helper.stdin.flush() BrokenPipeError: [Errno 32] Broken pipe 2019-10-09 15:46:39 DEBUG (SyncWorker_4) [homeassistant.components.mitemp_bt.sensor] Polling data for Nappali Humidity 2019-10-09 15:46:49 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.nappali_humidity is taking over 10 seconds 2019-10-09 15:47:02 WARNING (MainThread) [homeassistant.components.sensor] Updating mitemp_bt sensor took longer than the scheduled update interval 0:00:30 ...
One thing I also noticed that it seems the problem occurs only if there are multiple sensors used. Connection doesn't break with only one sensor.
Hi Norbi,
I have only one sensor and the same problem appears.
Since June,
definitely not an expert, but could someone try to ssh into the homeassistant container and try to get info with gatttool ? something like:
gatttool --device xx:xx:xx:xx:xx:xx --char-write-req --handle=0x0010 --value=0100 --listen
obviously with the mac of the xiaomi device instead of the xx.
I'm interested to see if it output the actual values, something like:
Characteristic value was written successfully
Notification handle = 0x000e value: 54 3d 32 36 2e 31 20 48 3d 36 32 2e 31 00
Notification handle = 0x000e value: 54 3d 32 36 2e 31 20 48 3d 36 32 2e 32 00
....
those numbers are just the ASCII values in hex of T=26.1 H=62.100
I've been able to reproduce it by myself, and gatttools keep working even when homeassistant isn't reading values anymore! So it menas that it's not a problem with the hardware but probably with a python lib in the middle.
As far as I understand this component -_mitemp_bt_- depends on mitemp_bt_poller.py that in turns depends on btlewrap
I'd like to test them apart, but the big problem here is that I'm not a python dev! anyone more experienced can give me some starting point ?
Finally, a possible workaround could be to template a call to gatttool with homeassistant command and a simple .sh file... what do you think ?
i think, its a problem general bluetooth lib, because i also have a pair of bluetooth flower sensors, and im seeing the same issues with them.
but then again its working for some, so its a bit tricky :)
@marcoCasamento im getting:
bash-5.0# gatttool --device 58:2D:34:34:E5:83 --char-write-req --handle=0x0010 --value=0100 --listen
connect: Resource busy (16)
is it possible that they're using the same bluetooth lib as above, specifically btlewrap ? (also called bluepy, seems)
yes that "Resource busy" sporadically happens to me too, but a retry within some seconds later give the correct output.
I have 2 LCD sensors. I wanted to try the gattool command as well but for me it's really random how it breaks in HA, it's now running for 17 hours without problem. Previously it broke from few mins to 1-2 hours after restart. I couldn't find out yet what triggers it but it's randomness is really annoying.
@vnorbix absolutely random, agree. The first time I've connected my device it worked flawlessly for almost 2 days, than it sometimes works for hours, sometimes works for minutes... totally unpredictable.
Good news is, at least on my case, that gatttool reading works smooth.
Now I'm trying to spawn a subprocess from python (gatttool) and communicate with it, but I don't know python! Chance for learning but it take times...
update: gatttool keep working while home assistant is unable to read since 24 hr.
I even wrote a small python wrapper around it. I'm going to keep in testing for a while than I'll probably wire up a custom component for HA
@marcoCasamento You are the hero we need!
This issue also appears for the miflora component. Whenever the values stop updating for mi_temp is exactly when the values stop updating for miflora as well. And as eveyone mentions, a restart of the home assistant makes all the sensors update correctly again for some time.
The issues 24453 and 19362 were closed when the dependency on bluepy 1.1.4
was added but despite having bluepy 1.1.4
installed in my docker container (running on my Raspberry 3) I still have this issue of the sensors stopping being updated after a few hours.
@ChristianKuehnel : Do you think this is something you could look at? And/or do we need to raise a separate issue for miflora?
For a temporary workaround for mi_temp it seems that somebody managed to create a custom component reading the data sent by the sensor instead of polling it manually: Xiaomi Mijia bluetooth temperature & humidity sensor compatibility
Sorry, I have no idea. We had sporadic problems with Miflora as well, and so far I have no idea what is causing this.
I've put some debug messages in btlwrap and bluepy modules. Btlwrap is a wrapper around the bluepy module which is wrapped in the mitemp_bt module (mitemp_bt_poller file). When polling is working, this is the log:
2019-10-13 07:44:53 DEBUG (SyncWorker_5) [homeassistant.components.mitemp_bt.sensor] Polling data for Hálószoba Temperature
2019-10-13 07:44:53 DEBUG (SyncWorker_5) [btlewrap.bluepy] BluepyBackend.connect(),
2019-10-13 07:44:53 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.init(),
2019-10-13 07:44:53 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.connect(),
2019-10-13 07:44:59 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.disconnect(),
2019-10-13 07:44:59 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.__del__()
2019-10-13 07:44:59 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.disconnect()
2019-10-13 07:44:59 DEBUG (SyncWorker_5) [homeassistant.components.mitemp_bt.sensor] Hálószoba Temperature = 23.1
When the error occurs, this is the log:
2019-10-13 07:49:01 DEBUG (SyncWorker_5) [homeassistant.components.mitemp_bt.sensor] Polling data for Nappali Humidity,
2019-10-13 07:49:01 DEBUG (SyncWorker_5) [btlewrap.bluepy] BluepyBackend.connect(),
2019-10-13 07:49:01 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.init(),
2019-10-13 07:49:01 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.connect(),
2019-10-13 07:49:01 WARNING (SyncWorker_5) [homeassistant.components.mitemp_bt.sensor] Polling error [Errno 32] Broken pipe,
2019-10-13 07:49:01 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.__del__(),
2019-10-13 07:49:01 DEBUG (SyncWorker_5) [bluepy.btle] Peripheral.disconnect(),
Exception ignored in: <function Peripheral.__del__ at 0x7fc882a10ef0>,
Traceback (most recent call last):,
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 636, in __del__,
self.disconnect(),
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 458, in disconnect,
self._writeCmd("disc\n"),
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 307, in _writeCmd,
self._helper.stdin.flush(),
BrokenPipeError: [Errno 32] Broken pipe,
There's a helper application bluepy-helper for the bluepy module which runs when polling. When the destructor runs, connection breaks with the helper application during disconnect, that causes the exception to be catched in the HA component module mitemp_bt/sensor.py, hence the log Polling error XXX
. The problem is there might be a lock or something which causes that the polling running next time through mitemp_bt and btlewrap the result is not received by the HA sensor.
I don't know how to fix this, maybe developers of the btlewrap or bluepy could help us, but I also noticed something in the HA code, in mitemp_bt/sensor.py there is a choice to use GatttoolBackend:
def setup_platform(hass, config, add_entities, discovery_info=None):
"""Set up the MiTempBt sensor."""
from mitemp_bt import mitemp_bt_poller
try:
import bluepy.btle # noqa: F401 pylint: disable=unused-import
from btlewrap import BluepyBackend
backend = BluepyBackend
except ImportError:
from btlewrap import GatttoolBackend
backend = GatttoolBackend
_LOGGER.debug("MiTempBt is using %s backend.", backend.__name__)
We can try to comment out using BluepyBackend and use GatttoolBackend instead, however I don't have an idea what that cause or if it'll be better, I assume the latter uses the gatttool command inside. But I don't know why bluepy backend is preferred by default. For someone who knows python and wants to experiment with this, changed code looks like this:
def setup_platform(hass, config, add_entities, discovery_info=None):
"""Set up the MiTempBt sensor."""
from mitemp_bt import mitemp_bt_poller
#try:
#import bluepy.btle # noqa: F401 pylint: disable=unused-import
#from btlewrap import BluepyBackend
#backend = BluepyBackend
#except ImportError:
from btlewrap import GatttoolBackend
backend = GatttoolBackend
_LOGGER.debug("MiTempBt is using %s backend.", backend.__name__)
The file for me is /usr/src/homeassistant/homeassistant/components/mitemp_bt/sensor.py
, I'm using docker container.
I'm also testing this solution now, for a start it could read values, however some warnings might appear which doesn't affect showing the data in HA:
2019-10-13 08:20:08 DEBUG (SyncWorker_6) [homeassistant.components.mitemp_bt.sensor] Polling data for Nappali Humidity,
2019-10-13 08:20:18 DEBUG (SyncWorker_6) [homeassistant.components.mitemp_bt.sensor] Median is: 53.8,
2019-10-13 08:20:18 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.nappali_humidity is taking over 10 seconds,
2019-10-13 08:20:18 DEBUG (SyncWorker_6) [homeassistant.components.mitemp_bt.sensor] Nappali Humidity = 53.8
Who wants to dig more, these are the files related in order of call stack:
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/mitemp_bt/sensor.py
https://github.com/ratcashdev/mitemp/blob/master/mitemp_bt/mitemp_bt_poller.py
https://github.com/ChristianKuehnel/btlewrap/blob/master/btlewrap/base.py
https://github.com/ChristianKuehnel/btlewrap/blob/master/btlewrap/bluepy.py
https://github.com/IanHarvey/bluepy/blob/master/bluepy/btle.py
Same problem for me until now.
Yesterday I changed from default local recorder DB to a PostgreSQL external one.
I was surprised this morning on notice that my xiaomi sensor was working starting with that change
Update: No luck. After restarting HA it lost connection again. Reseting PostgreSQL DB and restarting again does not recover the connection with the sensor this time.
@vnorbix very interesting. I just removed bluepy backend from the mitemp_bt component and threw it into my setup as a custom component.
It should now be using gatttool as it's backend. I'll let you know in an hour or two if this solution works.
Thanks
Edit:
Anyone else looking for a quick fix could try adding the three files below into their custom_components. You will need to add a folder called "mitemp_bt" into your custom_components folder and copy the 3 files from the link below into that folder.
https://github.com/helenclarko/home-assistant/tree/patch-1/homeassistant/components/mitemp_bt
My post below is giving updates on how long it has been working for.
Still updating, so I guess it is still working. One hour is not a great test, I'll update again in a few hours.
Edit: 3 hours later and I still seem to be getting updates.
I'll leave it until tomorrow morning and then submit a pull request or create a custom component.
I think I'll just flip the try and except statements.
Edit: 8 hours later, still reporting the temperature, I think we have a solution here.
I'll get a custom component made up tomorrow and a pull request will be made.
Gatttool backend is working for me now for 2 days. Because it's a separate binary tool, it doesn't affect the broken pipe error with the bluepy-helper binary in bluepy module.
Do someone know why is the BluepyBackend preferred in the first place?
Gatttool backend seems to be working much longer then it ever has before for me also, well over a day or so. Thanks so much @vnorbix and @helenclarko for the fix and everyone for their suggestions! Home Assistant has an awesome community.
I think that mitemp_bt was based on the code from the miflora library (which allows to connect to some plant sensors made by Xiaomi). And the documentation of the miflora library mentions that gatttool
has been deprecated by the bluez team, hence why bluepy
is recommended. Unfortunately, there seems to be more problems with bluepy
than with the gatttool
wrapper recently.
@camfrout Thanks for clarification!
Thanks :) It is working for me,
Now any plan to implement this on HA as a seperate component?
https://community.home-assistant.io/t/ble-custom-component/48355 (Credits @luca-angemi) has written workaround python script to work with BLE tracker,
I have like 8 friends who are waiting for a addon solution / addon component as HASSIO component. The problem with them is, they are not any programmers and 8000Km far away from me! (If they were around nearby, I would have helped them out), A simple HASSIO node would probably appreciated by many in the community (May be give your name for component with something like NAME.MI_BLE_TH :-) ) People will remember for sure and will be thankful :)
I fixed miflora too, I'll link it here shortly.
Edit:
https://github.com/home-assistant/home-assistant/pull/27673
I don't think these changes will get merged, looks like bluepy is the newer tool and they want to fix that.
I'll be sticking with gatttool until we've worked it out.
@vnorbix May have found something here:
https://github.com/IanHarvey/bluepy/issues/344
Does this look like the issue?
@helenclarko To me it does look like linked to the issue!
When I was playing with Popen in order to communicate with gatttool from python I had this exact errors a couple of time. I then searched stackoverflow for similar issue and found an answer to use subprocess like this:
try:
process = subprocess.Popen(cmd, shell=True, stdout=PIPE, stderr=PIPE,preexec_fn=os.setsid)
result = process.communicate(timeout=10)[0]
except TimeoutExpired:
os.killpg(process.pid, signal.SIGINT)
result = process.communicate()[0]
and it finally worked flawlessly for days.
I'm NOT a python dev so, please, take my insight with a lot of salt :smiley:
p.s. Thank you very much for your effort, your patch is working great!
Wish I could say I did the heavy lifting, it was all @vnorbix research. I just put it together for everyone. I submitted a pull request with the code change, but it looks like they want bluepy fixed rather than reverting to gatttool.
I'm not sure how to make modifications to bluepy because it looks like its not bundled with home assistant, I believe it downloads it when the component is used (correct me if I'm wrong). This would mean that the modification needs to be made in that sensor.py file after bluepy is imported. I haven't worked in python for a number of years, if someone can help with this it would be much appreciated.
Mine still does a "resource busy", but i also use the miflora sensor, that still uses the bluepy, and i guess it locks it, as it is stated above.
I editied the same lines for miflora as for mitemp, in file:
/usr/src/homeassistant/homeassistant/components/miflora/sensor.py
to see if helps ( im pretty sure it will )
@MartinTerp I submitted a pull request for the miflora too, seeing as it was the same code I thought it would be a good idea.
Think we may have found were the bug is, but it'll take someone more skilled with python to get it fixed.
@vnorbix May have found something here:
Does this look like the issue?
I think the error I got was slightly different, it was also in the disconnect
method, but the writeCmd
caused broken pipe error for me, instead of the stopHelper
. But indeed, it seems a similar deadlock problem or the ability to restart the helper app with popen again is missing from bluepy, at least that's what I suspect.
Way to go guys! Thanks for your work so far. Looking forward for a complete set of instructions to deal with this problem.
I'm finding that even gatttool stops working after some time.
Same thing happening to others here?
I'm finding that even gatttool stops working after some time.
Same thing happening to others here?
What i find, is that gatttool is talking way longer time, meaning if i restart ha while its doing its sync, it dosnt close the connection to the devices, and it cant connect again, until i reboot the whole server.
Could this be the case you are also experiencing?
I'm finding that even gatttool stops working after some time.
Same thing happening to others here?
Hello I installed hassio and dectected the problems discribed in this thread. The usage of the changed sensor.py with the lib gatttool is valid? how much time it stays functional?
I didn't have any issue since I've switched to a customcomponet with code from helenclarko.
It sometimes don't get updated for a while but is just because the sensor is two rooms far from the RPi and when both doors are closed radio signal is poor. I simply open a door or slightly move the RPi and it log data again.
I believe however that the longest test without an home assistant restart (for other reasons) is no longer than 3/4 days.
I've just migrated from RPI 3B+ to RPI 4 and have the issue on both machines. I completely reinstalled Hass.io and just moved my config over, so I'm not sure how hardware dependent it is.
Maybe it's dependend on the configured HA components and another component get ins the way of this one?
I don't think it's hardware related, I had problem with the bluepy backend on docker container on x86 arch. With the gattool backend I don't experience any glitches. Maybe polling is slower but it doesn't break down for good as gattool did. I don't experience the deadlock problem on restart, but docker containers probably just get killed if binary doesn't stop gracefully.
Using helenclarko's recommendations about mitemp_bt folder, solved the problem for me. Uptime: 2 days, 19:21 so far.
Thank you!
I'd like to invite @Danielhiversen and @ChristianKuehnel to look over this with us, as code owners I think they may have more insight.
Seems crazy that this is an integration that simply doesn't work as intended and the solutions are to either use another integration to pull the data in (ESPHome) or modify the existing code to use an outdated bluetooth backend.
I'm not saying Gatttool is the overall solution here, but it looks to be doing a better job than bluepy.
From my understanding the underlying problem is the instability of the
Linux Bluetooth stack. So maybe one workaround would be: restart the
Bluetooth stack after a certain number of failures. I haven't tried this so
far...
Am Mi., 6. Nov. 2019 um 20:33 Uhr schrieb helenclarko <
[email protected]>:
Seems crazy that this is an integration that simply doesn't work as
intended and the solutions are to either use another integration to pull
the data in (ESPHome) or modify the existing code to use an outdated
bluetooth backend.I'm not saying Gatttool is the overall solution here, but it looks to be
doing a better job than bluepy.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/24313?email_source=notifications&email_token=AEYJMCDCPATIKO4ZRIHESYDQSMLWXA5CNFSM4HTRCM22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDHW74Y#issuecomment-550465523,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYJMCGOAIUAGPTKML6R2STQSMLWXANCNFSM4HTRCM2Q
.
I researched a bit, yes gatttool is deprecated, so is bluepy current version is going to be.
before somebody stand out and come up a better solution,
gatttool is the only working plan.
I just setup an ESP32 with the Xiaomi Bluetooth sensor in ESPHome, so far this has been solid.
Not really a great solution, just another option.
Guys, I updated to Home Assistant Version 0.101.3! (Hassio)
And looks like it is working well, Will update back tomorrow!
It would be good to get updates from you awesome people too!! :)
Interesting, I don't see anything in the changelog for 0.101.3 about bluetooth. Glad it works for you, keep us posted!
@Harshajv : can you please confirm if, after some hours, the sensor's logging is still working properly?
Thanks
I have been running it now for 2 days without issues
Update: I had to restart twice in past 2 days, and now it has stopped, it has similar issue, but what I have noticed is that now it works longer (12 to 14 hours) than before.
@Harshajv : can you please confirm if, after some hours, the sensor's logging is still working properly?
Thanks
Update: I had to restart twice in past 2 days, and now it has stopped, it has similar issue, but what I have noticed is that now it works longer (12 to 14 hours) than before.
Hassio 101.3 here, I confirm it's lasting longer but the errors in the logs are still there.
When I enter the docker end use the example code from mitemp_bt it does not take "so long"
root@futro:~# docker exec -t -i homeassistant bash
bash-5.0# time ./my
4.9
real 0m18.033s
user 0m0.666s
sys 0m0.083s
I'm not an expert in Python, but it should be enough to check what was changed between release 095.xx and 0.96 in the flow on BT sensor data , as the sensor was correctly logged until version 0.96 was introduced (I'm still on 0.95.2 and working well since months....). Is there someone available for this task??
For the interval errors, take note that they are always present also in the version 0.95, I guess this is a different issue related with BT trasmission to the sensors... but after some attempts the sensor data are updated..
One problem is, that the mtemp_bt which is contained in the docker container has old code, which can not deal with temperatures under 10 grade c. I had to update the library manually.
It must be related to home assistant, because when I use mitemp_bt it does work both in the host and the docker image. It needs a couple of seconds an can read without problems.
Can anybody point me a place in the code where the home assistant tries to update the values from the sensors?
Updated to 0.102.0b0 same issue here.
Hello all, after patching to 0.102.0b1 ..after restart of HA its running for 12 horus without issue.
I have three xiaomi temp/humidity sensors and four ble eq3 valves.
- platform: mitemp_bt
mac: 'xxxxxxxxxxxxx'
name: bath room
force_update: true
median: 1
timeout: 10
monitored_conditions:
- temperature
- humidity
- battery
Could someone perform upgrade and check ?
Hello all, after patching to 0.102.0b1 ..after restart of HA its running for 12 horus without issue.
I have three xiaomi temp/humidity sensors and four ble eq3 valves.
- platform: mitemp_bt mac: 'xxxxxxxxxxxxx' name: bath room force_update: true median: 1 timeout: 10 monitored_conditions: - temperature - humidity - battery
Could someone perform upgrade and check ?
I had updated to 0.102.0b1, it is still failed.
Hello,
true .. after 15 hours it failed again :(
I'm on 0.101.3 and still have this problem. I hope it gets solved soon, as this issue has a big impact on my automation system.
I'm running a generic thermostat on top of this and it's useless for now.
Using an ESP32 with ESPHome is my best alternative so far. I followed this tutorial: https://blog.quindorian.org/2019/04/home-assistant-cheap-multi-room-temperature-humidity-sensors.html/
I am wondering if an ESP32-CAM could be used as a camera and Bluetooth packet sniffer simultaneously into Home Assistant.
Ich works now for me. Ich have made a pull request to bump the mitemp_bt up to 0.0.3 from 0.0.1 for the hass docker image. It was merged to dev. I have pull the dev image of docker with
docker pull homeassistant/raspberrypi3-homeassistant:dev
Then I had to create the custom_component of mitemp_bt for hass with the manifest of 0.0.3 mitemp_bt. Now it works since 2 days.
Hi,
is there any progress ? I have HASS.IO installation v0.101.3 , in docker, and same as @MartinTerp I can see devices with hcitool lescan, but they does not show in HA. Everything was working correctly when I installed it a few days ago. I have extended my configuration with force_update, and timeout to 60s, but devices are still missing.
Have the same problem on 0.101.3 running Hassio on RPI
2019-11-21 09:09:35 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.temp2_humidity fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 270, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 450, in async_device_update
await self.hass.async_add_executor_job(self.update)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(self.args, *self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/mitemp_bt/sensor.py", line 156, in update
data = self.poller.parameter_value(self.parameter)
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 125, in parameter_value
self.fill_cache()
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 68, in fill_cache
connection.wait_for_notification(_HANDLE_READ_WRITE_SENSOR_DATA, self, 10) # pylint: disable=no-member
File "/usr/local/lib/python3.7/site-packages/btlewrap/bluepy.py", line 26, in _func_wrapper
return func(args, *kwargs)
File "/usr/local/lib/python3.7/site-packages/btlewrap/bluepy.py", line 89, in wait_for_notification
return self._peripheral.waitForNotifications(notification_timeout)
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 516, in waitForNotifications
resp = self._getResp(['ntfy','ind'], timeout)
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 378, in _getResp
self.delegate.handleNotification(hnd, data)
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 195, in handleNotification
self._check_data()
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 144, in _check_data
parsed = self._parse_data()
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 177, in _parse_data
res[MI_HUMIDITY] = float(data[9:13])
ValueError: could not convert string to float: '5.3\x00'
The problem is here the old version of mitemp_bt (0.0.1) which can not parse the temperateus below 10.
The solution for me was to use dev docker, for which i have provided a patch to have the mitemp_bt 0.0.3
docker pull homeassistant/raspberrypi3-homeassistant:dev
Then I have created a custom_component -> copy mitemp_bt in the custom_components and put the in the manifest 0.0.3 for mitemp_bt
Seems to be fixed with latest release (0.102.0).
Not so for me. Still having the same problem.
I am using ESP32 and ESPhome and it works fine, have 10 sensors and there is no range issues too (With a 140Sq single floor house, two of the sensors are even placed outside with tripple insulated brick walls) and If I switch back to HA component, it works initially and stops after 16 hours this time. Using ESP32 is just a fallback solution, I am waiting for the fix with HA component.
Home Assistant 0.102.1 working for me more than 35h with "platform: mitemp_bt" and "MJ-HT-V1"
It's an amd64 arch Debian system with Docker and Hassio on top.
Today reached ~50h. Upgraded to 0.102.2 and continue running.
I can confirm it with HA 0.102.1 and 0.102.2, 24h and still working, even when I remove parameter force_update
It stopped after several hours.
I'll try custom components
Not working for me. HA 0.102.2 on RPI 3B+
Still 'Polling error Could not read data from Mi Temp sensor'
when I update to 0.102.0b0, it failed in 3or4 hours. but when I reboot the
system, it is still working for a week and not failed yet.
mine is RPI3B+
On Tue, Nov 26, 2019 at 4:50 AM rfontijn notifications@github.com wrote:
Not working for me. HA 0.102.2 on RPI 3B+
Still 'Polling error Could not read data from Mi Temp sensor'—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/24313?email_source=notifications&email_token=AFLLYFFVQBNT3WRFFIJW5QTQVQ27ZA5CNFSM4HTRCM22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFDYAJA#issuecomment-558333988,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFLLYFE5KUVFSENK5W2FGODQVQ27ZANCNFSM4HTRCM2Q
.
Yes, it does work now. I did two things, so I have to find out what did the trick:
I now can see the temperature and humidity readings. The battery state is an attribute of both meters.
Yes, it does work now. I did two things, so I have to find out what did the trick:
- Removed the integration with Flic (which uses bluetooth connections too)
- Installed a new version of mitemp_bt using the steps from here
I now can see the temperature and humidity readings. The battery state is an attribute of both meters.
It's working for me with this custom compontent, thanks!
Yes, it does work now. I did two things, so I have to find out what did the trick:
- Removed the integration with Flic (which uses bluetooth connections too)
- Installed a new version of mitemp_bt using the steps from here
I now can see the temperature and humidity readings. The battery state is an attribute of both meters.
"sudo apt-get install bluez-hcidump"
Is there a way to make this type of configuration in hassio?
"sudo apt-get install bluez-hcidump"
Is there a way to make this type of configuration in hassio?
I think you don't need it, just install the custom component. It worked for me!
Dev version does not solve anything for me. Sensors are being refreshed only for ~2h after Hass restart. Since i use hacked bluetooth (antena hack) dongle on hci1 it is also not possible to use custom component. Would it be so kind and release a newer/fixed version?
Here is an alternative component that seems to work: custom-components/sensor.mitemp_bt
Unlike the original mitemp_bt integration, which is getting its data by polling the device with a default five-minute interval, this custom component is parsing the Bluetooth Low Energy packets payload that is emitted each second by the sensor. The packets payload contains temperature/humidity and battery data. Advantage of this integration is that it doesn't affect the battery as much as the built-in integration. It also solves connection issues some people have with the standard integration.
Here is an alternative component that seems to work: custom-components/sensor.mitemp_bt
Unlike the original mitemp_bt integration, which is getting its data by polling the device with a default five-minute interval, this custom component is parsing the Bluetooth Low Energy packets payload that is emitted each second by the sensor. The packets payload contains temperature/humidity and battery data. Advantage of this integration is that it doesn't affect the battery as much as the built-in integration. It also solves connection issues some people have with the standard integration.
Wow, Great!
Have the same problem on 0.101.3 running Hassio on RPI
2019-11-21 09:09:35 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.temp2_humidity fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 270, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 450, in async_device_update
await self.hass.async_add_executor_job(self.update)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(self.args, *self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/mitemp_bt/sensor.py", line 156, in update
data = self.poller.parameter_value(self.parameter)
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 125, in parameter_value
self.fill_cache()
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 68, in fill_cache
connection.wait_for_notification(_HANDLE_READ_WRITE_SENSOR_DATA, self, 10) # pylint: disable=no-member
File "/usr/local/lib/python3.7/site-packages/btlewrap/bluepy.py", line 26, in _func_wrapper
return func(args, *kwargs)
File "/usr/local/lib/python3.7/site-packages/btlewrap/bluepy.py", line 89, in wait_for_notification
return self._peripheral.waitForNotifications(notification_timeout)
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 516, in waitForNotifications
resp = self._getResp(['ntfy','ind'], timeout)
File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 378, in _getResp
self.delegate.handleNotification(hnd, data)
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 195, in handleNotification
self._check_data()
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 144, in _check_data
parsed = self._parse_data()
File "/usr/local/lib/python3.7/site-packages/mitemp_bt/mitemp_bt_poller.py", line 177, in _parse_data
res[MI_HUMIDITY] = float(data[9:13])
ValueError: could not convert string to float: '5.3\x00'
Custom component worked for me.
Here is an alternative component that seems to work: custom-components/sensor.mitemp_bt
Unlike the original mitemp_bt integration, which is getting its data by polling the device with a default five-minute interval, this custom component is parsing the Bluetooth Low Energy packets payload that is emitted each second by the sensor. The packets payload contains temperature/humidity and battery data. Advantage of this integration is that it doesn't affect the battery as much as the built-in integration. It also solves connection issues some people have with the standard integration.
thank you! Works really well! I activate my stove at night based on the temperature of the room and it worked perfectly without a disconnection! You saved me from illness! 😄
Same as a few people. I have stopped using the official integration and I am now using the alternative component (easy to install with HACS). I used to have issues every couple of hours and it now works for several days in a row. It also looks like the miflora component is working better now (maybe because there are much less calls to bluepy).
Would the solution to this issue be to replace the official mitemp_bt integration by the custom one?
Would the solution to this issue be to replace the official mitemp_bt integration by the custom one?
Good point, in my opinion it would definitely make sense. The alternative solution seems to be more reliable, more battery friendly. Furthermore I had better experience in terms of range, I assume it is an result of the fact that HA does not need to send any data itself and just listening for sensor broadcasts. It is also more user friendly in terms of setup, user don't need to search for sensor MAC address anymore.
Can someone of HA team give some comments to this topic? Maybe @balloob?
@TUNER88 please see this PR's comments for some statements from the HA team: https://github.com/home-assistant/home-assistant/pull/27673
I confirm that on 102.3 the custom-components/sensor.mitemp_bt is working also for me very efficiently. The only drawback (but I'm not sure it's 100% related to) is that my EQ3BT Thermostats are now slower and more "unresponsive", and many times I get the "broken pipe" or "failed to connect" warnings.
After many attempts anyway I can update the values on the EQ3BT.
...Can it be related to the different BT management of the new component that may conflict with EQ3BT HA code??
Thanks anyway for the new component!!
@sibbl #27673 is about replacing bluepy
by gatttool
. The new custom component I mentioned above is using a totally different approach, it is listening to sensor broadcasts instead of actively pulling the data. So we can not reference to #27673 here and still need some feedback from the HA team.
@dxdx65 I don't have any of EQ3BT, my setup is working without any side effects. Maybe you can try to temporary disable the custom component to check if EQ3BT issues are related to it.
Agree with @TUNER88. The alternative component sensor.mitemp_bt is using passive listening.
Pros: Data update every minute. Just by passive listening (without active data request sending to device). No battery drain.
I am using sensor.mitemp_bt for 4 days in Home-Asistant and it works perfectly. Consider to migrate from current component to new sensor.mitemp_bt.
Absolutely agreed, I'm using this alternative component 24/7 without any
issue and never stop to works!
Il mar 10 dic 2019, 14:13 Martin Zaloudek notifications@github.com ha
scritto:
Agree with @TUNER88 https://github.com/TUNER88. The alternative
component sensor.mitemp_bt
https://github.com/custom-components/sensor.mitemp_bt is using passive
listening.
Pros: Data update every minute. Just by passive listening (without active
data request sending to device). No battery drain.I am using sensor.mitemp_bt
https://github.com/custom-components/sensor.mitemp_bt for 4 days in
Home-Asistant and it works perfectly. Consider to migrate from current
component to new sensor.mitemp_bt
https://github.com/custom-components/sensor.mitemp_bt.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/24313?email_source=notifications&email_token=AAEKGHX3OE3UXE4P5T5BLHTQX6IX5A5CNFSM4HTRCM22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGPFXNA#issuecomment-564026292,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEKGHSCYRK3Z6TGTWV4NYTQX6IX5ANCNFSM4HTRCM2Q
.
Alternative version is approved! I'm use it without issue, working like a charm!
@ma-zal @S1m0n3 @thiagogalvao thanks for feedback, according to the latest messages sensor.mitemp_bt seems to work quite reliable. Would be great to have it in the HA core, less config effort, more battery friendly, do you see any cons guys?
@Ernst79 @Magalex2x14 what do you think about submitting sensor.mitemp_bt as an PR to the main HA repo?
If we could merge it, the whole HA community would benefit from working mi sensors, I'm basically don't believe that the majority of HA users will be able to discover this custom component.
@TUNER88 I think that we need some more time, as there are some users with not working custom mitemp_bt . And even when we deal with this, PR may not accept, because if memory serves me, integration should not use third-party utilities, only Python libs (there is a chance that we can make a component according to all the canons of HA, but it takes time).
@TUNER88 I agree with @Magalex2x14 The custom component makes it easy for us (especially Magalex2x14) to sort thing out first, fixing the most important bugs. Next step is that we have to fulfill the following requirement according to the developers docs.
All communication to external devices or services must be wrapped in an external Python library hosted on pypi.
I have not done that before, but I guess that a lot of the python code has to move to a pypi package. All communication is now included in the sensor.py file. I think it’s better to focus on bugfixing first. Next step would be moving part of the code to an pypi package, if needed, and than update the official component. This will take time but the ultimate goal would hopefully be an official component.
@Magalex2x14 @Ernst79 okay, that sounds great. Would you think it makes sense to submit an small PR to the official repo with improved mitemp_bt
integration readme? We can add an troubleshooting section where we can point to sensor.mitemp_bt. It would help HA users to get rid of this annoying issues we are discussing here since a half of a year. Any chance to get it merged?
@TUNER88 Not sure if the core team of home assistant agrees on making a link in the official documentation of the mitemp_bt integration to the custom_component. I agree it would be helpfull for a lot of users in the meantime, but on the other end, I can also understand if the devs want to keep the docs clean. @balloob or @frenck, it this allowed or don't you want links to custom components in the documentation.
@Ernst79 keeping the docs clean makes totally sense, but the official integration unfortunately seems to be quite buggy, this is confirmed by all the users from the current topic. I think it is worth to mention the third party integration as possible workaround until the main one is fixed. But you are right, we have to wait for feedback from the HA team
@ zaurak27 hassio is not required to execute these commands. Please create an issue in the custom component repository, if the problem is still relevant.
@ zaurak27 hassio is not required to execute these commands. Please create an issue in the custom component repository, if the problem is still relevant.
Thank you Magalex2x14 for the quick reply. I deleted my post, as I found out in the meantime, that the entity changed, thats why it did not displayed anything. I just walked trough the entity list, and found the new entities.
Works great. Thanks also for the developer.
Another issue I am having now, is that the sensors reading is not forwarded to homekit. It is not filtered out, and still is not showing up. On home assistant Overview it is working
@zaurak27 please open an issue in the corresponding project, it's kind of off-topic here. Futhermore it will be much easier to track and maintain issues for the developers.
Can the new custom component called sensor.mitemp_bt monitor more than one temperature sensor simultanently?
yes it can
I know this issue is now more oriented to the custom sensor that actually seems better also looking at the code.
But I spot something that definitely might be a problem: the hass container has a very old version of btlewrap (0.0.2 instead of 0.0.9) used by mitemp.
I updated with pip install -U btlewrap
inside the home-assistant container.
It seemed to work since last longer 4 hours but now is still frozen :( I'll see tomorrow... anyway that is definitely a wrong version.
Of course the docker should not be modified manually but I think there is a mess with dependencies because pip warned me about incompatible requirements.
bash-5.0# pip list | grep btlewrap
btlewrap 0.0.2
bash-5.0# pip install -U btlewrap
Collecting btlewrap
Downloading https://files.pythonhosted.org/packages/3b/5c/917ea5ea2586ee03cb5bd41007969ac665618d9ba96b538947dac231dbf2/btlewrap-0.0.9.tar.gz
Requirement already satisfied, skipping upgrade: typing<4,>=3 in /usr/local/lib/python3.7/site-packages (from btlewrap) (3.7.4.1)
Building wheels for collected packages: btlewrap
Building wheel for btlewrap (setup.py) ... done
Created wheel for btlewrap: filename=btlewrap-0.0.9-cp37-none-any.whl size=18125 sha256=b96ccbc6fdf5ebf60c5c53133c00577600204b8b4521763c7c93b8bd8aaa7b30
Stored in directory: /root/.cache/pip/wheels/b1/f0/5d/9d18ca7147f05925adfc4d9a29f8a5491831c9012582ed65a8
Successfully built btlewrap
ERROR: mitemp-bt 0.0.3 has requirement btlewrap==0.0.8, but you'll have btlewrap 0.0.9 which is incompatible.
ERROR: miflora 0.4 has requirement btlewrap==0.0.2, but you'll have btlewrap 0.0.9 which is incompatible.
ERROR: beewi-smartclim 0.0.7 has requirement btlewrap==0.0.2, but you'll have btlewrap 0.0.9 which is incompatible.
Installing collected packages: btlewrap
Found existing installation: btlewrap 0.0.2
Uninstalling btlewrap-0.0.2:
Successfully uninstalled btlewrap-0.0.2
Successfully installed btlewrap-0.0.9
I did some more investigation, updating all the libraries does fix some problems but still reading data gets broken after a while.
I fixed exceptions, increased loglevel, even close connection on btlewrap after every read but nothing.
When it gets stuck the only solution is a full raspberry reboot, I tried also getting data via cli but no way, communication is blocked.
I noticed in dmesg these errors:
[ 1482.819606] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1482.834780] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1483.794611] Bluetooth: hci0: Frame reassembly failed (-90)
[ 1483.809015] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1485.888343] Bluetooth: hci0: command 0x0406 tx timeout
Looking at this issue https://github.com/raspberrypi/firmware/issues/1150# seems firmware/kernel related, unfortunately reducing the serial bandwidth, as suggested, on hassos is a bit complicated since /bin/btuart is on a squashfs read only file system.
I'll try updating the firmware with rpi-update on raspbian distribution.
I'll keep investigating...
Same problem wit tx timeout here. The solution was to restart (over timer solution of systemd) the bluetooth service every hour. After this it works very good :(
Any news on this? (my experience https://f.ruuvi.com/t/ruuvitags-in-ha-more-and-more-unstable-with-time/3953/5)
Any news on this? (my experience https://f.ruuvi.com/t/ruuvitags-in-ha-more-and-more-unstable-with-time/3953/5)
Yes! I finally solved this problem (with your workaround).
Just bought an TP-Link UB400 from Amazon (it was the first that showed), plugged it into my RP3, disabled the on-board bluetooth by adding ‘dtoverlay=pi3-disable-bt’ to the end of ‘/boot/config.txt’ (used my PC to edit the config.txt directly from the microSD) and boom! Solved!
My kids room temperature rely on the thermostat I have built with this BLE Xiaomi _cookies_.
No additional configuration, the dongle just worked out of the box. It's literally just a two step hack - outside spending ~10€.
EDIT: I'm on Hass.io 0.103.6, it that matters.
@rquattros Good to hear that it worked, however it's a pity that RPi3 on-chip BT module cannot be used. Hopefully the kernel (or whatever) will be fixed in future.
Looking at this issue raspberrypi/firmware#1150 seems firmware/kernel related, unfortunately reducing the serial bandwidth, as suggested, on hassos is a bit complicated since /bin/btuart is on a squashfs read only file system.
I managed to change btuart file with this baud rate: 460800 like in the below line and so far seems to work.
$HCIATTACH /dev/serial1 bcm43xx 3000000 flow - $BDADDR
else
$HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR
Back again with updates from the USB BT solution: it works for longer, but eventually stops updating just like with the internal BT. Some times works for a couple of days, some others just a few hours. It's not a permanent solution.
Hmm... @rquattros the work-around has worked for me. Have some other attached USB (or other) devices to your RPi? Check "dmesg", "dmesg | grep error" etc. on command-line.
This issue is confusing (and I did read through it). What's the actual verdict? Does the current HA version for Pi work with the sensor without hacks? The current docs at https://www.home-assistant.io/integrations/mitemp_bt/ doesn't warn of any issues and claims sit should work with platform: mitemp_bt
The folks who posted the last messages (Jan 5 onwards) seem to be discussing about config no longer supported ... adds to confusion
Same problem here. A tried with an external bluetooth dongle. It works ~2 hours after same error. :\
Been having this issue for over 6 months
Any news on this? (my experience https://f.ruuvi.com/t/ruuvitags-in-ha-more-and-more-unstable-with-time/3953/5)
Yes! I finally solved this problem (with your workaround).
Just bought an TP-Link UB400 from Amazon (it was the first that showed), plugged it into my RP3, disabled the on-board bluetooth by adding ‘dtoverlay=pi3-disable-bt’ to the end of ‘/boot/config.txt’ (used my PC to edit the config.txt directly from the microSD) and boom! Solved!
My kids room temperature rely on the thermostat I have built with this BLE Xiaomi _cookies_.
No additional configuration, the dongle just worked out of the box. It's literally just a two step hack - outside spending ~10€.
EDIT: I'm on Hass.io 0.103.6, it that matters.
Hello, I bouth the same, but the problems continue, I disable internal bluetooth of RPi3b
After many trial and error troubleshooting, i concluded that this must be related to power issues. After replacing my RPi power supply to a 5V-2.5A one, it works perfectly. No more BT stopping receiving results, no more need for restarts.
HI @simfun where did you buy??
The cable is a Blitzwolf braided USB-A to micro-USB:
https://www.banggood.com/BlitzWolf-2_1A-Reversible-Braided-Micro-USB-Cable-Double-Sided-USB-A-Male-to-Double-Sided-Micro-1m-p-1059938.html
The power supply (which is actually a quick charger 5V 3A) is this one in photo:
I can not remember where i bought it.
Yes, it does work now. I did two things, so I have to find out what did the trick:
- Removed the integration with Flic (which uses bluetooth connections too)
- Installed a new version of mitemp_bt using the steps from here
I now can see the temperature and humidity readings. The battery state is an attribute of both meters.
Raspberry Bluetooth (RBp Model 3B) still stop working in a couple of hours (Home Assistant 107.2)
Symptoms:
device_tracker
integration shows error:Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/bluetooth/bluez.py", line 31, in discover_devices
lookup_class=lookup_class, device_id=device_id)
_bluetooth.error: (22, 'Invalid argument')
hciconfig hci0 -a
(required SSH access, see https://developers.home-assistant.io/docs/hassio_debugging/) shows DOWN
bash-5.0# hciconfig hci0 -a
hci0: Type: Primary Bus: UART
BD Address: B8:27:**:**:**:** ACL MTU: 1021:8 SCO MTU: 64:1
DOWN
RX bytes:2685506 acl:6 sco:28 events:89264 errors:0
TX bytes:31053 acl:0 sco:0 commands:2545 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
or shows timeout errors
hci0: Type: Primary Bus: UART
BD Address: B8:27:**:**:**:** ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:21588252 acl:25 sco:188 events:639500 errors:0
TX bytes:421887 acl:0 sco:0 commands:35902 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Can't read local name on hci0: Connection timed out (110)
UP
doesn't work:$ hciconfig hci0 up
Can't init device hci0: Operation timed out (110)
dmesg | grep Bluetooth
shows errors like:[31640.441744] Bluetooth: hci0: Frame reassembly failed (-84)
[31640.442574] Bluetooth: hci0: Frame reassembly failed (-84)
[31640.443460] Bluetooth: hci0: Frame reassembly failed (-84)
[31640.444363] Bluetooth: hci0: Frame reassembly failed (-84)
and
[29431.849498] Bluetooth: hci0: command 0x1003 tx timeout
[29433.929502] Bluetooth: hci0: command 0x1001 tx timeout
[29436.009528] Bluetooth: hci0: command 0x1009 tx timeout
[29592.890423] Bluetooth: hci0: command 0x1003 tx timeout
[29594.970530] Bluetooth: hci0: command 0x1001 tx timeout
[29597.050443] Bluetooth: hci0: command 0x1009 tx timeout
I've found 4 possible workarounds for this
**Update**: Works good (3 days already) in my case, still receive signal after Raspberry BLE failure.

Use 3rd party Bluetooth usb dongle + disable built-in bluetooth in HassOS
Haven't tried this, but there are reports that it helps
Use better power adapter
The above posts say that it helps: https://github.com/home-assistant/core/issues/24313#issuecomment-600366034. Today I replaced my adapter and will see how it works next 2-3 days.
Wait until https://github.com/home-assistant/operating-system/issues/524 has been fixed in HassOS or try temporary fix, see updated instructions at https://github.com/raspberrypi/firmware/issues/1150#issuecomment-602020073. This workaround should be repeated again after HassOS reboot. Also seems it's better to use HASS OS mitemp_bt
component instead of built-in support (see https://github.com/custom-components/sensor.mitemp_bt), but it has the same bluetooth related issues.
Update: Partly works for me, I got bluetooth errors again in ~ 1 day. I don't recommend this solution.
For me,
the following option not fixed the problem
3.Use better power adapter
The above posts say that it helps: #24313 (comment). Today I replaced my adapter and will see how it works next 2-3 days.
The only thing that is working for me at the moment is installing the 'Xiaomi passive BLE monitor sensor platform' through the HACS system. It has worked for well over a week with no problem.
I followed the instructions here:
https://github.com/custom-components/sensor.mitemp_bt
@gojojo77
‘ Xiaomi passive BLE monitor sensor platform'
In my case it seemed to work first 24 hours, then the same bluetooth connection errors
It's fixed in hassos 3.13
After update battery draining on Xiaomi was very fast. Did someone more experience that?
I think this is due to how the sensor has been implemented not really related to the communication problem or fix itself.
There is another custom sensor that seems less chatty.
But i didn't remenber that this component drains the battery so fast.
Anyway, I will migrate to the custom one, that collects data passively.
Thanks.
Probably because wasn't working :)
Hey @juaigl, I noticed about that battery issue.
After I chenged the battery the problem was reducy a lot.
Probably because wasn't working :)
I was speaking about when it was working. For my was until 102-103, if im not wrong
After I chenged the battery the problem was reducy a lot.
Thank you for you suggestion
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
update: gatttool keep working while home assistant is unable to read since 24 hr.
I even wrote a small python wrapper around it. I'm going to keep in testing for a while than I'll probably wire up a custom component for HA