@Ernst @pixeldublu try the updated code from the post above. I hope all will be ok.
The condition seems to stop spikes so i added one for the humidity also.
Will report back 
Thanks!
Weird…
Apparently, it’s really not in vain that the original component used the median instead of the mean… It seems that there is no particular choice for dealing with this… It is not enough to simply discard values outside the range of the sensor. Curious. @Ernst, do you have the same situation?
@pixeldublu, send a photo of the sensor used, if not difficult.
@magalex. Haven’t seen this behavior, but I’m running your latest code for only two hours now. Will let you know tonight (CET).
1 Like
I will rewrite the code for the implementation of the median in addition to the mean, compare, see how it works. The median does not seem to me so revealing in the case of temperature measurement, but it really helps to exclude erroneous values from the measurement results, even if they are not so much different from normal ones.
The question remains, which sensors are prone to this behavior, and can they be distinguished somehow?
My sensors looks like this (works without any problems):
1 Like
I had a similar error a few minutes ago, with the latest code. Also a small spike of about 1.5 degrees lower than expected.
@Ernst @pixeldublu (and all who have sensors give inexplicable spikes)
I updated my previous post by adding a median calculation. Get updated gist and try new code with option CONF_MITEMPBT_USE_MEDIAN changed to = True (at line 43).
Can I ask, how do you connect it to HA ? Via the Xiaomi gateway, or directly ?
Directly. A gateway is not needed if the HA host has bluetooth LE.
1 Like
It seems to work fine now. No more spikes. Thanks for your help! Your component should replace the current built in component in home assistant.
1 Like
LATER EDIT:
Actually looks like its stopping again after a while… 3 hours since no update…
You need to see if there is a related to mitemp_bt error in the HA log…
Nothing in the logs… for now i restarted the pi3 and all working but will see for how long
I have one suspicion … Tell me, did you disable hcitool lescan with CONF_MITEMPBT_HCITOOL = False?
Dangerous option. I think I was in a hurry to include it in the code. In some situations, if some process intercepts access to bluetooth (even if for a short time), then hcitool is needed for the component to work… I updated the code by removing this option. If someone else disabled this option, then return it or update the code. With updated code HA log will not become clogged with the messages “Set scan parameters failed: Input / output error”.
1 Like
Not… but was just thinking now to disable it and see what happens
Hi @tsymbaliuk and @Magalex, thank you both so much for your effort on this custom component! I almost went nuts with my non-updating sensors and your work is a life saver. I am looking forward to seeing this to be part of the official distribution.
1 Like
Today I ran into a problem similar to yours - the sensor readings stopped updating. The HA log is empty, but in the syslog I found the following:
Sep 5 09:56:13 mini2x14 kernel: [649853.594066] Bluetooth: hci0: hardware error 0xf2
Sep 5 10:05:03 mini2x14 kernel: [650383.485700] Bluetooth: hci0: hardware error 0xe9
Sep 5 10:11:32 mini2x14 kernel: [650772.480441] Bluetooth: hci0: hardware error 0xe8
Sep 5 10:28:28 mini2x14 kernel: [651788.512050] Bluetooth: unknown link type 88
Sep 5 10:28:30 mini2x14 kernel: [651790.524556] Bluetooth: hci0: command 0x040a tx timeout
Sep 5 10:49:23 mini2x14 kernel: [653043.639621] Bluetooth: hci0: hardware error 0xf3
Sep 5 10:58:35 mini2x14 kernel: [653595.592115] Bluetooth: unknown link type 88
Sep 5 10:58:36 mini2x14 kernel: [653596.935072] Bluetooth: hci0: wrong event for mode 0
Sep 5 10:58:37 mini2x14 kernel: [653597.418059] Bluetooth: hci0: hardware error 0xeb
Sep 5 11:01:59 mini2x14 kernel: [653799.650422] Bluetooth: unknown link type 88
Sep 5 11:02:01 mini2x14 kernel: [653801.674003] Bluetooth: hci0: command 0x040a tx timeout
Sep 5 11:02:05 mini2x14 kernel: [653805.938356] Bluetooth: unknown link type 88
Sep 5 11:02:07 mini2x14 kernel: [653807.945327] Bluetooth: hci0: wrong event for mode 0
Sep 5 11:02:07 mini2x14 kernel: [653807.946055] Bluetooth: hci0: command 0x040a tx timeout
Sep 5 11:47:52 mini2x14 kernel: [656552.606614] Bluetooth: hci0: hardware error 0xdd
...
12:00:45 - latest temp/hum datapoint
...
Sep 5 12:00:46 mini2x14 kernel: [657326.545200] usb 3-1.1.3: reset full-speed USB device number 6 using ehci-pci
Sep 5 12:00:48 mini2x14 kernel: [657328.481169] Bluetooth: hci0: command 0x200b tx timeout
Sep 5 12:01:49 mini2x14 kernel: [657389.473585] Bluetooth: hci0: command 0x200b tx timeout
Sep 5 12:02:50 mini2x14 kernel: [657450.465885] Bluetooth: hci0: command 0x200b tx timeout
I do not think that the problem is somehow related to the component discussed here. Sounds like a driver/hardware issue (mac mini mid 2011 or 2012). An attempt to DOWN and UP hci0 device did not help, and the problem was solved only by rebooting. Digging further …
I arrived to this component from: https://github.com/home-assistant/home-assistant/issues/19326
Someone commented that this solves the issue… but it seems its something HASSOS related.
Under this issue someone write that bluetooth is in working condition. And the problem is with polling. This is different, yes. Since tsymbaliuk’s method does not use polling, but simply listens to the broadcasts, there really is no such problem with it. However, we remain hostages of the stable operation of bluetooth itself at the system and hardware levels… The only thing that can be done is to try to catch the occurrence of such a problem and somehow notify about it, or automatically make some sort of attempt to manipulate the bluetooth interface (in my case, unfortunately, only reboot helped).
As a workaround for my hardware error i will try this simple script (as a cron job):
#!/bin/bash
if /usr/bin/hciconfig hci0 | grep -q "UP RUNNING"; then
:
else
shutdown -r +1 "Blutooth is down! Server will restart in 1 minute. Please save your work."
fi