Aeotec Recessed door sensor 7

Before the 2.2.3 ( C7 ) update I tried to pair the (new) device. Finally got it paired but don’t get open / close to register. So I excluded it, factory reset it and waited. Installed the 2.2.3 update and did the Zwave firmware plus a reboot. Then ran a zwave repair. About an hour later, I included the device. Much faster inclusion than before, then i hit configure. Then closed the door, it registers closed, open the door, nothing changes. It show the battery level at 100 the red light activates upon opening and closing but not showing up in the device as opening ( always says closed )
At one time with the 2.2.2 firmware it always said “open”
Ideas?

1 Like

Model ZW187-A C-7 firmware 2.2.3.119.

I am having the same / similar issues, reports closed then does not report open.

Doing a little more investigating. Looking only at the Open/Closed events that show up in the logs... If I reboot the hub, it seems to detect the first one or two state changes that come through for each ZW187 device after starting up.

If I wait a few minutes, sometimes it will log another single open/close command.

Look to see if it routes through a non existent node. Like mine. I can pair it at the hub, it works perfectly device > hub. then I move it and do a zwave repair and it routes through device A5. As soon as it routes through A5 it no longer works, nothing. I have a repeater ( not A5 named device ) within 6 feet ( that other devices use ) and all is well. I don’t have a device A5 and NOTHING else tries to route there. So I don’t know if A5 is some ghost device in my zwave radio or what. I even removed all security, same A5 routing. But I’m waiting till the next update and then blowing away the Zwave and redoing it all. My zigbee is fine, so I’ll leave that.

Yeah, mine is routing directly to the hub (at least during this troubleshooting), no hops through repeaters.

The interesting thing is if I press the button on the device for ~seconds, which makes the LED solid red and puts it in "wake up" mode, that wake up event is seen by the hub every time. Also the hub is successfully receiving frequent battery level updates from the device.

any update on this ?

Same issue here. I bought 7 of the Aeotec Recessed Door Sensor 7 assuming they'd work with the Hubitat. Any updates?

Nope. I’ve filed a whole series of bug reports on the “consolidated” Aeotec Door/Window Series 7 driver, both for the Recessed Door Sensor 7 and for the Door/Window Sensor 7. Only response has been that the reports have been “referred to engineering”, then silence for months. The consolidated driver is a steaming mess. The older specific drivers for those two devices worked fine, but can’t be chosen any more following the release of the “consolidated” driver, at which point the older, working, drivers became “Deprecated” and disappeared from the driver choices.

It seems to me that a reasonable middle ground would be to have a “Deprecated” set of older built-in drivers that could be chosen until newer drivers had the bugs fixed, and I’ve made that request in my support tickets, too, but, again, silence and no bug fixes.

1 Like

Seems very reasonable to me as well.

Just got a response to my support request saying 'This issue has already been reported and referred to our engineering team. We hope to have a fix in the next update. '

Well I hope this update is coming soon, because I now have 7 useless door sensors... UGH!

So as I sit here with 10 useless door sensors pondering my options, I'm considering using OpenHab for the door sensors and tying it to my Hubitat. OpenHab has drivers that work with the Aeotec Sensor 7 no problem. The other option because of the unknown time it takes for updates, and if it's possible, is having developers create a driver for us to use until Hubitat fixes it in their next release. I Will let you know if we're able to create a custom driver...

Well, I have more info here. One of the issues, inability to set parameters (such as LED disable, etc) presented itself with a solution yesterday when one of mine “Failed” (as it does daily). I did factory resets, excludes, etc., and finally discovered that, if the sensor is put in “wake up” mode (press switch with paper clip more than 2 sec, when LED starts pulsing slowly, but less than 5 sec), then immediately hit Save Preferences in Hubitat driver, and the LED Indicator parameter will be set in the sensor. Nothing about this in the Hubitat documentation (which still, months later shows the older, now-unavailable Aeotec Recessed Door Sensor 7 driver, which worked, as the one to use).

But another issue reared its head in the process - the sensor device, when excluded, factory reset, included again with same driver, now shows a Serial Number of a boatload of all zeroes, and shows a firmware version. The other devices don’t have either of those items, same driver, same devices from same big order I received. See screenshot. Sigh.

Screenshot

Same issues. Any update?

C7 running version: 2.2.3.148.

Device:

  • protocolVersion: 7.12
  • hardwareVersion: 187
  • firmwareVersion: 1.04
  • deviceId: 187
  • S2: 1
  • manufacturer: 881

Make sure you turn in a support ticket. Won’t get fixed unless you do.

1 Like

I just bought one of these, had the same issues. I finally got this to work, as i guess a temporary measure until Hubitat fixes it:

Include the device with no authentication at all, uncheck all boxes. The device also has some advanced functions not listed in the paper manual. After everything is connected, you will want to press the button for 2-5 seconds to wakeup the device, allowing you to set and save the prefrences, such as disabling the LED light whenever the door opens/closes, or inverting the open/close reporting state. I also set the wakeup mode again and then hit use the configure command.

After that's been all done, the sensor is reporting reliably and quickly. Yes, this means no authentication, but at least it's working for now.

Thx @xanmato. I did get an email back from support that a fix is coming. "There is a known issue with the Aeotec Recessed Door Sensor 7 that will be fixed in the next update release."

By the way, does anyone have a good (detailed) link on ZWave security. Would like to understand security during pairing vs runtime security. It's my understanding that un-authenticated is just the pairing process, and that post pairing all comms are dones over AES-128 (good, not great).

1 Like
1 Like

Found this one. Particularly good:

Looks like I'm going to power-up my SmartThings Hub so I can use most of my Z-wave devices.

This is insane.

  • Just purchased a Gen 7 to replace an incompatible Aqara Door and Window Sensors (my bad) that I purchased to replace three Z-wave contact sensors that I thought died after installing our 1st Hubitat hub this week!

This after all kinds of **** with our other Z-wave devices: Generic Z-wave Switches/Dimmers/Outlets and Z-wave locks: Schlage & Kwikset!!!!! plus the 3 contact sensors: 1) Aeotec Recessed 2) Gen5 and a generic Monoprice & 3) generic Monoprice

Having to run polling to hopefully keep these devices alive is insane.

I really was hoping to love this platform.
I hope that Hubitat is paying attention.

Welcome! Sorry that you are having a bad experience.

You did read Paragraph 1.c. of the Terms of Service to which you agreed when registering your hub, right?

c. Customer acknowledges that the Hubitat Platform is under continuous development, is not complete or otherwise at the final stage of development and that Hubitat makes no representation that the Hubitat Platform is error or bug free. Customer acknowledges and agrees that the Hubitat Platform may experience unscheduled downtime and agrees that Hubitat shall not be liable for any harm resulting from unscheduled downtime. Customer acknowledges that Hubitat has no obligation to provide support for the Customer's use of the product.

I don't see a specific question on which you are requesting help from the community. Is there some way we can help?

672 Southmain. Thanks for the quick response.

I understand and understood the terms and greatly appreciate your quick response. Perhaps you can advise me how to me recover 3 of my existing ZW contact sensors and the new Aeotec 7 recessed contact sensor, purchased yesterday. All of these no longer can be seen by Hubitat after they partially connected and failed to join properly. Note, that I reset the devices per the manufacturers instructions.

Many thanks!

I have run multiple Z-wave repairs, restarted and even restored an earlier database to no avail.

Once I know that they are not damaged, I'll be happy to wait for the pending firmware release for a fix. I tried running my SmartThings Hub as a temporary measure, however the ST Z-wave radio interference killed the Hubitat mesh with connections to my locks, etc.

Any tips to recover these devices would be greatly appreciated.

My experience differs... I have 7 Hubitat hubs. Four of them have the ZWave radio enabled, Three do not. I also have a ST hub, and multiple ZWave sticks. My two primary ZWave Hubs, one for everything downstairs, the other for everything upstairs are sitting alongside my ST hub. They are 2 feet apart... almost in a triangle: One hub has the ST Hub 2 ft to the left, and the 3rd hub is directly below, about 2 ft. A 4th hub is joined to those original 3 and it's at least 20 ft away. I have two Yale ZWave locks and they see no interference, that I've detected.

In other words, I live in a sphere of at least 5 ZWave overlapping networks without detectable interference.

I'm NOT saying you don't have interference.. I'm saying that it doesn't have to be so.. and that many people have more than a few overlapping ZWave networks running.