This is the forum archive of Homey. For more information about Homey, visit the Official Homey website.

The Homey Community has been moved to https://community.athom.com.

This forum is now read-only for archive purposes.

How do you organize all your flows?

Hi, I've been using homey for a couple of months, and I love it.
But after building loads of flows for different things, my flows are a total mess, and at the point of me thinking about just deleting everything and start over. Everything I want to do at home atm WORKS, its just that it's such a paint to follow all my flows, see which have dependencies on which etc.

How do you sort and categorize your flows?
Do you use some kind of standardized naming of your flows?
Do you actively follow a certain approach when you build flows, just for the sake of keeping them easy to follow and understand, or do you just make it work, and then leave it?

Comments

  • I have a folder ‘triggers’ which are flows that trigger something. For example a light switch turned on.

    i have a folder ‘classes’ that do the turning the light on, alarm etc.

    so trigger flows trigger class flows. This in order to prevent flows fighting.

    in both folders I have sub-folders based on rooms. And then another level of sub folders to group certain triggers/classes like alarm/movement/lights.

    it took a while to convert everything. But it’s easy to debug now. And I often only need to change a single class. 
  • quakerix said:
    I have a folder ‘triggers’ which are flows that trigger something. For example a light switch turned on.

    i have a folder ‘classes’ that do the turning the light on, alarm etc.

    so trigger flows trigger class flows. This in order to prevent flows fighting.

    in both folders I have sub-folders based on rooms. And then another level of sub folders to group certain triggers/classes like alarm/movement/lights.

    it took a while to convert everything. But it’s easy to debug now. And I often only need to change a single class. 
    ok, seems like a good approach, I think my biggest problem might be I've not been consistent with my "classes". Some of my trigger flows follow this logic, some just "do the thing" in the trigger it self.
    Are you grouping different classes also, for example if you have many different classes in the living room, are they grouped to one or a few different "livingroom classes".
  • Baron said:
    quakerix said:
    I have a folder ‘triggers’ which are flows that trigger something. For example a light switch turned on.

    i have a folder ‘classes’ that do the turning the light on, alarm etc.

    so trigger flows trigger class flows. This in order to prevent flows fighting.

    in both folders I have sub-folders based on rooms. And then another level of sub folders to group certain triggers/classes like alarm/movement/lights.

    it took a while to convert everything. But it’s easy to debug now. And I often only need to change a single class. 
    ok, seems like a good approach, I think my biggest problem might be I've not been consistent with my "classes". Some of my trigger flows follow this logic, some just "do the thing" in the trigger it self.
    Are you grouping different classes also, for example if you have many different classes in the living room, are they grouped to one or a few different "livingroom classes".
    Yeah, the follow often the same grouping as the triggers. 

    Im curious how other people do it. I frequently changed my structure, but this is the one that staid.

    what would help me is virtual devices that don’t trigger once changed. But that’s not possible as far as I know.
  • casedacaseda Member
    edited December 2017
    ik have it in this Tree type of structure:

    Zone/Room where it is happening
         |-> by what type it is triggerd (IE: motion on/timer/door sensor)
              if the trigger is in a different zone, i add the zone in square brackets behind it (IE: motion [Kitchen])
              |-> flow: short description what it does
              |-> sub type (IE: Fibaro Switch 2 Right) if there have multiple things like double switches
                   |-> flow: short description what it does
  • caseda said:
    ik have it in this Tree type of structure:

    Zone/Room where it is happening
         |-> by what type it is triggerd (IE: motion on/timer/door sensor)
              if the trigger is in a different zone, i add the zone in square brackets behind it (IE: motion [Kitchen])
              |-> flow: short description what it does
              |-> sub type (IE: Fibaro Switch 2 Right) if there have multiple things like double switches
                   |-> flow: short description what it does
    okey, so if I under stand that correctly, you will place both your trigger and actions/classes in the same folders if they are for the same room?

    Some one who has a strict and logic naming standard of their flows?
    I also name my flows with a short description, and in the folder structure, this is very good. But when i want to us a flow inside another flow the name can be important. If it's not descriptive enough, it's easy to mix upp a trigger and an action for the same thing.
  • I have been in the same situation. My flows where getting too complicated and too messy. This was because of the number of devices and the limitations of the flow editor.

    Now i have cleaned-up everything. The most complicated flows are now HomeyScript scrips. Scripts are much more flexible and if you do it right they can be faster than flows.
    With scripts you can do things you can't do with flows (without the need for external apps) such as rebooting and fetching info from other websites etc.
    I have a script for reading openWeatherMap info and a script for reading tvgids.nl info without the need for external apps.
    I have still a lot of flows. But they are way more simplified now.

    I hope Athom will make HomeyScript an official part of Homey.


  • @Baron:
    Regarding structure for naming flows:
    To start another place - the devices themselves:
    [node-id] [type]-[location] [manufacturer/model].
    Using the node-id makes it easier to make direct associations and search the devices in the list when making flows, adding type help choosing the right type, and manufacturer/model also makes it easier to search.
    Some examples:
    3.6 L-LR-Floor (PN6-LR): socket 6 in node 3, controlling the L(ight) øv the floor, in the L(Irving) R(oom) - being a Powernode 6.

    73 PIR Stairs (Fibaro): Node 73 being a motion sensor from Fibaro located in the stairs.

    Variables follow same nomenclature, only always with _ instead of -

    Then flows using same system:

    L-GF-dark-coming home being a flow controlling L(ight) at the G(round) Floor when it is dark and someone comes home.

    My folder structure is main folder named Basic flows with subfolders per room, another mainfolder named system including subfolders like Logs and Presence, a main folder called sensors and subfolders per room or type (fire alarms, flood alarms, motion sensors), a main folder called Devices work subfolders like Roomba and AC-Sonos.

  • thx for the input @cbh, I think it's a good logic. Even if I might add a type to the flows, to describe if it's a trigger, an action or both. To also describe linked flows (triggers needing multiple flows to do a thing) in the name would be beneficial.

    @tb1962, I haven't looked in to the HomeyScript yet, but I think I'll need to do that, I have quite a few triggers that consist of multiple flows, just because of the lack of flexibility in the built in flow-feature.
    To just be able to do loops and nested if/elseif/then would eliminate a big number of flows and global variables.
  • PovlovPovlov Member
    edited March 2018
    Do not underestimate or forget to use the search box when you work on flows.
    It easily finds all flows in any subfolders with a certain device, text content, whatever.
    My flows are grouped as I developed skills and added devices. But as I know the use of the search box will do fine, I can be sloppy at using my own poor "structure rules"
    1. Main > only 6 folders, ideally All would carry all of course!!
    2.  "All" contains a whole row of subfolders, functional, device, randomly.
    3. As example I opened "Slapen" for you. Most of my action flows contain "this flow is started" as an action card. So Naarbedspraak or Naarbedmodusaan (activated by VT ) and Virtual Switch "NaarBed") are three ways to trigger the same actionset.

    Flows in "Test" contain cards to enter a line in papertrail or simplelog so that I can trace the functioning of new flows. When they work they make it into "All" and I usually cut the trail-card after a while.

    It is much like all the drawers and boxes  in my workshop. Only I know where to find things. Usually because items are in some way related to each other, often just because there is a visual map in my head... Makes sense? 



  • BTW: Of course you are puzzled who Rosie is.
    Rosie is the new Philips Vacuum-bot. She starts her job when Homey gives her the InfraRed look.
    So she really does  <almost>  what you thought she would do... 
  • Baron said:
    caseda said:
    ik have it in this Tree type of structure:

    Zone/Room where it is happening
         |-> by what type it is triggerd (IE: motion on/timer/door sensor)
              if the trigger is in a different zone, i add the zone in square brackets behind it (IE: motion [Kitchen])
              |-> flow: short description what it does
              |-> sub type (IE: Fibaro Switch 2 Right) if there have multiple things like double switches
                   |-> flow: short description what it does
    okey, so if I under stand that correctly, you will place both your trigger and actions/classes in the same folders if they are for the same room?

    Some one who has a strict and logic naming standard of their flows?
    I also name my flows with a short description, and in the folder structure, this is very good. But when i want to us a flow inside another flow the name can be important. If it's not descriptive enough, it's easy to mix upp a trigger and an action for the same thing.
    So there is now way to describe the flow inside it? even if the flow is easy a function should alwayes be descibe even if just a sentence or two in a header or so. also all as I understand all variabels is global it is bound to be a mess. as a software assessor I can't understand why this basic proggram need is not forfilled and informe there closes acting boss that they might re-think if they shoulden't hire someone else. maby just me having a long day but just terible
  • rickprickp Member
    1 map per room.
    1 map per specific function like presence / nfc / etc 
Sign In or Register to comment.