Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse SmartHome » discovery service overwriting existing item configuration
discovery service overwriting existing item configuration [message #1721097] Sat, 23 January 2016 17:32 Go to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
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 #1721098 is a reply to message #1721097] Sat, 23 January 2016 17:40 Go to previous messageGo to next message
John Cocula is currently offline John CoculaFriend
Messages: 20
Registered: June 2015
Junior Member
Once a user has accepted a discovered thing, it should not be subject to modification by any later discovery process, so I agree it's a bug.
Re: discovery service overwriting existing item configuration [message #1721173 is a reply to message #1721098] Mon, 25 January 2016 13:18 Go to previous messageGo to next message
Andre Fuechsel is currently offline Andre FuechselFriend
Messages: 28
Registered: December 2015
Junior Member

This may be related to the closed PR https://github.com/eclipse/smarthome/pull/716. It is a bug and should be fixed. Did you create an issue for it?
Re: discovery service overwriting existing item configuration [message #1721176 is a reply to message #1721173] Mon, 25 January 2016 13:35 Go to previous messageGo to next message
Andre Fuechsel is currently offline Andre FuechselFriend
Messages: 28
Registered: December 2015
Junior Member

Hmm, on a second thought this mechanism has been there for a while. Check https://github.com/chriskn/smarthome/blob/master/bundles/config/org.eclipse.smarthome.config.discovery/src/main/java/org/eclipse/smarthome/config/discovery/internal/PersistentInbox.java#L144, here the thing is updated with the discovered configuration.
Re: discovery service overwriting existing item configuration [message #1721214 is a reply to message #1721176] Mon, 25 January 2016 18:11 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
Messages: 59
Registered: September 2014
Member
thanks Andre,
You indeed found the place. It looks like it was there by design. Anyone knows in what sort of scenario this woud be useful?
In the mean time I'l create a PR to remove this piece of code, or if there are usecases, make it an optional rather than fixed behavior
Re: discovery service overwriting existing item configuration [message #1721260 is a reply to message #1721214] Tue, 26 January 2016 08:32 Go to previous messageGo to next message
Andre Fuechsel is currently offline Andre FuechselFriend
Messages: 28
Registered: December 2015
Junior Member

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 #1721340 is a reply to message #1721260] Tue, 26 January 2016 17:00 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 648
Registered: December 2011
Senior Member
As far as I remember, it was even André who implemented it initially (or at least participated in the design).
The reason for this feature (not bug) is simple: If a device dynamically changes its connection parameters, this needs to be reflected in the (already approved) thing. A good example (and where this is actively used) is a changing IP address due to DHCP reassignment. If the Thing is discovered through UPnP (i.e. the user never entered an IP address himself), the Thing must continue to work even if it is assigned a new address.
What we can discuss is if we should add new flags to configuration properties to mark whether they should not be modifiable through the user (we once had a read-only flag afair) or whether it should not be updated through discovery services.
Re: discovery service overwriting existing item configuration [message #1721632 is a reply to message #1721340] Thu, 28 January 2016 18:39 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
Messages: 59
Registered: September 2014
Member
thanks Kai,makes me understand the rationale.
Indeed that sounds like an understandable usecase.

So, I'll log an enhancement to address this, as I think in many other cases this will create problems.
Re: discovery service overwriting existing item configuration [message #1721686 is a reply to message #1721632] Fri, 29 January 2016 08:16 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
Messages: 59
Registered: September 2014
Member
For the implementation I suggest we add a new element to the config definition discoveryMode

where discoveryMode would represent something like
0 - Discovery service stops updating parameter once the Thing is accepted/created
1 - Discovery continues updating the parameter once the thing is accepted/created

hence the defintion becomes something like

 <parameter name="String" type="{text|integer|decimal|boolean}" min="Decimal" max="Decimal" step="Decimal" pattern="String" required="{true|false}" readOnly="{true|false}" multiple="{true|false}" groupName="String" unit="A|cd|K|kgv|m|mol|s|g|rad|sr|Hz|N|Pa|J|W|C|V|F|Ω|S|Wb|T|H|Cel|lm|lx|Bq|Gy|Sv|kat|m/s2|m2v|m3|kph|%|l|min|h|d|week|y" discoveryMode=1>
      <context>{network-address|password|password-create|color|date|datetime|email|month|week|time|tel|url|item|thing|group|tag|service}</context>
      <required>{true|false}</required>
      <default>String</default>
      <label>String</label>
      <description>String</description>
      <unitLabel>String</unitLabel>
      <options>
        <option value="String">String</option>
      </options>
      <filter>https://www.eclipse.org/forums/#
        <criteria name="String">String</criteria>
      </filter>
    </parameter>
  </config-description>
Re: discovery service overwriting existing item configuration [message #1721689 is a reply to message #1721686] Fri, 29 January 2016 08:21 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 648
Registered: December 2011
Senior Member
Nope, this does not work, since the ConfigDescription is completely unrelated to discovery (it is used within Rule Modules, Services, etc. as well). We should not introduce such a dependency here.
Re: discovery service overwriting existing item configuration [message #1727149 is a reply to message #1721689] Sun, 20 March 2016 09:50 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

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 #1727156 is a reply to message #1727149] Sun, 20 March 2016 11:21 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
Messages: 59
Registered: September 2014
Member

I think Markus idea is quite good, but may not aply to all situations. Hence I suggest to indeed change the logic to have by default the properties not updating, but for selected properties to indeed allow discovery to continue updating them.
As the earlier proposal (changing ConfigDescription) was not okay, I suggest the following solution.

We extend the DiscoveryResultBuilder.create(uid). with a new method 'withThingUpdatingPropertiesMap(<String,Object> properties)'
Only the properties in the withThingUpdatingProperties will indeed update an existing thing. The ones created with the regular DiscoveryResultBuilder withProperties(Map<String,Object> properties) & DiscoveryResultBuilder withProperty(String key, Object value) will not update an existing thing.

Re: discovery service overwriting existing item configuration [message #1727168 is a reply to message #1727156] Sun, 20 March 2016 17:49 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

@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 Go to previous messageGo to next message
Andre Fuechsel is currently offline Andre FuechselFriend
Messages: 28
Registered: December 2015
Junior Member

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 Go to previous messageGo to next message
Simon Kaufmann is currently offline Simon KaufmannFriend
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 Go to previous message
Andre Fuechsel is currently offline Andre FuechselFriend
Messages: 28
Registered: December 2015
Junior Member

Simon Kaufmann wrote on Thu, 31 March 2016 19:40
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.


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?
Previous Topic:Bug with rules
Next Topic:Cooperation with other alliances
Goto Forum:
  


Current Time: Tue Jun 19 11:02:22 GMT 2018

Powered by FUDForum. Page generated in 0.03396 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top