@Jose_Henrique_Costa @nickrout is right.
custom.mitemp_bt is designed to work with HomeAssistant on a Linux host system. You cannot just transfer its configuration to ESPHome - this does not work, unfortunately.
Thanks, @nickrout and @Magalex!
It is clear now. I am running my Home Assistant in an old netbook and it does not have BLE. Then, I am using ESPHOME and NODEMCU as a BLE Tracker for my Mi Flora devices, for example.
Looking at esphome.io website I see that esphome is compatible with others Mijia Umidity and Temperature sensores but not with this ‘new’ one yet.
Thanks,
Jose.
External dongle is not making any difference. If I swap locations of 2 devices, the one that was read isn’t and the one that wasn’t read is 
. I’ll have to go back to my polling system for now unfortunately.
There can be no difference. And if it is not, then there is a specific reason for this. Did you changed the number of the hci interface in the component settings?
Often a good result is the connection of the bt dongle on a usb extension cord (as with zigbee dongles).
Ha, changed the config to include both and now it is working great!! I’d assumed (fatal) that 0 would be the internal one. Obviously it isn’t.
One point, is it possible to include a timeout configuration i.e. when no data received after the timeout time, the entity is set as unavailable.
I think it is possible.
Relying on the last_updated attribute, you can make a simple binary sensor for all sensors, or break them into groups (different binary sensors) by broadcasting interval.
For example:
binary_sensor:
- platform: template
sensors:
bt_stuck:
friendly_name: "BT"
value_template: >-
{% set btvalues = [
states.sensor.mi_t_1.last_updated,
states.sensor.mi_t_2.last_updated,
states.sensor.mi_h_1.last_updated,
states.sensor.mi_h_2.last_updated]%}
{{ (as_timestamp(now())-as_timestamp(btvalues | max)) > 120 }}
device_class: problem
icon_template: >-
{% if is_state("binary_sensor.bt_stuck", "on") %}
mdi:bluetooth-off
{% else %}
mdi:bluetooth
{% endif %}
The state of this binary sensor will be changed when more than 120 seconds will pass from the moment of updating of “last updated” sensor.
1 Like
Hi @Magalex,
I run home assistant 0.103.5 in docker on a raspberry pi 4 and python version is 3.7.5.
I’m trying to test if I still get the error with the last stable docker image.
Hello, @pagigta
As far as I understood from the information on the link that I gave you above, such an error occurs when the Python was compiled without bluetooth socket support (the libbluetooth-dev package must be installed before the Python compilation). I can be mistaken, of course, but I understood just that …
UPD. A! I understood. You had an old image. Keep us posted.
Yes I realised that, I was just suggesting a builtin feature 
How to obtain the key of the device, such as this 217C568CF5D22808DA20181502D84C1B
How to obtain the device key, for example217C568CF5D22808DA20181502D84C1B
I tried, but I didn’t succeed
Hi,
Will this work with pi zero w and LYWSD03MMC? Should I see anything in the logs if I did anything wrong? I can only see that my home assistant got slower when installing this. I can see no new sensor and nothing regarding this in logs. I’ve installed via HACS.
It worked with RPI4 OOTB - it took some time, but if you follow instructions it should be fine.
1 Like
The computing resources of pi zero are quite limited, but I see no reason that the component does not work on it. @panec is right, the only thing that distinguishes LYWSD03MMC from most other sensors is encrypted messages, so you need to get the encryption key and specify it in the encryptors option.
Hi,
The slowdown is that great that HA becames mostly unusable. It took me 1h to change the config to disable Bluetooth and this component :< The most performance hit was when enabled
device_tracker:
- platform: bluetooth_tracker
I’m still not sure how to get this working on Pi zero w 
I have the clean hass.io install. Is there any manual step by step on how to do that? I’m quite new to all of this.
For now, I have only one LYWSD03MMC but another 4 are on the way and would be great to have them supported in HA
The first thing I would like to draw your attention to is the fact that the custom component discussed here and bluetooth_tracker will conflict (if you have only one bt-interface), that is, only one of them will work as it should, or none of them at all… This situation is described in our FAQ. Personally, I refused (long before I took up this custom component) from using bluetooth trackers because of their unreliability and short range. With wifi (platform: snmp + mikrotik router) I achieved much better results.
As for my component, I see no reason for a really serious load in its code, because between the sensor updates its operation is extremely minimal. The load increases after the time specified in the period option has elapsed. And the time required to sort through all packets received during the measurement period can be clarified by turning on the debugging mode (as described here).
I have no experience with pi zero, but let me assume that such a strong impact on performance may be due to the fact that HA, when you turn on any new component, first sets the necessary dependencies for it to work… Do subsequent restarts also take a lot of time? I suggest you be patient and try (leave only my component turned on).
In general, judging by the reviews on the Internet, pi zero is slow, yes, and if you plan to expand the capabilities of your smart home, then you should think about another platform.
I suggest you also consider these common causes of raspberry slowdown: poor power (you need a high-quality power supply and cable), a slow SD card (google about SD card speed classes and raspberry pi compatibility), poor cooling (thermal throttling is taking place).
1 Like