I like to envision this so that you’d not need to do any patches that one needs to apply via patchmanager rather you could contribute them back directly. More on the later – stay tuned. I’d warmly wish you to follow fortnight newsletter and community meeting logs.
That said, this is awesome stuff!! This community rocks!
The benefit of having one such integration is that you can have this in the notification view as well as on the lock screen.
Well, the general forecasts are normally of such a good quality that they don’t change substantially that often and need to be monitored from minute to minute. What really is of interest on a more short-term is yr.no’s live radar based graphical local precipitation warning for the next 90 minutes, and I believe no such stuff can be offered on the lock screen or in the notification view, anyhow.
Sure, don’t get me wrong. I also have a .desktop of a bookmark that leads to my favourite numerical forecast from meteo.pl.
You’re Norwegian right? I have to give you that yr.no is good, but unfortunately good isn’t enough to keep our ‘precious’ weather app running in notification area or lock screen. 
So if you are happy with an open web site, please stay with it. Me to have a bookmark to my area on yr.no, while not open 24/7.
To note here as well, on 4.6.0 loading of the weather widget is disabled by default as out of the box it doesn’t work too good.
Wrote about it there SFOS 4.6 / Foreca: How to enable the Weather infos is in the the Events view - #5 by pvuorela but in short to get it back can set dconf key /desktop/lipstick-jolla-home/force_weather_loading true and install lipstick-jolla-home-qt5-weather-widget-settings package for events view settings switch.
Any updates on this part? Was it supposed to point towards Weather app getting open sourced?
Is it possible to switch to api.weather.gov? KDE seems to be using that provider for the weather applet and i assume they are not paying anything, so this might be an option for SFOS as well:
https://weather-gov.github.io/api/general-faqs
Anyway i would prefer having an offical app instead of some other app that needs to be installed.
If Jolla could get us an API to be fed with weather data, then anyone could implement their own local weather backend support via some middleware layer.
Could something like the open meteo api be an option? No clue how hard is to change things like that but seems like a good economical option.
All these free/open services are only free for personal use, there was someone working on rewriting the weather widget to use one of them, no idea what happened to that but it would still require every user to register for their api key or it would hit daily limit very quickly. The other free option is scraping like meecast (until the service decides to hide behind a cloudflare captcha or other bs)
Could you please reference your statement?
As far as I understand yr.no can be used by companies and application developers without costs:
https://developer.yr.no/doc/TermsOfService/
Some information may be found in the old thread too:
Open-Meteo is an open-source weather API and offers free access for non-commercial use
Openweather faq:
1,000 API calls per day are included for free.
Yr.no does not offer commercial service, but jolla would need to get a special agreement, from link you posted:
Bandwidth
Anything over 20 requests/second per application (total, not per client) requires special agreement.
with them to avoid getting their user-agent banned like default android:
https://api.met.no/weatherapi/locationforecast/2.0/documentation#AUTHENTICATION
Examples of banned User-Agents include:
okhttp
Dalvik
fhttp
Java
Or you would spend dev resources only to have the weather fixed only to get broken again
Take a look at my post here: Change weather provider to yr.no for the default weather app - #3 by emva
My GNOME Weather App uses data from https://www.met.no/en which is the institute that provides yr.no services:
Weather – Apps for GNOME
GNOME / Weather · GitLab
How do they solve these limitations?
Probably through the special agreement they mention is needed for higher bandwidth usage, no idea how easy it is to get it or how willing they are to give it (or what it includes), also no idea how often their api changes, how reliable the service is etc
F-Droid’s Weather Forecast app also uses yr.no / api.met.no :
Yeah, open sourcing would be the best, otherwise ppl can try the patchmanager approach, but that is likely to get the default QML UA banned by yr.no (if it isn’t already, those were just examples after all and iirc jolla still did not stop blacklisting useragent headers in qml xhr, so patches will get you only so far), not sure yr would get into agreement with a patch author, maybe worth bringing up at a community meeting, if opensourcing is problematic maybe NDA for community volunteers willing to address this would be possible (it really should be pretty simple switching few urls/parameters, getting it done properly to avoid banning etc is the tricky part)
What is situation with jolla weather?Anything new after this february conversation