The workflow mode is controlled by a button in the settings tab of ALTUI device to switch it on or off. you can allways switch it off if you run into trouble ( which is possible if you create crazy workflow that keeps matching conditions and run in loops ). you can switch off or switch on the workflow mode without requiring a lua restart
You have a first page with is showing all your workflows ( you can have several ) , then when clicking on the wrench icon you can see a graphical representation of your workflow with the start state in green, the active state in red.
I have not found a way to use web sockets so I have to do polling from the GUI to know the workflow status, I do this every 3 sec to avoid overloading VERA ( small data ) and the workflow page shows the workflow graphically and displays, which state is active so you actually see how your workflow progresses
State have connection points, you can use any “In” for incoming transition and any “Out” for outgoing transitions, the fact there are several is purely for convenience
Double click on a state or transition , or clicking on the edit button first then the object you want to edit will open the propery windows for that object where you can set configuration
you can have many workflows ( like custom pages ), but on a vera backend I suspect you can hit some limits. Each workflow is made of states and transitions. A State is active or inactive. A Transition is met or un met. When a State is active and one of its transition is met, the transition is executed and the end point of the transition becomes the new state. if several transitions are met, only the first met transition is executed.
Once arrived in the new state, if one of its transition is met, the process continues, until the workflow is blocked , pending on a state where no transition can be met and it puts itself in waiting mode
There is a workflow report screen to display all details of states and transitions of a worfklow
a Bag is a associative array to store workflow specific variable that are visible in any state of the workflow and are persistent accross reboots/reloads. a resetWorkflow action will reset the variables to null.
They are accessible in lua code like this and the lua code can just add variable as it wants simply by assigning a value to them:
Bag["my_variable"] = 2
Be careful that variables starts with a null value if the workflow has been reset for instance so if you use operations that use the previous value of the variable, you must guard it with default values like this:
Bag["my_variable"] = (Bag["my_variable"] or 0)+1
2 workflows can have the same variable name in their Bag, their will not be name collision, each workflow has its own Bag.
States represent a logical state of your environment. Only one state in a workflow is active at a time. States are linked by transitions and transitions must be met for a state transition to happen. States have a set of n actions when we enter the state ( OnEnter ) and a set of n actions when we exit the state ( OnExit ). these are device UPNP actions. There is also the ability to run scene ( both on Enter and on Exit ), as well as execute a piece of LUA code. that Lua code can call any luup.* functions ( in _G space ) and have access to a special “Bag” of variables that belong to this workflow.
[ul][li]State onEnter or onExit can call the UPNP action of a device and can use a Bag[“xxx”] value in the parameters[/li]
[li]Link condition expressions can make use of a Bag[“xxx”] value in their expression[/li][/ul]
When the workflow starts it starts in the start state. You can create transitions from the start state to the state you want to be in. at least one transition from the start state should fire and put your workflow in a proper position. Start state is remembered accross reboots, so if it is still valid ( not deleted by the user , and user has not reseted the workflow on purpose ) the workflow will resume in that state
Transitions are basically condition ( device watches & lua expressions, like the watches ) , or timer ( transition is ‘met’ when the timer described in the transition is met. Transitions may have multiple conditions, and this is an “AND” of all of them to be valid.
Timer transitions can be a hard coded timer ( n seconds ) or a range ( min-max ) which will make ALTUI chose a random duration between min and max seconds for that timer ( and it will be different every time the timer is armed ) . The timer value can also be a Bag variable with the syntax : Bag[“varname”] .
Transition can also be “scheduled” transition. this is the same scheduling capabilities as scene and will enable the transition to be considered as true on a planned schedule basis. When you associate a schedule to a transition, it will create a scene called " Workflow " with the programmed schedule. the scene will run and trigger the workflow transition. House modes apply if you are on UI7. the Logic remains so even if the transition is considered as “true” when this happens, it will only trigger a worfklow state transition if the active state of the workflow, was the source state of the transition.
Transition of a workflow (A) can also be fired when another workflow (B) is entering a particular state. you can choose that state from the transition editor screen. as soon as the other workflow (B) reaches that state, ALTUI will check this particular transition : if the source state of the transition in workflow (A) is matching the actual state of workflow (A), the transition will fire. Otherwise it will be ignored
if you need “OR” , you create multiple transitions ( multiple arrows on your graph )
Logical expressions for Transitions
Blockly editor for Transition condition editor is enabled , otherwise Transitions obey to the same rule / syntax than watches , so you can use special variable like new and old , just remember device values are string typed so to express a condition for a tripped motion sensor for instance, you write new == ‘1’. you can use luup functions so new == ‘1’ and luup.is_night() is a valid expression to have for a transition. You can use Bag[“xxx”] variables so new == Bag[“my_var”] is a valid expression
it is based on watch and timers so it is fully asynchronous. inactive workflows do not use any resources on your vera. the only exception is the GUI refresh of active state which is a polling every 3 sec for a small packet of information and this is only hapening on the workflow display page
Workflows can trigger transitions in other worfklows using the method explained here: