Looks like HA has a new addon that provides for Z-Wave control over MQTT.
Yeah I saw that also…but then https://github.com/OpenZWave/Zwave2Mqtt
intriguing since I have feet in both camps.
Think we are both talking about the same thing. Looks like the link I shared utilizes the library you linked to.
i will try this soon, because i have tried to configure the official zwave binding with the thing file, but this was never working, i have everything file based, but not the zwave.
I’m using this between my main openhab instance and one providing zwave via a raspberry pi. The Pi is using a thing file for the controller and items which are then synced via mqtt, the main instance subscribes to this topic and is used via items as well.
zwave2mqtt is very easy to use, i have now running it.
these are my settings if someone is interested in:
with this settings the mqtt topic looks like:
You need to set the location and the name in the gui for the zwave device for a mqtt topic like in the picture.
i have 5 danfoss thermostats in use now with that.
these are the settings for mqtt:
Thing topic Devolo_thermostat_GF_Corridor "Thermostat Gang EG" @ "Gang EG" {
Channels:
Type number : temperature "Temperature" [ stateTopic="zwave2mqtt/Gang_EG/Thermostat_Gang_EG/thermostat_setpoint/heating_1", transformationPattern="JSONPATH:$.value", commandTopic="zwave2mqtt/Gang_EG/Thermostat_Gang_EG/thermostat_setpoint/heating_1/set", min=4, max=28, step=0.5]
Type number : battery "Battery Charge" [ stateTopic="zwave2mqtt/Gang_EG/Thermostat_Gang_EG/battery/battery_level", transformationPattern="JSONPATH:$.value" ]
}
More types of channels are possible, but i dont need more.
Zwave2mqtt is running in docker on a raspberry pi 3.
2 Likes
I agree that this is interesting. It’s because i’d like to make my MQTT message broker the centralized message bus in my home automation system. I’ve done some testing today running it in docker compose but I haven’t migrated yet.
When it comes to configuring the gateway, I notice that @mpuff used the depricated type “Name topics”. I think I’d like to go the “Configured Manually” path… I will have to define gateway values types to customize specific values topic for each device type found in the z-wave network.
One of the problems that I have stumbeled upon is this text in the log:
Failed to load device_classes.xml
2020-02-24 16:06:24.908 Warning, Check that the config path provided when creating the Manager points to the correct location.
i have now tried the new zwavejs2mqtt, this is the new project of zwave2mqtt.
this will in the near future replace the zigbee2mqtt project.
with the same settings the mqtt topic does not work, has someone the same in use and can help me how i need to set the mqtt topic to set the value?
Which one?
There were 2 zwave2mqtt One my openZ-Wave and another. further behind, by Home Assistant. The Home Assistant one required hacking to get it operational when I tried it. I notice it is so bad people on HA forum say to use the old creaky addon.
In my experience, at least for north American devices. the OXQ database is very lacking, especially compared to the one in OH. It was suggested several years ago to share data but OZW refused.
That just says zwavejs, How does that relate to the OZw based on C++ ?
It looks like a new venture trying to use the incomplete Z-Wave Alliance data as a source. Manufacturers choose whether their device data is publicly available there. It is not a requirement. We do not use that as a primary source of data.
I think there was some confusion about zwave2mqtt, zwavejs2mqtt and zwave-js which I’d like to clarify:
-
zwave-jsis an alternative z-wave driver implementation completely independent of OZW. -
zwave2mqttis an OZW-based software to bind Z-Wave devices to MQTT. It also supports auto-discovery (using HA conventions, which may be used by OpenHAB as well). -
zwavejs2mqttis the successor ofzwave2mqttusingzwave-jsas driver, causing it to be much faster and more stable then the former implementation using Open Z-Wave
zwave-js uses multiple sources to provide up-to-date device configurations (OpenZWave, OpenSmartHouse, Z-Wave Alliance, + many PRs from device users).
And Home Assistend has recently switched to zwave-js/zwavejs2mqtt as the main Z-Wave implementation:
Maybe this is of interest for OpenHAB too?
Why when we have the original driver using OpenSmarthouse? I have not found much of any functionality or support missing from the binding.
Does zwave-js support the 700 series Z-Wave Plus 2 controllers?
My experience on HA with the old OZW binding was an obvious lack of support for the devices available in North America.
I am curious. How are you retrieving that data? I know how I would approach that but I did not think that was common knowledge.
Does zwave-js support the 700 series Z-Wave Plus 2 controllers?
v6.0.0 introduced basic support for 700-series controllers:
https://github.com/zwave-js/node-zwave-js/releases/tag/v6.0.0
Some developers already successfully run the Silicon Labs SLUSB001A UZB-7 with zwavejs2mqtt since they got them a few days ago.
The currently supported command classes and their versions are transparently visible in this issue:
https://github.com/zwave-js/node-zwave-js/issues/6
Users can vote on required command classes which will influence what will be implemented next:
https://github.com/zwave-js/node-zwave-js/issues/729
I am curious. How are you retrieving that data? I know how I would approach that but I did not think that was common knowledge.
This file retrieves the configuration from some sources (OZW and OpenSmartHouse):
https://github.com/zwave-js/node-zwave-js/blob/master/maintenance/importConfig.ts
Hope this helps 
1 Like
I did not think that standard was public yet.
https://www.cd-jackson.com/zwave_device_database/zwave-database-json.gz.tar
That personal server died. If it has been resurrected with any database copy it is not current.That is likely an old comment.
// Where all the information can be found
const ohUrlManufacturers =
“https://opensmarthouse.org/dmxConnect/api/zwavedatabase/manufacturers/list.php?sort=label&limit=99999”;
const ohUrlIDs =
“https://opensmarthouse.org/dmxConnect/api/zwavedatabase/device/list.php?filter=&manufacturer=-1&limit=100000”;
const ohUrlDevice = (id: number) =>
https://opensmarthouse.org/dmxConnect/api/zwavedatabase/device/read.php?device_id=${id};
You are using the api. I did not realize it was common knowledge
But this is integrated using an unofficial interface. If you are desperate to run a uzb7 Initial Stage GATEWAY 700 series adapter support by NilsBohr · Pull Request #1370 · openhab/org.openhab.binding.zwave · GitHub but it will not make a huge difference.
May you explain to me what you are referring to as “using an unoffical interfae”?
Are you talking about the driver API interface do you refer to the way the device configuration is fetched from the database?
1 Like
It is using the serial bridge interface that is not officially supported to be used directly but only by Z/IP.
The standard for 700 series and beyond controllers currently is to use Z/IP though there is talk of a new static controller interface.
It works because you can map service to service between bridge and static controller. In future releases they might make the bridge controller interface significantly different which would make this less easy and more troublesome.
As the bridge controller serial interface is designed to only support use by Z/IP there is no guarantee they will not change it regularly as they develop Z/IP and new standards and features like long range.
This is interesting, thank you for letting me know!
Do you have some links (e.g. at Silicon Labs) that explain that in more details?
Start here Z-Wave Controller Software Development Kit - Silicon Labs
So the official integrations are:
- UDP to Z/IP
- C API wrapper for Z/IP
- Z-Ware which has a basic portal interface and web API but it might not look like you would imagine when you dig in INS12902-Instruction-for-Z-Ware-Web-Developer-Guide.pdf
All involve wrapping third party libraries with some advantage that Z/IP hides some of the complexity of dealing effectively with the hardware controller and z-wave network.
I imagine this is why if they do release a serial static controller they will make the approval process more rigorous. There is so much that you can get wrong when dealing with the controller through the serial interface. The basics are not too hard but there are some nasties hidden in the detail.
An example schema from the z-ware API
List nodes looks like this:
