- name: "[[[return `Update available: ${states['sensor.version'].state}`]]]"
1 Like
Does the lock function disable the button? I have an automation that changes an input_boolean to on. The user is allowed to turn it off but not on. I’m trying to use the lock feature but I don’t think I understand this feature correctly. Looking for a way to disable the button when status is off. Thanks
hide the button instead of locking it. Locking is to make sure you don’t miss click. Use a conditional card.
1 Like
yep, that’s what I was thinking I would need to do…thanks for your quick response
Thanks @AhmadK. That was the nudge I needed.
cards:
- color: 'rgb(255,0,0)'
icon: 'mdi:circle-outline'
styles:
card:
- height: 50px
- background: gray
tap_action:
action: call-service
service: remote.send_command
service_data:
command: Record
device: U-verse DVR
entity_id: remote.family_room
type: 'custom:button-card
On another note, I swear I will never understand the formatting of this stuff. For example, under “card:”, those items have to have a hyphen in front of them. Under “service_data:”, those items don’t have a hyphen. I never know what I’m doing unless I can find an example somewhere.
That’s a list vs a dictionary.
The docs will tell you what one it is or show you an example.
See how tap_action says object? That means its a dictionary of fields
See how styles says object list? That means you need to list items and also provide keys.
You should take the time to read and learn yaml. These are basic fundamentals of yaml and if you don’t understand them, you’ll have a bad time.
List: (list)
field:
- item1
- item2
- item3
dictionary, items that have names. (object)
field:
item1: value1 \
item2: value2 | - only object, no need for - in front of item 1.
item3: value3 /
list of dictionaries 
(object list)
field:
- item1: value1 \
item2: value2 | - first object
item3: value3 /
- item1: valueA \
item2: valueB | - second object
item3: valueC /
the - indicates the item, or the start of the item.
6 Likes
Your answer and thomas’s excellent yaml tutorial is very helpful for people learning yaml, but what keeps the confusing going is how Home Assistant parses the data (whether the - is implied or not).
For example, you have the ui editor and the raw editor in lovelace and the code you enter is different depending on whether you enter it in the code editor or in the raw editor. The same is true with the automation editor or if you use a file editor. For novice users learning home assistant, it makes it very difficult to try and figure out how the code should be formatted.
Other problems I have had has to do with how the !include works.
The different ways to use it are defined in the doc file
https://www.home-assistant.io/docs/configuration/splitting_configuration/#debugging-multiple-configuration-files
Again, a user needs to code the yaml file differently depending on how it is loaded from the configuration.yaml file.
So beside learning yaml (which is a must) a user must learn how HA inconsitently handles yaml statements. Most of my errors (and there has been a lot) was not that I didn’t understand that it was a list or a dictionary, it was that I didn’t understand how Home Assistant would take the file I created and reformat it.
Also which docs are you referring?
!includes are not driven by ha, it’s part of the yaml standard.
It’s actually simple. It alphabetizes everything. Nothing special.
if you configure:
b: 1
a: 2
c:
- z: 1
y: 3
what it will end up when you look at it after the UI modifies it:
a: 2
b: 1
c:
- y: 3
z: 1
The alphabetization occurs in the object only by the way…
b:
- z: 1
y: 2
- z: 3
y: 4
a:
y: 2
x: 1
ends up
a:
x: 1
y: 2
b:
- y: 2
z: 1
- y: 4
z: 3
No it is not that simple. Try creating a new card (non Lovelace mode) paste the same code in a create, manual card and in the raw editor. You will see that the user does not need the hyphen in the manual card ( implied) and does in the raw editor.
but that’s apples an oranges… the top level card in a manual card creation is the top level object… where as it’s not the top level object in the non-lovelace mode.
when viewing the whole setup… your context is this:
when you create a manual card your context is this…
I don’t think so. I believe this is what causes most of the confusion to new users. On the screen it says edit as yaml. It doesn’t say edit as a top level or any other level. I reading it think yaml is yaml. I think your map will be helpful.
Why isn’t the hyphen needed on the manual card?
If a document could be created showing where the contents are placed depending on where and how a user creates the contents I believe this would help a lot of users.
You need to think of these things as objects. Yaml is yaml. Yaml describes objects.
Because your only looking at the single card (object)! You aren’t looking at a collection (list) of cards (object).
This simple question can always answer whether you need the hyphen or not:
Am I putting in more than 1 item (object)? Yes=hyphen, No=No hyphen.
1 Like
If I edit in the raw editor you need a hyphen. One item.
Yes, and you have 1 item. A single view lovelace configuration. Which contains a collection of views. Each view contains a collection of cards.
WHen you create a manual card, you’re creating a single card. Not a view. Not the whole configuration.
The whole configuration needs a collection of views. Each new view needs the hypen.
The views need cards. Each card needs the hyphen.
When you are inside a view and add a manual card, it knows what view you are in and it knows you are adding a single card. The hyphen is not needed.
1 Like
I guess for long time users this concept is very clear. To me until you just explained it just now I had no idea what was going on. I was told that the hyphen was implied, etc. Anyway, I have tried to move as much as possible to yaml only and not use any other editor. It least until I am much more proficient I can enter the yaml code with dic, list etc and understand how the spacing should work.
Is there a similar explanation to each of the !include options?
Think of it as a viewbox…
Hyphen is still there… you just can’t see it cause you’re zoomed in on the object.
3 Likes
This is a perfect example. I now see also the spacing is taken care of for you. This is why I was having difficulties switching between the raw editor and the manual card creation. I had no idea what HA was doing. Maybe you can attach this to the official docs so others can gain from your knowledge?
Include options act the same way as the viewbox
when you do the merged list one, each separate file is a viewbox.
If you just do a normal include, the whole file is the viewbox.
These are the options:
- !include_dir_list
- !include_dir_named
- !include_dir_merge_list
- !include_dir_merge_named
I think (again I could be wrong) that this is slightly different than your answer?
