Novoferm 563S with cover component not working

Hi,

I’m trying to use esphome with the cover component used in esphome.

I’m using a low level shifter and an wemos s2

I can connect to the wemos but I don’t see messages from the unit. I’m using this config

esphome:
  name: garagedeur
  friendly_name: Garagedeur

esp32:
  board: esp32-s2-saola-1
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "************"

ota:
  - platform: esphome
    password: "58bcb8662f9cc5c509fb260cf0be3497"

wifi:
  ssid: home
  password: *****
  domain: .lan

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Garagedeur Fallback Hotspot"
    password: "********"
    
web_server:
  port: 80
captive_portal:
  
uart:
  rx_pin: GPIO19
  tx_pin: GPIO20
  baud_rate: 9600

cover:
  - platform: tormatic
    device_class: garage
    name: Novoferm 563s

Here some phofos



I imagine, that esphome uses CDC lor logging on S2.
Try with:

logger:
  baud_rate: 0

Also inspect carefully your soldering.

Logger I had also, but nothing happes when sending or receiving data

14:57:53	[D]	[cover:076]	

'Novoferm 563s' - Setting

14:57:53	[D]	[cover:084]	

  Position: 100%

14:57:53	[I]	[tormatic.cover:201]	

Fully opening gate

14:57:53	[I]	[tormatic.cover:312]	

Sending gate command Opened

Also when I use the remote nog data is receiving. Is there a debug option on the uart, so I can see it there is some communciation??

I mean to set the baud rate to 0, to make sure logger doesn’t spam the line.

Uart has debug option:

...
  debug:
    direction: BOTH
    dummy_receiver: true
    after:
      delimiter: "\n"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

Did check the solering again and debug but nothing

16:05:25	[D]	[uart_debug:114]	

>>> 08:3D:00:00:00:06:01:04:00:0A:00:01

16:05:26	[D]	[uart_debug:114]	

>>> 08:3E:00:00:00:06:01:04:00:0A:00:01

16:05:26	[D]	[uart_debug:114]	

>>> 08:3F:00:00:00:06:01:04:00:0A:00:01

16:05:26	[D]	[uart_debug:114]	

>>> 08:40:00:00:00:06:01:04:00:0A:00:01

16:05:26	[D]	[uart_debug:114]	

>>> 08:41:00:00:00:06:01:04:00:0A:00:01

16:05:27	[D]	[uart_debug:114]	

>>> 08:42:00:00:00:06:01:04:00:0A:00:01

16:05:27	[D]	[uart_debug:114]	

>>> 08:43:00:00:00:06:01:04:00:0A:00:01

16:05:27	[D]	[uart_debug:114]	

>>> 08:44:00:00:00:06:01:04:00:0A:00:01

16:05:28	[D]	[uart_debug:114]	

>>> 08:45:00:00:00:06:01:04:00:0A:00:01

16:05:28	[D]	[uart_debug:114]	

>>> 08:46:00:00:00:06:01:04:00:0A:00:01

16:05:28	[D]	[uart_debug:114]	

>>> 08:47:00:00:00:06:01:04:00:0A:00:01

16:05:29	[D]	[uart_debug:114]	

>>> 08:48:00:00:00:06:01:04:00:0A:00:01

16:05:29	[D]	[uart_debug:114]	

>>> 08:49:00:00:00:06:01:04:00:0A:00:01

16:05:29	[D]	[uart_debug:114]	

>>> 08:4A:00:00:00:06:01:04:00:0A:00:01

16:05:29	[D]	[uart_debug:114]	

>>> 08:4B:00:00:00:06:01:04:00:0A:00:01

16:05:30	[D]	[uart_debug:114]	

>>> 08:4C:00:00:00:06:01:04:00:0A:00:01

16:05:30	[D]	[uart_debug:114]	

>>> 08:4D:00:00:00:06:01:04:00:0A:00:01

16:05:30	[D]	[uart_debug:114]	

>>> 08:4E:00:00:00:06:01:04:00:0A:00:01

16:05:31	[D]	[uart_debug:114]	

>>> 08:4F:00:00:00:06:01:04:00:0A:00:01

16:05:31	[D]	[cover:076]	

'Novoferm 563s' - Setting

16:05:31	[D]	[cover:084]	

  Position: 100%

16:05:31	[I]	[tormatic.cover:201]	

Fully opening gate

16:05:31	[I]	[tormatic.cover:312]	

Sending gate command Opened

16:05:31	[D]	[uart_debug:114]	

>>> 08:50:00:00:00:06:01:06:00:0A:00:03

16:05:31	[D]	[uart_debug:114]	

>>> 08:51:00:00:00:06:01:04:00:0A:00:01

16:05:31	[D]	[uart_debug:114]	

>>> 08:52:00:00:00:06:01:04:00:0A:00:01

16:05:32	[D]	[uart_debug:114]	

>>> 08:53:00:00:00:06:01:04:00:0A:00:01

16:05:32	[D]	[uart_debug:114]	

>>> 08:54:00:00:00:06:01:04:00:0A:00:01

16:05:32	[D]	[uart_debug:114]	

>>> 08:55:00:00:00:06:01:04:00:0A:00:01

16:05:33	[D]	[uart_debug:114]	


I have no idea about the protocol used and if gate should reply or not.
Neither what is the meaning of the second byte that increases on your log…

Have you managed to get it working? I’m in the same situation and I’m not sure why it isn’t.

It’s been some years but I just came across the same problem as I wanted to read the state of my Novoferm 423.
The problem ist that you are using the wrong level shifter. This level shifter can only shift i2c levels. Somehow this is incompatibel to the uart.
Currently I made it running by not using a level shifter at all. I am using two of these modules:

One on the Novoferm side and one on the ESP32 side. Connected both modules with a simple 2-wire cabel. These modules can be operated with either 5 or 3.3 Volts. Works perfect.
I ordered another level shifter (yes, I still aim for a more slim version).
Almost forgot, it never worked with GPIO19 and GPIO20…don’t know why. Using other pins on my ESP32 S2 mini for the UART worked.

Usb D- / D+

That`s my config. Do I miss something? It never worked using D-/ D+ from the USB.

esphome:
  name: novoferm

esp32:
  board: lolin_s2_mini
  framework:
    type: esp-idf
    version: recommended

uart:
  tx_pin: GPIO20
  rx_pin: GPIO19
  baud_rate: 9600

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: "xxxxxxxxxx"

ota:
  - platform: esphome
    password: "xxxxxxxxxx"

wifi:
  ssid: "xxxxxxxxxx"
  password: "xxxxxxxxxx"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Novoferm Fallback Hotspot"
    password: "xxxxxxxxxx"

cover:
  - platform: tormatic
    device_class: garage
    name: Novoferm 423

captive_portal:

You can’t have uart on those pins.

Yeah, that was my conclusion in the end. Thank you very much for the confirmation.
So maybe it works with the level shifter on differen GPIOs. I will try it out.
Thanks a lot

You are right about the level shifter problem, bidirectional shifters are not best choice for uart, especially on higher baud rates.
But your RS485 approach is quite exotic… :wink:

You are right.
So, I just tested it.
!!!FORGET WHAT I WROTE IN MY INITIAL POST!!!
It works with this level shifter, just don’t use GPIO19 and GPIO20 as described in Tormatic/Novoferm Cover - ESPHome - Smart Home Made Simple.

I like your description of my RS485 approach :grinning:.
What do you think? shall I delete my initial post? Or maybe others like my exotic solution :joy:.

1 Like

Just leave it, the point is valid and your approach was working, so…

Thanks guys… almost gave it up, but tonight, changed from the advised gpio19 and gpio20 to gpio2 and gpio3 on my Wemos S2 mini and now it works :grinning:

And I did some more “research” and now I’ve got it working via the usb-c connector as well.
See Wemos S2 Mini: USB-C D+/D- (GPIO19/20) UART Fails for Novoferm · Issue #5902 · esphome/esphome-docs · GitHub

hello, can anyone help me and tell how to connect wemos s2 to my novoferm?

I dont get it what is written in Tormatic/Novoferm Cover - ESPHome - Smart Home Made Simple :
The unit pulls the USB’s D- (white) line high and uses it to transmit data. It receives data on the D+ (green) line, meaning the ESP should transmit on D+ and receive on D-. On a Wemos S2, these lines are directly routed to GPIO19 (D-) and GPIO20 (D+), since there is no separate in-line USB chip. This makes the S2 an ideal device for this purpose; it keeps the cable simple and compact, since it needs to fit in a tight space in the unit. Only a single header pin needs to be soldered the PCB to supply 3.3V to the logic level shifter, but it can be bent 90 degrees to sit parallel to the PCB, keeping a low profile.

Searched internet, but cant find any schema.
So do I need any logic level shifter? Or just connect d+ and d- from wemos to novoferm usb port, and take 5v and gnd from this novoferm usb port to power on my wemos?

EDIT: ok, I figured it out. yes i need LLS :slight_smile:

I noticed, upgrading to 2026.03 the Tormatic/Novoferm, is crashing when using it. Reverting back tot 2026.02, it works again

I see some uart changes in 2026.03, maybe this is causing the issue??

anyone else upgraded to 2026.03, andalso fails. I get these in the logs

07 [E] [tormatic.cover:297]

Reading remaining 259070 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 259326 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 259582 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 259838 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 260094 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 260350 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 260606 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 260862 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 261118 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 261374 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 261630 payload bytes of unknown type 0x0

14:39:07 [E] [tormatic.cover:297]

Reading remaining 261886 payload bytes of unknown type 0x0

Issue is solved in 2026.3.2. Here were some uart fixes