With openweathermap onecall api, a single call returns both daily and hourly forecasts.
For my own usage, I modified the old integration to add onecall support, and that one creates 2 “weather” entities, a daily and an hourly, with a single api call.
Onecall support was added to the builtin integration, which is great, but I understand it is daily OR hourly, currently, and that for getting both, you have to instantiate 2 integrations (if even possible) and that will generate 2 calls to OWM to basically get exactly the same response.
This FR to add an additional “onecall_daily_hourly” that would create 2 weather entities with a single OWM call.
P.S. This is also an indirect way to ask if a PR would be accepted
I’ve been dealing with this exact same thing. I tried to instantiate (if that’s the right term here) it twice, but the integration’s config flow gives an error saying it already exists. Your proposal is in line with what the default met.no integration already does: provide both the hourly and daily conditions and forecasts as two weather sensors.
Have you tried pushing a PR to see if it would be accepted, or reaching out the maintainers of this integration?
Well, problem is that it could be quite a bit of work, as my component and core has diverged, that could be scratched instantly by a “Not interested”.
There might be a way to propose a change to HA core, to agree on acceptance criteria, but if there is, I don’t know it. Ideally, it would be this forum, or maybe a specific “PR Proposal”, but I’m not convinced actual core developers read these posts.
The path of less resistance would probably be to add my custom_component to HACS…
Sad to see that this one died :-/ I’m currently looking into getting exactly this, and although I could setup just another OWM instance (Display weather from several locations), having both daily and hourly within one instance would be the way cleaner approach. The API supports up to 1000 calls per day, so doubling from 288 to 576 would still not be an issue, but “all in one” would have been the way to go. Too bad.