I’m pretty sure that’s it, but I’ll be shaking it down in my test environment as well. DEMII has been through a lot recently, so not surprised to find something “subtle” like this.
Version 2.9 has been released for all platforms/stores. For this version, I’ve imported the instant house mode response code from Reactor to improve performance with respect to house mode changes. For clarity, it is not necessary to use/install Reactor to enable this capability–it’s been copied in to DEMII’s code and preserves DEMII’s standalone nature. This version also fixes a bug in device state tracking that would sometimes cause 2.8 to leave lights on when DEMII was disabled while it was actively cycling.
@rigpapa: A feature request, can we have luup code execution fields for both before and after each light action?
The application is this: I have security cameras which have motion detection. Every time DEM turns a light on or off, it trips the camera which then sends me a snapshot. This could be avoided by running a code which disables the sensors before the light action and reenables it after the light action.
I’m not ignoring this request. I’m pondering the best way to get something like this done. What I don’t want to do is add two text fields where Lua gets pasted in, for a number of reasons. I’m trying to do something more elegant, but the plugin environment/jail is fighting me and I may not have a choice. I’m still experimenting…
1 Like
I never thought you were ignoring… I am sure you are thinking it through. 
UI implementation beyond icons is really not my forte.
If only it was the UI that stands in the way–that would be easy. In this case, I’m fighting the way Vera jails the plugin environment, which is good and right of them to do, but really fights some clean, obvious ways of doing this.
I have an idea: Maybe just provide a field to input a scene number for before and after the light action so the lua code can be put in a scene?
Yeah, I’ve already prototyped that. We’d be relying on the fact that the scene doesn’t run as a job (if it does, there’s no guarantee your work would finish, or even start, before the light changes). That may hold water today for Vera, but I haven’t tested that on openLuup, and since Vera’s docs don’t specify, it could change at any time. But I suppose we could just press forward, and cross that bridge if it ever comes before us…
Edit: oh, and I can’t tell you what’s about to happen… with the Lua-based approach I’ve prototyped, I can tell you which light and whether it will be turned on or off.
1 Like
OK. If you go to the stable branch on Github, take a look at the README, specifically the “Action Hook” section. You’ll find the two methods I’ve had the most success with:
- Scene – as we just discussed (but note the comment/edit: using a scene DEMII can’t tell you which light and what is going to happen) – set the state variable
PreactionScene; - Lua – more complicated, but, I can pass you the target device and state so you know which motion sensor to mute.
Give it a try. Tell me what you think.
1 Like
Thank you, Just installed and took a look at it.
The way you implemented it was an on-off to differentiate scenes for on from off action for the lights?
Actually what I was thinking was to run the same scene regardless of whether the light is turning on or off but rather run a different scene before the light action and another one after the light action so rather than on-off it would be pre-post. This would then turn the camera sensors on and off. 
Or did I misunderstand the on-off nomenclature?
It’s a pre-action only. If a post-action is required, a delayed scene group can provide that.
1 Like
Seems to be working for the most part. The only inconsistency I am seeing is due the timing by which the pre code is executed as it may not complete before the lights start switching on and off.
This is exactly why I didn’t do a separate post event, where the effect could be really severe. But yeah… you can send the command, but may not know when it starts or completes. I think maybe careful use of the hated luup.sleep could help you, though.
Had an issue where DuexEx 2.9 wasn’t running in AWAY mode. Something may have been switched off, but I double checked it today and still not working.
Dues Ex Machina II - ON
(underneath it shows Inactive in Home Mode)
Configuration I haven’t changed anything.
Auto-Activiation From BLANK to 23:10
House Modes: Away
No Limit on Targets and Controlled Devices are set as they always have been.
Any thoughts?
Next time you catch it doing something other than what you think it should be doing, request http://your-vera-ip/port_3480/data_request?id=lr_DeusExMachinaII&action=status and PM that to me.
Think I’m missing something, when I enter that into the browser, I just get a blank page. I just set it to activate in NIGHT mode to test it, shows next cycle time 21:43 so I’ll see what happens then.
Did it go OK?
Yes, while in NigHt mode no issues. I’ll try it again but set to away mode tonight.
If not, I didn’t get any info when I cut paste that status line into my browser.
Having more trouble with the plugin. It hasn’t been working, although it says next cycle time XX:XX.
I’ve also noticed my FROM time can’t be deleted/zeroed out, everytime I try and go back and save, it pops up with the original time I had. I have no problems changing the TO (end) time.
What’s the best way to send log?
No log needed. There’s a hotfix version on Github that addresses the operating issue, but it doesn’t contain the UI time field fix (it’s in the dev branch but not ported back). Give me enough time to get some caffeine on board and I’ll get that synced up for you.