@baz123 I forgot to mention the fact that you don’t need to manually introduce the logic of anti-bounce and delays using automations - in HA this is already implemented using the climate platform and the generic_thermostat component (look for min_cycle_duration and hot_tolerance parameters), for which there is also a Lovelace card.
I use this platform in association with Schedy. It does not help. My tolerance for my UFH is 0 hot and cold with a precision of 0.1. Rapid variations of more than 0.1 causes issues.
In these images, I am seeing fluctuations (jitter) of 0.3-0.5 which is not acceptable. My point was, that after I restarted HA, that variation dropped to 0.1 which suggested to me this was an issue with the component.
I’ve not gone back to it to check again.
The component parser is one for all supported sensors. And in the case of LYWSD03, which sends data every 10 minutes, the component transfers the data as is, without applying any additional algorithms to them, therefore, an error is excluded here.
As I said earlier, jitter will be in any case, and you have to fight it. Either delayed response, or the introduction of hysteresis (tolerance), or both.
If there is a need to maintain the temperature with high accuracy, then it seems to me that the LYWSD03MMC sensor is not suitable for these purposes.
I simply run the received data through a couple of filters and that smooths it out and yes delays but that is better than the jitter for my purposes.
Yes, this is also a solution. Can you tell in more detail which components you used for filtering?
Hi Gents! I am a noob why my basic silly questions and hope I am not posting in the wrong forum.
I have tried seaching and scouring the forums but could not find what I was looking for.
Status: I have HA (the erstwhile Hassio) running on a RPI3. All is well. About a month back, I bought 2 x LYWSD03 and that is how learnt of the mitemp_bt. Of course, it did not work back then! I wish to now get the integration going.
Actions: I do not know what hci is - I plan to use built-in BT of the pi (at least as a start). I use the SSH terminal to loginto HA.
after this, I turn the scan off.
I installed the stream app in an iPhone. I also have the China registered Mi app with both sensors configured and working well.
So, start the sniffing on Stream and immediately poll the sensor on the mi app.
Even from the detail view on the Stream app, I can not locate a bind key. I tried exporting a 3 minute sniff HAR file (while the temp and hum were nicely updated on the Mi app) and read in it visual code but could not find the bind key.
Guidance please.
Q1. What is hci? is it okay to use btctl as a start? Am i doing it all wrong?Should I alswyats keep scan on?
Thanks in advance.
PS:
Even with this in my config.yaml, all I get as a result is a my BT laptop!
device_tracker:
- platform: bluetooth_tracker
- platform: bluetooth_le_tracker
all this discussions are based on rpi3 with bluetooth. I have moved to minipc for HA (that actually has bluetooth, but since HA is in Virtualbox, I believe it would be too much struggle to use it) and I plan to use ESP32 with ESPhome (that I use also for some other sensors and relays) to connect to those modules (I have a few of them). How can this be estabished?
Hello, @amitseth! You can read about hci on wikipedia. In fact, this is your bluetooth module interface, which in your case will be called hci0. If in the future you insert a usb-bt dongle, then there will be two hci interfaces in the system - hci0 and hci1.
For the component to work, nothing else needs to be run (except HA itself). Here is the minimum working configuration (for your LYWSD03MMC):
sensor:
- platform: mitemp_bt
encryptors:
"A4:C1:38:88:BB:4E": "< bind_key1 >"
"<2nd sensor MAC>": "< bind_key2 >"
Other options are described in the documentation.
The addresses of both sensors you already know how to get - use bluetoothctl. After you receive both addresses, turn off scanning.
It may not have been very clear from the text of our FAQ that traffic should be collected when adding a sensor to the MiHome application (I added an explanation).
Our FAQ also says that the component conflicts with bt-trackers, so bluetooth_tracker and bluetooth_le_tracker should be turned off. In the future, if you still need trackers, the most reliable solution is to use two bt devices (internal one and external usb-dongle).
1 Like
Raspberry Pi is discussed here most often, because, as I understand it, this is the most common platform for Home Assistant. Because of its price, it seems to me. My personal opinion is that this platform is poorly suited for the implementation of good smart home system due to its low reliability and other shortcomings.
Home Assistant works great on other platforms, and there are no barriers to using the component discussed here on other platforms. Personally, I have HA installed on an old mac mini, and I was forced to dust off my raspberry only as part of testing the component in Hassio. The only component requirement for the hardware platform - is the presence of a bt-interface (built-in or external). In the case of Virtualbox, this issue can be resolved using usb passthrough.
ESPHome also uses passive reception of messages, however, the list of sensors supported by this platform is slightly smaller than that of the component discussed here. If this platform is used only to expand the coverage area, then our FAQ describes other ways to solve this problem.
1 Like
I fully understand why the discussion is based on RPI. I also started on it and only recently migrated. I would just need some hints how to use this component.
Meanwhile I realised that my variant of the computer does not have bluetooth so I am looking for other solutions than. My idea was to do like on https://medium.com/@chatupornrungcharoesrichai/use-esp32-to-collect-temperature-and-humidity-from-xiaomi-sensor-via-bluetooth-73362ac74cf6 but with your component so I will get passive data from this sensor
Hi, i get to work my LYWSD03MMC. How can i add my second LYWSD03MMC located in another room with this component? is this correct?
- platform: mitemp_bt
rounding: True
decimals: 2
period: 60
log_spikes: False
use_median: False
active_scan: False
hci_interface: 0
batt_entities: False
encryptors:
'A4:C1:38:1D:16:41': '0d1bc96a6-------dd43d4319a452b8'
'A4:C1:38:0E:88:50': '96aa0e1f6---------692'
report_unknown: False
Yes, the configuration looks correct. The only thing is that the key must be 32 characters long (both keys length must be the same).
Yes, i know that. keys are corrent. I just hide the entire keys.
Just in case, I want to note that most of the options are not really needed, since the specified values are the default values.
Your configuration might look like this:
- platform: mitemp_bt
encryptors:
'A4:C1:38:1D:16:41': '0d1bc96a6-------dd43d4319a452b8'
'A4:C1:38:0E:88:50': '96aa0e1f6---------692'
1 Like
Thanks, great component. Keep up good work!
1 Like
Oh, the man himself - @Magalex. I am humbled and truly appreciate your wonderful development as well as taking time out to help me.
Your tips are very useful. I hope to get things to work and report back soon.
Stay safe during these trying times!
1 Like
@Magalex Dear Aleksey,
In one statement - ALL IS WELL, my dear friend!
Very glad to report that your instructions, clear and complete as they were, did result in both sensors getting registered in HA and working fine (after the usual struggle - total 3 hours; some tears, lots of smiles).
For the benefit of others (and to serve as a reminder to my own-self when I acquire more sensors after this COVID nonsense is over), here are the steps as I followed them…
Hardware:
HA updated and current. Running on Rpi3 (I know, I know - will soon move to a SSD).
2 x LYWSD03MMC sensors.
Steps Taken:
- Acquire the mac address of the LYs. Easily done via ssh to HA.
$ ha help
➜ ~ bluetoothctl
Agent registered
[CHG] Controller B8:27:EB:7E:50:F2 Pairable: yes
[bluetooth]# scan on
Discovery started
[CHG] Controller B8:27:EB:7E:50:F2 Discovering: yes
[NEW] Device A4:XX:XX:XX:XX:67 LYWSD03MMC
[NEW] Device A4:XX:XX:XX:XX:4E LYWSD03MMC
[bluetooth]# scan off
Discovery stopped
-
Copied and pasted this (to copy/paste and for added functionality, used MS Visual Studio terminal) into a blank text file and named the sensors LY1 and LY2 to avoid confusion later.
Logged off ssh.
This info may be gathered by many ways; and various other BT apps. -
Opend the Stream app on my iPhone.
Important step - In the app’s settings, choose HTTPS sniffing otherwise the whole procedure will go a waste (I learnt it the hard way). To complete this, the usual VPN trust procedure in Settings>General>About>Profiles needs installation. Make sure this profile is verified and ticked green.
Now, ensure that MiHome app is logged-in (ensure it is logged-out of other devices and region chosen is mainland China - I faced some grief on account of multiple log-in on other devices) and that the LYs are not added. Remove (delete) if needed. This can be done multiple times without any issues. Force close the app and restart it. -
On Stream, hit ‘Sniff now’ and immediately move to the MiHome app and commence the pairing procedure - don’t worry if auto discovery selects the LY. Complete the pairing and get the T and RH data from the LY. I paired only one to start with - the LY1.
‘Stop sniffing’ on Stream. This took about 65 seconds in my case. Now, goto the sniff history, Edit, Select all and ‘Export HAR’. I did this export to my NAS.
Charles Proxy app (30 day trial) was used on a mac to open the said HAR file. Use the find feature and findbind_key
It will be 32 characters long.
-
Rinse and repeat for LY2
-
From here on, things get easier! I had the LY1 and LY2 data ready in VS but not yet pasted in the Configuration.yaml
Time for an important Start/Stop procedure (I did struggle here a bit).
a) Stopped HA from here.
b) For additional measure, powered off and restarted the pi.
c) Logged-into HA and appended the config.yaml file as shown above.
d) Restarted HA.
- Waited patiently for about 15 minutes.
- Voila!! 4 new entities magically appeared into the Entities tab! Renamed them - will give a more meaningful name once I have tried them for a few days.
Well…that is all there is to it!
My best wishes and salute to Aleksey and all others who have contributed to this project and indirectly, to my…happiness - life is nothing but a pursuit of it, is it not 
People, stay safe and stay happy!
4 Likes
Thank you for your kind words and for such a detailed step-by-step instruction! I’ll leave a link to it in our FAQ.
1 Like
@Magalex, thanks for providing us with such a useful plugin. Had to recompile Python 3.8.2 with Bluetooth Sockets though, but after that it worked.
However, as I have LYWSDCGQ devices scattered all over the house, and remote_ha probably isn’t the best option (I’ve got Raspberry Pi Zero Ws around the house), I was wondering what it would take to turn https://github.com/algirdasc/xiaomi-ble-mqtt into the same passive-mode approach ? I’m using it today but it’s doing the active-mode-approach.
I think it will be easier to write own daemon (since periodic launch through cron is not suitable for passive mode - the code should be executed all the time in the background). To do this, I need to figure out how to correctly implement it in python, and figure out how to correctly publish data to MQTT.
You are not the first who asks for this, and there is a corresponding issue in our GitHub repository. The implementation of the component as a standalone is in the plans, but I still can’t allocate time for this…