I have an automation that I would like to trigger at both sunset and sunrise. Right now I have it working like so:
trigger:
- platform: sun
event: sunset
- platform: sun
event: sunrise
Is there a more consolidated way to do this? I tried making a list like:
trigger:
- platform: sun
event: sunset, sunrise
but that dint work. Just trying to learn… thanks!
The only other way to “simplify” the triggers would be to use a value_template but I wouldn’t think you’ll get much value out of it.
If you do a state trigger on the entity sun.sun, it will trigger on any state change of the sun. But I think that includes attributes to, so it would trigger when the elevation changes too (e.g. Constantly).
It’s good to keep your automations simple and concise. But, someone chargin’ ya per line? 
Ha! I’m just trying to learn. It’s still confusing to me, when you use a list, maps, etc. I’m still at the stage where it seems arbitrary. It’s like everyone knows a secret and I don’t 
Since the sun component only throws events on sunset and sunrise, can you just omit the event: attribute?
trigger:
- platform: sunYes, that would work. But where/how do I find out that those are the only two events the sun platform throws?
EDIT: No, that doesn’t work. You have to put sunrise and sunset as separate triggers. But my “how does one find these things out?” question remains.
But what do you mean by list, maps etc? What are you trying to do? The best way to learn is first think of what you want to do, then search the forum and/or ask. There’s lots of us that are willing to help.
The sun trigger documentation clearly lists the possible values.
However, I agree there are plenty of undocumented or unclear things. My only advice is that if you learn of such things that are muss in the documentation, update them on github. 
Yeah, that’s what I do now, search, copy, trial-and-error, etc.
What I mean is that sometimes a construct like this is needed:
thing_to_config:
option1: blah
option2: blah
sub_option: blah
and other times you need:
other_thing_to_config:
- option1: blah
- option2: blah
sub_option: blah
Sometimes you can do:
entity_id: sensor.my_sensor1, sensor.my_sensor2
and sometimes that’s an error and you need to do:
data:
entity_id:
- sensor.my_sensor1
- sensor.my_sensor2
I’m missing the key piece of info or description keywords in the docs that makes this not seem completely arbitrary and random 
It’s definitely not random lol. And yes, I understand, there’s a steep learning curve since EVERYTHING needs to be configured.
The best place to start is to read the documentation.
Next, add some components from the components page
Once you have a few configured, try a simple automation like at a certain time, trigger a light on. Here’s an example:
Finally, when you are stuck, just ask a specific question. Hope that helps. Sorry, there’s no magical way of getting everything to work without a lot of elbow grease. 
I have a pretty complete setup already… ~45 z-wave devices, ~10 or so automations, etc. It’s all working so far. I’ve had SmartThings since they exited Kickstarter back in 2013 and wanted to move over to HA. So started that about a month ago.
Since you’ve been so kind as to reply… how do I know when I need to do a list (items denoted with a “-”) or not (which I belive is just a map/dict)? I’ve read the docs over and over… and some places one is used, some places the other…
That may be, but I wasn’t expecting that the “official” documentation of what all options are for a platform would be in a comment in an example code snippet…
@ha_steve
I’m not 100% sure on that myself. You’re right it is sometimes inconsistent. Probably due to multiple contributors or some components not being updated in awhile.
That’s cool - just wanted to make sure there wasn’t some decoder-ring that I should get, but somehow missed.