Hi. I’ve used your mitemp_plugin since september, and it worked great for me. it stopped working the other day, i think after some hcitool update.
With logging enabled, HASS spits out
2020-04-02 10:45:54 DEBUG (SyncWorker_7) [custom_components.mitemp_bt.sensor] Finished. Parsed: 0 hci events, 0 xiaomi devices.
ive moved my temp sensor (LYWSDCGQ) next to my board. lescan does find it. any idea what i can do to fix it?
tanks in advance
@Magalex
Thanks for the reply - are you referring to “home-assistant. log” - it doesn’t indicate anything special. just stops adding new info.
Same problem, I was going crazy knowing that it could be … I have HA core, raspberry pi 4 4gb and raspbian / docker / portainer, integrated bluetooth and 4 thermometers LYWSD03MMC … after 24h it saturates HA and it doesn’t work for me ( if I look at the CPU is at 100%) restarting HA solves the problem for 24H … and it happens again.
Recently, the bluez package was updated. The only thing I did in connection with this was to reboot the host. I did not notice any negative effects because of this update.
If you have not read it, then read our FAQ - it summarizes everything that we had to deal with. Make sure the status of the hci interface is UP (hciconfig cmd). Make sure that other bluetooth components do not enabled. Look carefully at the system logs. In general, more information is needed…
what else could i look at? hcitool lescan works, the python root access thingy works… i only have one bluetooth adapter, hci0, and its only being used by hass…
@roberdlv @dimaf
So far, I have not received feedback on this behavior of the system. You are the first. At the moment, I have no idea about the reasons for this. The only thing that affects the number of sensors is the load on the computing resources (component need to sort through more hci-events). Failure with increased load (in the case of raspberry) may be due to overheating or poor powering. I monitor the resource consumption of my component, and I do not see any signs of a memory leak in the current version (my data comes from three bt-interfaces and five sensors, but only two of them are LYWSD03). In the near future I will try to find some more LYWSD03 somewhere and load with them my raspberry pi 3b with Hassio).
As I said above, carefully review the system log (syslog). Pay attention to the time period corresponding to the stop of data reception.
A number of events equal to zero indicates problems in the operation of the bluetooth subsystem. I consider the conflict with another component such as bluetooth_tracker or other system utilities unlikely, because even then these events should be more than zero if my memory serves me right.
You should also not discard the power problem, because the failure can be at the hardware level (too many users in the case of raspberry pi solved their problems by replacing the power supply and cable).
@roberdlv @dimaf in continuation of my previous post
My test system:
Raspberry Pi 3b+, Hassio 32bit image: HassOS 3.12, Home Assistant 0.107.7
Duracell 3A power supply, high quality microusb cable (I don’t remember exactly the brand/model).
LYWSD03MMC: 4 sensors
LYWSDCGQ: 3 sensors
MiFlora: 1 sensor
Configuration:
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
# http:
# base_url: example.duckdns.org:8123
# Text to speech
tts:
- platform: google_translate
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
sensor:
- platform: mitemp_bt
rounding: False
period: 60
log_spikes: True
batt_entities: True
hci_interface:
- 0
encryptors:
"A4:C1:38:2F:87:6B": "217C568CF5D22808D120181502D84C1B"
"A4:C1:38:D1:6A:8D": "C99D2313182473B38A01086FEBF781BD"
"A4:C1:38:E6:5C:E7": "DAE14A7A1F620A18A8D842D642A14E92"
"A4:C1:38:BD:42:D0": "78430FD59BAABA433F4A7FBDB4179048"
report_unknown: True
- platform: rpi_power
text_state: true
- platform: systemmonitor
resources:
- type: disk_use_percent
arg: /home
- type: memory_use_percent
- type: load_1m
- type: load_5m
- type: load_15m
- type: processor_use
- platform: command_line
name: CPU Temperature
command: "cat /sys/class/thermal/thermal_zone0/temp"
unit_of_measurement: "°C"
value_template: '{{ value | multiply(0.001) | round(1) }}'
Some overheating (throttling) is reported (during system startups), but most of the time everything is fine. CPU load and memory consumption on graphs. I’ll wait a week, and update this post.
UPD. Added fifth LYWSD03MMC, screenshot updated.
Update since 10 days: everything works well, changing the period from 1 minute to 10 did not have a noticeable effect on the system load.
I continue with the problem, if I remove the sensors the system works perfect 4% of use all the time.
If I activate sensors, it works correctly at first and gradually increases and increases the percentage of use of the cpu until HA breaks and cannot be entered, if you restart HA it works correctly again or else if you disable bluetooth, HA it works again.
I also use a docker of this for my xiaomi scale and it is also bluetooth, this worked perfectly before putting the sensors, but I do not know if it creates any conflict with them. https://github.com/lolouk44/xiaomi_mi_scale
it managed to “sniff” one packet with the first version you made available, after re-pairing the sensor with the mi home app.
, nothing since
edit: its alive. i did not change anything, but its alive.
STOP Bluetooth and:
How long does it take after a reboot before a problem occurs?
I added the fifth LYWSD03 to my test system, so I get 5 sensors with encryption, plus four more regular ones (three of them are “fast”, which send 25 messages per minute) - I have not seen any negative effects yet. Updated my post. I look forward to…
20-26 hours maximum and charge my raspberry to the CPU limit
2020-04-04 17:35:23 ERROR (SyncWorker_12) [custom_components.mitemp_bt.sensor] Error during Bluetooth LE scan: cannot join thread before it is started
2020-04-04 17:59:57 ERROR (SyncWorker_8) [custom_components.mitemp_bt.sensor] Error during Bluetooth LE scan: cannot join thread before it is started
many of these also come out
This error indicates that the thread collecting data from the bt-interface did not manage to start until it should already be stopped (period option). What other features are your raspberry loaded with?
Try to increase the period to five minutes, for example.
On my test system, everything is fine, except for reports of overheating - my passive cooling is clearly not enough, I opened the lid of the case, I observe further.
As I said before I also use this component, is it possible that they interfere? Because since I added the sensors, my weight in HA has not measured me.
My raspberry docker:
Before adding sensors everything worked like silk, never hung or restart.
A conflict can occur with any other component that does not use a passive data reception. But I don’t see a connection here with an increase in the load (in terms of my component). The maximum that this always led to is the failure of one or the second component. One way out of this situation is to “explode” the operating time of the components (an experiment with the period option and a similar option for the second component, if any).
Published 0.6.4-beta with initial support for JQJCY01YM (Xiaomi Honeywell Formaldehyde Sensor, OLED display, broadcasts temperature, humidity, formaldehyde (mg/m³) and the battery, total about 50 messages per minute).
