I’m giving the beta a shot on a secondary sd card on my rpi4. Initial installation and setup went reasonably well. (Needs more testing, but the basics appear to work.)
My issue: I have some custom openzwave device xml files I would like to use. Is there any way to use them in current beta?
Background: In the existing official integration (which ozw 1.4-based), I had added xml files for some devices that weren’t supported, either because they weren’t recognized at all or because they were recognized as a similar, functional, but not identical device description. It appears those devices are also not recognized in ozw 1.6. I also had to modify manufacturer_specific.xml to point to the right files. In the old one, I did all this by setting config_path for the zwave integration in configuration.yaml and dropping in my own copy of the xml files, and occasionally editing or deleting the ozw_*.xml files to bring in the new configs.
I’m running an up-to-date hassio setup on rpi4. I suspect this would have to be accomplished in (or instead of) the openzwave add-on, since that docker image is where the xml files & ozw server are, but I’m new to docker and so still figuring out how to make persistent changes or replace the container with my own if you have any pointers on that front, ideally within hassio (I do have supervisor access on).
Thanks for any help, and really looking forward to experimenting with this some more! And apologies if I missed this in the documentation or elsewhere–I promise I did search.
Also it’d be helpful to submit your modifications to the OpenZwave project so others can benefit as well from your fixes to the device database.
Indeed, I started looking into that a couple of days ago. Will do when I have a minute. Interestingly, my xml is based on the cd-jackson database, which has had the device for a long time (though I did update a little from their version).
Might also be a good way for me to test it, by pointing the Dockerfile at my repository instead of the main one.
Yeah, The existing integration keeps it in hassio’s /config folder, but the new integration keeps it inside the Docker container. I’ve been messing around learning how to make changes there, with some success, but not quite there yet.
Yep–I’d never submit it before trying it (which is what I’m hoping this thread will help me do). I know the earlier model of this device had no difference between the 1.4 and 1.6 xml, so I’m hoping this one will not require much work for me to adapt it. But I’m still working on finding a reasonable way to test it.
p.s. Not directly relevant, but cd-jackson also produces malformed xml that won’t work with any parser, but I made a little script to fix it.
So far no luck. Right now the devices seem to work and I’m focused on getting everything else working cleanly, but I’ll no doubt return to it when I want to do some advanced configuration. Will follow up if I learn anything.
you can modify the config of the add-on by sshing into HA using the add-on then run docker ps -a to find the docker ID of the supervisor container: homeassistant/amd64-hassio-supervisor
then shell into it by: docker exec -it b41dbe957fa4 /bin/bash
Replace b41dbe957fa4 with your container ID.
the config can then be found here: /data/addons/data/core_zwave/ozw/
Please be aware that the devs dont want us doing this and also i was not able to get a custom XML to work at all. no matter what I did it crashed the daemon when i did refresh node or included the device and continued to crash the add-on every time it starts until I removed the custom XML. I believe this is a bug with the add-on but YMMV.
Let me know if you have any more success! This is the path I was referring to above when I was looking to make changes inside the docker container. I got stuck with it being very difficult to edit files inside the containers or even get external files into the containers. The addon has changed since then to make the files persistent, which I think is what puts it in the supervisor container and should help, but I’m currently holding off (see my next reply).
If people are interested, there is now a github issue requesting that the xml (and maybe logs) be exposed in the config directory or elsewhere so they can be modified more easily:
Frenck has said he’s open to it and checking with the team on implementation details, but it also sounds like there are some challenges.
fishwaldo suspects it has something to do with the libcversion in alpine linux used for the add-on. i would be interested to hear if anyone is able to get a custom xml to work with the add on though. For now I have just switched to the qt-openzwave docker image and I dont think I will being going back to the add-on. I can update openzwave whenever I want now is another benefit, especially since its under such heavy development right now.
and how you did it