Have an addon provide a method to map the numeric value to a string indicator

Hello,

As I’m writing the Air quality part of the Open Meteo binding, I’m providing channels for the European and US Air Quality Indicators, as numerical values.
As can be seen on the API documentation, the dimensionless numerical value can be mapped to various human readable levels such as good, fair, moderate…

While end users can do their own mapping by themselves, I would find it nice if my addon could provide something ready to be used by end users.

Unfortunately, I’m a bit lost as to what that “thing” would be.
I have read about Transformations but I’m not sure this would apply to my case, nor how an end user would use that in openHab.

Thanks for any help on this very new matter for me.

I’ve seen stuff like this handled using a separate String Channel.

I also have seen bindings push state description patterns and options. The options act as a map so it might get you where you want to be. I think the Roku add-on does that for the button channel iirc.

You can’t really rely on a transformation because you can’t guarantee the end user has that add-on installed.

I thought about that too, but I’d really like to avoid duplicating the 12 AQI channels.

Ok, I’ll have a look at it.

But the documentation I linked to describes creating a Transformation service and/or a Profile service. But I have no idea if this would be applicable here, nor if it would be useful to end users. I mean, I don’t even have any idea what Profiles can do, let alone how to apply this to the matter at hand.

That would be if you want your binding to implement and provide it’s very own transformation service or profile. For example the modbus add-on provides a gain offset profile. But that’s a brand new capability, not reusing something that already exists like the Map transformation. You would do that if you want to provide a capability that doesn’t already exist that is needed by users of your binding and likely not to be needed by any other binding.

And even then, the end user needs to apply the transform or profile themselves, so you really haven’t bought yourself anything if your new profile or transform does something already provided by an existing add-on.

In some of the binding I worked I use to have alert level in a number chanel (usually ranging from 0 to 3) with options that deliver readable values.

That’s what I thought of doing as well, but with 13 channels that would need to be duplicated to indicate the “level” as string, I feel it’s a bit of overkill.
That being said, those Air Quality Indicator channels are not available by default, so they don’t clutter up the interface anyway.

Thanks to all for the suggestions, I’ll see what I can do.

Definitely make use of the “advanced” label as well to hide the less used channels unless the user checks “show advanced”. If you have a number channel and a string channel, you could mark the number channel as advanced and only those users who are looking for it will need to see it.

They can be combined, a Number channel comes as a string in UI when options are present on it.

1 Like

To clarify what @glhopital is referencing, look at the documentation here: Thing Descriptions | openHAB (scroll down to the paragraph about state options).

Thanks for the suggestion, but in my case, it’s not a 1 to 1 mapping like signal strength but an interval based selection:

Lower bound Upper bound (excluded) Condition
0 20 good
20 40 fair
40 60 moderate
60 80 poor
80 100 very poor
100 1000+ extremely poor

Unless I’m mistaken, I don’t think options can represent this accurately

What I use to do is using map with scale.
Eg:
battery.scale

[0…15[=3
[15…30[=2
[30…90[=1
[90…101[=0

[…]=-1
NaN=Pas initialisé (NaN)

battery.map

0=Plein
1=Normal
2=Bas
3=Très bas

-1=inconnu :interrobang:
UNDEF=inconnu :interrobang:
NULL=inconnu :interrobang:

You could present both. The raw value, as an advanced channel and the corresponding condition as a synthetic value. This is what I do in the Netatmo binding (example here)

1 Like

Thanks for all the suggestions

I went with the “channels as string with options” approach but because it wasn’t all that hard, I also offered transformation profiles for maximum flexibility.

This is all in the 0.2.0 version that I just released.