MDT Logikmodul SCN-LOG1.02: Speichern und senden nach Reset

[mumpf]

Hi,

ich komme hier bei einer eigentlich simplen Funktion nicht weiter.

Ich nutze bei dem MDT-Logikmodul die Funktion "Speichern und senden nach Reset" für ein DPT 5. Ziel: Der letzte Wert dieser GA soll 2 Minuten nach Reset auf den Bus gesendet werden. Wertebereich ist (derzeit) noch 0, 1 und 2.

Beim allerersten Mal ging es gut: Ich hatte ein 2 auf die GA geschrieben. Nach der nächsten Programmierung hat das Modul nach 2 Minuten eine 2 auf die GA gesendet. SUPER.

Aber leider war es das... Jegliche Wertänderung seit diesem Zeitpunkt wird nicht gespeichert. Derzeit ist der Wert der GA eine 0. Auch ein Read von dem KO des Logikmoduls liefert mir eine 0. Nach einer erneuten Programmierung wird aber nach 2 Minuten wieder eine 2 geschrieben. Ich werde diese initial vergebene 2 nicht mehr los. Vor jeder Programmierung muss ich schauen, was für einen Wert die GA hat und nach jedem Programmieren die GA (nach 2 Minuten) manuell auf den Richtigen Wert setzen, da das Modul eine 2 schreibt. Und bei einem neuen Modul mit vielen Möglichkeiten programmiert man dieses sehr häufig... ich zumindest. Ist nervig und so nicht zu gebrauchen.

Hat sonst noch jemand diese Erfahrung gemacht? Gibt es noch irgendwo eine spezielle "Speichern"-Aktion über ein KO oder ähnliches, und ich bin nur zu blöd, das zu finden?

Bin echt gefrustet, da "Speichern und senden nach Reset" und "Wertetabelle" die wesentlichen Funktionen waren, weswegen ich das Modul gekauft habe.

Gruß, Waldemar

[hjk]

Das Problem liegt an der Neuprogrammierung des Logikmoduls. Das Logikmodul speichert bei Busspannungsausfall. Bei Neuprogrammierung geht das nicht, daher wird der vorherige Wert gesendet.
Wenn du den Wert im Logikmodul speichern willst, muss die Busspannung ausfallen, also Stecker ziehen oder Bus-Resettaaste drücken.
Nur dann wird der Wert gespeichert.

Die Funktion speichert bei Busspannungsausfall und stellt den Zustand nach Busspannungswiederkehr wieder her. Bei Neuprogrammierung kann der Wert nicht gespeichert werden. Die ETS macht danach aber einen Neustart, daher sendet das Modul den zuletzt abgespeicherten Wert.

Gruß
HJ

[mumpf]

Hi hjk,

danke für die prompte Antwort, trotz Wochenende...

Aber ich bin jetzt sprachlos... MDT/Dir ist schon klar, dass die Funktion damit sinnlos wird? Es ist ja nicht nur, dass das Modul den letzten Wert nicht speichert, nach der Programmierung sendet es den zuletzt gespeicherten, also wahrscheinlich falschen Wert! Und dass man nicht vor jedem Programmieren einen Bus-Reset macht oder beim Logikmodul den Stecker zieht, sollte klar sein, oder? Das Verhältnis von korrekter Funktion (bei Busspannugsausfall/Busreset) zum fehlerhafter Funktion (bei Neuprogrammierung) dürfte bei 1:100 liegen, zumindest so lange man an seinen Logiken schraubt und optimiert.

Hier als Motivation mal mein Fall: Ich habe bei mir im Haus 3 Heizphasen Sommer=0, Übergangszeit=1, Winter=2. Da ich mit meiner Klimaanlage auch heizen kann, ist dies in der Übergangszeit, in der man selten zuheizen muss, die bessere Alternative. Der Wert der Heizphase ist etwas, dass ich nativ in KNX halten möchte, da einiges Logik davon abhängt und ich nicht von einem Server abhängig sein möchte. Dass mir das Modul jetzt im Winter nach einer Neuprogrammierung den Sommermodus einstellt, nur weil der letzte Stromausfall im Sommer war, halte ich für ziemlich "bescheiden"...

Ich werde mal weiter testen, was ich da noch retten kann, aber erwartungskonform ist diese Funktion nicht. In allen euren Geräten ist Busspannunsausfall bzw. -wiederkehr und Neuprogrammierung gleich behandelt, nur hier nicht!

Gruß, Waldemar

[mumpf]

So, etwas weiter getestet.

Ich habe festgestellt, dass der Wert auch gespeichert wird, wenn ich das Logikmodul per ETS zurücksetze (Funktion Gerät zurücksetzen). Da das eine reine Software-Aktion ist, stellt sich die Frage, ob

Bei Neuprogrammierung geht das nicht

so wirklich stimmt. Ich wollte damit fragen, ob ihr nicht nochmal schauen könnt, ob ihr bei einer Programmierung nicht vorher intern einfach die gleiche Speichern-Funktion aufrufen könnt, die ihr bei "Gerät zurücksetzen" aufruft.

Wenn du den Wert im Logikmodul speichern willst, muss die Busspannung ausfallen

Zumindest muss nicht die Busspannung weg sein, damit er speichert.

Ich werde jetzt also so arbeiten, dass ich das Logikmodul vor einer Programmierung immer zurücksetze. Nicht toll, aber immer noch besser als Bus-Reset. Und in den Keller zum Kabelabziehen will ich definitiv nicht.

Gruß, Waldemar

[trollvottel]

Habe mit dieser Funktion die selben Probleme, eigentlich völlig nutzlos, höchstens vielleicht im regulären Betrieb ab dem Moment ab dem man definitiv nix mehr ändert. Aber gibt's das überhaupt bei KNXUF-Usern? Ich glaube nicht...

Dass bei (Neu)programmierung nix gespeichert wird und dann auch nicht unbedingt intuitiv ist, dass dann überhaupt was gesendet wird (ja was denn eigentlich?), hat hier bei uns schon für mehrere Aufreger gesorgt. Ich hatte versucht, den "Schlafen"-Status je Schlafraum damit abzuspeichern, sodass ich auch abends/nachts gefahrlos den Bus programmieren oder der Strom ausfallen kann ohne dass in den Räumen dabei "Party" entsteht. Das konnte ich allerdings relativ schnell vergessen, weil es nicht wie erhofft tut.

In allen euren Geräten ist Busspannunsausfall bzw. -wiederkehr und Neuprogrammierung gleich behandelt, nur hier nicht!

Das stimmt leider nicht. Der Heizungsaktor vergisst auch seine Betriebsartvorwahl beim Neuprogrammieren.

Ich werde jetzt also so arbeiten, dass ich das Logikmodul vor einer Programmierung immer zurücksetze

Danke für diesen hilfreichen Ansatz, aber ich fürchte, ich werde das trotzdem regelmäßig vergessen.

[hjk]

Dann müsste der Ablauf der ETS geändert werden, bei Neuprogrammierung erst das Gerät zurücksetzen, kurz warten und dann programmieren.
Wenn die Neuprogrammierung startet, kann nicht mehr gespeichert werden.
Im Normalbetrieb macht die Funktion genau was sie soll, nicht mehr und nicht weniger.
Vielleicht können wir abfangen, damit nach Neuprogrammierung nichts gesendet wird. Das können wir mal prüfen.

[mumpf]

Vielleicht können wir abfangen, damit nach Neuprogrammierung nichts gesendet wird. Das können wir mal prüfen.

Hi,

das wäre sicherlich auch eine Hilfe, denn nach dem Programmieren des Logikmoduls ist der restliche Bus ja noch da und es sollte alles stimmen. Falls ihr sowieso was in dem Bereich macht bzw. als Tipp für eine künftige Version sehe ich 3 Möglichkeiten:

1. Nach dem Programmieren gar nichts senden. Das ist wahrscheinlich das einfachste, aber ein Read auf die GA würde dann noch immer einen falschen Wert liefern (ich habe bisher das Logikmodul als führend betrachtet, deswegen hier auch das L-Flag vergeben). Kann man aber auch anders lösen...
2. Nach dem Programmieren könnte das Logikmodul für die Speichern-KO noch ein Read machen, um sich vom Bus zu initialisieren. Das würde das obige "Lesen"-Problem beheben.
3. Oder noch besser: Für die Initialisierung nach dem Programmieren noch ein eigenes KO vorsehen, dann könnte sich das persistente Objekt mit einen neuen Wert auch von einer anderen GA versorgen (wegen Schalt-GA, Status-GA). Wenn die gleiche GA gewünscht ist, würde man einfach die gleiche an beide GA zuweisen.

Dann wäre die Funktion gut produktiv nutzbar - bei laufendem Betrieb als Zwischenspeicher für Werte, nach dem Stromausfall als Lieferant für den "vorherigen Wert" und nach der Programmierung mit immer noch gültigem Wert.

Nur meine Meinung,
Gruß, Waldemar

P.S.: Warum das mit dem Read nicht unwichtig ist: Manchmal programmiert man ja mehr als ein Gerät, und wenn das 2 nach der Programmierung eine Reihe von Reads für die Initialisierung absetzt, ist mit dem "nicht senden" nichts gewonnen. Bzw. man muss wissen, dass dieses KO dann kein L-Flag haben darf...

[mumpf]

Das stimmt leider nicht. Der Heizungsaktor vergisst auch seine Betriebsartvorwahl beim Neuprogrammieren.

Danke für die Info. Das erklärt, warum meine Heizung immer im falschen Betriebsmodus landet, obwohl ich "nur" an den Reglerparametern optimiere. Muss ich mir merken bzw. werde gleich testen, ob der Workaround mit "Gerät zurücksetzen" auch hier zieht.

Gruß, Waldemar

[trollvottel]

Beim Heizungsaktor kann man immerhin einen fixen Default setzen, z.B. Komfort. Das ist aber nur für die Fälle eine Lösung, wo man sowieso nirgends umschaltet.

[alramlechner]

Ich hatte versucht, den "Schlafen"-Status je Schlafraum damit abzuspeichern, sodass ich auch abends/nachts gefahrlos den Bus programmieren oder der Strom ausfallen kann ohne dass in den Räumen dabei "Party" entsteht. Das konnte ich allerdings relativ schnell vergessen, weil es nicht wie erhofft tut.

Ich hänge mich an: habe genau das gleiche Problem. Logikmodul programmieren ist für mich tabu, wenn die Kinder schlafen ...

edit: Eleganter fände ich eigentlich, wenn sich der PM den Sperrstatus über eine Neuprogrammierung / Busreset behält.

[trollvottel]

Eleganter fände ich eigentlich, wenn sich der PM den Sperrstatus über eine Neuprogrammierung / Busreset behält

PM alleine würde mir an der Stelle nicht reichen, ich hab ja auch noch Rollos die gesperrt bleiben möchten und Taster die im richtigen Tag/Nachtmodus bleiben sollen. Da ist mir das übers Logikmodul flexibler abzufackeln.

Mein Workaround war daher, das Zwischenspeichern erstmal Callidomus zu überlassen (srsly! ). Aber eigentlich will ich so essentielle Funktionen mit reinen KNX-Geräten erschlagen können, ganz ohne Server.

[Beluk]

Bei mir das Gleiche. Ich habe mir eigentlich genau wegen der Funktion das Modul gekauft um meine Automatik Ein/Aus zu speichern. Ich würde es super finden wenn doch noch eine Lösung gefunden würde ohne zuerst das Gerät Rücksitzen zu müssen.

[mumpf]

Eleganter fände ich eigentlich, wenn sich der PM den Sperrstatus über eine Neuprogrammierung / Busreset behält.

Hi,

das wird man nicht machen, ich denke, es ist technisch aufwändig, einen solchen Speicher zu implementieren (bin aber nicht von Fach). Aber die PM (und überhaupt alle KNX-Geräte) müssten viel mehr Optionen bieten, sich vom Bus zu initialisieren, anstatt immer die programmierten Defaults zu nach dem Programmieren zu nehmen. So ein PM könnte also über eine GA fragen, ob er noch gesperrt ist. Und erst wenn auf diesen Read kein Antwort kommt, würde man den programmierten Default nehmen.

Sonst noch ein Tipp zum PM Sperren für die Nacht: Meine (BEG) PMs bieten die Möglichkeit, per KO zwischen Halbautomat und Vollautomat umzuschalten. Ich habe in den Schlafzimmern immer den ETS-Default auf Halbautomat, so kann nach dem Programmieren kein Licht angehen. Morgens (beim Ende Schlafmodus) und Abends bei Anfang Dämmerung werden die dann auf Vollautomat geschaltet (per Zeitschaltuhr). So kann ich auch Nachts programmieren, ohne dass es die Familie stört. Und wenn ich mal was Ändere und dadurch der PM mal das Licht nicht einschaltet, dann muss man mal über Schalter schalten. Und spätestens am nächsten Tag hat sich das von selber "geheilt". Falls man also seine PM per KO von Halb- auf Vollautomat stellen kann, finde ich das besser als sperren...

Muss ich mir merken bzw. werde gleich testen, ob der Workaround mit "Gerät zurücksetzen" auch hier zieht.

Habe es jetzt getestet, das geht beim Heizungsaktor leider nicht... Schade - aber nicht so schlimm wie beim Logikmodul, hier erwarte ich (zumindest bei mir) fortwährende Anpassungen und Verfeinerungen. Insofern wäre es toll, wenn hier noch was passieren würde.

Gruß, Waldemar

[STSC]

Gäbe es evtl. die Möglichkeit, dass man per KO das Logikmodul auffordert den letzten Wert zu speichern. Dann weiß man sicher, dass der aktuell gültige Wert nach einem Reset auf dem Bus geschickt wird.