CUL teilweise abgestürzt? Evtl. Probleme mit CUL-Firmware und Kopp-Funkschaltern?

[Willi]

Hallo,

ich habe seit etwa einer Woche zwei CUL mit RFR im Einsatz
(- lokale CUL an FHEM : CUL V3.2 mit Firmware "V 1.39 CUL868", sowie
- Remote RFR CUL an USB ohne Server: CUL V3.2 mit Firmware "V 1.39
CUL868")

Die CUL V 3.2 habe ich erst kürzlich geliefert bekommen. Die CUL V2
ist schon seit Anfang des Jahres im Einsatz.

Die ersten Tage lief auch alles ohne Probleme inkl. RFR. Da ich auch
RSSI logge und mir per pgm2 anzeige, konnte ich auch schön die
Verbesserungen sowie Pakete beider CULs sehen (bzw. zwei Linien
unterschiedlicher RSSI). RFR ist wirklich eine tolle Sache! :-)

Um die Situation noch komplizierter zu machen: Ich habe am Wochenende
zwei Funkschalter von Kopp (Free Control) installiert, die auch auf
868 Mhz funken. Allerdings habe ich es nicht geschafft mit diesen
Funkschaltern die CUL bei Tests durcheinander zu bringen.

Heute habe ich festgestellt, dass keine Daten mehr seit gestern etwa
20:00 Uhr von den CULs in FHEM angezeigt wurden (keine Anzeige der
Daten in den Grafiken sowie Logs mehr).
FHEM lief aber noch soweit, dass die Daten meines RFXCOM-Receivers
(Oregon-Wettersensoren) wurden korrekt empfangen und angezeigt
wurden.

Gemäß Analyse der Logfiles scheint schon zwei Tage vor dem Hänger RSSI
nicht mehr richtig funktioniert zu haben (ich sehe keine Daten mehr
mit entsprechender RSSI).

Keinerlei Fehlermeldung in fhem.log

Nach Neustart von FHEM wurden dann wieder Daten empfangen. Allerdings
funktionierte "get CUL raw V" nicht mehr. Es wurde "no answer"
angezeigt.
Nach Abstecken des lokalen CUL und Neuanschluss läuft jetzt wieder
alles (inkl. "get CUL raw V") ohne erneuten Restart von FHEM.

Ich sehe drei folgende mögliche Fehlerquellen:
-1- Hardwareprobleme der neuen CUL V3.2.
-2- CUL-Firmware-Probleme mit RFR
-3- CUL-Firmware-Probleme mit den Kopp-Funktschaltern

Mein Vorschlag wäre erst mal die CUL V3.2 abzustecken statt dessen
nur die CUL V2 an meinem produktiven FHEM lokal zu betreiben und
einige
Woche zu warten. Mit der CUL V3.2 würde ich dann an einem Testsystem
betreiben.

Oder soll ich anders vorgehen, da ich auf diese Weise kein RFR teste?

MfG Willi

[Rudolf Koenig]

> Nach Neustart von FHEM wurden dann wieder Daten empfangen. Allerdings
> funktionierte "get CUL raw V" nicht mehr. Es wurde "no answer"
> angezeigt.

Das ist deswegen komisch, weil 00_CUL.pm beim Start genau das durchfuehrt, um
sich zu vergewissern, dass es ein CUL ist. Wenn es nicht wie erwartet V...
zurueckliefert, dann kommt die Meldung:
Not an CUL device, got for V: ...

Mich wuerde noch die Blinkaktivitaet der beiden interessieren, im Ruhezustand
und falls irgendein Sender gerade schaltet.

[Willi]

Ich hatte heute wieder einen Ausfall.

Diesmal sehr seltsam:
- Im Zeitraum 9.11. 22:01 Uhr bis 10.11. 07:20 Uhr keine Daten
- Im Zeitraum 10.11 Uhr 07:20 Uhr bis 10.11. 10:17 Uhr kamen Daten,
ohne dass ich etwas geändert habe. In diesem Zeitraum schien auch RFR
zu funktionieren (zu sehen an den RSSI).
- Danach wieder keine Daten
- "get CUL raw V" funktionierte noch.
- Im Logfile nichts zu sehen. Die LEDs blinkten im Sekundenrythmus auf
beiden CULs. Kein zusätzliches Blinken des Datenempfangs.

Ich habe dann FHEM neu gestartet. Danach lief wieder der Datenempfang
ohne irgendwelche Änderung an den CULs.

Wenn man den Kopp-Funkschalter betätigt blinkt nichts bei CUL. Scheint
also nicht erkannt zu werden, was ja auch so zu erwarten ist.

Ich habe jetzt mal testweise CUL-V3.2 vom FHEM-Server entfernt und
statt dessen Remote-CUL V2 angesteckt.
CUL V3.2 werde ich dann gleich auf einem FHEM-Testsystem installieren
und bei beiden CULs RFR abschalten.

Mal sehen, was dann passiert.

[Willi]

Kurzes Update.
Seit der Abschaltung von RFR und der Verwendung von CUL-V2 sowie CUL-
V3.2 an separaten FHEM-Servern laufen beide CULs und auch FHEM bisher
ohne irgendwelche Störungen.