OpenKNX und ESP-Home

[henfri]

Hallo,

folgendes habe ich in einem anderen Thread schon geschrieben, aber ich denke, da ging es unter:

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

[Masifi]

Macht das nicht nur Sinn wenn man den RP2040 PICO-W nutzt?

[henfri]

Hi Masifi,

warum? Ein Web-Interface wird standardmäßig nicht benötigt und die Kommunikation kann ja statt über MQTT dann über KNX laufen.

Gruß,
Hendrik

[Masifi]

Und wie hilft dann ESP-Home?

[henfri]

Indem man eine einfache YAML erstellt, kann man eine Firmware bauen die fast jeden denkbaren Sensor unterstützt.

Man benötigt "nur" in esphome ein output-modul ähnlich dem mqtt modul, welches jedoch KNX spricht. In der o.g. YAML würde man die Sensoren und KOs definieren. In der ETS die Zuordnung zur GA.
Das KNX-Modul würde also die Daten vom Sensor annehmen und per KNX an die konfigurierte GA senden.

Gruß,
Hendrik

[STSC]

ESPHome ist stark für Home Assistant ausgelegt. Wenn man Openhab verwendet wird es schon schwierig. Da ist Tasmota einfach offener. Was YAML in ESPHome ist, ist die Scripting Language bzw. Berry in Tasmota.

[henfri]

Hallo,

ESPHome ist stark für Home Assistant ausgelegt. Wenn man Openhab verwendet wird es schon schwierig.

Das wäre ja hier überhaupt nicht relevant, da man KNX verwendet.

Was YAML in ESPHome ist, ist die Scripting Language bzw. Berry in Tasmota.

Na im ersten Schritt wird YAML ja verwendet, um die Sensoren zu definieren - nicht für Skripte.

[STSC]

Ich denke ich verstehe jetzt deinen Ansatz. Leider kenne ich ESPHome nicht. Wenn ich es richtig sehe hat ESPHome überhaupt keine GUI, da ja alles per YAML konfiguriert wird. Deshalb hast du auch geschrieben, man braucht kein WLAN.

Aber warum würdest du dann die Sensoren bzw. KOs in YAML definieren, das geht doch per ETS viel bequemer?

[Masifi]

Ich glaube aber, das es für die meisten Sensoren es schon fertige Libs unabhängig von ESPHome gibt. Interessant wird es hier wie bei dem Tasmota Thema auch, für nur ein paar spezielle Themen und daher auch hier die Frage, ob sich das alles dann noch lohnt?

[henfri]

Hallo,

erstmal hat man ja einen nackten Microcontroller. Der weiß nicht, welchen Sensor er überhaupt und wo angeschlossen hat.
Das macht man über die yaml - das ist heute in ESPHome schon so.
Heute werden die Sensordaten dann per MQTT verschickt. Das wollen wir durch KNX ersetzen.
Dazu braucht die Firmware die Information, welchen DPT eine Information von einem Sensor hat. Dann wird ein entsprechendes KO erstellt. Das wird in der YAML auch definiert (neu).
Die gleiche YAML fungiert dann als Input für den KNXProd-Generator.

So der Gedanke.

Man könnte natürlich auch eine allgemeine KNXProd erstellen. Aber die müsste man dann ja bei jedem neuen Sensor, welches von ESPHome neu unterstützt wird neu erstellen. Ginge auch, aber ist natürlich erstmal viel Aufwand. Wenn man es so macht wie oben vorgeschlagen, entsteht die Arbeit erst wenn jemand den jeweiligen Sensor auch nutzen möchte.

Für den BME680 würde die erweiterte YAML so aussehen:

sensor:
  - platform: bme680
    temperature:
      name: "BME680 Temperature"
      oversampling: 16x
    pressure:
      name: "BME680 Pressure"
      knx_dpt: 5
    humidity:
      name: "BME680 Humidity"
      knx_dpt: 5
    gas_resistance:
      name: "BME680 Gas Resistance"
    address: 0x77
    update_interval: 60s

In einem zweiten Schritt könnte man natürlich die Parameter (16x, 60s) per ETS konfigurierbar machen.

Gruß,
Hendrik

[henfri]

Ich glaube aber, das es für die meisten Sensoren es schon fertige Libs unabhängig von ESPHome gibt.

Das glaube ich auch. Ich glaube sogar, dass ESPHome diese benutzt. Darum geht es mir aber gar nicht.

Wenn wir mal gucken, wieviel Aufwand es ist eine OpenKNX-Firmware für einen BME680 zu erstellen
https://github.com/thelsing/knx/blob...knx-bme680.ino
https://github.com/thelsing/knx/blob...680/bme680.xml

Und wieviel Aufwand es ist eine Firmware mit BME680 und BH1750 zu erstellen.
Und wieviel Aufwand usw.

Der Code hierfür wird aber hier schon hier gepflegt.
https://github.com/esphome/esphome/t...ts/bme680_bsec
Es ist ja nicht nur die Lib für den Sensor, sondern auch das nutzen des Sensors (Abfrage-Intervall, Mitteln, ...).

Um jetzt *all* diese Sensoren für OpenKNX verfügbar zu machen, bräuchte es "nur" eine knx_sensor.cpp und .h, analog zu:
https://github.com/esphome/esphome/b...qtt_sensor.cpp


Gruß,
Hendrik

[thesing]

Prinzipiell ist es das gleiche Prinzip wie bei meinem knx-Plugin für SmarthomeNG: Die Items mit DPT werden gesammelt und pro Item wird ein KO angelegt und als xml gespeichert. Aus der kann man dann eine knxprod machen.

[henfri]

Hallo,

ja genau.
Und so hätte man die ganze Welt der esp-Home Sensoren in KNX - und müsste dafür als Anwender lediglich eine yaml schreiben.

Gruß,
Hendrik

[Ing-Dom]

ja an sich ist das eine nette Idee, macht sicher Sinn.

Nur hat es mit dem eigentlichen Ansatz von OpenKNX - die Entwicklung eigener Geräte, Hard- und Firmware - eigentlich nichts zu tun.

Ich spreche nur für mich, denke aber dass die anderen ähnlich denken - wir haben aktuell genug Baustellen um überhaupt erstmal unser OpenKNX "Framework" nenne ich es mal, zu entwickeln, standardiseren etc...

[henfri]

ja an sich ist das eine nette Idee, macht sicher Sinn.

Nur hat es mit dem eigentlichen Ansatz von OpenKNX - die Entwicklung eigener Geräte, Hard- und Firmware - eigentlich nichts zu tun.

Es wäre doch nur ein generisches Gerät. Ich sehe da keinen Widerspruch.

Ich spreche nur für mich, denke aber dass die anderen ähnlich denken - wir haben aktuell genug Baustellen um überhaupt erstmal unser OpenKNX "Framework" nenne ich es mal, zu entwickeln, standardiseren etc...

Dass es andere Prioritäten gibt, verstehe ich natürlich. Aber bevor hier das eine "ein-Sensor-Gerät" nach dem Anderen entwickelt wird, wäre der o.g. generische Ansatz sicherlich bedenkenswert.

Gruß,
Hendrik