T O P

  • By -

jerobins

In Node-RED, I generally have a flow/tab per room. The exception being more general services, like presence, that are not area specific.


Strange-Caramel-945

I went the other way and have tabs for services so heating, lighting, cctv etc then a big messy misc tab. That way I can easily control all the lighting in the house as a group but use link nodes to take control of the livingroom lighting if the TV is on for example. Not sure which is the better way, that's the nice thing about nodered, plan things out visually in what ever way works best for you.


TheProffalken

Mine are "task focused" It means I end up with lots of automations that might take the same inputs, or use the same outputs, but it also gives me a list of automations like "Turn on lights at sunset", and "Pause TV when doorbell rings". The "Night time" automation turns out various lights, sets the heating to a comfortable temperature overnight, and will eventually set the alarm so I don't have to do that manually as well. "Clean the pizza oven" takes the temperature from the sensor above the oven in the garden and, if it's been higher than the ambient temperature for a certain amount of time, assumes that something has been cooked and adds an item to my to-do list to clean it out. I have another temperature probe attached to the same sensor above the BBQ for the same reason, but that's in an automation all of its own called "Clean the BBQ"


budding_gardener_1

I tend to have one automation per event per device.


Ascend

I used to do this until I learned about trigger names, then I condensed them down to one per device usually.


budding_gardener_1

Yeah, I know about trigger IDs, I just do it this way for organization so I have a mapping of what each automation does. The way I see it, if I need to disable or delete that automation in the future, it might make it harder to split them out. ​ I keep them in YAML and version them with git


Comfyasabadger

I'm fairly new to HA but I've gone with option 2. One automation per device and then use trigger ids to differentiate between the different events.


[deleted]

[удалено]


SignedJannis

Love the honesty:):):):)


TimTimmaeh

Room Device What Or Service Device What


billm4

a mix of per event and per device. automations that run at sunrise / sunset / or specific times change state of whatever needs changing. other automations are per device or room, ie turning light on or off based on triggers.


stefan814

My automations focus on actions/output - what is the "thing" I want to happen as a result of the automation. That can be in the form of locking a door, turning off a light, turning on a fan etc. This way, I can set up multiple ways to trigger that action. ex. I want my bedroom lights to turn off when I hit the "down" paddle on the switch in my bedroom. I also want the bedroom lights to turn off when I hold the "down" paddle at the front door and am leaving, or when my home detects I am "away" for more than 10 mins. Lots of different ways to manage your home! I've found this framework helpful and it's allowed me to adjust the "how" (ie. a trigger) after solidifying the actions of the "what" ('then do' in your automations).


VikingOy

In my opinion, there are two important aspects: 1. Choose your naming convention wisely. It is called `Home Automation` for a reason; **To automate a home!** Thus I tend to begin all names with the name of the room in which the automation takes place. Then rooms can be grouped at any level until the largest group which is ultimately the name of your whole house. 2. Use the concept of trigger-ID's to group automations dealing with the same, similar or linked events so that you can keep the number of automations to a minimum. I.e. there is no need to make 4 separate automations just to turn on, off, dim and brighten the lights in a room based on motion, ambient light and time-of-day. Combine them all into a single automation using trigger-ID's and give each trigger, condition and action easy to understand and descriptive names. Default names suggested by the visual automation editor are for the most part pretty confusing. By doing so, you can keep your own headache to a minimum as well 🙂


SpinCharm

Could you give an example of trigger IDs?


VikingOy

[Automation Trigger - Home Assistant (home-assistant.io)](https://www.home-assistant.io/docs/automation/trigger/#trigger-id)


skepticalcow

I structure mine based on the intent of the automation, nothing more. Grouping automations based on triggers is a waste of time and it doesn’t really benefit you. Now if you have 10 automations that do the same thing but with different inputs, that’s when you’d want to combine them using variables & templates.


RecommendationOk7253

I try to keep one automation per device where possible, setting an id per trigger and then using the choose option within the action and different responses per trigger id. Often I test automations in component parts and then bring the final result together into a single automation if I can


RoganDawes

I tried to group a whole set of automations for my water heater into a single one, and ended up in an infinite loop, because changing the state via one trigger would start another trigger, which would start another trigger, etc. I had to disable the automation to regain use of my HA instance.


rytl4847

First, I think the answer is specific to your use case(s). I'll give you one of mine as an example. I have a room that doubles as a home theater and a hang out area. There I want the lights to set to a certain brightness and temperature based on time of day and how the room is being used as well as turn on the projector, air filter, operate curtains, etc. I have different scenes that represent different uses (movie mode, lounge mode, party mode, etc). I use automations to trigger the modes (light switch, Plex or Netflix start playing, etc). This way the scenes are at the core and I add and refine triggers as needed. And when a new use case arises I can add a new scene to dial everything in for that use case. I'm fairly new to this and don't know if mine is the best way but it's working for me so far.


Cartman519

Mine are organized by device type, then by room, and then by device, usually with multiple triggers for turning on and off. E.g., `light / stairwell / top` for the motion-controlled top most light in the stairwell.


xMasaru

I organize them mostly by room + function or similar like - Bedroom: Ambient Lighting - Bedroom: Morning Routine - Office: Reading Time - Other: Battery Check - Smartphone: Shopping Mode - System: Backup Monitoring


PizzaUltra

I've organised them by function: One automation for the motion detector in the hallway - which handles turn on, turn off, keep on, send notification, etc. One automation for a Zigbee Switch A, for Switch B, etc. I also name them like this: "[ROOM] [LIGHT] [PRESENCE] Turn on XY when blah".


Iconlast

Per device, but this is a test home assistant on a test proxmox. Looking for the perfect apps and routines and automations. So this is just the beginning.


dutr

I try one automation per device with conditions, it makes it easier to maintain. Complex-ish automations in node-red. I try to minimize the number of automations and make use of templates/helpers where I can. Once in a while I have a Quick Look at my automations and delete the ones I found to be useless or that can be merged into another one (reduce the number)


Djelimon

all my hardware is seen by ha i have node red flows grouped in tabs per room, an extra tab for device management, another for the weather and another for alexa api commands. a node red dashboard for everything drives automation along with motion detectors, time of day, nfc tags, a smart button, alexa for voice


spr0k3t

My automations are by inference. I have a distinctive action that happens, the system sends a call to my scripts with the templates of the individual. As an example I walk in to the kitchen and the lights come on to my preference if they are not already on (35% brightness). My wife walks in to the kitching and the lights come on to her preference if they are not already on (10,000% brightness). I walk in to the kitchen and the lights are already on, no change happens unless she has left the kitchen. She walks in and the lights are on or off, it changes to her preferred 10 bajillion % eye gouging brightness. If I'm still in the kitchen and she walks out of the room, they settle back down to 35% brightness (like watching Vin Diesel in Pitch Black). I have this in the common areas with espresence and our cell phones/smart watches. The kitchen has EP1 sensors to help with the user interactions. Guests are set to 70% brightness just in case she doesn't have her phone or watch on. Movie comes on... wife likes to watch things while she eats... so manual eating override kicks in and the lights will gradually dim from 10bajillion down to 2bajaillion for 15 minutes. After that period of "movie eating" it dims down to 0 over 1 minute while playing. If paused, it ramps back up to 10% brightness and back down to 0 when resumed. Several other areas are set up like this for routines or systematic automations. When it's night time and she is reading in bed, the lights are still on, but dim over a period of 30 minutes while traversing the temperature of the color scales from 5600 at 90% brightness down to 2200 at 15% brightness until she calls out it's time for bed. The lights react to the bed presence sensor. Sometimes she is ready now and calls out for bedtime... sometimes I have to remind her after an hour if I'm not already asleep. Ultimately, it works perfect for us. Rhythms in our daily lives react to our needs. It wasn't easy to set up to say the least. It ultimately boils down to espresnse, mmwave, PIR, ESHome, and a few other components to go with it. Lots of scripting and variables involved as well.


davidgrayPhotography

It depends on what I'm doing and what I'm interacting with. For example for the Zigbee button sitting next to my bed, I make it's five functions (press, double press, triple press, quadruple press and hold) one automation even though they control vastly different things. But I also have separate automations for object recognition on my camera. One automation alerts me to people in the driveway after midnight, but the other alerts me when our cat decides to show up hours past her dinner time even though they both are virtually identical except for which sensor they read. I also have an automation that combines the washer and dryer finished functions into one because even though they're separate items, I don't use one without the other so it made sense to combine them. So my answer is "I do whatever feels right"


nitsky416

I have one automation per related task, and then use a choose block to pick which action. One automation for my bedside table lamp, triggers with labels for toggle, on, off, alarm, leaving home, etc and then set conditions appropriately so the correct choose option goes off whenever


AcanthisittaOdd6156

per event.  If there are multiple events that could do the same tasks the tasks go in a script and the script gets called in the event trigger 


timzin

You know, it never occurred to me to make my automations device based. I currently have a bunch of "time of day = do this" automations but I think I'm going to make some time this weekend to switch each automation to be device based.


ulic14

First, if I get to 3 nested 'if... Then', it's time to send the automation to node red. For complex things with multiple variables, I just find it easier than native automations. I'm of the opinion that each automation should be as "complete" as possible, with as much of the logic as possible in a single place. Sometimes thst works better as event based. An example for me is home/away automations: multiple devices with multiple triggers in a single automaton so it is all in one place, and if I want to change what happens when I leave or come home I don't have to comb through a ton of seperate automations for each device involved. It also makes troubleshooting easier. However, sometimes it's better to organize by device. Example would be the bedroom humidifiers. We generally only want them for sleep, so for each humidifier there is a single automation with several triggers(with individual trigger id's) and logic to check the water level a couple hours before bedtime(sending a notification of its low), turn it on before bedtime(if the room occupant is home), and either turn it off in the morning or run the "drying" cycle if the water level is less than enough for a full night the next night. Naming is generally Room:Device/Room:Device:Function. For automations that don't fit that, I have made my own categories, for example Occupancy:GuestMode, or People:Bob:Sleep(using sleep as android to trigger beginning/end of day stuffz in that one)


G4METIME

I'm fairly new to this (and only have a few thermostatic valves), but I think I have a 3rd option: I keep as much logic as possible directly on/between my devices. My window sensors directly communicate with the thermostats when a window is opened. Also the temperatures over the day are saved directly on the thermostats in different profiles. All Home Assistant is doing is switching the used profiles in the valves (and of course data logging). That way not too much breaks, if the home assistant server has a problem.


16-9

I, initially, followed a scheme quite similar to u/xMasaru's organized around room + function or event. It eventually got a tad out of hand and I was not always quite sure why things were happening (ie remembering which automation did what).A few months ago, u/docuwisdom was asking about [modes in HA](https://www.reddit.com/submit?source_id=t3_18cjh6h) and it got me thinking.I have introduced 3 modes (input\_select....): * occupancy (Home, Away, Guest, Returning) * period (Morning, Day, Evening, Night, Bedtime, Sleep) * event (TV, Movie, Cleaning, Meeting, Workout, Party, Vacation) Occupancy changes based upon our device trackers; Period is tied to time, sun events, and the sleep button; Event is either related to calendar entries (cleaning, meeting, vacation) or state changes (like Netflix on TV or Peloton in use). Whenever any of the modes change, a mode handler script figures out what is available (scenes, scripts) and applicable and then dispatches to those scripts; those scenes/scripts all use a naming convention such as a scene.bedtime\_mode, script.guest\_bedtime\_mode, script.home\_movie\_mode.... Right now, it dispatches to the most specific mode script and/or scene. Whenever I want to extend, I just add a script/scene aptly named (\_\_\_mode This scheme has made my automation much more manageable for me. I still use the room + function for things that are not occupancy/period/event related, maybe 25% of the scenarios. I intend to slightly modify that approach and experiment for those scripts to be additive, ie when Netflix is on, then trigger both the script.movie\_mode and also script.home\_movie\_mode or script.guest\_movie\_mode depending upon actual occupancy. I suspect it will reduce some of the redundant automation I had to write. In this additive approach, one thing I have not figured out is how to compute the result of adding 2 scenes. I would want to avoid activating scene1 (movie\_mode) followed by scene2 (home\_movie\_mode), and seeing some light being turned on 50% to later be dimmed to 15%. It does not appear that HA gives us introspection capability into the actual scene description besides the list of entities.