pbeker46

Thanks, much appreciated. That's what I suspected, but I could se it being either way and needed to know for sure. And I get the story on battery powered devices, but they aren't my concern here.

I am working on a power loss recovery program. I am presuming a couple of things: 1. The ISY O/S doesn't query devices when a program runs unless the program specifically asks, rather it keeps current status based on event changes in its memory and that's what you are testing in a program status conditional. 2. If so, that means to be certain the ISY has correct information after a power on, I need to do a QUERY (unless the ISY does one on power on, which it might - does it)? My question is, can the Query trigger program state changes if it finds things different than the current ISY memory shows and thus run programs? If so, I'll need to make a variable that indicates programs shouldn't respond to a query, but if I don't need to do that, it saves a lot of coding. I pretty much trust the Insteon devices to remember their last state through a power off/on, but I also have been a real time man in the loop programmer for enough decades to "trust but verify" to catch that one case in 1000 where they didn't and be sure the system comes up in a safe state. I understand in general the state triggered structure of the ISY994i programming, but am trying to fully understand all the edge conditions like power on and Query that either may or may not trigger programs to run and handle them correctly. Of course, if this is totally incorrect, what does the ISY O/S do as to assuring it has correct device status on a power on?

So adding a device that is already cross-linked to the ISY and saying preserve links, doesn't cause the ISY to read and know those links? That would explain a few situations I've run into that I fixed by deleting the devices, re-installing them using "delete links" and then putting them into scenes in the ISY interface. I fell into assuming (and we all know what that does) that the option to keep links would cause the ISY to interrogate what those links were. Thanks!

Back again with another newbie Insteon Question (thanks for all the help here, really appreciated in a "crash learning" mode). A simple setup for this question is: A 3-Way switch is replaced with two SwitchLinc dimmers, one is actually connected to the load and handles the real dimming function, the other is virtual, connected to nothing but cross-linked to the first. This is a simple 3-Way setup. My question is: Is it possible to make the LEDs in the "virtual" SwitchLinc track with the "real" SwitchLinc dimmer to accurately reflect the dimming level? I wondered if an ISY program that set the level in the virtual one could do this, but was left trying to understand how to get it to track timing as it seems it is only triggered by the event of pushing or releasing the switch, not holding it down. Thinking about this also made me wonder if there was a way to light the LEDs other than the top and bottom ones on a SwitchLinc switch if it is used in virtual mode. This is a *really* small deal (especially if there is a way to do the above), as SwitchLinc dimmers and Switches cost the same, so buring a dimmer as a virtual switch isn't and issue. It really is just me wanting to explore this issue to the end once it has come up...

Thanks, I was afraid of that. Just wondered if I was missing something simple here. Sounds like blacking out the LED under the button combined with no toggle-off is best bet.

I'm a newbie to Insteon and trying to figure out how to disable an unused button on a Keypad. I thought that setting it to no-toggle off would do it, but when you press the key the led flashes rather than doing nothing. Is there a way to have the led simply do nothing (i.e. stay off) when a key is pressed reflecting that the unused key does nothing?