LeeG

"Adjust Scene ‘put the name of scene that has 2440's as controllers and load switch as responder(or controller/responder)’" That is the right answer when using the ISY Scene name. Unfortunately that is the wrong answer for the OP as the ISY Scene name is not what is being used in this case. The RL2 button is the Controller and that is the name that has to be entered into "In Scene" parameter. Also, regardless of what was entered into an Adjust Scene parameter the Adjust Scene statement does not turn On the load. That is why we need to see the actual Program posted.

Post the actual Program. Right click the Program name, select Copy to Clipboard, paste into forum post. Adjust Scene does not turn On the load. It sets the Responder On Level for when the respective Controller identified in the Adjust Scene turns On the load. The described results do not match the function of an Adjust Scene. Make sure there is not a pending Save for the Program.

A Serial PLM cannot be accessed through a USB port. There are USB to Serial adapters but not all work well with a PLM. Does the Device Manager show anything connected to a COM port when the PLM is connected directly to the PC serial port. Although normally COM1 perhaps it is coming up on a different COM number.

From an ealier post by UDI Yes you can and it's as easy as you have described it. The precise instructions are here: http://wiki.universal-devices.com/index ... r_ISY-994i Link to topic is below viewtopic.php?f=27&t=11802&hilit=99i+to+994i

I also installed Java update 45 and am having issues access my ISY. Not at all sure the two are related but it is odd as I have never had an issue access the ISY before.

Blinking Red indicates it is receiving the RF test message from the PLM and it is plugged into the same 120v leg as the PLM. Blinking Green indicates it is receiving the RF test message from the PLM and it is plugged into the opposite 120v leg as the PLM. This is the desired result to achieve coupling using the PLM and that Access Point. If using two Access Points to couple start the 4 tap test on one of the Access Points and look at how the other reacts. The test should be done in both directions. Not blinking means it is not receiving the RF test message from the PLM. Could be the 4 minute test time has expired or it is out of RF range of the PLM.

There should be a single ISY Scene. All three SwitchLincs should be Controllers of the single Scene. The ISY assumes Controllers are also Responders so adding all three SwitchLincs as Controllers is all that is necessary. Click each Red Controller node name (should be three of them) listed below the ISY Scene name. Each Controller should have two Responders. Set each of the Responders for all three Controllers to the desired On Level and Ramp Rate. The Local On Level and Local Ramp Rate apply to the specific SwitchLinc that has been selected as Controller. The SwitchLinc where the paddle is physically pressed reacts based on its Local values. The other two SwitchLincs which are Responders to the Controller where the paddle is physically pressed react based on the Responder On Level and Responder Ramp Rate defined for that specific Controller. Master SwitchLinc as Controller – Local On Level, Local Ramp Rate Slave SwitchLinc1 as Responder – On Level, Ramp Rate Slave SwitchLinc2 as Responder – On Level, Ramp Rate Slave SwitchLinc1 as Controller – Local On Level, Local Ramp Rate Master SwitchLinc as Responder – On Level, Ramp Rate Slave SwitchLinc2 as Responder – On Level, Ramp Rate Slave SwitchLinc2 as Controller – Local On Level, Local Ramp Rate Master SwitchLinc as Responder – On Level, Ramp Rate Slave SwitchLinc1 as Responder – On Level, Ramp Rate

In Insteon each Controller has a unique set of Responder values. Click on the Slave SwitchLinc node name below the ISY Scene name. Set the appropriate Responder On Level and Ramp Rate values for the Responders (one of which will be the Master SwitchLinc).

Use the Adjust Scene statement to change the Scene Responder On Level If From 12:01 AM To 6 AM (same day) Then Adjust Scene ‘In Scene=RL2 button’ ‘Set=SwitchLinc’ 30% (On Level) Else Adjust Scene ‘In Scene=RL2 button’ ‘Set=SwitchLinc’ 65% (On Level)

Sorry but I don't know it that will work with what Smarthome is now shipping in the 2413S. It worked a few years ago as I tested it here with one of my EZIO8SAs but the 2413S firmware has been updated a few times since then. I think I saw a post that has the latest 2413S at v.9D. Also Smarthome does not allow you to pick the firmware of the device.

Click the Keypadlinc button node name below the Scene name and set the appropriate Responder values. It sounds like the "Scene" Responder values have been set. The "Scene" uses the PLM as the Controller. Each Insteon Controller has its own set of Responder values. By clicking the KPL node name below the Scene name the Responder values for that Controller will be displayed.

"yes everthing is on the same side of the bus" Sorry I do not know what this means. Confirm that the PLM is NOT connected to the ISY through an Ethernet patch panel. The PLM is connected to the ISY with a Serial connection, not an Ethernet connection. A Serial port has a much more limited cable length than an IP connection.

There are hundreds of users that work fine. With multiple PLMs doing the same thing, multiple short cables (3-5' range) doing the same thing, there is something about your configuration that is unique. You do have 120v 60 cycle power? Look at the Port A RJ45 jack on the back of the ISY. Are any of the gold wires inside the RJ45 jack out of position?

Appears nothing has changed from when Tech Support worked with you. The RX LED On solid indicates the ISY cannot communicate with the PLM. That is confirmed by Safe Mode as that is what happens to the ISY when it cannot communicate with the PLM. If Tech Support has not already suggested try a different short cable between the PLM and Port A. After connecting with a different cable reboot the ISY. Is the LED on the side of the PLM On? The PLM is a 2413S (Serial), not a 2413U (USB). If the PLM LED is On, it is a 2413S, and a new cable does not resolve you need to go back to UDI Tech Support. There is nothing more to try.

Not sure why activities were attempted without a PLM. Once the ISY was booted up without a PLM just connecting the PLM is not helpful. The PLM should be powered. Then boot the ISY. After the ISY has had an opportunity to complete the boot process… What LEDs on the front panel are On before starting the Admin Console? How many LEDs are On at the rear RJ45 jack connection to the router? Does the router show an IP address has been assigned to the ISY?

Without having identified the cause it is hard to suggest a solution. I would try a Restore Modem (PLM). It does not take a lot of time and if things work then the problem has been identified as a PLM link record problem. I know of nothing at the PLM level that would have affected RF device responder link records only.

drkair It sounds like the PLM lost link records. Suggest checking if other non RF devices such as SwitchLincs or KeypadLincs show state changes. If they do not show state changes do a Restore Modem (PLM) to rebuild the PLM link database. It is highly unlikely to be an issue with the Motion Sensor links as those devices sleep making it impossible for the ISY to have written anything to the Motion Sensors nor would they be exposed to powerline glitches or outages.

NeilP Thanks for the update. That explains the results. With the information ELA provided earlier the issue is that an EZIComm with 9C firmware does not identify itself as having an I2CS Engine even though in a 2413 Dual Band shell. PLM firmware 9B does identify itself as having an I2CS Engine. Apparently Aartech has an inventory of EZIComm devices with 9C firmware. Likely if the EZIComm was functioning as a PLM in the context of an application interface using the Serial interface it would not make any difference. I issue I2CS messages through the Serial interface of PLMs that came out long before I2CS. That works fine. It is when the EZIComm is being used in the context of an internal PLM in an external package (like connected to an EZIO8SA) where knowing whether to use Peek/Poke or ALDB (is it I2CS) is critical. They may have to carry two versions of the EZIComm. One where it will function as a true external PLM where 9C firmware (or later) is desired as it should have the latest maintenance, and a version that is meant to run as an internal PLM with the EZIO8SA where how it identifies the Insteon Engine is critical. Update: the more I consider the EZIComm the more I realize it is no longer necessary to have a 2412/2413 replacement as far as an application interface. In the beginning the EZIComm could be used as a 2412S replacement when SmartLabs discontinued the 2412S. Now that the EZIComm is built on a 2413S shell there is no need for a 9C firmware level EZIComm. Logically that would be in competition with a standard 2413S. Loading the EZIComm with 9B firmware so it will work with the EZIO8SA is all that is needed from Smartenit.

If the value in the variable is of any importance look into setting the variable Init value at the same time the variable value is changed. Should the ISY reboot due to a power outage etc the variable Init value is what the variable value is set to during the restart.

Click the Primary node. What is displayed on the right side for the device type and firmware level? What ISY firmware is being used? Click Help | About, what is displayed for Firmware and UI?

The worst aspect of all this is the ISY will correctly write the link records if SHN left the PLM as an I2CS PLM. Michel went out of his way to make sure the SHN I2CS devices were correctly handled. Although there is nothing the ISY can do about the fact that the SHN device firmware does not implement the I2CS protocol.

II do not know what is being shipped now days. Initially they were 2413 shells with I2CS Dual Band PLMs. I have some that are true I2CS PLMs requiring the ALDB command for link management. The problem was SHN was not expecting this situation and had no plans to update any of the SHN device firmware to meet I2CS requirements. Thus the reflash activity to eliminate I2CS. I was not aware that some of the reflashed units (like yours) still identified themselves as having an I2CS Engine as that seems to defeat the purpose of the reflash to begin with. The effort to eliminate I2CS has not changed as far as I know. I'm still maintaining the Utility so if there was an active effort to update the device firmware to I2CS standards I should know about it as the Utility will need changes to move to all Extended commands for device configuration. Additional: The v.FF is what the EZIO8SA is reporting as the device firmware level in a command response that carries the cat/subcat (device type) and firmware level. That is the way the ISY pulls the device firmware level for all Insteon devices. The SHN Utility is pulling the firmware level from the PLM using a PLM specific serial command. The actual device firmware displayed by the Utility should be v.28 which is pulled from the EZIO8SA using an EZIOxx family device specific firmware. All clear as mud?

It does not appear the questions will be answered so there is nothing more I can do. Good Luck.

The difference is the latest EZIComm is reporting an I2 Engine rather than an I2CS. This forces the use of the SmartLabs algorithm rather than the I2CS technique for determining link database start address. Below is the Query Insteon Engine from the user trace. Sat 10/05/2013 09:08:21 AM : [iNST-TX-I1 ] 02 62 1E 7C 24 0F 0D 00 Sat 10/05/2013 09:08:21 AM : [iNST-ACK ] 02 62 1E.7C.24 0F 0D 00 06 (00) Sat 10/05/2013 09:08:21 AM : [iNST-SRX ] 02 50 1E.7C.24 25.13.F8 2B 0D 01 (01) Sat 10/05/2013 09:08:21 AM : [std-Direct Ack] 1E.7C.24-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Log in to the router/modem. It should list the local IP addresses in use and the MAC address of the device assigned 133. The Host Name may also give a clue.