After so many great additions to Apilio functionalities in the last months, I thought it was time to share my updated Top 10 features I’d like to see implemented some day
NOT operator (please, please, please…): This is specially needed for conditions with timeout and delay, as it is not always possible to create the opposite condition.
Description in logicblocks, variables, conditions: A free text field where I can enter a description of how that element works. With 89 logicblocks and 129 conditions, sometimes I forget the logic behind them.
Longer names for logicblocks, as it is quite difficult to give a descriptive name.
Ability to change a condition name without breaking complex conditions in logicblocks, where conditions are inserted by name, e.g. AND(cond1, OR(cond2, cond3)).
Ability to include a variable in the body of a webhook action (not only in parameters), for example like {{some_at_home}}, in order to use variables in JSON requests.
For the sake of simplicity, create 2 new action types, one for evaluating/enabling/disabling logicblocks and another one for updating variables, instead of using webhooks. The logicblock action would allow you choose the name of logicblock and action, for example.
Log export: Addition of tags (maybe separated by commas) in a new column in the log export, so you can easily create a filter in Excel (oh, and an option to choose if CSV export puts data separated by ‘,’ or ‘;’ as in Spanish, Excel expects “;”)
Remove the ‘trigger’ option in conditions, and add it as a “check” next to each condition in a logicblock. This would prevent creating two identical conditions, one with ‘use as trigger’ and one without it for those use cases where you need both.
Reduce the minimum ‘delay’ setting in Condition to less than 10 seconds (a door sensor may take 1-2 second to estabilise due to vibrations when closing, but not 10)
Ability to choose an existing tag, rather than writing it from scratch. For some reason I end up with seemingly identical and duplicated tags :
I could not agree more with this list (thanks @teknofilo !), and particularly support the addition of a more direct interface for setting variables instead of using webhooks.
But as we know that Santa has magical powers, I would perhaps add an extra couple of things for his elves to do:
A way of accessing device status values, which can be viewed in the web interface and even tested for in conditions, but cannot currently be read or copied to a variable.
Add error handling to catch circumstances where a logicblock fails
Just in case the elves are still looking for more work, here is yet another addition that would be very welcome for our Christmas stockings:
IFTTT and Tuya actions to allow use of variables in the same way that Webhook actions do.
At present, Webhook actions can pass parameters that optionally use variable values, which is extremely useful. However, although IFTTT actions can pass up to 3 values, these cannot be taken from variables. It would be extremely useful if the same sort of interface that you have provided for Webhook parameters could be added to IFTTT values.
Going slightly further, where Tuya actions allow a numeric value to be passed, if this could also include the option of passing a variable then this again would be extremely useful. For example, the brightness of a smart bulb can typically be in the range 10-100 but currently this needs to be set to a defined value within the Tuya action. Allowing this to be taken from a variable would provide a means of far finer control.
And now that we have the extremely useful custom command, allowing the text associated with that command to be taken from a string variable would be a really powerful addition…
): This is specially needed for conditions with timeout and delay, as it is not always possible to create the opposite condition.
:
though…
can do!
