Why do you want to change the node names?
You are aware you can change the entity_id (rather than the node name) without all that messing about?
I use Node Red for all of my automations. It references the devices by the zwave name, e.g. “zwave.nodeid_21_alarm_type_alpha”. They’re extremely difficult to track in automations that way. I kept having to manually edit the entity registry to change the device name to something easier to remember.
1 Like
Ah right, that explains it.
Your troubles and solution sound very similar to other posts I’ve been reading about moving devices back to Vera controllers. You are definitely not alone.
I’ve just started with zwave (5 devices including the USB stick controller) and so far everything has been easy enough to track with the entity_id in HA, even configuring a node’s parameters in the config console. And I’ve had no stability problems.
Reading this sort of thing makes me dread adding more devices (I’ve got plans for up to 40 more).
@TaperCrimp I feel your pain. Pretty sure that I’m going to die of old age before I get my Sensative Strip door sensors working as I’d like them to. None of the several suggested methods in the forums or on blog posts work for me. It’s been a very painful introduction to Z-wave.
OpenZWave is what is currently used, and yes it has many challenges. At the time Home Assistant introduced Z-Wave support it was the only option other than starting from scratch. Now things have changed and I believe the developers are intending to look at some of those other options.
As of at least 0.75 you’ve been able to change the entity ID of any Z-Wave related entity through the UI. Before that you could use the Z-Wave control panel 
I understand the need to consolidate, but I felt the old way of renaming within the z-wave configuration page was a bit better although not ideal. My old process looked like this: add the device, rename it in z-wave, delete all of new devices from the entity registry, and restart HA. It’d recreate all of the nodes for the device with the preferred device name, versus having to go in and manually edit each one.
Either way it’s really not ideal or user-friendly. In a perfect world it’d ask what you’d like for the z-wave name and then create all of the devices based on that. However, that was secondary to the Schlage lock issue which drove me back to SmartThings. I spent way too many hours trying to get that to work.
The developers are moving slowly in that kind of direction. Whether they’re thinking exactly that I don’t know - maybe worth raising a feature request.
Changing the entity_id is NOT the same as changing the node name.
To be clear, I was changing these lines in core.entity_registry:
"entity_id": "zwave.human_readable_name",
"name": "Name In The UI",
After restarting HA, the names associated with the z-wave unique_id would appear as expected in the UI, both for the entity and z-wave configuration.
If I have a choice between hunting in the UI to rename or doing a :s%/old_base_name/new_base_name/g in vi, then I’m going with the latter which is faster.
I’ve had similiar experience, I also have had issues off an on with my Schlage, learned a lot more than I ever thought I would, etc. I also came from smartthings. I’ve considered the MQTT bridge once or twice, but really, really wanted to be on just one system. I am using the " Linear HUSBZB-1" stick. It seems like most of my issues come around the time I’m adding, upgrading, stopping, starting, etc. Once its up and running and I leave it alone, stuff seems to be good. I’m not sure if this is good or bad, but I’ve had everything working well for up to two weeks a few times. Again, I always feel like the times of instability come around the times I’m adding a new sensor, etc.
But, here is my question about the MQTT broker and smartthings, does that still allow full independnce from the cloud? Can I still control locks, lights, switches, motion, etc if the Smartthings servers go down, or internet access? If I was able to just use Smartthings solely as a zwave/zigbee controller I might consider it.
1 Like
The mqtt-bridge is cloud-dependent even if the devices are listed as “local” in ST. Luckily my Comcast connection is pretty stable. I can post it if anyone is interested, but I’ve got a slightly-modified version of the mqtt-bridge app in ST that sends updates on a regular interval or “save” in the ST app. Unless I missed something, the default mqtt-bridge version just sends an event when the status changes. After added a device in ST, I just add it to mqtt-bridge, click save, and I can see the MQTT topic in the mqtt-bridge logs. Keep in mind that it doesn’t have “true” integration like esphomeyaml and you need to create a mqtt entry in sensor, binary_sensor, lock, etc.
That being said, I f’ing love MQTT for what it does. In a perfect perfect world there’d be a HA z-wave to MQTT component that could run independently from HA core, complete with formatting the MQTT topics so they auto-appear like esphomeyaml.
This is why I went Vera instead of Smartthings, kept it all local.
And yes, a lock was what drove me away from the built in zwave functionality too. In my case an August instead of a Schlage, but I was tired of finding that it hadn’t actually locked the door behind me when I left, even though I knew the automation had triggered properly (automation locks back door first, then opens garage door, the garage door opened every single time (wired relay, not zwave), but I’d often come home to find the back door had been left unlocked)
I found that once I got them going, my lights on the built in zwave worked ok, but the lock was always super flakey. Maybe it’s the “secure” devices that HA has more trouble with?
Either way, zwave devices are much faster, and much more stable connecting to HA through Vera than they ever were with the usb stick, and the inclusion and naming process is much less painful too.
1 Like
Thought about going that route but unfortunately it doesn’t support the First Alert Smoke/CO sensors. I didn’t want to buy new ones because of that. I’ve currently got an automation where if any of the smoke detectors trigger, it (1) turns on all of the lights in the house, (2) unlocks the front door and opens the garage, (3) sends a Pushover alert to everyone’s phone that needs to be acknowledged, and (4) enables the whole-house siren that you’ll definitely hear.
It isn’t a knock against HA, but I’ve had zero problems getting all of my z-wave devices working since I switched back. No more random dead nodes and I don’t need to sacrifice a small chicken every time I restart HA along with the z-wave stack.
Regarding the Schlage lock, the z-wave stick was approximately 8 feet from the door during setup and deployment. It’d consistently work for 1-2 days, spit out an error about an invalid status, and then drain the hell out of the batteries until I pulled/plugged the Schlage batteries back in.
1 Like
That’s weird, my Vera is working with the first alert smoke/CO detectors. Seems to work fine (though my house hasn’t burned down to test…)
1 Like
I haven’t tried Z-Wave with HA yet (it’s on my list), but a lot of the above is the similar to the experiences I have using it with the ISY-994i. I still have issues with devices that randomly stop responding and “heal network” magically fixes. I have a couple of Aeotec plug devices that work when they feel like it, even while responding to parameter changes and doing just find as repeaters to other devices.
Wait, I think I was confusing that with Wink. I’m now drawing a blank on which devices it didn’t support, but there was a major one on my list that was listed as not working or problematic. It’s what I’ll probably move to if ST decides to kick the bucket or their DB takes a dump again.
I’ve got over 200 Wave devices off a Aeon Wave stick and in the early days it was rough once I came up with a process it worked fine. That process has been adapted as HA has evolved away from needing OZWCP to the built in panel and now the new entity naming.
The number one thing you need to be aware of is the Zwave is a SLOW network. It runs at 40Kbps best case; which is 1/125th the speed of even basic 54Mbps wifi. It is very easy to overload the Zwave network by setting up polling. It also means that during discovery you will be bandwidth constrained and the network feel sluggish.
The #1 most critical task is to carefully pick your devices. I would not be able to have 200 devices if the majority did not support instant status report (ISR) and required polling. I have 28 legacy devices on my network that need polling; and that is set to a 30 second poll rate. Changing this to even a 20 second poll rate brings a nicely responsive Zwave network to a flaming pile of shit status (Eg: Wife gets angry).
So don’t be the guy who first thing configures the polling interval to 5 seconds and enabled on all devices. You will not be happy with the results.
Now is a good time to setup backups. I actually backup my running directories every 6 hours; as well as whenever HA is started. I keep past backups from the 1st of each month; every Sunday; and every day for the past 2 weeks. This allows me to salvage the zwcfg.xml if things go badly.
Next task is to learn how the OZW stack works and properly setup the logging and tuning options. You do not want all logging on (which is the default) as on a slow system (particularly with SD cards) it will also cause lots of issues. I run with almost no logging and just enable it if problems.
Lastly is to document you add/remove and renaming process and follow it. Don;t remove and use the clicker. Don’t use OZWCP any longer. Use the entity editor and keep default names. That way you eliminate all the stops, starts, etc. Let the system assign the unique name; then assign a human readable logical name.
It is manageable and I now spend very little time looking after my Zwave. It just works.
4 Likes
I have a rather small network with only 5 devices, but I share the same experience.
HA is just not robust when it comes to restarts. I have the same issue with reportedly dead zwave nodes that magically become available after manual (!) heal/test calls. The introduction of the entity registry was a not well thought through move as it required even more restarts for zwave users…
From the latest blog post it seems that the devs will switch to a different zwave software stack. So at least Zwave will eventually get some love again after it has been neglected in favor of Alexa, Bitcoin components, Cloudstuff etc.
I’ve tried to get feedback on how to externalize Zwave into a dedicated HA instance (Best way to create dedicated zwave instance) but from the missing feedback I gather there is no real pleasant way aside from bridging the 2 instances via MQTT. This means double config efforts, but at least one instance can be left alone while the other can restart without tearing down the network.
This dedicated instance approach works fine with my Zigbee components (via Deconz) and 433 mhz stuff ( via Pilight) so I’m positive it will improve the zwave experience as well.
2 Likes
I am so fed up with my Schlage lock (BE469) randomly stopping responding and resulting in a battery drain to 0 in a few hours that I am considering moving them back to Smartthings and operating them over the MQTT bridge.
I just wish I had a way to debug what the heck is going on here.