[feat] Home Assistant Discovery improvements

[varet80]

As a heavy user of Home assistant, I would like to have more integration with Home assisstant.
For instance, we can probably support assigning Devices (nodes) to current Areas (locations), when area exist.
Also would be easier for me to see the wording Device(node), Entity(device) and Area (location) under gateway configuration/hass discovery

Proposal feature 1 (Support Area/Device config)

On the Device/Area (hass name) support. Currently MQTT driver do not support setting an area_id through entity creation. therefore the only way is to use a plugin in Homeassistant.

What this plugin (integration) will do:
Read an mqtt topic and update devices areas, but also name of devices

Proposal feature 2

Change the names referring to Hass devices/entities/areas to fit hass.
Additionally to this, I believe we need to name the Home assistant parts the same way home assistant uses. As the current analogy is:

zwavejs2mqtt	homeassistant
device	entity
node	device
location	area

Feedback

do you think it worth working on any of the above proposals?

[jarrettv]

My dream setup would be zwavejs using a direct binary protocol with hass. Yes it would eliminate mqtt which I feel brings more complexity to the mix than is necessary. The protocol javascript code would be generated automatically from the existing API.

The hass integration could be a clone of the EspHome integration by reusing aioesphomeapi which is actively maintained. For example they recently added fan direction. For anybody that has used EspHome integration with hass. It just works! It is beautiful.

[jarrettv]

To use mqtt it adds too much complexity

• I need another process running (not a big deal with docker)
• I need to manage more secrets
• Figure out reconnect period, I wonder the best value for this since there is no default
• QoS 🤷‍♀️
• Prefix, should it be zwave, I wonder what is best for hass
• Retain, hum wonder what is best for hass
• Clean, don't know again
• Store? uhhh kill me now

[jarrettv]

Imagine if you start your zwavejs gateway. You do your inclusion/exclusion/healing and all that zwave stuff and for each node once you have named properly you set the individual node to "ready" and it just magically shows up and works in hass. It looks good automatically in lovelace with correct grouping etc. That is what I'm looking for. For example here is two esphome devices I added and they automatically grouped the entities together (one device offline).

[jarrettv]

With EspHome you never get this jumpy state where you turn something on and since there is an async (mqtt) hop, hass isn't sure if it turned on or not. This is especially annoying with dimmers. You turn it off and it isn't sure, wait for mqtt messaging. State gets out of sync.

[blhoward2]

Isn’t this what the server being worked on by the HA core team would do?

[roflmao]

This is the glue between mqtt <-> ha as a custom component:

https://github.com/cgarwood/homeassistant-zwave_mqtt

[shackrat]

I don’t believe you can use the built-in component with zwavejs2mqtt. I attempted this and the integration is looking form the add on. It won’t allow a manual configuration. Have you has any luck?

[blhoward2]

I don’t believe you can use the built-in component with zwavejs2mqtt. I attempted this and the integration is looking form the add on. It won’t allow a manual configuration. Have you has any luck?

I use the MQTT integration with no issue to discover the devices, following the readme. I added the control panel as a webpage in Lovelace in panel mode to access the zwavejs2mqtt UI.

[shackrat]

I’m looking to go that route but the main obstacles are the management of lock codes. I’m currently using ozw services for that. Would love someone to develop a native integration component to support this. I’m not a Python dev or I would do it myself.

[blhoward2]

I’m looking to go that route but the main obstacles are the management of lock codes. I’m currently using ozw services for that. Would love someone to develop a native integration component to support this. I’m not a Python dev or I would do it myself.

What do you need to manage lock codes? I don’t have any locks yet so I’m not sure what is involved. Is it setting a zwave parameter?

You may be able to do what you need with a raw MQTT.publish to the topic. That’s all the ozw integration does. It sends out the appropriate MQTT message with the data from the service call.

I’m considering hacking one together but I’m not sure I have the time to maintain it. That said if it can load the current UI, continue to use the MQTT integration for discovery (at least for now), and just add services, it shouldn’t take much.

[jarrettv]

Related idea: consider making zwavejs2mqtt support a compatible message structure so hass thinks it is talking to OZWDaemon.

Vlad Vukicevic floated this idea in slack:

However, one thing that would be killer for me is ozwdaemon mqtt compat. In other words -- mimic ozwdaemon's mqtt topic and data structures, thus ensuring that the native home assistant integration would transparently see it. I realize it's annoying to track someone else's data format, but could be worthwhile.

But I'm not sure his idea was completely understood.

[blhoward2]

While good in theory I suspect that would be a nightmare to keep up with. If you go through some of the old issues fishwaldo was always talking about having the integration people tweak this or that.

[robertsLando]

Hi guys. There is a work in progress to create a 'final' solution for home assistant and zwave. Once I can say more on this I will let you know in slack channel