Trials and Tribulations with Z-Wave

Configuration Z-Wave
4

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).

5

@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.

6

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 :wink:

7

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.

8

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.

9

Done.

10

Changing the entity_id is NOT the same as changing the node name.

11

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.

12

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
13

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.

14

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
15

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
16

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
17

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.

18

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.

19

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
20

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
21

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.

22

What controller are you using again? Can’t remember. My two BE469’s are almost flawless.

Here’s some details that may help us to figure out what’s going on with your setup.

40+ ZWAVE devices, switches, locks, motion sensors, etc.
2 BE469 Deadbolts, and 1 FE599 lock
One BE469 and the FE599 are about 15 feet from zwave controller, and the other is about 40 feet from controller, but there are several wired zwave devices between to act as repeaters.

I will say that my current batteries are at least 3 months old, and are reporting 60-90%, and are still working.

I have a sensor set up to let me know if/when doors dont lock when I expect them to, and I honestly cannot remember the last time that happened.

I lock/unlock my doors with zwave several times a day.
the FE599 locks at night, and unlocks in the morning, it also locks when I leave and unlocks when I get home.

One of the BE469s unlock when I get home and cross a line crossing sensor, the other does not auto unlock, but does auto lock after 5 minutes if the door is closed. This also works 100%

Lastly (have not tested in a while), but if any door is left physically open and the deadbolt locks via automation, it automatically unlocks to keep the door/deadbolt from being damaged.

I’m running 81.6 right now in a python VENV on an older i3 computer, a slightly customized open zwave (added barrier class).

I’ve seen your issues over the past few months and have wondered if there is something else going on?

1 Like
23

Thanks @ptdalen,

I have the two locks, one works pretty flawlessly, the front door lock (closer to the hub) is the problem. I have about 10 devices, including 2 powered switches, one right next to the problematic lock.

I even switched the locks around between the two doors, and the front door locks still was the one that had the problem.

So I was doing some reading today on people using a Smartthings hub seeing the same issues and read a couple of things:

  1. Make sure you pair the lock with 3 feet of the hub, otherwise the lock may stop working randomly in the future - I didn’t move it closer and it registered fine, might try moving it closer and repairing.
    https://community.smartthings.com/t/schlage-camelot-lock-not-responding/24344/24. https://community.smartthings.com/t/schlage-camelot-lock-not-responding/24344/9

  2. If you manually lock and unlock the schlage, then it could stop responding randomly - the front door gets lock and unlocked manually all the time, the other one is on an automation.
    https://community.smartthings.com/t/schlage-camelot-lock-not-responding/24344/13