HmIP-HAP als Funkmodul (HB-RF-HAP) nutzen - wie HB-RF-ETH

[Baxxy]

Für Linux ja.

Windows: https://ftdichip.com/utilities/

[sectorchan]

also mit meinem "original" FTDI Chip kabel geht es leider gar nicht, da kommt bei
detect_radio_module --debug /dev/ttyUSB0 -> No radio found

Wenn ich nun meinen anderen wo ich bei detect_radio_module --debug /dev/ttyUSB0 einen output bekommen habe, mittels dem ft232 Prog von der Herstellerwebseite nehme:

ftdi2.png

bekomme ich nun auch mit dem:

Code: Alles auswählen

root@homematic-raspi:/dev# detect_radio_module --debug /dev/ttyUSB0
/dev/ttyUSB0 could not be opened

wenn ich nun wieder zu dem FT Prog gehe und erneut scanne, wird mir mein FTDI nicht mehr gefunden und will anscheinend andere Treiber...
Leider habe ich davor nicht geschaut was für Treiber verwendet werden. Ich Schlafe mal drüber vielleicht hat sich dann der Rechner auch erholt und nimmt wieder die richtigen Treiber.

[jp112sdl]

Wenn ich nun meinen anderen wo ich bei detect_radio_module --debug /dev/ttyUSB0 einen output bekommen habe, mittels dem ft232 Prog von der Herstellerwebseite nehme:
ftdi2.png

Da musst du ja dann auch /dev/raw-uart nehmen (oder raw-uart1 wie bei Baxxy)

wenn ich nun wieder zu dem FT Prog gehe und erneut scanne, wird mir mein FTDI nicht mehr gefunden und will anscheinend andere Treiber...

Ja das liegt am FT Tool.
Auf der Kommandozeile geht das Rückgängigmachen mit

Code: Alles auswählen

ft232r_prog --old-pid 0x6f70 --new-pid 0x6001

[sectorchan]

Danke, aber scheint auch mit uart nicht zu klappen:

Code: Alles auswählen

root@homematic-raspi:~# detect_radio_module --debug /dev/raw-uart
21:28:23.199411 Sending HM frame:  fd 00 03 fe 00 01 14 1e
21:28:26.211794 Sending HM frame:  fd 00 03 00 01 00 9e 03
21:28:29.212495 Sending HM frame:  fd 00 03 fe 02 01 98 1d
21:28:32.213359 Sending HM frame:  fd 00 03 00 03 00 12 00
21:28:35.214147 Sending HM frame:  fd 00 03 fe 04 01 8c 1d
21:28:38.215058 Sending HM frame:  fd 00 03 00 05 00 06 00
Error: Radio module was not detected
root@homematic-raspi:~#

Ja das liegt am FT Tool.
Auf der Kommandozeile geht das Rückgängigmachen mit

Code: Alles auswählen

ft232r_prog --old-pid 0x6f70 --new-pid 0x6001

Mit adaptiertem Windowscode klappts nicht, startet nur die GUI.

Code: Alles auswählen

ft_prog.exe --old-pid 0x6f70 --new-pid 0x6001

Ich hole mir Vbox Kubuntu und nehme die Linux variante.
->Ich kann es nicht mal in VBOX weiterreichen, da erscheint der Haken nicht mal

[Baxxy]

Wird denn das Teil überhaupt korrekt erkannt?
/var/log/boot.log

Code: Alles auswählen

Identifying Homematic RF-Hardware: .......HmRF: HMIP-RFUSB/HB-RF-USB@usb-3f980000.usb-1.4, HmIP: HMIP-RFUSB/HB-RF-USB@usb-3f980000.usb-1.4, OK
Updating Homematic RF-Hardware: HMIP-RFUSB: 4.4.18, not necessary, OK

Wenn ja guckst du in der WebUI bei Hilfe welcher "Anschluss" genutzt wird.

[sectorchan]

Hi,

boot.log

Code: Alles auswählen

Identifying Homematic RF-Hardware: .........HmRF: HMIP-RFUSB/HB-RF-ETH@192.168.1.10, HmIP: HMIP-RFUSB/HB-RF-ETH@192.168.1.10, OK
Updating Homematic RF-Hardware: HMIP-RFUSB: 4.4.34=>4.4.18, ERROR (4.4.34 != 4.4.18)
Starting hs485dLoader: disabled

So wie bei dir

a.png (10.76 KiB) 280 mal betrachtet

Daher, wird nun der FTDI (den ich nun auf 0x6f70 PID gebracht habe) an das ST5 angeschlossen, gemäß

Mache den "affengriff" und löse ihn dann wenn ich zugriff auf das WebIF habe (Habe keinen separaten Monitor), die HAP LED bleibt aus.
Unter Hilfe schaut es nun so aus:

b.png (6.68 KiB) 268 mal betrachtet

Du musst die Stromversorgung des HAP trennen (z.B. VCC vom FTDI abziehen).
die Ethernet LED's sind beide an.

Ich versteh das schon richtig, das ich das VCC des FTDI gar nicht anschließen darf? UND auch die normale Stromversorgung nicht?!
Nur RX, TX, GND
Bei mir sind nie Ethernet LED an.

[Baxxy]

So wie bei dir

Naja, du zeigst den HAP als HMIP-RFUSB/HB-RF-ETH@192.168.1.10, also als HB-RF-HAP. Und das das bei dir nicht funktional ist hattest du ja gleich zu Anfang geschrieben.
Ich zeige HMIP-RFUSB/HB-RF-USB@usb-3f980000.usb-1.4, also die Verbindung über den FTDI.

Ich versteh das schon richtig, das ich das VCC des FTDI gar nicht anschließen darf? UND auch die normale Stromversorgung nicht?!
Nur RX, TX, GND
Bei mir sind nie Ethernet LED an.

Die Ethernet LED's vergiss mal.
Es muss natürlich auch VCC dran sein, ist doch hier: viewtopic.php?f=76&t=76156&start=50#p787278 zu sehen. Hast du ja auch auf deinem Bild korrekt dran. Also soweit richtig.

Mache den "affengriff" und löse ihn dann wenn ich zugriff auf das WebIF habe (Habe keinen separaten Monitor), die HAP LED bleibt aus.

Da ich mir inzwischen einen Taster als "Affengriff-Ersatz" angelötet habe, habe ich diesen testweise auch mal für die gesamte Bootzeit gedrückt. Bei mir klappt das auch so.

Ich glaube das können wir vergessen. Scheinbar verhindert die Firmware deines HAP irgendwie die Kommunikation.
Ich habe echt keine Idee mehr, tut mir leid.

[sectorchan]

habe nun ein aktuelles VBOX image am laufen.

Wenn ich nicht über FTDI verbunden bin (mit weiterleitung)
bekomme ich:

a.png (22.31 KiB) 230 mal betrachtet

Dann machst du ggf. mehrmals:

Code: Alles auswählen

detect_radio_module --debug /dev/ttyUSB0

Ich boote hier mit dem Affengriff, wärend der FTDI an RM angeschlossen ist. Aber woher weiss ich ob das /dev/ richtig ist?
Mit

Code: Alles auswählen

lsusb

wird mir aber kein USB Gerät angezeigt.

[Baxxy]

Fassen wir mal zusammen:

Du hast bei einem unbekannten HAP (es gibt wohl inzwischen 4 verschiedene Modelle) mit (spekulativ) Device-Firmware 3.0.16 und (bekannt) CoPro-FW: 4.4.34
Der Downgrade auf die nötige CoPro-FW: 4.4.18 klappt nicht mit:
- dem HAP als HB-RF-HAP übers Netzwerk
- dem HAP an einem Standard FTDI über USB

Bleibt nur der Versuch über den HB-RF-USB-FTDI und das klappt aktuell auch nicht.

Das der HAP nicht die HB-RF-HAP Firmware laden darf sollte inzwischen klar sein. Der Verhindert man durch den "Affengriff".
Als Indikator dient die LED des HAP, die muss aus bleiben.
So gebootet sollte RM das Teil finden...

Code: Alles auswählen

Identifying Homematic RF-Hardware: .......HmRF: HMIP-RFUSB/HB-RF-USB@usb-3f980000.usb-1.4, HmIP: HMIP-RFUSB/HB-RF-USB@usb-3f980000.usb-1.4, OK

...und eben bei dir meckern wenn die CoPro-FW nicht downgegraded werden konnte.
In der Hilfe der RM finden wir den korrekten "Anschluss", i.d.R. /dev/raw-uart (bei mir immer /dev/raw-uart1)

Bevor wir jetzt den Downgrade versuchen beenden wir erstmal diverse Dienste:

Code: Alles auswählen

monit stop rfd
monit stop multimacd
monit stop hmipserver

Jetzt testen wir nochmal die Kommunikation:

Code: Alles auswählen

detect_radio_module --debug /dev/raw-uart

Sieht gut aus? Dann versuchen die CoPro-FW zu flashen:
Hier wieder .arch und /dev/ anpassen.

Code: Alles auswählen

/opt/java/bin/java -Dos.arch=aarch64  -Dgnu.io.rxtx.SerialPorts="/dev/raw-uart1" -jar /opt/HmIP/hmip-copro-update.jar -p "/dev/raw-uart1" -o -f "/firmware/HmIP-RFUSB/dualcopro_update_blhmip-4.4.18.eq3"

Geht das dann immer noch nicht, dann bin ich mit meinem Latein am Ende.

Was mir aber beim studieren der Unterlagen noch auffiel:
Bevor ich irgendwas mittels STM32CubeProgrammer auf den HAP geflasht habe, hatte ich erstmal "Full chip erase" gemacht.

Wenn ich so gebootet lsusb ausführe zeigt er folgendes:

Code: Alles auswählen

root@homematic-raspi:~# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 004: ID 046d:c31c
Bus 001 Device 003: ID 0424:ec00
Bus 001 Device 002: ID 0424:9514
Bus 001 Device 005: ID 0403:6f70
Bus 001 Device 006: ID 0781:5583

Statusübersicht von CUxD sagt dazu:

Code: Alles auswählen

  USB 1-1 - (9514) [HUB] - Mon Dec  4 09:08:52 2023
  USB 1-1.1 - (ec00) [FF] - no driver - Mon Dec  4 09:08:52 2023
  USB 1-1.2 - Ultra Fit [STORAGE] - Mon Dec  4 09:08:52 2023
  USB 1-1.3 - USB Keyboard [HID] - Mon Dec  4 09:08:52 2023
  USB 1-1.4 - HB-RF-USB [FF] - no driver - Mon Dec  4 09:08:52 2023

Ich hatte damals >> dieses Template << auf den FTDI geflasht.

[sectorchan]

Nach dem ganzen stoppen, inkl tippfehler

Code: Alles auswählen

root@homematic-raspi:~# monit stop rfd
root@homematic-raspi:~# monit multimacd
Invalid argument -- multimacd  (-h will show valid arguments)
root@homematic-raspi:~# monit stop multimacd
root@homematic-raspi:~# monit stop hmipserver

schaut das detect_radio_module gut aus

Code: Alles auswählen

root@homematic-raspi:~# detect_radio_module --debug /dev/raw-uart
20:04:26.529783 Raw UART device: HB-RF-ETH@192.168.1.10
20:04:26.641276 Sucessfully resetted radio module.
20:04:26.641374 Sending HM frame:  fd 00 03 fe 00 01 14 1e
20:04:26.641489 Received HM frame: fd 00 0e fe 00 00 48 4d 49 50 5f 54 52 58 5f                                     42 6c f4 c2
20:04:26.641549 Sending HM frame:  fd 00 03 fe 01 01 92 1d
20:04:29.643915 Sending HM frame:  fd 00 03 00 02 00 94 03
20:04:29.647054 Received HM frame: fd 00 04 00 02 04 03 99 19
20:04:32.649511 Sending HM frame:  fd 00 03 fe 03 01 1e 1e
20:04:32.654112 Received HM frame: fd 00 0f fe 03 05 01 48 4d 49 50 5f 54 52 58                                     5f 42 6c 6b c4
20:04:32.654172 Sending HM frame:  fd 00 03 fe 04 03 0c 12
20:04:33.328529 Received HM frame: fd 00 04 fe 04 05 01 07 46
20:04:33.845202 Received HM frame: fd 00 0f fe 01 00 48 4d 49 50 5f 54 52 58 5f                                     41 70 70 0e 20
20:04:33.845282 Sending HM frame:  fd 00 03 01 05 09 86 21
20:04:33.948962 Received HM frame: fd 00 05 01 05 04 01 01 82 2b
20:04:33.949155 Sending HM frame:  fd 00 03 01 06 02 0c 18
20:04:34.049317 Received HM frame: fd 00 10 fe 02 00 44 75 61 6c 43 6f 50 72 6f                                     5f 41 70 70 b4 3c
20:04:34.054241 Received HM frame: fd 00 0d 01 06 04 01 04 04 22 01 00 18 01 4c                                     00 0d c9
20:04:34.054315 Sending HM frame:  fd 00 03 02 07 01 8a 2d
20:04:34.057396 Received HM frame: fd 00 07 02 07 06 01 10 31 39 f8 fd
20:04:34.057464 Sending HM frame:  fd 00 03 fe 08 04 a4 03
20:04:34.062291 Received HM frame: fd 00 10 fe 08 05 01 30 14 f7 11 a0 00 04 1d                                     29 99 17 66 f4 5f
20:04:34.062365 Sending HM frame:  fd 00 03 03 09 08 ae 0f
20:04:34.066179 Received HM frame: fd 00 07 03 09 01 01 ff a5 70 dc 7a
20:04:34.174753 Sucessfully resetted radio module.
HMIP-RFUSB 1D29991766 3014F711A000041D29991766 0xFFA570 0x103139 4.4.34

Anschliessend kommt aber (Habe nun VBOx

Code: Alles auswählen

root@homematic-raspi:~# uname -m
x86_64
root@homematic-raspi:~# /opt/java/bin/java -Dos.arch=x86_64 -Dgnu.io.rxtx.Serial
Ports="/dev/raw-uart" -jar /opt/HmIP/hmip-copro-update.jar -p "/dev/raw-uart" -o
 -f "/firmware/HmIP-RFUSB/dualcopro_update_blhmip-4.4.18.eq3"
[INFO] Homematic IP coprocessor update tool V1.0.10
[INFO] SGTIN = 3014F711A000041D29991766
[INFO] Performing update with firmware file '/firmware/HmIP-RFUSB/dualcopro_upda                                    te_blhmip-4.4.18.eq3' ...
[DEBUG] Start application ...
[DEBUG] Application 'HMIP_TRX_App' running
[DEBUG] Request application version ...
[DEBUG] Request application version ...
[INFO] Updating coprocessor from version 4.4.34 to version 4.4.18
[DEBUG] Start bootloader ...
[ERROR] Error in coprocessor communication: Failed to enter bootloader
java.lang.Exception: Failed to enter bootloader
        at de.eq3.cbcs.tools.copro.update.hmip.TRXAdapterUpdater.updateTrxAdapte                                    r(TRXAdapterUpdater.java:151)
        at de.eq3.cbcs.tools.copro.update.hmip.HmipCoproUpdater.main(HmipCoproUp                                    dater.java:89)
[INFO] Exiting update tool.

ich schließe das ganze, ist ja sinnlos :/
Leider kann ich nun auch nicht mehr den FTDI flashen, da mir dieser im FT_Prog nicht angezeigt wird.