Xathros

Insteon scenes don't have a status. You would need to test the status of each scene member to make a determination. Many of us choose a single member device to represent the status of a scene. Others will set a variable at the same time as turning on/off a scene and use the value of the variable to represent the scene's status. -Xathros

Any dual band Insteon device that receives a message with hops remaining will retransmit that message on both the power line and RF bands. It is not an either/or situation. -Xathros

I see nothing wrong with your programs or logic here. More likely, you have a battery in one or more motion sensors that is getting low. Many of the ALL ON insteon events seem to be related to low battery conditions with motion sensors. -Xathros

I'm not sure that I fully understand the exchange in the OP but it looks like there may be a session cookie involved which I believe is not supported by the ISY. -Xathros

Interesting results. I knew things got queued up on the ISY but that test really shines a light on it. -Xathros

Since the notification is the same for both, why not just include both addresses in the Email 1 group and send once ? -Xathros

Since you are well covered by access points, you might try putting the PLM behind a Filterlinc to force it to use RF only. See if that brings up your reliability any. -Xathros

Yes. That is all you should need. -Xathros

Create a program as follows: Program: GarageAutoLightPrevent If Control 'Garage Lights' is Switched Off Or Control 'Garage Lights' is Swiatched Fast Off Then Wait 5 minutes Run Program 'GarageAutoLightPrevent' (Else Path) Else Use the True/False state of this program in the conditions for your garage lights program: If From Sunset +X Hours to Sunrise (next day) And 'Dark Downstairs however you determine that' And GarageAutoLightPrevent is False Then Set scene 'Arriving Home' On This will prevent the garage auto lights from operating for 5 minutes after you turn the garage lights off. Hope that helps -Xathros

Princerichy- As Michel said above, secondary KPL buttons need to be placed in a scene and the scene used to turn them On/Off. Setting the backlight level (usually done on the primary node) affects the On and Off brightness levels for ALL buttons of the KPL. It does not turn on/off individual buttons - only sets the KPL's 2 brightness levels globally. -Xathros

Hybrid scenes (Zwave + Insteon) are not yet supported. UDI is working on this. -Xathros

amp; is the URLEncoded form of & You should be able to replace "amp;" with "&" as long as you have the EncodeURL box checked. -Xathros

Remove the colon from the end of the path line, increase the timeout to 1500. -Xathros

Anytime. Happy to help.

Add the KPL buttons A, B, C & D to this scene as responders too. Correct. Only the buttons are scene members here. This is the expected behavior. As expected under program control. There will be delays as the program executes and has to wait for insteon commands to process. The solution is in #1 above. Certainly possible to do exactly what you want. Hope this helps. -Xathros

Your choices are: Add the ISY994 to the Java exception list as above or upgrade the firmware to 4.1.2 or higher. I would recommend not upgrading to 4.2.2 (current beta) and instead wait for 4.2.3 hopefully this weekend as there are a couple of known issues with 4.2.2. Adding the 994 to the exception list is probably the easiest thing to do for the moment. -Xathros

Sorry. Assumed from Brian's post that it was a 99i. At least that gave a description of Why this happened. -Xathros

I don't believe that any of the KPL's require a current through the load as all of them have a neutral wire unlike the 2 wire Switchlinc dimmers. The KPL is powered from line to neutral regardless of whether or not there is a load attached. There should be NO current passing through the ground wire! The KPL should operate just fine without the ground connected however this is against code for safety reasons. -Xathros

Add ISY-99 to exception list with Java 1.7.51+ With the advent of Java 1.7.51 and up, Java applets are now required to contain a manifest file. Those that don’t are now not allowed to run unless you make a security exception for the applet. UDI has released newer firmware (4.1.2) that includes a manifest file and meets the new requirements. The ISY-99 series is not receiving firmware updates after firmware 3.3.10 as it has run out of room for the larger code in the newer firmwares. If you have decided not to upgrade to the ISY-994 series controllers, you will need to work around the new Java requirements and add an exception for your ISY-99i. Here is how to make that exception. MAC: Open System Preferences and double click the Java icon. In the Java preferences, click the security tab. Click “Edit Site List†Click “Add†and enter the URL for your ISY. Acknowledge the warning that this poses a security risk by clicking “Continue†Click “OK†then “OK†and close the Java preferences window. Windows: Open the Windows Control Panel Double click the Java control panel applet. Click the Security tab Click the “Edit Site List…†button. Click the “Add†button and enter the URL for your ISY-99i series controller. Click “OK†and close the Windows Control Panel†This should get you back up and running until you can upgrade to an ISY-994 and the newer firmware. -Xathros

Anytime. -Xathros Sent from my iPhone using Tapatalk

Some cfls have been problematic. Some only after they have aged for a while. Spme have been fine. Try unscrewing the garage cfls and test. -Xathros Sent from my iPhone using Tapatalk

No problem in that respect. Only issue is increased traffic on the powerline. -Xathros Sent from my iPhone using Tapatalk

What make/model is the door opener. I think that we need to verify that it can be operated with the IOLinc connected to the opener directly. -Xathros

Simply unplugging suspect devices and testing will usually lead to identifying problem devices. Often however, it is a combination of several devices that add up to being a problem making items harder to identify. Noise filtering power strips, UPS's AV equipment, chargers etc are all likely culprits. Line of site distance in this case is meaningless. The IOLinc is powerline only device so RF distance means nothing here. What else is on the garage ceiling circuit? How far by wire is it from the PLM? Is it on the same electrical phase as the PLM? Do you have a phase bridge solution in place? Create the following query program and set it to run at startup. If Then repeat every 5 minutes Set 'Garage / Garage Door IOLinc - Sensor' Query Else No problem. As always, happy to help. -Xathros

Since the hallway switch is the load control for the hallway light, anything that you do at that switch is going to affect the load, On, Fast On, Fade Up etc. To avoid that, we either have to take the load off of that switch and move it to something like a micro module or deal with this scenario programmaticly. One idea may be to use adjust scene to set the local onlevel of the hallway light to 20% between certain hours. Say 2 hrs after sunset to 1/2 before sunrise (next day). This way turning on the switch during these hours will only bring the hallway light up to 20% during the rest of the day, adjust to 100% or whatever level you like for daytime hours. Then have a program watch the hallway control during those hours and respond by bringing up the bathroom lights to 20% if the hallway is turned on between the dark hours. Have another program watch the hallway switch for fast off and turn off the bathroom scene when it sees a fast off from the hallway. This is not exactly what you wanted but close and does not require any additional hardware and avoids the hallway light getting brighter than 20% during the dark hours.. -Xathros