LeeG

Michel Not the beta. I went back to the Official 3.2.6 because I was sure this worked. It is fine when the Controller buttons are actual KeypadLincs. I had a Scene with two different KeypadLincs used to control the FanLinc Scenes. All the Secondary Responder buttons are displayed and can be set to 0% On Level. Using either KeypadLinc all the buttons stay in sync, both on the KeypadLinc where the buttons are physically pressed and on the second KeypadLinc. This was the work you did ahead of 3.2.6. The glitch is if a RemoteLinc2 (RL2) button is added to the Scene as an additional Controller, selecting the RL2 Controller button does not present the Secondary KeypadLinc buttons on the two KeypadLincs. Cannot set the Secondary KeypadLinc buttons to 0% On Level so all the KeypadLinc buttons come on when the RL2 button is pressed.

Make sure the static IP address is outside the router DHCP range. Otherwise the conflict could happen in the future as additional equipment is added that uses DHCP.

Confirmed. A RemoteLinc2 button as Controller does not allow the KeypadLinc Secondary buttons to be set to 0% On Level. I have Secondary buttons as Controllers for 2 different KeypadLincs in the same Scene and they do present the other Secondary buttons such that the On Level can be set to 0%. Looks like an issue associated with the RemoteLinc2 device type definition.

What is the KeypadLinc firmware level? A secondary KeypadLinc button cannot be turned Off from another Controller with a Scene On until KeypadLinc firmware v.40. Also what ISY firmware level is being used?

If all the devices on the LAN were setup for DHCP there would not be a conflict. The ISY IP might change but things would be functional. The error popup when the PC was rebooted tells me the network has a conflict which must be resolved. Perhaps the PC has a fixed address that was fine until the ISY was added and now the router is assigning a valid DHCP address that now conflicts with something else like the PC. I do not know enough about this to give good advice on solution except that there is a problem that will very likely surface again until the network conflict is resolved. I have run with DHCP for 3+ years with no problem so I don't think a static IP is an absolute but again I'm not the expert.

I think the ISY has been assigned an IP address different from that initially. It probably conflicted with the PC IP address which is why the error popup when the PC was rebooted. You could try other nearby IP addresses. For example, if using http://192.168.2.5/ try http://192.168.2.3/, http://192.168.2.4/, http://192.168.2.6/, http://192.168.2.7/. If the ISY was configured with a static IP which has been assigned to another device on the network the ISY will not be reachable. I suggest opening a Ticket with UDI tech support so they can resolve the configuration conflict.

It should identify the IP address assigned to each device on the LAN. Since the PC indicated a conflict when rebooted the conflict could be between the ISY and the PC. Either way the IP address assigned to the ISY should be indicated.

I do not have the network skills to guide you through logging on to whatever modem/router you are using.

You can also try http://www.universal-devices.com/99i/admin.jnlp which will display a popup window Insteon Finder which will have the IP address of the ISY. The Insteon Finder window may be under other windows. Minimize each active window until the Insteon Finder winder is visible. It sure sounds like the IP configuration is in conflict.

Could be multiple devices trying to use the same IP address. Is the ISY configured for a static IP? Check the router to see what devices have been assigned what IP address.

When using a From/To time range the If is True once at the From time which drives the Then clause once and False once at the To time which drives the Else clause once. The Program is not running at any other time. Your posted Program If is True at Sunset -30 minutes which runs the Then clause once, turning the lights On to 100%. At 10:30 PM or 1:00 AM the If is False which runs the Else clause once. My posted Program is True at 10:00 PM which runs the Then clause once to dim the lights to 50%.

If Time is 10:00:00PM Then Set '05.D0.EB.1' 50% Else - No Actions - (To add one, press 'Action') The above is a separate Program. Ifs cannot be nested. To turn the lights Off add this to the Else of your posted Program Set '05.D0.EB.1' Off

You are removing power and disconnecting the cables before switching SD cards.

Only once. Before moving to 3.2.6 the Insteon Engine level for that specific device was lost. The Query Insteon Engine refreshes the information. Once on 3.2.6 with refreshed information it should be fine.

Bring up the Admin Console, the My Lighting tree is all the device nodes in the left Admin Console window pane.

Right click on the LampLinc node in the My Lighting tree. Select Diagnostics | Query Insteon Engine. Select the LampLinc node and change the Ramp Rate to something else. When the Progress Bar goes away change it back to 4 minutes. When Progress Bar completes test the Program. If that did not work, run Tools | Diagnostics | Event Viewer with Level 3 selected. Change the Ramp Rate to something other than 4 minutes. Then change it back to 4 minutes and post the event trace. What is the exact LampLinc device type?

How are you setting the Ramp Rate? The Ramp Rate cannot be affected using Insteon Direct commands. The LampLinc has to be a Responder in an ISY Scene, setting the Scene Responder Ramp Rate for the LampLinc. Then turn the Scene On.

Remember that when coming up with a new SD card the ISY and associated configuration are gone. The IP address for telnet could be different, the Admin Console must be pulled from the UDI web site because it is gone, the ISY firmware has to be reloaded because it is gone.

The SD card should be installed. Telnet to ISY to format SD card. Invoke Admin Console from UDI web site. Manually update ISY image. Which of those steps is not working and how is it failing?

SmartLabs changed the 9 minute ramp rate definition to respond as 0.2 seconds. EDIT: the rationale behind that change has to do with the fact that a 9 minute ramp rate definition is a 00 value. If the ramp rate was never set for some reason such that the ramp rate value remained at 00 it looks like the device failed to react to an On command when it is actually just taking 9 minutes to turn On. Visually there is little difference between an 8 minute ramp up and a 9 minute ramp up but it apparently reduced the number of support calls Smarthome was getting.

When the magnet is moved away from the TriggerLinc an On command is sent. When the magnet comes back to the TriggerLinc it sends an Off command. The TriggerLinc On/Off results are what is desired when using a magnetic switch. The external switch is mimicking the results of the magnetic switch. You can either write the Programs to match the operation of the TriggerLinc or use a NC external push button to reverse the commands. EDIT: the Programs are written as though pressing the button one time produces a result which is different from pressing it the next time. As though the first press turns the TriggerLinc On and the next press toggles it Off. It does not. The TriggerLinc sends the same Off/On commands each time button is pressed and released. The Programs have to be changed to recognize that fact.

Sending an On command when an external NO button is released is the expected result. When the TriggerLinc external connection is shorted together, as would be when a NO button is pressed, an Off command is sent. This is the equivalent to putting the magnet next to the TriggerLinc. When the magnet is removed from proximity of the TriggerLinc it sends an On command to turn something On. This is the same as removing the external connection. Otherwise it would be necessary to make some additional wiring change to the TriggerLinc to isolate the internal magnetic switch when using the external TriggerLinc connection. Of course I don’t know for sure the external floor button is NO but that would produce the results seen. That is, the lights turn On when the button is released. Need to see both Programs to see how they are interacting with each other. The ON Program is doing what is normally does, turn On the lights. The fact that it happens when the button is released was probably not noticed with a momentary press of the NO floor button. It does make a different when the Off logic is being timed and then overridden when the floor button is released. Just need to confirm this so both Programs can be adjusted to work together rather than cross purposes.

Post both Programs. They both require timing checks. Otherwise a press of the button, regardless of how long, will always produce the On result.

The 2476S and 2476D are still being sold on the Smarthome web site. No one has reported the 2476D as being I2CS so spare Dimmers could be purchased. Of course with users moving to 3.2.6 an I2CS Dimmer could have been received and installed without problems so we might not know if the 2476D has moved to I2CS. The 2476S is I2CS so spares would not be of any use without going to 3.2.6. With so many other device types already on I2CS I really don't think staying at 2.7.15 is practical.

Follow this link... viewtopic.php?f=27&t=8937 the subject is covered in that topic.