DOC for v1.34ON/OFFThe 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
DisplayYou 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
Workflowsyou 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
Variable Bagsa 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:
Bags["my_variable"] = 2Be 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:
Bags["my_variable"] = (Bags["my_variable"] or 0)+12 workflows can have the same variable name in their Bag, their will not be name collision, each workflow has its own Bag.
StatesStates 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.
- State onEnter or onExit can call the UPNP action of a device and can use a Bag["xxx"] value in the parameters
- Link condition expressions can make use of a Bag["xxx"] value in their expression
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
TransitionsTransitions 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.
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 <altuiid> " 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.
if you need "OR" , you create multiple transitions ( multiple arrows on your graph )
Logical expressions for TransitionsBlockly 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
Implementation, detailsit 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
