AEOTEC Door/Window sensor help please...

[Tommy Sharp]

Hi Everyone, I'm just getting started on trying to add some z-wave devices to my openHAB setup which I've had running for a few months with some relays and a DSC alarm.

My first attempt is the AEOTEC Door/Window sensor (version 2 I think)...

I've actually got the sensor side of it working and can see the OPEN/CLOSED on my sitemap, the problem is that the battery level doesn't seem to be reporting.. It always shows as 0% in my sitemap...

Anyone got any advice on what I need to do to get this working? 

Here is the detail of my items configuration, I got it first from the WIKI.

Contact Contact_MF_Office "Office Sensor [MAP(nl.map):%s]" <contact> (GMF_Office) {zwave="2:command=sensor_binary,respond_to_basic=true"} 

Number Contact_MF_Office_Battery "Office Sensor battery [%d %%]" (GMF_Office) {zwave="2:command=battery"}

Any help would be appreciated.

[Martin Naughton]

for battery information you have to poll the sensor from the controller to ask for the information. Sensor does not send that information automatically. Check the openhab zwave page and see refresh interval. That means it will poll it to an interval that you set. I sent mine to once a day with 86400 seconds.

[Ben Jones]

How long have you been 'waiting' for - battery reports will only be sent when the device wakes up.

The other thing to check is the device associations to ensure it is configured to publish notifications to your controller.

The item binding for the battery item looks fine to me.

[Ben Jones]

Martin - the binding automatically schedules battery poll requests if it finds a BATTERY item binding (I believe). I don't have any polling interval configured but my battery reports are received no problem. I notice in my ZWave logs that battery requests are generated every hour or so but because the device is usually asleep only a single request is ever queued up.

When the device wakes up the battery request is sent and a response received.

[Chris Jackson]

> Martin - the binding automatically schedules battery poll requests if it finds a BATTERY item binding (I believe). I don't have any polling interval configured but my battery reports are received no problem. I notice in my ZWave logs that battery requests are generated every hour or so but because the device is usually asleep only a single request is ever queued up.
>
> When the device wakes up the battery request is sent and a response received.

This is correct Ben - the binding requests the update every hour automatically. Also, a number of devices will automatically send battery updates when they wake up.

[Tommy Sharp]

Hi Ben, it's been over 24 hours now and I have been opening and closing the contact which has been sending updates to OpenHAB for the OPEN/CLOSED state of the contact... But it's not updating the battery number. 

[Ben Jones]

One thing to remember, 'waking up' in Z-Wave speak is not the same as a
sensor node sending a state change - e.g. door opening.

The device will wake up periodically (configurable in Habmin) and handle
any config/network commands, and these include battery requests.

Just because your device is sending OPEN/CLOSE events, doesn't mean it
has 'woken up'. They are two different types of operation.

You would need to check your logs to see if that device has woken up at
any stage in the last 24 hours. My Fibaro Flood Sensor is scheduled to
wake up every 6 hours but often misses the window for some reason - but
it eventually gets thru. I might go 36 hours without a battery report
but they eventually come thru.

[Chris Jackson]

Bens 100% right - wakeup isn’t the same as receiving data from the device. This causes a lot of confusion - I might add something to HABmin to say when the last wakeup was.

However, it’s also worth looking at the wakeup configuration (in HABmin) to see what it thinks is set?

Chris

[Tommy Sharp]

Thanks Chris and Ben.... Good to know that a wakeup is different to actually receiving data...

Looking in HABmin I can see that the wakeup interval is set to "1680".... Is that minutes?

Under Power we have "Battery 0%".....

[Chris Jackson]

>
> Looking in HABmin I can see that the wakeup interval is set to "1680".... Is that minutes?

No - that will be in seconds.


> Under Power we have "Battery 0%"…..
If you mean that this is what HABmin is displaying, then this means that the device is reporting the battery is 0%. If it’s not received a battery level, it would show “BATTERY UNKNOWN”.

[Tommy Sharp]

Hey Chris, tested the batteries and they were about half charged.... put some fresh ones in and now have 100%...

Thanks!

[Chris Jackson]

My experience with the battery indicators in zwave devices is that it's not very accurate. I suspect it uses a simple voltage based althorithm rather than a more complex, but more accurate fuel gauging method...

Chris

[Ian C]

I can vouch for this, using 1.2 V rechargeable AA batteries vs 1.5V alkaline, an Aeotec multisensor will consistently report a low battery, and because the voltage is (more) constant than an alkaline during discharge, it doesn't change nearly as much as an alkaline.

[Ian C]

Also, sorry for the multiple posts, but I see that it's been noted the difference between a "wakeup" and a command sending. Another thing to note is that the door sensor is a battery operated device, it doesn't necessarily behave as you'd think. Chris and Ben have some good explanations of the wonkiness you might see there.

Basically, after looking through the debug logs as they suggest, if you don't see a battery command class received from that node, you may want to check in Habmin that it's set to (at whatever that wakeup interval) is broadcast battery status. 

If you're still having trouble, debug logs and a screenshot of the Habmin config page for it would help.