Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Brandt]

Ok so I searched the forum and there are like 14 pages of results for garage door, you better believe I'm not searching through all of that...

I have read that article in hometoys: http://www.hometoys.com/tips/tips04.htm but i'm not quite going with that intricate setup, I only have a Uni Mod connected to the same terminals as the button on the wall, and a Powerflash connected to Seco-larm n/o garage door contacts from smarthome.

with my HA monitoring software:

lets say "garage_door" is the universal mod, and "garage_door_status" is the powerflash

when I send a "garage_door on" the garage door opens and and the signal is recorded in my HA software as that uni module being in the ON state. The garage_door_status also updates and shows as being in the on/open state in the software, which is all correct.

Problem number 1 arises when the garage door is then closed with the wall button or the remote. The state of the garage_door uni mod in the software still shows as being on. (Also, do the Uni mod contacts; when set to momentary only require an on command to operate and have no need for an off command?)

Problem number 2 arises when the garage door is operated from a remote when a car is coming home. It seems as though the series of x10 events that occur when a person is coming home blocks the powerflash signal from being seen by the HA software, as the garage_door_status never seems to be correct.

[dave w]

1. Yup, in the Momentary mode the Universal Module does not need an OFF signal. Maybe as last step in the macro send it an OFF so the status will be correct.

2. So when activated by a car remote there is too much X10 activity and since the PowerFlash is impolite it transmits blindly and its signal is lost because other X10 transmissions are taking place at same time (probably also corrupting the in process transmissions also) is this correct? 

If this is correct, could you relocate the garage door switch to the back of the garage door rails? That would create a time delay equal to the period it takes to get the door to the full open position. Might be enough delay for all the X10 traffic to clear before the PowerFlash transmits. However this would now trigger the PowerFlash almost immediately after you start the door to lower, so do you have as much X10 traffic then?

[Brandt]

Ok, so #1 is an easy fix then.

#2 not so much. I have found a hack of a solution here:
http://brohogan.blogspot.com/2009/09/is-garage-closed.html
And I do have extra ATmega168's lying around and know how to program them...so I would be able to do this, however I'd rather not because of time and so forth...

too bad you can't poll the powerflash...hmmm 

[dave w]

#2 not so much. I have found a hack of a solution here:
http://brohogan.blogspot.com/2009/09/is-garage-closed.html
And I do have extra ATmega168's lying around and know how to program them...so I would be able to do this, however I'd rather not because of time and so forth...

I agree, playing with ASPIC's can be great fun, but in this case it's like shooting flies with a shotgun.
If you are fighting PLC bus contention/corruption caused by timing, I would be interested in hearing when you find a solution. Its too bad X10 did not make all their transmitters polite. I think the Smarthome equivalent to the PowerFlash (Smarthome Insteon I/O Linc) might be polite(?) and it could take the place of both the Universal Module and the PowerFlash.

Also if you really want to poll a PowerFlash you may be able to do it in a psuedo way. Plug the PowerFlash into an Appliance Module which is left ON except when you want to find status of the PowerFlash. To "poll" the PowerFlash, turn the Appliance Module off and then back on. If the garage door switch is closed the PowerFlash will return a HCUC "ON". If the garage door switch is open, the PowerFlash will not transmit. This is the way my PowerFlashes initialize. Who knows if the latest X10 build still works the same way, but would be easy to test.

[dbemowsk]

In my setup, I have a uni mod (G2) set to momentary for activation of the door.  In my module/macro setup I have a macro that is triggered by the same H/U code (G2) that pauses for 3 seconds and then issues a G2 off command which the uni mod ignores because it is already in the off state.  For status, I have 2 PF mods.  One to show up status, and another for down status.  For the sake of good status, I have macros set so that when one or the other PF mods issues an on status signal, it issues an off command for the other module.  I do this as sort of an error correction control. 

For example, if the garage door is open, the door open status PF mod should show on.  If I close the garage door, the sensor for the door open status should break contact and issue an off command.  When the door reaches the bottom, the door closed status PF mod should issue an on command.  The door closed status on command would then issue an off command to the door open status module in the software to correct the status of that module in the event that it didn't change.

My garage door can also be stopped in mid flight.  Having the upper and lower PF mods for status then lets me check to see if the door is stuck in mid travel.  It can then issue another activation code to G2 to attempt to unstick the door.

[pconroy]

too bad you can't poll the powerflash...hmmm 

http://davehouston.net/chamberlain.htm

I don't know if this helps in this situation or not.
I have one of these.
Home Depot was carrying them - and they had them on clearance.

[Brandt]

I think something is up with the way I wired up the uni mod....

I can never tell which one is going to open or close the garage door, either a couple of on's or a couple of off's

also when the uni mod is sometimes engaged (or disengaged?) the wall button seems to become disabled.

The uni mod is set to momentary

[dbemowsk]

I think something is up with the way I wired up the uni mod....

I can never tell which one is going to open or close the garage door, either a couple of on's or a couple of off's

also when the uni mod is sometimes engaged (or disengaged?) the wall button seems to become disabled.

The uni mod is set to momentary

The way it should be wired is the contacts of the uni mod should be wired parallel to the garage door wall switch wires.  When the uni mod is sent an on command it closes the two contacts just as if you had pushed the wall switch.  With the uni mod set to momentary, it should release control and allow the wall switch to work again as it should.

As for which one should open the door, you should just have to send a single on command to the H/U code of your uni mod.  With the uni mod set to momentary, you should never need to send an off to the module, unless it gets stuck which shouldn't happen normally.

If the uni mod is engaged, the wall switch will not work.  The reason for this is that the uni mod is closing the circuit for activating the garage door.  I had this happen once when I lost power in the garage.  My uni mod, even though set to momentary, for whatever reason stuck on.  I had to cycle it once off then on again before it went back to momentary.  With the uni mod stuck in the on position, the door opener thought that the wall switch was being held down which is why the wall switch didn't work.

My door opener setup has worked reliably for some time now.  I have a number of fail safes in place even for things that would rarely happen such as the door getting stuck in mid cycle.  My status indicator setup using the two PF mods works flawlessly and basically has error correction control built in.

[Deemar]

So are you saying the wall switch will no longer work with this setup? And why would you need to use the OFF command? You should just be using repeated ON commands for open/close.

[dave w]

So are you saying the wall switch will no longer work with this setup? And why would you need to use the OFF command? You should just be using repeated ON commands for open/close.

Check the original post, "problem #1". Not sure, but I believe Pomprocker is sending the OFF only as a status update for the screen and Activity Monitor. Otherwise the status of the Universal Module is always shown incorrectly.

[Brandt]

Not sure, last night I had to press off to get it to open, and then off again to get it to close....something backwards or not wired correctly...I'll have to investigate this weekend.

[Deemar]

Not sure, last night I had to press off to get it to open, and then off again to get it to close....something backwards or not wired correctly...I'll have to investigate this weekend.

Isn't that the way it's supposed to work though? If it simply closes the connection for the door, you're assigning it to a command which activates it. So there's no difference to the unit for up and down, it simply closes it and the brains figure out if it's supposed to go up or down. So sending OFF should work for both open and close. Is that right?

[dave w]

Not sure, last night I had to press off to get it to open, and then off again to get it to close....something backwards or not wired correctly...I'll have to investigate this weekend.

Sending an OFF to a Universal Module set to the Momentary Mode should not do anything at the module since it will be off anyway. It does not sound like the Universal Module is operating in the Momentary Mode. If it is operating in momentary mode you will hear it click twice with a single ON command.

Addendum: I just saw something in the UM 506 instructions that might explain your problem.
Try this: Put the module in Continuous Mode and send it an OFF command,  then put back in Momentary Mode and see if it works correctly.

To Brian H, do you know if the UM uses the solenoid/cam style relay?

[dbemowsk]

I agree with dave w.  I do not think that the uni mod is functioning correctly.  If you set it to momentary with nothing connected to the terminals, you should send an ON command, hear a click, and then 1.5 to 2.5 seconds later you should hear it click off.  You can check if it is working by putting a continuity tester across the terminals and then send the ON command.  You should get continuity for that couple seconds.  If this doesn't work, try dave w's suggestion of putting it in continuous mode, send an OFF command, and put it back to momentary and check it again.

In response to Deemar, this does not disable the wall switch.  The wall switch functions normally.  The only way the wall switch would not function is if the universal module got stuck in the ON position, which shouldn't happen in momentary mode.

To correctly show the module status in AHP/Heyu, set a macro for the uni mod that triggers on an ON command.  The macro simply has a 3 second pause and then sends an off command to the module.  The module will be off and ignore the off command that is sent, but AHP/Heyu should then indicate the correct status of the module.

[Brian H]

I am not sure what the switch mechanism is in a UM506, but can look. Maybe tomorrow.
I do know if it is On and you send it an On it clicks faintly not the usual clunk.

I found an interesting thread on a hanging UM506. Though it maybe they where overloading it or using it on higher than rated voltages. 
http://www.remotecentral.com/cgi-bin/mboard/rc-x10/thread.cgi?4600