mwester

I should probably be a little more clear on the polling thing, at least for the benefit of others who stumble upon this thread. You'll need two programs actually -- one that is triggered on STATUS of the IOLinc and does the email/text msg sending bit. Another that actually does the periodic polling of the IOLinc. I do this with one of my z-wave switches that doesn't support "instant status". Here's the program that does the polling - it's set to run at startup, and every 75 seconds thereafter: pollz - [ID 0005][Parent 0001][Run At Startup] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat Every 1 minute and 15 seconds Set 'ZW 002 Dimmer Switch' Query Else - No Actions - (To add one, press 'Action') And here's the dirt-simple program that controls my desk lamp: officeLights - [ID 0004][Parent 0001] If 'ZW 002 Dimmer Switch' Status > 50% Then Set 'Hue Hub / Dimsum' Turn On Else Set 'Hue Hub / Dimsum' Turn Off

What is the purpose of signaling the event to the ISY? This is an important factor. If the ISY is required in order to perform critical operations such as load-shedding, etc, then you need to rethink your entire solution -- hardwiring is necessary, and the controller probably shouldn't be an ISY. The big problem is that at the time the generator is coming on-line, it's pure optimism to think that a powerline or even RF signal is guaranteed to make it through. On the other hand, if the ISY is simply going to do some convenience things for you after the generator is up and running, well, then just poll the IOLinc rather than relying on it sending a message. Write a program that's based on STATUS rather than Control, and arrange to run that program every minute or two. That should be fast enough for any "convenience" actions, but still not pose too much of a load on the system. My concern with z-wave is that at the time the generator is coming online, who knows what the status will be of the various "things" we all have in our houses that have power supplies and capacitors in them -- the probability of spurious RF noise seems fairly high to me, so I suspect you may also occasionally miss a z-wave device's message during the generator switch-over as well as certainly missing any power-line signal.

Because this forum is for the ISY controller?

It's possible - but the most probable failure in the KPL would be the output TRIAC, which wouldn't prevent it from communicating. It's also possible that the fixture (if it uses an electronic ballast) is damaged -- and putting enough noise (or sucking out enough signal) to cause problems. Or, perhaps nothing has failed, it's just in a state where it's messed up (either the KPL or the ballast). So, the first step to do is to remove that florescent fixture - ASAP. Then pull the tab on the KPL to reset same, and see if it comes back to life. Then test the load on the KPL to see if that part of it is still working.

All of the above is true. But doesn't provide you with a lot of immediate help. Here's the very next steps you should take before you even start reading up on creating scenes in the ISY: Grab a clipboard and an pencil, go around the house to each Insteon device, and make some notes: - Location (e.g. "Guest Bedroom", or if more than one switch in the area, something like "Kitchen counter lights - North, middle paddle" - Actual function (e.g. "main light, dimmer", "ceiling fan, fan on/off", or "no direct function" for switches that no longer operate anything - Virtual function -- this is a memory exercise at this point! -- what was it that this "no direct function" device *used* to do? Now in the ISY Console, match up each device with what you have on the clipboard -- you may need a helper to check that the switch clicks or the leds on it move in order to ensure that you have a match in the Console to the actual location you noted on your clipboard. Name the device appropriately (I use terms in the name such as "Main" to describe the device that actually has the light wired to it, and "slave" or "secondary" to describe the "virtual" switch -- the one that should control the light, but no longer does. Once you've got all devices identified in the Console, you're more than half-way done. The rest is just dragging and dropping and setting up scenes to link the various switches together as described in the previous posts -- and all that is done from your computer, no more need to futz about with the switches themselves.

To help you troubleshoot the issue, the portal doesn't connect to the ISY -- it's the other way around. The ISY reaches out to contact the portal. Combining that with the fact that it cannot connect to the NTP server, the logical conclusion is that it's your ISY or your router that's the issue. Reboot both (router first) -- that would be a logical next step.

Not unless you use a network *hub* or have a managed switch that you've set up to duplicate traffic to the monitoring port. The issue is that all modern network devices are "switches" at heart, which means that aside from broadcast traffic, as soon as the switch learns which devices are on which ports (based on ethernet MAC addresses), it directs traffic to only the target port. The result is that wireshark will only see broadcast packets, and traffic to/from the device on which it is running. As for wifi -- slightly better, but the hidden transmitter problem can also make a full capture difficult.

I feel your pain -- I've a brand new house, wired per code with all modern (and name brand) appliances and devices -- even the phone chargers are all top-quality name brand. My Insteon network "works", and that's about all -- for example, I just replaced a failed KPL in the kitchen, and it took most of an afternoon to get the link database successfully written to it. The general troubleshooting advice available is painful for any modern house -- prepare to reset clocks and reboot computers, etc. You have to go to your basement, turn off all the breakers, and turn them on one by one until the noise problem appears -- that last breaker you turned on is the circuit that has the problematic device on it. Now you need to find everything on that circuit, and remove it -- everything. In my case, I even un-wired an outlet that had a built-in USB charger, just to make sure that wasn't contributing to the noise. Hopefully that'll find the problematic device(s) for you. (For me - I'm switching to z-wave as devices fail and I find acceptable replacements... I've just too many Filterlincs littering my house walls, and still have too many noise issues. IMO, the days of the clean sine-wave on the power-line are past us, what with high-efficiency switching power supplies in everything (including LIGHT BULBS!). Insteon's RF is, by design, coupled to the power-line zero-crossing, so the dual-band thing isn't an effective solution to noise (just to bridging or extending)... which basically means that, in my opinion, as a protocol Insteon is doomed to the dust-bin, and I just don't see that SmartHome has what it takes to bring a viable replacement to the market (there's already too many players there, what with Zigbee and Z-wave, etc). But all that's an opinion - there are many here who feel I'm full of **** )

The LED behind the button can only be turned on or off as part of a scene. Create a scene that has nothing but that button in it, and then you'll be able to turn that scene on and off from the program.

There is no support for sensors that might be attached to a Hue Hub. Network resources can't hep with this (they are outbound only). And the Hue node server (via Polyglot) doesn't support sensors.

Mr. jtara92101 is correct - you need to be careful to choose what the program does with the double-tap. That said, I do have two switches, with loads, that also have programs on the double-tap. The key is to make sure that the program doesn't try to adjust the load that's controlled by the switch that triggered the program. In my case, the two switches are at the bottom and top of the basement stairs -- a double-tap OFF on the switch will do an internal "fast-off" of the attached load (the light controlled by that switch), and it also triggers a program on the ISY. The program turns off all the lights in the various rooms in the basement, staggering each off from back to front in 30 second increments. The result is that a quick double-tap off at the top of the basement stairs ends up with all the basement lights turning off -- but if for some reason someone is still down there, they have enough time to turn the lights back on locally before being plunged into sudden utter darkness.

I've participated in many other Sonos beta tests up to now, but I figured I'd been passed over for this one since I've not heard from them in months.

Swapping a PLM between a PC and an ISY is not practical, for a lot of reasons. The biggest issue is that changes made (such as links inside the PLM) by the ISY will not be known to the application on the PC, and if the PC makes changes to the links, the ISY won't know about them. The result is that either or both will end up confused, and you may need to rebuild your Insteon network in order to recover, in the worst-case scenario. If you still insist on doing that, you'll want a serial PLM to connect to the ISY, and put the USB-to-Serial adaptor on the PC. By-the-way, I use both a PC and an ISY -- but I use separate PLMs, so that neither one gets confused. The PC is for debugging and testing work, the ISY has become so important in the home automation system that I can't turn it off to "borrow" it's PLM anyway.

Looks like you may, at some point in the past, have installed some custom web pages? Such as this package, perhaps? http://forum.universal-devices.com/topic/2560-isyajax-wip-network-module-custom-pages/

@larrylix -- don't get hung up on cross-over cables for RS232 serial stuff... that standard defines a DTE (Data Terminal Equipment) end and a DCE (Data Communications Equipment) end. The TX and RX pins are swapped between the two, so a straight-through cable worked just fine. The implementation using the RJ45s on the PLM and ISY follows the same idea -- the TX and RX pins are swapped so a straight-through cable works just fine there too.

Potentially true; there may indeed be additional costs in a z-wave solution. Also note that the costs may involve replacement of noisy/interfering devices, such as a 900MHz baby monitor, with newer ones that might operate in a different radio spectrum. Of course, as I have well learned, there are also potential hidden costs in the Insteon solution -- I have more unplanned-for Insteon filterlincs than I have in all other plug-in Insteon modules put together. I have multiple of the very large (and very expensive) XPR filters. I have thrown out numerous fully-functional-but-noisy phone chargers (which wouldn't be so bad, except most of them had to be replaced with very expensive name-brand Samsung chargers). I've replace countless LED bulbs in a never-ending hunt to find ones that don't interfere with Insteon... In the end, one must gaze into the crystal ball, and take a guess at which technology is most likely to be cheaper in the long run. Or, in my case, I took a look at Insteon's recent technology developments to see if I could get a hint as to their future -- are they considering better RF technology, encryption, security, local management? Or are they focused on marketing glitz and centralized Smarthome-owned management? Are there others beyond just Smarthome who are bringing Insteon-compatible solutions to market? Does the technology on-the-wire or on-the-air seem to be static or is it being improved? Alas, Insteon loses on every count. And I deeply regret that I got sucked into the Insteon device hype so deeply -- for a few dollars more per device I could have devices that have a future beyond our local electronics recycling drives!

And this is why I'm replacing Insteon devices with z-wave devices as they fail... the days of a "clean" sine-wave on the power line are long gone, and every appliance, light bulb, phone charge, wall wart, and now even major infrastructure items such as furnaces, heat pumps, and A/C units contain switching power supplies that disrupt Insteon devices. You can't filter everything. Just not practical. Never-the-less, in case you feel you must try, the biggest baddest filter out there is the x10 pro XPF filter (available on Amazon) -- it'll handle 20 Amps MAX, and you'll need two of them if your heatpump is on 240 VAC. There's nothing bigger available - I know, I've looked.

As with so many things in life, the answer is a definite "It depends"... and the answer to the logical next question ("So, what is it that it depends on, then?") is "Way too many things for anyone to be able to determine without trying it". I have no issues with my z-wave devices -- 50+ feet in every direction from the ISY, with no failures that I've ever observed. I have only one secure device (a garage door opener), and I purchased the Aeon siren just in case. But the optimum routing calculated by the ISY is direct to the GDO; the siren isn't necessary. (So I'm glad I bought the siren -- not only does it work far, far better than the repeater, but it's also useful as an alert device.) As far as I can tell from the ISY, nothing in the entire house actually gets repeated by any other device; everything claims to go direct to the ISY. To be fair, I have no other 900MHz devices in this house, and my nearest neighbor is 1/8 of a mile away (and they go "mooo" -- the people are further still). So I have no RF interference to worry about, and I expect that accounts for the excellent range I get. You might try unplugging baby monitors, old cordless phones, and searching for things like remote-control-extenders, etc, that use the 900MHz band. Signal strength is also attenuated by building materials. Metal is (of course) the worst, so a door lock that's on a solid steel door in a steel door-frame is already starting from way behind in terms of signal -- try placing your siren so it is directly in front of the door (rather than off to one side or the other. To a lesser extent, masonry and old plaster can also reduce the signal -- as can drywall, although one or two layers of drywall is hardly going to matter at 900 MHz, frankly.

Alas, the way the Syncrolinc is wired internally means that if the sump pump's startup surge (or other event) blows the fuse, then the Syncrolinc itself is dead. There is no heartbeat, and trying to query it to find out if it was in a "not responding" state was unreliable -- but more importantly, even if I managed to get a message out to me that the Syncrolinc had failed, that doesn't help me much -- the pump isn't pumping, and if I'm not there to fix it, well, then the "stuff" hits the fan, so to speak... The right solution is to use a transformer-based current sensor, not a Syncrolinc.

Please make sure you have a backup sump pump if you are using the Syncrolinc. The Syncrolinc is an "intrusive" rather than non-intrusive transformer-based current-monitoring device. More specifically, rather than using a current-sensing core that simple goes around the conductor to your sump pump, it actually inserts components into that conductor -- one of which is a fuse. That sounds nice (hey, who doesn't want a fuse?) but it basically adds another failure-point for your sump pump. I know this because I tried to use a Syncrolinc for the same purpose you describe here (except my pump was a septic tank lift pump). And I know about the fuse from experience as well. (I now use a proper non-intrusive current sensor with an IOLinc.)

I use the Aeon Labs multisensors (z-wave) for this purpose.

Counter-intuitive though it might seem, a firmware upgrade does not upgrade the UI. You have to download and install that separately (though you can download the UI app from either UDI's web site or from your ISY once you've upgraded it).

To be completely accurate, that merely indicates that SmartHome cares about customer service, not that they care about quality. The two are linked, but I would agree with the sentiment of the original poster -- it's not obvious to me that SmartHome really understands that if they addressed the quality issues, they would have fewer customer service issues. As a case in point, I'd suggest taking at look at the long-standing issue with the PLM. If that's not enough, consider something that takes no hardware whatsoever -- the issue where SmartHome failed to provide UDI with the API for the alarm device. No company is perfect, but SmartHome's products are certainly below the average expectation for consumer-level devices these days in terms of longevity and reliability.

Is it fair to say, then, that the tags do not function well when attached (or very close to) large metal objects -- but they do work ok at large distances, or when shielded by masonry or plaster? Can someone try placing the tag on a non-metallic object inside said mailbox? It may be that close proximity to large amounts of metal is causing the RF transmitter (or receiver) to de-tune. Worth a try...

Alas, the syncrolinc has a few, um, "challenges". One is that with the ISY, the settings panel won't let you set current ranges beyond the very lowest end. I don't remember the exact figure, but I do recall that the problem is that the ISY truncated the value when it shouldn't have. Perhaps this is fixed with later releases, I don't know -- I retired both my syncrolincs. I was able to work around the aforementioned problem by using the "set" button technique to set the threshold instead of the ISY. Another problem is that the syncrolinc doesn't use a current transformer, but rather uses a very-low-value resistor -- and that requires that the device be fused. After my pump blew that fuse, and ceased working, I decided that was a completely unacceptable failure mode, and replaced the syncrolinc with a current-transducer and an IOLinc. The final problem is that the pump, when starting, generated a lot of electrical noise -- so until I wired in a big 20-amp X10 noise filter the ISY would only sometimes get the signal from the syncrolinc when the pump started. (I tried a filterlinc, but that is also fused - see the previous paragraph for that problem!) I'd recommend a current-operated switch, and an IOLinc instead. Use the Syncrolinc only on things that you don't care if they don't work.