CUL 433 empfängt seit vorgestern keine Thermometer mehr

Invers · 09 September 2014, 23:02:51

Mein CUL 433 empfängt seit vorgestern meine Thermometer entweder gar nicht mehr, oder einige nur unvollständig. Als Fehler zeigt Verbose 5 (auszugsweise):

Code Auswählen

2014.09.09 22:41:30 4: CUL_Parse: CUL_1 tAE8D6706761C -60
2014.09.09 22:41:30 5: CUL_1 dispatch TXAE8D670676
2014.09.09 22:41:30 4: CUL_TX 70 (XAE8D670676) data error 2
2014.09.09 22:41:31 5: CUL/RAW: /tA05173673A23

2014.09.09 22:41:31 4: CUL_Parse: CUL_1 tA05173673A23 -56.5
2014.09.09 22:41:31 5: CUL_1 dispatch TXA05173673A
2014.09.09 22:41:31 4: CUL_TX 40 (XA05173673A) data error 3
2014.09.09 22:41:31 5: CUL/RAW: /tAE5152052C23

2014.09.09 22:41:31 4: CUL_Parse: CUL_1 tAE5152052C23 -56.5
2014.09.09 22:41:31 5: CUL_1 dispatch TXAE5152052C
2014.09.09 22:41:31 4: CUL_TX 40 (XAE5152052C) data error 3
2014.09.09 22:41:32 5: CUL/RAW: /tA04F7177140F

Meine Schalter und Steckdosen funktionieren.
Batterietausch bringt nichts.
Neustart des Raspberry (mit stromlos schalten) und fhem bringt nichts.
Ich habe an der Konfiguration nichts geändert. fhem-Updates mit Neustart habe ich täglich durchgeführt.

Hat jemand einen Tipp für die Fehlersuche?

Puschel74 · 10 September 2014, 04:50:14

Monn,

du bist im falschen Forumsbereich.
SlowRF läuft auf 868 MHz und nicht 433 MHz.

Grüße

rudolfkoenig · 10 September 2014, 08:20:04

Ich habe vor paar Tagen die in diesem
http://forum.fhem.de/index.php?topic=26831
Beitrag vorgeschlagenen Patch integriert.
Kannst du via restore die letzte Version restaurieren, und pruefen, ob es damit sinnvolle Ergebnisse kommen?

rudolfkoenig · 10 September 2014, 08:36:30

Nachtrag: nachdem ich auch bei mir deutlich weniger akzeptierte Daten beobachtet habe, habe ich den Patch entfernt.

Invers · 10 September 2014, 09:41:54

Zitat von: Puschel74 am 10 September 2014, 04:50:14
Monn,

du bist im falschen Forumsbereich.
SlowRF läuft auf 868 MHz und nicht 433 MHz.

Grüße

Mist. Sorry. Danke. Kann bitte jemand verschieben?

Die Datei 00_CUL.pm habe ich zurückgespielt und neu gestartet. Leider erst einmal keine wesentliche Besserung. Das am weitesten entfernte Thermometer in der Kücke wird komplett empfangen. 2 nahe gelegene dagegen gar nicht, trotz Batteriewechsel. 2 weitere Thermometer zeigen nur die Feuchte oder die Temperatur an.
Ich werde mal 1 Thermometer neu erkennen lassen und gucken, ob das dann wieder geht.

Vorerst vielen Dank für den Tipp.

EDIT:

Die Neuerkennung (Batterie raus und wieder rein, autocreate) hat leider nicht viel gebracht.

rudolfkoenig · 10 September 2014, 11:00:51

Erstens: du bist hier goldrichtig, SlowRF hat nichts mit 868MHz zu tun, sondern mit dem Empfangsmodus auf dem CUL, d.h. wo die Bits nicht von dem CC1101 sondern von der atmega MCU im Software interpretiert werden. Damit kann man manche Protokolle auch auf 433MHz empfangen, und die 433-er CULs werden mWn ausschliesslich in SlowRF betrieben, HM/MAX/etc ist da sinnlos.

Zweitens: Das "kaputte" Modul ist nicht CUL.pm sondern 14_CUL_TX.pm, das muss man restaurieren.
Siehe auch mein Link.

Invers · 10 September 2014, 11:46:24

Zu 1. Vielen Dank, das freut mich.
zu 2.
Das habe ich nicht gesehen und bitte um Entschuldigung. Ich hatte den verlinkten Beitrag gelesen, aber den Modulnamen überlesen.
habe ich nun ausgetauscht und neu gestartet und siehe: Es geht wieder.

Womit wir bei meinem Lieblingsspruch wären: Kaum macht man was richtig, schon funktionierts.
Womit ich in diesem Fall eher mich meine.

Vielen Dank für die erfolgreiche Hilfe.

Puschel74 · 10 September 2014, 18:00:02

Hallo,

Zitat von: rudolfkoenig am 10 September 2014, 11:00:51
Erstens: du bist hier goldrichtig, SlowRF hat nichts mit 868MHz zu tun, sondern mit dem Empfangsmodus auf dem CUL, d.h. wo die Bits nicht von dem CC1101 sondern von der atmega MCU im Software interpretiert werden. Damit kann man manche Protokolle auch auf 433MHz empfangen, und die 433-er CULs werden mWn ausschliesslich in SlowRF betrieben, HM/MAX/etc ist da sinnlos.

Wieder was gelernt - danke Rudi.
Ich warte jetzt nur noch bis die ersten Anfänger ankommen und schreien - ich hab FS20-Geräte, warum empfange ich keine Daten mit meinem 433-er CUL.
Aber nun kenn ich ja den Unterschied.

Grüße

Invers · 06 Januar 2015, 01:29:24

Seit 5.1.2015 ungefähr 10:40 empfange ich keines meiner 5 Thermometer mehr. Der 433er Stick sendet aber. Ist irgendein Fehler bekannt, der seit heute greift?
Im Log steht nichts drinnen. Kein Fehler und kein Empfang.
Kann ich irgendwie testen, ob der 433er noch Empfang hat? Hab leider nur die Thermometer und 3 Schalter.
Ich habe bereits den Stick umgesteckt und den Pi nebst Fritzbox neu gestartet.

Ein Ähnliches Problem hatten wir hier schon einmal, aber damals mit Fehler im Log.

rudolfkoenig · 06 Januar 2015, 09:21:20

Ich gehe davon aus, dass es sich weiterhin um CUL_TX handelt. Wann hast du zuletzt ein FHEM-Update gemacht? An den betroffenen FHEM-Komponenten hat sich nichts geaendert, allerdings gab es Aenderungen in culfw. Hast du neu geflasht?

Invers · 06 Januar 2015, 10:10:14

Das ist richtig, meine Signatur ist aktuell.
Ich mache eigentlich wirklich fast täglich ein Update. Auch an diesem Tag, seitdem der Fehler auftritt, hatte ich kurz vorher eines gemacht. Allerdings tritt der Fehler seit 4.1.2015 auf. Ich hatte mich im Datum geirrt, weil ich so spät geschrieben habe
Geflasht habe ich nicht, kann ich aber noch machen. Vielleicht hilft es ja, was ich aber nicht vermuten würde.
Aktuell läuft der Stick mit:
CUL_1 ccconf => freq:433.920MHz bWidth:58KHz rAmpl:42dB sens:8dB.

rudolfkoenig · 06 Januar 2015, 11:24:15

Flashen waere kontraproduktiv: es sind in der letzten Zeit neue Protokolle reingekommen, die den Empfng verhindern koennten. Ich vermute eher ein von FHEM unabhaengiges Problem, wie Funk-Kopfhoerer beim Nachbarn, etc.

Invers · 06 Januar 2015, 21:05:53

Ich habe mal aus einem Thermometer die Batterien entfernt und wieder eingelegt. Das Thermometer wird durch autocreate sofort erkannt und eingerichtet. Es werden aber keine Daten empfangen.
Es wäre schön, wenn das Problem in den Griff zu bekommen wäre. Ich müsste sonst wohl auf HM umsteigen, was ja ziemlich teuer wäre.
Eine Störquelle kann man natürlich nicht ausschliessen, aber die müsste ja irgendwann mal eine Unterbrechung haben.

Ich werde mal diese Woche noch abwarten, ob sich was tut, dann muss ich wohl in den sauren Apfel beissen.

Erstmal danke für die Antworten.

rudolfkoenig · 06 Januar 2015, 21:47:42

Wieso steht eigentlich in deinen Logs "data error 3"? In den aktuellen Quellen gibts es nur ein "data error", ohne 2 bzw. 3.
Kann es sein, dass du mit der CUL_TX.pm Version von 2014-09-07 unterwegs bist? Dieser Patch wurde nach 3 Tagen wieder rueckgaengig gemacht, da fehlerhaft.

Invers · 06 Januar 2015, 22:10:49

ich habe als 14_CUL_TX.pm folgende:

Code Auswählen

# $Id: 14_CUL_TX.pm 6689 2014-10-05 12:27:19Z rudolfkoenig $

EDIT
Hab jetzt mal update force gemacht, aber keine Änderung an der Situation.

rudolfkoenig · 06 Januar 2015, 23:13:52

ZitatHab jetzt mal update force gemacht, aber keine Änderung an der Situation.

Mag sein, aber in der aktuellen 14_CUL_TX.pm gibt es kein "data error 2" bzw. "data error 3", die einzige mir bekannte Version mit diesen Strings war fehlerhaft. Und du meldest diese Strings und hast Probleme.

Invers · 06 Januar 2015, 23:28:42

Könntest du oder irgendjemand mir die richtige Version hier anhängen und ich tausche sie per Hand aus? Dann wäre ich sicher, die richtige Version zu nutzen. Update force hat es ja offenbar nicht bereinigt, vermute ich. Alternativ hier meine Version zum Vergleich.
Aber selbst wenn das die falsche Datei wäre, es hat ja bislang hervorragend funktioniert.

rudolfkoenig · 07 Januar 2015, 12:46:36

Die angehaengte Version ist schon richtig, da kommt auch kein "data error 2" vor. Ich war gestern offensichtlich verwirrt: ich habe die Fehlermeldung aus dem ersten Beitrag der Diskussion gelesen, und uebersehen, dass das vor 3 Monaten war. Bei dem aktuellen Meldung hast du ja auch gesagt, dass es keine Fehlermeldung gibt. Da das Geraet per autocreate angelegt wird, werden die Nachrichten offensichtlich vom Stick empfangen. Kannst du bitte eine CUL_TX Nachricht via "attr CULXX verbose 5" aufzeichnen, und hier posten?

Invers · 07 Januar 2015, 21:24:51

Kein Problem.

Ich habe nun festgestellt, dass der CUL_1 offenbar doch nicht empfängt. Senden geht aber.
Auch das Umstecken des CUL und das Entfernen des anderen CUL868 nebst Neustart und anderer Verrenkungen hat nichts gebracht.
Ich fürchte nun fast, dass der 433er wirklich defekt ist. I

Protokoll:

2015.01.07 21:16:26 2: IT set Rechts on
2015.01.07 21:16:26 5: SW: is0000FFF00FFF
2015.01.07 21:16:26 5: CUL/RAW (ReadAnswer): is0000FFF00FFF

2015.01.07 21:16:28 2: IT set Rechts on
2015.01.07 21:16:28 5: SW: is0000FFF00FFF
2015.01.07 21:16:28 5: CUL/RAW (ReadAnswer): is0000FFF00FFF

2015.01.07 21:16:30 2: IT set Rechts off
2015.01.07 21:16:30 5: SW: is0000FFF00FF0
2015.01.07 21:16:30 5: CUL/RAW (ReadAnswer): is0000FFF00FF0

2015.01.07 21:16:32 2: IT set Rechts on
2015.01.07 21:16:32 5: SW: is0000FFF00FFF
2015.01.07 21:16:33 5: CUL/RAW (ReadAnswer): is0000FFF00FFF

2015.01.07 21:16:35 2: IT set Rechts off
2015.01.07 21:16:35 5: SW: is0000FFF00FF0
2015.01.07 21:16:35 5: CUL/RAW (ReadAnswer): is0000FFF00FF0

EDIT:
Habe mal in einen anderen Modus geschaltet, aber die Rückkehr nach slowrf geht schon nicht mehr:

2015.01.07 22:09:48 4: CUL_Parse: CUL_1 TMODE
2015.01.07 22:09:48 5: CUL_Parse: switched to TMODE
2015.01.07 22:10:01 5: SW: Ax
2015.01.07 22:10:01 5: SW: Zx
2015.01.07 22:10:01 5: SW: brx
2015.01.07 22:10:01 5: SW: X21
2015.01.07 22:10:01 2: Switched CUL_1 rfmode to SlowRF
2015.01.07 22:10:02 5: CUL/RAW: /OFF

2015.01.07 22:10:02 4: CUL_Parse: CUL_1 OFF
2015.01.07 22:10:02 2: CUL_1: unknown message OFF

Invers · 07 Januar 2015, 23:43:19

So, das liess mir nun doch keine Ruhe und ich habe noch etwas experimentiert.
set CUL_1 raw e habe ich gefunden und Probiert. Hat letztlich etwas gebracht. Die Thermometer werden wieder empfangen, aber nicht lückenlos.

Immerhin ist es eine deutliche Besserung. Ich habe nun auch wieder (natürlich) Protokoll. Hier ein Auszug:

2015.01.07 23:39:49 4: CUL_Parse: CUL_1 tAE2B52052225 -55.5
2015.01.07 23:39:49 5: CUL_1 dispatch TXAE2B520522
2015.01.07 23:40:01 5: CUL/RAW: /tA03570370217

2015.01.07 23:40:01 4: CUL_Parse: CUL_1 tA03570370217 -62.5
2015.01.07 23:40:01 5: CUL_1 dispatch TXA035703702
2015.01.07 23:40:02 5: CUL/RAW: /tAE3466066617

2015.01.07 23:40:02 4: CUL_Parse: CUL_1 tAE3466066617 -62.5
2015.01.07 23:40:02 5: CUL_1 dispatch TXAE34660666
2015.01.07 23:40:28 5: CUL/RAW: /tA0776626622D

2015.01.07 23:40:28 4: CUL_Parse: CUL_1 tA0776626622D -51.5
2015.01.07 23:40:28 5: CUL_1 dispatch TXA077662662
2015.01.07 23:40:47 5: CUL/RAW: /tAE2A53053422

2015.01.07 23:40:47 4: CUL_Parse: CUL_1 tAE2A53053422 -57
2015.01.07 23:40:47 5: CUL_1 dispatch TXAE2A530534
2015.01.07 23:40:58 5: CUL/RAW: /tA03570370217

2015.01.07 23:40:58 4: CUL_Parse: CUL_1 tA03570370217 -62.5
2015.01.07 23:40:58 5: CUL_1 dispatch TXA035703702
2015.01.07 23:40:59 5: CUL/RAW: /tAE3465065417

2015.01.07 23:40:59 4: CUL_Parse: CUL_1 tAE3465065417 -62.5
2015.01.07 23:40:59 5: CUL_1 dispatch TXAE34650654
2015.01.07 23:41:26 5: CUL/RAW: /tAE766006002D

2015.01.07 23:41:26 4: CUL_Parse: CUL_1 tAE766006002D -51.5
2015.01.07 23:41:26 5: CUL_1 dispatch TXAE76600600
2015.01.07 23:41:28 5: CUL/RAW: /tA0915135120A

2015.01.07 23:41:28 4: CUL_Parse: CUL_1 tA0915135120A -69
2015.01.07 23:41:28 5: CUL_1 dispatch TXA091513512
2015.01.07 23:41:28 5: CUL/RAW: /tAE919109160A

Medhr kann man sicher nicht velangen.

Ich danke dir für die Hilfe.