Trials and Tribulations with Z-Wave

Configuration Z-Wave
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

24

Interesting, so when you say the front door is still the problem even after you move them, do you mean the lock that IS in the front door or the lock that WAS in the front door, as in the problem is always with any lock in that physical location. If that’s the case sounds like a zwave communication issue?

As far as those two “issues”, I’ll say that I think that those are niche cases. Depends a lot on your zwave mesh. I paired by back door lock multiple times (issues when I was learning), 40 feet from the hub.

I also lock and unlock my doors all the time manually.

I forgot to mention my controller is the HUSBZB-1

How many powered switches, just the two? I really think this might be your issue if you only have two powered (not battery) zwave devices.

1 Like
25

Sorry, I mean two different locks have problems at the front door location. One of those locks seems to be fine at the garage door, however it rarely gets manually locked / unlocked there, its on an automation to lock at night, and unlock when we drive in the garage.

The physical location of the front door is super close to the hub, as well as in a couple of feet from 2 z-wave switches which work flawlessly. I have another 4 powered switches, but they are all a little further away.

I’m also on a HUSBZB-1 hub :slight_smile:

26

I will say it seems to me to be a zwave issue more than a lock issue based on your information. Either of the two locks work “ok” when they are somewhere other than the front door. I’ll say that my most used door gets unlocked with HA several times a day, and manually locked and unlocked probably another 5-6 times a day on average, but on busy days might be upwards of 20 times. Never any issues. I even have a sensor that reports lock/unlock/manual, etc and it’s nearly instant.

How many sensors did your lock produce when added? Should be 7 I think. I only use 3 for automations, so i cannot remember for sure.

1 Like
27

It might have been coincidence, but the “dead lock” issue seemed to start if the lock was jammed, i.e. the door wasn’t closed all the way and the lock attempted to close. It’d stop responding and drain the battery until I pulled the battery and plugged it back in*. Still haven’t had any issues since I switched management back to Smart Things with the MQTT bridge.

*It wasn’t the lock constantly trying to close. It’d let out a beep and stop trying.

1 Like
28

I have the usual 7 sensors, plus the lock itself in HA for both locks.

Yeah the whole things is kinda weird,and its so random as well with the door sometimes going weeks without an issue.

Which version of openzwave are you using? Just the stock release?

29

Stock release, but I forked to add cover support. But thats now in the current HA fork, so I might be good to go once I upgrade to 82.1 or above

30

Ah, so the same as me :slight_smile:

31

Hi there,
Im trying to set up my first ever zwave device that is somfy roller blinds + fgrm-222 + Aeotec by Aeon Labs Z-Stick - all on Hassbian.
.I just saw this post and thought perhaps had similar problems or hopefully know the solution?

I wired everything and the blinds go up and down.
However, it doesnt go down all the way it stops somewhere 80% of the window (although position says 100%). ANd it wont go further whatever i do.

I wonder how can i move this to correct position so it covers all the window?
So far i tried setting different parameters including parameter 29 with no luck.

Another thing to mention is that i dont have a switch and use hassbian->Configuration->zwave to set all this up. I wonder if i missing anything?

Really appreciate any help with this!

Cheers,
Alex