[SOLVED] Z-Wave OTA updates not working

🧰 Built-In Apps and Drivers
1

Hi everyone.

I'm wondering if anyone has any suggestions to help me with OTA Z-Wave updates. I have several Aeotec TriSensor devices, some work reasonably well and others freeze on motion active. What I've noticed is that using FW v2.16, these generally work well. I have some that have been upgraded to v2.21 and these are all problematic. Aeotec offered some suggestions, unfortunately nothing has resolved the problem.

Their support group sent me v2.17 firmware (for some reason v2.16 was not available), but I have been unable to update my sensors. My residence is operating with a C-5, but understanding that this doesn't support OTA updates, I put my C-7 [2.3.2.141] into service. Currently, the only device paired with the C-7 is the sensor I'm trying to update. The sensor has been both factory reset and excluded/included at least a few times and the device sits within 5-feet of the C-7. I have also tried to ensure the TriSensor remains awake.

I have uploaded the .OTZ file to the C-7 without problem. I can get to the point where is waits for the sensor to request the update, but the status bar never moves. I've waited in excess of 60 minutes with no change. The update has been attempted both with and without S2 security enabled. The battery in the sensor is a new Energizer lithium.

I've considered that the sensor may be defective, but I want to make sure I'm not doing anything wrong first.

Any thoughts? I'm pretty much at a dead end.

2

I don' think the Aeotec OTA firmware work with Hubitat. I finally followed their directions to load the SI labs software and updated some of their stuff from it. That worked quick.

If i remeber right there firmware files include some stuff that needs to be removed before they can work with Hubitat.

1 Like
3

Thanks for your response. I didn't have much luck with the SiliconLabs software, but I think it's an unrelated problem. I'll revisit this option. I did install the Z-Wave Firmware Updater (driver) created by @bcopeland and it seems to be working on downloading the firmware. I'm not sure exactly how long it should take, but it did say in the readme file it can be a while. I'll give it a little more time before I abort the process.

4

Don't forget there are two versions of the firmware updater. The built in app for the C-7 and then the one posted as an app you point to the device. I always use the one added from the Built in App section.

If it is taking a super long time it may not work. I have also had allot of issues when a devi e is paired with S2 security. If the sensor is you probably need to pair it without security to complete the firmware update.

5

Keep in mind.. Sleepy devices will have to be woken up before starting the process

3 Likes
6

For sure. I made certain to do this. With the TriSensor, the manual indicates that holding the button for 5 seconds and waiting for the yellow LED will keep it awake for 5 minutes. I also made sure to wake it periodically but the status never changed from 'Downloading Firmware'. I'll try again.

@mavrrick58 Thanks. I did try both the native app included with the release and the driver version. I'm not having much luck downloading Simplicity Studio. The page keeps timing out. I'm not sure if something is up with their site. I have no problem with any others and have added a firewall rule to permit access to their domain, just in case this was a problem since I have my security threshold set fairly high.

7

Also I have found if the driver the device is set to, sends the wakeUpNoMoreInfoCmd then the device goes back to sleep right away and its hard to get the firmware to start. I have better luck setting the device I am updating to the generic "Device" driver so I know that the driver wont interfere. Obviously this should not be an issue with the updater driver though, only the app.

I always fight with battery devices, its a struggle no matter what.

For using the updater driver, you have to give it a link to download, the fact it is getting stuck "Downloading" tells me its not a good link, what is the link you are using?

1 Like
8

I'm using a link to the file stored on a network drive. Perhaps I'll try moving it to my local machine and see if that helps.

9

I will check my computer and see if i have the installer for simplicity as well.

1 Like
10

I think it has to be an http(s) link? I usually put it on dropbox but you need to know how to get a direct download link. Someone else I helped was putting it on google drive.

11

That's a great idea -- I'll add that to my bag of tricks -- thanks!

Amen to that.

12

Ahhhh. That may explain things. I'll try moving the file to my DropBox account and see what happens. Thanks.

13

First, I really appreciate all the help everyone has offered!

A few things happened over the last several hours... I wasn't able to successfully get the Hubitat 'Driver' version of the OTA utility to work. I moved the firmware file to DropBox and did get a little further in the process. It still hung up at "Padding the hex bytes...". Honestly, these TriSensors have been quite obnoxious regardless of what method is used. There are even two different processes that might apply when using the Aeotec procedure to install v2.21 (which I don't recommend).

I did a bunch of reading about Simplicity Studio and how they manage security certificates. After some firewall modifications, I was able to successfully install the product. The Z-Wave PC Controller tool did the job, although there was some trial and error. When adding the TriSensor to the Z-Stick, it's important to select only "S0" when prompted (uncheck the two options for S2).

On the OTA firmware update screen, the Fragment Size defaults to 40 but for this device it must be changed to 20. As for the firmware file itself, I copied it to my desktop and browsed for it there.

In short, I was able to successfully roll back the software from v2.21 to v2.17. Now it's time to see if the sensor performance will improve.

14

If you do another one, uncheck all the security options. The firmware update will go much faster with no security overhead and the 40 fragment size will probably also work with no security.

Ultimately the PC Controller software always works best for me for updates as well.

For the Driver updater, you said up above the firmware was an OTZ file, which is non-binary. There are two version of the firmware updater, the "binary" version can handle both file types. I just checked the code and only the binary version has that log message you are getting stuck on (Padding hex bytes...), but it should only say that if the file is NOT an OTZ file. It looks like it is checking the first byte of the file for 0x80 to determine it. Anyway, point is possibly the file you have is not in the expected format (but still valid since it worked elsewhere) and confusing the firmware updaters in Hubitat but PC Controller is able to figure it out.

    if (byteBuffer[0]==(byte)0x80) {
        firmwareUpdateInfo['imageType']="otz"
        log.info "got otz compressed image reading compression header"
        parseOtzHeader()
        if (debugEnable) log.debug "OTZ Headers: ${otzHeader}"
        updateProgress("Decompressing firmware...")
        decompressImage(otzHeader['fastLzLevel'])
        if (abort) return
        int firmwareDescriptorOffset = ((decompressedBytes[8] & 0xff) << 8) | (decompressedBytes[9] & 0xff)
        firmwareDescriptorOffset -= 0x1800 // bootloader
        parseFirmwareDescriptor(decompressedBytes.subList(firmwareDescriptorOffset, firmwareDescriptorOffset+14))
        binding.variables.remove 'decompressedBytes'
    } else {
        // not otz
        firmwareUpdateInfo['imageType']="hex"
        updateProgress("Padding hex bytes...")
        padHexBuffer()
        if (abort) return
        int firmwareDescriptorOffset = ((byteBuffer[0x1808] & 0xff) << 8) | (byteBuffer[0x1809] & 0xff)
        parseFirmwareDescriptor(byteBuffer.subList(firmwareDescriptorOffset, firmwareDescriptorOffset+14))
    }
15

Thanks for the detailed information. It's been an adventure alright. I did try unchecking all the security boxes but then I kept getting the error "Requires authentication:0x10". Looking through the documentation, there was virtually nothing about exactly what this meant. By sheer luck and some trial and error, I re-paired the sensor trying different combinations. Finally with only S0 selected the process completed normally.

When I tried to understand the "Padding hex bytes..." I was further confused because as you mentioned, this doesn't apply to .otz files.

The sensor is installed in a moderate traffic area (at least moderate for our home). I have no other v2.17 TriSensor devices so I'm not entirely sure what to expect just yet. I did notice that the motion LED colour remains green despite having changed it to blue as I have with my other sensors. This worked correctly in v2.16 and v2.21 so I'm thinking it may be a version specific bug. Anyway, aside from that, so far so good.

16

S0 is unfortunately the worst option to choose - it's several times "noisier" on your mesh than S2.

The best choice for these types of devices (non-barrier devices, e.g., not locks, garage door openers, etc.) is usually considered to be no security - uncheck all security options. Reduces chattiness of device on your mesh and increases speed of any future FW updates.

2 Likes
17

The problem however, is that the software generated and error with no options selected and would not update the device. This was the only selection that allowed it to move forward with the update. Unless there is some other workaround, this didn't seem to be an option.

1 Like
18

That's disappointing. I just realized I must have missed your comments on trying to update w/no security in your previous messsage. Oops. :slight_smile:

If you can't do no security, then in the future S2 would be a better choice than S0, as it will be quieter on your mesh, as long as you can actually do the update w/S2 selected. :wink:

1 Like
19

Yes. I tried S2 as well but it failed. I had the option of S2 authenticated and S2 unauthenticated. Neither worked :frowning:

1 Like
20

Man, you are a patient person beyond all measure...I would have been putting the sensors into a small paper bag to drop into a lake at that point. :wink: