LeeG

Not likely two MorningLincs are defective. Sounds more like something on the MorningLinc circuit.

I am sure there are folks who are happy with a 2441TH. Based on my tests at the bench I would not install one. I keep getting flooded with Humidity change messages which are reflective of the constantly changing Humidity display on the thermostat itself. There are later hardware revisions and later firmware levels. I am not going to buy a later version just to find out if they have fixed obvious deficiencies. Not uncommon to have problems in early versions of devices but a thermostat is just too important to be playing with.

Use whatever screen/window capture program you have available, saving the image as a jpg file on the PC. Below the forum post text area is a second area for attaching an image to the post.

Backlight level has to do with how bright all the KPL buttons are when On and Off. Backlight itself does not turn On or Off any KPL button. Rather than recursive invoke the blink Program from itself use the Repeat statement in the blink Program Repeat 5 times Set Scene kplbuttonh On Wait 5 seconds Set Scene kplbuttonh Off The Else clause of the Program that invoked the blink Program can issue a Stop blink Program if the blinking should stop before the 5 Repeats complete.

It is not a good idea to run Insteon commands that blink a button more than a few seconds. All that traffic can interfere with other Insteon activity. As oberkc already mentioned changing the KPL backlight level affects the entire KPL and is not what you are looking to do. Note that Secondary KPL buttons can be turned On and Off only with a Scene that has the KPL button as a Responder. The KPL does not support a Direct command for that purpose which is why the ISY does not show an option for turning a Secondary KPL button On and Off directly.

The Then clause changes the Status of the AC which causes the If to be reevaluated when the Wait is executed. The reevaluation is False which drives the Else clause so nothing after the Wait is executed. One solution is to split the logic into two Programs with the Wait and Notification in a second Program that is not affected by the reevaluation.

“Is there a way to do all 12 of these without having to write 12 programs (one for each IF statement) ?†No. Also keep in mind that if any are dimmers a test for On is looking for 100% On Level. “Second, is there a way to (in one command) read the statuses all of the devices in the household, perhaps send back as a list or something. “ The ISY keeps track of device status so there is no need to physically Query each device. It can be a challenge to implement a “save current state†and “restore current state laterâ€. In the future it is anticipated that ISY Variables will be able to store current device state and have that information used later to restore a device. If dimmers are used it gets really difficult because only ranges of On Level can be realistically checked without having to write hundreds of Programs to check for each possible On Level and then Restore each possible On level.

I just ran an Event trace while doing a Set Options | Query on an older non-I2CS I/O Linc. Nothing was written back to the I/O Linc. Are any commands issued to the I/O Linc through the ISY plugin?

Was this a Query request or a Set Options request?

Perhaps indicating what is being done in those 500 Programs would help. Switching to Variables seems like a good idea. Perhaps some of what is being implemented in Programs can be done using Scenes.

The Master SwitchLinc (which has Red wire connected to load) has to have the Local On Level and Local Ramp Rate changed to affect what happens when the Master SwitchLinc paddle is used. The Adjust Scene statement should specify the Master SwitchLinc node name in both the In Scene and Set parameters. With this combination the ISY knows to change the Local On Level and Local Ramp Rate. The current Adjust Scene statements affect what happens when the Slave SwitchLinc paddle is used to turn On the Master SwitchLinc as a Responder and what happens if the ISY Scene name is used in a Program Set Scene statement or the ISY Scene is controlled through the Admin Console. As a side note the Else clause can be used to adjust the various values at Sunset – 1 hour.

Click on the Scene name for the Fan speed High. Check the Responder On Levels for the Secondary buttons that should turn off. Are they set to the required 0% On Level. Each Controller establishes a unique set of responder values. The responder values when the KeypadLinc button is Controller must be correct. However, the PLM is the Controller device when turning the Scene name On/Off which is what MobiLinc uses. Also for the PLM as Controller to turn Secondary buttons Off with a Scene On the KeypadLinc must have firmware v.40 or higher. If the KeypadLinc has firmware before v.40 than extra work is required. ISY Programs have to be triggered when the PLM as Controller turns On a particular KPL button. The ISY Program then issues a Scene Off for a Scene that has the KPL Secondary buttons that should be Off. An ISY Program and Scene are required for each KPL Secondary button that is a Controller if the KPL firmware is below v.40

I don't remember other reports like that. However, 3.2.6 was not processing the Set Options correctly for I2CS I/O Lincs. The 3.3.4 release (or maybe 3.3.3) corrected that problem. It is possible that the ISY had one of the Momentary mode indicators stored from 3.2.6 that was not reflective of the actual settings. I checked my I2CS I/O Linc which indicates Latching Mode and is operating in Latching Mode but that may be from my testing of the fix when it became available.

That is a problem. The ISY is not aware of the Set button links in the KeypadLinc and the FanLinc. The links will eventually be overlaid or deleted in one device or the other. Factory Reset both the KeypadLinc and the FanLinc followed by Restore Device to both devices. That will clean up the link database in both devices. Then define ISY Scenes to create the necessary KPL button to FanLinc relationships. Regarding MobiLinc that is correct. Secondary KPL buttons cannot be controlled individually. Even if the Controller was a SwitchLinc turning the SwitchLinc On does not turn on the SwitchLinc responders. The Scenes will be turned On/Off with MobiLinc when it is aware that the buttons are Controllers in ISY Scenes

Yes. How did you create the relationship between the various KPL buttons and the FanLinc?

The Scene which has KPL button A as Controller with Fan speed High, KPL buttons B,C,D must be Responders with the Responder On Level set to 0%. When button A is pressed, buttons B,C,D turn Off. The Scene which has KPL button B as Controller with Fan speed Med, KPL buttons A,C,D must be Responders with the Responder On Level set to 0%. When button B is pressed, buttons A,C,D turn Off. And so on for the Scenes with buttons C and D as Controllers.

Kidde makes Relay Modules (xx120X) for connecting to external devices. Looks like one would be needed for Smoke and one would be needed for CO.

I have no issues with the performance of the ISY. Been using them for several years as a Controller of the Insteon devices in the main house, detached garage and dock (some 50+ devices, 125+ nodes). Another is the driver of a significant Insteon device test bed. I do not have 300 Programs and the constant updating that has been raised as a concern.

johnnyt You will find the event log much easier to read when using WordPad rather than NotePad.

Using separate 10k ¼ or 1/2 watt resisters, connect I3 (AN1) and I4 (AN2) to the EZIO2X4 +5V. These are pullup resisters. To control the Inputs connect each to the EZIO2X4 Gnd through a dry contact switch or c-form relay.

What ISP is being used?

The leak sensor spec indicates this is correct. When the leak sensor goes Wet it turns the Wet node (Group 2) On. When it goes Dry it turns the Dry node (Group 1) On. There is no Off indicated for either node (Group). EDIT: the TriggerLinc functions the same way when operating in two Scene mode. It sends an On command to one node when the TriggerLinc turns On and sends an On command to the other node when the TriggerLinc turns Off. It does not send an Off command to either node.

Please do. It would be good to know for sure. The Mighty Mule uses a 4 bit code to identify transmitter and receiver. The Dakota Alert uses a 10 bit code. I don't see how the EZSnsRF could look at a 4 bit code and resolve it to the expected 10 bit Dakota Alert identifier.

The EZSnsRF works with the Dakota Alert 3000 series wireless devices. Nothing in the Mighty Mule documentation mentions compatibility with Dakota Alert technology.

A KeypadLinc has either 5 nodes (6 button KPL) or 8 nodes (8 button KPL). There is a + sign to the left of the Primary node in the My Lighting tree. Click the + sign to expand the KPL definition showing all the KPL nodes. A Factory Reset is a must. Or the device can be Deleted from the ISY and added back with the 'erase existing links' option. The ISY is not aware of manual Set button links. They will get deleted or overlaid leaving broken/half links which produces unwanted results.