Was there an intentional change in the behavior of the timer integration? Previously the state of the timer would always change to idle before the timer.finished event fired, now it always changes after the event fires. This breaks some conditional logic i was using in some automations.
Have no idea is my issue related to .4 or not.
Got a very crucial issue while attempting to test another issue.
A whole storage-mode dashboard was replaced by another storage-mode dashboard - i.e. I got 2 (almost) same dashboards:
- Assume dashboard_1 has 20 views, dashboard_2 has 10 views.
- You need to move card_X from some view on dashboard_1 to some view of_dashboard_2.
- Result: dashboard_2 becomes SAME as dashboard_1 - only this card_X is a difference.
And a json file for this lost dashboard is overwritten with a content of another dashboard.
What I tried to do:
- Opened that json file of the overwritten dashboard.
- Pasted a content of the same file from a backup.
- Cleared a cache just in case.
- But still the dashboard is shown as a copy of another dashboard.
- Fixed only after rebooting HA.
Consider this as a quiet alarm for those who prefer to keep everything in UI & convince others.
Same here! How to fix?
After a front page update the page was working again
I tried it again and now it worked like a charm - same browser, same cache. No idea what the issue was yesterday.
Thatās true, but I prefer to have an additional backup of the entire HA system just in case I canāt access the HA internal restore function. At least it seemed like that was the case yesterday. Maybe a cleared cache could have solved this. Anyway Iām happy it works now.
Thanks for your advice!
I really love the new organization tools, especially for my automations itās really helpful.
However 
I am missing at least two ālevelsā
A) I would like to have one more ātop-levelā above Floors, my installations covers three different houses, for that it would be helpful to have a āhouseā level.
Also I would love to incorporate the zones someway.
Maybe both can be added somehow.
Beside that I hope the integrations will pick up this organization schedule soon. Especially for the HomeKit Bridge Integration it is currently very difficult to entities to a bridge. Having some hundred entities, itās always a time consuming scrolling to find the entity I want to add.
Furthermore, what is the rationale behind having different categories for automations, devices, entities? And would it be possible to have multiple categories for one device/entitiy/automation?
Anyway thanks to all of you for your incredible work
1 Like
Also having this issue. Any ideas on how to fix?
Beside āAdd labelā other sorting topics should faciliated like āAdd areaā. So I can mark a ton of devices and entities and assign them the respective areas, labels etc.
You have to convert to the new template style.
For the life of me I canāt get this to work (NWS has gotten rid of forecasts now, so Iām forced to upgrade my forecast methodology). Here is my attempt at an automation:
- alias: "Weather Forecast Updated Hourly"
id: 'my_unique_id'
initial_state: true
trigger:
- platform: time_pattern
minutes: /30
- platform: homeassistant
event: start
action:
- service: weather.get_forecasts
data:
type: hourly
target:
entity_id: weather.nws_weather
response_variable: hourly
weather:
- platform: template
name: "Weather Forecast Hourly"
condition_template: "{{ states('weather.nws_weather') }}"
temperature_template: "{{ state_attr('weather.nws_weather', 'temperature') }}"
temperature_unit: "{{ state_attr('weather.nws_weather', 'temperature_unit') }}"
humidity_template: "{{ state_attr('weather.nws_weather', 'humidity') }}"
pressure_template: "{{ state_attr('weather.nws_weather', 'pressure') }}"
pressure_unit: "{{ state_attr('weather.nws_weather', 'pressure_unit') }}"
wind_bearing_template: "{{ state_attr('weather.nws_weather', 'wind_bearing') }}"
wind_speed_template: "{{ state_attr('weather.nws_weather', 'wind_speed') }}"
wind_speed_unit: "{{ state_attr('weather.nws_weather', 'wind_speed_unit') }}"
visibility_template: "{{ state_attr('weather.nws_weather', 'visibility') }}"
visibility_unit: "{{ state_attr('weather.nws_weather', 'visibility_unit') }}"
precipitation_unit: "{{ state_attr('weather.nws_weather', 'precipitation_unit') }}"
forecast_hourly_template: "{{ hourly['weather.nws_weather'].forecast }}"
Donāt get worked up over whatās in the template or not there, Iām trying to get the syntax to work and then Iāll figure out where everything goes. I get the following log error:
Automation with alias 'Weather Forecast Updated Hourly' could not be validated and has been disabled: extra keys not allowed @ data['weather']. Got [{'platform': 'template', 'name': 'Weather Forecast Hourly', 'condition_template': "{{ states('weather.nws_... <snip>
I was using this for reference: Template Weather Provider - Home Assistant. Running 2024.4.1.
Same here: so the question is, what parameters are missing (baudrate as an example is only necessary for a serial communication)?
I couldnāt find any information what was changed between version 2024.3.3 and 2024.4.1 regarding the Modbus integration. After downgrading to 2024.3.3 everything is working again.
you should take out the weather part there, as it is now, it is written to be part of the automation, and that is not an option, as is written in the error.
you want that to be on its own (so at the same level in the config as automation: )
btw, why the initial_state?
Youāre mashing together an automation and a template entity. You have to choose one or the other, you canāt mix and match yaml.
What do you want? An automation with the information in a notification or a template entity to put on your dashboard?
Well, I started with the trigger-based template sensor linked by Taras but I got that same error. So I tried modifying it based on the quick blurb in your post to which I replied.
So I thought these were automations that created/updated a sensor but I obviously donāt have the syntax down correctly. Ideally I want the sensor instead of the weather entity but I get the same error in either case. Iām going to keep spending time on it, I usually get these things, but Iām certainly missing something from the examples Iāve seen linked.
From your reply, it appears I donāt want an automation but I create a sensor with the trigger? (I havenāt used one of these as of yet, thus my confusion). That makes sense, I saw the triggers and assumed it was an automation.
And as to Mariusthvdb question, I was (apparently incorrectly) creating an automation and itās my default to include the initial_state in case I want to disable it by default for some reason. Yes, I know I can flip a switch in the UI, old habits die hard.
Yeah, this stuff goes in the template section of your configuration.yaml. Thereās an example in the documentation to make a sensor from a weather get_forecasts call.
There are two links in my post:
Which link did you use and what was the exact error message?
Yes, but nothing else is. ie: input_booleans etc. So basically all the other stuff we have in Packages other than Automations are not saved in YAML when done through the UI.
1 Like
This is not a frontend FR, the backend isnāt there.