RaspberryMatic 3.61.5.20211113 – Neue Version

[ubittner]

In den Vorversionen kann ich das nicht beurteilen, da ich erst mit dieser Version auf Docker nutze und ich kein extra Thread dafür aufmachen wollte.

[pitje_87]

Was eine Performancesteigerung zur vorherigen Version. Klasse! Danke @jensmaus

[matthiasmatthias]

Inzwischen hatte ich mit dieser Version meinen zweiten "Absturz" bzw. Funkprobleme. Mit älteren Versionen hatte ich dieses Probleme noch nie.
Problemfall:
Ich drücke auf einer IP Fernbedienung eine Taste, die LED quittiert grün das die Übertragung zur Zentrale geklappt hat aber keiner der Aktoren reagiert.
Andere Schalter dagegen funktionieren verzögert. Also schaue ich auf die WEB UI der Zentrale. Duty Cycle 70 % (normal 12%) ohne das ein Update läuft. Carrier Cense bei 20 % (normal 1 %). Im Log einige Einträge Gerätekommunikation gestört zu verschiedenen Geräte alle nicht batteriebetrieben . Neustart der Zentrale . Alles wieder O.K .
Die Batterie betrieben Geräte die ich besitze (IP Fensterkontakte und Classic Bewegungsmelder) beschweren sich nicht über einen niedrigen Batteriestand.

[MichaelN]

Den CS kannst du eigentlich nicht durch einen Reboot reduzieren, da es sich um aktuell gemessene Störungen im Funkband handelt.
Zum erhöhten DC: erstmal alle Programme mit Skripten deaktivieren, die externe Geräte ansprechen. Wenn das nicht hilft, alle Programme mit Skripten deaktivieren. Hilft das auch nicht, alle Programme deaktivieren. Dann nach und nach wieder einschalten und schauen wann der DC wieder nach oben geht. Immer warten, da der DC erst verzögert reagiert

[matthiasmatthias]

Den CS kannst du eigentlich nicht durch einen Reboot reduzieren, da es sich um aktuell gemessene Störungen im Funkband handelt.

Wie gesagt nach dem Neustart war der Wert wieder unten und alles lief normal. Ohne Neustart bleibt das Problem stabil stehen , es ist also nicht so das irgendwann ein Fremdstörer ausgeschaltet wird und es geht wieder.
Klar kann ich im Fehlerfall mal alle Programme einzeln abschalten. Ich dachte das bringt nichts , da kein Programm einen Grund hatte irgendwas zu tun.

[Xel66]

Ich dachte das bringt nichts , da kein Programm einen Grund hatte irgendwas zu tun.

Denken bringt da nicht viel. Das System macht das, was der Anwender programmiert hat und nicht das was er denkt programmiert zu haben. Die CCU hat eine eigene Logik, die sich nicht unbedingt mit der menschlichen deckt. Ob Programme getriggert werden, kann man relativ einfach an den jeweiligen Zeitstempeln in der WebUI sehen. Der Zeitstempel sagt aber nichts daraus aus, ob auch wirklich ein DANN abgearbeitet wurde.

Gruß Xel66

[matthiasmatthias]

Denken bringt da nicht viel. Das System macht das, was der Anwender programmiert hat und nicht das was er denkt programmiert zu haben.

Das mag wohl stimmen wenn das Betriebssystem und die Hardware absolut Fehlerfrei sind.
Da es aber keine fehlerfreie Software gibt ,r kann der Fehler an mir liegen oder eben auch nicht , da aber meine Programme relativ einfach und überschaubar sind, lange nicht geändert wurden und in der Vergangenheit stabil funktioniert haben, würde ich das einfach mal als den unwahrscheinlichen Fall ansehen.

[MichaelN]

Man kann Annahmen treffen, das ist durchaus OK. Aber man sollte sich schon die Mühe machen diese auch zu überprüfen. Ansonsten ist es keine Annahme, sondern eine vorgefasste Meinung. Zum Vorgehen siehe Tips in meiner Signatur.

[Xel66]

...da aber meine Programme relativ einfach und überschaubar sind, lange nicht geändert wurden und in der Vergangenheit stabil funktioniert haben, würde ich das einfach mal als den unwahrscheinlichen Fall ansehen.

Das ist absolut kein Kriterium zur Entscheidung, ob aktuell nun ein Programm getriggert wird oder nicht. Was Du meinst, mal programmiert zu haben, muss sich nicht unbedingt mit der Abarbeitungslogik der CCU decken. Beispiele hierfür gibt es im Forum zuhauf. Und ein beispielsweise im Sommer angelegtes Heizungsprogramm aufgrund von logischen Überlegungen muss im Winter noch lange nicht wie eigentlich beabsichtigt laufen, nur weil es seit dem Sommer nicht angefasst wurde. Wenn sich irgendwelche angelegten Zusatzbedingungen geändert haben, dann kann auch das Programm grundsätzlich anders funktionieren (nämlich so, wie es der Anwender angelegt hat). Zufällig kaputte Programme kommen ab und zu auch mal vor. Aber ausschließlich im Zusammenhang mit oft veränderten oder kopierten Programmen. Wenn sie nicht geändert wurden, fällt diese Ursache aus.

Entweder willst Du die Ursache für eventuelles Fehlverhalten finden, dann musst Du die Programmliste an Hand der Zeitstempel prüfen und dann vermeintlich falsch getriggerte Progamme anlysieren, oder Du willst das als theoretische Abhandlung fahren. Die Erfolgsquote liegt erfahrungsgemäß nahe Null.

Gruß Xel66

[lansester]

Denken bringt da nicht viel. Das System macht das, was der Anwender programmiert hat und nicht das was er denkt programmiert zu haben.

Das mag wohl stimmen wenn das Betriebssystem und die Hardware absolut Fehlerfrei sind.
Da es aber keine fehlerfreie Software gibt ,r kann der Fehler an mir liegen oder eben auch nicht , da aber meine Programme relativ einfach und überschaubar sind, lange nicht geändert wurden und in der Vergangenheit stabil funktioniert haben, würde ich das einfach mal als den unwahrscheinlichen Fall ansehen.

Leider wird hier im Forum immer davon ausgegangen, dass Raspberrymatic heilig und fehlerfrei ist und grundsätzlich der Anwender etwas falsch macht.
Wenn man als Anwender irgendwelche Annahmen trifft, wird man belehrt, dass das auch zu überprüfen sei, aber die Grundsatz-Annahme, dass Raspberrymatic nicht schuld sein kann, die ist natürlich immer erlaubt.
Ich finde Raspberrymatic genial und bin den Entwicklern extrem dankbar!! Und ja, auch ich habe immer mit Anwendern zu tun, die einfach unfähig sind. Aber hier ist die Voreingenommenheit schon sehr heftig. Man nutzt Raspberrymatic seit vielen Jahren, hat schon 20 Versionen durch und bei der 21. gibt es dann plötzlich ein Problem, ohne dass außer dem Update in den letzten Wochen irgendwas am System verändert wurde und ein Fallback behebt das Problem reproduzierbar. Und trotzdem wird es dann so hin gestellt, dass es am Anwender liegen muss und man irgendwas falsch gemacht hat.
Da hat man sehr wenig Motivation sich überhaupt hier zu melden, dabei will man doch nur einen Hinweis geben damit ein möglicher Fehler behoben werden kann und dieses tolle System noch besser wird.
Mein Prinzip ist daher mittlerweile so. Ich mache ein Update (über SD-Karten-Tausch und Backup/Restore), schaue ob die neue Version in den ersten paar Tagen ohne Probleme läuft. Wenn ja, dann bleib ich dabei, wenn nicht, dann gehe ich zurück auf die alte Version und warte einfach 2-3 Versionen ab bis zum nächsten Versuch.
Erstaunlicherweise wurden alle Probleme (bis auf eines was sehr hartnäckig ist) die ich je reproduzierbar hatte immer auf wundersame Weise gelöst, obwohl es doch ganz sicher auch dabei an meiner Implementierung und nicht an Raspberrymatic gelegen haben muss.
Sorry für die Ironie und den Sarkasmus. Aber wenn ich diese Diskussion mit einem engagierten Nutzer lese und das man ihn belehrt, er solle keine Annahmen treffen aber es umgekehrt ständig gemacht wird, dann finde ich das eine sehr unausgewogene (und nicht faire) Einstellung und sage etwas dazu.....