Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse SmartHome » Allow channels without item type
Allow channels without item type [message #1731551] Fri, 06 May 2016 17:51 Go to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
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
Re: Allow channels without item type [message #1731553 is a reply to message #1731551] Fri, 06 May 2016 18:13 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
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
Re: Allow channels without item type [message #1731566 is a reply to message #1731553] Fri, 06 May 2016 20:04 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
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.


Re: Allow channels without item type [message #1731667 is a reply to message #1731566] Mon, 09 May 2016 06:59 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 657
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.
Re: Allow channels without item type [message #1731745 is a reply to message #1731667] Mon, 09 May 2016 18:33 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
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.
Re: Allow channels without item type [message #1731751 is a reply to message #1731745] Mon, 09 May 2016 19:16 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 657
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.
Re: Allow channels without item type [message #1731754 is a reply to message #1731751] Mon, 09 May 2016 21:23 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
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 Go to previous messageGo to next message
John Cocula is currently offline John CoculaFriend
Messages: 20
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.
Re: Allow channels without item type [message #1732609 is a reply to message #1731792] Wed, 18 May 2016 13:29 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
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
Re: Allow channels without item type [message #1732865 is a reply to message #1731751] Sat, 21 May 2016 08:21 Go to previous message
Karel Goderis is currently offline Karel GoderisFriend
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
Previous Topic:How to access getAcceptedDataTypes for a channel
Next Topic:Channel Configuration through UI
Goto Forum:
  


Current Time: Thu Sep 20 00:18:53 GMT 2018

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

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

Back to the top