Eclipse Community Forums: Eclipse SmartHome

Home » Archived » Eclipse SmartHome » Binding Transformation(Transformation where the source is a binding)

Binding Transformation [message #1743124]

Mon, 12 September 2016 08:10

Eclipse User

I've written three bindings now and all three of them could have used a transform where the transformation came from the source equipment itself.

Simple example: a multizone audio system. Each zone will have a name and presumably the UI will allow the user to pick a zone to control. From a UI perspective, it would be nice to allow the user to pick from a list of zone names rather than zone numbers.

The mappings transformation can easily do this. However, the map file is not the official 'source' of those mappings - it's the source equipment and having it duplicated in a file will inevitably lead to a mismatch (especially if those names can be changed by the source equipment via keypads) and increases the amount of maintenance that needs to be done in large, complex automations.

I'd like to purpose a way for a mapping transformation to come from the binding itself. Do you all think it's a good idea?

If so, I don't know the backend code well enough but it seems that it can partly be done by implementing the TransformationService. But I have no idea how the registration of such a service occurs nor if it can be more generalized.

Re: Binding Transformation [message #1743227 is a reply to message #1743124]

Tue, 13 September 2016 08:37

Eclipse User

Hi Tim,

The TransformationServices are meant as a tool for the user to adapt the output of a binding to their needs, if that isn't what they need. TransformationServices should therefore NOT be used by the bindings themselves - instead, the bindings should directly spit out the expected values. So instead of having a Number-channel for zones, there could be a String-channel that directly sends the zone names as a state.

This doesn't solve the "present the user a list of options" problem though (although I do not see how this is solved through a map transformation file..?). This is usually done through StateDescriptionProviders. There is one implementation (ChannelStateDescriptionProvider), which takes this information from the thing type, so instead of defining your thing types in xml files, you could implement a ThingTypeProvider, which dynamically provides this information. This isn't really a good fit either, because your options do not depend on the thing type (=class), but on the thing (=instance) itself. Since the StateDescriptionProvider interface refers to items, this must not be implemented within bindings, so this isn't an option either. We might discuss to adapt the ChannelStateDescriptionProvider implementation to also optionally query ThingHandlers whether they want to provide specific state options - this would probably the best way to support your requirement. Does anyone have any other ideas/suggestions?

Re: Binding Transformation [message #1743328 is a reply to message #1743227]

Wed, 14 September 2016 08:09

Eclipse User

If you don't mind a little discussion, based on your response I'd say the transformationservice is exactly what should be used. From the users perspective (and if you don't mind me reusing your words), they want to adapt the output of the binding to the settings they have stored on their device.

The binding will still be spitting out the the correct values - it's just the binding will provide an optional implementation of the transformationservice a class that can then map those values to what the user has set in the source device.

Maybe I'm not understanding what you are getting at but think that would be a wonderful addition.

Examples (not suggesting this api - just for clarity of example):
Number Russound_Zone "Zone [RussoundMap(%d)]"

The user is saying to transform the russound zone id's via a binding supplied transformationservice that will convert the zone id's to zone names that they set on the source equipment.

[Updated on: Wed, 14 September 2016 08:10] by Moderator

Re: Binding Transformation [message #1743458 is a reply to message #1743328]

Thu, 15 September 2016 10:49

Eclipse User

Ok, I see what you mean. I would think that this could be realised as a configuration on the channels (they can be configured although hardly anybody uses this feature yet).
And then yes, it would make sense to allow the user to refer to transformation services within this configuration. We currently do not have such a thing as a TransformationServiceRegistry, it probably would make sense to introduce it for bindings, so that they do not have to search for the right OSGi service themselves.

But nonetheless: Having this feature will still not allow to render a drop-down list of those values for the user to chose (if they want to change the zone) - or am I missing something?

Re: Binding Transformation [message #1743469 is a reply to message #1743458]

Thu, 15 September 2016 13:18

Eclipse User

Actually - now that's I've thought it through even more. I think it would make more sense for the binding to have a configuration option that would simple tell it to write out a map file that the existing mapping transformation can use. That way the user can use it or modify it at will - seems more simple and flexible this way.

The config option would accept something like "None" (don't write the mapping file), "Write Once" (write if it doesn't exists) or "Always" (overwrite) to determine.

Re: Binding Transformation [message #1744164 is a reply to message #1743469]

Fri, 23 September 2016 01:17

Eclipse User

This isn't really an option, since bindings are not supposed to mess with user configuration files - this would be a break of the architecture. Also, the "conf" folder is considered to be read-only, the runtime might not even have permission to write into it.

Previous Topic:	Single binding for handling multiple things simultaneously
Next Topic:	Limit to single instance of a Thing in binding

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jun 18 05:05:39 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter