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

Search

Help

Login

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

Show: Today's Messages :: Show Polls :: Message Navigator

Switch to threaded view of this topic

Create a new topic

Submit Reply

discovery service overwriting existing item configuration [message #1721097]

Sat, 23 January 2016 17:32

Marcel Verpaalen is currently offline

Marcel Verpaalen

Friend

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

John Cocula is currently offline

Friend

Messages: 21
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.

Report message to a moderator

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

Mon, 25 January 2016 13:18

Andre Fuechsel is currently offline

Friend

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?

Report message to a moderator

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

Mon, 25 January 2016 13:35

Andre Fuechsel is currently offline

Friend

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.

Report message to a moderator

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

Mon, 25 January 2016 18:11

Marcel Verpaalen is currently offline

Marcel Verpaalen

Friend

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

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

Andre Fuechsel is currently offline

Friend

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.

Report message to a moderator

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

Tue, 26 January 2016 17:00

Kai Kreuzer is currently offline

Friend

Messages: 673
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.

Report message to a moderator

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

Thu, 28 January 2016 18:39

Marcel Verpaalen is currently offline

Marcel Verpaalen

Friend

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.

Report message to a moderator

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

Fri, 29 January 2016 08:16

Marcel Verpaalen is currently offline

Marcel Verpaalen

Friend

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>

Report message to a moderator

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

Fri, 29 January 2016 08:21

Kai Kreuzer is currently offline

Friend

Messages: 673
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.

Report message to a moderator

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

Sun, 20 March 2016 09:50

Markus Rathgeb is currently offline

Friend

Messages: 105
Registered: August 2014

Senior Member

maggu2810@jabber.ccc.de

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.

Report message to a moderator

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

Sun, 20 March 2016 11:21

Marcel Verpaalen is currently offline

Marcel Verpaalen

Friend

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.

Report message to a moderator

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

Sun, 20 March 2016 17:49

Markus Rathgeb is currently offline

Friend

Messages: 105
Registered: August 2014

Senior Member

maggu2810@jabber.ccc.de

@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...

Report message to a moderator

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

Thu, 31 March 2016 11:34

Andre Fuechsel is currently offline

Friend

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?

Report message to a moderator

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

Thu, 31 March 2016 17:40

Simon Kaufmann is currently offline

Friend

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

Andre Fuechsel is currently offline

Friend

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?

Report message to a moderator

Switch to threaded view of this topic

Create a new topic

Submit Reply

Previous Topic:	Bug with rules
Next Topic:	Cooperation with other alliances

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 16:35:46 GMT 2024

Powered by FUDForum. Page generated in 2.07227 seconds

.:: Contact :: Home ::.

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

Back to the top