io_guy

Pretty cool. I'm in the process of doing something similar because of issues I'm having with the ISY's built in IR. Going to be using a GC-IRE and a "GCLink" program to send variables to the ISY. IR learning will be GUI based. The nice thing about that unit is it does the full spectrum of IR frequencies, not just 38kHz. On the send side, with an IP2IR you can send commands directly from the network module, no need for a middle man.

Anyone else having IR issues with this version? Since upgrading my system to 4.0.1 none of IR receives work anymore. The event viewer sees my remote button presses but it's never the code it should be seeing.

Not storing codes is the exact reason I bought the IP2IR. It will send any IR code you send to it. I hate having a hundred "smart" devices in my home - I like having a single controller as the brain, not storing settings in multiple places. With an IP2IR I setup all my IR commands in the ISY's Network Resources and the IP2IR just receives/sends. Works like a charm.

I use a fan-powered Honeywell. It's very similar (same water system) to the bypass but uses a fan to recirculate the air on the furnace outlet side so no bypass ducting is required. You never have to bother with closing a duct because it doesn't exists, you just don't turn the unit on. http://yourhome.honeywell.com/home/Prod ... HE360A.htm I agree with Oberkc on keeping this away from HA. If you have a thermostat that supports humidifiers, use it. I have a Honeywell VisionPro IAQ which does, I set the desired humidty level on the thermostat and it does the rest. It also has a "frost" level setting and outdoor temperature sensor to handle johnnyt's concerns about mold/mildew.

I'd recommend the Raspberry Pi over the pogoplug. It's smaller, uses less electricity and can run off an SD card. I've used both with archlinux and the Pi is cleaner. Currently running all my link programs on a Pi. I've looked at Nest previously but have zero desire to do anything with it until a public API is available. "Hacking" into their web portal to talk to your home thermostat is just way too ugly. Personally I'd love to see some sort of "open API" added to the ISY, where specific ISY variables/functions can be read/written via REST, basically allowing us to interact with the internal ISY thermostat system instead of bit-banging over custom variables. I do the bit-banging right now with my Honeywell (Enviracom) but it's definitely not as clean as it could be.

My ADT contract ran out a few months ago and I went through the decision of switching to Elk or sticking with DSC. In the end, I stuck with DSC. Price wasn't the factor but it is quite a bit cheaper. For me, DSC is the largest alarm player in the market and have a very stable system. I like the Elk system but fundamentally I have an issue with having that much power in my alarm controller. This is a UL certified alarm instrument - in my opinion it's not the place to control lighting, garage doors, tempertures, write programs, etc. With all those features and constant firmware updates it's just a recipe to introduce bugs. I like the fact that my alarm system is hard coded and geared to just do one thing - alarm. That's why we have an ISY - to control automation. And last, the new DSC touchsreen is a thing of beauty, Elk's screens are ugly duckings.

At this point no. The interfaces and API that Honeywell uses are absolutely terrible. However the Envisalink 3 supports Honeywell/Ademco. They are working on an API specific for their card. Once complete, I plan to add support to DSCLink.

Archlinux http://archlinuxarm.org/platforms/armv6/raspberry-pi

I use an EnvisaLink card with my PC1832 and DSCLink into the ISY. Everything is hard-wired. I run DSCLink on a Raspberry Pi so it only eats a couple watts of electricity and doesn't need a standalone computer. I can't remember the last time it went down. I use the new PTK5507 touchscren keypad - it's quite nice. The EnvisaLink can be accessed over the web but cannot directly link to the ISY without DSCLink.

LeeG, Correct. With a I/O Linc going to ground, 12V wouldn't be needed. I use the relays with an 8SA so I send 12V through. Sorry for the confusion there - I try to avoid the I/O Lincs since the $/input ratio is quite high. rsansev, As LeeG pointed out, 12V PS not required (with standard I/O Linc). I haven't seen the specs on the Insteon detector but the advantage to linking into the Kidde is you get all detectors (interconnected, full house) off the single relay and you can also do carbon monoxide (plus you're not adding any extra detectors). I added the relays near my basement detector so they're not visible. If you're planning other I/O, put the relays in the basement and pick up a multi I/O unit like a 4x2 or 8SA.

That's a few minutes I'll never get back. They're arguing about 10 different points there. No, a secondary relay shouldn't be used as a replacement for a proper alarm smoke detector - that should be powered from the alarm system to allow for proper power loss protection. But for just automating it back to an ISY, the XX120Xs are perfect. Interconnected detectors, dry contact, what more do you need. The relays should be wired into an electrical box (since the coil side is 120V). I sent the output side to a terminal strip. Some of those guys go on about it powering auxiliary devices only - they obviously don't own them. Yes there's a LV powered out but there's also dry contacts perfect for automation. You'll notice that the people who actually owned them on that post said they work great for automation.

LeeG is correct. I have both of the xx120X in my house. The relays close when the alarm goes off. You supply 12V to the relay and wire the other side back to IO. They work great. http://www.kidde.com/Documents/sheet_re ... odules.pdf

I don't know the capabilities of the ISY to comment, but what about just making the SD card contents available via FTP, RSYNC, SMB or some other file sharing method. That way it's invisible to the admin console and power users, if desired, could schedule backups at any frequency they want using their own choice of software.

Yes, you just need the network module installed.

I don't have thermostats to test but you could try this program, which logs ISY data to CSV as well. viewtopic.php?f=79&t=7763

So I added an access point and the range was still terrible. I then removed the RL2 from the ISY and re-linked. After that, range is much better (usuable). Not sure why it would have made the range "marginal" by improper linking. Question... My RL2 shows up in the ISY as v.00. Is this normal or should I actually see a value?

It is a dual band dimmer installed in a metal wall box. I'm thinking I'll try picking up an access point for the wall outlet. That's as close as I can put one.

Is anyone getting decent range out of their RemoteLinc 2s? I picked up one today and installed a dual band device 15' from the back wall (brick) of my house. The RL2 will not work at all outdoors, terrible range. The only real option I have left is to add an access point, which would be directly on the inside of the exterior wall. I'd like to use this RL2 to control audio from my hottub which is 10' from the exterior wall. Am I asking too much? Any tips? I don't get > 15' from my nearest dual band, no chance of the advertised 50'.

Yea, the Homeseer quote is a Homeseer issue, not DSC. The DSC sends all events across the bus to the comm module (IT-100, PC5401, whatever) and the comm module in turn sends all out - there are no lost packets. The only spot for lost packets is on our end. Either a poor RS-232 setup (assuming using a serial comm) where your baud rate it set too high for line length, or your software is stalling and not grabbing all commands being sent (The comm module output does not buffer). It's a moot point either way because an hourly status request should do nothing to affect system performance. It's fine to leave in. I would really jump straight to Norton for my first test. Just a note, I believe you're using a 2DS. In that case you should be looking at the EnvisaLink API, not the IT-100 programmer's manual (very similar but small differences exist). Just as a sanity check on your issue (my setup is only 8 zones), I just populated 40 zones with ISY variables to test speed. From status request to last variable write was within 2 seconds (log doesn't go to milliseconds).

Please show me in the doc where it says that.

The IT-100 functions directly like a control panel (and receives the same data). The only time data would be missed would be if your computer was locked up.

Your error log is over a 6 day period. I would suggest doing a couple alarm status requests and checking the ISY's general/error log over that timeframe. As mentioned, I run DSCLink on W7 and a PogoPlug, my DSCLink log shows the request, DSC return, ISY REST sends and ISY replies within the same second (maximum two). Try disabling any additional software (such as 3rd party virus/firewall) to see if it makes a difference. My W7 machine runs the standard firewall and Microsoft Security Essentials.

Tim, Yes, exactly. The only time I've ever fixed IPs on clients is in an industrial setting, where a DHCP server did not exist (or in the really old days when a device didn't actually have a DHCP client). aLf, Everything behaves the same. You still specify the IP address in the router (reservation, IP/MAC binding, fixed lease, whatever you want to call it).

Personally I would never setup a static IP address on a client - the proper place for a static setup is via reservation on the DHCP server. Setting a client static is a recipe for conflicts.

I have CH AFCIs in my bedrooms, no issues with Insteon Comms.