Please post the specifics of what's not working with a c7 included without security that did work with the previous driver.
1 Like
Ok, Mike,
I will try to report, once again, and consolidate my bug reports as concisely as I can, including new information from Bryan today. I have never received a response from support to most of these except a canned reply that they were being referred to engineering. On the final support ticket (18627), I was told on October 2 that a fix was expected in the next (then upcoming, 2.2.4) release, but nothing more. I have been looking carefully through the release notes and hot fix notes and have never seen anything addressing the issues except the battery reporting issue that was fixed. I am a patient person, and I have generally been content to wait for things to be fixed. I realize that my issues are not the most important ones.
I am sympathetic to the time that it takes support and engineering to investigate and attempt to replicate issues reported by users. I would hope that you are sympathetic to the time it takes me to carefully document and replicate each of the issues I report, and to do regression testing each time a firmware release occurs. This can take hours on my end, and I suspect that it can take more hours on your end because you have to configure something that may not match my configuration in an attempt to replicate at your end.
I started this thread in a moment of frustration. I appreciate that you are willing to look at these issues. My frustration is simply that they seem to have fallen into a black hole by being "referred to engineering" for months and will never be addressed. It wouldn't bother me if they stay on the back burner until crisis items die down, but Bryan's post near the end of this thread seemed to indicate that he was moving on and had decided that there were not any further issues with this driver that needed to be addressed (other than the S2 Aeotec firmware bug):
To me, this seems to indicate that my issues will never be addressed. Never is a very different status than low priority.
I have 3 Aeotec Recessed Door Sensor 7 devices (on closet doors in our home) and one Aeotec Door/Window Sensor 7 device as the contact sensor for our LiftMaster garage door running the user-contributed MyQ Lite driver. I have never opened a support ticket on the MyQ Lite driver (because I recognize the difference between community contributed drivers and built-in drivers), and, the couple of times I have needed help on that driver, I have received exemplary help here in the community forum.
That said, here they are:
Support Ticket 17623
This was simply to report that all three of my Aeotec Recessed Door Sensor 7 devices, using the "Aeotec Recessed Door Sensor 7" driver, reported that the driver became "Deprecated" upon installing firmware 2.2.2.123 on my C-5 (now retired). Bobby D responded that the driver had been consolidated into the "Aeotec Door/Window Sensor 7 Series" driver, and that I could either switch to the new driver or else continue using the older driver. Sadly, this is not true.
I am unable to choose the Aeotec Door/Window Sensor 7 Series driver, which worked perfectly for me, after migrating to my C-7 because the older, deprecated driver no longer appears in the choice of built-in drivers. I have requested in my subsequent support tickets that some mechanism be provided for selection of older, deprecated drivers when they become retired and the replacement drivers no longer work, but there has not been any progress on that front.
Support Ticket 17646
This was simply to report that, after installation of 2.2.2.123, when changing the driver for the Aeotec Door/Window Sensor 7 device from the "Aeotec Door/Window Sensor 7" driver to the "Aeotec Door/Window Sensor 7 Series" driver, the "Report Closed When Magnet is" preference changes from "Closed" (the default) to "Open", thereby changing the reporting sense of the sensor. I observed this when following the suggestion made by Bobby D in his response to Support Ticket 17623 (see above). This repeatable bug was only able to be tested in regression testing by reverting to a 2.2.2.116 backup, in which the driver selection was for the older driver and in which the older driver was selectable in the driver type drop-down, changing to the older driver, updating the firmware to 2.2.2.123 (or later), and observing the results. I lost the ability to do this regression testing when I migrated my C-5 devices to my C-7, so I do not know whether it still exists. As I have said before, I would be happy to be able to revert to the older, now deprecated, drivers, but they are not available for choosing in any of the new firmware releases.
Support Ticket 17749
Issue:
Aeotec Door/Window Sensor 7 does not properly report status after switching from now-deprecated Aeotec Door/Window Sensor 7 driver to Aeotec Door Sensor 7 Series driver.
Repeatable on C-5, unable to test after migrating to C-7 because new consolidated driver can no longer be selected.
Repeat by:
Start with platform firmware 2.2.1.116 (restore from backup file), which includes the older Aeotec Door/Window Sensor 7 driver, choose Aeotec Door/Window Sensor 7 driver for Aeotec Door/Window Sensor 7 device. Leave default preference âReport Closed When Magnet is Closed [Default]â. As a remark, I changed the LED to Disabled to extend battery life, but that doesnât seem to affect any bugs discussed here. Save Device, Save Preferences, Configure.
Update to any of 2.2.2.122 - 2.2.2.129. Save & download a backup for reversion, discussed below.
Observe proper operation of MyQ Lite garage door driver and proper reporting of Aeotec Door/Window Sensor 7 device status.
Change driver to Aeotec Door Sensor 7 Series driver. Because of earlier bug, change âReport Closed when Magnet is Openâ to âReport Closed when Magnet is Closed [Default]â (see Ticket 17646, discussed above). I also set the LED to Disabled to extend battery life, but that doesnât seem to affect any bugs discussed here. Save Device, Save Preferences, Configure.
Observe bug: Sensor doesnât change state when magnet contact changes during operation of garage door, causing garage door driver (and garage door tile) to misbehave. This is not merely a case of misbehaving user driver - my dashboard has on it a tile for the garage door (Tile Device: Garage Door (from MyQ Lite driver), Template: Garage (Control)), but also has an adjacent tile for the Aeotec Sensor (Tile Device: Garage Door Sensor (with Aeotec Door Sensor driver)) so that I can compare the sensor status with the status from the MyQ Lite driver.
Workaround: revert to saved downloaded backup of 2.2.2.129 with deprecated Aeotec Door/Window Sensor 7 driver. Observe correct operation of Aeotec sensor and MyQ Lite driver.
I am no longer able to test this bug because, as explained above, after migration from my C-5 to C-7, and with numerous other device additions, I can no longer revert to the older driver.
My workaround upon migrating to the C-7 was, during migration, to exclude the Aeotec Door/Window Sensor 7 device from the C-5, reset it to factory defaults, include it on the C-7, configure using the new driver, and the sensor correctly changed state.
The consolidated ("new") driver no longer has a "Refresh" tile, that the older ("Deprecated") driver had. I believe that the lack of this tile made testing more difficult.
Again, as mentioned above, I can no longer use the older, deprecated "Aeotec Door/Window Sensor 7" driver with this device, but, despite Bobby D's assurance in his response to Support Ticket 17623 that the older driver could continue to be used, it can no longer be selected on my C-7 after migration from the C-5.
Support Ticket 18449
Configuration: C-7 running firmware 2.2.3.148
(1) Battery status is not reported on Aeotec Door/Window Sensor 7 device. That status parameter is simply not there on the device page, and thus cannot report to a dashboard tile. Repeatable. Was reported correctly on Deprecated Aeotec Recessed Door Sensor 7 driver, which I am unable to choose on the C-7 after migration. However, the battery status is correctly reported on Aeotec Recessed Door Sensor 7 devices using the same driver.
This issue seems to have been fixed with the 2.2.4.139 update. Thanks.
(2) Disable LED choice in Aeotec Door/Window Sensor 7 Series driver has no effect, not on any of the 3 Aeotec Recessed Door Sensor 7 devices, nor on the Aeotec Door/Window Sensor 7 contact sensor. I would like to disable the LED to improve battery life. This setting, which worked in the older, now-deprecated built-in Aeotec drivers, doesnât work in the consolidated driver. Repeatable on C-7.
I figured this out on my own, and Bryan Copeland seems to confirm today when he reported that the wake-up switch doesn't really wake up the device, but instead just triggers a NIF (Node Information Frame); you have to wait for the next wake-up period.
I figured out the solution about the beginning of October 2020:
You have to do the following with the device page open: set the preferences as you want them, then wake up the device, save preferences. It has to be done rather quickly. Worked for me.
Now, this doesn't quite agree with what Bryan Copeland posted today about NIF, but I posted this as a solution for another user trying to save parameters for this driver, and it solved his problem, and it solved mine. Here is that post of mine for the Door/Window Sensor 7, which has also worked for me on the Recessed Door Sensor 7:
Aeotec Door/Window Sensor 7 - Dry Contacts - #2 by 672southmain
Perhaps Bryan Copeland didn't do it all quickly enough. After doing this dance, I used the magnet to activate the device, and the parameters seem to have taken hold.
(3) on the C-5, one of the Aeotec Recessed Door Sensor 7 devices reported a âtamper: clearâ status, when that device does not have a tamper switch. The other two devices, using the same driver, did not. See attached screenshot below. When I migrated to the C-7, this oddness disappeared on this device, such that, after I solved the LED issue discussed above, all of the Aeotec Recessed Door Sensor 7 devices now operate correctly on the C-7 (though there are some oddities, discussed below).
As noted above, this issue disappeared when I manually migrated from the C-5 to the C-7 by exclude/reset/include. This device (Bedroom Closet Door sensor), however, still has other issues, discussed below.
Support Ticket 18627
This support ticket was to report good news and odd news.
Good news:
I 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). So, I suggest you add a sentence in the documentation about needing to put the Aeotec Recessed Door Sensor 7 (and Door/Window Sensor 7) into Wake Up mode before tapping Save Preferences to set the deviceâs configuration parameters.
Oddness:
Two of the Recessed Door Sensor 7 devices (Coat Closet Door sensor, Library Closet Door sensor), when excluded, factory reset, included again with same driver, now show a Serial Number of a boatload of all zeroes, as long as your arm, and show a firmware version. The other Recessed Door Sensor 7 device (Bedroom Closet Door sensor) doesn't have either of those items (no serial number, no firmware version), same driver, same devices from same big order I received. See attached screenshots below.
Interestingly, the device (Bedroom Closet Door sensor) that doesn't show a serial number and doesn't show a firmware version is the same device that earlier, on the C-5, indicated that it had a "tamper" switch that was "clear".
All three Recessed Door Sensor 7 devices are operable, after a fashion. Two of them, prior to 2.2.4, used to indicate "Not Responding" or "Failed" after a couple of hours, but would continue to function perfectly, and would return to "OK" after the door was opened and closed. I'm not one to obsess over the Not Responding / Failed issue, and I ignored that as long as the device operated. I have not seen a single instance of "Not Responding" or "Failed" on any device, not just these, since 2.2.4 was released. Thanks.
There is another oddity about the Bedroom Closet Door sensor. First thing in the morning, it takes five to ten seconds to respond (turn on the light). Once that has happened, it will operate quickly the rest of the day.
I don't believe that this is a mesh issue or a weak signal issue. Our house is small, and I have Ring Range Extender 2 devices every 20 to 25 feet, and have put an Aeotec Range Extender 7 about 5 to 10 feet from the Bedroom Closet Door sensor with no intervening walls. Even so, the Bedroom Closet Door sensor is about 25 feet from the hub vertically and 6 feet horizontally, and the hub routes directly to it.
Here are Z-Wave Details screenshots. The Garage Door Sensor is the Aeotec Door/Window Sensor 7; all others are Aeotec Recessed Door Sensor 7 devices.
Now, if your suggestion is that I need to exclude some or all of the devices on this consolidated driver, reset all of the Aeotec devices to factory defaults, include again, I will do that if you think it would help. The frustration on this end is that there is no support ticket tracking. I (and I suspect, others) never hear again from Hubitat once a ticket gets the dreaded "referred to engineering" response. I never see anything in the release notes about any relevant fix (except here for the mention about battery reporting, which fixed one of these issues). There's no way to see if the ticket has been closed and resolved, or closed because the issue can't be reproduced.
Again, I'm a patient person. Hubitat staff is doing an amazing job, in my opinion. Some great engineering. I see that all of you are working hard, putting in long hours. My issues are not the most important. If there are some cosmetic issues on driver pages, or if a light takes five or ten seconds to turn on, that's not the end of the world. Other Hubitat users have bigger issues than mine.
Oh, and these are just the issues I am seeing. There are many other posts in the forum from others with issues with this driver. I would hope that those users have filed support tickets as I have, and that they follow up if their issues have not been resolved.
Thanks in advance.
Can someone please refresh me about what secure pairing (S0) offers over unsecured? I know door sensors and locks have this and S0 is known to be "chatty" on zwave. Im really stuck on why locks and door sensors are "secured". Does this offer anything better on packet sniffing or something?
Fast forward to S2 with the available options. Which options are best for what? Im fine with a linked post explaining this.
In my cases, all my zooz stuff, i have re-paired everything back with nothing checked for the S2 popup, as almost every device was locked up or locked up my mesh when i added as S2 Unauthenticated.
I have a few HomeSeer switches and Inovelli Switches, which i did allow to pair S2 Unauthenticated and they seem to work alright.
My mesh has been stable and I'm still on the 2.2.3 release (waiting for things to quiet down, and looks like we are almost there), before installing 2.2.4.
I ask because I'm looking to buy some more recessed contacts and wondering if should buy some older versions or look for something with S2.
Here is a thread that discusses the basics. The following link, and its reply, have the essentials:
If that's not enough, post again and I can provide a more full explanation. Basically, the S0 and S2 pairings use different key exchange mechanisms, which is why S2, the more recent protocol, only takes 1/3 the packets to do the key exchange. Both are secure. S2 authenticated uses a different key for each device rather than one key for the network. S0, with 3x the traffic, is more congestion on your mesh and a bigger power drain on battery-powered devices.
Unsecure pairing might allow someone to sniff your traffic and possibly inject packets to operate a device. Not good if you are controlling a lock, sending unlock/lock key codes, etc.
People differ in what they want. I only want/need secure pairing on access control devices like locks, external doors/windows, alarm system components; other things, I don't care and can have them with no security. YMMV.
The bigger concern, in my opinion, is that you should get Z-Wave Plus devices rather than non-Plus because of the better route-improving decisions that Plus devices automatically and continuously make during normal operation.
Whilst i appreciate the thoroughness of your response, my question remains unanswered.
I'm less interested in the history here, and more interested in why you think the current driver running on a C7 when included without security is not functioning correctly.
It's a simple device, and it either works or it doesnt. If the device when using the new driver, included on a c7 with out security doesn't work, then say what doesn't work.
I really can't help without that information,
Sorry, Mike, I thought I provided it. There's really nothing more I am able to provide. If you don't want to read what I took the time to document and write, ok.
You will need to exclude, then factory reset (just to be safe), then re include these with all the security settings unchecked.
This is the firmware bug that Bryan mentioned, these will not work correctly with S2 security enabled.
2 Likes
Aeotec confirmed the issue and has stated they are preparing a firmware update to fix the issue.
8 Likes
Amazing thanks for the update
2 Likes
@bcopeland I just want to thank for all your help in this situation. I sure everyone appreciate this time you took to keep everyone inform about this issue. Thanks you and have a good thanksgiving.
4 Likes
These seem really chatty. Is there any way to slow that down?
On the C-7? How are you joining them? Because of the S2 bug in the Aeotec firmware, I've joined mine without security and I am only seeing open/close events when they happen and an occasional battery report every 6-12 hours or so. Even when I had mine joined with S2, All I saw were the occasional battery reports. Of course, I didn't see door open/close events.
I originally has it set up with S2 but rejoined it without when I read this article.
I know it's no help to say "I'm not seeing that".
It may help to post some logs of the sensor when it's being overly chatty so others can see what's going on.
1 Like
Recessed Door Sensor 7 firmware V1.05 is now available, you can find it at this link here: Update Recessed Door Sensor 7 V1.05 : Aeotec Group
This firmware update will resolve the session ID issue with Supervisor CC.
6 Likes
Has anyone successfully updated yet. I seem to be held on the Firmware Update Status page on Getting Device Versions (for 15 mins). All thatâs happening is the done button occasionally changes colour?
Ok.. Slight oversight on my part.. Sleepy devices need some work.. what you are going to want to do is disable the device (so it canât send wakeup no more information). Then trigger a wakeup right before you start the process
1 Like
Thanks for the speedy reply, will try now!
Future updates I plan to intercept the wake up
4 Likes
Iâm getting further now. Made it to the Requesting Device Start Firmware Transfer and being held there 
Will keep trying
