OpenKNX REG1 goes ESP32

[Ing-Dom]

Hallo zusammen,

an einige Stellen schon geteasert (hier und hier..), heute mal die offizielle Ankündigung dazu !

Für OpenKNX-Geräte die per IP (WLAN, LAN) kommunizieren werden wir zukünftig verstärkte auf die ESP32 Chips setzen - zum Einen aufgrund des integrierten WLAN und der Ethernet-MAC zum Anderen aufgrund der guten Qualität des IP-Stacks im IDF und der vielen verfügbaren Bibliotheken für diverse Anwenderprotokolle.

Für das modular aufgebaute REG1 System habe ich also in den letzten Monaten eine Controller PCB entwickelt die als MCU einen ESP32 mit integrierter Ethernet-MAC, 8MB Flash und 2MB PSRAM verwendet.
10/100 Base-T Ethernet wird über eine externe LAN8720 PHY realisiert.
Für WLAN/BT ist ein IPEX Connector vorhanden.

REG1-LAN-TP-Base.jpg

Die Interfaces im REG1-System, also zur Front und zur Applikations-PCB sind kompatibel so das diese (in gewissen Grenzen) interoperabel sind.

Sofern KNX-TP erforderlich ist wird eine NanoBCU mit 3.3V Vcc2 eingesetzt.
In dieser Betriebsart reicht der Busstrom leider nicht für WLAN !
Sofern auf KNX-TP verzichtet wird, wird statt einer NanoBCU eine NanoDCU verwendet, die aus einer 24V Versorgung die nötigen 3.3V bereitstellt, die dann auch für WLAN ausreichend sind.

REG1-LAN-Base.jpg

Wie ihr seht, gibt es vielfältige Möglichkeiten rund um die REG1-ControllerESP Platine verschiedene REG1-Geräte zu erstellen.

Um auf der Front maximal viel Informationen und Funktion unterbringen zu können habe ich auch eine neue Front-PCB, die REG1-Font-RGB entwickelt, die statt 2 Tastern und herkömmlichen LEDs 4 Taster und 4 RGB-LEDs hat. Damit ist man bei der Anzeige nochmal ein Stück flexibler.

20250202_213716.jpg
REG1-Controller-ESP sowie die REG1-Front-RGB, eine NanoBCU und eine NanoDCU.


Der Start wird mit dem
REG1 Basismodul LAN+TP (REG1-LAN-TP-Base) erfolgen, also ein Gerät mit LAN und TP, busversorgt. Basismodul, weil es keine Applikatoins-PCB enthält.
Das ist dann eine gute HW-Basis für die OpenKNX IP-Router Applikation, aber auch Michael hat dafür ein paar Applikationen schon in der Vorbereitung - Smarthomebridge (Homekit), Sonos etc..

20250101_210532.jpg

Konkret geplant ist dann auch ein
REG1 Basismodul LAN (REG1-LAN-Base), das auf die TP Anbindung verzichtet und über KNX-IP-Routing kommuniziert - da hier dann über die NanoDCU und 24V versorgt wird, ist auch das Strombudget ausreichend für zB Bluetooth-Kommunikation oder stromhungrige Erweiterungen.



Konkret hab ich dann dazu die "Schwester" des REG1-SEN-Multi (auf RP2040 Basis mit TP) geplant, den REG1-LAN-SEN-Multi.
Also ein Multisensor 1TE für die Hutschiene, zur Erfassung verschiedenster Sensorwerte (je nach Applikation - zB. zB 2 SML Zähler sowie 3 Binäreingänge für S0).
Vorteil hier: die Daten schnell und ohne Belastung des KNX-TP über LAN weiterleiten, loggen ...

Angedacht sind natürlich auch Geräte mit WLAN - die aber aufgrund des hohen Strombedarfes nicht zuverlässig über TP versorgt werden können.
Welche Nische hier genau dann passt, muss sich noch zeigen.



Zum Zeitplan:

Aktuell befinden sich eine kleine Anzahl in OpenKNX-Teaminternen Tests. Die soweit ganz vielversprechend sind, die USB-Schnittstelle ist beim ESP etwas zickig, das trifft aber eigentlich nur bei der Entwicklung, Endanwender sollten damit weniger zu tun haben (außer dem initialen Ladevorgang). Denn natürlich unterstützen die Geräte dann OTA FW-Updates - schnell und einfach.
Da aber noch Chinese New Year gerade so abklingt und ich den Kollegen da drüben lieber noch etwas Zeit lasse Ihren Rausch auszuschlafen, ist der Plan eine erste größere Closed Beta so in ca. 2 Wochen (also Mitte Februar) zu ordern. D.h. an euch geliefert dann zum reguären Termin am 08.03.
Sobald das dann in Produktion ist, wird es HIER dann dazu eine Ankündigung gegen, auf deren Basis ihr mich dann kontaktiert und einen Link bekommt zur Bestellung.
Es bringt NICHTS mich jetzt anzuschreiben oder Interesse konkret zu bekunden Das bringt nur alles durcheinander.

Ich beantworte aber gerne Fragen, nehme Anregungen auf etc...

[MarcoLanghans]

Ing-Dom so wie ich es sehe ist die NanoDCU von der Belegung identisch zur NanoBCU oder liege ich hier falsch? Ich finde diese nämlich zusammen mit dem ESP32 und WLAN sehr interessant, da ich ein paar stellen habe wo ich kein Buskabel habe, aber es wäre mir möglich 24V hinzubekommen und da kommt deine NanoBCU gerade richtig für Entwicklungen :-)

[traxanos]

Das ist die Idee. BCU und DCU sind PIN kompatibel. Die DCU hat sogar eine SavePIN

[Theees]

Ing-Dom … WLAN sehr interessant, da ich ein paar stellen habe wo ich kein Buskabel habe

traxanos plant ihr da eine KNX-RF Alternative? Oder verstehe ich das hier falsch?

[Ing-Dom]

ja richtig. Das ist der Grundgedanke. Der Controller bleibt gleich und durch die Wahl BCU oder DCU lege ich mich fest ob mit TP und busversorgt oder ohne TP und 24V Versorgung.

die DCU hat 200uF Puffer, eine SAV-Pin der einen Ausfall der 24V meldet und eine abschaltbere, 2. 3,3V Rail (EN-Pin) zum stromsparen in diesem Fall.
So ist ein "wegsichern" von Prozessdaten auch bei Nicht-TP Geräten grundsätzlich möglich (ist aber im OpenKNX Stack noch nicht eingebaut und erst recht nicht ausgiebig getestet).

Spezifiziert und gebaut für 24V Eingang und 3,3V Ausgang, max. 500mA.

Sie ist NICHT für 30V DC Eingangsspannung gebaut, sollte aber Dank Reserven ein versehentliches Anschließen an KNX oder unverdrosselter Spannung überleben (und auch das Gerät dahinter).

[traxanos]

traxanos plant ihr da eine KNX-RF Alternative? Oder verstehe ich das hier falsch?

was meinst du mit rf alternative? Im Grund ist es einfach nur ein normales knxip was wlan statt lan nutzt.

[Theees]

was meinst du mit rf alternative?

Als KNX ohne Kabel gibt es ja nur KNX-RF (multi).

Im Grund ist es einfach nur ein normales knxip was wlan statt lan nutzt.

Also quasi so wie Shelly es jetzt macht? Kommuniziert das dann über den IP Router?

[Ing-Dom]

Also quasi so wie Shelly es jetzt macht? Kommuniziert das dann über den IP Router?

Auch die Shellys funken KNX-IP über WLAN, korrekt.
Die Verbindung zum KNX-TP kann dann ein IP-Router herstellen, genau.

Das war, genau genommen überhaupt erst mein Antrieb den IP-Router zu entwickeln. Ich wollte WLAN KNX-IP Geräte niedrigschwellig einbindbar machen..

Und nein, aktuell denkt niemand von uns an Entwicklungen im KNX-RF Umfeld.. zumindest weiß ich von nichts.
Der knx stack kann das aber grundsätzlich, und irgendwer hat da auch Geräte damit gebaut, das aber nie breiter veröffentlicht...

[traxanos]

Als KNX ohne Kabel gibt es ja nur KNX-RF (multi).

wo steht das? knxip ist komplett spezifiziert. welchen layer 1 du nimmst ist dem Protokoll völlig egal.

Kommuniziert das dann über den IP Router?

korrekt ein router sowie eine passende spannungsversorgung ist vorausgesetzt

aber RF ist eher was für die UP-Dose und das ist beim REG1 sicher schwieriger Daher würde ich es nicht als Alternative betiteln. Aber es wird sicher Anwendungszwecke geben wo kein Kabel in der Nähe ist und man z.B. ne Wasseruhr per S0 oder so auslesen möchte

[traxanos]

Ein weiterer Vorteil ist das was Ing-Dom schon schrieb, dass man den BUS nicht mit Messwerten fluten muss, wenn man über IP geht (korrekte Filtertabellen vorausgesetzt). Aber interessant ist denke ich auch das Bluetooth. Man könnte z.B. zukünftig sogar darüber Bluetooth-Tracking machen. Das habe ich früher mal gemacht und hat damals recht gut geklapptm, solange die Frau nicht das BT ausgeschaltet hat

[Theees]

Ok danke euch für die Erläuterungen

[gbglace]

Mal ein Gedanke,
REG1 ESP32 Gerät als KNX-IP Only.

Wenn man dort KOs mit dynamischen Datentyp hätte und ich dann mir quasi alle GA's im Projekt dran verbinde, gerne auch nur mit den Flags K,S,A.
Wäre solche eine HW ausreichend performant die empfangenen KNX-Telegramme Wert-konvertiert direkt als MQTT weiter zu reichen?
Quasi ein KNX-IP <> MQTT GW, MQTT-Toppic Definition erstmal recht simple einen BasisPfad und dann die GA.

In HA und Co lässt sich sowas ja basteln aber man muss da immer mühsehlig GA für GA erfassen, allein schon wegen der Konvertierung der Hex-Werte entlang der DPTs und Einheiten. Und ich hätte da gern etwas ohne HA dazwischen.

Und bestenfalls einfach alles aber dann müsste man wohl das Gerät einmal komplett mit dem Projekt-file betanken und es hätte keine wirkliche ETS-Applikation weil es einfach nur auf der IP-Linie horchen würde und alles was ankommt konvertiert und weiter reicht.

Die KNX Adapter für eine influxdb sind ja auch viel Handarbeit und ich mag das auch nicht in influxdb haben, weil deren SQL schrecklich ist auszuwerten.

Nur mal so als Gedanken für einen potentiellen Anwendungszweck.

Aber ansonsten als KNX-IP Gerät mit IR-Lesekopf und ähnlichen Anwendungen sehe ich da auch reichlich Potential.

[traxanos]

Wäre solche eine HW ausreichend performant die empfangenen KNX-Telegramme Wert-konvertiert direkt als MQTT weiter zu reichen?
Quasi ein KNX-IP <> MQTT GW, MQTT-Toppic Definition erstmal recht simple einen BasisPfad und dann die GA.

sei nicht so ungedudig ...

[K1rk]

Mal ein Gedanke,
REG1 ESP32 Gerät als KNX-IP Only.
Wäre solche eine HW ausreichend performant die empfangenen KNX-Telegramme Wert-konvertiert direkt als MQTT weiter zu reichen?
Quasi ein KNX-IP <> MQTT GW, MQTT-Toppic Definition erstmal recht simple einen BasisPfad und dann die GA.

Fände ich auch interessant. Lt. ChatGPT können das bereits die IP Router von Weinzierl und Enertec.
Noch interessanter wäre es, wenn bspw ein MQTT Broker oder Zigbee2MQTT drauf laufen würde.

[Ing-Dom]

ich hab das bereits an vielen Stellen erwähnt:
Der IP-Router bleibt ein IP-Router. Keine 2. Applikation.

Ein wie auch immer geartetes Gateway vom IP-Protokoll x zu KNX wird ein separates Gerät sein - ggf. als "Multi-Gateway" aber definitiv nicht in der IP-Router Firmware.