Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse SmartHome » config description(s) limitation
config description(s) limitation [message #1715885] Fri, 27 November 2015 09:45 Go to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 105
Registered: August 2014
Senior Member

Here just an example of a thing type XML.

  <thing-type id="thingTypeID">

...

    <supported-bridge-type-refs>
      <bridge-type-ref id="bridgeTypeID" />
      ...
    </supported-bridge-type-refs>

...

    <channel-groups>
      <channel-group id="channelGroupID" typeId="channelGroupTypeID" />
      ...
    </channel-groups>

...

    <config-description-ref uri="{binding|thing-type|bridge-type|channel-type|any_other}:bindingID:..." />

...

  </thing-type>


A thing type can reference to (use[d by]) multiple bridges.
A thing type could use multiple channel groups.
A thing type could have only one config description.

Why can a thing type use only one config description.

Example:
I have different thing types but all need to be configured with ip + username + password.
So I create a config description (uri = "thing-type:bindingId:access") that contains that information (similar to the Hue config desc. example in the doc).
This config description should be used by all my things.
If different things needs additional configuration, I would like to add another config description.

IMHO this is very similar to the channel-groups.
Is there any reasons, we don't like that?
Re: config description(s) limitation [message #1716049 is a reply to message #1715885] Mon, 30 November 2015 21:06 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 105
Registered: August 2014
Senior Member

The implementation of the XML processing is rather old (also the config-description-ref).

Quote:

commit 284e1115d9c06b6d898def99b563725ac5259231
Date: Fri Jul 4 15:00:59 2014 +0200

Initial contribution of xml-processing.


Michael Grammling or Alex Tugarev could you give me some informations?

[Updated on: Mon, 30 November 2015 21:07]

Report message to a moderator

Re: config description(s) limitation [message #1716356 is a reply to message #1716049] Thu, 03 December 2015 08:38 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Well, what you are asking for is inheritance of config descriptions, right?
The idea of the config descriptions is that there is a single uri that identifies it for a thing / thing type. So if you want to distribute the information across multiple files/definitions, you would have to assemble them in some way.
Nobody asked for this feature so far, that's why it isn't there. Usually, simply copying the parameters that are in common is a pragmatic approach to it.
Re: config description(s) limitation [message #1716358 is a reply to message #1716356] Thu, 03 December 2015 08:48 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 105
Registered: August 2014
Senior Member

I wouldn't nonce it "inheritance" but "reuse".

I would like to do what is possible for groups also for config descriptions.

I add an example:

Create three config descriptions.

The first one is a configuration that applies to all devices of that binding (access information for the device):
* <config-description uri="thing-type:bindingId:cfgaccess">

The other ones are configurations for the device specific parts:
* <config-description uri="thing-type:bindingId:cfgfoo">
* <config-description uri="thing-type:bindingId:cfgbar">

And the two thing types for the devices:

<thing-type id="foo">
  <config-description-refs>
    <config-description-ref uri="thing-type:bindingId:cfgaccess" />
    <config-description-ref uri="thing-type:bindingId:cfgfoo" />
  </config-description-refs>
</thing-type>


<thing-type id="bar">
  <config-description-refs>
    <config-description-ref uri="thing-type:bindingId:cfgaccess" />
    <config-description-ref uri="thing-type:bindingId:cfgbar" />
  </config-description-refs>
</thing-type>
Re: config description(s) limitation [message #1716359 is a reply to message #1716358] Thu, 03 December 2015 08:50 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
You would change a single ref to an array of references - this would break a lot of code throughout ESH and would complicate many things like e.g. the Paper UI, which would have to iterate itself (as a client!) through the descriptions, deal with merging them into a consistent set (how to deal with conflicts?) etc. This is nothing that we should put as a burden and responsibility on the clients, because everybody will do it differently in the end.
Re: config description(s) limitation [message #1716362 is a reply to message #1716359] Thu, 03 December 2015 09:07 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 105
Registered: August 2014
Senior Member

> You would change a single ref to an array of references - this would break a lot of code throughout ESH

Do you prefer to copy the content of cfgaccess to cfgbar and cfgfoo (and all the other decives)? I would prefer to add this feature to the framework instead of the creation of a lot of redundancy.
Another option is, that I do not use XML and generate the config description using code.

> would complicate many things like e.g. the Paper UI, which would have to iterate itself (as a client!) through the descriptions, deal with merging them into a consistent set (how to deal with conflicts?) etc

What is the difference between the mechanism for channels and this one?
The thing could contain an already merged set, the thing type could have an array.
Don't see the difference.

Re: config description(s) limitation [message #1716365 is a reply to message #1716362] Thu, 03 December 2015 09:26 Go to previous message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
> Do you prefer to copy the content of cfgaccess to cfgbar and cfgfoo (and all the other decives)?

Yes, since usually you will only have a handful of thing types and copying this information is not a big deal.

> Another option is, that I do not use XML and generate the config description using code.

This is definitely an option if you are dealing with large amounts of thing types.

> What is the difference between the mechanism for channels and this one?

With channels, the groups co-exist - every channel of every group is a channel on the Thing.
But if you have two config descriptions that both have a parameter "foo", you have a conflict that you need to resolve.


Previous Topic:ESH Binding
Next Topic:Using the Designer
Goto Forum:
  


Current Time: Wed Apr 24 17:34:20 GMT 2024

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

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

Back to the top