AEOTEC Door/Window Sensor 7 Question

The Aeotec Door/Window Sensor 7 Series driver does not seem to recognize the Wakeup Notification message from the device as an Event. Should it? I would think so. The problem I am experiencing is that my Device Watchdog setup keeps flagging these devices on doors that are infrequently opened. Without the wake-up notification being set as an event, I can't think of another way to keep track of the actual responsiveness of these devices.

Can you answer this question or offer suggestions?

LJ

@bobbyD any thoughts on this? Any help would be welcome.

I am just pinging this one more time since no responses yet. Should the wake up notification message trigger an event in the driver?

LJ

@bobbyD

Are you running this on a C7?

I’ve turned in many bug reports to support on this driver since it was introduced, no response except that they have been referred to engineering. Good luck getting an answer. I wish there was some way to go back to the Aeotec Door/Window Sensor 7 driver, which worked, but that driver is no longer available as a choice now that the buggy Sensor 7 Series driver was released.

No on a C5

LJ

I got the same response, but I am good with that. I would rather see them working on the Protection service than this. I can wait on this.

s[quote="672southmain, post:4, topic:50278, full:true"]
I’ve turned in many bug reports to support on this driver since it was introduced, no response except that they have
been referred to engineering. Good luck getting an answer. I wish there was some way to go back to the Aeotec Door/Window Sensor 7 driver, which worked, but that driver is no longer available as a choice now that the buggy Sensor 7 Series driver was released.
[/quote]

1 Like

Now that 2.2.4 is out, I would like to ask @bobbyD if we could take a look at this one and see if the wake up from these devices could be used as an event. See first message.

LJ

The Wake-up is really "tamper". Here's the page from the manual:

Bryan Copeland (@bcopeland) is really the person to ask. He is working on fixing issues in the consolidated driver right now. See towards the end of this thread:

@672southmain

I am not sure this gets to my issue. I am not having problems with the function of the doors sensors on doors which are frequently used (meaning daily). However, I have three doors that rarely get used. These sensors don't send any messages most of the time other than low battery and scheduled periodic wake-up messages, thus the Last Activity At event date rarely gets updated. I use that event to monitor that the devices are still functioning and communicating. In this case, the wake-up notification is not a tamper notification. Your documentation shows a way to trigger a wake-up and keep the device in a wake-up state, but the wake-up message is defined in the z-wave specification as a specific message type that signals the controller that it is ready to accept updates and other commands. I am hopeful that the HE gurus can set an event state which increments the Last Activity At event date and time so that we can confirm that the device is still healthy. The old driver seemed to do something like that. This new one does not.

LJ

@bcopeland

I know you have been doing a lot of work on the newest Aeotec Door/Window Sensor 7 driver recently and as noted above we suspected you might have this ticket in you list but since I haven't seen my issue corrected I am thinking that you don't. Is what I am describing above possible to do. With the old driver the Last Activity Date seemed to stay current with wake ups or battery check ins and I wouldn’t get notified that the device hadn't checked in. Now it doesn't and I get notified every day that the devices haven’t been seen in over 24 hours by Device Watchdog.

Can you help address this.

LJ

Ok, now I understand, and mine operate as yours do (not as you want).

Screenshots of 3 Aeotec Recessed Door Sensor 7 devices

Like you, the Library Closet Door sensor is rarely activated. See screenshot showing that it last opened two days ago (last activity December 8), whereas the other two (Bedroom Closet and Coat Closet) had activity today (last activity December 10).

However, all send battery reports every hour or so. See logs, below, showing Bedroom closet activity today, and Library Closet battery report today (bottom of log). However, the Library Closet battery report didn’t generate a Last Activity entry on the driver page.

Edit: the Bedroom Closet and Coat Closet Doors did open and close today elsewhere in the logs, but none of the battery reports generated Last Activity updates. Perhaps that is a feature. I don’t remember how it was before.

Logs screenshot

Sorry I didn’t understand before.

Note that all 3 have been updated with the recent Aeotec firmware to address the S2 bug that Bryan Copeland (@bcopeland) found.

Isn't that firmware update just for the recessed door sensor? I have the Door/window sensors. Did they have that bug too? I can't find a firmware update for those.

LJ

Yes, that update was for the Recessed Door Sensor 7.

My response was because the two devices (RDS7 and DWS7) are using the same driver.

I don’t know if the Door/Window Sensor 7 has the S2 bug. I have my DWS7 paired with no security - seems like I recall, when I added mine, the C-7 had just come out and was having horrible problems with S2 on everything, so I did mine with no security. Because how I’ve got mine mounted in a wood block frame next to my garage door track, it’s non-trivial for me to take it off to remove the cover and hit the tamper switch to exclude/reset/include.

Mine is running firmware 1.01, and that’s the latest firmware update for the DWS7 that I see on the Aeotec site just now when I checked. I didn’t understand that you were asking about the S2 issue, only about the fact that Last Activity didn’t include battery reporting.

Here are screenshots showing that Last Activity reports only contact sensor operation, not battery reporting, for my Door/Window Sensor 7 that runs the same driver as the Recessed Door Sensor 7.

Screenshots for Door/Window Sensor 7

@bobbyD @bcopeland

Guys I have inquired about this issue a number of times and have gotten no response from you for many months. Bobby said it was referred to development. I am simply looking for a response to tell me if this is in the plan or not able to be or going to be addressed?

Please get back with some answer so I don’t stay hanging here.

LJ

No.. An event is driven by an attribute change.

Are you having a problem with the device? Or just it’s appearance in “device watchdog”

It is not a problem with the device except that it used to not exhibit this in the older driver. So to that extent it is problem with the new driver. The older driver apparently changed the state or caused an event somehow.

I understand your answer on state change but can the battery checkin message that device sends out ever 24Hrs or so constitute a state change? The actual battery level might not change from day to day on doors that are not used regularly but if the battery level field is simply overlaid with the same value could that constitute a state change?

LJ

It was being filtered out unless the % actually changed.. But in 2.2.5 the driver has been updated to force state change on battery reports.

3 Likes

Thanks for that. That helps. As always you guys are the best.

LJ

2 Likes