Jump to content

Garage door control with KPL and Mobilinc


Recommended Posts

Posted

I have tried every suggested setup from this forum and the Mobilinc forum that I could dig up over the last few months to have accurate status and control of my garage doors using a KPL button and Mobilinc but could never get exactly what I want. I'm a little OCD, so I need it to be perfect :)

 

The main features I want

  1. [*:25t1o0yz] A Scene that accurately shows open/close status tied to a KPL button. The basics of this are easy, but it is not always accurate. The main problem is, say the garage door is open, the scene is on, and I press the KPL button. The scene is immediately turned off, and the garage door is triggered, which is correct. But, say there is something in they way of the garage door and it does not actually close. The KPL button stays off. IMO this seems like a weakness in INSTEON and/or the ISY... Meaning, if I ask a scene to turn off and the controller of that scene (the IOLinc status) never turns off, that scene should not be off.
     
    [*:25t1o0yz] One button, a scene, in Mobilinc that shows accurate door status and allows pushing the button to control the door. Essentially solving the previous one also solves the status issue, and if done correctly allows for control as well. Also, as part of this, I want the garage door sensor to be in the scene so it is easy to double check the sensor inside that scene in Mobilinc.

Each of these on there own are fairly easy to solve, but at least for me, solving the both was a challenge.

 

So I decided to write the programs in state machine style to solve this, and after a few hours of it working and testing all possible combinations, I think I finally have it. While it does exactly what I want from above, it also has some extra features:


  1. [*:25t1o0yz]When the scene is toggled with the KPL button or Mobilinc, the KPL button flashes on and off every couple of seconds until the door reaches the requested state, or it times out. Then makes sure the scene in the proper state based on the door status. This also results in the Mobilinc icon alternating between on/off. I really like having the feedback that something is happening.
    [*:25t1o0yz]If the above timeout happens and the door is not in the requested state, it sends a notification.

 

Of course, it also properly handles everything when the door is manually opened or closed...

 

If anyone is interested in seeing the programs, or if you want to critique them, I could post them, although since it's 13 little programs that is a real pain....

 

Or if you have a much simpler way to accomplish at least the 2 main features, I would be interested.

Posted

I was asked to post them from a topic in another forum, so here they are...

 

All the programs are contained inside my Garage/GDM folder to better organize them. GDM=Garage Door Middle.

 

I am not responsible for your garage door being open when you think it should be closed! I have tried every possible combination and have not seen the scene status fail to be correct. If you try these programs please make sure to check the actual status of the IOLinc sensor! For me this is easy in Mobilinc, where I make the scene a favorite, then I can check the status of the sensor when I click on that scene. Otherwise just look out your door to make sure it is closed :-)

 

Notes:

  1. [*:2e2f5bax]The scene being controlled is 'Garage / GarageDoorMiddle'
    [*:2e2f5bax]The object 'Garage / GarageDoorMiddle-Sensor' is the IOLinc sensor for that door, and is in the scene as a controller.
    [*:2e2f5bax]The object 'Garage / GarageDoorMiddle-Relay' is the IOLinc relay and is not in any scene, and it is in ‘Momentary B’ mode.
    [*:2e2f5bax]The object 'ZZ-Buttons / Front House D (GDM)' is one of my KPL buttons in the scene as a responder.
    [*:2e2f5bax]The KPL buttons must be in toggle mode, which is the default.
    [*:2e2f5bax]My setup uses the magnetic switch which is NO (Normally Open), which is NOT what the current smarthome kits come with. But, a few changes to the logic would make a NC switch work as well.
    [*:2e2f5bax]The text below each program is from the 'Comment' section... Would be nice if the UDI copy to clipboard function said that.
    [*:2e2f5bax]I have removed all the ‘Else’ sections since they are not used anywhere.
    [*:2e2f5bax]I hope I copy and pasted everything correct... Sure would be nice if the UDI admin console could spit all this out for a folder... This has been requested a couple times, but seems to have no or very low priority :-(
    [*:2e2f5bax]I guess I could attach the 'exported' xml for the folder, but I have no idea how that would work for someone else since it contains my device specific information.

 

Again, feel free to comment or critique! I want these to work the best possible way so any input is ok.

 

Program: 000 ButtonOff

If
       $i.GDM_DontWatch is 0
   And Status  'ZZ-Buttons / Front House D (GDM)' is Off

Then
       $i.GDM_RequestedStatus  = 0
       $s.GDM  = 1

Function:
When the button state is changed, remember if it was changed
to on or off and start up the state machine.

Details:
All the '000' programs monitor the status of the KPL that is tied
to the GDM Scene.  We only have to monitor one of them, since when the
scene is changed by any of KPL or Mobilinc it will affect all of them.

The main state variable for all GDM programs is s.GDM, which tells
us where in this state machine we are.  We do not monitor that 
state variable in the 000 programs because other programs within
this state machine will toggle the scene on and off, which in turn
changes the button state, so while the state machine is running we 
ignore running the 000 programs using the i.GDM_DontWatch integer variable.

The i.GDM_RequestedStatus stores if the request was to close (0) or 
open (1).

 

Program: 000 ButtonOn

If
       $i.GDM_DontWatch is 0
   And Status  'ZZ-Buttons / Front House D (GDM)' is not Off

Then
       $i.GDM_RequestedStatus  = 1
       $s.GDM  = 1

See '000 ButtonOff' for a description.

 

Program: 001 DoorStateFalse

If
       $s.GDM is 1
   And (
            (
                 $i.GDM_RequestedStatus is 0
             And Status  'Garage / GarageDoorMiddle-Sensor' is On
            )
         Or (
                 $i.GDM_RequestedStatus is 1
             And Status  'Garage / GarageDoorMiddle-Sensor' is Off
            )
       )

Then
       $s.GDM += 1

Function:
We have just entered the state machine from a KPL button changing
state.  If the requested door status does not match the door sensor
status then go to the next state.

Info:
It seems that we could tie the check of the sensor status into
the 000 Button* states, but that does not work correctly because
it would trigger the 000 state when the sensor status changes
but the button status has not changed yet.   This is because I
have the sensor as a controller for the GD scene because I want to
see the sensor as part of the scene in Mobilinc.

 

 

Program: 001 DoorStateTrue

If
       $s.GDM is 1
   And (
            (
                 $i.GDM_RequestedStatus is 0
             And Status  'Garage / GarageDoorMiddle-Sensor' is Off
            )
         Or (
                 $i.GDM_RequestedStatus is 1
             And Status  'Garage / GarageDoorMiddle-Sensor' is On
            )
       )

Then
       $s.GDM  = 10

Function:
We have just entered the state machine from a KPL button changing
state.  If the requested door status matches the door sensor status 
then we are done.

Info:
See DoorStateFalse for info.

 

 

Program: 002 Init

If
       $s.GDM is 2

Then
       $i.GDM_DontWatch  = 1
       $s.GDM_Counter  = 10
       $s.GDM += 1

Function:
The door was requested to move, so initialize variables used in 
the state machine and go to the next state.
i.GDM_DontWatch: 1=Don't watch the state changes of the KPL's
s.GDM_Counter:   Loop counter for '002 Loop' program
s.GDM:           Main state variable, go to state 2

 

 

Program: 002 Trigger

If
       $s.GDM is 2

Then
       Set 'Garage / GarageDoorMiddle-Relay' On

Function:
The door was requested to move, so trigger it.

Note:
This could have been done in the Init program, but that delays
the flashing of the scene for longer than I like...

The IOLinc relay is in Momentary B mode so it is triggered
by both on and off.  I think this is important since I don't
turn it off, although I could, but I don't care what state
the relay is in.

 

 

Program: 003 DoorStatusClosed

If
       $s.GDM is 3
   And $i.GDM_RequestedStatus is 0
   And Status  'Garage / GarageDoorMiddle-Sensor' is Off

Then
       Set Scene 'Garage / GarageDoorMiddle' Off
       $s.GDM  = 10

Function:
While in the state and the door was requested to close, when
the door is closed we are done.  Make sure the scene is
off and go to the cleanup state.

 

 

Program: 003 DoorStatusOpen

If
       $s.GDM is 3
   And $i.GDM_RequestedStatus is 1
   And Status  'Garage / GarageDoorMiddle-Sensor' is On

Then
       Set Scene 'Garage / GarageDoorMiddle' On
       $s.GDM  = 10

See DoorStatusClosed for a description.

 

 

Program: 003 Loop

If
       $s.GDM is 3
   And $s.GDM_Counter > 0

Then
       Set Scene 'Garage / GarageDoorMiddle' Off
       Wait  1 second
       Set Scene 'Garage / GarageDoorMiddle' On
       Wait  1 second
       $s.GDM_Counter -= 1

Function:
Toggle the scene on and off so the KPL buttons and Mobilinc icon change 
state.  This gives visual feedback that we are waiting for the door.

Decrement the counter s.GDM_Counter each time, which tracks our timeout
function, and causes this program to restart until the counter reaches
zero.

We could have made the counter be the s.GDM... Oh well...

(I wish the 'Wait' could use a variable!)

 

 

Program: 003 Timeout

If
       $s.GDM_Counter is 0
   And $s.GDM is 3

Then
       $s.GDM += 1

Function:
If the s.GDM_Counter has reached zero while we are in the
waiting state, then the door did not reach the state that
was requested!  So go into state 3 which handles the failures.

(I had a reason for not handling them in this state, but can't
remember why...)

 

 

Program: 004 FailedClose

If
       $s.GDM is 4
   And $i.GDM_RequestedStatus is 0

Then
       Set Scene 'Garage / GarageDoorMiddle' On
       Resource 'Pushover-GDM-Close-Error'
       $s.GDM  = 10

Function:
There was a request to close the door, but we timed out waiting.  
Make sure the scene is on since this state machine toggles the 
scene we are not sure where it ended up. Send a notification to 
tell us that there was a problem!  Go to state 10 which does 
the cleanup.

Note:
I wonder if there could be a race condition...  If the door sensor
status happens to change after TimeOut and before this is triggered?
But I really don't think that will happen...

 

 

Program: 004 FailedOpen

If
       $s.GDM is 4
   And $i.GDM_RequestedStatus is 1

Then
       Set Scene 'Garage / GarageDoorMiddle' Off
       Resource 'Pushover-GDM-Open-Error'
       $s.GDM  = 10

See FailedClose for a description.

 

 

Program: 010 Done

If
       $s.GDM is 10

Then
       $i.GDM_DontWatch  = 0
       $s.GDM  = 0

State machine is all done so start watching again.

  • 2 weeks later...
Posted

Thanks so much for posting and the great lengths of work you have gone to document everything.

 

I implemented the programs last night and ran into some trouble and have not yet had the time to troubleshoot.

 

When I press my KPL button GD opens and KPL flashes. = Good

When I press my KPL button my GD begins to close and after a second or so it opens back up. Then it cycles through opening and attempting to close. I'll have to take a look at the variables at each step to see what might be going on. If you have any ideas right off hand please let me know.

 

I did as you suggested and switched to Momentary B. I think I have a "normally open" setup but not entirely sure. I am pretty sure I did this when setting up my GD Kit: "RED and BLACK wires from the reed switch and NOT the Green wire (NC or Normally Closed reed switch operation)."

 

Thanks

Posted

I think I figured it out. I have to run a few more tests. I had 1 line wrong in the 003 loop program.

 

I corrected the last line from this:

 

Then
       Set Scene 'Garage / 1car Garage - Status' Off
       Wait  1 second
       Set Scene 'Garage / 1car Garage - Status' On
       Wait  1 second
       $s.GD1 -= 1

 

To this:

 

Then
       Set Scene 'Garage / 1car Garage - Status' Off
       Wait  1 second
       Set Scene 'Garage / 1car Garage - Status' On
       Wait  1 second
      $s.GD1_Counter -= 1

 

Quick Question for you:

 

I have a few KPL's that I would like to use to monitor status (Light On when GD is open /Off when closed) but not be able to control (trigger GD). Currently I have the 3 KPL's in the scene with the sensor. If I remove two of the KPL's from the scene what would be a good program to just monitor the status on the KPL without control?

 

Thanks!

Posted

Awesome, glad to hear that someone else likes it and is trying it!

 

Good to hear that you also figured out the problem. The only issue I have had with this since running it on one of my doors for the last couple weeks, is that originally the isy would somehow miss the Status changing from the Sensor occasionally. I changed the two wait commands in the '003 Loop' from 1 to 2 seconds and have not seen the issue since.... I'm not positive that was the issue because even if I queried the Sensor after that happened, it would not return the correct status, so may be my connections are flaky. I've not had time to play with it anymore since then...

 

Quick Question for you:

 

I have a few KPL's that I would like to use to monitor status (Light On when GD is open /Off when closed) but not be able to control (trigger GD). Currently I have the 3 KPL's in the scene with the sensor. If I remove two of the KPL's from the scene what would be a good program to just monitor the status on the KPL without control?

 

Thanks!

 

After thinking about that for a couple seconds, I think the easiest way is to create another Scene, and have these programs turn that scene on or off along with the current scene in the '003 DoorStatus*' programs, and maybe the '003 Loop' if you want them to flash as well. Then you will need another program that monitors one of the kpl's in that scene which sets the scene back to the correct state if a button is pressed.

  • 2 weeks later...
Posted

Thanks so much. I am loving the program's. They have been working great. I made the wait adjustment to the "003 Loop" as you suggested. Thanks for the tip on setting status for the other KL's.

Posted

Really glad you love them! I did discover an issue this week. We had a power outage and when everything rebooted, it decided to open the garage door while I was gone. Luckily it one of the 004 Failed programs was triggered which sent me a notification! That is on my list to debug this weekend...

 

Sent from my SAMSUNG-SGH-I337 using Tapatalk 4

Posted

Wow, that's a whole lot of programming!

 

I have several kpl's that monitor the garage door (based on the wiki setup), and unless the kids get to pushing the button over and over or in rapid succession, they are never out of sync with the actual io linc sensor. If I find them out of sync, I go look. I had to go look a lot, before I got the insteon system. Never, ever knew for sure if it was closed and had many a night when the wife would wake me up asking who was in the garage. and then you HAVE to go look of the wife is pissed and convinced the whole garage has been stolen!

 

Now in your scenario that the power going on or off or a reboot opens the garage, look at run at startup. I think all but your status checking program should be marked do not run at startup.

 

My relay status is always wrong in Mobilic, and maybe that was fixed in ISY 4.0.5 as I have not moved up yet, however, the garage door icon itself is accurate as to open or closed, and if I was unsure, a refresh has always been true.

 

I may have put a program out there that does an occasional query of the io linc's normally closed sensors, but I found THOSE to be the key to making it reliable. (the io linc normally comes with normally open sensors, which is backwards for how it sets up after a power cycle)

Posted

Yes, lots of programming.. I did use the setup from the wiki for a while and it didn't meet both 1 & 2 from my OP, but I forget exactly why now since I tried a few different methods.

 

My problem is not a run at startup issue, I don't have any of my programs run at startup. I'm pretty sure issue is that I have to use "status" instead of "control" for the KPL buttons. I know how to fix it, just need to work on it later today.

 

Yes, the relay status never matters to me, especially since it's in momentary B mode.

 

I have had a couple times where the IO Linc sensor input was not right, and still haven't figured out how that happens since it never happens when I have time to look at it. My sensors are normally closed, so that is not an issue for me.

 

Thanks,

Jim

Posted

Here's the fix for the power outage issue, read the comments for more info. Also, like I mention in the comments, I did change the '000 ButtonOn' to use '100%' instead of of 'not Off' which probably would fix it as well, but I didn't test it.

 

If
       $i.GDM_DontWatch is -1
   And (
            Status  'ZZ-Buttons / Front House D (GDM)' is Off
         Or Status  'ZZ-Buttons / Front House D (GDM)' is 100%
       )

Then
       $s.GDM  = 10

Function:
Make sure everything is correct after a reboot.

Details:
Since I have to monitor the "status" of buttons and not "control", 
both of the 000 Button On or Off programs will be triggered on boot
up of the ISY, and one of them should be true.
On a normal reboot of just the ISY it all works properly because the 
button states are correct.  But for some reason during a power outage 
the button status has not been correct.  I think this is because the 
button is neither off nor on since the KPL is also rebotting, but I 
am not sure since I don't want to really force a power outage to the 
ISY & KPL at the exact same time.  Originally the ButtonOn program used
'not Off' (because I don't like seeing 100%) so I think that was the
root cause, but either way this program makes me feel better...

So, the i.GDM_DontWatch has it's init value as -1, so when the ISY
boots up, the 000 Button Off and On will not ever be true.  This
program runs the 010 Done, which resets the state.  Hopefully the
door was not in motion during the power outage, but I don't think
I need to worry about that.

 

Also, set the 'Init To' in '010 Done':

 

If
       $s.GDM is 10

Then
       $i.GDM_DontWatch  = 0
       $s.GDM  = 0
       $i.GDM_DontWatch Init To -1


State machine is all done so start watching again.

  • 1 month later...
Posted

Thanks very much for posting your code! I've wanted to get something like this working when we got the system, but never had time to get it working correctly.

 

I have it partially working now. The button press or MobilLinc will open and close the door and the button flashes. The button on/off doesn't seem to be correct yet, but that may be how our hardware is set up.

 

I have a few questions (probably more once I resolve these and do more testing).

 

On the Failed state's you have a Resource in the code. I don't see that as an option. It's also too general a word so searching hasn't showed anything that seems to apply yet. Can you tell me what a Resource is and how I can set it up?

 

On the code you later posted to fix the power failure option, I'm a little confused--does this replace one of the existing programs or is it a new program? Do I change the variables initial value to -1 under the Variables tab as well?

 

Thanks for any help you can provide and for posting the code!

 

Tammy

Posted

Tammy,

 

That resource is using the network module to send me a notification using pushover. I you have not purchased the network module you can use email or text message, or just leave it out.

The later post was a new program. You don't have to set the init value yourself, the first time the program runs it will set it for you.

Glad you like the programs!

Jim

 

Sent from my SAMSUNG-SGH-I337 using Tapatalk 4

Posted

Hi Jim,

 

Thanks for getting back to me. I was wondering if the Resource was related to Push. Haven't set that up yet, but will if we get some things work well enough to make it worthwhile.

 

I'm having an issue. Don't know if you can help me troubleshoot it or not. My Garage Sensor doesn't seem to consistently show the proper state. Sometimes it is off when the door is closed and other times it is on when it's closed and then the same with when it's open. Any idea what might be wrong with my setup? The relay is momentary B. What else should I check?

 

Really hoping I can get this working.

 

Thanks,

Posted

Hi tcaywilson-

 

Do you know if the trigger reverse uption is selected on your IOLinc? If so, this is likely the reason you see this anomaly. Trigger reverse causes the IOLinc to send the opposite state of the sensor when the sensor state changes, however, when the IOLinc is directly queried by the ISY (3am query) the TRUE state of the sensor is returned, not the reversed state. We have seen a lot of this since Smarthome dropped the dual contact mag switch from the garage door kit in favor of a normally open mag switch. The best solution in this case is to replace the door sensor with a normally closed mag switch and turn off the trigger reverse option.

 

-Xathros

Posted

Hi Xathros,

 

Thanks for the reply. No I'm not using Trigger Reverse. I remember trying that previously when I was trying to get the garage controls to work and that it caused problems.

 

I had gotten one of the buttons on our KPL's to show when the garage door was open. That was working for awhile, but then started showing the garage open when it wasn't intermittently. It started happening enough that I wrote a little program to check the garage door and reset the light if it was actually closed. I don't think anything had changed with our system as I hadn't had time to work on it. I'm trying to find time to get back to working on getting the ISY doing something useful, but it's frustrating when it doesn't work the way it's supposed to...

 

Besides buying new hardware, any other suggestions?

 

Thanks,

Tammy

Posted

Hi Tammy-

 

I'll have to agree with Jim then and place my bet on comms error. Might be a good idea to run a level 3 event log trace and operate the door a few times. That should give us an idea of the comms reliability. Since this is a random event, it may be difficult to track down.

 

-Xathros

  • 1 month later...
Posted

setting up a KPL button for controlling the IOLINC garage door kit - the way I wanted it to function was plaguing me for a few weeks after I purchased the KPL. I wanted the KPL light to be off when the door is closed, and on when the door was opened.

 

I was on the verge of buying a new sensor for the garage door so I wouldn't have to use the dreaded "reverse trigger" option on the IOLINC, but then I came up with what I think is an creative solution. (although I'm probably not the first to think of it)

 

I created a new scene that contains only 1 device - the kpl button, set as a responder.

 

Then I wrote 2 simple programs, one turns the KPL scene 'OFF' when the iolinc sensor turns on, and then vice versa.

 

The Wiki instructs you to put the KPL button in a scene with the garage door sensor, but since my sensor shows "ON" when the door is closed, it was turning the KPL light on.

 

Seems to work really well so far!

Posted

Thanks! I've been trying to get time to work on this again, but haven't had the chance. I'll try your solution to see if that works for me as well as doing some debugging as previously recommended to see if I have any communication issues.

Posted
Seems to work really well so far!

 

That does seem like a good solution. The complaint I expect to hear is about the delays associated with a program compared to scenes, but this surely sounds preferable to having to reprogram IOLincs every time there is a power outage.

Posted

OK.. New guy here...

 

After entering the program... it didn't work. Then, I realized why... I was using "normal" variables.

 

Should these ALL be "state" variables? or just some of them?

 

Tkx.

 

Update: forget that. I just realized that you use i. and s. to show the difference... I missed that the first time.

  • 4 weeks later...
Posted

I have implemented this program and it works pretty good except I had to disable the Program 003 loop section. When this is active, the garage door will start to go down from the raised position and then in about 1 second of movement (about 1/3 of the way down) it reverses and opens back up.

 

I think this may be due to how I have my sensor system. I am not using the magnetic sensors at the door, but instead have an industrial style limit switch with a roller arm that is actuated by a block that is attached to the drive chain. The sensor is on (active) in the door up position and then goes off when the door closes.

 

I have played around to no success with Momentary A, Momentary B, and Momentary C settings on the 2450 iolinc (v.41 BTW).

post-5855-140474162704_thumb.jpg

  • 4 weeks later...
Posted

Got it working. I discovered that I had the i.gdm_dontwatch and the i.gdm_requested status as state variables instead of integer variables (facepalm). I also for some reason had to extend the pulse duration on the iolinc from 0.2 to 0.3 seconds for consistent opening for the opener.

  • 3 months later...
Posted

Reviving this thread - I successfully implemented this set of programs and it's working great.

 

I'd like to add a couple more Keypadlincs to the mix - so I can see the status of and control my garage doors from my basement and bedroom.

 

Any thoughts on how to do that? I thought I could add the additional KPL buttons to the scene, and modify the first two programs to include those buttons (AND'ing the logic of the KPL button status) - but I couldn't get it working.

 

Can anyone suggest an approach?

 

Thanks!

Guest
This topic is now closed to further replies.

  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

    • There are no registered users currently online
  • Forum Statistics

    • Total Topics
      37k
    • Total Posts
      371.3k
×
×
  • Create New...