[Problem] [V1.5 RC7.1] TW nach Neustart Logik-Probleme

[Tomtheripper]

TW2400 V1.5 RC7.1

Hallo,

ich nehme aktuell Änderung an meiner Stromverteilung vor, weswegen des Öfteren der Strom auch beim Timberwolf weg ist (wird natürlich ordnungsgemäß runtergefahren).

1.: Was genau muß ich einstellen, damit die Logiken wie z.B. Zeitschaltuhren (alle absolut) wieder von selbst "anspringen"?
Das funktioniert nämlich bei mir nicht.
Heute früh z.B. Die Warmwasser-Zirk.Pumpe wird angesteuert über Zeit, Präsenz und Temperatur. Heute rein ins Bad - und nix. Glastaster zeigt an: Zirk. aus - Wassertemp (im Bad) 23 Grad . Runter zum Verteiler und den Aktorkanal manuell betätigt, Pumpe läuft, also ein Logik-Problem.

Da kommt gleich noch meine zweite Frage:
2.: Wie gehe ich sinnvoll vor, um den Logik-Fehler einzukreisen?
Wenn ich z.B. ne Logik über das Plus-Zeichen aufmach, kommt bei manchen erst mal "modified" und ich muss erstmal speichern, um den Doktormodus zu aktivieren, allerdings nicht bei allen Logiken. Warum?
Das verwirrt mich.
Übrigens war kürzlich auch die TW-Uhrzeit 1-2 Minütchen verschoben, erst ein neues abspeichern des Zeitservers (bei mir die FritzBox) hats korrigiert.

Und die dritte Frage:
3.: Kann ich zusammengehörende Logiken irgendwie "gruppieren"?

Beste Grüße
Thomas

[Matze76]

Hallo Thomas,

1.: Was genau muß ich einstellen, damit die Logiken wie z.B. Zeitschaltuhren (alle absolut) wieder von selbst "anspringen"?

Einfach die Persistenz aktivieren, das ist die Schaltfläche mit dem Unendlichkeits-Zeichen in jeder Logik:

3.: Kann ich zusammengehörende Logiken irgendwie "gruppieren"?

Du kannst das z. B. über die Tags machen (und danach filtern).
Darüber hinaus werden die Logiken nach Namen sortiert angezeigt. Ich habe die Anzeige-Reihenfolge meiner Logiken darüber etwas strukturiert, indem ich den Bezeichnungen der Logiken Nummern voranstelle (z. B. 01, 02, 03A, 03B).

[Dragonos2000]

Zeitschaltuhren sollten aber auch ohne Persistenz anlaufen. Beim Restart vom TWS können jetzt aber verschiedene Szenarien eintreten, die zu unerwünschten Effekten führen- da müsste man jetzt das Setup genau kennen.

Ein Beispiel aus der Praxis (nur um mal zu zeigen, wo überall komische Effekte herkommen können):
Ich habe KOs, die verschiedene Automatiken aktivieren, die ich über die Visu bei Bedarf ausschalten kann. Diese habe ich in einem OpenHAB Docker visualisiert, ein TWS KO ebenfalls in dieser Gruppe. Bei einem Neustart frägt OpenHAB die KO ab, der TWS reagierte darauf ebenso (weil ich das Lese-Flag noch gesetzt hatte), sowie der Busteilnehmer, der eigentlich den ReadRequest beantworten sollte. Je nachdem wer schneller im Beantworten war, hab' ich mir die Automatik ungewollt ausgeknipst.

Schau' mal im Busmonitor (evtl. per ETS, weil der TWS noch nicht richtig oben ist), was beim Restart auf dem Bus passiert.
@S. Kolbinger Ich hatte ja auch Probleme, dass der Initaltrigger nicht kam und manche Zeitbausteine nicht angelaufen sind. Das sollte doch aber behoben sein, oder?

Und @Tomtheripper , bitte die Versionsinformationen auch in den Thread-Titel!

[Tomtheripper]

Vielen Dank mal an euch!

D.h., am besten bei jeder Zeitschaltuhr die Persistenz aktivieren?

Ich hab mal den TW-Rebott geloggt und als *.pdf beigefügt.
Ist ja krass, was da beim Neustart abgeht, werden da vom TW alle Objekte abgeglichen?
Der Log-Inhalt sagt mir aber nicht wirklich was...

ETS-Busmonitor bei TW-Reboot.pdf

Grad nochmal alle Logiken kontrolliert, jetzt kann ich den Doktormodus bei allen ohne vorheriges speichern ("modified") aktivieren. Vielleicht war das Neuspeichern noch einem Firmware-Update geschuldet.

Gruß
Thomas

[StefanW]

D.h., am besten bei jeder Zeitschaltuhr die Persistenz aktivieren?

Ja, unbedingt, nur dann funktioniert das richtig.

Bitte beachten:

==> Im Modus Persistenz werden auch Zeitevents beim Einschalten nachgeholt.

Das kommt Dir mit Deiner Zirkulationspumpe durchaus entgegen, Beispiel:

- Um 7:00 Uhr soll die Pumpe gemäß Logik starten
- Um 6:30 Uhr wird der Server heruntergefahren wegen Umbau an der Verteilung
- Um 7:25 fährt der Server wieder hoch, da ist das Zeitschaltereignis um 7:00 schon vorbei
- Der Server holt das nach, also um 7:27, wenn der Server hochgefahren ist, wird der Trigger von 7:00 (nachträglich) ausgeführt, was dazu führt, dass die Zirkulationspumpe zwar zu spät aber trotzdem anläuft.

Bitte aber beachten, dass kann auch unerwünschte Ergebnisse haben:

- Jemand richtet sich eine Logik ein, die zweimal am Tag irgendwas startet und dann war der Server eine Woche offline (was auf der Baustelle ja durchaus passieren kann). Wenn nun nach einer Woche eingeschaltet wird, könnte es passieren, dass 14 mal hintereinander ein "Start" passiert. In den meisten Fällen wird das nichts machen, aber trotzdem sollte man das bedenken und dann die betreffende Zelle nicht auf "persistent" schalten.

Grad nochmal alle Logiken kontrolliert, jetzt kann ich den Doktormodus bei allen ohne vorheriges speichern ("modified") aktivieren. Vielleicht war das Neuspeichern noch einem Firmware-Update geschuldet.

Ja, ist ein neues Feature

lg

Stefan

[Tomtheripper]

[Dragonos2000]

@StefanW Grundsätzlich sollten Timer/Zeitlogiken aber auch ohne Persistenz anlaufen. Ich hatte ja einen Bug, bei dem das sporadisch nicht geklappt hat. Ob verpasste Events nachgeholt werden ist nochmal was anderes...

[Dragonos2000]

@Tomtheripper Da werden alle möglichen Stati beim Start abgefragt, dass macht der TWS aber nicht von sich aus. Das müsste von einem Docker (Visu,...) kommen, der das macht. In diesem Zusammenhang sollte man darauf achten, welche Busteilnehmer die Leseanfragen auf die jeweilige GA beantworten dürfen (Lese-Flag). Sonst verursacht das einerseits zusätzlichen unnötigen Traffic und kann andererseits auch inkonsistente Zustände verursachen (Beispiel von mir weiter oben).

Die Spalte "Typ" ist leider zu schmal, aber wenn ich das richtig interpretiere, da kommt ein Read und Dein TWS als auch der Aktor antworten darauf. Das ist der Punkt, an dem es inkonsistent werden kann: Der Aktor ist eigentlich führend was den Status angeht, der TWS antwortet aber ebenso und kann potentiell einen anderen/falschen Status haben. Je nach Timing/Reihenfolge hast Du dann anschließend in der Visu einen falschen Status.

Was ist die PA 1.1.202 ? Vermutliche eine weitere PA vom TWS, oder?

[Tomtheripper]

@Dragonos2000

Ich denke, die PA 1.1.202 ist ein Tunnel vom Wolf?
Ich lege noch für alle Tunnel-Adressen, die möglich sind, in ETS auch ein Dummy-Objekt an (wenn das funktioniert?).

Im Docker auf dem TWS läuft IOBroker, sonst nix mehr.

Der Aktor-Status - der ja das "Sagen" hat - steht bei den Abfragen immer an letzter Stelle, der TWS-Status kommt davor.
Vielleicht teilt der TWS seinen aktuellen Status beim Start mit und übernimmt dann den nachfolgenden Status des Aktors?

Beispiel mit dem Status des Kühlschranks:
108 16.10.2019 11:31:28,624 1.1.202 6/1/107 Kühlschrank Keller Status 5 GroupValueR…
109 16.10.2019 11:31:28,650 1.1.200 Timberwolf Server 6/1/107 Kühlschrank Keller Status 6 GroupValueR… 1.011 Status $00 | Inaktiv
110 16.10.2019 11:31:28,678 1.1.24 AZI-0616.01 Schaltaktor 6-fach … 6/1/107 Kühlschrank Keller Status 6 GroupValueR… 1.011 Status $01 | Aktiv


Die Tunnel-Abfragen oder Statusmitteilungen sind allesamt unvollständig,

Wenn das so nicht richtig ist, wie soll ich richtig konfigurieren?
(Ist mein erstes KNX-Projekt - Autodidakt. Flags hab ich eigentlich noch nie geändert...)

EDIT:
Ich kann keine Dummy-Applikation für die TW-Tunnel-PA's anlegen. ETS zeigt die nachfolgenden PA's als belegt an.

[StefanW]

@StefanW Grundsätzlich sollten Timer/Zeitlogiken aber auch ohne Persistenz anlaufen.

Tun sie auch. Die Persistenz sorgt dafür, dass nachgeholt wird.

Ich hatte ja einen Bug, bei dem das sporadisch nicht geklappt hat.

Der Bug kam mit der RC5 und wurde gleiche mit RC6 - die wir deshalb vorgezogen hatten - behoben worden.

Stefan