discovery service overwriting existing item configuration [message #1721097] |
Sat, 23 January 2016 17:32 |
Marcel Verpaalen Messages: 59 Registered: September 2014 |
Member |
|
|
Due to a recent reported issue I found that there is unexpected behavior in the discovery of already accepted items. If an thing is found again in the discovery, it will update the already accepted thing configuration parameters with the values as defined during the discovery.
I would think that is conceptional not the right approach. This way somehow the discovery should be made aware of all the changes.
I would assume that discovery does what it says: discovery. From that point onwards it is up to the user to update the configuration in either the binding or via the UI. It would be very hairy if we mix these.
There are several examples, e.g. in the ntp binding, the locale is set for the discovered item. However if it is updated by the user, at the next start of the binding the local item is discovered again and reset to the initial value
I think there will be many other examples as well where values set during discovery will be updated by the user later onwards. (same thing for e.g. the yahoo binding, I updated the location ID, to the one better reflecting my location, but it got changed back by discovery...not what I want)
I would consider this a bug, but wanted to hear the opinion of others as well.
[Updated on: Sat, 23 January 2016 17:32] Report message to a moderator
|
|
|
|
|
|
|
Re: discovery service overwriting existing item configuration [message #1721260 is a reply to message #1721214] |
Tue, 26 January 2016 08:32 |
|
I could imagine, that this behavior might be useful in cases, where the ESH installation is offline / not running and when it comes online again the discovery finds the devices again and updates their internal thing and item representation according to the device's current settings. But this sounds rather strange as this should be handled by the respective binding's ThingHandler. Please create at least an issue for that.
|
|
|
|
|
|
|
Re: discovery service overwriting existing item configuration [message #1727149 is a reply to message #1721689] |
Sun, 20 March 2016 09:50 |
|
I don't think the configuration should be updated by the discovery service for already approved things.
Your (Kai) example is valid, but I don't think it should be solved by updating the configuration.
I would prefer if the configuration contains the information that it should connect to "not IP" but "some information found by jUPnP".
So the configuration keeps the same but the way the connection is established uses an abstraction.
Similar as it is done by hostnames (that could be resolved by a system wide mDNS or by a well defined nameserver). The configuration does not need to be updated if a hostname instead of a IP is inserted and the IP address of the hostname changed.
|
|
|
|
Re: discovery service overwriting existing item configuration [message #1727168 is a reply to message #1727156] |
Sun, 20 March 2016 17:49 |
|
@marcelrv To differ the properties (update existing thing / don't update existing thing) seems like a possible way to go.
But I still don't feel happy if a configuration is changed automatically.
The user can change the IP address configuration and that change is overwritten by the discovery service later.
So, if the configuration is overwritten by the discovery service, there is no need that the user can set it manually.
If the user can set such stuff manually, it should not be overwritten by the discovery service.
If I want to use jUPnP information to establish a connection, then the thing configuration should contain the information that is used for the connection. I could create a thing and setup an IP, then this IP should be used. I could create a thing and setup a hostname, then the hostname should be used. I could create a thing and setup a service that is resolved by DNS-SD / mDNS... But set an IP address manually and the framework overwrites it later...
|
|
|
Re: discovery service overwriting existing item configuration [message #1728149 is a reply to message #1727168] |
Thu, 31 March 2016 11:34 |
|
Following this discussion I would also opt for having the discovery to not update an already created thing. Still I have no good feeling about your suggested implementations. Where should a a map of the properties to be updated come from? Is a bindning developer able to make this differentiation? Should we restrict it only to properties used to establish a connection? Which ones? How to?
|
|
|
Re: discovery service overwriting existing item configuration [message #1728187 is a reply to message #1728149] |
Thu, 31 March 2016 17:40 |
Simon Kaufmann Messages: 51 Registered: January 2011 |
Member |
|
|
I would like to point out that the discovery only overrides properties that it actually _can_ detect automatically from the "environment". The fact that we can discover and preconfigure Things by magic actually is quite valuable, and the same applies for changing environments: If e.g. a Hue Bridge gets a new IP address, the user must not take care about it. And we should not change this behavior in general.
We should make sure that we don't introduce some fancy special handling just for this location example (which by the way has a working solution to create a Thing manually, but I of course understand that this is not the point here...). Do you see any other concrete examples where this is an issue?
[Updated on: Thu, 31 March 2016 17:43] Report message to a moderator
|
|
|
Re: discovery service overwriting existing item configuration [message #1728386 is a reply to message #1728187] |
Mon, 04 April 2016 06:31 |
|
Simon Kaufmann wrote on Thu, 31 March 2016 19:40I would like to point out that the discovery only overrides properties that it actually _can_ detect automatically from the "environment". The fact that we can discover and preconfigure Things by magic actually is quite valuable, and the same applies for changing environments: If e.g. a Hue Bridge gets a new IP address, the user must not take care about it. And we should not change this behavior in general.
I agree but we cannot just mark such properties as read-only, as the user must be able to provide the ip address manually in case discovery fails for some reason. If we would just prevent the user to enter an IP address as it can be changed by the discovery at any time, how could a user provide an address manually?
|
|
|
Powered by
FUDForum. Page generated in 0.07783 seconds