Dynamic thing configuration options

Development Add-ons
#1

Hi,
I’m thinking about moving some thing properties of the comfoair binding to thing configuration. However, I’m not quite sure how to best implement this.
These properties currently indicate if certain modules are installed in the device. To make it possible for the user to change the device configuration, I would like to implement them as thing configuration options. This raises some issues:

  1. The current configuration cannot be pulled from the device before setting up serial connection and thus before thing initialization. So the user would have to set all options correctly by themselves, which cannot be expected from a common user.
  2. The device itself does only know about current settings. So, whatever the user sets to be installed is reflected as such by the device.
  3. Due to a lot of different device configurations, there is no standard setting that could be applied.

So I could think of a few options to solve this, but I don’t know, which would be possible with the framework or what would be the best option.

  1. Add a switch to the configuration to set if settings should be pulled from the device or current thing configuration should be used. Best would be, if the other configuration options are only shown, if the switch is enabled.
  2. Don’t show the configuration options on initial setup, but rather only make them available when editing the thing. Don’t know if this is even possible?

Any advice what would be preferable or any option that I didn’t think of? Could you even point to an appropriate reference implementation?

BR, Hans

[comfoair] New ComfoAir Binding
#2

These look like channels to me (also based on what I read in the other topic). Channels are for communicating state between the binding and the device. Configuration is more for how the binding communicates with the device, not how the device itself is configured.

#3

Okay, that was not really clear to me. Maybe also because this was even suggested during binding review: see comment.
However, implementing as channels would make this quite easy to solve.

#4

There is a slight difference between configuration and properties. Configuration is for the settings related to the binding and properties for information about the device that can be received from the device and set by the binding. Properties are not intended for interaction, just for meta information about the device. So as soon as the user needs to interact with that information it should be a channel. Specifically if the user can change these values and these should be send to the device. It’s common to see that this kind of data is modelled as channels, while its actually meta information and thus should not be channels.

#5

Thanks, for your detailed explaination. Will implement as channels then.

#6

One more related question: Currently I dynamically remove channels or channel groups based on these device options. Does this still make sense if options are set via channels or would this make the channel structure too dynamic?

#7

Dynamically changing channels/groups based state of a certain channel is too dynamic (If that is what you mean). This is because the user has to manually configure items to use a channel and thus adding or removing makes only sense in the binding initialization. Because from an item perspective the availability of channels is static.

Also dynamically removing channels is mostly an indication the thing should be split into different things as dynamically removing channels can cause confusion. Because a ui would look at the thing xml and show all channels available. And when initialized than some channels disappear and this might not be clear to the user why this happens. So in general if channels should be dynamically added not removed if possible.

I haven’t looked into the specifics off your binding. But it sounds as if it might also be modelled as a bridge with things. Where the bridge contains the serial connection information and specific things for the group of channels. For an example see the DSMR binding. Although I have no good overview in the dynamic conditions of the channels in your binding so it might or might not make things more logical.

#8

That’s what I thought. Even though it will provide most users some useless channels.

From my perspective, that was the easiest (and probably only) way to predefine the channels in the thing-types.xml and just show them if needed. But I’d agree that this was just the lazy way of implementation.

Thought of that already, but it doesn’t really add any value since there are a huge amount of devices from different manufacturers and AFAIK none of them has a predefined set of installed options. I think almost all options can be added to each device individually (and probably also installed aftermarket). Additionally, users seem to switch those options on purpose, which led to the issue that these have to be made controlable by the user again (from the current thing property read-only state). So I don’t think that using a bridge provides a benefit here.
But thanks anyway for your advices.

#9

I misunderstood this was for “comfoair” devices, which may or may not have optional parts installed, I dunno like a dehumidifier.
Is it in fact a widely used protocol, then?

There are example bindings dealing with similar situations -

zigbee for example only creates things based on properties the devices self-identify.

zwave uses a different approach, with a big database of known devices, for various historic reasons - but I think it’s generally recognized that is not at all ideal.

modbus has no self-identifying and few rules of use, so the binding allows vast complexity by providing any channel type for any device property by default. A real device is generally represented by a great many Things, grouped under a Bridge. That in turn leads to complex manual configuring, of course.

Having said that, there are a few cross-manufacturer standards superimposed on modbus, and the generic binding allows people to develop extensions. Such a binding extension 'knows" the target device e.g. some HVAC standard, and can pre-configure or use a “known” self-identifying process to discover, and then sets up the horrid underlying modbus stuff for you.

Approaches available to you depend on how much self-identifying you can get out of the devices.

#10

That, maybe was a bit overstated, but basically the “original” comfoair devices from Zehnder are rebranded and offered by different manufacturers (e.g. Wernig, StorkAir, Paul Santos, …). Even though they all provide different device types, which probably have a set of preinstalled options, most of the other optional modules can be added afterwards in almost any device I think.
So I still can’t figure a meaningful preconfiguration using predefined thing types. But thanks anyway for your suggestions.