Xathros

FWIW, I have 2 8 Button I2 KPL's that are working perfectly with 3.3.7 with regard to backlight changes. I had one event in 3.3.6 where the load on one of them turned on to 6% when the LED's were supposed to dim but that only happened once and it's been perfect since 3.3.7. My KPL's are FW V.36 and V.40. It was the v.40 that turned the load on instead of a backlight change once. I have 2 Fanlincs. One of those had the LED's turn back on with 3.3.6 and I could not turn them back off until 3.3.7. Once I installed 3.3.7 and did a Query Insteon Engine on that Fanlinc, I was able to turn the LEDs back off. Both Fanlincs are v.41 but only one had this problem and again, both are now fine with 3.3.7 -Xathros

While what you have there SHOULD cause the scene to come on at least once, it may never trigger again depending on the configuration of the motion sensor. Try chaing the IF from "Status is On" to "Control is switched On" and see what you get. -Xathros

Upgraded from 3.3.6 without issue. -Xathros

I have bought about 15 EcoSmart GP19 8Watt (40W Equiv) and found them to work quite well with Insteon dimmers and relays alike. These are selling for 9.99 ea at HomeDepot in my area. Only place they didn't work was on the 2 wire dimmers as they are not a large enough load. I only have about 6 months use on the oldest one so can't say how long they will last. -Xathros

I believe that KPLs with a firmware of V.40 and above, you can set a 0% on level for secondary buttons and activate those with a Scene On. Below V.40, you would need a separate scene containing the button(s) to turn off and issue a Scene Off command to that scene. In any event, I think it will require a program or two to monitor the KPL button presses and call the appropriate scenes. -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