[BETA] OpenKNX Dali Gateway - powered by REG1

[pbo]

thewhobox Du hattest in diesem Thread mal nach Rückmeldungen zur HCL Funktion gefragt. Ich habe Euer Gateway nun seit ein paar Monaten für das Küchenlicht im Testeinsatz (Aufputz in der Mietwohnung, der Rohbau vom Haus ist noch am entstehen). Die Konfiguration ist sehr intuitiv und von der Nutzerperspektive gedacht, das finde ich klasse!

Generell finde ich die HCL Implementierung schon sehr bequem, da die Orientierung nach Sonnenauf- und untergang ganz simpel ausgewählt werden kann. Inzwischen würde ich würde mir allerdings noch etwas mehr Konfigurationsmöglichkeiten wünschen. Gerade in der aktuellen Jahreszeit fällt mir auf, dass ich Abends die Helligkeitskurve gerne noch etwas mehr abflachen würde. Die Minimalhelligkeit soll dabei trotzdem so niedrig bleiben wie eingestellt, aber eben später erreicht werden, die Lichttemperatur kann dagegen der vorkonfigurierten Kurve folgen.

Was hältst Du von einer Konfigurationsmöglichkeit der Temperatur- und Helligkeitskurven ähnlich wie bei Ostara von Lumetix (vgl. Ostara Webinterface Präsentation, Slide 13)? Idealerweise umschaltbar mit absoluten Uhrzeiten oder dynamisch nach Sonnenauf und -untergang. Ich weiß nicht, ob sowas in der ETS möglich wäre oder ob sich die Weboberfläche dafür besser eignet.

Danke weiterhin für Eure überragende Arbeit an dem Projekt

[korpa]

SteffenRi arbeitet daran, die ganze HCL-Funktionalität in ein Function-Modul zu packen, damit das Dali-GW, der KNX-LED Controller von Andreas und weitere das nutzen können, ohne das Rad immer neu erfinden zu müssen. Damit wird dann deutlich mehr gehen als aktuell.
Ich weiß allerdings nicht, was der Stand da gerade ist. Es gibt aber immer wieder git commits von Steffen in dem Repo: https://github.com/OpenKNX/OFM-LightManager

[thewhobox]

pbo Wie Ostra wird garantiert nicht in der ETS für uns funktionieren. Im Webinterface würde ich das nicht sehen, sonst würde nur die neue Variante das verwenden können.
In der KNXprod war ja bereits ein Platzhalter für eine einfache Zeittabelle.
Ich habe es aber nie benötigt und deswegen nicht implementiert.

Den Stand vom OFM-LightManager kenne ich auch nicht.

[SteffenRi]

Damit wird dann deutlich mehr gehen als aktuell.Ich weiß allerdings nicht, was der Stand da gerade ist.

Die Idee: Die HCL-Logik wird aus den einzelnen Geräten herausgezogen und in ein eigenständiges Function-Modul gepackt. Es liefert nur Sollwerte für Farbtemperatur und Helligkeit. Die Ausgabe übernimmt das jeweilige Consumer-Modul, z. B. Hue Gateway, DALI-Gateway oder ein LED-Controller. So muss die Kurvenlogik nicht in jedem Gerät neu gebaut werden.

pbo, zu deinem Wunsch: Das geht grundsätzlich direkt in der ETS, ohne Webinterface:

• Die Kurve besteht aus bis zu 10 Stützpunkten je Profil, jeweils mit Uhrzeit, Farbtemperatur und Helligkeit. Dazwischen wird linear interpoliert.
• Jeder Stützpunkt kann an eine feste Uhrzeit oder relativ zu Sonnenaufgang, Sonnenuntergang, Dämmerung oder Sonnenhöchststand (± Offset) gebunden werden. Optional gibt es eine „nicht vor / nicht nach"-Uhrzeit.
• Deine Abendkurve lässt sich so bauen: Die Mindesthelligkeit bleibt gleich, wird aber über zusätzliche Stützpunkte später erreicht. Die Farbtemperatur folgt parallel ihrer eigenen Vorgabe.
• Zusätzlich gibt es mehrere Profile je Kanal, z. B. nach Wochentag, Sommer/Winter, Urlaub oder Feiertag. Dazu kommen Sperren, Tageslicht-Kompensation über einen Lux-Sensor und externe Vorgaben per KO.

pbo Wie Ostra wird garantiert nicht in der ETS für uns funktionieren. Im Webinterface würde ich das nicht sehen, sonst würde nur die neue Variante das verwenden können.

thewhobox Die Kurvenform selbst ist kein Problem. Das sind Polygonzüge aus Stützpunkten über der Uhrzeit, also genau das, was die Stützpunkttabelle abbildet. Der Unterschied ist die Punktzahl. Ostara zeigt dort etwa 12 Punkte bei der Farbtemperatur und etwa 15 bei der Helligkeit, jeweils unabhängig voneinander. Bei uns sind es maximal 10 Punkte, und jeder Punkt trägt beide Werte. Für eine alltagstaugliche Kurve reicht das, weil viele Punkte dort nur eng beieinander liegen, um Knicke zu formen. Eine exakte 1:1-Kopie ist es aber nicht. Statt Webinterface bleibt es bei einer Tabelle in der ETS, dafür funktioniert es für alle Varianten gleich.

Das LightManager Modul ist noch Beta. Im Hue Gateway (Beta Release in 1-2Wochen) wird es bereits als Quelle verwendet. Die Anbindung ans DALI-Gateway ist meines Wissens noch offen. Dort müsste das Gateway das Interface des Moduls einbinden. Das habe ich nicht selbst umgesetzt und kann dazu nichts versprechen.

[thewhobox]

Die Kurvenform selbst ist kein Problem.

Es ging nicht um die Kurvenform, sondern um das UI in der ETS. Dort werden wir nie so eine grafische Ansicht bieten können, da das die ETS einfach nicht hergibt.

Dort müsste das Gateway das Interface des Moduls einbinden. Das habe ich nicht selbst umgesetzt und kann dazu nichts versprechen.

Dass du das nicht machst ist klar, aber bisher war niemanden bekannt, welchen Status das HCL Modul hat. (was fehlt evtl, gibt es noch offene bugs, ist es überhaupt schon nutzbar, etc)
Das Dali GW selbst ist ja auch noch Beta, weil ich auf das HCL noch warte^^
Damit könnte ich viele Altlasten loswerden.

[pbo]

Ich habe ein Problem mit dem OpenKNX REG-1-LAN-DALI Gateway mit der Firmware 0.11.0. Mein aktuelles Setup läuft seit ein paar Monaten als Testinstallation. Bisher grundsolide. Sowohl mein KNX Testbrett als auch das EVG waren nun eine Woche lang stromlos. Nach dem Einschalten scheint das OpenKNX Modul nun allerdings ein Problem zu haben. Die DALI-Busstatus-LED leuchtet nicht mehr und folglich wird auch das EVG nicht mehr erkannt. Die Hardware und Verkabelung ist unverändert.

• Spannung des DALI Buses bis EVG bei ca. 15V
• Abstecken des EVGs, sodass nur die Spannungsversorgung und das OpenKNX Modul verbunden sind, bringt keine Verbesserung
• Erneutes Aufspielen der Firmware v0.11.0 via USB hat keine Verbesserung gebracht

Setup:

• DALI Spannungsversorgung: Lunatone PS 2
• DALI GW: OpenKNX REG1-LAN-TP-DALI mit 0.11.0
• EVG inkl. Netzteil: Lunatone 24V DALI-LED-Power-Supply DT8

Hat jemand eine Idee?

[Ing-Dom]

Hat jemand eine Idee?

1) reagiert das Gerät denn noch? Hat das drücken der Prog einen Effekt auf die LED? kannst du den Gerätestatus per ETS auslesen?
2) einmal KNX Parameter löschen (Prog taste beim Anstecken (KNX) so lange gedrückt halten bis die Prog LED blinkt.
3) flash nuke vor dem erneuten aufpielen der fw, dann per ets neu programmieren.
4) ein blick ins geräte schadet auch nie, falls es ein hw defekt sein sollte.

[thewhobox]

Die DALI-Busstatus-LED leuchtet nicht mehr und folglich wird auch das EVG nicht mehr erkannt.

Wenn sich sonst nix geändert hat und auch ein neu flashen nichts bringt, gehe ich eher von einem HW defekt aus.
Schau mal in das Webinterface vom Gateway und versuche dort direkt über die Konsole ein EVG zu steuern. (müsste dali set oder so sein, am besten die hilfe dazu auf der Konsole aufrufen)

[pbo]

Ing-Dom

1. Ja, die Prog LED leuchtet dann konstant. Auch beim booten blinkt diese wie zuvor. Es werden Telegramme versendet.
2. War mit dem Nuke zu schnell und habe diesen Schritt übersprungen.
3. `erase_flash` via esptool
4. Innen drin sieht es unspektakulär aus, also keine Auffälligkeiten.

Das Lunatone Netzteil liefert konstant 14,47V.

thewhobox Ich habe einen Scan via `scan 0000` durchgeführt: `Found 0 ballasts`

[Ing-Dom]

kannst du mit einem Multimeter - im Betrieb, incl. Dali und KNX - D1_Rx gegen Gnd messen?

[pbo]

Edit: Es war ein Wackelkontakt an einer der Lotstellen. Nun scheint das Modul zu laufen. Danke thewhobox und Ing-Dom !

[pbo]

Die Idee: Die HCL-Logik wird aus den einzelnen Geräten herausgezogen und in ein eigenständiges Function-Modul gepackt. Es liefert nur Sollwerte für Farbtemperatur und Helligkeit. Die Ausgabe übernimmt das jeweilige Consumer-Modul, z. B. Hue Gateway, DALI-Gateway oder ein LED-Controller. So muss die Kurvenlogik nicht in jedem Gerät neu gebaut werden.

pbo, zu deinem Wunsch: Das geht grundsätzlich direkt in der ETS, ohne Webinterface:

• Die Kurve besteht aus bis zu 10 Stützpunkten je Profil, jeweils mit Uhrzeit, Farbtemperatur und Helligkeit. Dazwischen wird linear interpoliert.
• Jeder Stützpunkt kann an eine feste Uhrzeit oder relativ zu Sonnenaufgang, Sonnenuntergang, Dämmerung oder Sonnenhöchststand (± Offset) gebunden werden. Optional gibt es eine „nicht vor / nicht nach"-Uhrzeit.
• Deine Abendkurve lässt sich so bauen: Die Mindesthelligkeit bleibt gleich, wird aber über zusätzliche Stützpunkte später erreicht. Die Farbtemperatur folgt parallel ihrer eigenen Vorgabe.
• Zusätzlich gibt es mehrere Profile je Kanal, z. B. nach Wochentag, Sommer/Winter, Urlaub oder Feiertag. Dazu kommen Sperren, Tageslicht-Kompensation über einen Lux-Sensor und externe Vorgaben per KO.

Das klingt super, SteffenRi – danke! Ich bin gespannt auf das nächste Release der GW Firmware :-)

[Ing-Dom]

Es war ein Wackelkontakt an einer der Lotstellen

Klassiker
Schön dass du es gefunden hast.

[Rakuri]

Hallo Zusammen,

Ich hab paar neue features eingebaut, die ich bei einem Dali Gateway vermisst habe.
Ich hatte Pull Request zum Projekt beigetragen die jedoch schon länger offen sind.
Denke das Projekt wird gerade nicht weiter entwickelt.

Ich habe auch nicht alles als PR übermittelt, da erstmal ein refactoring PR acceptet werden muss, bevor der rest drüber kann.
Oder man macht gleich alles ein Package.

Aufgrund eines anstehenden Refactoring-PRs machen weitere Einzel-PRs aktuell noch keinen Sinn.
Oder man führt das Ganze künftig direkt in einem eigenen Package zusammen, z.B. mit dem v12 branch (siehe unten).
Evtl. meldet sich ja der Main Entwickler und wir können es sauer überführen

Um euch nicht mit etlichen einzelnen PRs zu überlasten, findet ihr alles gesammelt hier:

https://github.com/rakuri255/OFM-Dali/tree/v12

https://github.com/rakuri255/GW-REG1...tree/virtualTW


Vendor bei Adressierung

Es wird nun der Hersteller des EVG ausgelesen und angezeigt. Mithilfe einer GTIN-Liste bekannter DALI-Hersteller lässt sich der Hersteller direkt in der Adressierungsübersicht darstellen. Das erleichtert das Hinzufügen neuer Geräte mit neuen Adressen enorm.


Screenshot 2026-10-15 234024.png

Geräteinformationen

Man kann weitere Hardware Informationen zum einzelnem EVG Gerät auslesen

Screenshot 2026-10-15 234249.png

Dimmingkurve

Man kann jetzt die Dimmkurve am EVG umstellen. Ob Logarithmisch oder Linear.


Screenshot 2026-10-15 234352.png


Virtual TunabkeWhite (2x DT6)

Es ist nun möglich, aus zwei DT6-EVGs ein virtuelles DT8-EVG zu erstellen, um beispielsweise eine TunableWhite-LEDs (z. B. für HCL-Steuerungen) anzusteuern.

Funktionsweise:

• Ein EVG wird als Master, das zweite als Slave konfiguriert.
• Die Bezeichnung „Slave“ dient hierbei lediglich der Symbolik und Dokumentation in der ETS.
• Die Kommunikation erfolgt vollständig über die Kommunikationsobjekte (KOs) des Masters, welche sich wie ein echtes DT8-EVG verhalten. Das Slave-EVG besitzt keine eigenen KOs.
• Achtung! Die Steuerung über Gruppen ist aktuell noch nicht implementiert (bisher kein Bedarf im Projekt).

Screenshot 2026-11-03 213524.png
Screenshot 2026-11-03 213613.png
Screenshot 2026-11-03 213642.png

[thewhobox]

Rakuri entschuldige, die PRs habe ich tatsächlich nicht mitbekommen.
Gerne hier kurz ankündigen oder direkt mich taggen bzw assignen.

Ich werde mir das die Tage anschauen.

Kurz vorab: ein 2xDT6 werde ich nicht mergen. Das habe ich bereits erleutert, dass das einfach veraltet ist und in der ETS nur schwierig wirlich gut darzustellen ist. Als nächstes kommt noch 4xDT6 für Rgbw dann wird es katastrophal ^^
Dein A2 scheint nur so benannt zu werden durch ein Assign? Das wird viele Support Fälle geben, in denen jemand das einfach überschrieben hat und sich wundert, warum das nicht funktioniert.