For the max! binding, I have the thermostats and so on configured in textual .things and.items files.
Now, every minute I get the following warnings in the openhab.log:
2016-05-28 16:25:18.242 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key max:thermostat:KEQ0565677:WZThermostat in ManagedThingProvider, because it does not exists.
2016-05-28 16:25:18.246 [WARN ] [.core.thing.binding.BaseThingHandler] - Error while applying configuration changes: 'IllegalStateException: Could not update thing max:thermostat:KEQ0565677:WZThermostat. Most likely because it is read-only.' - reverting configuration changes on thing 'max:thermostat:KEQ0565677:WZThermostat'.
As this is flooding the log file, it would be nice if either the max binding would stop trying to update the thing configuration if it is not possible, or if this would be somehow handled in the framework (make it DEBUG if it is expected behaviour?).
It is unexpected for me that a binding updates its own configuration - this is not really meant to happen. @marcel_verpaalen Do you have any input on why this is done here?
@Kai,
Indeed that is the purpose, these are configuration elements persisted in the device itself. I think what @kgoderis calls ‘transient’ configuration. So as the binding is loading, I update the configuration with the actual configuration of the device itself. Than once the user makes an update, I send the update to the device.
Same would be e.g. for the zwave binding where you update the device configuration through changes in the OH configuration. My intention with the MAX! binding is that there should be no need to use the manufacturing provided config tool, all can be done through OH. From new device inclusion to room naming and thermostat settings/configuration.
Question: is there indeed a way the binding knows whether it is a read-only thing or not. I am not aware of such a property that I can easily test and avoid this update when ro.
@dominicdesu,
Indeed I saw in your log this Warning, wanted to check into it as well. I never really used the definitions by text files, hence did not see this during my testing.
I think the reason that you see it again and again I can avoid. (meaning that if the updates fails, I will not re-try). As said above I’m not sure if I can avoid the initial warning as I can’t test for read-only things. Feel free to add an issue to GH to track it.
Well, for me it is fine for now. I switched to the approach of adding things through PaperUI and only have the item configuration in textual file, as this seems to be the better supported approach at the current stage of OH2.
Don’t know if it is worth investing your time fixing this as long as it is not clear how textual files will be handled in the future.
In addition to this, it is not only a question of changing a configuration but change the behaviour of the thinghandler in function of the characteristics or configuration of the physical thing, eg support more or less channels, etcetera and that for the purpose to minimise the number of different thing types for a binding since some hardware come in many many possible variations
