Thanks, that was indeed the issue here!
I prefer not to use default_config because it is a massive list which also includes things I’m not using. Bu t adding backup: works fine 
thats what I thought in the beginning, but checking the integrations that are configured by default_config: I see all of the integrations that are in my current self curated list of installed integrations… except for 1:
map:
and that’s only because I dont want the map in the left side menu column… other than that, I would be happy to use default_config:
except I dont use:
stream:
backup:
usb:
tag:
webhook:
either 
What we need is this for automations
Best of both worlds if this gets implemented. We will have much better GUI experience and still full flexibility to edit YAML.
If the GUI automations editor cannot figure out an advanced YAML automations it can always fall back to only offer YAML editing in the browser. I would love that. I would love to be able to create the basic automation in the GUI and then when needed enhance it in YAML mode.
What prevents me today is that it can only happen if you accept to work with all your automations in one long horror list with 100s of automations. I cannot wrap my head around that. I have my automations organized in files today with between 1 and 5 automations in each file and even that has grown to a number where I consider putting them in sub-directories.
I really think this UI area needs to be the next big thing.
And please - do not start using JSON instead of YAML as storage format for the automations and scripts files. It will still be needed to edit files directory. When you need to do something bigger or something repetitive (like a major refactoring of your automations - I have done that more than once) the GUI approach takes far too long time. I was really sad to see the helpers now saved in JSON instead of YAML which makes quick hacking much more difficult.
Indeed, but is possible,( create the “basic” with included entities etc. etc. in GUI ), then edit “automation.yaml” manually ( pick out the new GUI-created automation ), and place it in a new automation-file under /automation , i will soon also end up where i find automation.yaml to “boring” to scroll down/search in, so i really assume they never change this option
That is what I do today. But not exactly easy
Not sure what you mean, you can actually “switch” between GUI/yaml mode when creating the “Basic” automation, when your satisfied or at the end of the “rope” for the GUI, then in GUI click Yaml-mode, copy your creation, past it in a i.e notepad++(supports Yaml), after that you delete your work in GUI( never ends up in “Automation.yaml” , 5 seconds task
Still not what I would call easy or user friendly. It is a work around. And the yaml you copy still need to be manually put in a text file and then you need to trigger a reload of automations. And you will end up with it in automations.yaml because we all debug automations until they work as we want them. And I want to do that in the GUI. So first you work on your automation in GUI. Then you delete the automation in the GUI after having copy pasted the YAML. And you then need to put it in an existing file or create a new file and paste the YAML into that. And then reload automations. A lot of steps. Not something I can sit comfortably and do on my iPad.
Well, all Editors / Gui’s is created by someone at some point in time, was the same in early days in i.e. various HTML-editors, if you didn’t regularly “checked” (in text-mode) what you did in the GUI, the Editor had thrown in a lot “tags” and “unwanted” code, so if you made “from scratch” a html-page(in another text-editor), and opened it in the “GUI-editor” it would complain and even some would just change/add tags and code … so i think what you basically want, is not possible
did someone already mention the deletion of #comments in the UI? or was that fixed meanwhile…
1 Like
hmmm, annoying yes, i don’t know (should atleast be fixed as # is common(comment tag) in yaml )
Well the idea behind skip was that if you don’t want to do an update for some reason then you skip it. In which case you stop being notified about it because to you it no longer exists.
Kind of like how if you ignore a discovered device it stops letting you know about it. It’s still being discovered it’s just quiet about it since you’ve said you aren’t interested.
I kind of liked that design personally. And it’s not like anything ever skips an update for you. The only time an update is skipped is if the user tells it to skip it.
If you don’t like that it turns off on skip then I would recommend a check like looping over the update entities and checking if attributes.version_latest != attributes.installed_version. I wouldn’t rely on the update_available binary sensors anymore that the hassio integration makes today. I believe those are going away in a future release since they’re considered redundant with the update entities. That’s why the new HACS integration doesn’t even make them, it only makes update entities.
I would be happy if the automations GUI would give up if you add any detail it cannot understand (e.g. some Jinja template stuff) and fall back to YAML mode only. A bit like we know from the Lovelace/Dashboard cards today. You can toggle between UI and yaml until you do something the UI code for the card does not understand and then it falls back to yaml only. That works pretty cool today when you create your various cards.
1 Like
a ok, thats a good idea too yes.
I wasn’t aware they are marked for redundancy.
I’ve just proven they’re not
btw, ive just tried to make a template where the skipped_version: null/none is rejected, but cant make it happen somehow. Is this not a regular attributes of sorts?
To some extend it does EDIT: thou this is an automation entirely made in GUI, so it’s still a part of automation.yaml, not a separate file,… don’t know if that matters.
Thou removing comments (in any editors) is simply wrong
This worked for me:
{{ states.update | selectattr('attributes.skipped_version', 'none')
| map(attribute='entity_id') | list }}
Or flip selectattr to rejectattr if finding ones that have been skipped.
1 Like
ofc… I forgot the ‘attributes.’ in the template… o dear …
{{states.update|rejectattr('attributes.skipped_version', 'eq',none)
|map(attribute='name')|list}}
also works
1 Like
I have been converting my groups over from yaml into the UI method. So far so good. I have one group in yaml that contains four input_booleans. Is it possible to add input_boolean to the Helpers / Add Helper section?
beer_requested_group:
name: Beer Requested Group
entities:
- input_boolean.beer_requested_front_porch
- input_boolean.beer_requested_rear_porch
- input_boolean.beer_requested_garage
- input_boolean.beer_requested_pool
Thank you!
1 Like
Not sure what doesn’t work for you but this works for me:
service: media_player.play_media
data:
media_content_type: favorite
media_content_id: VRT Studio Brussel De Tijdloze
target:
device_id: 3b8953aa47ff5aedb657a10863655d59
No there’s no input_boolean type group currently so you still have to do that as an old-style group in yaml. Would recommend putting in a feature request.