OpenKNX-Steuerung für dezentrale Lüftungsanlage

[csknx]

Durch meinen manuellen Cut in den Repositories sind mir wohl die Namen durcheinander geraten. Jetzt sollten die Links wieder funktionieren (Achtung, Repo Name geändert). Zumindest hat es bei meinem Test gerade die korrekten Abhängigkeiten runtergeladen und der Producer läuft durch.

Das KoOffset habe ich auf 20 erhöht. Welchen Wert würdest du empfehlen?

Die OpenKNXId habe ich auf 0xAF geändert. Das die genau die Themen, bei denen ich mir noch nicht so sicher war. Auch die ApplicationNumber und OrderNumber sollten evtl. noch angepasst werden. Daher nehme ich gerne dein Angebot eines ausführlicheren Reviews an! Danke dir!

[Ing-Dom]

Ja, die Größe der Platine war durch die Klemmen vorgegeben, ansonsten hätte man es sicher kleiner machen können.

schau mal wieviel Platz auf einer REG1-App ist.. das sind 2x6 Klemmstellen mit 3.5mm Raster oder 2x8 Klemmstellen mit 2.5er Raster.

Unbenannt.jpg

aber nochmal, nur zur Sicherheit - dein Gerät ist toll so wie es ist, ich möchte nur für geneigte Mitleser in der Zukunft keine Missverständnisse aufkommen lassen was im REG1 möglich ist und was nicht.

[csknx]

Das sieht sehr interessant aus. Wie verschraubt man die Kabel dort? Von der Seite? D.h. müsste ich das Gerät ausbauen um die Kabel abzubekommen?

[jhaeberle]

Das finde ich auch ein sehr cooles Projekt! Dezentrale Lüftung und KNX ist leider völlig unterentwickelt!

Viel Erfolg! Gruß
Jochen

[MarcoLanghans]

csknx du Schraubst die Kabel in die Stecker zu den Buchsen und steckt diese dann einfach in das Gerät

https://www.phoenixcontact.com/de-de...-st-35-1840379

[Ing-Dom]

genau, Marco hat es ja schon erklärt. Diese steckbaren Leiterplattenklemmen haben zudem den großen Vorteil dass ein Gerät sehr schnell getauscht oder temporär ausgebaut ist (zB für FW-Update) und man dabei keine losen Leitungsenden im Verteiler hat..

[coko]

Das KoOffset habe ich auf 20 erhöht. Welchen Wert würdest du empfehlen?

20 ist hier gut, da Du keine anderen Module mit KOs verwendest. Die Offsets müssen so gewählt werden, die KOs verschiedener Module nicht kollidieren.
Jedes Modul kann kanalunabgänige KOs im Intervall [SingleKoOffset, SingleKoOffset+KOs_Anzahl_Shared[ und kanalspezfische KOs im Intervall [KoOffset, KoOffset + kanal_anzahl * KO_Anzahl_je_Kanal[ haben. Die dürfen sich alle nicht überlappen und auch nicht mit den ersten 20 KOs.

[coko]

Daher nehme ich gerne dein Angebot eines ausführlicheren Reviews an! Danke dir!

Dinge die mir da auffallen, erst mal in der ETS-Applikation (und ohne besondere Sortierung):

• Positiv kann man schon mal feststellen, dass ich erfolgreich einen Build der knxprod durchführen konnte. Spontan sind mir erst mal keine gravierenden offensichtlichen Probleme aufgefallen. Eher Detail-Hinweise zur Optimierung.
• Die Enum-Typen mit wenig Optionen kannst Du ruhig eine kleinere Größe als 8Bit wählen. Die Zugriffsmakros liefern dann mit Mask und Shift weiterhin direkt den passenden Wert. Die Parameter sollten allerdings keine Byte-Grenzen überschreiten, weil das der OpenKNX-Producer nicht unterstützt. Je häufiger ein Parameter verwendet wird, also insbesonder bei mehrfacher Verwendung innerhalb von Kanälen in hoher Anzahl vorhanden sind, destop relevanter wird das.
• Für die Parameter im Speicher ist i.d.R. langfristig praktischer diese gemeinsam in einem Union zu pflegen. Damit sind auch Überlappung von nicht gleichzeitig aktiven Parametern möglich.
• Bei den KOs fehlt das Attribut Text. Zu den Beschriftungskonventionen siehe https://github.com/OpenKNX/OpenKNX/w...gn-Richtlinien, oder aktuelle Module wie OFM-DFA, OFM-LogicModule, OFM-PresenseModule im v1dev-Branch
• Die ComObjectRefRefs solltest Du innerhalb eines ParamBlocks mit ShowInComObjectTree="true" ausgeben, damit erhältst Du eine weitere Anzeige-Ebene für die KOs innerhalb der ETS
• Die Reihenfolge der ComObjectRefRefs sollte der Reihenfolge der KO-Nummern entsprechen, ansonsten hast Du in der ETS inder Baum-Ansicht des Gerätes nicht die passende Ordnung
• Hat es einen besonderen Grund warum Du bei KOs und Params im Namen das Prefix "CH" verwendest?
• Text="Lüfter %C%: {{0:Lüfter %C%}}" - Duplikat ist da nicht schön. Besser {{0:...}} für Kanäle, ansonsten eine passende Standardbezeichnung
• Den Standardwert des Namensparameters solltest Du leer lassen. Kanal-Spezifische Parameter-Defauls solltest Du möglichst vermeiden, weil damit Einschränkenungen bei der Nutzung vom Konfigurationstransfer einhergehen.
• Ich empfehle die Definitionen von Parametern und KOs so zu formatieren, dass die gleichen Attribute in Spalten ausgerichtet sind. Das macht es übersichtlicher und leichter Abweichungen zu erkennen.
• Das Konfigurationsabhängige Aktivieren (Einblenden) von Parametern kannst Du vereinfachen: Ein Choose kann mehrere gleichzeitigt aktive Whens haben, von denen alle mit passender Bedingung eingeblendet werden
• Du könntest mal unter https://pictogrammers.com/library/mdi/ nach einem passenden Icon schauen. Sollte natürlich auch eindeutig sein.
• Parameter kannst Du in der ETS über das Attribut IndentLevel einrücken. Damit lassen sich Abhängigkeiten zwischen den Parametern deutlich machen und ein einheitliches UI realisieren. Schaue am besten mal die Verschiedenen Module im Raumcontroller an um ein Gefühl dafür zu bekommen.
• Für Prozent-Werte, oder allgemein Werte mit Einheit, kannst Du SuffixText nutzten
• Mehrzeilige Parameter-Beschriftungen würde ich versuchen zu vermeiden. Braucht aber erfahrungsgemäß einige Iterationen bis man insgesamt schöne Parameter-Bezeichnungen hat
• Beim Parameter Laufzeitauswahl ist für mich nicht sofort erkennbar was dieser bewirkt. Wird der Lüfter nach dieser Zeit immer abgeschaltet? Ich rege auch an, hier eine freie Zeitkonfiguration zu erlauben.
• Kontext-Hilfe wäre natürlich auch nett

Modul-Name und Modul-Prefix werde ich noch mal intern zur Diskussion stellen. Prefix ist bislang nicht belegt, bei generischen Bezeichnungen ist es aber immer besser da noch mal kritisch drüber zu schauen damit die Bezeichnung langfristig eindeutig nachvollziehbar bleibt. AppID schauen ist dann auch ein Thema für später.

[Ing-Dom]

Dinge die mir da auffallen, erst mal in der ETS-Applikation (und ohne besondere Sortierung):

jetzt verschreck' ihn doch nicht gleich,
Der nimmt doch Reißaus bei der Liste

[traxanos]

Er hat doch um ein Review gebeten und er muss ja auch nicht alles machen. Außerdem hat ja schon was funktionierendes Da sind dann kleine Optimierungen nicht mehr abschreckend Anders Rum wäre es viel schlimmer

csknx aber falls du hilfe brauchst oder was nicht verstehst, helfen wir dir gerne. auf wunsch auch gerne mal ein einer online konferenz falls dir das hilft. wir sind alles hilfsbereichte leute.

[csknx]

Perfekt, vielen Dank für das ausführliche Review! Ich denke das kann auch anderen Mitlesern hier helfen, die in ähnlicher Mission unterwegs sind. Wenn ich mal etwas Zeit finden im Laufe der Woche baue ich das Feedback noch ein.

[coko]

vielen Dank für das ausführliche Review! [...] Wenn ich mal etwas Zeit finden im Laufe der Woche baue ich das Feedback noch ein.

Sehr gerne. Freut mich, dass Du das als so nützlich empfindest. Für Fragen einfach melden, dann unterstützen wir. Kann dann auch aufs (Zwischen-)Ergebnis noch mal drauf schauen; wobei das tendenziell einfacher nachvollziehbar ist wenn Du nicht alle Änderungen in einem riesengroßen Commit abbildest. Danach gibt es dann auch noch mal ein Review zum Firmware-Teil ;-)

[csknx]

Für die Firmware habe ich noch einige Punkte auf der ToDo-Liste:

- Senden des Status nach Boot
- Wiederherstellen des Zustands nach Stromausfall
- Einstellen der Status-LED (z.B. dauerhaft leuchten bei Betrieb)
- Umstellung des Lüftungsmodus im Automatikbetrieb
- Einstellen der adaptiven Lüftungsgeschwindigkeit
- Unterstützung des PP45 Lüfters
- Doku
- …

Ich muss nur die Zeit finden

[csknx]

So, ein paar Dinge konnte ich heute Abend umsetzen, der Rest steht noch aus. Hier ein kleines Statusupdate:

• Positiv kann man schon mal feststellen, dass ich erfolgreich einen Build der knxprod durchführen konnte. Spontan sind mir erst mal keine gravierenden offensichtlichen Probleme aufgefallen. Eher Detail-Hinweise zur Optimierung.
• Die Enum-Typen mit wenig Optionen kannst Du ruhig eine kleinere Größe als 8Bit wählen. Die Zugriffsmakros liefern dann mit Mask und Shift weiterhin direkt den passenden Wert. Die Parameter sollten allerdings keine Byte-Grenzen überschreiten, weil das der OpenKNX-Producer nicht unterstützt. Je häufiger ein Parameter verwendet wird, also insbesonder bei mehrfacher Verwendung innerhalb von Kanälen in hoher Anzahl vorhanden sind, destop relevanter wird das. [Erledigt]
• Für die Parameter im Speicher ist i.d.R. langfristig praktischer diese gemeinsam in einem Union zu pflegen. Damit sind auch Überlappung von nicht gleichzeitig aktiven Parametern möglich. [hier brauche ich mehr Infos, nach welchen Kriterien werden welche Parameter zusammengefasst]
• Bei den KOs fehlt das Attribut Text. Zu den Beschriftungskonventionen siehe https://github.com/OpenKNX/OpenKNX/w...gn-Richtlinien, oder aktuelle Module wie OFM-DFA, OFM-LogicModule, OFM-PresenseModule im v1dev-Branch [brauche ich die bei den ComObjects zusätzlich zu den ComObjectRef's?, ansonsten Erledigt ]
• Die ComObjectRefRefs solltest Du innerhalb eines ParamBlocks mit ShowInComObjectTree="true" ausgeben, damit erhältst Du eine weitere Anzeige-Ebene für die KOs innerhalb der ETS [offen]
• Die Reihenfolge der ComObjectRefRefs sollte der Reihenfolge der KO-Nummern entsprechen, ansonsten hast Du in der ETS inder Baum-Ansicht des Gerätes nicht die passende Ordnung [Erledigt]
• Hat es einen besonderen Grund warum Du bei KOs und Params im Namen das Prefix "CH" verwendest? [das sah mir nach einer guten Konvention aus um globale von kanalspezifischen KOs/Params zu unterscheiden]
• Text="Lüfter %C%: {{0:Lüfter %C%}}" - Duplikat ist da nicht schön. Besser {{0:...}} für Kanäle, ansonsten eine passende Standardbezeichnung [Erledigt]
• Den Standardwert des Namensparameters solltest Du leer lassen. Kanal-Spezifische Parameter-Defauls solltest Du möglichst vermeiden, weil damit Einschränkenungen bei der Nutzung vom Konfigurationstransfer einhergehen. [Erledigt]
• Ich empfehle die Definitionen von Parametern und KOs so zu formatieren, dass die gleichen Attribute in Spalten ausgerichtet sind. Das macht es übersichtlicher und leichter Abweichungen zu erkennen. [das lässt sich nicht gut automatisch generieren, das werde ich wohl so lassen]
• Das Konfigurationsabhängige Aktivieren (Einblenden) von Parametern kannst Du vereinfachen: Ein Choose kann mehrere gleichzeitigt aktive Whens haben, von denen alle mit passender Bedingung eingeblendet werden [Erledigt]
• Du könntest mal unter https://pictogrammers.com/library/mdi/ nach einem passenden Icon schauen. Sollte natürlich auch eindeutig sein. [Erledigt]
• Parameter kannst Du in der ETS über das Attribut IndentLevel einrücken. Damit lassen sich Abhängigkeiten zwischen den Parametern deutlich machen und ein einheitliches UI realisieren. Schaue am besten mal die Verschiedenen Module im Raumcontroller an um ein Gefühl dafür zu bekommen. [offen]
• Für Prozent-Werte, oder allgemein Werte mit Einheit, kannst Du SuffixText nutzten [Erledigt]
• Mehrzeilige Parameter-Beschriftungen würde ich versuchen zu vermeiden. Braucht aber erfahrungsgemäß einige Iterationen bis man insgesamt schöne Parameter-Bezeichnungen hat [hier fällt mir tatsächlich bisher nichts besseres ein]
• Beim Parameter Laufzeitauswahl ist für mich nicht sofort erkennbar was dieser bewirkt. Wird der Lüfter nach dieser Zeit immer abgeschaltet? Ich rege auch an, hier eine freie Zeitkonfiguration zu erlauben. [offen, wird noch in der Doku ergänzt, damit kann man per KNX manuell einen Timer starten, der das Gerät nach der definierten Zeit ausstellt]
• Kontext-Hilfe wäre natürlich auch nett [offen]

[coko]

ein paar Dinge konnte ich heute Abend umsetzen, [...] Hier ein kleines Statusupdate:

Cool. Da hast Du ja schon eine ganze Menge umsetzen können.

Ich ergänze schon mal ein paar Antworten und Hinweise:

Die Enum-Typen mit wenig Optionen kannst Du ruhig eine kleinere Größe als 8Bit wählen. Die Zugriffsmakros liefern dann mit Mask und Shift weiterhin direkt den passenden Wert. Die Parameter sollten allerdings keine Byte-Grenzen überschreiten, weil das der OpenKNX-Producer nicht unterstützt. Je häufiger ein Parameter verwendet wird, also insbesonder bei mehrfacher Verwendung innerhalb von Kanälen in hoher Anzahl vorhanden sind, destop relevanter wird das. [Erledigt]

Reservern musst Du bei den Typen nicht einplanen. Du kannst die Typen auch später noch (ohne Datenverlust beim Update) vergrößern. Neben den Typen müsstest Du allerdings auch noch das Speicherlayout anpassen, ansonsten hast Du erst mal "nur" die 0-Werte an anderer Stelle. Das ist etwas was sich gut zusammen mit der Union-Einteilung realisieren lässt:

Für die Parameter [...] gemeinsam in einem Union zu pflegen. [...] [hier brauche ich mehr Infos, nach welchen Kriterien werden welche Parameter zusammengefasst]

In Deinem Fall hätte ich wahrscheinlich erst mal alle Parameter zusammen in ein Union geschoben. Das macht es später bei möglichem Anpassungsbedarf einfacher, weil Parameter in Unions anderes Ids verwenden. Wenn Du den Parts-Mechanismus im Producer verwendest, dann ergibt sich hier i.d.R. schon eine klare Einteilung. Unmittelbar nützlich wird das in Fällen in denen Du auf mehrere Parameter gleichzeitig zugreifen willst, wie z.B. beim BitFeld für die Feiertage im Logik-Modul. Da kannst Du bei Erweiterungen das Speicherlayout leichter anpassen. Ist zu einem gewissen Grad sicher auch Geschmachssache, hat sich allersings als Best-Practice im OpenKNX-Projekt bewährt.

Bei den KOs fehlt das Attribut Text. [brauche ich die bei den ComObjects zusätzlich zu den ComObjectRef's?, ansonsten Erledigt ]

Nein, wenn die in ComObjectRef Überschrieben werden, dann siehst Du den Text aus ComObjectRef (erst dort kannst Du mit den Platzhaltern arbeiten) sowieso nicht.

Die Reihenfolge der ComObjectRefRefs sollte der Reihenfolge der KO-Nummern entsprechen, ansonsten hast Du in der ETS inder Baum-Ansicht des Gerätes nicht die passende Ordnung [Erledigt]

Die Ids hättest Du deshalb nicht ändern müssen. Solltest Du später auch vermeiden. Insbesondere der Tausch von Ids würde beim Applikations-Update Probleme verursachen! Innerhalb des Update-Pfades sollten sich Ids niemals ändern, bzw. auch nicht wiederverwendet werden.

Hat es einen besonderen Grund warum Du bei KOs und Params im Namen das Prefix "CH" verwendest? [das sah mir nach einer guten Konvention aus um globale von kanalspezifischen KOs/Params zu unterscheiden]

KOs haben im Zugriffsmakro bereits ein KO enthalten. Der für parameter definierte Name wird auch in ConfigTransfer-Strings verwendet. Ich sofern bin ich ein Frund davon, dass die nicht unnötig lang werden. Verwende hier i.d.R. ein Präfix mit nur einem Zeichen passend zum Modul, das hatte ich von mumpf übernommen.

Ich empfehle die Definitionen von Parametern und KOs so zu formatieren, dass die gleichen Attribute in Spalten ausgerichtet sind. Das macht es übersichtlicher und leichter Abweichungen zu erkennen. [das lässt sich nicht gut automatisch generieren, das werde ich wohl so lassen]

Aus Neugier: Wie generierst Du die automatisch? Wenn die Einträge direkte untereinanderstehen, dann lässt sich das in VSCode recht einfach per Spalten-Markieren umsetzen.