I’ve found a handful of posts over the years describing using local modifications to the zwave db to create a channel for configuration parameters. I know Chris in particular has expressed reservations about the wisdom/complexity/safety of this idea, but I wonder if we can revisit this idea.
There are some pretty good use cases:
dynamically changing the double-tap behavior of switches based on guest mode
changing the default on brightness for a switch at dawn/dusk
dynamically changing lock codes
I don’t find the security concerns particularly compelling:
The channel would have to be linked to an item to enable access
The configuration is available through the REST API just like the items are
In the example of locks, I get that changing the access codes is a little more dangerous than being able to unlock the lock, but only in some semi-contrived circumstances. (Why would I change the access code when I can just use the item to unlock the door?)
It seems like this is just creating awkward configuration where folks either
run a locally modified device db to create a channel
access the configuration REST API via the rules engine somehow
Both of these are pretty undesirable compared to just being able to link an item to a config parameter ot-of-the-box.
In particular, the hack I use for the brightness in the morning is that, as part of the sleep scene, I have a rule that turns a few dimmers to max brightness and then turns them off so that, in the morning, when they are turned on they go to full brightness, not the low brightness they were at the prior evening.
I’m not really sure what posts you refer to about local database modifications, but it is already possible to link channels to configuration parameters and has been for many years. You just need to set up the channels in the database so that the system knows about them.
Well, that’s a completely different question to the title of this post - no there isn’t.
Well, it’s not a simple task, despite what you may think. openHAB doesn’t support local thing definitions, so we’d have to rewrite a load of functionality to provide a new wauy to define things and not use the OH standard functionality. That’s a LOT of work and would make the ZWave binding very non-standard.
I think I’m a little confused… it seems like the zwave binding reads the database and presents a model for each thing to OpenHAB, which includes configuration values and channels. It is possible in the zwave database entry to define a channel that links to a zwave configuration parameter, but most don’t. What if they did? Or if the binding itself made it so? Does that kinda make sense?
The database is exported to a bunch of XML files. These XML files are in the openHAB Thing Definition Format. When the binding is loaded into openHAB, the openHAB core reads all these XML files and makes them available to the binding.
The point here is it is the openHAB core that reads the data - not the binding. If the binding had to implement something to read these (or different) files, or directly read the online database, it would be a major task. It not only needs to read the data, but it needs to make all this information available to the openHAB core since it’s the core that manages stuff like configuration.
Well, if it did, then you’d have a channel available - just like any other channel. This is quite common for parameters that have “user functionality” (which isn’t most parameters) to be exported as channels.
