Simple Feature Requests

Like I said, I haven't been using this long enough to say I have much weight on this topic. But it sounds like several feature requests are for more of the control in trigger actions to be available in action groups (a condition test, a disable flag, etc).

I was also reading about the requests for some capability for hierarchy

It then occurred to me that a time/date trigger could be pretty nicely represented as a trigger type (just add date/time to the list of trigger type choices)

So to be so bold as to offer a 3.0 UI redesign:

There would be these choices on the left of the main window:

Devices
Actions
Control Pages
Variables
Log

(Seems like variables and log could easily be integrated instead of being their own window)

"Actions" would be a combination of Trigger Actions, Date Time Actions, and Action Groups

The tool bar at the top of actions would be similar but with the added options:
New Group
New Folder


A folder is just for organization, a group would be analogous to the current action group, but displayed as a disclosure triangle widget with action steps indented.

Devices would also allow folders for organization (but would not group them functionally). Popup menus for devices would then be hierarchical based on the folders.

Each action would have an icon to represent whether it was a group, or the trigger type (ie a clock for time/date triggers)

The main screen would be a split window. Clicking on an item in the list view on the left would open up the controls currently presented in modal dialogs in the right side. (or perhaps an inspector, but the dialogs should be phased out IMHO)

An action group contains child actions that are essentially the same as other actions but without a trigger (they have conditions and disable flag). Clicking on a group in the action list would still reveal the trigger and condition panes on the right, but no action of its own. Adding child actions could be done via drag and drop, or by clicking the "New..." button while a group or child is selected. Dragging an existing action into a group would delete/disable its trigger.

Again, Indigo looks awesome in its current form. While these are major suggested changes to the UI, they aren't the overhaul to the underlying code that it sounds like 2.0 was (LOVE the client server approach). Nonetheless I'm sure there are other major functionality features that are more interesting an inspiring to program already on the list.

I do think NOT having used Indigo much gives me the advantage of not being habituated to it and so perhaps there is value to the opinion of someone not new to software, but new to Indigo.

-Preston

[matt (support)]

These are good ideas. Keep them coming.

Regards,
Matt

...
(Seems like variables and log could easily be integrated instead of being their own window)
...

Good ideas, but I don't like this one. I have all three windows open all the time as it gives me the possibility to monitor Indigo. Especially when (re)defining action groups/triggers it's nice to be able to see the results in the log/variables window. By moving these two windows into the main window, this advantage goes away.

I have two feature requests:

Custom status for devices. I would like to display something other than on/off at times. For instance, I have a thermostat setback controller that when it is actually on it turns down the heat. It sort of backwards unless you know how it operates.

I would also like to see a location field for each device instead of having to use description.


--AJ

Here's what I'd like to see in the next release:

1) support for built-in countdown timers. I know this can be done with scripting, but something simpler that's built in would be nice.

2) A way to organize the device, trigger actions, time/date actions, action groups, etc... into groups or folders or something. It's just hard to see what you need to see when you've got 300 actions set up.

3) a way to duplicate actions and groups of action but automatically change the device referenced by the actions. (as well as change the references in the embedded apple scripts)

At last caught up to actually changing from 3.x to 4.x and 2 features popped in to my head:

1. Use a variable to set the dim, brighten numbers would be convenient, that way you can just change the variable, for example, when the house goes to sleep mode, say, its at 100%, sleep mode kicks in and change it to 25%.

2. Now that it detects the motions sensors state, it would be nice to send the device state as the action instead of explicitly sending a "turn on/off" or "toggle."

Also agree it would be nice to have multiple condition

Regards,

--Alan

I'm also going to throw my support behind multiple conditions - last night I set up turning the light in my detached garage if any door (of three) was open and it was after dark, and turning off when all doors were closed. yikes!

Anyway, if UI problems are holding this back, I have a suggestion from business process software package I used at work:

1) allow any number of conditions, one per line
2) each line has a letter or number
3) wrap them all up into a one "condition argument" that works on line numbers.

For example,

A) isDaylight is FALSE
B) eastDoor_open is FALSE
C) westDoor open is FALSE

condition argument: A and B and C

The UI for this could look a lot like the "show all" UI for actions, only each line would be number/lettered and there'd be a master control line at the top or bottom. This "advance mode" could be hidden; triggers can start with the existing screen, and flip to the new screen when an "add new" button is clicked... again, like multiple actions.

Also, I'd really like to apply more than one "trigger" even to a trigger action. Right now I seem to have a lot of duplication of trigger actions with different triggers, and it's getting irritating to manage them all. Trigger folders seems like a band-aid for this underlying missing behavior.

For example, right now my "living room lights" keypadlinc button turn on when any light (of four) is on and off when they're all off. The best way I could come up with for this logic required a *lot* of triggers:

first, the multi-triggers:

1) on device "hanging lamp" state becomes off, increment variable LRlampOff
2) on device "table lamp" state becomes off, increment variable LRlampOff
3) on device "mantle lamp" state becomes off, increment variable LRlampOff
4) on device "floor lamp" state becomes off, increment variable LRlampOff

now, the multi-conditions:

5) on variable LRlampOff change, if hanging lamp is off, increment variable LRlampOff1
6) on variable LRlampOff1 change, if table lamp is off, increment variable LRlampOff2
7) on variable LRlampOff2 change, if mantle lamp is off, increment variable LRlampOff3
8) on variable LRlampOff3 change, if floor lamp is off, turn off KeypadLinc LED

In addition, four *more* triggers are needed to turn the LED on why any light is turned on. Granted, it works... but, again, it seems like an awful hack around missing Indigo functionality. It's worse than programming Legos.

[jay (support)]

Also, I'd really like to apply more than one "trigger" even to a trigger action. Right now I seem to have a lot of duplication of trigger actions with different triggers, and it's getting irritating to manage them all. Trigger folders seems like a band-aid for this underlying missing behavior.

For example, right now my "living room lights" keypadlinc button turn on when any light (of four) is on and off when they're all off. The best way I could come up with for this logic required a *lot* of triggers:

first, the multi-triggers:

1) on device "hanging lamp" state becomes off, increment variable LRlampOff
2) on device "table lamp" state becomes off, increment variable LRlampOff
3) on device "mantle lamp" state becomes off, increment variable LRlampOff
4) on device "floor lamp" state becomes off, increment variable LRlampOff

now, the multi-conditions:

5) on variable LRlampOff change, if hanging lamp is off, increment variable LRlampOff1
6) on variable LRlampOff1 change, if table lamp is off, increment variable LRlampOff2
7) on variable LRlampOff2 change, if mantle lamp is off, increment variable LRlampOff3
on variable LRlampOff3 change, if floor lamp is off, turn off KeypadLinc LED

In addition, four *more* triggers are needed to turn the LED on why any light is turned on. Granted, it works... but, again, it seems like an awful hack around missing Indigo functionality. It's worse than programming Legos.

Thanks for the suggestion! Multiple conditions are very high on the list for version 5.0.

Now I'm trying to debug a trigger issue, and I thought of another feature that would be really helpful for maintenance, unless there's already a way to do this I haven't figured out yet.

From the "variable list" window, it would be extraordinarily helpful to be able to pull up a list of triggers that modify a given variable. It might also be nice to see triggers that depend on a given variable, or some combination thereof if it's easier to implement.

[jay (support)]

Now I'm trying to debug a trigger issue, and I thought of another feature that would be really helpful for maintenance, unless there's already a way to do this I haven't figured out yet.

From the "variable list" window, it would be extraordinarily helpful to be able to pull up a list of triggers that modify a given variable. It might also be nice to see triggers that depend on a given variable, or some combination thereof if it's easier to implement.

We've had several requests in the past to be able to start with one object type (device, trigger, variable, etc) and get a list of other objects that use it. It's on our list. There is a database report tool in the file library that you might find useful in the meantime, although I haven't personally used it.

The insteon motion sensors send a signal to insteon group 3. It would be nice if indigo could trap this and log (email etc..) which sensor has a low battery.

[jay (support)]

The insteon motion sensors send a signal to insteon group 3. It would be nice if indigo could trap this and log (email etc..) which sensor has a low battery.

You can: create a trigger on "INSTEON Command Received", receive "on", from "Group 3 (low battery warning)".

How's that for quick feature request turnaround.  ;)

I've done that but I have a lot of sensors in my house and it would be helpful to know which one is low on batteries.

[jay (support)]

I've done that but I have a lot of sensors in my house and it would be helpful to know which one is low on batteries.

Select the specific device from the "Device" popup and make sure your action is specific to that device (i.e. have it send an email with the device name in the subject line or something). Then, duplicate it for each motion sensor and alter the action as appropriate.