LeeG

deirwin From the cmd2 values I think the SwitchLinc was turned On at 08:48:57 Sun 04/03/2011 08:48:57 PM : [iNST-SRX ] 02 50 0D.2D.38 00.00.01 C7 27 FF (FF) And turned Off at 08:55:32 Sun 04/03/2011 08:55:32 PM : [iNST-SRX ] 02 50 0D.2D.38 00.00.01 C3 27 00 (00) I doubt the Admin Console will reflect the fact that the SwitchLinc was turned On/Off manually because of the unusual Insteon command being used to control the “companion†device. Since the SwitchLinc thinks it has a “companion†device, that companion device may also be controlling this SwitchLinc. Tom Can you shed any light on a SwitchLinc companion package from years ago (firmware is v.27 so the SwitchLinc would seem to be vintage). Lee

deirwin I’ve been using Insteon almost from the beginning of Insteon. The basic structure of the commands being traced indicates a “from†device address of the SwitchLinc in question. That normally indicates the SwitchLinc paddle is being pressed but the command being sent (0x27) is not the normal command for a simple paddle press (unless related to some package of “companion†switchlincs). Can you cover the ELK motion sensor (I assume it is not the Insteon motion sensor) so that it cannot signal motion to eliminate the ELK as the source of the SwitchLinc changing On levels? Lee

deirwin Well that is an Insteon command I have never seen used before. It is a Light Set Status (0x27) that “Updates SwitchLinc Companion’s LEDsâ€. Is that SwitchLinc part of a special package order that included multiple SwitchLincs that are prelinked together? The 0x27 command is not normal Insteon device to device control of individual devices. Lee

deirwin Very possible. If the device is being commanded from the ISY it is easy to determine. Run Tools | Diagnostics | Event Viewer with Device communications events selected. Walk past the motion sensor to trigger motion. The Event Viewer will trace any Insteon commands sent by the ISY to the SwitchLinc. If the event viewer trace is not familiar save the file and copy/paste the trace. I can interpret (need SwitchLinc Insteon address). If the ELK is doing it all on its own (I don't own an ELK so not familiar with its capability) that would not show up. Lee

deirwin I just ran tests with a SwitchLinc Dimmer hardware sticker v5.15 firmware v.38. Changing the Local On Level and Local Ramp Rate DO NOT take effect until the SwitchLinc is power cycled (AC power removed). This can be done by turning the circuit breaker Off/On or pulling the Air Gap switch to remove power from the device. The SwitchLinc should be left off for 20/30 seconds before restoring power. If the Air Gap switch is used be careful to push it FLUSH only with the SwitchLinc frame. If pressed too far in a factory reset can be done. Lee

Michel I would like to try the Venstar but am holding off until that issue is resolved. I don't think the motion sensor was hung up due to a firmware issue. RF communication could have been block because of a tstat flooding the RF spectrum but it is not clear that is what is creating the tstat problems. There was one user who reported a linking issue with a motion sensor that was resolved by unplugging the tstat dongle. That sounded like the dongle was interfering with RF communication in general. It would take multiple users reporting RF problems solved by unplugging the dongle before I would give that conclusion much merit. Too often a particular solution is given attribution for solving a symptom when something else actually changed at the same time. Like a rooster crowing causes the sun to rise. Often happens that way but not causal. Dongle RF interference is an interesting theory though and should be watched. One of those diagnostic tools (unplugging the dongle) that can be tried when RF communications is suspect. Lee

iostream212 I was using a non Dual Band LampLinc. Some devices recognize that the memory locations have been changed and immediately switch to the new values. Other devices (including other than LampLincs) require the firmware in the device to be rebooted (power cycled) to pick up the new changes. Any time a configuration change is made that does not take effect, often a power cycle will resolve. Responder values for On Level and Ramp Rate do not require a power cycle as the link records that are being changed by the ISY are retrieved by the device each time the device is reacting as a responder device. It is the Local configuration data that may require a power cycle. Lee

oskrypuch I pulled the following explanation from the User Guide Apply Changes To All Devices. This option will merge all Responder sliders to one slider to make bulk changes easier. For example, if you want all responders in a scene to turn on to 50%, simply check the Apply Changes To All Devices option and drag the single slider to 50%. Copy Scene Attributes From... As noted above, the ISY itself is also a controller of every scene. If a controller within a scene should use the same values as the ISY uses when controlling a scene, simply click this button to copy the values from the ISY over to the currently selected Controller. Lee

iostream212 I cannot confirm the results you are seeing on 3.1.1. I set the ramp rate on a LampLinc as a responder to a RemoteLinc button to 19 seconds. The LampLinc ramped up over 19 seconds when turned On with the RemoteLinc button. I set the LampLinc Local Ramp Rate to 8.5 seconds. Turning the LampLinc lamp On using the lamp (load) On switch and turning the LampLinc On through the Admin Console both have the expected 8.5 second Ramp Rate. It was necessary to power cycle the LampLinc for the Local Ramp Rate change to take effect. This is a characteristic of the LampLinc, not related to 3.1.1. What type of LampLinc are you using and what is the firmware level? Lee EDIT: this test was run on a 2456D3 with firmware v.33

dnl I agree completely that the reboot did not cause the motion sensor to stop sending motion messages. The reboot only explains why the motion and dusk/dawn status was blank. The low battery Off status does not indicate the state of the battery in this scenario nor does the Query. The ISY sets the low battery status to Off when it reboots. I could be many months before a motion sensor sends a low battery message so instead of leaving the low battery node blank for months it is initialized to Off during reboot. The motion sensor is asleep under most circumstances. The ISY understands a motion sensor device is asleep and will not actually issue the Query command as it is expected to fail. Should a motion sensor actually send a low battery message the method used to reset the low battery node from On to Off status is to select Query. Selecting Query simply resets the low battery node to Off without ever actually communicating with the motion sensor. Otherwise there would be no way to reset the low battery node from On to Off without rebooting the ISY. A motion sensor does not send a low battery Off message when a fresh battery is installed. The lack of actual device communication with Query can be confirmed by running the Event Viewer with Device communications events selected and click on Query. No Query command is actually sent to the motion sensor. The ISY simply marks the low battery node Off without communicating with the motion sensor. I would replace the battery in the motion sensor. Once it has sent the low battery message when the battery voltage drops below a certain threshold it does not send any more low battery messages. The low battery On status was lost when the ISY was rebooted. A search of the various forums will show a motion sensor will stop sending motion messages when the battery gets too low and they have been known to flood the system with false motion messages under the same conditions. Lee EDIT: another means of verifying the low battery node Off does not really reflect the condition of the battery, remove the battery from the motion sensor. Reboot the ISY, the low battery node will display Off even though the sensor and dusk/dawn nodes are blank. Click on Query, the low battery node will indicate Off. Obviously the low battery node Off status did not come from the motion sensor with the battery removed.

dnl The ISY would remember the last Motion Sensor status even if the Motion Sensor stops sending motion messages. For motion and dusk/dawn to be blank it sounds like the ISY was rebooted, perhaps due to a power interruption. Because the Motion Sensor is asleep it cannot be queried for status after an ISY power cycle so the motion and dusk/dawn will be blank until the motion sensor sends messages for either of those conditions. The battery in the motion sensor could be low or something is interfering with RF messages. The Dual Band device the motion sensor normally communicates through could be unplugged or lost power if a wired device. Once the Motion Sensor signals battery low it does not constantly repeat the message. When the ISY was restarted and lost current motion sensor statue it would have lost any low battery indication as well (I think). The low battery node is set to Off after an ISY restart. Lee

There was a time when 32 bit Java had to be instslled along with the 64 bit Java on a 64 bit machine. Don't know it that still applies.

thruster999 Some results and some open issues. First, the device link database initially displayed at the beginning of the last post looks correct except for the fact that the On Level and Ramp Rate changes made by the Program Adjust Scene have not been made. This explains why the dimmer is responding to On/Off commands from the motion sensor at full On and at the fastest ramp rate as that is what the link record indicates should happen. The green Icon noted in the last post indicates updates are pending for the dimmer. Usually indicates an attempt to talk to the device at some point failed so the updates are queued until the device can be accessed. The “Event Log Post fail:â€, is that a trace of the Program to Adjust Scene to the lower On Level and slower Ramp Rate? If so then nothing was written to the dimmer. The writing 0 bytes messages mean the ISY does not have changes to make to the device. First of the unknown! The Show Device Links Table after the recovery process is the next unknown! The “0FC8: E2 01 13.22.8F FF 1F 00†displayed in the last post, pre recovery process , is missing in the post recovery process Show Device Links Table. The fact that the Compare did not indicate it is missing is not good. It means the ISY does not think it should be present. This link record is used by the dimmer to send status updates to the ISY PLM. Without it the ISY will not know if the dimmer is turned On or Off at the dimmer. The good news is the post recovery process Event Log does show the expected On Level and Ramp Rate changes to the link records being written to the dimmer. Although things appear to be working post recovery process there are problems. Suggest running the Show Device Links Table again and see if the “E2 01 13.22.8F FF 1F 00†link record displays. If not the device link database was not recovered successfully. The lack of attempts to actually write the Adjust Scene values pre recovery process, the Compare that would not work before the recovery process, the missing link record post recovery process and the fact the Compare does not indicate it missing, are all suggestive of a problem with the configuration data now. With the green Icon present at the beginning of all this I’m concerned that there is an intermittent communication problem that backed up a bunch of Adjust Scene updates which may have lead to the corruption of configuration data. Try a Restore Device for the dimmer and see if the missing “E2 01 13.22.8F FF 1F 00†is restored. If this cannot be recovered the only way I know to fix it is to Delete the device and add it back. Of course this is going to impact Scenes and Programs. You could just ignore the missing link record and not have the ISY know when the dimmer is operated manually. Ignoring things like this have a habit of coming back to bite you later on. Lee

thruster999 I’ll go through all the great data. Thanks A quick question, is “SF Pool Table AP 18.03.EF t†an Access Point or the dual band dimmer? Lee

thruster999 Thanks for the additional information. With the Motion Sensor motion turning On/Off the switch the link in the switch must be intact (despite the error message text). An Insteon switch will not respond unless it has a responder link record that matches the Controller address and Group number. The errors may be a reflection of the ISY configuration information being incorrect rather than the actual switch itself. I had assumed the condition where the link was not being updated still existed (bad thing to do, assume). Next time it happens run a Tools | Diagnostics | Show Device Links Table. This will give us an accurate image of what is in the switch. A Compare (when the Show completes) after that will show what is in the switch versus what the ISY thinks should be there. Also the Tools | Diagnostics | Event Viewer with Device communications events selected run when the Program is run to update the link record (Adjust Scene) will show what the ISY actually did in response to the Program Adjust Scene statement. I’m thinking something is blocking the writes to the switch or the ISY is not trying to write the link updates because the configuration information in the ISY is corrupted. Check if there is an Icon to the left of the switch node in the My Lighting tree indicating writes are pending for some reason (next time if fails). The fact the situation has occurred over different ISY images and various devices has the earmarks of a powerline problem but the symptoms do not sync up with that type of failure. A failure to communication with a device usually results in an Icon to the left of the device node and can be cleared with a Query. Also the collection of symptoms seem to indicate a configuration data issue rather than a device communication problem. Perhaps some of the Program initiated configuration updates are creating a conflict between themselves. The next set of diagnostic information should point to the nature of the problem even if it does not provide the immediate solution. Lee

thruster999 I ran that example on 3.1.1 with success. The Responder Ramp Rate was changed correctly by the Program with an Adjust Scene where the Motion Sensor Sensor node is the In Scene value and an ICON Dimmer is the Set device. What ISY image are you running? Can you run Tools | Diagnostics | Event Viewer with Device Communications Events selected and run Program that adjusts the responder On Level or Ramp Rate. Lee EDIT: note that the Adjust Scene which changes the responder On Level or Ramp Rate is not changing anything in the Motion Sensor so the Dual Band device locations do not matter. The On Level and Ramp Rate are values stored in the responder link record. If this is an issue updating a device it is the responder switch that is in question. EDIT2: the In Scene field identifies the Controller which really identifies the link record in the responder to update. Selecting the Motion Sensor Sensor node indicates the link record in the switch associated with Group 1 Motion Sensor device is updated. Selecting the Scene name in the In Scene field identifies the link record in the responder associated with the ISY PLM.

Sure. A KPL button in toggle mode toggles between Fast On and Fast Off with quick double taps, just as it toggles between On and Off with a single tap. A double tap to a paddle always sends Fast On or Fast Off depending on which part of the paddle is taped Tap speed is important. Too slow and two On or Off commands will be sent. If there is any question about which command is flowing the Tools | Diagnostics | Event Viewer with Device communications events selected show the command being issued. A Fast On is a 0x12 (versus 0x11 for On), a Fast Off is a 0x14 (versus 0x13 for Off). The annotation by the ISY as to command will also reflect an On/Off versus Fast On/Fast Off. Tue 03/29/2011 02:02:30 PM : [iNST-SRX ] 02 50 0B.4A.AD 00.00.07 CB 11 00 LTONRR (00) Tue 03/29/2011 02:02:36 PM : [iNST-SRX ] 02 50 0B.4A.AD 00.00.07 CB 12 00 LTON-F (00)

If you already have the flood lights linked to an Insteon switch/KPL simply double tap switch/KPL to send a Fast On. It is the Fast On/Fast Off that overrides normal operation of the sense line. As in your example the Fast On can be sent as the command to the specific device or as a Scene command. Not sure why the Repeat. It should not be necessary.

Only regarding the point of turning a KPL button On/Off with a Program, this has to be done with a Scene where the KPL button is a responder. A KPL Secondary button cannot be turned On/Off with an Insteon Direct command.

The 2412S PLM supports 2000+ links, the 2413S supports 1000+ links. Only a factor in very large installations and/or with many Scenes. The 2413S has a faster processor but not likely will make any difference in day to day operation. The 2412S provides 12V DC to power the ISY, the 2413S does not. The 2413S is a Dual Band device (RF communication as well as powerline), the 2412S is powerline only. As far as the primary function of allowing an application to communicate with the powerline they are identical devices with identical command sets. An application issues the same commands whether a 2412S or 2413S. Many applications do not know whether using a 2412S or 2413S PLM. These are the two PLMs that work with the ISY for Insteon support.

deirwin What type of load is being controlled by the SwitchLinc Dimmer? Check the wiring to be sure the line, load and neutral are correct. Lee

andyf0 This can be ignored when using a RemoteLinc and any other RF only device such as a Motion Sensor or TriggerLinc. RF only devices send multiple Group Broadcast messages (2 or 3 total). The ISY trace is indicating multiple Group Broadcast messages are received with the extra ones are being ignored. Wired devices send one Group Broadcast message (per Insteon protocol). Lee

The Admin Console Event Viewer (Tools | Diagnostics | Event Viewer) with the Device communications events option selected provides the most detail available. With a 10 second interval between the Scene running and the device status of Off there may be another Program that is being triggered by the change in device(s) status. You can also right click on the Scene name and run a Diagnostics | Scene Test. This test is more extensive regarding Insteon commands issued. If another Program is causing the problem the other Programs can be disabled to see if the problem stops.

Sounds like a good idea. I agree that the difference between a 9 minute and 8 minute ramp up is not perceptible.

Avonlea22 Smarthome/Smartlabs are constantly adding/removing/tweaking function of the Insteon devices. The Smarthome user forum is a good place to frequent as rarely is any official statement made from Smarthome regarding changes. Lee