Autor Thema: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39  (Gelesen 264478 mal)

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #60 am: 20 Januar 2015, 22:01:19 »
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                                                                                                                                                                                               


Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #61 am: 21 Januar 2015, 00:07:18 »
Hallo Hermann,

erst mal danke für den Test.

Zitat
Wenn 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.


Zitat
Einige 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.

Zitat
Es 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.

Zitat
Die 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.

Zitat
Der 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.

Zitat
Im 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.
« Letzte Änderung: 21 Januar 2015, 00:09:47 von noansi »

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #62 am: 21 Januar 2015, 13:00:38 »
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.

Zitat
Wenn 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.

Zitat
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.

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".

Zitat
Sendet 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.

Zitat
Aktiviere 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.

Zitat
Also 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

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #63 am: 21 Januar 2015, 18:16:11 »
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

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #64 am: 21 Januar 2015, 23:58:33 »
Hallo Hermann,

Zitat
kann 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.

Zitat
Klar, 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.

Zitat
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.

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.

Zitat
Ich 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.

Zitat
Es 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.

Zitat
Hier 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.

Zitat
Es 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

Zitat
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?

####################################################################
# 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.


Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #65 am: 22 Januar 2015, 19:54:26 »
Hallo Ansgar,

ich beantworte deine Hinweise mal Punkt für Punkt.

Zitat
Ich 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

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #66 am: 22 Januar 2015, 20:15:47 »
Hallo Ansgar,

Zitat
V1.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

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #67 am: 22 Januar 2015, 20:24:26 »
Hallo Ansgar,

Zitat
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.

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

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #68 am: 22 Januar 2015, 20:40:58 »
Hallo Hermann,

Zitat
Dadurch 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

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #69 am: 22 Januar 2015, 20:43:05 »
Hallo Ansgar,

Zitat
Teste 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

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #70 am: 22 Januar 2015, 20:48:12 »
Hallo Ansgar,

Zitat
indem 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

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #71 am: 22 Januar 2015, 21:05:11 »
Hallo Ansgar,

Zitat
Gut, 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?

Zitat
Das 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

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #72 am: 22 Januar 2015, 21:12:12 »
Hallo Hermann,


Zitat
aber 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?  ;)


Zitat
treten 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.


Zitat
HM 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.

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

Gruß, Ansgar.

Offline hermannk

  • Jr. Member
  • **
  • Beiträge: 60
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #73 am: 22 Januar 2015, 21:46:38 »
Hallo Ansgar,

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

Zitat
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?!?

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.

Zitat
Ist 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.

Zitat
XOR 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

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #74 am: 22 Januar 2015, 22:33:49 »
Hallo Hermann,

Zitat
dass 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.