Simple Feature Requests

Posted on
Sat Sep 02, 2006 11:15 am
dduff617 offline
Posts: 659
Joined: Jul 05, 2006
Location: Massachusetts, USA

(No subject)

support wrote:
Unfortunately, this is impossible given how the INSTEON protocol is defined. Indigo cannot simulate or masquerade as another device to send out one of its commands. The PowerLinc V2 can send out group commands (Indigo doesn't do this yet), but they have to be groups defined and linked specifically with the PowerLinc V2. It is impossible to have the PowerLinc send out the same command that a KeypadLinc (or other module) sends out when one of its buttons is pressed.


thanks for replying and clarifying the capabilities of insteon. i understand that it is not kosher/possible to mimic another device at the insteon protocol level.

what i had in mind was that insteon could use the concept of a "smart on" command as a shortcut for saying all the commands you would need to do to achieve the same result as if you'd pressed the on button on a particular device. (note that you could also have "smart" off and dim commands, too). it could be implemented by having indigo send a sequence of individual commands, a group command, or whatever. the user doesn't really need to know or care. however it is implemented, i think it would be a useful feature to have in the program.

so, for example, if i have a "virtual n-way switch", in a script where i currently need to say something like

turn on "dining room light"
turn on "dining room light kitchen entrance slave switch"
turn on "dining room light living room entrance slave switch"
etc...

i could simply say

turn on "dining room light" with paired devices "yes"

or perhaps

simulate on "dining room light"

as another example, you set up a "scene" where one switch turned on a set of multiple units to certain brightness levels. using the "simulate on" command lets me invoke this scene easily from indigo without a lot of extra scripting.

i imagine that the user would just see an extra checkbox in the edit action dialog when the type is set to "send device command" called "also send to paired devices" or something. alternatively, there could be a distinct action type called "simulate insteon device command".

so does this seem feasible? it seems to me as though it would be, since a "simulate on" command could at worst be just a substitute for a sequence of insteon commands sent to the indicated device and it's pairs, and indigo already knows about everyone's pairings.

the only fly i see in the ointment here is that i don't understand why indigo can't change the state of keypadlinc buttons, even though other devices paired with those buttons CAN... what is it about the way indigo pairs with keypadlinc that introduces this limitation? and while we're on this topic... i will say that this issue is the single biggest "kink" in my system right now. i have invested in several keypadlinc II's around my house and while i love the reliable communication, the lack of proper support for the LED's on these things makes it so that using indigo on any devices linked to the keypad buttons mucks things up. needless to say, i hope we see some kind of improvement here soon.

thanks again.

Posted on
Sat Sep 02, 2006 11:42 am
nsosnicki offline
Posts: 168
Joined: Nov 14, 2004
Location: Boston, MA, US

Variables instead of absolute values in actions

I don't know if this should be categorized as simple or not:

It would be nice to have the option to use the value of a variable instead of an absolute value on the action tab of trigger actions for:

-brighten by %
-dim by %
-set brightness
-delay action by x minutes

I know this can be done in applescript, but it would be more convenient to be able to manage it all from the "edit trigger" window.

Posted on
Sat Sep 02, 2006 12:43 pm
macpro offline
User avatar
Posts: 765
Joined: Dec 29, 2005
Location: Third byte on the right

(No subject)

@nsosnicki:You get my votes for this request. I'm using variables for this purpose at the moment and have to rely on AppleScript to get it all working.

Posted on
Sat Sep 02, 2006 6:50 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

(No subject)

dduff617 wrote:
what i had in mind was that insteon could use the concept of a "smart on" command as a shortcut for saying all the commands you would need to do to achieve the same result as if you'd pressed the on button on a particular device.

I understand -- I thought you were wanting something different. This would be possible to implement, but I would really rather do this "the correct way" instead of adding additional (maybe temporary) UI at this point. One thought -- if your devices are really cross linked such that they both always mirror each other, why not just delete the secondary switch from Indigo altogether? So you would just have a single "dining room light" device defined in Indigo. I think Indigo will update its state correctly when controlled by the secondary switch since you already did a sync of the secondary (meaning Indigo knows about the links). Not an ideal solution, but it might work for the time being.

dduff617 wrote:
the only fly i see in the ointment here is that i don't understand why indigo can't change the state of keypadlinc buttons, even though other devices paired with those buttons CAN... what is it about the way indigo pairs with keypadlinc that introduces this limitation?


The problem is there is not a direct command supported by the KeypadLincs to turn the LEDs on/off. For Indigo to control the LEDs, Indigo will have to create a link pair (one in the KeypadLinc and one in the PowerLinc V2) for every single button on the KeypadLinc, and then Indigo will have to send out the appropriate group commands to the KeypadLinc. By the time we get that far, we are well into the link management feature.

Getting this implemented is a high priority, but it isn't a quick feature. I'd rather spend the development time doing the full feature than implementing and QAing a workaround solution.

Regards,
Matt

Posted on
Sun Sep 03, 2006 2:52 am
dduff617 offline
Posts: 659
Joined: Jul 05, 2006
Location: Massachusetts, USA

indigo (non-)support for cross-linked devices

support wrote:
if your devices are really cross linked such that they both always mirror each other, why not just delete the secondary switch from Indigo altogether? So you would just have a single "dining room light" device defined in Indigo. I think Indigo will update its state correctly when controlled by the secondary switch since you already did a sync of the secondary (meaning Indigo knows about the links).


yes you are of course correct that indigo correctly tracks the state of the load whether it is controlled directly or from any of the paired switches, and in that sense, representing the extra "slave" switches in indigo buys nothing.

actually, i should say that i'm sure it works this way in the case where indigo has been paired with both the load and the slave devices. i am less sure whether it still work correctly if indigo knew about the load but not the slave. i guess in some sense indigo would know about the slave even if i did not pair it to the controller, since it would find it in the link table of the load device, so i think it would still work (but i haven't tested it).

to answer your question, in the case where you want to be able to control the load from indigo, then you will find that the state of the LED's on the paired switches does not correctly track the state of the load if you don't send matching commands to the paired "slave" devices.

about 75% of the switches in my house were controlled from two or more locations in the original plan (before i got around to installing automation gear). while automation (and insteon, in particular) opens up lots of options, i have mostly found that it makes sense to leave switches in their original locations, since it really does make sense to control the lights from both/all of them - for example switches at two ends of a hallway, top and bottom of a staircase, two entrances to a room, etc.

that's why in my scripts, i find myself having to do the tedious task of controlling pairs/triples of units together to keep them properly sync'd with each other, even though it feels like indigo should be able to make this easier, and thus... my suggestion.

parenthetically, another argument for representing the slave units in my case is that i use them to facilitate invocation of extra automation commands from them, i.e. from double-tap commands.
Last edited by dduff617 on Sun Sep 03, 2006 3:32 am, edited 1 time in total.

Posted on
Sun Sep 03, 2006 3:25 am
dduff617 offline
Posts: 659
Joined: Jul 05, 2006
Location: Massachusetts, USA

(No subject)

support wrote:
The problem is there is not a direct command supported by the KeypadLincs to turn the LEDs on/off. For Indigo to control the LEDs, Indigo will have to create a link pair (one in the KeypadLinc and one in the PowerLinc V2) for every single button on the KeypadLinc, and then Indigo will have to send out the appropriate group commands to the KeypadLinc. By the time we get that far, we are well into the link management feature.


my understanding of the details of insteon are pretty weak, but isn't it the case that indigo already creates "forward" links from keypad buttons to the powerlinc at the time you first do "define and sync..." on the keypadlinc device? i assume so, because otherwise, the controller would not be able to track button presses and users could not attach triggers to keypadlinc button events as they now can in indigo. i assume so also because i have seen how long it takes to do the initial setup of a keypadlinc with indigo and i have seen messages in the logs which seem to indicate that there is some kind of pairing process taking place for each button.

so would it be sufficient to also create "reverse" links (from powerlinc to keypadlinc buttons) to allow the controller to change individual keypadlinc button LED's? would creating the linkage in both directions any harder than what you are already doing (aside from the fact that there would be 2x as many links to create)? or is there more to it than that?

or to ask it another way, would this two-way linkage be different than what indigo already does with a switchlinc? (aside from the fact that it needs to be done 6 or 8 times instead of just once) doesn't indigo already set up linkage in both directions for switchlincs? or for that matter for the "primary" button on keypadlincs? is there some fundamental difference between the way that the powerlinc controls the primary button (the load) on the keypadlinc vs. how it could control the secondary buttons?

i have a feeling i must be missing something, or else this would already be supported in indigo.

Posted on
Sun Sep 03, 2006 7:57 am
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

(No subject)

so would it be sufficient to also create "reverse" links (from powerlinc to keypadlinc buttons) to allow the controller to change individual keypadlinc button LED's?

Correct.
would creating the linkage in both directions any harder than what you are already doing (aside from the fact that there would be 2x as many links to create)? or is there more to it than that?

There is more to it than that. Indigo also has to send out group broadcast commands instead of direct commands. And creating and managing those links is non-trivial. It just isn't a 2 day feature, or would have been completed a long time ago. It'll be done when I get around to implementing the link management feature, since what you are talking about is pretty much link management.
or to ask it another way, would this two-way linkage be different than what indigo already does with a switchlinc?

Yes, it is different. It'll be done when link management is implemented.

i have a feeling i must be missing something, or else this would already be supported in indigo.

The only thing missing is how complex and time consuming it is to implement and QA INSTEON link management.

Regards,
Matt

Posted on
Thu Oct 19, 2006 4:31 pm
Terry offline
Posts: 44
Joined: Apr 24, 2005
Location: Essex Junction, Vermont

Set brightness to variable value

Matt,

Variables are a big part of Indigo, used to store and manipulate all manner of info. One of the things I found I could not do was set a device brightness to a value in a variable.

It seems like a natural as a feature instead of needing to resort to a script.

If possible, please add it, thanks.

Terry

I started off with nothing...I still have most of it left.

Posted on
Thu Oct 19, 2006 4:56 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: Set brightness to variable value

Hi Terry,

I have some long term plans for this functionality (and quite a bit more functionality related to this). Unfortunately, it likely won't make it in before 2.0 ships. :-)

Regards,
Matt

Posted on
Fri Nov 24, 2006 3:50 pm
macpro offline
User avatar
Posts: 765
Joined: Dec 29, 2005
Location: Third byte on the right

(No subject)

In AppleScript, it's possible to do a "remove delayed actions" for devices and triggers. But not for action groups, although it is possible to delay them also.
Is it possible to add a "remove delayed actions for group" option to Indigo?

Posted on
Fri Nov 24, 2006 5:24 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

(No subject)

I think this is a good idea, but it is unlikely to happen before 2.0 ships. The way things are setup the delayed actions don't know about their parent containers (Action Group in this case) so deleting them while they are in a delayed state is a bit more complicated than I would like.

Regards,
Matt

Posted on
Fri Jan 12, 2007 2:29 pm
macpro offline
User avatar
Posts: 765
Joined: Dec 29, 2005
Location: Third byte on the right

(No subject)

I like the action steps very much, but sometimes for some reason, I want to disable a single step.
This is not possible right now, so it means I'll have to delete the step and add it back when I need it again.
Is it possible to add an enable checkbox to action steps?


When sending messages to the log, they all are written in gray/black.
Indigo has the option of showing red error messages in the log.
Is it possible to show my own messages in red when I use a log type of Error?
Or maybe add an optional parameter color so I can define my own colors for log messages?

Posted on
Mon Jan 29, 2007 2:22 pm
DeepTech offline
Posts: 40
Joined: Nov 28, 2005
Location: New York, NY

Feature request for Control Pages

Heres an idea or two.
There should be a safe area to add user graphic files that wont be deleted during an indigo upgrade or reinstall.

also

Each device should provide for a path for image file to represent each state.
That would make it easier to use custom icons.

also

we need some kind of custom conditional states so we can have direct image representation for various variable values. e.g. "Armed - Disarmed, Active - Inactive, Full - Empty"

- DeepTech

Posted on
Fri Feb 09, 2007 4:05 pm
ptone offline
Posts: 5
Joined: Feb 09, 2007
Location: Santa Barbara

test script in conditions pane of trigger

I'm just getting fired up about indigo and Insteon and just doing my research so far. But in looking at Indigo as an experienced scripter, I keep thinking it would be great to have an embedded applescript option on the condition pane of a trigger.

Basically, a "Run test" radio button would enable an embedded AS text area. When the trigger event happens the script is run (which can test one or more variables, check states of other devices etc). If the test returns true, than continue to the actions, if it returns false, then abort and log)

I know I can put all this complex conditional testing in the Applescript at the action level, but this feels like the wrong place for it, and it means that I can't use the UI to set or change simple actions with complex conditions.

I guess it just seems cleaner to factor the condition scripting and the action scripting into the existing portions of the UI.

-Preston

Posted on
Fri Feb 09, 2007 4:34 pm
macpro offline
User avatar
Posts: 765
Joined: Dec 29, 2005
Location: Third byte on the right

(No subject)

I like this idea. But I would also like to see conditions per action step.
For instance: step 1, 2 and 3 always, step 4 only if it's dark and 5 only if device A5 is on.

Who is online

Users browsing this forum: No registered users and 1 guest