LeeG

You can use the Then clause to set one group of temp settings and the Else clause to set another group of temp settings. If more than two groups of settings are desired more than one program is required. If From 9:00:00AM To 5:00:00PM (same day) Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') The Then clause would contain the temp settings for 9 AM to 5 PM. The Else clause would contain the temp settings for 5 PM to 9 AM.

"1st question, it seems that when I move the EZSnSRF to a different electrical outlet (trying to get the best range to the motion sensor which I have located outside), I lose the communication from the motion sensor to the EZ and have to manually set it back up in ISY (add sensor to EZSnSRF). Is this normal?" No, I suggest moving it back to the outlet were things were working. The EZSnsRF information is stored in non-volital memory. Unless you factory reset the EZSnsRF accidently during the move the drop in power should have no affect. "What if there is a power outage, will the EZ and the motion lose communication and have to be set up again in ISY?" It should not lose configuration data. The affect of altering the Dakota Alert motion sensor should really be taken up with Dakota Alert. Using a Dakota Alert Universal Remote I triggered the EZSnsRF from 50’ through 2 interior walls. Walked outside about the same distance with the same results. Unplugged the EZSnsRF for 60 seconds. Universal Remote worked okay after EZSnsRF had initialized. You may have other issues, unreliable comm from the EZSnsRF plug point, low battery in the motion sensor. What type of wall material does the motion sensor have to transmit through.

Sounds like the variable being used is an Integer variable which does not trigger a Program when the value changes. Does not affect the Cool Program as it is triggered on a time basis. The Vacation Mode Program has only one thing in the IF which is the check of the variable value. The variable must be a State variable for that Program to be triggered when the value in the variable changes. The Status of a Program True or False indicates whether the Then clause or the Else clause last ran. Since the two programs that set the variable values have no If section only the Then clause will ever run with the result of True Status unless the Else clause is explicitly told to run.

ScottAvery Based on the results of adding 200' I now suspect it has more to do with the number of Insteon devices on the circuit the MorningLinc is plugged into and where the MorningLinc is relative to those other devices. Best to move the MorningLinc to the end of the circuit with many Insteon devices on it. Each Insteon device is a repeater so the more the Insteon devices on a particular circuit the better the signal strength and the greater the delay in getting to the last device. The amount of time is milli-seconds but that is all it seems to take. Thanks for that information. It may be helpful to someone else with the same problem.

I believe this is an I2CS device. You can see from the Show Device and Compare that the link database is nothing like it should be. The link records that were actually created do not match the commands that were traced and posted earlier. The only way to know for sure is to move to 3.2.1, delete the v.41 SwitchLinc and add it back under 3.2.1. After Deleting the device I suggest doing a factory reset of the SwitchLinc before adding it back under 3.2.1. That way the link database will not have anything left over from the activity on 3.1.17. An event trace of the device add under 3.2.1 will confirm the device is I2CS. Could also do a Show Device Links Table and Compare after adding the SwitchLinc under 3.2.1. If the links table is bad on 3.2.1 the device is defective which I do not believe for a second. EDIT: note the F8, F9, FA, FB etc in the first link record displayed. That is the classic I2CS result when the I2CS protocol is not followed. For other device types the commands have returned those values so the event trace clearly shows it to be an I2CS device. This is the first SwitchLinc I have seen with I2CS. It did not return the invalid data as other I2CS types do but did write the invalid data. That is why they say mismatch.

The link record flags are invalid. Not surprising the device will not respond to Scene requests. Can you take a screen capture of the Show Device Links Table popup? The posted file is not meant for human analysis. Also after the Show Device completes click on Compare.

Run a Show Device Links Table against the v.41 device. All the commands appeared to work but it is worth double checking. We may not have seen all the ways an I2CS device can reject commands.

Same concept, different variable. The 32 and below program and 90 and above program reset this additional variable.

You are right on, that is the concept. The variable should be an Integer variable, as opposed to a State variable.

I think the temp value is actually an xx.yy value. Any change in temp will trigger the Program again. You can AND an If Variable is 0 (arbitrary value) that allows the Then clause (True) to run. In the Then clause set the Variable to 1 which will stop the Then clause from running during additional temp changes. Another Program resets the Variable to 0 when the temp goes above 32.

ScottAvery This will sound counter intuitive but try moving the MorningLinc as far away from the ISY PLM as you can when adding the MorningLinc nodes to a Scene. Once the MorningLinc has been added to a Scene with the result that the PLM can no longer command the MorningLinc the only recovery is to Delete the MorningLinc and add it back using the described Start Linking with keep existing links option. After that is done and confirmed the On and Off nodes will cycle the lockset, move the MorningLinc to a distant location before adding the MorningLinc nodes to a Scene. After each node is added to a Scene check that either MorningLinc node can still cycle the lockset. If it will a MorningLinc node can be added to another or same Scene. Once the MorningLinc nodes have been successfully added to the Scenes and the MorningLinc nodes will cycle the lockset the MorningLinc can be moved back to its normal plug point. The objective is to increase the wire feet distance between the ISY PLM and MorningLinc while adding MorningLinc nodes to Scenes. There is a timing issue where the MorningLinc will disable ISY PLM control over the MorningLinc if commands come too quickly during Scene definition. If moving the MorningLinc to a distant location during Scene creation does not work send me a PM and I will describe an alternative method. It can have far reaching implications if not done correctly so I would prefer not to describe it on the forum. So far moving the MorningLinc to a distant location has resolved the Scene creation problem for every user assuming the MorningLinc has lockset control before the move.

Each Controller has a unique set of responder values. When the Scene name has been selected (ISY PLM is Controller) the Relay On Level applies when the ISY Scene name is controlled from the Admin Console or an ISY Program. To set the Relay On Level for the KeypadLinc button, click on the KPL button node name just below the Scene name. The Relay On Level displayed now is the value that is in effect when the KeypadLinc button is pressed. Give that a try and let me know.

LeeFleishman For sure the light turning Off when the Fan is not running is not the EMF issue I was thinking about. If you can ever catch that situation with an Event Viewer running at Level 3 I would love to see the trace. There is a generic Standard command that ISY issues to satisfy a Query request. For sure the FanLinc, being that it has two nodes (Groups), is not returning the Fan state. There is a general Extended command that most devices support which returns device information. The Extended command does return the Light On Level and Ramp Rate. For HouseLinc to get the correct Fan state there must be a variant of that Extended command that pulls the Fan information. I'm sure that is documented in the Developer section on SmartLabs web site but it requires a paid subscription to get access. I would buy a developer subscription but one has to sign an NDA and that I will not do. I'm sure this is something the ISY will support in a future beta drop. Thanks for the feedback on the Fan/Light interaction. Lee

Insteon powerline messages are far too complex with CRC check character to be generated by electrical noise. I really don't think the I/O Linc circuitry would be affected by humidity unless water was actually flowing on the device itself. Is the native garage door wall control a simple push button or the newer multi button controllers that support immediate open, delayed open, light control, and so on. A simple single button would seem unlikely to be affected by humidity. The more complex multi button controls might but that seems unlikely as well. They are designed to be installed in a garage where the environment can be harsh compared to inside a house. Is there an exterier switch such as a keypad that can control the opener. Something like that could be affected by rain. What company made the garage door opener. In the initial post it indicated the garage door kit was removed from the opener. Was this done by disconnecting the wires from the I/O Linc or unplugging the I/O Linc? Did the door ever move after the disconnect?

Sorry, I thought you were asking about what is available now rather than asking for additional function.

Reading the I/O Linc Sensor would have no control over door movement. For the door opener to move the garage door something has to be connected to the door opener circuit. What I was asking if the Relay side of the I/O Linc, which is separate from the Sensor side that is monitoring door position, is not connected to the door opener circuit, what control could Insteon have over door movement? Is any Insteon device connected to the door opener circuit? This is the circuit the wall mounted button is connected to that causes the door to open or close. Besides seeing if the door is open or closed is there a button on the MobiLinc that allows you to cause the door to open or close? If there is no Insteon device connected to the door opener circuit, nothing related to Insteon, ISY or MobiiLinc is related to the door moving when it rains. Did someone else install the I/O Linc in the garage?

3.2.0 added a Responding option to the list of Status values. If Status 'xxxxx' is not Responding Or Status ‘yyyyy’ is not Responding Or Status ‘zzzzz’ is not Responding would allow a Notify to be sent. Each device has to be checked individually.

dstanley Just updating the ISY image should not have changed anything in the KeypadLinc. If some change to the Scene was made then there could be a problem. Suggest doing a Restore Device on the KeypadLinc. It may be necessary to make a small change in the On Levels for both Load and B buttons to get the correct settings after the Restore Device. I set that Scene up on a v.36 KPL 6 button Dimmer. Button B brings it to 35%, ON brings it to 65%. I have done a Restore Device on this KPL for other reasons.

andrewm I don't know. It has happened so infrequently it is hard to pin down. In fact I had dismissed it until it was mentioned on the forum. I have FanLincs Rev 1.0 (v.3B) and Rev 1.05 (v.41) with the later being an I2CS device. Have not seen it at Rev 1.05 but I do not consider that meaningful at all. It is much too rare to reach that conclusion. Could even be a difference in the motors although they were purchased at the same time years ago.

I'm not thinking a defective device. Based on the initial post that the switches were Set button linked together and work perfectly would indicate the switch is not defective.

Has the wiring to this device been double checked with a meter to insure the wiring is correct.

That is correct. The Scene Test clears the event log so the preparatory work to put the devices in a known state is not in the event log. The switch could be defective but that is a very last option. Suggest factory resetting both switches followed by a restore device.

Suggest disconnecting the Red load wire and run the Scene Test again. Some CFLs are known to generate enough interference to prevent a device from turning Off.

This is not a comm problem per see. The 1B.87.63 device said it could not turn Off as directed. Does this device have the load and if so what type of load?

It is not an I2CS device. The link written to 1B.87.63 was created successfully which indicates communication between the ISY PLM and that device is good. There were no errors encountered writing the new link record. There could have been comm issues when this device was added but they are not there now. Since a Scene xxxx (where xxxx is a number) was not created when the devices were added I suggest creating a new ISY Scene and add both switches to the ISY Scene as Controllers. That should cross-link the devices and the Scene should control both devices. If something does not work from there we will be starting with a known. Once the ISY Scene has been created and the two devices added as Controllers, run a Scene Test to see if the test shows Successful for both devices.