Hello,
I have a LYWSD03MMC which is successfuly working with the hacs component. In addition I also have a LYWSDCGQ. Due to the hacs mitemp_bt component, I had to remove the “mac:xxx:xxx…” line and now I don’t know how to connect this sensor to my home assistant.
Any idea ?
thanks a lot !
Nothing needs to be configured (additional) for LYWSDCGQ.
If you have custom.mitemp_bt installed and the signal from the sensor reaches your host, then the corresponding entities will appear automatically.
Ok, now it works, the sensor was to far away therefore it was not connected.
Thanks a lot !
Version 0.6.8 with whitelist option and Xiaomi Mija Mosquito Repellent WX08ZM support released
Hello
i have been using your addon @Magalex for a two months now. I believe, that is the best option to make my three: LYWSD03MMC work under HA. I want to thank you for it very much.
I am reading all this statements above and starting thinking, that my configuration is wrong. Why? Because:
Can you please (or anybody) tell me how to find the error?
My most recent configuration:
sensor:
- platform: cpuspeed
- platform: mitemp_bt
rounding: True
decimals: 1
period: 60
log_spikes: False
use_median: False
active_scan: False
hci_interface: 0
batt_entities: True
encryptors:
'A4:C1:38:27:89:42': '2432BE8CE73F450CE7A306AA6505DBAA'
'A4:C1:38:62:A4:DE': 'F51745017DC51AE127CB704599E1F40E'
'A4:C1:38:8B:CF:37': 'F9241D0AD4CA8741A2980C6BBE209DF4'
whitelist: True
EDIT: Obviously, as you wrote in point 6 in your installation manual, I left the sensors paired with my mobile.
EDIT2: Versions: Home Assistant 0.109.4 and BLE monitor 0.6.8.
Hmm. Let’s figure it out…
Keys can fly off only if the sensors have passed the pairing procedure. In any case, I am not aware of other reasons. Even changing the battery does not reset the keys.
Thank you for so quick reply. I will try to be as much precise as possible. Please bear in mind, that I quite new HA user, so some answers can be a little bit funny.
You mean log from: Supervisor > System > Supervisor, Core, Host, DNS, … ?
Done that. I restarted HA after that, and found nothing suspicious in above logs. Maybe one thing - the time is 2hrs in the past. I will be happy to paste it here, but can you please tell me which one is that?
This is Hassio on Ubuntu (Ubuntu 18.04.4 LTS) installation (on laptop) on docker. I followed this video: https://www.youtube.com/watch?v=ekVfLXnoM7k
I am getting new keys by using this modified app: https://www.kapiba.ru/2017/11/mi-home.html. Basically I installed the app, created folders, pair the sensors and open the file which contained bind keys.
Ok, so you are saying, that after I have go the bindkeys I should remove sensors from xiaomi app, right?
You mean log from: Supervisor > System > Supervisor, Core, Host, DNS, … ?
No, I mean “Developer Tools > LOGS”
I am getting new keys by using this modified app: ЗАПИСКИ ЛЕНИВОГО ЭНТУЗИАСТА: Модифицированный Mi Home с множеством приятных дополнений. Basically I installed the app, created folders, pair the sensors and open the file which contained bind keys.
What interests me is not the way to get the keys, but what were you based on when you made the decision to change the keys? The fact is that if the key does not match, then in the log (indicated above) there will be a corresponding error message. If it is not, then the reason is different.
Ok, so you are saying, that after I have go the bindkeys I should remove sensors from xiaomi app, right?
No, no, you must not remove sensors from the application in any case (keys will be lost). Just make sure the application is not active (just in case). When an application is active, it can connect to the sensor, which is why it stops broadcasting.
Ok, thank you for giving info about the logs. I don’t want to make mess here but in short this is what i have got from Hassio:
Got exception while fetching the state: No response from the device
9:45:59 PM – xiaomi_miio (WARNING) - message first occurred at 9:30:59 PM and shows up 32 times
Got error when receiving: timed out
9:45:59 PM – components/xiaomi_miio/vacuum.py (ERROR) - message first occurred at 9:30:59 PM and shows up 32 times
Updating xiaomi_miio vacuum took longer than the scheduled update interval 0:00:20
9:45:58 PM – Vacuum (WARNING) - message first occurred at 9:32:22 PM and shows up 12 times
Update of vacuum.xiaomi_vacuum_cleaner is taking over 10 seconds
9:45:48 PM – __main__.py (WARNING) - message first occurred at 9:31:30 PM and shows up 31 times
Error handling message: required key not provided @ data['category']. Got None
9:31:08 PM – Home Assistant WebSocket API (ERROR)
Setup of vacuum platform xiaomi_miio is taking over 10 seconds.
9:30:48 PM – Vacuum (WARNING)
Setup of binary_sensor platform ping is taking over 10 seconds.
9:30:48 PM – Binary sensor (WARNING)
Setup of sensor platform command_line is taking over 10 seconds.
9:30:48 PM – Sensor (WARNING)
Regarding changing keys itself. Why did I started to changed them?
I found the red Icon called “restored” from Configuration> Entities. Once I get this icon, the values never show. If this icon dissapear (after changing bindkeys) I always received temperature and humidity values.
Ok, i switched off bluetooth on my mobile and the app itself.
This is normal behaviour when restarting HA. In this case, the sensor has the state UNAVAILABLE. At least one period (your period option) must elapse after a restart so that entities are updated. If during the first period HA has not received data from the sensor, sensor state changes to UNKNOWN. Since LYWSD03 sends data approximately once every 10 minutes (battery once per hour), it may take 10-12 minutes before the actual sensor reading appear.
That is clear for me, unfortunately I am waiting way much longer after restart to be able to see new (most recent) data from sensors. This is what I have get:
Ok to clarify.
Config is ok, right?
To get the bindkeys I should use the app (add the sensors) and straight after that I should switch off app/bluetooth an the bindkeys paste to my configuration. Restart the HA an leave it for the night, yes? It dosn’t metter are the letters are as capital or not.
There is nothing related to the sensors in logs, right? I haven’t found anything interesting, but as I said I am newbie. So I rather to kindly ask.
Is the above make sense?
Yes. Your configuration looks good.
Yes. Yes. In fact, turning off Bluetooth is not necessary. It may not even be necessary to unload the application from memory - I advise you to try this for confidence.
Yes. In the log, you showed there, is nothing related to our component.
In general, for now, I suggest that you tolerate and just wait. Depending on further behaviour, we will decide what to do next. Check the log from time to time. If the sensors still do not appear, then you must enable debugging mode, as I wrote above.
Hi there!
Im kinda new in the home automation world
I’m trying to setup 3 LYWSD03MMC devices, but no one is shown on dashboard.
Here is my setup:
sensor:
- platform: mitemp_bt
encryptors:
'A4:C1:38:3A:CC:43': '952c3c97473f5d72e36d7582341bbc8f'
'A4:C1:38:4D:37:6B': 'b170ae40ab3e7e923c93f41f354b7238'
'A4:C1:38:1D:7F:40': '1ec5c4897da65037a9e1ebe9610e8132'
decimals: 1
period: 60
log_spikes: False
use_median: False
active_scan: False
whitelist: False
The logs shows:
2020-05-06 00:08:26 DEBUG (Thread-28) [custom_components.mitemp_bt.sensor] HCIdump thread: start main event_loop
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] update_ble called
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] Discovering Bluetooth LE devices
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] Time to analyze...
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] Getting data from HCIdump thread
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] HCIdump thread: joining
2020-05-06 00:09:27 DEBUG (Thread-28) [custom_components.mitemp_bt.sensor] HCIdump thread: main event_loop stopped, finishing
2020-05-06 00:09:27 DEBUG (Thread-28) [custom_components.mitemp_bt.sensor] HCIdump thread: Run finished
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] HCIdump thread: joined
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] Spawning HCIdump thread(s).
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] HCIdump thread: Init
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] HCIdump thread: Init finished
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] Starting HCIdump thread for hci0
2020-05-06 00:09:27 DEBUG (Thread-29) [custom_components.mitemp_bt.sensor] HCIdump thread: Run
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] HCIdump threads count = 1
2020-05-06 00:09:27 DEBUG (SyncWorker_6) [custom_components.mitemp_bt.sensor] Finished. Parsed: 0 hci events, 0 xiaomi devices.
2020-05-06 00:09:27 DEBUG (Thread-29) [custom_components.mitemp_bt.sensor] HCIdump thread: Connection
2020-05-06 00:09:27 DEBUG (Thread-29) [custom_components.mitemp_bt.sensor] HCIdump thread: Connected
2020-05-06 00:09:27 DEBUG (Thread-29) [custom_components.mitemp_bt.sensor] HCIdump thread: start main event_loop
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] update_ble called
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Discovering Bluetooth LE devices
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Time to analyze...
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Getting data from HCIdump thread
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump thread: joining
2020-05-06 00:10:28 DEBUG (Thread-29) [custom_components.mitemp_bt.sensor] HCIdump thread: main event_loop stopped, finishing
2020-05-06 00:10:28 DEBUG (Thread-29) [custom_components.mitemp_bt.sensor] HCIdump thread: Run finished
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump thread: joined
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Spawning HCIdump thread(s).
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump thread: Init
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump thread: Init finished
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Starting HCIdump thread for hci0
2020-05-06 00:10:28 DEBUG (Thread-30) [custom_components.mitemp_bt.sensor] HCIdump thread: Run
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] HCIdump threads count = 1
2020-05-06 00:10:28 DEBUG (SyncWorker_8) [custom_components.mitemp_bt.sensor] Finished. Parsed: 0 hci events, 0 xiaomi devices.
I read the documentation but i don’t know what i missing 
Thanks in advance
Hello! The entry with the text Parsed: 0 hci events,... is an alarming entry, often saying that something is wrong at the system level.
Describe in more detail your system - hardware, software, how do you install Home Assistant.
Thanks for the reply
i installed Home Assistant Supervised with the following script https://github.com/home-assistant/supervised-installer
arch x86_64
dev false
docker true
hassio true
os_name Linux
os_version 5.6.10-arch1-1
python_version 3.7.7
timezone Europe/Madrid
version 0.109.4
virtualenv false
Lovelace
dashboards 1
mode auto-gen
resources 0
CPU: Intel Celeron G1610T (2) @ 2.300GHz
Bluetooth: 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Memory: 1077MiB / 3758MiB
if i miss something just ask
Do you have the ability to run the hcitool lescan command outside and inside the container?
Also, check the system log for any errors related to bluetooth.
Perhaps the matter is access rights to the bt interface. I definitely can’t tell you how to check this in the case of docker. The bottom line is that the process working with the bt-interface should get the rights, as indicated here(step 1). Probably in the case of Docker, these rights should be granted both inside the container to the python process and to the container itself. But I can be wrong, because I have no experience with docker…
Googling on your dongle’s ID shows that it could be a pretty old device. Is it supports Bluetooth Low Energy (has been included in the Bluetooth specification since version 4.0)?
must be the case. going to buy a new one, and report back. Again, thanks for your time.
The Bluetooth 4.0 specification was approved in 2010. I just don’t want you to waste money. Maybe you should make sure that this is the case?
You can try to run:
sudo hciconfig hci0 version
or
sudo btmgmt info
or
sudo hciconfig hci0 lestates
and post output here
sudo hciconfig hci0 version
hci0: Type: Primary Bus: USB
BD Address: 00:22:F7:17:D5:75 ACL MTU: 310:10 SCO MTU: 64:8
HCI Version: 2.1 (0x4) Revision: 0x149c
LMP Version: 2.1 (0x4) Subversion: 0x149c
Manufacturer: Cambridge Silicon Radio (10)
sudo btmgmt info
Index list with 1 item
hci0: Primary controller
addr 00:22:F7:17:D5:75 version 4 manufacturer 10 class 0x000104
supported settings: powered connectable fast-connectable discoverable bondable link-security
sudo hciconfig hci0 lestates
Can't read LE supported states on hci0: Input/output error(5)