Hmmm - that seems like bad news. Why was this restriction added?
The problem I have is that we don’t want to have to send hundreds of configuration values to a device each time the binding starts. Some configuration values (in Z-Wave devices at least) perform actions - if we send them every time the binding starts, then the action gets implemented (eg resetting a counter). Without the ability to manually send configuration to a thing, even if the data is lost, we can’t control devices…
Ok, so I know what your next comment will be ;). This is related to configuring devices, and not the thing handler. Ok, this is true, however as there is no alternative at this time, we have to use this system to configure devices.
However, I would suggest that even for a thing handler, allowing a user to configure it for the duration of the session is still useful as it means they can make temporary changes, and then write them into the text files once they are happy with their configuration…
I agree that it would be really helpful to enable temporary update of thing configuration. That was my initial understanding of what will offer the PR and that was a great news.
Then what would be the correct way of setting the thermostat form C to Fahrenheit? I have textual zwave config working with the only remaining issue being that my stats are in C rather then F.
This is a different issue - for this you need to be able to define definitions for channel configuration and I’m not sure where this is defined in the text files.
So I understand that technically this is a channel config, but do people really want to have thermostat_setpont_heating to F and set thermostat_setpoint_cooling to C? Why not for now just use config_scale setting on the Thing to set all channels?
Maybe this could be done - it’s more complicated and I’m not sure how to do it without it being a hack since it’s the command classes that have the configuration (same as in OH1). But yes, we could hack something together and it would solve the problem that you have right now.
However, we have other channel level configuration in ZWave that does need to be at channel level (inversion of certain data for example), and people are using these today as well (although not with text files I assume). Ok, yes, I guess I could hack something together to solve those problems as well, but I’d tend to argue that the system is meant to do this and it doesn’t, so we should try and have a solution.
Justification/use case for this: Even if a thing is not managed - ie it’s configured through text files - the user may want to update configuration for the duration of the session. Currently this is impossible - configuration of the thing must be undertaken through the text file, which means the thing is reinitialised (removed, and re-added).
