LeeG

The Program requires the device be turned On (If Control xxxxx is switched On) before the Local On Level is changed. Changing the Local On Level after the device is already On is not what the Program needs to be doing. If From 1:00:00PM To 8:00:00AM (next day) Then In Scene 'Hardware / Living Room' Set 'Hardware / Living Room' 30% (On Level) Else In Scene 'Hardware / Living Room' Set 'Hardware / Living Room' 100% (On Level) At 1 PM the Local On Level is set to 30%. When the device paddle is pressed after 1 PM it will turn On to 30%. If the device should be reduced to 30% if it is already On at 100% requires another Program. The Program turns the device down to 30% 1 minute after 1PM to allow the previous Program time to set the Local On Level If Time is 1:01:00PM And Status 'Hardware / Living Room' Is On Then Set 'Hardware / Living Room' 30% Else

The PLM firmware level is now 9A or 9B the last time I saw someone post. I have a v.99 that is 6-12 months old. SmartLabs does not publish what each new release of PLM firmware changes so there is no information regarding the exposure. Simply the difference between v61 and v99 numerically suggests many functional improvements. There is a completely new enhanced Insteon protocol, I2CS, along with a huge increase in the number of Dual Band devices since v.61 was released. Regarding the cable length, 50' is considered the maximum for a Serial connection. However, the shorter the better. A 50’ cable is definitely not recommended. I would expect the 3-4' cable that came with the 994 to work. Perhaps it is related to the number of times a cable has been inserted into an old RJ45 jack. With the 12' working perhaps the 3-4' foot would work now. EDIT: sorry I missed one. If the 994 is starting from scratch I would definitely factory reset the PLM to insure the link database is cleared. If the ISY-26 configuration is being migrated to the 994 (don't know if that is possible) then I would do a Restore Modem (PLM) to compress out any deleted or duplicate link records.

For all the devices in an ISY Scene to stay in sync they need to be added to the Scene as Controllers. The ISY assumes a Controller is also a Responder so all the Controller/Responder devices are cross-linked by the ISY so they stay in sync. Remove them as Responders and add them back as Controllers. Later KPLs have a beep feature such that when a button is pressed the KPL beeps. I don't think the ISY supports configuring that option. It will be necessary to turn that Off at the KPL. The KPL User Guide describes the process of turning button beep On and Off. How many times does the KPL button blink when pressed? The combination of blinking and beeping may indicate an issue with the load. What type of KPL (dimmer or relay) and what type of load (incandescent, something else such as CFL or LEDs).

Assuming the PLM communicates reliably with the installed devices eliminates a PLM problem. That leaves either the KPL itself (including how it is wired) or its install location. The simple way to eliminate location and test the KPL is to connect it to an Appliance cord (plug on one end, bare wires on the other) and plug the KPL into the PLM circuit. If it does not work there the KPL is suspect. I would try a factory reset of the KPL before returning it if it does not work at the PLM plug point. The unsupported device means that particular KPL type was released after the ISY firmware being used. Sounds like 3.2.6 is installed which is pretty old as far as new Insteon devices that have been released. I suggest installing 3.3.10 (RC7). It is a Beta but has been stable. Unless a significant problem is identified it will be the next Official release.

There is no communication with the KeypadLinc 22.16.ED. Three attempts were made to send commands to the KPL, it did not respond to any of them. Double check the Insteon address of the KPL label. When the KPL responds there will be Insteon messages in the event trace that start with 02 50 or 02 51 which are inbound messages to the PLM. Are there Access Points on opposite 120v legs for coupling? Be sure the PLM is not plugged into a power strip that has noise suppression. That will reduce the Insteon signal to the point where it might not make it out to devices. Other electronic devices powered on the same circuit as the PLM can also absorb Insteon signals.

I am assuming no messages of any kind were issued when the Progress Bar closed. This usually means the Insteon address is already defined. If that is not the case run Tools | Diagnostics | Event Viewer at LEVEL 3. Repeat the New INSTEON Device with the event viewer running and post the event trace.

One of the problems is easy to answer. Secondary KeypadLinc buttons cannot be turned On and Off with Direct commands. The Insteon Direct On/Off commands have no placeholder for a button number. That is why no On and Off buttons when a Secondary KPL button node is selected. The Primary Load control button, which should be A not B, is the only button that can be turned On and Off with a Direct command and have diagnostics run against. I suggest Deleting the KeypadLinc from the ISY. Use New INSTEON Device, enter the Insteon Address, Name of choice, leave Device Type set to default Auto Discover. Click Ok. It is not necessary to press Set button (or any button) on the KeypadLinc. That will remove any question about KPL nodes and names and use of the Set button. To link KPL buttons, define an ISY Scene, drag/drop the KPL button of choice to the ISY Scene and select it as a Controller. Drag/drop whatever devices should be Responders. Note that the ISY assumes a Controller is also a Responder so if the ISY Scene has multiple devices that should function as Controllers simply drag/drop then as Controllers. This ISY will automatically treat them as Responders as well as Controllers and cross-link them.

trdoney Perhaps we can help with some of the Programming questions/problems you are having. Although an ISY Program can handle complex conditions and situations many things can be accomplished with the basic features. Once the basics are mastered then move to the more complex if needed. It is often useful to post the Program in question by right clicking the Program name and select Copy to Clipboard. The Program statements can be posted into a forum post along with a description of the question/problem. Lots of really helpful folks in the ISY community who are more than willing to help along with UDI tech support.

Once added to an ISY Scene as a Controller there is no need to add it as a Responder. The ISY assumes a Controller is also a Responder. Delete the Responder definition if it was also added to the Scene as a Responder. To confirm my understanding, an ISY Scene has a Secondary KeypadLinc button as a Controller of the Scene. When the Scene is turned On/Off either through the Admin Console or a Set Scene On/Off Program statement the Secondary KeypadLinc button LED does not turn On/Off in response to the Scene On/Off. That should work if as described above. Could be a link record did not get written to the KeypadLinc for some reason or there is a comm problem between the PLM location and that KeypadLinc location. Suggest running a Scene Test on that Scene and see if the results show success or failure for that specific KeypadLinc button. If it fails consistently do a Show Device Links Table for the KeypadLinc and click Compare when the display is complete. Does the Compare indicate the link records are correct? If the Scene Test works then there is some marginal comm between the PLM location and the KeypadLinc location.

This is the statement in an earlier post that sets the Local On Level. It is not in the latest Program In Scene 'Hardware / Living Room' Set 'Hardware / Living Room' 35% (On Level)

The device Local On Level is not being set in the posted event trace. Could be the Program change adding the additional Adjust Scene was not Saved or the Program has already been run once. The ISY will not write a Local On Level to a device it thinks it has already set to that value. Change the On Level % to something different, like 40%, Save the Program changes and trace the Program with the event viewer again. I'll look at the new trace. Was the Query Insteon Engine run against the Dimmer?

That is an ancient PLM firmware level that should be replaced for that reason alone. In theory it should work with all the new Insteon devices but there has been so much maintenance to the PLM firmware since v.61. I would check the cable between the 2412S PLM and the 994 Port A as I would expect the basic serial command to identify the type of PLM and its Insteon address to work even at v.61 Note that the 2413S PLM, which is only Serial PLM available, does not provide 12v power as the 2412s does. The external power supply that came with the 994 will be required when using a 2413S.

Add the KeypadLinc button as a Responder in the ISY Scene. Turning the Scene On/Off will cause the KeypadLinc button as a Responder to turn On/Off.

Neither the indicated KeypadLinc nor ToggleLinc are Dual Band. That means the Motion Sensor must have been communicating with a 2413S Dual Band PLM? Evaluate the location of the Motion Sensor in relationship to the PLM location. Simple things like a refrigerator or metal filing cabinet between the Motion Sensor and the PLM can disrupt the RF signal. Something must be reducing the RF signal. Can be a combination of distance and object. With only one Dual Band device (assuming the PLM is Dual Band) how are the 120v legs being coupled? An Access Point is the easiest and I consider the best RF option. It can be plugged in where ever it needs to be to provide RF coverage.

"Let's say I have two scenes, each containing the same dimmer switch and nothing else (so the ISY is the controller). Can the ramp rate in one of them be 0.3sec and in the other 30 seconds?" Absolutely. The Dimmer will be a Responder in each ISY Scene. Click on Scene X and set the Responder Ramp Rate to 0.3 seconds. After the Progress Bar completes click on Scene Y and set the Responder Ramp Rate to 30 seconds. Insteon understands each ISY Scene is a different Insteon Scene (unique Scene/Group number) so the Dimmer will have a separate Responder link record for each ISY Scene. Each Responder link record can have its own unique On Level and unique Ramp Rate value. The Local On Level and Local Ramp Rate in effect when the Dimmer paddle is pressed are separate values from the Responder On Level and Responder Ramp Rate for each Scene.

There is a category for requesting additional ISY function. Good to post there so others can comment as how many folks want a function often dictates its priority. I don’t like the new Scene idea myself but thought I should mention it.

The 3 AM Query will get a comm error with it not powered. Cannot avoid it. When the OutletLinc is turned On (assume with a Program) a Wait of 15 seconds or so to allow the SynchroLinc to boot up and then issue a Query for the SynchroLinc should clear the comm error. EDIT: I guess I should mention that a new Scene with all the devices except the SynchroLinc could be created and change the 3 AM Program to use the alternate Scene name.

propman07 The ISY may not know how to update the Local information for this specific device definition. Right click on node name, select Diagnostics | Query Insteon Engine Change the Program to something other than 35% in the Then clause as the ISY will not write data to a device it thinks already exists. Save change and right click the Program name, select Run Then. If that does not set the Local On Level run Tools | Diagnostics | Event Viewer with LEVEL 3 selected. Change the Program again to some other Local On Level, Save change and right click Program name, select Run Then. Post the event trace. Some older devices cannot be updated without power cycling the device. If the device supports the newer technique the Query Insteon Engine should fix the problem.

The event viewer should run for as long as the Admin Console session is up. The Admin Console subscription can be terminated do to time. If that happened no more events could be pushed out from the ISY to the Admin Console (event viewer) so it could look the event viewer has a limited on time. It does not unless it is something very new.

"Positive ,I was expecting it to change but it never did until after I upgraded and only after the reboot of ISY and restarting the console, at that point the writing device xx.xx.xx dialog came up which was the address of the new device, at that point when I checked the address associated with the named device I replaced, the address was changed from the old to the new." Okay, thanks. Since the changes have completed with the reboot there is nothing to look back on. The Admin Console does close with a Replace xxxx with .... function. Otherwise there would be two device definitions with the same Insteon address. There is a popup that is now displayed describing the Admin Console shutdown as part of the Replace. The reboot of the ISY should not have been necessary. Perhaps there was an issue with the earlier image. I have run a Replace on the latest image with success.

If the load is connected to the Dimmer than changing the Local On Level has no affect on Fast On or Fast off. The Dimmer reacts and sets it load to Full On and at a fast ramp rate with a paddle double tap. It may be that the paddle is not double tapped fast enough to generate a Fast On. Runs Tools | Diagnostics | Event Viewer at LEVEL 3. It will display the command generated by the double tap. Also the Set Scene is not coded to change the Local On Level. Both the 'In Scene' and 'Set' parameters must specific the Controller node name to change the Local On Level.

Not to question the conclusion but are you sure the old node name was not assigned the new address. Something must have been assigned the new address, otherwise that new address could be added to the ISY. The Event Viewer would show “1)†if it had been running during the Replace xxxx with ..... It was not necessary to remove the old node name from Programs and Scenes. Now all Program and Scene changes have to be restored manually after the Replace. The idea behind Replace xxxx with .... is that none of that is necessary. There are link records not related to user defined Scenes that require changing. For “2)â€, pending changes would normally be noted by Green Icons to the left of affected nodes. These Green pending Icons change to Green updating Icons as updates to each node are being done. EDIT: can you run a Show Device Links Table request against the old node name, Save the file which will be in XML tag format and copy/paste the XML lines to a post. The forum is not currently accepting images unless you can store the image somewhere else and post a link to the Show Device Links Table image.

znuttyone The steps described are what should happen except for the second part of the last item. behavior: newly discovered module will disappear in the console and old unit will remain in the console with no changes. subsequently if you attempt to discover the module again, it will discover, but never shows up in the console again. Now cannot get the new module to add, and the old module cannot be deleted, renamed. The existing node, the one where the Replace xxxx with …. function is invoked against, is the node that should remain after the Replace completes. The idea is that the old node name remains, references to the old node name in Programs and Scenes remain unchanged. However, the Insteon address assigned to the old node name is changed to the new device Insteon address and the new device node is removed from the defined list of devices because two nodes cannot have the same Insteon address. The new device cannot be added to the ISY again after the Replace because the existing node definition in the ISY has been assigned the Insteon address of the new device. Programs and Scenes and old node definition that may have existed for years continue to exist as before. Programs continue to reference the old node name, Scenes continue to reference the old node name, the only difference is the old node name has the Insteon address of the new device. If you click on the old node name the information in the right pane should show the Insteon address of the new device. The part that is not normal is the old node name cannot be deleted, renamed. Unless there were pending updates that had not completed which were generated as a result of the Replace xxxx with …. function then certainly new changes would not be accepted/allowed until all the updates associated with the Replace completed. All link records with the old node Insteon address have to be updated with the Insteon address of the new device. This can take some time depending on how much linking the old node is associated with.

Within an ISY Scene Responders are Blue, Controllers are Red and displayed in Italics Not sure exactly what the other situations being asked about. Can you added some additional detail?

When the Green LED in the I/O Linc is On it means the I/O Linc Sensor is On. The command the I/O Linc sends when the Sensor is On depends on the Trigger Reverse option. If the Trigger Reverse option is set the commands are reversed. The I/O Linc sends a Sensor Off message when the Sensor is physically On (Green LED On) and sends a Sensor On message when the Sensor is physically Off (Green LED Off). That is why the option is called Trigger Reverse. It reverses the command sent versus the actual status of the Sensor in the I/O Linc What the ISY and MobiLinc show for the Sensor state depends on whether Trigger Reverse is used.