OpenKNX NUKI Bridge ???

[Techi]

Ich bräuchte mal eine Einschätzung, wie aussichtsreich wäre es OpenKNX mit https://github.com/I-Connect/NukiBleEsp32 auszustatten und daraus eine einfach zu verwendende KNX NUKI Bridge auf Basis eines ESP32 zu haben ? (NUKI https://nuki.io/de/)

Ich befürchte das ein Resourcenproblem (RAM und Timing) hier einen Strich durch die Rechnung machen könnte ? Ich kann das aber nicht wirklich gut beurteilen.

Hab nur mal schnell auf blöd versucht das "knx-demo-diy" Example von https://github.com/thelsing/knx zusammen mit dem Example von https://github.com/I-Connect/NukiBleEsp32 in ein PlatformIO Project zu Verwursten, bekomme das auch kompiliert jedoch gibt es bei der Ausführung Guru Meditation bzw. einen Bootloop.
(mit Verwursten meine ich, daß beide zumindest gleichzeitig nebeneinander auf einem ESP32 laufen (ohne weitere Verbindung beider) )

Und ja ich kenne auch "https://github.com/technyon/nuki_hub" und hab das auch erfolgreich in Verwendung aber ich fände es alleine aus Wartungsgründen super wenn man den IP Pfad (MQTT) entfernen könnte. Nun wollte ich auch wieder mit https://github.com/technyon/nuki_hub (unterstützt neben MQTT auch Steuerung per GPIOs) auf I/O umbauen und dachte mir dann, warum nicht gleich direkt von KNX auf Nuki Bluetooth. Die Hardware wäre halt so super schön schlank, nur einen ESP32 und eine BCU.

[jeff25]

warum vermutest du RAM und Timing Probleme?

[henfri]

ich denke, hier gilt das gleiche, wie bei meiner ähnlichen Frage
https://knx-user-forum.de/forum/proj...rtlock-steuern

[Techi]

warum vermutest du RAM und Timing Probleme?

Naja, daß ganze BLE Zeug beim ESP32 ist eigentlich RAM hungrig und so wie ich das gesehen habe ist der KNX Stack auch nicht gerade das kleinste Framework.
Beide Systeme haben außerdem strikte Anforderungen an die Einhaltung der Timings.
Aber wie schon erwähnt, ich hab mit solchen Program Frameworks nicht allzu-viel zu tun, ich bin eher der Man für extrem Hardware nahe Aufgaben und da bin ich es halt gewohnt mit IRQs und Timings zu jonglieren. Ich kann das bei so fertigen Frameworks halt schlecht beurteilen, deshalb frag ich ja auch hier.

[Ing-Dom]

Ich befürchte das ein Resourcenproblem (RAM und Timing) hier einen Strich durch die Rechnung machen könnte ? Ich kann das aber nicht wirklich gut beurteilen.

das würde ich fast ausschließen - zumindest wenn man es richtig macht.
Der ESP hat 2 Cores und ausreichend SRAM (und erst recht PSRAM).

Die Hardware wäre halt so super schön schlank, nur einen ESP32 und eine BCU.

hmm, das weiß ich nicht. Einen ESP mit WLAN bekommt man nicht aus dem Bus versorgt, der der Energiebedarf im WLAN Betrieb zu groß ist.
Wie sich das mit BT verhält weiß ich nicht - müsste man messen / ausprobieren.
Ggf. könnte man mit Goldcap / Stützkondensatoren oder einem Akku was machen oder eben halt zusätzlich eine 24V Versorgung.

Grundsätzlich wäre auch denkbar dass man ohne BCU auskommt und die KNX-Konnektivität über WiFi macht, dann bräuchte man nur 24V.

Wenn du das ernsthaft angehen willst unterstütze ich gerne bei der Hardware oder auch knxprod wenn es soweit ist.
Aber erstmal einen FW-Prototypen zum Laufen bekommen..

Pack' dein Zeug doch mal auf github damit man draufschauen kann, gib ein paar Details über die Hardware und die Fehlermeldungen... dann kommen wir da sicher weiter.

[mumpf]

Die Frage ist: Läuft bei Dir der NukiBleEsp32-Teil alleine in PIO (ohne OpenKNX)? Kannst Du schon Aktionen machen, die das Schloss öffnen/schließen?

Wenn das alles läuft, könnte man über eine OpenKNX-Anbindung zumindest mal nachdenken, wobei ich mich nicht wirklich auf dem ESP32 auskenne. Somit müsstest Du eher die Programmier-Seite übernehmen und ich könnte Dir bei der OpenKNX+ETS-Seite helfen. Hier gilt (zumindest von meiner Seite aus) da gleiche, was ich Hendrik geschrieben habe: Ich hab keine Anwendung hierfür und würde das sicherlich nicht als Projekt übernehmen. Wenn Du es aber machen willst und Dir zutraust, es zu programmieren, kann ich Dich unterstützen.

Wenn alles andere da ist, könnte man schauen, ob man erstmal ein einfaches offnen/schließen über eine GA hinbekommt. Je nachdem, welche Features Du Dir noch bei einem Schloss vorstellst, könntest Du die ja nach und nach erweitern.

Gruß, Waldemar

[Techi]

Ing-Dom
Bezüglich Strombedarf, hier müsste man mal sehen inwiefern man Wifi als solches deaktivieren kann denn man bräuchte ja nur BLE was selbst auf einem ESP32 stromsparend sein sollte. Insofern bin ich zuversichtlich, daß die Versorgung eher das kleinere Problem ist.

Das hab ich noch gefunden:
https://github.com/espressif/esp-idf...ment-500312453
Bei den dort ermittelten average current könnte man gut mit passenden Kapazitäten puffern.
Auch gäbe es noch den ESP32-H2 wenn man diesen nur mit BLE betreibt hätte man eher gar kein Problem. (den hab ich aktuell als Zigbee Device im Test, zum nachrüsten eine Batterie Tischlampe)

Zum Thema ohne BCU und dafür Wifi, genau das möchte ich ja gerade nicht mehr.
Aktuell hab ich einen Olimex ESP32 mit LAN und POE als MQTT zu NUKI Brigde laufen und möchte da eben davon wegkommen (keine IP Verbindungen mehr) dashalb ja nun IO oder gleich KNX. (also KNX TP)

OK, das mit Github werd ich machen.

mumpf
Also ich habe alle in einem Project verwurstet und das lässt sich auch kompilieren jedoch nicht ausführen.
Wenn ich jedoch in setup() und loop() den jeweils anderen Part temporär raus nehmen dann lässt sich noch vorhanden Part auch ausführen.
Also wenn ich den KNX bezogenen Code raus nehmen, dann läuft der NUKI bezogene und umgekehrt.
Nächste schritt wäre nun raus zu finden wo es genau klemmt, z.B. ob es schon in der setup() kracht oder erst im loop()
Soweit bin ich noch nicht, hab gestern Abend erst angefangen und wollte bevor ich jetzt mehr Zeit da rein stecke erst mal hier Fragen wie so die Einschätzung ist.

Bezüglich Features: (speziell KNX / ETS)
Das was ich brauche beschränkt sich auf das einrichten des Schlosses, also z.B. die Schloss ID zuweisen, das Binden sowie im Betrieb dann ein paar BOOL Ein / Ausgänge. ( LOCK, UNLOCK, UNLATCH, sowie noch ein paar Statusrückmeldungen, LOCKED, UNLOCKED )

Wenn man viel Arbeit rein steckt, dann würde sich wohl das komplette NUKI Ecosystem abbilden lassen das wäre jedoch erst mal gar nicht mein Ziel.

[henfri]

Falls du das realisierst, bin ich gerne dabei.
ich kann mir vorstellen, dass der Code leicht beide Varianten (nuki und eq3) unterstützen kann.

[Ing-Dom]

Aktuell hab ich einen Olimex ESP32 mit LAN und POE als MQTT zu NUKI Brigde laufen und möchte da eben davon wegkommen (keine IP Verbindungen mehr) dashalb ja nun IO oder gleich KNX. (also KNX TP)

natürlich gibt es gute Gründe gegen WLAN, mich würde aber die Motivation interessieren.
Es ist ja schon ein Unterschied ob man das Gerät per WiFi und MQTT einbindet und noch mit einer HA integration oder sowas, oder ob das Gerät sich per ETS "seamless" parametersieren lässt und direkt KNX "spricht" (wenn auch über einen IP-Router).
Ich will nur ausschließen dass du dir den Möglichkeiten die KNX und OpenKNX hier bieten nicht bewusst bist...

[Techi]

Ing-Dom
Es nerft halt z.B. von einem EthernetSwitch (der dann theoretisch USV benötigt) abhängig zu sein um z.B. zur Tür rein zu kommen.
und Funktechnik (allen voran Wifi) verwende ich fast ausschließlich für "!!! mobile !!!" Endgeräte.

[Ing-Dom]

Es nerft halt z.B. von einem EthernetSwitch (der dann theoretisch USV benötigt) abhängig zu sein um z.B. zur Tür rein zu kommen.

absolut verständlich. Mich hat nur die genaue Motivation interessiert.

BLE sollte tatsächlich buspowered möglich sein, wenn auch nicht ohne Weiteres. (ca. 130mA Spitzenbedarf, + LEDs etc..)
Bis 100mA @3,3V Gesamtbedarf geht einfach mit den 3,3V der BCU
Ab 100mA bis ca. 250mA ist machbar, aber dafür muss man entweder aufteilen oder einen zweiten Schaltregler verwenden.
Evtl. kann man bei ESP die entsprechenden Powerdomains entsprechend versorgen, müsste man prüfen und messen.


Da ich aktuell an einem ESP basierendem Gerät arbeite nehm ich den Usecase BLE + TP mal gedanklich mit auf, bisher hatte ich das ausgeschlossen

[c4orbi]

Als Nuki User wär ich interessiert und würd mich auch als Tester anbieten.

[Techi]

...
BLE sollte tatsächlich buspowered möglich sein, wenn auch nicht ohne Weiteres. (ca. 130mA Spitzenbedarf, + LEDs etc..)
Bis 100mA @3,3V Gesamtbedarf geht einfach mit den 3,3V der BCU

siehe den Link oben in meinem Post:
MAX cpu frequency = 240MHz
ADV(adv_interval = 1000.0ms) average current 3.05mA, max 149.34mA, min 0.71mA
SCAN(scan_wiONndow = 500.0ms, scan_interval = 1000.0ms) average current 59.57mA, max 170.26mA, min 0.93mA
CONNECTION(connection_interval = 960.0ms, slave_latency = 0) average current 2.07mA, max 152.28mA, min 0.81mA


Siehe auch https://www.microelectronicos.net/me...esp32-modules/
Würde somit voraussetzen, daß die Pufferkapazität mit 5V läuft und danach erst eine LDO auf 3.3V (besser noch ein hierfür Effizienz optimierter DCDC z.B. SY8089, siehe angehängtes Bild) verwendet wird, womit man dann einen Pufferdrop von 1,5V hätte.
Sehr pessimistisch angenommen (bei Powerup), 0,3A für 100uS und einer Entladung von 5V auf 3,5V wären wir bei 2000uF Puffer.

Ich hab aber gerade ein anderes Problem, mit geht der Flashspeicher aus, bin jetzt bei 104% (noch ohne weitere Funktionen, und das bei 128mBit Flash)
Ich sehe da gerade sehr schwarz, stehe aber mit diesem ganzen PlatformIO eh auf Kriegsfuss, so ein Molloch. Wer weis was da alles im Hintergund mit compiliert und unnötig eingebunden wird, ich blick da nicht mehr durch.



LilyGO-T-Koala-DCDC.png

[Ing-Dom]

Ich sehe da gerade sehr schwarz, stehe aber mit diesem ganzen PlatformIO eh auf Kriegsfuss, so ein Molloch. Wer weis was da alles im Hintergund mit compiliert und unnötig eingebunden wird, ich blick da nicht mehr durch.

das ist eher der Arduino Core als Plattform I/O.

Sehr pessimistisch angenommen (bei Powerup), 0,3A für 100uS und einer Entladung von 5V auf 3,5V wären wir bei 2000uF Puffer.

2000uF ist schon ein ganz ordentlicher Brocken und der LDO der dauerhaft 1/3 der Leistung verheizt auch eher unsexy. Aber wie gesagt, das ist ein lösbares Problem.

Ich hab aber gerade ein anderes Problem, mit geht der Flashspeicher aus, bin jetzt bei 104% (noch ohne weitere Funktionen, und das bei 128mBit Flash)

Achtung gefährlichs halbwissen.. das liegt wahrscheinlich an der Partitonierung des Flash und du hast wahrscheinlich nur 1MB für dein Programm.
Was hast du als Startpunkt für dein Projekt genommen? Hast du eine bestehende OpenKNX Applikation verwendet oder from scratch?

[henfri]

Hallo,

ich wollte mal sehen, ob ich mein eQ3 Lock selbst mit einem ESP zum laufen bekomme.
Gibt es einen guten Startpunkt für ein ESP32-Openknx-Projekt?

Im ersten Schritt würde ich gar kein KNX verwenden (hab keine BCU übrig). Im zweiten Schritt dann KNX-IP, final aber TP.

Gruß,
Hendrik