d_l

Michel, Well so it is. I just tested mine vs. another cable with various adapters. So I promptly marked it "ISY" to help keep from mixing it up with my other serial cables and prevent me from trying to use it with other serial port connection projects. Maybe a little ISY sticker label on the plugs would help others too.

So when you "connected" with hyperterminal, there wasn't any response (echo) of your input? How did you know that hyperterminal connected? Was there any response at all? Sorry, I don't know if the supplied cable is a regular "modem" cable or a null modem cable so I can't say if it would make any difference. Whenever I encounter a situation such as this, if the cable I try with gives no response, I usually slap a null modem adapter on to it to try the other possibility.

There used to be a way to access the the ISY Shell through a Windows COM port and Hyperterminal. You would use the provided DB9 cable to connect one of the COM Ports on your computer to Port B on the ISY; however, I don't know if this method still works in the latest firmwares. They haven't added Wiki documentation for this method and it is only described in the old Advanced Configuration Guide PDF file starting on page 6: http://www.universal-devices.com/docs/p ... 0Guide.pdf

Wonderful. This will answer the questions I often have when dealing with complicated or multiple conditions.

Dave, X10 signaling CAN be enabled by local control switching on the Lamplincs and Appliancelincs. So the device that is switched on locally would signal your PL network with an X10 address of your choosing that it is indeed on. Your ISY would then have to be programmed to interpret and track that status of that Insteon device. I'm not saying this is easy or convenient, just possible. Most people end up disabling the local control and/or the X10 address control on these devices.

I see this failure too on an ISY-26.

Those are error messages. http://www.universal-devices.com/mwiki/ ... r_Messages

Clark, https://your_dyndns_address:whatever_SSL_port should work fine. It works fine for me when I set up a second connection dial up or second DSL line to "remotely" access my LAN. I actually have my host name and included port web hopped to something like my_isy.webhop.net. That way I save having to remember the port and have to use just a web address. When you go through web hop frames like that your locked symbol on your browser won't show for the encrypted transfer, but it is still operating. BTW, you really wouldn't have to have your router map in a port like X443 to 443 in the ISY. I used X443 so I could remember more easily what was happening. I have a few of these port remappings in use and things can get confusing a few months later after my memory isn't as fresh.

Clark, there is this about SSL, self signed certificates, and port 443: http://www.universal-devices.com/mwiki/ ... o_Your_ISY For secure remote access, you should be accessing the ISY on port 443 unless some device on your LAN is already using 443. Then follow the explanation about how to change the ISY's secure port to another port. Frankly I don't use simple port forwarding through my router to 443 on the ISY. There are just so many malware probes on 443, I let my router "translate ports and forward" to 443, e.g. external access is on another port, say X443 where X is any value greater than 1 and up to 63, and the router forwards this port access to 443. Your Belkin router may not have this capability, not all routers do. I chose X443 to be a port without any known trojans and other malware. Your LAN access to the ISY can (and probably should for default simplicity) remain on port 80. On the LAN side you would simply access the ISY by its LAN IP. How are you accessing the ISY from the internet? With another broadband connection? You would access it at https://your_dyndyns_address:whatever_SSL_port_ you _passthrough_your router. If you aren't using another broadband to access the ISY and are trying the SSL port from your LAN, then you are probably running into a loop back situation.

I pretty much use those programs as the X10 equivalent of the Main tab. I believe that Universal Devices has plans for some firmware additions to the ISY that will help keep track of the X10 device status similar to the function of my programs.

Most X10 devices aren't two-way as the Insteon devices are so they won't respond to a request for a status. So you have to write programs to keep track of the status of all your X10 devices if this is important to you. I have a whole series of "X10 status " programs. They all are simple like this example: If X10 'F11/On (3)' is Received Or X10 'F11/Off (11)' is not Received Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') If the device is on, the program will read True and if off, it will be False. BTW, because I have a lot of these type programs, I designated them with an asterisk at the start, e.g. "* Guestroom Fan", of the name. This enables the Program Summary tab to sort all of them to the top when I want to check the X10 programs.

Isn't a DynDNS client better suited to be on a modem or a router instead? The ISY isn't directly connected to the broadband line/cable, but must be accessed through one or both of those devices.

It is pretty simple. If your ISP doesn't have its own NTP server that you can use, pick a public or private StratumTwo TimeServer that is close to you in network latency from this list: http://support.ntp.org/bin/view/Servers ... imeServers and enter it into the NTP server address box in the camera. I use the NTP server maintained by my state university system and have entered the IP in the address box so the time updates can be made without relying on DNS intervention. I use the same server for several cameras.

I can't quantify the double tap speed other than to say to get a double tap off on a ToggleLinc, I have to tap it about as fast as I possibly can. If there is an slight pause between taps, the double tap fails. I also have to tap fairly forcefully or it doesn't work either. I don't have any confidence in my ability to reliably double tap a ToggleLinc so I only use that command to initiate a"forced off override" program that disables the normal motion sensor control for the ToggleLinc. This override capability would be used infrequently. I don't use Fast On so I can't say anything about that.

IndyMike, I do the same pre-installation bench test on my new wired-in devices with a replacement power cord AND a rubberized replacement lamp socket. That way I can link it to the ISY, and then run through all the device functions with it plugged into the same house circuit, if possible, as where it will be installed. This beats having to pull out a newly installed device that doesn't work out of a junction box.

Michael, I just installed and added a new 2466SI ToggleLinc Relay on Friday without any problems. Maybe there is a problem with the installation of the 2474D?

Chris, Just to verify that I have this right, the new "Run At Startup" in 2.6.4 runs a Run (If) now, but if there is a program to be run at start up that has no If condition to evaluate, then would the Then statement be run automatically? Is this correct? Thanks.

Michel, If a user can program the EZRain's internal timer programs by some other means, can the ISY then call those programs as necessary rather than completely relying on its own timers/schedules to operate the EZRain? Thanks,

Chuck, thanks for that "Status is Off and Control is switched Off" idea. I've used it to enable a "forced off" condition on some ToggleLinc switches that are activated by motion sensors. When the wind blows hard, these switches turn on repeatedly at night so I've just decided that they should be off for the wind duration. Program Content for 'Manual Porch Switch Off' If Status 'Front Porch Light' is Off And Control 'Front Porch Light' is switched Off Then Wait 8 hours Run Program 'Manual Porch Switch Off' (Else Path) Else - No Actions - (To add one, press 'Action') I put that timer on the program so the forced off condition won't last forever if I forget that I have initiated it. This 'Manual Porch Switch Off' program then becomes a tested condition in the motion sensor program that switches the porch light on and if true, the light is not allowed to be switched on. I also have a complementary program, 'Manual Porch Switch On', that forces the lights to be on and not be turned off by the motion sensors.

You've run afoul of what I call the "A status check requires two programs" rule. Generally you can't check the status of a switch/device and then power it on or off in the same program because your change of the switch/device in the Then portion of the program immediately changes and affects the status of that switch/device in the conditions. You must split your program into two separate programs. One program checks the time and status conditions and the second program executes the Then action. Like this: "Program 1" IF { time is "7:00 AM" OR time is "8:00 AM" OR time is "9:00 AM" OR time is "11:00 AM" OR time is "12:00 PM" OR time is "1:00 PM" OR time is "4:00 PM" OR time is "5:00 PM" OR time is "7:00 PM" OR time is "8:00 PM" OR time is "9:00 PM" OR time is "10:00 PM" OR time is "11:00 PM" } AND Status 'Hot water Pump' is Off Then Run Program 2 Else - No Actions - ( To add one, press 'Action') "Program 2" If (no conditions here) Then Set 'How Water Pump' On Wait 10 minutes Set 'How Water Pump' Off Else

I had problems with the sunset timers triggering immediately after re-synchronizing the clock early this morning on 2.6.1. I didn't wait long enough to see if there were any other timer problems. When I saw that I couldn't make the sunset timers work correctly, i.e., not trigger at 7ish in the morning, I upgraded to 2.6.2. AFAIK, the timers are working correctly in this version. Be aware there is a different approach to accessing the administrative console in the 2.6.2 version that might break your bookmarks. If you have been using the ISY_IP/0/p method to jump directly to administrative console, you will want to use ISY_IP/admin instead.

Clark, What Mike says is true about the Wiki. MarkSanctuary has done a terrifiic job updating it as new ideas and info become available. I never have much luck finding anything there by browsing for it, but a good search always turns up what I need to know.

Mike, The "Or Control 'Kitchen Light' is not switched Off" is not needed in the example I posted, but I had it there because it IS needed if you change that program to add these sort of lines that I mentioned near the end of that post and so I've just started to add it to these type of programs automatically: If Control 'Kitchen Light' is switched On Or Control 'Kitchen Light' is not switched Off And From Sunset To 11:00:00PM (same day) Then Else Set 'Kitchen Light' Off This is actually the way I have my porch light set up. It is intended to automatically power off the light late in the night if it should ever be manually switched on and left on. Probably scoobydawg might not accidentally leave an inside kitchen light on all night, but it is easier to do with my porch light. Edit: This program works to turn off a manually switched on light at the To time and it prevents the motion sensor program from powering off the manually turned on light during the time interval, but it breaks the intended True/False structure. Instead of a From/To command, there would need to be an After Time command for it to work as I wanted. I had an alternate idea of setting the program to a multi-hour Wait in the Then branch and then shutting off the light after the Wait. This would have the advantage of showing up as a nice red "Running Then' entry in the Program Summary which would make it stand out.

OK Mike, here is what I was trying to do (thought I was doing) with the Control statement in my single program. This alternative method still needs two programs, but it makes the activation of the physical light switch sort of "non-overrideable" if you want. However as listed, it doesn't allow the switch to be powered on by a scene and then not shut off by the motion detector, but I really don't use scenes due to a limited number of Insteon devices and so I don't think about scene incorporation when making programs. "Program Content for 'Manual Kitchen Switch'" If Control 'Kitchen Light' is switched On Or Control 'Kitchen Light' is not switched Off Then Else // Manual activation of Kitchen Light Switch "Program Content for 'Kitchen Light On by A5'" If X10 'A5/On (3)' is Received And Program 'Manual Kitchen Switch' is False Then Set 'Kitchen Light' On Wait 5 minutes Set 'Kitchen Light' Off Run Program 'Kitchen Light On by A5' (Else Path) Else By tracking the manual activation of the Kitchen Switch, you have a little more information available to interact with other programs. This gets away from the two program technique of Check Status, then Run Statements Only that you posted and that Chris Jahn has shown before in this situation. If scoobydawg had a second X10 sensor that was to activate the Kitchen Light for a different length of time (this is a situation that I have), this method is much easier. Simply have a second program, e.g. 'Kitchen Light On by A7'. I absolutely could not come up with programs to do this by the 'Check Status, then Run Statements Only' technique. If someone had a problem with the Kitchen Light Switch accidentally being left on late into the night, I suppose that a From-To time test could be added to the first program, to power off the light at the end of that period.

clark, he put that Run "KitchenTimerProgram" (Else Path) in there because I had it in my incorrect single program. I'm not sure if he commonly uses that statement or not, but I do. Yes, the ISY just execute the Then statement to completion, and stop, but it would also still be read as True in the Program Summary page after it had stopped. The Run Else statement forces the program to be false after completion. I use a convention where I name my programs as simple sentences, e.g. in this case it would be something like, "Kitchen Light ON by A5". So when when I look at the Program Summary page and see "Kitchen Light ON by A5" is True, I know the Kitchen Light had been turned on by A5 conditions and the time limit for the A5 condition hasn't expired. Sure you can check the status of the Kitchen Light on the Main page, and know if it is on or not, but by using the Run Else as I do, then you have a little more information on the Program Summary page as to what is happening if you are using X10 sensors. This becomes more useful if you have multiple X10 sensors or other programs that turn the Kitchen Lights on.