The Vera Community forums have moved!

Advanced => Plugins & Plugin Development => Programming => Alternate UI to UI7 => Topic started by: amg0 on March 14, 2016, 07:34:18 pm

Title: ALTUI: Workflows Issues
Post by: amg0 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 (http://forum.micasaverde.com/index.php/topic,36868.msg277263.html#msg277263)
Title: Re: ALTUI: Workflows
Post by: amg0 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.


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
Title: Re: ALTUI: Workflows
Post by: amg0 on March 22, 2016, 05:52:08 pm
V 1.23.1334 makes some small changes
Title: Re: ALTUI: Workflows
Post by: tedp 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!
Title: Re: ALTUI: Workflows
Post by: amg0 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 )
Title: Re: ALTUI: Workflows
Post by: tedp 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.
Title: Re: ALTUI: Workflows
Post by: tedp 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
Title: Re: ALTUI: Workflows
Post by: xeinth 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
Title: Re: ALTUI: Workflows
Post by: amg0 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
Title: Re: ALTUI: Workflows
Post by: amg0 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

Title: Re: ALTUI: Workflows
Post by: amg0 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.
Title: Re: ALTUI: Workflows
Post by: amg0 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
Title: Re: ALTUI: Workflows
Post by: tedp 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
Title: Re: ALTUI: Workflows
Post by: tedp 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...
Title: Re: ALTUI: Workflows
Post by: amg0 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 )
Title: Re: ALTUI: Workflows
Post by: amg0 on March 25, 2016, 06:19:20 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?
which "test code" feature ? on which screen

Also -- for troubleshooting purposes, is there any way to follow the transitions as they execute and see which is the currently active state?
Yes, using the Lua Luup log. you can grep on "ALTUI"  or to limit to workflow related stuff you can grep on "ALTUI: Wkflow -" string
you get a result like
Code: [Select]
50 03/25/16 23:17:33.116 luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Start)  <0x743b6520>
50 03/25/16 23:17:33.167 luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Start)  <0x743b6520>
50 03/25/16 23:17:36.386 luup_log:216: ALTUI: Wkflow - Valid Transition found. Label:Lamp is On  <0x76db6520>
50 03/25/16 23:17:36.387 luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Lamp On)  <0x76db6520>
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 transition without any condition and with a timer of 1 or 2 sec should do the trick

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?
will look

Thanks!! I'm enjoying playing with the workflows!
-Ted
Title: Re: ALTUI: Workflows
Post by: tedp on March 26, 2016, 01:12:57 am
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?
which "test code" feature ? on which screen

Also -- for troubleshooting purposes, is there any way to follow the transitions as they execute and see which is the currently active state?
Yes, using the Lua Luup log. you can grep on "ALTUI"  or to limit to workflow related stuff you can grep on "ALTUI: Wkflow -" string
you get a result like
Code: [Select]
5003/25/16 23:17:33.116luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Start)  <0x743b6520>
5003/25/16 23:17:33.167luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Start)  <0x743b6520>
5003/25/16 23:17:36.386luup_log:216: ALTUI: Wkflow - Valid Transition found. Label:Lamp is On  <0x76db6520>
5003/25/16 23:17:36.387luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Lamp On)  <0x76db6520>
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 transition without any condition and with a timer of 1 or 2 sec should do the trick

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?
will look

Thanks!! I'm enjoying playing with the workflows!
-Ted
There's an option to "test code" when saving a workflow.

Sent from my BN NookHD+ using Tapatalk

Title: Re: ALTUI: Workflows
Post by: amg0 on March 26, 2016, 05:04:29 am
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?
which "test code" feature ? on which screen

Also -- for troubleshooting purposes, is there any way to follow the transitions as they execute and see which is the currently active state?
Yes, using the Lua Luup log. you can grep on "ALTUI"  or to limit to workflow related stuff you can grep on "ALTUI: Wkflow -" string
you get a result like
Code: [Select]
5003/25/16 23:17:33.116luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Start)  <0x743b6520>
5003/25/16 23:17:33.167luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Start)  <0x743b6520>
5003/25/16 23:17:36.386luup_log:216: ALTUI: Wkflow - Valid Transition found. Label:Lamp is On  <0x76db6520>
5003/25/16 23:17:36.387luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Lamp On)  <0x76db6520>
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 transition without any condition and with a timer of 1 or 2 sec should do the trick

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?
will look

Thanks!! I'm enjoying playing with the workflows!
-Ted
There's an option to "test code" when saving a workflow.

Sent from my BN NookHD+ using Tapatalk
Yes ignore it, that window showing the Json structure of the workflow is meant for debug and will disappear over time. The workflow report gives the user friendly view of it.
Title: Re: ALTUI: Workflows
Post by: amg0 on March 26, 2016, 02:25:36 pm
a transition without any condition and with a timer of 1 or 2 sec should do the trick

in fact , it does not work, so I will have a look at it to enable that
Title: Re: ALTUI: Workflows
Post by: amg0 on March 26, 2016, 06:45:59 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?
which "test code" feature ? on which screen

Also -- for troubleshooting purposes, is there any way to follow the transitions as they execute and see which is the currently active state?
Yes, using the Lua Luup log. you can grep on "ALTUI"  or to limit to workflow related stuff you can grep on "ALTUI: Wkflow -" string
you get a result like
Code: [Select]
5003/25/16 23:17:33.116luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Start)  <0x743b6520>
5003/25/16 23:17:33.167luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Start)  <0x743b6520>
5003/25/16 23:17:36.386luup_log:216: ALTUI: Wkflow - Valid Transition found. Label:Lamp is On  <0x76db6520>
5003/25/16 23:17:36.387luup_log:216: ALTUI: Wkflow - nextWorkflowState(216, Workflow 0-1, Start ==> Lamp On)  <0x76db6520>
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 transition without any condition and with a timer of 1 or 2 sec should do the trick

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?
will look

Thanks!! I'm enjoying playing with the workflows!
-Ted
There's an option to "test code" when saving a workflow.

Sent from my BN NookHD+ using Tapatalk

Tedp/Others
there is a beta version installable with the magic url
<yourip>:3480/data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&Version=30941

which brings
Title: Re: ALTUI: Workflows
Post by: amg0 on March 26, 2016, 07:06:05 pm
if you have problem saving workflows with it, go to J_ALTUI_verabox.js line 1218 and change it to
Code: [Select]
var maxchar = 2000;
Title: Re: ALTUI: Workflows
Post by: amg0 on March 27, 2016, 05:29:11 pm
integrated the fixes in the last release. plus a potential source of "no handler" issue.
however if , after waiting a while , you get the no handler issue, you please need to enable DEBUG mode ( using UI5/7 ) then reload Luup, capturing the log and send me the log along with the version number you are using so I can trouble shoot.

manual install : ?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&Version=30950
Title: Re: ALTUI: Workflows
Post by: xeinth on March 29, 2016, 01:07:54 pm
amg,

The latest versions seems to address my No Handler issues, although I think I found some thing that can still cause them along with a few comments/feature requests =).  I love the history feature.  A+ for debugging


Sorry for the dump of things, but you have to deal with the consequences when you get peoples hopes up like this.   This is the best way to do complex control graphically I've seen yet, by far.  Thanks.

bk
Title: Re: ALTUI: Workflows
Post by: amg0 on March 30, 2016, 11:29:19 am
  • using new==1 instead of new=='1' for checking the status crashes luup.  This can also can cause constant restarts as the condition is still being met, so it can be hard to clear.  It might be good to handle this scenario
will be adding a pcall() to protect this now
  • It would be really helpful to support triggers or watches.  If you want to use a scene controller for example, to override a timed light, you need to only transition on a new event, even if the scene doesn't change.  I.e. you can't evaluate just the current value, but only 'new' values.  This could be done perhaps with the scene time, but haven't figured that out yet
I do not understand. if you have a transition with your remote controller and a condition on a variable like sl_LastScene and button value, it should be able to match the transition at the press of the button ( since transition are evaluated based on luup.watch , so based on trigger
  • small detail, but using just an arrow for a transition doesn't work.  You need a timer with at least 1 second.  This could be intent to prevent race conditions but if thats the case perhaps a one second delay can be inferred rather than 'breaking' the state machine.
agreed, but I d rather the user know what he is doing, indeed a transition must wait on something. I ll check what could be done to default something
  • It would be nice to enable/disable individual workflows as new things are being tested
adding it
  • The workspace editor can't scroll horizontally, at least in Safari.  This can cause problems switching between devices or resolutions as if you design it in something with a large screen, you can't see it all on a smaller screen
are you talking about mobile safari , or desktop safari  ? on mobile device I know but some other things are not working well on mobile. i wonder if people would really use mobile to edit workflows.  on IE and Chrome I do get the proper scrolling behavior ( it appear only when the area is larger than the screen and it automatically enlarge the area if you drag and drop something beyond the boundaries right now ). I need to find a safari desktop to test. I ll probably not be able to fix it no mobile screens, touch & scrolling are not consistent enough there and jointjs library has its own quirckness as well
  • A feature request would be to have the equivalent of a variable container built into the workflow engine, either globally or local to a given workflow.  The use case is to maintain values in addition to maintaining state.  For example a thermostat controller could have a variable for temperature, that is edited based on schedule, occupancy or incremented up/down by either a echo, switch or whatever.  For the inc/dec case, you need the previous value which could have been set thru a number of methods, and polling the device and inc/decing is not ideal.  This could be integrated into the state actions.  The only remaining thing the user would need to do (this could be built in as well, or done separately), is to track the updates to this variable and push them to a device.  You wouldn't want to do that manually in the state machine, you'd want that evaluated based on changes to the variable alone
we need to discuss this more, I am not undersatnding yet fully how this would work. Also fearing that I do not want to turn into a whole lot of code writing for the users because if you talk about variable, you ll likely talk about arythmetic expressions with them etc..

  • A timer which has no name, but a time won't execute.  Not a big one but if you are lazy it will lock things up.  Generally the timer name is sort of pointless as we only have 1 timer, and I seem to have transitions with just a timer only, making the naming redundant
fixing this in the UI
  • When a luup crash occurs, the state machine seems to restore to the last state.  Not sure if that is the best behavior or returning to the start state is best.  If we hold the same state, it would be nice to leverage the global reset of sorts to return to start, but I'm not sure there is a great way to do this that would work for all workflows.  If there was a 'restart' device/variable we could trigger the start state on, that might be useful.
Yes ,  I kind of prefer the restart in the state where it was, but I am adding a UPNP ALtUI action to reset a particular workflow so you can then use this as a scene action or even as a workflow state action.
will be in next release

[/list]
Title: Re: ALTUI: Workflows
Post by: xeinth on March 30, 2016, 09:12:20 pm
Pruning down the response, you checked a lot off the list =).

-Perhaps I need to come up with an example or test what you suggested, but I was using sl_SceneActivated, and that definitely seemed to not trigger.  I had to capture the scenario if the scene was already active.
-Regarding the scrolling issue on Safari, it does happen on desktop and mobile, but I found I can swipe the trackpad to get it to scroll.  There are no drawn slider bars.  As to mobile, agree wouldn't want to edit on mobile, but its REALLY nice to debug the logic by watching the state machine on your mobile as you test out scene controllers.  This is how I found some of the issues..
-Regarding the variable container request, I saw on a earlier page you already had that as a planned feature (i.e. keeping variables) along with schedules and a few other things.  The would be great, the only possible request in addition is if we could expose them.  Let me see if I can do an example with external variable containers.

One other thing, having a backup facility might be good.  I deleted a single workflow, and I think it ended up deleting the wrong one, but I could have been mistaken.

Thanks for the great work.  Once the schedules are in place I've got a pretty cool example to try out =).
x
Title: Re: ALTUI: Workflows
Post by: amg0 on April 02, 2016, 05:31:46 pm
One other thing, having a backup facility might be good.  I deleted a single workflow, and I think it ended up deleting the wrong one, but I could have been mistaken.
I am halfway in schedules... stay tuned
regarding backup, you can go to MISC/DEBUG/Javascript code and type in
Code: [Select]
WorkflowManager.getWorkflows()
for the restore it can be done with this ( where <workflow_object> is what you got from above ) followed by a luup reload
Code: [Select]
WorkflowManager.init(  <workflow_object> )
Title: Re: ALTUI: Workflows
Post by: javed222uy on April 02, 2016, 06:06:04 pm
Can you upload a complete report of the first sample?
Thanks
Title: Re: ALTUI: Workflows
Post by: amg0 on April 03, 2016, 10:03:26 am
Can you upload a complete report of the first sample?
Thanks

here you are.  I will post very soon now a version with many bug fixes for timers and the scheduled transition capability

EDIT: adding another example for an activity I want every 5min
EDIT2: version with scheduled transition is published. v1394
Title: Re: ALTUI: Workflows
Post by: amg0 on April 03, 2016, 10:52:16 am
Small tip:
you can click on an expression and edit it directly here.  or, you can click on the pencil icon and edit it with the Blockly editor ( but here, you have to edit it from scratch as I did not want to save a very long XML blockly definition within the workflow object which is already quite long )
Title: Re: ALTUI: Workflows
Post by: javed222uy on April 03, 2016, 02:11:21 pm
Thank You Amg0!!
I will tray!
Title: Re: ALTUI: Workflows
Post by: tedp on April 03, 2016, 02:22:50 pm
I am trying to set up a workflow that sends VeraAlert notifications. It seems that I am forced to enter the "recepients" parameter as well as the "housemode" parameter (see attachment). My understanding with Vera Alerts is that if I leave "recepients" blank it should send the message to default recepients. Moreover, I think the Housemode parameter is something that has to do with UI7, and I am still on UI5.

So -- is the requirement to complete the fields self-imposed, or are they really necessary? If anyone has successfully integrated VeraAlerts with Workflows, perhaps they can post an example?

Thanks
-Ted
Title: Re: ALTUI: Workflows
Post by: amg0 on April 03, 2016, 03:10:20 pm
I am trying to set up a workflow that sends VeraAlert notifications. It seems that I am forced to enter the "recepients" parameter as well as the "housemode" parameter (see attachment). My understanding with Vera Alerts is that if I leave "recepients" blank it should send the message to default recepients. Moreover, I think the Housemode parameter is something that has to do with UI7, and I am still on UI5.

So -- is the requirement to complete the fields self-imposed, or are they really necessary? If anyone has successfully integrated VeraAlerts with Workflows, perhaps they can post an example?

Thanks
-Ted
it was self imposed, here is a hotfix to try for now
Title: Re: ALTUI: Workflows
Post by: tedp on April 03, 2016, 03:42:53 pm
Perfect -- successfully sent a message!

Thanks :)
Title: Re: ALTUI: Workflows
Post by: tedp on April 03, 2016, 03:57:23 pm
Perfect -- successfully sent a message!

Thanks :)

well... maybe I spoke too soon. I'm not sure if it's related to the hotfix or not, but nothing happens when I "submit" transitions. It just does nothing. If I close the transition screen, it's not saved.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 03, 2016, 05:00:03 pm
Perfect -- successfully sent a message!

Thanks :)

well... maybe I spoke too soon. I'm not sure if it's related to the hotfix or not, but nothing happens when I "submit" transitions. It just does nothing. If I close the transition screen, it's not saved.
Make sure you close the transition screen with the save button
The to make it effective, on the workflow diagram, click the save button which should have been highlighted in red.

Just to be sure , then go back to the main page where all the workflows are shown and click save. You should get several green messages and it will force the Lua driver to reload workflows.
From that point on changes should be effective.
In doubt once all is setup, reload luup.

if it continues to behave funny , here is a full release of beta v 1400
Title: Re: ALTUI: Workflows
Post by: tedp on April 03, 2016, 05:12:20 pm

Make sure you close the transition screen with the save button
The to make it effective, on the workflow diagram, click the save button which should have been highlighted in red.

Just to be sure , then go back to the main page where all the workflows are shown and click save. You should get several green messages and it will force the Lua driver to reload workflows.
From that point on changes should be effective.
In doubt once all is setup, reload luup.

if it continues to behave funny , here is a full release of beta v 1400

The general workflow "save" worked as you said (got the "green"). I tried restarting luup, and just went for a full reboot as well. However, I still can't seem to get the "link" screen to take. The attached screengrab shows where I get stuck. For this test, I simply tried to change the name of the link to "xyz" and then submit -- nothing happens.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 03, 2016, 05:18:53 pm

Make sure you close the transition screen with the save button
The to make it effective, on the workflow diagram, click the save button which should have been highlighted in red.

Just to be sure , then go back to the main page where all the workflows are shown and click save. You should get several green messages and it will force the Lua driver to reload workflows.
From that point on changes should be effective.
In doubt once all is setup, reload luup.

if it continues to behave funny , here is a full release of beta v 1400

The general workflow "save" worked as you said (got the "green"). I tried restarting luup, and just went for a full reboot as well. However, I still can't seem to get the "link" screen to take. The attached screengrab shows where I get stuck. For this test, I simply tried to change the name of the link to "xyz" and then submit -- nothing happens.
did you try to fully load the v1400 I attached earlier ( maybe I changed something which required other files than just the one I sent you as hot fix ?

also, can you check javascript console log for any error ?
Title: Re: ALTUI: Workflows
Post by: tedp on April 03, 2016, 05:50:15 pm
I missed the v1400 attachment, so I (think) I uploaded it (I still get v.1.30.1398 at the bottom). However, the behavior has not changed.

I opened up the console, and when I click on "submit" the following error pops up:
J_ALTUI_utils.js:2280 Uncaught TypeError: Cannot read property 'length' of undefined

the function in question is (just in case we're on different versions)

function _getLinkScheduleScene(workflow_altuiid, linkid) {
      var scheduled_scene = null
      var scenes = MultiBox.getScenesSync();
      $.each(scenes, function(i,scene) {
         J_ALTUI_utils.js:2280 Uncaught TypeError: Cannot read property 'length' of undefined
            var action = scene.groups[0].actions[0];
            if ( (action.device == g_MyDeviceID)
               && (action.service == "urn:upnp-org:serviceId:altui1")
               && (action.action == "TriggerTransition")
               && (action.arguments.length>0)
               && (action.arguments[0].value == workflow_altuiid)
               && (action.arguments[1].value == linkid) )
            {
                  scheduled_scene = scene;
                  return false;
Title: Re: ALTUI: Workflows
Post by: amg0 on April 03, 2016, 06:15:26 pm
I missed the v1400 attachment, so I (think) I uploaded it (I still get v.1.30.1398 at the bottom). However, the behavior has not changed.

I opened up the console, and when I click on "submit" the following error pops up:
J_ALTUI_utils.js:2280 Uncaught TypeError: Cannot read property 'length' of undefined

the function in question is (just in case we're on different versions)

function _getLinkScheduleScene(workflow_altuiid, linkid) {
      var scheduled_scene = null
      var scenes = MultiBox.getScenesSync();
      $.each(scenes, function(i,scene) {
         J_ALTUI_utils.js:2280 Uncaught TypeError: Cannot read property 'length' of undefined
            var action = scene.groups[0].actions[0];
            if ( (action.device == g_MyDeviceID)
               && (action.service == "urn:upnp-org:serviceId:altui1")
               && (action.action == "TriggerTransition")
               && (action.arguments.length>0)
               && (action.arguments[0].value == workflow_altuiid)
               && (action.arguments[1].value == linkid) )
            {
                  scheduled_scene = scene;
                  return false;
I see ... Side effect of making arguments optional I suppose. You can try to modify the test to accept action.argument ==undefined OR ...
I ll update tomorrow otherwise.


Title: Re: ALTUI: Workflows
Post by: tedp on April 03, 2016, 07:11:20 pm
I took a shot, but couldn't get it to work. I'll await your next update. Thanks!!!

FYI: this was my interpretation of what you were proposing:
   function _getLinkScheduleScene(workflow_altuiid, linkid) {
      var scheduled_scene = null
      var scenes = MultiBox.getScenesSync();
      $.each(scenes, function(i,scene) {
         if ( (scene.groups.length>0) && (scene.groups[0].actions.length>0) ) {
            var action = scene.groups[0].actions[0];
            if ( (action.device == g_MyDeviceID)
               && (action.service == "urn:upnp-org:serviceId:altui1")
               && (action.action == "TriggerTransition")
               && (action.arguments == undefined || (action.arguments.length>0))
               && (action.arguments[0].value == workflow_altuiid)
               && (action.arguments[1].value == linkid) )
            {
Title: Re: ALTUI: Workflows
Post by: amg0 on April 04, 2016, 02:01:58 am
I took a shot, but couldn't get it to work. I'll await your next update. Thanks!!!

FYI: this was my interpretation of what you were proposing:
   function _getLinkScheduleScene(workflow_altuiid, linkid) {
      var scheduled_scene = null
      var scenes = MultiBox.getScenesSync();
      $.each(scenes, function(i,scene) {
         if ( (scene.groups.length>0) && (scene.groups[0].actions.length>0) ) {
            var action = scene.groups[0].actions[0];
            if ( (action.device == g_MyDeviceID)
               && (action.service == "urn:upnp-org:serviceId:altui1")
               && (action.action == "TriggerTransition")
               && (action.arguments == undefined || (action.arguments.length>0))
               && (action.arguments[0].value == workflow_altuiid)
               && (action.arguments[1].value == linkid) )
            {

I am having second thoughts about this, you can revert to previous code, and go it your scene , find one called workflow 0-1 or something like that. Delete it.
Then back into your workflow edit the link with the schedule and save it again. It should recreate the scene.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 04, 2016, 03:37:42 am
I took a shot, but couldn't get it to work. I'll await your next update. Thanks!!!

FYI: this was my interpretation of what you were proposing:
   function _getLinkScheduleScene(workflow_altuiid, linkid) {
      var scheduled_scene = null
      var scenes = MultiBox.getScenesSync();
      $.each(scenes, function(i,scene) {
         if ( (scene.groups.length>0) && (scene.groups[0].actions.length>0) ) {
            var action = scene.groups[0].actions[0];
            if ( (action.device == g_MyDeviceID)
               && (action.service == "urn:upnp-org:serviceId:altui1")
               && (action.action == "TriggerTransition")
               && (action.arguments == undefined || (action.arguments.length>0))
               && (action.arguments[0].value == workflow_altuiid)
               && (action.arguments[1].value == linkid) )
            {

I am having second thoughts about this, you can revert to previous code, and go it your scene , find one called workflow 0-1 or something like that. Delete it.
Then back into your workflow edit the link with the schedule and save it again. It should recreate the scene.

you can also try this beta 1401
Title: Re: ALTUI: Workflows
Post by: amg0 on April 04, 2016, 12:00:02 pm

you can also try this beta 1401
I released 1406 so you can try this one
Title: Re: ALTUI: Workflows
Post by: tedp on April 04, 2016, 01:34:33 pm
"Bob's your uncle!!!"

I was able to prototype my workflow to send me a notification every X minutes if I leave my garage door open! I did it with 3 states.

A few followups:
* Does the "on exit" execute when all of the transitions conditions are true? If so I can see doing what I'd like with only two states, but I cannot seem to have a transition to go from a state back to itself. The idea would be to have a "wait state" with a link back to itself when a timer expires at which point the "exit state" would send a notification and the link would go back to the same state awaiting the timer to expire again. Is this consistent with your architecture?

* An idea: would it be possible to abstract a workflow into a subroutine like structure? I'd love to implement the same notifications for when other sensors are left open for too long (i.e. front door, etc.) I can copy/paste the workflow I suppose, but it would be sexier if I could just "call" my generic workflow with the device ID (and other parameters) as variables into the function.

* I had a crash of AltUI at some point when experimenting. After reloading LUA from UI5, altUI came back, but my workflows that were previously saved were gone. No big deal now, as I'm just experimenting. I think I saw something in a previous thread about the ability to backup the workflows.

Looks great!
-Ted
Title: Re: ALTUI: Workflows
Post by: amg0 on April 04, 2016, 03:02:42 pm
"Bob's your uncle!!!"

I was able to prototype my workflow to send me a notification every X minutes if I leave my garage door open! I did it with 3 states.

A few followups:
* Does the "on exit" execute when all of the transitions conditions are true? If so I can see doing what I'd like with only two states, but I cannot seem to have a transition to go from a state back to itself. The idea would be to have a "wait state" with a link back to itself when a timer expires at which point the "exit state" would send a notification and the link would go back to the same state awaiting the timer to expire again. Is this consistent with your architecture?

* An idea: would it be possible to abstract a workflow into a subroutine like structure? I'd love to implement the same notifications for when other sensors are left open for too long (i.e. front door, etc.) I can copy/paste the workflow I suppose, but it would be sexier if I could just "call" my generic workflow with the device ID (and other parameters) as variables into the function.

* I had a crash of AltUI at some point when experimenting. After reloading LUA from UI5, altUI came back, but my workflows that were previously saved were gone. No big deal now, as I'm just experimenting. I think I saw something in a previous thread about the ability to backup the workflows.

Looks great!
-Ted

1/OnEnter executed when the state is entered
OnExit is executed when the state is exsited, that is , when at least one of of the transaction leaving that state is evaluated as true. when that happens, OnExit of the source state is called, then the active state moves to the new state , then the OnEnter of the new state is called

2/ interesting idea but would be quite a change. it would mean an active state of a workflow could be a state of another workflow. that would require complex changes internally

3/ that is possible, especially if the box is getting full , and especially if you run in DEBUG mode.  another thing I have seen happen is when Luup reloads, if any scene are executed too soon before the lua startup is finished, it will crash VERA and it will restart luup again. ( with a GLOBAL failure message ). that is a strange bug that I do not understand why MCV is not fixing.  note that using workflow and scheduled transtion, you protect yourself from that bug as no trigger happens before ALTUI driver is ready. that is a good side effect of using workflows
Title: Re: ALTUI: Workflows
Post by: tedp on April 04, 2016, 03:44:51 pm
OK, I understand.

To follow up then: there should be no operational reason that a state cannot link back to itself? (i.e. when timer expires, send notification and link back to the same state to await timer to expire again).

Is there a way to download/backup the workflows just in case I get caught up in one of those unfortunate events you mentioned?

Thx
-Ted
Title: Re: ALTUI: Workflows
Post by: amg0 on April 04, 2016, 03:52:32 pm
OK, I understand.

To follow up then: there should be no operational reason that a state cannot link back to itself? (i.e. when timer expires, send notification and link back to the same state to await timer to expire again).

Is there a way to download/backup the workflows just in case I get caught up in one of those unfortunate events you mentioned?

Thx
-Ted

backup/restore => http://forum.micasaverde.com/index.php/topic,36868.msg277220.html#msg277220

I ll look for the loopback. not sure I can easily do this. and to avoid exceptions in the code and follow the same logic,  it would mean OnExit actions are called then OnEnter actions are called.  I am not sure we would save a lot in simplicity and readability of the workflow. To keep it simple you can easily accomplish that with 2 states , like in the workflow (updatethingspeak) here http://forum.micasaverde.com/index.php/topic,36868.msg277263.html#msg277263
Title: Re: ALTUI: Workflows
Post by: tedp on April 04, 2016, 03:54:22 pm
OK -- got it and thanks!
Title: Re: ALTUI: Workflows
Post by: amg0 on April 04, 2016, 04:14:18 pm
Here is a beta ( 1410 ) with a link to same state feature.
note that I have tested fully the consequences, so you need to be careful ( note that in worst case like a workflow in a deadloop you can allways go to ALTUI device and switch off workflow mode using the button. that ll stop it all )

a link to same state means:
- if it is a timer link, it is considered expired only the first time so safe
- if it is a scheduled link, I checked the code and it should be considered true only once, until the next scheduled trigger of the link. so safe here as well
- if it is a condition link about variable watch, that link will continuously be true if the variable stays true.  Fortunately there is a 5 second delay ( by design & on purpose ) between each re-evaluation of the workflow so, even if that variable stays true, the state OnEnter actions will only be executed 5 sec after the OnExit actions of the same state and these 5 seconds are giving VERA back-end server a chance to react to others things ( like you pressing the switch off button if need be )

let me know how it goes
thx
Title: Re: ALTUI: Workflows
Post by: tedp on April 04, 2016, 08:13:49 pm
I think I figured out a way to get the best of all worlds with my "notification for open door" project while maintaining one workflow: I included all the sensors that I want to be notified if open into a Combination Switch. It seems to work! I've implemented it with 3 states -- as you said originally: it's not such a big deal to add the extra state.

I'm still refining it (and have a couple of issues/questions with the Combination Switch), but it's pretty awesome.

Along the way, I found a couple of nits FYI:
* There doesn't seem to be a way to edit "device actions" for state enter/exit. If I want to change a device action, it seems I have to delete and create a new one.

* I had to write some LUA for my VeraAlerts notifications. It would be nice to be able to execute LUA on state entry and exit. As a workaround, I created a scene with the LUA code I wanted to run, and called the scene from the workflow

* When entering a condition into a link, if I click on Blockly, nothing happens (no blockly). However, if I click on the "edit" icon (the pencil) in the conditions (assuming a condition was already specified), then Blockly comes up (see attachment).

* Not really related to Workflows, but the Combo Switch control has a control labeled as "Switch is on when  N or more watched items are true" where N is an integer. It works in UI5, but in altUI N comes up as "false". (see attachment)

Regards
-Ted
Title: Re: ALTUI: Workflows
Post by: amg0 on April 05, 2016, 02:26:52 am
I think I figured out a way to get the best of all worlds with my "notification for open door" project while maintaining one workflow: I included all the sensors that I want to be notified if open into a Combination Switch. It seems to work! I've implemented it with 3 states -- as you said originally: it's not such a big deal to add the extra state.
Very excellent. could you share the details so that everybody benefits from your experience ?


I'm still refining it (and have a couple of issues/questions with the Combination Switch), but it's pretty awesome.

Along the way, I found a couple of nits FYI:
* There doesn't seem to be a way to edit "device actions" for state enter/exit. If I want to change a device action, it seems I have to delete and create a new one.
I ll look

* I had to write some LUA for my VeraAlerts notifications. It would be nice to be able to execute LUA on state entry and exit. As a workaround, I created a scene with the LUA code I wanted to run, and called the scene from the workflow
yes , on purpose to avoid having LUA code inside the workflow definition object which will then pose a problem of length and of special caracters in the saving of the workflow. but I ll keep the idea open

* When entering a condition into a link, if I click on Blockly, nothing happens (no blockly). However, if I click on the "edit" icon (the pencil) in the conditions (assuming a condition was already specified), then Blockly comes up (see attachment).
Yes because bootstrap does not support modal in a modal. I ll probably hide that button in the dialog

* Not really related to Workflows, but the Combo Switch control has a control labeled as "Switch is on when  N or more watched items are true" where N is an integer. It works in UI5, but in altUI N comes up as "false". (see attachment)
strange, cf my screen shot. mine works. can you share your device variables ?

I suspect this to happen:
get_device_state(deviceId, serviceId, variable, dynamic) API from UI7 returns false when the luup get_variable call returns null.
so I think the variable is missing from your device. try initialize it with a space or a number 0 maybe

Regards
-Ted
Title: Re: ALTUI: Workflows
Post by: tedp on April 05, 2016, 11:15:06 am
Quote
Very excellent. could you share the details so that everybody benefits from your experience ?

Here's what I did: (We can move to an examples thread if appropriate).

Goal: Get notifications every 30 minutes if one or more of my 4 exterior doors has been forgotten open.

Approach: Use the combination switch to trigger when ANY of the 4 sensors associated with the door trips. Once a trigger event happens, start a timer in AltUI's Workflows. When the timer expires, move to a state which calls a scene which in turn makes a call to  VeraAlerts to send a notification. In the scene that calls VeraAlerts, I added some LUA code to read through each of the 4 sensors at notification to see which are tripped so I can know which door (i.e. front, garage, etc.) is open. When the combo switch becomes "untripped" (i.e. all doors are closed), then we use the "global link" feature to reset the state machine to the start state.

To Do:

The state diagram is attached.

The workflow report:
Code: [Select]
Workflow Report

User Alarms - (0-1)
3 States: Start, Notify, Wait for Timer
3 Transitions: Timeout Expired, Something Open, Wait Again
Details
Start - f65e5812-a82a-4599-b37a-7fb28a7fd835
Global Conditions
device:'Exterior Door Open' (0-152) when urn:upnp-org:serviceId:SwitchPower1-Status (new=='0')
Transitions
'Something Open' - 5698222b-ed6a-4617-9451-5a6d4c647577
When
device:'Exterior Door Open' (0-152) when urn:upnp-org:serviceId:SwitchPower1-Status (new=='1')
Moves To
State: Wait for Timer
Notify - 5e60f87d-d3b1-4001-aa66-edd05130152e
OnEnter
run Open Exterior Notification (0-47)
Transitions
'Wait Again' - 4a9c6751-bbf6-435d-941b-793a681b6602
When
Timer: 'Dummy' expiration 1s
Moves To
State: Wait for Timer
Wait for Timer - 8f25fd89-ec13-4d1f-866e-3d692788ae02
Transitions
'Timeout Expired' - e48459ca-1653-4ee4-88da-2799a854130d
When
Timer: 'Timeout' expiration 1800s
Moves To
State

Here is the code associated with the scene that sends the VeraAlert. It gets the deviceIDs of the sensors associated with the Combo Switch, then for each of the deviceIDs, it looks up to see if that sensor is tripped. If so, it adds the device's description to the message that is sent by VeraAlerts so I know which door is open.

Code: [Select]
local alertMsg = ""
for i = 1 , luup.variable_get("urn:futzle-com:serviceId:CombinationSwitch1", "WatchCount", 152) do
  local foundDeviceStr, tstamp = luup.variable_get("urn:futzle-com:serviceId:CombinationSwitch1", i.."DeviceId", 152)
  local foundDevice=tonumber(foundDeviceStr)
  local deviceInfo=luup.devices[(foundDevice)].description
  local deviceState=luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped", tonumber(foundDevice))
  print (deviceState)
  if deviceState=='1' then
    alertMsg = (alertMsg .. " " .. deviceInfo)
  end
 end
luup.call_action("urn:richardgreen:serviceId:VeraAlert1", "SendAlert", {Message = "{tone:2}Sensor Timeout: "..alertMsg}, 192)
return true
Title: Re: ALTUI: Workflows
Post by: amg0 on April 05, 2016, 01:16:08 pm
Quote
Very excellent. could you share the details so that everybody benefits from your experience ?

Here's what I did: (We can move to an examples thread if appropriate).

Goal: Get notifications every 30 minutes if one or more of my 4 exterior doors has been forgotten open.

Approach: Use the combination switch to trigger when ANY of the 4 sensors associated with the door trips. Once a trigger event happens, start a timer in AltUI's Workflows. When the timer expires, move to a state which calls a scene which in turn makes a call to  VeraAlerts to send a notification. In the scene that calls VeraAlerts, I added some LUA code to read through each of the 4 sensors at notification to see which are tripped so I can know which door (i.e. front, garage, etc.) is open. When the combo switch becomes "untripped" (i.e. all doors are closed), then we use the "global link" feature to reset the state machine to the start state.

To Do:
  • Would be nice if I didn't have to create a scene to call VeraAlerts, but could do it directly from Workflows
  • Implement some sort of "muting" feature. I can check the state of a virtual switch before sending the alert. It would be nice to have the ability to disable the workflow based on some setting.

The state diagram is attached.

The workflow report:
Code: [Select]
Workflow Report

User Alarms - (0-1)
3 States: Start, Notify, Wait for Timer
3 Transitions: Timeout Expired, Something Open, Wait Again
Details
Start - f65e5812-a82a-4599-b37a-7fb28a7fd835
Global Conditions
device:'Exterior Door Open' (0-152) when urn:upnp-org:serviceId:SwitchPower1-Status (new=='0')
Transitions
'Something Open' - 5698222b-ed6a-4617-9451-5a6d4c647577
When
device:'Exterior Door Open' (0-152) when urn:upnp-org:serviceId:SwitchPower1-Status (new=='1')
Moves To
State: Wait for Timer
Notify - 5e60f87d-d3b1-4001-aa66-edd05130152e
OnEnter
run Open Exterior Notification (0-47)
Transitions
'Wait Again' - 4a9c6751-bbf6-435d-941b-793a681b6602
When
Timer: 'Dummy' expiration 1s
Moves To
State: Wait for Timer
Wait for Timer - 8f25fd89-ec13-4d1f-866e-3d692788ae02
Transitions
'Timeout Expired' - e48459ca-1653-4ee4-88da-2799a854130d
When
Timer: 'Timeout' expiration 1800s
Moves To
State

Here is the code associated with the scene that sends the VeraAlert. It gets the deviceIDs of the sensors associated with the Combo Switch, then for each of the deviceIDs, it looks up to see if that sensor is tripped. If so, it adds the device's description to the message that is sent by VeraAlerts so I know which door is open.

Code: [Select]
local alertMsg = ""
for i = 1 , luup.variable_get("urn:futzle-com:serviceId:CombinationSwitch1", "WatchCount", 152) do
  local foundDeviceStr, tstamp = luup.variable_get("urn:futzle-com:serviceId:CombinationSwitch1", i.."DeviceId", 152)
  local foundDevice=tonumber(foundDeviceStr)
  local deviceInfo=luup.devices[(foundDevice)].description
  local deviceState=luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped", tonumber(foundDevice))
  print (deviceState)
  if deviceState=='1' then
    alertMsg = (alertMsg .. " " .. deviceInfo)
  end
 end
luup.call_action("urn:richardgreen:serviceId:VeraAlert1", "SendAlert", {Message = "{tone:2}Sensor Timeout: "..alertMsg}, 192)
return true

quite nice thx for sharing . I hope it gives idea to others

As a potential alternative to avoid the combination switch (to save plugins and memory ), I wonder if you could have had a start state,  a "anyone one is open" state and 4 transitions from start state to this "one is open" state, with a given transition for each for a given tripped sensor.
Then your timer state with the notify scene and the return transaction is indeed what I would have done also.
Then a Start state condition which 4 lines checking each tripped sensor to be 0. so when all are closed the workflow is reset and go back to start

Title: Re: ALTUI: Workflows
Post by: dklinkman on April 05, 2016, 06:54:50 pm
I'm finally trying out the workflows (awesome by the way) and I'm having some problems.

Created a simple workflow with a transition to a state based on a door sensor.  Didn't work.  Tried a few more things.  Nothing works.  Back to a simple workflow with a transition which is just a 1 second timer from start to s1.  No luck.  Each time I delete the workflow and start over.

At some point I tried reloading luup and I'm stuck in the "No handler" purgatory.  Nothing works, reboots, etc.  Still No handler.

In there somewhere UI7 says I should update firmware.  So did that.  And bricked the Vera.  Ugh!

So dealt with that.  Got things back to where they should be.  On the new firmware.  But still "No handler".

By restoring from last night's automatic network backup I was finally able to get ALTUI working again.

So again, tried a workflow.  Got one to work actually!!  First time!!  Tried another.  No go.  Same again.  Tried some workflows that were really simple and should have worked.  But they didn't.

Hmm.  Let's try reload luup again.  And again -- No handler!!!!  Ok so restore from last nights backup and we're good again.  At least I skipped the brick this time.

Maybe corruption is happening.  I don't know.  UI7 says there are errors in scenes and events.  Maybe a clue.

Altui version is:  AltUI v1.31.1413

I know you'll probably want logs but I thought I would run the scenarios past you first.  Any thoughts?

--D
Title: Re: ALTUI: Workflows
Post by: amg0 on April 06, 2016, 04:00:21 am
Hello
Let?s see how I can help

First of all, the no handler issue.  Several things to check
a)   That you are not running ALTUI ( or others ) in DEBUG mode. This generates lots of debug and potentially you are too slow to restart or it triggers a log rotate in the middle of your restart etc ?
b)   I have noticed a serious UI7 bug. When UI7 starts, even if it has not yet finished, some scene can be executed ( by schedule or trigger ) and this crashes lua if the scene is calling some lua code which does not exist yet because the restart is not finished. To avoid this. Make sure you do not have scheduled recurrent scene that run to often ( since it takes 2-5 mn to restart, above a scene running every 15 mn is relatively safe, below 5mn is not at all )

c)   Make sure when you restart , you let it enough time before opening ALTUI. I have no proof but a feeling ALTUI opened too soon could encounter some not yet ready code and triggers a luup restart
d)   Finally a too loaded UI7 box is desperate.. get rid of some plugins. Maybe workflows will help us doing that


For your workflow test, here is a step by step that I have just done myself to make sure it is 100% accurate.

1)   Go to device page, open ALTUI control panel
2)   Flip the Workflow Mode switch to OFF ( Normal )
3)   Goto More/Worfklows page
4)   Click Create and it will create an empty one called ?Workflow 0-3? or whatever depending on your number of workflows. You can click on the title to rename it
5)   Click on the wrench icon to go into edit mode
6)   You will see a orange message ?Workflow mode is not enabled on your ALTUI device? which is normal since we disabled workflow mode for now, close it to acknowledge it
7)   You will get a default workflow with start S1 S2 states.  Delete S2 and space S1 a bit away to the right
8 )   Draw a transition from Start out port to one of the S1 input port
9)   Double click on the new transition called ?label? and name it ?MyLink?
10)   Go into Timer and put ?myTimer? in Name and 10 in the duration
a.   Big caveat,  if you use schedules and program a too frequent recurrent schedule, it will use a scene and you can run in the luup restart issue I explained above
11)   Click on Submit button. You should be back at workflow editor state with a RED save button
12)   Click on the red Save button you should see some green messages in the message section for a few seconds telling that the saving completed.
13)   I have a bug I need to fix, the save is not yet effective here !  you need to go back into the multiple workflow page and click the RED save button here
14)   You should see the START state being mentioned in your new workflow and 10 sec later it should say S1 instead
15)   Go into the workflow editor for that new workflow and you should see the state S1 higlighted in red

This gave me 2 bugs I will fix
1)   The save is  not effective immediately unless you do it from the workflow page
2)   ALTUI automatically puts back the workflowmode  switch and it should not , it should be a manual security control for the user
Title: Re: ALTUI: Workflows
Post by: amg0 on April 06, 2016, 08:38:48 am
I released 1.32.1422 to fix these bugs plus an number of issue which could result in a "no handler" message.
cf http://forum.micasaverde.com/index.php/topic,33308.msg277691.html#msg277691
Title: Re: ALTUI: Workflows
Post by: amg0 on April 07, 2016, 03:33:54 am
Along the way, I found a couple of nits FYI:
* There doesn't seem to be a way to edit "device actions" for state enter/exit. If I want to change a device action, it seems I have to delete and create a new one.

* I had to write some LUA for my VeraAlerts notifications. It would be nice to be able to execute LUA on state entry and exit. As a workaround, I created a scene with the LUA code I wanted to run, and called the scene from the workflow

* When entering a condition into a link, if I click on Blockly, nothing happens (no blockly). However, if I click on the "edit" icon (the pencil) in the conditions (assuming a condition was already specified), then Blockly comes up (see attachment).

* Not really related to Workflows, but the Combo Switch control has a control labeled as "Switch is on when  N or more watched items are true" where N is an integer. It works in UI5, but in altUI N comes up as "false". (see attachment)
Edit actions ( instead of delete + recreate ) and removing the faulty blockly button from the dialog is in the next future release
Title: Re: ALTUI: Workflows
Post by: xeinth on April 07, 2016, 12:51:58 pm
amg,
k
Sorry for the lack of feedback for a while, I was traveling.  I'll be playing with a few things shortly, but I had run into some issues with crashes that I think were related to workflows somehow, but with the latest release it seems I can leave workflows enabled with no issues.  Having debug on definitely made things worse..

Thanks for the insight on the backup method, but it still might be good to find a way to save this externally, may make it easier to share or manage workflows with a bit of safety.

x
Title: Re: ALTUI: Workflows
Post by: xeinth on April 08, 2016, 10:07:00 am
amg,

One other thing, I know you answered this before but I was wondering if you could be more specific with an example or expression to allow a triggered event from a scene controller.  I can transition states based on a button value, but that works on current state and is not triggered only when pressed.  Obviously we can use a timestamp to calculate this, but that I doubt is the right approach as you'd have to compare to when you entered the state.

Do you have an example which works?

I'm working on a workflow for the home modes, which transitions based on occupancy, time of day etc and drives the AC/security etc.  Thus far seems good but this is one of the issues, and I have yet to work on how to maintain variables of for the AC temp values.

X
Title: Re: ALTUI: Workflows
Post by: amg0 on April 08, 2016, 11:19:42 am
amg,

One other thing, I know you answered this before but I was wondering if you could be more specific with an example or expression to allow a triggered event from a scene controller.  I can transition states based on a button value, but that works on current state and is not triggered only when pressed.  Obviously we can use a timestamp to calculate this, but that I doubt is the right approach as you'd have to compare to when you entered the state.

Do you have an example which works?

I'm working on a workflow for the home modes, which transitions based on occupancy, time of day etc and drives the AC/security etc.  Thus far seems good but this is one of the issues, and I have yet to work on how to maintain variables of for the AC temp values.

X
I ll reply later with an example. I have a working version with lua code in OnEnter and OnExit for states and the ability to use a "Bag" of variables in your workflow code. so for instance I have a OnEnter State Lua code like this

Code: [Select]
-- onEnter
Bag["MyCounter"] = Bag["MyCounter"] or 0
Bag["MyCounter"] = Bag["MyCounter"] + 5
luup.log("Lua code - counter:"..Bag["MyCounter"])

I am still debugging some timer issues and I ll release
Title: Re: ALTUI: Workflows
Post by: xeinth on April 08, 2016, 01:09:10 pm
You make it hard to leave you alone.

The bag stuff, very nice.  A couple of questions, what is the scope of the variables (across workspaces, or within a workspace) and is there some way view them externally?  I assume they will persist across a restart?

The initial use case I'd be looking at this the thermostat values, which would follow the home mode/occupancy but still allow modification up or down from some stimulus like a scene controller or amazon echo triggered scene.

x
Title: Re: ALTUI: Workflows
Post by: amg0 on April 08, 2016, 01:32:30 pm
You make it hard to leave you alone.

The bag stuff, very nice.  A couple of questions, what is the scope of the variables (across workspaces, or within a workspace) and is there some way view them externally?  I assume they will persist across a restart?

The initial use case I'd be looking at this the thermostat values, which would follow the home mode/occupancy but still allow modification up or down from some stimulus like a scene controller or amazon echo triggered scene.

x

Scope is one workflow. 2 workflows can have the same variable name in their Bag, it will not collide. Bag is persistent accross reboot/reload ( such as timers ). State of the OnEnter OnExit lua code and can call Luup.* api in the Global (_G ) space

EDIT:  important :
Title: Re: ALTUI: Workflows
Post by: amg0 on April 08, 2016, 04:12:36 pm
amg,

One other thing, I know you answered this before but I was wondering if you could be more specific with an example or expression to allow a triggered event from a scene controller.  I can transition states based on a button value, but that works on current state and is not triggered only when pressed.  Obviously we can use a timestamp to calculate this, but that I doubt is the right approach as you'd have to compare to when you entered the state.

Do you have an example which works?

I'm working on a workflow for the home modes, which transitions based on occupancy, time of day etc and drives the AC/security etc.  Thus far seems good but this is one of the issues, and I have yet to work on how to maintain variables of for the AC temp values.

X

here is an example where I use a Nodon Octan scene controller ( remote with 4 buttons ). on this device,  once it is set in scene activation mode ( zwave param 3 is set to 1 ), you get the value of the pressed button in the LastSceneID variable of the device. so I use ALTUI watch features to trigger a scene when that variable LastSceneID is changed.

Here is a workflow that does nothing until the first button ( value 10 ) is pressed.  when it is pressed , the workfows goes to another state where it stays there until any button , other than the first one ( so value != 10 ) is pressed. when so, it returns to the first state.
More over, I use a Bag variable to capture the last pressed button and display it

that gives this workflow ( attached sceens )

hope this helps
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 08, 2016, 04:39:18 pm
This is amazing work!!  Thank you!!

Is there an export/import method for the code?  I saved the LUA code from a created workflow, then deleted the workflow.  I then tried to create a new workflow, and copy and paste the code back into the editor, but this didn't work.  Or at least the diagram didn't update. 

Any ideas?  SSH in and replace files somewhere perhaps?
Title: Re: ALTUI: Workflows
Post by: amg0 on April 08, 2016, 04:42:44 pm
This is amazing work!!  Thank you!!

Is there an export/import method for the code?  I saved the LUA code from a created workflow, then deleted the workflow.  I then tried to create a new workflow, and copy and paste the code back into the editor, but this didn't work.  Or at least the diagram didn't update. 

Any ideas?  SSH in and replace files somewhere perhaps?

seems to be often asked for, I need to work on it. but did you try this =>
backup/restore => http://forum.micasaverde.com/index.php/topic,36868.msg277220.html#msg277220
Title: Re: ALTUI: Workflows
Post by: dklinkman on April 08, 2016, 10:49:15 pm
I can hardly keep up with this but it's not like I'm trying.  Updated to latest

AltUI v1.34.1442, ? 2015 amg0

But I see new instability possibly.  I have one simple workflow which is just a 10 second toggle between two states.  Before update it worked just great.  Not exciting but it worked.

But now often I display the workflow, then get message above that controller did not respond.  Message repeats.  Apparently luup is restarting.  After a minute or so I can go back in fresh.

I was hoping to try the workflow reset button and now and again that appears to work.  The graphic shows state returning to start, but then the luup restart happens.  The above happens even without the reset button.  All just timing I guess.

I'll try deleting and recreating the workflow to see if that changes anything.  But this is definitely a thing with the existing workflow.

Cheerz!!    --David
Title: Re: ALTUI: Workflows
Post by: amg0 on April 09, 2016, 02:39:36 am
I can hardly keep up with this but it's not like I'm trying.  Updated to latest

AltUI v1.34.1442, ? 2015 amg0

But I see new instability possibly.  I have one simple workflow which is just a 10 second toggle between two states.  Before update it worked just great.  Not exciting but it worked.

But now often I display the workflow, then get message above that controller did not respond.  Message repeats.  Apparently luup is restarting.  After a minute or so I can go back in fresh.

I was hoping to try the workflow reset button and now and again that appears to work.  The graphic shows state returning to start, but then the luup restart happens.  The above happens even without the reset button.  All just timing I guess.

I'll try deleting and recreating the workflow to see if that changes anything.  But this is definitely a thing with the existing workflow.

Cheerz!!    --David
Try 1 or 2 min instead of 10 sec to see the impact.
The workflow must reach some waiting point at some time, esp in debug mode. If all transition are true and it has to transition state every time and it logs a lot in debug mode you could run into trouble.
You can also try the reset button, but the one on the settings page of altUI device which kills all persistency for a clean restart
Also we need the wflow description and the logs. Without more info, can't really help.
It is working really stable for me now but I do not have workflows like yours
Title: Re: ALTUI: Workflows
Post by: amg0 on April 09, 2016, 07:26:00 am
This is amazing work!!  Thank you!!

Is there an export/import method for the code?  I saved the LUA code from a created workflow, then deleted the workflow.  I then tried to create a new workflow, and copy and paste the code back into the editor, but this didn't work.  Or at least the diagram didn't update. 

Any ideas?  SSH in and replace files somewhere perhaps?

seems to be often asked for, I need to work on it. but did you try this =>
backup/restore => http://forum.micasaverde.com/index.php/topic,36868.msg277220.html#msg277220

in v 1448
Title: Re: ALTUI: Workflows
Post by: xeinth on April 09, 2016, 10:16:49 am
A few comments on capturing scenes below, but just FYI I had another no handler issue on 1.33, but wasnt able to capture when it happened.  I think it could be related to incomplete workflows which are invalid, I'll start disabling them until they are done and see if that helps.


here is an example where I use a Nodon Octan scene controller ( remote with 4 buttons ). on this device,  once it is set in scene activation mode ( zwave param 3 is set to 1 ), you get the value of the pressed button in the LastSceneID variable of the device. so I use ALTUI watch features to trigger a scene when that variable LastSceneID is changed.

Here is a workflow that does nothing until the first button ( value 10 ) is pressed.  when it is pressed , the workfows goes to another state where it stays there until any button , other than the first one ( so value != 10 ) is pressed. when so, it returns to the first state.
More over, I use a Bag variable to capture the last pressed button and display it

that gives this workflow ( attached sceens )

hope this helps

So the scenario I was considering was lights which are auto turned on at night when motion is detected or a door is opened.  In that case, I want to disable the automatic lights for some period of time if they are manually turned off on the scene controller, a lockout.  For this case, image button 10 in your example is 'scene off'.

The issue is that when entering this state in your example, if button 10 is already selected, it will proceed to the manual lock out.  In reality, we only want to do this if the user manually hits the button again after the lights are turned on.  Otherwise, this button press could have been weeks in advance, in theory.  The bag concept is interesting in that we could capture a timestamp entering the state, and then compare with a button press to determine if the new event was after entering the state.  This could also be handled by using multiple states, but that could be somewhat ugly to maintain.

I'll think on it more, but curious if you have thought about this case.  I'm still not caught up on all the other features you've added so I might be missing a elegant solution.

x
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 10, 2016, 09:57:36 am
Is there an export/import method for the code? 

in v 1448


That sir, is awesome.  Already rebuilt the diagrams and exported the resultant code.  Thanks!
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 10, 2016, 10:15:46 am
I wanted to share an example thermostat workflow I created.  This replaced the LUA table based scene control I was using previously, that I had found in this forum for Zwave thermostats.  The problem with the previous scene is that it had to run every 3-5 minutes to work properly, and it was the most problematic scene I had, requiring regular LUA reboots.  This workflow took me about 30 minutes to create.

A few details: 

The workflow does not support "Auto" mode on the thermostat, as I never use it.  The states (Off, Heat, and Cool) have manual transitions in both directions to each other.  All transitions between heat or cool and temperature states are time based, but they can be based on home mode, or other.  The return path from a temperature state back to heat or cool is a simple 5 second timer.  This is a first floor thermostat, I have a separate workflow for the second floor.  Changes to times, or additional temperature set points can be added very quickly and easily.

The workflow tool has a lot of possibilities.  Thanks to the creator for all the hard work on this!
Title: Re: ALTUI: Workflows
Post by: amg0 on April 10, 2016, 10:20:05 am
I wanted to share an example thermostat workflow I created.  This replaced the LUA table based scene control I was using previously, that I had found in this forum for Zwave thermostats.  The problem with the previous scene is that it had to run every 3-5 minutes to work properly, and it was the most problematic scene I had, requiring regular LUA reboots.  This workflow took me about 30 minutes to create.

A few details: 

The workflow does not support "Auto" mode on the thermostat, as I never use it.  The states (Off, Heat, and Cool) have manual transitions in both directions to each other.  All transitions between heat or cool and temperature states are time based, but they can be based on home mode, or other.  The return path from a temperature state back to heat or cool is a simple 5 second timer.  This is a first floor thermostat, I have a separate workflow for the second floor.  Changes to times, or additional temperature set points can be added very quickly and easily.

The workflow tool has a lot of possibilities.  Thanks to the creator for all the hard work on this!

Good lord... is not that impressive ? thanks a lot for sharing
Title: Re: ALTUI: Workflows
Post by: amg0 on April 10, 2016, 10:23:22 am
A few comments on capturing scenes below, but just FYI I had another no handler issue on 1.33, but wasnt able to capture when it happened.  I think it could be related to incomplete workflows which are invalid, I'll start disabling them until they are done and see if that helps.


here is an example where I use a Nodon Octan scene controller ( remote with 4 buttons ). on this device,  once it is set in scene activation mode ( zwave param 3 is set to 1 ), you get the value of the pressed button in the LastSceneID variable of the device. so I use ALTUI watch features to trigger a scene when that variable LastSceneID is changed.

Here is a workflow that does nothing until the first button ( value 10 ) is pressed.  when it is pressed , the workfows goes to another state where it stays there until any button , other than the first one ( so value != 10 ) is pressed. when so, it returns to the first state.
More over, I use a Bag variable to capture the last pressed button and display it

that gives this workflow ( attached sceens )

hope this helps

So the scenario I was considering was lights which are auto turned on at night when motion is detected or a door is opened.  In that case, I want to disable the automatic lights for some period of time if they are manually turned off on the scene controller, a lockout.  For this case, image button 10 in your example is 'scene off'.

The issue is that when entering this state in your example, if button 10 is already selected, it will proceed to the manual lock out.  In reality, we only want to do this if the user manually hits the button again after the lights are turned on.  Otherwise, this button press could have been weeks in advance, in theory.  The bag concept is interesting in that we could capture a timestamp entering the state, and then compare with a button press to determine if the new event was after entering the state.  This could also be handled by using multiple states, but that could be somewhat ugly to maintain.

I'll think on it more, but curious if you have thought about this case.  I'm still not caught up on all the other features you've added so I might be missing a elegant solution.

x

I did not really try this for real but could something like that solve this problem ?
Title: Re: ALTUI: Workflows
Post by: tomtcom on April 10, 2016, 10:34:39 am
My apologies folks, quick question. I have read amg0's description and searched this thread. Is workflows supposed to replace scenes? Is it supposed to be more flexible than Vera scenes?
Title: Re: ALTUI: Workflows
Post by: amg0 on April 10, 2016, 10:47:52 am
My apologies folks, quick question. I have read amg0's description and searched this thread. Is workflows supposed to replace scenes? Is it supposed to be more flexible than Vera scenes?

you can replace some scenes with workflow.  I would  not recommend going extreme on this and replace all scene. but sometime it make sense. I see 2 examples where it could make sense to use workflow instead of scene

a) scheduled scene ( every x min ) have a problem for instance. if they run before luup finished initializing and running your startup.lua ( which is a bug in my opinion that mcv should fix ) then scene code crashs and you sporadically get the "Global lua error" message unti l you force a manual restart of luup.   for these, workflow are good so I had a scene which ran every 15mn to update data in thingspeak and I replaced this with a workflow because of that bug

b) workflow are superior to scene when what you want to do requires a "memory" of what happened before.  workflows are a logical state machine ( like petri network ) and because the current active state drives which transitions happen, it means you can have dynamic behaviors which depends on what happened the past...   example : a motion will trigger a lamp on and switch it off later,  but only if the lamp was not set manually on before.  another example : a alert/message can be sent after a garage door has been left open for more than 30mn and after 9:00pm.   

All this is feasible with scene and lua , BUT  remember that lua set timer () are not persistent to reboot/reload so you can get in trouble. I have persistent timers for workflows...

to some extend workflows are superior to scenes , just like PLEG is superior to scenes, and workflows sit in between VERA scenes and PLEG. they are more powerful than scenes,  probably less powerful than PLEG , but with a wysiwig editor and you can track it visually in almost real time.

now workflows are still a "young" techno so far so we may encounter some issues/limits... and most importantly they are not native to VERA UIx so the drawback is they can only work if you use ALTUI . that is the price of it...
Title: Re: ALTUI: Workflows
Post by: tomtcom on April 10, 2016, 11:20:14 am
Thank you for this. Now I understand better. My scenes are not complex so I'll see what I can convert easily. Thanks.
Title: Re: ALTUI: Workflows
Post by: akbooer on April 10, 2016, 11:48:55 am
now workflows are still a "young" techno so far so we may encountner some issues/limits... and most importantly they are not native to VERA UIx so the drawback is they can only work if you use ALTUI . that is the price of it...

No, no.  That is the advantage of AltUI.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 10, 2016, 01:33:27 pm
now workflows are still a "young" techno so far so we may encountner some issues/limits... and most importantly they are not native to VERA UIx so the drawback is they can only work if you use ALTUI . that is the price of it...

No, no.  That is the advantage of AltUI.
:)
Title: Re: ALTUI: Workflows
Post by: xeinth on April 10, 2016, 01:57:08 pm
Quote from: amg0 link=topic=36868.msg278189#msg278189 date=1460298202

I did not really try this for real but could something like that solve this problem ?
[/quote

I think this or something like this could work, thats sort of what I was referring to when I said you could solve the problem with multiple states.  It does work, but if you had several triggers in play it could get a bit cumbersome.  I'd still think you need to do a time comparison as I did this sort of flow you had before, and it required the user to turn on the scene before turning off to disable (it seems you have it the same way).  Ideally its just a tap of the off button, which can't be detected with a flow like this unless you have a time check.

Now that you have Lua in the states that may be the easiest way to do it.
x
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 10, 2016, 02:17:03 pm
One issue I may have discovered, perhaps it's by design?  When setting up a transition with multiple items, the Devices category seemed to be logical "OR'd" with the Schedules category. Should this be a logical AND across categories, or maybe a check box to do either? I understand that multiple entries within the Devices category are logical ANDs.  I didn't try Timers vs Schedules and/or Devices to determine their combined logical operation.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 10, 2016, 02:46:37 pm
One issue I may have discovered, perhaps it's by design?  When setting up a transition with multiple items, the Devices category seemed to be logical "OR'd" with the Schedules category. Should this be a logical AND across categories, or maybe a check box to do either? I understand that multiple entries within the Devices category are logical ANDs.  I didn't try Timers vs Schedules and/or Devices to determine their combined logical operation.

All device conditions must match. If there is a timer it is : ( all conditions ) or timer. This gives ability to set maximum amount of time to wait for a transition to happen.

Schedule is a different beast , it is not evaluated when I evaluate the transitions of a new state. And other parameters ( device conditions, timer) do not matter. A schedule is just happening (at the time it is programmed) and when it happens and if the active state is the source state of the transition , then is just considered to be true and fires the transition to the target state.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 10, 2016, 02:59:48 pm
I think this or something like this could work, thats sort of what I was referring to when I said you could solve the problem with multiple states.  It does work, but if you had several triggers in play it could get a bit cumbersome.  I'd still think you need to do a time comparison as I did this sort of flow you had before, and it required the user to turn on the scene before turning off to disable (it seems you have it the same way).  Ideally its just a tap of the off button, which can't be detected with a flow like this unless you have a time check.

Now that you have Lua in the states that may be the easiest way to do it.
x
Still hoping we can avoid Lua or time stamps magic, but I am thinking maybe to differentiate a trigger ( a change of the value, so only true one time ) from an evaluation of an expression which is true and remains true as the variable won't change...
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 10, 2016, 03:08:11 pm
I understand.  I think some way to tie schedules and devices together with a logical "AND" would be very useful though, if it's trivial to do.

In my thermostat scene posted above, I would like all the "Schedule" transitions between "Heat/Cool" states and "Temp Set" states to only trigger when not in Vacation mode.  I'm open to other ideas on how to do this...I just didn't want to create a bunch of additional states in order to do it.  I attempted to couple both a schedule and "House Mode Plugin" device, but realized it was a logical "OR" at that point.

I also noticed that when a Schedule transition is utilized in a workflow, an actual scene is created under the "Scenes" menu.  Can I change the "House Modes" option on all the scenes for this workflow without affecting anything?

I'm open to other ideas on how to Transition at time X, but only when not in Vacation mode.  I could probably use multiswitch, or multistring plugins somehow too.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 10, 2016, 03:34:30 pm
I understand.  I think some way to tie schedules and devices together with a logical "AND" would be very useful though, if it's trivial to do.
what I could probably do is to evaluate the transitions device conditions when the schedule happens and only accept the transitions if the conditions are true. will look at that

In my thermostat scene posted above, I would like all the "Schedule" transitions between "Heat/Cool" states and "Temp Set" states to only trigger when not in Vacation mode.  I'm open to other ideas on how to do this...I just didn't want to create a bunch of additional states in order to do it.  I attempted to couple both a schedule and "House Mode Plugin" device, but realized it was a logical "OR" at that point.
since transition device conditions are lua expressions, nothing prevents you from using the house mode Plugin and put something like :  xxx and luup.get_variable( ) ~= vacation_mode_value in the expression field.

I also noticed that when a Schedule transition is utilized in a workflow, an actual scene is created under the "Scenes" menu.  Can I change the "House Modes" option on all the scenes for this workflow without affecting anything?
should work but I am not sure if you will loose that setting if you then edit the schedule ( since I edit the scene ). to be tested
I'm open to other ideas on how to Transition at time X, but only when not in Vacation mode.  I could probably use multiswitch, or multistring plugins somehow too.
your ideas about mode on scene is good idea, I just do not have a UI for that at the moment.
Title: Re: ALTUI: Workflows
Post by: akbooer on April 10, 2016, 03:50:37 pm
since transition device conditions are lua expressions, nothing prevents you from using the house mode Plugin and put something like :  xxx and luup.get_variable( ) ~= vacation_mode_value in the expression field.

Recall that, specifically for house modes, you can simply get them directly with

Code: [Select]
local m = luup.attr_get "Mode"
Title: Re: ALTUI: Workflows
Post by: amg0 on April 11, 2016, 03:57:33 pm
Some information about v1461 and the new TriggerOnly flag on a transition.

Transitions conditions are a boolean expression based on a device variable value. this expression is evaluated true or false and depending the result , the transition link is valid and the state change.

With the new TriggerOnly flag, the expression is only considered true the first time ( when the device variable value changes ). in other terms, it is like the LUA watch, the variable changes and the watch callback happens, but then the watch callback does not happen again until the variable changes.

so, a condition like "new == '1' " which would be marked as TriggerOnly , would only be considered true once, when the variable just take the value "1",  but then, even if the variable stays at value "1", it is not considered true, until the time where it had change its value to something else like 0 and then comes back to 1

Typically can be used for the remote btn 1 example discussed earlier in that thread, it simplifies a lot the workflow.

here is an example of a stupid workflow with 2 states linked by 2 transitions, each of them pointing to the same device, variable with expression new == '1'

if both are ongoing conditions the workflow will keep flip flop between the 2 states.  if you set one of them as TriggerOnly, the workflow will stay stuck on that state until you change the device variable to 0, then to 1 again. at that point it will go to the S1 state, evaluate the next transition ( ongoing ) so goes to state S2 , then get stuck until the next trigger on new == 1 happens

The "Flash" icon in the workflow reports means a condition that is marked as "TriggerOnly"
Title: Re: ALTUI: Workflows
Post by: amg0 on April 11, 2016, 04:12:09 pm
I understand.  I think some way to tie schedules and devices together with a logical "AND" would be very useful though, if it's trivial to do.

In my thermostat scene posted above, I would like all the "Schedule" transitions between "Heat/Cool" states and "Temp Set" states to only trigger when not in Vacation mode.  I'm open to other ideas on how to do this...I just didn't want to create a bunch of additional states in order to do it.  I attempted to couple both a schedule and "House Mode Plugin" device, but realized it was a logical "OR" at that point.

I also noticed that when a Schedule transition is utilized in a workflow, an actual scene is created under the "Scenes" menu.  Can I change the "House Modes" option on all the scenes for this workflow without affecting anything?

I'm open to other ideas on how to Transition at time X, but only when not in Vacation mode.  I could probably use multiswitch, or multistring plugins somehow too.

Just to confirm the exact behaviors of transitions

if a schedule is present,  when that schedule executes the transition executes. whatever the other parameters of that transition.

Otherwise, if a timer is present and the timer has expired, the transition executes, whatever the other parameters of that transition.

Otherwise, all conditions are evaluated and the "AND" result must be true.  TriggerOnly conditons ( as explained ) are only considered true the first time, when the device variable just changed

so transition = (SCHEDULE)  or ( TIMER  ) or ( ALL conditions )
Title: Re: ALTUI: Workflows
Post by: amg0 on April 12, 2016, 03:27:04 am
A few comments on capturing scenes below, but just FYI I had another no handler issue on 1.33, but wasnt able to capture when it happened.  I think it could be related to incomplete workflows which are invalid, I'll start disabling them until they are done and see if that helps.


here is an example where I use a Nodon Octan scene controller ( remote with 4 buttons ). on this device,  once it is set in scene activation mode ( zwave param 3 is set to 1 ), you get the value of the pressed button in the LastSceneID variable of the device. so I use ALTUI watch features to trigger a scene when that variable LastSceneID is changed.

Here is a workflow that does nothing until the first button ( value 10 ) is pressed.  when it is pressed , the workfows goes to another state where it stays there until any button , other than the first one ( so value != 10 ) is pressed. when so, it returns to the first state.
More over, I use a Bag variable to capture the last pressed button and display it

that gives this workflow ( attached sceens )

hope this helps

So the scenario I was considering was lights which are auto turned on at night when motion is detected or a door is opened.  In that case, I want to disable the automatic lights for some period of time if they are manually turned off on the scene controller, a lockout.  For this case, image button 10 in your example is 'scene off'.

The issue is that when entering this state in your example, if button 10 is already selected, it will proceed to the manual lock out.  In reality, we only want to do this if the user manually hits the button again after the lights are turned on.  Otherwise, this button press could have been weeks in advance, in theory.  The bag concept is interesting in that we could capture a timestamp entering the state, and then compare with a button press to determine if the new event was after entering the state.  This could also be handled by using multiple states, but that could be somewhat ugly to maintain.

I'll think on it more, but curious if you have thought about this case.  I'm still not caught up on all the other features you've added so I might be missing a elegant solution.

x

I did not really try this for real but could something like that solve this problem ?
with the new triggeronly option on transiton, that example does not need the extra state on the right any more. you just need to set the transtion "Remote btn1" to be trigger based and it will not fire a second time until that button is changed at least once
Title: Re: ALTUI: Workflows
Post by: amg0 on April 12, 2016, 05:46:46 pm
I understand.  I think some way to tie schedules and devices together with a logical "AND" would be very useful though, if it's trivial to do.

In my thermostat scene posted above, I would like all the "Schedule" transitions between "Heat/Cool" states and "Temp Set" states to only trigger when not in Vacation mode.  I'm open to other ideas on how to do this...I just didn't want to create a bunch of additional states in order to do it.  I attempted to couple both a schedule and "House Mode Plugin" device, but realized it was a logical "OR" at that point.

I also noticed that when a Schedule transition is utilized in a workflow, an actual scene is created under the "Scenes" menu.  Can I change the "House Modes" option on all the scenes for this workflow without affecting anything?

I'm open to other ideas on how to Transition at time X, but only when not in Vacation mode.  I could probably use multiswitch, or multistring plugins somehow too.

I have released 1471 which includes support for house modes in programming scheduled transitions
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 12, 2016, 08:26:52 pm
I have released 1471 which includes support for house modes in programming scheduled transitions

What a great addition!!  Some of the other items included in the list for this update are great too!!  You've really been working hard on this!  Thanks amg0!

So I went through a couple of my more complicated workflows with scheduled transitions...deleted the scheduled transitions, and then re-added them with the desired "House Modes" option included.  When I clicked "Save" I got the code review window, clicked "Save again and got a "moving refresh circular arrow" for one second, and then blank screen.  Hit F5 refresh, went back to the workflow and checked, and all setting changes stuck.  Then went back to main "Workflows" screen, and hit "Save" there and got the same result.  They seem to be working with the new house modes option though, so I'm not too worried about it.  Just thought I'd let you know.

When I edited other workflows without a scheduled transition, I did not get the blank screen.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 13, 2016, 07:44:55 am
I have released 1471 which includes support for house modes in programming scheduled transitions

What a great addition!!  Some of the other items included in the list for this update are great too!!  You've really been working hard on this!  Thanks amg0!

So I went through a couple of my more complicated workflows with scheduled transitions...deleted the scheduled transitions, and then re-added them with the desired "House Modes" option included.  When I clicked "Save" I got the code review window, clicked "Save again and got a "moving refresh circular arrow" for one second, and then blank screen.  Hit F5 refresh, went back to the workflow and checked, and all setting changes stuck.  Then went back to main "Workflows" screen, and hit "Save" there and got the same result.  They seem to be working with the new house modes option though, so I'm not too worried about it.  Just thought I'd let you know.

When I edited other workflows without a scheduled transition, I did not get the blank screen.

just a note, if you get a code review window, it means your ALTUI is in DEBUG mode. just wanted to make sure you are aware of that as it populates quite generously your log files :-)

The moving refresh circular window only happens if the workflow has to save or edit or delete an underlying scene, meaning you have ( or had ) a scheduled transition in your workflow.  I am not reproducing your problem which seems to be linked to several conditions together:  debug mode + saving a workflow with a scheduled transition.

I ll try again
Title: Re: ALTUI: Workflows
Post by: javed222uy on April 14, 2016, 09:13:18 am
Hello Amg0!
Since yesterday the workflows does not reflect the real change in device status. which would be the problem?
Thanks!
Title: Re: ALTUI: Workflows
Post by: amg0 on April 14, 2016, 10:21:07 am
Hello Amg0!
Since yesterday the workflows does not reflect the real change in device status. which would be the problem?
Thanks!

without further information, I cannot help.  you need to give me much more details and eventually DEBUG mode log files.
one thing to try is to press the RESET button on ALTUI device Settings tab or from the ALTU UPNP actions dialog box ( the parameterless reset )
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 14, 2016, 01:09:53 pm
Getting the following warning today (AltUI is device 153)

warning device:153 has duplicate state id 47 for variables: Wflow_House+Mode_13 , Wflow_2nd+Floor+Thermostat_4

I was under the assumption that variables in different workflows should not conflict at all.  There are no similarly named states in the two mentioned workflows.  Tried a restart of the plugin, and restart of the hub, still getting the error.
Title: Re: ALTUI: Workflows
Post by: amg0 on April 14, 2016, 01:22:06 pm
I had this so I added this warning in the console.log so that we can be aware. we have to monitor this issue to see if it develops but aside from hard reboot I am not sure where it could come from.
it has nothing to do with workflow this is about device variables , you have 2 variables which have the same internal id.
Maybe it is some concurency issues at the time of saving the workflows... not sure

you should be able to fix it this way:
a) do a backup of your file user_data.json.lzo in /etc/cmh of your vera. save it somewhere
b) go to ALTUI MISC DEBUG , you should find a button " Fix device State "
c) clikc on it and enter "0-153" if 153 is the device id that is complaining and click execute
d) you should get an OK message.  it will reload luup and then in the console.log you should not have this warning again
Title: Re: ALTUI: Workflows
Post by: tedp on April 14, 2016, 04:58:23 pm
I just noticed this oddity and am attaching the state transitions. As I've described in an example, I have a workflow that "arms" when ANY one of multiple sensors is tripped. After a certain timeout (half hour), I get a notification.

Here's what happened:
4/14/16 9:17:16.105 I got my notification (forgot to close a window).
4/14/16 9:37:44.856 I went to close the window (so the timer should have reset since only 20 of the full 30 minutes expired)
There were several open and close events (front door opening and closing), but at
4/14/16 9:34:08.984 The garage opened

here's the strange part:
4/14/16 9:47.17.758 I got a timeout notification.

So it seems that the timer was still counting after the 1st time I was notified (exactly half hour earlier) at 9:17:16.105.

My question: is the timer supposed to reset every time I enter my "Wait for Timer" state?
Title: Re: ALTUI: Workflows
Post by: amg0 on April 14, 2016, 05:41:19 pm
I just noticed this oddity and am attaching the state transitions. As I've described in an example, I have a workflow that "arms" when ANY one of multiple sensors is tripped. After a certain timeout (half hour), I get a notification.

Here's what happened:
4/14/16 9:17:16.105 I got my notification (forgot to close a window).
4/14/16 9:37:44.856 I went to close the window (so the timer should have reset since only 20 of the full 30 minutes expired)
There were several open and close events (front door opening and closing), but at
4/14/16 9:34:08.984 The garage opened

here's the strange part:
4/14/16 9:47.17.758 I got a timeout notification.

So it seems that the timer was still counting after the 1st time I was notified (exactly half hour earlier) at 9:17:16.105.

My question: is the timer supposed to reset every time I enter my "Wait for Timer" state?
answer is : yes ,a timer is only valid for the start state it was started from. if state change, all timer should be cancelled. I need to verify if I have a bug here, it is possible

maybe the reset to START state is not resetting times properly. note that in VERA timer cannot be reset !  so in fact it continues to run but should be ignored by the workflow, if it is not expecting a timer to come...
Title: Re: ALTUI: Workflows
Post by: tedp on April 14, 2016, 05:48:39 pm
OK -- looks like you got the gist of it. Either way, I'm happy because I'm not forgetting windows open any more :)

Thanks again!
Title: Re: ALTUI: Workflows
Post by: amg0 on April 14, 2016, 06:04:41 pm
this should fix it, I ll include in next release
the rule is : when leaving a state, all timers issued from that state are cancelled ( virtually as on vera we cannot cancel timers )
Title: Re: ALTUI: Workflows
Post by: tedp on April 14, 2016, 06:10:23 pm
Awesome!!! Not to ask for too many features, but would it be possible to add "on enter" and "on exit" actions for the initial Start state? For my example workflow, It would be nice to send a "secured" notification when all sensors are no longer tripped (and we globally set a link to the "start" state). I can see some possible weird side effects when starting up the machine, rebooting... Just a thought :)
Title: Re: ALTUI: Workflows
Post by: amg0 on April 15, 2016, 05:50:12 am
Awesome!!! Not to ask for too many features, but would it be possible to add "on enter" and "on exit" actions for the initial Start state? For my example workflow, It would be nice to send a "secured" notification when all sensors are no longer tripped (and we globally set a link to the "start" state). I can see some possible weird side effects when starting up the machine, rebooting... Just a thought :)

I understand but i d like to keep away from that. start state is like both transitions and state. I gave him the transition personality ( having conditions that brings back workflow to start when they match ) and giving him now the State personality with onEnter etc.. would create quite some complexities, both on the back end side and on the front end side

plus there is an easy workaround with a real first state that is just after start with a timer 1s link between the 2 and you implement all your logic in here. that actually would probably be cleaner than overusing START which is not supposed to be state. it must be a transient point you go through it at start but immediately set your workflow to somewhere else
Title: Re: ALTUI: Workflows
Post by: amg0 on April 15, 2016, 09:02:45 am
Another workflow example:

a smart way to manage window cover, which goes up and down depending on the light in the room, but enables the user to override the mecanisms and force the window cover to be open or closed without letting the light level influence that.

I attached workflow diagram & details report with a couple of "pay attention" tips
Title: Re: ALTUI: Workflows
Post by: tedp on April 15, 2016, 10:54:07 am
Awesome!!! Not to ask for too many features, but would it be possible to add "on enter" and "on exit" actions for the initial Start state? For my example workflow, It would be nice to send a "secured" notification when all sensors are no longer tripped (and we globally set a link to the "start" state). I can see some possible weird side effects when starting up the machine, rebooting... Just a thought :)

I understand but i d like to keep away from that. start state is like both transitions and state. I gave him the transition personality ( having conditions that brings back workflow to start when they match ) and giving him now the State personality with onEnter etc.. would create quite some complexities, both on the back end side and on the front end side

plus there is an easy workaround with a real first state that is just after start with a timer 1s link between the 2 and you implement all your logic in here. that actually would probably be cleaner than overusing START which is not supposed to be state. it must be a transient point you go through it at start but immediately set your workflow to somewhere else
OK, your solution makes sense.

Thanks!

Sent from my Moto X using Tapatalk

Title: Re: ALTUI: Workflows
Post by: xeinth on April 16, 2016, 04:52:56 pm
I've got an hour to kill before I head out for a week and won't be able to play with this again, but I wanted to say thanks for the work here.  This thing is getting close to critical mass and I think I'm close to having my house mode/climate control workflow workable.  Much thanks for adding the triggers, I've added some and will check out there functionality.  One thing that isnt clear is if they just fire once or if they only fire if a trigger occurs after entering the state.

One thing I can see would be useful is to have a transition conditioned on a Bag variable.  Of course, since Bag contents are set entering or leaving the state they cant change while in the state (and thus cant be the sole criteria for a condition), but they could be useful for doing logical masking of a transition.  Think occupancy detection or home modes, etc.

x
Title: Re: ALTUI: Workflows
Post by: amg0 on April 16, 2016, 05:53:05 pm
I've got an hour to kill before I head out for a week and won't be able to play with this again, but I wanted to say thanks for the work here.  This thing is getting close to critical mass and I think I'm close to having my house mode/climate control workflow workable.  Much thanks for adding the triggers, I've added some and will check out there functionality.  One thing that isnt clear is if they just fire once or if they only fire if a trigger occurs after entering the state.

it happens this way: when a variable (only the variable used in workflows) changes, each workflow active state is looked at. for each state, all transitions are evaluated. if one is a condition with this variable and the lua expression is true, then 2 things can happen:
a) it was a trigger transition and therefore, even if the lua expression is true, it only matches if the trigger (i.e. the variable that changed and triggered that whole process ) is the same variable as the one declared on that particular transition
b) otherwise, it was not a trigger transition and in that case, the lua expression is simply evaluated : if true, it matches, if false it does not

One thing I can see would be useful is to have a transition conditioned on a Bag variable.  Of course, since Bag contents are set entering or leaving the state they cant change while in the state (and thus cant be the sole criteria for a condition), but they could be useful for doing logical masking of a transition.  Think occupancy detection or home modes, etc.

x
Yes I have to think about this one... no answer yet.
of course already now, the lua expression of a transition can use bag.
Code: [Select]
new == '1' and Bag[name]>3
Title: Re: ALTUI: Workflows
Post by: amg0 on April 17, 2016, 11:48:51 am
One thing I can see would be useful is to have a transition conditioned on a Bag variable.  Of course, since Bag contents are set entering or leaving the state they cant change while in the state (and thus cant be the sole criteria for a condition), but they could be useful for doing logical masking of a transition.  Think occupancy detection or home modes, etc.
x

it does work already , here is an example of a workflow which counts up to 5
The only trick is to have a transition based on a variable that does not matter ( I picked ALTUI / Debug ) and have the lua expression only check the bag variable, in this case the transition lua expression  : "Bag["counter"] >= 5"

if the transition was marked as triggeronly, it would never match and the workflow would keep counting up.
Title: Re: ALTUI: Workflows
Post by: xeinth on April 17, 2016, 01:58:38 pm

it does work already , here is an example of a workflow which counts up to 5
The only trick is to have a transition based on a variable that does not matter ( I picked ALTUI / Debug ) and have the lua expression only check the bag variable, in this case the transition lua expression  : "Bag["counter"] >= 5"

if the transition was marked as triggeronly, it would never match and the workflow would keep counting up.

Thanks, when you mentioned it earlier I realized that probably is workable.  I've almost got my House/AC control implemented, but I did run into one more thing, I thought I would mention in case there was a easier solution.  Effectively I have a occupancy detector which evaluates a bunch of sensors and determines if someone is present or not, and adjusts the AC accordingly.  The issue  is the logic needs to be an OR, and after that I need a timer to delay the switch.  I can separate that into separate states and transitions, but the OR of the conditions is problematic.  I can invert the logic on one side and do AND the lack of activity on all of them, but when exiting the state I need to invert that.  Having a unique transition for each sensor is somewhat problematic.

Is there a custom way to use Lua expressions to customize the logic?  I was thinking I could store the results in a bag but the state only runs once on entry and on exit.  If there was a way to re-evalute these while in the state, I could then use that for a transition.

Anyways, thanks for the work.  This is really cool.

Title: Re: ALTUI: Workflows
Post by: amg0 on April 17, 2016, 03:57:28 pm

it does work already , here is an example of a workflow which counts up to 5
The only trick is to have a transition based on a variable that does not matter ( I picked ALTUI / Debug ) and have the lua expression only check the bag variable, in this case the transition lua expression  : "Bag["counter"] >= 5"

if the transition was marked as triggeronly, it would never match and the workflow would keep counting up.

Thanks, when you mentioned it earlier I realized that probably is workable.  I've almost got my House/AC control implemented, but I did run into one more thing, I thought I would mention in case there was a easier solution.  Effectively I have a occupancy detector which evaluates a bunch of sensors and determines if someone is present or not, and adjusts the AC accordingly.  The issue  is the logic needs to be an OR, and after that I need a timer to delay the switch.  I can separate that into separate states and transitions, but the OR of the conditions is problematic.  I can invert the logic on one side and do AND the lack of activity on all of them, but when exiting the state I need to invert that.  Having a unique transition for each sensor is somewhat problematic.

Is there a custom way to use Lua expressions to customize the logic?  I was thinking I could store the results in a bag but the state only runs once on entry and on exit.  If there was a way to re-evalute these while in the state, I could then use that for a transition.

Anyways, thanks for the work.  This is really cool.

really hard to understand without more details.
one idea could be use a Bag["active_sensors"] and increment it every time one of your sensor is active then
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 20, 2016, 01:18:27 pm
Petition for AltUI to become UI8

http://www.ipetitions.com/petition/altui-for-ui8
Title: Re: ALTUI: Workflows
Post by: amg0 on April 20, 2016, 03:34:49 pm
Petition for AltUI to become UI8

http://www.ipetitions.com/petition/altui-for-ui8

funny... I signed
Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 20, 2016, 04:06:05 pm
(... I am stilling laughing...)
However, I see you just put a guide in Post #2..

I will attempt that
Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 20, 2016, 04:22:12 pm
Ok I am back..

Yes.. I need a walkthrough with screenshots..

Everything I attempt never works..
Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 20, 2016, 04:30:53 pm
for example...

why does this never fire

Workflow Report
Living Room Motion - (0-2)
2 States: Start, S1
1 Transitions: label
Details
Start - 1b0bce04-8902-4078-9588-36913c31fcf7
Global Conditions
 Trigger, device:'Living Room Motion' (0-20016) when urn:micasaverde-com:serviceId:SecuritySensor1-Tripped (new=1)
Transitions
'label' - 58bd5169-f7f7-4035-ab69-16b937c32e50
When
Moves To
State: S1
S1 - bddf5200-07c9-4281-b2e6-1b88438d73d0
OnEnter
Lua
luup.inet.wget("http://192.168.2.30/jsonrpc?request=%7B%22jsonrpc%22:%222.0%22,%22method%22:%22GUI.ShowNotification%22,%22params%22:%7B%22title%22:%22Motion%20Detected%22,%22message%22:%22Living%20Room%22%7D,%22id%22:1%7D")
Title: Re: ALTUI: Workflows
Post by: amg0 on April 20, 2016, 04:43:51 pm
for example...

why does this never fire

Workflow Report
Living Room Motion - (0-2)
2 States: Start, S1
1 Transitions: label
Details
Start - 1b0bce04-8902-4078-9588-36913c31fcf7
Global Conditions
 Trigger, device:'Living Room Motion' (0-20016) when urn:micasaverde-com:serviceId:SecuritySensor1-Tripped (new=1)
Transitions
'label' - 58bd5169-f7f7-4035-ab69-16b937c32e50
When
Moves To
State: S1
S1 - bddf5200-07c9-4281-b2e6-1b88438d73d0
OnEnter
Lua
luup.inet.wget("http://192.168.2.30/jsonrpc?request=%7B%22jsonrpc%22:%222.0%22,%22method%22:%22GUI.ShowNotification%22,%22params%22:%7B%22title%22:%22Motion%20Detected%22,%22message%22:%22Living%20Room%22%7D,%22id%22:1%7D")

a) conditions in START are special things. they are evaluated everywhere time/everywhere in the workflow and if true they reset the workflow to start. ignore this for now, remove it

b) put the  Trigger, device:'Living Room Motion' in your transition between start and S1

c) for now, just in case there is bug in LUA code for escape and caracters, try something more simple in the lua like a luup.log('xxx')


Typically you would not use start state too much, you would try to quickly leave it, it is just there to initialize from scratch a workflow. so you could have
Start
transtion to S1 with a timer 1second

S1 = wait state
transition to S2 with a trigger on your motion detector

S2 = notificaiton state
lua code to send your notification
transition to S1 when the motion detector cancels the motion signal for instance or after a timer

workflow should then oscillate between S1 and S2,  until you reset it


one last thing. you must SAVE the workflow to force the LUA drive to take it into account. eventually try a reset too if it does not start
with the workflow above, after 1sec you should be in S1 state
Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 20, 2016, 04:55:30 pm
Thanks..
Looking at my screenshot..
in S1, why cant I select tripped like I can in start
Title: Re: ALTUI: Workflows
Post by: amg0 on April 20, 2016, 05:03:47 pm
Thanks..
Looking at my screenshot..
in S1, why cant I select tripped like I can in start

because you are in ACTION screen. not condition.
State have actions
Transitions have conditions
Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 20, 2016, 05:06:28 pm
AH!!!
I didnt know you could click on the links..
Title: Re: ALTUI: Workflows
Post by: amg0 on April 20, 2016, 05:21:04 pm
AH!!!
I didnt know you could click on the links..
Plus i probably confused you with the start state. Start state is Elvis Presley, neither dead nor alive, it is a state but behaves like a transition and when you edit it , it is like editing a transition. It is because starts states remembers global conditions which are valid from wherever in the workflow and if true, they reset the workflow to start ...
Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 20, 2016, 05:27:23 pm
im still struggling.. any chance you could export a workflow that I can import and just see what a working one should look like
Title: Re: ALTUI: Workflows
Post by: amg0 on April 20, 2016, 05:30:01 pm
im still struggling.. any chance you could export a workflow that I can import and just see what a working one should look like
Export import won't really work as my devices number are different , I ll try tomorrow.
but they are pdf examples earlier in that thread that could be useful
Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 20, 2016, 05:30:42 pm
grand ill check those in more detail
Title: Re: ALTUI: Workflows
Post by: ndoggac on April 21, 2016, 01:10:33 am
Use new==1 instead of new=1
Title: Re: ALTUI: Workflows
Post by: amg0 on April 21, 2016, 02:03:59 am
Use new==1 instead of new=1

2 important thing
a) equal operator in lua is == ( double ).  not equal is ~= .  use these.  new=1 will just do an assignment, not a comparison
b) device variables are string typed value, and must be compared as such

so it must be either

new == '1'
or
tonumber(new)==1
Title: Re: ALTUI: Workflows
Post by: amg0 on April 24, 2016, 03:42:46 pm
just a note to workflow users; there is a new function available for your workflow lua actions:
ALTUI_notify

Code: [Select]
ALTUI_notify( "your pushing box device ID" , "Your Message" )
Pushingbox is https://www.pushingbox.com/ (https://www.pushingbox.com/) and enables you to create notifications via several media ( email, twitters, Karotz, all kind of phone notifications etc ). ALTUI will take care of notifying pushingbox for you when you call this function , and pushingbox will notify your devices according to what you have configured.

EDIT 5/11/2016: modified this to have a global object called ALTUI, which exposes 2 methods you can use in scene, watches, worfklows...

so now you would do
Code: [Select]
ALTUI.notify( "your pushing box device ID" , "Your Message" )
Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 26, 2016, 04:37:51 am
I am sorry but I am back again.. I am really not getting how workflows work or flow


Could someone tell me whats wrong with this flow.
My goal is as follows:
Its night  then turn on outside lights

The alarm is now set to Stay/Home so turn off the lights

or its the alarm was never set but day has arrived so turn off the light

Code: [Select]
Start - ffc226b5-b8e3-4635-a368-5f97236d73f0
Transitions
'itsNight' - 5f0dd9f8-9ec2-4d47-86ea-190b597a037c
When
device:'DayNight' (0-9) when urn:rts-services-com:serviceId:DayTime-Status (((luup.variable_get("urn:rts-services-com:serviceId:DayTime", "Status", 9)) == '0'))
device:'House Alarm' (0-10053) when urn:micasaverde-com:serviceId:AlarmPartition2-Alarm (((luup.variable_get("urn:micasaverde-com:serviceId:AlarmPartition2", "DetailedArmMode", 10053)) ~= 'Stay'))
Moves To
State: Turn On Outside Lights
Turn On Outside Lights - 002f5d89-81aa-469a-938d-3151e35c9570
OnEnter
on 0-20012 urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":"1"}]
Transitions
'itsDay' - 0a71737d-10a9-4bdf-8386-5405cf491f7f
When
device:'DayNight' (0-9) when urn:rts-services-com:serviceId:DayTime-Status (((luup.variable_get("urn:rts-services-com:serviceId:DayTime", "Status", 9)) == '1'))
Moves To
State: Turn Off Outside \lights
Turn Off Outside \lights - 0d28b801-926d-4a8a-b918-96565839dae1
OnEnter
on 0-20012 urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":"0"}]
OnExit
on 0-20012 urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":0}]
Transitions
'label' - 68a05642-555a-4c28-b23a-b3f24e74850e
When
device:'DayNight' (0-9) when urn:rts-services-com:serviceId:DayTime-Status (((luup.variable_get("urn:rts-services-com:serviceId:DayTime", "Status", 9)) == '0'))
Moves To
State: Turn On Outside Lights


Just to add.. if I reset the state now.. it will work this evening but only to turn it on.. then it might not turn off with or without the alarm
Title: Re: ALTUI: Workflows
Post by: amg0 on April 26, 2016, 06:38:56 am
I am sorry but I am back again.. I am really not getting how workflows work or flow
Could someone tell me whats wrong with this flow.
My goal is as follows:
Its night  then turn on outside lights
The alarm is now set to Stay/Home so turn off the lights
or its the alarm was never set but day has arrived so turn off the light
Code: [Select]
Start - ffc226b5-b8e3-4635-a368-5f97236d73f0
Transitions
'itsNight' - 5f0dd9f8-9ec2-4d47-86ea-190b597a037c
When
device:'DayNight' (0-9) when urn:rts-services-com:serviceId:DayTime-Status (((luup.variable_get("urn:rts-services-com:serviceId:DayTime", "Status", 9)) == '0'))
device:'House Alarm' (0-10053) when urn:micasaverde-com:serviceId:AlarmPartition2-Alarm (((luup.variable_get("urn:micasaverde-com:serviceId:AlarmPartition2", "DetailedArmMode", 10053)) ~= 'Stay'))
Moves To
State: Turn On Outside Lights
Turn On Outside Lights - 002f5d89-81aa-469a-938d-3151e35c9570
OnEnter
on 0-20012 urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":"1"}]
Transitions
'itsDay' - 0a71737d-10a9-4bdf-8386-5405cf491f7f
When
device:'DayNight' (0-9) when urn:rts-services-com:serviceId:DayTime-Status (((luup.variable_get("urn:rts-services-com:serviceId:DayTime", "Status", 9)) == '1'))
Moves To
State: Turn Off Outside \lights
Turn Off Outside \lights - 0d28b801-926d-4a8a-b918-96565839dae1
OnEnter
on 0-20012 urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":"0"}]
OnExit
on 0-20012 urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":0}]
Transitions
'label' - 68a05642-555a-4c28-b23a-b3f24e74850e
When
device:'DayNight' (0-9) when urn:rts-services-com:serviceId:DayTime-Status (((luup.variable_get("urn:rts-services-com:serviceId:DayTime", "Status", 9)) == '0'))
Moves To
State: Turn On Outside Lights

Just to add.. if I reset the state now.. it will work this evening but only to turn it on.. then it might not turn off with or without the alarm

Couple of things :

- better to make start state to first state transition very simple. and not be part of the workflow logic

- avoid  using luup.variable_get("urn:rts-services-com:serviceId:DayTime", "Status", 9) when you can just use new/  so you first transistion could be:
Code: [Select]
device:'DayNight' (0-9) when urn:rts-services-com:serviceId:DayTime-Status  (new == '0') )
- you have 2 conditions in your itsNight transition so it is a AND. it will only move if it is night and if house alarm is different from "Stay".  so if alarm is not different from Stay you never leave the Start state


I would code this differently

STATES
- a Start state
- a Day state with onEnter action to switch off the exterior light
- a Night state with onEnter action to switch on the exterior light
- a "AtHome" state with onEnter action to switch off the exterior light

Transitions
Start => Day transition if DayTime is day
Start => Night transition if DayTime is night

Day => Night transition if DayTime is night and alarm mode is different from "Stay"
Day => AtHome transiton if DayTime is night and alarm mode is "Stay"

Night => Day transition if DayTime is day
Night => At Home transition if alarm mode is "Stay"

At Home => day transition if DayTime is day
At Home => Night transition if DayTime is night and alarm mode is different from "Stay"

Title: Re: ALTUI: Workflows
Post by: konradwalsh on April 26, 2016, 08:06:03 am
Here goes...

thanks!
Title: Re: ALTUI: Workflows
Post by: amg0 on May 01, 2016, 02:28:47 pm
Here is another example of a more sophisticated workflow

Objective : Manage the dimmer in a theater Room with a Nodon Octan remote

-   Pressing ?+? sign should start ramping up the dimmer level , up to a maximum of 60% by steps of 5% every 5 seconds
-   Pressing ?-? sign should start ramping down the dimmer level  down to 0% by steps of 5% every 5 seconds
-   While ramping up or down, we want the ability to take over the control and stop the ramp up/down. So for instance while ramping up, a press on either + or ? will simply block the ramp up/down and leave the dimmer level to where it is.
-   If the ?+? or ?-? is pressed then, the respective ramp up or down continues

Tutorial and detailled explanation in the PDF file


Title: Re: ALTUI: Workflows
Post by: amg0 on May 03, 2016, 05:54:34 am
UI enhancements

- more ports in state
- rotation
- multiple select with CTRL click
- unselect by clicking on blank area
Title: Re: ALTUI: Workflows
Post by: vitmar on May 03, 2016, 03:22:59 pm
Are there any difference to the IN1 IN2 IN3? Or can I connect any trigger to any IN/OUT port?
Title: Re: ALTUI: Workflows
Post by: amg0 on May 03, 2016, 03:39:25 pm
Are there any difference to the IN1 IN2 IN3? Or can I connect any trigger to any IN/OUT port?
any. just there for convenience
Title: Re: ALTUI: Workflows
Post by: amg0 on May 11, 2016, 04:50:47 pm
V 1.49.1647 introduces a useful workflow editor enhancement. when you type the name for a state or a transition, it will propose the names of the other states or transitions of that workflow and you can select it to make a clone of it. convenient when you have to create a workflow with several time the same transition for instance?
Title: Re: ALTUI: Workflows
Post by: Silverow on May 15, 2016, 03:28:56 pm
Hello.

Sorry for my English...

I want replace PLEG logic "(!motion; NOW > 2:00)". What I may write in transition "no motion above 2 minute"?
Title: Re: ALTUI: Workflows
Post by: konradwalsh on May 15, 2016, 05:45:51 pm
Hello.

Sorry for my English...

I want replace PLEG logic "(!motion; NOW > 2:00)". What I may write in transition "no motion above 2 minute"?

AMG0 might correct me here... but i think you need a state with 2 transitions
one that is a 2 min timer
and one that can escape before the two minutes ass
Title: Re: ALTUI: Workflows
Post by: amg0 on May 15, 2016, 06:18:05 pm
Hello.

Sorry for my English...

I want replace PLEG logic "(!motion; NOW > 2:00)". What I may write in transition "no motion above 2 minute"?

AMG0 might correct me here... but i think you need a state with 2 transitions
one that is a 2 min timer
and one that can escape before the two minutes ass
Correct. This  is basically a logical state in your overall logic,   where no motion happens within 2 min, so Konrad is perfectly right.
Title: Re: ALTUI: Workflows
Post by: Silverow on May 16, 2016, 12:40:06 am
I don't understand. Give me example plz.
Then "light is on & no motion above 2 minutes" -> light off
Title: Re: ALTUI: Workflows
Post by: amg0 on May 16, 2016, 05:27:13 am
The example smart motion light given earlier here http://forum.micasaverde.com/index.php/topic,36868.msg277263.html#msg277263 is slightly more sophisticated than what you want but it should give you idea.
It switches on a light when there is motion and switch it off only if there is no more motion detected and after an extra timer of 3 min after motion ceases.
It also shows how, if the light was turned on manually by a human, the the whole motion detection logic does not apply ( totally different states in the workflow )
Tell if that helped
Thx
Title: Re: ALTUI: Workflows
Post by: mssearch on May 16, 2016, 11:45:01 pm
Wow, this is very cool. Although I don't have any experience with state machines I was able to successfully navigate the Smart Light tutorial and it's working great!

I would like to make some improvements to this by adding some additional triggers from door/window sensors in order to make it flow smoother. As of current at takes a while for the motion detector to detect my presence and turn on the light so it would be great to use the door as a trigger as well so that the light would turn on almost instantly when the sensor is tripped.

The challenge is... We want both motion and the door sensor to act as a trigger but don't want to require both to trigger. We also would want to make some assumptions that if there is existing motion prior to the door sensor triggering that it doesn't turn on the light again when we leave the room by opening the door.

So... my question, I mainly want to be sure that I'm barking up the right tree so to speak when attempting to accomplish this objective with a Workflow or if I need to be looking into other options (i.e. PLEG, Vera Scenes, etc). Secondly, assuming that this is possible to setup with a Workflow (and prudent to do so) do you have any tips or suggestions in terms of the states needed and overall flow?

Think I'm getting the picture of how the state machines work but my brain just hasn't entirely wrapped around the best way to accomplish things with this method.

Really appreciate any insight! :)
Title: Re: ALTUI: Workflows
Post by: amg0 on May 17, 2016, 02:07:10 am
Wow, this is very cool. Although I don't have any experience with state machines I was able to successfully navigate the Smart Light tutorial and it's working great!

I would like to make some improvements to this by adding some additional triggers from door/window sensors in order to make it flow smoother. As of current at takes a while for the motion detector to detect my presence and turn on the light so it would be great to use the door as a trigger as well so that the light would turn on almost instantly when the sensor is tripped.

The challenge is... We want both motion and the door sensor to act as a trigger but don't want to require both to trigger. We also would want to make some assumptions that if there is existing motion prior to the door sensor triggering that it doesn't turn on the light again when we leave the room by opening the door.

So... my question, I mainly want to be sure that I'm barking up the right tree so to speak when attempting to accomplish this objective with a Workflow or if I need to be looking into other options (i.e. PLEG, Vera Scenes, etc). Secondly, assuming that this is possible to setup with a Workflow (and prudent to do so) do you have any tips or suggestions in terms of the states needed and overall flow?

Think I'm getting the picture of how the state machines work but my brain just hasn't entirely wrapped around the best way to accomplish things with this method.

Really appreciate any insight! :)

Each transition ( arrows ) between states is a trigger; if you need an "OR" to have motion detector  or Door lock you can have 2 arrows between the Lamp Off and Lamp Auto On state. as soon as one is matches, it will fire and transition the workflow to the next state

On the opposite, a transition can contain multiple conditions and this time it is an "AND". so the "No Motion" transition between Lamp Auto On state and No Motion state could be enhanced to include both conditions ( motion sensor is untripped , AND door lock is untripped ) and that will essentially make the workflow go to the "No Motion" state, only when both conditions are trues ( meaning both sensor indicates no activity )

Workflow should make what you want possible, i think, at least, once understood they are easier than scenes to do complex things, plus , you get the bonus to see it evolve in real time so you can understand what is going on


Title: Re: ALTUI: Workflows
Post by: Silverow on May 17, 2016, 02:33:08 am
The example smart motion light given earlier here http://forum.micasaverde.com/index.php/topic,36868.msg277263.html#msg277263 is slightly more sophisticated than what you want but it should give you idea.
It switches on a light when there is motion and switch it off only if there is no more motion detected and after an extra timer of 3 min after motion ceases.
It also shows how, if the light was turned on manually by a human, the the whole motion detection logic does not apply ( totally different states in the workflow )
Tell if that helped
Thx

Yes, it helped!!!
Add all yours examples to first post plz.

Title: Re: ALTUI: Workflows
Post by: konradwalsh on May 17, 2016, 04:03:22 am

Add all yours examples to first post plz.

@amg0
Yes I would appreciate an Examples thread locked by you and filled with your examples...Each time you reply to someone with a detail reply, you just I have added an example to the examples thread
Title: Re: ALTUI: Workflows
Post by: mssearch on May 17, 2016, 01:15:24 pm
Each transition ( arrows ) between states is a trigger; if you need an "OR" to have motion detector  or Door lock you can have 2 arrows between the Lamp Off and Lamp Auto On state. as soon as one is matches, it will fire and transition the workflow to the next state

On the opposite, a transition can contain multiple conditions and this time it is an "AND". so the "No Motion" transition between Lamp Auto On state and No Motion state could be enhanced to include both conditions ( motion sensor is untripped , AND door lock is untripped ) and that will essentially make the workflow go to the "No Motion" state, only when both conditions are trues ( meaning both sensor indicates no activity )

Workflow should make what you want possible, i think, at least, once understood they are easier than scenes to do complex things, plus , you get the bonus to see it evolve in real time so you can understand what is going on

Thank you for the insight! This is really helpful as I wouldn't have initially thought of having multiple transitions to a single state as a method of OR so this will make it much easier for me to work out the logic! I would have started by making a state for every possible scenario and attempted to tie all of the pieces together which would have created a lot of clutter and redundancy.
Title: Re: ALTUI: Workflows Issues
Post by: amg0 on May 17, 2016, 01:41:43 pm
I have create a sticky locked topic with workflow examples
Title: Re: ALTUI: Workflows Issues
Post by: konradwalsh on May 18, 2016, 09:27:11 am
I have create a sticky locked topic with workflow examples

Excellent!
Title: Re: ALTUI: Workflows Issues
Post by: mssearch on May 30, 2016, 02:56:32 pm
I'm having some interesting issues with the motion light example that (I believe) is narrowed down to the Workflow or AltUI.

Have had the example up and running for a few weeks now and was super impressed by how great that it worked. After a couple weeks I finally commented to my wife how great that it was working and being completely reliable.... and that is when it happened...

At some point in the middle of the night I woke up to see the light rapidly dimming up and down, off and on. Manually pushing the off button on the dimmer would stop it for a moment but usually within a minute it would resume rapid level change.

The first time this happened I went over and reset my Vera Plus which resolved the issue for a few days until once again I walked in during the middle of the day and my light was  rapidly dimming up and down. This time I opened AltUI and took a look at the "History" tab of the Workflow and watched it rapidly showing the state changes (multiple changes per second). This time I decided that it must have something to do the Workflow so I turned the workflow off and the rapid dimming immediately stopped.

The Workflow has now been off for about a week and I have had no rapid dimming issues but I also really miss my motion sensor light. I know that this message doesn't offer much to help troubleshoot this further so I mainly want to know what I should post to help diagnose this? Should I simply paste the Workflow report or do I need to wait for it to happen again and copy the LUAUPnp.log data while it's happening? Or perhaps something else entirely?

Thanks for any assistance you can offer!
-Jared
Title: Re: ALTUI: Workflows Issues
Post by: amg0 on May 30, 2016, 04:44:54 pm
ok let's see

in case of issues like that you can:
a) pause the workflow ( red light in top left corner )
b) set the workflow mode to off ( in ALTUI device settings )
c) the real clean up thing is the RESET button on the ALTUI device settings. it resets all timers, workstates etc, All.

now regarding trying to find the root cause, I would need more info on
- first what ALTUI version appear in the footer ?
- the exact workflow report
- indeed, a copy of LUAUPnp.log while you had the issue.
- a copy of ALTUI device variables, especially Timers, WorkflowsVariableBag, WorkflowsActiveState
Title: Re: ALTUI: Workflows Issues
Post by: mssearch on June 01, 2016, 12:30:44 pm
Thanks amg0!

Just have to wait for it to happen again so that I can catch it in the act... Hopefully it happens soon because I'm going to be away from home for ~1mo and will just shut it off in that case. Will report back once I catch it happening!

Thanks!
Title: Re: ALTUI: Workflows Issues: path not found
Post by: pls90 on July 24, 2016, 12:17:26 pm
I just created my first workflow (just following the steps of the motion sensor triggered light) and get _lots_ of errors (about 2 per sec) that the path to LuaUPnP.log is not found.
Code: [Select]
cat: /var/log/cmh/LuaUPnP.log: file or path not foundI am running openluup/AltUI from cmh-ludl in my home folder.
Is there a way to configure that path to avoid the errors?
Title: Re: ALTUI: Workflows Issues
Post by: akbooer on July 24, 2016, 01:31:45 pm
You're running openLuup?  This is my problem, not amg0's!

You simply need to create the /var/log/cmh/ directory and ensure the permissions are are set to read/write.  Actually, openLuup should do this for you, so I guess there is a permissions problem creating that directory from your account..  Use sudo to do it, and there should be no further problem.
Title: Re: ALTUI: Workflows Issues
Post by: CudaNet on July 25, 2016, 05:54:24 pm
Odd, this should already exist as a symbolic within the turn-key. I just checked my Razberry (via Weaved) test server and everything looked fine. When I get a chance tonight, I'll load the Raspbian turn-key and check the symbolics and permissions. All further posts regarding this should be within the openLuup board.

Code: [Select]
lrwxrwxrwx 1 root root 17 Mar 12 14:48 /var/log/cmh -> /home/pi/vera/cmh


You're running openLuup?  This is my problem, not amg0's!

You simply need to create the /var/log/cmh/ directory and ensure the permissions are are set to read/write.  Actually, openLuup should do this for you, so I guess there is a permissions problem creating that directory from your account..  Use sudo to do it, and there should be no further problem.
Title: Re: ALTUI: Workflows Issues
Post by: pls90 on July 26, 2016, 02:31:46 pm
I created the directory as suggested and the errors are gone, logs are now created. @CudaNet thank you for double checking. Please mind that I am on Ubuntu, not Raspian.

Gesendet von meinem SGP612 mit Tapatalk

Title: Re: ALTUI: Workflows Issues
Post by: pls90 on August 10, 2016, 08:49:57 am
Thanks to CudaNets excellent turnkey image and guide I have moved from ubuntu on a NUC to jessie on a PI3.
I am starting to move bits and pieces from PLEG to workflows.
To keep it simple in the beginning I modified the motion triggered light example from the tutorial (see attached).
At times it works as expected, but mostly it doesn't.

I think I finally found the root cause of the problem.

I use to motion sensors to turn on a light on and turn it off again when no more motion is detected.
It starts to either "lamp_on" or "lamp_off" depending on the status of the light. When motion is detected it moves to "auto_on", after motion is over it moves to "no_motion",waits for the timer and then goes to "light_off". But instead of actually turning it off it moves to "light_on" again and stays there forever.
I believe the problem is that the transition "light_is_on" from state "lamp_off" fires before the light is actually turned off.
So it could be a timing thing that could be cured if a transition from state "lamp_off" can only occur if the status for that state is confirmed.

A quick and dirty solution would be to run some kind of timer before the "light_is_on" transition.
But I have no idea how to do that.
In the last couple of days I think I read about some AltUI functions that can compare times, but I seem to be unable to find the right thread I saw it in.

My second issue with the workflow is that it sometimes just doesn't start right away but has a huge time lag.
At times I can walk through the room before the light comes on. I can see the motion sensor signal motion right away, then it sometimes takes 3-5s before I see the light.
PLEG used to be lightning fast, turning on lights almost instantly after the motion triggered.
Is this a problem with my setup (PI3, but the NUC felt as laggy as the PI)?.
Any thoughts on this?
Title: Re: ALTUI: Workflows Issues
Post by: amg0 on August 10, 2016, 05:28:43 pm
Thanks to CudaNets excellent turnkey image and guide I have moved from ubuntu on a NUC to jessie on a PI3.
I am starting to move bits and pieces from PLEG to workflows.
To keep it simple in the beginning I modified the motion triggered light example from the tutorial (see attached).
At times it works as expected, but mostly it doesn't.

I think I finally found the root cause of the problem.

I use to motion sensors to turn on a light on and turn it off again when no more motion is detected.
It starts to either "lamp_on" or "lamp_off" depending on the status of the light. When motion is detected it moves to "auto_on", after motion is over it moves to "no_motion",waits for the timer and then goes to "light_off". But instead of actually turning it off it moves to "light_on" again and stays there forever.
I believe the problem is that the transition "light_is_on" from state "lamp_off" fires before the light is actually turned off.
So it could be a timing thing that could be cured if a transition from state "lamp_off" can only occur if the status for that state is confirmed.

A quick and dirty solution would be to run some kind of timer before the "light_is_on" transition.
But I have no idea how to do that.
In the last couple of days I think I read about some AltUI functions that can compare times, but I seem to be unable to find the right thread I saw it in.

My second issue with the workflow is that it sometimes just doesn't start right away but has a huge time lag.
At times I can walk through the room before the light comes on. I can see the motion sensor signal motion right away, then it sometimes takes 3-5s before I see the light.
PLEG used to be lightning fast, turning on lights almost instantly after the motion triggered.
Is this a problem with my setup (PI3, but the NUC felt as laggy as the PI)?.
Any thoughts on this?
Need more detail on your workflow, exact configurations and actions... It is true that transitions are evaluated in sequence but it may be a case of putting actions in onexit of the states.
Title: Re: ALTUI: Workflows Issues
Post by: pls90 on August 11, 2016, 01:11:13 am
@amg0 did you see the attachment to my post. It has the complete configuration in it. Or do you need a snipet from a log? Thank you for looking into this.
Title: Re: ALTUI: Workflows Issues
Post by: amg0 on August 11, 2016, 01:33:23 am
@amg0 did you see the attachment to my post. It has the complete configuration in it. Or do you need a snipet from a log? Thank you for looking into this.
Oups no
I see it now I ll check
Title: Re: ALTUI: Workflows Issues
Post by: powisquare on August 30, 2016, 05:54:00 am
Is there a way to describe a timespan in transitions? ie if time is between 6am and 11pm, allow this transition.
Title: Re: ALTUI: Workflows Issues
Post by: powisquare on September 02, 2016, 04:41:15 am
 ... ALTUI.time_is_between("07:00","22:00")
Title: Re: ALTUI: Workflows Issues
Post by: amg0 on September 02, 2016, 05:05:37 am
... ALTUI.time_is_between("07:00","22:00")
indeed ! thx
Title: Re: ALTUI: Workflows Issues
Post by: powisquare on September 03, 2016, 03:02:45 pm
... and what is the best way to allow a transition at a specific time with new=='1' also as a condition? Not sure it will accept a condition and schedule? Am I barking up the wrong tree with (new == '1' and (19*3600+30*60+00) == now)
Title: Re: ALTUI: Workflows Issues
Post by: amg0 on September 03, 2016, 05:03:07 pm
... and what is the best way to allow a transition at a specific time with new=='1' also as a condition? Not sure it will accept a condition and schedule? Am I barking up the wrong tree with (new == '1' and (19*3600+30*60+00) == now)
Conditions of transitions are any valid Lua expressions as long as it returns true when valid so your example should work
Title: solved - drop down has no entries
Post by: pls90 on September 04, 2016, 09:50:20 am
I am trying to edit a workflow. In a state I want to set  the value of a multiswitch on vera to 0.
After I select the multiswitch, the drop down for the action is empty.
Another ms on vera does not show that problem.
Both Multiswitches work as expected.
I'm stuck. Tried renaming, saving, reloading luup engine, reloading vera.
The device with the problem is #10330.
From the log it seems it is created without a .json file
Code: [Select]
2016-09-04 15:54:49.697   luup.create_device:: [10328] D_DimmableLight1.xml / X / D_DimmableLight1.json
2016-09-04 15:54:49.698   luup.create_device:: [10330] D_MSwitch330.xml / X /
2016-09-04 15:54:49.901   luup.create_device:: [10218] D_MSwitch218.xml / X / D_MSwitch218.json

edit:
I found the problem. The multiswitch in question was created on vera after AltUI was installed, so the D_MSwitch330.json and  D_MSwitch330.xml files were not copied to the openluup install. After I did that manually everything worked as expected.
I will have to keep in mind that additional multiswitches on vera require a manual copy.
Title: Re: solved - drop down has no entries
Post by: amg0 on September 05, 2016, 03:58:14 pm
I am trying to edit a workflow. In a state I want to set  the value of a multiswitch on vera to 0.
After I select the multiswitch, the drop down for the action is empty.
Another ms on vera does not show that problem.
Both Multiswitches work as expected.
I'm stuck. Tried renaming, saving, reloading luup engine, reloading vera.
The device with the problem is #10330.
From the log it seems it is created without a .json file
Code: [Select]
2016-09-04 15:54:49.697   luup.create_device:: [10328] D_DimmableLight1.xml / X / D_DimmableLight1.json
2016-09-04 15:54:49.698   luup.create_device:: [10330] D_MSwitch330.xml / X /
2016-09-04 15:54:49.901   luup.create_device:: [10218] D_MSwitch218.xml / X / D_MSwitch218.json

edit:
I found the problem. The multiswitch in question was created on vera after AltUI was installed, so the D_MSwitch330.json and  D_MSwitch330.xml files were not copied to the openluup install. After I did that manually everything worked as expected.
I will have to keep in mind that additional multiswitches on vera require a manual copy.

thanks :-)
Title: Re: ALTUI: Workflows Issues
Post by: powisquare on September 07, 2016, 07:07:45 pm
Just got these errors .. device 61 is Altui. Not sure what they mean? I have two schedules on two seperate transitions called the same thing (12:05am) in workflow 0-3. Could it be this? Thx

?      9/7/2016, 11:53:30 PM   warning device:61 has duplicate state id 12 for variables: Wflow_0-3_5 , WorkflowsActiveState   
?      9/7/2016, 11:53:30 PM   warning device:61 has duplicate state id 7 for variables: Wflow_0-3_4 , ExtraController
Title: Re: ALTUI: Workflows Issues
Post by: amg0 on September 08, 2016, 01:18:21 am
No , you ll find the answer in this forum
Run misc debug fix devices state and type 0-61
It ll fix it. It happens sometimes not sure yet why
Title: Re: ALTUI: Workflows Issues
Post by: powisquare on September 09, 2016, 07:07:46 am
Not sure if I have a similar question to pls90. My workflow stops at Day Set 16c and does not return to Idle at 10.30pm. If I reset after 10.30pm it flows correctly to Night Set 14c. The 10.30pm transition is a day of week schedule set everyday. I have copied a log if that's any use?
Title: Re: ALTUI: Workflows Issues
Post by: amg0 on September 10, 2016, 01:20:15 pm
Not sure if I have a similar question to pls90. My workflow stops at Day Set 16c and does not return to Idle at 10.30pm. If I reset after 10.30pm it flows correctly to Night Set 14c. The 10.30pm transition is a day of week schedule set everyday. I have copied a log if that's any use?
last line before the crash seems to be
Code: [Select]
50 09/08/16 22:30:00.105 luup_log:61: ALTUI: Wkflow - Workflow:'0-1' triggerTransition(cab86b58-89c6-443f-808b-ee01519a5baa) <0x2b9bc680>
so some suggestions:
- open workflow 0-1 and check if there is a transition with ID cab86b58-89c6-443f-808b-ee01519a5baa
- this seems to be a scheduled transition, can you confirm ? can you check what is scene 27 and what it contains
- you can try to
a)delete this transtion
b) verify there is no more scene for workflow 0-1 in your scene list
c)recreate it

Title: Re: ALTUI: Workflows Issues
Post by: powisquare on September 11, 2016, 08:54:14 am
Scene 27 related to the troublesome transition. As suggested, I deleted said transition which removed the scene and created a new one. Seems to work now - thank you! For anyone else feeling their way through Vera this is what a crash looks like in the log ... one looks to the line above this to find out what it was trying to do before the event.

2016-09-08 22:30:00 - LuaUPnP Terminated with Exit Code: 245

2016-09-08 22:30:00 - LuaUPnP crash

01 2016-9-8 22:30:0 caught signal 11 <0x2b9bc680>
---------------exited-------------
  PID USER       VSZ STAT COMMAND
    1 root      1684 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    5 root         0 SW   [kworker/u:0]