OpenKNX-Steuerung für dezentrale Lüftungsanlage

[csknx]

Ich hatte heute endlich mal wieder etwas Zeit an dem Code weiterzuarbeiten. Dabei sind die folgenden Änderungen eingeflossen:
- Ausgabe der KO mit ShowInComObjectTree="true"
- Hinzufügen der Kontext-Hilfe
- Anpassung der Indent-Level in der ETS
- Implementierung der Status-LED
- Getrennt einstellbare Lüftungsmodi für den manuellen und automatischen Betrieb (z.B. WRG im manuellen bzw. Dauerbetrieb und Abluft im Automatikbetrieb, also wenn die Luftfeuchtigkeit zu hoch ist)

Damit sind fast alle Punkte deines Reviews integriert. Allerdings hänge ich wieder daran, dass es für die XML kaum eine Dokumentation gibt. Daher habe ich noch folgende offene Fragen:
- Wie errechnet sich die "SizeInBit" eines Union? Ich habe in den anderen OpenKNX Repos oft gesehen, dass die SizeInBit der Unions kleiner oder größer als der eigentliche Inhalt angegeben ist (wobei ich größer noch verstehen könnte)
- Ich würde gerne die KO umsortieren. Nach was richtet sich die Reihenfolge in der ETS (ComObject, ComObjectRef, ComObjectRefRef oder Number)?
- Was muss ich ändern um die KO umzusortieren, aber nicht alles zu zerschießen (wie oben in dem Kommentar erwähnt)
- Wie errechnet sich der Offset in "<Memory CodeSegment="%AID%_RS-04-00000" Offset="53" BitOffset="0" />"? Inbesondere wenn ich Parameter sowohl in share, als auch in template-Teilen des XML habe? Auch hier habe ich teilweise gesehen, dass der Offset in manchen Projekten immer konstant bleibt, auch wenn mehrere Parameter nacheinander definiert werden.

[coko]

csknx :-)

- Wie errechnet sich die "SizeInBit" eines Union? Ich habe in den anderen OpenKNX Repos oft gesehen, dass die SizeInBit der Unions kleiner oder größer als der eigentliche Inhalt angegeben ist (wobei ich größer noch verstehen könnte)

Kleiner ist ein Fehler, wobei dieser nicht zwingend sichtbar werden muss (z.B. wenn hinter dem Union genügend Leerraum ist). Der OpenKNXproducer ab der kürzlich veröffentlichten Version 4.0 meldet das inzwischen auch. Wird daher in den nächsten Modul Releases gefixt sein.
Die Größe des Unions muss so groß, dass alle enthaltenen Parameter darin Platz finden (Maximum Offset + Größe des Parametertyps)

- Ich würde gerne die KO umsortieren. Nach was richtet sich die Reihenfolge in der ETS (ComObject, ComObjectRef, ComObjectRefRef oder Number)?

Ib dee Baunansicht: Reihenfolge der Einbindung der ComObjectRefRef.

- Wie errechnet sich der Offset in "<Memory CodeSegment="%AID%_RS-04-00000" Offset="53" BitOffset="0" />"? Inbesondere wenn ich Parameter sowohl in share, als auch in template-Teilen des XML habe? Auch hier habe ich teilweise gesehen, dass der Offset in manchen Projekten immer konstant bleibt, auch wenn mehrere Parameter nacheinander definiert werden.

Die Offsets in share und templ werden vom Producer als relative Offsets genutzt. Der Offset in der fertigen XML ergibt sich durch hintereinanderlegen der Module und enthaltenen Modul-Kanäle. Häng am Ende also von anderen Modulen und den Kanal-Anzahlen ab.

[coko]

csknx
Habe noch eine kurzen Blick auf Seine Änderungen geworfen und auf dieser Basis zwei weitere Hinweise:

• Die Hilfetexte solltest Du automatisch aus der einer zentralen Applikationsbeschreibung erzeugen. Damit hast Du gleichzeitig und konsistent Dokumentation außerhalb und innerhalb der ETS.
• Wenn Du Fixes durchführst die keine Änderung in der XML beinhalten, dann reicht es aus die Patch-Version zu erhöhen (Hinweis: Die Versionierung folgt nicht SemVer

[mumpf]

- Ich würde gerne die KO umsortieren. Nach was richtet sich die Reihenfolge in der ETS (ComObject, ComObjectRef, ComObjectRefRef oder Number)?

Um das noch zu ergänzen: coko hat nur die Darstellung im ComObjectTree beschrieben. In der globalen Liste der Kommunikationsobjekte werden diese nach KO-Nummer sortiert. Du kannst die Nummer ändern, darfst aber die ID des ComObjects nicht ändern. Dann bleibt die Applikation updatefähig.

Gruß, Waldemar

[coko]

csknx noch zur Ergänzung, hatte ich vergessen im letzten Posting:

• Aufs Markdown achten: Zeilenumbrüche werden in die Ausgabe übernommen. Hinter Überschriften muss eine Leerzeile folgen. Siehst Du in Deinem Fall z.B. bei der Luftfeuchtemessung

Gut lesbar ist z.B. die Nutzung von Aufzählungen

* **Option:** Beschreibung

[cad435]

Oh, das ist cool. Ich hab heute die dezentralen Lüfter für meine Bude bekommen, da werkelt ein ebmpapst 8315100290 (AxiRev126 VWS0112EUGAZ). Ich such quasi genau das Teil das du gebaut hast.

image.png

Ich muss mir gleich mal eben deine HW ansehen, aber ich glaub da hast du zumindestens für die applikation schon mal einen Tester gefunden

Kannst du in deiner Applikation den PWM-Nullpunkt einstellen? dieser lüfter hier ist bei PWM=0% Maximal Drehrichtung A, bei PWM=50% "still" und bei PWM=100% Maximal Drehrichtung B.

Edit: was mir bei der Hardware noch unklar ist, was macht der SN74 Buffer? Einfach nur die RP2040 pins schützen? für meine Lüfter bräuchte ich sowieso open-collector ausgänge. das heißt ich müsste die HW dann wohl eh anpassen..

[csknx]

Hi cad435 ,

Auch mein Lüfter hat den Nullpunkt bei 50% und die gleiche Steuerungslogik wie dein ebm-papst. Mein Lüfter hat werkseitig 5 Stufen in jede Richtung, wobei ich vermute, dass mein Lüfter auch mit einer linearen Charakteritik wie in deinem Bild angesteuert werden kann. Wenn ich mich richtig erinnere ist nur die PWM Frequenz bei meinem 10kHz statt 2kHz, aber das kann man leicht im Quellcode anpassen. Der SN74 Buffer ist für die Konvertierung von 3.3V nach 5V. Ich glaube der Lüfter könnte theoretisch auch mit 3.3V angesteuert werden. Ich wollte es allerdings genau so implementieren, wie es auch der Hersteller gemacht hat. 5V sollten auch etwas robuster über die lange Leitung sein. Solltest du etwas an dem PCB Layout ändern wollen ist es auf jeden Fall wichtig, dass du die Freilaufdiode drinnen lässt (induktive Last), sonst crashed es den RP2040. Außerdem ist der RC-Filter wichtig, da du sonst sehr leicht cross-talk über die lange Leitung bekommst.
Jetzt weißt du auch, warum auf meinem PCB "V2" steht

Aus Interesse: Was ist das für eine Lüftungsanlage?

[csknx]

Die Hilfetexte solltest Du automatisch aus der einer zentralen Applikationsbeschreibung erzeugen. Damit hast Du gleichzeitig und konsistent Dokumentation außerhalb und innerhalb der ETS.

Wir wird denn der Link zwischen den erzeugten Dateien in Baggages und dem %DOC% in <ParameterRefRef RefId="%AID%_UP-%TT%00009_R-%TT%0000901" IndentLevel="1" HelpContext="%DOC%" /> hergestellt?

[coko]

Wir wird denn der Link zwischen den erzeugten Dateien in Baggages und dem %DOC% in [...] hergestellt?

Das ist schon der zweite Schritt. Damit wird "nur" der Dateiname automatisch aus dem zugehörigen Beschriftungstext erzeugt.

Zur Erzeugung der Einzeldateien aus der Applikationsbeschreibung siehe https://github.com/OpenKNX/OpenKNXpr...hilfe-baggages

[cad435]

Aus Interesse: Was ist das für eine Lüftungsanlage?

Ich verbau Fawas AirSolitaire 160 (irgendwann 2026, momentan steht grad mal der Keller )

Der SN74 Buffer ist für die Konvertierung von 3.3V nach 5V. Ich glaube der Lüfter könnte theoretisch auch mit 3.3V angesteuert werden.

Ich lehne mich mal ganz weit aus dem Fenster und behaupte, dass dein lüfter genau wie meiner einen OpenDrain Ausgang benötigt und intern einfach einen Pull-Up auf 5V verbaut hat Zumindest wären mir ausnahmslos Lüfter bekannt die dieses Prinzip benutzen. PushPull Input bei lüfter hätte ich noch nie gesehen.

Schraub mal die PWM Input Litze deines Lüfters raus, schalt die Versorgungsspannung und miss mal den PWM Eingang wärend der Lüfter läuft. Ich würde vermuten da wirst du auch die 5V über den integrierten PullUp messen.
Aber kann mich auch täuschen, nur weil mir das noch nicht untergekommen ist muss ja nicht heißen, dass es das nicht gibt

Wenn ich mich richtig erinnere ist nur die PWM Frequenz bei meinem 10kHz statt 2kHz, aber das kann man leicht im Quellcode anpassen.

PWM Frequenz parametrierbar in der ETS? Wär schon cool
Wenn du den verbauten Lüfter raus finden kannst, dann könntest du auch die Frquenz-Range rausfinden. Auch hier kenn ich das eigentlich immer so, dass eine range angegeben ist (Herstellerübergreifend, nicht nur beim Papst). Bei meinem Papst Lüfter beispielsweise von 1khz bis 5khz. Niedrigere Frequenzen sind weniger anfällig für Signalstörungen.

ist es auf jeden Fall wichtig, dass du die Freilaufdiode drinnen lässt (induktive Last)

Hmmm, induktive Last sollte das eigentlich nicht sein...
Freilaufdioden sind nie verkehrt, aber die BLCD Treiber in den lüftern sollten sich eigentlich eher kapazitiv verhalten, da du von aussen mehr den Eingangs-C der Treiberstufe siehst und den Motor direkt eigentlich nicht...

Müsst ich direkt mal messen wie sich meine Lüfter verhalten



Hardware mäßig glaube ich werde ich das REG1-Konzept versuchen. Pro lüfter eine 4-Polige Klemme, dann wäre auch das Tacho-Signal mit drin und man könnte pro REG1 2 Lüfter unterbringen, oben und unten einen.