Insteon 2450 doesn't work like garage door kit instructions

[satwar]

My garage door status light works correctly (On=Open)

 

Pressing the Set button on 2450 sequentially open/closes door

 

But the garage door sequentially open/closes with every press of the "On" button on ISY controller and the "Off" button on ISY controller does nothing, unlike what the instructions say:

 

Sending On command: If garage door is Open, it remains Open

If garage door is Closed, it should Open

 

Sending Off command: If garage door is Closed, it remains Closed

If garage door is Open, it should Close

 

I'm using Momentary C, but it doesn't seem to react to Status condition.

[andyf0]

Having just gone through this a couple of weeks ago ...

 

Wire the sensor to black/green. The LED will be on when closed.

Wire the opener contacts to Common and NO.

 

When you set Momentary 'C' make sure the door is open (sensor OFF). This is very important.

 

I suggest you start this again after doing a Factory Reset. The instructions that come with the kit assume the IOLinc is in it's factory default state.

 

Pressing OFF will activate the opener only if the door is open.

Pressing ON will activate the opener only if the door is closed.

 

On the ISY99 the Relay device will show the last ON or OFF it was sent and the Sensor device will show OFF for open and ON for closed.

 

I'm sure there are other permutations .. I tried wiring Red/Black on the sensor and setting Momentary 'C' with the door closed but I couldn't get it to work that way.

 

The instructions are confusing .. the text says to wire the sensor to black and green but the diagram shows black and red.

[LeeG]

satwar

 

The IO Linc relay reacts differently when commanded with Insteon Direct commands from the ISY Admin Console or Program versus issuing Insteon Group (Scene) commands to the IO Linc Relay.

 

Define a Scene with the IO Linc Relay as a Responder. Send On/Off commands using the Scene rather than the relay node directly. It will then respond as the SmartLinc instructions indicate. Outside the world of Home Automation, all Insteon device to device activity results in Group (Scene) commands so the Smarthome reference information is written in that context. Smarthome does not document how the relay reacts when receiving Insteon Direct commands.

 

Lee

[andyf0]

Doh! Thanks Lee, forgot that part.

[satwar]

satwar

 

The IO Linc relay reacts differently when commanded with Insteon Direct commands from the ISY Admin Console or Program versus issuing Insteon Group (Scene) commands to the IO Linc Relay.

 

Define a Scene with the IO Linc Relay as a Responder. Send On/Off commands using the Scene rather than the relay node directly. It will then respond as the SmartLinc instructions indicate. Outside the world of Home Automation, all Insteon device to device activity results in Group (Scene) commands so the Smarthome reference information is written in that context. Smarthome does not document how the relay reacts when receiving Insteon Direct commands.

 

Lee

 

That's what I was hoping for, thank you. I dragged the IOLinc Relay into a new scene I named Door Control. Unfortunately the On & Off buttons do the opposite of what I want. On closes and Off opens. I guess this is where green wire comes in ?

[andyf0]

It maybe the state the sensor was in when you programmed Momentary 'C'.

 

From the IOLinc Manual:

 

Momentary C

1) Set the sensor to the desired on state (meaning an ON command will not trigger the I/O Linc relay when the sensor is in this state). For example, if you want an ON command to open the garage door and an OFF command to close it, open the garage door in this step.

 

Edit: However, I think these instructions assume you used the green wire. If you used the red wire then maybe try close the door when programming momentary C.

[satwar]

It maybe the state the sensor was in when you programmed Momentary 'C'.

 

From the IOLinc Manual:

 

Momentary C

1) Set the sensor to the desired on state (meaning an ON command will not trigger the I/O Linc relay when the sensor is in this state). For example, if you want an ON command to open the garage door and an OFF command to close it, open the garage door in this step.

 

My god, I think I got it. You were right, I hadn't read that part of the instruction manual. So I have Status LED On=Open Door(red black wires) and an Insteon Scene that with the ON command: opens the door, if closed; remains open, if open

and with the OFF command: closes the door, if open; remains closed, if closed

 

What a nightmare, and I thought this would be fun. God knows what's going to happen after a power bump.

[LeeG]

Glad you got it working. The IO Linc can be complex to set up. It is relatively simple when each function is looked at individually but gets complex because the Sensor and Relay can be tied together as you have done with Momentary C. Depends on whether using a NO or NC magnetic sensor and there is a dependency on door Open/Close when using the Set button for configuration with Momentary C. Note the ISY provides configuration support through the Admin Console that allows setting the Trigger Reverse option that affects the door open close versus ON/OFF command response without having to use the Set button on the IO Linc.

 

There can be an out of sync situation after a power cycle. Should just be a matter of cycling the On/Off buttons to get it back in sync. Door may move during the process.

[satwar]

Sorry I did not respond sooner. NC has had many severe storms and tornados today (I'll clean this part up later).

 

Glad you got it working. The IO Linc can be complex to set up. It is relatively simple when each function is looked at individually but gets complex because the Sensor and Relay can be tied together as you have done with Momentary C. Depends on whether using a NO or NC magnetic sensor and there is a dependency on door Open/Close when using the Set button for configuration with Momentary C. Note the ISY provides configuration support through the Admin Console that allows setting the Trigger Reverse option that affects the door open close versus ON/OFF command response without having to use the Set button on the IO Linc.

 

There can be an out of sync situation after a power cycle. Should just be a matter of cycling the On/Off buttons to get it back in sync. Door may move during the process.

 

Yes the ISY was very helpful. I wouldn't have made it without the ISY. The trigger reverse function was illusive for me. The instructions that come with the garage kit were not all that helpful. Thank goodness for discussion forums like this.

 

Hopefully my second door goes smoother.

[SKE]

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.

[SKE]

In the end, no matter how many variations of the configuration that I try, "Momentary C" does not tie to the sensor input as the description implies. Pressing [Off] in the ISY never seems to do anything with the relay when in "Momentary" mode (which one could argue, it should never do anything, as the momentary action was "momentary"), other than change the "Current State" to Off (this is an ISY state, and has nothing to do with the Insteon device). There is no Stateful mode of operation as I thought I read in other postings.

 

The confusing aspect of all this is that when in any Momentary-C mode, you press [ON], the relay closes for 20ms, then the "Current State" shows as "On"". The state of the sensor plays NO role - I would love to see the sensor play a role here. A, B and C, behave the same as I see it so far, and simply are a non-latching (momentary) mode of operation - pick either of the 3 and you get non-latching and after the momentary relay close action - the Current State stays as ON. I think this is a bug (not sure at what level). I have a v1.8 I/O Linc device (the # 1122 is also listed). A solution with the sensor factored in seems trivial, maybe I am wrong, and I will learn this the hard way.

 

I will use this A-B-C mode and code my own logic in my controller which attempt to get the door in the state as desired, setting the relay several times if needed, to handle the state where the door was stopped in a non-parked/intermediate position (or out of sync from a power outage). I will communicate as though the input and output were raw simple devices, leaving all of the other settings off (I'll handle momentary myself, in latching mode, if I have to, this does leave the Current State set correctly).

 

I have read that placing the relay into a an ISY/Insteon Scene yields different behavior. I don't do ISY/Insteon scenes with my own controller, I talk to the discreet devices, and do my own scenes/groups, so using an ISY/Insteon scene is not an option for me (too much work for my use here). If a scene made a difference here, this still indicates a bug to be resolved.

 

Also, the internal behavior of the relay is not adequately defined (as I have seen so far, so I could be wrong) so I am assuming I will get this to work using just the raw device input and output logic. If I have issues, and ISY/Insteon becomes Rocket Science here, with my garage door working in a sane and logical manner, I will just use a more well-documented IP-based I/O device for my garage door. I never would have thought that this would be so complex with the ISY/Insteon solution. I am thinking that the reviewers at SmartHome are just not expecting a more-complete solution - they press their button and wait and see what happens (do they get a correct sensor or monitor alert after 10 seconds). I will not do that. That is counter-intuitive to the concept of "automation".

 

Overall, this seemingly-simple topic gets confusing with the different concepts and ambiguous terms used in the discussions. Even my term of stateful here is confusing; does it mean stateful with respect to the relay or stateful with respect to the garage door? This is a deceptively deep topic when you start digging into it all. Seems simple, not so.

 

All of the ambiguity and confusion comes into play because of the use of a the basic I/O device in many different, and sometimes complex scenarios (and the setting descriptions being too abbreviated). For use in a garage door setup, this must be a support nightmare for Universal and SmartHome - I bet they have very different docs used by their support teams. A case where a seemingly simple use-case sprawls into a nightmare.

 

I'll continue to learn more about these devices and what is happening at what layer (documented I hope). Lots to learn.

[LeeG]

Use Red/Black to produce I/O Linc Sensor On when door is Open (magnet away from reed switch).

 

Just to make things more complex you need to be on 3.3.4 as 3.2.6 has a bug associated with setting the new I2CS I/O Linc options.

 

The confusion about Relay On/Off versus door opener movement is due to the fact that the Smarthome documentation assumes a Scene is used to control the I/O Linc Relay. Since Smarthome devices cannot send Direct On/Off commands (except PLM with HA), only Scene On/Off commands, all the Smarthome doc describes device operation relative to Scene usage.

 

Sending a Direct On command to the Relay ALWAYS turns the Relay On. Being a garage door implementation Momentary mode (any of the three) automatically turns the Relay Off to simulate manual button operation. The Direct Off command serves no functional purpose as the Relay is always automatically turned Off with Momentary mode.

 

When Scene On/Off commands are used to control the I/O Linc Relay it will operate according to the Smarthome documentation for the various Momentary modes. Again, need to be on 3.3.4 for the Set Options to work with the new I2CS I/O Linc.

[oberkc]

I agree that the included instructions don't apply when using an ISY-99. I also found the instructions regarding the colored wires to be confusing, at best.

 

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)

 

I am not sure that i agree that these terms don't apply. NO would apply your second example, in my mind (close when magnet is near). NC would refer to your first example (closed when magnet is away).

 

I suspect, too, that much of your issues are related to the way the IOlinc operates outside the control of universal devices. The relay, for example, does not report status.

[SKE]

I am just saying that until a meter is put up to any magnetic sensor, or docs state the bahavior, one can't guess the behavior is - i.e. does the magnetic force cause a close cicuit or open circuit? As far as I know, there are no real industry rules and assumptions aren't always true.

 

Yeah the I/O Linc limitations are really not an ISY issue.

 

I gave up on the I/O Linc deivce settings being of any real use and I just use the latched mode and handle the momentary behavior myself. In ISY, one can setup a program/script to to look for the relay going on and turn it off 1s later. At that point all works fine as long as you accept that you have no door mode of behavior -you have to look at the sensor reading and then press Relay ON to toggle the door position as needed. In my app, I'll expand my C# object to handle a full garage door beavhior once I see the ISY working well with it for a while.

[LeeG]

It is best to move to 3.3.4 and use one of the Momentary modes. Or use the I/O Linc User Guide and set one of the Momentary modes with the I/O Linc Set button. If there is any comm problem that prevents awareness of the need to send an Off or the I/O Linc from receiving the Off it will leave the Relay On. This will prevent the normal manual garage door button from working.

 

Once the I/O Linc function is understood it is a nice device. Smarthome sells the I/O Linc with some dozen different kits for different applications. Makes the defaults difficult to tailor for so many different uses.

 

Actually there is an industry standard but it is different by industry. Devices sold for Security usage describe NO and NC in the context of switch state when the magnet is next to the reed switch. When used outside the Security environment the switches carry the opposite nomenclature. How much you want to bet both industries consider themselves right.

[oberkc]

gave up on the I/O Linc deivce settings being of any real use and I just use the latched mode and handle the momentary behavior myself. In ISY, one can setup a program/script to to look for the relay going on and turn it off 1s later. At that point all works fine as long as you accept that you have no door mode of behavior -you have to look at the sensor reading and then press Relay ON to toggle the door position as needed. In my app, I'll expand my C# object to handle a full garage door beavhior once I see the ISY working well with it for a while.

 

I use the garage door kit and ISY based upon the excellent example in the UD wiki. It takes advantage of latching mode and works beautifully (at least for me it does). The example, however, is based on a scene relationship between controller (keypad) and responder (relay). There is no ISY program controlling the garage door.

 

I remain a little unclear about your goals with your garage door kit, but I think it premature to globally accept a lack of door mode behavior. The door mode behavior does work in certain conditions. If, however, your C# program can handle only direct commands, then perhaps that is a limitation you will have to live with.

[MrTinker]

I've had a number of IO Lincs and a Seco-Larm garage door sensor (SM 226L, NO sensor with green and black wires only) sitting that I ordered awhile ago and am finally getting ready to install. Three of the IO Lincs are v1.4 and the remaining one is v2.2.

 

Reading this thread as well as others, I'm confused as to how I should connect everything. It sounds like the best configuration is to have a NC sensor such that when the door is opened the sensor on the IO Linc turns on (and no Reverse Trigger setting needs to be made in the ISY which would be lost if the IO Linc loses power). Is this a correct understanding?

 

Assuming my understanding above is correct, could I install the NO sensor so it's aligned when the door is open to solve this problem (of needing to set the Trigger Reverse and this being lost if the power is lost on the IO Linc)?

 

Thanks in advance for any help. I'd like to install this once and it be correct.

[oberkc]

Reading this thread as well as others, I'm confused as to how I should connect everything. It sounds like the best configuration is to have a NC sensor such that when the door is opened the sensor on the IO Linc turns on (and no Reverse Trigger setting needs to be made in the ISY which would be lost if the IO Linc loses power). Is this a correct understanding?

 

This depends on where you mount your sensor. I like the sensor to be in contact when the door is FULLY closed, and open on anything other than fully closed. Some have mounted the sensor where the sensor is in contact only when the door is FULLY opened. Yes, I agree that it is best that the sensor is "on" when the door is opened.

 

Assuming my understanding above is correct, could I install the NO sensor so it's aligned when the door is open to solve this problem (of needing to set the Trigger Reverse and this being lost if the power is lost on the IO Linc)?

This is a personal preference, but I prefer the opposite. It is more important for me to be confident that the door is FULL closed, rather than FULL opened. Given this, I would rather have the sensor aligned with the door is closed.

[MrTinker]

Reading this thread as well as others, I'm confused as to how I should connect everything. It sounds like the best configuration is to have a NC sensor such that when the door is opened the sensor on the IO Linc turns on (and no Reverse Trigger setting needs to be made in the ISY which would be lost if the IO Linc loses power). Is this a correct understanding?

 

This depends on where you mount your sensor. I like the sensor to be in contact when the door is FULLY closed, and open on anything other than fully closed. Some have mounted the sensor where the sensor is in contact only when the door is FULLY opened. Yes, I agree that it is best that the sensor is "on" when the door is opened.

 

Assuming my understanding above is correct, could I install the NO sensor so it's aligned when the door is open to solve this problem (of needing to set the Trigger Reverse and this being lost if the power is lost on the IO Linc)?

This is a personal preference, but I prefer the opposite. It is more important for me to be confident that the door is FULL closed, rather than FULL opened. Given this, I would rather have the sensor aligned with the door is closed.

 

Understood. I was actually working my way logically through the states the sensor would be in with each type of sensor installed in either the fully closed or fully open positions. I would say I fall into the same category as you, wanting to know that it's fully closed. I will thus plan to wire the NO sensor so it is aligned when the door is closed and set the Reverse Trigger. I'll see how it goes set that way and, if it annoys me having to reset it when the IO Linc loses power, I'll replace the NO sensor with a NC one.

 

Now that I think about it, I have a second garage door that I need to order a sensor for so maybe I'll get just two NC sensors when I order.

 

Thanks for the clarification!

[ejh3]

Mr. Tinker,

 

I am running into the same issues, I spent hours yesterday trying to get this I/O linc to work. When I get home from work today I plan to "monitor" the garage door

status from a different module (EZIO2X4) and see what I can come up with. This seems like Smarthome makes it much more complicated that it needs to be.

 

I will let you know how I make out.

 

Ed

[geogecko]

I've also just received this I/O Linc, and bought the NO/NC sensor, and am just as puzzled. It seems like the scene setup works, but I like using MobiLinc to control my stuff, and going to the My Devices page is usually what I do to control devices. I guess if there is no other way, I'll use the scene...

[MrTinker]

I've also just received this I/O Linc, and bought the NO/NC sensor, and am just as puzzled. It seems like the scene setup works, but I like using MobiLinc to control my stuff, and going to the My Devices page is usually what I do to control devices. I guess if there is no other way, I'll use the scene...

 

I use MobiLinc as well. If you have and use any KeypadLincs to display the status of the I/O Lincs you're using for the garage door (or any other devices for that matter), you would want to use the Scene you setup so the KeypadLinc will properly reflect the status. Save the scene to your favorites and you'll have quick access to it.

 

I ordered two of the garage sensors with both NO/NC and will hopefully receive those this week and can then try this out.

[oberkc]

you would want to use the Scene you setup so the KeypadLinc will properly reflect the status.

 

I did not believe that scenes had "status". In mobilinc, I rely on the sensor to determine door status. I use the relay to control the door. Alternatively, you could use the scene (with relay as responder) to control the door. I also have a webcam to verify, if I am concerned. Unfortunately, I don't believe there a single device that one can use with moblinc, or as a moblinc widget, to display status AND control the door. If you find something different, I would love to hear about it.

[MrTinker]

you would want to use the Scene you setup so the KeypadLinc will properly reflect the status.

 

I did not believe that scenes had "status". In mobilinc, I rely on the sensor to determine door status. I use the relay to control the door. Alternatively, you could use the scene (with relay as responder) to control the door. I also have a webcam to verify, if I am concerned. Unfortunately, I don't believe there a single device that one can use with moblinc, or as a moblinc widget, to display status AND control the door. If you find something different, I would love to hear about it.

 

From an earlier post by Lee

The IO Linc relay reacts differently when commanded with Insteon Direct commands from the ISY Admin Console or Program versus issuing Insteon Group (Scene) commands to the IO Linc Relay.

 

Define a Scene with the IO Linc Relay as a Responder. Send On/Off commands using the Scene rather than the relay node directly. It will then respond as the SmartLinc instructions indicate. Outside the world of Home Automation, all Insteon device to device activity results in Group (Scene) commands so the Smarthome reference information is written in that context. Smarthome does not document how the relay reacts when receiving Insteon Direct commands.

 

I'm not sure on the status of the relay scene as you open/close the door. The sensor (both device and scene) should reflect the status of the sensor (as you stated). So I definitely see what you're saying about a single device not controlling and reflecting status. I'm not sure about a single scene, I guess I'll find out after I get these setup I would also like to setup an IP camera in the garage to be able to monitor the door. Seems like a good thing to have for multiple reasons.

[geogecko]

Yes, that is also what I didn't like, that the scene itself wouldn't contain the status of the door, so I'd have to go somewhere else to verify that.

 

I kinda like the icons mobilinc uses too. I don't plan on using a KPL to show status, so that didn't bother me. I was going to see about writing a program that would either flash a light after a given amount of time, or something like that. Also send email, in case I was away.

 

At this time, I haven't installed mine until I figure this out, because it's a lot easier to troubleshoot with it in the same room as my computer.

 

I'm interested in how you guys set it up. I notice the setting options keep changing in the last couple RC firmwares...