For my Open-Meteo binding, I’m considering implementing a transformation profile that would “convert” the WMO weather condition code to an OpenWeatherMap icon Id so that existing widgets that use that kind if Ids will work without modification.
However, in order to do this, I need to information:
WMO code
Is it day or night?
The first comes from channel link on which to apply the profile so that’s easy. But the second one would have to come from an item linked to the is-day channel and I’m not sure this is supported, in particular in the settings web UI.
The XSD (here) tells me that only text, integer, decimal and boolean are supported, but could it be that some other types are only available via code?
If not, text would have to do, but which value should I ask to be put there? An Item id?
That’s a good question, and that borders on the “philosophical” side of things as I’d rather keep the OpenMeteo things focused on the associated API while (barely) helping users of other bindings.
Now, I see where creating a dedicated channel would make my life easier, but I fear that this would open a can of worm by creating precedent for other functionalities from other weather related bindings
So this would only work if you have both the Open-Meteo and the OWM add-ons installed and configured?
I’m not sure that’s a whole lot better than modifying the widgets. Or just using the OWM Thing for that Item in the first place. Maybe I’m missing something?
But with a Script transformation profile you can pass data to the script such as the names of other Items to be used. So you could add a profile and pass the names of the Items you need the additional information from as arguments and use that to transform the input from the Item.
No, it’s a transformation to create a “icon id” compatible with OWM so that widgets/rules using that id will work “out of the box”.
Basically, placing this mapping inside some code in my binding so that users do not have to implement it themselves.
Ok, passing the name is the idea I suggested above, so it’s doable. That item is linked to a channel from my binding as there already exist one that gives the isDay/isNight information
Adding the code inside your binding and giving people an extra channel makes life so much easier for them instead of them having to add a.profile and even come up with the code themselves.
At the very least if you could combine the two dependent information (day/night) into one output channel, then users can use a simpler map transform to translate that to other schemes.
Look at it as one channel gives you the weather type that is independent of day/night (the current one), and another channel where cloudyday is different to cloudynight.
You can pass additional information such as Item names to a script transformation. I don’t know if that’s possible for other types of transformation.
I agree with @jimtng though, the end users shouldn’t need to mess with this stuff. It belongs in the binding with a Channel. It may take information from OWM, but it doesn’t require the OWM binding to work.
A profile has a configuration which can contain as many elements as required, so yes, I can write it so that it receives an item name.
There is a misunderstanding here, this would never require anything from OWM, nor it would need to connect to OWM, it’s just trying to provide an information in “OWM compatible” format.
End users already have all that is needed to compute an icon id, based on those two items and on the mapping mentioned earlier.
I mean, just write a rule that reacts to change on any of those two items and update a third manually created item with the end result.
I could leave it as such but this would mean all users would have to implement this rule, which is quite tedious and error prone as not all users are willing to do this.
The next step would be to offer a profile to do the same somewhat automatically like this:
Hence the question in my original message about the ability to given an item name as a parameter to a profile. I understand that this is doable, but only as a string element which is not that user friendly. And also, this requires all end users that need this to manually edit an item linked to WMO code so that the profile is configured properly.
Another solution would be to create a new channel kind in the binding itself, like this:
This requires less complex setup on the part of end users, but it’s a (little) bit more complex on my side of things as there is no longer a “one to one” mapping on the is_day and weather_code fields presence in the request to OpenMeteo.
My only remaining concern is that this introduces a very specific behavior in the OpenMeteo binding that has nothing to do with the OpenMeteo API itself. This is nice to end users, but I’m not sure this would not lead to an endless litany of requests for other specifics unrelated to OpenMeteo.
Maybe instead of seeing it as “OWM Icon ID”, you can call it composite_weather_code which combines weather_code and is_day. At the very least, end users can use MAP transform which is far simpler than using a profile + item id. Especially if the user is not interested in either weather_code or is_day, they won’t even have to create items for those just for the sake of feeding it to the profile as you originally planned.
The MAP transform can then be used to transform it to OWM, or any other format the users may desire, and you won’t have to cater to a litany of requests for other specifics
I believe the changes are in core now. We just need MainUI to implement the UI to let us install transformation scripts from the marketplace.
When/if that gets implemented something like this becomes even easier for end users.
Isn’t that the job of bindings? To do the complicated stuff so the end users don’t have to? Otherwise we could just make the end users use the HTTP binding.
And if it does you can politely say no. I don’t think that will happen though because all the weather widgets and rule templates I know of it there are either agnostic or OWM focused. It seems unlikely someone works use OpenNMereo and some widget that is build for some other service.
Three issues I can think of with the profile approach:
aren’t bindings all but forbidden to mess with Items?
what if the end user transforms the state of the Item in unexpected ways?
what if more than one item is linked to the daynight channel?
With the profile approach, I would not mess with the items directly, I’m merely offering a profile that the end user needs to apply to their “Channel - Item link”.
Transforming the “IsDay” item used as the parameter to the profile could indeed be a source of issues.
I don’t see an issue here, the user can do whatever it wants, so long as there is one item linked to the isDay channel that is usable by the profile they applied manually on the channel - item link for weatherCode.
But in the end, it does indeed feel easier to create a new channel that does all the heavy lifting
