ESPHome over Thread

Showroom
,
21

Freut mich dass dir der Thread weitergeholfen hat.

Ein selbstgebauter OTBR mit den von dir verwendeten Boards war hier auch schonmal Thema, ich hatte mich da auch selbst mal für interessiert. Siehe hier: ESP Thread Border Router

Das ganze ist wohl nicht ganz so trivial, aber machbar. Was ebenfalls geht ist mit Hilfe eines MiniPCs/Raspi/etc, der bereits irgendwo in den Wohnräumen steht oder frei platziert werden kann zusammen mit einem USB-Dongle und Docker den OTBR einfach als Docker-Container zu hosten. Das hatte ich mal gemacht und war deutlich einfacher. Vielleicht ist das ja auch eine Option für dich?

22

Hallo Felix,

danke für den Link - alles hilft weiter :slight_smile:

Auch wenn es nicht trivial ist, werde ich mich mal daran versuchen. Ich sehe mehrere Vorteile in solchen kleinen, dedizierten Board(s) als OTBR:

  1. Redundanz. Man kann einfach ein paar im Haus verteilen (hier: problematisches Thema aufgrund der großen Flächen und dicken Wände)
  2. Gleichzeitig als BT Proxy nutzen
  3. können autark über POE / RJ45 laufen = Wifi Traffic etwas reduzieren (BT Proxy + Ethernet Seite der TBRs), Latenzen und Verfügbarkeit verbessern

Falls ich einen Prototypen stabil zum Laufen bekomme, würde ich 3-4 solcher Boards Flashen und verteilen.

Meine Hoffnung liegt auf dem Board mit der ESP P4+C6 Kombination. Der P4 hat ordentlich Wumms und RAM, für die Bluetooth Geschichte und Routing nicht zu unterschätzen.

Insgesamt ein spannendes Thema. Ich werde berichten :slight_smile:

1 „Gefällt mir“
23

Angeregt durch diesen Beitrag - vielen Dank dafür Felix - habe ich das auch mal testen wollen und bin dabei über ein paar Probleme gestolpert.

Das erste Problem hat sich durch meine Konfiguration ergeben. Ich hatte schon vor ein paar Monaten die App ESPHome Builder aus HA entfernt, da mit fast jeder neuen Version neue Fehler dazu kamen und ich jedes Mal meine produktiven Geräte aufwändig überarbeiten musste. Ich habe ESPHome seitdem in einem LXC Container auf Proxmox installiert und habe dort jetzt drei Instanzen. Eine, mit einer stabilen Version in der ich meine produktiven Geräte betreibe, die nicht mehr aktualisiert wird. Eine zweite Instanz läuft mit der letzten Version und in einer dritten kann ich jede beliebige ältere Version zum Testen installieren.

Dieses Szenario hat aber zur Folge, dass ich jetzt das Board mit Thread ohne WiFi nicht mehr über OTA flashen kann. Das funktioniert nur in der App ESPHome Builder in HA, die über den Thread Border Router (bei mir ein ZBS-1) auf das Thread-Netzwerk zugreifen kann.

Das zweite Problem war, dass ich die Konfiguration genau wie Felix mit der LED auf dem Board testen wollte.
Ich habe ein Waveshare ESP32-H2 Zero Mini, das statt einer blauen LED eine WS2812 Cool RGB LED verbaut hat. Damit funktioniert der Beispiel-Code von Felix leider nicht.

Mit diesem Code läuft es jetzt aber:

light:
  - platform: esp32_rmt_led_strip
    id: onboard_led
    name: "Onboard RGB LED"
    pin: 8
    num_leds: 1
    rgb_order: RGB
    chipset: ws2812
1 „Gefällt mir“
24

Das hier könnte gut an einer fehlenden Route in das Thread-Netzwerk liegen. Das Problem hatte ich auch schon andersherum, als ich versucht hatte einen Stand-Alone OTBR in meinem IoT-Netzwerk aufzusetzen. Das Problem hierbei ist, dass deinem Router nicht bekannt ist, dass “hinter” der Homeassistant Maschine noch ein weiteres Netzwerk liegt. Sprich die Anfragen an die Geräte im Thread-Netzwerk, welche ja direkt über eine IPv6 angesprochen werden können, laufen ins Leere weil der Router nichts damit anzufangen weiß.

Ich habe dies über die Definition des OTBR (bzw. in deinem Fall dann von Homeassistant) als IPv6 Gateway und einer Route in das Thread-Netzwerk mit dem entsprechenden IPv6 Präfix des Thread-Netzwerks gelöst.

25

@felix2911: logisch und spannend. Hättest Du Muse, die Config zu zeigen?

Da Du Dich offensichtlich bereits tiefer mit dem v6 Teil von Thread beschäftigt hast (ich nicht - möchte ich am Wochenende erledigen), ein paar Fragen:

(Syntax: “Router” = Hauptrouter im Ethernet Netz)

  1. Kann man den Prefix in einem bereits bestehenden Thread Netz ändern oder müsste man dann die Geräte neu einbinden? (externer prefix, nicht der mesh local - der ist mir Wurst)
  2. Könnte man OTBR dazu bewegen, den ULA prefix automatisch vom Router zu beziehen, wie bei jedem anderen v6 Gerät?
  3. (2) erweitert formuliert: Könnte man den OTBR dazu bewegen, vom Router sowohl einen ULA als auch GUA prefix zu beziehen und damit die Thread clients zu versorgen?

Du erkennst sicher, worauf das hinaus laufen soll :wink:

26

Wie das im konkreten konfiguriert wird hängt ein wenig vom Router ab, ich nutze hier eine OPNSense. Aber im wesentlichen musst du eine statische IPv6-Route in das Thread-Netzwerk definieren. Bei den Fritzboxen findet man das unter Netzwerk-Einstellungen in dem erweiterten Menü. Du brauchst zum einen ein Gateway, dass ist die ULA des Geräts auf dem der Thread-Border-Router sitzt. Und du musst das Netzwerk definieren, das ist dann das Subnetz was der Thread-Border-Router aufspannt. Das genau Präfix des Netzwerks musst du in der Konfiguration des Border-Routers nachsehen, dass ist meist eine Adresse der Art “fd**”. Mit dem Präfix und dessen Länge (Bei dem OTBR sollte das immer ein 64er Präfix sein) kann dein Router dann den Verkehr an die Thread-Geräte an das Gateway, also den OTBR weiterleiten. Wie man das bei deinem Router konkret einstellen muss, musst du vermutlich googlen. Aber da sollten sich Anleitungen für finden.

Was die anderen Frage angeht, kann ich dir ehrlich gesagt nicht beantworten. Ich würde aber mal spontan sagen, dass das zumindest standardmäßig so nicht vorgesehen ist. Und ich weiß auch nicht, ob das Thread-Netzwerk den gleichen ULA-Präfix haben kann wie das übergeordnete Netzwerk.

27

ebenfalls

IPv6-Hirnknoten. Erster Gedanke: Nein, denn für das “übergeordnete” /64er Netz ist die Sense der Router / Gateway.

Randnotiz: OTBR scheint sich selbst als Router zu Annoncen: Dokumentation bei OTBR. Theoretisch müssten doch damit manuelle Routen in der Sense überflüssig sein. Andererseits sehe ich den OTBR schon mal nicht im NDR table der Sense. Könnte aber auch am HA Host liegen (OTBR läuft derzeit noch als Addon / Container in der HA VM).

Falls ich es am Wochenende zeitlich schaffe, werde ich mal etwas experimentieren.

v6 macht immer wieder Spaß - und ich weiß, daß ich mit dieser Meinung allein auf weiter Flur bin :joy:

1 „Gefällt mir“
28

Das wäre auch meine Vermutung, aber ich habe mich damit nicht tiefer befasst bisher.

Interessant, da könntest du Recht haben. Bei mir lag der OTBR in einem anderen VLAN als die ESPHome-Geräte, deshalb hätte er dann vermutlich auch das Router Annoucement nichts gebracht. Nachdem ich die Route eingerichtet hatte, hat es auf jeden Fall funktioniert.

Dann kann ich dir auch exakt sagen wie ich es eingerichtet habe. Als erstes muss man den OTBR als Gateway unter System - Gateways - Configuration mit seiner ULA und dem zugehörigem Interface unter dem er erreichbar ist anlegen. Als zweites kann man dann unter System - Routes - Configuration das Thread-Netzwerk hinter dem zuvor angelegten OTBR-Gateway anlegen. Hierbei einfach auf “Add” drücken, das zuvor angelegte Gateway auswählen und dann den Präfix des Thread-Netzwerks hinterlegen. Danach konnte ich die die Thread-Geräte aus einem anderen VLAN anpingen.

29

Hilfe: Esphome mit Thread funktioniert, aber flashen über Thread nicht.

Ich habe einen Seeed XIAO ESP32C6 auf Thread umgestellt. Ich wollte ein paar Thread Router ( Fully Thread Devices ) mit einigen ESP32C6 in der Wohnung installieren.

Das funktioniert ohne Probleme. Es dauert zwar etwas länger als bei Wifi, bis die Connection mit dem Border Router ( Smlight SLZB-MR1 via Ethernet an Homeassistant ) steht, aber dann ist alles ok. Der ESP32C6 meldet sich ordnungsgemäss an Thread mit role “Router”.

ABER: Ich kann die Thread devices nur über USB flashen. Das funktioniert schnell und bequem. Aber es ist mir absolut unmöglich, die Geräte dann über Thread upzudaten oder neu zu flashen.

Jeder Versuch, das Gerät über Esphome Builder zu flashen, scheitert. Auch ein Download und dann ein Update über den Webserver des ESP32C6 hochzuladen führt zu Abbruch. Habe ich da etwas nicht gelesen und ist das derzeit unmöglich oder gibt es da einen Trick ?

Bitte um Hilfe.

Ich möchte nicht im laufenden Betrieb für Updates die Leiter aufstellen, den ESP ausbauen und zum PC schleppen, um einen Update durchzuführen.

Hier ist ein Log eines vergeblichen Flash-Versuches

INFO ESPHome 2026.3.1
INFO Reading configuration /config/esphome/test-esp32c6.yaml...
WARNING GPIO15 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq/#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Setting CONFIG_LWIP_MAX_SOCKETS to 13 (TCP=8 [api=3, web_server=5], UDP=2 [mdns=2], TCP_LISTEN=3 [api=1, ota=1, web_server_base=1])
INFO Compiling app... Build path: /data/build/test-esp32c6
Processing test-esp32c6 (board: seeed_xiao_esp32c6; framework: espidf; platform: https://github.com/pioarduino/platform-espressif32/releases/download/55.03.37/platform-espressif32.zip)
--------------------------------------------------------------------------------
HARDWARE: ESP32C6 160MHz, 320KB RAM, 4MB Flash
 - contrib-piohome @ 3.4.4 
 - framework-espidf @ 3.50503.0 (5.5.3) 
 - tool-cmake @ 4.0.3 
 - tool-esp-rom-elfs @ 2024.10.11 
 - tool-esptoolpy @ 5.1.2 
 - tool-ninja @ 1.13.1 
 - tool-scons @ 4.40801.0 (4.8.1) 
 - toolchain-riscv32-esp @ 14.2.0+20251107
Reading CMake configuration...
Dependency Graph
|-- noise-c @ 0.1.11
Compiling .pioenvs/test-esp32c6/src/main.cpp.o
RAM:   [=         ]  13.8% (used 45140 bytes from 327680 bytes)
Flash: [=====     ]  48.0% (used 880792 bytes from 1835008 bytes)
========================= [SUCCESS] Took 8.44 seconds =========================
INFO Build Info: config_hash=0x71b63954 build_time_str=2026-03-28 21:11:46 +0100
INFO Successfully compiled program.
INFO Connecting to fd25:477b:2492:1:99a:5154:17c2:c558 port 3232...
INFO Connected to fd25:477b:2492:1:99a:5154:17c2:c558
INFO Uploading /data/build/test-esp32c6/.pioenvs/test-esp32c6/firmware.bin (881152 bytes)
ERROR Error receiving acknowledge version: [Errno 104] Connection reset by peer
WARNING Failed to upload to ['test-esp32c6.local']

Das Flashen über USB und die anschliessende Inbetriebnahme funktioieren hingegen problemlos:

INFO ESPHome 2026.3.1
INFO Reading configuration /config/esphome/test-esp32c6.yaml...
WARNING GPIO15 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq/#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Setting CONFIG_LWIP_MAX_SOCKETS to 13 (TCP=8 [api=3, web_server=5], UDP=2 [mdns=2], TCP_LISTEN=3 [api=1, ota=1, web_server_base=1])
INFO Compiling app... Build path: /data/build/test-esp32c6
Processing test-esp32c6 (board: seeed_xiao_esp32c6; framework: espidf; platform: https://github.com/pioarduino/platform-espressif32/releases/download/55.03.37/platform-espressif32.zip)
--------------------------------------------------------------------------------
HARDWARE: ESP32C6 160MHz, 320KB RAM, 4MB Flash
 - contrib-piohome @ 3.4.4 
 - framework-espidf @ 3.50503.0 (5.5.3) 
 - tool-cmake @ 4.0.3 
 - tool-esp-rom-elfs @ 2024.10.11 
 - tool-esptoolpy @ 5.1.2 
 - tool-ninja @ 1.13.1 
 - tool-scons @ 4.40801.0 (4.8.1) 
 - toolchain-riscv32-esp @ 14.2.0+20251107
Reading CMake configuration...
Dependency Graph
|-- noise-c @ 0.1.11
Compiling .pioenvs/test-esp32c6/src/main.cpp.o
RAM:   [=         ]  13.8% (used 45140 bytes from 327680 bytes)
Flash: [=====     ]  48.0% (used 880792 bytes from 1835008 bytes)
========================= [SUCCESS] Took 8.49 seconds =========================
INFO Build Info: config_hash=0x71b63954 build_time_str=2026-03-28 21:11:46 +0100
INFO Successfully compiled program.
esptool v5.2.0
Serial port /dev/ttyACM0:
Connecting...
Connected to ESP32-C6 on /dev/ttyACM0:
Chip type:          ESP32-C6FH4 (QFN32) (revision v0.2)
Features:           Wi-Fi 6, BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 160MHz, Embedded Flash 4MB
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                58:e6:c5:ff:fe:00:90:f0
BASE MAC:           58:e6:c5:00:90:f0
MAC_EXT:            ff:fe

Uploading stub flasher...
Running stub flasher...
Stub flasher running.
Changing baud rate to 460800...
Changed.

Configuring flash size...
Auto-detected flash size: 4MB
Flash will be erased from 0x00010000 to 0x000e7fff...
Compressed 881152 bytes to 554285...
Writing at 0x00010000 [                              ]   0.0% 0/554285 bytes... 
Writing at 0x0001bc0a [                              ]   3.0% 16384/554285 bytes... 
Writing at 0x00025dd8 [>                             ]   5.9% 32768/554285 bytes... 
Writing at 0x0002a3ec [=>                            ]   8.9% 49152/554285 bytes... 
Writing at 0x0003143d [==>                           ]  11.8% 65536/554285 bytes... 
Writing at 0x000373c8 [===>                          ]  14.8% 81920/554285 bytes... 
Writing at 0x0003d63c [====>                         ]  17.7% 98304/554285 bytes... 
Writing at 0x00043631 [=====>                        ]  20.7% 114688/554285 bytes... 
Writing at 0x000497ee [======>                       ]  23.6% 131072/554285 bytes... 
Writing at 0x0004f95f [======>                       ]  26.6% 147456/554285 bytes... 
Writing at 0x00055784 [=======>                      ]  29.6% 163840/554285 bytes... 
Writing at 0x0005bd85 [========>                     ]  32.5% 180224/554285 bytes... 
Writing at 0x00062271 [=========>                    ]  35.5% 196608/554285 bytes... 
Writing at 0x000682fa [==========>                   ]  38.4% 212992/554285 bytes... 
Writing at 0x0006edd9 [===========>                  ]  41.4% 229376/554285 bytes... 
Writing at 0x00074d14 [============>                 ]  44.3% 245760/554285 bytes... 
Writing at 0x0007aecb [=============>                ]  47.3% 262144/554285 bytes... 
Writing at 0x0008127b [==============>               ]  50.2% 278528/554285 bytes... 
Writing at 0x00087383 [==============>               ]  53.2% 294912/554285 bytes... 
Writing at 0x0008d6da [===============>              ]  56.2% 311296/554285 bytes... 
Writing at 0x000939f8 [================>             ]  59.1% 327680/554285 bytes... 
Writing at 0x0009996c [=================>            ]  62.1% 344064/554285 bytes... 
Writing at 0x0009f913 [==================>           ]  65.0% 360448/554285 bytes... 
Writing at 0x000a5627 [===================>          ]  68.0% 376832/554285 bytes... 
Writing at 0x000ab8a0 [====================>         ]  70.9% 393216/554285 bytes... 
Writing at 0x000b1934 [=====================>        ]  73.9% 409600/554285 bytes... 
Writing at 0x000b7ad2 [======================>       ]  76.9% 425984/554285 bytes... 
Writing at 0x000bdbd6 [======================>       ]  79.8% 442368/554285 bytes... 
Writing at 0x000c36c9 [=======================>      ]  82.8% 458752/554285 bytes... 
Writing at 0x000c925e [========================>     ]  85.7% 475136/554285 bytes... 
Writing at 0x000cef9f [=========================>    ]  88.7% 491520/554285 bytes... 
Writing at 0x000d4ab7 [==========================>   ]  91.6% 507904/554285 bytes... 
Writing at 0x000daa2e [===========================>  ]  94.6% 524288/554285 bytes... 
Writing at 0x000e0944 [============================> ]  97.5% 540672/554285 bytes... 
Writing at 0x000e7200 [==============================] 100.0% 554285/554285 bytes... 
Wrote 881152 bytes (554285 compressed) at 0x00010000 in 3.1 seconds (2253.9 kbit/s).
Verifying written data...
Hash of data verified.
SHA digest in image updated.
Flash will be erased from 0x00000000 to 0x00005fff...
Compressed 22576 bytes to 14044...
Writing at 0x00000000 [                              ]   0.0% 0/14044 bytes... 
Writing at 0x00005830 [==============================] 100.0% 14044/14044 bytes... 
Wrote 22576 bytes (14044 compressed) at 0x00000000 in 0.2 seconds (977.5 kbit/s).
Verifying written data...
Hash of data verified.
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 3072 bytes to 134...
Writing at 0x00008000 [                              ]   0.0% 0/134 bytes... 
Writing at 0x00008c00 [==============================] 100.0% 134/134 bytes... 
Wrote 3072 bytes (134 compressed) at 0x00008000 in 0.0 seconds (1047.3 kbit/s).
Verifying written data...
Hash of data verified.
Flash will be erased from 0x00009000 to 0x0000afff...
Compressed 8192 bytes to 31...
Writing at 0x00009000 [                              ]   0.0% 0/31 bytes... 
Writing at 0x0000b000 [==============================] 100.0% 31/31 bytes... 
Wrote 8192 bytes (31 compressed) at 0x00009000 in 0.0 seconds (2166.0 kbit/s).
Verifying written data...
Hash of data verified.

Hard resetting via RTS pin...
INFO Successfully uploaded program.
INFO Starting log output from /dev/ttyACM0 with baud rate 115200
[21:15:07.144]I (193) esp_image: segment 3: paddr=000e470c vaddr=4080ce0c size[I][logger:120]: Log initialized
[21:15:07.145][C][safe_mode:136]: Unsuccessful boot attempts: 0
[21:15:07.148][D][esp32.preferences:144]: Writing 1 items: 0 cached, 1 written, 0 failed
[21:15:07.149][I][app:089]: Running through setup()
[21:15:07.151][D][binary_sensor:048]: 'System Boot Error' >> OFF
[21:15:07.152][D][light:079]: 'System Status LED' Setting:
[21:15:07.152][D][light:085]:   Color mode: On/Off
[21:15:07.260][C][component:252]: Setup openthread took 107ms
[21:15:07.280][W][component:398]: api set Warning flag: unspecified
[21:15:07.282][D][openthread:157]: Setting up SRP services. count = 2
[21:15:07.283][D][openthread:207]: Added service: _esphomelib._tcp
[21:15:07.283][D][openthread:207]: Added service: _http._tcp
[21:15:07.283][D][openthread:211]: Finished SRP setup
[21:15:07.284][I][app:138]: setup() finished successfully!
[21:15:07.284][D][text_sensor:120]: 'Aktive Verbindung' >> 'Getrennt'
[21:15:07.284][D][openthread:113][ot_main]: Thread Version: 5
[21:15:07.285][D][openthread:137][ot_main]: Link Mode Device Type: TRUE, Network Data: TRUE, RX On When Idle: TRUE
[21:15:07.286][I][openthread:152][ot_main]: Activating dataset...
[21:15:07.288][I][app:231]: ESPHome version 2026.3.1 compiled on 2026-03-28 21:11:46 +0100
[21:15:07.288][I][app:233]: Project xiao.esp32c6_sensors version 1.0.0
[21:15:07.289][I][app:238]: ESP32 Chip: ESP32-C6 rev0.2, 1 core(s)
[21:15:07.289][C][logger:229]: Logger:
[21:15:07.289][C][logger:229]:   Max Level: DEBUG
[21:15:07.289][C][logger:229]:   Initial Level: DEBUG
[21:15:07.289][C][logger:236]:   Log Baud Rate: 115200
[21:15:07.289][C][logger:236]:   Hardware UART: USB_SERIAL_JTAG
[21:15:07.289][C][logger:246]:   Task Log Buffer Size: 768 bytes
[21:15:07.305][C][gpio.output:010]: Binary Output:
[21:15:07.305][C][gpio.output:152]:   Pin: GPIO15
[21:15:07.306][C][gpio.output:012]:   Inverted: YES
[21:15:07.312][C][template.binary_sensor:016]: Template Binary Sensor 'System Boot Error'
[21:15:07.312][C][template.binary_sensor:237]:   Device Class: 'problem'
[21:15:07.317][C][template.text_sensor:016]: Template Sensor 'Aktive Verbindung'
[21:15:07.318][C][template.text_sensor:228]:   Icon: 'mdi:transit-connection-variant'
[21:15:07.323][C][light:092]: Light 'System Status LED'
[21:15:07.353][C][openthread:029]: Open Thread:
[21:15:07.353][C][openthread:031]:   Device Type: FTD
[21:15:07.359][C][web_server:434]: Web Server:
[21:15:07.359][C][web_server:434]:   Address: test-esp32c6.local:80
[21:15:07.364][C][esphome.ota:071]: Over-The-Air updates:
[21:15:07.364][C][esphome.ota:071]:   Address: test-esp32c6.local:3232
[21:15:07.364][C][esphome.ota:071]:   Version: 2
[21:15:07.369][C][safe_mode:026]: Safe Mode:
[21:15:07.370][C][safe_mode:026]:   Successful after: 60s
[21:15:07.370][C][safe_mode:026]:   Invoke after: 15 attempts
[21:15:07.370][C][safe_mode:026]:   Duration: 300s
[21:15:07.370][C][safe_mode:043]:   Bootloader rollback: support unknown
[21:15:07.375][C][web_server.ota:238]: Web Server OTA
[21:15:07.380][C][api:237]: Server:
[21:15:07.381][C][api:237]:   Address: test-esp32c6.local:6053
[21:15:07.381][C][api:237]:   Listen backlog: 4
[21:15:07.381][C][api:237]:   Max connections: 8
[21:15:07.381][C][api:244]:   Noise encryption: YES
[21:15:07.383][D][text_sensor:120]: 'Thread PAN ID' >> '16e7'
[21:15:07.387][C][openthread_info:016]: IPAddress 'Thread IP Adresse'
[21:15:07.393][C][openthread_info:016]: Role 'Thread Role'
[21:15:07.398][C][openthread_info:016]: PAN ID 'Thread PAN ID'
[21:15:07.403][C][mdns:194]: mDNS:
[21:15:07.403][C][mdns:194]:   Hostname: test-esp32c6
[21:15:07.703][D][text_sensor:120]: 'Thread Role' >> 'detached'
[21:15:08.098][D][main:089]: Thread verloren oder noch nicht verbunden!
[21:15:12.092][D][text_sensor:120]: 'Thread IP Adresse' >> 'fd25:477b:2492:1:99a:5154:17c2:c558'
[21:15:12.093][I][openthread:107][ot_main]: SRP client has started
[21:15:12.711][D][text_sensor:120]: 'Thread Role' >> 'router'
[21:15:23.531][D][api:222]: Accept FD25:477B:2492:1:D3F6:6CB5:DB06:EB1
[21:15:23.532][W][component:429]: api cleared Warning flag
[21:15:23.532][D][main:341]: >>> SYSTEM ONLINE <<<
[21:15:23.533][D][light:079]: 'System Status LED' Setting:
[21:15:23.533][D][light:092]:   State: ON
[21:15:23.534][D][light:079]: 'System Status LED' Setting:
[21:15:23.534][D][light:092]:   State: OFF
[21:15:23.534][D][light:079]: 'System Status LED' Setting:
[21:15:23.535][D][main:022]: Thread Netzwerk steht, LED aus.
[21:15:23.535][D][light:079]: 'System Status LED' Setting:
[21:15:23.535][D][light:092]:   State: ON
[21:15:23.536][D][light:079]: 'System Status LED' Setting:
[21:15:23.536][D][light:092]:   State: OFF
[21:15:23.536][D][main:043]: >>> SYSTEM ONLINE <<<
[21:15:23.689][D][api.connection:2440]: Home Assistant 2026.3.4 (FD25:477B:2492:1:D3F6:6CB5:DB06:EB1): connected
[21:15:37.287][D][text_sensor:120]: 'Aktive Verbindung' >> 'Thread'
[21:16:07.150][I][safe_mode:091]: Boot seems successful; resetting boot loop counter
[21:16:07.292][D][text_sensor:120]: 'Aktive Verbindung' >> 'Thread'
[21:16:08.285][D][esp32.preferences:144]: Writing 1 items: 0 cached, 1 written, 0 failed
30

Bei mir klappt das Flashen über Thread problemlos, es dauert nur sehr lange. Hier scheint es aber so zu sein, dass der Flash gar nicht erst gestartet wird. Hast du die Fehlermeldung mal bei einer Suchmaschine deines Vertrauens eingegeben?

1 „Gefällt mir“
31

Ja, und die AI hat mir des langen und breiten erklärt, das liegt daran, dass das Protokoll zum Flashen für Wifi geschrieben ist und weil Thread so langsam ist, deshalb Homeassistant dis Daten über Ethernet viel zu schnell sendet und deswegen der Speicher des Border Routers überläuft und das Flashen erst in der nächsten Release von Esphome funktioniert.

Ich konnte mir das nicht vorstellen und suche nach einer anderen Erklärung. Und es scheint ja laut deiner Aussage zu funktionieren.

32

Ich habe einen ESP32-H2 (der hat kein WiFi). Mit dieser Konfiguration funktioniert bei mir, nach einem erstmaligen Download per USB, auch Updates via Thread (mit einem Home Assistant Connect ZBT-2):

esphome:
  name: tread-test
  friendly_name: Tread Test

esp32:
  board: esp32-h2-devkitm-1
  variant: ESP32H2
  framework:
    type: esp-idf

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption: 
    key: !secret esphome_encryption_key

#wifi: #ESP32-H2 hat kein WiFi
#  ssid: !secret wifi_ssid
#  password: !secret wifi_password
#  min_auth_mode: WPA2

  # Enable fallback hotspot (captive portal) in case wifi connection fails
#  ap:
#    ssid: "Tread-Router-1 Fallback Hotspot"
#    password: !secret fallback_password

# captive_portal:

ota:
  - platform: esphome
    password: !secret ota_password

network:
  enable_ipv6: true

openthread:
  device_type: FTD #Full Thread Device
  tlv: !secret thread_network_tlv

# Example sensor to verify device works
sensor:
  - platform: uptime
    name: "Thread 1 Uptime"

# onloard RGB-LED
light:
  - platform: esp32_rmt_led_strip
    name: RGB-LED
    rgb_order: RGB
    pin: GPIO8
    num_leds: 1
    chipset: ws2812

text_sensor:
  - platform: openthread_info
    channel:
      name: "Thread Channel"
    role:
      name: "Thread Device Role"
    ext_addr:
      name: "Thread Extended Address"
    ext_pan_id:
      name: "Thread Extended PAN ID"
    ip_address:
      name: "Thread IP Address"
    network_key:
      name: "Thread Network Key"
    network_name:
      name: "Thread Network Name"
    pan_id:
      name: "Thread PAN ID"
    rloc16:
      name: "Thread RLOC16"
#    eui64:
#      name: "Thread EUI64"
33

Tja, vielleicht liegt es wirklich daran, dass mein OTBR via Ethernet einen Smlight SLZB-MR1 verwendet. Es gibt da so eine Warnung in der OTBR Doku, die ich bisher nicht beachtet habe, da meine matter Geräte ohne Problem funktionieren. Das Flashen mit seiner für Thread enormen Netzwerklast könnte das ändern:

The OTBR expects the RCP connected radio to be on a reliable link such as UART or SPI.
Using TCP/IP to reach a remote RCP radio breaks this assumption.
If the TCP/IP connection fails, the OTBR will not shutdown cleanly and leave stale routes in your network.
This will lead to Thread devices to be potentially unreachable for up to 30 minutes (route lifetime) even when other routers are available.
The RCP protocol is not designed to be transferred over an IP network: It is a timing-sensitive protocol.
You might experience Thread issues if your network link has excessive latencies.
As Thread is networking capable, running a Thread border router on the system the RCP radio is plugged in is recommended.

:crayon:by HarryP: Post formatiert

1 „Gefällt mir“