FHEM - Hausautomations-Systeme > MAX

Nebeneffekt -> Server restart lässt credits hochlaufen mit "time information"

<< < (2/3) > >>

Wzut:

--- Zitat von: Wzut am 11 März 2021, 17:39:50 ---Klären kann man das nur mit einem verbose 5 Log des CUL_MAX Device.
Im Log sieht mann dann immer wie groß der Zeitunterschied aktuell ist und warum CUL_MAX meint diese nachziehen zu müssen.

--- Ende Zitat ---
Bis heute kein Log !

arm9999:
Sorry für die verspätete Antwort, habe es eben erst gesehen ...

@adn77,
wirklich lösen konnte ich das Problem nicht, habe aber stattdessen einen workaround für mich gefunden.

Aber mal kurz zusammengefasst:
- Das Problem besteht nur auf einer Linux/Debian Hardware, unter Windows hatte ich den Effekt nicht.
- Hardware CUL = geflashter MAXLAN mit CUBe
- FHEM Service wird explizit (und mit Verzögerung) nach dem Netzwerkinterface und dem NTP Dienst gestartet (bringt keine Veränderung)
- broadcastTimeDiff auf 45 Sekunden bringt auch keine Veränderung
- tritt nur auf, wenn FHEM das erste Mal neu gestartet wird
   => meine Vermutung: bei der Initialisierung der Variablen für den CUL geht was schief/fehlt was

mein Workaround nach dem FHEM das erste Mal gestartet wurde:
   -> 2x den Befehl Sendqueue löschen auslösen
   -> danach "shutdown restart" für FHEM

Nachteil, die Credits sind bereits hochgelaufen, aber reduzieren sich dann wieder.

@Wzut,
wirklich dahinter gekommen was die Ursache ist bin noch nicht. Was ich aber erkennen kann:
- es hängt mit dem Neustart von FHEM auf einer LINUX/Debian Hardware zusammen
- der NTP Dienst ist nicht der Auslöser
- die broadcastTimeDiff hat keinen Einfluss
- als erstes taucht im logfile immer einer der WTs auf, danach schaukelt es sich hoch
- obwohl auf jede Nachricht des CUL eine Quittung und Antwort der WTs erfolgt, werden diese immer wieder mit der gleichen Nachricht
   angefunkt, das löst dann die Kettenreaktion aus.

  -> daher meine Annahme, das nach der "Erstinitialisierung von FHEM und MAXCUL" irgendwo ein Zähler/eine Variable noch nicht richtig
       gesetzt ist. Nachdem die ersten Nachrichten ausgetauscht wurden, scheint diese Variable belegt worden zu sein, so dass ein "FHEM
       shutdown restart" den CUL und das Modul wieder korrekt initialisiert.

- getestet habe ich auch, ob nur eine Neuinitialisierung des CUL etwas bewirken kann, hat leider keine Veränderung gegeben.
       
- Der Ansatz könnte aber sein, dass es etwas mit der Sendqueue zu tun hat. Denn der Befehl "Sendqueue löschen" bewirkt auf jeden Fall etwas.
  Lässt man diesen Weg und macht nur einen "FHEM shutdown restart"  schaukelt sich das System weiter hoch.
 

Wzut:

--- Zitat von: arm9999 am 29 Oktober 2021, 09:11:14 ---mein Workaround nach dem FHEM das erste Mal gestartet wurde:
   -> 2x den Befehl Sendqueue löschen auslösen
   -> danach "shutdown restart" für FHEM

--- Ende Zitat ---
shutdown restart löscht auch die Sendeque ! D.h. den Schritt könntest du dir sparen.
Aber wie soll man hier wirklich weiterhelfen wenn die simple Bitte nach einem verbose 5 Log so hartnäckig ignoriert wird ?

arm9999:
Hallo Wzut,

sorry, wollte nicht unhöflich sein und deine Bitte ignorieren. Ich bin seit ein paar Monaten viel unterwegs und dann habe ich es auch verbaselt, nachdem der workaround funktionierte. ( Die Befehlssequenz wird bei mir von einem Home Assistant Server (weiterer Server in meiner Hausautomatisierung) quasi remote auf FHEM ausgeführt, wenn der Fehler auftritt). Hole ich aber nach!

Welche Geräte/Module soll ich denn auf den Level5 setzen - nur den MaxCUL? Reicht dir dann eine Kopie der Ansicht aus dem Event Monitor oder welchen log brauchst du genau?

Der Hinweis von dir, dass beim "shutdown restart" auch die Sendequeue gelöscht wird, ist ein wichtiger Tipp. Denn nur ein "shutdown restart" löst das Problem mit den Credits nicht, erst wenn man den Befehl vorher ausführt und dann einen "shutdown restart" macht, gelingt es. Hier scheint der Unterschied zu liegen - was macht denn die Routine noch vor dem löschen der Sendequeue?

LG

arm9999:
Nachtrag zu meinem letzten Post:

Ich verwende einen geflashten MaxCUL mit der SW Version:
V 1.26.08 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)

Der CUL wird via seiner IP Adresse angesprochen, das DEF lautet:
192.168.x.xxx:2323 0000

Default Init-String in FHEM:
X21
Zr
Za0xxxx1  (xxxx = natürlich die richtige Adresse des CUL)
Zw111111

Als "Reset-Sequenz" für meinen MaxCUL, wenn die credits nach einem Neustart aus dem Ruder laufen, verwende ich:
- set MaxCUL raw B00
- 2 Sekunden warten
- set MaxCUL raw X21 Zr Za0xxxx1 Zw111111
- 4 Sekunden warten
- set MaxGW deleteSendQueue
- 4 Sekunden warten
- set MaxGW deleteSendQueue
- shutdown restart

Danach geht der Credit Wert auf "natürlichem Wege", sprich wie vorgeschrieben, wieder kontinuierlich auf den Wert 0 zurück.
Die Sequenz oben ist experimentell entstanden und vlt. ist der eine oder andere Zwischenschritt redundant, aber nur so konnte
ich das Problem als workaround fixen. Aktuell wird bei jedem Neustart von FHEM, z.B. nach einem update, das "Credithochl-
aufproblem" ausgelöst.
 

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln