[Enhancement] Support MMC-T201-1 Xiaomi Miaomiaoce Zenmeasure Smart Thermometer
dmatora opened this issue · 55 comments
Would really love to see support for this
2021-02-07 10:51:52 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0024c16fddf9810009002005c80d640d51b6
2021-02-07 10:51:54 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -71, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0025c16fddf9810009002005c80d640d51b9
2021-02-07 10:51:57 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -71, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0026c16fddf9810009002005c80d640d51b9
2021-02-07 10:52:02 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -73, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0028c16fddf9810009002005c80d640d51b7
2021-02-07 10:52:04 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -78, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0029c16fddf9810009002005c90d640d51b2
2021-02-07 10:52:07 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db002ac16fddf9810009002005c80d640d51b6
2021-02-07 10:52:14 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -77, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db002dc16fddf9810009002005c90d640d51b3
2021-02-07 10:52:17 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db002ec16fddf9810009002005c90d630d51b6
2021-02-07 10:52:22 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0030c16fddf9810009002005c80d610d51b6
2021-02-07 10:52:24 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -75, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0031c16fddf9810009002005c70d600d51b5
2021-02-07 10:52:27 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -79, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0032c16fddf9810009002005c70d600d51b1
2021-02-07 10:52:32 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -78, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0034c16fddf9810009002005c70d620d51b2
2021-02-07 10:52:34 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -87, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0035c16fddf9810009002005c70d620d51a9
2021-02-07 10:52:37 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -80, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0036c16fddf9810009002005c80d620d51b0
2021-02-07 10:52:47 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -78, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db003ac16fddf9810009002005c60d620d51b2
2021-02-07 10:52:49 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -87, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db003bc16fddf9810009002005c60d620d51a9
2021-02-07 10:52:52 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -78, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db003cc16fddf9810009002005c60d610d51b2
2021-02-07 10:52:54 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db003dc16fddf9810009002005c60d600d51b6
2021-02-07 10:52:57 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -76, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db003ec16fddf9810009002005c60d600d51b4
2021-02-07 10:52:59 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -79, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db003fc16fddf9810009002005c60d5f0d51b1
2021-02-07 10:53:02 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -77, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0040c16fddf9810009002005c60d5f0d51b3
2021-02-07 10:53:04 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -81, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0041c16fddf9810009002005c60d5f0d51af
2021-02-07 10:53:07 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -87, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0042c16fddf9810009002005c60d5f0d51a9
2021-02-07 10:53:12 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -83, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0044c16fddf9810009002005c60d5f0d51ad
2021-02-07 10:53:27 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -75, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db004ac16fddf9810009002005c60d600d51b5
2021-02-07 10:53:29 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -79, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db004bc16fddf9810009002005c60d600d51b1
2021-02-07 10:53:34 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -76, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db004dc16fddf9810009002005c60d600d51b4
2021-02-07 10:53:37 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db004ec16fddf9810009002005c60d610d51b6
2021-02-07 10:53:39 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -80, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db004fc16fddf9810009002005c60d610d51b0
2021-02-07 10:53:47 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -75, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0052c16fddf9810009002005c60d600d51b5
2021-02-07 10:53:49 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -80, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0053c16fddf9810009002005c60d5f0d51b0
2021-02-07 10:53:52 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -70, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0054c16fddf9810009002005c60d600d51ba
2021-02-07 10:53:54 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -72, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0055c16fddf9810009002005c60d610d51b8
2021-02-07 10:54:04 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -81, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0059c16fddf9810009002005c60d600d51af
2021-02-07 10:54:07 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db005ac16fddf9810009002005c60d600d51b6
2021-02-07 10:54:09 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -76, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db005bc16fddf9810009002005c60d610d51b4
2021-02-07 10:54:12 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -73, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db005cc16fddf9810009002005c60d620d51b7
2021-02-07 10:54:14 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -78, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db005dc16fddf9810009002005c60d630d51b2
2021-02-07 10:54:19 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -70, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db005fc16fddf9810009002005c50d630d51ba
2021-02-07 10:54:22 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -72, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0060c16fddf9810009002005c50d620d51b8
2021-02-07 10:54:27 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0062c16fddf9810009002005c40d620d51b6
2021-02-07 10:54:39 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -70, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0067c16fddf9810009002005c50d620d51ba
2021-02-07 10:54:44 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -73, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0069c16fddf9810009002005c40d630d51b7
2021-02-07 10:54:47 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -72, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db006ac16fddf9810009002005c50d630d51b8
2021-02-07 10:54:49 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -73, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db006bc16fddf9810009002005c50d630d51b7
2021-02-07 10:54:54 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -74, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db006dc16fddf9810009002005c60d630d51b6
2021-02-07 10:54:59 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -79, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db006fc16fddf9810009002005c60d630d51b1
2021-02-07 10:55:04 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -83, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0071c16fddf9810009002005c50d630d51ad
2021-02-07 10:55:07 INFO (Thread-3) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -75, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db0072c16fddf9810009002005c40d620d51b5
Looks possible. But I see two temperatures in the data, I think. The data you get above is e.g. c40d620d51
.
This has to be split up in different measurements. I can extract two temperatures around 35 degrees from this data.
c40d
--> 0dc4 --> 3524 --> 35,24 degrees
630d
--> 0d63
--> 3427 --> 34,27 degrees
51
--> 81 --> 81% battery
Are there two temperatures in MiHome? What can be the difference? If possible, I would like to convert it to one temperature, (depending on if you know what's the difference between the two). Our component is now designed to get one temperature per advertisement, I can average them, or take one of them, or the highest/lowest. But it all depends on if you can find out what the difference is between the two values.
Yes original app has two temperatures. One is actual temperature of the sensor. The other (higher one) is temperature of the body calculated using their patented algorithm - that's one you want to show
Ok, I'll use the first value (35.24 deg in the example above). I will include it in the next update.
thank you
I've added this in the 1.0.2-beta release. Can you try if it works? You can install the beta release via HACS.
Just tested it, other sensors are showing their values, this one doesn't
getting
Update of sensor.mitemp_bt_temperature is taking over 10 seconds
This looks loke mitemp_bt (build in component). Our component is called ble_monitor nowadays. Or did you give it that name yourself?
Oh, sorry, my mistake, I used "master" instead of the updated branch. One moment
This looks loke mitemp_bt (build in component). Our component is called ble_monitor nowadays. Or did you give it that name yourself?
you're right, I've added
sensor:
- platform: mitemp_bt
mac: "A4:C1:38:84:3A:A0"
monitored_conditions:
- temperature
before you made any changes to the code just to see if it will make any difference
now I cleared config, removed component, added it again and there are no signs of zenmeasure on Lovelace
logs are showing
2021-02-07 21:41:28 INFO (Thread-6) [custom_components.ble_monitor] BLE ADV from UNKNOWN: RSSI: -79, MAC: 0081F9DD6FC1, ADV: 043e2b02010000c16fddf981001f02010603020918171695fe7022db00bec16fddf98100090020052f0d920c51b1
I've just pulled updated you've just released and got
2021-02-07 21:44:39 WARNING (MainThread) [custom_components.ble_monitor.sensor] New voltage sensor found with MAC address A4C138843AA0. Enable battery entities and reload ble_monitor to add voltage sensor and make sure you use only one advertisement type (not all)
No, It was my mistake. I forgot to select the correct branch when making the release, so it was just the old version.
I've deleted the release and made a new one. I had to use a different name, but you can check that the new release has a dot (.) after the 2 in 1.0.2.-beta.
Can you try again.
Are you sure you're using higher value?
HACS needs to get the new info, can take a while, but you can force it by "reinstall" the component
it shows me value on sensor not body temperature
I'm using the first value of the two
can we try another one?
Yes, you can do it yourself by changing line 374 - 378 in __init__.py
, this part.
def obj0020(xobj):
(temp, _temp2, bat) = TTB_STRUCT.unpack(xobj)
# temp is the actual body temperature determined by an algorithm of the sensor
# _temp2 is the real measured temperature (not used)
return {"temperature": temp / 100, "battery": bat}
Just change it to
def obj0020(xobj):
(_temp, temp2, bat) = TTB_STRUCT.unpack(xobj)
# temp is the actual body temperature determined by an algorithm of the sensor
# _temp2 is the real measured temperature (not used)
return {"temperature": temp2 / 100, "battery": bat}
Mind the underscores.
It might be that they apply their "algorithm" based on these two temperatures. Then we need to figure out their magic algorithm.
I see 33.84 in your first screenshot
now it went to 33.2 :(
I'll try to talk to guy who patch their app, maybe they can reverse engineer algorithm
Ok,
We can also try ourselves. If you want, I can make a line in your logs on each measurement. If you write down the temperature in MiHome at the same time and add this to an Excel file, we can check the relation. Just do this a couple of times, if you have different temperatures in MiHome, and it should be possible to find the relation, I guess.
If you add the line with _LOGGER as displayed below, you will get a lot of data in your logs (displayed as errors, but that doesn't matter). Just place a # in front if you want to disable it. If you create an excel with the 2 temperatures and the temperature in MiHome and post it in a post in this issue, I can figure out the algorithm. Preferably at some different temperatures
def obj0020(xobj):
(temp, _temp2, bat) = TTB_STRUCT.unpack(xobj)
# temp is the actual body temperature determined by an algorithm of the sensor
# _temp2 is the real measured temperature (not used)
_LOGGER.error("Temperature 1 is: %s. Temperature 2 is: %s", temp / 100, _temp2 / 100)
return {"temperature": temp / 100, "battery": bat}
Issue is when I connect using original app home assistant stops getting any values
But I'll try making records on major changes
That’s true, but it won’t change very fast. Let’s first make a rough approximation, and we can do the fine tuning later.
I've tried to catch few values that were captured nearly simultaneously and sensor temperature exactly matched temp1
00:10 - 36.54 / 34.57 / 33.51 - (temp1 - temp2 = 1.06) / (gui_temp - temp1 = 1.97) / (gui_temp - temp2 = 3.03)
00:18 - 36.49 / 34.4 / 33.33 - (temp1 - temp2 = 1.07) / (gui_temp - temp1 = 2.09) / (gui_temp - temp2 = 3.16)
01:34 - 36.74 / 34.35 / 32.88 - (temp1 - temp2 = 1.47) / (gui_temp - temp1 = 2.39) / (gui_temp - temp2 = 3.86)
02:12 - 36.49 / 33.44 / 31.88 - (temp1 - temp2 = 1.56) / (gui_temp - temp1 = 3.05) / (gui_temp - temp2 = 4.61)
02:20 - 36.51 / 33.51 / 31.98 - (temp1 - temp2 = 1.53) / (gui_temp - temp1 = 3) / (gui_temp - temp2 = 4.53)
I did some googling and discovered that double tapping on sensor temperature in original app shows all 3 values
here are some values
34.03 32.78 36.48
34.00 32.68 36.53
33.98 32.59 36.59
33.98 32.53 36.64
33.90 32.40 36.65
33.89 32.38 36.65
33.87 32.33 36.64
33.84 32.28 36.63
33.83 32.25 36.63
33.83 32.23 36.63
33.81 32.23 36.62
33.81 32.22 36.62
34.54 33.00 36.94
34.57 33.22 36.82
34.62 33.31 36.81
34.67 33.39 36.81
34.73 33.59 36.71
34.76 33.75 36.61
35.12 34.47 36.49
let me know if that's sufficient
also people say that according to documentation, colder room causes gui temp to go higher
When using a linear relation (aT1+bT2=T3), like you have above, I get results that deviate with max 2% from the actual solution.
So I tried a logarithmic relation a * log(T1)+b * log(T2) = T3. I took two relations, and used Mathcad to solve the unkown in the equations.
Next, I used Excel to optimize a bit further, to get the smallest deviation from the actual results.
Max deviation is 0,10 degrees (0,3%). Seems accurate enough for now. Only thing to keep in mind is that all (body) temperatures are in between 36.57 and 36.86. I think we need to check the accuracy when someone has a fever (although I hope your baby does not get it, of course), or at least a temperature that is somewhat more out of this range.
I propose we use the relation 61.59 * log(T1)-38.12 * log(T2) for now, and you keep an eye on the temperatures, especially when someone has a fever. Please report back your findings, also when it does seem to be correct later. I'll add a disclaimer in the readme.
we need to check the accuracy when someone has a fever
Does 37.40 count as a fever? If so, here are few more values
35.77 34.81 37.18
35.82 34.89 37.19
35.87 34.96 37.21
35.91 35.00 37.24
35.93 35.01 37.26
35.97 35.03 37.31
35.99 35.03 37.34
36.00 35.03 37.36
35.99 35.05 37.32
36.02 35.04 37.38
36.04 35.08 37.38
36.03 35.07 37.37
36.05 35.12 37.36
36.06 35.15 37.34
36.08 35.18 37.35
36.09 35.18 37.37
36.12 35.20 37.40
36.12 35.24 37.36
36.12 35.28 37.33
For now I'm using temp1+2*(temp1-temp2)
This formula just failed me miserably, giving me 37.7 as value, while original app was showing 36.7.
Went back to 2 + temp1 / 100
I should probably mention, that temperature that original app is showing is often not the same as what regular thermometer says. Original app say that their algorithm has flaws, and can provide bad value, particularly when room temperature is cold, skin has a lot of fat, or thermometer is pressed to a body hard. So original app offers an alternative something they call Compensation mode, which might be more reliable than using two sensors, but would require adding an option to integration settings (haven't tested one yet)
Ok, I added the new values and decided to add an extra unknown to the equation (a * log(T1) + b * log(T2) + c = T)
After slightly optimizing a, b and c in Excel, I find a deviation of max. 0,19 degrees (0,5%) compared to the value in the app.
This results in the following relation T =128.18 * log(T1) -72.73 log(T2) -49.63.
I'll update the code with this relation for now. We can always change it, if we find something better
I found an even better function in Mathcad, that minimized the error. Added all the equations and this is the result.
Error is for most readings less than 0,1 degrees, except the last one (which was in the range that you checked first by switching between app and ble_monitor), so it might have been a wrong reading.
Error is for most readings less than 0,1 degrees
Nice job! Math was my specialty in university, but after looking at ease you've approached this with, I feel like I didn't study at all :)
in the range that you checked first by switching between app and ble_monitor, so it might have been a wrong reading.
I'm pretty sure these are inaccurate, I would discard them completely.
We only considered them because we didn't have anything better at that point.
You can try by adding
import math
at the top of __init__.py
And replacing the obj0020 with this.
def obj0020(xobj):
(temp1, temp2, bat) = TTB_STRUCT.unpack(xobj)
# Body tempeature is calculated from the two temperatures
body_temp = 123.993 * math.log10( temp1/100 ) - 73.428 * math.log10( temp2/100 ) - 42.214
return {"temperature": body_temp, "battery": bat}
You can try by adding import math at the top of init.py
Yeah, I've been testing your first formula since you posted it.
Updated to latest one. Works great!
Ok, will add it to the final release.
36.03 34.18 37.86
36.04 34.21 37.86
36.03 34.29 37.86
36.01 34.33 37.84
36.03 34.38 37.86
36.01 34.41 37.84
36.03 34.45 37.86
36.03 34.48 37.86
36.02 34.47 37.85
36.03 34.53 37.86
36.02 34.53 37.84
36.01 34.56 37.80
36.01 34.58 37.78
36.03 34.59 37.80
36.07 34.63 37.83
36.09 34.64 37.86
36.10 34.68 37.84
36.12 34.71 37.84
36.14 34.74 37.85
Currently HA shows 37.41 while Zenmeasure app shows 36.84, which is a lot of difference
34.37 32.33 36.86
34.40 32.31 36.87
34.38 32.27 36.86
34.39 32.28 36.87
34.39 32.29 36.87
34.38 32.30 36.86
34.39 32.31 36.87
34.38 32.28 36.86
34.36 32.29 36.85
34.35 32.29 36.85
34.39 32.30 36.87
34.35 32.34 36.85
34.39 32.34 36.87
34.39 32.38 36.87
34.40 32.38 36.87
34.41 32.43 36.88
34.43 32.46 36.89
34.45 32.48 36.90
I'll check and see if I can improve my magic formula. Perhaps another relation. I'll get back to it tonight
Ok, I tried a couple of possibilities. Error is the max deviation over all values you gave to me in this post (expect the first manual set)
T = 1.04 * T1 - 0.463 * T2 + 16.176 --> error between -0.19 and +0.28
T = 83.004 * log(T1) - 35.056 * log(T2) - 37.606 --> error between -0.20 and +0.29
T = 4.2846 * 10^-16 * exp(T1) - 6.18348*10^-16 * exp(T2) + 36.515 --> error between -0.13 and +0.21
T = 3.7193 * 10^-11 * exp(0.693138 * T1) - 1.02801 * 10^-8 * exp(0.53871 * T2) + 36.413 --> error between -0.14 and +0.14
So we could use the last. In Python code (yes, I know, it looks like a terribly complicated formula)
body_temp = 3.71934 * pow(10,-11) * math.exp(0.69314 * temp1/100) - 1.02801 * pow(10,-8) * math.exp(0.53871 * temp2/100) + 36.413
I should probably mention that even when sensor stays on a body for awhile, every time you connect original ZenMeasure app to the sensor, gui temperature starts from about 34 and then raises to value that HA shows instantly.
It might be they are using previous sensor values in their formula like people use pulse wave data to calculate blood pressure
Also there was recently a case when I had 37.6 on regular thermometer and ZenMeasure app was showing 37.33 while HA was showing 37.72, so their approach is not necessary always better (but so far in most cases it was)
I've updated formula and will keep comparing values
1.0.2 final has been released, which adds the sensor. I'll keep the topic open to collect more data.
Any specific for setting up the sensor.
I did try to integrate it but it did not work.
I tried repairing the device and capturing the encryption code and using it in the settings but nothing...
rPi4, Home Assistant in virtual environment and installation true HACS and manual setup using YAML method.
Thanks.
P.s. me and other people in the forum in Open Media Gateway tried to reverse engineer the values and relationship between them, but unsuccessfully unfortunately :-)
No, You don't need anything more more than the mac address + encryption key.
Let's figure out why it doesn't work.
Do you have other sensors? Do they work?
Are there errors in your logs?
Do you have a link to this "Open Media Gateway"? Or do you mean Open MQTT Gateway?
Edit: Ah, I guess your refer to this topic. We assumed that there is a relation between the two values measured by the sensor and the actual body temperature in the app. Based on the above data, I used Mathcad to approximate a relation. You have to give some basic form of the relation, so its a bit trial and error. For the given data, we are close (deviation is max 0,14°C). But I'm not sure if this is correct for other data, especially in the 39-40°C range.
Yes I do have 3 Xiaomi BLE leak sensors.
They work just fine. No issues there.
The log shows an error describing the fact that the encryption key is in invalid format. Bit I have get the encryption key the same way as the blue leak sensors. In fact I can see the defense but I have tried several times and the result was the same.
Example of 1 leak sensor and the temp bind/encryption keys.
Did: blt.3.15hoiqnese800
Token: a104bc04a4678407d35fc131
Bindkey: 08aef766a0f731g765da10206e206dbd
Mac: 54:EF:66:E0:47:5F
Did: blt.3.ps6u8rqs4000
Token: 92e3c7769c54b5ad7b996414
Bindkey: hh85bb37b2880f77b594475f
Mac: B0:91:55:.E8:AD:B7
I did mean Open MQTT Gateway. Just Typo :-) Sorry about that.
No problem.
This MMC-T201-1 does not need an encryption key. I think it fails because you entered a 24 character key, while it should be 32 characters. But for this device, just remove it, no key is needed.
I did try without an encryption key and it did not work. Device was not discovered.
That is why I tried a configuration with an encryption.
I did see that the key is "deferent" . After I did not work again, I have written here.
I'll test again without encryption key once more and will report back.
Thank you, for your effort and time.
- Does it work in original ZenMeasure app?
- Did you ensure device is awake by putting it to the base and removing from it? (or by putting any magnet near and then removing it, It should glow confirming the wake)
- Did you ensure you're using HACS 1.0.2+ version of BLE Passive component?
- When you follow
My sensor from the Xiaomi ecosystem is not in the list of supported ones. How to request implementation?
recommendations from FAQ, do you getBLE ADV from UNKNOWN
in your logs?
- Yes the device works with MiHome app and Zen Measure app. PS. When we tested in OMG forum, the device transmits data very very often when connected/reading the temperature with ZenMeasure app. When device is not "read" by phone it does send data less frequently.
- Yes I did try to sleep/awaike the device by punting it in and out of the case. I own this device from 4 years and even changed the battery,
- HASS, HACS, BLE module up to the latest version at the time.. Phyton 3,9 with virtual environment installation.
- Sorry but I did not get/understand the statement.
@vasil-github I was referring to FAQ of this component
He was referring to this part of the faq. But it’s better to use this command to collect some data.
sudo hcidump --raw hci > dump.txt
Keep it running for a few minutes, and post the generated file here. I will check the data to see if I can find out why it doesn’t work for you
I've been keeping an eye for a few days on values I'm getting and so far I was unable to spot major (more than 0.15) difference between ZenMeasure app, Home Assistance, and regular thermometer (wearing ZenMeasure above temple seems to provide best accuracy). In many (if not most) cases there were nearly no difference at all.
@Ernst79 thank you again for integrating this and great job on the math!
Ok, thanks. I'll close the issue than. Feel free to open again if you have new data or a modification is needed. I'll keep the calculation files.