Agreed, I wouldnât feel very comfortable doing that. Iâm surprised that such an ability isnât available to mods and admins only.
Regulars can add the WIKI state to our own posts. Thatâs it.
2 Likes
I missed this. The edit option makes more sense now.
It worked!1!!!1!!
Wrong topic, maybe?
Saw this post from Tom
" You should read this advice about avoiding device ids too: Why and how to avoid device_ids in automations and scripts"
If thatâs the advice why then does the automation editor make it soooo easy to do the wrong thing?
2 Likes
More than that. Itâs a âgreat way to startâ, apparently. 
3 Likes
Because the âDâ comes before the âEâ 
That REALLY sucs, but thatâs not the worst of itâŚ
You know there are entity_idâs (traditional), but now there are entity_idâs that are connected to Device_idâs that are the different but the same in theory. There are also entry_idâs that have something to do with entity_idâs naming, unique_id, or some mix of the 2. I donât know but I suspect entry_idâs are connected to both flavors or entity_idâs which we are supposed to pretend are only 1 flavor but are not.
Be wary wary careful if itâs an entity_id or an entry_id.
Use names in automations/scripts for device/entity ID.
So why are device_idâs favored? Because the architecture team wants them to be favored.
I think thereâs an FR to not have the device stuff favored and first on the list of options, but I couldnât find it.
2 Likes
Ranting here because this seems to be the direction this thread is headed.
I still canât understand the switch to âfriendlyâ names in automations.
I mean - weâre all used to referring to triggers, conditions and actions. Theyâre even right there in the yaml, but if you post an automation for anyone to use, now your brain needs to map trigger, condition and action to âWhenâ, âAnd ifâ and âThen Doâ respectively.
Itâs confusing enough for those who are used to the Front end matching the code. I honestly doubt itâll help anyone who is just starting out and has been given a yaml file to work with.
1 Like
I think it was a good âattemptâ to help âbeginnersâ, Howvere they should have kept, the ( Trigger / Condition / Action ) in parentheses , so Beginners learn what it means, instead of trying to âinvent a new formulaâ , which doesnât exist outside HA UI
EDIT: Well itâs actually there, below, i just noticed 
However a Trigger can be both When/If, a Condition can also be And IF/When , And it get even worse when people comes to Action ( IF / When )
" If/when " motion is detected , âwhen/ifâ itâs dark outside, i want the the light to turn on, but only âif/Whenâ there is someone home "
âIf/whenâ Someone is Home, i want the light to turn on, âWhen/ifâ motion is detected, and only âif/whenâ itâs dark outside
âIf/whenâ itâs dark outside , i want the light to turn on, âif/whenâ someone is home, And âif/whenâ motion is detected
A Very common Question, which can âvariateâ depending upon peoples mind, and the âpreferencesâ
Device should go in âOther Triggersâ . 
3 Likes
Device should go under âRâ, for recycle bin. Itâs one thing to make stuff simplified for beginners (who still wonât read the docs) - itâs another matter entirely when you alienate or confuse most of your existing userbase in order to cater for the lowest denominator.
Iâve said this to myself over the past year - âHA is prioritizing accessibility to my family members who still have no idea how it all works, while at the same time doing its best to complicate stuff for me, the main userâ
Rant over.
3 Likes
It doesnât help that the device concept is extremely fuzzy.
When I select Device to make a trigger in the UI, the first item in the dropdown list is ZHA Toolkit (it comes first because thereâs a symbol at the beginning of the name). Next is Alarmo, which is, I suppose, a virtual device created by an integration. Next we have ArgonOne, which is an add-on, followed by Average Sensor, which is a HACS integration.
You can now create your own devices and put any entities you like into them (Device Tools from HACS).
This is supposed to be easier?
I hate this as well, but as someone that doesnât use the ui very often itâs not horrible. I say that because I have interacted with people that this âplainâ language has helped them get passed that first barrier, so I ill give that slack.
My go to has always been the UI first and foremost. It allows me to gauge how really user friendly HA is while showing me everything on (mostly) a single screen without having to keep track of indentations.
Iâve occasionally been switching to yaml whenever thereâs any duplicate stuff within the automation (copy & paste is much easier there), and the context switch is really jarring, at least to me personally.
My youngest family member is 3
1 Like
Feels like weâre getting more and more closer to that Age-Group, with humongous Buttons, Default huge âPaddings / gapsâ, Filling up with 50% white-space
Well, i guess i will benefit from from this , when i reach the age of 99, needs +7 Glasses, and have beginning parkinsonâs disease
To go back to the original post (sort of)âŚ
One reason why people often ask the same question is because the answers they are getting are to slightly different questions.
There was an example this morning. A newcomer to HA had two sensible queries:
- Are PIR motion sensors reliable in the kitchen, where there are multiple heat sources?
- How do I manage turning off the lights.
The answers were âYesâ and âLook at this cookbook postâ, but the thread quickly morphed into a discussion of hardware.
Thereâs nothing wrong with this - the author of the post got the answers he wanted (not the right ones IMHO, but stillâŚ) and useful information was exchanged - but it does highlight how inefficient forums are as a reference source.
Theyâre more like a sea you have to swim in for a while to get your bearings.
1 Like
We have a guide for asking questions. Perhaps we need a guide for answering questions?
2 Likes