Small door window sensors but the batteries are only lasting about 3 weeks

[Rupp]

Guys,
I purchased several of these but the batteries aren't lasting more than a few weeks. Any of you guys have this issue or are the batteries that ship with these die out quickly?

[Guest]

2 years here.. still at 90-100

[Michael McSharry]

I have not seen in decline in the same sensor in battery level for several months. Make certain you are not polling status frequently.

[w.vuyk]

No polling of the device itself is done by the plugin. The Xiaomi/Aqara devices send their own report, instead of being polled. Maybe once per hour, others maybe slower.
I have an older version of the same device and batteries have been holding for two years now too (91%). And the batteries are the ones that were shipped to me in the device.

Unless the door or window opens very often they should last quite long?

[Rupp]

Ok, last night one of the door and window sensors quilt working so I removed it and added it back to the plugin. This time it just created a battery device and a root device. The battery was reporting 0% so I assumed is was dead. Overnight it's now reporting 93% so it appears to be reporting battery status BUT it never created the actual open/close sensor in HS3. I just fired up Phoscon and it shows a sensor and when I open and close the door it show the animate image of the sensor opening and closing. This sensor also shows fine in the deCONZ app. What do I have to do to get it back as a device within HS3?

[Rupp]

Update to my last post. I deleted the two devices that were created the last time I restarted HS3 (Battery and Root) . When I deleted these two devices I had a popup on my HS3 server that JowiHue plugin had stopped. I then restarted HS3 again and this time it created 3 devices (Root, Battery, and Open/Close sensor). So it appears I'm back to where I started but I'm wondering why this sensor stopped working in the first place. It's exactly 18 ft from the sensor through two walls.

[w.vuyk]

Rupp,

If you delete device belonging to the plugin, you need only to delete one device belonging to the parentgroup. The plugin will take care of the rest. Somtimes when you delete two or three devices of the same parentgroup the plugin comes to a halt, like you have been seeing. I have tried to catch it, but apearrantly I still did not catch it all. If you had pressed the ok button, I am pretty sure HS3 would have restarted the plugin itself.

A battery controlled device, and certainly Xiaomi/Aqara device are stubborn bound to where its router (plug/light/repeater) or coordinator is connected. You can check where a device is connected to in the deCONZ inteface, wich will give you a graphical representation of its mesh network.

I don't know if you have any plugs/lights or repeaters in your zigbee network. But lets say you have one light in the network. When you join the open/close sensor to the network it can choose between the coordinator and the bulb as its router. If it chooses the light, it will then always send its signal to this router. Especially Xiaomi/Aqara sensors stick to that choice and will not willingly change that. So if you switch power off the light, the open/close sensor can no longer reach the light, but will not then connect to the coordinator, unless you do the reset on the device and rejoin it to the network. Even if ths sensor is 2 feet away from the coordinator, it will keep searching for its original router.

Is it possible that you had a router in the network that was switched off?

As far I know other brands (Ikea, Nico, Philips, Bush Jaeger) do not have these issues, but might need a second trigger before the signal is connected to the different router.


Wim

[fresnoboy]

Wim, I made the mistake of adding the sensors before I mounted them in the their proper locations, so they all were unreachable. I went into the deconz app, deleted them, and then reset the sensors (Xiaomi multisensors), and then readded them. Things looks right, but only one of them is reporting updated battery levels (100%), since I swapped the batteries because of the devices showing 0% battery after I added them.

How do I know if the sensor is really in contact with the network and able to communicate?

If I click the switch, does that trigger an update?

thx
mike

[w.vuyk]

fresnoboy,

It would have been a lot easier that how you did this. All you needed to do is set the search for new devices in the configuration page of the plugin and then reset the Xiaomi device by pressing the small button for 5 seconds. Then you would try to find a new router to connect to. No need to remove the sensor from deCONZ.

As for the battery showing 0%, if they are newly added the sensors often show the 0% battery. Wait for a day or so and it will then report the correct battery values.So you might have swapped them without needing to.

If you doubt, indeed click the switch it should update the device in HS - check the last change column in the device utility page (you might have to enable this in the settings/custom page).
Most (not all) Xiaomi devices report to deCONZ once per hour, so if you check the root device's time you should see the time the sensor last reporting time.

Wim

[fresnoboy]

fresnoboy,

It would have been a lot easier that how you did this. All you needed to do is set the search for new devices in the configuration page of the plugin and then reset the Xiaomi device by pressing the small button for 5 seconds. Then you would try to find a new router to connect to. No need to remove the sensor from deCONZ.

As for the battery showing 0%, if they are newly added the sensors often show the 0% battery. Wait for a day or so and it will then report the correct battery values.So you might have swapped them without needing to.

If you doubt, indeed click the switch it should update the device in HS - check the last change column in the device utility page (you might have to enable this in the settings/custom page).
Most (not all) Xiaomi devices report to deCONZ once per hour, so if you check the root device's time you should see the time the sensor last reporting time.

Wim

Wow, this worked great! And why is it that I needed to do scan devices and not scan sensors in the plugin? Either way, that process worked really well - very easy to reset!

It would be good to put this in the documentation or an FAQ.

Do I even need to use Deconz to set the name or add a node?

Thanks!
Mike

[w.vuyk]

Mike,

If you rename the device in HS, on the properties/JowiHue page the new name will be send to deCONZ/Phoscon. So you would not need to set in thos interfaces. You would need Phoscon for registering the gateway only. The deCONZ window is usefull for checking th connections of lights and sensors as it will give you an impression on the quality on reachability of devices.

Scanning for sensors would have done the same really. It would have limited its search to sensors, in you case it would have worked just fine.

[fresnoboy]

Wim, I am still having issues with the sensors. After resetting them and each of them communicating status well to HS, after a couple of days only one of the 5 sensors is updating, even if I click the switch on top of the sensor.

What is going on? I am using the Securfi Peanut switches as repeaters - are they not reliable in that role? One of the sensors seems fine working though.

thx
mike

[w.vuyk]

Mike

To be honest, never heard of the Securfy Peanut switches here. Are those powered switches as battery devices will never act as repeaters? So far I know of plugs and lights being repeaters (routers) and a IKEA dedicated repeater.
You can check on the deCONZ window to see if the swtiches are acting as repeaters (yellow block on the device, gray for battery devices) and on the connecting lines if they are connecting to the sensors.

Wim