[Hardware] OpenKNX REG1 goes ESP32

[Theees]

Ok danke euch für die Erläuterungen

[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

[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

[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...

[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?

[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.

[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).

[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?

[traxanos]

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

[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 :-)

[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...