2 days ago he had a commit of a beta version for HA integration. https://github.com/OpenZWave/Zwave2Mqtt/issues/27#issuecomment-510427145 I have yet to test it, but I’m following this closely.
@abalakov, I tried doing what you suggested above, except for the fact that my user is named “MQTT” instead of “mqtt” (I am re-using it from another integration that I already had for a Raspberry Pi Monitor client), now I have a switch on the slave system that is set to Unavailable, any idea if I must name the user “mqtt” specifically?
@abalakov, never mind that question, I have another 
I realized I hadn’t included the zwave entity alongside the switch, corrected that and now it can be seen in the slave HA!
Just one issue remains, I can’t control it from the slave system. I can see the state changes, control it from the master system, but it ignores on/off from the slave system.
I used the exact code you gave above and am assuming the command_topic: “ha_master_topic/switch/myswitch/set” is what is not working for me at the moment…
Problem solved thanks to this post: Newbie question - how do I find the identity and topic for an mqtt message 
I had to also add this to automations.yaml in my master HA instance:
- alias: control_reds_workstation
trigger:
- platform: mqtt
topic: "ha_master_topic/switch/fibaro_system_fgwpef_wall_plug_switch_5/set"
action:
- service_template: "switch.turn_{{trigger.payload | lower}}"
entity_id: switch.fibaro_system_fgwpef_wall_plug_switch_5
Thanks again! Many headaches should be thus avoided in the future
OK, so I’ve made some progress in the sense that I’ve forwarded a dozen ZWave switches to the new instance via MQTT, buuuut, the switching from the slave system is not 100% functional…it seems to set the switch, but doesn’t update the state on the slave system…it shows the state correctly all the time if I use the switch on the master system.
Any ideas? (or rather, has this happened to anyone else?)
Check out my post on this: [Guide] Separating ZWave to a Separate HASS Instance via MQTT Statestream
What is/are your command/state topics? Switches are pretty easy and should “just work” from my experience.
I could not get your guide to work 
I’m supposed to input this only in the main system, correct? It brought the zwave system’s MQTT crashing down when I inputted it there:
mqtt:
discovery: true
discovery_prefix: ha_master_topic
This is what I have right now in the main system for a switch:
- platform: mqtt
name: "Counter Lights"
state_topic: "ha_master_topic/switch/fibaro_system_fgwpef_wall_plug_switch/state"
command_topic: "ha_master_topic/switch/fibaro_system_fgwpef_wall_plug_switch/set"
availability_topic: "ha_master_topic/zwave/fibaro_system_fgwpef_wall_plug/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
I think in your guide a couple of more details need to be given as to where the MQTT statestream and discovery components need to be inputted, because it’s not clear if they should be on the main system, on the zwave system, or both. Can you please elaborate that part a bit?
After following part of your guide discovery seems to be working for my switches, but I still wouldn’t say reliability is perfect…it seems a bit better than with my previous config, but I still seem to have introduced some extra “wonkiness” vs. just using the zwave switch directly, not all of them update every time.
In case you haven’t seen it. There is a custom component that is much more elegant than mqtt based stuff. It grabs the states from one or more remote HA instances and forwards local service calls to the remote instance.
Would you say this is better or worse the zwave2mqtt?
I’d prefer zwave2mqtt if it worked well. However, it does not support all device types. thermostats are, for example, rather tedious because they need a special config and don’t work out of the box. For some of them, this config has been shared in github issues or here on the forum, but it looks like a pain to create this from scratch.
Having another HA instance running is a lot of overhead, but you can pull out not only zwave related stuff but other features as well. This allows you to have dedicated instances for different RF standards or have redundancy.
I have just migrated my main instance to a VM and my zwave and Zigbee stuff to a pi. Zigbee works great with deconz but still don’t feel fully confident in zwave2mqtt ability not to crap out on me and cause me a massive headaches.
Yeah, I feel the same way. The integrated zwave is buggy as well but I have a little trust that built over the last 40 HA releases or so. 
I’m still looking for proper monitoring for zwave nodes because HA does display it when nodes lose contact or have not been communicating for a day.
Yes i tried this and couldn’t get it to work. kept getting websocket errors. If it works for you great!
I have been using this for close to 2 years. It works perfectly for me. I installed it around HA .90 version days and it has continued to work flawlessly for me up to 0.102.3
I use multiple raspberry Pi installs with zwave sticks around my large home that all then report to a central hassio install running on a NUC (over 1000 zwave devices) I can’t praise this plugin enough!
@azwildfire please could you specify what you have been using for the last 2 years? I’ve got a bit mixed up over who is talking about what. Thanks!