LeeG

I do not know why 3.3.9 would have dropped that device definition. It is in 3.3.10 - 2.44 [02.2C]

What does Help | About show for Firmware and UI levels. What does the unsupported message show for the cat/subcat 2.xx? The 2487s is listed in the 3.3.10 device type pulldown.

ellesshoo The "If Control 'xxxxx' is switched On" is looking at Insteon commands coming "from" device xxxxx and only looking at Insteon commands coming "from" device xxxxx. That means the paddle/button on xxxxx is pressed to generate an On command. A question related to any subject/scenario other than physical device xxxxx sending an On command, it does not trigger the Program. Does not matter whether xxxxx is turned On by a Program, turned On by a Scene, turned On by the phantom, if not turned On by the physical device itself so device xxxxx sends an On command the If Control does NOT trigger a Program. It is that simple for If Control. “If Status ‘xxxxx’ is ???†triggers a Program any time ‘xxxxx’ changes Status. Does not matter why Status changes. Could be the device Status changed by pressing its button/paddle, its Status changed by a Program statement, changed by a Scene, changed by the phantom, so long as the device Status changes the Program is triggered. Once triggered the If clause is evaluated for True or False. When the If evaluates to True the Then clause runs, when it evaluates to False the Else clause runs. Does the scenario/question result in ‘xxxxx’ changing Status? If so the Program triggers, if not the Program does not trigger. Every scenario, every question can be resolved by applying it to the above. It is fine to sanity check ones understanding of the above with individual questions. I apologize if much/all of this has already been covered in the various posts thus far. Happy to add clarification or answer a specific question to sanity check the above.

There is a Query command but the current state cannot be stored a variable. We are all hoping this will come sometime this year when Variables are enhanced. Until then a Program can check for a range of values If Status 'xxxxx' is => 20% and Status 'xxxxx' is =< 30% Then do something. Checking for every possible On Level has too many possibilities.

Junkycosmos This message Mon 01/21/2013 07:40:29 PM : [12 31 E6 0 ] May not fully support i2, reverting to i1 has to do with how the ISY will update the link database. I expect the device configuration for Local values will now be done with Extended commands that do not require a power cycle to take effect. The messages Mon 01/21/2013 07:44:18 PM : [iNST-SRX ] 02 50 11.A1.B5 00.00.01 C7 11 01 LTONRR (01) Mon 01/21/2013 07:44:18 PM : [iNST-DUP ] Previous message ignored. likely come from an RF device which does send multiple Group Broadcast messages. They should not cause a problem. I would take the IR messages to mean the ISY is picking up stray IR from somewhere. Placing a piece of opaque tape over the IR hole should resolve the situation. If not then there is some IR issue with the ISY. Be sure the tape is totally opaque.

Right click the SwitchLinc node, select Diagnostics | Query Insteon Engine. The ISY is using the original I1 Peek/Poke method for setting the Local value. This old technique requires the device be power cycled to take effect. Using the old method is either the result of the SwitchLinc being too old to support the later I2 method or the ISY does not understand the device supports I2. The Query Insteon Engine will resolve the problem if it is the later. If it is an old SwitchLinc that is as good as it gets. After the Query Insteon Engine see if a Local change takes effect immediately. The event trace will show using Extended commands rather than Peek/Poke to do the Local update if Query Insteon Engine resolves the problem. Note that the ISY will not send an update for a value it thinks is already in the device. The Local On Level will have to be changed to some new value to see if the Query Insteon Engine fixes the problem. What does the ISY show for the SwitchLinc firmware? Second line under the device name in the right pane of the Admin Console display for the SwitchLinc.

Michel What you wrote is exactly right. A 0% On Level in the link record reverses the Scene command actions. Scene On turns relay Off, Scene Off turns relay On. That is what this topic documented in the initial post. johnnty was seeing one of his I/O Linc Relays turn On with a Scene Off and did not understand why. It was because the link record has a 0% On Level. This is well documented in the initial post which Queried the I/O Linc relay and found it On when it was expected to be Off. That is what this topic is all about. What is described in 1. in the post just before this one is just the opposite to what is described in the initial post of this topic.. The confusion now is that 3.3.10 no longer changes the actual Responder link record when the Responder On Level slider is moved. I had the event viewer running while moving the On Level slider. A command is issued to change the state of the Relay when the On Level slider is moved between 0% On Level and 100% On Level but no commands are issued to change the link record in the I/O Linc. Do not know when not changing the link record started. The initial post by johnnyt shows the Responder link record in the I/O Linc with the On Level of 00 0FB8 : A2 1B 1E.48.AD 00 00 00 With 3.3.10 (do not know when this started) not changing the link record when the Responder On Level slider is moved the link record cannot be set back to 100% On Level to stop the relay/command reversal. Here is the event trace of moving the I/O Linc Relay Responder On Level slider. The first set of commands are when the slider was moved to 0% On Level, the second set of commands when the slider was moved back to 100% On Level. Note that no commands were issued to physically change the link record. Mon 01/21/2013 08:47:09 AM : [iNST-TX-I1 ] 02 62 15 BB 5A 0F 13 02 Mon 01/21/2013 08:47:09 AM : [iNST-ACK ] 02 62 15.BB.5A 0F 13 02 06 LTOFFRR(02) Mon 01/21/2013 08:47:09 AM : [iNST-SRX ] 02 50 15.BB.5A 19.70.06 2B 13 02 LTOFFRR(02) Mon 01/21/2013 08:47:09 AM : [std-Direct Ack] 15.BB.5A-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 01/21/2013 08:47:25 AM : [iNST-TX-I1 ] 02 62 15 BB 5A 0F 11 02 Mon 01/21/2013 08:47:25 AM : [iNST-ACK ] 02 62 15.BB.5A 0F 11 02 06 LTONRR (02) Mon 01/21/2013 08:47:25 AM : [iNST-SRX ] 02 50 15.BB.5A 19.70.06 2B 11 02 LTONRR (02) Mon 01/21/2013 08:47:25 AM : [std-Direct Ack] 15.BB.5A-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 01/21/2013 08:47:25 AM : [ 15 BB 5A 2] ST 255 johnnyt After changing the Responder On Level slider do another Show Device Links Table for the I/O Linc. The link record On Level is no longer being changed when the On Level slider is changed.

Michel To clarify a little, johnnyt is not using Trigger Reverse to reverse the Sensor commands. A Scene is being used with the I/O Linc Relay as a Responder. When the Responder On Level is 100% in the Responder link record a Scene On turns the Relay On (he operates in Latching Mode) and a Scene Off turns the Relay Off. If the Responder On Level slider is changed to 0% On Level in the Responder link record, the Relay action is reversed. The I/O Linc turns the Relay On with a Scene Off and turns the Relay Off with a Scene On. Currently the ISY marks the Relay Current State based on the last command issued which is fine unless the Responder On Level is set to 0%. The Relay is actually Off when the last command sent is Scene On and the Relay is actually On when the last command sent is Scene Off. The ISY would have to note the Responder On Level as well as the Scene command being sent to know whether to mark the Relay On or Off. Similar to noting a 0% On Level of a lighting device to know that a Scene On is actually turning the lighting device Off. The difference with the I/O Linc Relay is that a 0% On Level affects both the Scene On and Scene Off.

Do not use Insteon Direct On/Off commands to start with. A Direct On ALWAYs turns the Relay On. In any of the Momentary modes the I/O Linc automatically turns the Relay Off so the Direct Off command has no function. The I/O Linc User Guide, when it is discussing different Momentary modes and the relationship with On and Off commands, it is exclusively discussing Scene On and Scene Off commands. A device (other than the PLM) is not capable of issuing Direct device control commands so the User Guide is in the context of using Scenes. I will not be on the forum much for the next few days. Hopefully someone else can jump in.

Was the 994 update downloaded? Sounds like perhaps it is a 99i update being applied to a 994

Put a transmitter/receiver inside a solid metal box and it will likely not work at all. If the junction box has a non-metal face plate there is some RF coverage on the front side. The effectiveness of the Access Point behind the metal junction box in the other room is reduced. Hops Left=0 by itself can be okay. Depends on the Max Hops count. The trace shows variation across a very small time frame where Max Hops=3 and Hops Left=2 and 1. A single example is not enough to comment beyond saying a longer trace should be checked for how consistent Hops Left count is when Max Hops=3. Sun 01/20/2013 10:44:27 AM : [iNST-SRX ] 02 50 20.43.49 1E.48.AD 27 2F 00 (00) Sun 01/20/2013 10:44:27 AM : [std-Direct Ack] 20.43.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 01/20/2013 10:44:28 AM : [iNST-SRX ] 02 50 20.43.49 1E.48.AD 2B 2F 00 (00) Sun 01/20/2013 10:44:28 AM : [std-Direct Ack] 20.43.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Some of the Hops Left=0 are fine. The Extended response (02 51) containing the actual link record was sent with Max Hops=1. Hops Left=0 is the best response for a Max Hops=1. Sun 01/20/2013 10:44:28 AM : [iNST-ERX ] 02 51 20 43 49 1E 48 AD 11 2F 00 00 01 0F 47 20 A2 05 1A 1D 09 FF 1F 07 4E Sun 01/20/2013 10:44:28 AM : [Ext-Direct ] 20.43.49-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Sun 01/20/2013 10:44:29 AM : [iNST-ERX ] 02 51 20 43 49 1E 48 AD 11 2F 00 00 01 0F 3F 20 A2 05 17 A3 7B FF 1F 03 65 Sun 01/20/2013 10:44:29 AM : [Ext-Direct ] 20.43.49-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 The message Sun 01/20/2013 10:44:31 AM : [Ext MH ] Unexpected Response (i.e. DB range): ignored is the result of the PLM receiving KPL link record messages out of sequence. Actually I think it is an extra message from an earlier read request rather than an absolute out of sequence response. The link record at 0F40-0F47 is read successfully. The link record at 0F38-0F3F is read successfully. The link record at 0F30-0F37 is requested. An additional copy of the link record at 0F38-0F3F is received which is the DataBase (DB) range issue. This extended message has a Max Hops=3 Hops Left=0 which suggests the previous 02 51 Extended message with the first copy of 0F38-0F3F link record did not receive the PLM generated ACK so the KPL resent the 02 51 Extended message with the higher Max Hops count. The combination of the extra 02 51 message along with the variation in Hops Left count over such a small time period suggests a less than great comm. with the KPL location. With metal box (hopefully with plastic covers) I would try putting an Access Point on the front side of the box to see if that improves the Hops Left count variation.

Take a look at this topic on the Smarthome forum regarding ToggleLincs and wiring.. http://www.smarthome.com/forum/topic.asp?TOPIC_ID=11255

Any time. "The I/O Linc has three Momentary modes that are generally used in garage applications. Being able to reverse the Relay actions in combination with the various Momentary modes allow a KeypadLinc button press On or Off to control the Relay." I am aware the I/O Lincs are not being used in a garage application in this case. The above information was meant to describe how/why the command/relay action reversal is necessary/useful in some cases. The MorningLinc has the same capability, to reverse the On/Off command versus Lock/Unlock action. Some folks want a KPL On button press to open the garage door or unlock the MorningLinc. Others want just the opposite. Command reversal provides that. Memory says there is another Smarthome device with the same feature but I cannot bring it to mind. For the benefit of others who might gain some general device knowledge from these topics. I suspect there are folks who do not know 0% On Level turns a light Off. I suspect there are folks who do not know that until recently KPL Secondary buttons did not support being turned Off with a 0% On Level. I suspect there are folks who do not know the I/O Linc and MorningLinc commands can produce the opposite effect. I suspect some folks are familiar with all of the above.

If the button LEDs have no illumination it would be impossible to tell if a button is On or Off. The LED Backlight level set to 0/7 reduces the Off level to its lowest setting. The OFF button will still be on On when the load is Off. To eliminate that set the load control button to non-toggle Off mode. The KPL ON/OFF buttons have to be cycled for that change to affect the OFF button LEDs. The ON button and Secondary buttons A,B,C,D will be On at a very low level when the respective button is On.

No need to evaluate communication. When the toggle will not physically control the load how comm is not working does not much matter. Could run an Event Viewer at LEVEL 3 and request a Query. It will likely show the device did not respond to commands. Really does not matter when the toggle has no control. With multiple ToggleLincs showing the same symptom of toggle stops working it is environmental. Load, type, wiring. What else is on the same circuit?

Could be the size of the load is more than the ToggleLinc can handle. Could be the type of load is causing the ToggleLinc to hang up. Could be a wiring problem that takes days for the three switches to get in the combination of On or Off to compromise power to the ToggleLinc. This can be determined by checking the voltage to the ToggleLinc when it hangs up. When the toggle will not control the load the issue is with the device. Not necessary the fault of the device since more than one device has demonstrated the same symptom. The total wattage being controlled, the type of load being controlled, the wiring of the ToggleLinc have been constants when multiple ToggleLincs have been used in that location.

Does the toggle control the load when no communication is possible?

That is correct. A few devices will send a Group Broadcast message (which has no specific device destination) but most devices must be linked to a Responder before any Group Protocol message is issued including sending the initial Group Broadcast message. In the case of the EZX10RF the number of X10 nodes is not known when the device is added to the ISY. The X10 codes have to be defined after adding the device to the ISY so a new node can be created for each X10 code.

The I/O Linc has three Momentary modes that are generally used in garage applications. Being able to reverse the Relay actions in combination with the various Momentary modes allow a KeypadLinc button press On or Off to control the Relay. Smarthome makes no effort to describe the internals of link records and how various values affect device operation. Their user guides and quick start guides are written from the perspective of how to set up devices with Set button links and various On/Off/On Level conditions. Would be of little use for users to think about what values in a link record produce what results. I don't think reversing a device response is limited to the I/O Linc relay. Seems like the MorningLinc has something similar, and probably other non-lighting devices. The Simplehomenet/Smartenit devices use On Level, Ramp Rate and Unit number for things other than what they mean for the main stream Insteon devices for lighting and appliance control. The 0% On Level resulting in a device being turned Off with an On command is pretty much universal across lighting and appliance control devices like the ApplianceLinc. It would take a Developer Subscription to gain access to the confidential device spec's if you want/need the specifics on the internals. I don't have one as it requires an NDA which is just too limiting. Also some folks that have one express frustration over the level of detail and timeliness of the information even when one has a Developer Subscription.

Sounds like the EZX10RF was setup outside of the ISY. The ISY will not be aware of any of the Insteon traffic from the EZX10RF when done that way. Each X10 code has to be defined to the EZX10RF using the ISY facilities for adding X10 devices to the EZX10RF. Suggest the EZX10RF and the other devices that have been linked outside of the ISY be factory reset followed by a Restore Device to get each device link database in sync with the ISY. Then add the X10 codes to the EZX10RF. After that each EZX10RF node representing an X10 code can be added to an ISY Scene as a Controller.

ISY Scene 1B has a link record in I/O Linc 1F.50.CA for that Scene number. The link record has an On Level of 00 which reverses the Relay action. Off command turns Relay On, On command turns Relay Off. That is why I/O Linc Relay is On in response to Scene 1B Off command. Sat 01/19/2013 01:08:44 PM : [iNST-TX-I1 ] 02 62 00 00 1B CF 13 00 Sat 01/19/2013 01:08:45 PM : [iNST-ACK ] 02 62 00.00.1B CF 13 00 06 LTOFFRR(00) Sat 01/19/2013 01:08:45 PM : [ 15 B9 70 2] ST 0 Sat 01/19/2013 01:08:45 PM : [ 20 43 49 6] ST 0 HRV High Speed-S / 1F 50 CA 1 0FF8 : A2 00 1E.48.AD FF 1F 01 0FF0 : A2 05 1A.1D.09 FF 00 00 0FE8 : A2 06 20.43.49 00 00 00 0FE0 : A2 07 16.74.DF FF 00 01 0FD8 : A2 07 20.43.49 FF 00 00 0FD0 : A2 08 20.43.49 FF 00 00 0FC8 : A2 16 1E.48.AD 00 00 00 0FC0 : A2 17 1E.48.AD FF 00 00 0FB8 : A2 1B 1E.48.AD 00 00 00 0FB0 : A2 20 1E.48.AD FF 00 00 0FA8 : A2 25 1E.48.AD FF 00 00 0FA0 : A2 37 1E.48.AD FF 00 01 0F98 : E2 01 1E.48.AD FF 1F 01 0F90 : 00 00 00.00.00 00 00 00 Device Record Count : 14

Click on the Red KPL button node name below the Scene name. Check the KPL load button On Level when the Red KPL button node name is selected. Every Controller has a unique set of Responder values. The posted image (thanks for that image) shows some of the Responder On Levels when the ISY PLM is the Controller (using the ISY Scene name). Need to check the Responder values for when the Red KPL button node name is the Controller (when the Red KPL button node name is pressed).

It is the Scene definition that controls the On Level. Can you post the Scene definition when the KeypadLinc Controller button is selected (below the Scene name). What ISY Firmware level is being used?

The Admin Console (UI) should be at the same level as the ISY Firmware. It is likely the fix for the thermostat Scene problem fixed at 3.3.10 was in the Admin Console, not the ISY itself. Once the UI (Admin Console) is at 3.3.10 the Scene will have to be created again as it is the Admin Console that sets the data in the Scene link records.

"First can you add an X10 device to be controlled by a KeyPadLinc controller? " Insteon does not support X10 devices as part of an Insteon Scene. An ISY Program can be triggered by a KPL button press and have the ISY Program issue X10 commands. "Second can you have discrete scenes for the On and Off buttons?" If the question is can the ON button and OFF button control different Scenes, NO. The ON and OFF buttons use the same Scene/Group number so it is not possible to have different Scenes for the two buttons. An ISY Program can be triggered with the On command and control Scene X. Another ISY Program can be triggered with the Off command and control Scene Y. There would be no direct Scene control by the button press. There is a complex trick that can be done. Change the KPL to 8 button mode. That makes the top and bottom button rows operate separately. Buttons A and B have to be cross-linked and buttons G & H have to be cross-linked. To achieve the same button LED pattern between the ON and OFF buttons requires additional ISY Programs to turn the button LEDs On and Off to simulate 6 button mode. It is not something a newbie is likely to be successful in implementing. Too many moving parts.