Seems like the @allenporter blueprint is broken. I clicked on it to import, and it doesn’t appear in my list of blueprints. Tried this twice without success.
Your post is very devoid of context.
2 Likes
Because I am an idiot and tried to import it before doing the upgrade. It works (the import) now after updating HA core.
2 Likes
Sometimes we are our own worse enemy 
2 Likes
I followed this discussion on album information as best I could but got a bit lost. Is there any chance please that you could put the complete configuration and automation somewhere (like community guides) so that others of us can emulate it?
Here is is: Getting played album info from OpenAI - Community Guides - Home Assistant Community (home-assistant.io). Quickly created, so might require firther finetuning, but contain everything you might need for start. As there are some issues with implementation (highlighted at the end of post), I’ll update this guide if solution found.
4 Likes
Fantastic, many thanks.
wdym? Looks like the last 2 components are currently building
1 Like
It looks like ^Refactor async_get_hass to rely on threading.local instead of a ContextVar^ in the latest core release did not fix my issue of calling an openai script from a zigbee button press action.
The called script will run fine if executed directly, but will not execute as an action triggered by mqqt from another script .( in my case using zigbee2mqqt). Using any other trigger, the script executes as normal.
Looks like there is a Problem with Custom Cards in the Dashboard, right? Almost all Custom elements are broken and show red.
It is Mushroom Card, Vacuum Card, Mini Temp and Auto-Entities and almost every other…
Or is there a bigger change in configuration which i didn see?
Mushroom and auto-entities are working fine here. Not sure which vacuum card you are using but my custom xiaomi one is also fine.
Check your logs.
Not sure if anyone responded in this thread, but it’s because you don’t have a solar feed-in value.
not sure how I missed this in the release notes, but now that we have UI for google_translate, I am left with this question I cant find the answer to in the docs. Currently I use:
tts:
### only used to set cache: false on Cloud tts
##
- platform: google_translate
# service_name: google_say
# base_url: !secret external_url
cache: false
as I have in my comments, only to set false to the cache option. Since there is no other tts service I use (except for NB cloud) I needed to do so using google_translate.
We can not set the cache: false option to Cloud say unfortunately, since that is not a yaml option in the first place.
Does the UI for Google_translate offer this option too? I d like to be aware before I break the cache functionality I now have in yaml.
Thanks - I played around a little and got it!
1 Like
just noticed this in the more-info:
on a script in Yaml:
script:
reload_tradfri_integration:
alias: Reload Tradfri integration
mode: restart
sequence:
service: homeassistant.reload_config_entry
data:
entry_id: 01c28e550efaa39e54aaf8180d8c10d8
1: I was able to edit the name, even though Yaml scripts dont have unique_id’s? Is that new, or has it always been like that?
Means I can take out the alias on all of my scripts, so I can edit them in the UI and have it stored in the .storage/core.entity_registry ?
2 if you look closely, there’s a little Asterix behind the entity_id: Is this a Frontend glitch, or does it mean something. Normally Id expect a footnote when an Asterix is used, but these are not available.
btw, I see the latter in all more-info panes now. So good chance I just havent noticed that before…
Pretty sure scripts have always been like this. Well, ‘always’, meaning since traces were introduced in scripts.
yeah probably. its just we ve been programmed to use unique_id’s to be able to edit anything in the UI, thats my jaws dropped when I accidentally tried to do so on a script and it simply worked… same for automations btw, as Ive just found out too…
there is a big difference between the two in the handling:
when deleting an alias on a script, the scripts gets named according to the ‘name’ field (seems obvious…), and on automations, the automation with a cleared alias option are numbered: automation 123
at least there is a unique id:, even though its not a unique_id…
- id: alarm_clock_off
# alias: Alarm clock off
trigger:
platform: state
entity_id:
the inconsistency in the usage of names/(unique_)id/object_id throughout the various core integrations is worrying when you actually start digging…
1 Like
How is it worrying… If you know yaml, you’d know why it behaves like this (The slug name for the script is the unique_id). This is pretty standard, you just don’t see it often because most yaml integrations require lists not dicts. A list requires the unique_id field on the listed object, a dictionary does not because it’s “named” in the dictionary itself (key and value). The only inconsistency is id in automations because it predates the entire unqiue_id system by a couple of years. By all means, we can make a breaking change just for you to appease your worrying.
……
And then there are template sensors. And next command_line sensors. All behaving differently.
1 Like