SoCal Rob

TomL & bambamf16- Thank you! I would swear I had disabled them post-upgrade but when I went back in and verified they were disabled it was showing them enabled. I think I'll double-check in the Summary view from now on since the enabled state is MUCH easier to read there. I disabled the follow-up programs, saved, and all is working correctly again. I also may need to consider reading glasses since unless I zoom in on my display it is really hard to see the difference between an enabled program and a disabled program when both are stopped in the details view. I wonder if it would be better to change disabled to something like my crude example in the middle, here: To my eyes, the black / is more easily seen and color elements on the icon are still discernible.

I upgraded from 4.7.3 to 5.0.16 today and all went well except for my programs which rely on a Wait command. For program 1 (shown below) in the Then section rather than waiting 3 minutes and then proceeding to run program 2 whenever any if the 4 conditions in the If section are met it immediately runs program 2 as if the Wait 3 minutes command wasn't in the Then section. This differs from the 4.7.3 behavior where it would wait 3 minutes and then run program 2. I tried deleting the program and recreating it but it still doesn't execute the Wait before running Program 2. Do I need to do things differently with Wait commands in 5.x? Thanks! 1 MasterBath Lights on For 3 Minutes - [ID 000E][Parent 0024] If 'Master Suite / Master Bath - Shower Light' is switched On Or 'Master Suite / Master Bath - Shower Light' is switched Fast On Or 'Master Suite / Master Bath - Vanity Light' is switched On Or 'Master Suite / Master Bath - Vanity Light' is switched Fast On Then Wait 3 minutes Run Program '2 MasterBath Lights Still On?' (If) Else - No Actions - (To add one, press 'Action') If any of the MasterBath Lights are turned on (fast or regular) then wait for 3 minutes and run program 2 If statement

Brian- Yes, as I tried to explain in my "Batch mode: Am I doing it wrong?" post the 11010 button was gray and NOT green. On my Admin Console the 11010 button in the toolbar is the same as File > Automatic Writes to Devices and clicking either one changes the state of both. I thought that for both gray = off = batch versus green = on = immediate. Is that correct? If so, my system behaves the same (immediate writes) regardless of the state of this control. Again, any help is appreciated.

Hello- I upgraded to the Pro version and I tried making a change to a device setting in a scene while in batch mode (11010 button gray and NOT green). The device I was adjusting was immediately turned on to the selected setting and I received an "Error" window "Request Failed" followed by a window with a title bar of "Failed Communicating With" and text of "Cannot Communicate With . Please check connections." This behavior matches what happened before I upgraded. I thought that once in batch mode changes wouldn't be made to the device until I clicked the 11010. At that point the button would go from gray to green and ISY would write all pending changes to all devices in a batch. This doesn't sound right or seem like a communication issue so here are some more details: ISY 99i Pro running firmware v.2.8.10 Mac OS X 10.6.5 Snow Leopard Java SE 6 64-bit 1.6.0_22-b04-307 (primary) Java SE 6 32-bit 1.6.0_22-b04-307 (secondary) Exited all browsers, cleared Java cache (even the deleted items) and tried again with the same result. Please let me know if other diagnostic information is needed or if I should be posting this in a different version. Thank you very much.

oberkc- Yes, other than programming everything works very reliably. I assume that programming requires more bi-directional communications and with more data than regular operations and thus is more sensitive to the interference. I was doing some investigating in the forums and discovered that I also have a SwitchLinc Relay v.35 and a SwitchLinc Dimmer v.35 that appear to be known trouble-makers. I guess I need to ask SmartHome about swapping them. Even with all of what I am describing it is way, WAY more reliable than my former X10 setup which had reliability issues in everyday use. At least I only have communication symptoms when programming and normal use is rock-solid, even with my low voltage track heads dimmed and my two v.35 devices. I think that the PRO upgrade will do all that I need to eliminate this one annoyance. Thank you very much.

Michel- Each track head has a built-in transformer and the track follows an angled ceiling from 9 feet to 15 feet above the floor. In my case removing even the lowest one requires the use of a ladder so removing them all to get reliable programming would be a lot of work. The upgrade to PRO for batch changes sounds worth it to me and I appreciate the suggestion. I will give it a try. Lee & Brian- Excellent questions about the transformers and the safety/longevity issues. I apologize for omitting that important detail in my original post. Yes, the track heads use a dimmable solid state electronic transformer per the manufacturer. They were purchased with my Insteon setup in mind. I really appreciate the help and I wish all of you the best in 2011!

Hello- Before moving on to my question, I am open to the concept that I am doing something incorrectly and this is *entirely* my fault. Here is the background for my question: I have a number of dimmers that control track heads with low voltage transformers. The transformers, when dimmed, seem to create noise. Not enough noise to interfere with normal use as the modules respond fine to commands when dimmed but I have problems programming them. Whenever I change the dimming level of one of these in a scene, the ISY sets the device to that dimmed level. While convenient for verifying, this is self-defeating for me since the ISY invariably cannot communicate with the device that it just dimmed to write the scene. Typically I turn the device full on or off via the ISY and then force the ISY to write the pending data to the device. Here is my question: Is it possible to modify a scene and write the modifications as necessary without the ISY actually changing the devices first? If not possible then I have a suggestion: When making lots of changes to a scene (or setting up a scene with a lot of devices) it would be nice if there were a check box "Apply changes in real time." With the box checked, the ISY would behave as it does now. With the box unchecked, you could adjust all of the sliders without altering the state of the devices in the scene. The scene programming would be done as a separate step using a save changes button or something similar. I suspect that others may be encountering this same issue so changing this may result in fewer communications issues. Sorry for the novel and thank you.

Hello- Before moving on to my question, I am open to the concept that I am doing something incorrectly and this is *entirely* my fault. Here is the background for my question: I have a number of dimmers that control track heads with low voltage transformers. The transformers, when dimmed, seem to create noise. Not enough noise to interfere with normal use as the modules respond fine to commands when dimmed but I have problems programming them. Whenever I change the dimming level of one of these in a scene, the ISY sets the device to that dimmed level. While convenient for verifying, this is self-defeating for me since the ISY invariably cannot communicate with the device that it just dimmed to write the scene. Typically I turn the device full on or off via the ISY and then force the ISY to write the pending data to the device. Here is my question: Is it possible to modify a scene and write the modifications as necessary without the ISY actually changing the devices first? If not possible then I have a suggestion: When making lots of changes to a scene (or setting up a scene with a lot of devices) it would be nice if there were a check box "Apply changes in real time." With the box checked, the ISY would behave as it does now. With the box unchecked, you could adjust all of the sliders without altering the state of the devices in the scene. The scene programming would be done as a separate step using a save changes button or something similar. I suspect that others may be encountering this same issue so changing this may result in fewer communications issues. Sorry for the novel and thank you.