mzanni

When I wire up the finished product, I'll post it someplace in a bit more clean and thorough manner...if you think it will be of interest to people. apostolakisl: Amps v. Volts always takes me forever to figure out, which is probably why I should read more, but I'll roll with what you say here and go check it out. Maybe this time it will finally sink in. Running my multi-meter on this thing will give me answers, and I'll post my findings, though I suspect you are correct. In terms of the Elk rule, you are definitely correct, and I had started down that path. I didn't love that idea though, because I still needed to bypass and unbypass a zone, which is (obviously) different behavior than a normally wired zone. While it may be little more than a minor nuisance to see "ready - bypassed" vs "ready", the way it is wired now behaves exactly like a normal zone to the end user (read: my wife). Thanks again to the ISY team and people here at the forum, I have to say it is one of the best supported products I have in my house.

Figured out a solution so I thought I'd share just in case anyone else was curious: There really doesn't seem to be any way to do this programatically, not in a way that would conform to what one would expect from a normal zone. As such I took a hardware approach. (A basic understanding of DIY electronics will help) The outputs on the Elk M1 will put out 12v @ 50mA when set to on. There is also a constant 12v 50mA output and a ground on the output panel. Using a project board, I ran the ground (NEG) and Output 16 to a relay. The relay was only rated for 30mA on the input so I dropped a couple of resistors in to drop the amps (this is important if one is going to try this). A quick test turning on the output let me know the relay tripped when I heard the click. On the other side of the relay I put a 2.2k resister in front of the Normally Closed lead. I then ran one line from that resistor to the Zone 1 neg and a line from the other output of the relay to the POS of Zone 1. The next step was to write a program with ISY, well actually 2. The first program checks if the INSTEON motion sensor (could be any sensor) was "on" AND Output 16 on the Elk was off, if the conditions are met it turns on Output 16. The second program checks if the INSTEON motion sensor is "off" AND Output 16 on the Elk is on, if the conditions are met it turns off Output 16. Testing repeatedly has shown it works flawlessly and will show a zone violation in armed or unarmed states when the sensor is tripped. I think, from a security perspective, this is probably not a recommended approach for a few reasons: 1) It relies on some programming to set off the alarm, as opposed to solid-state 2) Network connectivity needs to be available to set the alarm off (this is why it defaults to being EOL closed in my configuration). Should the network be unavailable, the alarm will not be tripped. In the end, the ISY has proven to be exactly what I needed to allow me to go off on crazy tangent projects like this...and I'm having a blast.

...so I'm crazy then?

I have the ELK M1, ISY994i and the Elk Module, and here's what I'm trying to do: I need one more exterior door sensor, and it must be wireless due to location. Turns out I have an extra Insteon TriggerLinc so I figured I'd try to get that to act as a zone on my Elk using the ISY. Right there, I'm not even sure if this is possible and/or a good idea. So "nope, don't do it" would be a sad but understandable response. My attempt at this was to set a free zone in the M1 to be EOL and name is "Garage", obviously it starts out in a violated state as nothing is attached to it. After playing with the programming a bit, I ended up with two programs: 1) Check the Insteon to see if it is closed and if so bypass the zone. 2) Check the Insteon to see if it is open and if so unbypass the zone, thus triggering a violation. It should be noted that the "If" statement had to also check if the zone was bypassed first, because it is toggling the bypass and needs to know what state it is in before it does so to keep it in the correct state. So, here's the issue - this works fine if the alarm system is NOT ARMED. I get the chime, I can see the zone violated, all is well...however if the alarm is ARMED, nothing. From what I have found online, ISY can't bypass/unbypass when the alarm is armed...so there goes my program out the window. This leads to my next two questions: Am I completely off base on this one...can I even do what I'm trying to do? If it can be done, what should I do in the program if not bypass? (I've thought maybe throw a resistor in, but then all I can do it trigger a zone open for a sec before it returns to closed regardless of if the door is still open)

Thanks apostolakisl! That did the trick. I've been beating my head against the wall for a week on this. I'm going to get the Elk Module probably, because I want to code against the ISY REST system, and I suspect I'll need it. That, and I'd really like to see if I can get an Insteon open/close sensor to work as (or like) a zone on the M1.

First time connection. Been trying everything I can and it just won't work. There is some red-lettering at the bottom that says I can get FULL functionality out of the Elk Module, which I'd consider spending the $99 on if a) I knew what else I got out of it and I could get this thing to connect. Side note: This is complete B.S. on Smarthome's side and doesn't reflect well on UD. If you are going to bundle the ISY with the ELK system, you should mention that it costs another $100 to get some module you need. Honestly, reading all the available verbage online, it is implied that you get everything you need.

I have an Elk M1 and ISY 994i/PLM and I am experiencing what I THINK is an issue with communication between the two (as seen in the image attached, ISY screen on top, event log on bottom). First off, there is nowhere to enter a security code that I can see, just the dropdown I highlighted (which is empty). Secondly, the even log shows what you see below. I believe they are trying to talk or else I wouldn't have even gotten this far. * I HAVE set it up to use 2101 to communicate unsecure with the Elk, and used the RP software to test this. It should be noted that I currently have all of the first 16 zones in the M1 set to Normally Open, as I am yet to put any sensors on it (they are backordered). I am wondering if this is just a matter of the Elk not having any Zones and the ISY not knowing what to do with it. That said, I find it weird that I can't even use the ISY to "Go To Elk Console", which when I click it, does nothing. Any help would be appreciated.

Michel, First, thanks for the FAST help and attention to this. I used another box, and it worked after a bit of coaxing. Definitely using the installed Java version (versus the sandboxed web browser). I had done a bit of snooping and it looked like a pub/sub model application, so I'm not really surprised by the results. Anyway, it finally go working and communicating. I do have a couple of other small issues, but they are no doubt part of the learning curve / configuration. Again, thank you for the assist. -Matt

Michel, Ok, I am ASSUMING I should see something actually scroll up live on the event viewer...I'm not. One might be led to believe this is an issue with the firewall. I'm going to try to figure this out, perhaps try another PC like my media server and see what happens. In the mean time, can you tell me what ports the ISY uses to communicate with the app, and also whether it is TCP or UDP? I could always set up a rule in the firewall to get around it. Thanks, Matt

Yeah, it IS a bit odd right? (by the way, the FAST response on a Sunday of all days is impressive, and keeping my frustration level down, thank you) ISY (994i): 3.2.6 Java: 1.7.0_09 Firewall: I am running Windows 7 Enterprise SP1. It has the firewall enabled and I cannot shut it off (it is set on a policy as this is a work laptop). I do have local admin so I can add rules to it. Some more info: This is all on my local LAN (192.168.72.x), which is wide open inside, so there should be nothing else interfering with the traffic. I set the ISY to a static IP as I do with all devices that I know will remain in place, and I might need to access by IP. It does see the PLM: v9B/connected.

Ok. I followed your instructions: * Unplugged PLM from the wall, waited about 60 seconds * Plugged PLM back into wall * Rebooted the ISY * Ran the admin console There was nothing in the log at all, so I hit "Start Linking". I waited a bit and re-ran the Event Viewer, still nothing in it. Additionally, I get the same screen as posted above, and I've left it running. Not sure what the deal is at all. Thank you for the quick response, I'm feeling pretty frustrated right now.

I just installed my Elk M1 Gold, and started configuring my ISY 994i. I ran the admin tool as per the instructions, and when I hit "Start Linking" I get the screen attached. It doesn't give me any options, and it doesn't change the "Start Linking" icon to an (X) as the instructions say it should. It just stays on this screen, counting up to 100%, and then does it again. I have left it running overnight just to be sure it wasn't a timing thing, in the morning it was still doing the same thing. I have shut down the admin app and restarted it, still the dialog is there. Does anyone have any idea what be going on here? I can't even find anything on similar issues, let alone a solution.