So this would also apply to standard automations, but as blueprints are the new hotness I am trying to learn from the Jedi-masters on here as to what’s efficient.
Roast away! Note this blueprint works, being used in 14 instances in my system that pass the WAF.
Note I am not fond of the redundant triggers but have not found a way to get the same as “for” in a trigger without feeling bulky.
Note2: The 3rd trigger is a timeout to auto-turn off lights after a long period; typically these are set to 240 minutes or so and to catch if kids manually turn something on.
Note3: The light_off is different as most of my rooms have a light group; so this automation turns on the preferred light in that group on motion; but when the motion clears and room assumed empty it turns off the group of lights for the room.
The most elegant way to start any blueprint is to have a robust, tested, working automation.
Then convert that to a blueprint.
Attempting to create a blueprint direct means you have to keep track of variables, logic interactions (karnaugh maps/truth tables), sequences, and the translations (to and from automations and blueprints).
Why make it hard for yourself ?
A grasp of the automation basics will serve in all circumstances.
Ie show us what you wish to achieve and work back from there
I was really hoping you and @anon43302295 would have some ways to clean it up. Those first two triggers bug me but seems the cleanest way to use the for.
@Mutt this did start out as automations, 14 of them being quite similar, so the move to a blueprint was to get more reusability. That’s why things like the time constraint as well as the override are optional. It’s my only blueprint as the only repetitive automations in my system; I don’t see the point of using a blueprint if only a single automation is going to use it.
But I agree with @123, it’s generally quite well structured. The triggers are what they are, they can’t be reduced any more. I think all the variables are needed because they are all needed for templates, and the choose decides whether the light goes on or off, and because you’re passing brightness and transition with the turn on you can’t use a service template there, so choose is the best option.
I’ll be honest, I’m not properly ‘in the game’ today so I didn’t really double check the templates, but if the only other option after the first choose is the second one, then that should be a default rather than another condition, but again that’s just nit-picking really.
I’m afraid I must confess I skimmed your post, the ‘preformatted’ code window shows a limited window without scrolling
I appologise.
Regardless given your previous contributions I should have known better, sorry
Could also be a switch, and they don’t take the brightness_pct and transition arguments, so I had to have the two paths.
I also tried to use the 2nd condition in the inner choose as a default but it kept complaining and figured there might be an issue with nested choose’s with a default.
I replaced it with default and the resulting blueprint passed Check Configuration and Reload Automations without complaint and was used to generate an automation.
FWIW, I recently adopted a different formatting convention for my automations. In a nutshell, wherever indenting is not necessary, then I do not indent. It’s a stylistic choice that results in the code remaining closer to the left margin rather than being pushed to the right.
Here’s the convention used for lists that I had followed; note the two-space indent before each hyphen.
Here’s the action portion of your automation using this convention. Compare it to the example in my previous post (above) to see how the code (especially the nested conditions) remains much closer to the left, and in full view, as opposed to being pushed out of view to the right.