Passive BLE Monitor integration (Xiaomi Mijia BLE MiBeacon monitor)

Yes, you are right. Seems like it is energy saving.
Found info how to fix it: https://askubuntu.com/questions/772056/keyboard-stops-working-on-ubuntu-16-04-xenial-xerus

Hi all,
Iā€™ve installed the component, last version, but it doesnā€™t see my two (rounded) sensors, LYWSDCGQ, Iā€™ve put them close to my pi3, I linked them again to the mihome app, but they donā€™t appear in HA.
They worked before using the standard config (even if they stopped sending data after a while, the reason I installed this component).

The only log I found is running ā€œbtmon -t -w problem.logā€ that return this message:
Bluetooth monitor ver 5.50
Failed to bind channel: Operation not permitted
Is there something I can do ?

thanks

Hello! I see you read our FAQ, so Iā€™ll ask did you enabled the debugging level of logging for the component? If enabled, then show log for a couple of periods.

You know what? now itā€™s working :slight_smile:
Itā€™s like enabling the debugging mode kinda gave it the right push.

Many thanks anyways,
Iā€™ve other devices I need to add so I may come back at you soon :slight_smile:

Since the BLE ADV message parser code is common for all supported devices, if it works with one sensor, it will work with others.
Or do you have something interesting from the unsupported so far?

No no, Iā€™ve the rect LYWSD02, and a couple of MIFlora and Mosquito Repellent.

There are subtleties with the MiFlora sensor - in earlier versions it does not send BLE ADV messages, so it may be necessary to update its firmware in addition to pairing it with the MiHome app.

Thanks, I will.
Ok, Iā€™ve commented the logger lines in conf and the sensors stopped to be seen.
So I need to keep the logger active?

This canā€™t be) The code in debug mode is no different from normal mode (in fact, debug messages are also sended in normal mode, they just filtered out in the HA core).
How do you check for sensors presence?

I saw them, they appeared into my HA, but ā€¦ I fear I updated HA to the latest version ā€¦ without thinking (I know I shouldnā€™t have). And I suspect thatā€™s may be the main cause of the issue. Iā€™m trying to downgrade it (but apparently itā€™s harder than I thought, on docker).

Hm. I can only say that the component works in the latest versions of HA without any problems. I am testing it in the official image for RPi3b and in Python virtual env on Debian 9.

Where did they appear in HA? In the dev tools, in the frontend, where else? Please, be more specific, before you try the stunt on downgrading your HA version. The more info you give the easier it is to help! :slight_smile:

They appeared once in the front end. Actually, since they were already configured the ā€œmissing sensorsā€ warnings disappeared too.
(Iā€™ve downgraded but without any luck).
Iā€™m using it on a RPi3b too, hassio on docker.

Here the debugger log, that seems to find them BTW:

2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] update_ble called
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] Discovering Bluetooth LE devices
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] Time to analyze...
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] Getting data from HCIdump thread
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] HCIdump thread: joining
2020-05-11 16:01:04 DEBUG (Thread-18) [custom_components.mitemp_bt.sensor] HCIdump thread: main event_loop stopped, finishing
2020-05-11 16:01:04 DEBUG (Thread-18) [custom_components.mitemp_bt.sensor] HCIdump thread: Run finished
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] HCIdump thread: joined
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] Spawning HCIdump thread(s).
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] HCIdump thread: Init
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] HCIdump thread: Init finished
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] Starting HCIdump thread for hci0
2020-05-11 16:01:04 DEBUG (Thread-21) [custom_components.mitemp_bt.sensor] HCIdump thread: Run
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] HCIdump threads count = 1
2020-05-11 16:01:04 DEBUG (Thread-21) [custom_components.mitemp_bt.sensor] HCIdump thread: Connection
2020-05-11 16:01:04 DEBUG (Thread-21) [custom_components.mitemp_bt.sensor] HCIdump thread: Connected
2020-05-11 16:01:04 DEBUG (Thread-21) [custom_components.mitemp_bt.sensor] HCIdump thread: start main event_loop
2020-05-11 16:01:04 DEBUG (SyncWorker_0) [custom_components.mitemp_bt.sensor] Finished. Parsed: 1831 hci events, 4 xiaomi devices.
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] update_ble called
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Discovering Bluetooth LE devices
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Time to analyze...
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Getting data from HCIdump thread
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump thread: joining
2020-05-11 16:02:05 DEBUG (Thread-21) [custom_components.mitemp_bt.sensor] HCIdump thread: main event_loop stopped, finishing
2020-05-11 16:02:05 DEBUG (Thread-21) [custom_components.mitemp_bt.sensor] HCIdump thread: Run finished
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump thread: joined
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Spawning HCIdump thread(s).
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump thread: Init
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump thread: Init finished
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Starting HCIdump thread for hci0
2020-05-11 16:02:05 DEBUG (Thread-22) [custom_components.mitemp_bt.sensor] HCIdump thread: Run
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump threads count = 1
2020-05-11 16:02:05 DEBUG (Thread-22) [custom_components.mitemp_bt.sensor] HCIdump thread: Connection
2020-05-11 16:02:05 DEBUG (Thread-22) [custom_components.mitemp_bt.sensor] HCIdump thread: Connected
2020-05-11 16:02:05 DEBUG (Thread-22) [custom_components.mitemp_bt.sensor] HCIdump thread: start main event_loop
2020-05-11 16:02:05 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Finished. Parsed: 1761 hci events, 4 xiaomi devices.

Yes, judging by the log, everything is fine.
Check the list of entities in Developer Tools -> States, filter by text sensor.mi_

Ok, now I see them there. I upgraded to the latest version. I surely messed up things somewhere in -between.
Many thanks Magaleg,
so they donā€™t appear as ā€œNew devices discoveredā€ nor appear automatically on the front end. They need to be manually added.

Yes, sensors do not appear with notifications as newly discovered devices.
Such behaviour, as I understand it, is available only in integrations that are transited into configuration from the UI. There are some difficulties with this, mostly related to purely technical issues, and I have not yet decided what to do with it, since many users are indignant at switching to configuring from the UI only. I have this transition in the todo list, but so far there are more important tasks.

i am getting these errors since a while with bluetooth on an rpi3:
[62185.735832] Bluetooth: hci0: Frame reassembly failed (-84)
[62185.736069] Bluetooth: hci0: Frame reassembly failed (-84)
[62185.736198] Bluetooth: hci0: Frame reassembly failed (-84)
[62185.736305] Bluetooth: hci0: Frame reassembly failed (-84)

What could be the problem? Mitemp is not working anymore

This is a known bluetooth issue on raspberry pi. What is your system? Official Hassio image? Which version?
Look at this pinned issue on GitHub - there the user found a potential solution. In addition, in the latest version of HassOS, there were some fixes aimed at solving this problem, but I donā€™t know how successfully, on my RPi3b+ I did not encounter this problem.
In addition, if my memory serves me right, there was feedback from users who solved problems with bluetooth by replacing the power supply and the power cord with better ones (do not underestimate this solution!).

Hi there.

Iā€™m a not-happy-right-now owner of three MMCs. Everything was working fine(RPI3 official 32bit) until I moved out to aarch64 hassio image and placed RPi a bit further in a locker. RSSI went down and now one of three is sometimes recognized and parsed(60~ RSSI when measured on phone) however, two placed further than the working one donā€™t work(80+, but we can take into account that RPi3 has a weaker receiver than a one plus 7) I tried different tricks(f.e. disabled Wi-Fi via config.txt) or moving out to official component(that dies on timeout in that scenario).
I started looking around and noticed that
[ 259.458532] Bluetooth: hci0: Frame reassembly failed (-84)
also appears in my dmesg, despite having 3.13 hassio version.
Is there anything that I can hack out of internal BT(I first thought of filters, because btmon shows about 600~ events each scan). I have a dedicated power charger, so rather not that way.
In the end I may try to convince myself for buying an external dongle - is there anything that you are recommending on the market? Iā€™m wondering which chip providing BLE has the best support on Linux.

Passive reception (implemented in this component) works better in such situations, so it makes no sense to try components that use the connection to the sensor (such as the original mitemp_bt).

Unfortunately, I canā€™t recommend a specific chip, I donā€™t have statistics on themā€¦ When I was asked to implement support for collecting data from several interfaces, I also asked myself this question, but could not choose anything (I tried to find something inexpensive with the external antenna), so as extra dongles I took two of my existing boards on the nrf52840 chip and flashed them with the Zephyr project (hci_usb example). But this is the way for maniacs :slight_smile: and requires certain knowledge and skills. If interested, I can tell you in more detail (but Iā€™m not sure that I can remember in detail all the nuances).

Of course, little can be done with the built-in moduleā€¦ But I think that itā€™s worth looking on the Internet for articles from craftsmen who have attached an external antenna to the RPi, but you should think about this option if the aforementioned above error does not lead to a complete stop of data reception.

Also in our FAQ, there is a little about ways to solve problems with the reception - maybe there you will find something useful for yourself.
By the way, not so long ago, one good guy wrote code for ESPhome that implements support for all sensors from my component. You can see it here if the option with external ESP32 suits you.

While there are no more thoughtsā€¦ If something comes to mind - I will write.