We have moved at community.getvera.com

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

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #45 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

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +209/-8
Re: ALTUI: Workflows
« Reply #46 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

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #47 on: April 04, 2016, 03:54:22 pm »
OK -- got it and thanks!

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +209/-8
Re: ALTUI: Workflows
« Reply #48 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

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #49 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

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +209/-8
Re: ALTUI: Workflows
« Reply #50 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
« Last Edit: April 05, 2016, 02:42:42 am by amg0 »

Offline tedp

  • Sr. Member
  • ****
  • Posts: 288
  • Karma: +6/-2
Re: ALTUI: Workflows
« Reply #51 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:
  • 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

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +209/-8
Re: ALTUI: Workflows
« Reply #52 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


Offline dklinkman

  • Full Member
  • ***
  • Posts: 129
  • Karma: +1/-0
Re: ALTUI: Workflows
« Reply #53 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
VeraPlus, UI7, ALTUI on Chrome, Lots of devices and plugins including MQTT and MySensors.  Also playing around with openLuup

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +209/-8
Re: ALTUI: Workflows
« Reply #54 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

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +209/-8
Re: ALTUI: Workflows
« Reply #55 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

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +209/-8
Re: ALTUI: Workflows
« Reply #56 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

Offline xeinth

  • Full Member
  • ***
  • Posts: 144
  • Karma: +1/-1
Re: ALTUI: Workflows
« Reply #57 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

Offline xeinth

  • Full Member
  • ***
  • Posts: 144
  • Karma: +1/-1
Re: ALTUI: Workflows
« Reply #58 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

Offline amg0

  • Moderator
  • Master Member
  • *****
  • Posts: 3174
  • Karma: +209/-8
Re: ALTUI: Workflows
« Reply #59 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
« Last Edit: April 08, 2016, 11:24:13 am by amg0 »