Flow Gadgets - Now available

Hi everyone,

I’m currently working on a new Homey app called Flow Gadgets .

The app provides useful helper cards for Flows and Advanced Flows. Some of these cards already exist in my app Widget Forge , but many cards are brand new. The cards that are not widget-specific will eventually be marked as deprecated in Widget Forge, because they fit much better into this new, more generic helper app.

From now on, all future generic helper cards will be added to Flow Gadgets instead of Widget Forge.

Then cards currently included:

  • Calculate formula
  • Invert number
  • Generate random integer
  • Round number
  • Absolute number
  • Absolute difference
  • Apply deadband
  • Clamp number
  • Average number from list
  • Median number from list
  • Min / Max number
  • Min / Max number from list
  • Percentage of
  • Percentage change
  • Map number to range
  • Invert boolean
  • Boolean to text
  • Map tag text

And cards currently included:

  • Evaluate formula
  • Is number between / not between
  • Is number positive / not positive

Temporary values / variables:

Flow Gadgets also includes advanced cards to create, read, and read-and-release temporary number, text, and boolean values.

These temporary values are stored in memory for a limited time and can be useful when values need to be shared between Flows without creating global Homey variables.

More cards will follow depending on user requests and my own needs.

A test version is available here: Store

The documentation is available here: Doc

I would be very happy to hear your suggestions, feedback, and ideas.

Looks great!

Did not get to using them yet, but do have some questions and a 1st request…

  • can you explain “deadband”, I know the term but do not understand the result of the card.
  • can you explain “clamp”, I know the term but do not understand the result of the card.

Request:

  • Can we have a card that is a temporary Value that can be calculated. (Like the loggic card “calculate” but to a temp variable.
  • Next to the time for the temporary card, can we also have an option “duration of flow run”

Thank you for your reply. The deadband is explained in detail in the doc. Let me try to explain it here. Let’s say you have a sensor that goes from -1000 to + 1000. Around 0 it changes often fast in small steps like 4,-3,7,-10,15,-12 and so on. If you use this value it triggers a flow very often or makes a display in a widget change colors often in fast intervals. When you define a deadband from -20 to +20 the card will return 0 for the previous values. Only when the sensors value is over 20 it will return the true positive value of the sensor and only when the value is below -20 it will show the true negative value of the sensor. The deadband is the zone around zero that is simply replaced by zero. -1000…| -20 0 +20 | …+1000.

Clamp is quite the oposite of a deadband. Let’s suppose you have a sensor that outputs standard values from 0 to 100, but can output pikes up to 130. When you define a clamp from 0 to 100, and value between 0 and 100 is returned by the card but when a value is 130 then 100 will be returned. It is a kind of normalisation. All values below the clamp are returned with the lowest clamp value and all values above the clamp are returned as the highest clamp value.
Example: clamp -50 to +150
-40 returns -40
-60 returns -50
130 returns 130
180 returns 150

That can be done with 2 cards.


The # Result is the tag returned by the Calculate card.

I’m sorry, but I’m not sure to understand your request. Can you please explain more in detail what “duration of flow run” should be and what it should do.

Totally missed the calculate card, thanks.

Ooh and missed that doc too.

Should have been doing some better reading :wink:

It would be a more “local” variable, not available for a certain time, but available until the flow ends.

It is already offered by these apps,bit I think combined in your app it would be usefull.

Example: in an advanced flow that has multiple “branches” that can become active at the same time. I could use values calculated in “the other” branch

The deadband is always around “zero” right?

Might be usefull to have an offset to it? Like a deadband around 100.

I love the idea of triggering a flow less often, also when its not around zero…

Personally I like to use the “ceil” and “floor”, not known by many. But if its available as a card it will probably become more popular.. :wink:

The card is flexible but I think most of us will use it around zero. I use it for example for my PV dashboard as in many situations the grid is used to balance the system to preserve battery life. My System often shows fast changing grid values from -100W to +100W even when there is enough solar energy. So I use a deadband from -100 to +100 before sending data to Widget Forge (my other app) so that my grid simply shows a stable zero. But it is possible to define a deadband from +200 to +300 for example, even that I do not see a real life usecase in my smarthome. I simply think the card should offer this fexibility.

At my knowledge, there is no way to get the “flow ends” information from Homey. You can do it with a workaround. If different branches run at the same time, use different temporary values. If you need one consolidated value at the end, read and release every temporary value and store the value in another temporary value. While I see in theory what you mean, I don’t see the practical usecase. If you have a concrete case, please share it with me.

That function is in the Round card:


As you say these are technical terms that many lambda users do not know. That’s why I decided to call it “Always round down” and “Always round up” but that are exactly these functions.

I guess you are right…

If my flow runs again it will just overwrite the previous variable.

(I was worried 3min would be too long..)

Super, did not notice (guess I really need to your you “doc” first!)

Just for your info: The deadband can also be used in the Calculate card with the syntax { value ; lower deadband limit ; upper deadband }, and even in a nested form. That can also be found in the doc :wink:

The 3 min is just a fallback. You should always use the “Get and release” at the end to release the temporary value (delete from memory). But as flows become more complex chances are great that this card is omitted. Then the release will be done automatically after the 3 min to avoid memory overflooding.

Hi @Pascal_Nohl, I’m trying out your app right now, and I think I’ve found a bug.
Why is the result of 555,55 - 333,33 = 222,21999999999997 instead of 222,22?

Does this bug have anything to do with the Intel Pentium FDIV bug? :joy:

EDIT

The same error occurs with the flow card “Return absolute difference” as well:

Hi, thanks for reporting this.

This is caused by JavaScript floating-point precision. The calculation itself is not using a wrong formula, but decimal numbers like 555.55 and 333.33 cannot always be represented exactly internally.

While this is not a hard bug, I agree that the card should not expose this kind of precision artifact to the user. I will normalize the numeric result in the next update, so this example will return 222.22 as expected. I’ll have to do this for other cards too.

Best regards, Pascal

Hi Dirk,

I have already written a normalization function and integrated it into the Calculate Formula card:


I will now go through the other cards one by one and apply the same normalization where it makes sense.

Technical note: I now normalize JavaScript numeric results to 12 significant digits. JavaScript floating-point numbers are known to produce small precision artifacts in some decimal calculations, and this approach removes those artifacts without adding a heavy dependency.

The downside is that very large numbers, for example numbers with 10 integer digits, will only keep 2 decimal digits. However, I do not really see this as a problem in a smart home context. The alternative would be to include a larger arbitrary-precision math library, which would make the app bigger and more processor-intensive.

Best regards,
Pascal

Thank you very much for the quick implementation! :+1:t2:

The new version 1.1.0 is online for test here: Test Version

It adds 3 new cards and corrects the JS precision error.

Since certification of the previous submission did not move forward, I withdrew it for now.

In the meantime, I made some major upgrades and structural improvements to Flow Gadgets. The biggest change is that the simple math / expression logic now works across most cards and most numeric fields. This makes it possible to build much more compact Advanced Flows.

As a simple example, even a card like Invert Number can now accept an expression such as: {(#PV - #Load) * #Efficiency; -10; 10} instead of only a fixed number or a single tag.

Because this is a major change in the general card logic, some existing test flows may be affected, especially flows using hard-coded numeric values from earlier test versions. Tags should normally continue to work, but please check your Flow Gadgets test flows and change values in affected cards if needed.

I have now submitted this upgraded version again. It is much more advanced and clearly different from existing helper apps, especially because the formula logic, mapping cards, temporary values, and multi-condition expression cards work together across the app.

If you find Flow Gadgets useful, please leave a comment here. It would help show Homey that there is real interest in this app and that it provides useful functionality for Advanced Flow users.

The new version is here: Flow Gadgets | Homey

Examples with hard coded numbers but you can use tags and ‘±/*()’ in mathematical formulas, nested parenthesis and deadband { formula ; lowest value; highest value }

The certified version is online here: Flow Gadgets | Homey

Version 1.1.2 is now available for testing and has also been submitted for certification.
New cards:


The existing temporary value read cards intentionally throw an error when the temporary value does not exist or has already expired. This behaviour remains unchanged for compatibility.

The new safe read cards return a configurable default value instead, allowing the Flow to continue normally when a temporary value is missing or expired.

I also added a new AND card for temporary boolean values using the same default-value logic. This makes temporary states much easier to use, for example for manual overrides, automation lockouts, or temporary pauses.

A practical example: you can set a temporary boolean when a shutter is manually controlled and keep it active until 22:00. Your shading automation can then check this temporary state and avoid overwriting the manual action.