Sorry, I don’t really have any options. Maybe the Zensys software can do it.
I apologise for this, but it’s a decision that was made in ESH not to support this through the current config mechanism so unfortunately the configuration updates don’t even get passed to the binding when the things are defined in a text file .
It means that it’s not possible to configure things if they are defined in the text files… I know there’s a proposal to allow configuration of devices, but currently there is nothing available.
Err, no. It means that things in text files are configured through text files.
So @sipvoip should be able to define the PIR timeout in the Thing configuration in the things file and the binding should use this setting (and configure the remote device accordingly, if not already done).
Yes, you are right, but the consequences of this would mean that the binding would need to send ALL configuration to ALL devices when it starts in order to fulfil this.
We have discussed this in the past, but to explain this some more -:
Given that many devices have between 10 and 50 configuration parameters and many people have 60 to 100 devices, this would mean thousands of additional transactions which would really slow down the initialisation.
For this reason I don’t think it is a good idea to implement a system that reconfigures all parameters on startup.
Additionally some parameters are there to reset the device or make major changes and these must only be sent when really required.
@kai I was wondering if you had any further thoughts on handling this? I don’t think it’s possible for the binding to know if a config value is configured manually or not so I can’t see any easy way around this other than to send all configuration values on startup, and as above I think this is a really bad thing to do.
I’m open to thoughts on how to resolve this if you have any…
Well, I think this is pretty much related to this issue. We are talking here about a device configuration and I agree that it does not make much sense to send those out to the devices on every startup.
I would actually also claim that if someone configures his system statically/textually, the startup should not mess with the surrounding devices, but rather consider them to be pre-setup already.
Maybe we could think of some “configure device on startup” feature in issue #3484, but for now I would agree that those parameters are better not at all used in a textual configuration.
@sipvoip Could you live with that? Or what would be your current expectation of how the binding should behave if you have values set in your things file?
The only “path in the middle” that I would say is to have the binding check whether some value is out of sync and only set it, if it sees that the local config contains a different value than the device. Whether this is feasible (not sure if and how often you might get those values from the devices?) is probably something @chris can answer best.
Technically, this is possible, but it will result in every parameter being reset to defaults if it was previously configured…
The config description will be reset to the default values when a thing is added - the binding can then read the configuration of the device, and it could check if it’s different, and then configure it. But it means that any previous configuration would be reset to default values, so if someone is using other software to configure devices (such as the Zensys tool that is used by some) then it will be reconfigured.
Also, if the database is configured incorrectly (always a possibility) and then we end up with the device configuration in a bit of a mess.
So, I don’t really think this is a good thing to do.
I’m still not really sure why we shouldn’t allow the configuration to be updated in a thing, even if it’s not a managed thing? I know you said that the fact that the configuration is not persisted will confuse people, but I think if people are manually configuring their things, then they could be considered “advanced users” and therefore smart enough to work this out . I think this is a useful feature (forgetting device configuration completely) as it allows users using text configuration to adjust their system in the UI, find the right configuration for them, and then update their text files.
Also, I think currently there is no way for a user to update configuration without reinitialising the thing since I believe the thing will be reinitialised when the text files are updated (right?).
Will do - I don’t know that I would expect it super soon, but maybe in a month or so by the time the ESH changes are added, then the binding is updated.
Keep an eye on the issue that Kai referenced above.
.
.