io_guy

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).

Dlink doesn't appear to use a standard url for each camera. I have a dcs-942l. To get the commands I open wireshark and then execute the various command from the Dlink web interface. Wireshark will log the commands, which you can then use in the ISY. But if you're lucky, some of these may work: ftp://ftp.dlink.com/Multimedia/URL%20Commands/

Pretty much any IP camera should be able to be controlled via HTTP commands. Meaning the ISY's network module should do the trick. If there's no docs with the camera, stick wireshark on it. My d-link came with no docs, but I control the IR mode, zoom, etc. and recording from the ISY. I turn IR (B&W) on after sunset (or when the room lights are off), and set recordings based on time and motion.

Yes, make sure it's version 99 or above Sorry for the off topic question... Michel, why >= v99? I have a dual band in my system right now running v92. Just wondering if there are issues I should be concerned about.

Absolutely not true. The IT-100 provides full control via a published API (try to find one for any other IT-XXX device). It acts and functions identical to any control panel on your wall. Elk integration is handled in a virtually identical way. The M1EXP is nothing more than an ethernet port connected to th Elk's RS-232 port.

Reliability, simplicity, no batteries. Anytime you connect a wire (and that goes for any technology, not just alarms) your system is more stable and secure.

There is currently no support for this system. The ISY natively supports Elk and can support DSC panels through a a Windows program and some hardware. The Concord is quite an old system. I would recommend setting yourself up with something else, pretty much all the alarm installers will give you a free system if you sign a contract. Also, make sure you're setup for wired, not wireless.

Yes, as you said. Only one of your blacks is live because the other is relying on the connection to bring it power (parallel circuit). I'm not trying to be rude here at all, but I would recommend picking up a DIY electrical book to review common circuit wiring. The circuit you described is very common and you should have a good understanding of its principle before changing house wiring.

Most of the Canadian (if not all) stations do not provide rain data. I'd love to see a way to inject rain data into the ISY via REST. That way I could pull it from Weather Underground. I could just send it as a variable (which is what I do now), but directly into the ISY internal variable would allow it to work with the irrigation module.

I would doubt you'd see any "garbage collection" impact in this application. SD cards are extremely slow to begin with and there is very little fragmentation impact since the files/data you're reading is tiny anyway. This really comes into play with things like SSDs where you're expecting 100-500MB/s (depending on model) and large files. Wear-leveling, or wear in general would be the bigger concern, but it will likely be low as well. Virtually every memory controller these days has proper wear-leveling and with the amount of free space on our ISY cards, there a lot of room to play musical chairs. This used to be a problem years back. My automation house used to build embedded industrial PCs which used CF for storage. These controllers had no wear-leveling. With an ~1,000,000 (very rough number) write before death limit, a card would die in less than 2 weeks if you wrote to the same spot every second. That being said, avoid writing wherever possible. In a "real-time" system (or a small automation controller with limited resources) it is bad practice. If you're concerned about saving data, stick the ISY on a cheap battery backup: http://1wt.eu/articles/alix-ups/ Just my ramblings...

404 is Auth. You need to send user/pass with the command.

I agree with Lou, I would never lower my temperature. Go tankless, bacteria worries and setback issues solved.

Fast On/Off is an immediate double press (very clean solution). Waiting 3s or some amount of time would need a program against it (compare control off press w/ status of already being off).

Interesting idea. I just put together a quick "Link" program to play with this. I setup my phone with a static IP in the router. The Link pings the specified IP address and sets a variable within the ISY depending on whether the return was a success. Seems to work ok - I had it auto-disable my alarm as I made it to the doorway. Some issues with this idea (my implementation anyway): - Not sure how continually pinging the phone will impact battery life - Assumes everyone is capable of setting a static IP for wireless in their router (otherwise I could try IP lookup via arp and Mac Addy) - I'm sure there's more The nice thing about implementing it similar to this is that no special software is required on the cellphone (aside from wireless).

Personally I would just ditch HS, having 2 controllers is just asking for complications. I don't know your exact configuration or models but the devices you listed can likely play nice with the ISY... DSCLink for the DSC, a CAI WebControl board and WCLink for the 1-wire, ISY Brultech Module for the Brultech.

Here in Canada, all my smoke and CO sensors (brand is Kiddle) run through the same 14-3 circuit and interconnect (communicate) with each other. They use the 120VAC as power and as a bus to send signals. I use an SM120X and CO120X to tie into these. These are Kiddle isolated relays units that tie into the 14-3 and provide isolated 12VDC output that I tie into EZIO insteon inputs.

Insteon itself doesn't even have a normal temp sensor. I made a waterproof unit by potting a DS18S20 one-wire and connecting to a WebControl board and WCLink. Whole thing was about 50 bucks. If you're interested search WCLink in the forum and waterproof ds18s20 on google (or use plasti-dip).

A few of us use the CAI WebControl board for remote 1-wire temperature sensors. See these posts: viewforum.php?f=77 viewtopic.php?f=51&t=6470 I have remote temperature from the basement and second floor going into the ISY. I use these values (combined with my Honeywell Thermo on the main floor) to control dampers to balance temperature.

Michel, I emailed over a piece of my log file, nothing seems to be directly related to when I press an IR button.

I'm using the built in IR. It seems to have started for me in the last few builds, since the ISY internal network performance changes.

I've been running into IR issues over the last few builds, today IR wouldn't work at all. I have a number of programs looking for IR presses, which then send network commands. Over the last few builds I've seen a significant lag, where I'd press the remote button and a few minutes later the ISY would react. Today it stopped working all together. With an ISY reboot things go back to normal, but it gradually gets delayed again. I check both the log and error log but see no IR details. Sorry for the vague info, if there's anything else I can grab let me know.

If your device accepts a network command, it's highly likely you can get the network module to work. You just need to find the proper command to send.

Sorry for the late reply Michel. Yes, user/pass is always sent.