Aqara Battery

[mycanaletto]

Hello, I have been waiting for months for an update that would support the batteries on the new revisions of December of Aqara temperature sensors, very widespread sensors ... Well no, still not.

I am very disappointed, we are told about OTA updates and this simple support (ok in zigbee2mqtt) of the batteries is not updated.

Another thing expected, the possibility of updating Deconz / Phoscon from the web interface without having to log in to ssh, which admits it is not a cup of tea for novice users, you should not forget that this are also your potential customers ...

Under Home Assistant I like your solution (in opposition to ZHA and Z2MQTT), so I hope it will evolve in the right direction!

Merci :-)

[Mimiix]

Hi,

For me it seems to work fine

[mycanaletto]

Sure... But you dont have the new revision (look the firmware difference)

[Mimiix]

Which one sensor do you have? Product number?>

[SwoopX]

I really don't get what you mean. Battery reporting is working for years! What version of deconz are you running? Seems to be way behind.

[mycanaletto]

Firmware : 20191205

[mycanaletto]

I really don't get what you mean. Battery reporting is working for years! What version of deconz are you running? Seems to be way behind.

Yes I know it has been working for years, but not on this new revision (en 2.7.075 ou 2.5.77)

I received the first in this version in January and there 15 days ago.

[SwoopX]

I got like 10 of them running and all report battery. Now, to further investigate where the issue is, check the REST API to see if battery values are somewhere in the associated sensors.

[mycanaletto]

I got like 10 of them running and all report battery. Now, to further investigate where the issue is, check the REST API to see if battery values are somewhere in the associated sensors.

And in which firmware are yours? I tested on 3 Deconz / Phoscon installations ...

[Mimiix]

Did you check what the HA Debug shows?

[SwoopX]

I'd tend to say you're not yet fully aware of the involved components.

Firmware, from the deconz perspective, is the device firmware directly on your conbee or raspbee. Simplified, it handles the lower layers and enabled the basic communication.

deconz/deconz GUI is the core component with more logic and an interface to manage and configure your devices. It simply makes use of the hardware.

deconz REST API is where we are. It simply enables web based configuration and data acquisition from your zigbee devices.

Phoscon is just another REST client for the API, a graphical representation.

Now, the firmware has nothing to do with what you're experiencing and not even deconz core. Presumably, HA is just not picking the values, assuming the REST API works alright and the sensors are correctly set up.

[mycanaletto]

I know how this factory works ...

I am neither a developer nor a debugger however. I have several installations, in Home Assistant or another with an RPI and the card downloaded on the site. The sensors with the old firmware reassemble the battery well not those with the new firmware.

And I am not alone I believe to have made this observation. The same problem exists on ZHA but not on zigbee2mqtt.

[Mimiix]

I know how this factory works ...

I am neither a developer nor a debugger however. I have several installations, in Home Assistant or another with an RPI and the card downloaded on the site. The sensors with the old firmware reassemble the battery well not those with the new firmware.

And I am not alone I believe to have made this observation. The same problem exists on ZHA but not on zigbee2mqtt.

What did the HA debug show?

[SwoopX]

The sensors with the old firmware reassemble the battery well not those with the new firmware.

Where does that come from? Where do you get the new firmware and what's yours?

[mycanaletto]

Where does that come from? Where do you get the new firmware and what's yours?

As said above the firmware is 20191205. Delivered as by Amazon or AliExpress

[SwoopX]

Could you please provide a screenshot from the node, so we can have a look at the available clusters and read the basic cluster and provide a screenshot as well?

If that's really a new device firmware, than nobody ever mentioned something similar here. That might go hand in hand with changes in the special attribute reporting, but we should be able to further investigate with additional debug output.

OT: might be better if you join our discord channel (see readme) for some more interactivity.

[mycanaletto]

Could you please provide a screenshot from the node, so we can have a look at the available clusters and read the basic cluster and provide a screenshot as well?

Yes, but later because here I have to work a little for my real work :-)

[SwoopX]

Could you please provide a screenshot from the node, so we can have a look at the available clusters and read the basic cluster and provide a screenshot as well?

Yes, but later because here I have to work a little for my real work :-)

That's overrated :P

[mycanaletto]

So... After 1 or two hours the battery of a sensor (bios 20191205) goes up well ... (in 2.5.77) I redid a test with a new sensor (bios 20191205) and it also has to wait 80 minutes to see the battery. This is progress because in 2.5.75 the battery never went up on this version of sensor).

By cons if I use an older sensor (bios 20161129) the battery goes back up immediately ....

[SwoopX]

You're losing us here now. Let's do it step by step.

I have been waiting for months for an update that would support the batteries on the new revisions of December of Aqara temperature sensors, very widespread sensors ... Well no, still not.

Do we have an issue here describing that? As mentioned before, I cannot recall anybody else mentioning the absense of battery readings.

I am very disappointed, we are told about OTA updates and this simple support (ok in zigbee2mqtt) of the batteries is not updated.

Who told you what exactly? Please give reference. Deconz can generally update devices if the firmware files are available. If you have a newer firmware file, please share it here, so everybody can potentially benefit.

Another thing expected, the possibility of updating Deconz / Phoscon from the web interface without having to log in to ssh, which admits it is not a cup of tea for novice users, you should not forget that this are also your potential customers ...

I respect your opinion and agree it would be a nice feature for the "regular" user to have. However, it seems that priorities are currently set overwise and like with all expectaions, not all of them can be met (including my own). But I cannot speak for DE here. However, I could try to reach out of them to get any comment if that is on their todo list and let you know.

After 1 or two hours the battery of a sensor (bios 20191205) goes up well ... (in 2.5.77) I redid a test with a new sensor (bios 20191205) and it also has to wait 80 minutes to see the battery. This is progress because in 2.5.75 the battery never went up on this version of sensor).

By cons if I use an older sensor (bios 20161129) the battery goes back up immediately ....

What exactly do you mean by "go up"? You need to understand the mechanism here. It's solely the device that is responsible for providing that data (in this particular case). The battery value is reported only once in an intervall between 6 -12 hrs (if I recall correctly) and nothing can be done on the deconz side to change that. Eventually, if there's really a new firmware out there, that might have changed, but it is yet unknown and needs to be investigated.

[Kristian8606]

Mine works perfectly!

[mycanaletto]

What exactly do you mean by "go up"? You need to understand the mechanism here. It's solely the device that is responsible for providing that data (in this particular case). The battery value is reported only once in an intervall between 6 -12 hrs (if I recall correctly) and nothing can be done on the deconz side to change that. Eventually, if there's really a new firmware out there, that might have changed, but it is yet unknown and needs to be investigated.

These sensors are in firmware 20191205 and the battery is not immediately visible on the 2.7.077 and was never visible on the 2.7.075. So this new version fixes a problem, and no matter if you have to wait a bit to have the battery visibility, it works for me and we all have other things to do.

So you'll understand that I've been waiting for weeks for a new version to fix this problem, especially since it doesn't exist with zigbee2mqtt which must have the same information. And when I saw that the battery didn't appear I was disappointed.

Well, now I know I have to wait, and it would be good for users to know because this new revision will be generalized.

I'm not going to send you the firmware 20191205 because it's in my sensors and I won't be able to get it out.

In any case I thank you for taking the time to help me and try to understand.

Good evening, lionel

[ghost]

Hello everyone

I think i have the same problem but looking at it from ZHA side and using the conbee 2 USB.

All of my other temp senors are aqara, same details on the outside of the device right down to a similar mac address.

The issue we have now, is that the new temp sensors do not show any battery info. They do show temperature, humidity and pressure.

Seems that the code in the hardware is being detected differently, i dont think this is neccessarily a deconz issue, but it might be as i dont know anyone else HomeAssistant and another device.

What info can i give out to you all to help diagnose it. The devices both have the same model number on them..

Im struggling to upload screenshots so here is data form

Working sensor shows battery LUMI lumi.weather lumi.weather by LUMI IEEE:00:15:8d:00:04:5a:cb:50 Nwk:0xfae4 Device Type: EndDevice LQI: 255 RSSI: -49 Last Seen: 2020-06-03T20:15:14 Power Source: Battery or Unknown Quirk: zhaquirks.xiaomi.aqara.weather.Weather

{ "node_descriptor": "", "endpoints": { "1": { "profile_id": 260, "device_type": "0x5f01", "in_clusters": [ "0x0000", "0x0001", "0x0003", "0x0402", "0x0403", "0x0405", "0xffff" ], "out_clusters": [ "0x0000", "0x0004", "0xffff" ] } }, "manufacturer": "LUMI", "model": "lumi.weather", "class": "zhaquirks.xiaomi.aqara.weather.Weather" }

Non battery detected sensor LUMI lumi.weather lumi.weather by LUMI IEEE:00:15:8d:00:04:5c:71:f1 Nwk:0x5429 Device Type:EndDevice LQI:159 RSSI:-74 Last Seen:2020-06-03T20:16:58 Power Source:Battery or Unknown

{ "node_descriptor": "", "endpoints": { "1": { "profile_id": 260, "device_type": "0x0302", "in_clusters": [ "0x0000", "0x0003", "0x0402", "0x0403", "0x0405", "0xffff" ], "out_clusters": [ "0x0000", "0x0004", "0xffff" ] } }, "manufacturer": "LUMI", "model": "lumi.weather", "class": "zigpy.device.Device" }

[SwoopX]

The 2nd device has apparently no power configuration cluster (0x0001), hence, no battery. Interestingly, it is also a different device type. That may be indeed an indication that they changed something in the firmware.

Have you already tried to reset and rejoin the device?

[ghost]

@SwoopX I have indeed tried to reset and rejoin the device. Whats strange is all the details on the back are exactly the same, the mac address is also pretty close to each other, so they havent change the hardware.

I have fully reset the Home Assistant i am using and repaired all devices, all others i bought around the same time, and this once in the last month..

[Mimiix]

@martynstar If this is from ZHA in Home-Assistant , this is something that we cannot fix.

[SwoopX]

If I could get a debug log from the sensor, we should see clearer... Happy to guide you

[ghost]

Of course! What do you need me to do?

[SwoopX]

deconz must be run with --dbg-info=2 to provide maximum detail. With that turned on, physically reset and repair the sensor and share the output. If that may not be sufficient, it should be run for a longer period (1-2h) to catch all the attribute reportings.

This works easily when deconz is installed on a pure linux machine. If you use any "specialities" like docker or so, that might be more tricky to achive. Depends on your setup.

[riston]

A bit off-topic but the battery reporting by the Xiaomi devices is skewed or why it's reporting 100% always. I have three different types of devices but non is reporting correctly, IKEA devices seem to report battery level correctly at least value changes :).

[SwoopX]

Xiaomi devices report voltage only and that's somehow stable for a long time. However, if battery drains, that value will fall quite quickly.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MattWestb]

Bump

[labaland]

i dont get battery status on all of my 3 ikea remotes and on aqara! works in deconz but not zha in ha :(

[Mimiix]

@labaland Eh? I am not sure what you are asking @mycanaletto Is this issue still valid?

[obiwanzamora]

I am also getting this issue. No battery levels reported for my Xiaomi motion sensors.

[mycanaletto]

Just wait a time...

[obiwanzamora]

Sorry should have clarified. I have read about the 1 hour wait time for battery level reporting and have done so. In fact I left for several days and no battery reported. Motion works fine, just no battery level.

[mycanaletto]

All I can say is that I have the battery level, even if it doesn't seem particularly accurate or reliable.

[ghost]

I can confirm that my aqara sensors all have battery data now.The data is actually voltage related on aqara, so as the voltage degrades the battery life does so too, so it will say 100% for sometime, but that will then drop off as the battery fades, not a percentage like we see with lots of modern devices as there is no battery management on the devices-------- Original message --------From: My Canaletto notifications@github.comDate: Wed, 29 Jul 2020, 12:03To: dresden-elektronik/deconz-rest-plugin deconz-rest-plugin@noreply.github.comCc: martynstar Martynpb@gmx.com, Mention mention@noreply.github.comSubject: Re: [dresden-elektronik/deconz-rest-plugin] Aqara Battery (#2825) All I can say is that I have the battery level, even if it doesn't seem particularly accurate or reliable.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[obiwanzamora]

In Phoscon app and deCONZ VNC battery is reported as 100%. But prior to migrating over from Xiaomi mobile application the Xiaomi app was reporting ~40% battery. I understand it is actually voltage being converted to a percentage but presumably the conversion to percentage should be roughly similar. I've tried repairing, waiting etc. but always battery is 100%.

[ghost]

Yes it might be due to the algorithm used to calculate it.I doubt there will be anything a 3rd party app can match aqara would know roughly how long a battery lasts for, im aware are a two year life span is the usual, I have just got an automation to alert me when the levels drop to 20% I can't imagine it lasting much longer, but I have noticed that the battery levels fluctuate around 100% it can drop to 80 odd then go back to 100, we just need to be aware that when it's going down it might only do so in the last two weeks of its life time, better than nothing!-------- Original message --------From: obiwanzamora notifications@github.comDate: Wed, 29 Jul 2020, 12:21To: dresden-elektronik/deconz-rest-plugin deconz-rest-plugin@noreply.github.comCc: martynstar Martynpb@gmx.com, Mention mention@noreply.github.comSubject: Re: [dresden-elektronik/deconz-rest-plugin] Aqara Battery (#2825) In Phoscon app and deCONZ VNC battery is reported as 100%. But prior to migrating over from Xiaomi mobile application the Xiaomi app was reporting ~40% battery. I understand it is actually voltage being converted to a percentage but presumably the conversion to percentage should be roughly similar. I've tried repairing, waiting etc. but always battery is 100%.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[obiwanzamora]

Ok I guess if the 100% is really 100% then it should be fine. Just surprised that every sensor (which have been running for several years) reports 100% when Xiaomi showed approx. 40%. The exact percentage is academic, I just need to be sure that I am going to get a change from 100% before the battery runs out.

[SwoopX]

Well, now you got me curious. If you can get me a battery reading from the gateway(not just having it paired for 5 mins) and can later on give me deconz' debug output of 2 hours, I could see if there's a value transmitted roughly matching this.

[obiwanzamora]

2 hours of logs attached. I repaired the device at the very start of the 2 hours. Interestingly I just checked the battery with a voltmeter and voltage is 3.02V. So for a 3V battery the fact it is reporting 100% makes sense, just speculating but maybe Xiaomi do not consider 3V as 100% but deconz does? Either way I guess as long as you can see 3.02V approximately somewhere in the logs then should be ok.

log.txt

[ghost]

It is very difficult to detect a capacity by using the voltage, it is usually done with a load or some battery management, so if the aqara hub has some special API it uses to pull the data out we might not be able to see it.If voltage starts to drop a system can fail, so they are designed to keep voltage within a tolerance then fade at end of life.-------- Original message --------From: obiwanzamora notifications@github.comDate: Thu, 30 Jul 2020, 14:39To: dresden-elektronik/deconz-rest-plugin deconz-rest-plugin@noreply.github.comCc: martynstar Martynpb@gmx.com, Mention mention@noreply.github.comSubject: Re: [dresden-elektronik/deconz-rest-plugin] Aqara Battery (#2825) 2 hours of logs attached. I repaired the device at the very start of the 2 hours. Interestingly I just checked the battery with a voltmeter and voltage is 3.02V. So for a 3V battery the fact it is reporting 100% makes sense, just speculating but maybe Xiaomi do not consider 3V as 100% but deconz does? Either way I guess as long as you can see 3.02V approximately somewhere in the logs then should be ok. log.txt

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[obiwanzamora]

Indeed, voltage does not easily map to capacity. I suspect they are just using different algorithms to convert the voltage. Arguably 100% should be approx. 3.2V but I can understand why deconz would report 3.02V as 100%. Tempted to hook it up to a power supply and supply 2.8V and see if the % changes.

[ghost]

That would be an awesome test!Might need to leave it on and gradually degrade it over a day? Just incase it uses the movement to show levels!-------- Original message --------From: obiwanzamora notifications@github.comDate: Thu, 30 Jul 2020, 14:57To: dresden-elektronik/deconz-rest-plugin deconz-rest-plugin@noreply.github.comCc: martynstar Martynpb@gmx.com, Mention mention@noreply.github.comSubject: Re: [dresden-elektronik/deconz-rest-plugin] Aqara Battery (#2825) Indeed, voltage does not easily map to capacity. I suspect they are just using different algorithms to convert the voltage. Arguably 100% should be approx. 3.2V but I can understand why deconz would report 3.02V as 100%. Tempted to hook it up to a power supply and supply 2.8V and see if the % changes.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[SwoopX]

@obiwanzamora So, your Voltmeter is correct, the sensor reports 3.025V. What was the gateway showing before?

As I recall, any value above 3V is currently normalized to 100%, 2.5V should be 0%.

[obiwanzamora]

Thanks for checking it. I think it must just be that deconz and Xiaomi use different ranges for calculating the percentage. The important part is that the percentage level is working. It is arguable that 3.2V and above should be 100% but not crucial.

[SwoopX]

There's also another value which might be considered for it, but its purpose is currently unknown. That's why I'm asking what the Xiaomi gateways says. It give me 91 or 84 respectively as integer.