RaspberryMatic 3.51.6.20200613 – Neue Version

[jmaus]

Habe die neue Firmware gerade auf meine Test VMM in der Synology installiert. Leider warte ich jetzt schon fast 30 min bei dem Bildschirm "Starting initRFHardware" , siehe Anhang.

Ich lass das ganze jetzt noch was länger laufen, die Erfahrung mit der vorherigen FW zeigt, dass Geduld hier gefragt sein könnte.

Mal sehen wie es sich weiter verhält.
[...]
Wenn ich den USB Empfänger HB-RF-USB aus der virtuellen Maschine nehme dann startet sie normal durch.

Ich vermute due verwendest eine HB-RF-USB in Kombination mit dem alten HM-MOD-RPI-PCB Funkmodul, richtig? Gerade noch einmal selbst hier getestet mit Synology VMM und in der Tat bleibt es an der Stelle stehen. Muss ich dann mal in naher Zukunft mir anschauen/debuggen. Die Kombination mit HB-RF-USB+RPI-RF-MOD scheint jedoch problemlos zu gehen und zu booten. Also bleibt momentan Nutzern mit HB-RF-USB+HM-MOD-RPI-PCB nur der Weg zurück zur Vorgängerversion bis der Bug beseitigt wurde von mir und ich eine neue Version rausgebracht habe. Und vermutlich sind die Nutzer die ein QNAP nutzen auch davon betroffen wenn sie die HB-RF-USB+RPI-RF-MOD Kombination nutzen.

[LibertyX]

Alles, bis auf CCU-Historian, läuft ohne Probleme. CCU-Historian ist über Port 8082 nicht erreichbar, hat sich hier etwas geändert ?

Kommt drauf an, welche Version du vorher hattest.

Als erstes sollte der Port in den Firewall Einstellungen freigegeben werden

Einstellungen > Systemsteuerung > Firewall konfigurieren

[Klaus1954]

Alles, bis auf CCU-Historian, läuft ohne Probleme. CCU-Historian ist über Port 8082 nicht erreichbar, hat sich hier etwas geändert ?

Kommt drauf an, welche Version du vorher hattest.

Als erstes sollte der Port in den Firewall Einstellungen freigegeben werden

Einstellungen > Systemsteuerung > Firewall konfigurieren

Hatte vorher 2.2.2, Port 8082 ist als Port-Freigabe in Firewall freigegeben

[berlinchris81]

Habe die neue Firmware gerade auf meine Test VMM in der Synology installiert. Leider warte ich jetzt schon fast 30 min bei dem Bildschirm "Starting initRFHardware" , siehe Anhang.

Ich lass das ganze jetzt noch was länger laufen, die Erfahrung mit der vorherigen FW zeigt, dass Geduld hier gefragt sein könnte.

Mal sehen wie es sich weiter verhält.
[...]
Wenn ich den USB Empfänger HB-RF-USB aus der virtuellen Maschine nehme dann startet sie normal durch.

Ich vermute due verwendest eine HB-RF-USB in Kombination mit dem alten HM-MOD-RPI-PCB Funkmodul, richtig? Gerade noch einmal selbst hier getestet mit Synology VMM und in der Tat bleibt es an der Stelle stehen. Muss ich dann mal in naher Zukunft mir anschauen/debuggen. Die Kombination mit HB-RF-USB+RPI-RF-MOD scheint jedoch problemlos zu gehen und zu booten. Also bleibt momentan Nutzern mit HB-RF-USB+HM-MOD-RPI-PCB nur der Weg zurück zur Vorgängerversion bis der Bug beseitigt wurde von mir und ich eine neue Version rausgebracht habe. Und vermutlich sind die Nutzer die ein QNAP nutzen auch davon betroffen wenn sie die HB-RF-USB+RPI-RF-MOD Kombination nutzen.

Ja da hast du Recht, ich schwenke zurück und warte auf Neuigkeiten, vielen Dank für deine Arbeit.

LG Chris

[grazcrew]

Versuch mal die USB Hardware abzuziehen und dann zu booten, eventuell wäre dann noch ein Backup möglich ... bei mir iss das System dann hochgefahren nur ohne Funkverbindung.

Geht. Ich habe das Modul abgezoge, rebooot, alte Firmware aufgespielt. Modul aufgestekt und geht wieder.

Die neue Version kommt wohl mit dem USB-Modul nicht klar.

[deimos]

Hi,

ich habe mal in die S011InitRFHardware geschaut und zwei Bugs gefunden, welche im Zusammenspiel das Problem verursachen dürften:

- Es wird kein Reset der HB-RF-USB innerhalb der OVA Umgebung durchgeführt, warum auch immer die OVA Umgebung da explizit ausgenommen ist. Ohne den Reset kann es passieren, dass das Funkmodul nicht korrekt hochfährt und dann nicht antwortet.
- Beim Aufruf von hmip-copro-update.jar wird nicht mit Timeout gearbeitet und das Teil hat in sich einen Bug, dass es endlos auf Antworten vom Funkmodul wartet.

Viele Grüße
Alex

[jmaus]

ich habe mal in die S011InitRFHardware geschaut und zwei Bugs gefunden, welche im Zusammenspiel das Problem verursachen dürften:

- Es wird kein Reset der HB-RF-USB innerhalb der OVA Umgebung durchgeführt, warum auch immer die OVA Umgebung da explizit ausgenommen ist. Ohne den Reset kann es passieren, dass das Funkmodul nicht korrekt hochfährt und dann nicht antwortet.
- Beim Aufruf von hmip-copro-update.jar wird nicht mit Timeout gearbeitet und das Teil hat in sich einen Bug, dass es endlos auf Antworten vom Funkmodul wartet.

Danke Alex für die Hinweise. In der Tat bin ich auf das mit dem timeout auch schon prinzipiell gestoßen und werde das sicherlich dann zeitnah so umsetzen. Wärst du aber so freundlich und würdest mir einfach mal die besagten Codezeilen kurz mal zeigen? Einfach nen Link zu den Zeilen wo du denkst das da gewisse Fehler bei der initialisierung bei nutzung eines HB-RF-USB liegen könnte? Das würde mir wirklich helfen. Danke.

EDIT:

Zumindest der weggelassene Funkmodul reset scheint intentionally gewesen zu sein. Siehe:
https://github.com/jens-maus/RaspberryM ... 3306d2c331

Ob das noch aktuell ist kann ich natürlich gerade ohne weitere tests nicht beurteilen. Aber sollte generic_raw_uart + dem hb-rf-usb treiber nicht automatisch beim laden des modules eine reset des modules durchführen? deshalb habe ich damals wohl das explizit reset weggelassen.

[Klaus1954]

Alles, bis auf CCU-Historian, läuft ohne Probleme. CCU-Historian ist über Port 8082 nicht erreichbar, hat sich hier etwas geändert ?

Kommt drauf an, welche Version du vorher hattest.

Als erstes sollte der Port in den Firewall Einstellungen freigegeben werden

Einstellungen > Systemsteuerung > Firewall konfigurieren

Hatte vorher 2.2.2, Port 8082 ist als Port-Freigabe in Firewall freigegeben

Update:
Dies war der alte Aufruf: /addons/ccu-historian/config.cgi?sid=@XNPBopDCvb@
scheint als ob die config.cgi fehlt denn auch deinstallieren ist nicht möglich

[deimos]

Hi,

Zumindest der weggelassene Funkmodul reset scheint intentionally gewesen zu sein. Siehe:
https://github.com/jens-maus/RaspberryM ... 3306d2c331

Ob das noch aktuell ist kann ich natürlich gerade ohne weitere tests nicht beurteilen. Aber sollte generic_raw_uart + dem hb-rf-usb treiber nicht automatisch beim laden des modules eine reset des modules durchführen? deshalb habe ich damals wohl das explizit reset weggelassen.

Der Reset sollte insb. bei der USB Platine schon immer notwendig um sicherzustellen, dass das Funkmodul korrektinitialisiert wird, weil der Sanftanlauf zwar dafür sorgt, dass die USB Spec eingehalten wird, aber es dadurch passieren könnte, dass das Funkmodul mit zu wenig Spannung startet und sich falsch initialisiert. Und da es keine Brownout Erkennung hat, sollte man einen sauberen (Hardware) Reset forcieren.

Da du für dich entschieden hast, den wegzulassen ohne mal zu fragen, ob das Sinn macht, kann ich dir jetzt auch nicht sagen, was dich dazu gebracht hat.

Viele Grüße
Alex

[jmaus]

Hi,

Zumindest der weggelassene Funkmodul reset scheint intentionally gewesen zu sein. Siehe:
https://github.com/jens-maus/RaspberryM ... 3306d2c331

Ob das noch aktuell ist kann ich natürlich gerade ohne weitere tests nicht beurteilen. Aber sollte generic_raw_uart + dem hb-rf-usb treiber nicht automatisch beim laden des modules eine reset des modules durchführen? deshalb habe ich damals wohl das explizit reset weggelassen.

Da du für dich entschieden hast, den wegzulassen ohne mal zu fragen, ob das Sinn macht, kann ich dir jetzt auch nicht sagen, was dich dazu gebracht hat.

Na aber führt dein Treiber beim initialisieren nicht automatisch den funkmodul reset aus? Für den Rpi/Tinkerboard hab ich das ja explizit abgeschalten wegen anderen abhängigkeiten und mache den reset dort eben wie gezeigt manuell. Aber beim HB-RF-USB kernel modul sollte der reset des funkmodules doch automatisch ausgeführt werden, oder?