RaspberryMatic - Verbesserungsvorschläge/Wünsche
Moderatoren: jmaus, Co-Administratoren
-
- 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
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
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
-
- 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
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.
- onkeltommy
- Beiträge: 1392
- Registriert: 07.05.2016, 08:03
- Wohnort: Wien
- Hat sich bedankt: 28 Mal
- Danksagung erhalten: 26 Mal
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
lG
Thomas
--------------------------
RaspberryMatic 3.73.9.20240130 @ TinkerS (Produktivsystem) & Historian @ SynologyVM & 2x RB3+ @ Nachwuchs
Thomas
--------------------------
RaspberryMatic 3.73.9.20240130 @ TinkerS (Produktivsystem) & Historian @ SynologyVM & 2x RB3+ @ Nachwuchs
-
- 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
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.
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.
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Das wäre wirklich was Feines
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
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
-
- 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
Hi,
Der Familienvater
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)hbrockmann hat geschrieben: ↑30.01.2019, 12:46aber 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.
Der Familienvater
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
+1arrisun hat geschrieben: ↑30.01.2019, 12:49Das wäre wirklich was Feines
- jmaus
- Beiträge: 9865
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 464 Mal
- Danksagung erhalten: 1883 Mal
- Kontaktdaten:
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
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.
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.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- 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
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 istFamilienvater hat geschrieben: ↑30.01.2019, 14:18Hi,
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)hbrockmann hat geschrieben: ↑30.01.2019, 12:46aber 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.
Der Familienvater
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
-
- 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
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.