RaspberryMatic 3.47.10.20190713 – Erfahrungsberichte

[roe1974]

Habe ich so gemacht und neu gestartet, NEO Server ist trotzdem "online" ??!?!?!?

Was funktioniert hat letztendlich war ein:

Code: Alles auswählen

rm -rf /usr/local/addons/mediola

Damit wird beim nächsten boot NEO Sever neu installiert, und er ist "offline"

lg RIchard

[mototeacher]

Hi,

update von 20190511 durchgeführt. Ergebnis: gemischt!!!
Schnell ging es bei mir noch nie, aber dieses Mal war ich über 30 Min. geduldig, bis die neue Version wieder hoch kam.
Was auffällt:
DC war vorher meist so bei 3 - 5 %, nach Update erst bei 20% und jetzt nach ca. 3h immer noch bei 14%
Ein Aussenfühler HmIP-STHO hing und zeigte 0°C und 0% Hum. an. Dann Kommunikationsfehler. Leiter rauf, Batterie raus und wieder rein - dann zeigte er wieder 38,5°C.
Ein Innenfühler zeigte 3262,5, aber dem war es gegönnt, weil er auf dem Dachboden sitzt und wir dort >50°C haben. Aber 48 oder 49°C hatte er schon angezeigt. Ist mir bewusst, dass er nur bis 35 Grad spezifiziert ist.
Dann hatte ich vom Umbenennen der DC Variablen gelesen und natürlich ausprobiert.
Ergebnis: Jetzt hatte ich 2 DC Variablen - eine mit dem original und eine mit dem neuen Namen.
Versuch die Umbenennung rückgängig zu machen ... immer noch 2 (DutyCycle und DutyCycle (1) )
Die zweite gelöscht:
Jetzt spinnt der numerische Wert auf der Startseite (-1%) und braucht ne Weile, bis er wieder stimmt.
Und die Bezeichnung des grafischen DC trägt nach wie vor den geänderten Namen, obwohl ich den ja wieder gelöscht hatte.
Fazit: never touch....
Und während ich das hier schreibe, springt mein DC auf 4%. Wie schrieb Jens? "Einfach abwarten..."
Mal sehen, was bis morgen noch so kommt.

Gruß,

Uli

[sauss]

Ola zwei fragen
Kann jemand folgendes Verhalten bestätigen….

Bild1.JPG (18.08 KiB) 1658 mal betrachtet

Bild2.JPG (19.88 KiB) 1658 mal betrachtet

Dies passiert immer wenn sich das WebUi Aktualisiert beim erneuten öffnen mit Löschen des Browser Caches ist diese Darstellung in Ordnung.

Zweite Frage ich nutze zwei gleiche Systeme mit dem gleichen Softwarestand. Nur ist die Bildschirm-Auflösung bei beiden Systemen im Browser (Mozilla) unterschiedlich.

[LibertyX]

Zu Frage 1

https://github.com/jens-maus/RaspberryMatic/issues/656

Zu Frage 2

evtl. versehentlich bei einer der beiden im Mozilla den Seiten Zoom verstellt?

[sauss]

Zu Frage 1

https://github.com/jens-maus/RaspberryMatic/issues/656

Zu Frage 2

evtl. versehentlich bei einer der beiden im Mozilla den Seiten Zoom verstellt?

Daran merkt man... das nun zulange hinter dem Monitor gehangen wurde. Gut .... daraus lernen wir das der Zoom für eine Webseite immer erhalten bleibt. Danke !!!

[Je.Vi]

Hallo,

der Updateprozess lief Problemlos. Leider steigt der DutyCyle innerhalb 30-40 Minuten nach dem reboot so stark an, dass es Kommunikationsprobleme gibt mit den Aktoren und Programmen. Ein herunterfahren und Kurzzeitiges entfernen der Stromzufuhr hat auch kein Ergebnis gebracht. Meine Konfig siehe Signatur.

Alle bisherigen Updates meiner RaspberryMatic liefen für mich bis zu diesem Release Problemlos.
Hat einer eine Idee ?

Anmerkung 2019-07-16 163602.png
Anmerkung 2019-07-16 163719.png

Hallo ich bin zwar geduldig, aber irgenwie habe ich das gefühl da stimmt etwas nicht.

Anmerkung 2019-07-24 093318.png (10.58 KiB) 1564 mal betrachtet

[Xel66]

.... aber irgenwie habe ich das gefühl da stimmt etwas nicht.

Würde ich auch so sehen, da die CCU bis auf wenige Ausnahmen nicht von selbst mit den Aktoren spricht, liegt die Ursache mit relativ hoher Sicherheit in Deiner Programmierung. Vermutlich spielen irgendwelche Status-Rückmeldungen und darauf reagierende Programme Ping-Pong. Hier hilft nur die Standardvorgehensweise (Programme deaktivieren und nachfolgend unter Beobachtung des Duty Cycle wieder reaktivieren) um die Ursache für ein solches Funkfeuer zu finden.

Gruß Xel66

[Je.Vi]

.... aber irgenwie habe ich das gefühl da stimmt etwas nicht.

Würde ich auch so sehen, da die CCU bis auf wenige Ausnahmen nicht von selbst mit den Aktoren spricht, liegt die Ursache mit relativ hoher Sicherheit in Deiner Programmierung. Vermutlich spielen irgendwelche Status-Rückmeldungen und darauf reagierende Programme Ping-Pong. Hier hilft nur die Standardvorgehensweise (Programme deaktivieren und nachfolgend unter Beobachtung des Duty Cycle wieder reaktivieren) um die Ursache für ein solches Funkfeuer zu finden.

Gruß Xel66

Habe zwar in den letzten Monaten nichts an der Konfiguration geändert und bis zum letzten Update gab es nie Probleme.
Aber ich werde das mal Testen.

[Xel66]

Ob Du irgendetwas verändert hast, ist völlig unerheblich. Jetzt herrschen evtl. anderen Bedingungen, die ggf. geeignet sind, Deine CCU in eine Programmschleife zu schicken. Ein Beispiel wäre eine von der Außentemperatur abhängige Heizungssteuerung, die jetzt Deine Thermostate wegen der hohen Temperaturen dauerhaft in den ECO-Modus schickt o.ä. und dieser Vorgang durch den Systemstart initiiert wird (oder was auch immer). Normalerweise sollte sich ein Duty Cycle spätesten nach einer Stunde normalisiert haben. Ein Anstieg mach dem Reboot ist normal wenn auch nicht zwangsweise notwendig, wenn man seine Programme etwas optimiert hat (Abfrage des Iststatus vor dem Aussenden von Befehlen).

Gruß Xel66

[Je.Vi]

Ob Du irgendetwas verändert hast, ist völlig unerheblich. Jetzt herrschen evtl. anderen Bedingungen, die ggf. geeignet sind, Deine CCU in eine Programmschleife zu schicken. Ein Beispiel wäre eine von der Außentemperatur abhängige Heizungssteuerung, die jetzt Deine Thermostate wegen der hohen Temperaturen dauerhaft in den ECO-Modus schickt o.ä. und dieser Vorgang durch den Systemstart initiiert wird (oder was auch immer). Normalerweise sollte sich ein Duty Cycle spätesten nach einer Stunde normalisiert haben. Ein Anstieg mach dem Reboot ist normal wenn auch nicht zwangsweise notwendig, wenn man seine Programme etwas optimiert hat (Abfrage des Iststatus vor dem Aussenden von Befehlen).

Gruß Xel66

Habe seit ca. 1,5 Std alle Programme inaktiv nix ändert sich am Zustand. Danke für den Tip