# Developing flows: tips and best practices **URL:** \ **Category:** Flows\ **Tags:** flow\ **Created:** [October 4, 2024, 3:12pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362 "2024-10-04T15:12:44Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 4, 2024, 3:12pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/1 "2024-10-04T15:12:44Z")
Note: - It is based on personal preferences, but this may help you to assess what works for you and develop your own style. - Various links to specific solutions/flows in this community, - You will see in past and present examples an evolution from simple flows to advanced flows and various styles. - A number of apps mentioned (eg. Advanced Triggers, Advanced Virtual Devices) are best used when you have some experience in flows. 1. Avoid starting flows at a specific time; other triggers are preferred. 2. Avoid dis/enabling flows in a flow 3. Avoid ALL cards for simplicity 4. Group triggers and central logic 5. Split flows into functional parts, connect them with for example “Flow is started with” cards, virtual triggers, advanced virtual device triggers or Advanced Triggers. 6. Use a logging app to trace flows (and use notifications for select events) 7. Use Note cards to document flows. Use a note color system. 8. Avoid constructing flows with app specific devices: Instead, try using zones and (advanced) virtual devices or Groups 9. Use zone timers where you can to avoid building your own timer 10. Use advanced flows. Limit the use of simple flows to cases where you may want to change the flow on your mobile app. Align cards in advanced flows consistently so you can read them back efficiently in the future. 11. As timer (that can be interrupted) use Chronograph, limit the use of built-in Delay timers 12. Variables: Use logical names for variables so you can trace back what they are used for. An advanced virtual device can be used to store text/number/boolean variables that are related to each other. These device variables will not show in the logical variable list. 13. Did I mention to use zone cards where possible? (WHEN, AND, THEN). Great for motion, alarms, devices, etc. Examples: > [@Are there any best practices for building advanced flows?](https://community.homey.app/t/are-there-any-best-practices-for-building-advanced-flows/114605): > > I have been using a Homey 2019 for several years now. I have a large number of different devices with various protocols mixed together, ranging from lights and a multitude of sensors to shutters, and from heating with smart radiator valves to a weather station and more. I started with Basic Flows, and later, when Advanced Flows became available, I gradually rebuilt all my flows. At the moment, I have divided my flows into those that detect something, such as light levels, temperature, or prese… > [@Help with creating an advanced flow](https://community.homey.app/t/help-with-creating-an-advanced-flow/106096): > > I have been trying to create an advanced flow to start my (dumb) air humidifier through smart plug and an air quality sensor. I have been able to create three simple flows to make this happen but can’t combine them to one advanced flow. The flow should work like this: When: air quality sensor reports low humidity alarm on And: Time is between 19.00 and 06.00 Then: Turn on the humidifier plug When: Low humidity alarm goes off And: Time is between 19.00 and 06.00 Then: Turn off the humidifie… > [@Water heater flow](https://community.homey.app/t/water-heater-flow/111070): > > Hello I am a newbie con homey pro flows, and I don’t manage to make a water heater flow. I just want to heat water between 4:00 am and 7:30 am between 55ºC and 65ºC, and also to turn off heater at 7:30. Also I want create a security flow to turn off Heater when water reach 70ºC every moment. Now I have this flows > [@Reevaluate IF after 10 mins](https://community.homey.app/t/reevaluate-if-after-10-mins/111061): > > Hi, I 'm new to the advanced flows and have soms questions… I want to start charging my EV when I have -1500 Watt power because of my solar panels. The first part of the flow works: charing starts when power -1500 Watt (Homewizard P1 meter). In the second part of the flow I want a 10 min counter to be started when the power goes +4000 Watt. After the 10 min counter is done I want to reevaluate if I still use more than 4000 Watt. If yes =\> stop charging If not =\> continue charging and star… > [@Help to create a flow](https://community.homey.app/t/help-to-create-a-flow/109849): > > Hello, i’m trying to do the following flow : If the light level of my fibaro sensor is too low AND a movement is detected (by the same fibaro sensor), i want to turn on a light for 10 minutes timer before to turn off. But i dont know how to do that in an advanced flow Can you help me please ? pray > [@\[APP\]\[Pro\] Simple (Sys) LOG - Use this app for Simple (Sys) Logging](https://community.homey.app/t/app-pro-simple-sys-log-use-this-app-for-simple-sys-logging/77533/433): > > Not to take anything away from the deep dive in the recent messages about servers, I would like to stress the simple use case for many: just logging and sending notifications without using any servers. With the addition of BLL in the Simple Log cards, its use for logging is efficient and obvious. PS @Arie_J_Godschalk I will submit a feature request for an AND card with a list of severities. That would be more efficient than text based Logic AND cards (“…is exactly”). > [@Trigger for multiple conditions](https://community.homey.app/t/trigger-for-multiple-conditions/107301/6): > > If the above is what you wanted, then below a better version where the logic is placed in the middle column and is checked after every trigger. I think it is easier to read. > [@Beginnede flows tips / idee](https://community.homey.app/t/beginnede-flows-tips-idee/108057): > > hallo Ik ben al een tijdje bezig met homey pro 23. Nu loop ik soms wel is tegen dingen aan dat ik denk volgend mij kunnen flows beter of gestroomlijnder. Hopelijk kunnen jullie mij helpen of dit nou een beetje een juiste manier is? Of dat dit soort flows beter kunnen? Zal er een voorbeeld bij doen en ben dan ook nieuwschierig naar hoe jullie dit zouden doen? Dank alvast. (use Chrome automatic translate to English for Dutch examples) (edited) ---
**Author:** ![Dijker](https://avatars.discourse-cdn.com/v4/letter/d/b9bd4f/32.png) [@Dijker](https://community.homey.app/u/Dijker)\ **Post date:** [October 4, 2024, 3:16pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/2 "2024-10-04T15:16:30Z")
> [@Rrrr](#): > > Avoid AND cards for simplicity Guess you mean the ALL operator in Advanced Flows? That one isn’t an AND card hence it has the name “ALL” … ---
**Author:** ![dsdevries](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/dsdevries/32/80220_2.png) [@dsdevries](https://community.homey.app/u/dsdevries)\ **Post date:** [October 25, 2024, 11:44am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/3 "2024-10-25T11:44:45Z")
> [@Rrrr](#): > > - Avoid starting flows at a specific time; other triggers are preferred. > - Avoid dis/enabling flows in a flow > - Avoid ALL cards for simplicity I agree on most of the points except for the first 3. For the first 2, I actually advise the opposite. I also apply point 5 to split larger flows into their triggers and their functional part. However, sometimes I just want to disable the flow based on conditions. I can also do that by creating a boolean variable and check it with the logic card inside the flow, but there are 2 issues with that. The first being, clean coding guidelines state that you’ll want to create variables as locally as possible to avoid them being misused by other components and prevent unexpected side-effects. However, variables and tags in Homey are always global. Meaning, you cannot guarantee that the value is what you expect it to be. The disabled state of a flow on the other hand is very local to the flow and its meaning is absolutely explicit. It will never have an unexpected effect on any other flow. The second problems with using variables and logic state is that it is effectively slower. Homey already has a system that will always check whether or not a flow is enabled before it runs it. Why would you let that always resolve to true only to then do another check inside to flow itself? Homey flows and cards are all nicely build on promises. If a homey flow can’t be started because it’s disabled, the promise will be rejected early. When it comes to point 3. This is ridiculous actually. If you do any type of advanced logic, you will come across situations where you want multiple conditions to be true before you continue. Sure you can check them all one by one. But like I said before, Homey’s cards are all just based Promises. The “All” card is basically a wrapper around Promise.all. It will you to run all cards simultaneously and reject as early as possible. This will make your flows run way faster than if you were to check all conditions after each other. ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 25, 2024, 12:05pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/4 "2024-10-25T12:05:56Z")
> [@dsdevries](#): > > However, variables and tags in Homey are always global Not true. Here a few examples: - You can start flows with a variable text, number or boolean. - There’s a very useful app [Advanced Triggers](https://community.homey.app/t/how-to-handle-multiple-triggers-resulting-in-one-action-in-advanced-flow/89283/3) that lets you pass multiple local variables. - BLL formula as tag: [here](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/20) Related: You can also store variables in an Advanced Device ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 25, 2024, 12:33pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/5 "2024-10-25T12:33:42Z")
> [@dsdevries](#): > > Sure you can check them all one by one Correct. And if you construct the flow to check in the right order it’s efficient. A single flow and logic makes for easy readability. Using ALL (when it fails) can: 1. Complicate the remainder of the flow because you don’t know which condition(s) failed. 2. Require additional flows to deal with the conditions that fail 3. Make it harder to read/follow the meaning of multiple flows I’ve given examples that show this. But no problem if you find it’s working for you as experienced developer. ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 25, 2024, 1:00pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/6 "2024-10-25T13:00:27Z")
> [@dsdevries](#): > > However, sometimes I just want to disable the flow based on conditions > [@dsdevries](#): > > The disabled state of a flow on the other hand is very local to the flow and its meaning is absolutely explicit. It will never have an unexpected effect on any other flow If you found a solid way of working with enabled/disabled flows, I’m interested to see it. I found it hard when debugging to know if a flow was enabled or disabled at the time of running as the system doesn’t trace that. Having enabled/disabled flows is another element where you do not have most logic in a single view. Readability and debugging are important factors for me. Again, it’s personal preferences and one will evolve or change programming styles over time. ---
**Author:** ![dsdevries](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/dsdevries/32/80220_2.png) [@dsdevries](https://community.homey.app/u/dsdevries)\ **Post date:** [October 26, 2024, 8:41am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/7 "2024-10-26T08:41:51Z")
> [@Rrrr](#): > > Using ALL (when it fails) can: > > 1. Complicate the remainder of the flow because you don’t know which condition(s) failed. > 2. Require additional flows to deal with the conditions that fail > 3. Make it harder to read/follow the meaning of multiple flows I wholeheartedly disagree with any of this. I work as a software engineer. And in my company we even have a linting rule that prevent you from awaiting multiple promises in sequence if they are not dependent on each other. This is because it is just unnecessarily slow. The “All” cards themselves don’t have any error handling indeed, but that is because you would already handle that in the cards you want to await. Here’s an example on how The all cards dramatically improve performance. In my example I took some fictional api calls that return in pretty decent response times. I’m not saying that all flow cards will be this slow, but with the principle that each flow card is basically an abstraction behind a promise, you simply don’t know how long it takes for a card to resolve. You can also see that I add error handling on each step where something could go wrong. The “All” card really didn’t prevent me from anything i could do in sequence. It also didn’t massively increased the complexity of the flow. I just added the “All” card and reconnected some wires. All it did was massively improved the speed of the entire flow. So if you really want your homey to perform fast, I really suggest you dive in to it a bit further. ![Screenshot 2024-10-26 at 10.15.35](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/0/5/054ae1f0eee3576790d739f23e78ca84921fa244.jpeg) ![Screenshot 2024-10-26 at 10.16.34](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/2/9/29e3db6cdd624554dfb1c134142932b9d41493c5.jpeg) > [@Rrrr](#): > > Not true. Here a few examples: > > - You can start flows with a variable text, number or boolean. > - There’s a very useful app [Advanced Triggers](https://community.homey.app/t/how-to-handle-multiple-triggers-resulting-in-one-action-in-advanced-flow/89283/3) that lets you pass multiple local variables. This is not the use case I was describing. I know that you can pass variables from one flow/chain to another. But I sometimes also want to remember state for a longer time even after a flow/chain is finished. This can only be done in setting a global variable or tag. It would be very handy if Homey would let you declare variables and tags scoped to one advanced flow, but sadly that’s not the case right now. I know that there are flow cards that create and return so called local tags, but in reality these are just global tags that are deleted again after a few seconds. > [@Rrrr](#): > > If you found a solid way of working with enabled/disabled flows, I’m interested to see it. I have found a nice way to work with disabled flows. Of course, the system doesn’t traces disabled advanced flow that have listener cards in them. I only disable/enable those subroutine flows that you identified in point 5. These flows are only triggered by other flows with the “Start [flow] with [tag}” card. This card can be traced, as it will throw an error when the flow it wants to run is disabled. I also do not recommend disabling flows that has listener cards, but for subroutines it can be quite useful. Here I have an example of how I combine the use of disabling/enabling of flows, and the All/Any cards effectively in my flows. In these flows I programmed my living room lights to autonomously dim depending on different times of the day and the measured luminance of my motion detector. During the day I want the luminance in my room to be around 200lx, while at night I want to dim to a more cozy atmosphere. I also configured two moods to override the autonomous dimming for watching movies or practicing yoga. When I activate one of these moods, the autonomous dimming flow is disabled. When I activate the Autonomous Dimming Mood, the flow is enabled again and then run at least on time. In my flows I already removed all error handling cards because these flows have been running very stable for over a year now. But the principle remains the same as the above, you can just add error handling on each and every step if you want. ![Screenshot 2024-10-26 at 09.35.31](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/a/e/ae9113a4839ba354e7987e2cee6e45a50fd2da99.jpeg) ![Screenshot 2024-10-26 at 09.37.18](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/0/4/043381eb36805341252769636f2fac1feef9a88b.jpeg) ![Screenshot 2024-10-26 at 09.40.02](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/6/d/6d35f6a2d5d3d1622002d98fbf2ef4aced8a1352.jpeg) ---
**Author:** ![dsdevries](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/dsdevries/32/80220_2.png) [@dsdevries](https://community.homey.app/u/dsdevries)\ **Post date:** [October 26, 2024, 9:54am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/8 "2024-10-26T09:54:07Z")
> [@Rrrr](#): > > Again, it’s personal preferences and one will evolve or change programming styles over time. Also, if your intent was to share some experience and things that worked for you, then I would also suggest to change the tone of the post a bit. If the title of this article would be something like: “principles that I found worked for me”, then my response would have been different. But a title including words like “best practice’s” and sentences like “avoid this” really suggests that people should adhere to these rules. It’s statements like that that are bound to cause a discussion. New people on this forum that are also new to Homey, Home automation or to programming in general that read these posts will think that they should follow your principles that worked for you, thinking that they are best practices while in fact, there’s no real evidence to back up that claim. ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 26, 2024, 10:29am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/9 "2024-10-26T10:29:47Z")
ALL cards: you’ve described a good use case where using ALL works well and fast and is justifiable to use. However, there’s fast and there’s being CPU efficient. Your fastest result has simultaneous branches. If they are very CPU intensive you have to take into account that the CPU can take less care of other important events outside of this flow. Again, the CPU of the Homey pro is pretty good, but if you have many simultaneous flows, you need to take it into account. My comments where for different use cases as shown in examples. And I focused on readability and ease of debugging in those cases. Disabling/enabling flows: You showed a nice example where this works for you. It’s a tool that Homey offers, but I’ve already provided my view. And it’s not that black or white either. Thanks for your contribution. ---
**Author:** ![Peter\_Kawa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/peter_kawa/32/173848_2.png) [@Peter\_Kawa](https://community.homey.app/u/Peter_Kawa)\ **Post date:** [October 27, 2024, 1:48am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/10 "2024-10-27T01:48:42Z")
> [@dsdevries](#): > > would also suggest to change the tone of the post a bit. If there is such thing as a tone in posts, it’s very hard to ‘read’, and it also depends on your own state of mind at the time of reading. I also don’t agree with all recommendations by Rrrr and you, but we always can discuss about it as fellow users? Your ‘tone’, _ **to me** _, is also not the kindest, sorry. > [@dsdevries](#): > > New people on this forum that are also new to Homey, Home automation or to programming in general that read these posts will think that they should follow Hmmmm I think you are getting a bit off track here, don’t you think? Imho most people can think for themselves, and do realize it is a _user’s post_ with some info which might come in handy. Forum posts are not “The Only Truth”. Thanks Daan! ---
**Author:** ![JohanP](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/johanp/32/119002_2.png) [@JohanP](https://community.homey.app/u/JohanP)\ **Post date:** [October 30, 2024, 3:50pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/11 "2024-10-30T15:50:11Z")
I’m missing a hint here: According to Flow Checker I have : 8 flows and allready 85 (!) variables. I do a lot of math for energy usage and PV’s… Is the an advice on how to keep track of all varables and where the ‘belong to’ or are used in ? And sorry, I don’t think I can do with less variables… ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 30, 2024, 4:10pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/12 "2024-10-30T16:10:35Z")
@JohanP Good point: I have added variables to the list in the OP. - There may be a way to use less variables if you can show us what they are used for. - Use a naming structure for the global variables according to their use (which most likely you’ve already done). - One alternative is to set up an advanced virtual device with text/number/boolean variables. You will then have in one view all the variables related to the logic you are implementing. ---
**Author:** ![JohanP](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/johanp/32/119002_2.png) [@JohanP](https://community.homey.app/u/JohanP)\ **Post date:** [October 31, 2024, 7:55am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/13 "2024-10-31T07:55:52Z")
Like I said, I do a lot of math to calculate daily usage of power, how much the PV’s produce, how much I deliver back to then Net, how the % of direct-use is etc. So I need to store the numbers of a dozen of counters, and the sum of them, the difference between these at the start of the day, and at the current moment, and the difference between them… The flow is ‘in Dutch’ not sure if you can understand, but this is my ‘Stroom & Saldering’ flow to fil in an Advanced Virtual device : ![afbeelding](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/6/0/60e70b58f8df01f2473088b3cec27bc01daf91e8.png) I might cut down on some of the varables, but this way the whole flow and whet I’m dooing is stiil ‘readable’ and understandable. I know I could do something with BLL, but it would take some of the calculations ‘out of sight’… pls keep in mind I’m only working with Homey less then a month 😉 I’m considering adding a ‘code’ in front of the flow and variable to ‘conenct’ them, like ‘aa\_flowname’ and ‘aa\_variable’. next flow would be ‘bb\_flow’ and ‘bb\_variable’. If i use a variable in both flows i could name it ‘ab\_variable’… ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 31, 2024, 8:31am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/14 "2024-10-31T08:31:53Z")
> [@JohanP](#): > > The flow is ‘in Dutch’ Please use the Google Translate icon in Chrome and your cards will show in English. Otherwise we’ll need to take your post separate in a Dutch topic. 1. Well done, a very clear layout! 2. I see you are already using Advanced Virtual Devices, that’s great. However, you can also use the fields in AVDs to calculate, this will save you a lot of logic variables and logic calculation cards. 3. PBTH has a summarizer that automatically tracks power, gas, water. This will save you tracking these values over time. This will also allow you to cancel the “Every 15 Minutes” card and the “When it is 00:00” card who are both generating CPU demand on the dot, when potentially other flows do the same. ---
**Author:** ![JohanP](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/johanp/32/119002_2.png) [@JohanP](https://community.homey.app/u/JohanP)\ **Post date:** [October 31, 2024, 8:50am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/15 "2024-10-31T08:50:47Z")
Translate makes garbage of some of the TAGS and variables : ![afbeelding](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/1/1/1153ce4721b62e3db01eeb8300e82bc6c60220fc.png) The reason not to do calculations in AVD I allready explained, I want to keep what I’m doing and how I manipulate the values readable… I had a look at PBTH, but it doesn’t quite do what I want, so I’d rather ‘program’ it myself… ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 31, 2024, 10:25am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/16 "2024-10-31T10:25:06Z")
> [@JohanP](#): > > Translate makes garbage of some of the TAGS and variables I see what you mean, we will live with the Dutch version then 🙂 > [@JohanP](#): > > I want to keep what I’m doing and how I manipulate the values readable I do not understand your comment fully, but of course, it is your choice. Note that you can also store your intermediary results in AVD variables. It means replacing the logic calculation cards with AVD calculation cards. This will not reduce the number of cards, but it will provide you with an much easier way to view the current values in device variables AND it reduces the number of logic variables for intermediate results and for final results. > [@JohanP](#): > > I had a look at PBTH, but it doesn’t quite do what I want Ok, only you as user can decide the balance between reducing cards and variables versus getting exactly what you want. ---
**Author:** ![JohanP](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/johanp/32/119002_2.png) [@JohanP](https://community.homey.app/u/JohanP)\ **Post date:** [October 31, 2024, 11:36am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/17 "2024-10-31T11:36:13Z")
Ok, you mean i could reduce ![afbeelding](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/1/b/1b1c8a8d5d6754dfd7323e41c6da0b85d7fd6c4f.png) this one to one card. But this one ![afbeelding](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/a/1/a1ebe59dacaf0614804243ba69fb51553a34079c.png) I cloud not create in 2, let alone one. Ok, maybe I could, but it would become a very hard to read and very long string… As far as CPU concerns, I’m not sure how ‘automaticly tracking values’ are less demanding on the CPU then once every 15 mins. The Homey must have poor performance if the calculations are that CPU intensive. Maybe if you have hundreds of flows running… ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [October 31, 2024, 1:57pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/18 "2024-10-31T13:57:15Z")
> [@JohanP](#): > > But this one No, this is what I meant: > [@Rrrr](#): > > also store your intermediary results in AVD variables > [@JohanP](#): > > As far as CPU concerns, I’m not sure how ‘automaticly tracking values’ are less demanding on the CPU then once every 15 mins. The Homey must have poor performance if the calculations are that CPU intensive PBTH Summarizer just tracks one energy number over time. It is well designed. ---
**Author:** ![dsdevries](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/dsdevries/32/80220_2.png) [@dsdevries](https://community.homey.app/u/dsdevries)\ **Post date:** [November 2, 2024, 6:28am UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/19 "2024-11-02T06:28:38Z")
I think the only way to make advanced calculations with true temporary constants while only making a few variables or tags public is by using homey script. You can use the “run code and return number value” card, or just create a separate script that sets a bunch of tags and just the “run script” card. ---
**Author:** ![Rrrr](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/rrrr/32/629_2.png) [@Rrrr](https://community.homey.app/u/Rrrr)\ **Post date:** [December 4, 2024, 4:56pm UTC](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362/20 "2024-12-04T16:56:34Z")
@JohanP Here is another local variable, using tags. It does not require you to create a variable. ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/7/2/72016b4f6052529594aa62a1590565ba579df97d.png) ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/e/4/e42b2772b00ed4301217acdf3c69c957fff47eee.png) [Next page](https://community.homey.app/t/developing-flows-tips-and-best-practices/117362.md?page=2)