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

[benni123_]

Was kommt denn, wenn du detect_radio_module in piVCCU ausführst?

Ok, da müsste ich das Kommando innerhalb des lxc Containers ausführen, nehme ich an? Da müsste ich mich erstmal schlau lesen, wie das geht. Oder hat es jemand gerade parat?

Oder kann ich mich via SSH direkt in den lcx Container der piVCCU einloggen? Eine eigene IP hätte er ja ...

/Nachtrag: Auf der piVCCU per SSH bin ich jetzt. Allerdings scheint es detect_radio_module nicht zu geben. Oder es liegt irgendwo anders. Zumindest nicht in /bin. Auch direkt (ohne weiteren Pfad) geht es nicht.

Eine Suche

Code: Alles auswählen

# find | grep detect_radio_module
# 

gibt mir auch nichts weiter aus. Das scheint es dort so nicht zu geben.

[deimos]

Hi,

bei piVCCU ist das im Host und nicht im Container.
Aber ich kann schon die Antwort geben: Es wird die gleiche Ausgabe kommen, weil das die Antwort vom Funkmodul ist. In piVCCU und debmatic ignoriere ich das aber einfach, weil es unwichtig ist, da die wirklich verwendete Radio Mac vom rfd bei der Initialisierung gesetzt wird. Wichtig ist es nur bei ersten Start nach einem Werksreset um die initiale Config zu erstellen.

Viele Grüße
Alex

[jmaus]

In piVCCU und debmatic ignoriere ich das aber einfach, weil es unwichtig ist, da die wirklich verwendete Radio Mac vom rfd bei der Initialisierung gesetzt wird.

Sowas dachte ich mir schon. Aber wie kannst du dir erklären das dieses Funkmodul als Adresse 0x00000 zurückgibt? Das sehe ich hier ehrlich gesagt zum ersten Mal. Dafür muss es doch irgendein Grund geben?

Wichtig ist es nur bei ersten Start nach einem Werksreset um die initiale Config zu erstellen.

Was machst du dann in dem Fall? Bei auftreten von 0x00000 eine zufällig generierte Radio Mac ID generieren und diese dann in /etc/config/ids abspeichern?

[benni123_]

Hallo Alex,

Danke. Das würde das Verhalten erklären.

Die Frage bleibt, welche Ursache die fehlerhafte HmRF-Adresse hat/haben könnte?

Haben wir auf Software-Seite noch Möglichkeiten, dem weiter auf den Grund zu gehen?

Oder müsste man jetzt schon auf die Hardware schauen?

Viele Grüße

Benjamin

[deimos]

In piVCCU und debmatic ignoriere ich das aber einfach, weil es unwichtig ist, da die wirklich verwendete Radio Mac vom rfd bei der Initialisierung gesetzt wird.

Sowas dachte ich mir schon. Aber wie kannst du dir erklären das dieses Funkmodul als Adresse 0x00000 zurückgibt? Das sehe ich hier ehrlich gesagt zum ersten Mal. Dafür muss es doch irgendein Grund geben?

Grund kenne ich keinen, aber ich habe sowas schon gesehen, daher habe ich auch entsprechenden Code im detect-radio-module drin.

Wichtig ist es nur bei ersten Start nach einem Werksreset um die initiale Config zu erstellen.

Was machst du dann in dem Fall? Bei auftreten von 0x00000 eine zufällig generierte Radio Mac ID generieren und diese dann in /etc/config/ids abspeichern?

Genau das, nicht nur wegen diesem Problem, sondern auch für den Fall, dass der erste Start ohne Funkmodul durchgeführt wird.

Viele Grüße
Alex

[jmaus]

Sowas dachte ich mir schon. Aber wie kannst du dir erklären das dieses Funkmodul als Adresse 0x00000 zurückgibt? Das sehe ich hier ehrlich gesagt zum ersten Mal. Dafür muss es doch irgendein Grund geben?

Grund kenne ich keinen, aber ich habe sowas schon gesehen, daher habe ich auch entsprechenden Code im detect-radio-module drin.

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

Was machst du dann in dem Fall? Bei auftreten von 0x00000 eine zufällig generierte Radio Mac ID generieren und diese dann in /etc/config/ids abspeichern?

Genau das, nicht nur wegen diesem Problem, sondern auch für den Fall, dass der erste Start ohne Funkmodul durchgeführt wird.

Sowas müsste in RaspberryMatic im Grunde ja auch schon drin sein, denn auch das kann man ja gänzlich ohne Funkmodul betreiben. Und ehrlich gesagt kommt mir das ganze aktuelle wie ein DejaVu vor und ich meine mich zu erinnern das ich die Erkennung falscher/invalider Radio Macs eigentlich auch in RM mal eingebaut hatte. Vielleicht hat sich da eine Regression aufgetan?!? Hmmm

[Baxxy]

DejaVu

Du denkst dabei aber nicht an die CCU3/RM "Klon-Armee" wo durch einen Fehler beim Auslesen des Funkmoduls jedes frische System die 65535 als BidCos-Adresse bekam? Das war was anderes.

Sowas müsste in RaspberryMatic im Grunde ja auch schon drin sein

Nein, ist es nicht.
Eine RM die beim ersten Start kein Funkmodul hat legt auch keine '/usr/local/etc/config/ids' an.
Wozu auch? Ein System ohne Funkmodul braucht doch keine "Funk-Adresse".

Letztlich schlägt die Erkennung des "HM-Teils" vom HM-MOD-RPI-PCB (des TE) wohl fehl weil die Adresse nicht '0x000000' sein darf.
https://github.com/jens-maus/RaspberryM ... dware#L210

[jmaus]

Letztlich schlägt die Erkennung des "HM-Teils" vom HM-MOD-RPI-PCB (des TE) wohl fehl weil die Adresse nicht '0x000000' sein darf.
https://github.com/jens-maus/RaspberryM ... dware#L210

Danke für den Link. Das müsste exakt die Stelle wohl sein die dafür sorgt das bei einem 0x000000 er dann im Grunde die gesamte HmRF/rfd, usw. als nicht existent annimmt und einfach davon ausgeht das das Funkmodul lediglich HmIP kann. Die Frage wäre nur, was passiert wenn man diese Zeile jetzt entfernt wenn man ein HmIP-RFUSB-TK z.B. nutzt das ja kein BidCos/HmRF kann und dann sicherlich an der Stelle auch 0x000000 zurückgeben wird. Dann könnte es sein die HmIP-RFUSB-TK nutzer haben/bekommen ein Problem....

[deimos]

Hi,

die TK Variante vom HMIP-RFUSB kannst du zuverlässig am Radio Module Type in der ersten Spalte erkennen, siehe https://github.com/alexreinert/piVCCU/b ... n.cpp#L123

Viele Grüße
Alex

[jp112sdl]

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