Skip to content
This repository has been archived by the owner on May 7, 2020. It is now read-only.

Add support for properties on ItemChannelLinks #583

Closed
kaikreuzer opened this issue Dec 3, 2015 · 13 comments · Fixed by #4323
Closed

Add support for properties on ItemChannelLinks #583

kaikreuzer opened this issue Dec 3, 2015 · 13 comments · Fixed by #4323

Comments

@kaikreuzer
Copy link
Contributor

migrated from Bugzilla #456213
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2014-12-27 03:59:13 -0500, Gerhard Riegler wrote:

A item should have item properties. Let's say a DateTime channel is bound to two items, but for the second item the user wants a item specific offset from the channel DateTime value. This implies, that there should be a possibility to update the state item specific too or, maybe the better way, a callback method in the ThingHandler for each item which is updated with the item properties to have a chance to manipulate the state before it is published to the bus.

On 2014-12-27 15:49:53 -0500, Kai Kreuzer wrote:

Not the item should have these properties, but the ItemChannelLink (since the configuration can be specific for each channel an item is linked to).

@watou
Copy link
Contributor

watou commented Mar 6, 2016

Many OH1 bindings retain a copy of the bound item's acceptedDataTypes list, so when data arrives, the binding can create an acceptable state with which to update the item. In some cases the binding has no knowledge of the intended type other than the list of accepted types for the item. In ESH currently, such a binding would have to define duplicate channels for every possible type. If the ItemChannelLink knew the linked item's accepted data types and imposed no other constraint, bindings like these could be written for the ESH model without creating duplicate channels for every possible type.

@cdjackson
Copy link
Contributor

I would argue that for the stated example above at least, that the conversion should be provided by a middle layer rather than in the binding. I'm not sure where in the system translations sit these days, but I would argue that the binding should provide data in some format (or formats) and it shouldn't be modified each time a user wants a new conversion. I would suggest that such conversions are performed outside of the binding, so that they are (possibly) more user definable, and in any case are available to all bindings/items.

Maybe the above example doesn't represent all possible use cases for this, and maybe there's still a case for passing properties into the binding, but maybe it's not needed?

If we start passing properties (configuration?) from an item, then I assume we also need a configProvider for items?

@watou
Copy link
Contributor

watou commented Mar 7, 2016

That sounds right to me. Bindings should not have to be concerned with the various State types that satisfy the receiving items. See my comment here. Bindings should just call updateState(channel, boolean) or updateState(channel, String), etc., and it's then the channel's job to satisfy the linked item's accepted data types. This would simplify bindings and shift the job of satisfying linked items' accepted types to lower layers.

@kaikreuzer
Copy link
Contributor Author

The idea of the "conversions" sound pretty similar to what I had in mind with "profiles" for the new trigger channels in #1043, so we can probably come up with a solution that fits in both cases. The idea there was also that the binding has some defined output (PRESSED/RELEASED) and the link refers to a certain profile of how this is translated to ON/OFF or whatever.

@watou
Copy link
Contributor

watou commented Mar 8, 2016

Yet another way of looking at it: Make the item type of a channel type optional, so that channels are not required to only feed items of a pre-selected type (or set of types). While the current ESH model works well for many bindings, it completely fails for addressing bindings like MQTT, where all MQTT messages are strings, and the binding author has no idea which item types are appropriate. It also fails for bindings that provide different values depending on the destination's accepted data types (like the 1.x Astro binding. The 2.x Astro binding is missing the flexibility of the 1.x binding, perhaps for this reason.)

As a binding developer, I would love to be able to throw an Integer or Boolean at updateState, and leave the work to the channel to convert it as needed to the various linked item(s). This would simplify binding development, and remove required knowledge from each binding and centralize it. A model for converting standard JDK types to various States could vaguely resemble the PropertyUtils converter, where the channel type would have a default converter to convert types (String, Integer, Boolean, Calendar, etc.) to States. The greater benefit is that ESH bindings could be even further ignorant of core ESH States and item types, and result in more flexibility when new item and state types are added later. Bindings could also override these default conversions as and if needed, even adding their own private types for conversion to States.

@kaikreuzer
Copy link
Contributor Author

completely fails for addressing bindings like MQTT

This is because MQTT is a transport and it does really make sense to talk about a binding here. For the same reason, I never supported creating a serial or an http binding based on the new ESH APIs.

The 2.x Astro binding is missing the flexibility of the 1.x binding

If you read above, you will see that this issue here is exactly about the astro binding requirements. But the problem is not that it clearly specifies an item type (DateTime in this case), but that it needs some additional configuration for the link to the item.

I'd suggest to keep the scope of this issue on this: Supporting additional properties (resp. profile) on links.

@watou
Copy link
Contributor

watou commented Mar 8, 2016

This is because MQTT is a transport and it does really make sense to talk about a binding here.

I am referring to the openHAB 1.x MQTT Binding, which is still referred to as a binding in openHAB 2 and performs similar results to ESH bindings (except not on this point).

For the same reason, I never supported creating a serial or an http binding based on the new ESH APIs.

OK, but if it's been decided that that class of binding cannot be implemented using the ESH APIs, it would probably be helpful to document that for binding developers coming from openHAB 1.x, so they don't start with incorrect assumptions about what can be done using the ESH APIs. (Sorry if it is documented but I didn't see it.)

the problem is not that it clearly specifies an item type (DateTime in this case), but that it needs some additional configuration for the link to the item.

Would it not make sense to be able to link an astro channel to a Switch item, similar to OH1, instead of the binding author deciding that the one item type must be a DateTime? Maybe the Astro 2.x binding just needs a new channel type for switches instead of more configuration data in a different place?

I'd suggest to keep the scope of this issue on this: Supporting additional properties (resp. profile) on links.

I thought you meant to move the discussion here from the forum. 😄 But since this is different from #1043, should I open a new issue to request that the ESH APIs be expanded so that bindings can update items types determined at runtime based on context, similar to what OH 1.x bindings can do, or do you think this will never be a feature of the ESH APIs? Thanks.

@kaikreuzer
Copy link
Contributor Author

I thought you meant to move the discussion here from the forum.

What I said is that "parts of the discussion" are in this issue.

should I open a new issue to request that the ESH APIs be expanded so that bindings can update items types

Bindings can dynamically provide channels, so depending on the setup, they can already adapt their item types - but once it is determined for a channel, it should not change anymore (wouldn't we have severe problems if at one moment you receive a number and at another you receive a string or boolean value through MQTT)? So what exactly speaks against dynamic channels?

@watou
Copy link
Contributor

watou commented May 9, 2016

The use case that is met by several OH 1.x bindings is that, only the end user knows what type of item is appropriate for a particular input. The binding developer has no way of knowing. In these 1.x bindings, the accepted data types* for the bound item are saved during AbstractGenericBindingProvider.processBindingConfiguration(context, item, bindingConfig). Then, when it's time to update the item, the binding finds/creates an acceptable State object.

No additional configuration information is created that would in any way constrain the user from later editing his .items file and changing the item's type. The binding provider then goes through the above steps as usual, and further updates would now be sensitive to the new item type.

Also picture the case where a 1.x binding allows the user to define transformation of inputs from something odd like "ONE" and "TWELVE" into 1 and 12, which is then acceptable for Number items. Again, the binding developer has no visibility to the user's inputs or desired item types.

If there were a "clean" equivalent in ESH for bindings to address this use case, the gap would be closed (I think 😉 ).

So what exactly speaks against dynamic channels?

Do dynamic channels address what is described above? Sorry I don't know already.


*or, less flexibly, but still common, is saving the item type's class and using a hardcoded mapping of item types to accepted data types in the binding code.

@cdjackson
Copy link
Contributor

So what exactly speaks against dynamic channels?

Do dynamic channels address what is described above? Sorry I don't know already.

Dynamic channels allow the BINDING to choose a channel based on the data it provides - it doesn't however address the issue where the USER needs to change the data type.

Do, nothing speaks against dynamic channels in that they are also necessary, but the problem is still the same as with static channels - there's no way for the binding to know the data type so that it can provide the correct sate.

In short, both dynamic channels, and some mechanism for the binding to know data type are required. Or, the binding could alternatively provide an array of states, and then leave it to ESH to provide the most relevant state for the item type.

@kaikreuzer
Copy link
Contributor Author

I'd suggest to keep the scope of this issue on this: Supporting additional properties (resp. profile) on links.

I think we should stick to this, otherwise we completely flood this issue. I feel we are discussing quite many different requirements here at the same time (binding config, user config, transformations, multiple links, etc.) If you think that you have an isolated requirement and a clear suggestion on how to implement it, please create a separate issue. Otherwise, it is probably best to continue first at https://www.eclipse.org/forums/index.php?t=msg&th=1077227.

@sjsf
Copy link
Contributor

sjsf commented Oct 20, 2016

Dynamic channels allow the BINDING to choose a channel based on the data it provides - it doesn't however address the issue where the USER needs to change the data type.

That's only partially right - considering that the user also can define channels... So if the level of abstraction is right (i.e. server <-> Thing, topic <> Channel), then something like this would be possible:

Thing mqtt:mqtt:myFancyThing [ server="127.0.0.1" /* ... */ ] {
    Channels:
        String : aStringChannel [ topic="my/smarthome/text" ] 
        Number : aNumberChannel [ topic="my/smarthome/number" ]
        Switch : aBooleanChannel [ topic="my/smarthome/boolean" ]  
}

In #2343 I just made an proposal how existing ChannelTypes can be referenced in such manual channel definitions, making it easier for bindings to define what can be expected. This would give bindings also the chance to have different kind of Number channels, with maybe different conversion strategies (or whatever other use-cases you might come up with) by distinguishing the ChannelTypeUIDs.

IHMO the MQTT use-case @watou brought up should be covered already as of today by this kind of manually defined channels. Or am I missing something?

Still, the properties on ItemChannelLinks remains valid for other cases like e.g. the offset in the astro binding.

@triller-telekom
Copy link
Contributor

There is some ongoing work on such profiles here: #4108
However, these profiles are not configurable at the moment.

sjsf pushed a commit to sjsf/smarthome that referenced this issue Sep 22, 2017
This allows adding some configuration properties onto links, e.g. though

  Switch someItem {
      channel="a:b:c:channel" [
          foo="bar",
          answer=42,
          always=true
      ]
  }

or the REST API.

As a consequence, ItemChannelLinks now also can be updated through the REST API.

fixes eclipse-archived#583
Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>
sjsf pushed a commit to sjsf/smarthome that referenced this issue Sep 22, 2017
This allows adding some configuration properties onto links, e.g. though

  Switch someItem {
      channel="a:b:c:channel" [
          foo="bar",
          answer=42,
          always=true
      ]
  }

or the REST API.

As a consequence, ItemChannelLinks now also can be updated through the REST API.

fixes eclipse-archived#583
Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>
kaikreuzer pushed a commit that referenced this issue Sep 28, 2017
This allows adding some configuration properties onto links, e.g. though

  Switch someItem {
      channel="a:b:c:channel" [
          foo="bar",
          answer=42,
          always=true
      ]
  }

or the REST API.

As a consequence, ItemChannelLinks now also can be updated through the REST API.

fixes #583
Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants