Delay home modes AltUI not working

Hi Akbooer,

When I set the home mode to Away in AltUI on openLuup, there is a counter visible. This suggests that there is a delay on executing the actual mode change. But this doesn’t seem to work. I have a workflow that, amongst others, turns the lights off when I set the house mode to Away. But the lights turn off immediately when I set the mode and not when the counter has finished counting.

Is this a known issue, a feature or a bug?

The workflow is triggered on the HouseMode variable of openLuup.

It’s just an unimplemented feature that I haven’t got around to doing, because nobody has asked. AFAIK, it should be 30 seconds to any mode other than home?

The side-effect will be to add a further delay to bridged Vera mode changes if they are slaved to openLuup (and vice versa.)

I’ll look at doing it now.

Edit: it was already marked as TODO in the code!

OK, latest development version has this implemented.

Also changed VeraBridge to effect an immediate change to whatever mode if the remote machine’s mode is being mirrored.

Thanks, akbooer. I will check it out very soon.

I’m getting an error when trying to update.

2018-03-03 09:33:08.822 luup_log:5: AltAppStore : starting phase…
2018-03-03 09:33:08.823 luup_log:5: AltAppStore : downloading akbooer/openLuup [development] to /tmp/AltAppStore/
2018-03-03 09:33:09.061 luup_log:5: AltAppStore : error downloading: unknown error

I can’t yet figure out if it’s at my end. Can you check at your end?

Have you followed this procedure?,38102.msg352456.html#msg352456

As mention in the openLuup version thread here:,34526.msg352750.html#msg352750

I missed that, sorry. It’s working now!

My bad… I’ve posted a more explicit warning to update AltAppStore and openLuup.

First impressions are good. Thanks for the additional functionality!


There seems to be a strange issue after the last development update. My workflow triggers on the house mode of openLuup when it shouldn’t. It worked before.

My WF triggers on a triple click. It then sets house mode to ‘Night’. But immediately after that it returns back to mode ‘Home’, through the “Manual home” condition. This shouldn’t happen. See attached screenshots.

I can’t find out why and by what the openLuup variable is set to ‘1’. When I set the house modes manually through the gui, it works fine. And when I delete the “Manual Home” condition it obviously works too.

Can you help me figure this out?

I think openLuup is setting the house mode variable to ‘1’ instead of ‘3’. See device history attached.

But when I switch with the buttons in the gui, the variable is set correctly.

See also attached the WF step that sets the house mode.

Interesting. I don’t use workflows, so am not au fait with debugging them. You seem to have AltUI in debug mode which makes the log busy.

The relevant entries I see are:

2018-03-05 09:56:17.477   luup_log:3: ALTUI: debug: Calling Action device:2 Service:openLuup Action:SetHouseMode Params:{"Mode":"3"}
2018-03-05 09:56:17.477   luup.call_action:3: 2.openLuup.SetHouseMode 
2018-03-05 09:56:17.478   luup.call_action:2: 0.urn:micasaverde-com:serviceId:HomeAutomationGateway1.SetHouseMode 
2018-03-05 09:56:17.481   luup_log:3: ALTUI: debug: Calling Action device:2 Service:openLuup Action:SetHouseMode Params:{"Mode":"1"}
2018-03-05 09:56:17.481   luup.call_action:3: 2.openLuup.SetHouseMode 
2018-03-05 09:56:17.481   luup.call_action:2: 0.urn:micasaverde-com:serviceId:HomeAutomationGateway1.SetHouseMode 
2018-03-05 09:56:17.481   luup.variable_set:0: 2.openLuup.HouseMode was: 1 now: 1 #hooks:2

This describes a sequence of events where:

[ul][li]a workflow calls the openLuup SetHouseMode action with parameter ‘3’[/li]
[li]this gets translated into the actual HomeAutomationGateway action[/li]
[li]unmarked in the log, this nevertheless starts a 30-second timer (as you asked for previously!)[/li]
[li]3mS later, a workflow calls the openLuup SetHouseMode action with parameter ‘1’[/li]
[li]this gets translated into the actual HomeAutomationGateway action[/li]
[li]unmarked in the log, this effectively cancels the 30-second timer, and…[/li]
[li]… immediately set the Mode to ‘1’, as requested[/li][/ul]

This is exactly the behaviour that I would expect under these conditions.

Yes, I think you are right. Then it seems to be a AltUI issue, because the transition to ‘Manual Home’ should not be triggered. I don’t think there is a change of the variable to ‘1’, that happens later on when the the WF arrives at the ‘Home’ state.

Can you help me out with this?

There is one key issue here. The final log entry:

2018-03-05 09:56:17.481   luup.variable_set:0: 2.openLuup.HouseMode was: 1 now: 1 #hooks:2

Shows that the house mode is set to 1 when it already is 1. This leads to callbacks on that variable being invoked, another 3ms later:

2018-03-05 09:56:17.484   luup.watch_callback:: 2.openLuup.HouseMode function: 0x14066d0
2018-03-05 09:56:17.484   luup.variable_set:2: 2.urn:upnp-org:serviceId:altui1.DisplayLine2 was: [Home] now: [Home] #hooks:0
2018-03-05 09:56:17.484   luup.watch_callback:: 2.openLuup.HouseMode function: 0x13da330
2018-03-05 09:56:17.484   luup_log:3: ALTUI: debug: _internalVariableWatchCB(0-2,openLuup,HouseMode,old:'1',new:'1') - (Wkflow)

The first of these is benign - just openLuup updating its display of the house mode - but the second one is presumably what triggers your workflow.

The question is, should openLuup register this mode ‘change’ or not?

This seemed odd to me too. The watch should not trigger when the value doesn?t change, right? I haven never seen it before.

OK, I can make sure that it doesn’t do that.

OK. New development version 2018.03.05 has this change.

Does that fix your workflow problem?

Unfortunately it does not resolve my issue. I hope amg0 can shed some light on this, because it was working fine.

Problem solved by setting the trigger only flag on one of the transitions.

Thanks for reporting your workflow problem as solved. I take it that the delay house mode change implementation itself is quite satisfactory now.