TLDR - success! 3 Recessed Door Sensor 7 devices with updated firmware 1.05 that all work. Details below, perhaps this will help others.
After many unsuccessful attempts, and with the hints from Chris at Aeotec (@ccheng) and the “sleepy device” hints from Bryan Copeland (@bcopeland) and the clue I got from this post from @scottgu3 regarding a feature/bug with the Device Firmware Updater’s File Manager, I can now reliably and repeatably update an Aeotec Recessed Door Sensor 7 on my C-7 running 2.2.4.148. I have not done regression testing on my C-5 or C-7 using the Binary Firmware Updater driver using variations of this method, but this might point you in the right direction.
As some of you know from this thread, I’ve been around the block a few times with my Recessed Door Sensor 7 devices. Read that thread if you want the history and prior attempts at making them work (support certainly didn’t want to read that history).
I had one Recessed Door Sensor 7 that didn’t report a Serial Number, Firmware Revision, Hardware Version, or Protocol Version, and that lagged turning on the light by five or ten seconds first thing in the morning, and then lagged a few seconds after that during the day:
The firmware has been updated, everything is reporting correctly, and no lags. For the others, they now have updated firmware and work fine as well.
Here is how I got there on my C-7 with 2.2.4.148. Some of these steps may be unnecessary red herrings, but this is a process that worked for me.
The Device Firmware Updater is great, but has a few rough edges, as can be seen from my earlier post upthread. So, I deleted the Device Firmware Updater and added it back, then cleanly shut down my C-7 to red light, pulled the plug, and rebooted. This was to put the Z-Wave Radio in a known good state after all of the Firmware Updater errors.
I then excluded the Recessed Door Sensor 7 (after substituting a virtual device so automations didn’t break, a trick I learned from Ashok Aiyar (@aaiyar)), reset the RDS7 to factory defaults so that I was working from a known state, then re-included it, choosing the Aeotec Door/Window Sensor 7 Series driver. As Bryan Copeland (@bcopeland) instructed, I disabled that device (faint X in upper right corner of devices page, then X in first column for that device).
Because of the errors I was getting with Device Firmware Updater app, I decided to delete all firmware files in the Device Firmware Updater’s File Manager except the file for the RDS7. This is tricky because the DFU’s File Manager has (previously unknown to me) inaccessible options off the right of the screen (at least on my 512 GB iPad Pro 10.5 inch using Safari on iPadOS 14.2). After seeing this post from @scottgu3 regarding the DFU’s File Manager interface, I moved to my iMac, which has a wider screen than my iPad (even in landscape mode), and saw previously-hidden trash can icons at the right of the screen, allowing me to delete previously updated firmware files, and also showing a previously-hidden confirmation answer to the “are you sure” question when deleting.
I moved the RDS7 near the Hubitat hub (8 inches away).
Then, using the trick from Chris at Aeotec (@ccheng) and suggestion from Bryan Copeland (@bcopeland), I depressed the wake up button on the RDS7 using a paper clip until the light turned red, then immediately released the button, noting that the light stayed on, indicating that the RDS7 was awake.
I then proceeded through the Device Firmware Updater’s procedure to Update Z-Wave Firmware, making appropriate choices of device and firmware file. The RDS7’s LED stayed on solid for the 5 or 10 minutes it took for the file to be uploaded to the RDS7, then DFU indicated it had sent the last packet, etc., so I waited awhile and then hit done back to apps. The RDS7 LED stayed on, and the only way I could get it to go out and make the device responsive was to remove and replace the battery.
Re-enabled the device, re-installed the RDS7, and everything worked, snappy response, new firmware version (1.05) indicated in the driver.
I have no reason to believe that a similar procedure wouldn’t work with the Binary Firmware Updater procedure outlined by Chris at Aeotec (@ccheng).
Hope this helps the next person, and thanks to Bryan Copeland for writing the Device Firmware Updater, finding the Aeotec firmware bug, and pushing to get the bug fixed.
