Create complexType directly into binding

Development Add-ons
1

Hello,

I was asking myself if it was possible to create a ComplexType directly from a binding.

I’m asking this because I’ve face a architectural issue rewriting the SmartThings binding, and don’t know how to resolve it properly.

To describe it more precisly, Smarthings API expose for each device a certain number of attributes that are mapped to openHab channel, and that represents the current state of the device.

  • They are simple attribute that can map directly to standard openHab type like Number / String / …
  • They are some more complex attribute, like light color, but I can map them to HsbType using a conversion inside the bindings.
  • They are also complex attribute that have no equivalent in standard Openhab type and contains many properties.

So, I’ve possibly see 3 ways to handle them.

  1. Convert this complex type to Json String, and return the value to the channel. In terms of dev it’s the more simple. But it will not be very user friendly. And when the channel is Read/Write, it would make it possible difficult to send a new value to the channel.

  2. Expand this complex attribute so there is 1 channel for each embedded properties inside the attributes. This can be another solutions, but it will make the thing as a lot of channels exposed. Also,the handling of read/write channel will be difficult because Smartthings wait for a single command to set an attribute value, not individual commands for each properties of an attributes.

  3. The third possibility I can see is to create on the flight new ComplexType for this Channel.
    That would be I think the most end user friendly solutions, but I don’t see any binding doing this today, and not sure if it’s can be done.

Some examples of such attribute are:

  • audioTrackData: {totalTime=0, audioTrackData= { title=“”, artist=“”, album=“”, … }, elapsedTime=0}
  • powerConsumptionReport : {deltaEnergy=0.0999999999994543, energy=6896.9, …}
  • synthetic.lightingEffectFade : {duration=5.0, effects=[{capability=switchLevel, start=100.0, end=1.0}, {capability=colorTemperature, start=2500.0, end=2500.0}], fadeType=WindDown, state=Stop, afterAction={afterActionType=KeepCurrent}}
2

The standard approach is to do both 1 and 2. I wouldn’t worry too much about the number of channels (have you see the number in bindings like Astro and the weather add-ons?). Providing 1 in addition to 2 gives more advanced users more options.

3 is not feasible. It requires the creation of a new Item type and all that’s done in core and will touch pretty much every single part of OH to support. A huge effort with a low probability of being handled.

An option you’ve not mentioned though is to combine 1 and 2 with a rule action. The Channels will be read only and to send the command you need to do so from a rule using the action and the action(s) require the user to pass all the necessary data as arguments. The binding will handle converting that to JSON or what ever the device requires. This is a way to deal with the case where the binding can’t know all the data that needs to be sent when a command is sent to an Item.

3

Thanks for your response.

I’m currently try to implements a mixed approach with 1 and 2.
I will let you know the result of this, I’ve already be able to update a complex channel using a rule that send the Json to the channel.

I’m still asking myself if it will not be a good idea to introduce a new ComplexType, something called JSonType in org.openhab.core.library.types. It will enable in such scenario to have a more simple approach to handle this complex case. I will also test this other scenario to see if it can be a future extension to Openhab in a futur version.