We have moved at community.getvera.com

Author Topic: ALTUI: Workflows Issues  (Read 29670 times)

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
ALTUI: Workflows Issues
« on: March 14, 2016, 07:34:18 pm »
Logical State machines with graphical editor.

cf images and next post for explanations.

Example below:

I want to control a lamp by a motion sensor. When the motion sensor is triggered I want the lamp to switch on, and off after some time.
But if the lamp is on, I want to be able to walk in front of the motion sensor and I do not want the lamp to switch off ( not waf compliant )

So I have a different state for a lamp switched on manually and for the lamp switched on by the motion. And I only have a timer switch off action if the lamp was switched on by the motion.

Full working examples can be found here : http://forum.micasaverde.com/index.php/topic,36868.msg277263.html#msg277263
« Last Edit: May 17, 2016, 01:23:25 pm by amg0 »

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
Re: ALTUI: Workflows
« Reply #1 on: March 19, 2016, 08:21:24 am »
DOC for v1.34

ON/OFF
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

Display
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

Workflows
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

Variable Bags
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:
Code: [Select]
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:
Code: [Select]
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.

States
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.

  • 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
 
Transitions
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.
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 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

Implementation, details
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
« Last Edit: April 20, 2016, 04:10:18 pm by amg0 »

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
Re: ALTUI: Workflows
« Reply #2 on: March 22, 2016, 05:52:08 pm »
V 1.23.1334 makes some small changes
  • Enable workflow transitions to have both conditions and a timer : so to migrate from a state to another, either all the conditions of the link are matches,  or the timer expires.  ( timer survive reload & reboot )
  • Clickable lua expressions (for edit) for workflow transitions. click on the expression and you can modify it directly inside the text box
  • Movable link lables on the workflow graph editor ( it behaves a little bit strangely when the link has several Vertices on it but on straight line link, the label follows the mouse properly

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #3 on: March 23, 2016, 02:33:50 am »
I'm starting to play with the state diagrams, it's very intuitive for someone like me who knows how to design state machines :) 

Question: Is there a way to get back to the Start state? For example, when my state machine completes, I need to send it back to an Idle state to start all over again. I guess I can have an initial transition from "Start" to a state called "Idle", then I can do my thing, and return to Idle when complete.

As you wrote -- it would be nice to be able and trigger scenes via the state machines. Also nice would be some ability to have local variables (i.e. to keep track of iterations, etc.)

Very cool!

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
Re: ALTUI: Workflows
« Reply #4 on: March 23, 2016, 03:13:54 am »
I'm starting to play with the state diagrams, it's very intuitive for someone like me who knows how to design state machines :) 

Question: Is there a way to get back to the Start state? For example, when my state machine completes, I need to send it back to an Idle state to start all over again. I guess I can have an initial transition from "Start" to a state called "Idle", then I can do my thing, and return to Idle when complete.

As you wrote -- it would be nice to be able and trigger scenes via the state machines. Also nice would be some ability to have local variables (i.e. to keep track of iterations, etc.)

Very cool!

Thx. I indeed suggest you do the Idle intial state, I have to think about the start state, I was initially thinking to keep the start as a very special state for starting things. for instance all workflows goes back to Start when the user disable the workflow mode on the ALTUI device and reenables it. but maybe there is no true reason for that. 
regarding enhancements, I agree. I have these in mind..
- running a scene
- a variable set ( bag of variable ) that you would carry over from state to state
- ability to make a schedule a transition ( like match this transition every x at hh:mm etc )

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #5 on: March 23, 2016, 11:21:50 am »
Great! I just wanted to understand the intent and the use of the "start" state. so thanks for the explanation. Once I saw your examples in the first post, it also made sense.

Your UI is becoming quite capable -- you should consider monetizing it beyond donations.

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #6 on: March 23, 2016, 11:54:33 am »
Now that I'm creating some states, a useful feature (and use of the "start" state) would be to have "global" events associated with the start state that would take you to "start" regardless of where you are in the state diagram. That would go a long way to simplify each workflow.

For example, I'm writing a workflow to periodically notify me if the garage door is left open. There are several states, and I need a transition for each state back to "idle" when the garage door closes. If you could have these "global" transitions, I could reset the state machine from any state when the garage door closes.

Just a thought.
Cheers
-Ted

Offline xeinth

  • Full Member
  • ***
  • Posts: 144
  • Karma: +1/-1
Re: ALTUI: Workflows
« Reply #7 on: March 23, 2016, 03:27:44 pm »
Thx. I indeed suggest you do the Idle intial state, I have to think about the start state, I was initially thinking to keep the start as a very special state for starting things. for instance all workflows goes back to Start when the user disable the workflow mode on the ALTUI device and reenables it. but maybe there is no true reason for that. 
regarding enhancements, I agree. I have these in mind..
- running a scene
- a variable set ( bag of variable ) that you would carry over from state to state
- ability to make a schedule a transition ( like match this transition every x at hh:mm etc )

Those are all great.  One thing that could be helpful is if we could do the state editor, and the transition/action editor as side by side.  That is, you have 2 windows, one with the state machine graphically and the other with a table that represents either the transition or state action for the selected element.  The benefit would be in full effect if you eventually had the ability update the current state onto the diagram for debugging purposes, it would make it easier to see whats going wrong without losing the top level view.

Other than that, perhaps having a way to specify inputs once and associate a name that can be used throughout for any transition.  This would be a 'third' window but the benefit would be if we could do simple boolean expressions using those names, it would collapse the transitions into a single table which could make it a bit cleaner to manage things.  (i.e. you wouldn't need to select a bunch of device/variable combo's for each transition, just a single box for an expression.

I realize this may be a bit too specific, but just some thoughts =).  Cool stuff.

x

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
Re: ALTUI: Workflows
« Reply #8 on: March 24, 2016, 03:37:49 am »
Now that I'm creating some states, a useful feature (and use of the "start" state) would be to have "global" events associated with the start state that would take you to "start" regardless of where you are in the state diagram. That would go a long way to simplify each workflow.

For example, I'm writing a workflow to periodically notify me if the garage door is left open. There are several states, and I need a transition for each state back to "idle" when the garage door closes. If you could have these "global" transitions, I could reset the state machine from any state when the garage door closes.

Just a thought.
Cheers
-Ted

V 1.24.1340
  • Workflow Start state supports conditions like a link. Any matched condition will bring back the workflow to the start state
  • OnEnter OnExit actions of a state can also be running a scene now

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
Re: ALTUI: Workflows
« Reply #9 on: March 24, 2016, 03:41:55 am »
Now that I'm creating some states, a useful feature (and use of the "start" state) would be to have "global" events associated with the start state that would take you to "start" regardless of where you are in the state diagram. That would go a long way to simplify each workflow.

For example, I'm writing a workflow to periodically notify me if the garage door is left open. There are several states, and I need a transition for each state back to "idle" when the garage door closes. If you could have these "global" transitions, I could reset the state machine from any state when the garage door closes.

Just a thought.
Cheers
-Ted

V 1.24.1340
  • Workflow Start state supports conditions like a link. Any matched condition will bring back the workflow to the start state
  • OnEnter OnExit actions of a state can also be running a scene now

Start states behaves like a transition, so you can put several conditions in it ALL must be true for triggering the change of state ( which consists in coming back start state from wherever you are in the workflow ). Note that if these conditons remains true, your workflow will be stuck in the start state


Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
Re: ALTUI: Workflows
« Reply #10 on: March 24, 2016, 03:49:00 am »
Thx. I indeed suggest you do the Idle intial state, I have to think about the start state, I was initially thinking to keep the start as a very special state for starting things. for instance all workflows goes back to Start when the user disable the workflow mode on the ALTUI device and reenables it. but maybe there is no true reason for that. 
regarding enhancements, I agree. I have these in mind..
- running a scene
- a variable set ( bag of variable ) that you would carry over from state to state
- ability to make a schedule a transition ( like match this transition every x at hh:mm etc )

Those are all great.  One thing that could be helpful is if we could do the state editor, and the transition/action editor as side by side.  That is, you have 2 windows, one with the state machine graphically and the other with a table that represents either the transition or state action for the selected element.  The benefit would be in full effect if you eventually had the ability update the current state onto the diagram for debugging purposes, it would make it easier to see whats going wrong without losing the top level view.

Other than that, perhaps having a way to specify inputs once and associate a name that can be used throughout for any transition.  This would be a 'third' window but the benefit would be if we could do simple boolean expressions using those names, it would collapse the transitions into a single table which could make it a bit cleaner to manage things.  (i.e. you wouldn't need to select a bunch of device/variable combo's for each transition, just a single box for an expression.

I realize this may be a bit too specific, but just some thoughts =).  Cool stuff.

x
will look at it. not so easy if I want to respect my original design objective which is ALTUI works on any latform from phone to tablet to MAC/PC

it is indeed quite cool, the more I play with it the more I like it.   since timers and states are perssitent and resist to a reboot/reload ,  it should almost elimnate the need for many plugins like combinationswitch, countdowntimers etc ... all these great plugins that the community needed to overcome limitations of vera and making scenes much more robust as now, you can define actions which depends on what happened before and defered actions that will occur even if a reload happens in between.

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
Re: ALTUI: Workflows
« Reply #11 on: March 25, 2016, 06:51:23 am »
Workflow reports

Displays all transitions (when they exists) of all states
For the Start states, displays the conditions that will reset the workflow

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #12 on: March 25, 2016, 01:24:09 pm »
Hi,

I'm still trying to get myself started with some workflows:

Does the "test code" feature work? I get {"success":false} which I presume means fail? Is there a way to get more info as to what was causing the failure?

Also -- for troubleshooting purposes, is there any way to follow the transitions as they execute and see which is the currently active state?

As you described earlier -- I get the intent of the "start" state (thanks for adding the global transitions). Now -- if I want to get out of "start" right away is there a way to do it so I'm not awaiting any variable transitions? (i.e. I set a timer of 1 second)

A few cosmetics: It's very easy to accidentally delete transitions when trying to edit them. Perhaps a confirmation dialog for deletes would obviate that problem? Lastly, is it possible to scroll the window if the diagram gets to big for the frame?

Thanks!! I'm enjoying playing with the workflows!
-Ted

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #13 on: March 25, 2016, 02:29:51 pm »
I got a "no handler" when updating to v1.25. I went back to v1.24 and all is well again. Maybe it was a bad update, but wanted to check if anyone else had the issue before re-attempting an upgrade...

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +210/-8
Re: ALTUI: Workflows
« Reply #14 on: March 25, 2016, 03:23:08 pm »
I got a "no handler" when updating to v1.25. I went back to v1.24 and all is well again. Maybe it was a bad update, but wanted to check if anyone else had the issue before re-attempting an upgrade...
It should be ok, just give it enough time to reload. Or check the Lua log files in case of a startup problem. If you see a msg like ALTUI startup complete it should be ok

I ll check the other points.
To trouble shoot the transitions the best is to use the Lua log and search for ALTUI string ( with a grep )