ok, yes this is “included” in default configuration.yaml … so i guess you added
script: !include_dir_merge_named scripts
and this is suppose to “load” on start(reading configuration.yaml) , so if it’s empty when you start (read nothing),
ok, yes this is “included” in default configuration.yaml … so i guess you added
script: !include_dir_merge_named scripts
and this is suppose to “load” on start(reading configuration.yaml) , so if it’s empty when you start (read nothing),
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
so , it do work, or ?
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.
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
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
Actually this is what stated in end of official Doc, for (automation split) applied to script
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
… and next time open a Topic, instead of using " Update Release Blog" to get attention
Thou interesting, i also learned something today
This is the reason I have not bothered changing to the UI. My helpers have different names than entity_ids.
Nice job on database guys ! It is decreasing day to day :
clear your cache and refresh your page.
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.
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.
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
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
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).
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.
My home assistant is not showing the 4.1 update. Until now there was never a problem with new updates showing up.
Any idea?
Update your Devices like WLED is pretty cool. But it would be nice if i would know WICH device i update!