Forwarding ZWave output to a separate HA instance

johnflorin · July 12, 2019, 10:04am

As part of a quest to improve reliability and WAF, I’d like to have 2 HASS.IO instances in separate VMs, one with the ZWave integration and one with everything else.

This should lead to being able to quickly restart HASS.IO (without waiting minutes for my ~40 device network to come fully online) as well as protect the “delicate flower” that is ZWave in HA (seriously, restarting while the ZWave network was still starting has been a cause of sooo many issues).

So, how could I achieve this?

I was thinking MQTT, but I don’t want to use the ZWave2MQTT addon, as from what I’ve seen it replaces the existing HA ZWave integration and looks much tougher to setup and maintain.

What I want is to not touch my existing ZWave config, only add something that can forward its states to my other HASS.IO instance, then move all my automations that rely on these states to the new instance…is such a thing possible?

Thanks in advance for any ideas!

johnflorin · July 12, 2019, 12:11pm

It would seem like this is what I want: Multiple instances of home assistant on different networks - might be simpler to implement, hopefully, since the 2 instances would actually be on the same network.

squirtbrnr · July 12, 2019, 12:26pm

MQTT statestream, HA REST sensor component with API (What you found), or the ZWave2MQTT addon. I found a guide on how to migrate HA ZWave to ZWave2MQTT yesterday.

johnflorin · July 12, 2019, 12:30pm

Read that ZWave2MQTT guide just a few mins ago, looks pretty daunting, at least with MQTT statestream I only take what exists already and use it, whenever I hear “ZWave” and “migration” I shudder instinctively I really don’t want to mess with the current ZWave network at all, some of my stuff is behind wall switches, a total nightmare to reset or re-pair if anything goes wrong.

It looks like MQTT statestream does exactly what I want it to do, just gotta figure out where to keep that bridging broker, I hope I can just spin one up in the new Ubuntu instance.

squirtbrnr · July 12, 2019, 12:34pm

agreed. I’m in a similar situation. I don’t want to touch my zwave network and whenever I do it usually means downtime for HA. I’ve had mine running since version 0.4x with a few hiccups along the way but generally stable. I think the most daunting part of that guide is identifying all of the sensors and creating the respective MQTT switch/light/lock, etc. But once you understand the format, the templating gets pretty easy. I need to read up more on MQTT to understand best practices with the the topic name configuration such as group/area/device/sensor/state.

johnflorin · July 12, 2019, 12:36pm

Yep, it looks like I’ll have to create dozens of entities in MQTT, but that’s fine, as you say, it should become simple enough via repetition and it has the benefit that I don’t need to actually use the new instance in “production” until everything is ready.

abalakov · July 12, 2019, 1:01pm

Here is an example.

Zwave in Host/Master system:

mqtt_statestream:
  base_topic: ha_master_topic
  publish_attributes: true
  publish_timestamps: true
  include:
    entities:
      - switch.double_relay_sprinkler_switch
      - switch.double_relay_sprinkler_switch_2
      - zwave.double_relay_sprinkler

Slave system:

switch:
  - platform: mqtt
    name: "tap1"
    icon: mdi:water-pump
    state_topic: "ha_master_topic/switch/double_relay_sprinkler_switch/state"
    command_topic: "ha_master_topic/switch/double_relay_sprinkler_switch/set"
    availability_topic: "ha_master_topic/zwave/double_relay_sprinkler/is_ready"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    payload_available: "true"
    payload_not_available: "false"
    optimistic: false
    qos: 0
    retain: true
  - platform: mqtt
    name: "tap2"
    icon: mdi:water-pump
    state_topic: "ha_master_topic/switch/double_relay_sprinkler_switch_2/state"
    command_topic: "ha_master_topic/switch/double_relay_sprinkler_switch_2/set"
    availability_topic: "ha_master_topic/zwave/double_relay_sprinkler/is_ready"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    payload_available: "true"
    payload_not_available: "false"
    optimistic: false
    qos: 0
    retain: true

johnflorin · July 12, 2019, 1:06pm

Thanks a lot for that!

And what do I have to run on the 2 systems?

At the moment on my first (and so far only) HA I have the Mosquitto broker addon and the MQTT integration (both of which I’m using for connecting to a Pi that uses the Monitor presence script), can I just install the MQTT integration on the new slave system and tell it the topic?

abalakov · July 12, 2019, 1:24pm

You just need the Mosquitto broker addon (just one on any machine). I have it running (as Hassio add-on) on the Host system and it appears under -> Configuration -> Integration -> Configured

You need to add a user in HA “mqtt” / [any pwd]. It becomes your mqtt-user pwd for loging into Mosquitto.

No further configuration required in configurations.yaml in the Host system.

The Slave system has the following entry in configurations.yaml

mqtt:
  broker: 192.168.10.20
  username: mqtt
  password: [your mqtt user pwd - see above]
  client_id: ha_virtualbox
  keepalive: 60

I use this setup as development environment on a Virtual Machine and still can access ZWave devices if required.

johnflorin · July 12, 2019, 1:36pm

Wow, this looks EXACTLY like what I need, thank you so much for explaining it so thoroughly!

abalakov · July 12, 2019, 1:46pm

Make sure to install mosquitto_sub. This helps a lot.

Run it on your cmd line to watch the MQTT messages.

mosquitto_sub -v -h 192.168.10.20 -u mqtt -P [secret_PWD] -p 1883 -t 'ha_master_topic/#'

Emphyrio · July 12, 2019, 1:54pm

I just wanted to mention: since disabling the radio manager every restart has been flawless. No more z-wave issues. It’s described in the z-wave docs nowadays.

johnflorin · July 12, 2019, 1:56pm

Interesting…I see a mention of the Modem Manager at https://www.home-assistant.io/hassio/zwave/, not the Radio Manager, is this what you mean?

Emphyrio · July 12, 2019, 2:27pm

Yes, sorry for the mix up.

phantomdarkness · July 12, 2019, 6:31pm

I’ve also been exploring this. Was looking at zwave2mqtt mostly because i didn’t want to have to bother updating 2 HASS installs, though i suppose if both are in docker it’s not too bad.

Let me know how statestream works out for you.

johnflorin · July 12, 2019, 6:53pm

Yep, will probably give it a go on Monday if I can contain the excitement till then Updating 2 HASS installs is OK from my point of view because the plan is to keep one with ZWave, MQTT and literally nothing else, so that I’d only need to look out for ZWave breaking changes.

I will definitely be using this opportunity to create a 3rd VM, though, finally a DEV/TEST environment with all hardware accounted for!

phantomdarkness · July 12, 2019, 10:16pm

Anybody know if zwave2mqtt can handle double taps? Like I have a few automations that run on double taps on my light switches. If not, guess my best best is statestream

gregg098 · July 13, 2019, 5:35pm

I’m really curious about switch taps and lock control myself.

phantomdarkness · July 13, 2019, 5:39pm

Right now I’m bashing my head against a wall with mqtt_statestream and mqtt_discovery not seeming to want to play nicely with each other. But yeah, if zwave2mqtt is “easier” i might be tempted.

gregg098 · July 13, 2019, 5:51pm

I think it was on Reddit, but the developer said he just released a version of Zwave2MQTT that supported Home Assistant MQTT discovery. It sounded like more of a beta version, but worth checking out.