openLuup email server

[Crille]

Yes, I got all that already just wondered if I missed something. Perhaps I’m going to take another big leap to MSR then. But I never even used Reactor and managed so far with Lua. I’m afraid I’ll be a PITA when new to both openLuup and MSR

Edit: I’ll be bothering you guys regarding MQTT soon as well

[therealdb]

If my memory is not failing, @rafale77 wrote some code to port ModeSetting variable under openLuup.

[rafale77]

I am not quite sure what particular use case @Crille has. I use house modes quite extensively in identical ways as with the vera. I just use scenes with the housemode variable as trigger and actuate housemodes also through scenes. It seems pretty straightforward... and much more flexible than on the vera... indeed you can a scene to trigger when house mode goes to 2 to selectively arm all your security sensors for example and to arm only door sensors when it goes to 3. You can even change the behavior depending on what the old housemode value was... This can be done in 4-5 lines of lua code as opposed to endless clicking (if like me you have a lot of devices)

[Crille]

Thank you all.
I'll manage my use case either with scenes or MSR, just think Veras approach gives a good overview of what happens when I change House mode.

[LibraSun]

@crille said in My newbie questions:

Thank you all.
I'll manage my use case either with scenes or MSR, just think Veras approach gives a good overview of what happens when I change House mode.

You're right in saying Vera got that particular facility right. Funny, I only discovered that "House Modes options" page very late in the game (i.e. around 2013?) and never bothered to use it beyond un-Arm'ing everything then forgetting about it. (I don't use any physical sensors, anyway.)

But I will say +1 to moving everything to MSR (or at least Reactor for the time being) and away from Scenes and naked Lua. Main reasons: Editability and Portability.

Of course, all your Lua code snippets can be run by Reactor, if that's your thing. I found that every Scene I ever created on Vera could be accomplished more succinctly by Reactor, with the added luxury of Expressions and its powerful runtime logic.

Literally the only Scene I have left on Vera is one which resets Reactor whenever it "trips" (throttles due to too much activity in a short time span). Period. Done. Buh-bye.

[therealdb]

so, I wrote it @Crille

It will scan all your devices, and generate the actions into 4 functions, to be called when changing house modes.

https://github.com/dbochicchio/vera/blob/master/Devices/Vera.HouseModes.lua

[Crille]

Wow, cool! I’ll test it soon. Thanks!

[therealdb]

@crille it's not 100% perfect, but it helped me to finally move away this logic from my Vera

[toggledbits]

Just want to add, this (ModeSetting) is one of the areas where Vera screwed up the implementation pretty badly. It turns out that on Vera, when it switches between armed and disarmed, it just sets the Armed state variable directly, rather than calling the SetArmed action on the device. This is disastrous for devices that need to do other work when arming (e.g. an alarm interface plugin that might send additional commands to a physical device); they have to jump through additional hoops to detect this rogue change of state done by their "back door" implementation.

So, in a sense, you're not only porting a function from Vera to openLuup, you're also fixing it. Good on ya.

[Crille]

@akbooer How come luup.log(”My text”) does not log anything when put in lua_startup but log “My text” when executed from lua_test?

[akbooer]

Lua Startup is run at initialisation time (surprise!) hence any log output appears in the Startup log, not the running system one. You can easily examine this from the console Logs > startup_log page.

One key advantage of this is that the startup log is always available to you, no matter how many times the main log has rotated.

[Crille]

Ah, brilliant! Thank you.