Mir leider auch nicht
RaspberryMatic - Verbesserungsvorschläge/Wünsche
Moderatoren: jmaus, Co-Administratoren
-
- Beiträge: 12085
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 847 Mal
- Danksagung erhalten: 2139 Mal
- Kontaktdaten:
- jmaus
- Beiträge: 9818
- 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
Ich vermute irgendeine ungereimtheit in der kommunikation zwischen rfd und dem hmlangw dienst. Irgendwas läuft da nicht so sauber, sodass es mitunter zum abbruch der verbindung zwischen den beiden kommt und rfd dann auch aus irgendeinem grund dagegen entscheidet die verbindung selber wieder aufzubauen. Muss ich mal eQ3 antriggern...
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- blackhole
- Beiträge: 3718
- Registriert: 21.07.2015, 14:03
- System: CCU
- Hat sich bedankt: 184 Mal
- Danksagung erhalten: 586 Mal
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche
jmaus hat geschrieben: ↑21.06.2020, 18:17Das kann ich dir erklären. Natürlich nimmt RaspberryMatic das RFD binary aus dem OCCU github repository. Allerdings ist es zusätzlich so, das das build system von buildroot standardmäßig nach dem kopieren automatisch sämtliche binaries im nachhinein nochmal durch "strip" laufen lässt um etwaige überflüssig debug symbols, etc. zu entfernen und somit das image so klein wie möglich zu bekommen. Und das führt genau dann dazu das natürlich durch diese geringfügige Modifikation des binaries der md5 hash anders ist.
Deine Erklärung für die unterschiedliche Checksumme ist natürlich falsch.
Die Durchführung von strip als zusätzliche Modifikation (des Binaries) von RaspberryMatic zu verkaufen ist bedenkenswert.
Das rfd-Binary der original Firmware wurde selbstverständlich nach dem Kompilieren ebenfalls mit strip behandelt.
Das kann man ganz leicht am Kompilat der original Firmware überprüfen:
Code: Alles auswählen
# md5sum rfd
193ea36b7751a4c251f94b4093aae04d rfd
# strip rfd
# md5sum rfd
193ea36b7751a4c251f94b4093aae04d rfd
Die Anwendung von strip ist auch in keiner Weise etwas Besonderes, sondern eine völlig normale Standardvorgehensweise.
- jmaus
- Beiträge: 9818
- 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
Da hast du für das "rfd" binary natürlich recht. Aber nun mach das gleiche mal z.B. auf dem im OCCU befindlichen "hss_led" binary und du wirst sehen das das dort ungestrippt liegt.blackhole hat geschrieben: ↑22.06.2020, 07:54Deine Erklärung für die unterschiedliche Checksumme ist natürlich falsch.jmaus hat geschrieben: ↑21.06.2020, 18:17Das kann ich dir erklären. Natürlich nimmt RaspberryMatic das RFD binary aus dem OCCU github repository. Allerdings ist es zusätzlich so, das das build system von buildroot standardmäßig nach dem kopieren automatisch sämtliche binaries im nachhinein nochmal durch "strip" laufen lässt um etwaige überflüssig debug symbols, etc. zu entfernen und somit das image so klein wie möglich zu bekommen. Und das führt genau dann dazu das natürlich durch diese geringfügige Modifikation des binaries der md5 hash anders ist.
Die Durchführung von strip als zusätzliche Modifikation (des Binaries) von RaspberryMatic zu verkaufen ist bedenkenswert.
Das rfd-Binary der original Firmware wurde selbstverständlich nach dem Kompilieren ebenfalls mit strip behandelt.
Und wenn du buildroot kennen würdest, würdest du wissen das das nachträgliche strippen von binaries eines buildroot paketes automatisch passiert. Nun ist das rfd binary in der Tat bereits im occu gestrippt (das hatte ich übersehen). Allerdings hatte ich auch vergessen zu erwähnen das nach dem strippen der binaries im buildroot finalize schritt noch zusätzlich via "patchelf" modifikationen am binary durchgeführt werden um die RPATH pfade an die neue gegebenheiten der buildroot umgebung anzupassen in der sie sich dann befinden. Dazu gibt es im Buildroot den script "fix-rpath" (siehe https://github.com/buildroot/buildroot/ ... /fix-rpath) der automatisch unmittelbar vor dem finalen schritt des zusammenbastelns des *.img über das gesamte target Verzeichnis angewendet wird und der einfach nur sicherstellt, das die RPATH angaben in den binaries entsprechend stimmen und die binaries somit ihre shared libraries "besser" finden.
Hoffe das klärt es nun auf und ich kann auch nicht erkennen was daran "bedenkenswert" sein sollte?!?
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- blackhole
- Beiträge: 3718
- Registriert: 21.07.2015, 14:03
- System: CCU
- Hat sich bedankt: 184 Mal
- Danksagung erhalten: 586 Mal
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche
Genau, darum geht es hier ja auch.
Ich erkläre es dir gerne noch einmal:
Es wird nicht besser:
Wir vergleichen mit der Original Firmware:
Code: Alles auswählen
# md5sum hss_led
b121d7e41a0f4a383889df4f3e20e08b hss_led
# strip hss_led
# md5sum hss_led
b121d7e41a0f4a383889df4f3e20e08b hss_led
Wie zu erwarten, wurde auch dieses Binary mit strip behandelt.
- roe1974
- Beiträge: 746
- Registriert: 17.10.2017, 16:15
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Wien
- Hat sich bedankt: 52 Mal
- Danksagung erhalten: 13 Mal
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche
Also ich verwende die aktuelle RM(0621) + eine RM(0420) als LGW.
Das LGW ist in der Garage via OpenVPN (in der Garage ist ein LTE Router) an mein Home angebunden.
Das läuft solange der Tunnel steht super stabil.
Aber ich habe zwei reproduzierbare Phänomene:
1)
Wenn die LTE Verbindung kurz weg ist (Abrechnungstechnisch) ist zwar der Tunnel ein paar Sekunden später wieder da, das LGW wird jedoch nicht mehr automatisch in der RM(CCU) erkannt. Durch einen reboot des LGW (macht der Router mit einem script automatisch) funkt dann wieder alles.
2)
Bei einem Update des LGW auf z.B. die aktuelle Version sieht die CCU zwar das LGW als verbunden, alle Aktoren dahinter sind jedoch nicht erreichbar.
Hier hilft ein reboot der Zentrale.
lg Richard
- jmaus
- Beiträge: 9818
- 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
Die Frage ist doch eher, glaubst du mir oder glaubst du mir nicht oder willst du nur mal wieder sinnlos nen Fass aufmachen?blackhole hat geschrieben: ↑22.06.2020, 09:10Es wird nicht besser:
Wir vergleichen mit der Original Firmware:
Wie zu erwarten, wurde auch dieses Binary mit strip behandelt.Code: Alles auswählen
# md5sum hss_led b121d7e41a0f4a383889df4f3e20e08b hss_led # strip hss_led # md5sum hss_led b121d7e41a0f4a383889df4f3e20e08b hss_led
In der Tat bin ich im OCCU Verzeichnis verrutscht, denn leider legt eq3 an mehreren Stellen z.B. das hss_led binary im OCCU repository ab. Denn wenn du mal in das https://github.com/eq-3/occu/tree/maste ... -3/RFD/bin Verzeichnis schaust, so liegt da ein ungestripptes hss_led.
Aber seis drum. Es ist jedoch in der Tat so wie ich gesagt habe. Buildroot macht beim "build" eben ein finales strip gefolgt vom fix-rpath script aufruf das in den binaries die pfade zu verlinkten bibliotheken in relative pfade auflöst und daher mittels "patchelf" kommando die binaries anfasst. Ansich nichts ungewöhnliches und völlig i.O. Das erklärt aber eben warum die md5 checksumme des rfd binaries im OCCU repo substantiell anders ist als das binary das im RaspberryMatic dann am schluss landet. Und nun kannst du mir das glauben oder nicht, es ist aber definitiv so.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- Beiträge: 12085
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 847 Mal
- Danksagung erhalten: 2139 Mal
- Kontaktdaten:
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche
Ok, beruhigt mich schon mal, dass es nicht an der umgebauten CCU2 als solches liegt, sondern dass auch dieses Verhalten bei Verwendung eines RM LAN GW auftritt.roe1974 hat geschrieben: ↑22.06.2020, 09:44Also ich verwende die aktuelle RM(0621) + eine RM(0420) als LGW.
...
das LGW wird jedoch nicht mehr automatisch in der RM(CCU) erkannt. Durch einen reboot des LGW (macht der Router mit einem script automatisch) funkt dann wieder alles.
2)
Bei einem Update des LGW auf z.B. die aktuelle Version sieht die CCU zwar das LGW als verbunden, alle Aktoren dahinter sind jedoch nicht erreichbar.
Hier hilft ein reboot der Zentrale.
- jmaus
- Beiträge: 9818
- 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
Ich hab ehrlich gesagt schon länger die Vermutung das doch noch irgendwas mit dem reverse-engineerten "hmlangw" Dienst nicht ganz 100% stimmt und es deshalb zu gewissen sporadischen Verbindungsabbrüchen kommt. Bis jetzt hab ich mich aber an das Thema noch nicht rangetraut bzw. hab noch nicht ausreichend zeit dafür gefunden das zu debuggen.jp112sdl hat geschrieben: ↑22.06.2020, 10:48Ok, beruhigt mich schon mal, dass es nicht an der umgebauten CCU2 als solches liegt, sondern dass auch dieses Verhalten bei Verwendung eines RM LAN GW auftritt.roe1974 hat geschrieben: ↑22.06.2020, 09:44Also ich verwende die aktuelle RM(0621) + eine RM(0420) als LGW.
...
das LGW wird jedoch nicht mehr automatisch in der RM(CCU) erkannt. Durch einen reboot des LGW (macht der Router mit einem script automatisch) funkt dann wieder alles.
2)
Bei einem Update des LGW auf z.B. die aktuelle Version sieht die CCU zwar das LGW als verbunden, alle Aktoren dahinter sind jedoch nicht erreichbar.
Hier hilft ein reboot der Zentrale.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- shartelt
- Beiträge: 7421
- Registriert: 14.01.2015, 14:59
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 524 Mal
- Danksagung erhalten: 752 Mal
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche
also ich hatte auch lange mit meinen 3 LANGWs zu kämpfen. Bemerkt habe ich es immer, wenn ich Servicemeldungen der Aktoren erhalten habe, die eben ausserhalb der Reichweite der Zentrale sind.
Ich kann alles auf mein Netzwerk zurückführen....hatte in der Garage eine PowerLAN Verbindung...an der ein Unifi Accesspoint hing und über den dann das LANGW lief...sowie eine Verbindung im OG, deren Netzwerkdose teilweise aussetzer auf einer Ader hatte...
Nun alles gefixed...seither keinerlei Abbrüche mehr der LAN Gateways....
Ergo würde ich sagen, wenn mal die Netzwerkverbindung bisschen problematisch ist, verbinden sich die LAN Gateways nichtmehr korrekt und man hat eben genau die Erscheinungen.
Es ist übrigens mit einer modifizierten CCU2 UND mit Raspis mit dem alten Funkmodul gleichfalls aufgetreten.
Eventuell kannst Du das als Test nehmen...einfach Netzwerk wegnehmen...geben...und dann schauen wann es auftritt.
Erster Indikator war bei mir sofort der -1 % Duty Cycle bzw wegfall des grafischen DC Balkens in der Hauptseite des WebUIs.
Ich kann alles auf mein Netzwerk zurückführen....hatte in der Garage eine PowerLAN Verbindung...an der ein Unifi Accesspoint hing und über den dann das LANGW lief...sowie eine Verbindung im OG, deren Netzwerkdose teilweise aussetzer auf einer Ader hatte...
Nun alles gefixed...seither keinerlei Abbrüche mehr der LAN Gateways....
Ergo würde ich sagen, wenn mal die Netzwerkverbindung bisschen problematisch ist, verbinden sich die LAN Gateways nichtmehr korrekt und man hat eben genau die Erscheinungen.
Es ist übrigens mit einer modifizierten CCU2 UND mit Raspis mit dem alten Funkmodul gleichfalls aufgetreten.
Eventuell kannst Du das als Test nehmen...einfach Netzwerk wegnehmen...geben...und dann schauen wann es auftritt.
Erster Indikator war bei mir sofort der -1 % Duty Cycle bzw wegfall des grafischen DC Balkens in der Hauptseite des WebUIs.