Did adding it to the new plugin reset your dimmer settings? And the setting for the button changed from on-off to momentary? Wild guess…
Correct some dimmers have instant status, some do not.
You’ll have to wait till there’s an update from the ozw end of things.
Cool. thanks for your help. Much better than beating my head against the wall.
Hi,
Since last week i started using this new integration (openzwave).
After a restart of home assistant core i receive this error inside the log:
Sensor not implemented for value Error Code
How can i solve this?
Thanks
Hello, I have regular unresponsiveness. No errors, just not doing anything. Reboot container (addon) and gone… sometimes 1 month, sometimes 2 weeks. Any suggestions?
Just wanted to point out, someone wrote a script for the LED strip for Inovelli dimmers and switches here as well.
2 Likes
Also, if you use Node Red, there’s a node for it that you just feed into an ozw.set_config_parameter. I have not tried this yet since I moved from Z wave to OZW, but it should work. Guessing the LED setting will still fail until .115 comes out, but notifications should work.
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
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 
Oh wow, I’d just began playing with the LEDs as status notifications recently. This came just in time, thanks
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
}
1 Like
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.
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?
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.
Thanks for your information the PR’s been merged to resolve these messages.
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.
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…
1 Like
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.
1 Like
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.
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