@mterry63 Check the chamberlain parts site to see which “travel module” your door uses. The diagram is based off of this one. On my opener, the cable that connects the module is straight through, so also check that.
You can also look at the module itself - the RPM1/2 pins were labeled on my rotary encoder board.
Regarding 3.3v power - if you find a power source that works let me know and I will add it to the instructions.
Looking at the parts diagram on their site it is the same travel module as you linked.
The first place I would look is at those large capacitors which are likely part of the power supply.
Yeah, also there is a serial EEPROM chip and radio transceiver chip and both datasheets show Vcc connections.
@PaulWieland what signals appear at the RPM1 and RPM2 pins? I plan to try to confirm these signals as well while I have the board powered up. The travel module appears to be the same as yours but I can only see 5 wires in your 6 pin connector. It appears that counting from the left of your photo RPM1 is the 2nd pin (orange wire) and RPM2 is the 6th pin (brown wire). Are they putting out some logic level when the limits are reached?
@mterry63 The rotary encoder is 3.3v logic. This page does a better job of explaining how they work than I can type here.
I actually don’t know what the other wires are for… normally a rotary encoder would only need 4 (ground, vcc, rpm1, rpm2). Some have a 5th wire because you can click the button, but in this application I never bothered to figure out what the other two wires are for.
And before you try - the vcc pin on my logic board could not provide enough current to power the ESP8266.
Given your advice there maybe I’ll just use a USB power supply and solder only the RPM1 and RPM2 connections then like you suggested early on. I did find a Chamberlain description of the travel module which says it’s “a combination of a limit sensor and RPM sensor in one”. This article describes it with the concept of a “pass point” at the center of travel so the system knows whether to go forward or reverse when reacting to some event. Photos of the unit show the travel module with these markings:
PP
RPM1
VCC
GND
MOT
RPM2
Which corresponds to the pinout you have labeled for RPM1 and 2.
Yeah not sure what mot and pp are for.
You can get direction of rotation and speed from the rotary encoder (rpm1/2). I’m not sure what the other part of the sensor is actually measuring or outputting.
@PaulWieland I got one of the boards with D1 mini installed today. I powered the device via a USB power supply and soldered to RPM1 and RPM2 connectors on my board. I then connected control, ground, obstruction, RPM1 and RPM2 to the board. Once configured and watching with MQTT Explorer, I can see that the open, opening, closed, closing, and obstructed/clear statuses are all working correctly. I was only able to send a working “open” command one time and the door opened. After that, neither open, close, nor light commands caused any physical change. When I send an “open” command the status immediately changes to “open”, but the door does not open. If I use the button on the wall the door works correctly and the MQTT status is updated accordingly.
Thoughts?
@mterry63 can you open an issue on GitHub so I can track it? Include your garage door opener model number and the serial log (which you can pull from esp tools).
Someone else is having an issue with an early security+ 2.0 opener from 2015. Im getting the wall button so I can compare, I’m wondering if chamberlain changed the protocol somewhere along the line.
Sure thing. Thanks.
BTW, my GDO model is exactly the same as switchtower on github, but I’m confident it worked via command once.
I have a feeling the timing is slightly different. I’ll know for sure once I get the older wall control in hand and can analyze it.
Short update… I got a 2015 vintage board to test with and it works fine.
It seems that there are two different series of part numbers used on the logic boards - some start with 050 or 50 and these work fine. The problematic boards start with part number 45A.
I’m still trying to figure out the numbering scheme of these door opener models and part numbers. There doesn’t seem to be any rhyme or reason to it!
There is a 45 series logic board en route. Thanks Scott!
Great work! I am looking at doing this myself, except I’m using the NodeMCU dev boards since that’s what I already have on-hand. Also, I’m planning on sensing the state of the light via measuring the voltage to the light’s relay; I’m wondering why you didn’t use that?
I’ll also be putting AM312 Passive IR motion and DS18b20 temperature sensors on mine, so I’ll be looking at translating your code to ESPHome for my project.
I do have a GDO with this model 045ACT control board (another view), so I’m very interested in your progress on the 45 series logic boards.
I wonder if the J2 header on that board has anything useful?
Version 2.0 (alpha) adds rolling code support for legacy 45 series logic boards.
I’m having issues with ESP Web Tools, so flashing has to be done the old fashioned way.
For those following, Paul has a couple of people (myself included) who have reported the 45 series logic boards are working with the new code. Great progress has been made! Thanks to @PaulWieland for all the hard work.
This is a cool little project and recently my old non-security+ GDO is on its last leg. Does anyone have any Chamberlin models they can recommend in the US that works for this plug and play? I love the non-solder option if possible. Thanks!
EDIT:
I saw on the ratdgo page that there is a reed switch hook-up. Is this 100% required for HA if there is another method? For example today I use a ZooZ ZEN17 and also a ZooZ ZSE43 tilt sensor. With this code below in HA I am able to determine if the door is open/closed.
# For Garage stuff
cover:
- platform: template
covers:
garage_door:
device_class: garage
friendly_name: "Garage Door"
position_template: "{{ is_state('binary_sensor.garage_door_tilt_sensor_window_door_is_open', 'on') }}"
open_cover:
- condition: state
entity_id: binary_sensor.garage_door_tilt_sensor_window_door_is_open
state: "off"
- service: switch.turn_on
target:
entity_id: switch.garage_door_relay_2
close_cover:
- condition: state
entity_id: binary_sensor.garage_door_tilt_sensor_window_door_is_open
state: "on"
- service: switch.turn_on
target:
entity_id: switch.garage_door_relay_2
stop_cover:
service: switch.turn_on
target:
entity_id: switch.garage_door_relay_2
icon_template: >-
{% if is_state('binary_sensor.garage_door_tilt_sensor_window_door_is_open', 'on') %}
mdi:garage-open
{% else %}
mdi:garage
{% endif %}
So can I do the same thing just eventually replacing the switch entities with the future ratdgo device?
Any security+ 2.0 door opener will work with ratgdo.
There was an issue with early security+ openers which has been resolved with the latest version.
