mikrocontroller.net

Forum: Projekte & Code SDR-Dekoder für TFA KlimaLogg Pro/IT+ Temperatursensoren


Autor: Georg A. (georga)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Hi,
wie in Beitrag "Wetterstationssensor: Kann der RFM12b das Protokoll überhaupt?" schon angedroht, 
habe ich den Code zur Dekodierung der TFA KlimaLogg Pro/IT+ Sensoren 
(30.3180.IT) mittels SDR-Stick auf github gestellt:

https://github.com/baycom/tfrec

Der Dekoder versteht nur die KlimaLogg Pro Sensoren 
(Temperatur+Feuchtigkeit), die in NRZS senden. Diverse andere 
TFA-Varianten machen NRZ, daher können nur die per RFM69&Co empfangen 
werden.

Verwendet wurde ein Stick mit R820T2-Tuner (so ein hellblauer ala 
Ebay-Artikel Nr. 172322877121), der wird von librtl-sdr auch gut 
unterstützt. Damit ist die Empfindlichkeit mit der mitgelieferten 
Antenne mindestens so gut wie mit der TFA Basisstation. Und billiger als 
ein JeeLink ist er auch noch...

Getestet wurde mit Linux (x86/x86_64/RasPI3) und MacOS. Für Windows 
hatte ich noch kein Bedarf, sollte aber eigentlich auch gehen. 
Inzwischen laufen damit 16 Sensoren problemlos.

Jedes Sensor-Telegramm kann nach dem Empfang an ein beliebiges 
Executable übergeben werden, dass sich um die weitere 
Auswertung/Speicherung kümmert. Bei Bedarf baue ich noch das Versenden 
via UDP an einen Host ein.

Ansonsten ist der Code jetzt eher so hingeschlonzt, mag sein, dass das 
noch effizienter geht ;)

Eine Demo-Visualisierung mit Apache/Perl+MySQL ist auch noch drin, das 
ist aber nur ein Quick-Hack.

Autor: gr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Georg,

Funktioniert perfekt auf einem PI3 + 4 Sensoren und wird auch gleich via 
Webservice in meine Loxone Visualisierung integriert!

Vielen vielen Dank für die Implementierung!

LG

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr schön...

Ich glaub ich baue auch nochmal was ala "executive summary" ein, wo 
maximal x Sekunden auf das Auftauchen von n IDs gewartet wird und dann 
alles in einem Rutsch ausgegeben wird. Das 10s-Raster jetzt ist zwar 
schon nett (ui, wer ist grad durch die Haustür rein...), aber auch nicht 
wirklich datensparsam :)

Offensichtlich gibt es für IT+ noch einen Sensor mit abgesetztem 
Temperaturfühler (.3181). Muss ich mir wohl noch anschaffen, evtl. hat 
der einen anderen Typ-Code.

BTW: Die normalen IT+ Sensoren gibt es für 15EUR bei Knufis Optik Shop 
(kein Witz, nur eine Metzgerei wäre noch abstruser...). Das ist der 
bislang niedrigste Preis, der mir untergekommen ist. Ich habe da gleich 
16 Stück bestellt, die auch geliefert wurden. Also kein Fake-Shop ;) Für 
den Preis fange ich nicht an, was mit AVR/ESP8266/PIC/RFM* selber zu 
frickeln, zumal die Sensoren dank Display ja selbst ohne Funk schon 
nützlich sind und die Batterien bei meinen "alten" schon mind. 2.5 Jahre 
durchgehalten haben. Das muss man erstmal mit der Eigenentwicklung 
schaffen...

Autor: gr (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich hab die Integration jetzt mit UDP gemacht, da das auf die schnelle 
am einfachsten war. Eine UDP Option in der Auswertesoftware ist schon 
fast overkill, da es in Linux mit einem Einzeiler erledigt ist und mit 
systemd auch gleich als Service läuft:

/home/osmc/tfrec/tfrec -q -e /bin/echo | socat - 
udp-sendto:192.168.1.2:6000

Die Auswertung auf dem Miniserver ist auch sehr einfach mit einem 
virtuellen UDP Eingang erledigt, da spielt auch die Freuquenz der 
eintrudelnden Pakete keine Rolle, da der Zeitraum der Statistiken 
konfigurierbar ist.

Was soll ich sagen, es funktioniert perfekt!

Ein .3181 ist schon bestellt, mit dem integriere ich dann im Sommer die 
Pooltemperatur, ich geb bescheid, ob er im tfrec auftaucht.

Danke nochmal für die Implemetierung!

Autor: Gerhard M. (heligemus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin gerade auf diesen für mich super interessanten Thread gestoßen.

Ich habe derzeit 9 solcher Sensoren im Haus verteilt wovon ich ja 
gleichzeitig nur 8 verwenden kann - im Sommer tausche ich immer einen 
'normalen' Raumsensor .3180 gegen einen .3181 für die Messung der 
Pooltemperatur - daher ist für mich die Unterstützung beider Sensortypen 
Uch wichtig.

Weiters experimentiere ich gerade mit der Home Automation Plattform 
'HomeAssistant' herum und da bietet sich natürlich ein Verbinden beider 
Systeme perfekt an.

Ich werde mir heute noch den SDR-Stick bestellen - die Frage ist, ob ein 
RasPI1 auch reichen würde, den hätte ich noch unbenutzt herumliegen.

Wenn's dann mal läuft muß ich die Daten noch in den HomeAssistant hinein 
bekommen - ich habe da ein kleines Testprojekt mit dem MQTT Protokoll 
gemacht - ich denke, das müsste mit dem vorhandenen Code und einer 
entsprechenden Library auch machbar sein.

Ich werde wieder berichten sobald ich etwas am Laufen habe - oder wenn 
Probleme auftauchen - bin schon sehr gespannt. Für Tipps bin ich immer 
dankbar.

Vielen Dank vorab für die ganze Arbeit.

Autor: Georg A. (georga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Ich werde mir heute noch den SDR-Stick bestellen - die Frage ist, ob ein
> RasPI1 auch reichen würde, den hätte ich noch unbenutzt herumliegen.

Potentiell ja, aber per Monte-Carlo-Methode ;) Die SDR-Lib liest ja 
immer 256KB Daten ein, danach werden sie dekodiert. Das Einlesen erfolgt 
per USB/DMA, also eher keine CPU-Last. Wenn die SW-Auswertung zu lange 
braucht, müssten "nur" ganze Blöcke verloren gehen. Wenn Telegramme in 
einem Block sind, sollten die schon einwandfrei dekodiert werden können. 
Es dauert also vermutlich nur länger, alle Sensoren mal zu erwischen.

Autor: Gerhard M. (heligemus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg,

ich hab die Komponenten bekommen (hab mir zur Sicherheit doch einen 
Raspi3 mitbestellt) und das System jetzt in Betrieb genommen - und was 
soll ich sagen, es hat auf Anhieb (fast) perfekt geklappt. Nur der .3181 
Sensor machte vorerst ein wenig Probleme.
Das Protokoll scheint ganz gleich zu sein wie das vom .3180, nur weil er 
als reiner Temperatursensor einen Standard-Feuchtewert von 0x6a 
mitschickt bin ich nach einiger Zeit Code-Review draufgekommen, daß du 
einen Wert von 0x6a expliziet als Fehler behandelst - daher hab ich das 
mal kurzerhand ausgeklammert und siehe da, jetzt funzt auch der .3181. 
Den Feuchtewert könnte man z.B. noch auf Null setzen, aber das ist ein 
kleines Detail.

Vielen Dank nochmal für die super Arbeit - beizeiten probier ich dann 
auch den Raspi1 nochmal aus. Jetzt muß/kann ich mir erst noch ein paar 
zusätzliche Sensoren beim Optiker kaufen ;)


hier noch ein paar Daten zur Info:

Debug vom .3181 vor der Code-Änderung mit tatsächlich schwacher 
Batterie:
#095 1486819092  2d d4 b7 a6 86 42 6a e0 60 56 56           ID 37a6 +0.0 
0%  seq 6 lowbat 2 RSSI 79

Debug vom .3181 vor der Code-Änderung mit neuer Batterie:
#153 1486819400  2d d4 b7 a6 86 42 6a 60 40 56 5f           ID 37a6 +0.0 
0%  seq 4 lowbat 2 RSSI 80

Debug vom .3181 nach der Code-Änderung mit neuer Batterie:
#934 1486821012  2d d4 b7 a6 87 03 6a 60 b0 56 02           ID 37a6 
+30.3 106%  seq b lowbat 0 RSSI 80

Code-Änderung:
// Sensor values may fail at 0xaaa/0xfff or 0x6a/0x7f due to low battery
// even without lowbat bit
// Set it to 2 -> sensor data not valid
if ( /*hum==0x6a ||*/ hum==0x7f) {
   batfail=2;
   hum=0;
   temp=0;
}

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gabs schon einen Patchvorschlag im git (von gr?), der das macht. Bin 
noch nicht dazugekommen, wollte noch meinen 81 abwarten, der im Versand 
hängt. Der Check an sich kam daher, dass bei meinen etwas penetranten 
Tests auf Unterspannung sich der Sensor wohl manchmal aufgehängt hatte 
und dann je nach Laune 7f oder 6a bei der Feuchtigkeit rauskam. 
Allerdings waren da AFAIR auch die Temperaturnibbles aaa/fff.

Bei meinem Kollegen ist wegen massiver Luftfeuchtigkeit in der Garage 
auch ohne Unterspannung 6a entstanden, da stand im Display --%... 
Vermutlich sollte man also eher die Temperatur als Sanitycheck nehmen 
und die Feuchtigkeit auf 100% begrenzen.

Mich wundert eigentlich, dass der 81 keinen anderen Typ hat. Diese 
konstante 56 klingt irgendwie danach.

Autor: Gerhard M. (heligemus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na super - und ich war stolz auf mich das ich das Problem selbst finden 
konnte. Ich bin wie du merkst nicht so bewandert mit git und Co und war 
schon extrem froh, dass ich den Code überhaupt zum Laufen bringen 
konnte;)

Autor: gr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja der Fix ist der den ich bei mir umgebaut habe, dass der 3181 läuft.
Zumindest bei mir funktioniert es bisher ohne Probleme, sowohl mit 3180 
als auch 3181. :)

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der 3181-Sensor ist jetzt im git-Repository.

Und nebenbei habe ich den Support für die anderen TFA/LaCrosse-Sensoren 
mit NRZ und 17240 und 9600Baud eingebaut. D.h. es gehen jetzt mindestens 
auch 30.3143, 30.3144 und 30.3155 (die drei Geräte habe ich), vermutlich 
auch 30.3146. Wenn ich aber die unzähligen Telegramme sehe, die da jetzt 
rauspurzeln, egal wo ich den Dekoder anwerfe, sind es sicher noch viel 
mehr unterstützte Typen, wie Nonames ala TX21IT, ... . In meiner 
Umgebung gibts schon 4 "fremde" Aussentemperatursensoren ;)

BTW: Es gibt wohl auch einen dedizierten Pool-Sensor 30.3199.IT für 
KlimaLoggPro, der sollte auch gehen. Scheint aber gern undicht zu 
werden...

PS2: Falls die CPU-Load für den RasPI jetzt zuviel wird, kann man die 
neuen Decoder mit der -T Option wieder ausschalten.

: Bearbeitet durch User
Autor: Oneiros (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nice Work!!!
Funktioniert bei mir mit 30.3159.IT, 30.3156.WD und 30.3147.IT:
#092 1490255901  2d d4 9d 46 41 6a 0a                       ID 10009d40 
+24.1 0 0a 0a RSSI 78 Offset -11kHz
11009d40 +24.1 0 0 0 78 0 1490255901
#093 1490255904  2d d4 92 04 51 6a 94                       ID 10009200 
+5.1 0 94 94 RSSI 76 Offset -16kHz
11009200 +5.1 0 0 0 76 0 1490255904
#028 1490255904  2d d4 91 04 58 6a cb                       ID 20009100 
+5.8 0 cb cb RSSI 86 Offset -16kHz
22009100 +5.8 0 0 0 86 0 1490255904

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Rückmeldung. Ich werde die Liste der unterstützen Sensoren 
updaten. Die IDs 10009d40&10009200 sind 3147/3159, die 20009100 der 
3156, oder?

Ich verliere echt gerade den Überblick bei dem TFA-Sammelsurium, da gibt 
es gefühlte 100 Stationen mit 50 Sensoren...

Autor: Oneiros (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die IDs 10009d40&10009200 sind 3147/3159, die 20009100 der
> 3156, oder?

Ja,

10009d40 3147
10009200 3159
20009100 3156

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, damit ist der ganze Weatherdirect-Kram definitiv die 
9600Baud-Variante.

Stellt sich nur die Frage, wo eigentlich der Unterschied zwischen 3147 
und 3159 liegt. Display haben sie beide keins, Feuchtigkeitssensor auch 
nicht, Gehäuse sieht identisch aus. Produktvielfalt ist schon was 
tolles...

Autor: MitLeserin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@GeorgA

Sehr interessantes Projekt, Danke.

Ich habe versucht, mich in Perl einzulesen, um /contrib zu verstehen.
In der Bilddatei ein screenshot der Konsole.

./trec funktioniert
./tfrec -e /var/cgi-bin/contrib/pushvals  wird aufgerufen, aber 
vermutlich noch nicht korrekt.

apache2 installiert. PERL tutorial funktioniert.

MySQL installiert, Tabelle erstellt, aber keine Erfahrung mit MySQL.

sensors.html geändert für einen Sensor [Temp/Hum] mit korrekter ID.
sensors.html öffnet Browser, aber leer, nur der Titel ist richtig: 
"TFA-Sensor-Portal"

Für Hinweise zur Fehlersuche wäre ich dankbar.
*********************************************
Alexandra

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Datenfluss ist deswegen so "kompliziert", damit die Datenbank auf 
einem anderen Rechner als dem eigentlichen Empfänger laufen kann.

1) tfrec ruft das pushvals-Script mit den Sensorswerten auf.
2) Das wiederum ruft das pushvals.cgi auf deinem Webserver auf.
3) pushvals.cgi fügt die Daten in MySQL ein
4) sensors.html lädt mit Javascript via sensors.cgi die Daten jedes 
einzelnen Sensors nach.
5) sensors.cgi holt die Daten aus der DB und liefert sie JSON-formatiert

1-3 sieht eigentlich gut aus. Du kannst dich ja mal mit "mysql -u 
smarthome -p smarthome" (und dann dem DB-Passwort aus pushvals.cgi) ein 
die DB einloggen und mit "select count(*) from sensors;" bzw. "select * 
from sensors;" nachschauen, ob/was schon in der Tabelle steht.

zu 4) Javascript muss im Browser angeschaltet sein, sonst bleibt es 
leer. Falls bei der Setup-Tabelle in sensors.html was faul ist, steht 
wg. Syntax-Fehler auch nichts da. Evtl. mal im Javascript-Debugger die 
Console anschauen (zB. im Firefox Web-Konsole bzw. Firebug). Wenn JS 
geht, sollte normalerweise eine "Loading..."-Meldung pro Chart dastehen. 
Wenn es das nicht tut, ist da wohl was faul.

zu 5) Kann man im Browser mit 
"http://<servername>/sensors.cgi?type=tfa-temp&id=<...; probieren. 
Da sollte eine Liste zurückkommen.

BTW: Wenn der Webserver auch von aussen erreichbar ist, wäre das 
"Verstecken" der CGIs in einem Unterordner evtl. nicht verkehrt. Ausser 
den beiden CGIs und dem html sollte auch sonst nichts im Verzeichnis 
sein, insb. das pushvals-Shellskript.

Autor: MitLeserin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Anleitung.
Funktioniert einwandfrei.

Ein schönes Beispiel für Datenerfassung, Speicherung und Darstellung.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg,

vielen Dank für das tolle Projekt!

Ich habe bemerkt, dass auch bei Angabe von '-q' einige Debug-Ausgaben 
erscheinen. Ich glaube den Fehler gefunden und behoben zu haben, Du 
findest dazu einen Pull Request im Git-Repository.

Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

zuallererst möchte ich mich noch einmal bei Georg für das tolle Projekt 
bedanken. Ich suche seit vielen Jahren nach einer Möglichkeit, meine 8 
Temperatur-Sensoren in die Heimautomation zu integrieren. Mit trfec 
sieht es so aus, als könnte das gelingen.

Ich habe zur Zeit noch ein kleines Problem: Beim Start von tfrec werden 
alle 8 Sensoren empfangen, aber nach und nach verschwinden alle Sensoren 
wieder.


Mein Systemaufbau:
- Raspberry Pi B 3
- DVB-T-Stick: PID/VID: 0bda/2838 (Realtek RTL2838UHIDIR), 
tfrec-Ausgabe: Fitipower FC0012
- 8 Sensoren TFA 30.3180.IT
- tfrec als systemd-Service, Aufruf:
/opt/tfrec/tfrec -T 1 -g 13 -q -e /opt/tfrec/publish-tfrec-to-mqtt.sh
- im Weiteren Verlauf noch mosquitto und FHEM, das spielt für das 
Problem aber keine Rolle


Das Problem
Beim Start von tfrec werden alle 8 Sensoren empfangen, aber mit der Zeit 
verschwinden einige Sensoren nach und nach. Nach einiger Zeit (ca. 1,5 
Stunden) wird nur noch 1 Sensor (immer dieselbe ID: 5151) empfangen. 
Nach weiterer Zeit (ca. 2,5 Stunden) empfange ich überhaupt keinen 
Sensor mehr. Nach Neustart von tfrec (ohne Hardware-Eingriff) werden 
wieder alle Sensoren empfangen.

Zusatz-Informationen:
- Im System-Log und in der Ausgabe von tfrec ist nichts zu finden.
- Effektiv sind nur 4 Gain-Werte möglich:
  -g 0 bis 5: -4.0
  -g 10 bis 12: 7.1
  -g 13 bis 18: 17.9
  -g 19 und mehr: 19.2


Leider verstehe ich den Quellcode selbst nicht genug, um das Problem 
weiter zu analysieren. Meine Vermutung: Während der Laufzeit passt tfrec 
einige Tuning-Parameter an, und dabei läuft irgend etwas schief (ich 
tippe hier auf tfa2_demod::demod und fsk_demod::process).

Hat jemand eine Idee?

: Bearbeitet durch User
Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian X. schrieb:
> Hat jemand eine Idee?

Ja. Vermutlich geht die Triggerlevel-Erkennung daneben. Ich habe da 
etwas eingebaut, was bei zu vielen Auslösungen die Empfindlichkeit etwas 
runtersetzt (aber nicht wieder rauf). Offensichtlich funktioniert das 
aber nur bei mir. Ich habe auch einen anderen Report, wo wohl soviel 
Störungen in der Umgebung sind, dass damit eine dauerhafte Taubheit 
entsteht. Ich versuche gerade das etwas dynamischer zu machen. Als 
temporäre Abhilfe könntest du in fm_demod.cpp so ab Zeile 56 den 
gesamten if-Block 'if (triggered >= ...) {...}' auskommentieren.

BTW: Die beschränkte Anzahl der Gain-Werte liegt an dem Fitipower-Tuner 
(zB. im Noxon-Stick benutzt). Da kann jeder Tunerchip was anderes.

: Bearbeitet durch User
Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die schnelle Antwort.

Ich habe den Code-Block wie vorgeschlagen auskommentiert. Ohne weitere 
Veränderungen hatte ich damit zunächst keinen Empfang mehr; ich schätze, 
dass die Trigger Ratio nun nicht mehr automatisch ermittelt wird und 
der Default-Wert in meinem Fall nicht passt. Deshalb habe ich dann die 
Änderung rückgangig gemacht und durch Angabe von '-D -D' die erweiterte 
Debug-Ausgabe eingeschaltet. Damit wird auch die Trigger Ratio 
ausgegeben. In meinem Fall ist 1000 ein geeigneter Wert. Ich habe 
deshalb meinen Aufruf entsprechend erweitert zu
/opt/tfrec/tfrec -T 1 -g 13 -t 1000 -q -e /opt/tfrec/publish-tfrec-to-mqtt.sh
und empfange damit wieder alle Sensoren. Ich bin bisher sehr zufrieden 
und gespannt auf die nächsten Stunden und Tage.

Autor: Maik W. (istler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hall Georg,

so heute ist endlich mein SDR angekommen. Ich konnte ihn auch gleich 
ausprobieren. :-)
Bei den Requirements für das Make fehlt noch "pkg-config".
Ansonsten konnte ich ohne probleme unter "Ubuntu 16.04.2 LTS" 
kompilieren und lief auch gleich los! :-)
Ich möchte damit meinen Pool-Sensor (30.3199.IT) abfragen.
Doch leider lieferte dieser gleich erst mal  "BAD 33 RSSI 73 (SANITY)". 
:-(
Schuld ist die Abfrage in tfa1.cpp Zeile 70
&& ((rdata[7]&0x70)==0x60
Wenn ich diesen UND-Teile Auskommentiere oder mit 1 verodere, dann 
erhalte ich folgenden Output:
#045 1497699524  2d d4 59 cd 86 63 6a 70 c0 56 f1           ID 59cd +26.3 0%  seq c lowbat 0 RSSI 81
:-D Das ist richtig!

Bei dem Pool-Sensor ist das 8 Byte scheinbar immer 0x70. Warum hast du 
da auf 0x60 abgefragt?

Gruß
Maik

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maik W. schrieb:
> Bei dem Pool-Sensor ist das 8 Byte scheinbar immer 0x70. Warum hast du
> da auf 0x60 abgefragt?

Weil bei den zwei Sensorinkarnationen, die ich habe, das immer 0x60 ist 
und damit ein zusätzlicher Check auf Sinnhaftigkeit der empfangenen 
Daten vorhanden ist. Ich habe keine Ahnung, was da eigentlich kodiert 
wird... Das oberste Bit ist ja der Batteriealarm. Ich hätte aber eher 
gedacht, dass der Sensortyp in der 56 steckt, die Zahl wird beim Startup 
ja auch ausgegeben.

Aber gut, dass wir verglichen haben ;) Ich würde da jetzt ein 
rdata[7]&0x30)==0x20 draus machen, dann gibts immerhin noch zwei Bits 
für den Sanitycheck.

Autor: Maik W. (istler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg,

Georg A. schrieb:
> rdata[7]&0x30)==0x20
Das klappt nicht, bei mir rdata[7]=0x70 ergibt 0x70 & 0x30 = 0x30. Wenn 
funktioniert es mit (rdata[7]&20)==20.


Ich lasse meinen Stick jetzt mit:
/usr/bin/tfrec -D -D -D -D -e /var/www/html/tfrec/pushvals
laufen. Dabei tritt bei mir das Problem auf, dass er manchmal den einen 
oder Anderen Sensor, der etwas weiter weg ist (RSSI ~ 60) für eine 
Zeitlang (> 60min) nicht empfängt. Dann empfängt tfrec diesen wieder 
stundenlang ohne Probleme. Der JeeLink, der direkt neben dem tfrec-Stick 
hängt, empfängt die fraglichen Sensoren die ganze Zeit ohne Probleme!?
Hast du eine Idee, was ich debuggen könnte?

Gruß
Maik

Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter 
https://github.com/git-developer/fhem-examples/wik... 
gibt es eine Anleitung für die Integration von tfrec in FHEM.

Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte in letzter Zeit einige Male das Problem, dass tfrec nach 
langer Laufzeit keine Werte mehr liefert. Ursache ist vermutlich eine 
instabile Verbindung zum DVB-T-Stick. Es würde mir helfen, wenn der 
Prozess in so einem Fall mit einem Fehlercode beendet würde anstatt ohne 
Funktion weiterzulaufen. Ich habe deshalb unter 
https://github.com/baycom/tfrec/issues/3 einen Feature-Request erstellt.

Ich würde auch probieren, das selbst zu implementieren; ich wäre dankbar 
für einen Tipp, an welcher Stelle im Code ich dafür ansetzen kann.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist rauszufinden, was in dem Zustand eigentlich los ist. 
Wenn da vom Stick schon keine Daten mehr kommen, könnte man das mit 
einem trivialen Alarm-Timeout/Signal lösen. Wenn da noch Schrottsamples 
kommen, wirds schwerer.

Kommentier mal in sdr.cpp/sdr::read_data das printf am Anfang wieder 
rein. Dann sollte man sehen ob der Datenstrom abreisst oder nicht.

Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das printf einkommentiert; das Log hat sich daraufhin auch 
schnell mit Meldungen 'Got 262144' gefüllt, im Schnitt ca. 20x pro 
Sekunde. Der letzte Absturz ist nach 6 Wochen aufgetreten, davor war die 
Laufzeit 1 Woche. Ich möchte das Log ungern ein paar Wochen volllaufen 
lassen, zumal es auf einer SD-Karte liegt (-> Lebensdauer).

Ich denke, dass der Stick keine Daten mehr liefert, und zwar aufgrund 
folgender Beobachtungen:

1.) Für die letzten beiden Ausfälle habe ich Logs zur CPU-Last; zum 
Zeitpunkt des Ausfalls ist sie von 0.4 auf 0.1 gefallen, das entspricht 
der Auslastung von tfrec.

2.) Im Log sehe ich, dass nach der Meldung 'cb transfer status: 1, 
canceling...' das USB-Gerät getrennt und sofort wieder verbunden wird. 
Ich vermute, dass die Bibliotheken libusb bzw. libsdr nach dem 
Disconnect neu initialisiert werden müssen, bevor wieder Daten geliefert 
werden.

3.) Der Stick hängt an einem Raspberry Pi 3. Ich habe dort schon die 
Erfahrung gemacht, dass abhängig von Netzteil und angeschlossener 
Hardware die USB-Verbindung nicht immer stabil ist; im Netz wird dieses 
Problem häufig mit einer unzureichenden Spannungsversorgung in 
Verbindung gebracht. Wenn der USB-Stick im laufenden Betrieb von tfrec 
neu startet, werden vermutlich ebenfalls die Bibliotheken neu 
initialisiert werden müssen.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin nach langer Zeit mal wieder dazugekommen...

Der Bug mit der schwindenden Empfindlichkeit sollte jetzt weg sein, der 
Triggerlevel wird automatisch in beiden Richtungen nachgeführt. Diese 
Automatik lässt sich mit -t <level> ganz abschalten, falls es nötig ist.
Der Check für den Pool-Sensor müsste auch passen. Und schliesslich 
beendet sich das Programm, wenn es 5s lang keine Daten vom Stick 
bekommen hat.

Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schön!

Ich teste die neue Version. Bisher funktioniert es, allerdings werden 
nach wie vor beim Setzen von '-q' Debug-Ausgaben erstellt (siehe 
Beitrag "Re: SDR-Dekoder für TFA KlimaLogg Pro/IT+ Temperatursensoren" bzw. Pull-Request 
https://github.com/baycom/tfrec/pull/2 ).

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wusste, dass ich irgendwas vergessen habe. Kommt heute abend...

Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Merge, jetzt sieht's gut aus und läuft bisher ohne 
Aufälligkeiten.

Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Beenden im Fehlerfall klappt. Ich hatte heute erneut einen Ausfall, 
der Service wurde diesmal aber automatisch neu gestartet:
Oct 25 17:37:09 localhost run-tfrec.sh[579]: cb transfer status: 1, canceling...
Oct 25 17:37:09 localhost kernel: [366534.515362] usb 1-1.3.2: USB disconnect, device number 7
Oct 25 17:37:09 localhost kernel: [366534.816957] usb 1-1.3.2: new high-speed USB device number 13 using dwc_otg
Oct 25 17:37:09 localhost kernel: [366534.958613] usb 1-1.3.2: New USB device found, idVendor=0bda, idProduct=2838
Oct 25 17:37:09 localhost kernel: [366534.958621] usb 1-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 25 17:37:09 localhost kernel: [366534.958625] usb 1-1.3.2: Product: RTL2838UHIDIR
Oct 25 17:37:09 localhost kernel: [366534.958629] usb 1-1.3.2: Manufacturer: Realtek
Oct 25 17:37:09 localhost kernel: [366534.958633] usb 1-1.3.2: SerialNumber: 00000001
Oct 25 17:37:14 localhost run-tfrec.sh[579]: Read timeout, exiting
Oct 25 17:37:14 localhost systemd[1]: tfrec.service: main process exited, code=exited, status=255/n/a
Oct 25 17:37:14 localhost systemd[1]: Unit tfrec.service entered failed state.
Oct 25 17:37:14 localhost run-tfrec.sh[579]: Registering demod for TFA_1 KlimaLoggPro
Oct 25 17:37:19 localhost systemd[1]: tfrec.service holdoff time over, scheduling restart.
Oct 25 17:37:19 localhost systemd[1]: Stopping tfrec...
Oct 25 17:37:19 localhost systemd[1]: Starting tfrec...
Oct 25 17:37:19 localhost systemd[1]: Started tfrec.
Oct 25 17:37:19 localhost run-tfrec.sh[31569]: Found Fitipower FC0012 tuner

Autor: MitLeserin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte es sein, dass inkompatible neue Sender 30.3180.IT (05/2017) auf 
dem Markt sind?
****************************************************************
Ich habe 4 Sensoren, deren Daten mit ./tfrec -D nicht verarbeitet 
werden.

Daten Rückseite NEU: 05/2017 V024 C2 ID: XXXX R08B
**************************************************
Beim Einschalten melden sich die Sender auf dem Display mit:
r08 0056 XXXX (Kennung)

Daten Rückseite ALT: 11/2016 V011 C2 ID: XXXX V35
*************************************************
.. die alten Sender melden sich mit:
b35 0056 XXXX

Autor: MitLeserin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
********
pi@raspberrypi:~/tfrec $ sudo ./tfrec -D
Found Rafael Micro R820T tuner
AUTO GAIN
Frequency 868.2500MHz
Samplerate 1536000
START READ THREAD
#000 1509614402  2d d4 15 43 86 93 1d 60 70 56 21           ID 1543 
+29.3 29%  seq 7 lowbat 0 RSSI 80
#001 1509614403  2d d4 fe 5e 86 27 29 60 a0 56 3f           ID 7e5e 
+22.7 41%  seq a lowbat 0 RSSI 80
#002 1509614412  2d d4 15 43 86 93 1d 60 80 56 39           ID 1543 
+29.3 29%  seq 8 lowbat 0 RSSI 80
#003 1509614413  2d d4 fe 5e 86 27 29 60 b0 56 51           ID 7e5e 
+22.7 41%  seq b lowbat 0 RSSI 80
#004 1509614417  2d d4 65 f1 85 91 31 60 f0 46 6c           BAD 1 RSSI 
65 (CRC 6c 2f)
#005 1509614422  2d d4 15 43 86 93 1d 60 90 56 57           ID 1543 
+29.3 29%  seq 9 lowbat 0 RSSI 80
#006 1509614424  2d d4 fe 5e 86 27 29 60 c0 56 6a           ID 7e5e 
+22.7 41%  seq c lowbat 0 RSSI 80
#007 1509614428  2d d4 65 f1 85 91 31 60 00 56 74           ID 65f1 
+19.1 49%  seq 0 lowbat 0 RSSI 65
#008 1509614432  2d d4 15 43 86 93 1d 60 a0 56 e5           ID 1543 
+29.3 29%  seq a lowbat 0 RSSI 80
#009 1509614434  2d d4 fe 5e 86 27 29 60 d0 56 04           ID 7e5e 
+22.7 41%  seq d lowbat 0 RSSI 80
#010 1509614439  2d d4 25 b1 85 91 31 60 20 ac 34           BAD 2 RSSI 
65 (CRC 34 ce)
#011 1509614442  2d d4 15 43 86 93 1d 60 b0 56 8b           ID 1543 
+29.3 29%  seq b lowbat 0 RSSI 80
#012 1509614445  2d d4 fe 5e 86 27 29 60 e0 56 b6           ID 7e5e 
+22.7 41%  seq e lowbat 0 RSSI 80
#013 1509614450  2d d4 65 f1 85 11 31 60 20 56 28           BAD 3 RSSI 
65 (CRC 28 1b)
#014 1509614452  2d d4 15 43 86 92 1d 60 c0 56 63           ID 1543 
+29.2 29%  seq c lowbat 0 RSSI 80
#015 1509614454  2d d4 12 00 08 82 32 00 01 02 44           BAD 4 RSSI 
51 (CRC 44 e1)
#016 1509614456  2d d4 fe 5e 86 27 29 60 f0 56 d8           ID 7e5e 
+22.7 41%  seq f lowbat 0 RSSI 80

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Autogain sieht die Empfangsfeldstärke (RSSI) etwas mau aus, die 
Telegramme sehen bis auf Prüfsummenverändernde Einzelbitfehler 
eigentlich auch so aus wie immer. Kannst du den Sensor mal näher zur 
Antenne bringen oder mal ohne Autogain (z.B. '-g 50') probieren? Evtl. 
hat die neue Version weniger Sendepower...

Wo sind die Sensoren denn her? In meinem Zoo (hab jetzt auch mit den 
"alten" schon fast 25...) macht einer mehr jetzt auch nix mehr aus ;)

Autor: MitLeserin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Quelle: https://www.brack.ch/tfa-dostmann-temperaturfeuchte-185631

zum Testen stehen 3 alte und 2 neue Sender auf einem Tisch und die 
Antenne des SDR hängt 1m darüber.

Es ist die FREQUENZ:
************************

pi@raspberrypi:~/tfrec $ sudo ./tfrec -D -g 45 -f 868330  // statt 
868250
Found Rafael Micro R820T tuner
GAIN 44.5
Frequency 868.3300MHz
Samplerate 1536000
START READ THREAD

#000 1509692779  2d d4 ... 53    ID 1543 +29.4 28%  seq 4 lowbat 0 RSSI 
71  // ALT
#001 1509692783  2d d4 ... 10    ID 743d +21.0 45%  seq 0 lowbat 0 RSSI 
81  // NEU
#002 1509692784  2d d4 ... b5    ID 6777 +21.1 44%  seq 0 lowbat 0 RSSI 
81  // NEU
#003 1509692786  2d d4 ... 85    ID 7e5e +22.0 41%  seq 2 lowbat 0 RSSI 
71  // ALT
#004 1509692789  2d d4 ... 3d    ID 1543 +29.4 28%  seq 5 lowbat 0 RSSI 
71
#005 1509692794  2d d4 ... c3    ID 743d +21.1 45%  seq 0 lowbat 0 RSSI 
81

#024 1509692840  2d d4 ... 00           BAD 1 RSSI 71 (CRC 00 25)   // 
ALT // ID 65f1 ist nicht empfangbar auf 868.330 MHz

#025 1509692849  2d d4 ... b5    ID 6777 +21.1 44%  seq 0 lowbat 0 RSSI 
81
#026 1509692849  2d d4 ... 7a    ID 7e5e +22.0 41%  seq 8 lowbat 0 RSSI 
71
#027 1509692850  2d d4 ... c3    ID 743d +21.1 45%  seq 0 lowbat 0 RSSI 
81

#028 1509692850  2d d4 ... a6           BAD 2 RSSI 80 (CRC a6 09)

Autor: Oliver L (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe auch kürzlich diesen Super Thread gefunden.
Vielen Danke an den Autor!!!

Es funktioniert perfekt auf meinem Raspberry 3.

Ich würde es jetzt gerne zusammen mit Home Assistent über das MQTT 
Protokoll auf dem einen Raspberry nutzen. Auch das ist mir mit der 
tollen Anleitung auf GitHub von Christian X gelungen.

Meinen Home Assistent habe ich dann auf den neuesten Stand gebracht. Der 
läuft jetzt aber unter dem Namen hass.io in einer Docker Umgebung. - Was 
prinzipiell recht elegant ist, da viele nützliche Zusatzpakete als 
Dockerimage per Menü dazu installiert werden können.

Leider fehlt mir zu Docker ein wenig Erfahrung. Ich habe es noch nicht 
geschafft tfrec unter Docker auf dem PI zum Laufen zu bewegen.

Falls da schon jemand weiter ist, würde ich mich über ein paar Tipps 
freuen.

Gruß, Oliver

Autor: Christian X. (mikrocontroller-user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tfrec, der MQTT-Broker und Dein Home Assistent sind unabhängig 
voneinander und können auch getrennt voneinander betrieben werden. 
Möchtest Du tfrec und Mosquitto aus einem bestimmten Grund auch unter 
Docker laufen lassen? Falls nein, müsstest Du im Docker-Container nur 
den Hostnamen Deines Pi als MQTT-Broker angeben. Andernfalls müsstest Du 
ein oder mehrere Docker-Images bauen (und pflegen).

Autor: Oliver L (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Rückmeldung.

Wenn ich die hass.io Plattform nutzen möchte, bleiben mir 2 
Möglichkeiten.
Entweder tfrec+MQTT Client in einem Docker Container oder
auf einem seperaten PI.
Hass.io ist als reine Trägerplattform gedacht. Da läuft Home Assistent, 
MQTT Brooker, SSL, SAMBA, DYNDNS,Let's Encrypt, ... alles sauber 
getrennt in Docker-Containern.
Ich würde halt gerne tfrec auf dem gleichen PI laufen lassen. Das hatte 
ich vorher auch mit WEEWX. Allerdings ohne Docker...

Ich werde noch ein wenig testen. Vielleicht liegts am USB Zugriff aus 
dem Container.

Autor: deminex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke fuer das tolle tool. Habe es auf beaglebone black laufen.

Hat schon jemand Erfahrung mit dem Regensensor TFA 30.3306.02 
http://tfa-dostmann.de/index.php?id=161&L=0 ? Der soll nur mit 
WeatherHub Gateway gehen, da das Gateway auch mit den bekannten obigen 
Temperatur-Feuchte Sensoren funktioniert (ich habe einige 30.3180 und 
30.3181 die mit dem Gateway gehen sollen), hatte ich die Hoffnung, dass 
man die Daten auch mit tfrec sehen kann. Habe mir deshalb einen 
gebraucht besorgt, bisher sehe ich jedoch nichts, werde noch einmal im 
debug modus laufen lassen, jeweils einmal mit Regensensor an und aus, um 
dann die "nicht Regensensor" Daten auszufiltern und dann hoffentlich nur 
den Regensensor zu sehen. War aber im ersten Anlauf nicht erfolgreich. 
Gibt  es noch Ideen was man variieren könnte?

Ich kann leider auch nicht mit "normal" empfangenen Daten vergleichen, 
wollte mir kein Gateway ins Internet zulegen. Zum variieren der  Daten 
kann ich nur die Regenwippe haendisch betaetigen, um es mal gezielt 
regnen zu lassen und mal einen anderen Satz Daten zu bekommen .... .


Danke fuer weitere Ideen.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss ich das Dingens wohl doch mal kaufen ;)

Du könntest aber auch mal mit der Empfangsfrequenz etwas rumspielen. Ich 
habe den Filter absichtlich recht eng gemacht, weil das die 
Empfindlichkeit steigert. Versuch mal 20kHz höher oder niedriger, also 
zB. 868230 oder 868270. Auch geht der jetzige Code davon aus, dass das 
Telegramm mehr als 9 Byte hat. Wenn der Sensor sonst nichts misst, 
könnte das Telegram auch kürzer sein.

Autor: deminex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hatte mit dem Regensensor bisher keinen Erfolg. Noch etwas mehr Info:
Die Teile werden wohl von Mobil-Alerts designed und anscheinend auf 
unter verschiedenen Labeln verkauft (ELV,Conrad), TFA ist nur ein 
weiterer.
Die IDs der Gerate besteht aus 12 Buchstaben, die ersten beiden geben 
den Typ des Geraets wieder (siehe mehr unter 
https://github.com/sarnau/MMMMobileAlerts/blob/mas...). 
Der dortige Download dekodiert anscheinend die Datentelegramme vom 
Gateway in die Cloud. Es gibt wohl auch eine Menge anderer Sensoren, wie 
Fensterkontakte etc.

Deshalb ist das Telegramm eventuell auch laenger statt kuerzer. Ich habe 
im Quellcode tfaX.cpp im Debug Modus  die Ausgabe so geaendert, dass 
nicht fix n<11, sondern n<=byte_cnt ausgegeben wird. Aber die ID meines 
Sensors kann ich in den BAD Feldern nicht finden. Allerdings scheint es 
verstaerkt laengere Datensaetze zu geben, wenn ich den Sensor bewege. 
Ansonsten hat der wohl auch ein sehr langes Sendeintervall von 2h, in 
denen er dann meldet, dass es keinen kein Niederschlag gegeben hat. Ich 
bin natuerlich auch nicht sicher, ob die Startsequenz immer noch 
dieselbe ist .... .

Die veraenderte Frequenz scheint nicht zu helfen, die Datentelegramme 
bei "manuellem Regen" kommen auch bei der Standard Frequenz an.
Sonst noch Ideen? Danke.

Danke.

Autor: Maik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin, kannst du die Datensätze, die von dem Regenmesser stammen sollen 
veröffentlichen? Vielleicht erkennt ja jemand anderes was in den 
Datensätze.

Gruß
Maik

Autor: deminex (Gast)
Datum:
Angehängte Dateien:
  • wald2 (9,36 KB, 106 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Hallo, habe aktuelle Daten im Anhang, die Device ID ist 0832C158D623. 
Ich bin extra ausserhalb bewohnten Gebietes gefahren, so dass es keine 
anderen Sensoren gab. Daten gab es auch erst ab Bewegen der Sensorwippe 
des Regensensors. Die Frage ist noch, ob evtl. einer der Parameter 
verkehrt ist, d.h. Variation Baudrate oder Kodierungsverfahren, ich 
kenne mich mit Funk nicht aus, lohnt es sich, das Programm noch zu 
aendern, dass mit anderen Baudraten eventuell andere Daten empfangen 
werden, wie bei seriellen Verbindungen? Weil vorher geschrieben, in den 
Daten finde ich die DeviceID nicht. Außerdem nehme ich an, dass Inverted 
Sync auch auf einen falschen Parameter deutet? Wie wuerde man am besten 
andere Baudraten und Kodierungsverfahren in Kombination auswaehlen, ohne 
alles zu probieren, gibt es da ein bestimmtes Vorgehen?
Der Datensatz, der vom Regensensor vom Gateway in die Cloud gesendet 
wird, ist ja auf der Seite des Projektes 
https://github.com/sarnau/MMMMobileAlerts/blob/mas... 
beschrieben, ich gehe mal davon aus, dass der genannte Datensatz, der im 
64Byte Block gesendet wird, mit dem Block im FunK Telegramm identisch 
ist, nur entsprechend kuerzer je nach Sensortyp. Demnach steht die 
Sensorid auch am Anfang.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, sieht aber nicht wirklich sinnvoll aus. Dass da ein scheinbar 
korrekter Sync (2d d4) erkannt wird, kann auch nur mit Rauschen 
vorkommen. Der Triggerlevel wird zur Empfindlichkeitssteigerung so nah 
ans Rauschen rangefahren, dass es so Fehlerkennungen ala Lotto schon mal 
geben kann.

Ich hab das Teil jetzt bestellt und werde mal schauen, was es wirklich 
so rausmorst. Kann aber etwas dauern, gibt noch ein paar grössere 
Projekte...

Autor: Michael (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, vielleicht kann mir jemand kurz helfen.

Momentan binde ich mittels USB-WDE1-2 und Funksensoren(Auslaufmodell) 
Werte in eine in eine RRD-Datenbank ein (Raspberry).
Habe die Hoffnung das ich mein jetziges Rec.-script(angehängt) leicht 
abändern kann und tfrec direkt einbinden kann ?!
wäre nett wenn mir da jemand ein Beispiel geben könnte, ich würde da 
vermutlich Tage mit zubringen.

MfG Michael

Autor: Michael (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, bei mir steigt die tfrec ständig aus, (Ungültiger 
Maschinenbefehl) besonders  -T1 läuft garnicht , fremde Sensoren mit -T2 
kann ich teils empfangen. Jemand ne Idee ?

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Makefile das -g bei PROFILING einkommentieren, make clean; make und 
dann im gdb starten.

gdb --args tfrec -T1
> r

Wenn es aufschlägt, "thread apply all bt"

BTW: was ist das für eine PI-Version? Evtl. stimmt was mit den 
Compiler-Flags nicht ganz...

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Georg, du hast mir sehr geholfen !
wie du wohl schon gemerkt hast bin ich nicht so der Programmierer ,
Es ist ein Raspberry 2B und es lag an den Cflags  , hab jetzt hin und 
her gegoogelt , jetzt sieht es so bei mir aus:

CFLAGS=-O2 -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard 
-ftree-vectorize -ffast-math \
              -std=c++0x -Wall \
              -Wno-unused-function  -Wno-unused-variable 
-Wno-unused-but-set-variable \
              -Wno-write-strings
CXXFLAGS="${CFLAGS}"

jedenfalls funktioniert es jetzt oder hast du noch Vorschläge ?
Nochmals DANKESCHÖN

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg

Erst mal herzlichen Dank für das tolle Tool.
Es wäre toll, wenn auch die Daten eines TX22IT (WS 1600) empfangen 
werden könnten.
Hast du bereits einmal daran gedacht? Würde das theoretisch gehen?
Das Format des TX22IT ist im JeeLink Sketch für LaCrossITPlusReader 
beschrieben.
Man könnte sie so den JeeLink in fhem sparen.

MfG Thomas

Autor: Maik W. (istler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

wenn ich das richtig lese [1][2], dann müssten die Daten ja schon tfrec 
empfangen TFA_2 (17240bit/s) empfangen werden.
Kannst du mal bitte tfrec mit der Option -D starten, dann werden die 
Rohdaten als Hex-Werte aus gegeben. Da sollten dann die Daten [3] von 
deinem TX22IT eigentlich schon zu sehen sein. Die Daten des TX22IT 
müssen immer mit einem 0xA anfangen. Idealerweise sind die ersten drei 
Zeichen einer Meldung 0xa12 oder 0xa38.
Kannst du bitte ein paar dieser Hex-Daten hier posten?

Gruß
Maik


[1] http://www.g-romahn.de/ws1600/
[2] http://fredboboss.free.fr/articles/tx29.php#modulation
[3] http://www.g-romahn.de/ws1600/Datepakete_raw.txt

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, ich bin auf folgendes gestossen:

https://wiki.fhem.de/wiki/JeeLink

...und wenn ich das bei der Liste der unterstützen Sensoren richtig 
lese, hat der TX22 eine Baudrate von 8842 und passt schon mal so zu 
keiner der von tfrec decodierten Baudraten (9600/17240/38400).

Keine Ahnung, was er damit dann sendet, aber man könnte mal in main.cpp 
beim Setup des TFA_2-Demodulators diese Baudrate einsetzen und schauen, 
was rauskommt (TFA_3 hat dasselbe Format nur andere Baudrate).

Also
demods.push_back(new tfa2_demod( tfa2_dec, (1536000/4.0)/17240));
durch
demods.push_back(new tfa2_demod( tfa2_dec, (1536000/4.0)/8842));
ersetzen.

Mit etwas Glück passt der Rest inkl CRC und es kommt schon was 
sinnvolles raus. Ansonsten mal im -D Modus die Pakete ausgeben lassen. 
Evtl sehe ich ja was...

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg, Maik

Zuerst einmal herzlichen Dank für euren Feedback.

@Georg: Habe die Baudrate mal in main.cpp eingetragen und tfrec neu 
kompiliert.
-D zeigt leider nichts Brauchbares (siehe Screenshot im Anhang; nur 
Einträge mit BADx beachten!).

Vielleicht hilft euch die TX22IT.CPP Datei weiter. Hier ist das 
Datenformat beschrieben.

Autor: Maik W. (istler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

kannst du ein Bisschen programmieren?
Das TFA2 erkennt die Pakete am Sync-Paddern 0x2dd4. Bei dem TX22IT soll 
aber das Sync-Padder 0xA lauten, also nur 4 statt 16 Bit.
Debug-Meldungen werden erst ausgegeben, wenn mehr als 7 Byte nach dem 
Sync-Paddern 0x2dd4 empfangen wurden.

Evtl. kannst du das printf in der Funktion tfa2_decoder::store_bit 
einkommentieren und gucken ob aus dem Input was zu erkennen ist. Es ist 
schwierig mit nur einem Nibbel (4 Bit) Sync-Paddern aus dem Bit-Strom 
den richtigen Startpunkt zu finden.
Zeige doch dann mal, was du empfangen hast. Aber es müssen deutlich mehr 
Zeilen sein, als in deinem Screenshot. Und am besten als Text-Datei. 
Jede Ausgabe ist ein Empfangenes Bit.

Gruß
Maik

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das 2dd4 fehlt wohl in der Beschreibung, das a als erstes Nibble in der 
Payload passt schon. Damit sind af 35 xx wohl Pakete vom TX22. Aufgrund 
der Ähnlichkeit der Baudrate 9600 vs 8xxx gibts dann zwei ähnlich 
dekodierte Pakete, wo es einmal einen Bitschieber gibt (03 31 -> 06 43).

Ich schau mal, wie ich das reinbekomme. Aber bitte etwas Geduld, hab 
grad sonst einiges zu tun und ein TFA-Regenmengensensor steht auch noch 
unerkundet rum ;)

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maik

Ich muss mal schauen was ich hin bekomme. Habe meine 
Programmiererfahrung noch aus Zeiten von Hex und Assembler wo Computer 
noch mit Dampf betrieben wurden :-).

Mfg Thomas

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg

Das wäre super. Ich denke tfrec würde so noch genialer :-).

Mfg
Thomas

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maik

Hier der Output von -D mit den von dir vorgeschlagenen Änderungen. Und 
diesmal als Textfile :-).

MfG Thomas

Autor: Istler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
das war gar nicht mehr nötig. Georg hatte gesagt, dass für den TX22 auch 
das Sync-Paddern 0x2dd4 gilt. Und das 0xa schon bereits in deinem ersten 
Output enthalten war (die "Bad RSSI" Einträge).
Gruß
Maik

Autor: Maik W. (istler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

kannst du irgendwo ablesen, was dein Sensor misst? Kann es bei deinem 
Dump 26,3 °C gewesen sein?
Die Funktion tfa2_decoder::flush gibt nur 7 Bytes aus, deshalb sind die 
Meldungen von deinem TX22 nicht vollständig in der Ausgabe. Maximal 
könnte die Meldung 13 Byte lang sein.
In der Zeile 55 steht der Kopf einer For-Schleife: for(int n=0;n<7;n++)
Kannst du mal statt der 7 eine 13 hinein schreiben. Dann wird zwar bei 
kürzen Paketen misst aus gegeben, aber dann sind auf jeden Fall die TX22 
Meldungen vollständig im Ausgabe.
Du kannst dann ja nochmal den Output posten.

Gruß
Maik

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maik

Die 26,3 °C sind vermutlich nicht korrekt. Es sollte so um 22 °C sein.
Ich hatte allerdings der Regen- und Windmesser nicht am TX22IT 
angeschlossen. Ich weiss daher nicht was der TX22 dann macht.
Sende dir wie gewünscht nun einen Output mit angeschlossen Regen- und 
Windmesern. An der Bassisstation wurden folgende Werte angezeigt: 
24,2°C; 1013hPa, 45%RH, 0,0Wind. Es werden im Vollbetrieb auch noch die 
Windrichtung sowie Böhen angegeben. Auf dem Schreibtisch findet halt nur 
"einfaches" Wetter statt :-).

MfG Thomas

Autor: Maik W. (istler)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

ich hatte ich mich verzählt, bzw. das Sync-Paddern 0x2dd4 nicht mit 
gezählt gehabt, deshalb fehlen jetzt bei deiner Ausgabe der letzte Wert 
und die Prüfsumme.
In deinem Trace waren wohl 9 Datenpakete von deinem TX22, davon waren 5 
Pakete korrekt empfangen:
Temperatur: 24,3 °C
Luftfeuchte: 45 %
Regen: 0
Wind: 0m/s 292,5°

Da lässt sich also was machen! :-)

Gruß
Maik

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maik

Korrekt, das habe ich auch bemerkt. Ich habe zwischenzeitlich auch ein 
bisschen mit meinen rudimentären C-Kenntnissen weiter "gefrickelt" :-). 
Das Resultat siehst du im Output im angehängten File (Darstellung im txt 
File nicht so optimal). Es scheint also grundsätzlich zu gehen. CRC 
Berechnung ist noch falsch. Wenn ich Zeit habe, versuche ich mal den 
Code aus dem fhem LaCrosseITPlusReader in tfrec zu integrieren oder 
einer von euch Profis macht das ;-). Ich denke das wertet tfrec nochmals 
auf, zumal man damit relativ einfach mit fhem und Homematic CCU2 einiges 
machen kann.

MfG Thomas

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

nachdem ich seit Jahren eine Klimalog Station mit 8 Sensoren betreibe 
wollte ich jetzt eine bessere Auswertung durchführen.

Ich habe das tfrec auf meinem Raspi zum laufen gebraucht und der Empfang 
der Sensoren geht auch.

Jetzt würde ich gern die weitere Auswertung in python durchführen.

Kennt jemand von Euch eine einfache Möglichekeit, die Sensorwerte 
einfach dort einzulesen?

Gruß
Thorsten

Autor: Maik W. (istler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thorsten,

du kannst tfrec beim Starten eine Programm mitgeben, dass bei jedem 
Emfpang aufgerufen werden soll:
-e <exec>   : Executable to be called for every message (try echo)
z. B.:
tfrec -e pushvals

Das Programm 'pushvals' verarbeitet dann die empfangenen Sensorwerte und 
könnte ein Phyton-Skript sein.

Gruß
Maik

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maik,
vielen dank für deine schnelle Antwort.

Das Skript, an das ich übergeben möchte, läuft selbständig, 
dementsprechend wollte ich die Werte auf eine andere Art übergeben.

Ich habe jetzt mal einen fifo angelegt und tfrec so aufgerufen:

tfrec -T 1 > myfifo &

Das Auslesen der Daten aus dem Fifo in meinem python script funktioniert 
schon.

Allerdings ist der fifo doch blocking, hast du eine Ahnung, was tfrec 
macht, wenn ich es nicht so häufig aus dem Fifo hole?

Oder sind die Wert dann nicht mehr aktuell?

Gruß
Thorsten

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ein Fifo per mkfifo hat typischerweise 4KB. Da muss schon einiges 
zusammenkommen, dass die Ausgabe blockiert... Wenn das passiert, kann es 
es sein, dass einige Werte verloren gehen. Aber die Werte von den 
Sensoren kommen alle 10s, kann nicht so schlimm sein.

Ansonsten könntest du ja noch die "Sammelvariante" mit Abbruchzeit 
benutzen (zB. '-m 1 -w 60').

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum WeatherHub-Regensensor 30.3306.02: Ich habe jetzt nach recht 
mühevollem Reverse-Engineering immerhin die rohen Telegramme 
rausbekommen. Das Ding ist total anders als alle anderen Sensoren.

Zum einen sendet es mit jedem Wippen 16mal 5Byte-Telegramme im 
Zickzack-Frequenzsprungverfahren mit 4000bit/s. Das scheint kompatibel 
zu irgendwas Uraltem zu sein. Die Infos sind immer dieselben, mit der 
aufgedruckten ID hat das auch nichts zu tun. Wenn man einen Puls 
verpennt, hat es weniger geregnet, bei einem anderen Sensor in der 
Umgebung doppelt soviel ;)

Es gibt aber dahinter nochmal zwei identische, recht lange Telegramme 
mit 6000bits/s, an denen ich mir jetzt doch länger die Zähne ausgebissen 
habe. Aber irgendwann gings dann doch. Es ist PSK-moduliert mit NRZM 
und mit G3RUH-Scrambling, deswegen sieht man da erstmal gar nichts 
Sinnvolles. Es stecken in 41 Bytes dann die 6 Byte ID, ein Counter der 
Wipp-Impulse und sogar eine History der Zeitabstände der letzten Pulse 
drin.

Allerdings habe ich noch nicht rausgefunden, mit welcher CRC das 
geschützt ist. Sieht nach einer CRC32 aus, aber da gibts viele 
Möglichkeiten...

Desweiteren habe ich eben nur den Regensensor. Das Protokoll scheint 
recht universell, daher wären andere WeaterHub-Typen hilfreich. Bevor 
ich mir da jetzt ein paar leiste (Wind, Türsensoren und Temp/Hygro gäbs 
noch in nicht-wirklich-billig): *Hat jemand hier was anderes aus der 
Serie*? Dann könnte ich den rohen Telegramm-Dumper schon mal ins git 
stellen und evtl. sieht man mehr vom Format...

: Bearbeitet durch User
Autor: deminex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe bisher keine weiteren WeatherHub Geraete, werde mich mal 
umsehen was am besten passt und dann kaufen. Ich nehme an ein zweiter 
Regensensor hilft nicht, ist die ID ausserhalb des CRC?

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit der CRC finde ich schon noch, gibt algorithmische Möglichkeiten, 
das auszuknobeln, muss mich da etwas einarbeiten. Eine "echte" CRC ist 
es aber, das lässt sich anhand einiger spezieller Eigenschaften 
nachweisen. Die ID ist auch offensichtlich.

Es geht eher um die Füllung der anderen ~30 Bytes bei den verschiedenen 
Sensor-Typen und wie man erkennt, was was ist. Da habe ich bislang nur 
Vermutungen. Muss mal in mich gehen, was ich mir leisten will. Aber 
mehrere Exemplare sind immer gut fürs Reverse-Engineering ;)

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<offtopic> CRC erledigt dank einem schönen Reverse-Engineering-Tool:

http://reveng.sourceforge.net/

Die Doku ist zwar etwas kryptisch, aber das Tool findet per Brute-Force 
alles raus, was man so braucht... Hat keine Minute gedauert :) Es ist 
zwar ein Standard-Polynom, aber ein sehr krummer-Init-Wert.

Autor: deminex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, habe ein Set Tuersensoren bestellt. Sollen Anfang naechster Woche da 
sein. Kann dann Daten sammeln und schicken. Es gibt (fuer mich) 
interessantere Geraete, die bereits angekuendigt werden, aber noch nicht 
verfuegbar.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ein paar Sachen committed:

Support für TX22 (so halb fertig, aber nur trocken getestet)

Muss mit mit "-T 8" angeschaltet werden. Da neben Temperatur (temp) und 
Luftfeuchtigkeit (hum) auch noch Wind&Co rauskommen und auch temp+hum 
getrennt gesendet wird, codiert die ID beim TX22 die neuen Werte des 
Ausgabestrings:

300bccd

cc ist die ID des Sensors
d=0 temp (hum ist immer 0)
d=1 hum (temp ist immer 0)
d=2 Regenzähler (12Bit), Menge pro Kipper müsste man ausmessen...
d=3 temp=Windgeschwindigkeit (m/s), hum=Windrichtung (Grad)
d=4 temp=Böengeschwindigkeit (m/s), hum=0

Keine Ahnung, ob das wirklich so geht, hab keinen TX22 ;) Auf jeden Fall 
wären rohe Telegramme aus dem echten Leben (mit -D) sehr hilfreich.

Reverse-Engineering-Support für WeatherHub :

Muss mit "-D -T 20" angeschaltet werden und wirft nur die rohen 
Telegramme aus. Bei meinem Regensensor sieht das so aus:
4b 2d d4 2b 25 08 33 c2 70 80 f1 40 a5 00 c6 00 86 c0 00 ... 
<--SYNC--?> |  <-----ID--------> TV VV  <-->    ??       
            Länge?               Typ/value |Temp

... cd 63 c0 0a c0 53 c0 0e c0 1a e6 ea c2 2c 84 89 c0 01 66 90 a5 2b
    <---- Zeitdifferenz zu letzten Pulsen---------------> <--CRC---->

Der Value-Wert ist beim Regensensor einfach ein Zähler pro Wippenkipper 
(=250ml/m^2, vermutlich 11 oder 12 bit). Die Temperatur ist 
11Bit-Zweierkomplement in 0.1Grad, aber recht rauschig, da die wohl 
direkt im Prozessor gemessen wird. Der Rest ist eine History der Zeiten 
der letzten Kipper, vermutlich damit man einfach die l/h hochrechnen 
kann.

Die ID ist die, die auch als QR-Code aufgedruckt ist. Das 
WeatherHub-System ist halt der übliche Cloud-Wahnsinn, wo die Sensoren 
weltweit eindeutig sind und das Gateway die Werte nur in die Cloud 
hochlädt und die App das anhand der ID wieder runter...

Ich habe noch keine Ahnung, wie Format das bei anderen Sensortypen aus 
der Serie aussieht. Insbesondere weiss ich nicht, ob die Telegramme 
immer gleich lang sind (die 0x25 passt zur Länge, also wären andere 
Längen möglich), ob das 2b noch zum RF-Sync gehört oder schon den 
Sensortyp codiert, etc. Also immer her mit den Telegrammen :)

: Bearbeitet durch User
Autor: deminex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das WeatherHub Format sieht so aus als ob der in die Cloud transferierte 
Datenblock mit dem per Funk gesendete Datenblock uebereinstimmt, 
zumindest im Header (Siehe 
https://github.com/sarnau/MMMMobileAlerts/blob/mas...)

Im Anhang der Datensatz eines Regensensors und eines Tuersensors, in den 
Dateien die IDs der Sensoren.

Demnach ist beim Regensensor 25 die Laenge des Pakets (immer gleich beim 
Regensensor) und die ID beim Regensensor beginnt immer mit 08, beim 
Tuerkontakt ist die Paketlaenge immer 17, die ID beginnt immer mit 10.

Uebereinstimmung mit der Beschreibung im Datenblock muss ich mir noch 
genauer ansehen. Aber anscheinend liefern fast alle Sensoren auch noch 
eine Temperatur mir.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, super... Hätte mich ja gewundert, wenn das auf LAN-Seite noch keiner 
angeschaut hätte ;)

Zur Beschreibung des Regensensors: Wippe links/rechts gibts IMO nicht, 
weil bei mir der Reedkontakt immer nur beim Wippen selbst geschlossen 
wird. D.h. man weiss nicht, wo die Wippe eigentlich ist. Hab da als 
oberstes Nibble ausser 4 (Wipp-Event) oder 0 (Timeout/Repeat) noch nie 
was anderes gesehen.
Das Word nach dem Wipp-Counter scheint die Zeit "ohne Events" zu sein. 
Die zählt nur bei den Timeout-Repeats hoch, ansonsten ist sie immer 
c000. Sie geht auch nicht in die Event-History danach ein, da zählen 
wohl wirklich nur Wipp-Ereignisse und nicht die Wiederholungen.

Auf dem Regensensor sieht man ganz gut, dass die Temperatur 
offensichtlich direkt in der CPU gemessen wird, es gibt nichts auf der 
Platine, was das sonst könnte. Kältespray auf den Blob der CPU lässt das 
auch sofort reagieren. Deswegen wird das auch nicht allzu genau sein.

Jetzt kann ich mir mal überlegen, wie man den Kram in tfrec reinbekommt. 
Die bisherige Art der Übergabe von Temperatur und Luftfeuchtigkeit ist 
bei der Vielzahl der jetzt möglichen Werte irgendwie etwas 
unterdimensioniert...

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg

Anbei ein paar TX22 original Daten zum Testen mit deinem neuen Code 
(TX22 ohne angeschlossen Wind- und Regensensor!).
Zwischenzeitlich habe ich auch etwas selber "herumgebastelt" und auf 
Basis deines Codes die TX22 Daten auseinander genommen.
Bitte verzeih den Code. Ist alles mit Try & Error entstanden. Vielleicht 
kannst du das Eine oder Andere daraus bezüglich Werte-Berechnung 
verwenden.
Basis ist der Code von JeeLink-LaCrossITPLusReader.
Bei mir wurden jedenfalls alle Werte korrekt angezeigt.
Ich erhalte nur relativ viele CRC-Fehler.

Mfg
Thomas

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg

Kann es sein, dass in der Routine "tfa2_decoder::flush_tx22" die CRC 
Berechnung nicht korrekt ist?
Ich erhielt keine korrekten Ausgaben. Die crc_val und crc_calc sind 
nicht identisch.
Habe daher folgende Zeilen angepasst:
crc_val=rdata[2*num+4]; (original +6)
crc_calc=calc->calc(&rdata[2],2+2*num); (original 3+2*num)
Nun sind crc_val und crc_calc identisch.

Hast du das Datenmodell bewusst nicht für den TX22 ergänzt? Du schreibst 
alle berechneten Daten in sd.temp.

Habe dir meine angepasste tfa2.cpp angehängt sowie das ergänzte 
Datenmodell.
So erhalte ich einen korrekten Output aller Messwerte des TX22.

Was mir beim spielen mit meinem TX22 aufgefallen ist, dass er einen 
relativ grossen Frequenz-Offset hat. (meiner arbeitet auf 868.225 MHz). 
Wenn man dann noch andere Sensoren gleichzeitig lesen möchte, welche auf 
868.250 MHz arbeiten gibt es viele Auslesefehler.

Mfg
Thomas

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> Hast du das Datenmodell bewusst nicht für den TX22 ergänzt?

Ich habe genau diese Zeile nach Indien outgesourced ;)

Ich korrigiere das, der WeatherHub-Kram bekommt auch ein grösseres 
Update (Regen-, Wind-, Fenster- und Temperatursensoren sind jetzt 
durch.).

> Was mir beim spielen mit meinem TX22 aufgefallen ist, dass er einen
> relativ grossen Frequenz-Offset hat. (meiner arbeitet auf 868.225 MHz).
> Wenn man dann noch andere Sensoren gleichzeitig lesen möchte, welche auf
> 868.250 MHz arbeiten gibt es viele Auslesefehler.

Das ist das Problem des engen Filters. Gut für die Empfindlichkeit (der 
SDR-Stick ist jetzt ja nicht so der Knaller beim Rauschen), leider 
schlecht für Sender mit Gummi-Quarzen bzw. absichtlichen Offsets. Eine 
Option für einen breiteren Eingangsfilter müsste eigentlich drin sein.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, alles neu macht der Mai:

- WeatherHub-Support für 5 Sensortypen ist jetzt drin (Temp+Hum, 
Temp+Hum+Wetness, Rain, Wind, Door)
- TX22 sollte jetzt passen (neues Spiel, neues Glück...)
- Breiterer Filter mit -W, toleriert grössere Frequenzoffsets

BTW: WeatherHub/TX22 müssen explizit angeschaltet werden (-T 20 bzw 8).

Thomas schrieb:
> Hast du das Datenmodell bewusst nicht für den TX22 ergänzt?

Ah, hab ich falsch verstanden. Ja, das war Absicht, weil ich das 
Aufrufformat des Handlers nicht ändern wollte. Stattdessen gibt es 
Subtypen als letztes Nibble der ID (wie schon bei den Sensoren mit zwei 
Temperaturen) und die anderen Werte werden auf Temperatur und 
Feuchtigkeit verteilt. Dasselbe Prinzip wird jetzt auch bei den 
WeatherHubs benutzt. Damit kann ein Datenpaket vom Sensor mehrere 
Handleraufrufe mit mehreren IDs triggern.

Zum WeatherHub: Es gibt immer noch das Problem, dass ich noch nicht 
rausgefunden habe, wie der Typ-abhänge CRC-Init-Wert ausgewürfelt wird. 
D.h. neue Typen (zB. die Technoline-MobilerAlerts-Geräte) gehen nur, 
wenn ich ein paar Raw-Messages dazu habe. Einen Temp+Hum-Sensor habe ich 
bei mir in der Nachbarschaft schwach "gehört", daher geht der jetzt auch 
;)

Beim Regensensor kommt nur der rohe Counter raus, der natürlich auch mal 
einen Wraparound haben kann. Daher muss man das noch extern 
nachbearbeiten, 1 Counter-Tick sind ca 0.25mm/m^2.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg

Kam erst jetzt dazu deinen neuen Code für TX22 zu testen. Leider nicht 
erfolgreich. Es werden keine gültigen Daten ausgegeben.
Fehlermeldung, aufgrund falschem CRC-Vergleich, es wird eine falsche 
Frame-Länge angezeigt.
Ich habe deine Methode, wie du die Framelänge bestimmst (noch) nicht 
durchschaut. Du weisst, der TX22 verwendet eine variable Frame-Länge, 
welche der TX22 mitliefert (Anzahl Nibbles in rdata[3]). Nach ca. 5h 
sendet der TX22 nicht mehr alle Sensordaten mit.

Mfg
Thomas

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achje, kommt davon, wenn man sich nur alles ohne Tests 
zusammenfantasiert. Ich schau noch mal drauf und versuche, die 
Telegramme von oben irgendwie einzuspeisen.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> Nach ca. 5h sendet der TX22 nicht mehr alle Sensordaten mit.

Ich habe das jetzt mal simuliert, finde aber keinen offensichtlichen 
Fehler. Mit den kürzeren Demo-Paketen von 
http://www.g-romahn.de/ws1600/Datepakete_raw.txt passt eigentlich alles, 
die CRC wird schon richtig extrahiert.

Kannst du mal ein paar rohe Frames posten (nur -T 8 -DD)? Ich habe den 
Verdacht, dass evtl. schon die Bits selbst aufgrund der (krummen) 
Datenrate falsch demoduliert werden. Der Teil ist so gefühlt noch wenig 
tolerant.

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg

Sorry dass es so lange gedauert hat.
Hier wie gewünscht der Dump. Hoffe die Anzahl reicht.
Die Länge des Frames (byte_cnt) ist nicht korrekt.

Mfg
Thomas

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke... Aber ich glaube, das es da schon falsch empfangen wird. 
Irgendwie sind die Telegramme zu kurz für 5 Werte und sie sind auch so 
nicht stimmig, zB.

#001 1527281284  2d d4 a8 35 06 62 10 48 21 fc 83 c0 00
#002 1527281288  2d d4 a8 35 06 62 10 47 21 fc 83 c0 00

Da ändert sich ein Wert mittendrin (48->47) und der Rest bleibt gleich? 
Kann so nicht sein... Der Frequenzoffset ist da auch schon grenzwertig. 
Versuch mal mit -W den breiteren Filter oder manuelle Frequenzeingabe.

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ändert sich leider nichts. Die Telegramme sind immer zu kurz (meistens 
13 Bytes).

Im Anhang habe dir als Beispiel ein Dump von der "alten" Version 
angehängt, welche ich seinerzeit modifiziert hatte. Die Telegramme 
sollten in den ersten 5h 18 Bytes lang sein.
Ich konnte in deinem neuen Code auch nicht erkennen, wo Problem 
entsteht.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vermutlich ist der Timeout an der Grenze, sonst würden die Pakete nicht 
so abgewürgt aussehen. Setz mal in tfa2_demod::demod das 
"timeout_cnt=16*spb" auf 32*spb.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat leider auch nicht geholfen.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mir jetzt auch so einen ominösen TX22 angeschafft... Das Problem war 
ein zu scharfer Check auf zuviele 0-Bits. Sowas gabs bei den anderen 
Sensoren nicht... Deswegen wurden diese Bereiche ignoriert, die 
Telegramme verkürzt und damit ruiniert. Jetzt sollte es gehen.

Autor: Thomas Nick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin leider erste jetzt dazu gekommen die neue Version zu testen. Scheint 
aber jetzt zu funktionieren :-). Herzlichen Dank für deine Hilfe.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.