Home Assistant mit RaspberryMatic Add-on: HMIPServer kann HM-MOD-RPI-PCB nicht ansprechen

[benni123_]

Wäre aber natürlich noch interessant zu erfahren welche Radio Mac die eQ3 eigenen Tools (eq3configcmd) für diesen Fall ausspucken…

Code: Alles auswählen

update-coprocessor -lgw -u ( <-rfdconf rfd.conf> | <-s serial> <-k Aes-Key> [-c] [-l LOGLEVEL]) [-d FIRMWARE-DIRECTORY]
	-p: Serial port of CCU2/HM-MOD-UART coprocessor (Alternatively use -s)
	-s: Serial number of lan gateway. (Alternatively use -p)
	-k: Aes-Key (passphrase) of lan gateway; Needed if encryption is enabled
	-u: Do Firmwareupdate if necessary
	-f: Force update and ignore version
	-v: Get Version
	-av: Get avaiable Version
	-bl: Start Bootloader
	-app: Start Application
	-se: Get coprocessor serial number.
	-sg: Get coprocessor SGTIN if applicable.
	-lgw: Update target is a LAN gateway.
	-rfdconf: Path to rfd.conf file. (Used when -lgw is supplied.)
	-c: Log to console instead of syslog.
	-l: Loglevel.
	-d: Path to firmware directory which contains firware files and fwmap file. Default is /firmware.
	-t: Coprocessor type: CCU2 or HM-MOD-UART. Default ist CCU2.

Mit -se kann es benni123_ ja mal testen

Teste ich später heute.

Noch weitere Dinge zu testen?

Viele Grüße

Benjamin

[benni123_]

Ok, gerade mal ausprobiert:

Code: Alles auswählen

root@homematic-raspi:~# monit stop rfd
root@homematic-raspi:~# monit stop multimacd
root@homematic-raspi:~# monit stop HMIPServer
root@homematic-raspi:~# eq3configcmd update-coprocessor -t HM-MOD-UART -p /dev/raw-uart -c -l 0 -se
2024/04/05 20:45:46.051 <Debug> firmware filename is: coprocessor_update.eq3

2024/04/05 20:45:46.557 <Debug> () CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in dual coprocessor application.
2024/04/05 20:45:46.557 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): hmip common frame
2024/04/05 20:45:46.557 <Debug> () CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in dual coprocessor application.
2024/04/05 20:45:46.557  CoprocessorUpdate::startApplication()
2024/04/05 20:45:46.557 <Debug> CoprocessorUpdate::startApplication():Coprocessor entered application.
2024/04/05 20:45:46.612 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): lowlevelmac frame
2024/04/05 20:45:46.612 <Info> SerialNumber: QEQ0407065

SerialNumber: QEQ0407065

[jmaus]

SerialNumber: QEQ0407065

Oh, das ist nicht das was ich meinte. probier mal lieber:

Code: Alles auswählen

eq3configcmd read-default-rf-address -v -f /dev/raw-uart

Das sollte die default rf adresse zurückgeben...

[jp112sdl]

Oh, das ist nicht das was ich meinte.

Ach ja, stimmt. Hatte Seriennummer und Adresse gedanklich vertauscht

[benni123_]

Oh, das ist nicht das was ich meinte. probier mal lieber:

Code: Alles auswählen

eq3configcmd read-default-rf-address -v -f /dev/raw-uart

Das sollte die default rf adresse zurückgeben...

Hallo Jens,

gerade nochmal ausprobiert:

Code: Alles auswählen

root@homematic-raspi:~# monit stop rfd
root@homematic-raspi:~# monit stop multimacd
root@homematic-raspi:~# monit stop HMIPServer
root@homematic-raspi:~# eq3configcmd read-default-rf-address -v -f /dev/raw-uart
Initalizing coprocessor...
Requesting default rf address
Default RF-Address is: 
7143423

Sagt Bescheid, wenn ihr noch weitere Debugging-Tests braucht. Ich schaue hier täglich mal rein.

Viele Grüße

Benjamin

[jmaus]

Gerade nochmal ausprobiert:

Code: Alles auswählen

root@homematic-raspi:~# monit stop rfd
root@homematic-raspi:~# monit stop multimacd
root@homematic-raspi:~# monit stop HMIPServer
root@homematic-raspi:~# eq3configcmd read-default-rf-address -v -f /dev/raw-uart
Initalizing coprocessor...
Requesting default rf address
Default RF-Address is: 
7143423

Danke. Das wäre dann in Hex als Radio Mac Adresse 0x6CFFFF. Da müsste Alex (@deimos) sagen warum er in seinem detect_radio_module Tool diese Adresse offensichtlich als "invalid" erkennt und dann dort 0x000000 stattdessen ausgibt?!? Für mich sieht diese default RF Adresse aber auf den ersten Blick nicht problematisch aus?!?!

Wenn man sie deine vorherigen Debugausgaben von detect_radio_module noch einmal anschaut erkennt man diese Adresse auch in den Ausgaben:

Code: Alles auswählen

21:00:18.117105 Sending HM frame:  fd 00 03 03 08 08 28 0c
21:00:18.120097 Received HM frame: fd 00 07 03 08 01 01 6c ff ff f0 21
21:00:18.120206 Sending HM frame:  fd 00 03 03 09 07 ae 2d
21:00:18.124466 Received HM frame: fd 00 0e 03 09 01 01 51 45 51 30 34 30 37 30 36 35 14 50
21:00:18.302173 Sucessfully resetted radio module.
HM-MOD-RPI-PCB QEQ0407065 3014F711A061A7DA498F9E19 0x000000 0xBF2C1E 2.8.6

In der zweiten Zeile findet man ganz hinten ja genau das "6c ff ff".. Das wird bestimmt die Default RF Adresse sein die auch das eq3configcmd ausgibt. Die Frage bleibt also, warum nimmt detect_radio_module diese nicht? Alex kann das bestimmt aufklären.

[deimos]

Hi,

das reicht in das Jahr 2020 noch vor der Entwicklung vom detect-radio-module zurück. Da haben Adressen, welche mit 0xffff endeten immer mal wieder für Issues bei Nutzern von piVCCU gesorgt, weshalb ich bei diesen nicht die Adresse aus demFunkmodul verwende, sondern eine random erzeugte.

Viele Grüße
Alex

[jmaus]

das reicht in das Jahr 2020 noch vor der Entwicklung vom detect-radio-module zurück. Da haben Adressen, welche mit 0xffff endeten immer mal wieder für Issues bei Nutzern von piVCCU gesorgt, weshalb ich bei diesen nicht die Adresse aus demFunkmodul verwende, sondern eine random erzeugte.

Verstehe. Aber welche Probleme waren das (weißt du das noch?) bzw. sind diese noch aktuell? Wenn nicht oder unklar, wäre es vielleicht gut diesen workaround aus detect_radio_module zu entfernen bzw. vielleicht detect_radio_module (ggf. durch angeben einer Option) es zu ermöglichen trotzdem diese Adressen auszugeben.

[deimos]

Hi,

ich bring es nicht mehr vollständig zusammen, ein Problem war zumindest mit dem RPI-RF-MOD, welches im Auslieferungszustand eine Firmware drauf hatte, welche keine BidCos eigenständige Adresse geliefert hat, aber es gab da noch mehr. Da sich beim BidCos Thema aber seit Jahren nichts mehr getan hat, werde ich diesen Workaround nicht ausbauen, weil mir das Risiko einer Regression zu hoch ist und es an sich kein Problem ist, es drin zu lassen, wenn man den Fallback auf eine Random Adresse drin hat, welcher so oder so sinnvoll ist für den Fall, dass gar kein lokal angeschlossenes Funkmodul vorhanden ist sondern nur ein LAN Gateway.

Viele Grüße
Alex

[jmaus]

ich bring es nicht mehr vollständig zusammen, ein Problem war zumindest mit dem RPI-RF-MOD, welches im Auslieferungszustand eine Firmware drauf hatte, welche keine BidCos eigenständige Adresse geliefert hat, aber es gab da noch mehr. Da sich beim BidCos Thema aber seit Jahren nichts mehr getan hat, werde ich diesen Workaround nicht ausbauen, weil mir das Risiko einer Regression zu hoch ist und es an sich kein Problem ist, es drin zu lassen, wenn man den Fallback auf eine Random Adresse drin hat, welcher so oder so sinnvoll ist für den Fall, dass gar kein lokal angeschlossenes Funkmodul vorhanden ist sondern nur ein LAN Gateway.

Diesen Ansatz (don't touch a running system) kann ich natürlich prinzipiell verstehen. Beim detect_radio_module tool würde ich aber eigentlich auch erwarten, dass es einfach die Daten des Funkmodules so zurückgibt wie sie dort auch hinterlegt sind und es nicht selbst irgendwelche Logiken/Ausschlüsse, etc. gibt die versuchen Dinge zu optimieren/kompensieren die ggf. besser auf einer anderen Ebene stattfinden sollten, denn ansonsten komm ich ja mit detect_radio_module gar nicht an die ursprünglichen daten heran. Und so würde ich eben erwarten das dann ggf. in piVCCU oder RaspberryMatic selbst dann genau diese Exceptions (Adressen mit 0xffff hinten) eingebaut sind und nicht im detect_radio_module hart verdrahtet. Genau deshalb ja auch die prinzipielle idee vielleicht eine zusätzliche Option in detect_radio_module einzubauen (vielleicht --raw bzw. -r) um genau die Daten des Funkmodules ohne zusätzlich Ausschlusslogiken zurückzugeben. Dann kann die Anwendung (piVCCU, RaspberryMatic, etc.) selbst entscheiden was sie mit dieser Info anfängt.