Passive BLE Monitor integration

Normally this is an issue related to Bluetooth not having the correct sudo rights after a python update but these can also happen if there is an issue with the Bluetooth radio, or an error in the firmware of the bluetooth dongle. If it is all running fine now, I wouldn’t worry too much about it, if it continues check this issue on github.

ok, thank you

Hello Passive BLE Monitor integration team,

First of all thank you for the great peace of software. I have been running it for many months without interruptions. I am very satisfied and I am full of the respect to the owner.

Nevertheless for couple of days now I am fighting with the issue. Problem in points:

  • I am running Hassio (nevest update).
  • I have 6 peaces of LYWSD03MMC
  • Few days ago 2 of them just stopped showing data (didn’t refresh the state).
  • I have tried to:
    – restart HA, Hassio,
    – remove and add again faulty sensors from Home Assistant (correct with procedure),
    – changed battery,
    – generate new token. And here the weird part starts. I went to Telink Flasher v3.1 and generate new Bind Key. But when I copied it to the configuration file and restarted Home Assistant I get the error:

This error originated from a custom integration.

Logger: custom_components.ble_monitor.ble_parser.xiaomi
Source: custom_components/ble_monitor/ble_parser/xiaomi.py:585
Integration: Passive BLE monitor (documentation, issues)
First occurred: 5:44:29 PM (2 occurrences)
Last logged: 5:45:28 PM

Decryption MiBeacon V4/V5 advertisement failed: No encryption key found

With the error above the rest of 4 sensors still works fine.

I have been trying to search for resolution on web - no luck.
Yes, I have been here: My sensor stops receiving updates some time after the system restart. But when I run the final command ( nohup hciattach /dev/serial1 bcm43xx 460800 noflow - <MyMAC> &) the command crashig.
Additionally I have no SSD drive close to any of the sensors or my Hassio box.

Can I kindly ask someone for help? Maybe someone has this error before.

Did you update to ble monitor 2.6.3? There is a fix for encryption keys that were sometimes not found from config.

1 Like

Great! Haha, Thank you @Ernst. I can promise, that i updated BLE yesterday or two days ago.
It doesn’t matter, after your advise I have double checked tnd yes! It was it!
Again, thank you for help and quick reply. You have made my day.

2.7.1 Released - Encrypted ATC support
Version 2.7.1 adds support for ATC sensors with encryption. In ATC firmware version 3.2, you can now enable encryption for BLE messages in one of the ATC advertising formats. This will encrypt the advertisements.

In 2.7.1 of BLE monitor, you can now read these advertisements by adding the encryption key in your configuration. This is a 32 character long key, which can be found (and changed) in the settings of your ATC firmware via the TelinkFlasher webpage. Copy this encryption key into the configuration of your device (options - devices - MAC address - encryption key).

BREAKING CHANGES in 3.0.0

We have released 3.0.0 with some small breaking changes. So, before upgrading, please read carefully.

Yeelight dimmer and Yeelight smart switch

The following sensors will have a breaking change in this release. Please verify your configuration settings.

  • YLAI003: The time after which the sensor state returns to no press has been changed from a fixed value of 1 second to the time that can be set with the reset_timer option (default 35 seconds).
  • YLKG07YL, YLKG08YL: The sensor state will now return to no press after the time that is set with the reset_timer option (default 35 seconds). If you don’t want this, you can return to the old behavior by setting the reset_timer to 0 seconds.

It is advised for both sensors to change the reset_timer to a relatively short period, e.g. 1 second.

Battery entities

  • Removal of the generate battery entities option.
    • The option batt_entities has been removed (it will display a warning if still in your YAML configuration). BLE monitor will, from now on, always generate the battery and/or voltage entities. HA has built in functionality to disable these sensors.

New sensor: Qingping Bluetooth clock (CGC1)

  • This device (most likely) requires an encryption key. If you have information about update frequency, encryption key requirement, and/or a log with report_unknown: "qingping", we can improve the documentation and implement qingping format support without encryption. Please open an issue if you want to help us with this information.

CGC1

Other changes

  • Rewriting sensor and binary sensor (part 6)
    • Optimization of the code to make it easier to add future sensors

What are some advantages/disadvantages between this integration and ESPHome BLE tracker, besides the obvious that ESPHome requires an add-on and external hardware? Has anyone tried both and can share their experience? Is one more reliable or more actively maintained?

The main difference is that ESPHome is using external ESP32 hardware, while BLE monitor uses the Bluetooth of the system HA is running on (e.g. raspberry pi). So the main choice for one or the other will be the Bluetooth range. If the sensor is close to your HA machine, you can use BLE monitor, ESPHome can be used for sensors further away.

Another important difference is the number of supported sensor types, I counted 13 supported sensors for ESPhome, while BLE monitor supports 38 sensor types at the moment. But on the other hand, ESPhome support many other things, so you could combine things. In BLE monitor, we are working on Thermosmart sensors and Govee sensors at the moment.

Both integrations are actively maintained, ESPHome is actually part of the Nabu Casa. But BLE monitor is also actively maintained, just look at the number of updates last weeks (:slight_smile:). And it is one of the most installed custom_integrations on HACS, I think.

So, both have their cons and pros, it mainly depends on what you need (supported sensors), the location of the sensor and the (bluetooth) hardware you already have.

2 Likes

Hello! Maybe someone asked, but I didn’t find it. Tell me, is it possible in this integration to support other bluetooth devices, such as a phone or bluetooth tags?

No, not yet. We made a start in the past, but didn’t finish. But we will implement this in the future, but it will take some time.

Could someone please tell me what I’m doing wrong.

I have 4 devices added via the gui listed in the devices dropdown but HA only shows “3 devices” on the integration page. The missing device (HHCCJCY01) was deleted earlier via gui for troubleshooting then re-added. I’ve tried to delete and re-add again, restart HASS, reboot the entire PC but the problem remains. There are no remnants of the deleted device in the core.devices_registry file.

The device is found by CLI bluetooth scan.

Device (new): c4:7c:8d:63:d9:2f (public), -77 dBm 
      Flags: <06>
      Incomplete 16b Services: <0000fe95-0000-1000-8000-00805f9b34fb>
      16b Service Data: <95fe31029800002fd9638d7cc40d>
      Complete Local Name: 'Flower care'

Here’s the debug log showing my current integration settings.

2021-06-08 17:09:07 DEBUG (MainThread) [custom_components.ble_monitor.config_flow] async_step_init (before): {'bt_interface': ['30:3A:64:5A:37:8B'], 'period': 60, 'discovery': True, 'active_scan': False, 'decimals': 1, 'log_spikes': False, 'use_median': False, 'restore_state': True, 'report_unknown': False, 'devices': [{'mac': 'A4:C1:38:3C:75:B7', 'temperature_unit': '°C', 'name': 'Bedroom climate sensor'}, {'mac': 'C4:7C:8D:63:D9:2F', 'temperature_unit': '°C', 'decimals': 'default', 'use_median': 'default', 'restore_state': True, 'reset_timer': 35}, {'mac': 'A4:C1:38:F8:16:96', 'temperature_unit': '°C', 'name': 'Living Room climate sensor'}, {'mac': '5C:CA:D3:95:78:E7', 'temperature_unit': '°C', 'decimals': 'default', 'use_median': 'default', 'restore_state': 'default', 'reset_timer': 35, 'name': 'MIBFS'}], 'is_flow': True, 'hci_interface': [0]}

Lastly, I’m not sure if it’s related but I see the following line repeated in the debug log.

2021-06-08 17:09:08 DEBUG (Thread-225) [custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d

The last debug log is an advertisement that isn’t useful, it only contains a MAC address and RSSI, no data. This debug message is saying that it is ignoring this message, which is OK.

The same applies for the advertisement you show with the CLI bluetooth scan, this adv. only shows a MAC address and RSSI value in the payload.

Could you check if you can find longer advertisements. Your config look OK btw.

Hi Ernst. Thanks for the response. Does this bluetoothctl scan help?

[CHG] Device C4:7C:8D:63:D9:2F RSSI: -77
[CHG] Device C4:7C:8D:63:D9:2F UUIDs: 0000fe95-0000-1000-8000-00805f9b34fb
[CHG] Device C4:7C:8D:63:D9:2F ServiceData Key: 0000fe95-0000-1000-8000-00805f9b34fb
[CHG] Device C4:7C:8D:63:D9:2F ServiceData Value:
  31 02 98 00 00 2f d9 63 8d 7c c4 0d              1..../.c.|..   

The debug log doesn’t seem to have anything else related to this device other than what I had posted earlier.

2021-06-08 19:11:01 DEBUG (Thread-3) [custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d
2021-06-08 19:11:03 DEBUG (Thread-3) [custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d
2021-06-08 19:11:04 DEBUG (MainThread) [custom_components.ble_monitor.binary_sensor] 0 MiBeacon BLE ADV messages processed for 1 binary sensor device(s) total. Priority queue = 0
2021-06-08 19:11:06 DEBUG (Thread-3) [custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d
2021-06-08 19:11:06 DEBUG (MainThread) [custom_components.ble_monitor.sensor] 3 BLE ADV messages processed for 3 measuring device(s).
2021-06-08 19:11:06 DEBUG (Thread-3) [custom_components.ble_monitor] HCIdump thread: main event_loop stopped, finishing
2021-06-08 19:11:06 DEBUG (Thread-3) [custom_components.ble_monitor] HCIdump thread: Scanning will be restarted
2021-06-08 19:11:06 DEBUG (Thread-3) [custom_components.ble_monitor] 2073 HCI events processed for previous period.
2021-06-08 19:11:06 DEBUG (Thread-3) [custom_components.ble_monitor] HCIdump thread: Run
2021-06-08 19:11:06 DEBUG (Thread-3) [custom_components.ble_monitor] HCIdump thread: connected to hci0
2021-06-08 19:11:06 DEBUG (Thread-3) [custom_components.ble_monitor] HCIdump thread: start main event_loop
2021-06-08 19:11:07 DEBUG (Thread-3) [custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d
2021-06-08 19:11:08 DEBUG (Thread-3) [custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d
2021-06-08 19:11:08 DEBUG (MainThread) [custom_components.ble_monitor.sensor] Data measuring sensor received: {'rssi': -66, 'mac': 'A4C138F81696', 'type': 'LYWSD03MMC', 'packet': 56, 'firmware': 'Xiaomi (MiBeacon V3)', 'data': True, 'battery': 71, 'voltage': 2.839}
2021-06-08 19:11:12 DEBUG (Thread-3) [custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d
2021-06-08 19:11:20 DEBUG (MainThread) [custom_components.ble_monitor.sensor] Data measuring sensor received: {'rssi': -74, 'mac': 'A4C1383C75B7', 'type': 'LYWSD03MMC', 'packet': 153, 'firmware': 'Xiaomi (MiBeacon V3)', 'data': True, 'temperature': 26.6, 'humidity': 56.0}
2021-06-08 19:11:29 DEBUG (Thread-3) [custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d

No, it is still only broadcasting your MAC (reversed) + 1 byte of the RSSI strength (last 7 bytes).

I think the issue is that your sensor isn’t connected/added in MiHome. Some/most sensors require to be added to MiHome first, before they start sending temperature and humidity data. Can you check that it is added in MiHome?

Hi Ernst. Thank you for the suggestion. It’s finally working.

The MiHome app wasn’t able to find the device on scan. I tried the Flower Care app which did connect, but still wasn’t detected in HA. After a few minutes the app alerted me to a device firmware upgrade from 2.7.0 to 3.3.1, which I did, and now the device is working in HA.

I also no longer see the following error in the debug logs.

[custom_components.ble_monitor.ble_parser.xiaomi] Xiaomi device data is using old data format, which is not supported. Data: 0f1695fe31029800002fd9638d7cc40d

3.1.1 Release

  • Added support for Xiaomi Honeywell smoke detector (Bluetooth) (JTYJGD03MI)
  • Added support for Thermoplus thermo/hygrometer sensors (smart hygrometer, lanyard hygrometer and mini hygrometer)
1 Like

Xiaomi Kettle temperature stooped working after update to latest version:
opened issue on github: Xiaomi Kettle temperature stooped working · Issue #401 · custom-components/ble_monitor · GitHub

can you please help to check?

3.2.1 has been released

As you may have noticed, there have been quite some updates lately. I needed to rewrite large parts of the code as over time the integration grew, supporting more and more sensors, not only Xiaomi’s, but also others. This was not always added as structured as I would have liked. So it was time to set things up more efficient, at least for me, which allows me to add future sensors easier, with less code. It might have caused some issues, that were working fine in the past, sorry for that. Most of the work is done with this release, so I can now concentrate on adding new sensors. I will also look into the possibility of adding a device tracker for BLE devices, but this will take some more time.

The changes:

BREAKING CHANGE for Yeelight remotes

  • Added a reset timer for Yeelight remotes.
    The state will now return to no press after the time set by the reset_timer option (default 35 seconds). It is advised to change it to 1 second. Alternatively you can turn it off by setting it to 0 seconds (this is the previous behavior before this update).

Other changes

  • Add support for Linptech K9B switch (1, 2 and 3 button versions)
  • Fix for Kettle temperatures causing an error above 60 degrees (fixes the above post)
  • Fix for ATC encryption key not found
  • Rewrite of sensor classes

there is support for xiaomi mosquito 2?