Just wanted to check if this is still true in OH3. Like a lot of people, I’m using entirely text config, including for ZWave. I don’t change the config of modules often but when I do, I’m having to comment them out of the thing files, discover them, add them as things, change the config, delete them as things and then uncomment them in the things file.
I’m guessing it probably isn’t but if this limitation is removed in OH3, it would be great to be able to manage the module config in the UI.
Yes, unfortunately it is. I don’t believe that the maintainers are ever likely to allow this to e changed. Personally in my own system, I’ve removed this limitation, but the change was rejected when it was proposed into the core.
Was there a [good] reason for this? The text config handles how the module interfaces with OH whereas the module config is about the module itself so I would have thought they are different and could be treated as such.
Did you have to compile a version of OH yourself to remove the limitation? If so, that feels like harder work than temporarily transferring the modules to UI config to manage them.
That limitation is part of the binding and I am sure the developer made it as accessible as they could, considering the limitations of the OH framework.
No - this limitation is in the OH core. My preference was t remove the limitation.
The maintainers considered that it was confusing for people to be able to send configuration to things that are configured through text files, so this is blocked and the configuration is not passed to the binding at all if the device is configured through files.
My counter argument was that if people are configuring with text files, they probably understand that they need to update things in the text file as well, but often we’re in the situation where we don’t want to edit the file to change something while “playing around” to get things working and therefore being able to send configuration to a thing is still useful. Anyway, I was not successful in getting this changed and my PR was rejected - sorry.
Yes, as I said above in my system I don’t have this limitation - it is possible to configure things through the UI even if they are configured in files.
I can see why the maintainers want to restrict the ability to edit configuration in the UI and text files simultaneously. The ability to do so creates issues around precedence of things or items that have been specified differently in the two methods.
However, OpenHAB does not provide a means to configure the modules themselves using text files, and neither should it. OH configuration should be about how the device works with OH. In that case, OH could provide a useful UI for modifying modules configuration without any conflict with the OH configuration for text based configurations in exactly the same way as it does for UI configured things.
I can only assume that the issue is that things are either locked due to being configured in text or unlocked.
It seems to me that a simple solution would be for the module configuration parameters to be unaffected by the lock status of the thing.
+1 from me for allowing module changes when setup with files. It’s an absolute pain in the backside having to remove, discover, change. Plus then the problems now and again having to reheal etc afterwards.
I only used the ui for about a week after discovering openhab and switched straight to files as it’s far far easier to maintain, make changes, see an overview at a glance and backup/restore. I didn’t realise this was just a simple rejection of a PR (just thought it was some form of config restriction)
I’m astonished tbh , I’ve seen so many posts of changes not applying and it’s all because of files, jeez I’ve done it myself numerous times and wasted hours… then the light comes on… damn.
I don’t see that it would interfere in any way??
If you use the ui the config is there…
If you use text files the config is there…
Just separate the standard stuff such as nodeid from module stuff such as lifeline.
It’s actually my only gripe with the binding. Other than that big hat off to @chris as it’s the one binding I never have issues with
Why is that, what are you doing? Deleting a Thing, rediscover, give the same name so that all the old stuff reattaches seems straightforward. Where does healing come into it, this shouldn’t affect the network it’s just an openHAB procedure?
Obviously some channels might change/disappear/reappear because you have change device properties,but that seems the same in all cases.
Please note that this limitation is not anything to do with the binding. I have honestly tried to remove this limitation, and it was rejected. I can only apologise, but can’t do anything about it - the limitation is actually in the REST API.
Personally I don’t agree with Kai’s analysis. The Z-Wave handler already restarts if you update the .things file so that is the behaviour I expect. Moreover, if the UI updated the module configuration, the handler would not need to restart. So the thing Kai is trying to avoid already happens but wouldn’t happen on the scenario we want.
@chris we feel your pain. You have clearly invested a lot of time in creating a capable and stable binding, for which we are very grateful. It must be frustrating not to be able to make it work the way you and other users see it could.
Anyway just off to try something with a couple of modules, so two rounds of remove/discover/add/change/delete/restore coming up.
, I’ve seen so many posts of changes not applying and it’s all because of files, jeez I’ve done it myself numerous times and wasted hours… then the light comes on… damn.
)