The Future of Z-Wave in HA - QT-OpenZWave

ha_steve · September 4, 2020, 1:42pm

This just means there is a messages that one of your devices is sending that OZW does not know about. I have several of them. It should not impact functionality

firstof9 · September 4, 2020, 2:32pm

Can you post the mqtt value for the topic of your sensor that has the “Error Code” sensor?

ie:

{
    "Label": "Switch",
    "Value": true,
    "Units": "",
    "ValueSet": true,
    "ValuePolled": false,
    "ChangeVerified": false,
    "Min": 0,
    "Max": 0,
    "Type": "Bool",
    "Instance": 1,
    "CommandClass": "COMMAND_CLASS_SWITCH_BINARY",
    "Index": 0,
    "Node": 38,
    "Genre": "User",
    "Help": "Turn On/Off Device",
    "ValueIDKey": 642334736,
    "ReadOnly": false,
    "WriteOnly": false,
    "Event": "valueChanged",
    "TimeStamp": 1598198889
}

Mind posting your values as well? I want to see what type of sensor could be causing this and try and fix it if possible

cree8 · September 4, 2020, 3:32pm

Oh wow, I’d just began playing with the LEDs as status notifications recently. This came just in time, thanks

wohlraj · September 4, 2020, 7:23pm

I’m getting this as well:

Sensor not implemented for value Alert Location
Sensor not implemented for value User Code

Both are triggered by my Mini Keypad RFID (Schlage Link).
Here are some details:

One occurrence for “alert location”:

{
    "Label": "Alert Location",
    "Value": "",
    "Units": "",
    "ValueSet": false,
    "ValuePolled": false,
    "ChangeVerified": false,
    "Min": 0,
    "Max": 0,
    "Type": "String",
    "Instance": 1,
    "CommandClass": "COMMAND_CLASS_NOTIFICATION",
    "Index": 257,
    "Node": 6,
    "Genre": "User",
    "Help": "Location that the Alert was detected at",
    "ValueIDKey": 72339069121347607,
    "ReadOnly": true,
    "WriteOnly": false,
    "Event": "valueAdded",
    "TimeStamp": 1598741172
}

Multiple ones for “user code”, here’s one:

{
    "Label": "User Code",
    "Value": 0,
    "Units": "",
    "ValueSet": true,
    "ValuePolled": false,
    "ChangeVerified": false,
    "Min": 0,
    "Max": 255,
    "Type": "Byte",
    "Instance": 1,
    "CommandClass": "COMMAND_CLASS_NOTIFICATION",
    "Index": 260,
    "Node": 6,
    "Genre": "User",
    "Help": "User Code ID that was used",
    "ValueIDKey": 73183494051479569,
    "ReadOnly": true,
    "WriteOnly": false,
    "Event": "valueChanged",
    "TimeStamp": 1598939966
}

firstof9 · September 4, 2020, 9:36pm

The Alert Location should work, but that one is not passing in because it’s null. I have an idea for that.

User Code however, that’s a byte, and should still pass since the value is 0.

Thank you for this information.

@FutureTense this user code bit may effect your lock.

matejdro · September 6, 2020, 4:21am

Since original issue tracker (https://github.com/cgarwood/homeassistant-zwave_mqtt/issues) was closed, does anyone know where the up to date roadmap of this project is being kept?

RickKramer · September 6, 2020, 9:49am

As shown on https://github.com/cgarwood/homeassistant-zwave_mqtt

Notice - Repository Archived

This component has been merged into the Home Assistant Core as the OpenZWave/ozw component. Please submit bug reports to the Home Assistant Core repository.

firstof9 · September 7, 2020, 4:28am

Thanks for your information the PR’s been merged to resolve these messages.

matejdro · September 7, 2020, 6:09am

Yes I understand that. But there were some issues on the old repo (such as https://github.com/cgarwood/homeassistant-zwave_mqtt/issues/15) that served as a roadmap. But those were not transferred over.

mang0 · September 7, 2020, 6:29am

So I installed the OpenZWave through the addons / core integration, and I’m having trouble finding my zwcfg or ozwcache file. Where is this supposed to be located? I looked in the /config folder and the /data folder but it just doesn’t seem to exist. Seemingly my network of like 10 ish devices is working fine though…

jaburges · September 7, 2020, 2:33pm

Hi Folks,
This maybe an unpopular opinion, but I wanted to ask a few questions as coming from Zwave2MQTT. (and i’m assuming the point of the beta is to battle test stuff and gather feedback - so please take this as intended as I know people have worked hard on it!)

The qt-OZW docker only allows node numbers to be used (not overly helpful when working out what is what in MQTT) - yes this is solved when you use the integration, but that has its own issue (see #2)
Using the OZW beta integration like the previous Zwave integration adds a LOT of entities that aren’t used - so I could manually add the mqtt devices/entities to reduce the number to just the ones I need to surface (but then need the node name ideally not just the number). A ‘simple’ alternative would be an option to allow OZW docker to send node_names to MQTT, instead of node numbers.
As i’m not able to customize entities on the OZW side, my switches that are lights show up as switches. In Zwave2MQTT i’m able to customize some settings (and use MQTT discovery) OR just manually add my mqtt devices to HA and thus translate switches that are lights to mqtt lights.
I know this can be done with a light switch platform, but with 20 switches - seems like extra work that isnt needed.

What would be handy is a ‘don’t send to HA’ option in the OZW UI, Then for those devices one could manually add them (and if needed add as a light not a switch).

Also can I ask why another Zwave 2 MQTT implementation was built rather than just work with the Zwave2MQTT dev to shape that to the needs? It has more customization and config that the current qt-OZW docker + integration.

bernhard · September 7, 2020, 3:18pm

That one was answered a while ago. Because zwave2mqtt relies on the node wrapper for openzwave and then adds the complexity of translating zwave items to MQTT items.
While ozw Dämon just puts zwave stuff on MQTT topics without translating them into MQTT lights, MQTT covers, etc.

Ozw daemon is the slimmer, easier to maintain solution. Personally I prefer the zwave2mqtt approach as I do most stuff in node red directly via MQTT. While this works with ozw daemon as well, zwave2mqtt topics are nicer to work with.

I would love if zwave2mqtt would have been the basis but I understand ozw daemon follows a different design idea which is makes a lot of sense as well.

jaburges · September 7, 2020, 6:07pm

Interesting, thanks for the info (and taking the time to reply!)
I figured it maybe technically more complex.

The only other question then is what made the team choose MQTT? Is qt-openzwave being built for just HA? If so wouldn’t using the HA API make more sense to avoid a step (and add a bunch of noise to MQTT?)

Actually I lied, one other question lol, what does the integration do that enabling MQTT discovery doesn’t?

I went back to Zwave2MQTT as I’m trying to avoid all of the additional entities that aren’t used, plus the other main point was the switch/light conversion.
I’ll raise a FR in case it’s functionality the team want to add

bernhard · September 7, 2020, 7:19pm

I guess MQTT makes it easier to build integrations with other systems? No idea really.

For my use case Z2M works better for now, but let’s see. Great that there is some work done.

michael.olson · September 9, 2020, 2:54pm

Running the qt-openzwave-allinone Docker image and lost the ability to add nodes to my network through my Aeotec Z-Stick. Anyone experience anything similar? Filed a bug, but I’m still waiting on a response: https://github.com/OpenZWave/qt-openzwave/issues/160.

p.deelen · September 9, 2020, 9:25pm

Hi,

Thanks for the answer.
This is what i have found:

{
    "Label": "Error Code",
    "Value": "",
    "Units": "",
    "ValueSet": false,
    "ValuePolled": false,
    "ChangeVerified": false,
    "Min": 0,
    "Max": 0,
    "Type": "String",
    "Instance": 1,
    "CommandClass": "COMMAND_CLASS_NOTIFICATION",
    "Index": 266,
    "Node": 14,
    "Genre": "User",
    "Help": "The Error Code returned by the device",
    "ValueIDKey": 74872344045961239,
    "ReadOnly": true,
    "WriteOnly": false,
    "Event": "valueAdded",
    "TimeStamp": 1599120664
}

firstof9 · September 9, 2020, 9:36pm

A fix was already merged in, this should be resolved in a future version likely 0.116.

HA_fanatic · September 11, 2020, 2:21am

I have the same question. Did you ever get an answer some how?

gregg098 · September 11, 2020, 2:52am

I am currently setup with OZW installed on an RPi3 along with a few other containers like Portainer and Duplicati for backups. My Hass/MQTT server machine is a NUC in another room. Today I upgraded the firmware on my router which caused about 5 minutes of downtime on my network. Afterwards, OZW never recovered. Everything was just unavailable in Home Assistant. I first tried restarting Home Assistant, but that didnt work. I finally had to restart the OZW Docker container on the RPi and let the network refresh before anything was usable again. Unfortunately I was not in a position to dive into logs to see what happened and had to just get things working again.

Is this normal? Are there plans to make this kind of setup more reliable and resilient to network interruptions?

Other than this, my overall experience has been pretty good other than the initial migration.

freshcoast · September 11, 2020, 5:48am

ozwdaemon currently shuts down when it gets disconnected from the MQTT broker. Unknown if it will be changed in the future, but I sure hope so (see Github issue).

If you are using the latest container image, it will automatically restart and wait for the MQTT broker for a short timeout. I can’t remember if there’s a limit on the number of retries. Older versions (e.g. the fabled build-150) don’t do this.

If you don’t have a docker restart policy configured, which is sounds like you don’t (?) you probably want to.