Is anybody using Z-Way with the Razberry Z-Wave controller?
If I understand correctly, Z-Way uses closed-source Z-Wave libraries but it also appears to support S2 security and looks to have a lot of nice features.
Does Home Assistant have any integration with Z-Way? If not, is it because Z-Way uses closed source software?
I’ve recently started the switch from SmartThings to Home Assistant and I’ve spent a lot of time playing with Zwave2Mqtt (OpenZWave based) and Z-Way to try and decide which is best for me.
This is my (current!) thinking, which is just about what is best for me, so it may or may not apply to you:
Z-Way
Pros
Cons
Zwave2Mqtt
Pros
Cons
So my conclusion at the moment, is that Z2M does everything I need at the moment (and almost everything I want, though not quite), it has a nicer UI (imho!) and the MQTT stuff is better. It has some bugs and oddities but the main developer is really responsive to bug reports so my current thinking is that (for me!) Z2M is the best way forwards. I may even submit some PRs to Z2M to fix some of the bits that I’m not overly keen on
I’ve had z-way/razberry running on a pi for a few years and its been very functional and stable. I’ve recently adopted and building HA on a Pi 4 and have just installed the z-way MQTT add-on. I’ve just successfully got my 1st z-way light switch working in HA using MQTT. Will see if this is stable over the next wee while.
This is very interesting… I’ve been battling with the MQTT plugin in Z-way and tried to get HA to recognize the units. Would you mind sharing some more details on how you did?
Maybe you have a few screen shots available?
Sure, I’ll see if I can help. It’s been a while since I got it all going now but all my z-way devices are working within HA via mqtt. It’s been very stable.
First up, here are screenshots of the version and config of mqtt in z-way.
Oops, those screenshots are in reverse order sorry.
Anyway, by using the tag of “mqtt” as per the 1st screenshot above.I can add that tag to each device element that I want to partake in mqtt. Like this example for my kitchen lights:
Thats all the configuration required in z-way. Everything else is configured in HA.
This is soooo appreciated!! Thanks
I’ll sit tight for the HA side 
In HA you install the Mosquitto mqtt broker integration using configuration defaults. Create a HA user for this addon to use - I called my user “mqtt” with a password to match what you use in the z-way mqtt app.
Then you need to listen and record what z-way is sending to HA when you change the state of a z-way device, by using the topic specified in z-way suffixed by “/#”.
In this screenshot you can see my kitchen lights turning on and off.
If this works, you’ve successfully got z-way talking to HA and all you need to do is script to capture, interpret and use the mqtt messages.
When you get all that working (have a beer and a little dance to celebrate ) then you create some code to for each device. This is mine in my lights.yaml for the kitchen lights. My lights btw are all Aeotec z-way devices.
- platform: mqtt
name: zway_kitchenlights
command_topic: "zway/kitchenLights/set"
state_topic: "zway/kitchenLights"
payload_on: "on"
payload_off: "off"
The last and easiest step is to add your light in a card to your HA dashboard, enjoy and show it off to everyone!
Aha… This is probably where I misunderstood.
I thought the units would show up in the overview just by having the Z-Way and HA talking to each other.
Edit:
Holy mother Theresa!! I got it to work.
You are my hero!
But… the card will change status based on the light status. But the device do not react if I turn it on or off in HA by clicking the card?!?
The card itself indicate that the light was swithed off… but the light is still on. And the Z-Way app also show the light as On.
When looking in the Mosquitto “listen mode”… it seems like clicking the card in dashboard do send a message. But for some reason Z-Way isn’t listening/doing what is being instructed…
Is something more required to have HA confirm that what was sent off in MQTT actually was performed?
This to me is one of the major benefits with Zwave compared to 433 and similar…
If flipping a switch in Z-Way and the device for some reason isn’t responding the switch will flip back to the previous state to indicate the command was unsuccessful. I would preferably want that using MQTT as well.
Or is this not possible?
Lights.yml… so you have a config file for each type of unit?
Or can they all go under the platform:MQTT??
Edit:
So I simply added this to Configuration.yaml;
Light:
-platform:mqtt
Etc… same as you describe…
And it seems to have done the trick.
I could them find it in Dashboard when creating a light card.
Do you have your lights in a separate config file? If so, why?
By the way…
this all make sense when it comes to switches… (on/off)
I assume a dimmer is slightly different? Do you have an example?
And even more complex (maybe, I don’t know)
What about a sensor, temp, humidity or similar? Do I “wake” them and listen?
Normally you don’t send anything to them, they just report in with their data.
Do you have such a unit set up?
Great that you have your 1st message working. To answer your questions:
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
sensor: !include sensors.yaml
light: !include lights.yaml
#Aeotec nano dimmer
- platform: mqtt
name: zway_livingroomlights
state_topic: "zway/livingroomLights"
command_topic: "zway/livingroomLights/set"
brightness_state_topic: "zway/livingroomLights"
brightness_command_topic: "zway/livingroomLights/set"
payload_on: "on"
payload_off: "off"
on_command_type: "first"
brightness_scale: 99
state_value_template: "{% if value|int == 0 %}off{% else %}on{% endif %}"
Here’s, my heatpump which is controlled a Remotec zxt-120 infrared device. Note, we live in a temperate climate down here in the South Island of NZ, so I’ve only set this up for heating. Cooling would possible if you put the work in. This one goes in the configuration.yaml.
### Heatpump ###
climate:
- platform: mqtt
name: zway_heatpump
temperature_command_topic: "zway/remotecHeat/set"
temperature_state_topic: "zway/remotecHeat"
temperature_state_template: "{{ value }}"
current_temperature_topic: "zway/remotecTemperature"
current_temperature_template: "{{ value }}"
mode_state_topic: "zway/remotecOperate"
mode_state_template: >
{% if value == 'on' %}
heat
{% else %}
off
{% endif %}
power_command_topic: "zway/remotecOperate/set"
payload_on: "on"
payload_off: "off"
precision: 1.0
min_temp: 19
max_temp: 28
modes:
- "off"
- "heat"
So you got z-way and HA communicating, which is the 1st big thing. The rest now comes down to lots of trying things until you get everything working as you expect.
You are my hero KiwiAndy!!
And you’re from NZ, I wasn’t sure but your name gave it away a bit 
I’m from Sweden but I’ve been in NZ once travelling the country and absolutely loved it!
I’ve got my Fibaro dimmers, Qubino mini dimmers and a bunch of sensors up and running now.
yesterday however my Zway had built up a message queue to the degree that it wasn’t responsive to anything. It just added all commandos to the bottom of the queue. 
I had to restart the Zwave engine to fix it.
This on the other hand created a mismatch between the device statues in HA and the ones in Z-way.
If I pressed any unit where there was no mismatch in HA, the device would act fine.
If I pressed a unit that had a mismatch, the switch flicked back in HA after a few second suggesting the command had failed (correct, I was looking at the lamp that didn’t respond).
meanwhile I could listen to MQTT status messages that gave the status of the mismatch devices away. But for some reason HA wasn’t picking these up and fed into the entities.
I thought this would have been the case, that if there was a mismatch, the MQTT messages would set HA back on track. That didn’t happen. So I’m a bit disappointed. In a way I’m then back to 433mhz standard where a command is never confirmed.
The way back on track was to via a physical button or Zway actively change the status. I could then turn the light off in HA and Z-way and HA were again in agreement with each other.
Do you have any idea if this is standard? Or have I missed anything in the setup?
My devices are set up in similar ways to your examples above.
One thing that I noticed is that although it works fine to get/set status from/to “zway/akvarium” and "zway/akvarium/set… When listening to /# I see that this is actually sending/receiving on “zway/akvarium 12-0-37”…
What is this numeric postfix? I’ve seen this on other forum threads. Are they important?
Could they be related to my message queue?
I think not, the queue seem to have happened on the Zwave side, ie between the gateway and the device… not related to MQTT out from the gateway. But I’m no expert
Many thanks for getting me sorted!
All down hill from here. Except for a few extra questions above 
Good on you for getting things happening between z-way and HA Johan, and good on you even more for being a Swede. When I travelled through the Northern Hemisphere (many, many eons ago, oh I am getting too old!), sadly I didn’t get to Scandinavia. But I plan to get back up your end of the world when this damn virus goes away.
Hmmm, I can’t say I’ve encountered the problems you have described, although one thought - are you running the same version of z-way mqtt as I am - v 1.4.1?
Also I’ve noticed that there is no message qos option within z-way mqtt so the qos is defaulting to 0, which means no guarantee on the message send. Not sure if this has relevance though.
I do think that the z-way mqtt app is fairly basic and may even be a little buggy, although to be honest it has worked pretty reliably for me. If you are using an earlier version it may be even buggier!
As for the 12-03-37 that looks very familiar but I can’t quite put my finger on it. What type of device is sending this?
In the meantime, keep “tweaking”, researching and trying things. I’m confident you will get it all working (almost ) perfectly in the end.