LeeG

Sorry, I understand now. Sounds like a Java issue on the Mac. I'm running 3.3.10 with Java 7 update 13 on windows. Perhaps someone running on a Mac can jump in and confirm what happens. That is the correct sequence.

Left click the KeypadLinc Primary node in the My Lighting/ISY Lighting tree. At the bottom of the right pane is a Buttons Toggle Mode button. Click that button which displays Set Button Toggle Mode popup. From that popup any of the KeypadLinc button toggle mode can be set.

"Is it possible to have a single SwitchLinc Dimmer control two scenes?" No. Insteon does not support any Controller node (SwitchLinc Dimmer in this case) being assigned as Controller for more than one Scene. Each Responder has a link record telling it how to respond to each Controller. This is keyed to the Controller Insteon address and Scene (Group) number. There is no facility to assign multiple Scene numbers for one Controller node. A KeypadLinc has a unique Scene (Group) number for each KPL button. A SwitchLinc paddle can have only one Scene (Group) number. Triggering a Program with the paddle press is the mechanism. Be careful though because it can take some time for the Scene the SwitchLinc paddle is controlling to complete all the Scene commands sent by the SwitchLinc. The majority of these commands are redundant and produce no visible effect. However, if there is a temporary glitch on the powerline it may be necessary for the SwitchLinc to retry one of those commands which makes them no longer redundant. The conflict comes if the Program immediately issues a command to turn another Scene On. Insteon allows only one Scene in progress at a time. The Scene command issued by the Program will cause the SwitchLinc to terminate the Scene it is controlling. Depends on how many Responders are in the SwitchLinc controlled Scene and whether the powerline has some problems. If you find the Responders controlled by the SwitchLinc Scene become unreliable when sending a Scene On from the Program, issue a Wait of 1-2 seconds in the Program before sending the Scene On.

Try the Leak Sensor near one of the Access Points. Use New INSTEON Device, enter Insteon address, Name of choice, leave Device Type set to Auto Discover. BEFORE clicking Okay, put Leak Sensor into linking mode with Set button press until LED blinks continuously. Then click Okay. Another option is to temporarily move an Access Point to the same plug point as the PLM and repeat the above. Have the Leak Sensor near the Access Point moved to the PLM plug point. If it does not work there either the Access Point, PLM or both need to be upgraded. When you say it fails to link, what is the specific symptom?

The shorter the better. That is a Serial Port connection, rather than an Ethernet port connection. 50' is considered the max for a Serial interface but something on the order of 3-4' is the normal arrangement.

The blank means the Motion Sensor has never reported On or Off for the Dusk-Dawn node. Could be a defective Motion Sensor. Could be a PLM link database is full, not having room to store the responder links for Dusk/Dawn and perhaps Low Batt. The ISY primes the Low Batt node with Off as it may be months before the MS would report status for that node. Could run a Show PLM Links Table followed by a click on Count when the display completes. The maximum in a 2413 PLM is 992 links. The challenge with Show PLM Links Table is any Insteon traffic reaching the PLM while the Show PLM is running will produce a false high or low link count. For the link count to be considered accurate the Show PLM Links Table followed by Count must be run 3-4 times to verify the Count is the same across multiple runs. Could also put the Motion Sensor into link mode and run a Show Device Links Table followed by a Compare to see if all the link records were written into the Motion Sensor. Actually that is a better thing to do before running a Show PLM Links Table.

It is usually best to use Auto Discover so the ISY obtains the device firmware level when it is added. Is the 2441ZTH being used on battery or external power supply? The temp has to change by 2 degrees if memory is correct before the 2441ZTH will send a value. It does this to save battery life. I run mine on an external power supply so its battery limitations are not fresh in my mind. Take a look at the 2441ZTH user guide. I think it spells out the differences between running on battery versus power supply.

Correct. A second PLM cannot be added to the same ISY. If actually beyond the PLM capacity and not just full because of deleted and duplicate links in the PLM, some Scene management will open up additional free space. Multiple Scenes with nearly identical responders can be combined to reduce the number of Scenes. With a little ingenuity the number of PLM links can often be reduced. If the solution cannot be found there an additional ISY can be used, where devices are split between the ISYs. The challenge is to split the devices so there is no need to control a device from both ISYs.

The ISY Links Table is simply the link records the ISY thinks should be in the Leak Sensor. They should and do match what is in the Leak Sensor. They are not the link records in the PLM. A Show PLM Links Table displays the link records in the PLM. The New INSTEON Device wrote Responder link records into the PLM. If the PLM does not have Responder link records it is likely full. I full PLM link database can usually be corrected with a Restore Modem (PLM) which compresses out any deleted and duplicate records. Sun 02/10/2013 07:39:55 PM : [MNG-LNK-RSP ] 02 6F 41 A2 01 21 7D D7 10 08 3E 15 Sun 02/10/2013 07:39:56 PM : [MNG-LNK-RSP ] 02 6F 41 A2 02 21 7D D7 10 08 3E 15

The ISY sets the Dry node to Off when the Leak Sensor sends a Wet On message. The ISY sets the Wet node to Off when the Leak Sensor sends a Dry On message. The Leak Sensor does not send an Off command to the Dry node or the Wet node which is why a directly linked device does not turn Off. I suggest Deleting the Leak Sensor from the ISY. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Use New INSTEON Device, enter the Insteon address of the Leak Sensor, Name of choice, Device Type set to default Auto Discover. BEFORE clicking Okay, press Leak Sensor Set button until Leak Sensor LED blinks continuously. Now click Okay on New INSTEON Device popup. Post the event trace when the add completes. That will show the PLM commands used to create the PLM link records.

What does Help | About show for Firmware and UI levels? What is being entered in the Device Type field when the Leak Sensor is added to the ISY? Note that the linked light not shutting Off is normal. The Leak Sensor only sends On commands. It does not send Off commands as the Leak Sensor changes from Wet to Dry to Wet. Take a look at the spec’s section of the Leak Sensor sales page. It documents the commands the Leak Sensor sends (On command only).

The PLM link records must be Responder link records which start with A2. Have no explanation for what you are seeing in the PLM unless some manual linking was done. The PLM will not pass inbound messages from the Leak Sensor to the ISY application without A2 Responder link records with the Leak Sensor Insteon address 873 : 0369 : A2 01 21.7A.CC 10 08 3E 874 : 036A : A2 02 21.7A.CC 10 08 3E

Could be a finger check but the link records are not correct. They should be 0FF8 : E2 01 19.70.06 FF 1F 01 0FF0 : E2 02 19.70.06 FF 1F 02 Also the PLM links must be Responder links A2 01 ...... and A2 02 ...... When the link records are correct be sure the Leak Sensor is near a Dual Band device. After the Leak Sensor has been successfully added a tap of the Set button will alternate between Wet and Dry messages which can be traced with the Event Viewer set to LEVEL 3.

What is the Dusk/Dawn light level set to? Are the Motion Sensor jumpers being used? If so which jumpers are in place? Note that the ambient light level has to exist for more than 3.5 minutes before the Dusk/Dawn node will change state.

The Program has no statements to turn the devices Off. The Then clause is invoked at the From Time because the If evaluates to True. The Program is triggered again at the +2 hours invoking the Else clause because the If is now False. The current time is outside the time range, albeit seconds outside the range, which is why the If is False driving the Else. The Else contains the statements to turn the devices Off. If From Sunset + 45 minutes For 2 hours Then set 'Family room lights' 55% set 'Kitchen lights' 55% Else set 'Family room lights' Off set 'Kitchen lights' Off

Posting in the forum is a good idea. Lots of great folks who are very willing to assist. Just not much chance installing 3.3.10 on top of 3.3.10 has much exposure.

Understand. I do not know what the recover procedure should be because I do not know what is actually wrong with the ISY. If you cannot ping it you cannot telnet into it to format the SD card and I don't think the card needs formatting anyway. This may be one of the very few times an ISY factory reset is appropriate but I don’t know that for sure. Did you open a Ticket with UDI support?

I think you wanted the If logic to say if all the first three conditions exist Or the last statement condition exists. ( Status 'Garage door' is Off And Status 'Kitchen Keypad.1' is Off And Status 'Living Room' is Off ) Or $Honeyhometrue is 1 Without parens that is not the result. The last Variable condition is Ored with the Statement above it And Status 'Garage door' is Off And Status 'Kitchen Keypad.1' is Off And ( Status 'Living Room' is Off Or $Honeyhometrue is 1 ) The Ored statement does not produce the effect needed without parens. Add parens to obtain the desired combination of conditions. Maybe this is what you want?? If From Sunset To 9:00:00PM (same day) And ( ( Status 'Garage door' is Off And Status 'Kitchen Keypad.1' is Off And Status 'Living Room' is Off ) Or ( $Honeyhometrue is 1 ) ) Then I think the Variable was added to avoid the reevaluation results when the Wait is executed. Easier to accomplish this by breaking the logic into two Programs. Have the Then in the first Program Run Program 2 which has the Then logic of the existing Program and nothing in the If clause. That way the changes the Then clause are making to the If conditions do not cause a reevaluation. The Variable can be removed completely if done that way.

What ISY firmware are you using. It is supported on 3.3.10 and I think that support was there a few images before. Click Help | About. What is displayed for Firmware and UI?

I think we should wait until UDI goes over this topic later tonight or tomorrow. Can also open a ticket but not sure that will get any faster response on the weekend. Once on 3.3.10 (RC7) Beta, that is the Official release. I don't know the implications of installing 3.3.10 on top of 3.3.10. Never tried that before. There are some activities that happened when going to 3.3.10 initially. Not sure the implications of making those updates on top of the same updates. Not something that is normally done so any issues may not be known.

I don't think any corrective action should be tried until the ISY is observed locally. Besides if you cannot contact it remotely what action could be taken. It is hard to develop an action plan without knowing the current conditions, more than it cannot be accessed remotely. For all that is known now is it could be accessed locally. It is all specutation at this point.

The If clause needs parens to get the order of precedence correct. Not sure what is supposed to be Anded together and what is should be Ored to what. The first set of statements before the first Wait change the conditions the If is checking. This means the If will be reevaluated as soon as the Wait is executed. For example, Set 'Kitchen Keypad.1' 70% will make the Anded statements False because Kitchen Keypad.1 is no longer Off. That will cause the Else clause to execute. Also need to know if the Variable is an Integer or State Variable. If a State Variable changing its value will cause the If to be reevaluated when a Wait is encountered.

The manual override should only happen between Sunset and 11PM? That is the effect of using the Program True/False state and that can be impacted by whether the garage light was already on at Sunset. Also the Variable is not used in any of the Programs that actual control the light so it would seem the latest Program is not posted. Start with If control garage light is switched on and control garage light is not switched Off then $LightsManual = 1 else $LightsMaual = 0 Now the Variable reflects true manual switch operation. It should be an Integer Variable. It can now be used to prevent the automatic turn Off at 11:33 PM If time is 11:33 pm and $LightsManual = 0 then set garage light off

If the ISY is power cycled the only LED that ever lights is the PWR LED? It sounds more like the IP address may have changed. Does the ISY respond to a ping that stops responding when the ISY is powered down?

There are no embedded Ifs. What can be done is have Program 1 Then clause which runs when Program 1 If evaluated to True perform some function and then invoke Program 2. Program 2 contains additional If conditions which will be evaluated only when Program 1 If evaluated True. Programs can be cascaded in this fashion to accomplish what embedded Ifs would do. Difficult to evaluate pseudo code results. Right click Program name, select Copy to Clipboard, post actual Program to forum which as much detail as to what is desired and what actually happens.