Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

hermannk

Hallo Ansgar,

Die folgenden Beobachtungen beziehen sich auf culfw-code-459-trunk_lufa_rf_cr_sd_72.zip, Hardware CUL V3.4, in FHEM als CUL433 definiert. Ich verwende den CUL433 ausschließlich für den Empfang von WS2000 Daten, also 433 MHz OOK.

1. Wenn ich die "raw RSSI" Daten sehen möchte

    set CUL433 raw Xa7

    dann werden die nicht angezeigt. Für die Fehlersuche bei einem OOK-Protokoll wäre das aber sehr hilfreich. Ist das ein gewünschtes Verhalten?

2. Einige von CUL433 an FHEM gesendete Pakete werden verworfen. Beispiel:

    2015.01.20 11:49:41 2: CUL433: unknown message p 9  784  384  368  864 10  5 5 DE 8A5DE8539E90  288  240                                                                                                                                   


    Das Datenpaket 8A5DE8539E90 (von einem ASH 2000) lautet in binärer Darstellung

    10001     01001     01110     11110     10000     10100     11100     11110     10010
                        ↑


    Ich habe die Daten in Nibbles (4 Daten- plus jeweils ein Stoppbit) gruppiert, so wie sie vom WS2000-Protokoll verwendet werden. Jede Gruppe muss mit einem Stoppbit (= 1) abgeschlossen werden. Offensichtlich ist an an der markierten Stelle nicht erfüllt. Es zeigt sich, dass man ein Bit (das Bit vor dem markierten Bit) verwerfen muss, um ein gültiges und sinnvolles Paket zu erhalten:


10001     01001     01101     11101     00001     01001     11001     11101     00100
1         2         6         7         0         2         3         7         4
Type      Adr       7.6                           73.3                          Check1


    Ich beschreibe das deshalb so ausführlich, weil das bei fast der Hälfte der Pakete passiert. Mit anderen Worten: Die Filterung der Rohwerte lässt von Zeit zu Zeit ein paar Störungen durch, die dann als zusätzliche Bits erscheinen und das Paket zerstören. Die Störungen treten unabhängig von der Entfernung zwischen Sender und Empfänger auf. Ich würde das gern mit den RSSI Daten konkretisieren. Aber, wie gesagt, ...

    Des weiteren habe ich den Eindruck, dass die Prüfsumme nicht übertragen wird. Wird der vom ASH2000 nicht gesendet oder wird der im CUL verworfen?

3. Der S2000R (Regensensor) sendet Daten, die sich leicht vom Protokoll (http://www.dc3yc.homepage.t-online.de/protocol.htm) unterscheiden. Oder der CUL empfängt sie anders.

    Beispiel:

    2015.01.20 14:21:50 2: CUL433: unknown message p 9  752  384  352  864 10  4 2 44 4FD610F780  384  240

    Schlüsselt man das Datenpaket wie oben beschrieben auf, so erhält man:

    01001     11111     01011     00001     00001     11101     11100     00000
2         f         a         0         0         Check1    Check2


    Die Adresse sollte eigentlich niemals f sein können. Vermutlich liegt hier das Problem im Reverse-Engineering des Protokolls. Auch das Protokoll des S2001-ID unterscheidet sich von der Beschreibung (nur zur Info).

    Im Ergebnis ist das Problem, dass FHEM im autocreate Modus

define autocreate autocreate                                                                                                                                                                                                                                                   
attr autocreate autosave 1                                                                                                                                                                                                                                                     
attr autocreate filelog ./log/%NAME-%Y.log                                                                                                                                                                                                                                     


    im Laufe der Zeit einige Hörmann-Geräte erzeugt, von Regensensor jedoch keine Spur:


-rw-r--r-- 1 fhem dialout        0 Jan 20 11:13 CUL_HOERMANN_4FC210DF20-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:12 CUL_HOERMANN_4FC210DF90-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:11 CUL_HOERMANN_4FC210EF90-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 20:40 CUL_HOERMANN_4FCE10C790-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 17:56 CUL_HOERMANN_4FCE10D390-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout      102 Jan 20 21:51 CUL_HOERMANN_4FCE10E390-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout       51 Jan 20 21:45 CUL_HOERMANN_4FCF086390-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:22 CUL_HOERMANN_4FD210FFA0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 14:13 CUL_HOERMANN_4FD610F7D0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:23 CUL_HOERMANN_4FD9087FD0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout      102 Jan 20 11:22 CUL_HOERMANN_4FE1086F90-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout      153 Jan 20 21:53 CUL_HOERMANN_4FE7086390-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:23 CUL_HOERMANN_4FE9087FD0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 12:00 CUL_HOERMANN_4FED0877D0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 14:35 CUL_HOERMANN_4FF610B7A0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 14:33 CUL_HOERMANN_4FF610B7D0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 15:07 CUL_HOERMANN_4FFB085BD0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:15 CUL_HOERMANN_67E1086F90-2015.log                                                                                                                                                                                               



noansi

#61
Hallo Hermann,

erst mal danke für den Test.

ZitatWenn ich die "raw RSSI" Daten sehen möchte

Meinst Du das was bei Xa7 wegen Bit 7 kommen sollte, dann ja, weil ich das im Code bei der Ergänzung des Keying Protokolls raus genommen hatte, da mit Bit5 ohnehin die RSSI (Register)-Werte als Hex Wert kommen (das DE im Beispiel unten), die dann nur entsprechend umgerechnet werden müssen. Grund 1 war, Speicherplatz für CUL_V2 zu sparen. Grund 2 ist, dass man bei COC damit die Ausgabe des einzelbit Empfangstimings einer ganzen Nachricht aktivieren kann und damit richtig sehen kann, wie gut oder schlecht die Daten bezüglich Timing empfangen werden und dann ist die Ausgabe dieses Wertes vor der eigentlichen Nachricht etwas störend.
Könnte ich bei Bedarf bei CUL_V3 aber wieder mit rein nehmen, da der nicht genug Pufferspeicher für die bit-Timing Ausgabe hat.
Die Umrechung in dem Quell-Code wäre dann:

      rssi = (rssi >= 128 ? rssi-128 : rssi+128);    // Swap
      if(rssi < 64)                                  // Drop low and high 25%
        rssi = 0;
      else if(rssi >= 192)
        rssi = 15;
      else
        rssi = (rssi-80)>>3;
      DC('a'+rssi); // ouput data char


... was aber ohne Probleme FHEM beim Empfang in 00_CUL.pm machen und ausgeben kann. Für K... Nachrichten, die kommen, macht es so was auch für die RSSI Werte.


ZitatEinige von CUL433 an FHEM gesendete Pakete werden verworfen. Beispiel:

Der Empfang des KS Protokolls prüft auf die Stopbits und die Checksummen. Wenn da was nicht stimmt, dann wird das Paket in CUL verworfen, also keine K... Message an FHEM gesendet. Die Rohdatenbitausgabe, die Du akiviert hast, aber doch. Mit der macht aber FHEM nichts.

ZitatEs zeigt sich, dass man ein Bit (das Bit vor dem markierten Bit) verwerfen muss, um ein gültiges und sinnvolles Paket zu erhalten
Schön analysiert. Wenn es auch einem sinnvollen Messwert entsprechend den Umgebungsbedingungen entsprochen hat.
Ich beobachte bei mir, dass sich die Sendedaten der Einzelsensoren von Zeit zu Zeit überlagern und dann Unsinn kommt. Außerdem sendet noch irgendwas aus der Nachbarschaft regelmäßig und stört schon mal. Und ein TX3 Sensor quasselt auch häufig dazwischen.
Aber das Timing ist ohnehin schon auf der Senderseite nicht so doll, wie ich an einem WS2000 Repeater an der Signalquelle für den Sender messen konnte, von daher ist der Empfang schwierig. Die Empfangstimingauswertung ist ein Kompromiss, respektvie, wenn beim Sync das keying erkannt wird und es dann schief geht, dann ist das Empfangspaket leider zu schlecht. Ich bin eigentlich ganz froh mit dem was bei mir durch kommt. "Sens" habe ich bei mir übrigens auf 8 bei CUL eingestellt, vielleicht hilft Dir das noch.

ZitatDie Filterung der Rohwerte lässt von Zeit zu Zeit ein paar Störungen durch
Die Flanken kommen so in der Firmware vom Empfänger des CUL an. Würde man speziell auf das KS Protokoll abzielen, dann wäre da eventuell noch was zu machen, aber dann fliegen die übrigen empfangbaren Protokolle teilweise wieder raus. Der Auswertungsansatzt, wie ich ihn im Quelltext vorgefunden hatte ist da schon ziemlich clever und flexibel gewählt.

ZitatDer S2000R (Regensensor) sendet Daten
...

Du must auch noch die 4 und die 2 beachten. Es sind 4 bytes + 2 bits = 34 bits empfangen worden, also musst Du die 0000 am Ende streichen. Das fehlende Stopbit beim jeweils letzten Nibble wird auch noch bei der Prüfung "ergänzt" (was auch noch scheitern kann).
Nach XOR-Check und Summe würde Protokoll V1.2 hier passen.
V1.1 sendet die Summe nicht (und das habe ich in der Firmware ergänzt, dass auch das noch als K... Message bis FHEM durch kommt.)
Sendet der immer f als Adresse? Oder nur wenn es regnet? Leider habe ich den Sensor nicht, um damit mehr nachvollziehen zu können. Das wäre aber ohnehin eine Frage der nachgeschalteten FHEM Auswertungen in CUL_WS.
Kam denn die K... Message dazu rüber? Denn dann wäre in der CUL Firmware dabei alles ok gewesen. Aktiviere verbose 4 für den CUL, um die K... messages im LOG zu sehen.

Die 10 davor sagt übrigens, dass 10 sync bits empfangen wurden, bevor es mit der message los ging.

ZitatIm Ergebnis ist das Problem, dass FHEM im autocreate Modus
...

Das ist leider nur dadurch zu vermeiden, dass Du die Sensoren einmal dazu einträgst (oder eintragen lässt) und dann Autocreate deaktivierst und den Müll wieder aus der Config entfernst. Hörmann ist auch das am wenigsten in CUL weiter geprüfte bzw. gefilterte Protokoll. Mit mehr Infos dazu könnte man hier eventuell mehr raus werfen.

Man könnte die Timing Prüfung in CUL noch schärfer programmieren, aber dann kommen auch deutlich weniger gültige Pakete durch. Das will ich jedenfalls nicht und habe das für meine Wettersensoren auch durch.

Also bis auf den Regensensor siehst Du nun alle Sensoren in FHEM?

Gruß, Ansgar.

hermannk

Hallo Ansgar,

danke für die zeitnahe und informative Antwort, die mich ein gutes Stück vorangebracht hat.

Zum Bit 7 (von Xa7). Ist CUL_V2 noch ein Thema? Ich bin zwar kein Freund von bedingter Übersetzung. Aber: wenn man schon den CUL_V2 Zombie pflegen möchte, kann man nicht einzelne Funktionen in bedingter Übersetzung einklammern?

Die Überprüfung der Rohdaten hatte ich so erwartet. Gut, dass die Rohdatenausgabe vorher zuschlägt, so dass man das Problem überhaupt bemerkt.

ZitatWenn es auch einem sinnvollen Messwert entsprechend den Umgebungsbedingungen entsprochen hat.

Klar, das hatte ich bei dem Beispiel und bei weiteren Beispielen natürlich sichergestellt, sonst wäre die Bitfummelei sinnlos gewesen. Noch ein Beispiel zweier aufeinanderfolgender Messungen:


2015-01-20 13:35:17 8A4BD0E73DE0

1 0 0 0|1 0 1 0|0 1 0 0|1 0 1 1|1 1 0 1|0 0 0 0|1 1 1 0|0 1 1 1|0 0 1 1|1 1 0 1|1 1 1 0|0 0 0 0

10001     01001     00101     11101     00001     11001     11001     11101     11100     00000
1         2         4         7         0         3         3         7         7         0
Type      Adr,0     7.4                           73.3                          Check1

2015-01-20 13:38:13 8B25F439CF78

1 0 0 0|1 0 1 1|0 0 1 0|0 1 0 1|1 1 1 1|0 1 0 0|0 0 1 1|1 0 0 1|1 1 0 0|1 1 1 1|0 1 1 1|1 0 0 0

10001     01100     10010     11111     01000     01110     01110     01111     01111     000
             ↑
           remove

10001     01001     00101     11110     10000     11100     11100     11110     11110     00000
                                  ↑
                                remove

10001     01001     00101     11101     00001     11001     11001     11101     11100     00000
1         2         4         7         0         3         3         7         7         0
Type      Adr,0     7.4                           73.3                          Check1


Die Symptome sind, dass niemals ein Bit hinzugefügt werden muss, dass fast immer 1-Bits (= keine 0-Bits) entfernt werden müssen und dass manchmal auch mehrere Bits entfernt werden  müssen.

ZitatIch beobachte bei mir, dass sich die Sendedaten der Einzelsensoren von Zeit zu Zeit überlagern und dann Unsinn kommt. Außerdem sendet noch irgendwas aus der Nachbarschaft regelmäßig und stört schon mal.

Beide Erklärungen scheiden bei mir aus. Der nächste Nachbar wohnt 60 m weit entfernt und ich habe lediglich 5 WS2000 Geräte (im 433 MHz Bereich). Und da die in einen streng vorgegebenen und mir bekanntem Zeitraster senden, kann das beschriebene Problem nicht durch Kollisionen erzeugt worden sein.

Ich kenne die rohen OOK Signale vom Scope. Da wird man schnell zum Fan von FM. Und wenn das noch für verschiedene Quellen funktionieren soll, dann wird es endgültig zum Problem. sens steht bei mir auf 4 dB. Nachdem ich es auf 8 dB gesetzt hatte, hat sich Folgendes geändert:

1 Ich kann jetzt einen sehr schwachen Sensor (RSSI -97.5 dB) empfangen, der vom FTH2000 (ELV Produkt) nicht empfangen wird.

2 Zwei andere Sensoren (RSSI -56 dB, RSSI -60 dB, RSSI -70 dB) hatten mit sens=4 dB etwa 6 erfolgreiche Übertragungen pro Stunde. Mit sens=8 dB sind es etwa 15.

3 Die anderen Sensoren (RSSI -87 dB) werden nach wie vor gut empfangen: etwa 15 erfolgreiche Übertragungen pro Stunde.

Fazit: Für WS2000 (= SlowRF) sollte sens auf 8 dB gesetzt werden. Die wenigen verworfenen Pakete haben immer noch "zu viele Einsen".

ZitatSendet der immer f als Adresse? Oder nur wenn es regnet?

Derzeit befindet sich der Sensor bei mir im Arbeitszimmer. Es regnet hier drinnen nicht. ;) Für den Sensor erzeuge ich Regen, indem ich das Gerät vorsichtig hin und her kippe. Dann zählt er wie erwartet, aber an der Adresse ändert das nichts.

ZitatAktiviere verbose 4 für den CUL, um die K... messages im LOG zu sehen.

Das bringt Klarheit. Ein "normaler" ASH2000 sieht so aus:


2015.01.21 11:40:06 4: CUL_Parse: CUL433 K51894079D1 -97.5                                                                                                                                                                                                                     
2015.01.21 11:40:06 4: CUL_Parse: CUL433 p 9  784  416  288  896 10  6 1 D1 8D6630967DFF80  320  240


Der Regensensor (S2000R-1) sieht so aus:


2015.01.21 11:38:44 4: CUL_Parse: CUL433 KF20E017                                                                                                                                                                                                                             
2015.01.21 11:38:44 4: CUL_Parse: CUL433 p 9  800  432  336  848  9  4 2 17 4FDE10E780  256  240


Hier fehlt der RSSI.

Zitat... und den Müll wieder aus der Config entfernst

Klar, mach ich ohnehin. fhem.cfg  >:( und autocreate  >:( sind wesentliche Schwachstellen von fhem:

1 In der Datei sind dynamische (z.B. actStatus) und statische (z.B. define) Einträge vermischt. Das erschwert die händische Pflege der Datei. Vgl. z.B. die Einführung der Verzeichnisse /etc und /var in unixoiden Systemen.

2 FHEM verändert die Datei von Zeit zu Zeit so (trailing white space), dass ein händischer Vergleich erschwert wird.

ZitatAlso bis auf den Regensensor siehst Du nun alle Sensoren in FHEM?

Jau. Aber es steht noch der S 2000 W aus.

Viele Grüße

Hermann

hermannk

Hallo Ansgar,

vom "S 2000 W" (Windsensor) empfängt der CUL nach dem Einschalten:


2015.01.21 15:55:17 4: CUL_Parse: CUL433 K73005027E4 -88                                                                                                                                                                                                                       
2015.01.21 15:55:17 4: CUL_Parse: CUL433 p 9  896  304  416  752  9  6 1 E4 CF4210D7A92C00  368  240                                                                                                                                                                           


Das sieht erst einmal ganz nett aus. Auch wenn man sich die Daten näher ansieht, bleibt der gute Eindruck:


2015-01-21 15:55:17 CF4210D7A92C00

1 1 0 0|1 1 1 1|0 1 0 0|0 0 1 0|0 0 0 1|0 0 0 0|1 1 0 1|0 1 1 1|1 0 1 0|1 0 0 1|0 0 1 0|1 1 0 0|0 0 0 0|0 0 0 0

11001     11101     00001     00001     00001     10101     11101     01001     00101     10000
3         7         0         0         0         5         7         2         4         1
Type      Adr,0     000 (velocity)                275 (direction)               Check1    Check2

2015-01-21 16:26:33 CF421084B9CC80

1 1 0 0|1 1 1 1|0 1 0 0|0 0 1 0|0 0 0 1|0 0 0 0|1 0 0 0|0 1 0 0|1 0 1 1|1 0 0 1|1 1 0 0|1 1 0 0|1 0 0 0|0 0 0 0

11001     11101     00001     00001     00001     00001     00101     11001     11001     10010
3         7         0         0         0         0         4         3         3         9
Type      Adr,0     000 (velocity)                340 (direction)               Check1    Check2


Bei der zweiten Übertragung hatte ich die Windfahne um etwa 90 Grad verdreht.

Es sieht so aus, als wäre der CUL aus dem Schneider. Liege ich da richtig?

fhem erzeugt mit "autocreate" die üblichen Hörmann Protokolldateien und versaut auch gleich die fhem.cfg. Kann ich was sinnvolles in die fhem.cfg eintragen?

Viele Grüße

Hermann

noansi

Hallo Hermann,

Zitatkann man nicht einzelne Funktionen in bedingter Übersetzung einklammern?

Das ist an der Stelle sogar so, aber nicht in Deinem Sinne.  ;)

Da mit Rohdatenausgabe auch der RSSI rüber kommt und mit voller Auflösung, macht es aus meiner Sicht mehr Sinn, die Rohdatenausgabe bezüglich RSSI und Umrechnung in 00_CUL.pm auszuwerten und im Log auszugeben. Aber nicht mehr heute Abend.

ZitatKlar, das hatte ich bei dem Beispiel und bei weiteren Beispielen natürlich sichergestellt

Gut, denn ab und zu reicht bei mir die Checksummenabsicherung nicht, um fehlerhafte Daten raus zu werfen. Deswegen muss ich fragen.

ZitatDie Symptome sind, dass niemals ein Bit hinzugefügt werden muss, dass fast immer 1-Bits (= keine 0-Bits) entfernt werden müssen und dass manchmal auch mehrere Bits entfernt werden  müssen.

Danke für den Hinweis. Nun das könnte auf ein Problem beim Keying Collect hindeuten, bzw. auch bei den Einstellungen des Receivers. Demnach müssten kurze Pulse vom Receiver kommen, die dann als bit missinterpretiert werden. (mit Flankeninterrupt werden die Rohsignaldaten vom Receiver ausgewertet)
Mit der alten Auswertung würden die Pakete dann direkt verworfen, wegen ganz unpassendem Timing im Vergleich zum Sync Timing und den letzen empfangenen Bits. Keying schaut nur danach, ob lowtime > hightime oder umgekehrt ist. Das würde in diesem Falle kurze High Pulse, also Spikes bedeuten.
Die Gesammtlänge könnte ich da auch prüfen, um das (ganze Paket) raus zu werfen. Aber das Paket wäre halt trotzdem verloren, weil vorher schon der Timer genullt wird, um möglichst genau die Zeit messen zu können und gleichzeitig den Interrupt Timeout für Paket Ende neu loslaufen zu lassen.
Also erst mal die Quelle der kurzen Pulse aufdecken und eliminieren wäre günstiger. Denn die Art der Auswertung hat für die WS Sensoren bei mir zu einer deutlichen Verbesserung beim Empfangserfolg geführt.

ZitatIch kenne die rohen OOK Signale vom Scope

Wenn Du da einen Empfänger hast und mit dem Scope zuschauen kanst, könntest Du da mal schauen, ob die Sensoren da schon mal Mist in die Sendepulse einbauen?
Wenn die es nicht sind, dann müssten man einen tiefen Blick in die Receiver Doku werfen, um zu schauen, ob da noch was an den Registereinstellungen zu optimieren wäre (möglicherweise natürlich mit Einfluss auf andere Protokolle mit kürzerem Timing).
Aber vielleicht geht es auch einfacher. Teste bitte mal sens 12. Der Ansatz mit 8 war ja schon gut.

ZitatEs regnet hier drinnen nicht. ;)

Gut, dann hat das zu viel gesetzte Bit entweder eine andere Bedeutung, oder es ist einfach immer gesetzt. -> in 14_CUL_WS.pm zu berücksichtigen, aber erst, wenn die Adressfrage klar ist. CUL hat damit erst mal nichts zu tun.
Lass es mal mit Wasser ;) regnen und schau, ob sich was am Bit ändert. Natürlich könnte die Regen-Sofort-Erkennung, sofern in dem Sensor vorhanden, auch durch Verschmutzung oder Beschädigung daueraktiv sein. Das Bit wäre zumindest noch geeignet, um dafür gut zu sein.

ZitatHier fehlt der RSSI.

Ich schätze mal, Du benutzt nicht meine 00_CUL.pm aus der zip Datei. Der RSSI hängt noch nicht ausgewertet hinten dran. Die original 00_CUL.pm kann nicht mit ungeraden Anzahlen von Nibbles.

ZitatEs sieht so aus, als wäre der CUL aus dem Schneider. Liege ich da richtig?
V1.2 und sieht gut aus.  :) Und wenn Du noch Wind in Deine Bude bringst, noch besser.  ;D

Zitatfhem erzeugt mit "autocreate" die üblichen Hörmann Protokolldateien und versaut auch gleich die fhem.cfg. Kann ich was sinnvolles in die fhem.cfg eintragen?


####################################################################
# automatische Sensordetektion, nur Kommentar entfernen, wenn neue Sensoren entdeckt werden sollen
####################################################################

#define autocreate autocreate
#attr autocreate autosave 1
#attr autocreate device_room %TYPE
#attr autocreate filelog /opt/fhem/log/%NAME-%Y.log
#attr autocreate weblink 1
#attr autocreate weblink_room NeueSensoren

############################
# CUL WS 433.92 MHz
############################

define CUL_WS433 CUL /dev/ttyACM1@38400 0000
attr CUL_WS433 room Receiver
attr CUL_WS433 verbose 2

#################################
# CUL WS 433.92MHz Sensoren
#################################

define CUL_WS4_bla3 CUL_WS 3
attr CUL_WS4_T_bla3 IODev CUL_WS433
attr CUL_WS4_T_bla3 room Sensoren_WS4

define CUL_WS4_blub7 CUL_WS 8
attr CUL_WS4_blub7 IODev CUL_WS433
attr CUL_WS4_blub7 room Sensoren_WS4


Und die anderen Sensoren mit Code = Adresse+1 entsprechend.
Bei Adresse 7wird gesammelt, was auf Adresse 7 von den verschiedenen Sensoren rein kommt.

Wenn Du gerne viel Log siehst, dann geht auch verbose 4 oder 5. Aber mach das nur, wenn Du die Logs auf eine Festplatte schreibst. Ich habe mir schon nach einem viertel Jahr den ersten USB-Stick zerschossen, auf den ich die FHME Logs geschrieben habe (zu viele Schreibzugriffe -> möglich Flash Schreibzyklen zu schnell erschöpft).

Gruß, Ansgar.


hermannk

Hallo Ansgar,

ich beantworte deine Hinweise mal Punkt für Punkt.

ZitatIch schätze mal, Du benutzt nicht meine 00_CUL.pm aus der zip Datei.

So war es. Ich hatte ganz übersehen, dass in culfw-code-459-trunk_lufa_rf_cr_sd_72.zip noch eine 00_CUL.pm oberhalb des Unterverzeichnisses war. Leider wird mein fhem-2015-01.log jetzt geflutet mit

2015.01.22 19:43:54 1: PERL WARNING: Use of uninitialized value $hmSioDly in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:43:54 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:43:57 1: PERL WARNING: Use of uninitialized value $hmSioDly in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:43:57 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:44:12 1: PERL WARNING: Use of uninitialized value $hmSioDly in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:44:12 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/00_CUL.pm line 1190.


Dadurch wird mein  log sehr unübersichtlich. Lässt sich das abstellen?

Gruß

Hermann

hermannk

Hallo Ansgar,

ZitatV1.2 und sieht gut aus.  :) Und wenn Du noch Wind in Deine Bude bringst, noch besser.  ;D

ich habe den Windsensor ausgewildert. Heute weht fast kein Lüftchen, aber dennoch meldet der Sensor sinnvolle Daten. Z.B.:


2015.01.22 19:34:04 4: CUL_Parse: CUL433 K73040058F4 -80                                                                                                                                                                                                                       
2015.01.22 19:34:04 2: CUL433: unknown message p 9  832  352  336  848  9  6 1 F4 CF4A108475BD80  384  240


Der Datensatz  übersetzt sich in Geschwindigkeit 4 (= vermutlich 0.4 km/h Windgeschwindigkeit), Richtung 180 (= Süd), Schwankungsbreite der Richtung 1 (= ±22.5°). Die RSSI ist jetzt auch im Log.

Gruß

Hermann

hermannk

Hallo Ansgar,

ZitatGut, dann hat das zu viel gesetzte Bit entweder eine andere Bedeutung, oder es ist einfach immer gesetzt. -> in 14_CUL_WS.pm zu berücksichtigen, aber erst, wenn die Adressfrage klar ist. CUL hat damit erst mal nichts zu tun.
Lass es mal mit Wasser ;) regnen und schau, ob sich was am Bit ändert. Natürlich könnte die Regen-Sofort-Erkennung, sofern in dem Sensor vorhanden, auch durch Verschmutzung oder Beschädigung daueraktiv sein. Das Bit wäre zumindest noch geeignet, um dafür gut zu sein.

Der Regensensor ist flammneu, frisch aus der Verpackung und ohne Staub.;D Er hat keinen Feuchtesensor. Er hat "nur" die Wippe. Ich habe ihn mal nach draußen gestellt aber auf den Regen muss ich noch ein paar Tage warten.

Gruß

Hermann

noansi

Hallo Hermann,

ZitatDadurch wird mein  log sehr unübersichtlich. Lässt sich das abstellen?

... ich hab da doch was gelesen... Ja, indem Du den HM CUL auch auf meine Firmware Version flashst.

Denn selbst wenn ich den Logeintrag abstelle, das alte Warten habe ich raus genommen, da CUL bei mir wartet. Und dann würde HM nicht gesendet, da CUL in alter Version den Befehl nicht versteht.

Gruß, Ansgar

hermannk

Hallo Ansgar,

ZitatTeste bitte mal sens 12. Der Ansatz mit 8 war ja schon gut.

Okay.

2015.01.22 19:41:42 3: Setting AGCCTRL0 (1D) to 92 / 12 dB


Ich muss mir das jetzt erst einmal einen Tag laufen lassen, denn die Empfangssituation verändert sich periodisch im Tagesverlauf.

Eines interssiert mich aber jetzt schon. Seit ich sense geändert habe, treten im Protokoll in schöner Regelmäßigkeit Zeilen der Art


2015.01.22 20:00:06 4: CUL_Parse: CUL433  264418 A FF02 00134616 00 01 CE -138
2015.01.22 20:05:39 4: CUL_Parse: CUL433  073141 A FF02 00467640 00 01 CE -138
2015.01.22 20:11:12 4: CUL_Parse: CUL433  406152 A FF02 00800664 00 01 CE -138
2015.01.22 20:16:45 4: CUL_Parse: CUL433  214875 A FF02 01133688 00 01 CE -138
2015.01.22 20:22:18 4: CUL_Parse: CUL433  023598 A FF02 01466712 00 01 CE -138
2015.01.22 20:27:51 4: CUL_Parse: CUL433  356610 A FF02 01799736 00 01 CE -138                                                                     
2015.01.22 20:33:24 4: CUL_Parse: CUL433  165333 A FF02 02132760 00 01 CE -138


Die Zeilen unterscheiden sich wesentlich von den anderen "CUL_Parse"-Zeilen. Was bedeuten die Einträge?

Gruß

Hermann

hermannk

Hallo Ansgar,

Zitatindem Du den HM CUL auch auf meine Firmware Version flashst

HM läuft bei mir auf einem CUNO, auf dem CUL läuft ausschließlich SlowRF. Kann ich die Meldungen ignorieren?

Gruß

Hermann

hermannk

Hallo Ansgar,

ZitatGut, denn ab und zu reicht bei mir die Checksummenabsicherung nicht, um fehlerhafte Daten raus zu werfen. Deswegen muss ich fragen.

ich habe mal bei einigen WS2000 Paketen die XOR und die SUM nachgerechnet. Die XOR stimmt immer, die SUM stimmt fast nie. Beispiele:

2015-01-21 18:30:11 8D6230E623EF00 (K51813081 D3, RSSI -96.5)

1 0 0 0|1 1 0 1|0 1 1 0|0 0 1 0|0 0 1 1|0 0 0 0|1 1 1 0|0 1 1 0|0 0 1 0|0 0 1 1|1 1 1 0|1 1 1 1|0 0 0 0


10001     10101     10001     00011     00001     11001     10001     00011     11101     1110!
1         5         1         8         0         3         1         8         7         7
Type      Adr,0     8.1                           81.3                          XOR       SUM      xor=7 sum=b

2015-01-22 01:11:31 8D4630E67D9F00 (K51883079 D4 -96)

1 0 0 0|1 1 0 1|0 1 0 0|0 1 1 0|0 0 1 1|0 0 0 0|1 1 1 0|0 1 1 0|0 1 1 1|1 1 0 1|1 0 0 1|1 1 1 1|0 0 0 0|0 0 0 0

10001     10101     00011     00011     00001     11001     10011     11101     10011     1110!
1         5         8         8         0         3         9         7         9         7
Type      Adr       8.8                           79.3                          XOR       SUM      xor=9 sum=9

2015-01-22 01:17:20 8D6630867EEF80 (D1 -97.5)

1 0 0 0|1 1 0 1|0 1 1 0|0 1 1 0|0 0 1 1|0 0 0 0|1 0 0 0|0 1 1 0|0 1 1 1|1 1 1 0|1 1 1 0|1 1 1 1|1 0 0 0|0 0 0 0

10001     10101     10011     00011     00001     00001     10011     11110     11101     11110
                                                                          ↑
                                                                        remove

10001     10101     10011     00011     00001     00001     10011     11101     11011     1110!
1         5         9         8         0         0         9         7         b         7
Type      Adr,0     8.9                           79.0                          XOR       SUM      xor=b sum=7


Ich habe deshalb den Sensor mit der Adresse 5 ausgewählt, weil ich ihn (= sein Programm) kenne. Darüber hinaus habe ich seine Signale sehr gründlich geprüft. Ich behaupte mal, dass es nicht sein kann, dass er fast immer (mit einer Häufigkeit von 15/16) falsche SUMmen sendet. Empfängt der CUL überhaupt die SUMme? Oder überschreibt er sie?

ZitatDas fehlende Stopbit beim jeweils letzten Nibble wird auch noch bei der Prüfung "ergänzt" (was auch noch scheitern kann).

Das verstehe ich nicht. Das letzte Stoppbit wird doch wie alle anderen Bits vorher empfangen. Warum erfordert das eine Sonderbehandlung?

Gruß

Hermann

noansi

Hallo Hermann,


Zitataber auf den Regen muss ich noch ein paar Tage warten.

Ist es schon so kalt, dass Wasser aus einem Glas direkt beim reinschütten in den Trichter gefriert?  ;)


Zitattreten im Protokoll in schöner Regelmäßigkeit Zeilen der Art

Das sind HM Pings aus den Änderungen für HM in Firmware und 00_CUL.pm. Damit messe/aktualisiere ich die IO Zeiten um HM Antwort delays zu optimieren.
Die sollten eigentlich nur bei HM angefordert werden, aber da habe ich noch eine Unschärfe in 00_CUL.pm, so dass die Pings auch bei anderen Protokollen periodisch angefordert werden.


ZitatHM läuft bei mir auf einem CUNO

Und hängt mit am System und läuft über 00_CUL.pm? Das gibt dann wohl erst mal einen Versionskonflikt. Bei HM würde es dann bei Dir jetzt nicht mehr wirklich laufen?!?
Da müsste ich dann mal einen Mix-bau von 00_CUL.pm machen.

Zitatdie SUM stimmt fast nie
XOR mit in die Summ und +5

Gruß, Ansgar.

hermannk

Hallo Ansgar,

danke für die Hinweise. Die haben einige Fragen beantwortet.

ZitatUnd hängt mit am System und läuft über 00_CUL.pm? Das gibt dann wohl erst mal einen Versionskonflikt. Bei HM würde es dann bei Dir jetzt nicht mehr wirklich laufen?!?

das Problem hatte ich glatt übersehen. Denn bis heute hatte ich lediglich den CUL433 neu geflasht. Klar, der CUNO verwendet das gleiche 00_CUL.pm. Und seit etwas mehr als einer Stunde ist HM tot. Schade. Dann werde ich zunächst wieder die "alte" 00_CUL.pm restaurieren, denn die einzig sichtbare Verbesserung ist derzeit bei mir, dass die RSSI beim Regensensor mit der neuen 00_CUL.pm korrekt angezeigt wird.

ZitatIst es schon so kalt, dass Wasser aus einem Glas direkt beim reinschütten in den Trichter gefriert?

Das würde schon durchlaufen und dabei die Wippe genau so bewegen, wie ich es vorher durch Neigen des Gehäuses gemacht habe. Von der Wippe läuft es dann direkt durch Öffnungen im Gehäuse auf den Boden. Ich kann mir nicht vorstellen, dass dabei irgendetwas Unvorhergesehenes passiert. Deshalb ist meine Motivation, Wasser in den Trichter zu giessen, recht klein. Zumal sich das "Problem" ohne mein Zutun erledigt.

ZitatXOR mit in die Summ und +5

Oops, ist das peinlich. :-[

    nib2fifo_ (crc_);
    nib2fifo_ ((sum_ + 5u) & 0xf);


Wenn man bedenkt, dass crc_ und sum_ durch nib2fifo() weiter gerechnet werden, hätte ich meine Zeilen verstehen müssen.

Gruß

Hermann

noansi

Hallo Hermann,

Zitatdass die RSSI beim Regensensor mit der neuen 00_CUL.pm korrekt angezeigt wird.

Dann wirf einen Blick in CUL_Parse und bau Dir die RSSI Anzeige richtig ein, wenn sie Dir so viel hilft.

Alternativ kannst Du Dir natürlich auch die Firmware anschauen und bei CUNO die nötigen Anpassungen ergänzen, damit Du die Firmware auch auf CUNO laufen lassen kannst.  :)


Zitat, weil ich ihn (= sein Programm) kenne

Hast Du Dir einen eigenen Sensor gebaut und/oder eine eigene Firmware für einen WS Sensor geschrieben?

Gruß, Ansgar.