toggledbits / deusexmachina Goto Github PK

Allow a light sensor to trigger DEMII to start cycling (or stop cycling).

Many users have asked if DEMII can be start or stopped with PLEG. There is a standing workaround to set the start and end times the same, which makes DEMII run continuously when enabled; then it's just a matter of having PLEG (or scene or Lua) enable or disable DEMII as needed.

But this has some side-effects, most notably that the slow shut-off of lights doesn't happen--disabling DEMII either shuts all the lights off immediately, or leaves them as-is (user selectable option).

Please add some form of an on/off to the app to allow for programmatic enabling/disabling the device.

I would like to be able to enable the vacation timer device using a scene triggered by a google calendar event device. If the calendar has the appropriate type of event, it will set my thermostat to appropriate settings and enable the vacation timer.

Otherwise, great app!

From MCV forum user Thorden: Could it be expanded to have more than one "working period"? For instance between "Start time" and sunrise? That can be quite a long time of darkness, especially for us living on the north side of the globe. Right now, sunrise is at 09:15 am, even later two weeks ago. So there are several hours of darkness in the morning where it would have been natural to have some lights on in the house.

Inconsistently, but usually, version 2.6 has started turning lights fully on instead of at the configured dimming level. Reported by Thorden on MCV forums.

I have LED lights that need a very specific minimum level - would it be possible to show the percentage selected next to the slider?

There doesn't seem to be a way to save the configuration of the plugin:

Firmware: 1.7.583

Icon hosting isn't great. We can do better.

From MCV forums user Thorden: Could the turning off of lights that DEMII has turned on be optional for selected lights? For instance: Lights in my hallway is turned on (based on ambient light level) when I unlock the front door and disarm the alarm system. But if the same light is turned on by DEMII, it will be turned off. Hard to control which of the events that control that specific light, my "Welcome home" scene, or DEMII. Right now, lights are turned off by DEMII when I get home, so it welcomes me with darkness...

I have the plugin enabled, and set to run only in vacation mode (no other modes are checked). It's turning my lights on even when I'm in home mode, though. Possibly relevant line from logs:

DeusExMachinaII:deusStep(): run in state 1, modebits=16, currentMode=1,

Don't know if it matters that I'm running the most current beta version, 1.7.891.

Is there anyway to set DeusExMachina to run one hour before sunset or any user defined amount of time before sunset?

Most people are using their light before sunset.

If not, seems like a missing capability.

Thanks

DEMII doesn't do anything with the house mode. The workaround (install another plugin and create a scene using that plugin's trigger) isn't really acceptable.

Reported by T.C. 2016-08-07

DEMII currently relies on the value of luup.sunset, which is tested when Deus is enabled. The definition of luup.sunset is the time of the next sunset, and therefore if the test occurs after today's sunset, it reports tomorrow's sunset time.

The result is that if DEMII is enabled after today's sunset (but before lights out time), DEMII will not operate today until the hour and minute of tomorrow's sunset. That is, if today's sunset is 7:24PM, and tomorrow's is 7:28PM, and DEMII is started at 7:25PM, it will not operate today until 7:28PM, even though it should start at 7:24PM.

Community user rafale77 has requested that it be possible to execute some Lua prior to DEMII changing the state of a target. The purpose is to mute camera motion sensing prior to the change so that the change does not cause snapshots/recording.

DeusExMachina II doesn't show in 1.7.3832 - but DuesExMachina does. Did the usual search by DeusExMachina II and zero returns. Dropped the "II" and, boom, there's the old one. Any thoughts?

Thanks for picking up this project and continuing with its development.

I still have a bunch of lights throughout my house that are still on x10. Whenever something dies, I switch it to z-wave, so now, I'm at about 60/40 x10 to z-wave.

For the x10 lights, I still control them in my Vera via "virtual switches" that make HTTP calls to turn on/off the lights. It would be great if these virtual switches showed up as options in the "lights to be controlled" configuration menu, so that I could add some of my legacy x10 lights / switches to the list of lights controlled by this plugin.

I installed v2.2 today but havent actually gotten it to work yet, it's not turning anything on/off and its now 1 hour after sunset. I did use the original DEM some time ago and it did work for me.

Still I would like to request the ability to control the dimmer level for devices that are dimmers. Just one variable to control the level of dimming for all the dimmer devices would do it for me (all dimmer devices would have the same dimmer level). I usually use 25% for all my vacation mode devices.

Thanks and keep up the good work!!

I leverage the Turn Controlled Lights Off feature, and it ultimately works. What would be awesome though is if it would turn the controlled lights off as soon as the house mode changes. Right now there is about a 5-10 minute delay from when I get home and enter the house to when the controlled lights turn off. It's a little wife upsetting when she has manually turned on a controlled light after getting home and then DeusExMachinaII turns it off on her within that 5-10 minutes.

User sebby in the Vera forums posted the following. Seems like a useful ideas, since it is doable with scenes, but is probably an "advanced skill" and a fragile config.

"Could I make a suggestion for the next cycle of this plugin? I love that i can select to kick this off with different house modes, but would love to be able to run a different scene depending on which house mode the plugin was in when it was turned off/completed. for example, i have this kick off when i am on vacation and away mode. on vacation mode, i want it to turn off all lights when the cycle is complete,but when i am in away mode, i want it to not shut off all lights when i get home. does that make sense?

I am doing this:

Set the active period to "Manual Activation" as described above, and use the Activate and Deactivate actions to start and stop cycling, respectively. When deactivating with this method, lights will be progressively turned off to simulate the bedtime "lights out" behavior DEMII uses with automatic scheduling. These actions are part of the urn:toggledbits.com:serviceId:DeusExMachinaII1 service, and take no parameters.

like this:

luup.call_action("urn:toggledbits-com:serviceId:DeusExMachinaII1", "Activate", {}, deviceNumber)

But how do I set the "Light out" time"

This seems to only set DEMII to be on / off but never get the lights out time.

openLuup appears to be more sensitive to passing of newTargetValue in SwitchPower/SetTarget as number; it wants string. Some devices will not respond when sent number.

We have a max number of lights on. Maybe we need a min, eh?

Reported by opel-oleg

Hi.

I've just added a Philips Hue bulb to my Vera network but it doesn't appear in the list of devices that the DeusExMachina plugin can control.

Is this something that can be added?

Thanks in advance
Matt

Thank you for providing this plugin! It's very handy and very easy to use.

In the spirit of saving energy, I think a neat option would be to allow the user to specify how many lights are allowed to be on at the same time. If the user specified '1' for example, then if a light was about to be turned on because its random toggle time came up, it simply wouldn't turn on if at least one other light was already active.

From MCV forums user Thorden: Would it be possible to add some time before sundown and after sunrise where DEMII is active? Again, in the far north the dusk time can be quite significant, since the sun rises and sets more slowly. So it would be normal to have lights on for some time before sundown and after sunrise (dusk). I made this work very well with Vacation Ghost in combination with Heliotrope plugin, based on sun height/Azimut data from it.

D_DeusExMachinaII1_UI7.json - line 119 - still shows 2.4 with old date.

This appears to be the text displayed in the Device panel, resulting in a perception that the plugin hasn't been updated.

(Also, the auto-update in Vera doesn't seem to be grabbing the new version yet...)

As a user, I'd like to be able to set different cycle times for each device / scene so that I can control for how long a room is lit.

Scenario: I have several rooms under DEM control when I'm away. Some of them are bathrooms (usually occupied for 5-10 minutes, then unoccupied for a while), others are living spaces (usually occupied for 30-60+ minutes), and others still are transition spaces (hallways, stairways, etc.), usually occupied for 30-60 seconds. It would be nice if DEM could have different settings for each of these groups - so the stairway lights are on for ~60 seconds, but the living room might be on for 60 minutes.

Apparently some dimming devices don't respond to SwitchPower commands (Leviton Vizia RF+ does).

Reported by T.C. on 2016-08-07

On the Configure screen, when tapping the green plus button after selecting On and Off Scenes, nothing happens.

I'm running UI7 on a Vera Plus and Chrome 62.0.3202.94 (Official Build) (64-bit) on Windows 10 via relay.

The code that initializes the plugin may miss setting the LightsOutTime variable. If the user never changes the time after install, just leaves the advertised default of 23:59, what in fact happens is that the variable is never created. This causes a fetch of the variable in isBedtime() to return nil and take a branch that causes it to return true unconditionally, so Deus never operates. If a user had changed the time in config even once, this would not happen; it only happens to people who have never changed the time at all. An addition problem with LightsOutTime is that its unit is milliseconds, which is a bit excessive for the purpose. This has been known and the plan has been to move to seconds since midnight. Now's the time.