Reverse engeneering the Hörmann UAP1 protocoll

I own a Hörmann sectional door to my garage which is driven by a Hörmann SupraMatic E. To control the door via a home automation system you have several options:

  • Connect potential free contacts directly to the motor. That means you have just very basic control over the motor because you can't give up and down command but just a go command as you can with the radio controls.
  • Usa a UAP1, a small extension box to have better control over the motor and get some feedback signals. Costs are about 50€ for the UAP1 and still a couple of potential free contacts are needed to connect the UAP1 to the home automation system.
  • Speak directly to the motor and get the signals directly onto the homeautomation system. Exactly what I want to have :-)

I searched the internet for information about the bus, but little to nothing can be found about it. So I decided to reverse engeneer and document the bus!


Top side of the circuit board: UAP1 top side

  1. The micro controller, a 20-pin SSOP, labled with F9222. After a while I found out that it must be a Renesas μPD78F9222 8-bit micro controller (datasheet).
  2. A Darlington Transistor Array, a 16-pin SOT, labled with ULN2003A. Drives at least the three relais, maybe more.
  3. The power supply, a D-PAK, labled with 78M05G. Converts the 24VDC coming from the motor down to 5VDC.
  4. A RS485 transceiver, a 8-pin SOT, labled with SP485EE.

Bottom side of the circuit board: UAP1 bottom side

Not much to see here, just that all pins of the 6-pin RJ12 sockets are directly conected to each other.

UAP1 connectors


  1. Not clear
  2. 24VDC
  3. GND
  4. Not clear
  5. RS485, DATA-
  6. RS485, DATA+

I use a ExSys USB to RS422/RS485 converter I had lying around which a connected to the BUSOUT connector using a cable I made specifically for that purpose.

Reversing the protocoll

I expected a rather simple protocoll where no comunication happens until the UAP1 gets triggered by a switch, but I was more than wrong. Here's what I got using the USB converter:

output of /dev/ttyUSB0

At first I thought I had a wrong baudrate but after a while I saw that at powerup the UAP1 sends the string "EE000478-00" before the gibberish starts. That occured at 19200 baud (8N1) so I think that must be the correct baudrate.

Then I encountered another problem I didn't think about in the first place. RS485 is Half-Duplex, that means that only one participant on the bus can talk at a given time. But how can I tell who is sending which bytes!?

I had to go to the other side of the RS485 converter IC which is connected to the UART of the μPD78F9222 and one pin that enables the transmitter. Whith that one I can tell when the UAP1 is sending and when it is receiving!

But connecting a SOT IC to the Logic analyzer is no fun, so i decided to solder three wires to the bottom of the PCB where the three signals I need are luckily connected to vias. I also soldered a pin header to the 5 solderpads next to the μPD78F9222. I hoped to find the signals there as well but it turned out that is not the case. But at least I can connect to GND there.

I decided to look at the boards communications without the motor connected. To supply the board with 24VDC, which normally comes in via the RJ12 connector, I simply used the terminals taht normally connect the switches.

My setup: My setup

My setup in detail from the top

  • White: TX
  • Brown: TX enable
  • Green: RX

My setup in detail from the bottom

When the board is powered while the logic analyzer is collecting data, we see these bytes comming in:

Startup sample

Thats 0x00 0x0B followed by the ASCII "EE000478-00" and terminated by 0x71. At that point I realized that "EE000478-00" is printed to the PCB, so its kind of a model or serial number.

Unfortunately no other communication is happening when I trigger a "close door" for example. It seems that this must happen when the UAP1 is connected to the motor.

Later I captured traces using my logic analyzer for each possible command, these are:

  • startup (not a real command but maybe interesting)
  • open door
  • close door
  • ventilation position
  • toggle lamp
  • Radio door open
  • Radio door close

This is what I got: First trace

I've set two analyzers for async serial data on both, the RX and the TX line. They make me able to export the analyzed data as CSV.

Vimdiff exports

The RX line still contains the sent bytes of the UAP1, so I wrote a python Script that annotates the RX file with RX and TX labels.

This is how far i got until now. I'll try to extend this artcle or write a followup in the future.