-
Notifications
You must be signed in to change notification settings - Fork 779
Add support for properties on ItemChannelLinks #583
Comments
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. |
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? |
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 |
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. |
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 |
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.
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. |
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).
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.)
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 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. |
What I said is that "parts of the discussion" are in this issue.
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? |
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 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 😉 ).
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. |
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. |
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. |
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:
In #2343 I just made an proposal how existing 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. |
There is some ongoing work on such profiles here: #4108 |
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>
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>
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>
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:
On 2014-12-27 15:49:53 -0500, Kai Kreuzer wrote:
The text was updated successfully, but these errors were encountered: