Premise Garage Door Opener suggestions
- Thread starter w84no1
- Start date
Motorola Premise
Just my opinion, sure others will have their own experiences. Whenever the walls are open or wires can be pulled, always always use hardwired devices over wireless. They are cheaper, less maintenance and more reliable, save the wireless devices for later(damn missed that).
We installed several Z-wave devices in our current home more for testing for our new home build. It uses Homeseer and a usb z-wave controller and I have been impressed with the reliability and uptime of Z-wave at this location, near 100%.
At our new project we have just finished a new garage that uses Z-wave for lighting using a VRCOP to an ELK-M1(yes wiring run for future hardwired lighting). All other devices were hardwired. The door controllers that came with the door openers were hardwired to the M1 along with the open and closed sensors. Since this is a remote site and only the garage exists at this time we have not yet utilized the capability to open/close the doors remotely thru the M1, just too risky need more cameras.
For me remote control of garage doors needs to be rock solid. For us the VRCOP does not meet this test, it has not been reliable enough. I would never consider z-wave for any part of a remote control garage door, and frankly the VRCOP won’t be part of the new house design either.
We installed several Z-wave devices in our current home more for testing for our new home build. It uses Homeseer and a usb z-wave controller and I have been impressed with the reliability and uptime of Z-wave at this location, near 100%.
At our new project we have just finished a new garage that uses Z-wave for lighting using a VRCOP to an ELK-M1(yes wiring run for future hardwired lighting). All other devices were hardwired. The door controllers that came with the door openers were hardwired to the M1 along with the open and closed sensors. Since this is a remote site and only the garage exists at this time we have not yet utilized the capability to open/close the doors remotely thru the M1, just too risky need more cameras.
For me remote control of garage doors needs to be rock solid. For us the VRCOP does not meet this test, it has not been reliable enough. I would never consider z-wave for any part of a remote control garage door, and frankly the VRCOP won’t be part of the new house design either.
BraveSirRobbin
Moderator
I agree with Brian's post above. There are just to many other options than to go wireless with something like Z-Wave to control AC power to the garage door controls (though I do feel sound using my wireless garage door sensor hack as that is totally different version of 'wireless'... See my How-To HERE).
The VRC0P should be very reliable. If it's not reliable something is setup wrong or there are RF issues. The Premise VRC0P module is very well written and performs very well in my experience. Your issue could be firmware related, but I'm not sure as I haven't used the VRC0P with the Elk.
I know my job failure rate is 1/2000 to 1/10,000 (the open source module several of us wrote records job failures). These failed jobs usually occur when a light bulb burns out and the z-wave control circuit in the switch no longer has power. This is based on real world everyday use in a 50 node network. I'd expect failure rates to be even less if you never let a lamp burn out or if you use the 15A switches instead of the dimmers.
If you use locks, I would put those on their own VRC0P as the locks transmit too much data (for encryption purposes), so they slow things down when sending these encrypted packets.
That said, I wouldn't use z-wave for a garage door either, but you ought to have door sensors to check the door state after requesting the door to close. If you do this, all you have to do is add programming to re-perform the closure and email you if the door still doesn't close. This is what I do with Premise via the Elk M1G. Either way, not having door state indication on an exterior door and only assuming the door closes when you tell it to is silly.
I know my job failure rate is 1/2000 to 1/10,000 (the open source module several of us wrote records job failures). These failed jobs usually occur when a light bulb burns out and the z-wave control circuit in the switch no longer has power. This is based on real world everyday use in a 50 node network. I'd expect failure rates to be even less if you never let a lamp burn out or if you use the 15A switches instead of the dimmers.
If you use locks, I would put those on their own VRC0P as the locks transmit too much data (for encryption purposes), so they slow things down when sending these encrypted packets.
That said, I wouldn't use z-wave for a garage door either, but you ought to have door sensors to check the door state after requesting the door to close. If you do this, all you have to do is add programming to re-perform the closure and email you if the door still doesn't close. This is what I do with Premise via the Elk M1G. Either way, not having door state indication on an exterior door and only assuming the door closes when you tell it to is silly.
BraveSirRobbin
Moderator
The global cache can monitor a simple contact closure input correct? Why not just use a magnet sensor made for the garage door (I mounted mine on the top header)?
Maybe I'm not understanding your situation/question Chuck.
Maybe I'm not understanding your situation/question Chuck.
BraveSirRobbin
Moderator
Yes, the "Lady of the Lake" already took care of that task, but thanks for the compliment. Just make sure your Global Cache WILL take a contact closure input.chucklyons said:
BraveSirRobbin
Moderator
Well, my personal opinion would be to run 22 gauge pair to windows and four pair to doors. Don't forget about laundry room (run at least two pairs), plus wiring to where garage door button will be located.w84no1 said:
Think about under sinks and such as well for water leak detectors and put some wiring at the main water pipe entry.
Been a while since I posted here. I hope people are still around...
Resurrecting this old thread with a question.
I have an iTach WF2CC on my network, and I've configured it in Premise. I have a couple of the WF2IR devices already, so I'm familiar with how to set up the iTach devices.
I've validated that I can activate the contact closures because I can telnet into the iTach device, then issue "setstate,1:3,1" and "setstate,1:3,0" to close and open the #3 relay, respectively.
Problem is, I can't activate the relay using Premise. In PortSpy, I can see the periodic "getversion" commands being sent from Premise to the iTach. But when I try to activate the relay using the device properties, nothing happens, and I don't see anything in PortSpy. Does Premise not know how to issue the "setstate" commands? Do I need to do this from within a script? If I need to do it in a script, what do I need put in the script?
Thanks,
Mark
chucklyons said:
Resurrecting this old thread with a question.
I have an iTach WF2CC on my network, and I've configured it in Premise. I have a couple of the WF2IR devices already, so I'm familiar with how to set up the iTach devices.
I've validated that I can activate the contact closures because I can telnet into the iTach device, then issue "setstate,1:3,1" and "setstate,1:3,0" to close and open the #3 relay, respectively.
Problem is, I can't activate the relay using Premise. In PortSpy, I can see the periodic "getversion" commands being sent from Premise to the iTach. But when I try to activate the relay using the device properties, nothing happens, and I don't see anything in PortSpy. Does Premise not know how to issue the "setstate" commands? Do I need to do this from within a script? If I need to do it in a script, what do I need put in the script?
Thanks,
Mark
It should work with the Global Cache add-in that comes with Premise. If it doesn't be sure to update the iTach's firmware. I use two iTach for IR control and they work great.
Originally though, I had to call Global Cache and they were kind enough to modify the protocol slightly for the iTach to be completely backwards compatible with the GC100 protocol! I have only tested IR, but if you have issues, just call Global Cache after studying port spy and comparing the GC100 protocol to the iTach protocol. Also, if you have issues email me and I will forward the original email chain that should have the contacts I spoke to at Global Cache.
Originally though, I had to call Global Cache and they were kind enough to modify the protocol slightly for the iTach to be completely backwards compatible with the GC100 protocol! I have only tested IR, but if you have issues, just call Global Cache after studying port spy and comparing the GC100 protocol to the iTach protocol. Also, if you have issues email me and I will forward the original email chain that should have the contacts I spoke to at Global Cache.
markh said:
Similar threads
