Is there any plans for supporting functionality for updating Z-Wave device firmware?
OZW does not support OTA firmware updates, so it isn’t possible for HA to support it.
So does that mean we’d need another product, like Z-Flash, to update our nodes?
And I guess you can’t tell until a release is finalized for OpenZWave, but we all really hope that editing and deleting existing nodes in the network is easier to do! 
Thanks,
Ambi
So does that mean we’d need another product, like Z-Flash, to update our nodes?
Yes. The Silicon Labs Z-Wave PC Controller software (need login to download) also has the capability to do OTA updates, but I’ve never had the need to use it. The Z-Flash includes several different firmwares which could be hard to obtain individually. Manufacturers, besides Aeotec, seem reluctant to release them publicly. They may also be encrypted. There is an open issue in OZW to implement it, but no takers yet.
And I guess you can’t tell until a release is finalized for OpenZWave, but we all really hope that editing and deleting existing nodes in the network is easier to do!
I would suppose that doesn’t have much to do with OZW though? There have been recent changes that improve things: a) the Devices page can rename a node and then all its entities automatically and b) removing a node removes all its entities. The existing problem I know of is that the “Device” entry is not removed, but that should be fixed soon. Is there anything else specifically in regards to editing/removing nodes you think is still missing or could use improvement?
1 Like
Hi,
The only other thing I could think of is that when I use some Z-Wave devices, such as the Aeotec Multisensor 6’s, the status doesn’t seem right. If I start these up as battery units (for convenience) then run them on USB power, they still think they’re battery…they sleep all the time. Despite sleeping, they seem to return the temp, lux, motion, etc. updates as expected.
Other ones, which are in the basement, report “dead”, but again, they report. Looking at the status page shows they are indeed awake or have reported lately, etc. Perhaps it’s a device-specific thing?
Perhaps one way to help debug Z-Wave may be to graphically depict the node-to-node relationship? As in computer network management systems, take the current topology, and connect each node with a line, in some pleasing to look at graphic. Then when the network changes, maybe a node drops out, or a different path to the controller is preferred due to signal changes, redo the map.
The changed map could be drawn in green while the previous (or historically selected via a slider?) map is in red or yellow?
Nodes that come or go could do graphic or even just like the current “Logbook” in HA and say “Den Dimmer (node 12) neighbors changed to 10, 15” so a bit like a troubleshooting page, but less like a raw log and more like a notification. Also, certain changes could be selected for standard popup notifications like (x mins with no report, no heard from again, etc.) by clicking on an option tab for each node.
Oh, one other troubleshooting tool that I always liked with UPB, was the ability for the controller to listen to the channel and report “there’s some noise on the line”, and retry commands if noise was detected. So, maybe a way for the controller…or another dongle that just listens, to report on the “on the air” status of the network may be good.
Anyway, just a few ideas, but basically, I’m very, very pleased with how HA’s working with Z-Wave. And there’s nothing particularly different I need with a new OZW implementation…just as long as it keeps working!
Thanks to you and all the team on making this a great product!
Cheers,
Ambi
1 Like
You mean similar to this:
it’s not perfect and it doesn’t do everything you mentioned but it does kind of mostly work. 
1 Like
Bringing this back to life. The Z-Wave graph linked by @finity is a big step forward from what we have included now (nothing), but it doesn’t show the actual message path. Something that would eliminate a ton of ZWave problems/questions is showing the message path so we can figure out where the ball is being dropped.
Example: message began at controller, passes message to node 8 successfully on hop 2 , message dropped at node 16 before reaching destination (node 27.) I realize I don’t know the whole story about how ZWave is handling messages but anyone can appreciate being told the route it’s trying to take without guessing.
As far as ZWave development, can anyone explain this link and our future: https://github.com/cgarwood/python-openzwave-mqtt
1 Like
Any update on this? I’m running into bugs in 1.4 that’s making it problematic. Most of my devices are z-wave for internal control.
What issues are you running into? I am still running ha 0.90.2 with a openzwave dev 1.5 build. Haven’t updated as I don’t want to roll back to ha ozw 1.4.
My issue is just missing zwave profiles for some of my newer devices.
Are you running ha via Docker? I run an images based off the public released image, then patch/tweak it.
FROM homeassistant/home-assistant:0.90.2
COPY ha.patch ./ha.patch
RUN patch -p0 < ha.patch
You could do the same for copying new device xml files and then patching manufacturer_specific.xml to include them. As long as the devices only need the new config to work right you are good. If it needs newer code, that is a bigger issue.
I’ve reported tons of bugs regarding the Qubino Shutter in venetian mode. Currently they are working on firmware updates which should hopefully solve the problems, I’ll let you know if they will end up working properly in HA.
1 Like
I’ve been speaking to them a lot, and they have offered to update the firmware on my modules, which will supposedly fix many of the problem. However, the only way to upgrade the firmware is to send them the modules, have them upgrade, and get them back. That’s a very tedious process, with a few weeks in between where the modules are not installed. Too much of a hassle for me.
However, I was able to resolve some of the problems by changing the associations.
You have to call the zwave.change_association service twice, with these parameters:
1st call:
association: "remove"
node_id: <YOUR NODE ID>
group: 1
target_node_id: 1
2nd call:
association: "add"
node_id: <YOUR NODE ID>
group: 1
target_node_id: 1
instance: 1
I don’t suggest you to send them right now anyway, because they still didn’t manage to fix all the issues: everything works but the tilt value doesn’t get updated if you change it using the physical buttons.
Any news about implement new version openzwave 1.6 ?
And how i can verify what is now version on Hassos with Hassio ?
If you follow the instructions in my previous post the tilt value will be updated when using the physical buttons. It took me a long time to figure it out.
Your suggestion worked, thanks. Unfortunately the firmware is still bugged and reports a bogus tilt value when par 73 (Slats position) is set to 0 (UI Control).
Any news when openzwave 1.6 will be implement in HA ?
2 Likes
When it’s ready.
2 Likes
It looks like it will be replaced with a newer MQTT based system that will be able to tracker closer to OpenZWave.