Update template weather docs because of removal of forecast attribute #32163
Conversation
✅ Deploy Preview for home-assistant-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| If you want to use the forecast of another weather integration, you'll need to create a trigger based template sensor and store the forecast in an attribute. | ||
| This is an example on how you can create such a sensor which will update every 3 hours. | ||
|
|
||
| {% raw %} | ||
|
|
||
| ```yaml | ||
| # Example configuration.yaml entry | ||
| template: | ||
| - trigger: | ||
| - platform: time_pattern | ||
| hours: "/3" | ||
| action: | ||
| - service: weather.get_forecasts | ||
| target: | ||
| entity_id: weather.my_region | ||
| data: | ||
| type: daily | ||
| response_variable: forecast | ||
| sensor: | ||
| - unique_id: daily_weather_forecast_template_sensor | ||
| name: Daily Weather Forecast | ||
| state: "{{ now() }}" | ||
| attributes: | ||
| forecast: "{{ forecast['weather.my_region'].forecast }}" | ||
| ``` | ||
| {% endraw %} |
There was a problem hiding this comment.
This is basically re-creating what we wanted to get rid off. I don't think it makes sense to do that?
There was a problem hiding this comment.
Yes, you are right.
My main goal was to remove the reference to state_attr('weather.my_region', 'forecast') as that was no longer possible.
But if you do want to add a forecast to a template weather, it has to come from somewhere, that's why I added it.
I can remove that part, and leave it to the end user how they get the data for the <type>_forecast_templates.
|
@frenck as the template weather now works with the modern template format, shouldn't this page just be removed (and linked to the It should also be removed from the list with integrations still using the legacy format at the top of this page https://www.home-assistant.io/integrations/template/ |
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
📝 WalkthroughWalkthroughThis update revises the Template Weather provider documentation. The changes clarify that the Changes
Sequence Diagram(s)sequenceDiagram
participant Scheduler as 3hr Scheduler
participant Sensor as Template Sensor
participant Forecast as Daily Forecast Provider
Scheduler->>Sensor: Trigger sensor update every 3 hours
Sensor->>Forecast: Request forecast via sensor.daily_weather_forecast
Forecast-->>Sensor: Return forecast data
Sensor-->>Scheduler: Update sensor state with new forecast
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
source/_integrations/weather.template.markdown (4)
24-24: Clarify the 'my_region' NoteThe note instructs users to update
my_regionin both the template weather condition and the corresponding template sensor configuration. Consider rephrasing it for enhanced clarity. For example:Note: Ensure that you update the
my_regionplaceholder in both the condition template and the template sensor configuration to match your setup.
42-44: Enhance Wording in the Sensor Trigger ExampleThe current phrasing—"trigger based template sensor" and "an example on how you can create such a sensor"—can be improved for clarity and grammatical correctness. Consider revising it to:
If you want to use the forecast from another weather integration, you'll need to create a trigger-based template sensor and store the forecast in an attribute. This is an example of how you can create such a sensor, which will update every 3 hours.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~42-~42: This expression is usually spelled with a hyphen.
Context: ...er integration, you'll need to create a trigger based template sensor and store the forecast ...(BASED_HYPHEN)
[uncategorized] ~43-~43: The preposition “of” seems more likely in this position.
Context: ...ast in an attribute. This is an example on how you can create such a sensor which ...(AI_EN_LECTOR_REPLACEMENT_PREPOSITION)
45-67: Adhere to Markdownlint Guidelines for Fenced Code BlocksThe fenced YAML code block in this section should be surrounded by blank lines to conform with markdownlint MD031. Please ensure there is a blank line before the opening
yaml and after the closingto improve readability and compliance.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
66-66: Fenced code blocks should be surrounded by blank lines
null(MD031, blanks-around-fences)
65-65: Verify Forecast Key ConsistencyThe YAML example uses the expression
{{ forecast['weather.my_region'].forecast }}. Make sure that this reference is consistent with the updated configuration instructions. It might be helpful to remind users that they should replace'weather.my_region'with their actual weather entity ID if it differs from the placeholder.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
source/_integrations/weather.template.markdown(2 hunks)
🧰 Additional context used
🪛 LanguageTool
source/_integrations/weather.template.markdown
[uncategorized] ~42-~42: This expression is usually spelled with a hyphen.
Context: ...er integration, you'll need to create a trigger based template sensor and store the forecast ...
(BASED_HYPHEN)
[uncategorized] ~43-~43: The preposition “of” seems more likely in this position.
Context: ...ast in an attribute. This is an example on how you can create such a sensor which ...
(AI_EN_LECTOR_REPLACEMENT_PREPOSITION)
🪛 markdownlint-cli2 (0.17.2)
source/_integrations/weather.template.markdown
66-66: Fenced code blocks should be surrounded by blank lines
null
(MD031, blanks-around-fences)
🔇 Additional comments (1)
source/_integrations/weather.template.markdown (1)
37-37: Confirm Updated Forecast ReferenceThe change from referencing
weather.my_regiontosensor.daily_weather_forecastforforecast_daily_templatecorrectly reflects the updated data source. This aligns with the overall update of the configuration.
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
Proposed change
The old example was still referring to the
forecastattribute of a weather entity. It also still hadforecast_templatein the configuration variables, which is no longer working.I also added an example on how to create a template sensor with the forecast.
Type of change
currentbranch).currentbranch).nextbranch).nextbranch).Additional information
Checklist
currentbranch.nextbranch.Summary by CodeRabbit