Xathros

Mark- Always happy to help. -Xathros

oberkc- I don't believe you can directly turn off a secondary KPL button. Instead, include the D button in the Full Bright scene with a 0% on level. -Xathros

It still sounds to me like you are suffering from marginal Insteon communications in this setup causing delays. -Xathros

I don't think the timing will be effected very much. ASSUMING good Insteon communications, we are looking at maybe a 1-2 second delay between On command and test to verify that feeder did turn on. Program: DogFeederSchedule IF Time is 9:00 am OR Time is 6:00 pm <------Added to show multiple feeding time usage THEN Run Program DogFeederOn THEN Path Program: DogFeederOn (Disabled) IF Status DogFeeder is Off THEN Set DogFeeder On Set DogFeeder Query Run Program DogFeederOn IF Path ELSE Wait 19 Seconds Run Program CheckDogFeeder THEN Path I dropped the delay from 20 to 19 seconds to account for the test time - Adjust as necessary. This does not notify on failures but we could add a counter variable and notify program as we did with the Off programs. -Xathros

Hi Tim- While I don't think its absolutely necessary since we force a test on startup, for cleanliness sake, you have a good point. Mark- Edit the Check programs as follows: Program: CheckDogFeeder If Status DogFeeder is On Then Set DogFeeder Off s.DogFeederOffTest = +1 s.DogFeederOffTest InitTo s.DogFeederOffTest <---Add Wait 5 seconds Run Program DogFeederFailNotify Run Program Check Dog Feeder If Path Else s.DogFeederOffTest = 0 <---Add s.DogFeederOffTest InitTo 0 <---Add This way if the power does fail during a feeder off attempt, the system will resume where it left off in the attempt/notify cycle. -Xathros

Sorry, Find the program in the list on the summary tab, right click the program name and select Enable run at Startup. Dunno why this option is so buried. -Xathros

sbex55- The Harmony remote is talking to the ISY via IR not RF so the IR eye in the ISY needs to be able to see the remote's IR LED(s). Access points and Dual band devices are Powerline/RF units only - not IR. While your Harmony remote may also be RF capable, I highly suspect it doesn't speak Insteon or even operate in the same RF band as Insteon. The remotelink does speak Insteon on the Insteon RF band. Many electronics stores sell IR repeaters which you could use to pipe the IR down to the ISY via wire or RF. -Xathros

Thanks for that little tidbit. That is excellent news and just changed my mind on ordering a second CAI board this week. That is worth waiting for. -Xathros

Mark- To recover after a power failure, create a program as follows to run each of the CheckFeeder programs and put a check in the Run At Startup box for this program: IF THEN Run Program CheckDogFeeder IF Path Run Program CheckHorseFeeder IF Path Run Program Check LlamaFeeder IF Path ELSE Also, Not sure about the outletlincs but most of the appliancelinc modules I have used will default to OFF after a power failure. I highly suspect the outletlincs are the same way but can't say without having tested any. I suspect your fail to turn off problem is more a comm failure due to noise or distance than power loss. Might need to look at filtering noisy equipment or adding some access points to extend/repeat the messages. -Xathros

Kentinada- What version of MAC OS are you running? Maybe clicking A or B below... Xathros

Mark- I don't think there is a method for testing how long an Insteon device has been in a given state. I don't think it ill be very difficult to deal with this by modifying your original programs just a little and adding a check program and notify program for each feeder. Define some state vars - 1 for each feeder: s.DogFeederOffTest IF Time is 9:00am THEN s.DogFeederOffTest=0 Set 'Feeders / Dog Feeder in Garage' On Wait 20 seconds Do program Check Dog Feeder IF Path (this will turn off the feeder and keep trying until it succeeds) I removed the Query as it served no function that I could see. Program: CheckDogFeeder If Status DogFeeder is On Then Set DogFeeder Off s.DogFeederOffTest = +1 Wait 5 seconds Run Program DogFeederFailNotify Run Program Check Dog Feeder If Path Else Program: DogFeederFailNotify IF s.DogFeederOffCount = 5 or s.DogFeederOffCount = 15 or s.DogFeederOffCount = 25 THEN Notify Mark: DogFeeder OFF Failed! So simply duplicate the CheckDogFeeder program and DogFeederFailNotify program for the other feeders and call the check programs in place of just setting the feeders off. This way they will retry until off. You will be notified if OFF fails after 5, 15 and 25 attempts. Your schedule is still managed the same way it is now with your first program. You can expand on this for the Feeder On portion if you wanted to ensure that nobody goes hungry as well. Thoughts ? -Xathros

Yep. Same stuff - different box... -Xathros

Mark- How about something like the following: Program: Check Feeders IF Time is 9:01:35 am THEN Run Program Check Dog Feeder IF Path Run Program Check Llama feeder IF Path Program: Check Dog Feeder (Disabled) If Status DogFeeder is On Then Set DogFeeder Off Wait 5 seconds Run Program Check Dog Feeder If Path Else Notify Mark: Dog Feeder Off - Succeeded. This won't notify on failure but will retry the off every 5 seconds Until success.

RichTJ99- Going way back to near the beginning of this thread, you indicated Trigger 8 missing an address label. Here is your solution to ID Trigger 8: Pick one of your swtichlincs and do a show device links. Make a screenshot of the table or write down the links if only a few. Then, manually (set button) link Trigger 8 with that switch. When done, do a display links on that switch again and look for a new address that wasn't there before. That is the address of trigger 8. Now you can factory reset trigger 8 and restore device on the switch to remove the extra unwanted links. HTH -Xathros

Or a $20 Pogoplug with Archlinux would give you a full Apache webserver and pretty much anything else you might need like perl, PHP, MySQL etc. -Xathros

I also use a CAI Webcontrol board along with IO_Guy's program running on a Pogoplug with Linux. Yes, the initial setup was much more complex. I had to get all the bits, hack Linux into the Pogoplug and configure everything. Took a day or two (maybe 6 hours total) to get it the way I wanted. Now I have a much more capable system with digital and analog IO, A real Apache web server, ProFTP ftp server, Syslog server, Network control of a few devices with OR without the ISY being involved. The parts totaled out around $65 for the CAI Webcontrol board and the Pogoplug. The capabilities I have gained are worth so much more. Ethernet communications reliability between the CAI Webcontrol, Pogoplug and the ISY are orders of magnitude better than Insteon communications and faster to boot! I recommended the IOLinc/EzIO method due to it's simplicity. If I were doing this myself, it would be through the CAI Webcontrol board for sure. -Xathros

No. That shouldn't cause any errors. All that means is that when you added (linked) the EZIO, you specified the device type rather then letting the ISY auto discover the device type. Not a problem. -Xathros

The ISY itself has nothing to do with RF. That is up to the PLM and any dual band devices and access points. If you hve the 2413 PLM then you have RF. You may need one, two or three (if a 3 phase electrical system) access points to bridge phases and extend your RF coverage. Can you describe your problem in greater detail? I'm not positive but I don't believe any of the 3 Insteon devices shown above are dual band (RF capable) devices meaning you are relying on power line communication rather than RF for these. -Xathros

Or simply move the contents of the Then path into a separate disabled program and call it from the ten path of the first program so that it won't be effected by status changes in the first program. -Xathros

ejh3- Sorry, I missed the second question. Here is one of my garage door monitor programs. This assumes you are controlling your door with an IOLink and that the sensor is ON when the door is NOT closed. If you are configured differently, this will need to be modified. If Status 'Garage / Garage Door IOLinks / GD- Dad Garage Door Sensor' is Off Then Set Scene 'Garage / Garage-Dad' Off Else Set Scene 'Garage / Garage-Dad' On The only thing in the Garage-Dad scene is a KPL Button H -Xathros

ejh3- I have the same concern and developed the following two programs that I use for my back porch floods day and night: Back Porch Daytime Timer If From Sunrise + 1 second To Sunset - 1 second (same day) And Status 'Back Porch / Back Porch Flood Light' is On Then Set Scene 'Back Porch / Back Porch' Off Else - No Actions - (To add one, press 'Action') Back Porch Night Timer If From Sunset To Sunrise (next day) And Status 'Back Porch / Back Porch Flood Light' is On Then Wait 15 minutes Set Scene 'Back Porch / Back Porch' Off Else - No Actions - (To add one, press 'Action') I have a few more programs that disable and re-enable the above programs as necessary. Hope this helps. -Xathros

Johnnyt- I currently have just under 100 programs. Many of these I hope to eliminate as the ISY's capabilities mature. Once we have the ability to do variable assignment to/from devices and maybe get some string variable support, I suspect I could cut my program count in half. Not knowing what exactly you are doing with programs I can't venture a guess as to how that could effect your program count. In the short term, I see my program count increasing somewhat as I continue to build out my Insteon network and need to keep track of more devices and data. The feeling I get is that a large program count isn't necessarily a problem unless you have many trigger at once or as in your case where it causes a repetitive update delay. I see this with Mobilinc. The more devices, programs and variables I have, the longer it takes to sync up with current statuses. Not really a big issue for me unless I'm on on a weak 3g/edge connection at the time. -Xathros

For what it's worth, I have a 994i-Pro with 90+ programs, 60+ network resources, 80 variables, 60 nodes and have a CAI web control board in near constant communication with the ISY. I haven't noticed a performance issue with the ISY under these conditions. I did upgrade from a 99i earlier this year. I can say that the Admin console "feels" quicker to respond than it did on the 99i. There have been some firmware updates since then so I can't say for sure that the improved feel is due to the 994 over the 99. Guess I need to set up the 99 as a test bed. I just don't have enough leftover Insteon parts to make that worth while yet. -Xathros

I would use 2 10K ohm resistors between +5v and Each of the I3 and I4 inputs then place your dry contacts between ground and each input. Make sense ? -Xathros

No Problem. Happy to help. I assume you just changed the timeserver to the ip address that I supplied a few replies back on the clock thread. If that is the case, that may stop working if that time server moves. Now that you have fixed the DNS at the ISY, you can change that server back to time.nist.gov or pool.ntp.org as the ISY can now resolve the current address for a named server. -Xathros