I'm trying to implement "when motion is detected that suggests someone is arriving, turn certain lights up to 30%." The idea is to make them 30% if they're off, but not turn them down if they're already on (because someone is home).

This would be trivial if I wanted "all the way on" - just have the motion sensor turn the lights on. But how do I explain to Indigo "to 30% unless it's already higher"? The "brighten by 30%" action works once, but slowly moving people can trigger the sensor multiple times, leading to 60% or 90% instead.

So: What's the best way to implement "x% or whatever higher level it's already at"?

Thanks
-- perry

The easiest way I have found with Indigo 4.x is via AppleScript. With it, you can test what the current level of a Device is, and then decide whether to change it.

AppleScript is currently the best (perhaps only) way. In 5.0 though, this would make for a great plugin action...

Is 5.0 on the near horizon?

Not particularly near - hopefully beta by the end of Q12011 (March), but even that's not fixed.

@Perry The Cynic.

I had a similar scenario. I have an action to bring up my office lights to 30% around sundown. The problem i had was If i was working in the office with the lights brighter then 30%, when that date/time action ran, it would dime the lights on me. I can live with that, but the spouse… not so much. Here's what I did without scripting.

I set up a variable called "officeOverride" it's a True/False value.

I then set up two triggers to set the value of my variable. The first one sets the value to "false" or "don't override my action; run as is".

When my office date/time action runs, one of the lights brightens to 30%. So I know if the light is below 30 then there's a good chance nobody is in the office.
The trigger: "Device State Changed" [name of light] "Brightness level becomes less than 10"
Action: Set variable to "False"

The second one sets the value to "True" -- or "yes, override my date time action, 'cause somebody is working in the office"

Trigger: "Device State Changed" [name of light] "Brightness level becomes greater than 30"
Action: Set variable to "Ture"

I then modified my date/time action to use a condition of my officeOverride variable is "false"

It's been working great so far and no complaints from my spouse.

Cheers,
-Andrew

EDIT: I should point out, I'm not opposed to scripting, but wanted to see if this could be done w/o scripting.

I've done some experimenting with detecting movement via Indigo (via Insteon motion sensors). My current favorite way to do this is to write a script on each motion detector that writes the date & time into a variable called "LastHouseMotionDate". So, when motion is detected by *any* inside sensor, it writes the date & time into the variable, thus giving me the latest any motion was detected. Then a separate script runs once every minute that says "If the date variable is older than 5 minutes from now, then the house is NOT occupied. Otherwise it IS occupied". It writes out to another system variable "isHouseOccupied" as a boolean that can be used by other scripts and functions in Indigo.

This allows about a 5 minute delay from the time the last motion is seen until Indigo determines the house is empty. This is very handy for delays on exit (think: ALL OFF that delays until everyone is out of the house for sure), and for turning off lights in various parts of the house to save on the electric bill. Of course the "5 minutes" could be configured to whatever you would like.

If you'd like to me share the script code, I'd be happy to.

dstrickler wrote:I've done some experimenting with detecting movement via Indigo (via Insteon motion sensors). My current favorite way to do this is to write a script on each motion detector that writes the date & time into a variable called "LastHouseMotionDate". So, when motion is detected by *any* inside sensor, it writes the date & time into the variable, thus giving me the latest any motion was detected. Then a separate script runs once every minute that says "If the date variable is older than 5 minutes from now, then the house is NOT occupied. Otherwise it IS occupied". It writes out to another system variable "isHouseOccupied" as a boolean that can be used by other scripts and functions in Indigo.

Motion is not the same as presence. If my wife sits on the couch in the living room watching TV, she may not (detectably) move for five minutes. That doesn't mean she wants the lights to go out, nor should the house conclude that it is now unoccupied. Besides, I don't have 100% motion sensor coverage on the inside of my house. But basically, giving the house a notion of "occupancy" is sound; I've got one but based on manual manipulation for now.

I wish there was an easy way to track the distinction between explicit orders (wall switches, etc.) and deduced commands (motion, timeouts, etc.), such that explicit orders always override deduced commands. This is rather hard to do in Indigo at present, outside of AppleScript (which takes you completely outside the Device/Event UI logic). I so wish Indigo had soft devices (one of the things XTension does)...

More generally, I try hard not to make control logic that expects sensors to be perfect. I want resilient logic that doesn't fail in the face of sensors missing events (or doubling them). That's why I didn't go for the "full on, off after a while if nothing seems to be happening" approach.

Anyway, thanks for the suggestion. I may do this at some point when I'm confident enough of my sensor coverage.

Cheers
--perry

Perry The Cynic wrote:I so wish Indigo had soft devices (one of the things XTension does)...

Indigo 5 will go a long way beyond the virtual devices that XTension offers, although I'm not sure how that would do what you're wanting without scripts...

jay wrote:

Perry The Cynic wrote:I so wish Indigo had soft devices (one of the things XTension does)...

Indigo 5 will go a long way beyond the virtual devices that XTension offers, although I'm not sure how that would do what you're wanting without scripts...

I'm thinking "device stack" - a device that is a stack of virtual device layers and implements a maximum function - it's on when any of the stack layers is on (or is the brightest of any layer, if dimmable). This isolates the "multiple source" issue for lights without forcing me to implement scripted logic for each layer interaction.

There's nothing wrong with scripting, of course. The various UI elements in Indigo are scripting of a sort. The problem with Indigo 4 (and earlier) is that while UI scripts can drive AppleScripts, AppleScripts can't drive UI scripts (except through Indigo variables, which are a wee bit inflexible at present). So AppleScript use becomes a slippery slope driving me away from UI scripting, which I'd much rather keep using - if only because it's more likely to be improved to deal with edge cases and problems (while you're not going to fix my AppleScripts for me ).

One of my big hopes for your Indigo 5 plugins is keeping the "big picture" stuff at the UI configuration level, by implementing logic puzzle pieces as plug-ins and then just throwing more (virtual) devices into the mix. That sounds much more scalable than descending into an AppleScript (or Python) soup.

Am I making any sense?

Cheers
-- perry

Perry The Cynic wrote:One of my big hopes for your Indigo 5 plugins is keeping the "big picture" stuff at the UI configuration level, by implementing logic puzzle pieces as plug-ins and then just throwing more (virtual) devices into the mix. That sounds much more scalable than descending into an AppleScript (or Python) soup.

Am I making any sense?

I'm not quite following you. Can you provide a more concrete example?

Perry The Cynic wrote:One of my big hopes for your Indigo 5 plugins is keeping the "big picture" stuff at the UI configuration level, by implementing logic puzzle pieces as plug-ins and then just throwing more (virtual) devices into the mix. That sounds much more scalable than descending into an AppleScript (or Python) soup.

Am I making any sense?

And that is what the v5 plugin system should allow....

Users and Programmers will be better able to modularize the system(s).... Both for the UI & for the backend...

It's useless for Matt & Jay to make a upgradeable User Interface, if the backend doesn't allow for the addition of customized systems...

- Benjamin

Perry:

For the mean time, you're stuck with doing scripts if you want a major functionality increase in Indigo.

And yes, I know just what you mean about "Motion" vs "Occupancy" - you're spot on to a problem I have been thinking about. Being still while reading a book means "occupied", but not "motion", and there's very little to tell the difference.

As far as your "device stack" example, you can, with AppleScript, accomplish this, but it's going to be complex. And while Indigo 5 may allow for some of this to be solved, there will always be situations where a UI/Wizard won't do a complex job.

Even though I am a programmer, I love using the Indigo UI to solve automation tasks, as I know they will work the first time out, be fully debugged (with rare exception) and allow me to design, test, and use an idea quickly. That being said, I've been writing a lot of scripts lately

Let's wait and see what Indigo 5 brings from 3rd party developers, and I will share any "motion" vs "occupancy" solutions I come up with in this forum.

support wrote:

Perry The Cynic wrote:One of my big hopes for your Indigo 5 plugins is keeping the "big picture" stuff at the UI configuration level, by implementing logic puzzle pieces as plug-ins and then just throwing more (virtual) devices into the mix. That sounds much more scalable than descending into an AppleScript (or Python) soup.

Am I making any sense?

I'm not quite following you. Can you provide a more concrete example?

It's hard to provide a concrete example of scalability issues without knowing what I've got to work with. So let me just make up what I'd want your plugin interfaces to look like, and cook a bit.

Example #1: A composite irrigation controller. I've got more than eight watering circuits. So I create a "whole house watering" device type that is given a list of watering controllers to supervise. It behaves the same as the existing device type (but with any number of channels), and overrides the operation of all its constituent controllers. I'd add UI for controlling the watering schedules (via a webpage), and a mini-daemon to control the inevitable foul-ups during reboots/restarts/power messes.

The point here is that the new behavior looks like an existing irrigation device, so existing scripts that work with irrigation controllers will continue to work. Nothing specific to my house goes into the device plugin. Nothing specific to controlling the watering hardware goes there either - it's done indirectly by controlling the individual devices. If I need more watering, I add another physical controller, but I don't have to change anything in my scripts.

Example #2: Light stacks. I want multiple reasons for turning a light on to stay cleanly separated so they don't interfere with each other. I'd create a new virtual light device type that's like a dimmable light, but with no hardware. Then I'd create a device attachment plugin that goes with any light device (told you I'd make up stuff ) and allows me to configure (through UI) a list of light devices. The attachment simply forces the top light to be the maximum of the intensity of all the input devices.

Concretely, to control the "living room" (LR) light, I'd create a "LR/explicit" device, a "LR/occupancy" device, and an "LR/nightlight" device, and stack them together to control LR. Now I can use Indigo's UI to link a wall switch to LR/explicit, a motion sensor to "turn LR/occupancy to 50% and turn it off again after 10 minutes of inactivity", and a "nighttime" variable to turn LR/nightlight to 20%. They won't interfere with each other, because they can't - they're nominally addressing different devices. I don't have to write code to remember explicit activation to bypass the inactivity-off; I don't need variables for any of this stuff, and so it scales nicely. I can put those soft lights into action groups, trigger actions, etc. and it all works because they are exposed at the top (device, UI) level, not just figments of a script's imagination. And the guys who download my plugins don't need to know a thing about how to use it, because they already know how to handle light devices.

Example #3: Non-Insteon control. Say I have a Panasonic AVR (AV Receiver) device that can be controlled through its RS-232 serial port. I have a Global Caché GC-100 network device near it (connecting to the serial port). I write a controller plugin for the GC-100 that knows how to configure the serial port and push data to/from it. I write a plugin for the Panasonic that allows me to send commands to it ("switch to DVD!", "volume +5 db", "switch output to HDMI-2", etc.), read its status, and create Indigo triggers based on that. (That Panasonic actually reports all changes to its serial port, so turning the volume knob would report a volume change, for example.)

The GC-100 plugin needs to be routed (connected) to the Panasonic plugin - Indigo needs to understand that you "reach" that particular Panasonic through that particular GC-100's serial port #2 (say). At this point, we're done writing Python or AppleScript code; the rest is good old Indigo actions and triggers. And if the topology changes, no scripting needs to change at all. Say I replace the Panasonic with a version that has an Ethernet interface. It talks the same protocol on a TCP/IP port that its brother talks on RS-232. The Panasonic plugin needs no changes; you simply "disconnect" its instance (in UI) from the GC-100 and "connect" it to an IP address/port plugin instead. Flexibility and scalability, again.

I can spin those on forever. These three all happen to be concrete problems I have around my house.

The major points I draw from these examples (and many others) are:
1. Make it easy to isolate particular knowledge and behavior in a plugin and make it easy for different plugins to cooperate to produce complex behavior. If you find yourself saying "you can just script that interface," you're falling off the wagon. Well-written plugin components in common scenarios should be connected in the UI with no other scripting needed. If scripting is needed, it should take the form of a "glue" plugin, not some glob of Python in my project.
1b. I'll say this again: different kinds of knowledge (transport, language, behavior) should go into different plugins (not one "do my thing" super-plugin), and Indigo should make it easy, inviting, and downright seductive to do so.
2. Indigo needs to support any number of controllers working together at routing requests to and from devices (though perhaps only one to talk the Insteon protocol).
3. Plugins must be powerful enough to implement all predefined device behaviors, and predefined device types should be available to subclass (derive behavior from).

Anyway, again: am I making sense to you? I have a pretty strong sense of what I need and want, but this isn't the easiest setting to get it across.

Cheers
-- perry