Probleme HomematicSocket und TimerEvents nach Update auf 5.5

Hallo an alle,

ich nutze seit ein paar Jahren IPS und war bisher auf Version 4.4 „stehengeblieben“. Never touch a winning team!

Nun habe ich den Teillockdown mal genutzt, um die Modernisierung anzugehen.

SSD am Raspi statt SD --> OK, klappt (noch mit IPS 4.4)
Skript zum regelmäßigen Image der kompletten SSD und Ablage auf NAS --> OK, klappt

Upgrade Sketch zu Buster --> OK, klappt mit ein paar Nacharbeiten (lirc z.B. für meine IR), dabei hat sich der Raspi schon die 5.5er gezogen

Upgrade IPS 5.5 auch zunächst unauffällig, bei genauem Hinsehen aber mit zwei für mich wichtigen Themen:

Problem(e):

  • Homematic Socket i.d.R. nach Neustart fehlerhaft, nicht verfügbar, nicht verbunden (Abhilfe schafft Deaktivieren und Aktivieren des Sockets - habe jetzt ein Skript dazu geschrieben, welches das überwacht / übernimmt- manchmal in Verbindung mit Neustart CCU) --> woher kommt das auf einmal?

  • Nach Reboot starten viele / alle? Timer-Ereignisse (man sieht es, dass das letzte Aktualisierungsdatum zum reboot war, obwohl das Ereignis nicht dran gewesen wäre. Somit lösen die natürlich sehr viel Unsinn aus) --> kann das sein? Was kann ich tun?

Wenn mir jemand bei den o.a. Problemen helfen könnte, wäre das schön.

Danke

Eric

PS: Anmerkungen:

  • schön ist, dass endlich wieder Diagramme in der App auch mehr als nur 1 Tag anzeigen
  • schön ist, dass sich Wochenpläner auch in der Konsole bearbeiten lassen
  • massiv nervt der Umstieg auf die Web-Verwaltungskonsole. Die (fast) neue Pro-Konsole ist im Prinzip ja das gleiche. Hier muss ich mich erst noch einwohnen, momentan bin ich noch zu „emotional“ (um nicht zu sagen gereizt bis wütend) für objektive Kritik
  • durch den Wechsel der PHP-Version sind etliche Änderungen (entfallene Funktionen, anders arbeitende Klammern bei Arrays, massive Intoleranz gegenüber schlechter Variablennutzung (früher hat einem PHP verziehen, wenn Zahlen ein string waren und diese dennoch addiert - z.B. HEX, jetzt muss man die erst zu DEC umwandeln) mitgekommen, die ein Nacharbeiten des Codes erfordern. Leider lässt sich das nicht mit Such und Find machen. Somit merkt man es erst, wenn es nicht geht
  • echo-Ausgaben aus den Skripten tauchen in der Pro-Console nicht in den Meldungen auf

Hi und danke für dein umfangreiches Feedback!

Zum Thema Pro-Konsole hast du, glaube ich, die richtig Einstellung. Es ist sehr viel Gewohnheit mit dabei und die meisten haben die Vorzüge bereits zu schätzen gelernt. Wenn noch etwas fehlt sind wir auch weiterhin dran diese einzubauen. Meld dich einfach sobald die erste Phase rum ist :slight_smile:

Das HomeMatic und Timer Problem ist bisher nicht bekannt. Kommt das nachstellbar? Kannst du im Log nachsehen mit welcher Meldung HomeMatic sich nicht öffnen lässt? Kannst du das mit den Timern nachstellen bzw. so erklären, dass ich es nachstellen kann?

echo Ausgabe sollten weiterhin angezeigt werden in der Pro-Konsole. Hast du da mal ein Beispiel, wo genau etwas ausgegeben werden soll und jetzt nicht wird?

paresy

Hallo,

hier erstmal etwas zu den Timern:

Habe 12:53 einen Neustart durchgeführt und danach ein Screenshot vom „Ereignisinformation“-Tab gemacht (nur relevante Ereignisse), welches Timer zeigt, die exakt nach dem Neustart ausgeführt wurden. Ich gehe davon aus, dass es nicht nur diese sondern alle waren (nur das die mit niedriger Zykluszeit von selbst angelaufen sind).

Dass das für Chaos sorgt, ist klar?

Was mir auffällt, (anderes Bild), dort wird die Uhrzeit gesetzt (um 1.5Jahr in die Zukunft) zwischen IPS betriebbereit und dem zeitlichen Start der ganzen Timer. Hat das Setzen der Uhrzeit des Rapsi eventuell damit zu tun? Habe so eine MakerHawk RPI DS1307 RTC Echtzeituhrmodul, von dem stammt die tatsächliche Uhrzeit. Der Raspi holt die sich von dort.
Kann das Ändern der Uhrzeit die Timer auslösen? Das war früher nicht so!
Da ich gleichzeitig Raspbian und IPS upgegradet habe ist natürlich jetzt unklar, wer von den beiden ggf. sein Verhalten geändert hat.

Allerdings sollte ja dann die Winter/Sommerzeitumstellung zukünftig auch Probleme machen.

Hilfe bitte! Der WAF (Woman Acceptance Factor) der Automatisierung sinkt!

Hallo,

zum Timerproblem hier die Lösung.

Beim Upgrade auf Raspbian Buster hat sich etwas bei der HW-Clock geändert. Habe die I2C-Treiber neu installiert und nochmal die Einstellungen überprüft (Anleitungen gibt es ja viele). Jetzt aktualisiert der Raspi nach dem Booten wieder artig die Systemzeit noch bevor der Symcon Dienst gestartet wird.

Zum Start von Symcon habe ich im Start-Skript auch eine Aktualisierung der Systemzeit enthalten (gehabt). Da nach dem Reboot neuerdings die Zeiten so weit auseinander lagen (1.5 Jahre), kam es wohl zu Problemen. Jetzt geht es wieder. Habe nun sicherheitshalber das im Start-Skrip auskommentiert und aktualisiere über Timer.

Ich kann nur vermuten, dass die Uhrzeitaktualiserung beim Systemstart in einem solch ungünstigen Moment passiert ist, der dann alle Timer starten ließ.

Vielleicht kann paresy das bestätigen?

PS:
Das Homematic-Thema kommt immer mal wieder. Scheint etwas mit den Funkmodulen zu tun haben (Meldung im IPS: Funkmodule können nicht geladen werden), d.h. Bidcos oder so läuft nicht korrekt. Wenn ich die Funkgeräte deaktiviere im IPS, geht es. Scheint also ein Homematic-Problem und nicht Symcon. CCU-Neustart löst das Problem bis zum nächsten Mal. Habe vor ein paar Tagen einen neuen Funkaktor angelernt. Der funktioniert zwar, wird aber nicht in der Homematic angezeigt. IPS findet ihn aber. Wer weiß, ich muss da nochmal ran. Ich sage Bescheid, wenn es gefunden und gelöst ist. Ein anderer Funkaktor zickt auch rum.

PPS:
Somit scheint mir Symcon 5.5 unschuldig an meinen 2 Umstiegs Problem-Themen.
Bleibt nur die (für mich) neue Konsole und die nervigen Code-Änderungen wegen der neuen PHP-Version. Zur Konsole werde ich noch ein paar Änderungswünsche äußern, das jedoch in einem anderen Fred.

Ja, wenn die Systemzeit springt, dann kann genau der von dir beschriebene Effekt eintreten, da wir die NextRuns berechnen und beim „Zeitsprung“ (1,5 Jahre) diese immer erreicht werden und somit sofort ausgeführt werden.

paresy