RaspberryMatic - Verbesserungsvorschläge/Wünsche

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Familienvater
Beiträge: 7151
Registriert: 31.12.2006, 15:18
System: Alternative CCU (auf Basis OCCU)
Wohnort: Rhein-Main
Danksagung erhalten: 34 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von Familienvater » 30.01.2019, 11:23

Hi,

der Updatevorgang HM und HmIp unterscheidet sich grundsätzlich, bei HM haben die Geräte zu wenig Speicher, um zwei Firmware-Versionen gleichzeitig speichern zu können, also muss das HM-Gerät in einen Firmware-Updatemodus gebracht werden, wo die komplette Firmware am Stück zum Gerät gefunkt werden muss, das dauert entweder max. ca. 30 Sekunden oder es geht "schief", weil zuviele Übertragungsfehler passiert sind, und der Aktor ist solange nicht mehr nutzbar, bis der DC und die äußeren Bedingungen es erlauben, die Firmware am Stück komplett zu übertragen.
Bei HmIP werden immer nur kleine Brocken der Firmware zum Gerät gefunkt, weil die Geräte mehr internen Speicher haben, so das die neue Firmware parallel zur alten mit auf das Gerät passt. Weil aber ein HmIP-Gerät evtl. nur über zwei Router erreichbar ist, müssen die Brocken klein genug sein, damit die jeder Router empfangen, zwischenspeichern und wieder weiterleiten kann, ohne das er selber deswegen Sendezeit-Probleme bekommt.
Und die Größe oder Frequenz, mit der "Brocken" von der Zentrale gesendet werden, ist vom zur verfügungstehenden DC abhängig, je höher der "Basis"-DC ist, desto weniger kann für Updates genutzt werden (und die Updates werden nur bis ca. 50% DC verfunkt, danach wird auf bessere Zeiten gewartet)

Der Familienvater

Hütte
Beiträge: 746
Registriert: 08.02.2017, 11:08
Hat sich bedankt: 32 Mal
Danksagung erhalten: 75 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von Hütte » 30.01.2019, 12:07

Super Erläuterung. Die sollte mal bei Allgemeinen Informationen fest verankert werden. Das würde, unter der Voraussetzung, der Nutzer benutzt die Suchfunktion, permanente Nachfragen oder "Beschwerden" bezüglich Dauer von FW-Updates reduzieren.

Benutzeravatar
onkeltommy
Beiträge: 1383
Registriert: 07.05.2016, 08:03
Wohnort: Wien
Hat sich bedankt: 28 Mal
Danksagung erhalten: 26 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von onkeltommy » 30.01.2019, 12:44

hbrockmann hat geschrieben:
27.01.2019, 18:34
Visu hat geschrieben:
27.01.2019, 14:05
ich würde mir für 2019 wünschen, dass die Filter so lange gesetzt bleiben, bis man den Fiter wieder manuel auflöst.
+1
+1

:D
lG
Thomas
--------------------------
RaspberryMatic 3.73.9.20240130 @ TinkerS (Produktivsystem) & Historian @ SynologyVM & 2x RB3+ @ Nachwuchs

hbrockmann
Beiträge: 32
Registriert: 22.01.2013, 17:21
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von hbrockmann » 30.01.2019, 12:46

aber auch mit dieser guten erläuterung wäre es wünschenswert, eine möglichkeit zu schaffen das der "max. dc" während des updatevorgangs manuell konfiguriert werden kann.
ein max. "update-dc" von 50% "verschenkt" einfach in einigen fällen zu viel zeit.

wenn ich die wahl habe zwischen tagelangen updatevorgängen und dem risiko, das die zentrale mal innerhalb einiger minuten ein ankommendes paket nicht empfangen könnte, würde ich während manuell angestoßener updates zweiteres wählen wenn der updatevorgang dadurch erheblich verkürzt wird.

Benutzeravatar
arrisun
Beiträge: 181
Registriert: 19.01.2016, 18:43
Wohnort: Köln
Hat sich bedankt: 9 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von arrisun » 30.01.2019, 12:49

onkeltommy hat geschrieben:
30.01.2019, 12:44
hbrockmann hat geschrieben:
27.01.2019, 18:34
Visu hat geschrieben:
27.01.2019, 14:05
ich würde mir für 2019 wünschen, dass die Filter so lange gesetzt bleiben, bis man den Fiter wieder manuel auflöst.
+1
+1

:D
Das wäre wirklich was Feines :D
Liebe Grüße
Andy

Das Verhältnis zwischen meiner Frau und mir lässt sich ungefähr so beschreiben: Ordnungsamt trifft auf Wanderzirkus


!!! Arbeiten am 230V Netz, bzw.an 230V Geräten nur von Fachleuten durchführen lassen !!!


193 Kanäle in 66 Geräten und 45 CUxD-Kanäle in 3 CUxD-Geräten

Familienvater
Beiträge: 7151
Registriert: 31.12.2006, 15:18
System: Alternative CCU (auf Basis OCCU)
Wohnort: Rhein-Main
Danksagung erhalten: 34 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von Familienvater » 30.01.2019, 14:18

Hi,
hbrockmann hat geschrieben:
30.01.2019, 12:46
aber auch mit dieser guten erläuterung wäre es wünschenswert, eine möglichkeit zu schaffen das der "max. dc" während des updatevorgangs manuell konfiguriert werden kann.
ein max. "update-dc" von 50% "verschenkt" einfach in einigen fällen zu viel zeit.

wenn ich die wahl habe zwischen tagelangen updatevorgängen und dem risiko, das die zentrale mal innerhalb einiger minuten ein ankommendes paket nicht empfangen könnte, würde ich während manuell angestoßener updates zweiteres wählen wenn der updatevorgang dadurch erheblich verkürzt wird.
das wird mit Sicherheit ein Wunsch bleiben, Jens kann da nichts tun, das sind Dinge, die tief im HmIP-Server liegen, wo es auch zur Zeit keine "öffentlichen" Methoden gibt, um irgendwelche Parameter von außen zu verstellen. Und die Nebenwirkungs-Gefahr ist nach meiner Meinung für EQ3 zu hoch, das die sich damit ein Bein stellen, weil es zuviele Konstellationen geben kann: wie gesagt, es könnten 2 Router involviert sein, die auch einen DC haben, der jeweils eingehalten werden muss, und die Router müssen ggf. aber auch "DC-teure" Dinge vollkommen unabhängig von der Zentrale machen können, nämlich Direktverknüpfungen zwischen den Geräten, weshalb die ganze Kette nicht überlastet werden darf. Und n-Betriebsmodi, ist der Aktor direkt ereichbar, dann Limit 70% DC, wenn über einen Hop dann nur 50% DC etc. wird EQ3 nicht machen, weil wir auch nicht wissen, welche Codebasis sich der HmIP-Server mit der Cloud teilt (vielleicht nicht ohne Grund heißt der auch crRfd -> cloud ready Rfd)

Der Familienvater

TobiS
Beiträge: 7
Registriert: 30.01.2019, 12:47

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von TobiS » 30.01.2019, 14:37

arrisun hat geschrieben:
30.01.2019, 12:49
onkeltommy hat geschrieben:
30.01.2019, 12:44
hbrockmann hat geschrieben:
27.01.2019, 18:34
Visu hat geschrieben:
27.01.2019, 14:05
ich würde mir für 2019 wünschen, dass die Filter so lange gesetzt bleiben, bis man den Fiter wieder manuel auflöst.
+1
+1

:D
Das wäre wirklich was Feines :D
+1

Benutzeravatar
jmaus
Beiträge: 9817
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1855 Mal
Kontaktdaten:

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von jmaus » 30.01.2019, 15:29

Bevor hier mehr und mehr Leute +1 eingeben. Der Wunsch nach dem bestehenbleiben übergeordneter Filter in der WebUI ist verständlich, aber auch nichts neues. Hierzu gibt es bereits ein entsprechendes Ticket auf GItHub:

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

Da ich allerdings nicht die Welt alleine retten kann wäre es schön wenn sich jemand finden könnte der das ganze ggf. einmal exemplarisch umsetzt und einen PullRequest oder ähnliches dann erzeugt. Denn ich würde mich freuen den dann in RaspberryMatic entsprechend zu übernehmen.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Hütte
Beiträge: 746
Registriert: 08.02.2017, 11:08
Hat sich bedankt: 32 Mal
Danksagung erhalten: 75 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von Hütte » 01.02.2019, 02:55

Familienvater hat geschrieben:
30.01.2019, 14:18
Hi,
hbrockmann hat geschrieben:
30.01.2019, 12:46
aber auch mit dieser guten erläuterung wäre es wünschenswert, eine möglichkeit zu schaffen das der "max. dc" während des updatevorgangs manuell konfiguriert werden kann.
ein max. "update-dc" von 50% "verschenkt" einfach in einigen fällen zu viel zeit.

wenn ich die wahl habe zwischen tagelangen updatevorgängen und dem risiko, das die zentrale mal innerhalb einiger minuten ein ankommendes paket nicht empfangen könnte, würde ich während manuell angestoßener updates zweiteres wählen wenn der updatevorgang dadurch erheblich verkürzt wird.
das wird mit Sicherheit ein Wunsch bleiben, Jens kann da nichts tun, das sind Dinge, die tief im HmIP-Server liegen, wo es auch zur Zeit keine "öffentlichen" Methoden gibt, um irgendwelche Parameter von außen zu verstellen. Und die Nebenwirkungs-Gefahr ist nach meiner Meinung für EQ3 zu hoch, das die sich damit ein Bein stellen, weil es zuviele Konstellationen geben kann: wie gesagt, es könnten 2 Router involviert sein, die auch einen DC haben, der jeweils eingehalten werden muss, und die Router müssen ggf. aber auch "DC-teure" Dinge vollkommen unabhängig von der Zentrale machen können, nämlich Direktverknüpfungen zwischen den Geräten, weshalb die ganze Kette nicht überlastet werden darf. Und n-Betriebsmodi, ist der Aktor direkt ereichbar, dann Limit 70% DC, wenn über einen Hop dann nur 50% DC etc. wird EQ3 nicht machen, weil wir auch nicht wissen, welche Codebasis sich der HmIP-Server mit der Cloud teilt (vielleicht nicht ohne Grund heißt der auch crRfd -> cloud ready Rfd)

Der Familienvater
Auch wenn ich in manchen meiner Beiträge darauf verwiesen habe, das Changelog zu beachten, das besagt, ob nach einem Firmware-Update ein Ab- und Neuanlernern notwendig sein könnte, so habe ich gerade feststellen müssen, dass beim HmIP-SMI (Bewegungsmelder Innen) beim Update der Firmware von Version 1.2.2 auf 1.4.8, bereits bei Version 1.4.0 ein weiterer Kanal 2 hinzu gekommen ist, von dem man im Changelog nur durch ganz genaues Lesen etwas im Nebensatz mit Sternchen erfährt (*[HMIP_SMI-28]: Reset motion state with blocking period when a switch command is received on the new channel 2 (input)). Und trotzdem steht im Changelog an keiner Stelle, dass ein Ab- und neu Anlernen des Gerätes notwendig ist

Von daher würde es mich nicht wundern, ob es auch bei klassischen HM-Geräten nicht angebracht ist, nach einem FW-Update, das Gerät auf jeden Fall ab- und neu anzulernen, auch wenn es nicht im Changelog steht.

Daher bietet sich die Zeit, welche die Zentrale (egal, ob es ein HmIP-AP, eine CCU2, CCU3 oder RaspberryMatic oder was auch immer ist) benötigt, um die Firmware auf mehrere Geräte gleichzeitig, dabei "scheibchenweise", zu übertragen, als guter Zeitpunkt, für diese Geräte noch einmal alle Punkte zu checken und zu dokumentieren, um hinterher alles wieder in denselben Zustand zu bekommen, wie es vorher war. Wenn das dann alles dokumentiert ist, dann kann man ruhigen Gewissens bei nur jeweils einem Gerät das eigentliche Update anstoßen und wenn dann das Update durchgeführt wurde, das Gerät Ab- und neu Anlernen und laut Dokumentation wieder alles so einrichten, wie es vorher war. Neben den "üblichen" Verdächtigen (aktuelle Geräteeinstellungen aller Kanäle, Programme und Direktverknüpfungen) sollte man auch nicht vergessen, zu prüfen und zu dokuemtieren, ob es Verknüpfungen zwischen dem Gerät und Systemvarialben gibt. Denn diese Verknüpfungen kann man leider nicht abrufen, wenn man sich im Menü der Geräteeinstellungen befindet. Diese Verknüpfungen sieht man nur im Menü der Systemvariablem

Mir sind beim Dokuemntieren meiner Bewegungsmelder nicht nur die üblichen "Verdächtigen" aufgefallen, also Direktverknüpfungen und Programme. Ich hatte auch noch Systemvariablen, die mit den Geräten verknüpft waren. Nur sieht man diese Verknüpfungen nicht, wenn man sich die Geräteeinstellungen anschaut

Hütte
Beiträge: 746
Registriert: 08.02.2017, 11:08
Hat sich bedankt: 32 Mal
Danksagung erhalten: 75 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019

Beitrag von Hütte » 01.02.2019, 03:02

Bezug nehmen auf meine obigen Beitrag wäre es sicher sehr praktisch, wenn man in den Geräteeinstellungen nicht "nur" Direktverküpfungen und Programme ausfindig machen kann, in denen das jeweilige Gerät direkt benutzt wird, sonder auch Systemvariablen, die mit dem Gerät verknüpft sind.

Antworten

Zurück zu „RaspberryMatic“