House Mode sync problem

Several people in the past asked for this functionality to assist in an interim period where some logic/scenes/plugins were still on Vera and yet others entirely on openLuup. Key variables which are controlled by the current openLuup logic may be ‘mirrored’ back onto devices in Vera and used as scene triggers or polled values by the logic there.

I could dig up some more specific examples by users if needed.

Several people in the past asked for this functionality to assist in an interim period where some logic/scenes/plugins were still on Vera and yet others entirely on openLuup. Key variables which are controlled by the current openLuup logic may be ‘mirrored’ back onto devices in Vera and used as scene triggers or polled values by the logic there.

I could dig up some more specific examples by users if needed.[/quote]

Don?t bother, thanks. I think I get the picture. If I understand it correctly I probably won?t need it when all logic resides on Openluup.

UPDATE: Self-admitted N00B alert!

True or False
Switching over to AltUI would allow me to stop using the “House Modes” plug-in to programmatically change Vera’s House Mode?
(i.e. I’m asking whether AltUI has that read/set functionality built-in.)

I currently use Reactor to (very carefully!!) mirror the Home/Away/Sleep-Night/Vacation-Other status of both Vera and my ecobee thermostat – in both directions – which turned out to be a nightmare logistical problem to solve (but I won!). Always looking to simplify further…

Thanks! Seriously contemplating taking the AltUI plunge!

  • Libra

AltUI displays house mode on the home page with buttons that can be used to change it. Does that answer the question?

openLuup, itself, has an action which may be used in scenes to change the mode.

UPDATE: Self-admitted N00B alert!

Almost… see, the HouseModes Plug-in was created to add something Vera lacked out of the box, namely the ability to “use House Modes in scenes, either as a trigger or as an action.”

Without it, Vera cannot change House Modes unless the user directly taps one of the “Home”, “Away”, “Night” or “Vacation” buttons in the UI.

So I am curious whether AltUI contains a similar capability. (I’m always looking to drop a plug-in or merge its workflows with a newer, better one.)

Thanks!

AFAIK, it doesn’t. But since you are posting in the openLuup section, I assume you are not talking about running on Vera?

The openLuup plugin itself maintains a HouseMode variable which may be synced to a bridged Vera, and can be used to trigger scenes.

1 Like

You are posting in the openluup section, not the ALTUI one.

@akbooer answered for openluup.
ALTUI is not a replacement for the vera, it is an interface for it.

1 Like

You guys beat me by mere seconds. I was just on my way back in to type “Oops, sorry for posting this question in an ‘openLuup’ forum!” I just realized.

Thanks for the info, though!!

It’ll be useful for when you switch to openLuup in the future. :wink:

1 Like

That being said… I made the suggestion just yesterday for openluup to reproduce the UI7 behavior of setting and acting on the ModeSetting variable of the devices:

enabling arm/disarm and SetLoadlevel and SetTarget commands where relevant.

:slight_smile:

1 Like

You know it’s WAY more involved than that, right?

Check out the variables for thermostats for example in the wiki. Setpoints, modes, bizarre string syntax, kludge out the wazoo… shudder.

2 Likes

Depends on what you mean. I am already reproducing the behavior by running a scene at housemode changes. The scenes are relatively simple: Screen for through the luup.devices table and select specific device types and take actions based of their ModeSettings variables.
The setting of this housemode variable would need an openluup console page showing device list by device type and action/per mode. Otherwise the users would have to edit it manually for each device.

There’s a whole thing with thermostats and other devices too. Wiki documents it just enough to make you regret considering it, I think.

I don’t know. I am excluding the thermostat from consideration for doing this because… I already have my own thermostat plugin. I think for housemodes the 3 device types needed would be the binary lights, the security sensors and the LoadLevel/dimmers.

I just also looked at UI7. For thermostat, it only offers mode change which would be pretty straighforward.

1 Like

It should never have been done this way, IMO. If scenes had been implemented correctly, none of this would be necessary. I think this “feature” creates more problems and confusion for users than it solves. I think openLuup has done fine without it. Why change now? And if change, is a partial implementation the way to go?

Look at the wiki. There’s more, IIRC.

Yup… http://wiki.micasaverde.com/index.php/House_Modes

Also see CustomModeConfugration and CustomModeControls here (would likely impose additional requirements on ALTUI as well) http://wiki.micasaverde.com/index.php/Luup_UPnP_Variables_and_Actions

That’s a better question! It is a feature of convenience since it is visually easier to set and control than through luup code. It is particularly relevant for the z-way plugin actually as I am working towards removing the vera. I can do just fine without by using scenes but… eventually it is a lot of scenes to run.
Having them all in one place could help. I didn’t find it confusing.

I see, yes there is more to it. I am still not finding anything confusing about it… I have been using this syntax to set my vents opening % according to housemodes before I wrote my HVAC plugin which takes more into account than the housemode, maybe that’s why.

Check my edits to prev post

And yes its just code, but what’s the ROI?

To me the ROI could be pretty high, excluding the thermostat, it enables users to reproduce the housmode set behavior without having them write code themselves when using other platforms and plugins than the verabridge… like z-way or even ALTHUE or any other device and this without the need for another plugin.

And the code to be added is pretty simple save for the console part…

It’s up to @akbooer of course, anyway, but my feeling is that implementing just the specific things you need today leaves him (and @amg0) exposed to later being in the uncomfortable position of potentially having to do much more or all of it later. I don’t think they get the option of not doing a UI, even for the most basic part, and as you know, the UI usually requires a lot more work than the underlying feature. As I said, openLuup seems to have gotten along without that until now, and there are other ways of getting it done that are easier for users to wrangle with, and the UIs for them are already there. But it’s not up to me, of course, I’m just playing devil’s advocate.