HmIP Aktoren können nicht an RPI-RF-MOD angelernt werden

[Marci24h]

Hallo zusammen,

Seit ein paar Tagen versuche ich verzweifelt zwei Aktoren (HmIP-FSM & HmIP-FROLL) an RaspberryMatic mit RPI-RF-MOD anzulernen und scheitere :(
Da es im Haus ein paar Änderungen gab, habe ich beschlossen neue Anforderungen mit HomeMatic IP umzusetzen. (Bisher ist HomeMatic im Einsatz)

Daher werkelt jetzt ein Raspberry Pi 4 B mit RPI-RF-MOD in unserer Wohnung. (Um die IP Komponenten anbinden zu können)
Das Anlernen habe ich mit und ohne Internetzugang über KEY & SGTIN versucht.
Allerdings tauchen die Geräte nicht im Posteingang auf.

Zwei Sensoren (HmIP-SLO & HmIP-SPI) konnten einen Tag zuvor Problemlos angelernt werden.
Diese Übermitteln auch jetzt aktuelle Daten.
Einen defekt der RPI-RF-MOD Platine würde ich daher ausschließen.

Aktueller Aufbau & Versionen:

Raspberry Pi 4 B mit Raspbian GNU/Linux 10 (buster)
Linux 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux
# dpkg --list | grep -E 'docker|ccu'
ii  docker-ce                            5:20.10.5~3-0~debian-buster         armhf        Docker: the open-source application container engine
ii  docker-ce-cli                        5:20.10.5~3-0~debian-buster         armhf        Docker CLI: the open-source application container engine
ii  docker-ce-rootless-extras            5:20.10.5~3-0~debian-buster         armhf        Rootless support for Docker.
ii  pivccu-modules-dkms                  1.0.59                              all          DKMS package for kernel modules needed for Homematic
ii  pivccu-modules-raspberrypi           2.0-15                              all          Raspberry Pi kernel modules needed for Homematic
raspberrymatic image: 3.57.4.20210320

Als Test habe ich mal die beiden Versionen raspberrymatic:3.55.10.20210213 & 3.57.5.20210415-acba907 getestet. Jedoch ebenfalls ohne Erfolg.
Da dies ebenfalls Erfolglos blieb, habe ich das Docker Volume gelöscht. -> Der RaspberryMatic Container / CCU war somit im Werkszustand.

Hier das Log vom letzten start des Container's:

Starting watchdog...
Identifying onboard hardware: oci, OK
/etc/init.d/S02InitRTC: line 38: can't create /sys/class/leds/rpi_rf_mod:green/trigger: nonexistent directory
/etc/init.d/S02InitRTC: line 39: can't create /sys/class/leds/rpi_rf_mod:red/trigger: nonexistent directory
/etc/init.d/S02InitRTC: line 40: can't create /sys/class/leds/rpi_rf_mod:blue/trigger: nonexistent directory
Initializing RTC Clock: rx8130, OK
Running sysctl: OK
Checking for Factory Reset: not required
Checking for Backup Restore: not required
ln: /dev/raw-uart: File exists
ln: /dev/eq3loop: File exists
Initializing System: OK
Starting logging: OK
Populating /dev using udev: done
Init onboard LEDs: init, OK
Starting irqbalance: OK
Starting network: eth0: link up, fixed, firewall, inet up, 172.18.0.2, OK
Identifying Homematic RF-Hardware: ....HmRF: RPI-RF-MOD/GPIO, HmIP: RPI-RF-MOD/GPIO, OK
Updating Homematic RF-Hardware: RPI-RF-MOD: 4.2.14, OK
Starting hs485dLoader: disabled
Starting xinetd: OK
Starting eq3configd: OK
Starting lighttpd: OK
Starting ser2net: disabled
Starting ssdpd: OK
Starting sshd: OK
Starting NUT services: disabled
Initializing Third-Party Addons: OK
Starting LGWFirmwareUpdate: ...OK
Setting LAN Gateway keys: OK
Starting hs485d: disabled
Starting multimacd: .OK
Starting rfd: .OK
Starting HMIPServer: .........OK
Starting ReGaHss: .OK
Starting CloudMatic: OK
Starting NeoServer: OK
Starting Third-Party Addons: OK
Starting crond: OK
Setup onboard LEDs: booted, OK

Beim Starten bin ich dann zufällig auf folgenden Eintrag gestoßen:

Starting HMIPServer: WARNING: SGTIN 00089BXXXXXX49 not found in regadom... moved 3014F711A000089BXXXXXX49.* to /etc/config/crRFD/data/old_20210414-171146/
WARNING: SGTIN 00115BXXXXXXC9 not found in regadom... moved 3014F711A000115BXXXXXXC9.* to /etc/config/crRFD/data/old_20210414-171146/

Also habe ich die zur SGTIN passenden Dateien gelöscht

/ # rm /etc/config/crRFD/data/3014F711A000089BXXXXXX49.dev
/ # rm /etc/config/crRFD/data/old_20210414-171146/3014F711A000089BXXXXXX49.dev 
/ # rm /etc/config/crRFD/data/old_20210414-171146/3014F711A000115BXXXXXXC9.dev

und nach einem reboot das anlernen erneut versucht. -> Jedoch ohne Erfolg :(

Die beiden Aktoren geben nach dem bestromen folgende Leuchtsignale von sich:
extrem kurz Orange,
dann ca.: 1,5 Sek Grün,
dann im 10 Sekundentakt Orange.

In den beiden Logs tail -f /var/log/messages /var/log/hmserver.log war nichts auffälliges zu finden.
Also habe ich das Loglevel herauf (auf info) gesetzt und dabei folgende Einträge gefunden:

local0.info ReGaHss: Info: Event="00089BXXXXXX49:0"."UNREACH"=true [execute():iseXmlRpc.cpp:321]
local0.info ReGaHss: Info: WARNING: no device object exists (interface: 1009 address:'00089BXXXXXX49:0') [GetObjectByHSSAddress():iseXmlRpc.cpp:2170]
local0.info ReGaHss: Info: Event="00089BXXXXXX49:0"."UNREACH"=true [execute():iseXmlRpc.cpp:321]
local0.info ReGaHss: Info: WARNING: no device object exists (interface: 1009 address:'00089BXXXXXX49:0') [GetObjectByHSSAddress():iseXmlRpc.cpp:2170]

Da die ID / address ein Teil der hinteren SGTIN ist, scheint es irgendeine Art von Kommunikation zu geben, jedoch nicht Final zu Stande zu kommen.
In der RaspberryMatic WebGUI tauchen unter "Startseite > Programme und Verknüpfungen > Direkte Verknüpfungen" zwei Verknüpfungen zu Sender Unbenanntes Gerät und Empfänger Unbekanntes Gerät auf.
Beschreibung: Verknüpfung der internen Gerätetaste Unbenanntes Gerät

Das zurücksetzen der Aktoren auf Werkseinstellungen habe ich ebenfalls getestet.
(4 Sek. drücken, schnelles Blinken, erneut 4 Sek. drücken, grüne LED, dann im 10 Sekundentakt Orange)

Die "Basisstation" RPI-RF-MOD und der Aktor befinden sich im selbem Raum. ~ 2 Meter Abstand. Habe es aber auch bereits aus einem anderem Raum getestet.

Was kann ich noch prüfen / testen?
(Ich muss gestehen, das ich bis jetzt noch keine Berührungspunkte mit RaspberryMatic oder einer CCU hatte.)

In den Logs meines DNS-Servers konnte ich die beiden Anfragen finden.

secgtw.homematic.com. AAAA IN
secgtw.homematic.com. A IN

Auf meiner zentralen Firewall habe ich für den Host das logging aktiviert und sehe immer mal eine TCP-Verbindung zu folgender IP-Adresse:Port.
DST: 81.14.202.208:8443
(Wird natürlich durchgelassen)

Unabhängig davon:
Seit 2015 hatte ich den hm-cfg-lan mit fhem in Betrieb.
Ca.: 2018 kam dann iobroker dazu und wurde mit fhem gekoppelt.
Ende 2020 wurde fhem durch homegear abgelöst.
Bis jetzt lief das ganze setup bis auf wenige Aussetzer sehr stabil.
Mit dem Einsetzen der Batterien in die HmIP Sensoren ist das hm-cfg-lan ufo ständig abgestürzt und war im Netzwerk nicht mehr erreichbar.

04/13/21 19:16:30.414 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "My-HM-CFG-LAN": Error in file PhysicalInterfaces/HM-CFG-LAN.cpp line 347 in function void BidCoS::HM_CFG_LAN::reconnectThread(): Could not $
04/13/21 19:16:31.646 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "My-HM-CFG-LAN": Warning: Connection to HM-CFG-LAN closed. Trying to reconnect...

Daher habe ich Firmware Update auf Version 0.965 durchgeführt. Seit dem sind keine Unterbrechungen mehr zu Verzeichnen.
Die "alte" HomeMatic, homegear, iobroker Installation läuft in einer virtuellen Maschine auf einem KVM-Host und nicht auf dem Raspberry.

Testweise habe ich das Gateway vom Strom genommen und dann versucht einen HmIP Aktor anzulernen.
Jedoch ebenfalls ohne Erfolg.

[Baxxy13]

Bei

Raspberry Pi 4 B mit RPI-RF-MOD

läuten sofort die Alarmglocken. Möglicherweise stört dein Pi4B so stark den Homematic-Funk das die Anlernversuche scheitern. Dazu würden dann auch die UNREACH Meldungen im hmserver.log passen.
Zum Thema "Pi4B als Homematic - Zentrale" hatte ich mal einen kleinen "Leitfaden" verfasst. Zu finden im Homematic Forum.

[Marci24h]

Danke für den wichtigen Hinweis.
Ich hatte deinen Artikel bereits zuvor gelesen, aber jetzt, als das Problem auftrat, nicht mehr daran Gedacht.
Werde heute Abend mal meinen Pi B+ (v1.2) ausprobieren und Rückmeldung geben.
Dann allerdings RaspberryMatic nativ (ohne docker) laufen lassen.

Der CS Wert auf der Startseite für die CCU schwankt zwischen ~ 4% und 45%.
Dachte das er Teilweise aufgrund der anderen Komponenten im Haus so hoch sei.

[jens-maus]

Der CS Wert auf der Startseite für die CCU schwankt zwischen ~ 4% und 45%.
Dachte das er Teilweise aufgrund der anderen Komponenten im Haus so hoch sei.

Damit hat/kann das nichts zu tun. Ich habe fast 200 HomeMatic/homematicIP Geräte im Haus verteilt und mein CarrierSense-Wert ist konstant 0%.

[Marci24h]

So, habe das Image RaspberryMatic-3.57.4.20210320-rpi0.zip auf eine SD-Kart gepackt, das Modul auf den Pi B+ umgesteckt und gestartet.
Anschließend das zuvor erstellte Backup aus dem Container wiederhergestellt.
Die beiden Sensoren haben direkt gefunkt und auch das anlernen der beiden Aktoren hat auf Anhieb geklappt.
Vielen Dank für eure Hilfe!

Der CarrierSense Wert ist jetzt in der Regel bei 0%
Ab und zu wechselt er mal auf 1%

PS.: Am Pi4B war Bluetooth und W-Lan deaktiviert. An den USB-Ports war kein Gerät angeschlossen.
Vermutlich war es trotzdem das Vorhandensein des USB 3 Signals.
(Hätte noch eine GPIO Erweiterungsplatine, dann wäre das Modul 3 ~ 4 cm weiter weg.)

[jens-maus]

PS.: Am Pi4B war Bluetooth und W-Lan deaktiviert. An den USB-Ports war kein Gerät angeschlossen.
Vermutlich war es trotzdem das Vorhandensein des USB 3 Signals.
(Hätte noch eine GPIO Erweiterungsplatine, dann wäre das Modul 3 ~ 4 cm weiter weg.)

Statt sowas zu machen würde ich empfehlen gleich zum HB-RF-USB-2 oder HB-RF-ETH zu greifen und damit das Funkmodul entsprechend abzusetzen. Damit klappt es dann auch definitiv mit einem RaspberryPi4 (wenn es denn unbedingt einer sein muss).

[Marci24h]

Das (GPIO Erweiterungsplatine) wäre dann nur ein Test.
Für den Betrieb bleibe ich beim alten Raspberry.
Der Pi4B sollte noch ein paar "Backup" Dienste wie Sekundären DNS-Server, zweiten DHCP-Server, Ersatz VPN-Einwahl, etc. zur Verfügung stellen.
Das kann man ja auch unabhängig voneinander Betreiben. (Ursprünglich wollte ich alles auf einem Versuchen)

[friedpa]

Bei mir hat das "absetzen" des Funkmoduls (mit einem ETH) vom RPI 4 den entscheidenden Durchbruch solcher Probleme gebracht. Kann nur empfehlen den Leitfaden von Baxxy13 zu folgen und die Distanz zwischen RPI 4 und dem Funkmodul zu maximieren.