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
Marius, those configurations require listsā¦
Remember,
list:
foo:
- x:
y:
- x:
y:
- x:
y:
dict:
foo:
x:
y:
Notice in the dict, I canāt have more than 1 x or y?
e.g.
Automation (list of dicts)
automation:
- alias: Same Name
id: Something Unique 1
...
- alias: Same Name
id: Something Unique 2
...
vs Script (dict)
script:
something_unique_1:
...
something_unique_2:
...
vs Template (list of dicts)
template:
- sensor:
- name: ...
unqiue: something_unique_1
...
- name: ...
unqiue: something_unique_2
...
vs Command Line (List of dicts)
command_line:
- sensor:
name: ...
unique_id: something_unique_1
...
- sensor:
name: ...
unique_id: something_unique_2
...
Notice all the dashesā¦
Notice the lack of dashes on the script.
4 Likes
If you would take the time to try and understand my point that would help.
Command_line sensors now get a very useful (ā¦.notā¦) command_line_sensor object_id, and donāt relate to a set unique_id at all.
Templates sensors are better, they get the unique_id in the object_id, with the famous ātemplate_ā prefix. Or set a name once (is what I do, to set the object_id) and next comment the yaml name:
Combine that with the naming for scripts and automations, and we have at least 4 integrations that have different naming conventions. Not even talking about the difference in config option naming for the same options in the yaml here.
Marius, It took 3 rereads of your posts to understand that youāre talking about the entity_id. Please use the correct verbage? Yes, the naming of the object_id from name/unique_id is not consistent. Name refers to the name, not the entity_id or object_id.
As for the name (not entity_id) of the entity, it always comes from the name: field or alias field, depending on the integration. The default name and entity_id when alias or name is not provided will be hit or miss depending on the integration.
As an aside: The current flow for all integrations via yaml that provide a entity_id & unique_id is the same. The only difference is the seed that each integration uses to come up with the default naming scheme. There is no āstandardā for this seed and that ultimately results in this inconsistency that you see. e.g. template sensors adding template_ etc, or compensation using compensation_yoursensorname.
If you provide a name and a unique_id (however they are required via the yaml for the integration in question), your result will always be the same. Your name will be the name and your entity_id will be <domain>.<sluggified_name>. The exception to this rule is scripts because it was designed before this system was in place. There may be other exceptions, typically older integrations that were built prior to the unique_id/name system was added.
1 Like
Glad you admit there is some inconsistency 
I could have been clearer on the use if words, sorry about that.
thing is, it is a combination of unique_id (id), (frinedly_)name (alias) and the resulting object_id conventions (have to look up āseedā), and modern vs legacy (older) integrations.
So it isn that straightforward to begin with.
Talking about that fix you suggested on automation/script: why not? As they will remain in yaml anyhow, we might best make those behave identically indeed. change id: to unique_id;, change alias: to name: and make these have the unique_id in the name if the name is left out. In stead of
It would be a huge step forward, and a very small breaking change. Add unique_id to script, and your yaml would look much better
Sorry for the Off-topic we did here.
back on topic:
whatās with that asterix on the entity_id cardā¦
1 Like
Thatās just a name I call it. But thereās nothing to look up. Itās just the default name that you provide to HA when creating your entities without a name or unique_id. Itās up to the integration & developer, itās not provided by HA. I.e. this is the reason for the inconsistency.
3 Likes
Did you test to change the entity id as well? Is it working in the meantime?
yes, its working just fine. Ive moved all of my automations and scripts to use only their unique identifier in the Yaml, and set icons, name in the UI now.
also changing entity_id (object_id) via the UI is without issue.
Only thing I noticed was that the trace history got wiped (even though the unique identifiers remained untouched)
Changing object_id does result in:
so some caution is required and double check those entity_id in eg automations using that script
So you can still open and edit the scripts in UI editor after changing their entity_id via UI? That was definitely not possible in the past.
No sorry. Miscommunication.
I donāt edit the scripts in the Ui script editor.
These are yaml scripts. My confusion was about the fact they donāt use unique_id and still I can edit the script entity from the more-info window
As Iāve always understood the unique_id being required to be able to do so, I was surprised I could do that without unique_id
just noticed something after updating to latest version just released,
I noticed some changes as well. I use this in my automation that seems to work. Might be of help to you.
service: tts.speak
data:
cache: true
media_player_entity_id: media_player.sonos
message: |
{{ ('Grote Wasjes, Kleine Wasjes, de wasmachine is klaar!',
'Alle kleren zijn weer fris! De was is klaar.',
'De wasmachine is klaar!'
)|random }}
language: nl
target:
entity_id: tts.google_nl_nl
Donāt update to 2023.7.2 if you use the Daikin integration. Thereās a bug fix submitted for the next version.
3 Likes