Xathros

See above - you posted while I was adding more to my previous post. Is the old KPL bad and not responding?

Assuming the replacement Keypadlinc is of the same type as the original then Replace With should do the job just fine. They need to be either both dimmers or both relays and both the same number of buttons. Otherwise, you will have to go the manual route. If taking the manual route, Add the new KPL and don't remove the old one. Give the New KPL and temporary and obviously different name to avoid confusion with the old one. Then use Find & replace for each of the buttons to replace the old with new. That will make the program updates easier. Then make go through the scene memberships for each of the old buttons, adding the appropriate new button then removing the old. Once you have removed all of the old KPL buttons from the scenes, you may remove the old KPL from the tree. -Xathros

Is the keypadlinc button H configured as Non-Toggle Off ? -Xathros

Anytime! -Xathros

I'm hopeful that the next firmware update with expanded variable support will allow me to reduce my program count significantly while greatly improving the ISY's capabilities. -Xathros

I've been on the ISY for almost 5 years now and have never encountered that behavior and while I do see reports of lost link records here now and then it does not seem to be a common problem. -Xathros

Sorry. I assumed that node 2 was the sensor. Must be the relay. Right Click the sensor node in and select Diagnostics/Show Device Links Table. When the display is complete, click compare. Post results. -Xathros

Communications look perfect with the IOLinc at the PLM location. It still looks to me like the sensor is responding. Are you looking at the relay node of the IOLinc or the Sensor Node ? -Xathros

The My Programs Folder could be collapsed thus hiding ALL programs. Click the '+' Icon on the toolbar to expand the program tree. The My programs folder could also have a folder condition preventing all programs from running. Click the My Programs folder and look for conditions in the right hand pane. These are 2 simple items that could easily produce these symptoms. -Xathros

LeeG- Aside from the obvious comm issues, it looked to me like the IOLinc Sensor IS responding. I see: Tue 09/17/2013 02:35:35 PM : [ 19 61 92 2] ST 0 Tue 09/17/2013 02:35:41 PM : [ 19 61 92 2] ST 255 Tue 09/17/2013 02:35:59 PM : [ 19 61 92 2] ST 0 Tue 09/17/2013 02:36:01 PM : [ 19 61 92 2] ST 255 Tue 09/17/2013 02:36:20 PM : [ 19 61 92 2] ST 0 Tue 09/17/2013 02:36:24 PM : [ 19 61 92 2] ST 255 Are these not the sensor status messages? I have to wonder if the OP is looking at relay status and not the sensor status. -Xathros

Have you tried LeeG's recommendation to test the IOLinc at the PLM location? If not, I think that is your best next move. From here on in, you should have the event viewer running at level 3 during your testing so we can have visibility to the communications between your PLM and the IOLinc. Open up the event viewer, set it to level 3 and cycle the IOLinc input a few times. Post the resulting trace. -Xathros

Very nice. Thanks for the data and your effort to gather it. After my recent round of battery replacements, I'm thinking it's time for some newer sensors. Most of mine are 4+ years old. -Xathros

Did you do a restore PLM after the factory reset? Have you tried a restore device on the IOLinc? -Xathros

JimsEvilTwin- The # in the alert variable need to be the Decimal value of the program ID. So, if the program you want the status of is ID: 000A then the variable should be: ${sys.program.10.status}. Leaving the '#' in the variable seems to be shorthand for ID of the calling program. -Xathros

Always happy to help. -Xathros

Uncheck DHCP and use the following settings for the ISY: IP Address: 192.168.1.20 Subnet Mask: 255.255.255.0 Gateway: 192.168.1.1 DNS: 8.8.8.8 Then in your routers port forwarding section: Outside Port 443 to Inside Port:443 at IP Address 192.168.1.20 And don't bother with "Enable Internet Access" in the ISY -Xathros

EZFlora Zone 1 ? -Xathros

Do the 4 tap test again and look around at other dual band devices in the garage and house and see if any blink green. It would be good to know that the AP it also talking to something on the opposite phase. If not, It may be well worth another AP in the house on the opposite phase to bridge the phases. -Xathros

Hi John- Tap the set button on one of the AP's 4 times then go observe the LED on the other AP and any other dual band devices near the 2nd AP and post your findings. APs are designed for and normally used for bridging the 2 120v phases of a normal home electrical system. Generally, you don't need to "Link" an AP to anything. They just communicate with each other and pass what they receive on the powerline to the other via RF and what they receive via RF they pass to the powerline. The 4 tap test does 2 things: 1) Determines if the AP's are withing RF range of each other 2) Determine if they are on opposite phases from each other. The same test can be performed between any 2 dual band devices but you will have to consult the user guide for each device to determine what the LED response means for each particular device. At the very least, if the 4 tap test gets the other AP blinking, then you will know they are in range of each other. -Xathros

See my previous post - I posted a screenshot of one of my Net Resource rules. This one points the cam to position #1 I use the web console in firefox to capture the command being sent to the cam by it's web interface and then translate that into a role. I suspect the IE Dev console is about the same thing. -Xathros

Hi Mark- I have an older version of that Cam and am doing exactly what you want. You DO need the network module. You won't be using /REST commands for this. /REST is for setting/getting data and commands to the ISY. Network module allows the ISY to talk to other things on the network. All of that said, the Trendnet cams have performed very poorly for me. I have had much better results with the Foscam PTZ cams. Here is one of my Net resource rules for my Trendnet: -Xathros

Correct. If using the state variable to force a check every 5 minutes, we need to break it into 4 set point programs to avoid conflicts with the else blocks. If you don't need the forced check every 5 minutes then you can use either the original 2 programs or the 4 program version (without the state mvar) to achieve the same result. In that case, its just a matter of what you like better. There are often several ways to accomplish the same end result with the ISY and often it comes down to a matter of style or what you find easier to read. I sometimes use more programs than I need to just to make things easier to follow. -Xathros

The reason to use 4 over 2 is illustrated in my second example where we force a check every 5 minutes. If we don't need that, then there is no difference and is simply a matter of preference. -Xathros

Yes they do. All the ISY does when you create those relationships is write the controller and responder link records into the devices so that they are aware of each other. If the ISY goes offline, programs will not run but all of your defined scenes will continue to work just fine. -Xathros

Assuming "Catch up schedules" is enabled, depending on the time at startup, one or both may run but my understanding is that they would run in sequence. As long as comms are good to the thermostat, then it should work as planned. If catchup schedules is NOT enabled, then the stat will remain at its last set point until the next trigger time rolls around. Unless, both programs are selected to Run at Startup in which case there will be a race condition between the two else sections and the stat will most likely be set wrong. Neither of these programs should be set to run at startup. All of that said, my last post (above) details another method that should enforce the correct setting every 5 minutes but requires 3 more programs to pull it off. -Xathros