Indigo Domotics

Different Computers wrote:

Is there a way of doing this I haven't even thought of?

In 1.5.0 of Device Extensions I added a new conversion to read the device's lastUpdated property and turn it into "minutes elapsed". You can write an easy trigger "if door = open and elapsed >= 1". That feature is current in the plugin on the site (as 1.4.2) if you want to test it out. If the concept sounds good and works the way you want then let me know, I have a couple easy code ideas that could probably make it work out for you.

Nice!

For now I've gone with variables. More I thought about it, the smoother that seemed.

If it looks like a device, and quacks like a device, call it a device. That's what the virtual devices are for. These are actual devices, but one that you don't have a direct connection to. If you set it up as a device, then you can use normal device semantics to interact with it.

Then, if you ever swap out those sensors for Insteon or Z-wave ones, nothing changes except the device type in the existing device.

Different Computers wrote:

For now I've gone with variables.

FlyingDiver wrote:

If it looks like a device, and quacks like a device, call it a device.

And these two quotes perfectly embody the reason for most of my plugins, I got tired of managing variables

Colorado4Wheeler wrote:

Different Computers wrote:

For now I've gone with variables.

FlyingDiver wrote:

If it looks like a device, and quacks like a device, call it a device.

And these two quotes perfectly embody the reason for most of my plugins, I got tired of managing variables

Different Computers wrote:

But IS that more complicated? In one case I have two groups (that have to be built of various parts and kept up to date) and in the other I have ONE group and one variable.

Imagine if I decided I want my GE Link bulbs to come on at 50 % starting at Sunset until full dark. If I don't do a variable, I have to create another group entirely for that 40-ish minute window of time/behavior.

I'm all for simplicity. But I wonder about how to achieve it. Hence my calling for best practices.

I am late to the game here, and what I have done in these cases is create scenes. When a device has more than on/off state and I want to leverage that consistently at a trigger or schedule, that works for me. For instance. I have all my outdoor low voltage pathway lights on a on off scene. But the lights on the garage exterior and front porch can be ramped to any level of brightness. I wanted my garage and porch to be a progressive ramp over the course of an hour to come on and go off (it is such a subtle beauty to watch). I have scenes set for 3 brightness levels. I did this because I also use those brightness levels off a motion sensor trigger.

I run the scenes in an on script with a delay that allows the ramp. May not be the best practice but I like how it looks and overall isn't that what really matters?

I'm still thinking about this, but my first thought about it is Actions are better than virtual device groups because they're easier to tune or change. Doesn't mean I don't use some VDGs, but going forward I'll probably use Actions.

Having tried a bunch of ways to get my lights to react to sunrise/sunset, I'm finding the most satisfying one is to use a Luminance sensor. I'm still tuning the sensor itself and fixing some rules that keep exterior lights from coming on too soon, but this works best for me--better than a python script that counts up/down a value for "darkness" around sunset/sunrise, or trying to set long ramp up values based on the same.

Not an answer that's necessarily generalizable--but maybe it is: Maybe the Best Practice is to, whenever possible, have automations react to real world changes rather than set schedules or scripts.

Hi Ahmed,
Take a look at this page Indigo 7 Documentation

There is a link on that page to Getting Started Guide highlighted with ← Start here!

That should get you going but any further questions, please ask.