Hi,
ich habe einen neuen Wasserzähler mit WMBus bekommen.
Um meinen Verbrauch zu empfangen habe ich mir einen NanoCul gekauft.
AESKey vom Versorger geholt und alles eingerichtet. Empfang läuft, alles super........
ABER: Nach ein paar Tagen ist der Empfang plötzlich tot.
Es gibt keine Fehlermeldung. Im Logfile ist kein Eintrag vorhanden. Der Stick ist nach wie vor in FHEM verbunden.
Starte ich FHEM neu ist der Empfang wieder möglich bis nach einigen Tagen wieder das selbe Problem auftritt.
Jetzt bin ich ein wenig ratlos was das Problem sein könnte. Es gibt ja keinen Fehler.
Hat von euch jemand ähnliche Probleme bereits gehabt?
Im Anhang ein paar Screenies vom Status.
Hallo,
wie oft rufst Du die Daten ab. Ggf. ist das Zeitbudget überschritten und der Nano macht zu.
Grüße Jörg
Vielleicht hilft auch ein Verbose 4 (oder 5) am CUL_1 dabei zu sehen was passiert (oder auch nicht) wenn der Stick tot ist.
Bzw. in der Zeit davor.
Bei einem Wasserzähler bleibt die Datenmenge im Log hoffentlich beherrschbar.
Gruß Ralf
Zitat von: JoWiemann am 24 August 2025, 05:47:50wie oft rufst Du die Daten ab. Ggf. ist das Zeitbudget überschritten und der Nano macht zu
Im Screenshot "CUL_1_MSGCNT 6434" sieht schon nach viel Datenverkehr aus.
Zitat von: Olli7766 am 23 August 2025, 20:54:06Starte ich FHEM neu ist der Empfang wieder möglich
dann würde vermutlich auch ein einfaches "set reopen" helfen.
Etwa off-topic:
ZitatAESKey vom Versorger geholt ...
Gibt es irgendwelche Tricks dabei? Mein Versorger stellt sich doof.
Zitat von: JoWiemann am 24 August 2025, 05:47:50Hallo,
wie oft rufst Du die Daten ab. Ggf. ist das Zeitbudget überschritten und der Nano macht zu.
Grüße Jörg
Hi Jörg. Ich verstehe nicht was du mit Zeitbudget und "der Nano macht zu" meinst.
Der Wasserzähler ist ein Hydrus Typ 173. Dieser sendet alle 40 Sekunden seinen Verbrauch per WMBus raus. Das ist von den Stadtwerken so eingestellt und kann ich nicht ändern.
Der CUL Nano empfängt nur. Ist passiv. Da wird nichts abgerufen.
Zitat von: RalfRog am 24 August 2025, 09:03:41Vielleicht hilft auch ein Verbose 4 (oder 5) am CUL_1 dabei zu sehen was passiert (oder auch nicht) wenn der Stick tot ist.
Bzw. in der Zeit davor.
Bei einem Wasserzähler bleibt die Datenmenge im Log hoffentlich beherrschbar.
Gruß Ralf
Ja der Stick läuft jetzt im Verbose 5. Mal schauen wann der nächste Crash kommt und was dann drinnen steht. Danke für den Tipp.
Zitat von: RalfRog am 24 August 2025, 09:09:40Zitat von: JoWiemann am 24 August 2025, 05:47:50wie oft rufst Du die Daten ab. Ggf. ist das Zeitbudget überschritten und der Nano macht zu
Im Screenshot "CUL_1_MSGCNT 6434" sieht schon nach viel Datenverkehr aus.
Tja...... alle 40 Sekunden halt........
Zitat von: frank am 24 August 2025, 10:02:16Zitat von: Olli7766 am 23 August 2025, 20:54:06Starte ich FHEM neu ist der Empfang wieder möglich
dann würde vermutlich auch ein einfaches "set reopen" helfen.
Werde ich nach dem nächsten Crash einstellen und schauen was es bewirkt.
Zitat von: rudolfkoenig am 24 August 2025, 11:01:23Etwa off-topic:
ZitatAESKey vom Versorger geholt ...
Gibt es irgendwelche Tricks dabei? Mein Versorger stellt sich doof.
Kein Trick und keine Magie notwendig :)
Eine freundliche E-Mail an die Stadtwerke und 2 Tage später kam der Key per E-Mail.
War echt total unkompliziert. Es gab keine Nachfrage oder ähnliches.
Beim Stromzähler habe ich auch den PIN zum freischalten der erweiterten Info Daten erhalten.
Ist bei uns in der Region echt easy.
Und sollte ja heute eigentlich standard sein. Im Zeitalter von Industrie 4.0 8)
Gerade wieder gestorben..........
Keine Fehlermeldung und im Logfile steht mit Verbose 5 absolut nichts???? :o :o
Jetzt weiß ich nicht mehr weiter...........
Hallo
Ich stecke da auch nicht so tief drin und hätte noch was zum Indizien sammeln. Da CUL_Read ausbleibt kommt offensichtlich nix mehr über Funk rein bzw. den Funkchip.
Zitat von: frank am 24 August 2025, 10:02:16dann würde vermutlich auch ein einfaches "set reopen" helfen.
Das wäre ja einen Versuch Wert.
In dem Zusammenhang ist aber noch interessant ob du mit FHEM-Neustart meinst den FHEM-Prozess zu stoppen und wieder zu starten,
oder du einen Reboot des Rechners machst. Das hat ja ggfs. zu Folge, dass die USB-Ports und damit der CUL kurz stromlos werden.
Vorher kannst du noch prüfen ob der CUL noch mit dir redet. Der CUL besteht ja aus Controller und Funkteil (vielleicht stellt nur der Funk-Teil das Arbeiten ein).
Mit dem GET-Befehl am CUL-Device
get CUL_1 uptime fragst du den Controller wie lange er UP ist. Wenn du eine Antwort bekommst liegt das Problem Richtung Funk.
Gruß Ralf
Mit "set reopen" kann ich den Stick neu starten. Empfang läuft dann wieder.
Ich vermute auch, dass das Problem nicht am FHEM liegt.
Serielle Verbindung ist da. Stick ist ja online.
Aber wie du schon sagst, kommt einfach kein Empfang mehr rein.
Ich habe jetzt mal eine andere Firmware drauf geflasht. Vielleicht war das ja das Problem.
Aktuell ist nun drauf: V 1.67 nanoCUL868
Mal schauen ob es was bringt.......................
ZitatMit "set reopen" kann ich den Stick neu starten. Empfang läuft dann wieder.
Laut CC1100 Handbuch muss Frequenz/Hardware/etc regelmaessig kalibriert werden.
Das passiert beim Oeffnen der Verbindung mit einem expliziten Befehl (CC1100_SCAL) und beim Wechseln zwischen Senden und Empfangen (Registereinstellung: MCSM0=0x18 => Calibration: RX/TX->IDLE).
Soweit ich weiss, wird in diesem Anwendungsfall nicht gesendet.
Hypothese: bei manchen Chips wandert die Frequenz schneller weg als bei Anderen, und braucht oefters eine Rekalibrierung.
Okay wenn ich dann alle 24h ein reopen mache sollte das Problem nicht mehr auftreten.
Auffällig ist zudem, das ziemlich zeitgleich nach ca. 3300 Readings der Empfang ausfällt.
Ich schaue mal, ob das Verhalten mit der anderen Firmware auch auftritt.
Eigentlich könnte man ja erwarten, dass die Firmware die Kalibrierung selber ausführt. Das Gerät ohne senden zu betreiben sollte ja ein gängier Anwendungsfall sein............... Gerade bei MBus Geräten.
ZitatEigentlich könnte man ja erwarten, dass die Firmware die Kalibrierung selber ausführt. Das Gerät ohne senden zu betreiben sollte ja ein gängier Anwendungsfall sein............... Gerade bei MBus Geräten.
Dafuer muss man nur "kurz" rf_mlib.c (https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/clib/rf_mbus.c) anpassen :)
Zitat von: Olli7766 am 25 August 2025, 17:17:55Ich habe jetzt mal eine andere Firmware drauf geflasht. Vielleicht war das ja das Problem.
Aktuell ist nun drauf: V 1.67 nanoCUL868
beim wechsel der fw kann es passieren, dass der eeprom inhalt nicht mehr zur aktuellen fw passt, wodurch ggf seltsame dinge passieren können.
ich empfehle dir, nach
jedem fw wechsel, eine manuelle eeprom initialisierung durchzuführen. bei culfw funktioniert es über:
set cul raw efalls es weiterhin probleme gibt, würde ich es mal mit der fw tsculfw von @noansi probieren.
da sehe ich in der datei rf_mbus.c jedenfalls viele änderungen.
hier der link zur aktuellen version: https://forum.fhem.de/index.php?msg=1321390 (https://forum.fhem.de/index.php?msg=1321390)
vielleicht auch mal im thread bei ansgar nachfragen.
Hallo Frank,
danke für deine Tips.
Der Empfang ist heute Nacht nach 8 Stunden Uptime wieder einfach ausgeblieben.
Ich habe jetzt erstmal das set cul raw e durchgeführt.
Falls es wieder nicht funktioniert werde ich mal auf die FW von @noansi wechseln......
Beim WMBus müsste eigentlich nach jeder empfangenen Nachricht eine Kalibrierung erfolgen.
Nach jeder empfangenen Nachricht geht der cc1101 nach IDLE und dann wieder nach Receive.
Beim Wechsel von IDLE nach Receive erfolgt eine Kalibrierung.
Werden die Nachrichten regelmässig empfangen oder gibts ab und zu eine längere Pause.
Wie ist der RSSI Wert der empfangenen Nachrichten?
Wenn nichts mehr empfangen wird wären die Werte der cc1101 Register Hex 25 (FSCAL1) und Hex 35 (MARCSTATE) interessant.
Beim sduino lassen sich diese einfach mit get auslesen geht dies auch beim cul?
Gruß Ralf
Zitat von: Ralf9 am 29 August 2025, 16:12:12... einfach mit get auslesen geht dies auch beim cul?
Ich denk schon. Lt. CommandRef
C<reg>
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
Example: C35 -> C35 = 0x0D / 13 Also
get <CUL> raw C25
Aktuell läuft der Empfang noch! Sind bei 4492 MSGCNT. So weit ist er noch nie gekommen.
RSSI ist -45.5. Der Empfang sollte damit nicht das Problem sein.
Der Stick ist direkt neben dem Wasserzähler. Luftlinie ca. 1m.
Die Nachrichten kommen absolut sauber an. Ohne Pause. Alle ca. 60 Sekunden eine.
Sobald der Stick wieder steht werde ich die Register mal auslesen.
Okay der Empfang ist wieder weg.
Die Register sind:
CUL_1 raw => C25 = 19 / 25
CUL_1 raw => C35 = 01 / 1
ZitatCUL_1 raw => C25 = 19 / 25
Ist ok, muß ungleich Hex 3F sein.
ZitatCUL_1 raw => C35 = 01 / 1
Das passt nicht.
1 ist IDLE, das muß 0D / 13 (Receive) sein.
Ist es immer 1, wenn Du es mehrmals abfragst?
Zitat von: Ralf9 am 31 August 2025, 10:55:57Das passt nicht.
1 ist IDLE, das muß 0D / 13 (Receive) sein.
Ist es immer 1, wenn Du es mehrmals abfragst?
Ja habe 20x abgefragt. Immer 1.
Passt auch zum verhalten.............
UPDATE1:
Jetzt ist der Stick nach 2 Stunden gestorben!
2025.08.31 20:16:45 2: Setting CUL_1 fhtid from TMODE to 0000
2025.08.31 20:16:45 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 reappeared (CUL_1)
2025.08.31 20:17:13 1: No Logdevice /FileLog_CUL_WS_4/
2025.08.31 20:17:22 3: CUL_1: Unknown code 0000, help me!
2025.08.31 22:05:18 1: No Logdevice /FileLog_CUL_WS_4/
Komisch? Kann die Hardware vielleicht einen Knacks haben?
Kurzes Update von meiner Seite um das Thema abzuschließen:
Ich habe seit 3 Tagen einen neuen Stick am laufen. Bis jetzt keine Ausfälle.
Das Problem war wohl die Hardware.