OpenKNX und Tasmota

[STSC]

Hallo,

hat schon jemand versucht den OpenKNX bzw. thelsing/knx Stack mit Tasmota zu kompilieren.
Ich bin am überlegen, ein Modbus/IR Gateway auf dieser Lösung zu bauen.
Über das Tasmota Scripting müssten sowohl IR Leseköpfe als auch Modbus unterstützt sein.

https://ottelo.jimdofree.com/stromz%C3%A4hler-auslesen/

Tasmota hat den Vorteil, dass es schon eine Webseite, WLAN und MQTT fertig zur Verfügung stellt.
Um das ganze an KNX TP angebunden zu bekommen, könnte die NanoBCU verwendet werden, dafür bräuchte man aber einen passenden KNX Stack.

Als uC würde der ESP32 zum Einsatz kommen. Was meint ihr?

[henfri]

Tasmota kann doch schon knx. Ist es nicht einfacher, diese Funktion zu erweitern?

[mumpf]

Tasmota kann doch schon knx

Das wäre aber KNX-IP. Er redet hier von KNX-TP. Die Idee ist nicht abwegig.

STSC Würdest Du denn ein Gerät anstreben, das komplett über die ETS programmierbar ist? Das ist ja die eigentliche Besonderheit von unserem KNX-Stack.
Da wir bisher unser Augenmerk auf Geräte gelegt haben, die über den Bus versorgt werden, haben wir nur den SAMD und den RP2040 genutzt, da der ESPxxxx zu viel Strom zieht. Aber der Stack an sich hat eine ESP32 Unterstützung. Insofern kann man das schon angehen.

Ansonsten gibt es aber von uns schon ein fertiges Modbus RTU-Gateway und Ing-Dom wollte auch einen IR-Lesekopf anbieten (der ist aber noch nicht fertig). Vielelicht könnten Deine Energien auch in diese Richtung fließen...

Gruß, Waldemar

[henfri]

Ah ja, verstehe.

Einen Anderen Gedanken in die Richtung, den ich schon hatte:
Kennt ihr ESPHome?
Ist ganz ähnlich zu Tasmota und unterstützt richtig viel Hardware. Die Konfiguration erfolgt am PC über eine YAML Datei.

switch:
  - platform: gpio
    name: "Living Room Dehumidifier"
    pin: 5

ESP-Home unterstützt den RP2040 (https://esphome.io/components/rp2040.html)

Wenn man jetzt:

• In ESPHome den OpenKNX-Stack implementiert
  • Das ist natürlich (s.u.) komplexer als man denkt, denn hier muss ja nicht nur die Kommunikation als Solches, sondern auch die Zuordnung Sensor-Daten zu KO erfolgen
  • In der o.g. YAML sieht man natürlich erstmal nicht, welchen DPT das KO hat

switch:
  - platform: gpio
    name: "Living Room Dehumidifier"
    pin: 5
    knx_dpt: 1

• Aus der YAML eine XML für den KNX-DB Generator erzeugt
• Die Zuordnung KO -- GA würde dann über die ETS erfolgen

Hätte man plötzlich OpenKNX Support für hunderte Sensoren.

Sorry fürs Kapern des Threads. Wenn es lohnt, den Gedanken weiter zu verfolgen, können wir gerne an anderer Stelle weiter machen.

Gruß,
Hendrik

[STSC]

Das wäre aber KNX-IP. Er redet hier von KNX-TP. Die Idee ist nicht abwegig.

STSC Würdest Du denn ein Gerät anstreben, das komplett über die ETS programmierbar ist? Das ist ja die eigentliche Besonderheit von unserem KNX-Stack.
Da wir bisher unser Augenmerk auf Geräte gelegt haben, die über den Bus versorgt werden, haben wir nur den SAMD und den RP2040 genutzt, da der ESPxxxx zu viel Strom zieht. Aber der Stack an sich hat eine ESP32 Unterstützung. Insofern kann man das schon angehen.

Ansonsten gibt es aber von uns schon ein fertiges Modbus RTU-Gateway und Ing-Dom wollte auch einen IR-Lesekopf anbieten (der ist aber noch nicht fertig). Vielelicht könnten Deine Energien auch in diese Richtung fließen...

Gruß, Waldemar

Die Stromaufnahme ist bei einem Hutschienengerät kein Thema, da kann man ein externes Netzteil verwenden.
Mir gefällt bei der Tasmota Lösung, dass man die Realtime Werte direkt auf der Webseite angezeigt bekommt. Vor allem bekommt man auch gleich schöne Graphen mit Google-Charts (Tag, Monat, Jahr). Bei KNX kann man definitiv nicht alle 1-2s neue Werte auf dem Bus senden. Für KNX könnte man eher Schwellen definieren und vielleicht alle 15 Minuten ein Mittelwert.

Prinzipiell wäre es das Modbus RTU-Gateway nur mit ESP32. Das Problem ist einfach, dass man für den RP2040 zum einen kein WLAN hat und noch jede Menge Funktionlität entwickelt werden müsste, das in Tasmota bereits vorhanden ist.

[Ing-Dom]

Ich sehe wenig Sinn darin, einem Geräte das sowieso WiFi mitbringt, zusätzlich KNX-TP beizubringen.
Dann KNX-IP über WiFi - auch wenn das natürlich mit Verfügbarkeitseinschränkungen daherkommt...

[henfri]

Dann KNX-IP über WiFi - auch wenn das natürlich mit Verfügbarkeitseinschränkungen daherkommt...

Eben. Das wäre doch ein Grund

[STSC]

Jetzt völlig unabhängig von KNX, finde ich das Modbus RTU-Gateway ziemlich interessant. Wenn ich es richtig verstanden habe, wird es momentan ehe auf RP2040 umgebaut. Sehe ich es richtig, dass dafür nur die Mittelplatine getauscht werden muss? D.h. für einen ESP32 bräuchte man auch nur eine andere Mittelplatine

Wie ist eigentlich die galvanische Isolation bei diesem Modbus Gateway umgesetzt? Bei manchen TTL-zu-RS485 Boards sieht man z.B. einen ADUM3201 + CTTF0505.


Irgendwie fehlen mir gerade die Hardware Einzel-Threads für die ganzen OpenKNX Projekte, wo man solche Themen diskutieren könnte.

[Masifi]

Ja es wird gerade auf den RP2040 umgestellt. Aber einfach so die Mittelplatine tauschen ist es dann auch nicht :-) Der RP2040 wird nicht über die Hilfsspannung versorgt. Diese ist nur da, das man den Modbus einfach vom KNX-Teil trennen kann.

Zu den HW Einzel-Threads(zu meiner HW) kann ich nur sagen, die wird es geben, aber wann weiß ich selber noch nicht. Es hängt für mich noch zuviel Herzblut daran und ganz fertig sind die Module auch noch nicht.

[mfd]

Eben. Das wäre doch ein Grund

Ich stelle mir gerade ein Gerät vor, dass zur Einrichtung oder für Updatezwecke ein WLAN zur Verfügung hat, ansonsten aber wie ein "normales" TP-Gerät im Verteiler oder Unterputz wohnt...
Bei der Ersteinrichtung spannt es dann ein WLAN auf, womit es bequem vom Smartphone aus betriebsbereit gemacht werden kann (der Teil klingt wie bei Tasmota).

Also WLAN für den Wartungskomfort und TP für die Zuverlässigkeit beim Betrieb.

[henfri]

Naja, bei OpenKNX ist das Konzept ja, dass man das Gerät per ETS konfiguriert - wofür braucht man dann das Webinterface?

[mfd]

Bis man an dem Punkt ist, dass es überhaupt ein Gerät ist, das per ETS konfigurierbar ist dachte ich...

[willisurf]

Einrichtung oder für Updatezwecke ein WLAN zur Verfügung hat

Wäre mir zu viel Aufwand und Hardwareoverhead. Für einmal einrichten und maximal eine Handvoll Updates ein WLAN auf die Platine zu packen, das dann nie wieder benutzt wird.
Achja und aus dem Verteiler müsste es auch noch rausfunken oder man muss beim Update die Tür offenlassen.

[STSC]

Der Vorteil vom ESP32 ist, dass er bereits WiFi integriert hat. Da braucht man im Gegensatz zum RP2040 keinen weiteren Baustein. Dafür hat der ESP32 einen deutlich höheren Stromverbrauch. Es kommt auch immer darauf an was man machen will. Für Zählerwerte in Echtzeit auslesen ist WLAN deutlich besser als KNX. Ein Zähler liefert alle 1-2 Sekunden neue Werte, das geht sicher nicht per KNX.
Bei einem Modbus Gateway ist das schon schön, wenn man per HTTP in einem Webrowser auch noch sieht, wie der Tagesverbrauch, Monatsverbrauch bzw. Jahresverbrauch ist und das ganze auch noch mit Graphen dargestellt ist.

Anders sieht es wieder aus bei Tasterinterfaces oder Sensormodulen. Hier braucht man sicher kein Webinterface. Hier hat der RP2040 klare Vorteile, da er einfach weniger Strom verbraucht und vom Bus versorgt werden kann.

[Masifi]

Ich verstehe das der ESP32 ein nettes Spielzeug hier ist. Aber ob man das wirklich alles braucht und den Zeitaufwand rechtfertigt, Tasmota mit OpenKNX zu verbinden, nur damit man Zählerwerte im Sekundenbereich abfragen kann, ich weiß nicht. Um Monatsverbräuche und Jahresverbräuche anzuzeigen gibt es doch bessere Lösungen (Influx-DB, Grafana, ...) Wobei man die Notwendigkeit alle 1-2sek einen Wert abzufragen, schon mal infrage stellen müsste :-)

Klar ist es nicht so toll das direkt über KNX zu machen, daher habe ich auch eine 2TE Einheit mit einem RP2040 und RJ45 ETH Anbindung. Aber auch hier stellt sich die Frage, lohnt der Aufwand hier was umzusetzen?

Ein Traum wäre schon von mir, wenn mein Modbus RTU Gateway über die ETH Schnittstelle, die Messwerte direkt über ETH in die InfluxDB zu schreiben (oder über einen Umweg MQTT-Influx-DB). Die KNX Schnittstelle, kann dann für Logiken verwendet werden. PV Eingangsleistung >xxW, dann mache XY.