LeeG

First thing is to determine what the problem is. Does the Last Run Time indicate the Program was triggered when it should have. This determines whether the issue is something that prevents the Program from running to some action (Scene or Direct command) did not function as expected. No sense restoring devices that did not respond if the Program did not trigger. It is also important to know if the Scene Test is successful. If the Scene Test is successful there are not link record issues.

Looking at the IRLinc user Guide it indicates the I-L buttons send On only, not Off. Scene Activation Buttons These buttons provide smooth and simple scene transitions for when a scene doesn’t need an OFF command • Tap to activate a scene • Press & hold to toggle between brightening or dimming the scene The A-H buttons send On and Off. As I mentioned initially I do not use the IRLinc Rx. What documentation indicates I-L can be defined to toggle On and Off?

The ISY does not restore links on it own initiative.

Does the Last Run Time column indicate the expected time the Program should have been triggered? If so, with the True Status, there could be a comm problem developing, or some of the devices have lost link records. Right click the Scene name, select Diagnostics | Scene Test. If the Scene test is successful then there is likely a comm problem. If the Scene test fails it could be a comm problem but more likely a link record problem. Try a Restore Device on a device that fails the Scene Test and run Scene Test again.

An ISY Scene does not require an explicit Controller. The ISY PLM is the default Controller for all ISY Scenes. Can you post the Program that did not run at Dusk. If the Folder condition was True there is some issue with the IF conditions in the Program.

When statements after the Wait do not execute the condition the If is checking has changed before the Wait has expired. Perhaps the ELK Output is momentary. It turns On which triggers the Program but then turns Off. For sure the If condition has changed for some reason before the Wait expired.

I do not use the IRLinc Rx but I think it functions like any other Smarthome "Controller Only" device. The IRLinc button status is simply a reflection of the last command received from the IRLinc. Turning an individual responder device Off or On has no affect on the Controller of the Scene even if that device does have Responder capability (which the IRLinc Rx does not). This is not unique to the IRLinc Rx. Insteon architecture does not propagate a command sent to a Responder to other devices that may be linked with to that Responder. Again, this is consistent with all Insteon devices, not something unique to the IRLinc Rx.

“So your program would force a toggle and only use one button (such as button a) from both remotelincs.†My example handles an On or Off from a single button. It allows all the RemoteLinc2 buttons to operate in toggle mode. Unlike a KeypadLinc where each KPL button can be set to one of the three toggle modes, all the buttons on a RemoteLinc2 must operate in the same mode. “My program would force an on from both remotelincs if button a is pressed and force an off if button b is pressed.†An ISY Program cannot force any command from a RemoteLinc2 button. Your example was pseudo code, missing some operative aspects of ISY statements. Not possible to know what commands were going to handled from the RemoteLinc2 buttons “The pro for my program is it would be an on/off instead of a toggle. The con of my program is it would require the use of two buttons.: Correct? It would require two buttons. Unless the RemoteLinc2 is configured for 4 Scenes where the left button in a given row is Off and the right button is On, if the RemoteLinc2 is in 8 Scene mode each button will toggle On/Off (unless of course the entire RemoteLinc2 is put into one of the non-toggle modes).

Response to two posts back Yes. The If statements require checking for specific commands or specific status, however the concept is valid. Remotelinc2 can be set to 4 Scene mode where the left button sends an Off and right button sends an On (or maybe that is backwards). Like all things with the RemoteLinc2 this would affect the entire device reducing from 8 different Scenes to 4 different Scenes. They also have a single paddle RemoteLlinc2 if all that is anticipated is controlling the bedroom light. Response to one post back I have multiple RemoteLinc2's, A, B, C, etc. The B indicates RemoteLinc2 B. My Program example handles only 1 RemoteLinc2. Add checks for the same commands from another RemoteLinc2 if both RemoteLinc2's should be processed the same way.

Self-help is the good way. Wish more folks would try it. Even if not successful in the specific endeavor much is learned every time something new is attempted. The ISY User Guide covers the basics of most (maybe all) of the Program statements. Folks on the ISY forum are most helpful.

Program CycleLight2 MUST BE DISABLEd so it does not trigger again when it changes the Status of the LampLinc. CycleLight1 If Control 'RemoteLinc2 - 8 Scene - B / RemoteLinc2 - 8 Scene - A' is switched On Or Control 'RemoteLinc2 - 8 Scene - B / RemoteLinc2 - 8 Scene - A' is switched Off Then Run Program 'CycleLight2' (If) Else - No Actions - (To add one, press 'Action') CycleLight2 If Status 'LampLinc DB' is not Off Then Set 'LampLinc DB' Off Else Set 'LampLinc DB' On

In some sense it is a moving target since SmartLabs is expanding the Dual Band device inventory. What is fully supported today may not be fully supported tomorrow. If you know the cat/subcat values of the devices they now have I can check against the 3.2.6 device list. 3.2.6 is the latest ISY firmware which is going on 4 months old. The next ISY release may change the equation and SmartLabs may release more Dual Band types the week after the next ISY release is available. If you don't know the cat/subcat values what are the specific device types that were not supported a year ago. It is likely 3.2.6 supports more cat/subcat values than 1 year old firmware.

That is the nature of a RemoteLinc2. Being a battery RF device it goes to sleep immediately after pressing button to extend battery life. It cannot receive any command while it is asleep to change the button behavior. Also there is no command to change the button behavior because it would be useless in a device that is asleep most of the time. One solution is not to link the RemoteLinc2 buttons in a 3 way configuration. Trigger a Program based on a button press, On or Off, and have the Program toggle the bedroom light On and Off. Or pay attention to the color the RemoteLinc2 LED flashes when the button is pressed. Or put the RemoteLinc2 into non-toggle On mode so it only ever turns On the bedroom light. That puts all the RemoteLinc2 buttons in non-toggle mode so there are negatives to all alternatives that use a RemoteLinc2 in a 3 way. Pick your poison. Or use a KeypadLinc in the garage where the button LED would indicate the state of the bedroom light.

If the lights are connected to the Red load wire on the KeypadLinc what you describe is the expected result. When Main LED is On (the KPL load is On) pressing the Main button directs the KPL to turn the load Off. That happens immediately, much faster than the Program can be triggered and change the On Level to something else. Try changing the Local Ramp Rate to something slower, a few seconds to start with, perhaps slower will be needed. That way the lights will begin to fade down to Off slowly. The Program will have a chance to trigger and change the On Level to 99%. The down side is the load will be slow to ramp on to 99%. That might be resolved by having the Program turn On a Scene which has Main as the Responder and a fast ramp rate for the Scene Ramp Rate. Another approach is to put Main into non-toggle On mode so that Main only sends On. The example did not say what is being used to actually turn the KPL load Off. Using non-toggle On mode might present a problem turning the load Off when it should be Off rather than to a different dim level.

RemoteLinc and RemoteLinc2 are Controller Only devices. Both can be added to one ISY Scene as Controllers that has the garage light as a Responder such that buttons on either device control the garage light. However, as Controller Only devices their respective status cannot be updated as say a KeypadLinc button which is both a Controller and a Responder. The "Current State" of a RemoteLinc and RemoteLinc2 button is simply a reflection of the last command received from the button. Same with Motion Sensors, TriggerLincs as they are Controller Only devices.

What would likely be helpful would be to use any documents SmartLabs (ower of the Insteon protocol) and Smarthome (retail seller of Insteon products) have to offer. The ISY supports Insteon, ZigBee and soon to be ZWave. The ISY does not own any of those protocols so it cannot be expected to provide a comprehensive reference document how all of this stuff works. Lots of information is there between the User Guide, Wiki and the forum itself but there is no "reference book" that describes Insteon capabilities. Even if someone wanted to produce such reference material SmartLabs considers much of the command and internal device information Proprietary and Confidential. Over the years information has leaked into the public domain but that does not allow an entity to ignore the general confidentiality of the information and publish a comprehensive reference document. SmartLabs does offer a $200 Developer Subscription that allows access to some of the Insteon confidential information. Have to sign an NDA to access that information so it cannot be shared with the general public. There is enough Insteon information in the public domain on the various Insteon oriented forums to get a good idea of how much of the Insteon protocol works. It does take time to read and research.

The terms Local On Level, Local Ramp Rate, Responder On Level, Responder Ramp Rate are Insteon. The Local On Level and Local Ramp Rate define what happens to the device where the button/paddle is physically pressed. The Responder On Level and Responder Ramp Rate define what happens to the linked Responder device when sent a command from the Controller device. From the example it looks like the devices are cross-linked such that tapping one device On causes that device and the cross-linked device to respond. That is all Insteon hardware/firmware reaction. All the those values can be altered by an ISY Program "before" a button/paddle is pressed. Once the button/paddle is tapped or double tapped with cross-linked devices the results have already been determine by what the respective values have been set to. You can unlink the devices by removing the devices from the ISY Scene that resulted in them being cross-linked. That would allow a Program to react to a button/paddle press and affect what the other device does as it is no longer linked as a Responder. However, where the button/paddle is pressed, if that is connected to a load, the Local On Level and Local Ramp Rate dictate. Except in the case of Fast On where the results are architected to go to 100% On at a fast ramp rate. The Fast On command is not designed to be overridden. There are techniques such as pressing an On paddle twice with 2-3 seconds that an ISY Program reacts to and does something different then a single On paddle press. Have to do the two On press actions slow enough so the device hardware/firmware does not react to a Fast On.

I believe it has been this way for the nearly 4 years I have been using an ISY. It may not be logical to someone with a programming background (which I have) but it serves a purpose. This will not be the only aspect of ISY programming that may look unusual but they all serve a purpose in an event driven environment.

That is what happens when the MorningLinc has lost its authorization link that identifies the ISY PLM as a device allowed to interface with the MorningLinc. The commands being used to interface with the MorningLinc are being echoed back from the MorningLinc with invalid cmd2 values because the PLM is no longer authorized to interface with the MorningLinc. That is why I asked if the PLM had changed. Unplug the MorningLinc to cause a permanent no response error. Then delete the MorningLinc and add it back following the Wiki instructions exactly. I recommend doing a factory reset of the MorningLinc before adding it back. This will clear the MorningLinc link database so the ISY starts with a clean device. The factory reset does not erase the link between the MorningLinc and the lockset as that information is maintained in the lockset itself.

Who knows! They don't even provide a Smarthome item number. The FilterLinc function prevents noise from reaching the powerline at the X10 frequency and prevents the X10 signal from being attenuated. The Insteon and X10 frequencies are close enough that it probably works. Purchase at your own risk. A few months ago someone was selling the plugin SignaLincs with the black external antenna. They are the predecessor to Access Points. They do not work with any of the current RF devices and do not couple Extended messages. Useless in today’s Insteon but I’m sure someone purchased them.

FilterLincs that support Insteon come in 5 and 10 amp variants. I use the 5 amp variant on a TV and the small UPS devices scattered around the house. The 10 amp variant supports a large UPS and other PC and telecom equipment. What is the item number of the FilterLinc in question?

The Ramp Rate is not affected by Local Ramp Rate or Responder Ramp Rate settings when using Fast On. The function of Fast On is to override any On Level/Ramp Rate settings, going to full On with a fast ramp rate.

Open a Ticket with UDI Tech Support. Describe how it is working, how you think it should be working. They will either fix it or characterize it as normal. EDIT: the conditions that trigger a Program (cause it to Run) are separate from evaluating the True/False of the If section. An Integer variable value change never triggers a Program (never causes it to Run) but the compare of the Integer variable value always affects the True/False result. Same with If Control, what triggers a Program is very different from what determines True/False. Ask UDI directly. That is the only answer which will satisfy the question.

That is a very good point. I had a control relay contacts problem a few years ago that kept the aux heat from coming on. During the heating season it would blow cold air for a few minutes when it switched to the defrost cycle which keeps things from freezing up. The aux heat is turned on during the defrost cycles to prevent the cold air blast. Only happens a few minutes each hour but disconcerting to be blowing AC air during the winter.

Did you check the external IP address? Not uncommon for an ISP to change that IP address. Mine wants an extra $5 a month to maintain a fixed IP.