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

[jp112sdl]

Müsste mit den Silvercrest HmIP-HAP-B1 auch funktionieren oder nicht?

Jup

[jp112sdl]

Wäre es möglich auf dieser Basis aus dem HmIP-HAP ein klassisches LAN-Gateway auf Basis von einem HM-LGW-O-TW-W-EU zu flashen? Mit HMLANGW viewtopic.php?f=18&t=69229 ?

Ein klares Jein.
Die hmlangw Quellen sind ja frei verfügbar. Das auf den STM32 zu portieren sollte überschaubar sein.

Jedoch läuft auf dem Funkmodul die DualCoPro Firmware. Und damit kann der hmlangw nicht.
Ich hab mich aber auch nicht weiter damit befasst, was man machen müsste, damit der hmlangw auch darüber kommunizieren kann.

[jmaus]

Wäre es möglich auf dieser Basis aus dem HmIP-HAP ein klassisches LAN-Gateway auf Basis von einem HM-LGW-O-TW-W-EU zu flashen? Mit HMLANGW viewtopic.php?f=18&t=69229 ?

Ein klares Jein.
[...]
Jedoch läuft auf dem Funkmodul die DualCoPro Firmware. Und damit kann der hmlangw nicht.
Ich hab mich aber auch nicht weiter damit befasst, was man machen müsste, damit der hmlangw auch darüber kommunizieren kann.

In der Tat wäre das IMHO eine wirklich gute Sache wenn sich mal jemand dem recht alten hmlangw Quellcode annehmen würde und den vielleicht sogar dahin bekommt das dieser mit aktuellen DualCoPro-Firmwares der Homematic-Funkmodule auch funktioniert. Mir selber fehlt da leider in der Tat die Zeit!

[AchimHome]

Wer nicht aufpasst, kann sein Device unbrauchbar machen.

Ich habe mir meinen HMIP-HAP gerade erfolgreich gebrickt. Habe es mit der CLI unter macOS versucht und war leider nicht erfolgreich. Der CLI-Befehl war:

Code: Alles auswählen

/Applications/STMicroelectronics/STM32Cube/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/MacOs/bin/STM32_Programmer_CLI --connect port=tty.usbserial-1440 -rdu -w HB-RF-HAP.hex

Die Übertragung hat bei 82 % abgebrochen, da vorher bereits das Memory gelöscht wurde, ist das Teil jetzt unbrauchbar. Seitdem ist das Teil mausetot, keine LEDs gehen mehr an.

Hat jemand in der Gegend von Nürnberg über die Feiertage noch ein HMIP-HAP günstig abzugeben?

[jp112sdl]

Ich habe mir meinen HMIP-HAP gerade erfolgreich gebrickt.

Kann eigentlich nicht passieren, da der Bootloader nicht angefasst wird.

Heißt: Selbst wenn beim Flashen an irgendeiner Stelle was daneben geht, kommst du immer wieder in den Bootloader (mit der Brücke siehe 1. Beitrag) rein.



P.S.: Cool, die

CLI unter macOS

kannte ich noch gar nicht.

[AchimHome]

Oh cool, danke für den Tipp mit der Brücke. Das Teil ist tatsächlich nicht kaputt.
Es kamen halt keine normalen Bootmeldungen mehr rein, und die LED ging nicht mehr an, Ethernet hatte auch nicht mehr geleuchtet.
Mit Büroklammer als Brücke kommt man aber tatsächlich wieder ins Bootmenü und kann neu flashen.
Siehe Screenshot, es war diesmal erfolgreich.

[jp112sdl]

dem recht alten hmlangw Quellcode annehmen würde und den vielleicht sogar dahin bekommt das dieser mit aktuellen DualCoPro-Firmwares der Homematic-Funkmodule auch funktioniert.

Hmm, das scheint evtl. gar nicht notwendig zu sein.

Wenn man einfach den multimacd vorschaltet und dem hmlangw als Schnittstelle /dev/mmd_bidcos übergibt, kommt was Brauchbares raus.
Hab jetzt aber erstmal nur die technische Anbindung gecheckt.

Ob es tatsächlich auch "funkt", muss ich (gern auch jemand anderes) irgendwann mal probieren.

Und das wäre dann auch was für einen eigenen Thread.

[jmaus]

dem recht alten hmlangw Quellcode annehmen würde und den vielleicht sogar dahin bekommt das dieser mit aktuellen DualCoPro-Firmwares der Homematic-Funkmodule auch funktioniert.

Hmm, das scheint evtl. gar nicht notwendig zu sein.

Wenn man einfach den multimacd vorschaltet und dem hmlangw als Schnittstelle /dev/mmd_bidcos übergibt, kommt was Brauchbares raus.
Hab jetzt aber erstmal nur die technische Anbindung gecheckt.

Hmm, das ist ne interessant erkenntnis. Dachte das hätte ich bereits schon einmal gecheckt bzw. überprüft vor Jahren und da ging das meiner Erinnerung nach nicht das man dem hmlangw einfach /dev/mmd_bidcos gibt. Da hat der den Dienst trotzdem mit verweigert.

Müsste man also wirklich nochmal in der Tat überprüfen und wenn das wirklich so ist könnte ich das ganze ja in der Tat umbauen das man kein FW Downgrade mehr machen muss auf die 1.4.1 Version. Und dann sollte das doch auch prinzipiell mit einem RPI-RF-MOD gehen, oder?

[jp112sdl]

da ging das meiner Erinnerung nach nicht das man dem hmlangw einfach /dev/mmd_bidcos gibt. Da hat der den Dienst trotzdem mit verweigert.

Ich hatte gestern mit Debian auf einem alten Tinkerboard gespielt.
eq3_char_loop und hmlangw kompiliert und den HM-MOD-UART mit einem einfachen FTDI als /dev/ttyUSB0 angeschlossen.

Jetzt habe ich es noch mal mit 2 OVA VMs und direkt mit dem HB-RF-USB Treiber über /dev/raw-uart aufgebaut.
Das geht genau so gut.

Und dann sollte das doch auch prinzipiell mit einem RPI-RF-MOD gehen, oder?

Ja, und auch mit dem HmIP-RFUSB oder auch einem (wie hier im Thread beschrieben) umgeflashten HmIP-HAP.

[jmaus]

Jetzt habe ich es noch mal mit 2 OVA VMs und direkt mit dem HB-RF-USB Treiber über /dev/raw-uart aufgebaut.
Das geht genau so gut.

Und dann sollte das doch auch prinzipiell mit einem RPI-RF-MOD gehen, oder?

Ja, und auch mit dem HmIP-RFUSB oder auch einem (wie hier im Thread beschrieben) umgeflashten HmIP-HAP.

Sehr interessant. Dann müsste ich mal schauen ob ich das in RaspberryMatic so umgebaut bekomme das ich den LANGW Modus mit multimacd und eq3_char_loop starten lassen und hmlange dann mmd_bidcos nutzen lassen. Wie gesagt dachte ich ich hätte das eigentlich schon getestet.. aber wer weiss