The door status is connected to A0 because the old code used the analog value to get the door status. This was fine at the start and then i improved the code thanks to a contributor and now is a simple “on/off”.
On the ESP32-C3 A0 can be used as a digital pin too and it was left as is on the PCB.
The door status simply detect if the door is open or close
OK, when I measure the pins of the control with the multimeter, I get a constant 3.2 volts. Unfortunately, that doesn’t change anything. No pulse signal like in the instructions. I’m not using a module on the control board of the door control. But the additional board is just an optocoupler.
The door status comes from the other board. Where the OutputOC should be and there is little circuitry there.
I attached a snippet of the schematic.
You can check the complete schematic on github https://github.com/exico91/SommerESP
why do you connect the GND of the Sommer board with the GND of the Wemos. The potentials are completely different.
Any common DC to DC power supply will have GND in common from input to output. Maybe I do not understand the question
The supply from the sommer board is +24v DC
You would only need to connect PIN 2 (as seen from above, the field marked in red) to a digital input of the ESP with a 4.7 kOhm resistor to GND, as this pin outputs 3.2 volts.
As I said A0 can act as digital input and this is what I did. Im pretty much self-taught in electronics so maybe the circuit is not “optimal”. I did try to mimic the original Sommer OutputOC and Conex to minimize problems. Maybe the STN3NF06 mosfet is not necessary but was there on Sommer’s OutputOC.
You can avoid the resistor and just use the internal one on the ESP. Also on the ESP32-C3 there are 4 or 5 Analog inputs not just one. So calling it A0 is wrong. Its Gpio 4.
Fantastic project! I Great thanks for all your efforts.
I am in the process of buying two new garage door openers. I was recomended the APERTO from Sommer by my dealer. The circuit board in the manual looks very similar to to illustrations above. Do you know if the APERTO opener is compatible?
Again, many thanks
Hello, from the manual I found it seems compatible but obviously I cannot guarantee it 100%
The connectors are there as you can see from the image below.
DIP, Relay and Keypad
Sorry, I found only one in Italian.
Thanks,
I think I will take a chance and give it a try. Will report back in on the result
Good! If you can provide some photos and the precise model (I think there is a 550 and 800 variant of Aperto) would be great and I can add the info on Github that is supported.
Let me know!
Have not bought the opener myself yet but I gave the distributor a call and they confirmed the Aperto and Sommer base share the same control unit. Proof is in the pudding though …
Thank you for sharing your impressive project! Your plug-and-play kit for the Sommer Pro controller is a clever and cost-effective solution. I appreciate the integration without external wires or DC-DC transformers—it’s a clean, efficient design. Keep up the great work!
Your last buyer kit in France,
Great work @exico91 !
I’ve also built an equivalent board, simpler to build thanks to through-hole components that I’ve been using for over a year now.
I’m also recovering the light state of the carriage that allowed me to synchronize this light with my garage lights. 
1 Like
Nice board but how do you recover the light status? I see that there is a dedicated connector for the light on the board but i see no cable
Hi Micky,
I’m just about to order a new door with a Sommer controller, and I really like this project.
I have a query for you regarding the ESPHome YAML.
In your button definitions you have…
- platform: gpio
pin:
number: 6
#inverted: True
name: "Garage door close Switch"
id: close_switch
on_turn_on:
- delay: 250ms
- switch.turn_off: close_switch
restore_mode: ALWAYS_OFF
The above contains a 250ms delay before turning off again.
But in your -Cover section, you also include a 250ms delay…
close_action:
- switch.turn_off: open_switch
- switch.turn_on: close_switch
- delay: 250ms
- switch.turn_off: close_switch
Is there a need for both delays? Would it be OK to just rely on the one in the button definition?
Apologies if this is simple issue, I’m VERY new to ESPHome
Regards,
Glenn
Hello,
If you are looking to buy my board I ordered the components and the batch should be ready for mid-August.
Regarding the delays, you are probably correct but seems that they dont sum, more like a 250ms delay in “parallel”.
It should be safe to let the delay on the switch and remove it from the cover.
Also, the “manual” switches are there for debugging and accessible only from the web ui of the ESP module, only the Cover item is exposed to HA.
Ill test it and update the yaml when I can.
Thanks for pointing it out
Hi @exico91,
Indeed, it lacked some explanations. I simply get one bit of data from the “Light” connector at the bottom left of the board.
Here’s a discussion on the subject: Light Connector question · Issue #1 · camillebaronnet/sommer-pro-esp-adapter · GitHub
Hello! Checkout the new version out now.
With a single board design, thanks to M3c4tr0x on Github.
Now with ethernet support (coming soon)
But if you want to try now there is a esphome yaml here SommerESP/ESPHOME/esphome-eth.yaml at af6894ed1df86ce2150c4bc6013b75b9f9b14102 · exico91/SommerESP · GitHub and I used a W5500 module. You just need to buy a w5500 module that is standard and attach it wit dupont to the gpios on the board.
I had a small batch available that sold immediately but Ill have more boards available soon
Hi,
thanks for your dedication with this project Micky. I was so lucky to get two boards of your latest batch.
I have an Aperto / Sommer 550L system.
The combined PCB fits well in my case. The dip switches aren’t pre-soldered on my board, so i bridged pins 1 and 2 by soldering a small wire.
I still have one weird behavior where I’m not sure if this is specifc to the 550L: The output signal for the door status is inverted. When the garage door is closed it puts out a LOW signal on the GPIO so the status is wrong with the default firmware. I could simply invert the status in the yaml but it seems wrong to me. Do you have seen such a behavior in the past?
Best,
Sebastian