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
http://www.ebay.de/itm/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.
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
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...
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!
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.
> 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.
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;
}
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.
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;)
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. :)
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.
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...
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...
@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
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=<sensorid>"; 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.
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.
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:
- 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?
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.
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
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
1
&&((rdata[7]&0x70)==0x60
Wenn ich diesen UND-Teile Auskommentiere oder mit 1 verodere, dann
erhalte ich folgenden Output:
1
#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
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.
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
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.
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.
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.
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.
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
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 ;)
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
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).
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.
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.
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.
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/master/MobileAlertsDevices.markdown).
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.
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
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/master/MobileAlertsDevices.markdown
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.
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...
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
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 ?
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...
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
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
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
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...
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.
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
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 ;)
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
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
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
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
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
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
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
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
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').
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...
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?
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 ;)
<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.
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.
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:
<---- 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 :)
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/master/MobileAlertsGatewayBinaryUpload.markdown)
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.
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...
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
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
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.
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.
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
Achje, kommt davon, wenn man sich nur alles ohne Tests
zusammenfantasiert. Ich schau noch mal drauf und versuche, die
Telegramme von oben irgendwie einzuspeisen.
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.
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
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.
Ä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.
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.
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.
Hallo,
zuerst mal danke für tfrec, das ist wirklich genial!
Ich hab mir vor gut einem Jahr die TFA Klima Home (30.3060.01) geholt,
die mir als gute Lösung erschien (Preisgünstig, 3 externe Sensoren schon
dabei, und eine relative schöne Station die auch gleichzeitig die Werte
von allen 3 Sensoren und den von der Station anzeigt).
Die dabei mitgelieferten Sensoren sind 30.3180.IT womit mir klar war,
dass ich die mit tfrec lesen kann.
Das ganze hat auch dann recht gut funktioniert. Leider hat sich jetzt
vor kurzem einer der externen Sensoren verabschiedet und TFA hat mich an
amazon wegen Tausch verwiesen.
Die haben mir auch brav ein komplett neues Set geliefert. Ich kann von
diesem jetzt aber keine Werte empfangen mit tfrec.
Die neuen Sensoren sind auch von der gleichen Type 30.3180.IT haben aber
in neueres Datum (11/2017 statt 02/2017) darunter steht dann V026 C2
statt V022 C2.
Die alte Basisstation kann die Daten von den neuen Sensoren auch
empfangen (die neue Basistation war schon defekt angekommen), sodass
sich davon ausgehen, dass sich nichts grundsätzlich geändert hat.
Auch wenn ich tfrec mit -D oder -DDD aufrufe sehe ich von den neuen
Sensoren nicht, die Daten der alten Sensoren kommen aber an, auch ein
anderer Sensor (wohl von einem Nachbar) taucht auf.
Was kann es da haben?
Aja und noch einen Nebenbaustelle: Die Basisstation kann ja TFA
WeatherHub, die würde so auch die Daten von allen externen Sensoren und
auch den internen Sensor raussenden.
Die Daten sehe ich mit tfrec auch, können aber wohl nicht ausgewertet
werden:
tfrec -D -T 20 -W
Registering demod for TFA_WHB sensors, 6000 bit/s
WHB: Samples per bit: 64.0
Wide filter
Found Rafael Micro R820T tuner
AUTO GAIN
Frequency 868.2500MHz
Samplerate 1536000
START READ THREAD
#000 1539205083 L=56 4b 2d d4 2b 2e 11 7a dd af 2f f6 05 d0 00 72 08 4e
00 ca 08 34 00 83 08 4b 00 d3 08 34 00 73 08 4d 00 cb 08 34 00 84 08 4b
00 d3 08 34 1a 29 3c 63 35 00 00 00 96 69 01 RSSI 87 WHB: Probably
unsupported sensor type 11! Please report
WHB BAD 1 RSSI 87 (SANITY)
#001 1539205083 L=56 4b 2d d4 2b 2e 11 7a dd af 2f f6 05 d0 00 72 08 4e
00 ca 08 34 00 83 08 4b 00 d3 08 34 00 73 08 4d 00 cb 08 34 00 84 08 4b
00 d3 08 34 1a 29 3c 63 35 00 00 00 96 69 01 RSSI 87 WHB: Probably
unsupported sensor type 11! Please report
WHB BAD 2 RSSI 87 (SANITY)
#002 1539205083 L=56 4b 2d d4 2b 2e 11 7a dd af 2f f6 05 d0 00 72 08 4e
00 ca 08 34 00 83 08 4b 00 d3 08 34 00 73 08 4d 00 cb 08 34 00 84 08 4b
00 d3 08 34 1a 29 3c 63 35 00 00 00 96 69 01 RSSI 87 WHB: Probably
unsupported sensor type 11! Please report
WHB BAD 3 RSSI 87 (SANITY)
#003 1539205083 L=56 4b 2d d4 2b 2e 11 7a dd af 2f f6 05 d0 00 72 08 4e
00 ca 08 34 00 83 08 4b 00 d3 08 34 00 73 08 4d 00 cb 08 34 00 84 08 4b
00 d3 08 34 1a 29 3c 63 35 00 00 00 96 69 01 RSSI 87 WHB: Probably
unsupported sensor type 11! Please report
WHB BAD 4 RSSI 87 (SANITY)
Was kann ich denn machen, damit die neuen Sensoren funktionieren?
Vielen Dank schon im Voraus
Chris
> Was kann es da haben?
Möglicherweise ist die Mittenfrequenz zu weit weg. Versuch mal -f 868200
oder 868300, evtl. auch -W. Ich hab halt die Filter relativ eng gemacht,
damit ist die Empfindlichkeit IMO deutlich besser als die Basisstation.
> Was kann ich denn machen, damit die neuen Sensoren funktionieren?
Ich brauche drei unterschiedliche Messages, die vier oben sind alles
Wiederholungen und daher identisch. Da steckt ein Typ-abhängiger
Startwert einer CRC drin, wo ich noch nicht rausbekommen habe, wie er
entsteht (ausgewürfelt oder basierend auf irgendeinem Algorithmus).
Daher muss das per Brute-Force ausgerechnet werden.
Hallo Georg,
danke für die schnelle Antwort!
Das mit dem Anpassen der Frequenz hat funktioniert, ich hab die noch
etwas weiter erhöht auf 868350 weil bei 868300 gab es fehlerhafte
Pakete.
Wegen dem Weatherhub hab ich jetzt tfrec mal ca eine Stunde raufen
gelassen. Der Output ist im Anhang.
Danke
Chris
Danke, hab den CRC-Startwert schon. Muss mir jetzt nur noch überlegen,
wie ich für die 5 Werte aus dem Paket eine eindeutige ID erzeuge.
Das mit der anderen Frequenz bei den neuen Sensoren ist interessant, da
bräuchte es wohl ein automatisches Frequenzhopping, wenn man alte und
neue zusammen benutzt. Oder paralleles Dekodieren mit unterschiedlichen
Filtern, das kostet aber CPU...
Die WeatherHub-Stationen 30.3060.01 ("Coloris") und 35.1147.01
("Klima@Home") werden jetzt auch unterstützt. Die internen Werte haben
als ID-Nibble die 0, der Outdoor-Wert bzw. die Werte der drei anderen
Sensoren c bis e. Beispiel ist im Readme.
Hallo Georg,
zuerst mal vielen Dank für die tolle Arbeit.
Leider habe ich aber ein Problem...
Ich habe die TFA 30.3180.IT im Einsatz. Sie liefern auch brav Werte.
Allerdings habe ich im Sekundentakt folgende Fehlermeldung:
Dec 26 11:29:53 raspberrypi run-tfrec.sh[10879]: Warning: Unable to
locate configuration directory, default config not loaded.
Dec 26 11:29:53 raspberrypi run-tfrec.sh[10879]: Warning: Unable to
locate configuration directory, default config not loaded.
Dec 26 11:29:54 raspberrypi run-tfrec.sh[10879]: Warning: Unable to
locate configuration directory, default config not loaded.
Die Installation habe ich nach Anleitung von Christian gemacht.
(https://github.com/git-developer/fhem-examples/wiki/Temperatur-Feuchte-Sender-mit-tfrec-und-MQTT)
Auf der Kommandozeile kommt keinerlei Fehler.
Nur beim Start über das Script kommen die Fehler.
Das Config File ist eindeutig hinterlegt, Rechte 0777.
Kann irgendwo in der Source noch ein Verweis sein, der Schwierigkeiten
macht?
Vielen Dank
Andi
also HOME ist für den ausführenden User "mosquitto" gesetzt:
HOME=/var/lib/mosquitto
...wobei das Verzeichnis schon etwas eigenartig ist.
Wurde aber bei der Installation so angelegt/festgelegt.
Habe den user "mosquitto" nun mal probehalber in die root Gruppe
geschoben.
Mal sehen was passiert...
Andi G. schrieb:> Habe den user "mosquitto" nun mal probehalber in die root Gruppe> geschoben.> Mal sehen was passiert...
Leider kein Erfolg.
Immer noch die Fehlermeldungen.
Ich werde jetzt mal das Home Verzeichnis verschieben (Inhalt kopieren
nach /home/mosquitto; home variable beim user mosquitto ändern von
/var/lib/mosquitto nach /home/mosquitto)
(...blindes rumstochern, da ich es wie Christian schon schrieb, auch
nicht verstehe...)
Hab keine Ahnung von Mosquitto, aber du könntest rausfinden, wonach da
eigentlich gesucht wird, indem man da ein Helper-Skript für den Client
dazwischenschaltet, so ala
#!/bin/bash
strace -o /tmp/dbg.txt <client.exe> $*
Das Skript könnte man dann auch nutzen um das passende Environment zu
schaffen...
Hallo Georg,
anbei nun das strace log vom tfrec Aufruf.
Ich bin kein Spezialist, aber sieht mir nach einem Speicherthema aus.
Im mosquitto client_shared.c
(https://github.com/eclipse/mosquitto/blob/0cca732c816b6aa47e907a19e21656dd419f6dc5/client/client_shared.c#L204),
ab Zeile 204 wird die HOME Varible oder die XDG_CONFIG_HOME Variable
ausgelesen und dann per malloc damit Speicher reserviert/allokiert
(soweit ich richtig verstehe). - Danke nochmal an Christian für den
Hinweis, wo die Meldung herkommt.
1
#ifndef WIN32
2
env=getenv("XDG_CONFIG_HOME");
3
if(env){
4
len=strlen(env)+strlen("/mosquitto_pub")+1;
5
loc=malloc(len);
6
if(!loc){
7
fprintf(stderr,"Error: Out of memory.\n");
8
return1;
Wenn alle Abfragen fehlschlagen, kommt es zu der Fehlermeldung:
"Warning: Unable to locate configuration directory, default config not
loaded."
(Zeile 235):
1
}else{
2
fprintf(stderr,"Warning: Unable to locate configuration directory, default config not loaded.\n");
3
}
Das strace log liefert unmittelbar vor der Warnmeldung die dazu
passenden Aufrufe:
1
brk(NULL) = 0x1dbe000
2
brk(0x1ddf000) = 0x1ddf000
3
write(2, "Warning: Unable to locate config"..., 78) = 78
googlen nach brk(NULL) liefert das hier:
https://unix.stackexchange.com/questions/464974/why-execve-and-brknull-are-always-the-first-two-system-calls
Dazu passt auch ein weiteres Problem, das bei mir nach einiger Zeit
auftaucht. (Ich hatte das bisher so nicht im Zusammenhang gesehen.)
Zitat aus dem Beitrag:
In Linux a new process is created via fork()
Nach etwas mehr als einem Tag erhalte ich Fehlermeldungen im
Zusammenhang mit "fork":
1
Cannot fork: Cannot allocate memory
(im selben Sekundentakt, wie die Warnmeldungen...)
Es scheint also erheblich komplizierter zu sein, als zunächst gedacht...
Andi G. schrieb:> Ich bin kein Spezialist, aber sieht mir nach einem Speicherthema aus.
Das glaube ich nicht.
> Wenn alle Abfragen fehlschlagen, kommt es zu der Fehlermeldung:> "Warning: Unable to locate configuration directory, default config not> loaded."
Nein. Nur wenn die Umgebungsvariable 'HOME' nicht gesetzt ist, wird die
Meldung ausgegeben. Andernfalls wird die Zeichenkette
"$HOME/.config/mosquitto_pub" auf die Variable 'loc' geschrieben.
Schlägt das fehl, wird die Meldung "Out of memory." ausgegeben. Das
scheint bei Dir aber nicht der Fall zu sein.
Ich denke, dass die Umgebungsvariable 'HOME' beim Aufruf von
'mosquitto_pub' nicht (oder nicht wirksam) gesetzt ist. Ihr Wert ist
übrigens völlig egal, und auch, ob sie auf ein existierendes Verzeichnis
verweist.
Der Aufruf von 'exec' im Skript 'run-tfrec.sh' führt dazu, das ein neuer
Prozess gestartet wird. Vielleicht erbt dieser neue Prozess auf Deinem
System nicht die Umgebungsvariablen vom Elternprozess.
Idee 1: Probier mal, die Variable 'HOME' explizit in
'publish-tfrec-to-mqtt.sh' zu setzen:
Ich nutze mosquitto auf zwei verschiedenen Raspberry Pi 3 Model B (auch
unabhängig von tfrec).
Auf dem ersten läuft Raspbian Jessie (Kernel 4.9.35-v7+,
mosquitto-clients 1.3.4-2+deb8u3). Dort läuft alles wie es soll.
Auf dem zweiten läuft Raspbian Stretch (Kernel 4.14.78-2-osmc,
mosquitto-clients 1.4.10-3+deb9u2). Dort muss ich in dem Skript, das
'mosquitto_pub' aufruft, 'HOME' explizit setzen, ansonsten erhalte ich
die von Dir beschriebenen Meldungen:
1
MQTT_TOPIC_PREFIX=...
2
MQTT_BROKER_HOSTNAME=...
3
export HOME="${HOME:-/dev/null}"
Dieses Skript wird übrigens von einem systemd-Service aufgerufen, also
vermutlich auch ein geforkter Prozess.
Das sollte also Dein Problem beheben. Es bleibt aber interessant, warum
'HOME' manchmal nicht gesetzt wird.
Andi G. schrieb:> anbei nun das strace log vom tfrec Aufruf.
Nur der Vollständigkeit halber: strace hilft bei "harten" Problemen
(Libs, Permissions, Sockets, File-I/O, etc.). Wenn das nichts bringt und
auf die Schnelle auch kein Debugger bzw. Binary mit
Debug-Info/Sourcecode da ist, kann man auch noch ltrace versuchen, damit
bekommt man alle Library-Calls mit , insbesondere die der C-Lib. Da
würde dann vermutlich der fehlgeschlagene getenv auffallen. Ist halt nur
deutlich mehr an Ausgabekram, denn man anschauen muss. strace/ltrace
gehen übrigens auch auf schon laufende Programme (-p <pid>).
Wollte es nur mal gesagt haben ;)
Christian X. schrieb:>> Wenn alle Abfragen fehlschlagen, kommt es zu der Fehlermeldung:>> "Warning: Unable to locate configuration directory, default config not>> loaded.">> Nein. Nur wenn die Umgebungsvariable 'HOME' nicht gesetzt ist, wird die> Meldung ausgegeben. Andernfalls wird die Zeichenkette> "$HOME/.config/mosquitto_pub" auf die Variable 'loc' geschrieben.
Da habe ich mich wohl falsch ausgedrückt.
Ich meinte natürlich schon, so wie Du das beschreibst, dass eben die
HOME Variable nirgends gefunden wird....
Sorry.
Christian X. schrieb:> Idee 1: Probier mal, die Variable 'HOME' explizit in> 'publish-tfrec-to-mqtt.sh' zu> setzen:MQTT_TOPIC_PREFIX=devices/tfa/30.3180.it> MQTT_BROKER_HOSTNAME=localhost> HOME=/var/lib/mosquitto
habe ich so ausprobiert...ging aber nicht...
Aber zum Glück habe ich Deinen 2. Post gelesen:
Christian X. schrieb:> export HOME="${HOME:-/dev/null}"
Habe nun...
1
export HOME=/var/lib/mosquitto
...eingefügt.
Was passiert?
HOME wird nun verarbeitet.
Das habe ich auch gleich im Log gemerkt. Nicht nur, dass die Warnings
weg waren, sondern auch der Eintrag in der
/var/lib/mosquitto/.config/mosquitto_pub "--debug" gezogen hat, und alle
Ausgaben im Log landeten.
Ich danke vielmals!
Das Log ist nun sauber.
Jetzt hoffe ich noch, dass die Fork Meldungen auch weg sind.
Sonst nehme ich noch das exce raus und schau dann weiter.
Georg A. schrieb:> Wollte es nur mal gesagt haben ;)
Danke Georg!
Die Ausgaben sind wohl, wenn man etwas mehr versteht als ich, extrem
aufschlussreich.
Andi G. schrieb:> Jetzt hoffe ich noch, dass die Fork Meldungen auch weg sind.> Sonst nehme ich noch das exce raus und schau dann weiter.
Nach mehr als 24 Stunden keinerlei Meldungen mehr vom Typ:
Andi G. schrieb:> Nach mehr als 24 Stunden keinerlei Meldungen mehr vom Typ:Cannot fork:> Cannot allocate memory
mmmhhh, leider zu früh gefreut.
Habe seit Tagen wieder das Problem das der Speicher vollläuft.
Es ist das tfrec script.
Solange es läuft wird die RAM Beanspruchung des Systems laufend höher.
Sobald ich das Script stoppe, sackt der Verbrauch ab und bleibt stabil
niedrig.
Die Idee 2 habe ich auch schon - ohne Erfolg - getestet.
Christian X. schrieb:> Idee 2: Entferne das 'exec' in 'run-tfrec.sh'.
Ich verarbeite die Daten mit fhem.
Im Moment helfe ich mir mit einem "shutdown restart" bei einem
logeintrag "Cannot fork".
Aber das ist halt nur Pflaster und Verband und gefällt mir gar nicht.
Wo könnte man denn da noch schrauben, um das in den Griff zu kriegen?
Da fällt mir wenig zu ein.
> Im Moment helfe ich mir mit einem "shutdown restart" bei einem> logeintrag "Cannot fork".
Das dürfte meiner Meinung nach nicht viel bringen, weil tfrec und fhem
ja unabhängige Prozesse sind. Du müsstest als Workaround doch eher tfrec
als fhem neu starten.
Bei mir läuft der Prozess 'tfrec' seit 14 Tagen durch und verbraucht 30
MB virtuellen bzw. 10 MB realen Speicher (Angaben gemäß 'top').
Du müsstest ja eigentlich nach einiger Zeit den Prozess ermitteln
können, der sich mehr und mehr Speicher einverleibt. Ist das wirklich
'tfrec'?
Also der Prozess, der hoch läuft ist /usr/bin/perl fhem.pl fhem.cfg.
tfrec (/opt/tfrec/tfrec -T 1 -t 1000 -q -e
/opt/tfrec/publish-tfrec-to-mqtt.sh) läuft i.d.R. mit ~30 MB
Aber, wie schon geschrieben
Andi G. schrieb:> Solange es läuft wird die RAM Beanspruchung des Systems laufend höher.> Sobald ich das Script stoppe, sackt der Verbrauch ab und bleibt stabil> niedrig.
Dann ist tfrec möglicherweise der Verursacher, aber nicht der Übeltäter.
Wenn fhem vollläuft, solltest Du dort weiterforschen. fhem und tfrec
sind ja nur sehr lose über MQTT gekoppelt. Du könntest als nächsten
Schritt mal tfrec laufen lassen, aber die Verarbeitung der tfrec-Werte
schrittweise abschalten: zuerst die Verarbeitung der Werte (expandJSON),
dann die MQTT-Subscriptions, dann das ganze MQTT-Device. So verliert
fhem den Kontakt zu den Werten von tfrec. Interessant ist, unter welchen
Bedingungen der Speicher immer noch volläuft.
OK, das werde ich versuchen.
Zwischenzeitlich habe ich mal mit "fhemdebug memusage" versucht ein paar
Infos zu ergattern, konnte aber noch nichts ausmachen...
Habe nach einem Shutdown restart gleich mal die Werte wegkopiert und
werde das dann später nochmal machen.
Dann das schrittweise Abschalten....
Mann mann mann, doofes Teil... :-)
So....
Habe auch im fhem forum gesucht und bin auf diesen Thread gestoßen:
https://forum.fhem.de/index.php/topic,84372.msg789057.html#msg789057
Ich hatte Freezemon installiert, nach einiger Zeit auf disable=1
gesetzt.
Das hat wohl das Problem verursacht.
Durch die vielen tfrec readings und dem nicht abarbeiten von Blocking
Calls lief wohl der Speicher hoch.
Nachdem ich Freezemon komplett gelöscht habe, ist nun auch das Problem
behoben.
Ich nutze tfrec seit inzwischen 1,5 Jahren ohne nennenswerte Probleme
mit 16 TFA-Sensoren 30.3180.IT. Vor Kurzem habe ich einige Z-Wave-Geräte
ausprobiert und hatte dabei Probleme mit der Funkverbindung. Mir fiel
auf, dass sowohl die TFA-Sensoren als auch Z-Wave im Bereich 868.4 MHz
funkt. Ich habe deshalb zu Testzwecken alle Thermometer außer Betrieb
genommen, und siehe da, die Z-Wave-Probleme waren verschwunden. Dann
habe ich nach und nach die Thermometer wieder in Betrieb genommen, und
die Probleme sind wieder da.
Laut Datenblatt sendet jeder TFA-Sensor im 10-Sekunden-Takt seine Werte.
Bei 16 Sensoren wären das im Schnitt alle 625ms ein Telegramm. Hoppla.
Da kann ich nachvollziehen, dass es die Z-Wave-Nachrichten schwer haben
durchzukommen, zumal in Z-Wave sowohl Hin- als auch Rücknachricht
überleben müssen, und das ggf. über mehrere Hops hinweg.
Jetzt suche ich nach Optionen, das Problem in den Griff zu bekommen. Am
einfachsten wäre sicher, die Anzahl der TFA-Sensoren zu reduzieren. Hält
es alternativ jemand für denkbar, das Funkintervall von 10 Sekunden
irgendwie zu erhöhen? Mir fehlt hier das Wissen über die Technik im
TFA-Sensor. Auch andere Ideen sind willkommen.
Bei den Sensoren kann man nichts ändern, die sind so wie sie sind. Wenn
ich das mit Z-Wave richtig verstanden habe, machen die aber mit
Acknowledge. Wenn das tauglich implementiert ist, sollte das doch über
so Fremdbelegungszeiten hinwegkommen.
Ansonsten könnte man noch ein paar Weatherhub-Sensoren statt der
KlimaloggPro nehmen (die gehen ja jetzt auch in tfrec). Die wiederholen
nur alle 7min. Ausser der längeren ID sollte es sonst keine
Nebenwirkungen geben.
> Wenn das tauglich implementiert ist, sollte das doch über> so Fremdbelegungszeiten hinwegkommen.
Ja, das ist halt genau der Punkt - meistens bis manchmal, aber für meine
Ansprüche nicht häufig genug.
> Ansonsten könnte man noch ein paar Weatherhub-Sensoren statt der> KlimaloggPro nehmen (die gehen ja jetzt auch in tfrec). Die wiederholen> nur alle 7min.
Gute Idee, danke.
Möglicherweise liege ich doch falsch mit meiner Vermutung, dass das
Funkband durch die TFA-Sender zu häufig belegt wird. Ich habe vor ein
paar Tagen den Z-Wave-Controller (Cyrus ZUB-CYR10103) gegen ein anderes
Fabrikat (Everspring SA413) getauscht und alle Geräte neu angelernt;
seitdem habe ich keine Verbindungsstörungen mehr. Ich habe auch gelesen,
dass Z-Wave im Fall eines belegten Frequenzbandes vor dem Senden eine
zufällige Dauer wartet, also zumindest theoretisch damit umgehen können
sollte (
https://www.embedded.com/design/connectivity/4025721/Catching-the-Z-Wave
).
Flavio C. schrieb:> Kann ich dir noch irgendwie helfen bei dem Sensor?
Danke, den Schubs hats noch gebraucht ;) Schau mal, ob jetzt der WHB-Typ
2 was sinnvolles liefert.
Hallo Georg
Nach langer Zeit ich wieder einmal mit einem TX22 Problem.
Ich habe das Problem, dass bei der Ausgabe via MQTT (FHEM) die Humidity
nur mit Null angezeigt wird bzw. kurz erscheint und dann sofort wieder
auf 0 gesetzt wird. Der Sub-Typ "1" (30000IDx) erscheint nie in der
Ausgabe.
Gruss
Thomas
0 ist vermutlich eher 100%. Ich habe einen Sensor in einem sehr feuchten
Keller(loch...), der gerne von 99 auf 0 springt. 100 kann nicht
übertragen werden. Ich habe daher bei den Sensoren, von denen ich weiss,
dass sie einen Feuchtigkeitssensor haben, beim Eintragen in die DB noch
eine Korrektur 0->100 gemacht.
Ein Aussensensor, der durch ungünstige Montage im Regen mal total
abgesoffen ist, hat auch dauernd 0 gemeldet. Hab ihn dann aufgemacht und
das Sensor-Platinchen gründlich mit Aquadest gereinigt. Dann ging er
wieder.
Gabs nicht irgendwo auch Berichte, dass so typische Sensoren ala DHT11
auch gerne einfach auch so versterben?
Hallo Georg
Der Sensor ist erst seit wenige Tagen im Aussenbereich und komplett
Regengeschützt montiert. Vorher lag er bei mir im nur im Büro herum. Ich
glaube daher nicht, dass es daran liegt. Wenn ich den Output des
Handlers ansehe, dann erscheint der Sub-Typ "1" nie in der Ausgabe. Im
Debug-Modus werden regelmässig die korrekten Hum-Werte ausgegeben,
welche auch auf der zur WS-1600 gehörigen Basisstation angegeben werden.
Also wird der Wert vom Sensor korrekt empfangen aber irgendwie nicht
korrekt durch den Handler ausgegeben. Zur Info: ich übertrage TX22 Werte
via MQTT an FHEM, wo vier einzelne Devices angelegt sind, welche jeweils
die Werte aus dem Temperatur und Humidity Reading auslesen. Ich konnte
das Problem soweit selber eingrenzen, dass bei dieser Umsetzung der Wert
verloren geht. Vielleicht kannst du mir das Konzept der erklären wie die
Werte aus den Sensordaten-Array umgewandelt wird, da ich leider nicht
über deine Profi-Programmierkenntnisse verfüge ;-). Gruss Thomas
Hallo Georg
Die Ursache, dass die Feuchtigkeit des TX22 nicht angezeigt wird liegt,
daran dass die Sensordaten nicht korrekt abgespeichert werden wenn das
Flag "have_hum" gesetzt wurde. Da in deinem Code Humidity nur zusammen
mit der Temperatur (SubTyp "0") ausgegeben wird und der TX22 Temperatur
und Feuchtigkeit nicht immer gemeinsam sendet, sondern separat, führt
dazu, dass die Feuchtigkeit nicht korrekt ausgegeben wird obwohl korrekt
empfangen wurde.
Habe das im Code von tfa2.cpp geändert (siehe Anhang).
Gruss
Thomas
Hier ein Tipp für alle Interessierten.
Seit Georg tfrec so erweitert hat, dass auch TX22 Sensordaten (WS-1600)
empfangen werden können, stellte sich nur das Problem, dass der TX22
seine ID nach jedem Batteriewechsel wechselt, was ein Integration in
fhem via MQTT
(https://github.com/git-developer/fhem-examples/wiki/Temperatur-Feuchte-Sender-mit-tfrec-und-MQTT)
erschwert.
Ich umgehe dieses Problem mit einem kleinen Trick indem ich den
wechselnden Teil der ID durch einen fixen String ersetze (siehe
Bash-Script im Anhang). So lässt sich in fhem ein eindeutiges Device
anlegen (funktioniert nur mit einem TX22!).
Hallo zusammen,
ich habe mir den TFA WeatherHub Regenmesser(30.3306.02) zugelegt.
Eigentlich sollte er erkannt werden. Aber ich empfange nur diesen
String:
#000 1561228174 L=44 4b 2d d4 2b 25 08 2e ee bb 7d c6 40 0b 40 f3 00 09
c0 00 c9 89 c1 6c c3 ad fd 23 c2 5d c0 21 ca f4 c0 04 c0 98 61 07 4d 2b
b0 4c 0e RSSI 86 /n# 2484 1561228176 2d d4 9e 86 38 35 19
Gestartet habe ich den tfrec-Prozess mit diesen Parametern:
/usr/bin/tfrec -f 868220 -D -q -T 27 -e /usr/bin/pushvals
Hat damit schon jemand Erfahrung? In der Sensorliste taucht dieser
Sensor ja eigentlich auf...
Schöne Grüße
Maik
Hallo zusammen,
so der Sensor scheint zu funktonieren. Ich hatte einen Fehler beim
Starten von tfrec gemacht: -D und -q sollte man nicht zusammen
benutzen..
Gruß
Maik
Hallo alle,
hoffentlich seid Ihr hier noch aktiv;
ich bräucht Hilfe, denn bei mir spuckt tfrec keine sinnvollen Daten aus,
höchstens BAD (s.u.)
Zunächst hatte ich Raspberry Pi 4 benutzt, jetzt Rasperry Pi 3 B+. Beide
unter Debian Buster.
zum Stick (aus dmesg):
Realtek RTL2832 successfully attached
Rafael Micro r820t successfully identified
Beim kompilieren von tfrec gab es reichlich warnings.
Sensoren sind 30.3180.IT und 30.3147
Hat jemand eine Idee, was hier schief läuft?
Danke
---><-------><-------><-------><-------><-------><-------><-------><----
./tfrec -D -t 1200 -T2
Registering demod for TFA_2 sensors, 17240 bit/s
type 0x1: Samples per bit: 22.3
Found Rafael Micro R820T tuner
AUTO GAIN
Frequency 868.2500MHz
Samplerate 1536000
START READ THREAD
Allocating 15 zero-copy buffers
Inverted SYNC
#000 1598510947 2d d4 49 51 a4 a8 2f TFA2 BAD 1
RSSI 63 Offset 4kHz (CRC 2f 4e)
#001 1598510950 2d d4 a5 65 2b ab 7e TFA2 BAD 2
RSSI 59 Offset 4kHz (CRC 7e 20)
#002 1598510951 2d d4 8b 2c 15 d8 45 TFA2 BAD 3
RSSI 58 Offset -3kHz (CRC 45 d7)
Inverted SYNC
#003 1598510953 2d d4 da a9 65 5e ad TFA2 BAD 4
RSSI 59 Offset 1kHz (CRC ad c9)
> Beim kompilieren von tfrec gab es reichlich warnings.
Das ist bei mir auch so, ich denke das ist unabhängig von Deinem
Problem.
> Sensoren sind 30.3180.IT und 30.3147> ./tfrec -D -t 1200 -T2
Ich habe für meine 30.3180.IT-Sensoren andere Parameter gesetzt:
-T 1 -t 1000 -g 13
Laut Doku ist -T 1 für KlimaLoggPro-Sensoren (30.3180.IT) und -t kann
höchstens 1000 sein. Vielleicht hat es damit etwas zu tun?
Bereits seit ein paar Monaten verwende ich tfrec um die Daten von acht
Klimalogg Sensoren auf zu zeichnen. Klappt ziemlich gut, vielen Dank!
Oben kam mal die Frage nach Python Anbindung auf, hier ein
Codeschnippsel dazu der tfrec direkt aus Python startet (nur auf Linux
getestet).
Wer nicht unbedingt ein SDR-Setup verwenden will, sondern den
mitgelieferten Kommunikations-Dongle, kann dies mit dem pyPI-Paket
kloggpro probieren.
https://pypi.org/project/kloggpro/
Ich kann auf einem Pi4 mit IOTstack [RTL_433, mosquitto, node-red,
influx, grafana] mit 433MHz-Stationen Temperatur und Feuchtigkeit in
einem Grafana-Zeitdiagramm darstellen.
Wäre dankbar für Hinweise zur Überprüfung der Datenausgabe von
tfreq-mqtt und für die mqtt-Integration in Node-RED.
Sofern Du kein abweichendes MQTT_TOPIC konfiguriert hast, werden die
Daten unter tfrec/<Sensor-ID>/json veröffentlicht.
In der Dokumentation unter Result (
https://github.com/git-developer/tfrec-mqtt#result ) findest Du
Beispiele.
Zur Problem-Analyse kannst Du das erstmal über mosquitto_sub überprüfen,
bevor Du weitere Tools ins Spiel bringst. Falls Du damit keine Daten
empfängst: Stimmen die Argumente für tfrec? Liefert baycom/tfrec (ohne
Docker) Ergebnisse?
MitLeserin schrieb:> Ich vermute Address not available bezieht sich auf mqtt-publish
Die Meldung wird von Mosquitto geliefert, wenn der Hostname des Brokers
nicht stimmt. Überprüf mal die Umgebungsvariable MQTT_OPTIONS, da sollte
'-h xyz' drin vorkommen, wobei xyz der Hostname Deines MQTT-Brokers ist.
step by step by step .. funktioniert !
IOTstack - https://github.com/SensorsIot/IOTstack/
Mit den beiden im Anhang aufgeführten Dateien in einem neuen Verzeichnis
/home/ab/IOTstack/.templates/tfrec-mqtt/ lässt sich das tfrec-mqtt image
von https://hub.docker.com/r/ckware/tfrec-mqtt in IOTstack integrieren.
Bisher getestet unter System Mint 19.3:
Host: Dell-i5
Kernel: 5.4.0-91-generic x86_64
bits: 64
Desktop: Cinnamon 4.4.8
wm: muffin
dm: LightDM
Distro: Linux Mint 19.3 Tricia
base: Ubuntu 18.04 bionic
Issue
https://github.com/SensorsIot/IOTstack/issues/424#issuecomment-964144025
ist für x86_64 zu berücksichtigen.
Herzlichen Glückwunsch!
Noch ein paar kleine Anmerkungen zu Deiner tfrec-mqtt/service.yml:
* Ich empfehle den Parameter 'init: true' zu setzen, damit tfrec-mqtt
sauber und schnell beendet werden kann. Ohne den Parameter wird der
Shutdown wahrscheinlich 10 Sekunden dauern und der tfrec-mqtt-Prozess
wird abrupt beendet.
* Die Umgebungsvariablen "MQTT_TOPIC" und "FORMAT_JSON" entsprechen den
Default-Werten und können entfernt werden. Alle Optionen mit ihren
Default-Werten findest Du unter
https://github.com/git-developer/tfrec-mqtt#configuration
Georg A. schrieb:> 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> ;)
Hallo Georg,
ist schon eine Weile her.
Ich könnte nun aber hinsichtlich MobileAlerts unterstützen.
Mit der Option T -20 empfange ich Werte von folgenden Geräten:
Temperatursensor MA10100
Temperatur- und Luftfeuchtesensor MA 10200
Regensensor MA 10650
Windmesser MA 10660
Daten sind anbei.
Gruß
Andi
Danke, die haben offensichtlich alle schon ihre "magische" CRC-Zahl,
d.h. ich habe schon vergleichbare Varianten aus dem TFA-Zoo. Aber schön,
dass sich damit die Liste der unterstützten/äquivalenten Devices weiter
auffüllen lässt.
Hallo,
Ich kann kein Deutsch, ich benutze Google Übersetzer. Verzeihung.
Vielen Dank für Ihre großartige Arbeit mit diesem Projekt.
Ich setze seit mehreren Wochen TFA-Sensoren mit tfrec / tfrec-mqtt ein.
Ich glaube nicht, dass es so funktioniert, wie es sollte.
Die Moskito-Protokolldatei wächst sehr schnell.
Es gibt viele solcher Einträge darin:
1642437035: New connection from 172.22.0.2 on port 1883.
1642437035: New client connected from 172.22.0.2 as
mosq-9UdOMppdzLVMQOa1Im (p2, c1, k60).
1642437035: Client mosq-9UdOMppdzLVMQOa1Im disconnected.
1642437036: New connection from 172.22.0.2 on port 1883.
1642437036: New client connected from 172.22.0.2 as
mosq-3Jjrz7ANvOuWqjEW8c (p2, c1, k60).
1642437036: Client mosq-3Jjrz7ANvOuWqjEW8c disconnected.
1642437037: New connection from 172.22.0.2 on port 1883.
1642437037: New client connected from 172.22.0.2 as
mosq-QNB28fg1VEiPBStT1q (p2, c1, k60).
1642437037: Client mosq-QNB28fg1VEiPBStT1q disconnected.
1642437038: New connection from 172.22.0.2 on port 1883.
1642437039: New client connected from 172.22.0.2 as
mosq-Y93YmFEuYy1aieBOry (p2, c1, k60).
1642437039: Client mosq-Y93YmFEuYy1aieBOry disconnected.
tfrec-mqtt und der Moskito laufen in Docker-Containern.
Wo soll ich nach einer Lösung suchen? Docker, Moskito, tfrec-mqtt usw.?
Hi Sebeen,
we can write in English if you prefer that.
Your log seems to be the mosquitto log containing reconnections. To
avoid these messages, I see the following options:
1.) Prevent reconnections
You could try to set a client id so that your broker can remember your
tfrec-mqtt container. This has to be configured in tfrec-mqtt, e.g.
1
MQTT_OPTIONS: "-h broker -i tfrec-mqtt"
in your docker configuration.
2.) Suppress log messages
You could configure your broker not to log these messages; when you use
mosquitto, try putting these lines into your mosquitto.conf:
Did I miss something in the tfrec-mqtt/mosquito container?
I also tested rtl_433 today.
Everything looks fine in the mosquito log file, although I have no
experience.
I discovered tfrec/rtl433 a few weeks ago and am excited :).
Below is the mosquito log file for rtl_433.
1
1642439453: Saving in-memory database to /mosquitto/data/mosquitto.db.
2
1642441254: Saving in-memory database to /mosquitto/data/mosquitto.db.
3
1642443057: Saving in-memory database to /mosquitto/data/mosquitto.db.
4
1642444859: Saving in-memory database to /mosquitto/data/mosquitto.db.
The tfrec-mqtt config looks good to me. To set a client id:
1
services:
2
tfrec-mqtt:
3
environment:
4
MQTT_OPTIONS: "-h mosquitto -i tfrec-mqtt"
I can't tell if your network configuration is appropriate. On my
machine, the configuration doesn't contain an external network but
exposes the mqtt ports. When your broker and tfrec-mqtt are running on
the same machine, this would be the configuration:
1
services:
2
tfrec-mqtt:
3
extra_hosts:
4
- "mosquitto:host-gateway"
5
mosquitto:
6
ports:
7
- "1883:1883"
8
- "9001:9001"
If you want to suppress the connection entries in the broker log, your
/home/pi/docker_NAS/mosquitto/config/mosquitto.conf should look like
this:
You gave me a hint. Adding "-x" solves the problem.
1
MQTT_OPTIONS: "-h mosquitto -i tfrec-mqtt -x 60"
Now the connection is maintained for the specified period of time.
Of course adding
1
log_type error
2
log_type warning
it also solves this, but I don't want to limit myself to error and
warning messages only in the log file.
By the way, I will ask about one more thing. What is the best practice
to generate graphs from tfrec to Grafana?
As I understand it, there are several options for using different
applications:
tfrec-mqtt-> mqtt_broker-> Node-RED-> Influxdb-> Grafana
tfrec-mqtt-> mqtt_broker-> Telegraf-> Influxdb-> Grafana
Can it be done with fewer applications (e.g. tfrec-mqtt-> Influxdb->
Grafana) or with others to make it better?
I am a child of Windows and I am just getting to know the nooks and
crannies of Linux, IoT, etc.
You gave me a hint. Adding "-x" solves the problem.
1
MQTT_OPTIONS: "-h mosquitto -i tfrec-mqtt -x 60"
Now there are no longer connected and disconnected messages.
Of course adding
1
log_type error
2
log_type warning
it also solves this, but I don't want to limit myself to error and
warning messages only in the log file.
By the way, I will ask about one more thing. What is the best practice
to generate graphs from tfrec to Grafana?
As I understand it, there are several options with the use of different
applications:
tfrec-mqtt-> mqtt_broker-> Node-RED-> Influxdb-> Grafana
tfrec-mqtt-> mqtt_broker-> Telegraf-> Influxdb-> Grafana
Can it be done with fewer applications (e.g. tfrec-mqtt-> Influxdb->
Grafana) or with others to make it better?
I am a child of Windows and I am just getting to know the nooks and
crannies of Linux, IoT, etc.
>tfrec-mqtt und der Moskito laufen in Docker-Containern.>Wo soll ich nach einer Lösung suchen? Docker, Moskito, tfrec-mqtt usw.?
@Sebeen (Gast)
all you need is composed into IOTstack:
https://www.youtube.com/watch?v=KJRMjUzlHI8&list=PL3XBzmAj53RloHdY69p3TkSaodIIm0Wpz&index=4
IOTstack is intended for Pi4, but it also works on my
Dell-Vostro-i5 Linux Mint 19.3 Tricia
tfrec-mqtt can be added into IOTstack - see
Beitrag "Re: SDR-Dekoder für TFA KlimaLogg Pro/IT+ Temperatursensoren"
rtl433 is available in IOTstack
The IOTstack to use : tfrec-mqtt -> mosquitto -> node-red -> influx ->
grafana
a screenshot with the grafana-graphics is included
Sebeen schrieb:> Can it be done with fewer applications (e.g. tfrec-mqtt-> Influxdb->> Grafana) or with others to make it better?
I'm sorry I can't help you with that because I don't use Grafana to plot
the values.
Hi,
ich suche ein Modul, das 868Mhz NRZS kann, aber finde keine Infos dazu.
Zuerst vll das, was ich vor habe. Ich möchte einen kleinen "Übersetzer"
für meine 3 30.3180.IT Stationen basteln. 868Mhz -> MQTT. Am besten wäre
es, das ganze mit einem ESP32 zu erledigen, von der Programmierung her
wäre es auch kein Problem dank der Infos und des Codes hier. Allerdings
finde ich keine Infos, ob es ein Modul gibt, das NRZS kann (also nicht
als Stick, sondern ein einfaches Modul, das ich an einen ESP
anschliessen könnte). Vll kann mir jemand hier weiterhelfen.
Danke
Tom
Tom schrieb:> Ich möchte einen kleinen "Übersetzer" für meine 3 30.3180.IT Stationen basteln.
868Mhz -> MQTT
Einen Übersetzer von 30.3180.IT auf MQTT gibt es mit tfrec-mqtt bereits
- allerdings auf Basis eines Linux-basierten (Mini-) Rechners und eines
DVB-T-Sticks. Wenn es Dir nur auf geringe Größe ankommt, könntest Du Dir
z.B. einen Raspberry Pi Zero ansehen.
Wenn ich Dich richtig verstehe, möchtest Du tfrec aber auf einem
Mikrocontroller betreiben und dazu den Code von tfrec wiederverwenden.
Keine Ahnung, ob das funktionieren würde. Meinst Du mit "Modul" ein
Stück Hardware, das Du direkt an einen ESP32 anschließen kannst? Da
fällt mir eigentlich nur ein, einen DVB-T-Stick zu zerlegen.
In den Sendern sind Chips von Axsem (jetzt Onsemi) drin. Irgendwas mit
AX5xxx. Sehr wahrscheinlich ist das Gegenstück (bzw. ein Transceiver)
auch in den Empfängern. Die Chips wären bei Digikey sogar erhältlich.
Aber Module dazu kenne ich auch nicht, vermutlich ist es einfacher, eine
Klimalogg-Pro-Basisstation zu schlachten und das SPI zum Transceiver
anzuzapfen.
Christian X. schrieb:> Tom schrieb:>> Ich möchte einen kleinen "Übersetzer" für meine 3 30.3180.IT Stationen basteln.> 868Mhz -> MQTT>> Einen Übersetzer von 30.3180.IT auf MQTT gibt es mit tfrec-mqtt bereits> - allerdings auf Basis eines Linux-basierten (Mini-) Rechners und eines> DVB-T-Sticks. Wenn es Dir nur auf geringe Größe ankommt, könntest Du Dir> z.B. einen Raspberry Pi Zero ansehen.>> Wenn ich Dich richtig verstehe, möchtest Du tfrec aber auf einem> Mikrocontroller betreiben und dazu den Code von tfrec wiederverwenden.> Keine Ahnung, ob das funktionieren würde. Meinst Du mit "Modul" ein> Stück Hardware, das Du direkt an einen ESP32 anschließen kannst? Da> fällt mir eigentlich nur ein, einen DVB-T-Stick zu zerlegen.
Hi,
das Problem ist, dass es erstens vom Platz her mit einem Pi Zero nicht
gehen wird, zweitens läuft das System mit Akkus und sendet an einen
Server per Lora, der 3,5km weit weg steht. Das mit den Akkus ist recht
schwer mit dem Pi.
Georg A. schrieb:> In den Sendern sind Chips von Axsem (jetzt Onsemi) drin. Irgendwas> mit> AX5xxx. Sehr wahrscheinlich ist das Gegenstück (bzw. ein Transceiver)> auch in den Empfängern. Die Chips wären bei Digikey sogar erhältlich.> Aber Module dazu kenne ich auch nicht, vermutlich ist es einfacher, eine> Klimalogg-Pro-Basisstation zu schlachten und das SPI zum Transceiver> anzuzapfen.
Danke, ich schaue mal ob ich die Chips finde. Die Basisstation zu
zerlegen wäre natürlich eine Möglichkeit, aber verkompliziert alles
etwas.
Tom schrieb:> Ich suche etwas wie die RFM63W-Module, aber eben mit NRZS, die RFM63er> können nur NRZ. Leider, sonst wären die perfekt
Der TO hat in einem Thread geschrieben, dass er glaubt welcher Chip im
KlimaLogg Pro verbaut ist. Vielleicht liest er hier mit und gibt einen
Hinweis. Ansonsten: Gibt es einen Empfänger, der das Signal 1:1
durchreicht? Die Dekodierung übernimmt dann ein µC.
Ich habe hier noch eine Basisstation RH100 inkl. Funk-Stick liegen. Auf
dem Stick liegt nur 1 Chip frei, darauf steht "SILABS F326 DCNAQO
0838+". Scheint mir der Mikrocontroller zu sein. Ein anderer Chip,
vermutlich das Funkmodul, ist unter einem schwarzem Batzen versteckt.
Der Stick wird am PC mit VID 6666 PID 5555 Serial 0123456 erkannt.
Laut FHEM-Forum
(https://forum.fhem.de/index.php/topic,11808.msg204967.html#msg204967)
enthält
- der USB-Stick einen AX5051
- die 30.8180.IT-Sender einen AX5031
Hallo zusammen,
ich bin auf dieses tolle Projekt gestossen, welches eigentlich genau das
macht was ich suche: Direkt die Temperatursensoren einlesen ohne über
die Klimalogg-Basisstation zu gehen. Leider hab ich das ganze bisher
nicht zum laufen bekommen. Vieleicht könnt ihr mir auf die Sprünge
helfen, ich bin nicht so versiert mit Unix systemen.
Mein Setup:
- 8 Sensoren 30.3180.IT
- RTL2832U Stick an einer
- Synology NAS DS220+ mit Betriebssystem DSM7.2.1
Auf dem NAS läuft Docker mit folgendem tfrec image:
https://github.com/git-developer/tfrec-mqtt
Das scheint soweit zu funktionieren. Zumindest sehe ich keien
Fehlermeldungen. Ich glaube allerdings, dass der RTL2832U Stick noch
nicht richtig erkannt wird oder an docker weiter geleitet wird. Mir ist
nicht so ganz klar, wie ich das am besten Debugge.
Wenn ich in Docker folgenden Befehl ausführe:
Es scheint also schon so, als wäre im tfrec der RTL2832U Stick mit ID
0bda:2838 bekannt. Muss ich noch irgendwas einstellen, damit tfrec weiss
auf welches USB Gerät es zugreifen muss?
Irgendwo hab ich gelesen, dass Synology ab DSM7 USB devices nicht mehr
unterstüzt. Ich habe jedoch die Treiber nachgerüstet mit folgendem
Tutorial:
https://mariushosting.com/synology-how-to-add-usb-support-on-dsm-7/
Disclaimer: ich bin der Maintainer von tfrec-mqtt und habe keine
Erfahrung mit Synology NAS.
Fragen:
1. Wie ist der USB-Stick gemountet? (z.B. --devices /dev/bus/usb)
2. Mit welchem User wird der Container gestartet?
Ideen:
1. Das Gerät wird von einem anderen Prozess belegt. Vielleicht hat die
NAS-Software den USB-Stick im Zugriff.
2. Der Benutzer hat keine Berechtigung zum Lesen des USB-Gerätes. Das
könnte sich bei Dir mit den Befehlen 'ls -la /dev/bus/usb/001/002' (auf
dem Host) und 'id' (im Container) prüfen lassen.
3. Der Treiber ist nicht geladen. Das kann man durch 'lsmod | grep -i
rtl2832' prüfen. Wenn der Treiber nicht geladen ist, dürfte keine
AUsgabe kommen.
In https://github.com/wmbusmeters/wmbusmeters/issues/774 liest es sich
so, als würde der Kernel-Treiber für den RTL2832-Stick fehlen. Sollte
das der Fall sein, müsstest Du den Treiber dvb_usb_rtl28xxu.ko für Dein
NAS beschaffen oder selber bauen. Dabei kann ich leider nicht
weiterhelfen.
Vielen Dank für die schnelle Antwort. Ich hab zwischenzeitlich zur Übung
das ganze auf einem Pi ohne grosse Probleme aufgesetzt. Mit der
Erfahrung eines funktionierenden Systems plus deinen Tipps hab ich mich
dann nochmal hinter die Synology gesetzt.
Ich bin fast ein bisschen erschrocken, als plötzlich Daten daher kamen.
Das Problem war wie von dir vermutet die Berechtigung zum Lesen des USB
Gerätes.
Jetzt empfange ich zumindes 3 von 8 Sensoren. Ich vermute es hängt noch
damit zusammen, dass ich noch keine Antene habe und vorerst einfach ein
Stück Kabel an den Antennenanschluss gefummelt hab.
Gain und Threshold hab ich auf Automatik. Kann ich irgendwie sehen auf
welchen Wert sich die Automatik eingestellt hat?
Gain wird glaube ich beim Starten ausgegeben. Laut
Troubleshooting-Abschnitt der tfrec-Doku (
https://github.com/baycom/tfrec#troubleshooting ) kann man das
Debug-Argument mehrfach angeben, also -DD und -DDD. Vielleicht findest
Du darüber mehr heraus. Man sieht damit u.a. das Verhältnis von Signal
zu Rauschen und kann mit dem Wissen ggf. das Gain-Argument anpassen.
Ansonsten erinnere ich mich noch, dass ich schon etwas experimentieren
musste, bis ich regelmäßig Empfang von allen Sensoren hatte. Deutlich
haben sich bei mir die Position und Ausrichtung der Antenne ausgewirkt.
Außerdem habe ich verschiedene Frequenzen zwischen 868250 und 868337
ausprobiert.
Und wieder war dein Tipp super. Ich musste die Frequenz auch etwas nach
oben anpassen. Mein Optimum ist bei ca. 868300kHz. Damit empfange ich
alle meine 8 Sensoren und das obwohl meine Antenne immer noch ein
simpler Draht ist.
Vielen, vielen Dank für deine Unterstützung!
Meine drei Jahre alten, acht TFA Sensoren vom Klimalogg sind leider
recht instabil bei der Luftfeuchtemessung. Ich verwende sie u.a. zur
Steuerung einer kleinen Lüftautomatik. Wenn der Außensensor um vier
Prozentpunkte daneben liegt finde ich das schon viel.
Momentan versuche ich gelegentlich die Sensoren alle nebeneinander zu
legen und abzugleichen. Allerdings scheinen die Abweichungen auch
feuchtigkeitsabhängig zu sein. Bevor ich jetzt versuche die Steigung der
Sensoren auch noch abzugleichen wollte ich mal fragen ob jemand Tipps
dazu hat oder vielleicht stabilere Sensoren empfehlen kann?
TFrec kompatibel wäre natürlich praktisch.
Hier sind selbstgebaute Funksensoren des TiNo-Projekts im Einsatz, dabei
habe ich Sensoren SHT31 von Sensirion verwendet.
Die sind sehr präzise, schwanken auch untereinander kaum.
Danke für die Tipps. Scheint mir allerdings etwas aufwändiger mit dem
TiNo.
Ich habe zwischenzeitlich zwei neue Sensoren bestellt. Eigentlich wollte
ich über mehrere Sensoren mitteln aber es hat sich herausgestellt, dass
bei einem meiner alten Sensoren die Feuchtemessung schlicht defekt ist,
zumindest weicht er deutlich von allen anderen ab. Tja, es scheint
geboten, die TFA Sensoren gelegentlich zu prüfen. :-)
Thread beobachten
Seitenaufteilung abschalten