bipto

4 KPL's, 2+ years, no issues...

This sounds painfully familiar. I was also burned by this ambiguity when buying replacements for my garage door IOLincs, purchasing switches identical to those I sought to replace. I ended up hedging my bets and finding a single pole, double throw (SPDT) model reed switch, which allowed me to wire it in the configuration of my choice. Fool me once, LOL...

I wouldn't hold my breath - I have emails from Mobilinc (Wes) dating back two years promising that Elk / Moblinc integration was just around the corner... Personally I doubt whether Mobilinc (especially the Android flavor) will EVER be developed to its full potential...

I use mini's as fanlinc controllers as well - no issues...

Yeah, that's pretty much what I was eluding to with "seasonal angle"... but thanks ... I'm just not sure whether that alone explains the (mis)behavior I'm seeing. On many bright, mostly-sunny days the light level remains in single digits until well after noon, and then will abruptly increase to 80+ percent. I'd almost be inclined to believe that the sensors on some of these stations are now in the shade most of the day - except that this behavior is not necessarily consistent from day to day...

Thanks for the tip - I can think of a couple uses I could make of that... FYI, I too have tried to factor Climate::Light in to my lighting programs but have found that the HAM light percentage reporting is far too inconsistent / erratic for me to rely on for this purpose. Sometimes the value seems completely wrong for the current light condition, other times the value seems to "stick" for hours and then jump. Not sure if this is an issue with HAM, or with the stations themselves, though I have tried several different stations within a reasonable radius and have yet to find one that I can rely on. Given that this behavior seems to have gotten worse over the past weeks, I'm not convinced that this doesn't have something to do with the seasonal angle of the sun, either... I just know that I am not able to reliably use that value to indicate internal lighting requirements...

Yet another gripe I have with Mobilinc... The fact that it truncates names to one line of text makes it necessary for me to wrap all the functions that I want to map to Mobilinc shortcuts in in programs with grossly abbreviated names... So "Water South Zones at Dawn" becomes "Water S AM" Not like its a huge deal, and it's certainly close to the bottom of the list of changes I'd like to see in Mobilinc, but I can't image it's that difficult to word wrap the program name across two lines...

Having just passed the 75 device mark (and still growing, LOL), removal of my entire system would likely take me weeks of evenings and weekends, and despite the investment I just can't see that being a viable option. I might be more inclined to consider a compromise where I left all the "basic" devices behind (SwitchLincs, OutletLincs, etc.) linked appropriately to provide typical household lighting and outlet control, but taking the ISY and PLM along with the devices requiring custom programming, like thermostats, motion sensors, etc.

I agree that Insteon / ISY likely will have a neutral or negative impact on property value, but wow - the thought of rapidly undoing all that I have done over the span of years makes my head hurt...

I have also run the Intermatic IG1240RC3 since before I started my Insteon build out with no comm issues... As others have said there's really no way to tell if it's done any good, but in 2.5 years the only Insteon device I've had to replace is a PLM...

Wow, when I saw this thread I figured this rumor was too good to be true... This is great news - I'd definitely be interested. Any target date for availability..? Well played, UD!

Wow, great rumor! After my last replacement of a 13 month-old PLM I now keep two spares - 1 for the inevitable just-out-of-warranty replacement of the unit I have in service now, and another just in case that replacement is dead in the box... Hard to imagine UD could do any worse...

Sure, I could see where something like this could work, thanks! And to your other point, I'm not so sure that the my issue isn't lack of faith in the algorithm either. My measuring cups got delivered today... I look forward to getting an accurate output number and then observing and experimenting from there...

Glad I saw this thread - this has had me scratching my head for a few days now... I've been setting up / observing my newly-purchased irrigation module, and I started on a day when we got just under an inch of rain. Now today, after 3 consecutive sunny 85+ degree days I see that the irrigation requirement is still negative. I'm not yet using these results to schedule my watering, but I'm betting that if I was the sunniest parts of my lawn would be getting pretty crispy... So forgive the noob question, but does the evapotranspiration value represent the amount of water that needs to be replaced / applied on a daily basis..? If so, I would think that value could be used in conjunction with the Total Rain Today value to come up with a suitable work-around requirement estimate in these situations, no..?

Ordered... Thanks!

Thanks - that's great info for those of us just getting started with this! I do have one question... How are you folks figuring out how much water your system is putting down? My system, for example, covers about 13500 sq. ft. using 27 heads distributed across 7 zones. Each head is currently configured to flow between 1 - 2 gpm depending on my "guess" of the relative requirements at its location, and each zone is currently run between 16 - 22 minutes depending on the amount of sun / shade it sees. Add to all of these variables the fact that all zones have varying degrees of overlap (all "points" are affected by at least two heads, but some see 3 - 4), and it seems that estimating a system-wide output with any accuracy would be nearly impossible...

Thanks Lee, looks like I'm all set - with your help the RemoteLinc is triggering programs as expected. I first tried the device restore with no effect, but after the PLM restore I immediately noticed event viewer communication traffic with button presses and my programs were firing. Curious... could this have had anything to do with my recent upgrade from a 99i to a 994i PRO..? It occurs to me that this is the first device I have added since... I did not replace the PLM, only the ISY. Should I have restored the PLM as part of the upgrade..? Thanks again!

Yes I do. SwitchLincs, KPL's, an IRLinc, a motion detector - they all generate comm events in the viewer. Not so with the RemoteLinc however... Even though it will successfully act as a controller for a scene...

Tried this with the remote at varying distances from 2 dual band devices, moving it closer until the were right on top of them - it still does not work and I still see NO event for the remote button press. So I dragged the 'MBR Remote - A' in to a scene as a controller, where I know it works and I STILL see no events in the viewer...

Status = FALSE, Last Run Time is blank

So this one's got me befuddled. I've purchased my first RemoteLinc2 (2444A2 v.37) and am having difficulty integrating it in to one of my existing lighting programs. I boiled it down to a simple test program, and I'm still having no luck getting a RemoteLinc scene button to trigger it... By my understanding this should work, should it not..? If Control 'MBR Remote - A' is switched On Then Set 'Lighting / Interior / MBR Lamp Module' 250 (Beep Duration) Else - No Actions - (To add one, press 'Action') I have a 994i running 4.1.1 I've been through the linking procedure a number of times, it always succeeds with all four nodes appearing in the device list. Adding to my confusion is the fact that any of these nodes can be dragged into scenes as controllers and successfully control them... Have I missed anything..? Any ideas / suggestions would be most appreciated! Thanks!

Not a bad idea... Perhaps you could fashion some sort of bracket to mount it on the center post below the socket...

Your wife and my wife must be related... Seriously, in our household (an older home with few ceiling fixtures and many table lamps) what you're describing is a pretty big hole in our automated lighting strategy. The issue is not specific to the Insteon bulb, but arises from the lack of a common point of (Insteon and human) control at the lamp itself. So Insteon turns the lamps on programatically via an Insteon bulb or an OutletLinc, and my wife runs around turning them off via the the bulb socket switch. Very frustrating... As Brian suggested I have resorted to KPL's in the Smarthome tabletop cases to control our bedside lamps, and have successfully retrained my wife in their usage. This solution works well, but would be a bit costly to implement at every lamp, or even those that we use most often... As I have posted in the "Wish List" thread on the Smarthome forum (HERE), I think this issue could be addressed pretty neatly by integrating Insteon technology in to some sort of touch lamp modules such as these: http://www.touchandglow.com/product-p/t-302s.htm http://www.touchandglow.com/product-p/m-102.htm --Bill

Definitely concur with considering more keypad locations - I went with 3 in a 3k sq ft installation. The Master Bedroom keypad is a must! And if you do decide to go with 3 or more keypads, the Elk M1DBH M1 Databus Hub can simplify things, allowing you to wire your keypads with home-runs (star topology) rather than daisy-chaining. Beyond that, I might recommend a larger panel to allow more room for the add-on modules mentioned, as well future expansion. The 14" model included with the kits fills up pretty quickly...

Hi Lee - I'm sure you're probably correct. One of the questions I posed in my original post was whether my attempt to "toggle" was a misuse of the "Scene Activation" buttons (I - L), and it may very well be that the answer is yes... The instructions do indicate that these buttons do not support OFF, but on the other hand they also state that buttons (in general) can be linked in a "toggle" mode, which didn't seem to make much sense to me for the A - H buttons, given that they are automatically linked in pairs. That's what led me down this path... My eventual goal is to migrate this functionality to my universal remote, and given that this scenario will pretty much force me to use soft keys, I'm trying to avoid having more than one button per device - thus my preference for "toggle" functionality. Looks like I have some more tinkering to do... Thanks again for your help! --Bill