mikrocontroller.net

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


Autor: Georg A. (georga)
Datum:

Bewertung
2 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 Mueller (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 Mueller (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 Mueller (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)

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.