Decoupling Z-wave from HA

Development
1

I’m thinking about the possibility to move Z-Wave to a new service that could be run separately from HA over the network and would like some input on what difficulties such an implementation would face.

I am not talking about scrapping the current z-wave implementation, but building a separate service under a different name that is independant of homeassistant, working in a networked server-client model with HA being the client.

Some benefits that I see from this implementation:

  • Z-Wave controller can be on a different machine.
  • Possible to use more than one controller at a time from HA.
  • Device configuration and states are kept by the service, meaning that
    • It doesn’t care about HA being restarted.
    • It could be used by more than one automation service at the same time.

Currently I don’t have the time to implement something like this, but I am interested in hearing your opinions on the project, and if it’s feasible or not.

2

You could do that or you could just buy a wink or some other type of hub. The main problem you will encounter is the same one you find with HA. There are always new devices out there that have to be added and maintained. Doing it is probably a full time job.

What I would rather see, is something HA is already working on, the ability to restart specific parts of HA without restarting the whole thing. We can already restart Zwave, Groups, Automations (and whatever “core” does). We just need the rest of it now. :slight_smile:

3

I keep having the same idea of decoupling the 2. I run home assistant on my Qnap and I extra had to move it to be able to reach all devices. I would prefer to run the Z-Wave controller where I can best reach my devices using 1 or multiple Raspis. Besides that I don’t like the idea that the Home Assistant has to initialize the network on each startup.
I did have a Vera for testing and that was very nicely integrated. Unfortunately the Vera needs an internet connection. Besides that it does not have any authentication on the local rest interface.

I am somehow still putting some hope on homegear. They are actively working on a Z-Wave add-on for some time now.

I was also thinking of either creating a server based on the Z-Wave implementation in Home Assistant, but that is too complicated.

Another thing that I thought of is integrating z-way-server the same way as Vera. That should not be too complicated.

I do have a self made Z-Wave controller based on Node Red, that talked Mqtt, but that requires to configure every single device manually in the config and sometimes these configmap can be tricky if multiple topics have to be combined to a single entity.

4

I understand your pain about the zwave network restarting. I have over 50 devices on it, and it takes quite a while. I’ve found that the only times I’m frequently restarting HA is when I do an upgrade. That’s usually about an hour or so of time to get everything to reload well. I do them one week after the release so that any major bugs have been found and fixed. Other than that, the only times I restart HA is when I’m adding something to the zwave network, and rename the sensor as part of that process.

How often are you restarting HA?

I solved the problem about location by buying a couple of the GE smart outlets and installing them as basically range extenders.

5

With the move to the built in PIP install to keep OpenZwave up to date, and the recent individual restart options for groups, automation etc I think that would be a step backwards.

I haven’t looked into it in depth but HA already supports having more than one HA instance linked together… I wonder if you couldn’t just link all of the Zwave to a dedicated HA instance and share state… That would decouple a lot of the functions for you in terms of restarts.

6

That’s a possible interim solution. But I think the longer term solution is going to be for HA to continue isolating things that can be restarted independently of restarting the entire application. The main thing missing for me, and it may be there, under “restart Core” is the ability to rename a zwave device and not have to restart HA for it to take effect. No one has every explained what restart Core does. I’ve never really seen it do anything the few times I’ve pressed it. LOL Restart HA entirely should be a very infrequent activity. Almost as infrequent as rebooting the raspberry pi. It would be nice to be able to simply rename a device and either have it take effect immediately, or be able to re-load zwave config without having to interrogate all the zwave devices again.

7

FWIW, This is what the HDMI component does (or rather, offers). The hardware for HDMI interrogation can be on another machine, but then a network relay is used to allow HASS control.

8

Well one possibility is to run a separate HA/OpenHab instance and communicate with it via the MQTT. This instance doesn’t have to be updated that often.

9

I already tried running a second instance of HA just for Z-Wave as well. I connected the 2 via Mqtt, but that has the downside that if you do restart your master instance then you only get the states of the Z-Wave instance in the next update. Besides that it did not seem very stable to me. I have not checked this in detail though.

10

I was actually thinking of this:

But it looks like it was removed as a feature.

11

I use a Z-Way appliance Raspberry Pi using Razberry / Z-Way which talks to my main system through MQTT. Not sure what other hubs might support MQTT publishing though.

12

That looks interesting, any noticable lag when using it?

13

I’m actually using razberry with just the HTTP calls HA right now and was looking at setting up MQTT. What did you have to setup to get that to work, and is there any lag when using it?

14

Z-Way publishes through the MQTT module instantly as long as the Z-Wave devices publish their status correctly. That’s more a general Z-Wave issue though (and screw you HomeSeer for not using standard status reporting mechanisms in your switches BTW, and then having the gaul to release a firmware version that might fix that but requiring customers to BUY a firmware update tool to get it… I’m a little salty). Z-Way is fairly stable itself, though the node.js based part could use a few more QA eyes before they publish updates sometimes :slight_smile:

The MQTT module is ok. It’s a little weird because the module system in Z-Way is not well thought out, so it uses a cobbled together single-file MQTT client instead of one of the good node,js libraries that are available. It works, but had a lot of node.js closure issues that caused reconnect issues for a long time. Most of those should be fixed now… the author is very accommodating of pull requests. I suspect there is still one bug in the reconnect logic that triggers sometimes when the MQTT server goes away for a while, but it’s not a big enough deal that I’ve put time into hunting it down, and I don’t see a lot of others complaining about it since the 3.0 release of the module.

Frankly, any good controller with a good MQTT implementation can be an appliance like this. Z-Way was just the cheapest, OSS, supported ZWave Plus, and it has served me well.

15

trying to figure out the setup for MQTT light in HA to Z-way. Can you share your config file?:slight_smile: Strugglng with the on(last value)/off function.

light:
  • platform: mqtt
    name: “zwaytest”
    state_topic: “zway/kjokken/Dimmertest/status”
    command_topic: “zway/kjokken/Dimmertest/set”
    brightness_state_topic: ‘zway/kjokken/Dimmertest/status’
    brightness_command_topic: ‘zway/kjokken/Dimmertest/set’
    brightness_scale: 100
    qos: 0
    payload_on: “on”
    payload_off: “off”
    optimistic: false
16

Oh I don’t actually use HomeAssistant. But I think your “state topic” might be wrong? If I understand it right, and that’s what it’s supposed to subscribe to on the HASS side, I’d assume its should be “zway/kjokken/Dimmertest”. The “/status” topic, at least by default on mine, is used to REQUEST the current status to be republished on the status topic.

17

I think it might be good idea and I’d recommend looking at using MQTT to do it. After lots of problems with my Insteon devices, I wrote an MQTT<->Insteon bridge process which allows HASS to use MQTT to run everything and for me, it works extremely well. Having a separate process specific to that service allows you to add features specific to zwave that HASS might not need to know/care about but which are still useful (this has been very useful in the Insteon case).

The biggest problem with doing this is that it’s not really a HASS component then. It’s more complicated to configure and start up (separate daemon process). For some/many of the HASS users, that’s going to be an issue. So if you want wide spread acceptance, you’ll need to address ease of use.

18

OK, thanks I answering. I have made it a little further. Here is my setup now:

light:

  • platform: mqtt
    name: “zwaytestmedbryter”
    state_topic: “Azway/kjokken/kj_taklys_Dimmer”
    command_topic: “Azway/kjokken/kj_taklys_Dimmer/set”
    brightness_state_topic: “Azway/kjokken/kj_taklys_Dimmer”
    brightness_command_topic: “Azway/kjokken/kj_taklys_Dimmer/set”
    brightness_scale: 100
    state_value_template: “{{ value.state }}”
    brightness_value_template: “{{ value }}”
    qos: 0
    payload_on: “on”
    payload_off: “off”
    optimistic: false
    on_command_type: ‘brightness’

Don’t think I need the state and brightness value template? I have yet two problems. First is when I hit the “on” button in the frontend the light send out “100” instead of “on” and the other is that I have no feedback if I change the light from z-way or from the physical switch.

19

Hi steinis,

I’m also switching to zway with mqtt, I came up with almost the same thing:

light:
  - platform: mqtt
    name: Kitchen Lamps
    command_topic: "zwave/kitchen_dimmer_level/set"
    brightness_state_topic: "zwave/kitchen_dimmer_level" # required to display as flash
    brightness_command_topic: "zwave/kitchen_dimmer_level/set" # required to display brightness slider
    brightness_scale: 99
    payload_off: "0"
    on_command_type: "brightness"

Maybe you should dump the payload_on?
If you don’t need to extract values then you don’t need the value_tempates.

20

Thanks. I have tried your setup but I have still no feedback and the on button sends out 99 instead of “on”. Starting to think this MQTT light object isn’t for me.