-
-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Enhancement] Support MMC-T201-1 Xiaomi Miaomiaoce Zenmeasure Smart Thermometer #264
Comments
Looks possible. But I see two temperatures in the data, I think. The data you get above is e.g. This has to be split up in different measurements. I can extract two temperatures around 35 degrees from this data. 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
|
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 |
you're right, I've added
before you made any changes to the code just to see if it will make any difference
|
I've just pulled updated you've just released and got
|
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
Just change it to
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
|
Issue is when I connect using original app home assistant stops getting any values |
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
|
I did some googling and discovered that double tapping on sensor temperature in original app shows all 3 values here are some values
let me know if that's sufficient |
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. |
Does 37.40 count as a fever? If so, here are few more values
This formula just failed me miserably, giving me 37.7 as value, while original app was showing 36.7. 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. |
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 :)
I'm pretty sure these are inaccurate, I would discard them completely. |
You can try by adding And replacing the obj0020 with this.
|
Yeah, I've been testing your first formula since you posted it. |
Ok, will add it to the final release. |
36.03 34.18 37.86 |
Currently HA shows 37.41 while Zenmeasure app shows 36.84, which is a lot of difference |
34.37 32.33 36.86 |
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)
So we could use the last. In Python code (yes, I know, it looks like a terribly complicated formula)
|
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. |
No, You don't need anything more more than the mac address + encryption key. Do you have other sensors? Do they work? 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. Did: blt.3.15hoiqnese800 Did: blt.3.ps6u8rqs4000 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. |
|
|
@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.
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. |
Would really love to see support for this
The text was updated successfully, but these errors were encountered: