ThingItemProvider defaults to String items?

[Karel Goderis]

It seems the TIP creates only StringItems by default

11:45:39.901 DEBUG o.o.b.k.h.KNXBridgeBaseThingHandler[:282]- Received a KNX telegram from '1.3.104' for destination '1/5/3'
11:45:39.901 INFO tuwien.auto.calimero[:43]- [KNXnet/IP receiver] link 192.168.0.10:3671: indication from 1.3.104
11:45:39.902 DEBUG o.o.b.k.handler.GAThingHandler[:126]- Processed event (channel='io', value='0', destination='1/5/3')
11:45:39.903 WARN o.e.s.c.i.items.ItemUpdater[:68]- InstantiationException on org.eclipse.smarthome.core.library.types.StringType
11:45:39.904 DEBUG o.e.s.c.i.items.ItemUpdater[:77]- Received update of a not accepted type (DecimalType) for item knx_ga_ip1_AtticLight3Current_io

Karel

[Kai Kreuzer]

No, it should actually use the item type that is defined for your channel, see
https://github.com/openhab/openhab2/blob/master/bundles/core/org.openhab.core/src/main/java/org/openhab/core/internal/item/ThingItemUIProvider.java#L168

And if I check your KNX binding, you define a String item type for it:
https://github.com/openhab/openhab2/pull/21/files#diff-8ebd945d0c01cbd18bbb33c3b1cb92f7R46

> --
> You received this message because you are subscribed to the Google Groups "openhab2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
> To post to this group, send email to open...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/B5BB09CF-71BA-4CC6-A41A-6F5BC5A16890%40me.com.
> For more options, visit https://groups.google.com/d/optout.

[Kai Kreuzer]

> The implicit assumption is that a channel can only accept a single Type of data, right?

Right.

> In that case, do we have to define a channel per type of data that can be sent/accepted by the thing, e.g.


Yes, a channel should represent a specific functionality and as such should be mappable to a single item type. Channels are not meant to be „pipes“ to transport any raw data without any meaning.

Could you give an example of a channel with an generic „I/O“ type?

Regards,
Kai

> Am 10 Dec 2014 um 09:52 schrieb Karel Goderis <karel....@me.com>:
>
> Reflecting on this, how could this be solved? The implicit assumption is that a channel can only accept a single Type of data, right? In that case, do we have to define a channel per type of data that can be sent/accepted by the thing, e.g.
>
> StringIO
> DecimalIO
> ….
>
> Or should we stick with one channel, like io, but convert everything to for example String Types?
>
> Karel

[Karel Goderis]

I think there is a use case to allow Channels morph their accepted datatype. e.g. Channel.setAcceptedDataType() to be part of the API

The KNX binding’s GroupAddress ThingType is a type whereby the actual data type that is sent over the bus is set at configuration time, e.g. by choosing a DPT for the GA. the GA defines the kind of data that flows through the pipe, and therefore, at instantiation of the GAThingHandler the “io” channel’s AcceptedDataType should be set to match the datatype of the pre-defined DPT. 

The alternative is that the GAThingHandler queries each Channel for associated Items, and then, based on the accepted types of the Item, it updates the “io” channel that matches the Item. This assumes that the GA thing has a string_io channel, a decimal_io channel and so forth. e.g. a channel for each possible type.

20:58:24.707 DEBUG o.o.b.k.h.KNXBridgeBaseThingHandler[:282] - Received a KNX telegram  from '1.3.21' for destination '8/5/14'

20:58:24.707 INFO  tuwien.auto.calimero[:43] - [KNXnet/IP receiver] link 192.168.0.10:3671: indication from 1.3.21

20:58:24.708 INFO  runtime.busevents[:25] - knx_ga_gateway_ga8_5_14_io state updated to OFF

20:58:24.708 DEBUG o.o.b.k.handler.GAThingHandler[:126] - Processed event (channel='io', value='OFF', destination='8/5/14')

20:58:24.708 WARN  o.e.s.c.i.items.ItemUpdater[:68] - InstantiationException on org.eclipse.smarthome.core.library.types.StringType

20:58:24.709 DEBUG o.e.s.c.i.items.ItemUpdater[:77] - Received update of a not accepted type (OnOffType) for item knx_ga_gateway_ga8_5_14_io

Cfr here above, the ‘io’ channel should morph to accept OnOffType when the ga8_5_14 GAThingHandler is instantiated. 

I am not sure if the KNX is the only exception to the rule, but maybe there are other bindings where the format/type of the data that is associated with a Channel is not fixed.

On 16 Dec 2014, at 16:54, Karel Goderis <karel....@me.com> wrote:

On 11 Dec 2014, at 17:43, Kai Kreuzer <k...@openhab.org> wrote:

The implicit assumption is that a channel can only accept a single Type of data, right?

Right.

In that case, do we have to define a channel per type of data that can be sent/accepted by the thing, e.g.

Yes, a channel should represent a specific functionality and as such should be mappable to a single item type. Channels are not meant to be „pipes“ to transport any raw data without any meaning.

Could you give an example of a channel with an generic „I/O“ type?

Well, the KNX binding for example. It is a binding whereby the KNX GA itself is already an abstraction of a real-world thing, with the DPT the explicit definition of the nature of the data that is sent over it. So, unless you want to define a separate Thing Type for each possible KNX DPT, you would have a GA as a Thing which can accept any kind of data, since the DPT is freely configurable at the KNX side. So, if we define a channel "io" on the GA, then any kind of data can be passed on that channel. The DPT is then an attribute that can help interprete what has been sent on the KNX bus, but the bridge to the OH userspace would be generic. Hence the question, do you define a "io_string", "io_decimal",... channel that will take the value coming from the KNX bus (translated to a DPT) and convert it to the String, Decimal,... type

K

[Kai Kreuzer]

Hi Karel,

I think there are two answers here:

1. If you know the required channel type when the handler is instantiated, you know it when creating the thing, don’t you? So you could have different thing types for the different possibilities. If your thing can have multiple channels, you do not even have to define a thing type at all, but you can construct your thing (with its channels) according to your needs.

2. I think that the discussion shows that your current approach might not be on the right level of abstraction. It feels to me too „low-level“, i.e. rather like a basic TCP/IP communication or the like. What I would expect from the KNX binding is, that Things correspond to the different devices I have in my electrical cabinet (or as sensor devices in the rooms) - and for all of them, the channel types should be clearly defined. And btw, things like shutters should not be represented as 3 channels for 3 GAs, but as a single channel. I understand that this approach does not allow an auto-discovery by simply sniffing the bus for GAs. But I don’t really think that this will work for a complex system like KNX anyhow. So the better way might be something like an import of the ETS project and retrieving Thing definitions from there. Did you already think along those lines? Do you see any major problems with that?

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/C354F7D2-2E5F-4834-8447-8BC832D64042%40me.com.

[Karel Goderis]

Hi Kai,

In the meantime I also wrote this https://www.eclipse.org/forums/index.php/t/907212/ as a point of reflection. 

With respect to 1. You are right. Because we know the DPT in advance, we could construct the channels at runtime, but I failed to find the solution to do that. e.g. creating Channels and then adding them to Things. If I am misreading you here, you might be referring to solution 2. in the above posting.

too low-level, maybe, but it is the most resembling the OH1 environment, so I consider to be at the same level as before. And indeed, forget about discovery for sure, the only thing you can really discover on a KNX bus is the Group Addresses and the Individual Addresses, but nothing more meaningful like the DPT used on the GA, or the read/write flags. 

Importing the ETS xml file is an interesting route, already taken by some commercial solutions. I need to have a look at how that XML is structured, and let’s hope that a proper definition/namespace does exist in the public domain, otherwise it will be parser-hell. It would certainly be an advantage for larger installations like mine. 

In the meantime I propose to proceed as follows:

 - build a “base” KNXThingHandler that acts a participant on the KNX bus and so forth

 - build a “catch-any” GroupAddressThing that maps onto a single GA and converts data to a fixed String type. This is great for discovery and testing, and for mapping “undefined”/“exotic”/“partial” devices 

 - build a series of simple ThingsTypes like Switch, Dimmer, Blind,… with the lowest common denominator GA’s, and with a clear cut interface to the OH userland. Those can then be extended by everyone to cover the more complex hardware. 

Parts 1 and 2 will require some refactoring oft he current 2.0 code base, so that will be covered pretty fast. Personally I have a lot of MDT, Arcus-eds, Siemens hardware, some GIRA analogue actors, some Ling Jankke as well. Those will serve as the basis for my inspiration, let’s say ;-) 

In the meantime, and I wrote elsewhere, we need a mechanism for bindings to discover their “siblings” in a Item definition. in OH1 these were part of the same bindingconfig, but now they are disjunct, as captured in different channel=“” segments. These channels possibly belongs to the same binding, but to different ThingHandlers, so they need to now and discover about eachother, in order to do things like not sending out a value on a bus when received by another channel segment of the same item configuration (e.g. as needed in KNX)

Regards

K

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/27717F87-F7D7-4749-A195-48AFA131EB74%40openhab.org.

[Kai Kreuzer]

Hi Karel,

Probably best to pick up your example for the further discussion. What I have in mind is that (as long as we do not want/have the „real“ devices described as many thing types) we should not use Things at all - your bridge could simple contain all required channels for your personal setup with suitable parameters:

Bridge knx:ip:gw1 [ ipAddress="192.168.0.10", portNumber="3671", localIp="192.168.0.150", ipConnectionType="TUNNEL", readingPause="50", responseTimeOut="1000", readRetriesLimit="3", autoReconnectPeriod="1" ] 

{ 

Channels:

Switch : light_table            [ address="1/5/0", dpt="1.001", read="false", interval="0"]

Switch : light_bedroom         [ address="1/5/1", dpt="1.001", read="false", interval="0"]

Rollershutter : shutter_kitchen [ ga_updown="2/1/10", ga_movestop="2/1/11", ga_percent="2/1/12"]

}

This would give you a well-structured way of defining your KNX setup and in the items file you could refer to the different channels by „knx:ip:gw1:light_table“.

There is no need to have ANY GA things or thing types at all. The only thing type would be for the bridge and this would not list any channels in its description.

So the only information that gets lost this way (meaning: is not formalized) is the information about what parameters the different channels types take. Actually, you can also define these channel types in the XMLs, but you would not refer to them in the thing file (as in the example above).

Does this make any sense?

Best regards,

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/50BF6F5E-4100-4176-A843-4EAB27CCA33F%40me.com.

[Karel Goderis]

It does make sense. I think I was a bit sideblinded by the fact that the Channels DSL part was only added recently, the initial 2.0 effort was earlier. I think I will define the channel types as you suggest. 

I have quickly looked at the ETS4 XML and it is quite a complicated thing to handle. There is actually a bunch of XML files with a XML Element naming which is not convenient  at all. The best others have come up with is reading one of the xml files (“0.xml”) which only contains the Group Address definitions. Calimero comes with a set of XSLT to transform the XML in a Calimero proprietary format. OpenRemote has also a basic GA import feature, and I found some pretty ugly java code snippets via google that try to attempt the same thing. On top of that there are seemingly different file format versions between various variations of ETS4, so it is not something I would even attempt to do in the end. 

Regards

Karel

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/21F981A7-97A6-4C85-8698-0A6E1090BC77%40openhab.org.

[Kai Kreuzer]

Hi Karel,

I am glad you like my suggestion :-)

Wrt ETS XMLs: I agree that this is probably nasty code to implement and something which probably does not work as expected in the end. So I am fine with asking users to do the extra step to manually define their setup.

Regards,

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/1306D8A1-BCDF-4776-A50E-4263757BB5E7%40me.com.

[Karel Goderis]

Hi again

I gave all what we discussed a push, and well, the conclusion are not that great. Not as great as I was expecting. Just a few findings:

1. Channels as below are ok for Types that can be mapped onto a single GA/DPT. Anything else really makes the code butt-ugly with a lot of exception handling. For the dimmer for example, it is not 3 GA that do the trick, you need (depending on the actor) 6 GA’s, *and* 6 DPT that need to be defined (on/off, percent, and increase/decrease with their respective “state” GA that are send back by the device (most often on a different GA than the one you use to control the device)). It is easier to capture those complex Types into full Things of their own, instead via a Channel on the bridge

2. The data that is send back over the bus is sometimes translated into a CommandType, not a StateType (for example: IncreaseDecreaseType). It is impossible to feed that to a Channel, since a channel only takes States. Ok, you can convert maybe IncreaseDecrease to a %, but do want the code full of this kind of stuff, whereby you need to to reference the actual % value before you can increase/decrease it? It is really ugly.

3. Sometimes an actor sends back more than one GA value. For example, on my dimmers I get back a % and an IncreaseDecrease value. As is stands, they are both processed independently by the runtime, but they update the same Channel. If captured in a Thing of its own, at least those side effects can be dealt with in a correct way.

Karel

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/67C8E9F5-0887-48CA-9B33-4B53B5AB60E5%40openhab.org.

[Kai Kreuzer]

As discussed in private, let us continue this discussion once we have tackled https://bugs.eclipse.org/bugs/show_bug.cgi?id=456226.

Best regards,

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/FDB97189-98AE-4426-972A-90888B6358EC%40me.com.