Eclipse Community Forums: Eclipse SmartHome » discovery service overwriting existing item configuration

Home » Archived » Eclipse SmartHome » discovery service overwriting existing item configuration

discovery service overwriting existing item configuration [message #1721097]

Sat, 23 January 2016 12:32

Eclipse User

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 12:32] by Moderator

Re: discovery service overwriting existing item configuration [message #1721098 is a reply to message #1721097]

Sat, 23 January 2016 12:40

Eclipse User

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 08:18

Eclipse User

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 08:35

Eclipse User

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 13:11

Eclipse User

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 03:32

Eclipse User

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 12:00

Eclipse User

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 13:39

Eclipse User

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 03:16

Eclipse User

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 03:21

Eclipse User

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 05:50

Eclipse User

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 07:21

Eclipse User

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 13:49

Eclipse User

@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 07:34

Eclipse User

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 13:40

Eclipse User

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 13:43] by Moderator

Re: discovery service overwriting existing item configuration [message #1728386 is a reply to message #1728187]

Mon, 04 April 2016 02:31

Eclipse User

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:

-=] Back to Top [=-

Current Time: Wed Jul 23 13:25:22 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter