Erweiterung für Persistenz: Senden nach Reboot

[blaubaerli]

Hi Robert,

das ist jetzt wieder mein Problem... Das Ding hat bei mir in einer Zelle jetzt aktuell schon 32 Werte.

Zum Glück habe ich mir da vorher von meiner CV-Seite mit all den aktuellen Werten nen Screenshot gemacht.

Ich hatte mir aber vorher schon nen Persistierer über den PluginContainer gebaut. Da hatte ich nur dann auch das Timingthema.

Ich muss mal sehen, eventuell baue ich mir ne Kombi aus beidem. Also die änderungstolerante Persistenz über den Plugincontainer in Verbindung mit deinem ersten Baustein.

Hätte aber auch wieder alles seine Nachtteile, weil ich da halt die DPT-Typen nicht geschenkt bekomme.

Danke für deine Infos.

Beste Grüße
Jens

[Robert_Mini]

32 ist schon beeindruckend.
Mach draus 4x8, dann ist es mit dem Anpassen schon ein leichtes.

Ist der WG Plugin-Container überhaupt sauber bez. Persistenz zB. Container-Neustart?

lg
Robert

[blaubaerli]

Hi Robert,

im Wiregate-Container kann ich mir die Daten bei Änderung in einem File auf dem persistenten Filesystem ablegen und dann bei Bedarf wieder holen.

Aber da die Inhalte der "/etc/wiregate/eibga.conf" vom Wiregate ja nicht wie von Geisterhand über die Programmierung der ETS aktualisiert wird, ist dann hier eben nen Workaround zu bauen.

Beste Grüße
Jens

[martin]

Hallo zusammen,

@Robert_Mini erstmal vielen Dank für deinen Baustein und die vielen Logikbeispiele!

Version: 2.0 Insider Preview 3.1

Zum Kontext: Die Erweiterung zur Persistenz - Senden nach Reboot setzte ich u.A. ein um das Freigabeobjekt des PMs nach Bus-Reset zu setzen. Der PM unterstütz kein "Lesen nach Init" und das Freigabeobjekt im PM ist als Default auf Sperren nach Busreset gesetzt, damit Nachts bei Bus-Reset das Licht nicht angeht. Um nun für den PM trotzdem eine Persistenz nach Busreset bei Stromausfall hinzubekommen passt die Funktion im Timberwolf sehr gut. Für jedes Schlafzimmer habe ich je einen kleinen Zustandsautomat mit aktuell zwei Zuständen ("Automatik", "Anwesend & Schlafend"). Der "Anwesend & Schlafend" Zustand geht dann u.A. auf den knx-bus und von dort in das "Senden nach Reboot" Modul.

Auffälligkeit: Nach geplanten Stromausfall von ca. 8:35 - 9:30 Uhr am 31.03.2021 (Anschluss Nachbar) wird der "Anwesend & Schlafend" Zustand vom einem Raum (O3 - nicht verwechseln mit Output-Bezeichnung der Logikmodule) korrekt auf dem knx gesendet, vom anderen nicht (Raum O4). Die Räume sind IMHO vergleichbar (gleiche HW, gleiche Logikmodule). Die Logikmodule liefen zum Glück alle im Debugmode:


Zustandsautomat der Räume O3 (K-402) und O4 (K-402) mit Grafana Logs. Um 7:52 Uhr gehen die Zimmer über einen Zentralbefehl in den Zustand "Automatik"

2021-04-02 22_10_09-Logik Manager _ Timberwolf.png

2021-04-02 22_09_15-O3 Zustandsautomat - Grafana.png

2021-04-02 22_10_26-Logik Manager _ Timberwolf.png

2021-04-02 22_09_47-O4 Zustandsautomat - Grafana.png

Persistenz Logikmodul mit Grafana Logs (Eingang und Ausgang für die Objekte K-402 und K-403)

2021-04-02 22_10_02-Logik Manager _ Timberwolf.png

2021-04-02 22_08_08-Reboot_ 2) Persistente Werte Senden - Räume-Zustand - OG - Grafana.png

2021-04-02 22_08_36-Reboot_ 2) Persistente Werte Senden - Räume-Zustand - OG - Grafana.png

Bus-Monitor
K-402 <-> GA 0/2/110
K-403 <-> GA 0/2/120

2021-04-02 22_07_06-Busmonitor _ Timberwolf.png

Zwischenfazit:
Ich verstehe nicht, woher im Persistenz Logikmodul für das Objekt K-403 der true-Wert nach dem Reboot kommt. Jegliche Hinweise dazu sind herzlich willkommen.

Viele Grüße
Martin

[Robert_Mini]

Hallo Martin!

Vorweg, perfekt aufbereitet!
Einen Fehler kann ich ad hoc auch nicht erkennen.

2 Sachen fallen mir ein:
- Schau mal mit dem Tool-Tip den Zeitstempel von I4 und O4 der Reboot 2) Logik an, ob tatsächlich O4 vor I4 sendet (eventuell sendet der Zustandsautomat nach der Reboot Logik?)
- Prüfe in der Objektverwaltung, was alles mit K-403 verbunden ist.

Ein letzter Punkt:
Kannst du deine Custom-Logik mit uns teilen. Ist vermutlich ein nettes Beispiel, das auch für andere interessant sein könnte.

lg
Robert

[martin]

Hallo Robert,

- Schau mal mit dem Tool-Tip den Zeitstempel von I4 und O4 der Reboot 2) Logik an, ob tatsächlich O4 vor I4 sendet (eventuell sendet der Zustandsautomat nach der Reboot Logik?)

2021-04-03 22_46_06-Reboot_ 2) Persistente Werte Senden - Räume-Zustand - OG - Grafana.png

2021-04-03 22_45_23-Reboot_ 2) Persistente Werte Senden - Räume-Zustand - OG - Grafana.png

Der Zustandswechsel 1-> 0 in der Reboot 2 Logik für I4 ist 7:52:42.636 und passt zum Ausgang des Zustandsautomaten
Der Zustandswechsel 0->1 in der Reboot 2 Logik hat für I4 und O4 den gleichen Zeitpunkt 9:31:35.269

Nach meinem Verständnis dürfte der der Eingang in der Reboot 2 Logik nur durch ein Signal verändert werden das schonmal den Weg über den knx-bus gegangen ist. Bis zum Zeitpunkt des Reboots war das laut knx-busmonitor nicht so. Kann es sein, dass hier beim Booten vom knx-Stack ein alter Wert herangezogen wird? Gerne kann ich versuchen das Verhalten zu reproduzieren. Erstmal lasse ich das System jedoch so, falls hier noch in den Logs was nachvollzogen werden kann.

- Prüfe in der Objektverwaltung, was alles mit K-403 verbunden ist.

2021-04-03 22_40_29-Objekt Manager _ Timberwolf.png

Geschrieben wird K-403 von der Reboot 2 Logik und vom Zustandsautomat
Gelesen wird K-403 von der Reboot 2 Logik und von einer weiteren Logik um den Zustand über alle Zimmer abzubilden.

Kannst du deine Custom-Logik mit uns teilen. Ist vermutlich ein nettes Beispiel, das auch für andere interessant sein könnte.

Ja gerne, das steht schon länger auf meiner ToDo-List. Dafür lege ich noch einen eigenen Beitrag an.

VG
Martin

[martin]

Hallo @Robert_Mini,

ich hab nun nochmal getestet und das fehlerhafte Verhalten reproduzierbar hinbekommen

Bei einem harten Reset des TW (Spannung weg), sendet die Reboot 2) Logik einen Wert, der nicht unbedingt der letzte Wert auf dem knx war.

Getestet habe ich das so:
1. Reboot 2) Logik neu speichern, so dass alle Ein- und Ausgänge mit False initialisiert werden
2. Dann Zimmer O4 in den Zustand "Anwesend & Schlafend" schicken -> K-403 sendet nun ein True (0/2/120)
3. hart reset TW
4. Reboot 2) Logik sendet auf K-403 ein False

Bei Schritt 4. hätte ich auf K-403 ein True erwartet.
Deine Custom Logik heißt ja : Persistenz: Senden nach Reboot und nicht nach Reset Bei einem sauberen Reboot funktioniert die Logik auch.
Meine Wunschvorstellung wäre, dass die Persistenz auch im Fall eines harten Resets gegeben ist.

Bug oder potentielles neues Feature?

Viele Grüße
Martin

[StefanW]

Hi Martin,

Bug oder potentielles neues Feature?

Um den Flash zu schonen, werden NEUE Werte bei Aktivierung von Persistenz nur dann gesichert, wenn dieser Wert in den letzten 10 Minuten nicht schon einmal gesichert wurde.

Bislang war das ausreichend. Es gibt interne Diskussionen für eine bessere technische Lösung (übrigens zufällig gerade erst heute) aber ob die Kundschaft dies dann auch wünscht (und bezahlen möchte) wissen wir nicht. Es hat sich gezeigt, dass für so ausgefeilte Funktionen sich am Ende oft nur eine Minderheit interessiert.

Edit: Ich habe eine Umfrage eingestellt, ob für eine USV-Extension und / oder ein NV-RAM Extension ein Interesse besteht. Die Umfrage ist hier: viewtopic.php?f=9&t=2785

lg

Stefan

[martin]

Hallo Stefan,

vielen Dank für deine Rückmeldung.

Mit dieser Info:

werden NEUE Werte bei Aktivierung von Persistenz nur dann gesichert, wenn dieser Wert in den letzten 10 Minuten nicht schon einmal gesichert wurde.

konnte ich hier beschriebene Verhalten nachvollziehen:

1. Reboot 2) Logik neu speichern, so dass alle Ein- und Ausgänge mit False initialisiert werden
2. Dann Zimmer O4 in den Zustand "Anwesend & Schlafend" schicken -> K-403 sendet nun ein True (0/2/120)
3. hart reset TW
4. Reboot 2) Logik sendet auf K-403 ein False

Wenn ich zwischen den Schritten jeweils >10min warte, sendet K-403 ein True, wie erwartet

Bei aktiviertem DokMode bekomme ich das allerdings nicht reproduziert. D.h. wird nach >10min auch mal ein nicht persistenter Wert gesendet. Das würde auch erklären warum das Verhalten hier überhaupt aufgefallen ist; der Zustandswechsel (d.h. neuer Wert) war um 7:52Uhr (False); harter Reset (Stromausfall) um 8:35 Uhr mit falschem Wert (True) um ca. 9:30 Uhr nach dem wieder Spannung anlag; der letzte Wert in der Nacht davor um ca. 20 Uhr (True). Hier sollten die Persistenzkriterien (zur Speicherschonung) erfüllt sein, oder?
Ist diese Wechselwirkung mit dem Dokmode gewollt?


VG
Martin

[markusrohr]

Hallo Robert @Robert_Mini

ich habe noch eine Frage zum revidierten Baustein2. Im neuen Code sind die Ausgänge mit "c" (Change) definiert, im Bild noch wie ursprünglich mit "A" (always) aufgeführt. Welches ist die richtige Einstellung?

Beste Grüsse und schönes Wochenende
Markus