Updating Z-Wave device parameters fails

//Reviving this ancient thread for a 3.0 discussion (also related to [SOLVED] ZWave .things config parameters - #7 by chris)

@chris, @sihui, @Kai - Is there an updated (for OH3.x) answer to:

How can one dynamically configure certain runtime properties of an unmanaged thing (defined in .things file)?

Historically the answer has been:

(paraphrasing):

  1. can’t be done,
  2. stop using static configuration, use autodiscovery (and backup Things.json if you need to retain state across installs) = can’t be done :slight_smile:

Has this been revisited for 3.x?

I claim it is worthwhile to reignite this discussion…
While it might seem to only benefit bindings like ZWave, which do update thing’s configuration on the fly, it seems to be a common pattern for lots of smart devices to store their own settings. It also makes sense to me that the user is not interested in explicly defining all of them (they’d rather let it be discovered). Plus, zwave itself is quite a major binding for OH and the current answer is quite a limitation.


Case and point - I store 100% of my hand-entered config in a git repo (and wipe/replace entire OH setup routinely). While I am keeping backups of Thing.json file… I am not considering it equivalent to static .thing configuration.
From my POV:

  • The latter (.thing file) is an imperative (and auditable) way of expressing the devices I want controlled (and consistent across 100% devices)
  • The former(JSON DB) can also be a full DB of things, but is much more - as it also contains dynamic configuration = is big in volume (machine generated) and volatile

Given OpenHab still claims it can be configured from text files… I believe we need to have an answer to “how to manage the manually-entered devices?”. Be it some ‘override’ specifiers in .thing files, shadow copies of the devices (with one way sync from .thing files) or separation of configuration into ‘static’ and ‘runtime’, or sth else.

OH3 with some of its breaking changes seems to be the right timing for that(?)… What do you think?
On the other hand… claiming hand-entered devices are 100% unmanaged… is highly unsatisfactory as a long-term answer IMHO.

Cheers,
Mateusz

[EDIT] Relevant GH issue: Introduce a differentiation between handler and device configuration · Issue #3484 · eclipse-archived/smarthome · GitHub