[SNEAK PEEK] Z-Wave firmware updating inside HE

🚧 Developers
51

Mike has a lot more on his plate than just drivers..

5 Likes
52

I am only kidding. I know all of the HE team have more to do than they have time for. That they have any time to participate here is amazing.

8 Likes
53

Major progress today..

  • Major reorganization / code cleanup
  • parsing of hex and otz file formats
  • Support for firmware update MD CC v1-4
  • Firmware activation on CC v4+
  • Support for all status report messages

Tested on aeotec multisensor 6 - firmware update md cc v2
Tested on inovelli red dimmer - firmware update md cc v4

10 Likes
54

Also tested on .hex format file and .otz (compressed)

and added support for FastLZ level 2 compression just had level 1 before..

4 Likes
55

Wow man! I can't believe you're working on this! Thanks a ton!

I'm real new here, just got my HE last week, but I am loving it. I've been known to write some code, but haven't done so with my home automation stuff (aside from basic manipulations to ST drivers).

Will PM you with my GitHub name....

1 Like
56

I have the following Aeotec firmwares extracted for the beta..

US, EU, and AU regions
ZW100 - MultiSensor 6 - V1.13
ZW116 - Nanosmartswitch - V2.01
ZW132 - DualNanoSwitch - V2.02
ZW139 - NanoSwitch - V2.00
ZW141 - NanoShutter - V3.01

6 Likes
57

Can't wait to see the code! :nerd_face:
For the past months I have been doing this with my secondary controller, now having a direct way is even nice!

2 Likes
58

Todo list for today:

  • Locking mechanism - To prevent accidental or impatient double click
  • Memory cleanup of data that is no longer used
  • Reduction of debug logging - and adding of enable debug logging preference
  • Add reminder for wakeup of sleepy devices on no response after x time
  • Test of parser on hex files that need 0xFF byte padding (boot loader area)
  • Work on update MD CC v5+ packets
5 Likes
59

It is underpowered for many uses, And your specific app working does not "prove otherwise".

And that is not to take away from your work - it's pretty cool, even if it isn't something I'll personally use.

60

I would not like to get into the Middle of this, but, the Hub is able to be a 'well powered' Home Automation Hub. I think it would be underpowered for tasks like gravity mapping, heat flow analysis etc. It is IO bound, but a lot of THAT is due to the 9.6k half duplex nature of some ZWave devices. The CPU on the other hand, would be doing nothing, really fast. Which, if you can have it be doing something instead, would be done, really fast. If the CPU is 'churning' on a DB retry loop or garbage collection, or any of the other potential problem areas of Java, then that speed/performance is wasted on what looks just like "nothing, really fast".

4 Likes
61

I would love for you to explain how it is under-powered...

1 Like
62

It has been covered a dozen times, no point in rehashing it. Summary... Excessive use of RM, slowdown. Excessive use of lan or web endpoints - slowdown. Excessive use of logging/event creation - slowdown. No easy way to prevent thread concurrency without being a PhD level programmer - slowdown. During the daily maintenance window - slowdown.

Anyway, I didn't want to derail your thread. Just couldn't help myself when you said it wasn't under powered just because your single use works. :roll_eyes: Sorry.

2 Likes
63

Wow

5 Likes
64

Progress Update

Completed:

  • Locking mechanism - To prevent accidental or impatient double click
  • Memory cleanup of data that is no longer used
  • Reduction of debug logging - and adding of enable debug logging preference

New task:

  • Added an abort mechanism to stop processing the firmware update at any point

These 2 got pushed as I got on a side tangent while researching hardwareId

  • Add reminder for wakeup of sleepy devices on no response after x time
  • Test of parser on hex files that need 0xFF byte padding (boot loader area)

This one has me stumped for the moment.. V5 added hardwareId as a classifier.. But I have no sample firmwareImage and have not yet found a file structure definition that describes where to find this in the firmware image.. And cheating on this and just reporting back what the MD report had doesn’t sound completely safe.. Although it should be rejected after download..

  • Work on update MD CC v5+ packets
4 Likes
65

I wonder if you might be able to get hints for any of this from the Open Zwave folks. They will have some deep insights into the inner workings of Zwave.
http://www.openzwave.com/ or openzwave@googlegroups.com

2 Likes
66

I am scouring through the 700 series sdks and docs right now.. It’s got to be in there somewhere..

1 Like
67

I searched every document from this massive download on all the 500 and 700 series sdks ... Nowhere in any place where they describe the firmware descriptors do they mention hardwareId .. Ugh...

Probably doesn’t matter at the moment as 700 series devices are not widely available yet.. And apparently the whole structure of the image is different, as my structure parsers are making no sense out of it..

Looks like that’s going to be a v2.0 problem to solve...

I have some sample firmwares from the sdk .. I’ll play with it more later...

1 Like
68

Excuse my ignorance.
Will I be able to use this forthcoming tool to update the firmware of my Leviton switches?
I happen to have the new version of their firmware.

1 Like
69

Yes .. If the device is z-wave and supports OTA firmware updates

1 Like
70

And there is an update available for that specific device that has been released by the company.

1 Like