Home Automations

Automations

By Kobe Nys and 2 others
6 articles

Rebalancing with Torq Automations

The rebalancer has a lot of hidden attributes so it deserves it's own article. We will expand this article when more questions are sent to us about the rebalancer's internals. To start let's state the obvious: - Destinations: These are the channels that you are trying to get extra local balance (your side) for. So you try to lower these channels' remote balance (other side). - Sources: These are the channels you decided that have excess (to much) local balance. So you want to lower your local balance (your side) and increase the remote balance (other side) - Amount: When the rebalancer starts working on a channels it uses this specified amount. - Maximum cost: Like the name says it's the maximum cost when attempting to rebalance. We also have this odd selection field called "Focus". This focus field drives the parallelism of the rebalancer. So when you use destinations as focus then you strive to have enough local balance on the destination channels. So if 10 channels come in the workflow node as destination and 8 channels as sources then there will be 10 concurrent rebalance attempts (one for each destination). These rebalancer routines will work for a maximum of 2 hours. As you are well aware a lot can happen in 2 hours time. So Torq does not keep a static list of channels used by it's rebalancers. So instead of keeping a static list for those 8 channels we keep the list of criteria that composed that list. Every time the rebalancer has exausted a channel pair it will reevaluate those criteria to get a fresh list of channels and look for a pair that wasn't already tried. There currently is an arbitrary hard cap on 100 maximum concurrent rebalancer routines. When you want to allow the rebalancer to do fast sequential rebalance operations on a successful channel pair then you need to enable the "Channel Balance Changes" trigger. However if you have a busy node and a complex rebalancing workflow it's adviced to use a "Channel Balance Changes Filter" (from the Advanced Actions section) on your datasource so you can filter out small balance changes from triggering the entire workflow. i.e. If your rebalance amount is 50,000 sats then you could filter out balance changes below 49,000 sats The rebalance software always checks if there isn't already a rebalance routine working on your focus channel and if there is it doesn't start a new one. It will updates the details (if they changed).

Last updated on Jan 19, 2024

Action nodes for Torq Automations

Action nodes are nodes that will perform an operation on or with the data that was passed to it. The channel filter action node will filter channels based on criteria you provide. It's a general good practice to give these nodes a meaningful name by double clicking on "Channel Filter" once you dragged them onto the workflow canvas. If you have a time trigger then all channels will exit that time trigger, if you link this time trigger node with the channel filter node then you can filter out channels. Only the channels that are not filtered out will continue further down to the next node. You can just chain as many of these filter nodes in sequence so no need to create very complex filters into 1. With the channel policy node you can modify the channel policy data. If you only want to modify Maximum HTLC then leave the other values empty (so do not set them to zero). These policy changes will apply to all channels that were coming into this node. So when you link a time trigger with the channel policy node directly you will be modifying ALL your channels. So use a channel filter if you only want to update a subset of channels. This rebalance node has a lot of hidden complexities. We have a separate article for that one. Know that it uses a set of channels as source and a different set for destinations. The option to specify the amount and costs are also required. At ln.capital we believe that tagging is an essential part of node running. It's for that reason that that is part of our first iteration of our automations. This node will add a tag on the list of channels that come out of it's parent node. You can chose between tagging a channel or tagging the node of that channel. This does the opposite from the add tag node. This node will remove a tag.

Last updated on Jan 19, 2024

Workflow variables

Workflow variables are a mechanism to use dynamic and calculated values as workflow node inputs. They are available in Torq version 2.0. If you have a need to use a same value for multiple inputs, that you might want to change, you can use a variable to change it only in one location instead of editing all the inputs separately. Creating a workflow variable In a workflow, go to configurations and select either Add Workflow Variable or Add System Variable. A workflow variable is only usable in that specific workflow, but system variable is usable across all workflows (and in the future possibly even outside workflows). In this article we call both simply as "workflow variable" as their behavior is exactly the same. Add a name for the variable, select a datatype and add the definition. The most basic variable definition is just a constant. Note that text has to be added in quotes. Beside constants you can define the variable as a formula (with math operations), or use the "template-variables" inside the variable, to make it dynamic based on data available when the workflow is running. This is explained better at the end of the article. Using a workflow variable After a workflow variable is created it can be dragged to some input fields in workflow nodes. Note that each input accepts only one type of variable. An exception is the text area inputs for the Notification node and API Client node POST request body. To those text areas you can drag any workflow variable, and it will be added to the message as a template variable. A little icon in an input tells if a workflow variable is usable for that field. The icon also tells the type of variable that is accepted for that field. If there is no icon (except for the mentioned text areas), it means that workflow variables are currently not usable for it. Above is presented the three different types of inputs that accept variables: text, number and datetime. Below, a workflow variable is added to an input. Testing workflow variable behavior A simple way to test if a variable behaves as expected is to use it in a Notification node (with or without defining any communication methods). Choose the "Each channel" option for the node. Drag the workflow variable into the notification message (it should appear as a template variable), and run Dry-Run. You will see the evaluated variable value in the Workflow Logs. Below there was a variable that was defined as 2 * 100000. The evaluated value is seen in the messages. Overwriting workflow variables when triggering workflow via gRPC It's now possible to trigger workflows via gRPC API (refer to the article about gRPC API ). When triggering a workflow via the API, you can overwrite variables defined for the workflow by setting them to the gRPC call parameters. Be sure to use exactly the same name as the WorkflowVariable.name parameter as the variable name in Torq. Creating advanced variable definitions Let's get back to defining the workflow variables. As stated mathematical operations as well as dynamic "template variables" can be used in the workflow variable definition. Choose the template variables from the dropdowns above the variable definition. The variable is evaluated with https://github.com/Knetic/govaluate . Refer to their docs to see what is possible. Basically all basic math operations (+ - / * & | ^ ** % >> <<) and string concatenation with + operator are possible. Always remember to choose the correct data type that you aim to evaluate! Some examples: - Numeric variable: "Half the channel capacity": {{Channels.capacity}}/2 - Text variable (note the quotes!): "{{Channels.shortChannelId}} - {{Channels.gauge}}"

Last updated on Aug 01, 2024