OpenKNX-Logikmodul release

[thilog]

Moin,

erstmal danke für das Logikmodul. Ich habe es gestern auf Basis des OpenKNX PiPico-BCU-Connector mit VPM-Modul in Betrieb genommen. An einer Stelle hänge ich jedoch: Ich würde gerne eine Tagesphase generieren, um sie u.a. im VPM zu nutzen. Vorgesehen sind drei Szenen: Tag (Szene 1), Abend (Szene 2) und Nacht (Szene 3). Idee war, dafür drei Zeitschaltuhren zu verwenden, je eine pro Tagesphase. Bei EIN sendet sie die passende Szene, bei AUS passiert nichts. Hier ein Auszug aus der Parametrierung:


image.png

image.png

image.png

Dummerweise kann ich nicht feststellen, dass das KO gesendet wird, auch ein Read-Request auf der GA wird nicht beantwortet.

Sende ich "l10" an das Debug-KO erhalte ich als Ergebnis "Ax Bx Cx Dx Qx".

Ideen? Was mache ich falsch?

Danke & viele Grüße
Thilo

[mumpf]

Hi, ab sofort gibt es eine neue Version 0.12.3 mit reinen Bugfixes:

• FIX: Treppenlicht konnte erst über KNX wieder abgeschaltet werden, sobald das Logikmodul länger lief als die eingestellte Treppenlichtzeit.
• FIX: "Einschaltverzögerung -> beim 2. EIN sofort schalten" wurde auch erst geschaltet, wenn das Logikmodul länger lief als die eingestellte Verzögerungszeit.
• FIX: "Ausschaltverzögerung -> beim 2. AUS sofort schalten" wurde auch erst geschaltet, wenn das Logikmodul länger lief als die eingestellte Verzögerungszeit.
• FIX: Konvertierung von DPT 9 nach DPT != 9 war um Faktor 10 zu groß. 9.0 wurde auf 90 Konvertiert statt auf 9.

Es ist ein reines Firmware-Update, die ETS-Applikation muss nicht akualisiert werden.

Download-Links wie immer in ersten Beitrag in diesem Thread.

Gruß, Waldemar

[EPIX]

Danke für die Rückmeldung - ich dachte mir schon, dass es aufwändig ist....

Lösbar wäre es eventuell wenn man den Schaltuhren-Teil in ein eigenes Modul auslagert - also ein Standalone-Schaltuhr-Modul, da wäre dann das Platzproblem gelöst.

Von "außen" müsste man halt die gewünschte Zeit als Zeit-DP10 an das jeweilige KO senden, das Verhalten definiert (Ein, AUs, Szene,...) definiert man über die ETS und braucht zur Laufzeit ja nicht geändert werden.

Mir gefällt euer Ansatz der getrennten Geräte auf einer "Einheits-Platform" sehr gut und ich würde bei Gelegenheit gerne noch ein paar bestückte Sensormodule beziehen. Für das feine Löten sehe ich mittlerweile einfach nicht mehr gut genug
(...aber das ist eine andere Geschichte)
Aber wie eingangs geschrieben: es war nur eine Anregung...

[mumpf]

Tja... einerseits nicht abwegig, andererseits leider kein "easy win". Die Logik kann noch kein DPT10 und DPT11 verarbeiten und ich wüsste nicht, wie man menschenwürdig die Schaltzeiten adressiert und neue Schaltzeiten vergibt. Ich hab pro Kanal nur 2 Eingänge und leider kaum noch Platz in den Paramtern.
Ich sag mal so: Es kommt auf jeden Fall in die Sammlung meiner Sachen für die Zukunft und ich schaue mit bei der nächsten intenen Feature-Runde für die Logik (etwas im Januar) an, was man mit dem Logikmodul noch reißen kann. Ansonsten wird es irgendwann eines geben, dass nur auf dem RP2040 läuft, da hab ich dann mehr Speicher und mehr freiheiten, aber da reden wir von >2 Jahren!

Da man viele Schaltkanäle hat, kann man derzeit natürlich mehrere Zeitschaltuhren definieren und passend zur externen Situation über eine Logik nur die Schaltuhr zum Eingang durchschalten, die man gerade haben möchte. Das erlaubt zumindest einige Freiheitsgrade...

Gruß, Waldemar

[EPIX]

eine Anregung für das Logikmodul:
es wäre natürlich seeehr bequem, wenn man die Schaltzeiten im Betrieb ändern könnte ohne jedes Mal die ETS zu starten...
Dazu wäre ein KO für jede aktive Schaltuhr notwendig wo man die Schaltzeiten abfragen / setzen kann.


Alternativ könnte man über die Debug-KO die Schaltzeiten ändern.

Ich habe natürlich keine Ahnung wie aufwändig die Umsetzung ist, bzw ob das Ganze in die Grundidee des Logikmoduls passt - ist nur ein Gedanke...

[mumpf]

Also... PIO ist etwas schwierig, auch nach 2 Jahren verstehe ich immer noch nicht alles, was da passiert. Und zudem sind wir in OpenKNX auch noch auf der Suche nach der richtigen Projektstruktur, um sowohl unsere Entwicklung reibungslos zu gestalten wie auch andere möglichst reibungslos zu unterstützen. So weit sind wir aber noch nicht. Deswegen gibt es immer wieder Projektänderungen. Und die Doku ist nach einer Umstellung sicherlich nicht auf dem neusten Stand, sorry. Soweit zum Hintergrund.

Zu den Fehlermeldungen: In PIO gibt es immer nur ein Projekt, dessen Symbole analysiert und verfolgt werden. Im Logikmodul sind das alle Dateien, die im src-Verzeichnis liegen und alles, was im lib-Verzeichnis liegt. Auch wenn im lib-Verzeichnis nur Links auf die Projekte im Hauptverzeichnis stehen, ist es für PIO immer noch eine Datei mit ihrem kompletten Pfad, die Zählt.
Wenn Du also OpenKNX/OGM-Common/src/Helper.h anguckst, wirst Du Fehler gemeldet bekommen, weil es hier kein Projekt und keine gesetzten Pfade gibt.
Wenn Du auf die SELBE Datei über OpenKNX/OAM-LogicModule/lib/OGM-Common/src/Helper.h zugreifst, bekommst Du keine Fehler, weil das Projekt gültig ist und PIO weiß, wo es alles zu finden hat.
An welcher Datei was geändert wird, ist aber egal, da die ja verlinkt sind und somit wirklich die SELBE Datei sind.
Die Projekte liegen im Hauptverzeichnis, damit sie entsprechend in Git verwaltet werden können und in mehreren anderen Projekten verwendet werden können.

Und zu OGM-SensorDevices: Im Rahmen unserer Projektänderungen versuchen wir auch, die Projekte immer mehr zu kapseln und unabhängiger zu machen. Inzwischen benötigt das Logikmodul kein OGM-SensorDevices nicht mehr. Deswegen habe ich den Link entfernt.

Ich hoffe, so etwas Licht ins Dunkel gebracht zu haben.
Gruß, Waldemar

[wknx]

komplexe Projektstruktur, mit eigentständigen Projekten [...]. PlatformIO kann hier nicht immer automatisch alle include finden. Deswegen gibt es immer wieder rote Markierungen. Und der QuickFix kann da nicht helfen. IMO sollte aber das Logikmodu-Projekt keine roten Markierungen enthalten, Subprojekte schon.

Habe nun noch mal genauer hingeschaut. Sieht so aus als würde das Phänomen tatsächlich nur in den anderen Projekten (knx und OGM-Common) auftreten.

Das Logikmodul baut auch für SAMD und RP2040. Weiter habe ich den Prozess aber noch nicht ausprobiert.

Btw.: In der Dokumentation war auch noch das Projekt OGM-SensorDevices genannt, wobei das ja inzwischen auch keine formelle Abhängigkeit vom Logikmodul ist (anders heraum wahrscheinlich schon, könnte also in Gesamtbetrachtung doch wieder sinnvoll sein die gemeinsam im selben Verzeichnis liegen zu habe.)

[mumpf]

Ja, unsere Antworten haben sich überschnitten.

Wenn Synlinks nur mit Admin-Modus gehen, solltest Du den Developer-Mode (ja, den von Windows) einschalten. Die Anleitung im Wiki ist die aktuellste, die im Projekt werde ich ändern.

Wenn es baut, funktioniert alles. Wir haben eine sehr komplexe Projektstruktur, mit eigentständigen Projekten, die aber auch von anderen Projekten wiederverwendet werden können. PlatformIO kann hier nicht immer automatisch alle include finden. Deswegen gibt es immer wieder rote Markierungen. Und der QuickFix kann da nicht helfen. IMO sollte aber das Logikmodu-Projekt keine roten Markierungen enthalten, Subprojekte schon.

Das teilweise klemmen muss also noch eine andere Ursache haben.

Was meinst Du mit "teilweise klemmen"?

Gruß, Waldemar

[wknx]

Bist Du nach unserem Wiki https://github.com/OpenKNX/OpenKNX/w...atformIO-(PIO) vorgegangen? Der Screenshot ist wichtig, also das gelb hervorgehobene.

Nein, nach https://github.com/OpenKNX/OAM-Logic...O-dev-setup.md
Die Option hatte ich allerdings aktiviert. Dort wird übrigens auch noch das Projekt OGM-SensorDevices mit gecloned, was zumindest vom Logik-Modul nicht benötigt wird.
Vielleicht hat sich Deine Prüfung mit meinem Update überschnitten: Mit Admin-Rechten funktionierte das Clonen inklusive Symlinks.

Das teilweise klemmen muss also noch eine andere Ursache haben.

Und Du musst den Developer Mode eingeschaltet haben

Von Windows?

[mumpf]

Ja, nach 0.11 hat sich das Build-System verändert, es sind die Symlinks dazugekommen und einige Files weggefallen (was aber gut ist, weil es für weitere Entkopplung von Modulen gesorgt hat).

Bei git ging es nicht um den aktuellsten Client sondern um die symlink-Unterstützung, die man gleich beim installieren angeben muss. Bist Du nach unserem Wiki https://github.com/OpenKNX/OpenKNX/w...atformIO-(PIO) vorgegangen? Der Screenshot ist wichtig, also das gelb hervorgehobene.

Ich habe es soeben nochmal in einem komplett neuen Verzeichnis probiert, clone hat mit Links geklappt. Und bauen auch.
Du musst in der Reihenfolge clonen, die anegeben ist.

Falls das clonen mit symlinks nicht klappt UND Du sicher bist, die symlink-Unterstützung bei der Installation eingeschaltet zu haben, dann mach noch ein

git config core.symlinks

genau in dem Verzeichnis, in dem Du git clone startest. Sollte das false zurückkommen, hast du wahrscheinlich für Deinen user symlinks ausgeschaltet (dann mit git config --user core.symlinks true wieder erlauben).

Und Du musst den Developer Mode eingeschaltet haben, sonst musst Du immer alle git Befehle in der Admin-Console ausführen (cmd, Command Prompt, Eingabeaufforderung).

Mehr fällt mir nicht ein, außer dass wir sonst mal im Laufe der Woche ne Online-Session machen müssten..

Gruß, Waldemar

[wknx]

Falls Du selber bauen willst, musst Du bitte auch noch auf den Merge warten.

Wollte ich mal testen. Zwischendurch lief es auch schon mal durch der Build (AFAIR mit der 0.11), jetzt aber nicht mehr. Scheitert immer an Includes. (Beginnend mit Helper.h) Hatte zwischenzeitlich es schon mal mit QuickFixes über die Config versucht, wobei das für mich vollkommen intransparent ist wo VSCode dann etwas an der Konfiguration ändert.
Die libs musste ich übrigens von Hand nachbiegen. Das war die Stelle an der es beim gescheitert war bevor es dann zwischendurch funktionierte. Mit den Symlinks hat es bei mir auch mit Update von git auf neusten Stand und setzen als Standard-Config nicht funktioniert. Fehlermeldung beim Check-Out gibt es allerdings keine.

Irgendwelche Vorschläge was ich probieren sollte?

UPDATE:

Nach erneutem Checkout funktioniert es nun erst mal.
Mit Admin-Rechten werden auch die Symlinks korrekt erstellt.
Kompiliert nun auch, aber im Editor bekomme ich weiterhin teilweise die Meldung zu angeblich nicht gefundenen Includes.

[mumpf]

So, habe jetzt noch ein 0.12.1-Beta nachgeschoben, jetzt hoffentlich mit den korrekten Ständen. Ich möchte nochmal betonen: Funktional hat sich nichts geändert, wer 0.12 hat, muss kein Upgrade auf 0.12.1 machen.

Gruß, Waldemar

[mumpf]

Ist das wirklich der aktuelle Stand?

Jein... Die Firmware und die ETS-Applikation haben den aktuellsten Stand. Allerdings hab ich den Merge mit dem main-Branch vergessen, so dass github das Label 0.12 auf einen falschen Stand vergeben hat.

Danke für den Hinweis. Ich werde dann noch ein 0.12.1-Beta mit den passenden Ständen machen, wird aber erst morgen was.

Du kannst die ETS-Applikation und die Firmware bereits verwenden, die Applikaitonsbeschreibung ist im "new-include" Branch (der ist noch nicht gemerged): https://github.com/OpenKNX/OAM-Logic...ibung-Logik.md. Falls Du selber bauen willst, musst Du bitte auch noch auf den Merge warten.

Und ich muss nochmal in mich gehen, um den Release-Prozess zu automatisieren.

Gruß, Waldemar

[wknx]

ab sofort gibt es ein neues 0.12-Beta auf Github: https://github.com/OpenKNX/OAM-Logic.../tag/0.12-Beta
Die Applikationsbeschreibung ist auch aktualisiert: https://github.com/OpenKNX/OAM-Logic...ibung-Logik.md

Ist das wirklich der aktuelle Stand? Der Tag 0.12-Beta verweist auf einen Stand von Sonntag (genau wie der Code im Git-Repo), die Applikationsbeschreibung hat auch noch nicht alle Änderungen mit drin.

[mumpf]

Hmm, also auch auf dem SAMD. Darauf hab ich auch getestet mit meinen ursprünglichen 400ms, jetzt 40 ms, allerdings mit nur 16 belegten Kanälen. Dass 25 Kanäle 1 Sekunde dauern sollten, finde ich verwunderlich. Bei 80 Kanälen vielleicht, aber als ich früher mal den Durchsatz gemessen habe, bin ich nicht über 300 ms Processing über alle Kanäle gekommen. Bei 80 belegten Kanälen.

Vielleicht ist das schon relativ viel?

Nein, das sollte nicht sein.

würde die Verzögerung nach meinem bislang nur groben Verständnis der Implementierung vom Umfang der erforderlichen Verarbeitungsschritte abhängen.

Prinzipiell hast Du recht. An sich tun aber die Kanäle meistens gar nichts. Und selbst wenn viele Kanäle gleichzeitig was tun müssen, ist das so programmiert, dass ein Kanal aus vielen Teilschritten aufgebaut ist (Eingangskonverter, Logikfunktion, Treppenlicht, Ein-/Ausschaltverzögerung, Ausgangsfilter, Ausgangskonverter), die quasi-parallel verarbeitet werden, indem sie Rechenzeit an parallel laufende Kanalfunktionen abgeben. Deswegen verstehe ich eine so große Verzögerung nicht.

Jetzt ist der Fix +1000 drin, den solltest Du mit Deiner Hardware nutzen können. Einmal die 25 Kanäle manuell übertragen ist zwar blöd (sorry für die 0.10), aber in Zukunft wird das nicht nötig sein. Ich hab in meinem Haus inzwischen bestimmt 200 Logikkanäle aktiv (auf verschiedene Module verteilt), die will ich nicht neu machen müssen. Deswegen ist es auch in mienem Interesse, das kompatibel zu halten.

Dazu braucht es z.B. auch die Flankenerkennung.

Meiner Meinung nach braucht man das in KNX immer, ich bin eigenlich stolz drauf, dass ich recht viele Varianten unterstütze. Das Du gleich am Anfang einen Bug gefunden hast, tut mir leid. Wobei nicht so wirklich, denn so hab ich ein Feedback bekommen und konnte das fixen.

Gruß, Waldemar