| properties vs config in DiscoveryResultBuilder [message #1694593] |
Wed, 06 May 2015 13:48  |
 Marcel Verpaalen
Messages: 59
Registered: September 2014 |
Member |
|
|
Seems the with the addition of real properties support the DiscoveryResultBuilder has bit of strange/inconsistent way of setting things.
The withProperties actually does not set the propeties but it sets configuration. There is currently no way to sset the properties outside of the name property, which is defined with the .withLabel
Wouldn't it be better to rename the .withproperties to .withconfiguration, and allow the withproperties to actually set the property. note that this would break existing bindings,
e.g.
Map<String, Object> properties = new HashMap<>(2);
properties.put(MaxBinding.IP_ADDRESS, IpAddress);
properties.put(MaxBinding.SERIAL_NUMBER, cubeSerialNumber);
ThingUID uid = new ThingUID(MaxBinding.CUBEBRIDGE_THING_TYPE, cubeSerialNumber);
if (uid != null) {
DiscoveryResult result = DiscoveryResultBuilder.create(uid).withProperties(properties)
.withLabel("MAX! Cube LAN Gateway").build();
thingDiscovered(result);
I would also suggest we update the descriptions to so we add configuration
/**
* Adds a property to the desired result
*
* @param property of the desired result
* @return the updated builder
*/
public DiscoveryResultBuilder withProperty(String key, Object value) {
this.properties.put(key, value);
return this;
}
|
|
|
|
| Re: properties vs config in DiscoveryResultBuilder [message #1694730 is a reply to message #1694692] |
Thu, 07 May 2015 12:43  |
Marcel Verpaalen
Messages: 59
Registered: September 2014 |
Member |
|
|
Personally I don't like the current difference between a property and configuration. The key difference is in whether the user can update it or not, and if it should be persisted or not.
In other words, it is not so clear whether we are talking smarthome configuration or physical thing configuration.
e.g. take the serial number, it now is defined as a configuration, as it is they key on how a thing is uniquely identified and you want to be able to 'configure' it through the interface when manually adding a new Thing. However, the serialnumber obviously is not something you actually want to 'configure'/change on the device. Result of it is now in ESH we have it both as configuration as well as property.
This indeed is even the case for an IP address, which is something you want to configure manually because you need to inform the binding what ip to use, but the physical device maybe wants to have only the configuration if the IP is static or dynamic, and the IP it gets is actually a property of latest DHCP results.
Also when I look at the properties in ESH I think they are currently too simplistic, meaning that similar to the configuration I would like to have it context or grouping, label, description etc so that it can properly be displayed in the UI. Obvious this can all be copied to the properties logic, but I feel we then are duplicating lot of logic, instead of giving maybe one or two additional options to a configuration to determine whether it is a configuration or property in the current sense of ESH
wrt your last remark, I think there is no need to have a sync from properties i into Things automatically (if there is an updated discovery result) . I think in the very specific case where properties are changing, the Thinghandler should identify/update that rather than using discovery for that purpose
|
|
|
|
|
| Re: properties vs config in DiscoveryResultBuilder [message #1694835 is a reply to message #1694785] |
Fri, 08 May 2015 11:26 |
Marcel Verpaalen
Messages: 59
Registered: September 2014 |
Member |
|
|
Kai,
What I would suggest then is keep properties extremely limited, indeed just for very limited set of predefined values. Then these few can then be nicely rendered etc, and no need for extensive additional features around the update logic/information to the framework etc.
For all my other ones I think I'll use the suggestion of Chris, as I do think we want to give them proper readable names (parameters currently are only camelcase names) , grouping etc.
I see for the MAX! binding many similarities to what Chris has done for zwave in openhab.
There are certain grouped sets of parameters, part of them read-only, others changeable and controlling the device behavior.
For the MAX! binding, I'm close to finishing the display of all changeable parameters. After completion of that I'll will start create the logic to actually make the configuration updates through the UI and configure the devices without the need for the vendor application.
[Updated on: Fri, 08 May 2015 14:31] Report message to a moderator |
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04289 seconds
] 
Search
Help
Register
Login
Home
