Xiaomi vs Aqara door/window sensors

Just used the old battery again after depleting more, back to 219 again… not good.

Edit
Correction, that seem to happen initially when changing Battery.
Now battery back to 4% which is better. Might incline to higher value. Will see tomorrow.

17-10-2017: Battery raised to 46%
18-10-2017: Battery raised to 50%

Maybe it is just scaling it to an 8-bit value? I.e., 0…255

I think you’re right
The battery has raised to 44% which is possible

Any luck on getting the battery to report correctly on the Aqara? I purchased 1 and used the DH suggested but the battery bounces between 0% and 2%. Not a major issue but would like to correct it if possible.

2 Likes

While waiting on a solution for the battery on the Aqara’s I’ve modified the DH to not show the battery. I also ordered an Original Xiaomi sensor which I do believe shows the battery correctly.

I might have found it. But it’s difficult to know for sure.
I’ll check the battery voltage to see if the percentage seems close enough.

1 Like

I don’t want to keep this for myself, just forgot to share, i now see.
Please remember that i am not sure this is correct, but please feel free to use it and test it with me.
Be aware that this percentage goes up and down a bit. But that seems to be the same behavior as my Aeon sensors.

resultMap = getBatteryResult(cluster.data.get(6))

def volts = rawValue / 2.55
def maxVolts = 100
if (volts > maxVolts) {
			volts = maxVolts
}

result.value = volts.toInteger()
result.descriptionText = "${linkText} battery is ${result.value}%"

return result

I just replaced a sensor battery, which had 65% (test battery), with a new one. Now have to wait an hour for check-in.
Will report back.

First report:
Old battery: 65%
New Battery: 52%

As you can see this is not encouraging, but i’m quite confident the percentage will still rise a bit.
More tomorrow.

2nd report:
Old battery: 65%
New Battery: 48%

3rd report:
Old battery: 65%
New Battery: 44%

1 Like

Had a chance to replace the text in my DH and now getting 81% on the battery on its first reporting. :grinning:

Thank you again for all your hard work on this its greatly appreciated.

Well,
My “new” battery is reporting only 44% now. It should be 90% or so.
Having doubts here…

But this was the only value that changed after depleting a battery using a light.

I understand the doubts but still think you have it right with the 6th integer and 2.55. It is possible that its a bad battery? Do you have another sensor to see how it reports that battery?

I did find another DH for a Xiaomi water sensor and when I just checked to see what that one had for battery reporting it has the following…

result = getBatteryResult(cluster.data.get(6))

def battLevel = Math.round(rawValue * 100 / 255)
result.name = 'battery’
result.translatable = true
result.descriptionText = "${device.displayName} battery was ${battLevel}%"
result.value = Math.min(100, battLevel)
return result

Cool! That seems to support my case here.
I have noticed that the battery value goes up and down a bit.
My value might still rise.

Thanks

I made another change to the devicehandler. Specially for WebCore.
If you want to create a script that checks the lastcheckin as a date to see if a sensor hasn’t checked in for awhile, you need a DateTime, not a stringvalue.
You can use a stingvalue and convert this to a date in WebCore, but if you have a DateTime it is so much easier to use.

Thanks, I’m not using WebCore yet. Still dipping my toes in the water, I’ll jump in the deep end soon enough… LOL.

That other DH for the water sensor also had another interesting area about the battery. In the Tile he has it reporting a color BG as well. I modified it a slight bit but it will show a green BG down to 51% then go yellow from 26 to 50% then go Red lower than 25%

valueTile(“battery”, “device.battery”, decoration: “flat”, inactiveLabel: false, width: 2, height: 2) {
state “default”, label:’${currentValue}% battery’, unit:"",
backgroundColors: [
[value: 10, color: “#bc2323”],
[value: 26, color: “#f1d801”],
[value: 51, color: “#44b621”]
]

it’s now checked in a second time and I’m still at 81%. This is also the original battery that’s been in it since it showed up at my house.

Oh but you will use WebCore soon :grinning:

Looks good!
Guess we need another fork for two devicehandlers :wink:

I had to replace this line:
label:’${currentValue}% battery’

with this
label:'${currentValue}%'

Otherwise i got the word ‘battery’ in the icon.

DOH! Thats on me, my mistake. I made the same change too, if you look at my picture the word battery is missing. I just copied and pasted the wrong code, i took it from my notepad and not out of the IDE. Sorry for the confusion.

1 Like

Changed battery again
Brand new one from blister: 65%
Now we wait

18-11-2017, 15:13: 71%

It’s not the mesh. There are some network management features in the V2 hub which are not available in the V1 hub so the drop off problem is just constant for V1 with these particular devices. This would be true even if you only had one device sitting 6 feet from the hub.

The battery code looks to be slightly off. I had one aqara device bouncing between 98% and 0%; looking at the data, it looks like it’s a 16-bit value of bat voltage in mV as follows:

result = getBatteryResult((cluster.data.get(7)<<8) + cluster.data.get(6))

def volts = rawValue / 1000
def minVolts = 2.1
def maxVolts = 3.0
def pct = (volts - minVolts) / (maxVolts - minVolts)
def roundedPct = Math.round(pct * 100)

result.value = Math.min(100, roundedPct)
result.name = 'battery’
result.translatable = true
result.descriptionText = "${device.displayName} battery was ${roundedPct}%"
return result

1 Like

Had some thoughts it would be wrong. But why are you including clusterdata 7 ?

Will give this a try!