LeeG

“I have four buttons tied to a FanLinc (Fans High, Fans Medium, Fans Low and Fans Off). Since the Fans Off button turns the fans off, I'd like the button to turn off as well (or never come on in the first place).†Set the Fans Off button to non-toggle Off mode. The button LED will blink twice when pressed and turn Off. It will always issue an Off command in non-toggle Off mode. “I have an "All On" button that turns on many many lights and fountains in a scene. I like my KeypadLinc to act as a status dashboard telling which components are on. Since the "All On" is not tied to a single device, I'd just as soon have the button LED turn off (or never come on).†Set this button to non-toggle On mode. The button LED will blink twice when pressed and turn On. Not what you want for the button LED but this will have the button always send a On command. Write a simple Program that says If Control ‘buttonx’ is switched On Then Set Scene ‘xxxx’ Off. Scene ‘xxxx’ has this KPL button as a Responder. “Similar to the point above, I have an "All Off" button that I would like to turn or keep off. Same reasoning as above.†Set this button to non-toggle Off mode.

KeypadLincs with firmware below v.40 do not support turning a Secondary KPL button Off with an On command (0% On Level).

You are absolutely right. A Program with a From/To time trigger is invoked twice. The Program is triggered at the From time, the If is True so the Then clause executes. The Program is triggered at the To time, the If is False so the Else clause executes.

There is no conflict between the two Programs. The first Program Else executes at Sunrise and turns the device Off. The second Program Else executes at 11PM and turns the device Off. Even if the two Programs were physically running at the same time only one Program can actually be executing statements at any given time. The ISY would send the commands to the device through the PLM which can only handle one Insteon command at a time. If I have missed the point please post back.

The PLM can fill with duplicate and no longer needed link records when there is active Scene/device management activity. There is a Tools | Diagnostics | Show PLM Link Table with a Count after the current records have been displayed. The max count for a 2413 PLM is 992 link records. The issue with this is any inbound Insteon activity that reaches the PLM during the Show process will produce a false high or low link count. The Show PLM Links Table and Count have to been done 3-4 times to insure the Count is the same to be sure the count is accurate.

When a device reliably turns On/Off from the Admin Console but does not report state changes most likely issue is link records missing in the PLM or the device. I would start with a File | Restore Modem (PLM) which will rebuild the PLM link database. If problems remain right click on failing device node and select Restore Device. If this is needed it will have to be done for each failing device. PLM link database is the most likely cause since it affects many devices.

See if the Admin Console shows the device(s) turning On. With power outages the PLM may have lost link records such that the ISY does not know the devices are changing state. If state changes are not being seen issue a File | Restore Modem (PLM) to rebuild the PLM link database.

Check Programs | Summary for another Program that is being triggered at the same time. Disable the posted program and see if light comes On anyway. Click Help | About, what is displayed for Firmware? what is displayed for UI?

The posted Program should not produce the stated actual result. Most likely a Save was missed and running with older version than what is being displayed. The other possibility is the ISY does not have the correct state of one of the lights. Look at the On/Off state displayed by the Admin Console for both lights before the door is moved.

It is the Control4 that needs filtering. The Filterlinc is 10 amp max. Is the Control4 on one plug or multiple devices?

Correct on all points.

That could happen. If the Leak Sensor remains solid Wet the Heartbeat message will indicate the Leak Sensor is Wet and the ISY will mark the Dry and Wet nodes appropriately. That could take anywhere from a few minutes to nearly 24 hours which is a long time when something is continuing to leak. For those Leak Sensors that tend to cycle wet to dry to wet to dry the condition would be noted quickly once power came back and all the equipment came on line. I would put sensors like that on my security system which would not be affected by power outage.

larryllix I think it would be best to look at the insteondetails.pdf document on insteon.com web site. It goes into Insteon in some detail. It may generate more questions but that is a good place to start if you want to understand Insteon and how the pieces work together. The document was updated recently with the latest changes in the Insteon protocol. Most folks don't care to go that deep but your interest seems deeper than most care about.

From an Insteon perspective there are many Scenes involved even though there is only one ISY Scene. The ISY Scene Name is used by Programs and can be controlled with from the Admin Console. This is one Insteon Scene with the PLM being the Controller. Within the one ISY Scene definition, there can be additional Controllers. For example, multiple KPLs can be added as additional Controllers. Each of these additional Controllers represents an additional Insteon Scene. SceneABC - PLM is Controller - one Insteon Scene KPL1buttonC - Controller - one Insteon Scene KPL2buttonC - Controller - one Insteon Scene This single ISY Scene definition represents three Insteon Scenes. That is why each Controller can have a different set of Responder On Level and Responder Ramp Rate values as each Responder stores these values keyed to the respective Controller Insteon address. Be careful using the word Group. When reading hardware manuals (not external Quick Start or User Guides) the term Group is used to describe a collection of Insteon devices. The term Group in a hardware manual is synonymous with the end user term Scene. From an engineers perspective they are called Groups. From a normal Insteon users perspective they are called Scenes. Group and Scene mean the same thing.

Exactly right. Battery devices sleep (turn Off RF circuitry) to extend battery life. This makes it impossible for the ISY to Query a battery device to verify its existence. When the condition being monitored changes that state change will be sent to the ISY. For a Leak Sensor the most likely change will be a Heartbeat message.

salex319 Before investing time working on the power for the wireless On/Off module, I don't think that module is doing anything to help the I/O Linc. The I/O Linc is powerline only. The wireless on/off module is RF only. Messages to/from the I/O Linc travel over the powerline. Messages from the wireless on/off module travel over RF to some Dual Band device. Messages sent to the I/O Linc will be transmitted over RF by some Dual Band device but have no way of getting from the RF only wireless on/off module to the powerline and the I/O Linc. The reverse, powerline messages from the I/O Linc will not be seen by the wireless on/off module so it will not be sending messages from the I/O Linc over RF.

"Oh and the ISY Admin Pgm doesn't respond to my trigger input but does respond to the manual trigger." What voltage is applied to the I/O Linc Sensor? The Green LED turning On does not mean the Sensor is actually On enough to send a command. It sounds like what is controlling the I/O Linc Sensor is not applying I/O Linc GND to the Sensor Input.

The Green LED on the I/O Linc at the wire connections should turn On/Off as the I/O Linc Sensor turns On/Off. If the Green LED does not turn On/Off look at what is controlling the I/O Linc Sensor input. If the Green LED turns On/Off does the I/O Linc Sensor node "Current State" column cycle On/Off. The Sensor node may be On when the Green LED is Off depending on what is controlling the Sensor. If the Current State column does not cycle On/Off when the Green LED does there is a comm issue between the I/O Linc and the PLM.

Independent of the RF question (2412 PLM had no RF) the powerline should reach at least some of the devices. Describe the electrical environment and physical environment where the ISY and PLM are powered. What is the PLM plugged into. What else is powered from the circuit supplying the PLM. Are noise reducing extensions in use. Is there an unfiltered UPS in use. Things such as that.

I suggest talking to Smarthome about the lack of interaction between the Access Points and the PLM. I run with a v.9B PLM and it beeps but the LED does not blink while in 4 tap test mode.

Newer I2CS devices must have a link for the PLM to read/write the device. The device indicates if that link is missing and the Restore Device puts that link back. Would need to see an event trace at LEVEL 3 of the Restore Device to see what the issue was.

For Status "> Off" and "not = Off" would mean the same thing. For the other variations they could be different things. For example ... If Status 'xxxx' > 20% versus If Status 'xxxx' not = 20% produces different results. The > 20% means the On Level has to be greater than 20% to be True. For "not = 20%" means it is True if the On Level is below or above 20%.

bigscience A device can be factory reset at the device without removing it from the ISY. Do the factory reset and then do a Restore Device to rebuild the configuration and link database.

bigscience Are you asking in the context of "If Control" or "If Status"? It makes a difference. larryllix You might want to wait until you have an ISY and have a chance to actually work with one. Some of the posted information in this topic and another is not correct.

"Will both timers work?" Both Programs will run. The first program dims the device (to Off?) in 5 minutes. If the first program turns the lamp off the second program will send another Off after the program has run for 10 minutes. "Will the latest timer cancel the previous timer?" No, not with the information provided. "What will happen?" Both programs run to completion. "Are timers dedicated to each device and only one can be running at any given point in time? or Are timers just freely allocated timers and control programme execution? If so, is there a quantity limit on timers running concurrently?" There is no 'timer' type program. The programs perform as they have been coded. One could cancel the other if coded to do so. They may do nothing to each other as I have assumed with the previous answers.