I’m looking for a Z-Wave to MQTT software based gateway that also allows node management without needing additional hardware or software. Any suggestions?
I’ve been playing with https://github.com/belyalov/open-zwave-mqtt, but it doesn’t have any provisions for node management.
For whatever reason, HA doesn’t provide the ability to control devices by publishing commands to HA via MQTT. So scratch that idea.
have you tried this one?
Not sure I follow, I have a garge door that is open/closed from HA, so the mqtt cover has a command set. You’d have to find the mqtt variant for your component, then check for the command.
Or do you mean the ability to include devices on the controller via HA?
I tried that one, it requires NodeJS which crashed on me a few times, so I had to scrap that one. Perhaps it was a CentOS 7.x issue. CentOS doesn’t play nicely with anything fairly new. I may try that one again using Debian.
I mean, one cannot setup MQTT subscribe in HA and send an MQTT publish command to control a non-MQTT device that HA controls. If that worked, I would be set because I could just use a separate HA instance as my Z-Wave to MQTT gateway. BUT, no dice! I’m not sure why HA doesn’t permit such a use case.
Ahh right, yeah that’s one disadvantage of the device based model that HA has. In openhab I can define any mqtt topic for input or output an do what I like with it.
Is there a generic mqtt item in HA, or a switch that would be applicable for what you want?
I’ve read that there is a way of creating “automations” to listen for published MQTT topics. They then take those topics and payloads to convert into internal HA device control commands. Seems kludgy to me so I skipped that idea.
Still poking through the NodeJS based Zwave2Mqtt again though. Maybe once I get over all the quirks it will meet my needs. Still wish HA just do this natively.
Can you elaborate on what you mean exactly? I’m trying to understand why you would “send an MQTT publish command to control a non-MQTT device”. What is the point of publishing to an MQTT topic if the target device doesn’t support MQTT?
With all due respect, your interpretation and understanding of automations is superficial at best and deeply flawed at worst.
You have the option to ask for assistance on how to achieve your goal … or you can continue to believe that it’s a "kludge’ to use an automation to process MQTT messages.
In fact, you have no choice but to do that because openHAB’s Items lack any concept of higher-order abstractions like thermostats, alarm control panels, covers, etc. If the goal is to simply map an MQTT topic to a String item, openHAB’s syntax (at least for MQTT Binding 1.0) is admittedly more compact than the equivalent in Home Assistant (using an automation). It’s one lengthy line using an awkward syntax (I should know because I created many of them when I used openHAB for several months). However, if the plan is to do something with that Item then you’ll need a Rule. In Home Assistant the same automation that subscribes to the topic can also process it (i.e. serve as a Rule).
I interpreted this statement as a non HA mqtt device…ie he had a topic that’s not currently assigned to a specific HA component (eg mqtt alarm, mqtt sensor, mqtt switch).
It’s has pros and cons this method. HA’s use of devices is great for standardising interactions between different platforms. The concept is unwieldy in OH, needing 3 or 4 distinct items to make up a thermostat for example.
But I haven’t seen if there’s a simple HA device using the mqtt platform that will take a string state and display it.
But for the OPs post to an mqtt topic I would have thought an mqtt switch would do it, altering the payload to whatever value you wanted.
One way would be to use input_text.
The service, input_text.set_value, is used to set a value. A simple automation could subscribe to a topic and use the received payload to set an input_text’s value. For example:
- alias: 'example 1'
trigger:
platform: mqtt
topic: test/whatever
action:
- service: input_text.set_value
data_template:
entity_id: input_text.whatever
value: "{{ trigger.payload }}"
A more sophisticated automation can subscribe to more than one topic, process the payload, possibly transform it into some new format, call other services, assign it to one or more entities, etc.
To compare this to openHAB, it would be like having a Rule that could subscribe directly to an MQTT topic and process the payload before assigning the value to an Item (or even more than one Item). Except, of course, it doesn’t work like that in openHAB. Some pre-processing is possible, using Transformations, but it’s not as flexible as Jinja2 templates.
I would like to define Z-Wave devices in HA and subsequently have HA subscribe to an MQTT topic so that the Z-Wave nodes can be controlled via MQTT. Let’s call that topic: “home-assistant”. THEN, be able to publish something like “home-assistant/zwave/family_room_fan/level/set low” from any device that can publish to my MQTT broker and have HA change the state of that device.
GitHub - OpenZWave/Zwave2Mqtt: Fully configurable Zwave to MQTT gateway and Control Panel using NodeJS and Vue meets the requirements I’ve stated, but it’s not HA, so this means adding more software to the mix. I was hoping the requirements could be met using just HA.
Side rant:
What I don’t understand is why HA will publish MQTT topics and payload information when device states change, but it cannot listen to MQTT topics to change device states. Another oddity is that HA only publishes on/off states of fan items instead of actual values such as: low, medium, high.
Don’t get me wrong, HA is awesome in many ways. For me, it just needs a little polish around the MQTT edges.
I’m assuming you’re running just Home-Assistant then, since Zwave2 MQTT is now available as a HassIO addon.
I seem to get a low, med, high setting for my fan.
That’s possible now, using an automation.
I was hoping the requirements could be met using just HA.
Your expectation cannot be met the way you envision it. You’re expecting Home Assistant to be able to do this natively. In other words, every entity defined in Home Assistant, or for your purpose every zwave entity, is automatically assigned an MQTT topic. No such functionality currently exists in Home Assistant.
The closest thing available now is Home Assistant’s Application Programming Interface (API). All entities and their services are accessible via the API. Effectively, you’re asking for the same degree of accessibility but implemented via MQTT.
For me, it just needs a little polish around the MQTT edges.
Your request amounts to much more than just a little “polish”. It’s a completely new way to interact with all entities.
I think the MQTT Statestream is close, but you don’t get to tweek too much about how it sends/receives the data. You could use the include/exclude entities/domains piece to only use it for your z-wave devices too, i think."
*Edit- Looks like this can only push out changes, not receive new commands.
It seems like the mqtt_eventstream component can also receive events, but is meant to connect two HA instances. Not exactly what he’s looking for.
Yes, its one-half of the functionality as envisioned by Rickerdo. It’s the publisher half; all entity state-changes are published to well-formed MQTT topics.
What’s missing is the subscriber half.
In a manner of speaking, MQTT Discovery does a bit of what one would expect of the ‘subscriber half’. However, it only subscribes to topics for MQTT-based entities it has been instructed to create (a.k.a. discover). Whereas in the envisioned functionality, all defined entities (regardless of platform) are automatically assigned MQTT topics.
I still think this problem can be solved with an automation subscribed to homeassistant/zwave/# and would need either a clever tempate and/or a python_script to achieve the desired result (control zwave-based entities via MQTT).
The reason why I say this is because I created the same functionality for Premise (the home automation software I continue to use in combination with Home Assistant). Every entity in Premise is automatically assigned two MQTT topics, one for receiving commands and one for transmitting status.
state_topic: "premise/master/tablelamp/powerstate"
command_topic: "premise/command/master/tablelamp/powerstate"
Exactly my point. Grated, I don’t know the inner workings of HA and how much work it would take to create a synchronous MQTT <> Z-Wave mapping. BUT, it seems like it’s very close. I tinkered with MQTT Eventstream and MQTT Statestream. Both were pretty close to meeting my requirements, but just a tad short in execution.
Correct. I just run HA in a Python virtual environment on a Debian VM. That VM acts more like a logic controller and GUI server. I have a small embedded PC (not a low-end Pi) being used to interface with serial devices like Z-Wave, Alarmdecoder, and my UPS. I have a Pi running in my home theater using Node-Red to create an MQTT gateway for my projector and receiver as both of those devices are controlled via RS232. So I have a somewhat distributed system using MQTT as the communication bus.
I was referring to what HA publishes via MQTT through MQTT Statestream. It’s a known issue that I cannot find the reference to now, but the issue is that when changing the speed of a fan at the controller itself, HA only publishes on and off states via MQTT.
MQTT Statestream publishes an entity’s state (which isn’t constrained to on/off). A fan’s speed is an attribute.
If you want it to also publish changes to an entity’s attributes, you must enable the option:
publish_attributes
I know this is an older topic, but if anyone finds this like I have, check the thread titled “The future of Z-Wave in HA”.
The new integration is using QT-Open-ZWave and it is also using MQTT to communicate with HA.
It looks quite promising.