LeeG

I have no theoretical explanation for how this is happening. First I do not think the ISY has a defect. That leaves me with some outside activity, another Program, some other application using an ISY plug-in issuing REST commands that has not been mentioned to this point, something about this specific environment that has not been discussed yet. oberkc The duplicate messages that have been labeled ignored are not uncommon with all the Dual Band activity that is in place now days. They are redundant Group Broadcast or Group Cleanup Direct messages which the ISY has detected as being duplicates and ignored them. I don't think they are causing the change in device state or interfering with variable counting.

No PLM restore should be needed. If the Scene Test was successful even once the necessary link records are present in the PLM and the devices. When a Scene Test is intermittent there are comm issues. The type of load being controlled could be generating noise. Other devices/appliances on the circuit could be causing interference. Extension cords with noise suppression could be involved. Lots of possibilities.

bjhanson3 First paddle On press Thu 12/20/2012 11:38:19 AM : [iNST-SRX ] 02 50 1B.23.94 00.00.01 C7 11 00 LTONRR (00) Thu 12/20/2012 11:38:19 AM : [standard-Group][1B.23.94-->Group=1] Max Hops=3, Hops Left=1 Thu 12/20/2012 11:38:19 AM : [ 1B 23 94 1] DON 0 Thu 12/20/2012 11:38:19 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01) Thu 12/20/2012 11:38:19 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Thu 12/20/2012 11:38:19 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01): Process Message: Ignored Thu 12/20/2012 11:38:19 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Second paddle On press Thu 12/20/2012 11:38:20 AM : [iNST-SRX ] 02 50 1B.23.94 00.00.01 C7 11 00 LTONRR (00) Thu 12/20/2012 11:38:20 AM : [standard-Group][1B.23.94-->Group=1] Max Hops=3, Hops Left=1 Thu 12/20/2012 11:38:20 AM : [iNST-SRX ] 02 50 1B.23.94 00.00.01 C7 11 00 LTONRR (00): Process Message: Ignored Thu 12/20/2012 11:38:20 AM : [standard-Group][1B.23.94-->Group=1] Max Hops=3, Hops Left=1 Thu 12/20/2012 11:38:20 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01) Thu 12/20/2012 11:38:20 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Thu 12/20/2012 11:38:20 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01): Process Message: Ignored Thu 12/20/2012 11:38:20 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Third paddle On press Thu 12/20/2012 11:38:22 AM : [iNST-SRX ] 02 50 1B.23.94 00.00.01 C7 11 00 LTONRR (00) Thu 12/20/2012 11:38:22 AM : [standard-Group][1B.23.94-->Group=1] Max Hops=3, Hops Left=1 Thu 12/20/2012 11:38:22 AM : [ 1B 23 94 1] DON 0 Thu 12/20/2012 11:38:22 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01) Thu 12/20/2012 11:38:22 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Thu 12/20/2012 11:38:22 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01): Process Message: Ignored Thu 12/20/2012 11:38:22 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Thu 12/20/2012 11:38:22 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 21 DD 81 (81) Thu 12/20/2012 11:38:22 AM : [standard-Direct Ack][1B.23.94-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Forth paddle On press Thu 12/20/2012 11:38:23 AM : [iNST-SRX ] 02 50 1B.23.94 00.00.01 C7 11 00 LTONRR (00) Thu 12/20/2012 11:38:23 AM : [standard-Group][1B.23.94-->Group=1] Max Hops=3, Hops Left=1 Thu 12/20/2012 11:38:23 AM : [ 1B 23 94 1] DON 0 Thu 12/20/2012 11:38:23 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01) Thu 12/20/2012 11:38:23 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Thu 12/20/2012 11:38:23 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01): Process Message: Ignored Thu 12/20/2012 11:38:23 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Fifth paddle On press Thu 12/20/2012 11:38:25 AM : [iNST-SRX ] 02 50 1B.23.94 00.00.01 C7 11 00 LTONRR (00) Thu 12/20/2012 11:38:25 AM : [standard-Group][1B.23.94-->Group=1] Max Hops=3, Hops Left=1 Thu 12/20/2012 11:38:25 AM : [iNST-SRX ] 02 50 1B.23.94 00.00.01 C7 11 00 LTONRR (00): Process Message: Ignored Thu 12/20/2012 11:38:25 AM : [standard-Group][1B.23.94-->Group=1] Max Hops=3, Hops Left=1 Thu 12/20/2012 11:38:25 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01) Thu 12/20/2012 11:38:25 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Thu 12/20/2012 11:38:25 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 41 11 01 LTONRR (01): Process Message: Ignored Thu 12/20/2012 11:38:25 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Sixth paddle On press Thu 12/20/2012 11:38:26 AM : [iNST-SRX ] 02 50 1B.23.94 00.00.01 C7 11 00 LTONRR (00) Thu 12/20/2012 11:38:26 AM : [standard-Group][1B.23.94-->Group=1] Max Hops=3, Hops Left=1 Thu 12/20/2012 11:38:26 AM : [ 1B 23 94 1] DON 0 Thu 12/20/2012 11:38:26 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 42 11 01 LTONRR (01) Thu 12/20/2012 11:38:26 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=2, Hops Left=0 Thu 12/20/2012 11:38:26 AM : [iNST-SRX ] 02 50 1B.23.94 19.71.04 42 11 01 LTONRR (01): Process Message: Ignored Thu 12/20/2012 11:38:26 AM : [standard-Cleanup][1B.23.94-->ISY/PLM Group=1] Max Hops=2, Hops Left=0 Note that the ISY displays a device On message “Thu 12/20/2012 11:38:26 AM : [ 1B 23 94 1] DON 0†every other time. The ISY display this message only when the device status has changed to ON from something else which means there is some other activity going on which has not been identified as yet. This unidentified activity is affecting the device Status as well as affecting the variable count I suspect. I suggest marking all other Programs Disabled and see if the Variable count goes up as expected. The SwitchLinc is telling the ISY about each paddle On press.

bjhanson3 No problem with the event log analysis. Run a few tests with the SwitchLinc, counting the number of paddle presses so we can know what to look for. Save the event log and post it with copy/paste to a forum post with how may paddle presses were done. Thanks for pointing out that 6 button KPL was being used. I had updated my previous post when I saw from the button name it was a 6 button KPL.

rahnee What was the ISY firmware level before moving to 3.3.6. There is some building indications of an issue with the migration of the configuration data although that is speculation at this point.

Envirogreen Right click on the Scene name in the My Lighting tree, select Diagnostics ! Scene Test. Be sure 3.3.6 is installed. There was a bug in 3.3.5 that falsely show failed when the test was successful. The Scene Test will display each device Insteon address and show whether it was successful or failed. It takes a few seconds to complete the test. This test verifies the link records in the PLM and device are correct as well as communication between the PLM and device. If this fails it is usually the result of something happening to the link database in the device or the PLM which can be solved by a Restore Device or Restore Modem (PLM). Insteon Mesh Network has to be pretty bad for Scene Test to fail assuming link records are correct. If Scene Test is successful and Scene does not work the Insteon Mesh Network is suspect or the type of loads the devices are controlling. Turning a Scene On or Off is like issuing an X10 command. One command is placed on the powerline with the expectation all devices will see this one command. No ACKs are given thus no retries occur. The ISY marks the Responder On or Off as it expects them to respond, not as they might actually respond or not respond.

bjhanson3 It is not only inconsistent, the KeypadLinc makes no sense either as a KPL button toggles On and Off which would normally generate an On command with one press, and Off command with the next press, and so on. I suggest running Tools | Diagnostics | Event Viewer with LEVEL 3. Press the SwitchLinc paddle On and see what/if commands are traced by the Event Viewer. Press the On paddle again and see if the same commands are traced. There is an unknown here that has not yet been discovered which will explain the Program behavior. EDIT: actually the KeypadLinc is working as expected as that is a 6 button KPL (from the naming convention) and the ON button is used as the test button. This button always issues an On command for each button press so the observed results are the expected results for that KPL.

Unchecked. The two LEDs actually turn On and Off on mine as I check and uncheck the LED Background check box. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Are commands traced as the LED Background check box is checked and unchecked. Give it a few seconds between checking and unchecking the box for the command to be executed and a response received. Post the event trace if the LEDs are not reacting

"Do I need to do all my programming in the isy99 and not manually link the buttons?" Yes. Manual Set button links should not be done with the ISY. Define an ISY Scene, adding the appropriate RL2 and KPL buttons as Controllers and the FanLinc Light or Motor node as Responder I'm running 3.3.6. I can turn the FanLinc LED Backlights On and Off on an I2CS FanLinc. Is yours an I2CS device? Could try right click, diagnostics | query Insteon Engine and then see if LED Backlight check box works.

That is the problem. The Program is changing the state of 'Master Side Lamp' in the Then clause as well as well as testing 'Master Side Lamp' Status in the If. When the Wait is executed the If is reevaluated because one of the conditions it is testing has changed. Because 'Master Side Lamp' is not On the If is False and the Else executes. The next time the Then clause is run 'Master Side Lamp' starts off being On so what the Then clause issued the Set On the Status does not change so the Wait completes as expected. The solution is to put the Then logic into a second Program that is invoked from the Then clause of the current Program. The second Program has nothing in the If clause so changing the Status of 'Master Side Lamp' does not affect the Wait.

The actual If statement would be better posted rather than pseudo code. From the results discussed it sounds like "If Status 'xxxxx' is Off" is being used where the Then clause if changing the state of 'xxxxx'. When the Wait is executed any change in state of 'xxxxx' causes the If to be reevaluated and probably ran the Else clause. Next time the Status is already On so the initial statement does not change the Status so the Wait completes and executes the Off. The effect of changing the conditions the If clause is testing has on Wait and Repeat is covered pretty well in the Wiki. If you right click the Program name, there is an option 'Copy to Clipboard' which copies the Program to the OS Clipboard. At that point a Paste can be done into a forum post to get the actual program logic in the post.

The next time it happens do a Show PLM Links Table to see what the actual condition of the PLM is. A corrective action is known (Restore Modem) but what is that action correcting for. I understand the symptom it is addressing, what I am looking for is what actual condition exists. Are all the link records gone or is the PLM only locked up, that type of question. Since there are hundreds if not thousands of ISY/PLMs running today that are not having this symptom I think it is important to determine what the problem actually is. What ISY firmware and what PLM firmware is being used?

The best way to determine a device address is to manually Set button link it so some other device. In this case link the KPL as a Controller to say a LampLinc or ApplianceLinc and then do a Show Device Links Table of the LampLinc or ApplianceLinc. Normally the KPL address is the last address in the link database. After that be sure to do a Restore Device to the LampLinc or ApplianceLinc to get rid of the Set button link. This is one of the rare times a Set button link is Ok and it is immediately removed. Unless an 8 is being taken as B (or vise versa) it is more likely a comm issue exists at that KPL location.

A Program can issue a Repeat every 15 minutes followed by a Query of the I/O Linc. However, that should not be necessary if comm is okay. Also Trigger Reverse does not affect the Query response. Trigger Reverse reverses the commands issue by the Sensor but it does not reverse the state returned by Query. The Query returns the actual true state of the Sensor which is On when the door is closed with the NC magnetic switch in the current kit. If you absolutely have to Query change the magnetic switch to a NO and turn off Trigger Reverse.

After a Factory Reset the KPL LEDs responded correctly when I set the buttons to non-toggle Off mode. Correct LED operation and correct command generated. After I did a Restore Device to get the link database back I see the same thing you are seeing. The KPL button LEDs do not operate correctly for non-toggle Off mode but the Off command is issued for each button press,

The I/O Linc Sensor functions regardless of how the door opener is commanded to move. Watch the Green LED on the I/O Linc where the wires connect. Does this consistently shoe On when door is closed and Off when door is open (this assumes using the new kit with only a NC magnetic contact). Determine if the Green LED is accurate all the time. If not there is a magnetic sensor or wiring problem. When the Green LED is determined to be correct ALL the time, and the KPL LED is not there is a comm problem between the I/O Linc location and the ISY PLM. Independent of the consistency issue the I/O Linc Sensor has to be set to Trigger Reverse to have the KPL button LED Off when the door is closed. A better solution is use a NO magnetic switch as Trigger Reverse has other issues associated with Query. When controlling the I/O Linc Relay from the Admin Console Insteon Direct commands are used. Nothing in the Smarthome I/O Linc publications describes how the Relay works with Direct commands. A Direct command ALWAYS turns the Relay On. If you want the various command actions versus Sensor states and Momentary mode described in the Smarthome publications, use an ISY Scene with the I/O Linc Relay as a Responder. "If the KPL button is pushed the LED should just go back to the current garage door state. So if someone pushes it and its on I would like it to query and turn it self back on if the sensor still shows the door is open. If the door is closed the LED should wind up off. " This requires an ISY Program with logic to check the status of the I/O Linc Sensor. Easy to do but get the KPL button showing an accurate state of the door first. Then add the bells and whistles.

KeypadLinc buttons in non-toggle mode should blink twice when pressed. A non-toggle On button LED is left On. A non-toggle Off button LED is left Off. I had to factory reset my v.36 and then set the button toggle mode to Off before the LEDs worked correctly. After doing a Restore Device the button LEDs stopping working correctly even though the buttons continued to send only Off commands.

That document is from 2007. Much has changed since 2007.

You have access to internal documentation that I do not. The wrong 2E variant is being used for a LED Brightness change. I will leave it up to UDI to clear this up. Suggest opening a ticket with UDI tech support.

One thing for sure, stop playing with various backups. Restore the 3.3.6 backup. Nothing from a previous device definition should carry forward after deleting and adding the device back from scratch. Is the v.36 KPL a Relay or a Dimmer. The progress bar situation is resolved with everything at 3.3.6. Let’s stick with that and find the answer to the command variation question.

You can change the Scene Responder On Level (using Adjust Scene) for the bathroom light to turn the bathroom light Off using a 0% On Level after bed time. The Scene action cannot be eliminated. If using a different On Level is not acceptable a slight delay using a Program is the option or no control using a Scene.

The command issued on my system is using 07 as the 2E variant. The command in your post shows the 03 variant. Since both are v.36 KPLs I would expect both commands to use the same variant. The 7/15 (7F) is setting the same brightness level Sun 12/16/2012 03:26:42 PM : [iNST-TX-I2 ] 02 62 16 7D 60 1F 2E 00 00 03 7F 00 00 00 00 00 00 00 00 00 50 Sun 12/16/2012 07:20:41 PM : [iNST-TX-I2 ] 02 62 15 9A F9 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B

My 3.3.6 Admin Console is using a different option in the 2E command when setting LED Brightness on my v.36 KPL. What does Help | About show for the Firmware and UI level. Is it correct the progress bar is now completing?

Make sure the thermostat is Off. That message normally means there is no response to the PLM commands. An Event Viewer at LEVEL 3 while doing a New INSTEON Device will confirm.

Stay on 3.3.6. Delete the KPL and add it back under 3.3.6