Like many, I have a lot of flows now (229 of them, to be precise). I have tried a few different ways to structure and organise them since I migrated from Indigo to Homey about a year ago. For a long while I used the system described here How to structure your flows and it worked OK but I personally found it too cumbersome to maintain. I liked a lot of the ideas and principles but adding devices to enable strict separation of trigger and action flows, while a great idea, just didn’t work for me in practice. I found it would still take me ages to trace through chains of flows to find and fix faults. Also, I ended up with a tonne of devices and that cluttered up the device views making it hard to find what I was looking for. It’s also really user-unfriendly if you have other family members using the Homey app since they also get to see all your “inner workings” devices whether they want to or not.
So I came up with a new approach which is a lot simpler and which, having converted everything to it and lived with it for ~3 months now, I am really pleased with. So here it is:
Key points
- Flows are organised into folders (and, where necessary, sub-folders) based on the type of actions they do - such as: lighting, heating, security, presence etc.
- Each flow does one type of action (which obviously determines which folder/sub-folder it goes into).
- Each flow is named primarily according to the action it does and sometimes secondarily the trigger, where this is needed to disambiguate from another flow (e.g. “Bathroom fan on when humidity rises”, “Bathroom fan off when humidity falls”, “Log bathroom humidity change”, “Lights for day mode”)
The point about each flow doing only one type of action is the key here. Since we only have a folder hierarchy rather than tags for flows, we need each flow to belong logically to exactly one folder/sub-folder. Using the actions as the basis for organisation, the folder tree is based around action types and so each flow needs to do exactly one action type.
I have found that, for me, it’s the exception rather than the norm that I want one trigger to trigger more than one type of action (I often have more than one action of course, but generally all of the same type). For the exceptions, I simply duplicate the flow and put actions of one type in each ‘copy’ of the flow (with the same WHEN and AND cards in each). An example is my morning wake up alarm where I want to control the lights and the radio. One flow for all the lights control and one for the radio - with the same trigger (my wake up alarm in Homey) and conditions. These are filed accordingly into their respective places in the folder tree (“Lighting / Upstairs” and “Radios”, respectively).
Other top tips
- While you’re organising your flows, take the opportunity to add logging to EVERY SINGLE ONE. I use the Simple LOG app and the last action card in every single flow is a Simple LOG card
- To make this easier and more consistent, I use the “Add Something to a log group” card from Simple LOG and set the group name to the name of the folder the flow is in, showing sub-folders like this “Lighting / downstairs”. For the log entry itself, I simply use the name of the flow. This way, I can always see the exact sequence in which flows are triggering when I look at the log and if I need to go and change one, the log tells me where in the flow folder tree to find that flow.
- When using ELSE branches in the THEN section, I add a log card to each ELSE branch and append a logical description of which branch to the log - like this “Record bathroom light level (BRIGHT)”, “Record bathroom light level (DARK)”. This way, I can also tell from the log which branch of each flow was actually executed.
This helps to make up for Homey’s lack of a general-purpose log and makes fault-finding enormously easier. By looking through the logs I have several times found faults I didn’t even realise I had simply by spotting that I had flows triggering far more often than I intended (which was causing issues by clogging up the z-wave network with duplicate commands and slowing down other commands). When you have issues to track down later, you will thank your past self for making sure every single flow creates a clear and consistent log entry.
Why organise around actions rather than triggers?
My reasoning was that I wanted to make fault-finding and maintenance easier. Generally when I go fault finding it is because something either happened that I wasn’t expecting or didn’t happen that I was expecting. For the latter case (something didn’t happen that I was expecting), I generally go through the flow folder tree to find it - e.g. “why did the upstairs hall light not come on when I walked into the upstairs hall and it was dark?” → go look in the “Lighting / upstairs” folder for a flow called something like “Upstairs hall light on with motion”. Then if I can’t see the issue immediately, go look in the logs to find out whether the flow executed, which branch, which other flows executed before it if they were meant to set the conditions etc.
For the former case (something happened that I didn’t expect), I generally go looking in the logs for the thing that happened at about the right time. For example “why did the upstairs hall light come on when I walked into the upstairs hall but it was light?” → go look at the logs for an entry at about the right time called something like “Upstairs hall light on with motion”. If I can’t remember the exact time and I need to browse through a lot of logs, export them to CSV and then use a spreadsheet to filter only the log entries with the group “Lighting / upstairs lights”.
In both situations, I want the flows and log entries to be named and organised based on the action.
I hope this is useful for someone. Very interested to hear other experiences / approaches with this same issue.
