I’m considering writing a weather forceast binding for the Open Meteo service and had a look at other existing bindings.
Most have “channel groups” for each forecast day with channel for values inside those groups, and the names for the groups seems to follow this scheme: forecastToday, forecastTomorrow, forecastDay2…
In order to make this binding useful to most, I’m wondering if there are particular recommendations, particularly on on channel naming and grouping.
I would recommend utilizing the new support in Persistence to store future values. With this you can save the forecast in Persistence and users are able to chart the values into the future. In addition, when that future date comes the Item is updated with that persisted value (this is probably less useful for weather info as the future values are constantly being replaced).
I think it would be cool if this add-on used that. However, I don’t know if that approach covers all the forecast use cases (e.g. showing the forecast on a UI you still need Items which means you still need Channels) so I don’t know if it would eliminate the need for all those dozens of forecast Channels. Maybe make it so users can add and configure forecast Channels for just those values they want.
OWM add-on implements the storing of future states in Persistence if you need an example.
As for naming conventions, I’d follow the examples in the existing weather add-ons. They are all pretty similar in how they name and group their Channels (or at least they used to be). I think most of the weather related widgets on the marketplace were written around Items that will follow this sort of naming convention for the Items (when using create Equipment from Thing the Item names come from the Chanel names).
Thanks, there is now a beta version for the binding.
However, I’m having an afterthought because I created this:
openmeteo bridge → forecast thing → channel groups → channels
Where the forecast thing has a location property, one channel group for hourly and one for daily, where the channels in those groups are not exactly identical.
When I use MainUI to create “Equipment from thing” and select all channels, they are created in the model all at the same level, effectively ignoring the channel groups they were assigned to.
This makes it quite hard to identify which channel belongs to what when browsing the model. For instance, here are pairs of channels that exist in both groups:
Without looking at their Id, it’s impossible to know which group they originate from.
This is why I wonder if it wouldn’t be better if I was to create the following situation:
This would also allow for later adding AirQuality and MarineForceast things that depend on the location bridge.
The downside thought is added setup complexity and the fact hourly and daily data can be retrieved together with the same API call, while air quality and marine forecast are separate calls, even if the latter has the ability to retrieve daily and hourly at the same time.
Or maybe I should suffix the channel labels with " - hourly" and " - daily" ?
But wouldn’t that be redundant with the channel groups?
I don’t have a strong opinion, but I’d personally lean a little toward separating hourly from daily with your location-bridge approach. I don’t think it adds much complexity, and in some ways kind of makes it easier for me to wrap my head around since hourly and daily channels would be in separate buckets. I also like that it will present in a very logical way if/when you add air quality and marine forecast.
Will the separate API calls make a difference to the user for setup? If not, then I wouldn’t be too concerned about it from that perspective. But if it’s a significant pain for you as a developer, I think the channel suffixes would be perfectly fine.
I think it would be better for the Item names/labels to include the Channel Group as well rather than change your organization. Otherwise I’m not sure Channel Groups adds much for the end user. They don’t really have a point.
And changing it there will help all bindings that use Channel Groups.
Often services are rate limited. I don’t know if this one is but it’s a consideration.
For the purposes of channel names in the model, would it be better as:
Hourly: Wind Direction
Hourly: Wind Speed
etc.
Daily: Wind Direction
Daily: Wind Speed
etc.
Or:
Wind Direction (Hourly)
Wind Direction (Daily)
etc.
Wind Speed (Hourly)
Wind Speed (Daily)
etc.
It seems to me that the first scenario would be better for reinforcing the value of channel groups, but the channel names are more sensible individually in the second scenario.
I too lean towards the location bridge approach but I can sense it adds a bit too much complexity for the end user. Well, with location discovery, the chain would be automatically created for the system location, hiding that complexity for most users.
No they would not but Open Meteo has a daily call limit per IP. Right now it’s at around 10000 so way more than the default 24 per thing as they refresh every hour. But if you updated every minute (pointless by the way) you would have 1440 calls per day, getting you faster to the limit, especially if you have multiple locations.
Well, if I was to change the organization with a “location bridge”, there would not be a need for a channel group anymore, unless the user configures the thing to use “split channels” (one per future hour/day)
That being said, I agree that I don’t see much point in Channel groups right now from an end user point of view because they are not reflected in the way items are created/displayed.
What do you mean? As an example of a “good thing to do” that others could follow?
Overridden how? When creating the items? That’s quite painful to edit 20 item names when about to create items, but yes doable.
Yes, that was my original idea with a suffix and I must admit that using the parenthesis looks better.
Then, if the user chooses to use split channels, I guess this would give this kind of names:
What I mean is if Channel Groups are going to be useful at all, the group name should be included in the Item’s name and label by default when using MainUI’s add equipment to model or add points to model. Otherwise it’s missed opportunity to make things easier for end users as well as calling into question what the point of Channel Groups may be.
But if the Channel Group name is included in the Item name and label, your binding isn’t the only one that would benefit. End users would find it easier to create Items from any binding that uses Channel Groups.
Yes.
Indeed. I didn’t say it was nice and easy. But right now everyone has to edit each of the Items regardless of which format they would approve. But the only way stuff like this can be managed at all is for the UI to be opinionated.
Yes, add the Channel Group name in the parens to make it easier to distinguish between the created Items. Even if it’s not the end user’s favorite format, it’s loads better than a bunch of Items with identical labels.
So what I must conclude here is that my idea of an intermediate “location bridge” is not desirable?
I’m not locked on that idea either, it’s just that I want to be sure of what’s the usual/recommended way to deal with so many potential channels on a given thing.
To me it seems overly complicated and it’s a work around for a problem that is better fixed in MainUI instead of by you the add-on developer.
I don’t know that there are too many add-ons with so many Channels so I’m not sure there is a “usual” way. Using Channel Groups feels like the intended way to manage them, but as we’ve discussed, they don’t add much to help the end user unless and until they are included in the Item name and label.
What i try nowadays is to generate items directly in the binding and link them to the channels. No need for the user imo to manually have to create items for all channels.
Possibly you can add a config parameter (switch) in the bridge thing “automatically generate items for all channels”. If you automatically generate items you can add a useable label field as well.
Maybe it’s once bitten twice shy of me given how much this approach failed spectacularly in OH 2, but given that the Items are the model of the end user’s home, the binding rarely if ever has the knowledge necessary to automatically generate Items in a way that matches the end user’s model of their home.
I think for a lot of bindings with many channels, you should not have to create items unless you want to.
That being said you should still be able to edit and customize them as you see fit, but linking to channels etc is just tiring imo. Each to its own I will add option to automatically generate items for the bindings I maintain, and it’s and approach I’m using for my own stuff.
I tend to package rules into modules (jar-files), and when they are deploy it automatically generates the items I need together with the rules. This however is something else, since it is not related to a specific binding.
It sounds like you are talking about the already existing “add points to model”, “add equipment to model”, “create equipment from thing”, or “add points from thing”. You never have to mess with the Links at all even for Thing with hundreds of Channels. The Items, their semantic parents (e.g. Equipment Group and membership in the Location Group in the model) all get handled automatically. The default Item names become the name of the parent Equipment (where applicable) plus the name of the Channel it’s linked, the default label is the Channel name, and all the major important properties of the Item can be edited from the defaults for all of these Items prior to their creation (name, label unit, state description, label, semantic tags, etc).
If you are manually linking Items to Channels you are missing out on one of the more powerful features of MainUI.
And the advantages this has over the binding creating the Items are:
end user gets to choose to use their own language, not forced to use English Item names (or what ever language the binding author uses)
gets to use meaningful names and labels based on their home, not the technology involved
has the opportunity to change just about anything about the Items prior to their creation
gets to pick and choose which Items get created in the first place
Links are created automatically
position in the semantic model happens automatically, including creation of the parent Equipment (where applicable)
and most importantly it works and works the same way for all bindings
I’m not going to say there isn’t room for further improvement but to have bindings individually decide whether and how to make Items and leave it to the users to have to go back and change things to match what they want after the fact is a step backwards in usability, particularly since the binding does not know everything necessary to match the user’s home system.
I agree with you, I hardly see a point in auto creating the items as they would end up in the model in a place which I don’t like.
That being said, if the “create from equipment” was to automatically add a level for channel groups, that would make for a much clearer model.
It would not change the fact that in the Item list they would still be only distinguishable by their id, so I will add the suffix anyway.
But one of the main points is it creates the Items in a place in the model you pick. Maybe I don’t understand the statement.
I’m not sure I understand what you mean here by “level for the channel groups”. Are you referring to sub-equipment? If so that doesn’t seem wholly unreasonable. Today you’d have to create the grandparent Equipment first and then create each sub equipment one at a time to achieve that type of organization.
If you are talking about the Item names, those have to be unique anyway and the most straight forward way to do that is through a suffix or a prefix. By default MainUi will use a prefix which is the name of the parent Equipment Item. So if I have an Equipment “HourTwoForecast” the Point Items will be create with the name “HourTwoForecast_ChannelName” (e.g. “HourTwoForecast_MinTemperature”).
What I’d like to see added somehow is the option to also add the location and equipment information to the Item Label.
I was referring to the suggestion that a binding would create the items on its own which does not seem desirable like you said.
Yes, technically, they all are a group items but conceptually, it would indeed be a sub equipment
Equipment “Forecast thing”
SubEquipment “Daily forecast”
Item for channel “Wind direction”
Item for channel “Max temperature”
…
Yes, sorry, I mixed up name and label concepts. That being said, I don’t see how I could have an impact here within my binding as, if I’m correct, the default suggested label is the channel name and there does not appear to be a mechanism to provide another suggested label.
I think all you can do from the binding side right now is to add the Channel Group name to the Channel name. Then that should flow into the Item label and the Item name. But then we are back to the whole discussion on what’s the point of the Channel Groups if you have to include that in the Channel names anyway. But we have the OH we have right now. That’s the only way I can see you can influence it from the binding right now.
