My front door has a Kwikset zw+ lock and an Aeotec 7 contact sensor (also zw+). There's an Aeotec extender right by them. I'm not having any trouble with the lock. It's been very reliable. It's the contact sensor. Every now and then it fails to report the correct state. I'm using the generic contact sensor because I found the "Aeotec Door/Window Sensor 7" driver to be incredibly chatty.
What I'd like to do is...
If the front door is locked and the contact sensor reports open, or if the front door is unlocked and the contact sensor reports closed,
Ping the contact sensor and ask for an updated state.
I can't figure out a way to do the ping. Suggestions gratefully accepted!
Most battery powered devices go to 'sleep', and thus are not listening for incoming traffic, as @kahn-hubitat mentioned. Thus, no Refresh command on those devices. These devices only wake up when they sense a change, and then they transmit the packet and go back to sleep.
Maybe the problem you're experiencing is related to using a driver not intended for this device? It's possible the Aoetec sends commands in a way that the generic driver is not parsing appropriately. I'd back up a bit: what problems did you have with the dedicated Aeotec 7 driver, and have you tried to solve those first? The driver shouldn't be "chatty" unless maybe it's logs, which you should be able to control; if there is Z-Wave traffic (some of which may produce logs, depending on what it is and your settings), that's almost certainly the device.
The generic driver has a "Suppress duplicate contact events?" switch that's not available in the Aeotec device driver. So I solved the problem by switching drivers. And, as I mentioned, most of the time it's fine. But last night at midnight my HSM didn't arm because it was convinced the door was open. Not what I want to deal with in the middle of the night.
My suggestion: enable debug logging (so you can see what Z-Wave commands the driver is parsing into these events, ultimately), then we can tag someone from staff to look at it and see if there's a way to suppress what also appear to be duplicate events here.
In the meantime, if this isn't actually causing problems for you (like double-triggering rules/apps--at least some of those logs look late enough that the event should have finished processing and it probably will be filtered out at the platform level), I'd probably stay with this driver since I assume it at least reports events correctly.
I’ve got the Aeotec Door/Window Sensor 7 device as well (two of the non-Pro, and 4 Recessed Door Sensor 7 devices).
The Aeotec Door/Window Sensor 7 driver became Deprecated as of 2.2.2.123 firmware, when the Aeotec Door/Window Sensor 7 and the Aeotec Recessed Door Sensor 7 driver were consolidated into a new driver, Aeotec Door/Window Sensor 7 Series driver. I believe that the code for the Deprecated driver is still in the current firmware so that you can continue to use it, but, once you switch to the consolidated driver, you will not be able to go back to the Deprecated driver unless you restore an older backup.
I’m not seeing this chattiness on the consolidated driver. However, I set the parameters so that the LED is off so as to conserve battery life.
That is the driver that I'm using, and I also have the LED turned off.
Well... I turned on debug logging and now it's behaving itself. The events in the log are all actually separate opens and closes. I'll keep an eye on it and see what happens. If it gets chatty again I'll report back.
Thanks everyone for suggestions! I love this forum!
If I may offer a suggestion? If this "repeating" continues, unexpectedly...
I had a similar situation with a device repeating like that in the logs. It was my zwave mesh - there was a device that was "flipping out" , and that's why it was repeating.
I know that it's frustrating - because there is no indication which device is the cause! It's just a matter of trial and error to see what's causing this. I also had a device in my mesh that was not 100% compatible, and I was using an old (community) driver.
Thanks for the reply. Right now it seems to have settled down and is behaving itself. I don't know if putting it in debug mode kicked it into submission or what. Not going to argue.
Honestly, I'm not sure how to even troubleshoot a mesh problem. I have a C-5 hub, all of my Z-Wave devices are ZW+, and I haven't added anything new or changed anything for quite a while, except changing the front door lock to the ZW+ model. That was a couple of months ago, and I was having this problem before that, also.
Chattiness resumed today. See the screen shot, which is just one example. "Front Door" (dev: 1928) is the Kwikset lock. "Contact Sensor - Front Door" (dev: 1697) is the Aeotec Door/Window Sensor 7. I'm using the "Aeotec Door/Window Sensor 7 Series" driver, which I believe is the correct "new" one. Sensor Operation Mode is set to Internal Magnet Sensor. Report Closed When Magnet Is Closed. LED Indicator is disabled. There aren't any other options to set.
It also missed a close event yesterday and the HE thought it was open for several hours. For now I've taken it out of HSM.
Really hoping someone can help me debut this. I'd prefer not to replace this sensor. The door frame is such that only a really small magnet will fit there.
ETA: It seems to mostly chat about being open. I wonder if it's sending multiple open events? Can the hub stutter? Or does the device stutter? One of the reason I'd gone with the generic ZW Contact device driver was because it had a "Suppress duplicate contact events" option.
This might be a stupid question, but...are you sure these open/close events aren't the magnet being a touch too far away? Maybe the sensor is thinking the door is opening/closing constantly because it's just on the edge of the max distance for that magnet...if you temporarily tape the magnet right to the sensor (force it to think it's always closed), that might prove/disprove it.
Good suggestion, but I don't think that's it. It does't always do it. For example, I just opened and closed the door to see what would happen. It was fine. The door typically gets opened when I'm leaving, so it gets opened all the way. I'm usually taking the dog out for a walk. He's trained to sit in the doorway until I tell him "OK." He's not a big dog, but with both of us going through the door, it has to be completely open. The door was completely open the whole time it was "chatting." You can see that the closed event comes just before the door is locked, which is correct.
This screenshot shows what I expect: (1) door unlocked, (2) door opened, (3) door closed, (4) door locked.
