Soni
You just simply need to install the Custom firmware first. Once it is flashed, you just need to connect to the Sensor again (in the Telink flasher) and select the advertising type to “Mi Like”. I thouhgt it was explained clearly in my origina post above. This is why I mentioned that your most likely cause would be not having activated the “Mi-like” advertising after flashing the CW.
Hello there 
I’ve flash my Xiaomi temp sensor with the custom firmware but I can’t find where I can find my MAC adress 
Any idea please ?
Edit : Found it using an Android app : https://play.google.com/store/apps/details?id=com.macdom.ble.blescanner very usefull.
It is also visible as an attribute to your entity in home assistant (check e.g. developer tools, states). Or if you only have the following configuration, it will be in the name of the sensor (without the : )
sensor:
- platform: mitemp_bt
Today we have released a new beta version 0.8.0-beta. This version has some breaking changes, as we have decided to move some configuration parameters to the new devices option. This allows us to define more parameters at device level in the future.
If you are using one of these options, please read the instructions on this page carefully and modify your configuration after updating to 0.8.0-beta.
encryptorssensor_namessensor_fahrenheitwhitelistThe new format (0.8.0 and above) will become:
sensor:
- platform: mitemp_bt
discovery: True
devices:
- mac: 'A4:C1:38:2F:86:6C'
name: 'Livingroom'
encryption_key: '217C568CF5D22808DA20181502D84C1B'
temperature_unit: C
- mac: 'C4:3C:4D:6B:4F:F3'
name: 'Bedroom'
temperature_unit: F
- mac: 'B4:7C:8D:6D:4C:D3'
Explanation of the new options can be found here.
Instructions to convert your old configuration to the new format can be found here
I quite like how active the development on this is.
I don’t suppose this update makes it possible to exclude types of sensors with the devices option? Let’s say I only care about the light level and moisture, but not the temperature or conductivity.
At the moment there is no such possibility, yes. However, this change opens the way for us to expand the number of possible settings per device, and it is quite possible that the possibility you mentioned will appear in the future releases (need to think about it).
One question - why is it not enough to simply not use unnecessary entities?
No you’re right I can of course just disable them/ignore them. I guess I thought it is be better to “disable” anything not in use as close to the source as possible. That was all
Checking and enumerating such settings at the stage of parsing messages from the device will consume more computing resources. But I’ll think about it, maybe I’m wrong.
For standard built in components, the policy is to always add all sensors by the component and let the user decide to exclude certain sensors in Home Assistant by switching them off.
Yes, it seems correct to me too, but I remembered the monitored_conditions setting in the original mitemp_bt.
See this page for more info why they have decided to not allow monitored conditions anymore. Original mitemp_bt hasn’t been updated, but it should be removed there.
Interesting reading, thanks.
Just wondering if there had been an update on the Ubuntu 20.10 issue with some NUCs? I believe hcitool was not working, but was working with bluetoothctl.
I’m not sure I understood what issue you mean.
hcitool is deprecated tool, and may not work or may not be present at all in the distro.
So from what I have seen on the repo, some people have had issues when using an Intel NUC on Ubuntu 20.04 and later with this component working. I have not been able to get this component working after moving from an Rpi 4 to an NUC with HA running in Docker.
Yes, there is one. The point is that regardless of the root of the problem, it has to do with the library that our component relies on or lower levels responsible for the operation of the bluetooth subsystem. More details in this thread. There is also a link to a fork that implements a crutch to workaround this problem.
After the fork appeared, it was decided to leave this issue as it is, pending its solution at the library or driver level. Since you’ve raised this question again, I’ll go over it again - maybe I’ll see a good way to solve it at our component level…
Great, thanks for that! I’ve tried using the fork and unfortunately getting anywhere. Will just need to wait on this one I think
If I were you, I would try to use some kind of external usb adapter. It is possible that there will be no solution to the problem in the near future…
That’s a good point. I’ve actually set up the custom firmware, so will look at running a Python script using the new library and send via MQTT or something.
I have got a script now running on boot on my NUC that sends the values to MQTT to HA.
from bluepy.btle import Scanner, DefaultDelegate
from time import sleep
import json
import paho.mqtt.client as mqtt
# Set up MQTT client
client = mqtt.Client()
client.connect("11.11.11.11", 1883)
# Parse values amd send to MQTT
def getValues(string):
n = 2
array = [string[i : i + n] for i in range(0, len(string), n)]
temperature = float(int(f"{array[6]}{array[7]}", 16)) / 10
humidity = int(array[8], 16)
battery = int(array[9], 16)
print(temperature, humidity, battery)
message = {"temperature": temperature, "humidity": humidity, "battery": battery}
client.publish("livingroom/sensor", json.dumps(message))
# Devcie MAC address to look for
devices = ["A4:C1:38:5C:A6:20"]
# Scan for BLE advertisments
class ScanDelegate(DefaultDelegate):
def __init__(self):
DefaultDelegate.__init__(self)
def handleDiscovery(self, dev, isNewDev, isNewData):
if not dev.addr.upper() in devices:
return
for (adtype, desc, value) in dev.getScanData():
if adtype == 22:
data = value[4:]
getValues(data)
# Start the main loop
while True:
scanner = Scanner().withDelegate(ScanDelegate())
scanner.clear()
scanner.start()
scanner.process(10)
scanner.stop()