PI-GPIO zeigte plötzlich 100% Last auf dem Wirk- und dem Test-Pi.
Mit HTOP konnte ich aber sehen das die Auslastung nur bei 27-30% lag.
Den TestPI erst einmal ein Update gemacht. Da nach startete der Pi3B nicht mehr. Bootloader zerschossen.
Auf Grund dieser Erfahrung - erst einmal eine Datensicherung auf dem Wirk-Pi gemacht.
Der IPS-Dienst dauerte ewig lang bis er stoppte. Bei der Überprüfung des Archiv, sollte eine Reaggregation durchgeführt werden. System sehr langsam, bei HM wird zwar sofort geschaltet, aber Rückkanal dauert ewig bis der richtige Status angezeigt wird. Das gleiche bei den Shelly`s und Tasmota .Eine Reaggregation von 444 Datensätzen hat über 20min gedauert. Eine andere Settings habe ich schon ausprobiert. HTOP zeigt an das der IPS-Dienst in der Spitze max 37% braucht.
Ich brauche das Logging für den Holzvergaser - sonst kann man nicht erkennen wenn die Puffer leer sind. Im Sommer wäre das mir das egal, jetzt wird der Ar… kalt
Andreas
PS
Was mir noch im Archiv aufgefallen ist, das einige Variablen (Zähler Variablen) ein Ausrufungszeichen haben und angezeigt wird das die Variable nicht geloggt wird.
Also so langsam bin ich am verzweifeln. Instanzen lassen sich nicht löschen. Fehlermeldung: Der Rückkanal ist ausgelastet, bla, bla bla, kontaktieren sie den Symcon Premium-Support. SSD ist übrigens ok.
Antworte ich mir einmal selber. Zur Info: es lag am PiGPIO. Ich monitore 4 x Pi3B + IPS-Pi 4B und aus irgend einem Grund hat es hier Probleme gegeben. Das sich weder die Sockets, noch die Splitter vernünftig haben deaktivieren zu lassen war es eine Sisyphusarbeit herauszufinden an was es lag. Da auch kein Debug möglich war. Zwei Tage versaut. :rage: Ich hatte keinerlei Updates gemacht, somit kann ich mir nicht erklären woher der Fehler gekommen ist.
danke für deine Rückantwort.
Problematisch war das auch kein Debug möglich war und ich erst nach dem ich blödsinniger Weise angefangen hatte, zwei Variablen reorganisiert hatte, das Problem sich vergrößert hatte. laut TOP der IPS Dienst der vorher nur max 37% Prozessorlast in Anspruch genommen hat, plötzlich 100% Last gebraucht hat. Der Speicherverbrauch war aber ok. Leider hatte ich kein Ersatzsystem, da wir immer noch vom Lieferanten keine Pi4B 4MB erhalten haben.
in diesem Fällen ist es immer zu empfehlen dem Entwickler eine Nachricht zukommen zu lassen.
Das Raspberry Pi-Monitoring läuft im Wesentlichen über SSH2-Zugriffe über die phpseclib.
Möglicherweise ist hier ja ein Fehler der IPS2GPIO damit komplett „lähmt“?
Ich werde diesen Hinweis mal prüfen…
Sorry das war kein Vorwurf von mir - nur ein Hinweis. Habe leider zur Zeit andere Probleme, so dass ich dem Ganzen keine besondere Aufmerksamkeit mehr gegeben hatte.
so habe ich das auch nicht verstanden. Geht nur darum das ich hier eher zufällig den Thread zur Kenntnis genommen habe - selbst auf der Suche warum IPS2GPIO nicht mehr „so rund läuft“.
Ich habe einmal den RPi-Monitor deaktiviert, subjektiv läuft das Modul, insbesondere die I2C-Kommunikation jetzt deutlich schneller, eigentlich so wie ich es gewohnt war.
Es ist also sehr gut möglich das die phpseclib nicht mehr sauber läuft…
