This is an amazingly complicated setup for something that should be quite simple, a garage door use-case. Sorry my comments are long here but I wanted to point out some ambiguity/confusion in the the configuration, found in the docs and/or maybe earlier in this thread. Please note when reading this that there are several version of this kit - so please don't assume that your experience is the same as others (a few of the comments at SmartHome note what I am about to mention here).
I have an ISY (that I love), and I purchased the garage door kit (#74551) which included a 3-wire SECO-LARM (garage door) sensor and I/O Linc (#2450) from SmartLabs/Smarthome/Insteon.
It appears that my I/O Linc device is working correctly. This is verified by the operation of the LEDs on the device. Insteon devices and the ISY usually work quite well on the first configuration attempt, but I am stuck here.
I have added the #2450 Insteon device to my ISY (with _DEFAULT_ settings). The basic I/O device logic appears to work fine via the ISY UI. When the input wires are touched, the green input LED lights up (ISY indicates this). When I tell the ISY to set the relay (output) to ON, the bright white LED lights up (ISY indicates this). I think this demonstrates that the I/O Linc device is working fine with the ISY default settings.
It is the higher-level ISY device logic (the settings dialog), when configured according to the comments earlier in this thread that seems to not be working correctly. But this just can't be and _I_ must be doing something wrong on my end. While it is obvious that the included garage door wiring instructions (Rev 01-17-2011) are clearly wrong (and this should be corrected in future shipments) the instructions earlier in this thread should be correct, right? I must be missing something after spending hours on this.
One of the problems is that the garage door kits come with 2 different sensors, some with 3 wires and some with 2. Mine came with 3 wires (black, red AND green). The 2 wire sensor (that some have in their kit) have only black and red wires.
The latest PDF for the #74551 kit shows that the kit now comes with a 2-wire sensor and the PDF doc shows a revision of "08-01-2012". It also references a diagram that is missing. A QA process on documents can save so much time. An hour saved by a vendor can cost the world many 1000's of hours of research and requested support.
I guess the kit changes at times. It now comes with the cheaper sensor setup. I personally would just by the I/O Linc and the nicer SECO-LARM sensor - but either will do the job.
Going with my older 3-wire version of the kit, and included printed docs...
A nice chart in the docs for the 3-wire sensor would be helpful - here my take on it. Using terms like NO (normally open) and NC (normally closed) do not apply here - there is no "normal" in the many use cases (the user would have to know the implementation internals of the sensor to understand NO and NC, and this should not be required - basic design practice).
The Black and Red wires are used to to make contact (close) when the magnet is AWAY from the base of the sensor (when a garage door would be typically be open).
The Black and Green wires are used to make contact (close) when the magnet is NEAR the base of the sensor (when a garage door would typically be closed)
As an end-user, I can only assume that the color coding of these wires are industry common, but I of course can only guess.
The docs for my garage door kit shows a pic of the 3 wire sensor at the top. The instructions just below mention wiring up the black and red wires to the Input of the I/O Linc. A picture at the bottom shows two wires, but the doc is printed in black and white and the original PDF (which may be in color) is no longer found online. In contrast, the comments earlier in this thread mention using the black and green wires. Hmmm, so, there is a lot of ambiguity and opportunity for confusion, in the best case with an end-user.
The issue I have is that, when following the directions, or not, I do not get the implied Stateful operation. Meaning, when I press the ON button in the ISY (or via API call), the momentary relay is ALWAYS fired. I am sure some users do not care about this, and live with it, and always have to go back 10 seconds later and look at the sensor status (the sensor works fine), but this is dangerous as the operation is not stateful. The logic that I seen mentioned, using the "Momentary C" setting, is that I can press the ISY UI ON botton, and the door will open, (never illogically close). And the OFF button, will always close (not illogically open).
I have been through the configuration steps several times and followed the detailed gotcha configuration points and still do not get the desired results. I am going to have to try more permutations of the configuration.
In Short: Comments seem to imply that from a Factory Reset state, I can wire using the black and green, and with the door open (sensor open), set "Momentary C" behavior in the ISY. Then in ISY clicking ON opens the door, and OFF closes the door - no other illogical behavior.
The device in the ISY is obviously a virtual device intended to assist people with various common configurations, but the setting descriptions are very vague and only have initial first-glance meaning to the author, or after much digging to decipher the author's intent (I could explain but I won't as these should be easily seen).
A garage door would be a simple use-case for this the I/O Linc device. My questions (and suggestions for future PDF and printed documents) are:
[1] Which sensor wiring should be used for a garage typical garage door scenario door (sensor base and magnet NEAR each other when the door is closed, and is that OPEN or CLOSED contacts)? An extra sentence of clarity in the doc could help many users.
[2] Is this black and red as the docs state, or black and green as this thread states?
[3] Is it required that the sensor be open or closed (this depends on the previous answers) exactly at the moment when the "Momentary C" setting is configured? This is perhaps the biggest gotcha point in the docs based online postings. The ISY setting dialog should mention this is a given state is required at the time of setting. Some comments suggest this.
[4] Based on what I read earlier in this thread.....Can the "Momentary C" setting be set with the ISY HTTP interface or only via the physical button presses on the device? I used the term "physical" here, because button press can have many meaning now in 2012 (the earlier comments in the thread show this ambiguity between UI button and Physical button). Most readers won't catch this when reading it here online. The reason I am being very specific here is that I have been writing software for 25 years and I spot ambiguity like this instantly. "Button" - well, what button? Context can sometimes clear it up.
I am trying to get all of this working based on typical use of this device. In the end, it may not matter to me (I will explain below), but while I am here I am trying to clear it up for others that will stumble on this issue.
==== Other comments on my usage of the ISY
Because I like a nice clean (big red/green button) dashboard for my devices (IMO, the ISY Standard and Admin UI is rather visually awkward for getting a quick status), I have written my own native (not web) Windows controller wrapper app in C# that simply uses the ISY for the Restful HTTP calls - I was up and running with my app in about an hour as the Restful API is easy to work with (kudos to Universal Devices on this). I used http, because I am new to Insteon so I do not yet know how to talk at the lower command level (I will learn that soon). So, with my app, I can implement a fail-safe garage door opener logic in my own code layer in under an hour. I may just do this rather than spend many more hours figuring out the configuration. But even so, the configuring of the garage door opener, for me and others, should not be so difficult.
All of this leads me to comment on the ISY virtual devices (like the extra logic you see in the ISY device, above and beyond the simple I/O Linc logic). While the ISY virtual devices are intended to be helpful (and needed if you use the standard means for controlling your home), without very clear and precise (unambiguous) documents, these virtual devices sometimes cause quite a bit of headache. In this case, I am using a simple input (sensor) and output (relay) device. As I mentioned, I can build that stateful garage door logic within an hour, in my controller, assuming that I am talking to 1 input device and 1 output device.
So.....I would LOVE to see the ISY controller provide some bare devices for things like this I/O Linc device - that is, the simple reading of the input and setting of the output without all of the other logic wrapped over it. Then I could call the Restful http API service and do what I want without and other "helpful" layer, "helping" me (if non-default settings are activated). Now I realize that 99% of users do not use Insteon devices in this raw manner and I should probably learn the lower level command against the power line modem for my goals here, but I jumped into using the Restful interface within 1 hour of opening the box of the ISY - the Restful interface is very nice and works 99.9% of the time (some XML data return truncation errors at times - which my controller catches). It would be nice to have the option of talking to a lighter bare device in ISY, in the UI or Restful API. I guess might defeat the purpose of the ISY intended use, and my path here will be to use the lower level Insteon commands, which I was hoping to avoid in my early stages here (using the ISY via Restful http as a decoupled layer).
Thanks to all fo you that help in these forums. I usually have my Insteon problems solved quickly with the info here, but this time I am confused with some of the documentation, or I am goofing up on my end. I have not (yet) read every posting on this topic, so maybe this is cleared up elsewhere.
Thanks in advance for your help.
