Can’t you just create a one-way routine to create 4 scenes, starting from the variables, and migrate this to openluup when necessary? I mean, I still use this feature (because when I started it was convenient and, you know, it’s working OK for me, to turn off lights at night/away/vacation), but I think the pain is to migrate your actual configuration, and you will stop needing this when your migration is completed.
The only advantage of this feature is that you can change the settings with no luup reload, which is quite impossible with other approaches.
Yep, I know. I was just speaking of native Vera features. Openluup and Reactor will be OK, if you haven’t invested in a huge customization of devices linked to House Mode. I did, I regret, but I’m not changing it unless I’ll be forced to - I think that’s @rafale77 point, in fact.
…and checkout the revision date on the bottom of the Wiki page:
This page was last modified on 3 November 2014, at 07:19.
I have steadfastly been ignoring its contents since that time.
It’s for things like this that Reactor (and AltUI Workflows, and Rules Engine, and PLEG, and …) were invented. Heck, I didn’t even implement Vera scene triggers.
Just so you all know, @rigpapa is the guardian of my sanity, so you don’t mess with him…
So if I implemented importing of Vera house mode rules into Reactor activities, would you feel differently about needing to support them natively in openLuup?
Yes, I think it’d be enough. I mean, I just want to migrate them in case I’ll completely move to openluup. No pressure, since I’ll personally stay with my current configuration at least until they completely deprecate the current firmware generation. But I see openluup in my future, more and more.
as @therealdb is pointing out, it all depends on whether or not one has started using these features or not. Sure there are other ways to do it. Some seemingly better and for me it isn’t so much for personal needs as I have reverted back to a scene based solution and fairly simple lua code to replace/replicate the house mode switch feature. I must recognize also that for those who do not code, this was a pretty nifty feature and the UI for it made sense. We keep on complaining that vera should support a lot more of what reactor does, yet when something good actually came from that UI we go back and dismiss it saying that it is redundant with what we already are doing with plugins and lua code…
For openluup and verabridge, the vera could keep this feature so there was no need to move it to openluup. When I now look at the implementation for z-way, I think it would be a nice addition.
For example, for me to change the behavior of a device depending on the house mode, do I want to go to the house mode menu? change a variable in the device? Or go dig into my scene lua code? I would argue that the former is a lot more convenient. And this multiplies with the number of devices. I actually had scenes change these house mode device behaviors by altering the ModeSetting variable and found it quite convenient.
Now that I pretty much wrote the code to parse the variable and act on most of the devices in the wiki… I understand that the ROI problem is not so much on coding or time spent but likely more on wise use of CPU cycle. Added to this is the unnecessary idiotic nomenclature under the hood of using “N”, “F”, “A” etc… since it is under the hood why did they not use something more consistent across multiple device types? I see why you don’t like it. It doesn’t make the feature less useful but it could definitely be better implemented. I saw it more from the point of view of a user than one of a developer.
