l3arcf
commented
3 years ago I like the idea of promoting the using and testing of modified configs. In that spirit I thought I'd comment here.
I played with configuring my own config file for a lock before it was well supported by OZW 1.6. I agree that for a first-time user it felt a bit cumbersome, but TBH, I think the most un-clear part was 'resetting' OZW to use the edited config rather than what was in cache and confirming that it had taken. Managing a temporary replacement file was not too big of a deal.
My concern with an override set of configs is that it does not promote the fundamental idea of cloud-sourcing config solutions that can be shared by others. Complacency would likely prevent more people from uploading a working config. Currently, once it works, there's a carrot. Put in a PR and it will likely be reviewed, shared and not overwritten later.
Just food for thought.
rrozema
As a user of Home Assistant with the OpenZWave integration and my own devices developed using Z-Uno I frequently encounter problems with the device configurations, e.g. being unable to set config values through OZW. There have been a lot of conversations in the Home Assistant community regarding updating existing device configurations and creating new ones without need for complicated workarounds.
I would suggest to have OZW read the official device configurations from the location as it is today and then, if a configuration parameter is set to point to a config override directory, append/override the official configuration with manufacturer_specific.xml and device xml files from this directory.
I do not know how device configurations are handled by OZW, but I will assume that the configurations are read from the xml files when they are needed. If that is not the case the following will have to be adjusted to the way it works, but the idea should be the same.
When a device configuration is needed by OZW it will start by looking in the override directory and use that configuration if present. If device configuration cannot be found in the override directory, the official version will be used.
The solution described above will make it easy to test out changes to existing device configurations, create new device configurations and allow users as myself, who have developed their own devices, to create configurations for these devices without these configurations being overwritten when a new version of the official configurations becomes available.