RaspberryMatic 3.75.7.20240420 – Neue Version

[klana]

Hab die Nighy jetzt drauf.
Zugriff per Browser im Vergleich mit der Version vom 30.11.23 immer noch zum Erbrechen langsam.
z.B. Aufruf "Einstellungen/Gewerke" -> 25 Sek.

Habe mich mal quer durch alles durchgeklickt...zumindest auf dem MacMini sind die Fernsterverschiebungen nicht mehr da.
DC und DS natürlich nach dem Boot oben...werde es jetzt mal bis morgen in Ruhe lassen.

Alle Logs habe ich nach dem Boot, als alles abgearbeitet war, gesichert.
CuxD Status, CuxD-Systemlog, CuxD-Kernellog, Raspi Systemlog (auf nur Fehler gestellt).

Kann ich gerne hier rein stellen, wenn gewünscht.

[Xel66]

HiDer DC ist ja eine Sache, aber bei mir eben Hauptproblem, dass eben immer wieder CPU auf "Anschlag" geht und die ganze Sache extrem langsam wird und so Verwendung net wirklich Sinn macht.

Dann betrachte die Sache mal nüchtern logisch. Der Duty Cycle ist der Anteil der Funkzeit, die das Modul pro Stunde senden darf. Wenn dieser hochgeht, wird viel ausgesendet. Von sich aus sendet die Raspberrymatic nicht exzessiv (merkt man daran, dass ohne Programmierung und Konfiguration der DC nicht ansteigt), sondern Sendevorgänge werden durch die Gerätekonfigration und/oder Programmierung des Anwenders (in Worten: Du) in Abhängigkeit von Gerätestatus und anderen Triggern und angelegten Bedingungen ausgelöst.

Insofern sitzt die eigentliche Ursache ca. 70 cm vor dem Bildschirm. Wie man dem DC auf die Spur kommt, ist nicht nur ein Mal hier im Forum zu finden. Und nein, es hat eher nichts mit der RM-Version zu tun, sondern vermutlich mit den jeweils herrschenden Bedingungen (Temperaturen, Uhrzeiten etc.) zum Zeitpunkt des Reboots. Und wenn bei Dir nach dem Reboot der DC in den Anschlag fährt, dann liegt es mit an Sicherheit grenzender Wahrscheinlichkeit an Programmen, die getriggert durch Initialwerte oder zyklisch übertragene Gerätestatus ihre Bedingungsprüfungen durchführen und zugeordnete Aktionen ausführen. Eine umfangreiche Benutzung von SONST in Programmen kann eine ähnliche Auswirkung haben.

Vermutlich hast Du auch irgendwo eine Schleife programmiert, die die CCU auslastet (extrem langsames WebUI) weil sie nur mit sich selbst beschäftigt ist. Ein weiteres Indiz, dass die Ursachen für Deine DC-Probleme in Deiner Programmierung liegen. Auch vergebliche Kommunikationen mit externen Servern (u.a. auch per URL angesteuerten Aktoren), weil sie nicht erreichbar sind oder sich deren IP durch Änderungen im Netzwerk geändert haben, können die CCU vorzüglich auf den Bauch legen. Auch hier ist nicht die Firmware die Ursache, sondern der Anwender, der diese Sachen nicht ausreichend gegen Fehlfunktion gesichert hat.

Gruß Xel66

[klana]

Schönen Guten Morgen,

so, nach einer Nacht mit dem NightlyBuild (3.75.7.20240426-b0d78d-tinkerboard) folgendes Ergebnis:

WebUI getestet:
- mit verschiedenen Browsern (Safari, Firefox, Chrome, Edge) getestet.
- iPad (iPadOS) per WLAN ,
- MacMini (OSX Sonoma) per LAN 1GB
- Lenovo Laptop (Win11) per LAN 1GB

Ergebnis:
1. alles unerträglich langsam (und nein, es liegt nicht am Netzwerk)

2. die Fenster "Einstellungen/Zusatzsoftware" und "Einstellungen/Zeit- und Positionseinstellungen" sind auf dem iPad
nach links unten verschoben.
Das Fenster"Zusatzsoftware" sogar so weit, dass das Schließen nicht mehr möglich ist.
Auf dem MacMini und dem Lenovo Notebook sind diese Fenster zwar auch verschoben,
aber nur leicht nach links (also nicht mehr mittig) und weiter bedienbar.

3. Der DutyCycle hat sich nach der Installation um die 30-39% eingependelt
- mit der Version vom 30.11.2023 liegt er bei 15-22%

4. Der CarrierSense ist nach der Installation zwischen 0 und 26%, und schwankt sehr stark und oft
- mit der Version vom 30.11.2023 liegt er bei 0-10%

5. Safari Browser auf dem iPad kann das Systemprotokoll nicht mehr komplett anzeigen.
Der "Wartekringel" läuft die ganze Zeit und hört dann irgend wann auf - das Systemprotokoll ist dann max bis zur Hälfte geladen.
Auf dem MacMini und dem Lenovo Laptop funktioniert das (aber dauert sehr lange)
Das Protokoll hat ca. 15 Bildschirmseiten.

6. Rollladen: 2 von 18 Stück sind heute morgen nicht hochgefahren.

7. Meldungen von PocketControl HM:
- Einlesen der Geräte usw. bei Start von PocketControl HM dauert deutlich länger als sonst
- Systemprotokoll wird hier komplett angezeigt.
- Messages werden zum Teil nicht gesendet oder kommen mit mehreren Minuten (einmal sogar 34 Min.) Verspätung an.

Ich habe alle Logs gesichert und kann die bei Bedarf als ZIP File (2,3 MB) zur Verfügung stellen.

[onkeltommy]

Hallo Xel

Danke für Deine ausführlichen Hinweise, aber wie schon gesagt, mir ist der DC "im Moment" "eher" unwichtig wenn das Grundsystem nicht "will"
Hoher DC nach Reboot bei meinen vielen Geräten bin ich gewohnt, einfach in Ruhe lassen und in 1-2h ist der Spuk vorbei und wieder alles "normal". Aussitzen und gut iss
Allerdings bei den letzten beiden Versionen immer wieder DC Warnung >80 (CS 0) und das merkt man natürlich. Ja, der DC geht nach der "Magic Hour" auch wieder runter, bleibt aber um 20-30% höher als eben V 30.01 und darunter

Tritt nicht auf bei den Versionen <=30.01.

Erklärt weiters nicht
-warum die Zentrale nach der Installation und für den ersten Boot in die WebUi ca doppelt solange braucht
-warum es während Boot zig Rega HSS Errors gibt (welche erst ab den Versionen nach 30.1. auftreten
-warum erneutes FW up/downgrade bis zum Runterfahren nach der Übertragung 5-10m braucht. (Updatevorgang dann aber wieder normal)
-warum die WebUi brutal langsam ist: Ein Test: anlegen einer SV; Button "neu" -> 10s bis Eingabefeld, SV anlegen, auf OK.....Sanduhr...nix mehr.
erneuter Versuch nach abmelden: Sanduhr ging nach 40s ca weg. Reload der SV Seite dauerte dann wieder halbe Minute.

.das ist alles "verschwunden" wenn ich wieder auf 30.1. bin

-DC - das wird ja von einigen hier beschrieben, dass mit den letzten 2 Versionen dieser raufgeht- 30.1. rein und alles wieder gut.

Das kleine Script welches die CPU Last in "jetzt/5m/15m" ausgibt.....bei den 2 letzten Versionen gibts da Werte 190/180/100 oder höher - und dann ist das Teil unbedienbar. Dann wieder gehts runter auf 30/20/80 oder 100/90/100 usw. Auch über 200 gabs schon Werte-
Auch nach einem Tag "in Ruhe lassen"

Version 30.1.: Fallweise 120/60/70 oder so, aber generell 14-30/40/40....und darunter....und das wars. Keine Auffälligkeiten.

Vielleicht kann Klana da mehr in Sachen Logs beitragen, er dürfte sich damit leichter tun als ich

[Gerti]

Hi,

besorge dir mal den SDV.
Damit kannst du in alle Deine Programme Debug Ausgaben einbauen lassen und diese protokollieren (z.B. in eine Systemvariable vom Typ Text).
Wenn du die dann auf protokolliert stellst, siehst du ggf. wo die Ursache liegt.

Gruß
Gerti

[MichaelN]

Zum DC gab es hier den Tipp nur für die Geräte "Routing aktiv" einzustellen, die es auch benötigen, also ohne Router die Zentrale nicht sicher erreichen.

Und als Router sollten dann auch nur ausgewählte Geräte eingestellt werden.

Das veränderte Verhalten liegt aber am FW Kern von eq3. Wird sich also auch nicht mehr ändern.

Zur Analyse der CPU Last wurde hier schon ausführlich geschrieben. Da kam mW nichts bei rum.

[NilsG]

Zum DC gab es hier den Tipp nur für die Geräte "Routing aktiv" einzustellen, die es auch benötigen, also ohne Router die Zentrale nicht sicher erreichen.

Und als Router sollten dann auch nur ausgewählte Geräte eingestellt werden.

Das veränderte Verhalten liegt aber am FW Kern von eq3. Wird sich also auch nicht mehr ändern.

Zur Analyse der CPU Last wurde hier schon ausführlich geschrieben. Da kam mW nichts bei rum.

Ich habe meine Geräte alle so zugeordnet, wie sie den besten Empfang haben, bzw an welchem Device (CCU od. Gateway).
Das hatte ich mie da auch so rausgelesen, dass das an der neuen FW von eQ3 liegt und bin fein damit, solange es funktioniert

[Xel66]

Ja, der DC geht nach der "Magic Hour" auch wieder runter, bleibt aber um 20-30% höher als eben V 30.01 und darunter

Nochmal, der DC hat ausschließlich was mit der "verbrauchten" Funkzeit zu tun. Es ist eher unwahrscheinlich, dass das an der Firmware liegt (weil sie von sich aus nicht Geräte wahllos anfunkt), sondern hat eher was mit Deiner Programmierung und der Konstellation zum jeweiligen Boot-Zeitpunkt zu tun. Und ein überbordender DC beim Reboot lässt eben auf massive Ausführung von Funkaktionen schließen, weil Programme durch Initialstatus (0°C, TFK "geschlossen", Aktoren AUS, Thermostate AUTO etc.) oder eben spätestens nach der ersten zyklischen Statusübermittlung getriggert werden.

Sprich, Deine Programmierung kann sich beispielsweise auch nach einem Reboot Sonnenuntergang anders verhalten, als vor Sonnenuntergang, wenn Dein Programmierfehler in einem Programm liegt, die z.B. diese Astrozeit als Bedingung enthält. Das ist jetzt nur ein Beispiel und kann sich auch auf jeden anderen Status beziehen. Somit hätte das nichts mit der Firmware zu tun, sondern ausschließlich mit der individuellen Konstellation.

Wenn Deine CCU lahm ist, dann ist die einzige Erklärung, dass das System massiv ausgelastet ist. Hierfür kommt eben auch wieder ein Programmierfehler, eine hängende externe Kommunikation oder auch ein inkompatibles Addon infrage und auch wieder nicht zwingend die CCU-Firmware. Wäre letztere die wirkliche Ursache, würde das Problem nicht nur bei einzelnen Nutzern auftreten, sondern massiv verbreitet sein. Ein überschaubarer Anstieg ist durchaus durch etwas geänderte Kommunikation möglich, aber eben nicht massiv. Auffälligerweise sind es aber immer die gleichen Anwender mit Problemen. Ob z.B. ständig Programme getriggert werden, kannst Du auch selbst in der Programmübersicht unter "Status und Bedienung" sehen. Bei den betreffenden Programmen ändert sich dann häufig (bei jeder Aktualisierung der Seite) der Zeitstempel. Da benötigt man nicht mal Logs.

Und ein hoher Carrier Sense kann auch von vielen zusätzlichen Gateways und deren massive Funktätigkeit herrühren, weil diese das Funkband genau so belegen. CS und DC werden ja pro Funkschnittstelle separat erfasst. Die CCU sieht quasi "eigene" Aussendungen über die eine Schnittstelle über eine andere (verschiedenen HAPs/LAN-Gateways) als "Störung" des Funkbandes. Genau darum hilft viel eben nicht viel, insbesondere nicht, wenn die verschiedenen Funkmodule/HAP/LAN-Gateways sich gegenseitig "sehen".

Gruß Xel66

[onkeltommy]

Hi

nochmals danke, ich werde mal wieder alle Programme durchgehen und auf Deine Tips untersuchen/anpassen.

OffTopic....ich gehe gerade weils ja Sinn macht die Geräte durch welche auf Routing aktiv stehen - wo es eben keinen Sinn macht, dass es aktiv ist.
Wollte mir dazu ein neues Gewerk anlegen um die umgestellten zu "markieren"...... neues Gewerk anlegen (3x probiert - XML Transport Error - Rega restart....wtf...

@ Hinweis wegen eq3 Kernel und so.....oje....hoffe nicht, dass ich bei der 30.1. jetzt mal stehen bleiben muss.

Nur....dass es nun bei der 30.1.er mit dem Gewerken nen Abflug gibt, ist vl auch ein Grund für die vielen Rega Fehler beim Boot mit der aktuellen FW...maybe...keine Ahnung

btw: vielen Dank dazwischen mal für Eure Tips und so

[Bernd-Joras]

Hallo miteinander ...

Ich habe mich ja gar nicht mehr getraut hier irgendetwas schlechtes über diese Version zu berichten …
=> siehe viewtopic.php?f=65&t=82334&p=802682#p802682

Trotzdem, irgendwas passt „bei meinen Systemen“, (zwei Mal RPI3B+) nicht mehr so gut wie mit der Vorgängerversion.
Ich habe nun mehrmals die neue und Vorgängerversion mit je Backups der Anderen Version eingespielt und das Verhalten verglichen.
Immer, aber nur bei der 3.75.7.20240420 habe ich ein erhöhten DC und ein CS von 10 sofort nach der Installation.
Der DC bleibt auch Tage danach erhöht der CS geht von zehn auf null und auch mal wieder auf 10.
Noch dazu von Zeit zu Zeit WatchDog: regahss-restart.
So etwas kann und konnte ich bei den Vorgängerversionen nicht beobachten.

SD Karte habe ich bei beiden Systemen ersetzt (durch neu) keine Änderung.

Ich würde nun auch alle Programme deaktivieren und immer Tageweise wieder eins aktivieren ... OG, das dauert Wochen ... Schei....

Wo kann ich hier noch ansetzen um den Fehler in meiner schlechten Programmierung / Zusammenstellung zu finden ?

Danke vorab, BGB