Firmware 2.2.4 and Aeotec Door/Window Series 7 issues

[672southmain]

@bcopeland and @mike.maxwell,

First, thanks for all of the hard work that both of you, and the others on the staff, put in to get the 2.2.4 release out. Clearly, it involved a great deal of work.

However, I don’t see anything in the release notes about bug fixes for the consolidated Aeotec Door/Window Series 7 driver.

Ordinarily, I don’t post bug report issues in the public forum, and I realize that this forum is not the official support channel. I prefer to go through regular channels (file a support ticket) but I am at a bit of a loss as to what to do now about the unresolved problems with this driver.

As @bobbyD knows, I have submitted a series of support tickets for this driver ever since it was released, consolidating the “Aeotec Door/Window Sensor 7” driver and the “Aeotec Recessed Door Sensor 7” driver, and those older drivers became Deprecated and no longer selectable. See, for example, beginning July 27, support tickets 17623, 17646, 18449, 18627.

Each ticket always ends up being closed without resolution, with the comment that the ticket has been “referred to engineering.” After the most recent ticket (18627) was submitted, it was closed on October 5 with a comment from support:

Thank you for taking the time to reach out to us. This issue has been reported to our engineering team and they hope a fix will be released in the next update.

I’m not the only one having problems with this driver. See, just as one example, this thread:

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 activate…

What should I do now?

Should I exclude, reset all of these devices, include again, and go through the hours of regression testing and submit the tickets again?

Candidly, as I have mentioned in my support tickets, my preference, if the problems with the consolidated driver aren’t going to be addressed, would be to go back to the prior, now deprecated, unconsolidated drivers, but that’s not an option because they are no longer available in the driver choice list.

Is this simply an inadvertent omission from the 2.2.4 release notes, such that the problems with this driver have been addressed but just not mentioned in the release notes?

Thanks in advance for your suggestions for a path to resolution.

[bcopeland]

I worked with someone on this and distinctly remember this problem being resolved .. What exactly are you seeing?

[ourmessages]

IIRC this was not resolved. My DW/7 doesn’t work and I never addressed it as I was under the impression 2.2.4 would fix it, so I have been waiting also. The device doesn’t work using the A DW-7 driver.

[672southmain]

If anything was resolved, there is no note in the release notes that anything changed in the driver. If you worked with someone, it wasn’t me. I just submit tickets, am told that it’s been referred to engineering, and the ticket is closed. The only time I heard further was on the final Recessed Door Sensor 7 ticket, when I was told on Oct. 5 that, hopefully, everything would be fixed in the next (2.2.4) release.

3 Recessed Door Sensor 7 devices, 1 Door/Window 7 device.

I’m just asking whether anything changed. If it was, then I will spend the hours regression testing and make up a new bug list and submit new tickets.

Right now, the devices are paired without security just to get things working as they are. I don’t care about security on the 3 Recessed Door sensors I have now because they just turn lights on/off in closets. It might be nice to have the Door/Window sensor paired securely because it senses opening/closing of the garage door. I’d like to put Recessed Door sensors on the front & back door for security, but those should be paired securely.

With only installation of 2.2.4 and no exclusion/reset/inclusion of any devices, I notice that one of the Recessed Door Sensors no longer reports that it has a tamper switch reporting clear. The other two never reported a tamper switch. As you know, the Recessed Door Sensor does not have a tamper switch.

Two of the Recessed Door Sensors still report a serial number of all zeros as long as your arm; the third does not report a serial number.

All of the Recessed Door Sensors work, more or less, yet one of them, before the update, would go into a mode where it reported “Not Responding” and would lag response by several seconds; after the door was opened, it would resume responsiveness and report OK. Another one would report “Not Responding” and then “Failed”, yet always worked. The third has never reported “Not Responding” or “Failed”.

I’m not one to obsess over “Not Responding” or “Failed” messages as long as the devices work, and I don’t look at the Z-Wave Details page unless something is not working. I’m not one to obsess over Z-Wave repairs; since there is only the one non-Plus Z-Wave device, I just let the mesh self-route as it wants.

The 2.2.4 update hasn’t been installed long enough to know whether this behavior has been fixed.

Ever since the Door/Window sensor has been paired without security, it has worked reliably.

Screen shots attached for the Recessed Door Sensors. There seems to be no correlation between the ones that show the long zero serial numbers and the other issues (reporting failure or non-response, prior reporting of a non-existent tamper switch).

I really don’t believe this is a mesh issue. Hub is centrally located, and there are Ring Extender 2 devices about every 30 feet from the hub. Only one non-Plus Z-Wave device (Somfy ZRTSI), Lights are Hue (on hub Pro) and Lutron Caseta. It’s really a very vanilla install, and the house is fairly small, about 2000 square ft on two floors. Only about a dozen Z-Wave devices, and 4 of those are the Ring Extenders.

Coat closet sensor has never had an issue. Bedroom closet is the one that occasionally lags, Library closet is the other one that occasionally doesn’t respond. All work mostly.

[leeonestop]

I have an Aeotec Door/Windows 7 Recessed sensor and mine only show battery, but no open or closed? I'm running 2.2.4 update.

[bcopeland]

Update coming in the next build.. I suspect a config value that in it's default state should have worked was actually changed at some point. When the hotfix comes out triggering a wake-up should resolve this.

[672southmain]

Thanks, Bryan. Is a wake-up trigger all that is needed for each device? Do we need to Configure or Save Device or save Params or switch to another driver & back or exclude/reset/include?

[bcopeland]

Correct.. wakeup trigger should do it..

[672southmain]

Great. Simply FYI, the 2.2.4.139 update has been running now on my C-7 since moments after it was released (almost a full day now), and there has not been a single instance of “Not Responding” or “Failed” for any of these devices. That’s a dramatic change. They always worked, more or less, and I could get the status to go back to OK simply by opening and closing the appropriate door, but the “Not Responding” or “Failed” would always return in an hour or two. So, on that point, congratulations and thanks.

On a related point, the subject of my initial post, see the screenshot below. It may be of interest that the Bedroom Closet Door Sensor, the one that now lags several seconds turning on after a long time inactive (a few hours), but which becomes instantaneous after that initial open/close, is the only device that doesn’t report a RTT value. Perhaps that means something. Firmware values in screenshots above, etc.

[bcopeland]

@672southmain

doesn’t report a RTT value

it will eventually.. This is measured from packets sent from the hub from the driver. So sleepy notification based sensors won’t have this populated until a wakeup event.

[672southmain]

Ok, but this recessed door sensor 7 is the most used of all. The others report an RTT but have only been opened/closed once or twice. Again, this may be related to the fact that this, and only this, recessed door sensor 7 has the initial several second response lag after not being opened/closed for a couple of hours, and then will be fine.

[bcopeland]

@672southmain

is the most used of all

Right.. but the only time anything is sent to the device is during a wakeup event.. RTT is measured on packets sent to the device from the driver. So until a packet is sent from the driver to the device there is nothing to show here. You can't measure round trip time on incoming packets.

[leeonestop]

I have excluded and included a couple of times and I cannot get it to work correctly (Aeotec Door Recessed Sensor) Here is the log that I snip. It now shows the battery and closed but when I try to open and closed nothing happens? Is there anything else that I need to do? This is a C-7 hub and latest firmware.

[672southmain]

@bcopeland, I tried the wake-up trigger on one of the Recessed Door Sensor 7 devices (Coat Closet Door sensor, see screenshot in my post above) after updating my C-7 to 2.2.4.141.

Link to post above with screenshots

Firmware 2.2.4 and Aeotec Door/Window Series 7 issues

Also hit Configure and Save Preferences just for good measure. Serial number still a long string of zeroes, as before.

New error appeared in the live log when this was done:

Device still seems functional.

[bcopeland]

I have one coming in.. This is the only model I didn’t have.

[672southmain]

Thanks, Bryan. It will make your life complete.

[bcopeland]

Well I don’t know about it completing me

[bcopeland]

But at least I will be able to see first hand what issues there may be.

[672southmain]

Bryan, simply to further complete your life, below is another, different, error message from the same Recessed Door Sensor 7, about which I posted above, that I did the wake-up trigger you indicated would be necessary. It’s the same C-7 running 2.2.4.141 as before. No additional wake-up trigger or Configure or Save Device or Save Parameters was done subsequent to the report yesterday that showed yesterday’s error message. Operation is still fine for this device.

As an additional piece of information, the error occurred the first time the door was opened after sitting closed overnight. Subsequent open/close today do not produce an error.

Enjoy!

[leeonestop]

I still having issues with this driver? Is there a driver that works with the recessed sensor?