I wouldn’t call it a mess but, I would say it makes it more difficult for less experienced users.
However, using automations to poll services makes me a little uneasy. It just doesn’t feel right.
3 Likes
There’s a PR by @allenporter which allows trigger-based template entities to call services: Extend template entities with a script section by allenporter · Pull Request #96175 · home-assistant/core · GitHub
With that PR, this could all be done within a single trigger-based template sensor, removing the need for the extra automation.
The details in the PR, for example how to export variables from the actions to templates still need to be worked out.
4 Likes
Yes, I probably shouldn’t have said mess. I just used that word for simplicity in that sentence.
Just remembered I use a bunch of apex chart generators on forecast attributes too:
- entity: sensor.solcast_forecast_data
type: line
name: Forecast
color: '#e45e65'
extend_to: now
stroke_width: 2
unit: W
show:
in_header: false
legend_value: false
data_generator: |
return entity.attributes.forecasts.map((entry) => {
return [new Date(entry.period_end), entry.pv_estimate*1000];
});
tbh, who cares about DB size anymore? isnt that a somewhat over articulated aspect nowadays? While phones and watches outgrow the specs from devices at the time this decision was made (not even mentioning the other devices people run HA on), it seems watching DB size decrease has low priority?
so its 1.4 GB. doesnt break the system? while breaking this functionality causes real trouble for the non savvy.
2 Likes
Well, according to that blurb, that’s not a weather entity, so it’s unaffected by this change.
The attribute is staying for 6 months from September. So there’s nothing to delay, we just have six months to merge a PR that solves the problem.
2 Likes
You’re right, it’s not going away immediately. Nevertheless, that PR reduces the aforementioned “mess” by half, thereby making it easier to show users how to get a forecast attribute.
Just a guess but I think it would look something like this:
template:
- trigger:
- platform: time_pattern
hours: /1
action:
- service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.home
response_variable: hourly
sensor:
- name: Weather Forecast Hourly
unique_id: weather_forecast_hourly
state: "{{ now().isoformat() }}"
attributes:
forecast: "{{ hourly.forecast }}"
4 Likes
I think this one could blow up into a real *** storm in this forum, just like the MQTT nameing issue. It never rains but it pours!
(All puns intended!)
2 Likes
One possible pitfall - Time Pattern Triggers are great, and I use them all over, BUT, they don’t trigger on a restart so can leave entities undefined without some extra magic (included in my example above)
trigger:
- event: start
platform: homeassistant
- platform: event
event_type: event_template_reloaded
- platform: time_pattern
hours: /1
condition: []
action:
<stuff and things>
I’ve got a separate templates.yaml file, so have updated my previous syntax for the more general case.
Which exactly why I’m here gently asking questions and hoping that both pitchforks are left in the barn, and possible improvements to the change from valid use cases are discussed within the 6 month depreciation period…
Communication is key - so let’s keep talking so we all understand what’s going on properly.
I for one have learnt a few things in this thread, which is noice!
1 Like
Yes, I agree it needs a startup trigger. Nevertheless the example was merely meant to demonstrate the basic principle of getting the weather forecast into a Template Sensor by way of an automation. The user is free to modify/enhance the triggers, and all other aspects of it, as they see fit.
Anyway, we’re likely to be discussing this thing a whole lot more in the near future as more users become aware/affected by the change.
NOTE
See the example here to get an idea of what might become possible in the near future.
1 Like
Regarding the DB, I don’t understand, forecast attributes are already excluded from the DB, see Exclude weather forecast attribute from recorder by frenck · Pull Request #69205 · home-assistant/core · GitHub
Also from the documentation: Events - Home Assistant
CALL_SERVICE
This event is fired when a service is called.
If the weather is now updated using a service call, why not include the service response in the event data which are sent when the service is called?
Then we don’t need the automation.
3 Likes
It’s not a theory, that’s the literal reason why attributes are being removed from entities. Weather is no different, it just had a special case to exclude the forecast from recorder. I purposely glossed over that because it’s not relevant to the actual reason and it just derails the conversation. You will see attribute reduction or complete exclusion in existing and future entities. This has been a goal for multiple years now.
Again, we should not be focusing on why, we should be focusing on “what to do next”.
1 Like
What about:
This is being brought into arch discussions by Alan Porter, so something will end up replacing this, not necessarily the linked PR.
2 Likes
Well, events aren’t the easiest to work with, that’s a whole other issue. I’m not saying “no”, but more or less saying we need something easier.
2 Likes
But where is the benefit then? Instead of having the data where they were useful and usable in the attribute (and not stored in the history) (e.g. without a template sensor directly in template and UI) we have to define new template entities which will periodically call services and store data into entities and db history …
I can see lots of disadvantages of this idea/decision and have to really puzzle to find any benefits at all.
But for every click on a weather card it will be live-pulled then via such services and cannot be taken out of the attributes anymore … Or perhaps with every display of such cards to be prepared for the click? Either … or … both seem to be not good approach.
2 Likes
Then calling the service in a template trigger seems a nice solution