Home » Archived » Eclipse SmartHome » Update configuration information to an object
| Update configuration information to an object [message #1693564] |
Sat, 25 April 2015 11:31  |
 Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
I'd like to propose a change to the way configuration information is provided in the REST interface. Currently it is just sent as a string/int, but I'd like to propose to change this to an object to allow for future enhancements/metadata to be added to a configuration value.
As an example use case, in the ZWave binding in OH1, I mark some configuration parameters as 'pending' when the user updates them, but they aren't yet updated on the device. This is very useful since in ZWave, and I suspect other RF systems, the binding can't immediately send the data to the device - it can take up to 1 day to send the data (depending on how the user has configured the device - mostly it's 1 hour). Without the pending flag, it's very confusing to users who don't understand the detail of the protocol - they think they've updated the device, but it's not working.
This is just one example - I'm sure other use cases will come along, so I'd propose to change the interface to an object... This would allow future enhancements without breaking UIs.
Any thoughts from anyone?
Chris
|
|
| |
| Re: Update configuration information to an object [message #1693570 is a reply to message #1693567] |
Sat, 25 April 2015 12:10  |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Dennis Nobel wrote on Sat, 25 April 2015 07:44
which interface do you mean exactly? The configuration interface/class? The REST interface exposes more a less the Java API, so it would also need a change there.
Yes, of course, that is what I meant - sorry - I did't just mean to change the REST interface, but the underlying data.
Dennis Nobel wrote on Sat, 25 April 2015 07:44
Changing method signatures to more abstract classes like Object may prevent API breaking changes, but you also loose type information. If the return type of a method is Object, what should the developer expect?
Shouldn't they expect the return type that is specified in the parameter configuration, that was originally specified by the developer? The type is defined already in the ThingType.configParameters.type field.
Personally, I don't think that ESH should assume that the REST client has returned the right type since JSON doesn't provide strong typing and different clients might interpret values differently. In any case, what I propose is to put the current value inside the object so that any such information is still available - it's not changing this, it's just moved inside an object rather than being the only, such that this has the possibility to expand.
Dennis Nobel wrote on Sat, 25 April 2015 07:44
For your concrete use case with pending configuration we introduced a ThingStatusDetail named CONFIGURATION_PENDING
Ok, this is useful, but in my opinion it would still be useful to know what parameters have been transfered to the device, and which are still waiting. Since this PENDING flag is on the thing, it is not possible to tell this, just that the thing is not fully initialised. Using your example we might end up with the thing always showing in a CONFIGURATION_PENDING state if someone is updating a parameter regularly...
Dennis Nobel wrote on Sat, 25 April 2015 07:44
The thing object (including the configuration) can be seen as a contract between the binding and the the framework, and this contract must be as accurate as possible, so that the binding knows what it can get from the UI and vice versa.
I don't disagree - I'm not proposing that we make this a free for all - ie something that users can put anything they like into - it would simply allow us to expand the interface at a later date which is currently not possible now with a single value being returned.
Maybe I wasn't clear earlier - what I would propose is simply the following (looking at this from the json level) -:
Currently we have -:
thing.configuration {parm1: val1, parm2: val2}
I would simply propose that this is
thing.configuration [{config: 'parm1', value: val1},{config: 'parm2', value: val2}]
such that in future, we could add other attributes to the object without breaking the interface - eg -:
{config: 'parm1', value: val1, status: 'PENDING'}
Chris
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:47:11 GMT 2024
Powered by FUDForum. Page generated in 0.03408 seconds |
] 
Search
Help
Register
Login
Home
