OpenKNX-Logikmodul release

[mumpf]

Hi Soundman,

das ist ja ganz schlimm, was Du beschreibst, wenn das so wäre, dann würde ich mein Logikmodul auch nicht mehr benutzen wollen . Wie immer kann ich nicht ausschließen, dass ich irgendwo einen Fehler habe, aber ich bin mir ziemlich sicher, dass es keiner ist, der so elementar ist, dass er nur 25 statt 99 Logiken zulässt.
Wir können gerne zusammen die Ursache ergründen und ich korrigiere es natürlich, falls das Problem bei mir liegt.

Aber erstmal ein paar Informationen zum Handling, da Dein Post hier meiner Meinung nach einen falschen Eindruck vermittelt:

Auf jeden Fall half auch ein Trennen der Busversorgung nicht, musste das Gerät wirklich "hart" resetten.

Der einzige mir bekannte Fall, der das auslösen kann, ist eine Schleife (Ausgang geht auf Eingang, das löst die Logik wieder aus und das löst wieder ein neues Telegramm aus). Da das Logikmodul sehr schnell ist, sendet es die Telegramme so schnell, dass man nicht mehr von außen dran kommt.
Ich bin schon seit längeren am überlegen, was ich gegen so was machen kann, aber mir ist noch keine gute Idee eingefallen, die nicht potentiell Logiken kaputt macht.
Falls Du es ohne eine Schleife zu bauen zum aufhängen bekommen hast, bin ich sehr an einem Beispiel interessiert.

ist ja viel Arbeit das jedes mal neu in der ETS aufzusetzen

Sorry, aber es gibt keinen einzigen Grund, alles in der ETS neu aufzusetzen. Schon gar nicht, weil Du bei der Firmware einen nuke machen musstest. Dann wird die Firmware neu aufgespielt, die gleiche PA vergeben und einfach nochmal programmiert.
Sicherheitshalber mache ich schon vor der Programmierung den Gruppenmonitor an, dann sehe ich die ersten Telegramme nach der Programmierung, die gesendet wurden, bis der Hänger erneut kommt (falls es wieder passiert). Und das gibt normalerweise einen guten Hint, welche Logik beteiligt ist. Diese Logik kann man dann deaktivieren (dafür gibt es eine Checkbox beim Logikkanal), und dann kann man sehen, ob es mit deaktivierter Logik ohne Hänger klappt.
Und dann überlegt man, warum die Logik zum Hänger führt - meist hilft da auch die Detailanalyse des Gruppenmonitor-Auszugs.

Mich interessiert sehr, was Dich überhaupt auf die Idee brachte, die Applikation neu aufsetzen zu müssen? Das Produkt wäre ja komplett unbrauchbar, wenn so was nötig wäre! Es ist bei meinem Logikmodul sogar genau umgekert: Die Einstellungen in der ETS bleiben auch über viele Releases und Updates erhalten, ohne dass man (wie bei einigen anderen Herstellern) nach einem Update alle Parameter neu eingeben muss.

ich habe es nicht hinbekommen, das Gerät neu zu programmieren.

Bist Du sicher, dass Du nach dem erneuten aufspielen der Firmware (nach dem nuke) auch die PA neu programmiert hast? Nach einem Nuke ist alles weg, auch die PA. Dann hat das Gerät wieder die KNX-Typische PA 15.15.255.

Rauswerfen und neu importieren ging,

Das kann nicht sein, zumindest hast Du dann andere Schritte gemacht als bei dem einfachen Versuch, es neu zu programmieren. Dass nach dem Rauswerfen alle Parameter weg sind, stimmt natürlich. Aber ich bleibe dabei: Rauswerfen ist nicht notwendig. Folgende Schritte gehen garantiert nach einem nuke (in der Annahme, 1.1.38 ist ein in der ETS existierendes Logikmodul):

1. Firmware per USB aufspielen
2. Prog-Button drücken (rote LED leuchtet)
3. In der ETS auf die 1.1.38, rechtsklick, Programmieren->Physikalische Adresse, rote LED geht aus.
4. Danach 1.1.38, rechtsklick, Programmieren->Applikationsprogramm

Ich lasse das jetzt erst mal ruhen und warte auf das neue Netzteil.

Ich bin mir sehr sicher, dass es nicht am Netzeil liegt. Ist einfach nicht wahrscheinlich.

Und jetzt noch kurz zu dem, was ich in Deinem KO-Bild von oben sehe:

• Die Logik 27 hat am Eingang 2 die GA 0/5/102 Zustand, die auch dem Ausgang der Logik 29 zugewiesen ist.
• Der Ausgang von Logik 27 geht über GA 0/5/109 ZERG7 auf Eingang 2 der Logik 28.
• Ausgang der Logik 28 ist über GA 0/5/110 ZERG8 mit Eingang 1 der Logik 29 verbunden.
• Hier haben wir also eine potentielle Schleife
  • Logik 27 -> 28 -> 29 -> 27

Ich weiß nicht, wie die Logiken definiert sind, aber das ist eine mögliche Schleife. Eine weitere mögliche Schleife habe ich gesehen über

• Logik 22 -> 23 -> 28 -> 29 -> 22

Und auch wenn Du sagst, dass ist so definiert, dass es am Anfang nichts auslöst - das würde ich hier als erstes bezweifeln. Deaktiviere mal Logik 29 und schau, ob sich das Gerät immer noch aufhängt.

Solche Logiken mit Rückkopplung sind möglich, ich betreibe selber ein Paar, aber man muss natürlich aufpassen, dass daraus keine Endlosschleife wird. Viele der Einstellungen im Logikmodul erlauben eben detailliert den Signalweg zu beeinflussen und damit trotz Rückkopplung eine Endlosschleife zu verhindern.

Da würde ich ansetzen. Ich unterstütze Dich gerne, wenn Du Einblick in Deine Logiken bietest (screenshots). Wir können auch einen Call ausmachen, wenn Du gar nicht weiter kommst. Derzeit würde ich aber behaupten, wenn Du Logik 29 deaktivierst, wirst Du die 29 Kanäle programmieren können .

Gruß, Waldemar

[Soundman]

Moin,
erstmal vielen Dank die Ausführungen.

Ich habe das jetzt noch einmal nachgebaut.

Wie komme ich dazu?
Angefangen hat es mit meinem Problem für die "Umschaltung Tag-/Nachtbetrieb" hier hat mir knxPaul im Beitrag https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/knx-einsteiger/1945168-umschaltung-tag-nachtbetrieb?p=1956733#post1956733 dann einen Hinweis auf eine Wertetabelle gegeben.

Also habe ich "blauäugig" die Frage mal an ChatGPT gestellt:
ChatGPT: "Natürlich, ich helfe dir gerne mit deiner KNX-Anforderung. Kannst du bitte die Details deiner Anforderung beschreiben?
Je mehr Informationen du gibst, desto besser kann ich dir helfen. Zum Beispiel:

Welche Art von Gerät/en möchtest du steuern (Licht, Heizung, Jalousien, etc.)?
Welche spezifischen Aktionen oder Szenarien möchtest du umsetzen?
Gibt es bestimmte Bedingungen oder Auslöser (z.B. Zeit, Temperatur, Bewegungssensoren), die berücksichtigt werden müssen?
Je genauer du deine Anforderung beschreibst, desto präziser kann die Lösung sein."

ICH:
"alter Zustand | DMS | Uhr | Tag/Nacht
0 | 0 | 0 | 0
0 | 0 | 1 | 0
0 | 1 | 0 | 0
0 | 1 | 1 | 1

1 | 1 | 1 | 1
1 | 0 | 1 | 1
1 | 1 | 0 | 1
1 | 0 | 0 | 0

Erläuterung:
Zustände: 1 - Tag, 0 - Nacht
DMS - Dämmerungsschalter
Uhr - Astroschaltuhr

Die Eingänge vom DMS (GA 0/5/100) und der Uhr (GA 0/5/101) habe ich.
Wie realisiere ich nun, das auf das Tag/Nacht (GA 0/5/102) immer nur entweder Nacht(1) oder Tag(0) anliegen?"

ChatGPT:
"Um die gewünschte Logik in deinem KNX-System zu implementieren, kannst du eine Logiksteuerung verwenden.
Es gibt mehrere Wege, dies zu erreichen, je nach dem, welche Hardware oder Software du in deinem KNX-System hast
(z.B. KNX-Logikmodule, ETS4/ETS5, oder eine spezielle KNX-Logiksoftware wie z.B. KNX Logic Machine).

Hier ist eine allgemeine Beschreibung, wie du die Logik umsetzen kannst:"

Darauf kam erst einmal eine Auflistung, wie man das mit einer Logiksoftware machen kann.
."..Mit diesen Schritten kannst du die gewünschte Logik in deinem KNX-System implementieren. Wenn du noch spezifische Fragen oder Anforderungen hast, lass es mich wissen."

ICH:
"so nun das ganze ohne logikmodul nur mit UND, ODER, XOR und TOR als logikfunktionen."

ChatGPT:
"...Mit diesen Schritten kannst du die gewünschte Logik in deinem KNX-System umsetzen, ohne ein spezielles Logikmodul zu verwenden. Falls du weitere Fragen oder spezifische Anforderungen hast, lass es mich wissen."
(Darauf kam eine Antwort, die aber schon offensichtlich falsch war.)

ICH:
"Damit komme ich in eine Endlosschleife. Ich muss den Zustand irgendwie zwischenspeichern"

ChatGPT:
"Um die gewünschte Logik zu implementieren und den Zustand zwischenspeichern zu können,
kannst du das ETS5 Logikmodul und die entsprechenden logischen Bausteine verwenden. Hier ist eine detaillierte Anleitung zur Umsetzung:

Schritt-für-Schritt-Anleitung in ETS5:
Erstellung der Gruppenadressen:

GA 0/5/100 für Dämmerungsschalter (DMS)
GA 0/5/101 für Astroschaltuhr (Uhr)
GA 0/5/102 für den Zustand (sowohl alter als auch neuer Zustand)

Logikbausteine hinzufügen:

Logik für den Fall "alter Zustand == 0":
AND-Gatter für DMS und Uhr (DMS AND Uhr):
Eingang 1: GA 0/5/100 (DMS)
Eingang 2: GA 0/5/101 (Uhr)
Ausgang: Zwischenergebnis 1 (Wert = 1 wenn DMS und Uhr beide 1 sind, sonst 0)

Inverter für den alten Zustand:
Eingang: GA 0/5/102(alter Zustand)
Ausgang: Zwischenergebnis 2 (invertierter alter Zustand)

AND-Gatter für Zwischenergebnis 1 und Zwischenergebnis 2:
Eingang 1: Zwischenergebnis 1 (Ausgang des ersten AND-Gatters)
Eingang 2: Zwischenergebnis 2 (invertierter alter Zustand)
Ausgang: Zwischenergebnis 3 (aktiviert, wenn alter Zustand 0 und DMS und Uhr beide 1 sind)

Logik für den Fall "alter Zustand == 1":
NOT-Gatter für DMS (NOT DMS):
Eingang: GA 0/5/100 (DMS)
Ausgang: Zwischenergebnis 4 (Wert = 1 wenn DMS 0 ist, sonst 0)

NOT-Gatter für Uhr (NOT Uhr):
Eingang: GA 0/5/101 (Uhr)
Ausgang: Zwischenergebnis 5 (Wert = 1 wenn Uhr 0 ist, sonst 0)

AND-Gatter für Zwischenergebnis 4 und Zwischenergebnis 5:
Eingang 1: Zwischenergebnis 4 (Ausgang des NOT-Gatters für DMS)
Eingang 2: Zwischenergebnis 5 (Ausgang des NOT-Gatters für Uhr)
Ausgang: Zwischenergebnis 6 (Wert = 1 wenn DMS und Uhr beide 0 sind, sonst 0)

AND-Gatter für Zwischenergebnis 6 und alter Zustand:
Eingang 1: Zwischenergebnis 6 (Ausgang des zweiten AND-Gatters)
Eingang 2: GA 0/5/102(alter Zustand)
Ausgang: Zwischenergebnis 7 (aktiviert, wenn alter Zustand 1 und DMS und Uhr beide 0 sind)

Kombination der beiden Logiken:
ODER-Gatter für Zwischenergebnis 3 und Zwischenergebnis 7:
Eingang 1: Zwischenergebnis 3 (aktiviert, wenn alter Zustand 0 und DMS und Uhr beide 1 sind)
Eingang 2: Zwischenergebnis 7 (aktiviert, wenn alter Zustand 1 und DMS und Uhr beide 0 sind)
Ausgang: Zwischenergebnis 8 (neuer Zustand)

Speichern des neuen Zustands:
Verknüpfen des neuen Zustands:
Ausgang des ODER-Gatters (Zwischenergebnis 8) wird mit GA 0/5/102(neuer Zustand) verknüpft

Implementierung:
Gruppenadressen erstellen:
Erstelle die Gruppenadressen 0/5/100, 0/5/101 und 0/5/102 in der ETS5 Software.

Logikgatter konfigurieren:
Füge die benötigten Logikgatter in der ETS5-Logikfunktion hinzu und verknüpfe die entsprechenden Gruppenadressen gemäß der oben beschriebenen Logik.
Konfiguration der Logikgatter:
Öffne die Konfiguration des Logikmoduls in ETS5 und füge die oben beschriebenen Logikbausteine hinzu.
Stelle sicher, dass die Ausgänge der Logikbausteine korrekt mit den Eingängen der nächsten Logikbausteine verbunden sind.
Testen und Validieren:

Lade die Konfiguration auf dein KNX-Gerät und teste die Logik, indem du die Werte für DMS, Uhr und den alten Zustand veränderst. Verifiziere, dass die Gruppenadresse 0/5/102 korrekt auf Tag (1) und Nacht (0) umschaltet, basierend auf der beschriebenen Logik.
Durch diese Schritte wird die gewünschte Logik umgesetzt und der Zustand korrekt zwischengespeichert, ohne eine Endlosschleife zu erzeugen."

Also habe ich das gemacht:

L_1.png
GA_1.png

So nun der Test und wie erwartet komme ich in eine Endlosschleife:

M1.png

Trotzdem war der Bus nicht überlastet:
M3.png

Ausgeschaltet:
M5.png

dann die Verbindung ZERG8 und GA 0/5/102 getrennt und anschließend zu programmieren probiert, und das ging jetzt schief.

M6.png
Ich glaube, beim letzten Mal habe ich dann probiert, zu programmieren und dabei die PROG-Taste zu drücken, das mehrmals und irgendwann wollte gar nichts mehr😤
Da habe ich dann das Gerät neu "geflasht" und es nicht hinbekommen, das wieder in die ETS einzubinden, so dass ich es komplett gelöscht und dann neu aufgenommen habe.

Heute habe ich einen "Bus-Reset" über den MDT ausgeführt (komme im Moment nicht an den Schaltschrank und nur den Strom von Gerät zu nehmen, meine Tochter schläft in dem Zimmer), damit gib es wieder. (Bloß blöd, dass die UD/S Dimmer dann meinen eine Lasterkennung durchführen zu müssen und es überall kurz "blitzt" [meine Frau und Tochter sind zu Glück nicht aufgewacht, das hätte Ärger gegeben...])

Ich habe wohl in dem ersten Moment vieles Falsch gemacht.
Da möchte ich um Entschuldigung bitte.

Evtl. hilft aber diese "Testsituation" , um das Verhalten des Reg-Geräts robuster zu machen.

Eine Idee zu der Erkennung von solchen Endlosschleifen hätte ich noch.
Da ich beruflich aus der Leitsystem-Ecke komme, kenne ich ein ähnliches Problem.
Wenn ein Messfühler "spinnt", kommt es zu einem Schwall von unsinnigen Eingangswerten auf den Eingangsschnittstellen. (IEC-104 kann das sogar übertragen.)
Man kann das so abfangen, dass man die maximal Anzahl an Änderungen (auf Eingangsseite) pro Zeiteinheit limitiert.
Dann wird der Eingang abgeschaltet bis entweder wieder "Ruhe" ist, oder nach einen definierten Zeit.

[willisurf]

Also habe ich "blauäugig" die Frage mal an ChatGPT gestellt:

Tatsächlich -wie Du jetzt sicher auch weißt- keine gute Idee. Aber Danke, das Du das hier klargestellt hast.

[knxPaul]

eine Schleife (Ausgang geht auf Eingang ...

ich muss mich als Quasi Verursacher outen: Genau die Schleife ist wohl passiert.
Die Aufgabe ist eine Logik zu erstellen, die nicht einfach kombinatorisch die Eingänge verknüpft, sondern ein Gedächtnis hat. Wie unten verlinkt sollen zwei unterschiedliche Kombinatoriken abgearbeitet werden in Abhängig vom aktuellen Ausgang der Logik.
In einem getakteten System kann man den Ausgang auf einen Eingang zurückführen, alle Zwischenzustände des Logikausgangs spielen keine Rolle; erst beim nächsten Takt wird der alte Zustand in der Logik als Eingang wieder ausgewertet.

• Im ereignisgesteuerten KNX gibt es erst mal kein getaktetes System.

Das erklärt das nicht mehr nachvollziehbare Verhalten, das in Ventilatordrehzahl über Dimmaktor beschrieben wird. Die Zwischenzustände beschäftigen die Kombinatorik durch die direkte Rückkopplung.

Nun braucht es einen sehr guten Kenner des Logikmoduls, der bei der Lösung helfen kann.

[mumpf]

Hi knxPaul,

der "Verursacher" ist sicherlich eine Kombi aus einem unerfahrenen User und der Verwendung von ChatGPT unter Umgehung jeglicher dokumentation. Das erkenne ich alleine daran, dass Inverter-Logikkanäle verwendet wurden, ob wohl man bei mir bei jedem Eingang einstellen kann, ob er invertiert wird - mit einem Click statt mit 20.

Du hast es richtig erkannt, mein Logikmodul implementiert eine ereignisgesteuerte Logik. Es bietet aber auch Möglichkeiten, die Ereignisse zu beeinflussen. Indem man z.B. nur bei Wertänderung senden lässt oder einen Ausgangsfilter setzt, der gleiche Werte ausfiltert. Beides würde wahrscheinlich das obige Problem lösen.

Ich habe aber die Lösung schon im Ausgangs-Thread beschrieben (Ich glaube, Dein Link ist falsch, es ist der hier: https://knx-user-forum.de/forum/%C3%...33#post1956733), es müssen einfach nur 2 Flags geändert werden.

Der Originalansatz war:

1. AUS und AUS ergibt AUS
2. EIN und EIN ergibt EIN

Alle anderen Kombinationen sollen nichts tun.
Genau so würde ich es parametrieren:

1. Kanal: A ODER B, nur AUS senden
2. Kanal: A UND B, nur EIN senden

Jetzt hat man 2 Ausgänge, die auf die selbe GA senden und natürlich beim Read falsche Werte liefern, weil immer beide antworten. Die Lösung ist dann aber nicht eine irre komplizierte Logik zu erfinden, sondern einfach die Eigenschaften von KNX zu nutzen:
Der eine Ausgang bekommt die Flags KLSÜ, der andere nur KÜ. Der mit KLSÜ hat jetzt immer den richtigen Zustand und antwortet als einziger auf das Lesetelegramm.

Gruß, Waldemar

[mumpf]

Eine Idee zu der Erkennung von solchen Endlosschleifen hätte ich noch.
Da ich beruflich aus der Leitsystem-Ecke komme, kenne ich ein ähnliches Problem.
Wenn ein Messfühler "spinnt", kommt es zu einem Schwall von unsinnigen Eingangswerten auf den Eingangsschnittstellen. (IEC-104 kann das sogar übertragen.)
Man kann das so abfangen, dass man die maximal Anzahl an Änderungen (auf Eingangsseite) pro Zeiteinheit limitiert.

Danke für die Info, aber mir ist das von Dir beschriebene verfahren natürlich klar und bekannt. Meine Aussage bezog sich darauf, dass ich eine Stelle im Logikmodul finden muss, die die Funktionalität der anderen Kanäle nicht beeinflusst und auch Wege bereitstellen muss, um solche deaktivierten Kanäle anzuzeigen und erneut aktivieren zu lassen.
Das Problem ist also nicht das "was man machen muss" sondern das "wie".

Gruß, Waldemar

[TabSel]

…Ich bin schon seit längeren am überlegen, was ich gegen so was machen kann, aber mir ist noch keine gute Idee eingefallen, die nicht potentiell Logiken kaputt macht…

Idee: durchschnittliche Anzahl Eingangsimpulse/Sekunde über ein Zeitfenster x Sekunden errechnen und bei Überschreiten einer Rate y/Sekunden das Processing unterbinden und an KO senden (b01) bis ein Resetimpuls am KO (b00) empfangen wird. Ein/Ausschaltbar per ETS-Parameter.

[mumpf]

Wie gesagt, das "was" ist klar.

Ich weiß auch inzwischen das "wie": Es wird im nächsten Release eine Endlosschleifen-Erkennung geben, ich konnte das so lokal bauen, dass es nur dezidierte Kanäle deaktiviert werden und der Rest des Logikmoduls unbeeinflusst bleibt.

Rahmendaten: Es müssen mehr als 50 Aufrufe eines Kanals in einer Sekunde erfolgen, dann wird er deaktiviert. Es wird nicht aktiv gemeldet. Man kann den Zustand über das Diagnoseobjekt abfragen und zurücksetzen. Da die Endlosschleifen-Erkennung eine Fehlkonfiguration behebt, ist das primäre Ziel, dass das Gerät programmierbar bleibt. Danach kann man es neu programmieren und weitere Versuche machen.

Gruß, Waldemar

[stoepf]

Ich hab heute versucht eine PiPico über NanoBCU und BCU-Breadboard-Adapter mit dem Logikmodul in Betrieb zu nehmen.
Das Programmieren des PiPico über USB hat problemlos funktioniert, ich sehe auch die Ausgaben auf der Console.
Ich kann auch in dern Programmiermode schaltem, allerdings lässt sich die Adresse nicht programmieren.
Aktuell hab ich noch keinen ADUM eingebaut, weil ich auf der USB-Seite das Notebook im Akkubetrieb einsetze und die glavanische Trennung nach meinem Verständnis dann nicht notwenig ist. Oder irre ich da?

Fehlermeldung in der Console sobald ich die ETS nach Geräten im Programmiermodus suchen lasse:

L_data_con not received within expected time

Zu der Fehlermeldung hab ich Hinweise gefunden, dass wegen dem KNXD evtl. 2 Geräte gleichzeitig im Programmiermodus erscheinen. Abschalten vom KNXD hat aber leider nichts gebracht.
Ein Sensormodul funktioniert ohne Problem


Irgendwelche Ideen?

Viele Grüße
Stefan

[mumpf]

Versuch erstmal ohne USB, nur um auszuschließen, dass es stört. Der PiPico kann ja auch über KNX versorgt werden.

Sonst fällt mir nichts ein, wenn Du sicher bist, dass die KNX-Leitung wirklich verbunden ist und die NanoBCU keinen Wackler hat...

Gruß, Waldemar

[willisurf]

oder auch mal in einem Minimalsystem, d.h. nur SV und Schnittstelle, falls Du so etwas verfügbar hast oder leihen kannst.

[stoepf]

Versuch erstmal ohne USB, nur um auszuschließen, dass es stört. Der PiPico kann ja auch über KNX versorgt werden.

Hab es auch mal ohne USB probiert, aber auch keine Meldung in der ETS.

NanoBCU keinen Wackler hat...

Das kann ich leider nicht ausschließen. Werde mir wohl eine neue BCU bestellen, den PiPico hab ich schon getauscht.

oder auch mal in einem Minimalsystem

Hab ich leider nicht.

Danke euch

[mumpf]

Noch ne andere BCU zum ausprobieren?
Meldet der denn auf der Konsole direkt nach dem boot, dass KNX da ist?

0d 00:00:03: KNX:                     TP is connected

Oder alternativ:

0d 00:00:54: KNX:                     TP is disconnected

Das wäre schon mal ein Hinweis...

Gruß, Waldemar

[traxanos]

Der Hinweis kommt aber erst mit der neuen (zukünftrigen) Firmware!

[mumpf]

Ja... In der alten ist aber ein

UART nicht available

oder so was ähnliches. Das wird Stefan schon erkennen, wenn er darauf achtet.

Und wenn du mir deine Mail-Adresse schickst, kann ich dir auch eine Vorabversion der neuen zukommen lassen, die steht sowieso kurz vor dem Release. Die ist deutlicher in den Meldungen, wenn an TP was nicht stimmt.

Gruß, Waldemar