Eclipse Community Forums: Eclipse SmartHome » Allow channels without item type

Help

Home

Home » Archived » Eclipse SmartHome » Allow channels without item type

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

Allow channels without item type [message #1731551]

Fri, 06 May 2016 17:51

Marcel Verpaalen

Messages: 59
Registered: September 2014

Member

One of the challenges I see with esh/oh2 I'd that a channel ties to a specific item type.
This is mostly fine for physical world, but tricky for interfaces.

E.g mqtt binding is not aware of what is the item type of a channel. Same fir example the snmp binding. In oh1 the binding solve that by trying to convert to various datatypes.

In oh2 this approach does not seem to work.
Would it be an idea to allow channel tool be defined without a type, our create some special 'accept all types' type.

Our, can anyone recommend a good way tho accomplish this.

See also an example here. https://community.openhab.org/t/conversion-from-string-item-to-number-item/10363/5

Report message to a moderator

Re: Allow channels without item type [message #1731553 is a reply to message #1731551]

Fri, 06 May 2016 18:13

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

For reference, there was a similar discussion on the openHAB forum about exposing item types to the bindings to solve this sort of problem.

https://community.openhab.org/t/map-transform-for-zwave-items/8349/24

Report message to a moderator

Re: Allow channels without item type [message #1731566 is a reply to message #1731553]

Fri, 06 May 2016 20:04

Marcel Verpaalen

Messages: 59
Registered: September 2014

Member

I see, indeed same discussion. I'm quite supportive of your proposal there.
Likewise here:
https://github.com/eclipse/smarthome/issues/583

Dunno the best location tho have the discussion, but would be great to agree on a way forward.

The way I'm trying to solve it currently in the oh2 mqtt binding is having a channel configuration that has the output type.
The idea I'd that if it is changed, I actually change the channeltype in the background.
It is a very cumbersome way I must say.

Report message to a moderator

Re: Allow channels without item type [message #1731667 is a reply to message #1731566]

Mon, 09 May 2016 06:59

Kai Kreuzer

Messages: 673
Registered: December 2011

Senior Member

> One of the challenges I see with esh/oh2 I'd that a channel ties to a specific item type.
> This is mostly fine for physical world, but tricky for interfaces.

I am wondering if the use case is then really a "binding" (south side) and not rather an exposing ESH (north side) to an external system. See also https://github.com/openhab/openhab2-addons/pull/21#issuecomment-215410150.

For a Thing, I still think that it makes sense that the binding clearly declares what functionality it offers and not to shift it all to a best-effort behaviour ("trying to convert to various datatypes") during runtime.

> create some special 'accept all types' type.

What implications would that have on the existing APIs/bindings? If you then have 3 items bound with different types, how would you send the updates to them? This looks all very complicated to me.

Report message to a moderator

Re: Allow channels without item type [message #1731745 is a reply to message #1731667]

Mon, 09 May 2016 18:33

Marcel Verpaalen

Messages: 59
Registered: September 2014

Member

I don't know for others, but in my case most of my integration is done via mqtt. You may call that a transport, but the mqtt binding is the one exposing all the things that OH has no bindings for (e.g. solar logging, electricity metering, water & gas metering, control water valves, control non-standard lighting, alarm system etc)

If that is no longer considered a binding... than what is it. The mqtt transport layer is already defined, I think similar to the serial binding it is more of a background service than something the user will interact with. Hiding some of the complexities of the mqtt protocol.

I think that the solution watou posted on the forum is certainly better than my proposal: let the ESH framework deal with proper conversions rather than each binding. So depending on what itemtype is linked, the framework will try to convert into the linked item. That also solved the problem what to do when multiple itemtypes are linked to a channel.
In that case e.g. the mqtt binding would simply expose a string channel, and if the user wants to have number or switch item controlled by it, he/she links such an item type, and get's the data delivered according to the item type.

Report message to a moderator

Re: Allow channels without item type [message #1731751 is a reply to message #1731745]

Mon, 09 May 2016 19:16

Kai Kreuzer

Messages: 673
Registered: December 2011

Senior Member

> it is more of a background service than something the user will interact with

Yes, so you seem to agree that the concept of a Thing, which represents an external (usually physical) device with certain features, does not match here at all - it is rather an extended event bus with its own very specific configuration to get it working.
I simply think that we should not try to press it into the Thing concept, if it only makes stuff more complex for all others. I also wonder, if there needs to be any UI support for such a "technical" feature. It seems rather better to be compared to the REST API (which also allows integration with "all for which there is no binding") or e.g. the HomeKit integration (https://github.com/openhab/openhab2-addons/tree/master/addons/io/org.openhab.io.homekit).

But let's stick to the Things for another moment, because I am still not sure I have grasped the whole problem.

> the mqtt binding would simply expose a string channel, and if the user wants to have number or switch item controlled by it, he/she links such an item type

So why doesn't the user directly define a Thing with a number or switch channel? Why does it have to be a string channel in the first place?

Maybe it is not clear that it is not only the binding, which can define channels of a Thing, but also the user, see https://www.eclipse.org/smarthome/documentation/features/dsl.html#defining-channels.
So you can simply define an MQTT Thing with channels for your solar logger, meter, valves, etc. and link the according items to these channels - all would be type safe and would fit nicely into the current architecture.

Report message to a moderator

Re: Allow channels without item type [message #1731754 is a reply to message #1731751]

Mon, 09 May 2016 21:23

Marcel Verpaalen

Messages: 59
Registered: September 2014

Member

Kai Kreuzer wrote on Mon, 09 May 2016 21:16

>

Maybe it is not clear that it is not only the binding, which can define channels of a Thing, but also the user, see https://www.eclipse.org/smarthome/documentation/features/dsl.html#defining-channels.
So you can simply define an MQTT Thing with channels for your solar logger, meter, valves, etc. and link the according items to these channels - all would be type safe and would fit nicely into the current architecture.

Indeed this is unknown to me.I'll give that a try and see how it works. It may just solve the issue.

[Updated on: Mon, 09 May 2016 21:31]

Report message to a moderator

Re: Allow channels without item type [message #1731792 is a reply to message #1731754]

Tue, 10 May 2016 08:18

John Cocula

Messages: 21
Registered: June 2015

Junior Member

> So why doesn't the user directly define a Thing with a number or switch channel?

One possible answer is that it is burdensome for the user to have to conceive of a Thing, create one, and then link its channels to items, as this is more moving parts than in OH1, where the user just chooses an item type and lets the binding figure out how to update the item. Requiring users to enforce type safety and type agreement across multiple concepts they have to create and coordinate seems burdensome. I envision users rejecting this concept and continuing to use the legacy bindings. Maybe I'm wrong! I will be interested to see if Marcel can find a solution that doesn't introduce too much complexity for users to deal with.

Report message to a moderator

Re: Allow channels without item type [message #1732609 is a reply to message #1731792]

Wed, 18 May 2016 13:29

Marcel Verpaalen

Messages: 59
Registered: September 2014

Member

The way I'm currently trying to solve this is a hack to me.
I define a channel configuration field on the channel where the user can select the type, when it is changed I actually create a new channel based on the selection.

Note that I first tried to go from the linked items, but that route goes wrong once you define multiple items with different types. Than the binding either sends too many updates (for each item type) or too little (if arbitrary I take one of the types)

The suggestion of Chris I believe was very good... instead of creating channels without type, the framework to ensure it passes the update in the right type according the item definition

Report message to a moderator

Re: Allow channels without item type [message #1732865 is a reply to message #1731751]

Sat, 21 May 2016 08:21

Karel Goderis

Messages: 198
Registered: March 2014

Senior Member

Kai Kreuzer wrote on Mon, 09 May 2016 15:16

>

Maybe it is not clear that it is not only the binding, which can define channels of a Thing, but also the user, see https://www.eclipse.org/smarthome/documentation/features/dsl.html#defining-channels.
So you can simply define an MQTT Thing with channels for your solar logger, meter, valves, etc. and link the according items to these channels - all would be type safe and would fit nicely into the current architecture.

Ah.... this reminds me of https://www.eclipse.org/forums/index.php/t/1072808/
Would that be the solution to that problem as well?

Karel

Report message to a moderator

Previous Topic:	How to access getAcceptedDataTypes for a channel
Next Topic:	Channel Configuration through UI

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 15:29:20 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter