LeeG

I think it is great to present alternate approaches. I happen to agree that using a separate Scene for the 8 minute Ramp Rate is the preferred approach all things considered. My concerns are justifying the alternative with inaccuracies. “By changing the ramp rate, you will not only be affecting the lights turning on by the program, but also if someone manually turns the light on during that time period. So lets say Olivia wakes up when the light is just starting to ramp up and wants full light, the only way to get the light on full brightness right away will be to go to the load switch and "fast on" it.†These statements are just plain wrong. Changing the Responder Ramp Rate of the SwitchLinc for the PLM as Controller only affects the SwitchLinc when it is a Responder to the PLM. It does not affect manual switch operation. It does not prevent a single manual paddle press from turning the light On with whatever Local Ramp Rate was established for the SwitchLinc (without a Fast On double tap). Nor does it affect turning the SwitchLinc On from another Controller if there are other Controllers of the Scene. The SwitchLinc as a Responder has a unique On Level and Ramp Rate for each Controller. Changing the Ramp Rate for the PLM Controller does not affect any other Controller of the same Scene. “But there must be multiple switches controlling that light, or there would be no need for a scene at all.†Again, a wrong statement of fact. A Scene is needed even if there are no other Controllers of the SwitchLinc. An Insteon Direct command cannot directly tell the SwitchLinc to Ramp On at an 8 minute Ramp Rate. Only a Scene with a Responder Ramp Rate of 8 minutes for the SwitchLinc can do that. It would also be informative to mention the use of the additional Scene increases the number of link records in the PLM. In an installation where the number of PLM link records is a concern the extra Scene link records could be factor to consider. The point about the extra Insteon traffic to change the Ramp Rate could be a failure point is good information and supports the use of two Scenes. It takes three Insteon commands to change the Ramp Rate for older devices. It takes one Insteon command for the newer I2CS devices. “if other Insteon/ISY activity coincides with the re-write.†Other Insteon traffic should not affect the Insteon Direct commands that change the Ramp Rate. no clue My apologies for all this additional exchange. I just hate to see factually incorrect information being relayed. I’m getting off this topic unless or until you have additional questions.

The KeypadLinc with 1C.8C.74 is missing 3 of its link records in the PLM. Need a Show Device Links Table for that device to see if it has the required E2 xx link records. The number 992 in combination with the missing last 3 link records for button F,G,H tells me the PLM is full. The varying number of PLM link records (500-700) is the result of the PLM seeing inbound Insteon traffic during the Show PLM. The ISY uses a PLM Serial command that requests the Next Link Record. The problem is the PLM alters the Next Link Record pointer to match the link record that matches an inbound Insteon message. Either groups of link records are skipped or groups are read multiple times depending on whether the inbound message matches a link record past or before the current Next Link Record pointer. That is why I indicated a Show PLM must produce a consistent result for the result to be considered accurate. The solution to the 1D.99.7F problem is to reduce the number of link records. The PLM will not pass a message on to the application (ISY in this case) unless the inbound message matches one of the Responder (A2) link records that also matches the button Group number and Insteon address of the device. Need to see a Show Device Links Table result for the other KeypadLinc to begin to analyze that. Would have thought the first few buttons would have worked if the KeypadLinc has the required link records.

I was not expressing an opinion about using two Scenes. Only that using Adjust Scene to change a Responder Ramp Rate has no affect on the Local Ramp Rate. A Scene is needed if the SwitchLinc Local Ramp Rate is one value and the Responder Ramp Rate is another. An Insteon Direct command cannot specify an override Ramp Rate. I would think the Local Ramp Rate would be faster so that fast full bright can be had with a simple paddle press. The point of the Program is to wake the person. Once up it could be desirable to turn the light On at a normal Ramp Rate, not having to learn a double tap to override an 8 minute Local Ramp Rate. The OP can decide what functions to use. It is useful to know what impact a Responder Ramp Rate setting has and what impact it does not have.

I have to interject here. Setting the Responder Ramp Rate for the SwitchLinc when the PLM is the Controller (controlling the ISY Scene with a Program) does NOT affect the Local On Level or Local Ramp Rate of the SwitchLinc. If the Local Ramp Rate is 0.2 seconds tapping the paddle once will bring the load up in 0.2 seconds. The Local Ramp Rate and Local On Level can be changed with an Adjust Scene but it has to be coded to change the Local values. Changing the Responder values does not change the Local values.

alphamale78 Run Help | About and verify both Firmware and UI indicate 3.3.3. Sounds like the UI (Admin Console) is not at 3.3.3. That is caused by not clearing the Java cache after installing 3.3.3 on the ISY and/or no using the correct URL to invoke the 3.3.3 Admin Console. I have installed a 2441ZTH successfully.

You are welcom. That will do it!

The Set Scene xxxx On has to be done after the Adjust Scene. The simple approach to turning the Scene Off is to add a Wait after the Set Scene On for the time difference between 6:21 and 9:00, with a Set Scene Off (or Fast Off if light should turn Off without the slow Ramp Down) following the Wait. Note that the Adjust Scene is changing the Responder Ramp Rate in the Responder device to 8 minutes until and unless it is changed to something different with another Program or changed with the Admin Console. If the Scene is to be used at other times with a faster Ramp Rate another Adjust Scene could be coded after the Wait or after the Set Scene Off to restore the normal Scene Responder Ramp Rate. If the Scene is always used at the 8 minute Ramp Rate the Adjust Scene(s) can be removed altogether. Use the Admin Console to change the Responder Ramp Rate to 8 minutes for that Scene.

I think something happened during your post. There is no event log. Also need the Help | About information for Firmware and UI levels

Two things. SmartLabs has changed the 9 minute Ramp Rate to 0.2 seconds on most devices. Use 8 minutes as it is hard to tell the difference between an 8 and 9 minute ramp up. Second, the Adjust Scene is only changing the Responder Ramp Rate. It is not actually turning the Scene On. Another statement is needed to actually turn the Scene On. Actually I just saw another problem. The Else will never execute. When a single explicit time triggers the Program with a True condition driving the Then clause, nothing triggers the Program Else clause.

Looks that way. The only way that would have worked here is if a missed Deleting the Primary EZX10RF node. The ISY determines the link database size/location only for the first node. That EZX10RF was added to the ISY more than a year ago. If I missed the first node the ISY would already know the size/location of the link database. I will repeat the test hear making sure I Delete all the nodes. I thought it strange that the Add X10 Device to EZX10RF worked because I thought it was the same path as New INSTEON Device. I'll post back the results of my next test. The only option would be to go back to 3.2.6 and add the EZX10RF back there. The problem with that option is the ISY configuration data was changed at 3.3.3 making it incompatible at 3.2.6. I would be necessary to restore a 3.2.6 backup to use the 3.2.6 firmware.

There is a known problem at 3.3.2 and 3.3.3 adding non-I2CS SHN devices. Will be resolved in 3.3.4 but have not seen a target date for that Beta. I was able to add the EZX10RF using Link Management | Add X10 Device to EZX10RF. I was running tests to double check that the ISY had no X10 code information. It does not. However, in running that test I Deleted the EZX10RF with the v.1C firmware and added it back successfully using Add X10 Device to EZX10RF function.

The EZX10RF screen image does not cover the link records. That information relates an X10 RF code to a Group/Scene number. The other half of the information is the link database itself which must match the X10 codes defined.

There are 12 nodes for the EZX10RF currently in the My Lighting tree and the Show ISY Links Table is blank? The EZX10RF receives X10 RF messages, converting them to Insteon powerline messages. These Insteon messages can be used to control other devices directly by linking an EZX10RF X10 node as Controller of an ISY Scene with no ISY Program intervention. Of course the Insteon message can trigger an ISY Program. If you have an X10 RF receiver other than the EZX10RF the X10 codes on the powerline can be used to trigger ISY Programs. X10 powerline messages cannot be used to directly control an Insteon/ISY Scene. My experience with X10 and Insteon has shown Insteon messaging to be far superior to X10. The ISY can be used to restore the EZX10RF link database. Your situation of having nodes defined with a blank Show ISY Links Table is an issue of unknown cause at the moment. It would be nice if the ISY could restore the X10 code information. There are many things on the ISY requirements list that have not been implemented to date so you can request that function be added. If there are EZX10RF nodes in the My Lighting tree now with nothing in the ISY Links Table information those nodes should be deleted before defining the X10 codes. Otherwise the Scene/Group numbers the EZX10RF uses for each new X10 code could be out of sync the link records that are built. You mentioned that UDI tech support helped rebuild the other devices. What happened the required that effort. Perhaps that information would help explain how you have EZX10RF X10 nodes without link information.

Theoretically yes. Do a Show ISY Links Table for the EZX10RF which will display the link records the ISY thinks should be there. That does not restore the X10 specific code information if that has been reset.

Try a right click on the KeypadLinc Primary node, select Diagnostics | Query Insteon Engine. If that does not resolve run Tools | Diagnostics | Event Viewer at Level 3. With trace running do another Query Insteon Engine. Then change the LED level and post the event trace. What does Help | About show for Firmware and UI?

Look at the ISY Log. It should show changes in mode and whether the change originated at the device or by the ISY (would have to be an ISY Program). EDIT: these are Log entries as I pressed the Mode button on my 2441TH 2441TH - Main Thermostat Mode Auto Thu 2012/11/01 08:45:50 PM System Log 2441TH - Main Thermostat Mode Off Thu 2012/11/01 08:46:06 PM System Log 2441TH - Main Thermostat Mode Heat Thu 2012/11/01 08:46:10 PM System Log 2441TH - Main Thermostat Mode Cool Thu 2012/11/01 08:46:31 PM System Log

Great news. You are absolutely correct, the more new devices installed the better the overall network responds because each new device is now a repeater of Extended commands. I have many old devices as I started with Insteon near the beginning of Insteon. Decided to start replacing the old stuff with new SwitchLincs and ran into the paddle color mismatch. Now I am stuck because I cannot replace the old I1 ICONs with new SwitchLincs because the paddle color does not match anything else. Not every switch I have is Insteon. Some switches did not make sense to be changed to Insteon so I have several manual paddle switches that would not match the SwitchLinc alongside it and the cover plates do not match. Got to love SmartLabs and Smarthome!

Happy to. The lower left corner of the Admin Console page has a Green flag and the word Ready when a function completes. There should also be a Progress Bar. Not to everyone’s taste but I keep the event viewer up on Level 3 when running functions like a Restore or Update. One might not understand what all the Insteon messages represent but it does show activity as it happens. Great to hear!

With the event viewer tracing some data it is not an AV or firewall issue. The Restore Modem (PLM) is the thing to do. Link records in the PLM are necessary for the PLM to receive messages from devices. Not likely that every device lost its link database. The PLM link database is the common factor across all the devices. Do not put any of the RF devices into linking mode. Putting multiple RF devices into linking mode cancels each other’s linking mode. The ISY may not attempt to write to any of the RF devices. If it does they will fail with the updates being queued. If updates are queued to the RF devices after the PLM restore is complete put one RF device at a time into linking mode and select Write Updates to Device. When one RF device update is complete go to the next.

Verify that NO device will register a state change. If this is correct, run Tools | Diagnostics | Event Viewer at Level 3. Using the Admin Console turn a device On/Off. Does the Event Viewer show the Insteon traffic? If yes try a Restore Modem (PLM). If nothing is posted in the event viewer it is an AV or firewall issue. Perhaps the IP address for the ISY changed and AV or firewall is blocking traffic being pushed from the ISY to the Admin Console.

Sounds like the link database has been compromised. Put the RemoteLinc2 into linking mode with its Set button, right click the RL2 Primary node (button , select Restore Device.

The TriggerLinc has a connection for an external switch. Magnetic switches are water proof. Mount a magnetic switch where needed and run a pair of wires to a protected location containing the TriggerLinc itself.

Can you post the Program?

The new ToggleLinc is I2CS, confirmed from the Event Trace. An I2CS device only supports the use of Extended length commands for link database management. I2CS devices have dropped the Peek/Poke Standard commands used by most devices for link database management. SmartLabs does not publish documentation covering what devices at what firmware support I2CS. I am assuming since the older ToggleLinc works at the same location it is not an I2CS device. The older devices us Standard length commands for link database management. The procedure I described in my previous post tracing a Query Insteon Engine will confirm the older ToggleLinc is not I2CS. When Standard length commands work and Extended commands do not the Insteon mesh network is not passing Extended length commands to the same degree as Standard length commands. Older devices do not know about Extended commands. They do not block them but they do not repeat them either which generally reduces the reliability of Extended commands when there are older devices involved. The Access Point being a few feet away really does not mean anything since the ToggleLinc is not a Dual Band device. If the Access Point is powered from the opposite 120V leg the Extended messages would have to travel a much longer distance than 6'.

viewtopic.php?f=27&t=9659