mwester

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.

BTW, the "<>" icon in the toolbar when you post will format the selected text as code, which will make it far, far more readable.

My syncrolinc gave me similar issues -- kept losing the links table. I was actually going to write a program on my RPi to contact the ISY periodically to query and correct the links table in it. Then I decided that was fixing the symptom, and I should fix the problem instead. (Plus, I blew the fuse inside the Syncrolinc, which was a completely unacceptable failure mode for the pump it was monitoring.) So, I now use an A/C current sensor (a few bucks on eBay) and an IOLinc instead. Much nicer. (Search for "Neilsen-Kuljian D150" on eBay, or just look for "Current Operated Switch")

Y'all are just plain wrong! Electrical tape, light-dims, and all that still leave the dang thing BLUE! Power lights are green. That's the long and the short of it. Not just too intense, but wrong color! (Are ya listening, UDI?! Green! Make 'em green!)

BTW, once you complete this project, can you share your results? Specifically the resistor value you selected, and any tips for other interested folks who might like to try this? I'd like very much to get rid of the chunk of black electrical tape on mine -- which was my solution to that intense blue laser-beam emitted by the ISY. Dunno why manufacturers fell in love with those horrible blue leds; the soft green ones worked just fine and were far easier on the eyes.

Fire danger in basements is no greater than anywhere else - and egress windows/walk-out basements address exit requirements. Bronchitis? How? Proper HVAC installation ensures air quality is no different on any floor. CO2? See above. Radon? Tested, none here. Last house had a radon reduction system installed. Problem solved. SADS? How is the basement more dangerous? illegal? Say what? Is that what the Canadian government has been up to? Making laws about what floor is habitable? Good grief, talk about government overreach! Anyway, to help you stay on topic, why not just imagine that the OP wants a night light because his root cellar / freezer is down there, and it would help in those midnight snack runs!

Well, not yet. Once the 5.x release is out, cross-technology scenes will be available between Insteon, z-wave, and node-server-based devices (which would be one of the options for supporting the Hue). For now, though, you'll need programs and network resources.

There's no evidence that the capacitors are "higher rated" - just reports that they are higher capacity.

Ok, you're right -- "Enable Internet Access" is a poorly-named menu item that does not do what the name suggests. And even worse, what it DOES do is not supported by most current routers any more. And you're right about the Help/About text -- it too should not read "Internet Access Disabled", but should probably say something about your router not supporting UPNP. But since portal access has nothing whatsoever to do with either of those two items, just forget about those. The portal works in the OPPOSITE direction -- my.isy.io does NOT contact your ISY, rather it is your ISY that connects OUTWARD to the my.isy.io portal, and establishes the connection. So that message is telling you that your ISY has not contacted the portal. Which has nothing to do with the ability for you or anyone else to connect INWARD to your ISY from the internet. Since your ISY is responsible for establishing the connection to the portal, not the other way around, the error logs and information to debug this are on your ISY. The error logs, as MWareman suggested, are a good place to start. When mine refused to connect, it turned out that the problem was exactly as suggested -- the cipher set on my ISY was incorrect, and it was unable to establish a secure connection to the portal until I fixed it. The logs on your ISY tell the story.