OpenKNX-Logikmodul release

[mumpf]

Freue mich auf den Fix.

Der Fix ist jetzt drin und ein erster Test sieht gut aus. Ich mach noch ein paar weitere Tests (morgen), aber es wird funktionieren.

Ich habe auch Deinen Vorschlag im Timer.cpp eingebaut und incrementiere jetzt um 1000. Das Verhalten ist wesentlich besser, auch hier danke für den Tipp. Jetzt ist die Verzögerung bei mir nur noch 40ms.
Und ja, ich könnte den Timer vom Controller nehmen, hab das bisher nicht angegangen, weil es so viele andere interessante Sachen zu entwickeln gibt. Und mit eine Sync über den Bus alle 10-15 Minuten merkt man nicht wirklich eine Verzögerung.

Danke für Deinen Input, ich sehe zu, bald ein neues Release zu machen.

Gruß, Waldemar

[mumpf]

wknx Nochmal ne Rückfrage: Auf was läuft den das Logikmodul bei Dir? Also welches Software/Hardware-Package? Sensormodul/EnoceanGateway/Standalone? Auf SAMD oder RP2040?

Letztendlich finde ich 1 Sekude Verzögerung pro Minute einfach zu viel, auch wenn ich wie bereits gesagt nicht wirklich darauf geachtet habe. Selbst meine 400ms fand ich schon zu viel, aber das ist auf dem ModbusGateway (kommt bald mit Logikmodul), da ist das Modbus-Timing, was dazwischenfunkt, da muss sowieso noch was optimiert werden.

Gruß, Waldemar

[jeff25]

Hi Waldemar,

könnte man das nicht auf 2 Kerne aufteuilen dann wäre das Problem gelöst....

Gruß
Robert

[mumpf]

könnte man das nicht auf 2 Kerne aufteuilen dann wäre das Problem gelöst....

Wenn man 2 Kerne hätte... das Logikmodul muss auch auf dem SAMD laufen können. Hier wäre der bessere Weg ganz klar, einen der internen Timer des Prozessors zu nehmen. Aber auch dafür muss man sich Zeit nehmen (die Sourcen sind verfügbar, es muss nicht immer ich sein).

Und mal ernsthaft, ich weigere mich, das als Problem zu sehen (auch wenn ich mir das grundsätzlich anschaue): Wir reden hier von Zeitschaltuhren, die Geräte im Haus steuern. Ob der Rollanden morgens um 07:05:00 oder um 07:05:01 aufgeht, ist vollkommen egal, selbst wenn es 07:06:04 werden sollte. Die alten mechanischen Zeitschaltuhren für die Steckdose hatten ein 15 Minuten-Raster...

An anderer Stelle finden man eine Zeitbasis von 1/10 Sekunden, was hier vielleicht einfach zu hohe Erwartungen weckt.

Dazu wollte ich auch was sagen: Die Zeitbasis von 1/10 Sekunden sagt nicht, dass die Uhren besonders genau laufen, sondern nur, dass man Verzögerungen bauen kann, die unter einer Sekunde ligen, was häufig hilft, wenn man Probleme mit Telegrammlaufzeiten hat.

[mumpf]

Ich hatte nun gerade zwischendurch die 0.10-Beta erwischt.

Noch eine Anmerkung, falls das (irgendjemandem) passiert, dass ein neues Release kein upgrade kann: Bitte meldet euch bei mir hier übers Forum. Ich achte sehr darauf, dass man bei meinen ETS-Applikationen einen upgrade machen kann und nicht nochmal alles neu parametrieren muss. Aber auch ich mache Fehler. Normalerweise kann ich sowas zeitnah korrigieren und dann geht ein Upgrade ohne Probleme.

Gruß, Waldemar

[mumpf]

Hi,

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

Auszug aus dem Changelog:

• NEU: Interne Ausgänge (als Quelle für die X- und Y-Eingänge eines Logikkanals) können jetzt neben EIN- und AUS-Werten auch nur EIN- oder nur AUS-Werte weiterleiten.
• NEU: Zu den mathematischen Funktionen, die Ausgangswerte berechnen können, ist jetzt die Funktion % (Modulo), also Rest-Division, hinzugekommen.
• NEU: Neben den mathematischen Funktionen, die Ausgangswerte berechnen können, sind jetzt auch Bitoperationen hinzugekommen. Es gibt jetzt
  • & (Bit-Und),
  • | (Bit-Oder),
  • ^ (Bit-Exklusiv-Oder),
  • << (Bit-Links-Verschiebung),
  • >> (Bit-Rechts-Verschiebung)
• FIX: Bei der Einstellung "Nur bei geändertem Ergebnis, aber erstes Telegramm immer senden" wurde das zweite Telegramm auch gesendet, wenn es gleich zum unterdrückten war. Das ist jetzt korrigiert.
• Die Zeitbasis für Zeitschaltuhren ist jetzt genauer, die Zeitschaltuhren driften jetzt weniger.

Bei den internen Ausgängen (also den rein booleschen internen Verknüpfungen) hab ich eine kleine Lücke geschlossen: Man kann jetzt bestimmen, ob der Ausgang nur EIN- oder AUS-Signale weiterleitet. Und natürlich auch beide Signale, wie bisher.

Die mathematischen Funktionen sind etwas erweitert worden, vor allem die Bitfunktionen erlauben jetzt neue Funktionalitäten.

Es gab eine Lücke, wenn erste Telegramme nicht gesendet werden. Die ist jetzt auch geschlossen, danke wknx für die Meldung. Ebenso danke ich Dir für die Idee, die Zeitbasis für die Zeitschaltuhren zu verbessern.

Viel Spaß mit dem Release,
Gruß, Waldemar

[wknx]

wknx Nochmal ne Rückfrage: Auf was läuft den das Logikmodul bei Dir? Also welches Software/Hardware-Package? Sensormodul/EnoceanGateway/Standalone?

Aktuell auf einem Sensor-Modul mit nur Beeper auf der Platine.

Habe diese Implementierung derzeit "nur" experimentell im Einsatz und will einige Funktionen dadurch abbilden die jetzt teilweise noch in OpenHab hängen. Dazu braucht es z.B. auch die Flankenerkennung. In der aktuellen Konfiguration sind es 25 Logikkanäle, davon 6 Schaltuhren die wahrscheinlich auch eher exotisch sind (jede Minute/Stunde/Tag/Woche/Monat/Jahr) und bislang nur aus Neugier angelegt wurden. Vielleicht ist das schon relativ viel? Ohne den Fix mit +1000ms würde die Verzögerung nach meinem bislang nur groben Verständnis der Implementierung vom Umfang der erforderlichen Verarbeitungsschritte abhängen.

Lokale Abweichungen im Sekundenbereich halte ich auch für unproblematisch. Der Drift ist bei mir wahrscheinlich auch nur aufgefallen, weil ich bislang nur die Uhrzeit-Datum-Kombination auf den Bus sende und niemals die reine Zeit.

[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

[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]

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

[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

[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]

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]

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, 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