LeeG

ergodic The Motion Sensor sent a Direct command NAK to the PLM. No command was sent from the PLM to the Motion Sensor, Direct or Group. Appears to be an erroneous message. The From device address is that of the Motion Sensor but no way to tell if it was generated by the Motion Sensor or the PLM. Is this the only device address generating the Comm failed message? Lee

gakran Thanks for that information. I was able to recreate something similar by having the cursor outside the physical boundary of the slider box when I let go of the mouse button. I was using a Secondary KPL button On Level slider where only Full On or Full Off are valid options. Slider moved but did not generate an event the Admin Console was aware of so nothing was changed in the device. Once I got the slider to generate an event then it did not matter where the cursor was when I let go of the mouse button. This looks like an issue with the way the Admin Console and the slider are operating rather than a failure of the Admin Console to initiate a device change. I'm running 3.1.6. Once the slider started generating events then it did not matter where the cursor was after that. Lee

gakran What does the Admin Console list as the Device Type of one of the SwitchLincs that does not accept an On Level change? What is the new On Level that is being set? What is the ISY firmware level? Lee

gakran ‘Why would the ISY progress bar message display " [ X10 ] I/6"’ What operation was being performed? I do not run with X10 device addresses assigned to any of my Insteon devices. X10 is just too unreliable. Perhaps a Restore Device was restoring a device and was in the process of restoring its X10 address. For sure it was not writing X10 information in an Insteon link record as there are no fields in a link record for X10 information. The Tools | Diagnostics | Event Viewer with Device communications events selected will trace what the ISY is actually doing on the powerline when the X10 message is in the progress bar. Hopefully someone who uses X10 addresses with their Insteon devices can jump in here. Another SwitchLinc test would be to disconnect the red load wire and see if it remains On. What type of load is the SwitchLinc controlling? There are Program Export/Import functions available. Right click on a Program name. Note that UDI does not recommend doing a Factory Reset of the ISY. Lee

gakran First, disable ALL Programs and see if the SwitchLinc will stay On. Either a command is being sent to the SwitchLinc to turn Off or it is turning itself Off based on some load condition. Did this start after power interruptions? X10 devices are not linked like Insteon devices. Insteon link records have no reference to X10 addresses, commands or devices. Of course an Insteon device can have an X10 address assigned but this never appears in any link record. Note that a single progress bar does not reflect the total activity. Each update activity is reflected by a new progress bar so give the total process a change to complete. Watch the status flag/word in the lower left corner of the Admin Console. Lee

sanders2222 The v.00 is normal when the Device Type field is selected from the pulldown options. There is a known situation where SmartLabs has begun shipping a variant of the SwitchLinc 2476D with a new Cat/Subcat value. When the Device Type was specified as Auto Discover was a message issued saying something like unknown device:1.48? If so the workaround is to select the SwitchLinc Dimmer device type from the Device Type pulldown. This may be resolved in 2.1.7 if Smartlabs provides information on the new device type in time. Lee

If you can catch one of those messages with the Event Viewer running it may provide the answer. Does the Error Log show anything at the time one of the messages appears? Hopefully someone has seen it before and knows the cause.

ergodic It means the ISY tried to send something to the Motion Sensor and could not reach the device. Normally the result of not having the Motion Sensor in linking mode when updates are made. Run Tools | Diagnostics | Event Viewer with Device communications selected. Then put the Motion Sensor into linking mode with the Set button. Then click on Write Updates to Device or Query and see what the ISY is trying to write. Lee

After the Program changes the responder On Level for Closet Dimmer, the next time the Motion Sensor sends a Motion On the Closet Dimmer should turn On to the last responder On Level set by the Program. If the Closet Dimmer does turn On to the correct On Level but that On Level is not reflected back to the Admin Console Current State field for Closet Dimmer there is likely an unreliable powerline communication between the Motion Sensor and the ISY PLM. That result would indicate the Closet Dimmer is receiving the Motion On message and reacting to it but the ISY PLM is not seeing the same message so the Admin Console status is not being updated. I set up a Scene with a Motion Sensor as the Controller and an ICON Dimmer as the responder. A Program triggered at a particular time and set the responder On Level for the ICON Dimmer responder to 85%. When the Program ran no change was reflected at the ICON Dimmer and no change was reflected at the Admin Console (as expected as only the link record is changed by the Program). The next Motion On turned the ICON Dimmer On to 85% and the Admin Console Current State for the ICON Dimmer changed to 85%. I am not using any Query, not in the Program and not from the Admin Console. If that is not the results you are seeing please detail what is happening and we can proceed from there.

The change to the Responder link record is immediate. You can confirm this by running Tools | Diagnostics | Event Viewer with Device communications events selected. The trace will look similar to this.... Wed 08/31/2011 03:49:09 PM : [C 8C 3B 1 ] Link 21 : 0F50 [A225129FE4D81F01] Saving [..........D8....] Wed 08/31/2011 03:49:09 PM : [All ] Writing 1 bytes to devices Wed 08/31/2011 03:49:09 PM : [C 8C 3B 1 ] Using engine version i1 for 'KeypadLinc White Box' Wed 08/31/2011 03:49:09 PM : [C 8C 3B 1 ] Link 21 : 0F50 [A225129FE4D81F01] Writing [..........D8....] Wed 08/31/2011 03:49:09 PM : [iNST-ACK ] 02 62 0C.8C.3B 0F 28 0F 06 SET-MSB(0F) Wed 08/31/2011 03:49:09 PM : [iNST-SRX ] 02 50 0C.8C.3B 12.9F.E4 2B 28 0F SET-MSB(0F) Wed 08/31/2011 03:49:09 PM : [standard-Direct Ack][0C.8C.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 08/31/2011 03:49:09 PM : [iNST-ACK ] 02 62 0C.8C.3B 0F 2B 55 06 PEEK (55) Wed 08/31/2011 03:49:10 PM : [iNST-SRX ] 02 50 0C.8C.3B 12.9F.E4 2B 2B FF PEEK (FF) Wed 08/31/2011 03:49:10 PM : [standard-Direct Ack][0C.8C.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 08/31/2011 03:49:10 PM : [iNST-ACK ] 02 62 0C.8C.3B 0F 29 D8 06 POKE (D8) Wed 08/31/2011 03:49:10 PM : [iNST-SRX ] 02 50 0C.8C.3B 12.9F.E4 2B 29 D8 POKE (D8) Wed 08/31/2011 03:49:10 PM : [standard-Direct Ack][0C.8C.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 This is the trace of an Adjust Scene to set the responder On Level to 85%. The effect on the actual responder On Level will not be seen until the Scene is turned On the next time. The Scene On command causes the responder to access the link record for the particular controller to see what On Level and Ramp Rate should be used for the On command.

C Martin The Adjust Scene Action is changing the Responder On Level or Ramp Rate in the link record of the selected Responder. The Action has no immediate effect on the Responder device itself. When the Scene is used the next time the new On Level will take effect. Lee

remedy1234 The Low Battery node is initialized to Off when the Motion Sensor is added to the ISY and when the ISY is rebooted. Once a Motion Sensor reports low battery it is necessary to “Query†the Motion Sensor to reset the Low Battery node back to Off after the battery has been replaced. The Motion Sensor is not actually accessed with the Query so there is no need to put it into linking mode. Try moving one of the Motion Sensors that is not reporting status closer to an Access Point or other Dual Band device. Is Jumper 5 in place to allow the ISY to control the Motion Sensor options? Depending on the options that are in effect Dusk/Dawn will not be reported. Also depending on the options in effect the Motion On message will be sent only after the timeout interval has expired. Also depending on the options the Sensor node may never say anything but ON. Lee

The hardware does not respond the same between a LampLinc relay and the I/O Linc relay. A Scene Off to a LampLinc always turns the LampLinc Off. The Scene Off to an I/O Linc may turn the I/O Linc relay On or it may turn the I/O Linc relay Off.

I agree completely with the thought the On Level should default to 100% for the I/O Linc relay. The LampLinc and most other Insteon devices do not command reverse when the On Level is 0%. A Scene On turns the LampLinc On to the specified On Level which at 0% is Off. A Scene Off turns the LampLinc Off regardless of the On Level. The I/O Linc is actually command reversal. With 100% On level a Scene On command turns the relay On, a Scene Off command turns the relay Off. At 0% On Level the commands are reversed. A Scene On turns the relay Off, a Scene Off turns the relay On. The ISY could mark the Relay status based on a combination of command executed and On Level. The Scene definition would have to be accessed for both On commands (which is done today for most devices) and Off commands which is unique to the I/O Linc. Something for UDI to comment On. Perhaps posting an entry under the requirements topic. The relay status would remain wrong when using Momentary mode.

The ISY is reporting the last command sent to the I/O Linc relay. The fact that the relay turns On with an Off command and Off with an On command is not a consideration, it is only reflecting the last command issued. The Relay status as reported by the ISY will also be wrong when using one of the Momentary modes as the I/O Linc turns the Relay Off and does not notify the ISY of the change. Like the Trigger Reverse situation, Query returns the true state of the Sensor and the true state of the relay regardless of the command that got it that way. The only way to prevent the state switch with a Query is to run without Trigger Reverse on the Sensor and 100% On Level with the Relay. There is no work around for Momentary mode turning the Relay Off short of doing a Query.

A reboot does not destroy the error log.

Please do not reset the ISY. There are many posts from UDI indicating the ISY should not be reset as it rarely fixes anything. Clear the Java cache, check that Tools | Diagnostics | PLM Info shows a Connected PLM. A router and ISY reboot would be good things to try. Also there is an issue with the 3.1.6 backup which makes it unusable so recovery after a reset could be difficult. Again, unless someone from UDI instructs the ISY be reset, please do not reset the ISY.

According to the 3.1.6 release notes "Support for 2491T All in One thermostat" has been added.

Sorry if this post is way late. Just got power and DSL back after more than 24 hours in the dark. Irene made her presence known. The ISY does not use I2 linking in Automatic mode except for those devices that only support I2. Some day it will, hopefully when all devices that report I2 actually support I2. I suspect that if the ISY moved to I2 linking for all devices that report support for I2 there would be a group of devices that no longer link correctly. Lee EDIT: sorry, I missed part of the question. Yes, I would consider devices purchased in the last year to be new devices. I do not have an inventory of every SmartLab device but the devices I have gotten lately have functional I2 linking (and I1 linking except for Motion Sensor and TriggerLinc).

TJF1960 You are definitely NOT doing anything wrong using Automatic. That is the option of choice for link management. I2 link management is MUCH faster as you have seen firsthand. Using a single command to read/write eight bytes at a time is much faster than the 17 I1 commands necessary to write one 8 byte record. The issue is that I2 linking has been an evolving implementation. Devices that said they had an I2 engine often did not actually have the Extended ALDB 2F command implemented which is the basis for I2 link management. Even devices that had a form of Extended ALDB command implemented did not always implement it the same as other devices. It is much better today. At some point it will be possible to move to I2 link management completely but I'm not sure we are there today. I have some older devices that indicate I2 engine but do not have functional Extended ALDB commands. Devices such as the Motion Sensor and TriggerLinc can only use I2 link management. The commands to support I1 linking were not implemented in those devices. In fact the I1 commands that support linking have been labeled "Deprecated (do not use in the future)" for several years. However, there is so much software in the field dependent on those commands that they continue to be available in all but a few select devices. Some products have implemented methods for identifying individual devices that should use I2 linking. It requires the user to be familiar with all the devices, what firmware level implemented I2 linking for that specific device type and be prepared to set device specific configuration information. This goes against all the ISY is trying to avoid, users having to manage that level of device specific information. For the brave and with relatively new device inventory the device specified option may work well. There are no guarantees however. Lee

Powerline problems are not isolated by the circuit breaker protecting the circuit. A device that is injecting noise or absorbing the Insteon signal on the powerline can affect more than the circuit being by protected that one breaker. Depends on how far away from the breaker panel the bad device is located. How large is the noise being generated or how much Insteon signal is being absorbed. A circuit breaker has no electronics to block noise or prevent Insteon signal absorption from affecting other circuits. Circuit breakers make good diagnostic tools at the gross level as they generally turn Off many appliances/devices. The circuit is actually broken, isolated from the rest of the electrical circuits in the house. Just turning Off devices is not always a good test as many devices keep their power supplies turned On so that IR devices can activate the device, clocks keep power to maintain accurate time, etc. Turning Off a UPS will not stop it from absorbing Insteon signals. Not all UPS devices do absorb Insteon signals but many do. I have my UPS and all the peripherals isolated with a single 10A FilterLinc. Often a single FilterLinc can be used to isolate all audio/video equipment which are located in a common place.

The FilterLinc has a filtered outlet which the appliance/device plugs into. It effectively isolates the appliance/device from the powerline, preventing noise and Insteon signal attenuation by the device(s) plugged into the FilterLinc. How much effect it has on overall powerline operation depends on how badly the now filtered device was affecting the powerline.

After all is done the only change will be the old KeypadLinc nodes Insteon address will be that of the new replacement KeypadLinc.

ingeborgdot Physically replace the bad KeypadLinc with the new KeypadLinc and add the new KeypadLinc to the ISY under a new device name. Then right click on the old KeypadLinc node entry and select Replace xxxx with .... which will display a list of devices that are eligible to replace the old KeypadLinc. Select the new KeypadLinc. The Replace with will change all references to the old KeypadLinc with the new KeypadLinc Insteon address, Scenes and Programs, and delete the new KeypadLinc entry. Lee

klundy Force of habit, it is not needed for this example. The "not Off" is used to drive the Else clause when If Control is being used. I chose to use If Status rather than If Control to prevent repeated On paddle presses from suppressing the desired email notification. The second part of the If would be needed when using If Control. Lee