Strange things happening with v1.63.1838

Don’t know if it is related to the new version, but strange things are happening making scenes and workflows not working properly.

Anyone else have had any problems after upgrading to v1.63.1838?

Any specifics ? I am using it and did not see any problem. An impact on wkflow is possible as some changes were in that arena but not possible on scenes

My Vera became very slow. One of my motion sensors had hung at “tripped” today so the system never run my “auto away”.
When I got home some motion activated lights run when there was no motion, one RGB LED got the wrong color.
My blinds did not roll down when I turned on the TV and my egg boiler never alerted me when it was finished.

I had a problem opening the plugin web, but after I disabled workflows and restarted my Vera I could open it again.

EDIT: I had to disable workflows again later. Non of my motion activated light-workflows where working as expected. Lamps did not turn on when motion was detected. Then suddenly, the lamps started to turn on and off rapidly several times. It feels like all of the commands where stacked. I also lost contact with AltUI and could not reconnect until workflows was disabled and Vera restarted.

Is there some information I can get from my Vera to locate the problem?

I could try to go back to previous version if I knew how.

[quote=“vitmar, post:3, topic:193815”]My Vera became very slow. One of my motion sensors had hung at “tripped” today so the system never run my “auto away”.
When I got home some motion activated lights run when there was no motion, one RGB LED got the wrong color.
My blinds did not roll down when I turned on the TV and my egg boiler never alerted me when it was finished.

I had a problem opening the plugin web, but after I disabled workflows and restarted my Vera I could open it again.

EDIT: I had to disable workflows again later. Non of my motion activated light-workflows where working as expected. Lamps did not turn on when motion was detected. Then suddenly, the lamps started to turn on and off rapidly several times. It feels like all of the commands where stacked. I also lost contact with AltUI and could not reconnect until workflows was disabled and Vera restarted.

Is there some information I can get from my Vera to locate the problem?

I could try to go back to previous version if I knew how.[/quote]
It is possible that workflows are not well designed and constantly fire transitions. You need to review the workflows, the start conotions and eventually the logs in debug mode to see what happens and if something keeps the Vera busy forever. You can also pause all workflows and enables them one by one until you find the culprit.

They worked fine before the update.

How can I go back to V 1827 to see if it get better?

EDIT:

I may have reach the roof for how many variables Vera can handle… again…
Same symptoms as last time. I cannot save any changes in workflows and/or delete any workflow.

I guess I have to make a backup of all of them and then do a reset somehow. :frowning:

I disabled all my workflows and re-enabled the workflow engine. Then I activated only one of them (this one is the first I made, and it have worked just fine before, no updates to the states or transitions for a very long time). This is what I got in the history log:

It seems to me that workflows are unable to read the device status anymore with the new update.

EDIT:

Or maybe the workflow engine became to fast. The state “Fans on” should turn on the fan, but if for some reason the fans turn off (probably by me manually) there is a transition that goes back to the “fans off” state. Workflows should perform all the state actions before the transition conditions are evaluated.

[quote=“vitmar, post:6, topic:193815”]I disabled all my workflows and re-enabled the workflow engine. Then I activated only one of them (this one is the first I made, and it have worked just fine before, no updates to the states or transitions for a very long time). This is what I got in the history log:

It seems to me that workflows are unable to read the device status anymore with the new update.

EDIT:

Or maybe the workflow engine became to fast. The state “Fans on” should turn on the fan, but if for some reason the fans turn off (probably by me manually) there is a transition that goes back to the “fans off” state. Workflows should perform all the state actions before the transition conditions are evaluated.[/quote]
this is what they do, but there is definnitely a race condition happening here which I am eager to understand. can you share the complete workflow report ?

i did the update too and haven’t noticed anything strange. Everything seems to be working as expected. I did have situations with race conditions a couple of times but have not been able to reproduce them. Usually a reboot resolves the issues.

this is what they do, but there is definnitely a race condition happening here which I am eager to understand. can you share the complete workflow report ?
[/quote]

Here it is!

If the workflow transitions are suppose to be run before the state have run its actions, then I would have to add a secondary state to many of my states. Like “Turn fan on > fan has turned on > waiting state” > fan turned off

Kaninventilation - (0-2)
4 States: Start, Fans on, Fans off, Fans on (scheduled)
10 Transitions: Fans are off, Fans are on, Clone of Fans turn off, Fans turn on, CO2 > 800 & Temp >2, Temp >=25, After 6h, CO2 <=550 & Temp <=22, After 1h, Fans turn off
Details
Start - a08844a9-ac51-4e3c-adbb-615a1258d9c5
Transitions
'Fans are off' - da56daae-34a0-4c8d-8960-97f7631ad6cb
When
device:'WP Kanin #68' (0-68) when urn:upnp-org:serviceId:SwitchPower1-Status (((luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 68)) == '0'))
Moves To
State: Fans off
'Fans are on' - 30cccd1a-4111-494e-bdb7-775ebeda98e7
When
device:'WP Kanin #68' (0-68) when urn:upnp-org:serviceId:SwitchPower1-Status (((luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 68)) == '1'))
Moves To
State: Fans on
Fans on - a53d1572-d645-47f7-aa5e-196689932fbf
OnEnter
on WP Kanin #68 (0-68) urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":"1"}]
Transitions
'CO2 <=550 & Temp <=22' - 8c0cb9dd-468a-4b5a-b753-d7eb690e8930
When
device:'Kaninerna - CO2' (0-50) when urn:micasaverde-com:serviceId:GenericSensor1-CO2 (((tonumber((luup.variable_get("urn:micasaverde-com:serviceId:GenericSensor1", "CO2", 50)))) <= 550))
device:'Kaninerna - Temperat' (0-49) when urn:micasaverde-com:serviceId:GenericSensor1-Temperature (((tonumber((luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 49)))) <= 22))
Moves To
State: Fans off
'Fans turn off' - 83357cc8-fa1d-4089-a34f-74e620256a42
When
device:'WP Kanin #68' (0-68) when urn:upnp-org:serviceId:SwitchPower1-Status (new == '0')
Moves To
State: Fans off
Fans off - 095b4f2b-fc57-427c-af27-ba24f7adb463
OnEnter
on WP Kanin #68 (0-68) urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":"0"}]
Transitions
'Fans turn on' - c3960cfe-b3b5-4911-b013-a22c3a0bd31e
When
device:'WP Kanin #68' (0-68) when urn:upnp-org:serviceId:SwitchPower1-Status (new == '1')
Moves To
State: Fans on (scheduled)
'CO2 > 800 & Temp >2' - cb32e33c-c99a-432f-8313-858b9f798617
When
device:'Kaninerna - CO2' (0-50) when urn:micasaverde-com:serviceId:GenericSensor1-CO2 (((tonumber((luup.variable_get("urn:micasaverde-com:serviceId:GenericSensor1", "CO2", 50)))) >= 800))
device:'Kaninerna - Temperat' (0-49) when urn:micasaverde-com:serviceId:GenericSensor1-Temperature (((tonumber((luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 49)))) > 2))
Moves To
State: Fans on
'Temp >=25' - 57627e99-5b55-45cb-a463-b21f58fd523d
When
device:'Kaninerna - Temperat' (0-49) when urn:micasaverde-com:serviceId:GenericSensor1-Temperature (((tonumber((luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 49)))) >= 25))
Moves To
State: Fans on
'After 6h' - 4aa90cd8-2ce6-4e42-8fc5-1e5b772488e4
When
Timer: 'Every 6h' expiration 21600s
Moves To
State: Fans on (scheduled)
Fans on (scheduled) - 7dcdea4f-868d-4f60-a416-b7685b9c4edb
OnEnter
on WP Kanin #68 (0-68) urn:upnp-org:serviceId:SwitchPower1-SetTarget [{"name":"newTargetValue","value":"1"}]
Transitions
'Clone of Fans turn off' - a2205213-ed38-4f69-b7cd-365a767d4b76
When
device:'WP Kanin #68' (0-68) when urn:upnp-org:serviceId:SwitchPower1-Status (new == '0')
Moves To
State: Fans off
'After 1h' - ede54f72-4ca8-4651-80d8-8788fee26adf
When
Timer: '1h' expiration 3600s
Moves To
State: Fans off

ok, having looked at this , I believe it could be this.

When you switch a SwitchPower1 with SetTarget , it will set the Target variable to one but it will take an undefinite amount of time ( zwave asynchronicity ) before it reaches the real ON status with a Status variable set to one.
So if you immediately jump to another state which has an exit transition testing that Status variable == “0”, it could very well match immediately because Status is still “0” when you enter the state

One potential fix to try is to use the trigger feature ( “Only when triggered” checkbox ) on the transition condition. this way, your condition could then be that Status just reaches “0” again value and eliminate the situation where it was still “0” when you entered

Another way is indeed to have an intermediate state
S1 = “Turn On Fan” trigger the action to turn the switch it on
S2 = “Fan is really On” , only enter this state when the status is really 1
S3 = "Turn Off Fan"trigger the action to turn the switch off
S4 = “Fan is really Off” , only enter this state when the state is really 0

hope this helps

OK, Ill try only when triggered" first and see if it helps.

EDIT: It did help. Now things are working are before! :slight_smile:

Btw, it would be very nice if there was a way to make a “hard copy” of a transition so that if the master version change its content, the “hard copy” all change as well.

+1 for the “hard copy” feature.
And a search and replace feature to swap one device within a workflow for another one. I duplicated my “watch door and window” workflow 10 times and had to swap all the door sensors.

FYI

My problems are solved now but I want to share with you what I had to do.

First of all, I had to make sure that if a state have an action on a device that is also in a transition, I had to add another state so that the workflow would not loop.
For example, instead of this: [a lamp should turn on] > (Turn on lamp) > [lamp was turned off]
I had to do this: [a lamp should turn on] > (Turn on lamp) > [lamp was turned on] > (Lamp is on) > [lamp was turned off]

The other thing seems to be related to Vera. When I reach an unknown number of workflow variables, things go bad. Really bad!
The Vera stops being able to save workflow changes and the system become sluggish. It was not even possible to delete workflows to make it better.
I had to go into the advanced options for the Alternate UI device and look at the variables.
Then I had to start clearing the content for all workflows manually by: clicking on a variable, select all, delete, click outside to make it save. and repeat like 200 times
When this was done I reloaded the Vera luup and had to delete some variables that still had not been cleared, tried to open AltUI and got the “no handler” error .
After some time I figured out that I had to clear the AltUi Variable for active workflows, after that I could go back into the AltUI and create new workflows from my backed up list of exported workflows.

I don’t know if it is Alternate UI or Vera that is the problem, but it seems that even if a workflow or parts of a workflow is deleted, some variables are still stored as variables in Vera making it fill up until it cannot handle any more variable data.