RaspberryMatic - Verbesserungsvorschläge/Wünsche

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

Moderatoren: jmaus, Co-Administratoren

jp112sdl
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

Beitrag von jp112sdl » 21.06.2020, 19:03

jmaus hat geschrieben:
21.06.2020, 18:17
Bisher ist mir das nämlich mit einfachen Tests leider noch nicht gelungen.
Mir leider auch nicht

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
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

Beitrag von jmaus » 21.06.2020, 19:46

jp112sdl hat geschrieben:
21.06.2020, 19:03
jmaus hat geschrieben:
21.06.2020, 18:17
Bisher ist mir das nämlich mit einfachen Tests leider noch nicht gelungen.
Mir leider auch nicht
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 / ☕️

Benutzeravatar
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

Beitrag von blackhole » 22.06.2020, 07:54

jmaus hat geschrieben:
21.06.2020, 18:17
Das 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.

Benutzeravatar
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

Beitrag von jmaus » 22.06.2020, 08:39

blackhole hat geschrieben:
22.06.2020, 07:54
jmaus hat geschrieben:
21.06.2020, 18:17
Das 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.
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.

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 / ☕️

Benutzeravatar
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

Beitrag von blackhole » 22.06.2020, 09:10

jmaus hat geschrieben:
22.06.2020, 08:39
Da hast du für das "rfd" binary natürlich recht.

Genau, darum geht es hier ja auch.

jmaus hat geschrieben:
22.06.2020, 08:39
ich kann auch nicht erkennen was daran "bedenkenswert" sein sollte?!?

Ich erkläre es dir gerne noch einmal:

blackhole hat geschrieben:
22.06.2020, 07:54
Die Durchführung von strip als zusätzliche Modifikation (des Binaries) von RaspberryMatic zu verkaufen ist bedenkenswert.
blackhole hat geschrieben:
22.06.2020, 07:54
Die Anwendung von strip ist auch in keiner Weise etwas Besonderes, sondern eine völlig normale Standardvorgehensweise.

Es wird nicht besser:

jmaus hat geschrieben:
22.06.2020, 08:39
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.

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.

Benutzeravatar
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

Beitrag von roe1974 » 22.06.2020, 09:44

jp112sdl hat geschrieben:
21.06.2020, 19:03
jmaus hat geschrieben:
21.06.2020, 18:17
Bisher ist mir das nämlich mit einfachen Tests leider noch nicht gelungen.
Mir leider auch nicht
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

Benutzeravatar
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

Beitrag von jmaus » 22.06.2020, 10:26

blackhole hat geschrieben:
22.06.2020, 09:10
Es wird nicht besser:
jmaus hat geschrieben:
22.06.2020, 08:39
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.
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.
Die Frage ist doch eher, glaubst du mir oder glaubst du mir nicht oder willst du nur mal wieder sinnlos nen Fass aufmachen?

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 / ☕️

jp112sdl
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

Beitrag von jp112sdl » 22.06.2020, 10:48

roe1974 hat geschrieben:
22.06.2020, 09:44
Also 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.
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.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
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

Beitrag von jmaus » 22.06.2020, 11:37

jp112sdl hat geschrieben:
22.06.2020, 10:48
roe1974 hat geschrieben:
22.06.2020, 09:44
Also 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.
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.
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.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
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

Beitrag von shartelt » 22.06.2020, 12:46

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.

Antworten

Zurück zu „RaspberryMatic“