io_guy

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.

I can certainly understand people's hesitation for running a 24-7 PC. For me, it just makes sense. I run a HTPC machine 24-7 anyway, and having the machine running allows me run about a dozen various "Link" programs to connect my home. I use a low power PC that only pulls about 25W on idle. An Atom based PC would be even less.

I do this right now (although it requires a PC running). ISYLogger can log (to CSV files) any variables within the ISY. I track indoor, outdoor, setpoint and AC status conditions to view a day of thermostat behavior. For external sensors, I have a ton of them connected via Webcontrol and WCLink into the ISY. Probably not as clean as you were hoping, but there are always options.

Marc, I come from industrial automation as well and 10 years ago, I would have agreed - no computers. In reality everything these days is a computer and there is device layer upon device layer talking to make a system work. Times are changing. Take Siemens or AB for example... PLC is really an embedded computer (with firmware) talking to a drive (another computer and firmware) communicating via some other device (with firmware) via some protocol (such as Profi, DN, MB, OPC, etc) to an HMI, which is really just an outdated Windows embedded machine running some other software. I've installed precision (0.5um accuracy) multi-axis tools into major fab plants that run completely custom .NET HMIs talking to QNX computers used as controllers. Anyways, your choice. I have a 2DS arriving shortly and I'll be adding support to DSCLink in case you change your mind.

1 - Yes 2 - Send an email request to UDI with the old and new device UIDs 3 - Wiki factory reset. It involves holding in the little pinhole button on the device 4 - Contact UDI 5 - UDI Energy Monitor currently under development

Use a state variable. In the first program's then, statevar = 1. In the else statevar = 0. In your second program, use the statevar as the if, not a program state.

Why not combine into a single program, with the off command going in the else? It will be re-evaluated (send new command) each time the temperature changes, but that shouldn't be a large amount of traffic. I control my ceiling fan (fanlinc) using a single program checking whether the upstairs temperature is > the downstairs temperature (one-wire sensors via WebControl/WCLink).