OpenKNX-Logikmodul release

[mumpf]

Ich habe ganz vergessen, es hier in den Thread zu schreiben: Das Logikmodul-Release-3.1.3 ist seit dem 25.1.24 freigegeben. Wie immer mit einigen Korrekturen und einigen neuen Features und mit einer überarbeiteten Oberfläche. Interessant für Einbaugeräte: Ein Firmware-Update kann ab dieser Version über den KNX-Bus erfolgen.
Weitere Infos wie immer am Angang des Threads im Beitrag #2 und in unserem Wiki.

Gruß, Waldemar

[mumpf]

Hallo,

bitte das neuste Logikmodul-Release 3.1.3 NICHT auf einen SAMD einspielen. Da gibt es ein Problem mit dem Flash-Tool, zumindest wenn man die neusten OpenKNX-Tools verwendet. Wir arbeiten an einer Lösung.

Alle RP2040-Varianten sind OK, auch die IP-Variante.

Gruß, Waldemar

[jeff25]

Hallo Waldemar,

wäre das neueste Release nicht die "3.1.4-release" Version?

Gruß
Robert

[mumpf]

Stimmt, danke für die Info.

Aber wir wissen inzwischen, das es nicht am Logikmodul, sondern an den OpenKNX Tools liegt, die wir zur Installation nutzen. Man darf die OpenKNX Tools nicht in der Version 2.11.x verwenden. Die Version 2.4.x, die ebenso auf GitHub verfügbar ist, funktioniert.
Einfach die 2.4.x erneut installieren, die überschreibt die 2.11.x. es kommt drauf an, dass im Installationsprotokoll sein

bossac 1.7.0

Ausgegeben wird, und nicht ein bossac 1.9.1.

Gruß, Waldemar

[zenvy]

Hi,

ich hatte nach der Zeitumstellung ein paar komische Probleme mit meinen Zeitschaltuhren welche durch einen Neustart des Moduls behoben worden sind. "Komische Probleme" heißt hier, Zeitschaltuhr hat zu früh geschaltet und aber gleichzeitig auch richtig? Beispiel: Ich habe eine Zeitschaltuhr die immer um 7 Uhr schaltet (Tag/Nacht objekt um die Displays der Glastaster weiß/schwarz zu schalten). Um 05:53 Uhr hatte sie aber schon geschaltet, ich war kurz wach um kurz nach 6 und ein Display hat den Raum erhellt. Habe dann über Home Assistant das einmal manuell überschrieben. Die Zeitschaltuhr hat dann aber korrekt nochmal um 7 Uhr geschaltet. Habe dann nen Neustart gemacht, seitdem ist alles ok.

Anyway, ich dachte mir nun mal, ich könnte das ja mal updaten, ich war noch auf der VPM Applikation 1.7. Ich habe nun die 1.11 drauf und mir ist beim Prüfen der Parameter folgendes aufgefallen:

- Meine Zeit sendet ein MDT IP Router auf drei GAs: Datum, Zeit und Datum/Zeit.
- Der Router hat automatisch Sommer/Winterzeitumstellung aktiv.
- Die gesendete Zeit ist ohne Zeitzoneninfo, ist aber korrekt (also der sendet jetzt 18:45 und es ist auch 18:45 CEST).
- Die gesendete Datum/Zeit ist auch korrekt und hat ein Flag für Sommerzeit aktiv

- Das Logikmodul/VPM kann mit Datum/Zeit nichts anfangen und möchte das als getrennte Daten haben, kann also das Sommerzeitflag nicht auswerten, da nicht vorhanden.
- Das LM/VPM hatte bei mir auch automatische Zeitumstellung aktiv.

Wenn ich das jetzt richtig verstehe, muss ich beim LM/VPM doch die automatische Zeitumstellung ausmachen (bzw. auf externes KO Sommerzeit aktiv stellen und das dann einfach nicht belegen) da mein Zeitserver immer die korrekte Zeit auch nach Umstellung sendet oder?

Wieso hatte es nach einem Neustart überhaupt funktioniert? Das LM/VPM müsste doch denken die 18:45 wären Winterzeit und selber nochmal ne Stunde draufrechnen und daher immer eine Stunde zu früh schalten. Edit: Ich hab nicht richtig geschaut, die Schaltzeit ist "Sonnenaufgang: Spätestens um 7:00" und nicht immer 7:00 Uhr. Das erklärt dann auch, dass um 5:53 geschaltet wurde, der LM/VPM hat nämlich selber nochmal ne Stunde draufgerechnet, Sonnenaufgang war um 6:53. Waurm es dann trotzdem nochmal um 7 geschaltet hat, keine Ahnung.

Ich habe jetzt jedenfalls erstmal das automatische Zeitumstellungsrechnen im LM/VPM deaktiviert und schaue mal was passiert heute.

[Soundman]

Moin,

ich habe die Release-3.1.4 auf meinen Modul (Bausatz von Ing-Dom, also RP2024).
Heute ist es mir zum Widerholten Mal passiert, das sich das Modul komplett aufgehangen hat, sobald ich über Logik Nr. 25 gekommen bin.
So viele sind das ja nicht.(s.u.)
Jetzt half wieder einmal nur der Komplettreset mittels "flash_nuke.uf2". Das ist nun wirklich nicht mehr schön.
LM.png

[willisurf]

Ich denke nicht, das es an der Anzahl der Logikkanäle liegt. Ich hatte diesen Stand auch schon mit deutlich mehr Kanälen lange Zeit problemlos im Einsatz.

Ich habe jetzt 5 Geräte (allerdings mit VPM) mit jeweils mehr als 60 Logikkanälen mit Lücken hoch bis 99 seit vielen Monaten ohne solche Probleme im Dauerbetrieb laufen.

Es muss irgendein anderes Problem sein. Hast Du nur das eine Gerät? Gibt es ggf. eine Schleife in den Logiken? Passiert es wirklich genau an der Grenze von 25 und dann reproduzierbar?

Sorry für die vielen Fragen, aber irgendwie müssen wir das ja eingrenzen.

[Soundman]

Hallo willisurf, ich habe nur das eine Gerät.

Ich kann auch noch nicht genau eingrenzen, wann das passiert (bin aber im Moment etwas vorsichtiger geworden, ist ja viel Arbeit das jedes mal neu in der ETS aufzusetzen).

Leider kann man wohl nur per USB debuggen bzw. auf die Console zugreifen (da war aber was mit Potentialtrennung).
Auf jeden Fall half auch ein Trennen der Busversorgung nicht, musste das Gerät wirklich "hart" resetten.

[willisurf]

Was passiert denn genau beim Absturz, das Du in der ETS alles neu aufsetzen musst?
Das Gerät ist nicht mehr ansprechbar, Du musst das Flash komplett löschen soweit verstanden.
Aber warum musst Du es in der ETS neu aufsetzen?

[Soundman]

Moin,

ich habe es nicht hinbekommen, das Gerät neu zu programmieren. (Kann mich aber auch zu blöd angestellt haben.) Rauswerfen und neu importieren ging, dann war aber die Parametrierung weg.
Hatte eben (fast) wieder den selben Effekt, konnte durch abziehen und anstecken der Busspannung das Teil reanimieren.
Ausschrift im GM:
LM_F.png

[willisurf]

Das war ziemlich sicher Zufall. Rauswerfen aus der ETS und neu parametrieren ist nicht nötig, um ein abgestürztes Gerät zu resetten.
Schau mal mit dem Gruppenmonitor im normalen Betrieb, ob es Auffällligkeiten, wie z.B. hohe Buslast gibt. Könnte es sein, das Du mit den Logiken eine Schleife erzeugt hast?

[Soundman]

Moin,

eine Schleife wird durch die Logiken erzeugt, aber nur, wenn ich eine GA mit einem bestimmten EIN Telegramm versorge Im bzw. nach dem Programmierzustand ist alles so, dass da nix automatisch angestoßen wird.
Die Buslast ist beim Start der Programmierung absolut niedrig (sorry, hatte die Zeiten im Screenshot nicht dabei). Im Schnitt gehen ca. 3-5 Telegramme pro Sekunde durch (aber nur alle 10 Minuten, wenn die Werte von den Stromzählern kommen).
Ich hänge morgen mal eine neue Stromversorgung (MDT-STC-640.01) an den Bus (bisher Meanwell KNX-20E-640). Einfach um auszuschließen, das da was nicht so wirklich i.O. ist. Sind in der Zwischenzeit 44 Komponenten dran, darunter Zennio Z35, da weiß ich nicht, was wirklich auf dem Bus an Strom los ist.

[willisurf]

eine Schleife wird durch die Logiken erzeugt, aber nur, wenn ich eine GA mit einem bestimmten EIN Telegramm versorge

Wenn da eine Parametrierung vorgenommen wurde, die potenziell so eine Rückkopplung hat (wenn ich Dich richtig verstanden habe), dann deaktiviere das mal bitte, um den Fehler einzugrenzen.

Einzelne Logiken lassen sich in den Einstellungen ohne Verlust der GA Zuordnung/Parametrierung testweise deaktivieren. Das wäre generell ein Versuch, um das Problem einzukreisen.

[Soundman]

Ich lasse das jetzt erst mal ruhen und warte auf das neue Netzteil.
Die Logiken waren so angelegt, das nur das letzte Ausgangsobjekt für ein Eingangsobjekt wieder verwendet wurde. Damit war das keine im eigentlichen Sinne keine Endlosschleife, sondern nur ein "Durchfahren" von definierten Zuständen. Durch die Änderung auf einem Eingang konnte das auch unterbrochen werden.
Die erste Programmierung ging ja, da wurden auch die anderen, von diesem Ablauf nicht betroffenen ausgeführt Logiken weiterhin ausgeführt.
Ich werde nach und nach jetzt weitere Funktionen mit dem Logikmodul versuchen umzusetzen, muss aber erst noch meine "Wichtigen" auf die verschiedenen Interfaces mit eingebauten Logiken "verteilen". Dann kann ich die im Logikmodul in Ruhe testen.

[willisurf]

Dann nur abschließend zwei Tipps. Solch eine Rückkopplung kann durchaus die Ursache für die o.g. Probleme sein.
- wenn Du die fragliche Logik später wieder in Betrieb nimmst, nutze die Einstellung „nur bei Änderung senden“, damit vermeidest Du in vielen Fällen eine Botschaftsflut
- mit dem Gruppenmonitor kann man eine Telegrammflut gut erkennen, diese kann auch nur sporadisch auftreten

Viel Spaß beim Entdecken der vielen Möglichkeiten des Logikmoduls!