Yeah I thought it would be removed as well.
I glanced through the code, and I don’t believe they’ve made the change yet.
maybe/hopefully they are in doubt whether it was an “effective/productive” change , to please a few people who had/got issues with their DB size, People who make templates and tweeking updates rates etc, without knowing the consequences on the Recorder
The default Recorder-setup is the MAJOR reason, for the huge DB-sizes for most people, People have to learn/know that the Default behavior is record ALL/EVERYTHING regards if you never, ever use or need it
The Recorder should be change to( record the essentials !), and then people have to add-to-recorder, IF they want it recorded/stored ( Upon their own responsibility, and proper requirements/preparations made to handle the increasing of the DB ) , i mean it is a “HomeAutomation System”, not a playground, alongside spotify, youtube, and latest counter-strike 
From the discussion that accompanied the change, I understand it was not really about database size per se, but about the loading of the states machine, including all entity attributes when you access or refresh a Dashboard view.
This affects everyone regardless of how they’ve set up the recorder integration.
And so i affected me to, however i didn’t noticed or experienced any issues what so ever related to this, and still don’t spite the fact i now have 12 template-sensors(6+6), and a total of 96 attributes(8 for each sensor), as a substitute, for the “missing” flexibility the services-call setup/degradation of the weather-service caused
True, always faster to fetch datas from RAM( When refreshing a view ), however ALL the attributes are there, Daily as well as hourly.
But if you need to access 1 specific attributes for i-e an automation, i doubt there is any relevant differences, if you fetch it from ram or db, or even a dict in a file.
There are many integrations/devices which have tons of “attributes/sensors” i.e Cams and the likes, and Devices/entities(several sensors which some find it relevant to update every seconds etc. (State engine load + read writes to db etc)
And beside the Weather-Card, people add graphs to show the datas in nice graphs in many/most cases with the help of a couple of template-sensor.
In this context the “initial” weather-forecast is relative small/stable, if it’s i.e update “changes” ones/even twice an hour.
( if people then want/need variable amount of API-Calls direct to provider, this could be optional, some have a paid subscription, some a free “limited calls” , and this has nothing to do with what kind of Weather-Integration HA offers)
I don’t find the current solution as an open-source, flexible solution. It’s a strict limited solution, doo to high shouting people, which in the end will get issues anyways, doo to overloading the state-engine, db and their overloaded WIFI-n(b), and resource limited phone, trying to retrieve 4K cam views etc.
Ah, just a mix of plants in the garden. I dont know if its good to water during the day… but the last few months testing, it grows really well. 
I am only watering the soil not the plant itself.
It’s never good nor effective watering when sunny and warm, more water evaporates, and yes, the plants don’t like water, when the sun is baking (the get burned, brown, dies)
Atleast you only water the soil
Same as above most water evaporates, the rest get too warm, the dark earth reach might not reach boiling point, but can get quite warm ( To warm for any plants )
Best is to water “Ahead” therefore nice with reliable forecasts, water in the night, or late-evening/early-mornings, before sunny days
The water have time to reach the roots ( which is where it has to go ), before the sun is baking
It’s not for nothing that many irrigation-system has tubes, just below earth or under soil cover ( of vegetable source )( i use “cuts” of previous years dried/died leaf, cover and long-term fertilizer ) and suffocate most of the “undesired” weeds
You can easily make your own, take a water-hose, plug the end, puncture alot of small holes i the hose, wrap-it in “weed cloth” so it doesn’t get plugged with soil and roots
if the plants have deep roots you can even better dig the tube(s) 1decimeter down
It bugs me as well. I understand that HA core developers are app people - meaning they do not do automations. OK. i can live with the jinja database crap for coding automations and even doing nested for loops, integrating stuff and calculating… gets very ugly, but hell, it works. but please - keep the the input data available for “NPCs” like me. i dont want a fancy GUI. I want to automate stuff like electricity consumption - heat pump predictive scheduling to boost COP and save on electricity.
1 Like
that cannot be the issue. I have tons of sensors that record about every second to 5 seconds. What is an hourly forecast compared to this? only 3600 times smaller in DB. logging data should be definable indeed. What to log and whats the step. that goes without saying.
Seems like we are not getting where. I really don’t understand the logic behind this change.
Still no easy solution to get the old hourly sensor back… 
1 Like
It seems like I’m to stupid. I’ve read through the documentation and suggestions from above.
The met.no integration now only creates a single entity that provides both daily and hourly weather forecasts.
The entiity is available in HA and I can see a state and some attributes in developer tools. Also the lovelace card shows forecast fore the next days.
What I’m now missing: how to read these forecast data from the entity “weather.forecast_home”? I’ve also run the service manually in dev tools:
service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.forecast_home
response_variable: daily
but when trying to read “daily” in dev tools I get “daily is undefind”
that response variable only lives within the lifetime and scope where it was defined.
you may be able to see it (statically though) in the trace of the call. or make that call in devtools- services and see the results there
1 Like