2022.4: Groups! Groups! Groups!

[KennethLavrsen]

I made a typo in my example which I edited.

It should be
script manual followed by script

This is how automations work (which is documented)

I raised a bug report for this Configuration.yaml does not allow multiple lines for script like automations causing GUI do not work if you use manual yaml scripts · Issue #69801 · home-assistant/core · GitHub

And please note that I want to both run manual yaml scripts and GUI like I do with automations. Complex scripts and automations are a nightmare in the GUI

[boheme61]

so , it do work, or ?

[KennethLavrsen]

No, it does not work. It is not documented to work either. The “automation manual” is documented. This is not the case for scripts. But my point is that it should be added to the parser because it currently forces you to choose either manual yaml or GUI. You cannot mix for scripts like you can for automations.

[boheme61]

ahh ok, guess it was not intended to , or never though off
And i do agree about your point, the Automation"code" here i learned by making a simple, and checking the yaml(and for some i had to “switch"mode, to make it work), same way i learned html back in late 80, etc.
… thou the automation you make in the gui, regardless of “switching mode” ends up in automations.yaml, same as scripts, if im not wrong … i’ve never seen/use "
automation manual:” in configuration.yaml … sorry, thought it was either “!include” and/or “include_dir_merge_list” or “-named” like themes

Splitting up the configuration

Noticed “scripts” are not mentioned, but might work be the same way

Thou as it not mentioned anywhere that you can do as you do, i guess it’s not a Bug, but a FeatureRequest

[Gav_in]

boheme61

try this…doesn’t 100% solve the problem but does “work”

Script editor and split up files

[image] Here is how I combined script: # for UI editable scripts which are left in the original /config/scripts.yaml file # with script manual: # for manually created (and non UI editable) scripts which I separately placed in /config/scripts folder First, edit your /config/configuration.yaml file: script: !include_dir_merge_named /scripts Then, create a /config/scripts folder which will include - all your manually created scripts - and a ui_scripts.yaml file which will refer to the UI ge…

[boheme61]

Actually this is what stated in end of official Doc, for (automation split) applied to script

@rainbowbreeze

Following the suggestions for setting automations in the official doc , I tried the same also for scripts. And it works!

# Scripts created and edited in the UI
script ui: !include scripts.yaml
# Scripts created and edited manually
script manual: !include_dir_merge_named scripts/

[KennethLavrsen]

Indeed it works.

Also for me now. I must have made a typo somehow. I do not understand how I can have tried this a year ago and again earlier today and mistyped both times.

I will update my bug report and close it

[boheme61]

… and next time open a Topic, instead of using " Update Release Blog" to get attention
Thou interesting, i also learned something today

[tom_l]

This is the reason I have not bothered changing to the UI. My helpers have different names than entity_ids.

[SNoof85 (Sébastien)]

Nice job on database guys ! It is decreasing day to day :

Using mariaDB, 3 days retention and a daily purge

[petro]

clear your cache and refresh your page.

[Eoin]

Groups: I continue my journey moving all light and binary_sensor groups from yaml over to the UI. One thing I’m missing is the ability to see the state of all binary_sensor from the UI.

Old behaviour when viewing more info on a binary_sensor groups was seeing a list of all binary_sensor and their individual states. This appears to have gone and you now only see the state of the group.

[aruffell]

@Mariusthvdb

Must admit the current tendency of Streamlining the UI experience is really taking away from non Ui experience. Trying to voice that as positively as I can.

Please keep support for the entity_id in the UI ?

Agreed! I am absolutely NOT a fan of replacing entity id with device name… first of all the list loads at a snail’s pace (even in Node Red) and it is quite annoying when a device has many entities. It would be nice if both options existed. Type in the entity id if you know it and the device name populates for you, or populate the device name and then pick your entity id from a short list specific to the device.

I am keeping my fingers crossed that the end state after the changes will be a lot more usable than what I see now.

[nightwood (Simon)]

I have the same request/issue. I was using lock templates and converted to the new Switch as X, however the locks are showing locked when unlocked and vice versa

[Dudenell (Daniel Carr)]

@nightwood

Someone on reddit pointed me in the right direction, used template lock. Put this in my configuration.yaml file and it works as expected:

lock:
  - platform: template
    name: Basement Sliding Door
    value_template: "{{ is_state('switch.basement_door_lock', 'on') }}"
    unlock:
      service: switch.turn_off
      target:
        entity_id: switch.basement_door_lock
    lock:
      service: switch.turn_on
      target:
        entity_id: switch.basement_door_lock    

[nightwood (Simon)]

Yeah, that’s what I had and what I was trying to get rid of. It seems to me this is precisely the use case for Switch as Lock (except that it needs to be inverted for it to work for me).

[Dudenell (Daniel Carr)]

The order of the lock vs the unlock matters as I found with testing, if you put unlock first then lock it will inverse the template.

[StefanHabel]

My home assistant is not showing the 4.1 update. Until now there was never a problem with new updates showing up.

Any idea?

[chrisgott]

Update your Devices like WLED is pretty cool. But it would be nice if i would know WICH device i update!

[robertklep]

+1, I got 4 WLED update notifications but no idea for which devices