Nach reboot keine Kommunikation mit HMIP Bewegungsmelder

[pboettch]

Hallo,

Ich bin vor Kurzem von FHEM auf RaspberryMatic umgestiegen (auf einem RPI4 im Docker-Container, mit HM-MOD-RPI-PCB). (Kleine Randnotiz, ich sah in den logs, dass RaspberryMatic die Firmware vom HM-MOD-RPI-PCB aktualisierte und erst danach wurde HMIP aktiviert, genial!).

Ich hatte davor nur HM Geräte im Einsatz. Das Aufsetzen von RaspberryMatic erlaubt mir nun auch das Ansteuern von HMIP Geräten. Vor 2-3 Jahren hatte ich fälschlicherweise 3 HMIP Bewegungsmelder gekauft, die ich jetzt endlich nutzen kann/konnte.

Meine erste Frage wäre: Das Anlernen der HMIP Geräte ging nur mit Eingabe der Seriennummer und des Keys ("Teach In Local"). Hätte es auch über Teach in HmIP funktionieren müssen?

Mein eigentliches Problem ist aber, dass nach einem Neustart der RPIs RaspberryMatic nun "Device communication disturbed" für alle 3 Bewegungsmelder (mit einem ausgegrauten "Confirm"-Button) meldet. Woran kann das liegen und was kann ich tun?

Bei meiner Recherche bzgl. dieses Problems, las ich, dass es an einem zu hohem duty-cycle liegen kann. Dieser liegt bei mir, laut Anzeige auf de RPMatic-Startseite zwischen 8-12 %.

[frd030]

Meine erste Frage wäre: Das Anlernen der HMIP Geräte ging nur mit Eingabe der Seriennummer und des Keys ("Teach In Local"). Hätte es auch über Teach in HmIP funktionieren müssen?
Mein eigentliches Problem ist aber, dass nach einem Neustart der RPIs RaspberryMatic nun "Device communication disturbed" für alle 3 Bewegungsmelder (mit einem ausgegrauten "Confirm"-Button) meldet. Woran kann das liegen und was kann ich tun?
Bei meiner Recherche bzgl. dieses Problems, las ich, dass es an einem zu hohem duty-cycle liegen kann. Dieser liegt bei mir, laut Anzeige auf de RPMatic-Startseite zwischen 8-12 %.

Es hätte auch ohne SIGTIN und KEY gehen müssen, wenn Deine RM eine Internetverbindung hat. Hat sie?

Nein, der Duty Cycle ist nicht das Problem für die Kommunikationsstörungen, aber vermutlich der Carrier Sense.

Du hast einen Raspi 4! Der verursacht jede Menge Funkstörungen, siehe hier.
Das heisst speziell bei HmIP, dass aufgrund des "Listen before Talk" die CCU nicht senden kann, wenn sie einen Funkstörer (hier vermutlich den Raspi 4) "hört". Bei HM-Classic geht es meist immer noch, da gibt es kein Listen before Talk!

Der CarrierSense würde das aufzeigen (auf der Startseite der RM). WIMRE kann aber Dein Funkmodul den Carrier Sense nicht liefern.

[Sven_A]

Mein eigentliches Problem ist aber, dass nach einem Neustart der RPIs RaspberryMatic nun "Device communication disturbed" für alle 3 Bewegungsmelder (mit einem ausgegrauten "Confirm"-Button) meldet. Woran kann das liegen und was kann ich tun?

Für Bewegung vor dem Bewegungsmelder sorgen. Nein, im ernst: mein HmIP-SMI55 hat das von Anfang an. Vermutlich versucht die Zentrale ihn nach einem Reboot zu erreichen und ignoriert den Fakt das dass ein batteriebetriebener Sensor ist der sich nicht einfach so wecken lässt. Mit der ersten Bewegung läuft alles. Auch eine Aktualisierung der gemessenen Helligkeit nach einiger Zeit sollte die Dinge wieder richten.

Gruß,
Sven

[pboettch]

Es war ein Resetproblem. Nach reseten der Sensoren und erneutem anlernen (ohne manuelle Keyeingabe) geht (erstmal alles). Jetzt muss ein Bugfix-firmware-update her.