Hi zusammen,
letzens bin ich auf diese Seite aufmerksam geworden: luftdaten.info (http://luftdaten.info)
Dort wird beschrieben wie man sich für ca. 40 € (falls ich alles richtig zusammen gezählt habe ::)) einen Feinstaubsensor selber bauen kann.
Da ich selbst direkt an einer Hauptstraße wohne finde ich das ganz interessant und werde das demnächst mal versuchen.
Die Anbindung an fhem würde ich dann erstmal über HTTPMOD lösen.
Interessant wäre natürlich auch ob man das ganze nicht mit einer Batterie betreiben kann. Oder gibt es Kabel die ich dauerhaft gefahrlos durch ein Fenster legen kann?
Bisher habe ich noch nie etwas mit einem Arduino gemacht, aber das war ja bei allen mal der Fall.
Sobald ich mehr Zeit dafür habe melde ich mich wieder.
Grüße
igami
Hallo,
Ich bin gerade dabei, zwei solche Sensoren zu bauen. Prinzipiell geht eine Versorgung über Batterie, das Teil braucht 5V, benötigt aber für sein WLAN recht viel Energie. Daher wirst Du da mit normalen Batterien nicht glücklich - da sprechen wir eher von Blei-Gel Batterie mit 12V->5V Spannungswandler oder einer 6V Motorradbatterie.
Da der Sensor seine Daten über WLAN überträgt, brauchst Du nur ein zweipoliges Kabel für 5V mit einem MicroUSB Stecker an einem Ende. Das könnte man auch mit einem Flachbandkabel machen, bei dem man dann innen und außen mehrere Litzen zusammenfasst um auf einen vernünftigen Querschnitt zu kommen.
Gruß,
Reiner
Hallo zusammen,
ich habe mir gerade eben auch einen Sensor zusammengebaut. Ich brauch noch ein schöne Gehäuse und nen schönen Platz für die Montage.
Wenn jemand von euch etwas zusammenschreibt, wäre ich an der Lösung interessiert.
Mit freundlichen Grüßen
Nico
Ich hab seit ein paar Tagen einen in Betrieb ... http://vair-monitor.com ... funktioniert einwandfrei. Also falls jemand keine Lust auf selber Zusammenbauen hat, und wie ich nur die Messwerte haben will um dann mit denen dann zu basteln, ich kann das Ding wärmstens empfehlen ;)
Zitat von: peterk_de am 23 Februar 2017, 21:05:35
Ich hab seit ein paar Tagen einen in Betrieb ... http://vair-monitor.com ... funktioniert einwandfrei. Also falls jemand keine Lust auf selber Zusammenbauen hat, und wie ich nur die Messwerte haben will um dann mit denen dann zu basteln, ich kann das Ding wärmstens empfehlen ;)
Welchen hast du denn da genommen...?
Und wie ist die Anbindung...?
Gesendet von iPhone mit Tapatalk
Zitat von: peterk_de am 23 Februar 2017, 21:05:35
Ich hab seit ein paar Tagen einen in Betrieb ... http://vair-monitor.com ... funktioniert einwandfrei. Also falls jemand keine Lust auf selber Zusammenbauen hat, und wie ich nur die Messwerte haben will um dann mit denen dann zu basteln, ich kann das Ding wärmstens empfehlen ;)
Aber die kosten ja schon ein bisschen mehr als der vom Chinamann
Ich bin gerade dabei mir auch den Sensor zu bauen. Wenn der Sensor läuft, übermittelt er die Daten und man kann diese bei http://feinstaubsensor-<chipid>.local/data.json per HTTP abholen / anzeigen. Entweder mit HTTPMOD oder mit JSONREADINGS.
Diese sind dann so im Device sichtbar
sensordatavalues_01_value 18.40 2017-02-24 09:37:43
sensordatavalues_01_value_type temperature 2017-02-24 09:37:43
sensordatavalues_02_value 48.00 2017-02-24 09:37:43
sensordatavalues_02_value_type humidity 2017-02-24 09:37:43
sensordatavalues_03_value 98373 2017-02-24 09:37:43
sensordatavalues_03_value_type BMP_pressure 2017-02-24 09:37:43
sensordatavalues_04_value 19.10 2017-02-24 09:37:43
sensordatavalues_04_value_type BMP_temperature 2017-02-24 09:37:43Zitat von: igami am 08 Februar 2017, 06:23:27
Die Anbindung an fhem würde ich dann erstmal über HTTPMOD lösen.
Wie kann man nun die empfangenen Werte auf aussagekräftige Readings (z.B. temperature, humidity, usw.) wandeln?
Ich habe es mit HTTPMOD und Regex hinbekommen :). Hier kann man den JSON String mit Regex sehr gut testen https://regex101.com/.
#SDS011
define SDS011 HTTPMOD http://feinstaubsensor-<chipid>.local/data.json 60
attr SDS011 userattr reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex reading04Name reading04Regex reading05Name reading05Regex requestHeader stateFormat
attr SDS011 reading01Name temperature
attr SDS011 reading01Regex "temperature","value":"(0|\d*\.\d+)"}.*
attr SDS011 reading02Name humidity
attr SDS011 reading02Regex "humidity","value":"(0|\d*\.\d+)"}.*
attr SDS011 reading03Name BMP_temperature
attr SDS011 reading03Regex "BMP_temperature","value":"(0|\d*\.\d+)"}.*
attr SDS011 reading04Name BMP_abs_pressure
attr SDS011 reading04Regex "BMP_pressure","value":"(0|\d*+)"}.*
attr SDS011 reading05Name software_version
attr SDS011 reading05Regex "software_version": "(.*?)".*
attr SDS011 requestHeader Content-Type: application/json
attr SDS011 room Wetter
attr SDS011 stateFormat {sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Press: %.1f mbar", ReadingsVal("SDS011","relpressure",0))}\
attr SDS011 userReadings relpressure { ReadingsVal("SDS011","BMP_abs_pressure",0)/100+25.7;; }
attr SDS011 verbose 1
Kurze Erklärung:
"temperature","value":"(0|\d*\.\d+)"}.*
"temperature","value":" als Erstes kommt dies
() innerhalb der Klammer ist der Wert den man lesen will
0 ist erlaubt
| oder
\d* nummerisches Zeichen kommt nicht oder mehrfach vor
\. Dezimalpunkt
\d+ nummerisches Zeichen kommt einmal oder mehrfach vor
"} Es kommt ein Hochzeichen und eine Klammer
.* Dann kommen noch Zeichen
Beim Luftdruck ist der reguläre Ausdruck anders, da der Wert in Pascal und ohne Dezimalzeichen ist und bei der Software Version auch.
Die Feinstaubwerte sind noch nicht mit drin, da ich noch auf den Sensor warte.
Gleich mal für die nächste Bestellung vormerken....So ein Tierchen fehlt mir noch in meinem Zoo :D
Wobei's hier am Lande, wo sich Fuchs und Hase gute Nacht sagen, kaum eine Belastung geben wird ^^
@Icinger
Freu Dich nicht zu früh ;)
ZitatEine weitere wichtige Quelle ist die Landwirtschaft: Die Emissionen gasförmiger Vorläuferstoffe, insbesondere die Ammoniakemissionen aus der Tierhaltung, tragen zur sekundären Feinstaubbildung bei.
http://www.umweltbundesamt.de/themen/luft/luftschadstoffe/feinstaub (http://www.umweltbundesamt.de/themen/luft/luftschadstoffe/feinstaub)
Viele Grüße
Thomas
Wir haben hier nur Argrar, keine Tierhaltung im weiteren Umkreis.....
... und keine Nachbarn mit ältere Holzheizung? ;)
Touché :)
Zitat von: nico2506 am 23 Februar 2017, 20:53:26
Hallo zusammen,
ich habe mir gerade eben auch einen Sensor zusammengebaut. Ich brauch noch ein schöne Gehäuse und nen schönen Platz für die Montage.
Wenn jemand von euch etwas zusammenschreibt, wäre ich an der Lösung interessiert.
Mit freundlichen Grüßen
Nico
Hallo Nico,
kannst du da bitte mehr Infos geben. Welchen hast du genommen, wie zusammen gebaut (Komponenten) und wie ins FHEM integriert (cfg)
Ich werd wohl noch ein paar Tage auf meine Teile warten müssen, aber werde dann den vorgeschlagenen Rohrbogen als Gehäuse verwenden.
Hm, eigentlich eine tolle Sache. Aber das mit dem Netzteil ist für mich leider ein No-Go :( Wenn die Dinger nicht WLAN aber dafür per 433 MHz oder 868 (wie Homematic) senden würden und dann vielleicht per Batterie zu betreiben wären, dann wärs super.
Das Problem ist wahrscheinlich weniger das WLAN, sondern eher, dass das nötige Volumen per Lüfter durch den Sensor geschleust werden muss.
Ich wollte bei mir dann auch mal eine Messsteckdose dazwischen hängen um zu gucken wie viel Strom das Teil so braucht.
Zitat von: cfi am 24 Februar 2017, 18:15:07
Ich habe es mit HTTPMOD und Regex hinbekommen :). Hier kann man den JSON String mit Regex sehr gut testen https://regex101.com/.
#SDS011
define SDS011 HTTPMOD http://feinstaubsensor-<chipid>.local/data.json 60
attr SDS011 userattr reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex reading04Name reading04Regex reading05Name reading05Regex requestHeader stateFormat
attr SDS011 reading01Name temperature
attr SDS011 reading01Regex "temperature","value":"(0|\d*\.\d+)"}.*
attr SDS011 reading02Name humidity
attr SDS011 reading02Regex "humidity","value":"(0|\d*\.\d+)"}.*
attr SDS011 reading03Name BMP_temperature
attr SDS011 reading03Regex "BMP_temperature","value":"(0|\d*\.\d+)"}.*
attr SDS011 reading04Name BMP_abs_pressure
attr SDS011 reading04Regex "BMP_pressure","value":"(0|\d*+)"}.*
attr SDS011 reading05Name software_version
attr SDS011 reading05Regex "software_version": "(.*?)".*
attr SDS011 requestHeader Content-Type: application/json
attr SDS011 room Wetter
attr SDS011 stateFormat {sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Press: %.1f mbar", ReadingsVal("SDS011","relpressure",0))}\
attr SDS011 userReadings relpressure { ReadingsVal("SDS011","BMP_abs_pressure",0)/100+25.7;; }
attr SDS011 verbose 1
Hier noch die Settings für den SDS011 Sensor:
attr SDS011 userattr reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex reading04Name reading04Regex reading05Name reading05Regex reading06Name reading06Regex reading07Name reading07Regex requestHeader stateFormat
attr SDS011 reading06Name pm100
attr SDS011 reading06Regex "SDS_P1","value":"(0|\d*\.\d+)"}.*
attr SDS011 reading07Name pm25
attr SDS011 reading07Regex "SDS_P2","value":"(0|\d*\.\d+)"}.*
attr SDS011 stateFormat {sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("SDS011","pm100",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("SDS011","pm25",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("SDS011","humidity",0))}
Hab heute auch meinen SDS011 bekommen.
Der gibt ja eh serielle Daten aus, lässt sich also leicht auch an nen Arduino anschließen.
Nachdem ich den Sensor eh in der Zuluft meines Pool-Technikraumes unterbringen will (wobei der Technikraum bzw. der ganze Pool erst in 14 Tagen gemauert wird), kann ich den ja auch direkt an meinen AdruinoMega, der die Poolsteuerung übernimmt, anklemmen :)
Werde den dann vermutlich im Stundentakt an/ausschalten für jeweils 5 Minuten. Muss mich da mal herantasten, was sinnvoll ist.
Der Laser da drinnen hat ja leider nur eine ca-Lebensdauer von 8000 Stunden, also im Dauerbetrieb nichtmal ein ganzes Jahr.
lg, Stefan
Ich bin momentan dabei für Luftdaten.info ein Modul zu schreiben. Man sollte kein HTTP Mod verwenden um den Sensor lokal auszulesen, wenn er auch an die Server für die Map sendet.
Wenn die Abfrage und das senden zusammen Fallen blockiert der Sensor, da der RAM nicht ausreicht, und muss neugestartet werden.
Zitat von: Icinger am 01 April 2017, 11:30:29
Der gibt ja eh serielle Daten aus, lässt sich also leicht auch an nen Arduino anschließen.
Wenn du da weiter kommst und das Teil in betrieb hast, würden wir uns sicherlich über die Bauanleitung freuen.
Gerne auch mal ein Foto und eben Infos über script, cfg etc. etc.
Danke
Jörg
Zitat von: igami am 01 April 2017, 12:46:23
Ich bin momentan dabei für Luftdaten.info ein Modul zu schreiben. Man sollte kein HTTP Mod verwenden um den Sensor lokal auszulesen, wenn er auch an die Server für die Map sendet.
Wenn die Abfrage und das senden zusammen Fallen blockiert der Sensor, da der RAM nicht ausreicht, und muss neugestartet werden.
Welche Alternative zu HTTP_mod schwebt Dir vor, um die Daten zu lesen?
Zitat von: reibuehl am 01 April 2017, 13:05:40
Welche Alternative zu HTTP_mod schwebt Dir vor, um die Daten zu lesen?
Ein eigenes Modul welches die Daten von http://api.luftdaten.info/v1/sensor/<SensorID> holt. Zusätzlich soll es die Daten auch lokal abfragen können.
Als Readings werden dann bei remote:
latitude, longitude, PM10, PM2.5, temperature und humidity bereitgestellt
und bei lokal:
WiFiSignal, signalQuality, PM10, PM2.5, temperature und humidity.
Ich denke, dass ich eine erste Version davon im lauf der Woche bereitstellen kann.
Hört sich sehr interessant an!
Danke für die vielen Infos.
Ich habe ein kleines Gehäuse für den SDS011 Nova Sensor entworfen.
Kostenlos runterladen bei Thingiverse: http://www.thingiverse.com/thing:2219718
Mehr Infos in meinem Blog: https://blog.moneybag.de/sds011-feinstaubsensor-fuer-fhem/
LG
/robin
Weiß jemand was es mit diesen Daten auf sich hat:
{"value_type":"samples","value":"284269"},{"value_type":"min_micro","value":"184"},{"value_type":"max_micro","value":"20404"}
die werden beim lokalen json request als "sensordatavalues" zurückgegeben.
Ansonsten macht das Modul grade Fortschritte :)
Könnte mir bitte jemand das json von "http://<ip>/data.json" schicken? Ich habe selbst noch kein SDS011 und weiß daher auch nicht wie das geparsed werden muss.
So, anbei die erste Version des Moduls.
Einfach auf http://maps.luftdaten.info/ (http://maps.luftdaten.info/) die Sensor id Raussuchen und dann mittels
define <name> LuftdatenInfo <SensorID>
anlegen.
Ich würde mich über FeedBack freuen, besonders wenn Fehler auftreten.
Edit: neue Version weiter hinten im Thread
Zitat von: Icinger am 01 April 2017, 11:30:29
Werde den dann vermutlich im Stundentakt an/ausschalten für jeweils 5 Minuten. Muss mich da mal herantasten, was sinnvoll ist.
Der Laser da drinnen hat ja leider nur eine ca-Lebensdauer von 8000 Stunden, also im Dauerbetrieb nichtmal ein ganzes Jahr.
Bei der Version von Luftdaten.info wird der Sensor in jeder Minute für 15 Sekunden eingeschaltet.
ZitatBei der Version von Luftdaten.info wird der Sensor in jeder Minute für 15 Sekunden eingeschaltet.
Das Datenblatt schweigt sich darüber leider aus, aber an einigen anderen Stellen hab ich gelesen, dass der Sensor erst nach 30 Sekunden verlässliche Daten liefert....
Hmm......Na mal schaun wie ich Lust habe, den selbst anzusteuern....
Zitat von: igami am 02 April 2017, 16:12:35
Ich würde mich über FeedBack freuen, besonders wenn Fehler auftreten.
Vielen Dank für Deine tolle Arbeit an dem Modul! Ich hab es gerade mal bei mir installiert. Die Werte sehen beim Vergleich mit dem aktuellen data.json korrekt aus.
Das State Attribut könnte meiner Meinung nach etwas "informativer" gestaltet werden. Ich hab es bei mir mal über das Attribut stateFormat abgeändert:
state = {sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("Feinstaub","PM10",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("Feinstaub","PM2.5",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("Feinstaub","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("Feinstaub","humidity",0))}Damit sieht der State des Device dann so aus:
PM10: 17.0 µg/m³ / PM2.5: 15.3 µg/m³ / Temp: 16.5 °C / Hum: 57.6 %
Außerdem würde ich die Beschreibung des Zusammenhangs zwischen SDS011 ID und DHT ID in der CommandRef ändern. Hier wird meiner Meinung nach Digit und Count bzw. Wert und Stelle verwechselt. Wie wäre hier einfach
The DHT22 SensorID is usually the SDS011 SensorID + 1 and does not have to be specified explicitly.
bzw. in Deutsch
Die DHT22 SensorID entspricht normalerweise der SDS011 SensorID + 1 und muss nicht explizit mit angegeben werden.
Dann ist mir noch ein kosmetischer Fehler aufgefallen: In der CommandRef scheint "Prerequisites" von der Einrückung her eine Unterüberschrift zu sein, wird aber nicht fett gedruckt.
Ich werde wohl über Ostern noch einen zweiten Sensor bauen, diesmal mit einem Bosch BME280 statt dem DHT22. Sobald der läuft, kann ich Dir mal ein data.json schicken, in dem dann auch relpreasure mit echten Werten gefüllt wird.
Zitat von: reibuehl am 02 April 2017, 19:16:25
Damit sieht der State des Device dann so aus:
PM10: 17.0 µg/m³ / PM2.5: 15.3 µg/m³ / Temp: 16.5 °C / Hum: 57.6 %
Also wenn ich mir das Weather oder HomeMatic Modul angucke sind die zusammengesetzten states immer ohne Einheiten und da war ich noch nie ein Fan von.
Ich bastel Sie mir auch immer selbst mit stateFormat zusammen.
State ist meiner Meinung nach ein Reading welches Informationen über den Status geben soll, eben active, disabled oder auch error.
Zitat von: reibuehl am 02 April 2017, 19:16:25
Außerdem würde ich die Beschreibung des Zusammenhangs zwischen SDS011 ID und DHT ID in der CommandRef ändern. Hier wird meiner Meinung nach Digit und Count bzw. Wert und Stelle verwechselt. Wie wäre hier einfach
The DHT22 SensorID is usually the SDS011 SensorID + 1 and does not have to be specified explicitly.
bzw. in Deutsch
Die DHT22 SensorID entspricht normalerweise der SDS011 SensorID + 1 und muss nicht explizit mit angegeben werden.
Dann ist mir noch ein kosmetischer Fehler aufgefallen: In der CommandRef scheint "Prerequisites" von der Einrückung her eine Unterüberschrift zu sein, wird aber nicht fett gedruckt.
Werde ich abändern, vielen Dank für das genaue lesen :)
Zitat von: reibuehl am 02 April 2017, 19:16:25
Ich werde wohl über Ostern noch einen zweiten Sensor bauen, diesmal mit einem Bosch BME280 statt dem DHT22. Sobald der läuft, kann ich Dir mal ein data.json schicken, in dem dann auch relpreasure mit echten Werten gefüllt wird.
Momentan prüfe ich auf den Sensor Typ. Das Modul wird dann keine Werte für den Sensor liefern. Werde ich dann aber einbauen.
Ich denke dann sollte ich die Internals für die IDs auch nochmal umbenennen, vllt in SENSORPMID und SENSORWEATHERID oder so.
Das mit den Abstürzen kann ich leider bestätigen, ich dachte mir auch, warum die Daten aus der Ferne holen, wenn ich sie lokal habe. Allerdings stürzt der Sensor leider regelmässig ab wenn man den integrierten Web-Server pollt.
Immerhin gibt es einen Timeout und er startet neu, man muss also nicht die Stromversorgung kappen oder ähnliches.
Wenn ich mal wieder Zeit habe, werde ich mir das Modul anschauen, oder die Firmware des Sensors....
Im Anhang eine neue Version des Moduls.
Es wurde die Commandref abgeändert, die Internals der Sensor IDs geändert. Längen- und Breitengrad werden nur einmal als Readings angelegt, es gibt ein neues Reading address in dem die Adresse als "Straße Hausnummer, Postleitzahl Ort" steht.
Also das reading address ist bei mir nicht aufgetaucht. Worüber sollte das gefüllt werden?
Mach mal bitte ein modify, das reading wird nur befüllt, wenn es latitude oder longitude noch nicht gibt. Werde ich nachher noch erweitern.
Wenn ich auf DEF klicke und dann (ohne die Sensor ID zu ändern) auf Modify, schmiert mir mein ganzes FHEM mit der Meldung
Undefined subroutine &main::readingsBulkUpdateIfChanged called at ./FHEM/59_LuftdatenInfo.pm line 301.
ab. :(
Ist dein FHEM aktuell? Die Funktion ist "erst" seit dem 10.10.2016 in fhem.pl enthalten.
interessanter Thread. Der weckt den Bastlerinstinkt! :-)
Werd mir mal die Teile besorgen und bauen!
Ups... da war mein update wohl schon länger überfällig :) Der Absturz ist damit weg - das address reading wird aber trotzdem nicht angelegt.
Frage: wie oft werden denn die Luftdaten aktualisiert?
im WWW sehe ich für den Sensor der mir am nächsten liegt (729) andere Daten als das Modul abruft.
Interval steht auf 5 Minuten. die Readings PM10 und PM2.5 werden aber nicht aktualisiert.
Gibt es hier einen fest eingebauten anderen Interval?
Die Sensoren senden ein mal pro Minute an luftdaten.info.
Zitat von: reibuehl am 05 April 2017, 15:02:16
Die Sensoren senden ein mal pro Minute an luftdaten.info.
Daten auf der Webseite: PM10: 9 / PM2.5: 8
Daten in FHEM: PM10: 11.92 / PM2.5 10.60 (Zeitstempel 13:56)
Temp und Feuchte werden aktualisiert, die PM Daten nicht.
Sensor ID 729 (nicht meiner)
Da war noch ein Bock im Modul ::)
Neue Version im Anhang.
Also das reading wird jetzt angelegt, was drin steht ist aber Blödsinn. Schmeiß das ganze am besten wieder raus. Die Koordinaten der Sensoren sind in den Daten auf Luftdaten.info künstlich ungenau gemacht und zeigen nur etwa 100-200m den Standort an. Ein Rückrechnen über Openstreetmap bringt also nur zufällig manchmal eine korrekte Adresse und in den allermeisten Fällen einfach nur irgendeine Adresse in der Umgebung.
Ich hab das Reading eingebaut, damit man auf die schnelle überprüfen kann ob der Sensor in der Nähe ist und nicht ein Tippfehler unterlaufen ist. Es wird auch nur angelegt, wenn es noch nicht existiert.
Wenn ich jetzt noch darüber nachdenke sollte ich die Abfrage bei OSM noch unterbinden, wenn das Reading durch suppressReading unterdrückt wird.
Wäre es möglich statt address ein reading Position einzufügen mit dem Value "https://www.openstreetmap.org/#map=18/<latitude>/<longitude>" als HTML Link? Dann kann man testen.
Zitat von: reibuehl am 05 April 2017, 18:48:56
Wäre es möglich statt address ein reading Position einzufügen mit dem Value "https://www.openstreetmap.org/#map=18/<latitude>/<longitude>" als HTML Link? Dann kann man testen.
Sicher könnte man das machen, aber was stört dich daran, dass die Adresse direkt lesbar ist? Wir ja nur einmalig nach dem define abgefragt.
Zitat von: igami am 05 April 2017, 20:11:14
Sicher könnte man das machen, aber was stört dich daran, dass die Adresse direkt lesbar ist?
Mich stört, dass sie falsch ist. Eine meiner Meinung nach unnötige Angabe, die dazu auch noch einen falschen Wert liefert. Mein Sensor ist halt nun mal nicht zwei Strassen weiter sondern an MEINER Adresse. Das es Readings für Latitude und Longitude gibt, sehe ich ein, da diese in den abgefragten Daten enthalten sind. Aber wozu braucht es ein Reading, dass daraus eine falsche Adresse macht?
Vielleicht sollte das reading nur die Plz anzeigen.
Für Tippfehler ausreichend, und nicht "falsch"
neue Version im Anhang. Statt adress gibt es nun location mit PLZ Ort.
Das ist ja was Feines ;D. Das kannte ich auch noch nicht.
Da werden wir bald unser Wetter-/Vogelhaus erweitern.
Wer es noch nicht kennt, es gibt dazu bereits einige Veranstaltungen bundesweit: http://luftdaten.info/veranstaltungen/ (http://luftdaten.info/veranstaltungen/)
Viele Grüße
Rainer
Wenn es soweit keine Änderungsvorschläge mehr gibt würde ich das dann zu morgen einchecken
Will die Laune ja nicht verderben, aber bei mir hat er heute Nacht gegen 03:00 aufgehört Daten zu holen.
die letzten Daten sind von 02:56.
um 3:00 läuft bei mir die automatische Sicherung.
könnte durch die Sicherung verursacht sein. würde aber erwarten dass nach der Sicherung alles weiterläuft.
LIST:
Internals:
CFGFN
CONNECTION remote
DEF 729
INTERVAL 300
NAME Luftdaten_Wolfartsweiher
NR 37642
SENSORID1 729
SENSORID2 730
STATE pm10 9.52 µg/m³ - pm2.5 6.93 µg/m³ - Temp 6.60 °C - 61.60 % rH
TYPE LuftdatenInfo
Helper:
Dblog:
Pm10:
Logdb:
TIME 1491526585.54002
VALUE 9.52
Pm2.5:
Logdb:
TIME 1491526585.54002
VALUE 6.93
State:
Logdb:
TIME 1491461646.02979
VALUE active
Readings:
2017-04-07 02:56:25 PM10 9.52
2017-04-07 02:56:25 PM2.5 6.93
2017-04-07 02:56:25 humidity 61.60
2017-04-06 08:54:11 latitude 48.977
2017-04-06 08:54:12 location 76228 Karlsruhe
2017-04-06 08:54:11 longitude 8.452
2017-04-07 02:56:25 state active
2017-04-07 02:56:25 temperature 6.60
Attributes:
DbLogExclude humidity,latitude,location,longitude,state,temperature
room Klima
stateFormat pm10 PM10 µg/m³ - pm2.5 PM2.5 µg/m³ - Temp temperature °C - humidity % rH
Backup wird blocking ausgeführt, ich bin mir nicht sicher was passiert, wenn der ausführungszeitpunkt eines timers in den Bereich fällt.
Werde ich klären.
Verbose 5 --> Statusrequest manuell --> Auszug aus Log:
2017.04.07 16:57:50 5: LuftdatenInfo (Luftdaten_Wolfartsweiher) - entering LuftdatenInfo_statusRequest
2017.04.07 16:57:50 5: LuftdatenInfo (Luftdaten_Wolfartsweiher) - entering LuftdatenInfo_GetHttpResponse
2017.04.07 16:57:51 5: LuftdatenInfo (Luftdaten_Wolfartsweiher) - entering LuftdatenInfo_ParseHttpResponse
2017.04.07 16:57:51 4: LuftdatenInfo (Luftdaten_Wolfartsweiher) - returned data: [{"id":70182162,"sampling_rate":null,"timestamp":"2017-04-07 14:52:22","location":{"id":349,"latitude":"48.977","longitude":"8.452","country":"DE"},"sensor":{"id":729,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":192007620,"value":"21.73","value_type":"P1"},{"id":192007621,"value":"15.20","value_type":"P2"}]},{"id":70183150,"sampling_rate":null,"timestamp":"2017-04-07 14:53:20","location":{"id":349,"latitude":"48.977","longitude":"8.452","country":"DE"},"sensor":{"id":729,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":192009691,"value":"16.88","value_type":"P1"},{"id":192009692,"value":"14.80","value_type":"P2"}]},{"id":70184135,"sampling_rate":null,"timestamp":"2017-04-07 14:54:19","location":{"id":349,"latitude":"48.977","longitude":"8.452","country":"DE"},"sensor":{"id":729,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":192011750,"value":"21.58","value_type":"P1"},{"id":192011751,"value":"14.00","value_type":"P2"}]},{"id":70185116,"sampling_rate":null,"timestamp":"2017-04-07 14:55:17","location":{"id":349,"latitude":"48.977","longitude":"8.452","country":"DE"},"sensor":{"id":729,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":192013802,"value":"19.88","value_type":"P1"}]},{"id":70185116,"sampling_rate":null,"timestamp":"2017-04-07 14:55:17","location":{"id":349,"latitude":"48.977","longitude":"8.452","country":"DE"},"sensor":{"id":729,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":192013804,"value":"14.97","value_type":"P2"}]},{"id":70186113,"sampling_rate":null,"timestamp":"2017-04-07 14:56:16","location":{"id":349,"latitude":"48.977","longitude":"8.452","country":"DE"},"sensor":{"id":729,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":192015893,"value":"18.65","value_type":"P1"},{"id":192015894,"value":"14.85","value_type":"P2"}]}]
jump to the top
Daten kommen wohl rein, werden aber nicht weiterverarbeitet.
Zitat von: Frank_Huber am 07 April 2017, 17:00:46
Daten kommen wohl rein, werden aber nicht weiterverarbeitet.
Hmm, normal sollten die beiden Zeile
2017.04.07 16:57:50 5: LuftdatenInfo (Luftdaten_Wolfartsweiher) - entering LuftdatenInfo_GetHttpResponse
2017.04.07 16:57:51 5: LuftdatenInfo (Luftdaten_Wolfartsweiher) - entering LuftdatenInfo_ParseHttpResponse
nochmal auftauchen, da ja zwei request gemacht werden.
Ich werde es mir nachher noch mal genauer anschauen.
kannst du bitte noch die Raw definition von einem nicht funktionierendem Zeitpunkt posten? Es gibt noch ein ausgeblendetes Reading .timestamp
Mach ich wenn er wieder aufhört, seit 2 Uhr ca heute Nacht kommen wieder Daten.
Ich habe mir auch einen mit der gleichen ID eingerichtet und bekomme regelmäßig Daten. Und mit dem Backup sollte es nichts zu tun haben.
Ich habe nur diese Zeile eingebaut
return unless($timestamp ge ReadingsVal($SELF, ".timestamp", ""));
mit der geprüft wird ob die erhaltenen Daten neuer sind als die vorhandenen. Um nicht noch einen zweiten request zu starten wenn es eh nichts neues gibt.
Habe es nun trotzdem schon mal ofiziell eingecheckt.
Dabei gibt es noch eine Änderung: Bei der Abfrage bekomme ich immer 5 Werte zurück und bisher hatte ich immer den ältesten verwendet, nun wird der aktuelle genommen. Hatte mich da vertan.
Hallo,
ich würde gerne einen SVG Plot aus den Luftdaten-Werten in FHEM anzeigen lassen, bin aber, was FHEM angeht, leider noch neu und unerfahren.
Kann mir hier jemand auf die Sprünge helfen?
Soweit ich sehen kann müsste erstmal ein FileLog für das Luftdaten Device angelegt werden, und dann braucht man noch ein gplot-File. Aber was soll da drin stehen?
Ich verwende folgendes SVG gplot File:
# Created by FHEM/98_SVG.pm, 2017-04-02 19:23:32
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics
set y2tics
set grid ytics
set ylabel "µg/m³"
set y2label "µg/m³"
set yrange [0:200]
set y2range [0:200]
#logdb Feinstaub:PM10
#logdb Feinstaub:PM2.5
plot "<IN>" using 1:2 axes x1y1 title 'PM10' ls l3 lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'PM2.5' ls l2 lw 1 with lines
Benutzt logdb statt Logfile.
Ich werde bei Gelegenheit mal gplot erstellen dateien einchecken
Für neue Plots kopiere ich meist ein bestehendes und andere dann die Devices/Readings ab. (dblog)
Btw: keine weiteren Ausfälle beim Daten holen bis jetzt.
online! ID: 1651
Hallo zusammen,
nachdem ich Euren Thread gelesen habe, habe ich die "Große" HMUART Platine https://forum.fhem.de/index.php?action=dlattach;topic=56606.0;attach=76061 so erweitert, dass sie auch für einen Luftdatensensor passt. Es wäre klasse, wenn jemand von Euch noch mal über den Schaltplan schauen könnte.
Gruß PeMue
Ich habe gestern den Sensor nachgebaut, bei Luftdaten.info registriert und das Modul in Betrieb genommen. Es funktioniert auch und die Feinstaubdaten laufen regelmäßig ein. Leider werden irgendwann keine DHT22 Daten mehr abgerufen. Man sieht im verbose 5 Log nur noch den Aufruf und die Antwort vom SDS011. Nach einem "shutdown restart" werden wieder ein paar mal beide Sensoren abgefragt, bis irgendwann wieder nur noch der SDS011 abgefragt wird. Vermutlich wird bei einer ausbleibenden Antwort (timeout etc) der zweite Sensor deaktiviert. Ich bin der Meinung, das man das nicht tun sollte wenn der zweite Sensor bewußt im Define angegeben ist. Damit teilt der Nutzer ja mit, das der Sensor da ist. Ich habe als workaround für mich erstmal die Zeile 238 auskommentiert. Kann damit leben, wenn mal ein Wert fehlt.
hier die Device Daten:
Internals:
CONNECTION remote
DEF 1679 1680
INTERVAL 300
NAME Luftdaten
NR 292
SENSORID1 1679
STATE active
TYPE LuftdatenInfo
Helper:
Dblog:
Pm10:
Logdb:
TIME 1492324238.50584
VALUE 5.42
Pm2.5:
Logdb:
TIME 1492324238.50584
VALUE 2.70
Humidity:
Logdb:
TIME 1492321538.94285
VALUE 42.40
State:
Logdb:
TIME 1492324238.50584
VALUE active
Temperature:
Logdb:
TIME 1492321538.94285
VALUE 7.30
Readings:
2017-04-16 08:30:38 PM10 5.42
2017-04-16 08:30:38 PM2.5 2.70
2017-04-16 07:45:38 humidity 42.40
2017-04-15 12:45:14 latitude 51.795
2017-04-15 12:45:14 location 06849
2017-04-15 12:45:14 longitude 12.258
2017-04-16 08:30:38 state active
2017-04-16 07:45:38 temperature 7.30
Attributes:
verbose 5
Erfolgreicher Abruf nach restart:
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_statusRequest
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_GetHttpResponse
2017-04-16 07:45:38 ESPEasy ESPEasy_sonoff_5_Schalter Relay: off
2017-04-16 07:45:38 ESPEasy ESPEasy_sonoff_5_Schalter R: -84.00 R: off
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_ParseHttpResponse
2017.04.16 07:45:38 4 : LuftdatenInfo (Luftdaten) - returned data: [{"id":83355927,"sampling_rate":null,"timestamp":"2017-04-16 05:40:04","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1679,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":219687848,"value":"5.32","value_type":"P1"},{"id":219687849,"value":"2.77","value_type":"P2"}]},{"id":83357043,"sampling_rate":null,"timestamp":"2017-04-16 05:41:03","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1679,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":219690196,"value":"6.50","value_type":"P1"},{"id":219690197,"value":"3.62","value_type":"P2"}]}]
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - returned data is newer than readings
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - parsing SDS011 data
2017-04-16 07:45:38 LuftdatenInfo Luftdaten PM10: 6.50
2017-04-16 07:45:38 LuftdatenInfo Luftdaten PM2.5: 3.62
2017-04-16 07:45:38 LuftdatenInfo Luftdaten active
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_GetHttpResponse
2017-04-16 07:45:38 CUL_FHTTK OG.kz.TK.Kinderzimmertuer Window: Closed
2017-04-16 07:45:38 CUL_FHTTK OG.kz.TK.Kinderzimmertuer Reliability: ok
2017-04-16 07:45:38 CUL_FHTTK OG.kz.TK.Kinderzimmertuer Battery: ok
2017-04-16 07:45:38 CUL_FHTTK OG.kz.TK.Kinderzimmertuer Closed
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_ParseHttpResponse
2017.04.16 07:45:38 4 : LuftdatenInfo (Luftdaten) - returned data: [{"id":83355953,"sampling_rate":null,"timestamp":"2017-04-16 05:40:05","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1680,"pin":"7","sensor_type":{"id":9,"name":"DHT22","manufacturer":"various"}},"sensordatavalues":[{"id":219687900,"value":"7.30","value_type":"temperature"},{"id":219687901,"value":"42.50","value_type":"humidity"}]},{"id":83357072,"sampling_rate":null,"timestamp":"2017-04-16 05:41:04","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1680,"pin":"7","sensor_type":{"id":9,"name":"DHT22","manufacturer":"various"}},"sensordatavalues":[{"id":219690254,"value":"7.30","value_type":"temperature"},{"id":219690255,"value":"42.40","value_type":"humidity"}]},{"id":83358414,"sampling_rate":null,"timestamp":"2017-04-16 05:42:15","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1680,"pin":"7","sensor_type":{"id":9,"name":"DHT22","manufacturer":"various"}},"sensordatavalues":[{"id":219693070,"value":"7.40","value_type":"temperature"},{"id":219693071,"value":"42.80","value_type":"humidity"}]},{"id":83359777,"sampling_rate":null,"timestamp":"2017-04-16 05:43:29","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1680,"pin":"7","sensor_type":{"id":9,"name":"DHT22","manufacturer":"various"}},"sensordatavalues":[{"id":219695923,"value":"7.30","value_type":"temperature"},{"id":219695924,"value":"42.40","value_type":"humidity"}]}]
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - returned data is newer than readings
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - parsing DHT22 data
2017-04-16 07:45:38 LuftdatenInfo Luftdaten temperature: 7.30
2017-04-16 07:45:38 LuftdatenInfo Luftdaten humidity: 42.40
2017-04-16 07:45:38 LuftdatenInfo Luftdaten active
irgendwann kommt das:
2017.04.16 07:50:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_statusRequest
2017.04.16 07:50:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_GetHttpResponse
2017.04.16 07:50:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_ParseHttpResponse
2017.04.16 07:50:38 4 : LuftdatenInfo (Luftdaten) - returned data: [{"id":83366710,"sampling_rate":null,"timestamp":"2017-04-16 05:49:39","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1679,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":219710410,"value":"4.97","value_type":"P1"},{"id":219710411,"value":"2.98","value_type":"P2"}]}]
2017.04.16 07:50:38 5 : LuftdatenInfo (Luftdaten) - returned data is newer than readings
2017.04.16 07:50:38 5 : LuftdatenInfo (Luftdaten) - parsing SDS011 data
2017-04-16 07:50:38 LuftdatenInfo Luftdaten PM10: 4.97
2017-04-16 07:50:38 LuftdatenInfo Luftdaten PM2.5: 2.98
2017-04-16 07:50:38 LuftdatenInfo Luftdaten active
2017.04.16 07:50:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_GetHttpResponse
2017-04-16 07:50:38 ESPEasy ESPEasy_sonoff_5_Schalter Relay: off
2017-04-16 07:50:38 ESPEasy ESPEasy_sonoff_5_Schalter R: -84.00 R: off
2017.04.16 07:50:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_ParseHttpResponse
2017.04.16 07:50:38 2 : LuftdatenInfo (Luftdaten) - no second sensor found
und dann wird nur noch der Feinstaubsensor abgefragt:
2017.04.16 07:55:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_statusRequest
2017.04.16 07:55:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_GetHttpResponse
2017.04.16 07:55:38 5 : LuftdatenInfo (Luftdaten) - entering LuftdatenInfo_ParseHttpResponse
2017.04.16 07:55:38 4 : LuftdatenInfo (Luftdaten) - returned data: [{"id":83368197,"sampling_rate":null,"timestamp":"2017-04-16 05:50:58","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1679,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":219713540,"value":"5.45","value_type":"P1"},{"id":219713541,"value":"2.63","value_type":"P2"}]},{"id":83369333,"sampling_rate":null,"timestamp":"2017-04-16 05:51:59","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1679,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":219715919,"value":"5.77","value_type":"P1"},{"id":219715920,"value":"2.67","value_type":"P2"}]},{"id":83370444,"sampling_rate":null,"timestamp":"2017-04-16 05:52:58","location":{"id":838,"latitude":"51.795","longitude":"12.258","country":"DE"},"sensor":{"id":1679,"pin":"1","sensor_type":{"id":14,"name":"SDS011","manufacturer":"Nova Fitness"}},"sensordatavalues":[{"id":219718245,"value":"6.82","value_type":"P1"},{"id":219718246,"value":"3.63","value_type":"P2"}]}]
2017.04.16 07:55:38 5 : LuftdatenInfo (Luftdaten) - returned data is newer than readings
2017.04.16 07:55:38 5 : LuftdatenInfo (Luftdaten) - parsing SDS011 data
2017-04-16 07:55:38 LuftdatenInfo Luftdaten PM10: 6.82
2017-04-16 07:55:38 LuftdatenInfo Luftdaten PM2.5: 3.63
2017-04-16 07:55:38 LuftdatenInfo Luftdaten active
Zitat von: PeMue am 14 April 2017, 11:13:46
nachdem ich Euren Thread gelesen habe, habe ich die "Große" HMUART Platine https://forum.fhem.de/index.php?action=dlattach;topic=56606.0;attach=76061 so erweitert, dass sie auch für einen Luftdatensensor passt. Es wäre klasse, wenn jemand von Euch noch mal über den Schaltplan schauen könnte.
Ich bin kein Bastler in dem Sinne und kann dazu leider nichts sagen.
Hallo zusammen,
Zitat von: Waldmensch am 16 April 2017, 08:38:07
Ich habe gestern den Sensor nachgebaut, bei Luftdaten.info registriert und das Modul in Betrieb genommen. Es funktioniert auch und die Feinstaubdaten laufen regelmäßig ein. Leider werden irgendwann keine DHT22 Daten mehr abgerufen. Man sieht im verbose 5 Log nur noch den Aufruf und die Antwort vom SDS011. Nach einem "shutdown restart" werden wieder ein paar mal beide Sensoren abgefragt, bis irgendwann wieder nur noch der SDS011 abgefragt wird. Vermutlich wird bei einer ausbleibenden Antwort (timeout etc) der zweite Sensor deaktiviert. Ich bin der Meinung, das man das nicht tun sollte wenn der zweite Sensor bewußt im Define angegeben ist. Damit teilt der Nutzer ja mit, das der Sensor da ist. Ich habe als workaround für mich erstmal die Zeile 238 auskommentiert. Kann damit leben, wenn mal ein Wert fehlt.
Ich werde einstellen, dass der Sensor 3x keine Daten liefern muss, bis er entfernt wird.
Warum machst Du es nicht so, dass er entfernt wird, wenn das Modul ihn selber gesucht hat. Wenn der Nutzer den Sensor explizit im DEF angegeben hat, lässt Du ihn drin. Wenn FHEM einfach mal für 3x Intervall kein Internet hat, würde der Sensor ja immer gelöscht werden. Ich würde da schon auf den User hören, der sagt das der Sensor existiert, und den Sensor abfragen.
Oder füge die erlaubten Fehlversuche als Attribut ein, das man sie selber auf 1000 o.ä. setzen kann, wenn man das Verhalten nicht möchte.
Gesendet von iPhone mit Tapatalk
Zitat von: Waldmensch am 17 April 2017, 18:22:37
Warum machst Du es nicht so, dass er entfernt wird, wenn das Modul ihn selber gesucht hat. Wenn der Nutzer den Sensor explizit im DEF angegeben hat, lässt Du ihn drin. Wenn FHEM einfach mal für 3x Intervall kein Internet hat, würde der Sensor ja immer gelöscht werden. Ich würde da schon auf den User hören, der sagt das der Sensor existiert, und den Sensor abfragen.
Oder füge die erlaubten Fehlversuche als Attribut ein, das man sie selber auf 1000 o.ä. setzen kann, wenn man das Verhalten nicht möchte.
Wenn keine Internetverbindung besteht wird das als Fehler ins Log geschrieben, aber keine SensorID gelöscht.
Habe es jetzt so gelöst wie du vorgeschlagen hast: Die Sensor ID wird nur gelöscht, wenn der Sensor nicht explizit angegeben wurde. Ist dann ab morgen verfügbar.
Cool! Vielen Dank :)
Gesendet von iPhone mit Tapatalk
Ich habe mir auch eine Feinstaubsensor SDS011 bestellt, will den aber nur lokal mit fhem verwenden. Ich will also nicht, dass irgendetwas rausgeschickt wird ins Inrnet / zu luftdaten.info. Geht das mit der bestehenden Software?
Ansonsten dachte ich an die ESPEasy firmware anstelle der luftdaten.info firmware. ESPEasy ist ja sehr gut an fhem anzubinden. Hat mal jemand ESPEasy + fhem mit dem SDS011 sensor probiert und zum Laufen bekommen?
Schau Dir mal das MH-Z19 Plugin (https://github.com/letscontrolit/ESPEasy/blob/mega/src/_P049_MHZ19.ino) an, dieser CO2 Sensor wird ebenfalls seriell angesprochen. Sollte sich mit etwas Zeit und Spucke entsprechend anpassen lassen.
Ja, das geht. Musst nur in deinem Router die IP für das Internet sperren. Evtl kannst es auch direkt in der Software abschalten.
Meiner persönlichen Meinung nach solltest du das aber nicht machen. Du nutzt die Software von dem Projekt, dann kannst doch auch die Daten hinschicken. Sind dich nur die Luftdaten und es ist ja auch keine Behörde.
Nur meine Meinung. Nicht zur Diskussion gedacht...
Gesendet von meinem JY-S3 mit Tapatalk
hintergrund ist, dass ich den sensor verwenden will um den feinstaub im innenraum verursacht von kamin, laserdrucker, staubsauger etc zu messen. das wäre uninteressant für das projekt luftdaten.info bzw wären falsche daten.
kann ich den sensor ohne regisrtierung bei luftdaten.imfo verwenden und kann man per konfiguration verhindern, dass er irgendwas ins netz schickt?
man kann natürlich auch die firewall dicht machen zur not. ginge dann der sensor noch?
Du kannst einfach das Modul dafür verwenden und die IP Adresse als DEF eintragen. In der Konfigurationsseite vom Sensor kannst du das senden an luftdaten.info ausschalten.
danke, klingt gut. probiere ich so wenn er ankommt. danke für das entwickeln des fhem moduls!
Zitat von: igami am 22 April 2017, 12:49:48
In der Konfigurationsseite vom Sensor kannst du das senden an luftdaten.info ausschalten.
Ah, ist die Option drin. war mir da nicht sicher. :)
siehe Anhang
Hätte ich dir auch so geglaubt.
Damit der Post nicht ganz off topic ist, hat einer von euch dem BME280 angeschlossen? Würde das Modul die entsprechenden Daten abrufen?
Gesendet von meinem JY-S3 mit Tapatalk
Zitat von: dev0 am 22 April 2017, 12:43:05
Schau Dir mal das MH-Z19 Plugin (https://github.com/letscontrolit/ESPEasy/blob/mega/src/_P049_MHZ19.ino) an, dieser CO2 Sensor wird ebenfalls seriell angesprochen. Sollte sich mit etwas Zeit und Spucke entsprechend anpassen lassen.
danke, das wäre auch noch eine option. die spec des sds011 inkl uart protokoll spec findet man ja unter http://breathe.indiaspend.org/wp-content/uploads/2015/11/nova_laser_sensor.pdf (http://breathe.indiaspend.org/wp-content/uploads/2015/11/nova_laser_sensor.pdf)
Zitat von: Frank_Huber am 22 April 2017, 13:24:19
Damit der Post nicht ganz off topic ist, hat einer von euch dem BME280 angeschlossen? Würde das Modul die entsprechenden Daten abrufen?
Nein, wird noch nicht ausgewertet, ab morgen aber ;)
na das ging ja schnell. ;o) danke.
hab aber meinen BME280 noch gar nicht. der ist noch irgendwo zwischen China und Deutschland...
Das Modul liefert mir keine Daten :/
Zitat2017.04.23 17:36:56 2: LuftdatenInfo (Feinstaub) - no data returned
Mit HTTPMOD hats ganz gut geklappt
Zitat von: Pr3mut05 am 23 April 2017, 17:40:20
Das Modul liefert mir keine Daten :/
Mit HTTPMOD hats ganz gut geklappt
Poste mal bitte ein list.
Bist du dir mit der ID sicher?
Zitat
Internals:
CFGFN
CONNECTION remote
DEF 3997542
INTERVAL 300
NAME Feinstaub
NR 47
SENSORID1 3997542
SENSORID2 3997543
SENSORIDS implicit
STATE no data
TIMEOUT 5
TYPE LuftdatenInfo
Readings:
2017-04-23 17:50:40 state no data
Attributes:
room Wetter
ID ist mein eigener Sensor und korrekt
Über HTTPMOD wird alles korrekt ausgelesen
Ah
OK
Ich muss die Sensor ID aus der Karte nehmen
Jetzt klappts
Zitat von: Pr3mut05 am 23 April 2017, 17:57:09
Allerdings habe ich hier keine Temperatur :/
Du hast keinen Sensor, oder du bekommst keine Daten?
Mit Eingabe des zweiten Sensor Wertes hat es dann geklappt
Danke
Normal sollte das nicht nötig sein, da die TemperaturSensorID eine Stelle größer ist als die FeinstaubSensorID. Ist das bei dir anders?
Zitat von: KyleK am 09 April 2017, 20:51:31
Hallo,
ich würde gerne einen SVG Plot aus den Luftdaten-Werten in FHEM anzeigen lassen, bin aber, was FHEM angeht, leider noch neu und unerfahren.
Kann mir hier jemand auf die Sprünge helfen?
Soweit ich sehen kann müsste erstmal ein FileLog für das Luftdaten Device angelegt werden, und dann braucht man noch ein gplot-File. Aber was soll da drin stehen?
Dafür könnte ich auch eine "Dummy" Anleitung brauchen :P
Mit den SVG Plot komm ich noch gar nicht zu Recht :/
Zitat von: Pr3mut05 am 23 April 2017, 18:20:13
Dafür könnte ich auch eine "Dummy" Anleitung brauchen :P
Mit den SVG Plot komm ich noch gar nicht zu Recht :/
Das hat nun aber nix mit dem Thema hier zu tun, falls du wirklich nicht weiter kommst bitte einen neuen Thread erstellen.
1. FileLog oder DbLog vorhanden? Falls nein: erstellen. Wie das geht? Commandref, Wiki
2. im LogDevice auf 'Create SVG plot' klicken
3. im Plot Editor das SVG so zusammenklicken wie du es haben möchtest
Hallo igami,
Ich habe mir auch einen Sensor zugelegt und dabei gesehen, dass es im Sensor einen Punkt "Sende an eigene API" gibt. Hat es einen Grund, dass du pollst und dich nicht von dem Sensor triggern läßt?
Horst
Zitat von: Harst am 01 Mai 2017, 09:53:33
Hallo igami,
Ich habe mir auch einen Sensor zugelegt und dabei gesehen, dass es im Sensor einen Punkt "Sende an eigene API" gibt. Hat es einen Grund, dass du pollst und dich nicht von dem Sensor triggern läßt?
Horst
Ich hatte das am Anfang vor, dann aber schnell festgestellt, dass ich nicht weiß wie man das programmieren soll :D
Weiterhin bietet die Pull Methode auch die Möglichkeit Daten von Luftdaten.info abzurufen, also auch fremde Sensoren zu verwenden. Auch muss man so nur die FHEM Seite einstellen und nicht noch zusätzlich was im Sensor.
Hallo,
ich benutze aktuell die "software_version": "NRZ-2017-078". Hier wird bei Aktivierung des BME280 folgendes json ausgegeben:
{"software_version": "NRZ-2017-078", "sensordatavalues":[{"value_type":"SDS_P1","value":"18.90"},{"value_type":"SDS_P2","value":"15.66"},{"value_type":"BME280_temperature","value":"22.27"},{"value_type":"BME280_humidity","value":"45.73"},{"value_type":"BME280_pressure","value":"101164.59"},{"value_type":"samples","value":"790124"},{"value_type":"min_micro","value":"180"},{"value_type":"max_micro","value":"27928"},{"value_type":"signal","value":"-74 dBm"}]}
Für die lokale Abfrage würde ich gerne die beigefügte Codeänderung vorschlagen:
elsif($connection eq "local"){
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, "software_version", $data->{software_version});
my $sensor;
foreach (@{$data->{sensordatavalues}}){
$_->{value} =~ m/^(\S+)(\s|$)/; ???? Was macht diese Zeile. Habe ich nicht verstanden!
$sensor = $1;
readingsBulkUpdate($hash, $_->{value_type}, $sensor);
}
readingsBulkUpdate($hash, "state", "active");
readingsEndUpdate($hash, 1);
}
}
Hinzugenommen habe ich noch die Ausgabe der Firmwareversion.
Grüße Jörg
PS: Ob die Änderung für die Remoteabfrage auch notwendig ist, habe ich noch nicht geprüpft.
Zitat von: JoWiemann am 04 Mai 2017, 16:58:27
Für die lokale Abfrage würde ich gerne die beigefügte Codeänderung vorschlagen:
elsif($connection eq "local"){
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, "software_version", $data->{software_version});
my $sensor;
foreach (@{$data->{sensordatavalues}}){
$_->{value} =~ m/^(\S+)(\s|$)/; ???? Was macht diese Zeile. Habe ich nicht verstanden!
$sensor = $1;
readingsBulkUpdate($hash, $_->{value_type}, $sensor);
}
readingsBulkUpdate($hash, "state", "active");
readingsEndUpdate($hash, 1);
}
}
Wofür benötigst du die Software Version in FHEM? Kann das einchecken, sehe aber noch keinen Nutzen.
Die Abfrage der Luftdruck Werte funktioniert problemlos?
Welche Modul Version hast du? Bei der aktuellen Version 14070 sieht der code an der Stelle, mit eingebauter softwareVersion, so aus:
elsif($connection eq "local"){
readingsBeginUpdate($hash);
readingsBulkUpdateIfChanged(
$hash, "softwareVersion", $data->{software_version}
);
foreach (@{$data->{sensordatavalues}}){
$_->{value} =~ m/^(\S+)(\s|$)/;
if($_->{value_type} eq "temperature"){
readingsBulkUpdate($hash, "temperature", $1);
}
elsif($_->{value_type} eq "humidity"){
readingsBulkUpdate($hash, "humidity", $1);
}
elsif($_->{value_type} eq "pressure"){
readingsBulkUpdate($hash, "pressure", $1);
}
elsif($_->{value_type} eq "SDS_P1"){
readingsBulkUpdate($hash, "PM10", $1);
}
elsif($_->{value_type} eq "SDS_P2"){
readingsBulkUpdate($hash, "PM2.5", $1);
}
elsif($_->{value_type} eq "signal"){
readingsBulkUpdate($hash, "signal", $1);
}
}
readingsBulkUpdate($hash, "state", "active");
readingsEndUpdate($hash, 1);
}
Die Zeile
$_->{value} =~ m/^(\S+)(\s|$)/;
belegt die Variable $1 mit dem Wert des Readings ohne einheit. Bei signal stände sonst "-74 dBm" was zu Problemen beim plotten oder so führen könnte. Einheiten gehören meiner Meinung nach nicht in die Readings, sondern nur in die commandref, damit man weiß welche Einheit das Reading hat.
Hallo,
hm, ich habe eine Update gemacht. Bei mir gibt es die Softwareversion noch nicht.
Die Zuordnung der BME280 Werte funktioniert definitiv nicht, da das json immer BME280_ im value_type voran stellt.
Die Firmwareversion macht es nur einfacher bei der Fehleranalyse. Wenn jemand ein list vom Device postet ist sie dann halt sofort dabei. Jedenfalls machen das die meisten Devices in Fhem so.
Grüße Jörg
würde dann jetzt folgende Änderungen einchecken:
Index: FHEM/59_LuftdatenInfo.pm
===================================================================
--- FHEM/59_LuftdatenInfo.pm (Revision 14184)
+++ FHEM/59_LuftdatenInfo.pm (Arbeitskopie)
@@ -352,13 +352,13 @@
foreach (@{$sensor->{sensordatavalues}}){
$_->{value} =~ m/^(\S+)(\s|$)/;
- if($_->{value_type} eq "temperature"){
+ if($_->{value_type} =~ /temperature$/){
readingsBulkUpdate($hash, "temperature", $1);
}
- elsif($_->{value_type} eq "humidity"){
+ elsif($_->{value_type} =~ /humidity$/){
readingsBulkUpdate($hash, "humidity", $1);
}
- elsif($_->{value_type} eq "pressure"){
+ elsif($_->{value_type} =~ /pressure$/){
readingsBulkUpdate($hash, "pressure", $1);
}
}
@@ -370,17 +370,20 @@
}
elsif($connection eq "local"){
readingsBeginUpdate($hash);
+ readingsBulkUpdateIfChanged(
+ $hash, "softwareVersion", $data->{software_version}
+ );
foreach (@{$data->{sensordatavalues}}){
$_->{value} =~ m/^(\S+)(\s|$)/;
- if($_->{value_type} eq "temperature"){
+ if($_->{value_type} =~ /temperature$/){
readingsBulkUpdate($hash, "temperature", $1);
}
- elsif($_->{value_type} eq "humidity"){
+ elsif($_->{value_type} =~ /humidity$/){
readingsBulkUpdate($hash, "humidity", $1);
}
- elsif($_->{value_type} eq "pressure"){
+ elsif($_->{value_type} =~ /pressure$/){
readingsBulkUpdate($hash, "pressure", $1);
}
elsif($_->{value_type} eq "SDS_P1"){
Damit wird die software_version als Reading softwareVersion bereitgestellt und es kann ein belibiges prefix vor den value_type stehen.
Das mit dem beliebigen Präfix hatte ich auch erst überlegt, aber was ist wenn Du einen BMP180 und einen BME280 angeschlossen hast?
Grüße Jörg
PS: Ich würde auch nicht die Daten, die geliefert werden, selektiv behandeln, sondern alle Informationen in Readings ablegen. Ist allerdings meine private Meinung. Ggf. kann man das ja auch über ein Attribut regeln.
Grüße Jörg, ach ja und was wir immer vergessen: Danke für das Modul.
Zitat von: JoWiemann am 04 Mai 2017, 20:14:47
PS: Ich würde auch nicht die Daten, die geliefert werden, selektiv behandeln, sondern alle Informationen in Readings ablegen. Ist allerdings meine private Meinung. Ggf. kann man das ja auch über ein Attribut regeln.
Da lässt sich drüber Streiten. vorallen wird dann bestimmt die Frage gestellt was min_micro und max_micro ist. Ich habe keine Ahnung. Könnte ich eigentlich mal in Erfahrung bringen. Und die Proben nummer, würde auch nur Events erzeugen ohne einen Nutzen zu bringen.
{"value_type":"samples","value":"790124"},{"value_type":"min_micro","value":"180"},{"value_type":"max_micro","value":"27928"}
Zitat von: JoWiemann am 04 Mai 2017, 20:14:47
Grüße Jörg, ach ja und was wir immer vergessen: Danke für das Modul.
Das hört man gerne. Eine gute Community ist aber auch wichtig um das Projekt voran zu bringen :)
Die Werte min_micro und max_micro würde ich als kleinste und größte Zeit für einen Schleifendurchlauf (Probennahme) interprtieren. Sieht jedenfalls im Source danach aus.
Wie Werte, inkl. samples, könnten hilfreich sein beim debuggen. Vielleicht dann doch wenigstens ab verbose 4 ins log schreiben?
Grüße Jörg
PS: Sofern noch nicht im Blick kannst Du bei $rv = readingsSingleUpdate($hash, $reading, $value, $do_trigger); und auch bei readingsEndUpdate($hash, $do_trigger); bestimmen ob ein Event ausgelöst wird , oder nicht.
Siehe auch:https://wiki.fhem.de/wiki/DevelopmentModuleAPI
Grüße Jörg
Zitat von: JoWiemann am 04 Mai 2017, 20:59:16
Die Werte min_micro und max_micro würde ich als kleinste und größte Zeit für einen Schleifendurchlauf (Probennahme) interprtieren. Sieht jedenfalls im Source danach aus.
Wie Werte, inkl. samples, könnten hilfreich sein beim debuggen. Vielleicht dann doch wenigstens ab verbose 4 ins log schreiben?
Ab Verbose 4 wird das gesamte JSON ins Log gechrieben.
Zitat von: JoWiemann am 04 Mai 2017, 21:08:22
PS: Sofern noch nicht im Blick kannst Du bei $rv = readingsSingleUpdate($hash, $reading, $value, $do_trigger); und auch bei readingsEndUpdate($hash, $do_trigger); bestimmen ob ein Event ausgelöst wird , oder nicht.
Siehe auch:https://wiki.fhem.de/wiki/DevelopmentModuleAPI
Das ist mir bekannt. Trotzdem vielen dank
Zitat von: JoWiemann am 04 Mai 2017, 19:24:34
Das mit dem beliebigen Präfix hatte ich auch erst überlegt, aber was ist wenn Du einen BMP180 und einen BME280 angeschlossen hast?
Habe es jetzt erstmal wie geschrieben eingecheckt. Im device habe ich ja momentan nur ein temperatur Reading. Wie sollte ich mit zwei Messwerten umgehen?
Zitat von: igami am 04 Mai 2017, 21:16:32
Ab Verbose 4 wird das gesamte JSON ins Log geschrieben.
Ah, hatte ich übersehen.
Grüße Jörg
Zitat von: igami am 04 Mai 2017, 21:39:08
Habe es jetzt erstmal wie geschrieben eingecheckt. Im device habe ich ja momentan nur ein temperatur Reading. Wie sollte ich mit zwei Messwerten umgehen?
Ich würde als Reading die value_type der Sensoren übernehmen, wie sie von der Firmware geliefert werden.
Grüße Jörg
Zitat von: JoWiemann am 04 Mai 2017, 19:24:34
Das mit dem beliebigen Präfix hatte ich auch erst überlegt, aber was ist wenn Du einen BMP180 und einen BME280 angeschlossen hast?
Hast du vor das zu machen? Vermutlich würde man dann eine weitere ID für den Sensor bekommen.
Aber warum sollte man zwei Sensoren die das gleiche Messen einbauen?
Zitat von: JoWiemann am 04 Mai 2017, 22:23:16
Ich würde als Reading die value_type der Sensoren übernehmen, wie sie von der Firmware geliefert werden.
Ich bin dafür, dass in FHEM die Readings einheitlich benannt sind.
Für AV Geräte gibt es das schon https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV
Zitat von: igami am 05 Mai 2017, 05:50:25
Hast du vor das zu machen? Vermutlich würde man dann eine weitere ID für den Sensor bekommen.
Aber warum sollte man zwei Sensoren die das gleiche Messen einbauen?
Weil ich meinen nodeMCU getrennt vom Feinstoffpartikelsensor betreibe. Der nodeMCU befindet sich im Raum und von dort geht ein Mehrpolkabel zum Gehäuse des Feinstaubsensors, in dem sich auch der BME280 befindet. Den BMP180, hatte ich noch in der Bastellkiste, benutze ich zur Erfassung der Temp/Feuchte im Raum. Damit kann ich den bisherigen Funksensor für etwas anderes nutzen.
Ich überlege noch die Firmware um einen TLS2561 (Luminosity) zu erweitern. Damit wäre dann ein kompletter Umweltsensor vorhanden. Schick wäre dann nur noch ein UV Sensor. :)
Zitat von: igami am 05 Mai 2017, 05:50:25
Ich bin dafür, dass in FHEM die Readings einheitlich benannt sind.
Für AV Geräte gibt es das schon https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV
Das mag für bestimmte Aufgaben durchaus sinnvoll sein. Bei Multisensordevices halte ich das für einengend. Ich betreibe ein ESP-Easy Device im Keller. Hier erfasse ich über drei BMP180 die Daten von drei Räumen. Das spart einfach Devices. Der ESP hängt im Kellerflur und von da aus gehen dann drei kurze Leitungen in die zu monitorenden Räume.
Mir würde es helfen, wenn ich über ein Attribut einstellen könnte, ob ich alle Werte aus dem json im Original haben kann oder halt eine "bereinigte" Datentiefe.
Grüße Jörg
Hallo Gemeinde, hallo igami,
erst mal vielen Dank für das tolle Modul was mich gleich wieder zum basteln angeregt hat.
Nun, nutze ich aber so wie JoWiemann, neben dem SDS011 für die Feinstaubmessung und dem zusätzlichen DHT22 für Temperatur und Luftfeuchte noch zusätzlich einen BMP180, allerding zur Luftdruckmessung (liefert auch noch eine Temperatur). Soweit funktioniert das auch, leider ist luftdaten.info momentan nicht erreichbar, ich konnte mich da noch nicht anmelden, aber bei opensensemap.org kommen die Daten an.
In FHEM (Einstellung local über IP) erhalte ich auch die Daten für PM2.5, PM10, Temperatur und Luftfeuchte vom DHT22, also alles soweit super, es wäre aber schön auch noch die Werte vom BMP180 in FHEM zu erhalten. Ich denke läuft auf das gleiche hinaus wie bei JoWiemann.
Beste Grüße und vielen Dank
Manuel
Edit: seit dem letzten Update erhalte ich keine Werte mehr local für temperatur und huminity
Guten Abend,
scheinbar hat das Modul mein FHEM nach folgender Meldung in die Knie gezwungen:
malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<!DOCTYPE HTML PUBLI...") at ./FHEM/59_LuftdatenInfo.pm line 265.
Die Meldung habe ich heute auch bekommen.
Es scheint manchmal kein JSON zurück zu kommen.
Weiß jemand wie man simpel prüfen kann ob es ein json ist?
Hmmmm. Meine Instanz wo das Modul läuft ist auch schon 4 mal ohne Grund abgestürzt. Jessie lief, fhem war aus, ließ sich aber problemlos wieder starten. Ich Kuck später mal ins log. Die 3 abstürze von heute sollte ich noch finden.
Gesendet von meinem S3_32 mit Tapatalk
Ich würde jetzt einfach mal Prüfen ob der Rückgabewert in [ ] eingefasst ist. Ansonten brächte man ein extra Perl Modul
Hab das error handling grad eingebaut, ist dann ab morgen verfügbar.
Zitat von: MaMi7880 am 06 Mai 2017, 14:16:27
Edit: seit dem letzten Update erhalte ich keine Werte mehr local für temperatur und huminity
Sowas bitte nicht als Edit schreiben, darüber bekomme ich keine Benachrichtigung.
Meine Idee: ein Attribut in dem man die Sensoren die ausgewertet werden sollen auswählen kann. Dann wäre für den zweiten Sensor ein neues device notwendig. Die Readings bleiben dann aber temperature und humidity.
Ist das okay?
Nur der Vollständigkeit halber:
2017.05.07 18:20:46 2: LuftdatenInfo (Luftdaten_Wolfartsweiher) - error while request: read from http://api.luftdaten.info:80 timed out
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "<!DOCTYPE HTML PUBLI...") at ./FHEM/59_LuftdatenInfo.pm line 265.
Bei 3 fhem crashes heute die letzte log Zeile.
Gesendet von meinem S3_32 mit Tapatalk
Irgendwie vermute ich, dass die ID manchmal nicht richtig ausgewerte wird und man dann diese URL aufruft: http://api.luftdaten.info/v1/sensor//
Aber das sollte mit dem update heute dann auch kein Problem mehr sein.
Zitat von: igami am 07 Mai 2017, 21:25:16
Die Readings bleiben dann aber temperature und humidity.
Ist das okay?
Hallo,
grundsätzlich ja. Würde dann wie bei der EspEasy-Bridge funktionieren. Warum aber die Auswahl per Attribut? Ich würde die gefundenen Sensoren dann alle anlegen lassen.
Grüße Jörg
Zitat von: igami am 08 Mai 2017, 05:43:06
Irgendwie vermute ich, dass die ID manchmal nicht richtig ausgewerte wird und man dann diese URL aufruft: http://api.luftdaten.info/v1/sensor//
Aber das sollte mit dem update heute dann auch kein Problem mehr sein.
Update installiert und die Devces wieder aktiviert.
jetzt heist es abwarten. ;)
Danke für den schnellen fix!
Zitat von: igami am 07 Mai 2017, 21:25:16
Hab das error handling grad eingebaut, ist dann ab morgen verfügbar.
Sowas bitte nicht als Edit schreiben, darüber bekomme ich keine Benachrichtigung.
Meine Idee: ein Attribut in dem man die Sensoren die ausgewertet werden sollen auswählen kann. Dann wäre für den zweiten Sensor ein neues device notwendig. Die Readings bleiben dann aber temperature und humidity.
Ist das okay?
Sorry, das nächste mal achte ich drauf.
Da der zweite Sensor eh "Zusatz" zum eigentlichen Luftdaten.info-Sensor ist, ist dein Vorschlag mehr als okay. Ich persönlich sammel mir die Daten eh in einer readingsgroup zusammen, da macht ein Device mehr nichts aus.
Gruß
Manuel
Habe soeben das update durchgeführt, jetzt bekomme ich:
2017.05.09 00:43:22 2: LuftdatenInfo (FeinStaub) - error while request: malformed JSON string
2017.05.09 00:43:37 5: LuftdatenInfo (FeinStaub) - entering LuftdatenInfo_statusRequest
2017.05.09 00:43:37 5: LuftdatenInfo (FeinStaub) - entering LuftdatenInfo_GetHttpResponse
2017.05.09 00:43:38 5: LuftdatenInfo (FeinStaub) - entering LuftdatenInfo_ParseHttpResponse
Mein Sensor ist lokal definiert:
define FeinStaub LuftdatenInfo ESP-3CFC85
Angeschlossen sind ein SDS011 und ein DHT22.
Zitat von: pantau am 09 Mai 2017, 00:52:40
Habe soeben das update durchgeführt, jetzt bekomme ich:
2017.05.09 00:43:22 2: LuftdatenInfo (FeinStaub) - error while request: malformed JSON string
2017.05.09 00:43:37 5: LuftdatenInfo (FeinStaub) - entering LuftdatenInfo_statusRequest
2017.05.09 00:43:37 5: LuftdatenInfo (FeinStaub) - entering LuftdatenInfo_GetHttpResponse
2017.05.09 00:43:38 5: LuftdatenInfo (FeinStaub) - entering LuftdatenInfo_ParseHttpResponse
Mein Sensor ist lokal definiert:
define FeinStaub LuftdatenInfo ESP-3CFC85
Angeschlossen sind ein SDS011 und ein DHT22.
autsch, hatte übersehen, dass das lokale json anders aussieht ::)
mit dem update von heute ist das behoben
Hallo,
ich benutze einen "fremden" Sensor der zufällig im gleichen Ort steht - bekomme aber seit dem 05.05. keine humidity/temperature-Werte mehr. Laut log (verbose 5) kommen die aber mit:
2017.05.09 08:08:22 4: LuftdatenInfo (luft) - returned data: [{"id":XXX,"sampling_rate":null,"timestamp":"2017-05-09 06:05:12","location":
{"id":XXX,"latitude":"XXX","longitude":"XXX","country":"DE"},"sensor":{"id":XXX,"pin":"7","sensor_type":
{"id":9,"name":"DHT22","manufacturer":"various"}},"sensordatavalues":[{"id":XXX,"value":"9.80","value_type":"temperature"},
{"id":XXX,"value":"68.60","value_type":"humidity"}]},{"id":XXX,"sampling_rate":null,"timestamp":"2017-05-09 06:07:40","location":
{"id":XXX,"latitude":"XXX","longitude":"XXX","country":"DE"},"sensor":{"id":XXX,"pin":"7","sensor_type":
{"id":9,"name":"DHT22","manufacturer":"various"}},"sensordatavalues":[{"id":XXX,"value":"9.80","value_type":"temperature"},
{"id":XXX,"value":"69.40","value_type":"humidity"}]}]
Zitat von: Weisswurstverkäufer am 09 Mai 2017, 08:12:47
ich benutze einen "fremden" Sensor der zufällig im gleichen Ort steht - bekomme aber seit dem 05.05. keine humidity/temperature-Werte mehr. Laut log (verbose 5) kommen die aber mit
Uuups,
gerade festgestellt dass bei mir auch keine Temp / Feuchtedaten mehr ankommen.
ID: 1651 / 1652
Grüße
Frank
Jetzt wo ihr das erwähnt, ich habe mich heute morgen schon über den Strich in meinem SVG gewundert, aber keine Zeit gehabt mir das näher anzugucken.
update ab morgen verfügbar.
Es lag daran, dass ich mit "$_->{value} =~ m/^(\S+)(\s|$)/;" die Eineheiten abgeschnitten habe und durch "if($_->{value_type} =~ /temperature$/){" ein beliebiges prefix zulassen wollte, dadurch wurde $1 wieder geleert.
Funktioniert wieder - besten Dank :)
Hallo,
bei mir mit (noch) lokalem Sensor funktionieren, auch nach dem Update, die Temp/Humity nicht. Hast Du es vielleicht nur für Remote gefixt ;) ?
2017.05.10 10:02:04 4: LuftdatenInfo (luftdatensensor1) - returned data: {"software_version": "NRZ-2017-078", "sensordatavalues":[{"value_type":"SDS_P1","value":"6.23"},{"value_type":"SDS_P2","value":"5.63"},{"value_type":"temperature","value":"17.40"},{"value_type":"humidity","value":"35.00"},{"value_type":"samples","value":"794779"},{"value_type":"min_micro","value":"181"},{"value_type":"max_micro","value":"25482"},{"value_type":"signal","value":"-55 dBm"}]}
Ronny
Zitat von: rcmcronny am 10 Mai 2017, 10:04:22
bei mir mit (noch) lokalem Sensor funktionieren, auch nach dem Update, die Temp/Humity nicht. Hast Du es vielleicht nur für Remote gefixt ;) ?
Ja, du hast recht :-[
Memo an mich: erst programmieren, dann Wein trinken ;D
Zitat von: igami am 10 Mai 2017, 10:07:36
Memo an mich: erst programmieren, dann Wein trinken ;D
Oder einfach mal einen Abend nicht programmieren und nur mit der Frau/Freundin Wein trinken. ;)
Hat jemand den BME280 am laufen?
Bisher habe ich nichts gefunden, welcher PIIN wo hin muss?
Bei meinem Witty ist das GPIO4 und 5, ist das hier auch so?
Danke und Gruß Robert
Zitat von: no_Legend am 10 Mai 2017, 17:41:16
Bisher habe ich nichts gefunden, welcher PIIN wo hin muss?
ganz normal an I2C: SDA, SCL, 3,3V und GND, die müssten gekennzeichnet sein ...
Gruß PeMue
Zitat von: Frank_Huber am 10 Mai 2017, 10:13:48
Oder einfach mal einen Abend nicht programmieren und nur mit der Frau/Freundin Wein trinken. ;)
Ist ja nicht viel gewesen und dann mit dem update morgen verfügbar *cheers*
Zitat von: PeMue am 10 Mai 2017, 18:12:28
ganz normal an I2C: SDA, SCL, 3,3V und GND, die müssten gekennzeichnet sein ...
Gruß PeMue
Danke für deine Antwort. Ich glaube ich hab mich falsch ausgedrückt Am Sensor ist eigentlich klar. Aber am Node bin ich mir nicht sicher wo hin.
Muss man eigentlich zwingend den kleinen Kunststoff Schlauch benutzen?
Hat dieser eine andere Funktion, außer die Luft im Muster Aufbau zum Sensor vom Gehäuse-Äußeren zu transportieren?
Gruß Robert
Gesendet von iPad mit Tapatalk Pro
Zitat von: no_Legend am 10 Mai 2017, 20:33:28
Muss man eigentlich zwingend den kleinen Kunststoff Schlauch benutzen?
Hat dieser eine andere Funktion, außer die Luft im Muster Aufbau zum Sensor vom Gehäuse-Äußeren zu transportieren?
Also ich benutze den momentan noch nicht
Je nach "Gehäuse" zirkuiert die Luft ohne dn Schlauch nur intern.
Gerade bei dem Doppel-HT-Bogen.
Ob der benötigt wird oder nicht hängt also von deinem Aufbau ab.
musst dafür sorgen dass der Sensor Aussenluft bekommt.
Ich hab gerade den SDS011 im 3D CAD gezeichnet.
Werde dann mal ein Gehäuse anfangen zu zeichnen.
Gruß Robert
Hallo Robert,
das ist ja super mit der Zeichnung, wir haben einen 3D Drucker und der Sensor ist unterwegs ;D.
Viele Grüße
Rainer
Erstellt ihr dafür bitte ein extra Thema?
Ich möchte vermeiden, dass der Thread hier unübersichtlich wird.
Zitat von: igami am 11 Mai 2017, 21:43:33
Erstellt ihr dafür bitte ein extra Thema?
Ich möchte vermeiden, dass der Thread hier unübersichtlich wird.
Klar kann man machen.
Ich finde allerdings, dass so etwas auch zum Bauen dazu gehört.
Zum Gehäuse ich hab mich doch gegen ein eigenes Gehäuse entschieden.
Der Grund ist ganz einfach, die benötigte Gehäuse Größe wird wohl vom Preis leider teurer sein als ein Kauf.
Fibox TA111107
Ich werde wohl dafür einen Adaptierung für die Teile machen.
Gruß Robert
Hallo,
zu beachten ist die vom Hersteller präferierte Einbaulage des Staubsensors. Lüfter nach unten und waagerecht.
Gesendet von iPad mit Tapatalk
Grüße Jörg
Zitat von: JoWiemann am 12 Mai 2017, 10:23:29
Hallo,
zu beachten ist die vom Hersteller präferierte Einbaulage des Staubsensors. Lüfter nach unten und waagerecht.
Gesendet von iPad mit Tapatalk
Grüße Jörg
Nach Datenblatt in Version 1.3, gibt es 3 "Recommended Installation direction"
https://eckstein-shop.de/SDS011-Laser-PM25-PM10-Dust-Feinstaub-Sensor-Modul-Luft-Qualitaet-Detector-Built-in-Fan
Siehe Seite 11 (Adobe PDF Seiten Zähler)
Oder sehe ich hier was falsch?
Gruß Robert
Hallo Robert,
Du hast recht. Ich hatte eine andere Unterlage im Kopf, in der ich meine nur eine gesehen zu haben.
Gesendet von iPad mit Tapatalk
Grüße Jörg
Hallo ZUsammen,
Habe folgendes Problem - wenn ich meinen Sensor mit define ins fhem einbinde, schmiert der fhem (Raspi) ab (fhem status not running)-
Egal, ob ich die IP oder Sensor-ID angebe. Hat jemand eine Idee?
Gruß
Dieter
Es steht im Log?
Undefined subroutine &main::encode called at ./FHEM/59_LuftdatenInfo.pm line 264.
auf welchem System betreibst du dein FHEM?
mir war nicht bewusst, dass encode ein extra perl modul benötigt.
raspberry 3
ganz normal mit jessie lite?
Dann sollte bei fheminfo inetwa folgendes herauskommen:
Fhem info:
Release : 5.8 FeatureLevel: 5.8
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.20.2
Fhem info:
Release : 5.8 FeatureLevel: 5.8
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.20.2
uniqueID : b78b586a18cb597935dedb95cb113b78
upTime : 00:16:42
änder doch mal bitte den Kopf des Moduls, sodass er wie folgt aussieht:
# packages ####################################################################
package main;
use Encode;
use strict;
use warnings;
use HttpUtils;
Das kannst du auch übers webinterface tun. Dafür folgende URL aufrufen, wobei ip und port passend zu ersetzen sind:
<ip>:<port>/fhem?cmd=style%20edit%2059_LuftdatenInfo.pm
Wenn es dann klappt habe ich einfach das use Encode; vergessen und es ist bisher nicht aufgefallen, weil es genug andere Module gibt die das geladen haben :D
use Encode; eingefügt - funzt
Kaum macht man es richtig :) :)
Dann packe ich es zu morgen ins Update.
Vielen Dank für den Hinweis :)
Vielen Dank für die Turbounterstützung
Das mit dem BME280 habe ich über den Quellcode Raus bekommen.
Quelle:
https://github.com/opendata-stuttgart/sensors-software/blob/master/esp8266-arduino/ppd42ns-wificonfig-ppd-sds-dht/ext_def.h
// BME280, Luftdruck-Sensor
#define BME280_READ 0
#define BME280_API_PIN 11
#if defined(ESP8266)
#define BME280_PIN_SCL D4
#define BME280_PIN_SDA D3
#endif
Hier findet man auch die Infos zu anderen Sensoren, welche Pins zu benutzen sind.
Gibt es eigentlich einen Wiki Seite zum Sensor und FHEM?
Gruß Robert
Zitat von: no_Legend am 14 Mai 2017, 12:46:57
Gibt es eigentlich einen Wiki Seite zum Sensor und FHEM?
Nein, gibt es nicht. Darfst du aber gerne erstellen, dann packe ich einen Link in die commandref ;)
Okay.
Mal schauen vll komm ich morgen dazu.
Findet immer schlecht einen Langen Thread zu durchzusuchen um z.B. meine Info mit den Pins zu finden.
Achja, das Gehäuse ist bei mir gestern eingetroffen.
Eventuell schicke ich morgen das 3D Model des Halters zum mal zum Drucken raus.
Muss morgen noch ein paar Kleinigkeiten anpassen.
Sobald es so weit ist werde ich ein paar Bilder posten.
Gruß Robert
Ich habe ein Layout für die Befestigung der NodeMCU und eines DHT22 auf dem Sensor auf Thingiverse hochgeladen. Einfach nach der Sensor Bezeichnung suchen.
Gesendet von iPhone mit Tapatalk
Hallo,
kann es sein, dass das "timeout"-Attribut abhanden gekommen oder absichtlich entfernt wurde?
Ich bekomme local immer ein timeout und würde die Zeit gerne etwas erhöhen.
Gruß
Manuel
Zitat von: Waldmensch am 14 Mai 2017, 18:20:25
Ich habe ein Layout für die Befestigung der NodeMCU und eines DHT22 auf dem Sensor auf Thingiverse hochgeladen. Einfach nach der Sensor Bezeichnung suchen.
Gesendet von iPhone mit Tapatalk
Dein 3D hatte ich schon gesehen. Für meine Einsatz ist der Halter so nicht zu verwenden. Benutze nicht die pe röhre.
Ich habe den Halter speziell auf das Gehäuse was ich verwenden möchte angepasst.
Morgen gibt es Bilder.
Gruß Robert
Gesendet von iPhone mit Tapatalk Pro
Zitat von: MaMi7880 am 14 Mai 2017, 18:28:41
kann es sein, dass das "timeout"-Attribut abhanden gekommen oder absichtlich entfernt wurde?
Ich bekomme local immer ein timeout und würde die Zeit gerne etwas erhöhen.
Tatsache, wird genutzt und ist dokumentiert, aber nicht als Attribut vorhanden, ab morgen im update. Vielen Dank für den Hinweis :)
@no_Legend
Hallo Robert,
kannst Du das 3D Modell zur Verfügung stellen?
Viele Grüße
Rainer
Zitat von: igami am 14 Mai 2017, 20:51:50
Tatsache, wird genutzt und ist dokumentiert, aber nicht als Attribut vorhanden, ab morgen im update. Vielen Dank für den Hinweis :)
Gerne und vielen Dank...
So ich hab mal mit einer Wiki Seite begonnen.
Es ist noch alles sehr knapp gehalten.
https://wiki.fhem.de/wiki/Luftdaten.info/Feinstaub
Wer keinen Wiki Zugang hat, kann gerne etwas Verfassen und mir zukommen lassen.
Dann Pflege ich das gerne auf der Seite ein.
Gruß Robert
Hallo Robert,
ich schaue es mal durch. Habe am Wochenende ebenfalls meinen Sensor bekommen und lokal in Betrieb genommen (aber noch ohne FHEM).
Gruß PeMue
Zitat von: PeMue am 16 Mai 2017, 08:17:23
Hallo Robert,
ich schaue es mal durch. Habe am Wochenende ebenfalls meinen Sensor bekommen und lokal in Betrieb genommen (aber noch ohne FHEM).
Gruß PeMue
Alles Klar.
Ich bin immer noch nicht so Firm mit dem Wiki.
Hoffe ich habe nicht viel verbockt. :-)
Auf nem Breadboard läuft der Sensor bei mir schon.
Das Fibox TEMPO TA111107 Gehäuse habe ich bereits zuhause.
Den Bauteil-Träger habe ich gezeichnet und auch schon an nen Bekannten gegeben zum Drucken.
Ich hoffe dass der Träger diese Woche kommt und ich schauen kann ob alles so passt wie gedacht.
Sollte dies der Fall sein, werde ich das ganze zur Verfügung stellen.
Gruß Robert
Hallo Peter,
wenn Robert getestet hat, dann werfe ich den Drucker an ;D (Gehäuse und Bauteil-Träger).
Hallo Robert,
die wichtigsten Infos sind im Wiki drin (aus meiner Sicht). Jetzt muß nur noch das 59_LuftdatenInfo.pm ins Wiki
Viele Grüße
Rainer
Zitat von: Heuberg am 16 Mai 2017, 10:31:09
wenn Robert getestet hat, dann werfe ich den Drucker an ;D (Gehäuse und Bauteil-Träger).
Ich hab kein Gehäuse konstruiert, davon habe ich mich bei den Maßen von 100x100x60mm, gleich verabschiedet.
Da ist kaufen um einiges Billiger.
Dazu ist hier auch eine geschäumt Dichtung im Deckel, bei dem Fibox TEMPO TA111107.
Somit kommt kein Wasser von Oben in das Gehäuse.
Verstehe nicht ganz was du mit
Zitat von: Heuberg am 16 Mai 2017, 10:31:09
Jetzt muß nur noch das 59_LuftdatenInfo.pm ins Wiki
Gruß Robert
Hallo Rainer,
Zitat von: Heuberg am 16 Mai 2017, 10:31:09
wenn Robert getestet hat, dann werfe ich den Drucker an ;D (Gehäuse und Bauteil-Träger).
super, vielen Dank. Ich werde den Sensor mit meiner Platine (der Großen) (https://forum.fhem.de/index.php/topic,56606.msg481258.html#msg481258) bzw. "in der Röhre" verwenden.
Ggf. muss ich doch noch einen Träger konstruieren ...
Gruß Peter
Zitat von: PeMue am 16 Mai 2017, 10:48:52
Hallo Rainer,
super, vielen Dank. Ich werde den Sensor mit meiner Platine (der Großen) (https://forum.fhem.de/index.php/topic,56606.msg481258.html#msg481258) bzw. "in der Röhre" verwenden.
Ggf. muss ich doch noch einen Träger konstruieren ...
Gruß Peter
Den Träger bekommst hier für die Rohre: http://www.thingiverse.com/thing:2248787
Der Träger funktioniert mit meinem (großen) NodeMCU nicht. Der NodeMCU sitzt zu nah am Abschirmblech des SDS011, so dass Pins kurzgeschlossen werden.
Zitat von: reibuehl am 16 Mai 2017, 11:38:50
Der Träger funktioniert mit meinem (großen) NodeMCU nicht. Der NodeMCU sitzt zu nah am Abschirmblech des SDS011, so dass Pins kurzgeschlossen werden.
Hast du eine Foto von?
Welchen NodeMCU benutzt du?
Der auf der Projektseite ist doch schon der große Node?
Sind die Lötstellen oder die Pins betroffen?
Die Pins könntest du ja mit einem Seitenschneider abzwicken.
Ich hab den NodeMCU als "NodeMCU V3" gekauft. Anbei zwei Bilder. Es sind wohl "nur" die Pins, die anstoßen, evtl. könnte man das ganze durch auslöten der Pinheader und direktes anlöten der Kabel von oben oder einlöten einer Reihe 90°-Pinheader von oben lösen. Einfach abknipsen geht nicht, da die Pins D3, D4, 3V3 und GND für den BMP280 benötigt werden.
Zitat von: reibuehl am 16 Mai 2017, 11:58:20
Ich hab den NodeMCU als "NodeMCU V3" gekauft. Anbei zwei Bilder. Es sind wohl "nur" die Pins, die anstoßen, evtl. könnte man das ganze durch auslöten der Pinheader und direktes anlöten der Kabel von oben oder einlöten einer Reihe 90°-Pinheader von oben lösen. Einfach abknipsen geht nicht, da die Pins D3, D4, 3V3 und GND für den BMP280 benötigt werden.
Die Unteren Pins kannst du einfach per Seitenschneider abschneiden.
Danach wie du schon geschrieben hast oben die Kabel anlöten.
Gruß Robert
Hallo zusammen,
die fliegende Verdrahtung ist Mist, heute war der Sensor den ganzen Tag aus. Der Stecker am Feinstaubsensor musste doch ein Akkustecker im 2,54 mm Raster sein, oder? Hat jemand zufällig eine Idee? Sonst suche ich mal ...
Gruß PeMue
Zitat von: PeMue am 16 Mai 2017, 21:33:44
Hallo zusammen,
die fliegende Verdrahtung ist Mist, heute war der Sensor den ganzen Tag aus. Der Stecker am Feinstaubsensor musste doch ein Akkustecker im 2,54 mm Raster sein, oder? Hat jemand zufällig eine Idee? Sonst suche ich mal ...
Gruß PeMue
Das mit dem Stecker hab ich mir auch schon gedacht.
Leider war bei dem sds011 aus Deutschland kein Kabel dabei.
Habe auch leider nicht den Richtigen Stecker zum ausprobieren da.
Vll habe ich Glück und beim China Sensor ist ein Stecker dabei. Sicher bin ich mir nicht.
Kannst du nicht einfach einen pfostenstecker (Nagel nicht nicht auf den richten Namen fest) / Federleiste nehmen und mit nem Tropfen heißkleber sichern?
Gruss Robert
Gesendet von iPhone mit Tapatalk Pro
Zitat von: no_Legend am 16 Mai 2017, 13:53:23
Die Unteren Pins kannst du einfach per Seitenschneider abschneiden.
Danach wie du schon geschrieben hast oben die Kabel anlöten.
Warum nehmt ihr den keinen Wemos D1 mini ?
https://de.aliexpress.com/item/ESP12-ESP-12-WeMos-D1-mini-V2-Mini-NodeMcu-4-Mt-bytes-Lua-WIFI-Internet-der/32673300492.html?spm=2114.010208.3.2.SBSS5E&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10152_10065_10151_10068_5160014_436_10136_10157_10137_10060_10138_10155_10062_10156_10154_10056_10055_10054_10059_100032_100033_100031_10099_10103_10102_10101_10096_10147_10052_10053_10050_10107_10142_10051_5150014_10084_10083_10080_10082_10081_10177_10110_10111_10112_10113_10114_10037_10181_10180_10183_10182_10185_10033_10184_10032_10078_10079_10077_10073_10186_10123%2Csearchweb201603_9%2CppcSwitch_5&btsid=2236c062-1194-4014-8db6-97fb82f58258&algo_expid=fe737b7c-53e1-4bf5-a87c-e676393d7c23-0&algo_pvid=fe737b7c-53e1-4bf5-a87c-e676393d7c23 (https://de.aliexpress.com/item/ESP12-ESP-12-WeMos-D1-mini-V2-Mini-NodeMcu-4-Mt-bytes-Lua-WIFI-Internet-der/32673300492.html?spm=2114.010208.3.2.SBSS5E&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10152_10065_10151_10068_5160014_436_10136_10157_10137_10060_10138_10155_10062_10156_10154_10056_10055_10054_10059_100032_100033_100031_10099_10103_10102_10101_10096_10147_10052_10053_10050_10107_10142_10051_5150014_10084_10083_10080_10082_10081_10177_10110_10111_10112_10113_10114_10037_10181_10180_10183_10182_10185_10033_10184_10032_10078_10079_10077_10073_10186_10123%2Csearchweb201603_9%2CppcSwitch_5&btsid=2236c062-1194-4014-8db6-97fb82f58258&algo_expid=fe737b7c-53e1-4bf5-a87c-e676393d7c23-0&algo_pvid=fe737b7c-53e1-4bf5-a87c-e676393d7c23)
Der ist um einiges kleiner und kommt in Einzelteilen ... will heissen die Pinleisten sind noch nicht verlötet.
Dadurch könnt ihr die Kabel direkt anlöten.
Hoi,
ich hatte es auch zuerst fliegend mit ner NodeMCU v3 aufgebaut aber dann mir für Robins Gehäuse einen Wemo geholt, passt 1a und ist wirklich einfacher, wenn man löten kann ;)
Ich habe den SDS aus China, da ist nen Kabel inkl. Adapter für den USB Port dabei gewesen. Das kabel hab ich durchgetrennt und an den Wemo gelötet, hat einfach Hand und Fuß.
Was das aber genau für ein Stecker ist, keine Ahnung sorry.
Ronny
*LOL*
Ich hatte noch Wemos in der Bastelkiste und hab mir nach Stückliste des Projekts den NodeMCU beschafft. *facepalm*
Habe alle süber Dupont verdrahtet, hält bisher ganz gut. der DHT22 hängt sogar nur an den Dupont senkrecht unten am Rohr raus.
/Frank
Hallo,
bei den Steckverbindungen handelt es sich um JST Teile:
http://de.rs-online.com/web/p/leiterplattensteckverbinder-gehause/8201624/
http://de.rs-online.com/web/p/products/8201529/
Grüße Jörg
Zitat von: AxelSchweiss am 17 Mai 2017, 08:01:26
Warum nehmt ihr den keinen Wemos D1 mini ?
https://de.aliexpress.com/item/ESP12-ESP-12-WeMos-D1-mini-V2-Mini-NodeMcu-4-Mt-bytes-Lua-WIFI-Internet-der/32673300492.html?spm=2114.010208.3.2.SBSS5E&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10152_10065_10151_10068_5160014_436_10136_10157_10137_10060_10138_10155_10062_10156_10154_10056_10055_10054_10059_100032_100033_100031_10099_10103_10102_10101_10096_10147_10052_10053_10050_10107_10142_10051_5150014_10084_10083_10080_10082_10081_10177_10110_10111_10112_10113_10114_10037_10181_10180_10183_10182_10185_10033_10184_10032_10078_10079_10077_10073_10186_10123%2Csearchweb201603_9%2CppcSwitch_5&btsid=2236c062-1194-4014-8db6-97fb82f58258&algo_expid=fe737b7c-53e1-4bf5-a87c-e676393d7c23-0&algo_pvid=fe737b7c-53e1-4bf5-a87c-e676393d7c23 (https://de.aliexpress.com/item/ESP12-ESP-12-WeMos-D1-mini-V2-Mini-NodeMcu-4-Mt-bytes-Lua-WIFI-Internet-der/32673300492.html?spm=2114.010208.3.2.SBSS5E&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10152_10065_10151_10068_5160014_436_10136_10157_10137_10060_10138_10155_10062_10156_10154_10056_10055_10054_10059_100032_100033_100031_10099_10103_10102_10101_10096_10147_10052_10053_10050_10107_10142_10051_5150014_10084_10083_10080_10082_10081_10177_10110_10111_10112_10113_10114_10037_10181_10180_10183_10182_10185_10033_10184_10032_10078_10079_10077_10073_10186_10123%2Csearchweb201603_9%2CppcSwitch_5&btsid=2236c062-1194-4014-8db6-97fb82f58258&algo_expid=fe737b7c-53e1-4bf5-a87c-e676393d7c23-0&algo_pvid=fe737b7c-53e1-4bf5-a87c-e676393d7c23)
Der ist um einiges kleiner und kommt in Einzelteilen ... will heissen die Pinleisten sind noch nicht verlötet.
Dadurch könnt ihr die Kabel direkt anlöten.
Der Wimo ist nicht schlecht.
Hat aber für den Nachteil, nicht alle pins sind ausgeführt und es gibt keine befestigungslöcher.
Dazu habe ich die nodes schon mal vor längerem in China bestellt gehabt. Somit habe ich keine Lust noch mal 6 Wochen zu warten.
Gruß Robert
Gesendet von iPad mit Tapatalk Pro
Hallo,
ich habe den Sketch um den Luminosity-Sensor TSL2561 und den VEML6070 erweitert und den BME280 so umgebaut, dass zwei davon betrieben werden können.
In den Adafruit Library's habe ich die Objektorientierung entfernt und sie so angepasst, dass durch Übergabe der Sensoradresse die Funktionen direkt aufrufbar sind. Die .cpp und .h ist nun als .ino und .h ins Sketchverzeichnis gewandert. Meine Ergänzungen habe ich etwas schöner gemacht und die aktuellen Änderungen zur Mehrsprachigkeit übernommen.
Vielleicht habt Ihr ja Lust das zu testen.
Grüße Jörg
PS: Habe ich auch mal als Issue https://github.com/opendata-stuttgart/sensors-software/issues/73 gepostet
Hallo Jörg,
Zitat von: JoWiemann am 19 Mai 2017, 15:15:11
Vielleicht habt Ihr ja Lust das zu testen.
könntest Du bitte das
binary ebenfalls zur Verfügung stellen? Dann brauche ich mich als Hardwerker nicht mit dem Kompilieren rumschlagen ;)
Danke + Gruß
Peter
Zitat von: PeMue am 19 Mai 2017, 15:49:02
Hallo Jörg,
könntest Du bitte das binary ebenfalls zur Verfügung stellen? Dann brauche ich mich als Hardwerker nicht mit dem Kompilieren rumschlagen ;)
Für welchen ESP8266?
Grüße Jörg
Hallo,
falls einer das Ganze mit EspEasy (Mega geht auch) machen möchte. Anbei das entsprechende PlugIn rückwärtskompatibel für nicht Mega gemacht.
Grüße Jörg
Zitat von: PeMue am 19 Mai 2017, 15:49:02
Hallo Jörg,
könntest Du bitte das binary ebenfalls zur Verfügung stellen? Dann brauche ich mich als Hardwerker nicht mit dem Kompilieren rumschlagen ;)
Danke + Gruß
Peter
Hallo Peter,
anbei für nodeMCU.
Hallo,
ich habe den SDS011 jetzt seit rund 1 Woche laufen. Dann habe ich noch zwei SHARP GP2Y1010AU0F.
Ds die nicht die gleichen Werte liefern, kann ich mir vorstellen.
Aber hat jemand auch mal die SDS011 Werte mit denen des Uweltbundesamtes für seine Region verglichen.
Bei mir liefert der SDS011 so Werte zwichen 1,5 und 4. Der Sharp meist so um 70.
Das UWB sagt meistens 25.
Ich habe auch mal auf der luftdaten.info Karte mal Stationen rausgesucht, die in der Nähe eine UWB Station haben ==> gleiches Ergebnis: Meist Faktor 30 Höher als die SDS011 Werte.
Wie sind eure Werte mit der "ungefähren" Messgenauigkeit.
Grüße
Jörg
P.S: Ich erwarte ja keine identischen Werte - aber die Größenordnung sollte schon passen: Also hinreichend genau
Hallo Jörg,
Zitat von: JoWiemann am 19 Mai 2017, 18:36:57
anbei für nodeMCU.
nodeMCU und WeMosD1 mini sind dieselben, alle haben einen ESP12irgendwas drauf.
Zitat von: JoWiemann am 19 Mai 2017, 18:05:41
... falls einer das Ganze mit EspEasy (Mega geht auch) machen möchte. Anbei das entsprechende PlugIn rückwärtskompatibel für nicht Mega gemacht.
Sprich, ich installiere die Bibliothek, kopiere das .ino ins ESPEasy Verzeichnis und übersetze neu? Das müsste ich hinbekommen ;) Aber dann ist der Luftdatensensor lokal und speist nicht in das Netz ein, oder?
Zitat von: jnewton957 am 19 Mai 2017, 20:02:11
Aber hat jemand auch mal die SDS011 Werte mit denen des Uweltbundesamtes für seine Region verglichen?
Hier habe ich etwas gefunden: http://luftdaten.info/2017/05/15/vorabinformation-der-lubw-zu-vergleichsmessungen-des-feinstaubsensors-sds011/
Meinen muss ich erst ins Gehäuse "eintüten" und auf's Dach montieren, bevor ich richtig ins Rennen gehe ...
Vielen Dank.
Gruß Peter
Gibt es eigentlich Empfehlungen, wo man den Sensor am besten aufstellt?
Gesendet von iPhone mit Tapatalk Pro
Zitat von: PeMue am 19 Mai 2017, 20:32:05
Sprich, ich installiere die Bibliothek, kopiere das .ino ins ESPEasy Verzeichnis und übersetze neu? Das müsste ich hinbekommen ;) Aber dann ist der Luftdatensensor lokal und speist nicht in das Netz ein, oder?
Stimmt, das mit dem EspEasy ist für alle, die es anders machen möchten.
Grüße Jörg
Hallo zusammen,
mal eine ganz dumme Frage: ich hatte den Sensor ausgeschaltet, weil es geregnet hat und ohne Gehäuse war mir das zu heiß auf dem Balkon. Jetzt habe ich wieder eingesteckt und wollte eine neue Firmware flashen, wollte nur noch mal die aktuelle Firmwareversion checken - und siehe da, es scheint eine neue Firmware drauf zu sein (NRZ-2017-080). Kann das sein, dass der Sensor seine Firmware selber aktualisiert ???
Danke + Gruß
PeMue
Ja, mit der "original" Firmware prüft er und zieht auch Updates automatisch. Kann man aber auch abschalten glaube ich.
Gesendet von meinem S3_32 mit Tapatalk
Zitat von: Frank_Huber am 20 Mai 2017, 19:35:48
Kann man aber auch abschalten glaube ich.
Stimmt, siehe Bild ;) Mal sehen, wie lange Jo's Firmware braucht, bis sie auf meinem Sensor ist ;D
Gruß PeMue
Zitat von: PeMue am 20 Mai 2017, 19:29:28
Hallo zusammen,
mal eine ganz dumme Frage: ich hatte den Sensor ausgeschaltet, weil es geregnet hat und ohne Gehäuse war mir das zu heiß auf dem Balkon. Jetzt habe ich wieder eingesteckt und wollte eine neue Firmware flashen, wollte nur noch mal die aktuelle Firmwareversion checken - und siehe da, es scheint eine neue Firmware drauf zu sein (NRZ-2017-080). Kann das sein, dass der Sensor seine Firmware selber aktualisiert ???
Danke + Gruß
PeMue
Das ist leider als Default so konfiguriert. Ich halte das für problematisch. Sofern jemand hier eine Hack schafft und seine Firmware auf den ESP bringt sind weiteren illegalen Aktionen Tür und Tor geöffnet. Irgendwie haben die Jungs/Mädels noch nicht mitbekommen, dass IoT Devices gerne für kriminelle Zwecke genutzt werden.
Grüße Jörg
Zitat von: JoWiemann am 20 Mai 2017, 20:08:36
Das ist leider als Default so konfiguriert. Ich halte das für problematisch. Sofern jemand hier einen Hack schafft und seine Firmware auf den ESP bringt sind weiteren illegalen Aktionen Tür und Tor geöffnet.
Habe soeben den Haken entfernt.
Gruß PeMue
Bei mir hat das Firmware Update am 20.05. um 23:20 stattgefunden. Ab der Zeit kann mein HTTPMOD die Daten nicht mehr lesen... Das Ausgabeformat hat sich anscheinend geändert.
Zitat von: chem am 24 Mai 2017, 06:59:10
Bei mir hat das Firmware Update am 20.05. um 23:20 stattgefunden. Ab der Zeit kann mein HTTPMOD die Daten nicht mehr lesen... Das Ausgabeformat hat sich anscheinend geändert.
Und mit dem Modul?
Hallo,
also bei mir läuft noch alles mit der Version NRZ-2017-080 (die bei mir am 19.5. abends eingespielt wurde).
Ronny
Zitat von: chem am 24 Mai 2017, 06:59:10
Bei mir hat das Firmware Update am 20.05. um 23:20 stattgefunden. Ab der Zeit kann mein HTTPMOD die Daten nicht mehr lesen... Das Ausgabeformat hat sich anscheinend geändert.
In dem Thread hier geht es um das Modul welches die Daten vom Web-Portal abruft.
Wenn Du per HTTPMOD etwas selbst gebaut hast passt das nicht hierher.
mach dein HTTPMOD weg und nutze das Modul...
Zitat von: Frank_Huber am 24 Mai 2017, 09:02:29
In dem Thread hier geht es um das Modul welches die Daten vom Web-Portal abruft.
Es kann auch lokal die Daten abrufen ;)
Da fällt mir ein ich muss das mit den mehreren Sensoren noch einbauen ::)
Könnte mir noch einer von denen die zwei Temperatur Sensoren verwenden das json schicken?
Hallo igami,
noch eine Idee. Ich würde gerne den Versand der Daten über Fhem an Luftdaten.info durchführen. Könntest Du Dir vorstellen eine entsprechende Option in Dein Modul einzubauen?
Grüße Jörg
Zitat von: JoWiemann am 24 Mai 2017, 10:11:52
Hallo igami,
noch eine Idee. Ich würde gerne den Versand der Daten über Fhem an Luftdaten.info durchführen. Könntest Du Dir vorstellen eine entsprechende Option in Dein Modul einzubauen?
Grüße Jörg
also eine art "set <name> push Luftdaten.info"?
Ich selbst wüsste jetzt nicht wie man sowas einbaut, aber wenn mir jemand dabei hilft kann ich das gerne machen.
Oder ein Attribut, mit dem ich aktivieren kann welcher Sensor automatisch gepusht wird, nachdem Dein Modul frische Daten geholt hat.
Grüße Jörg
Aber bitte nur optional.
Ich finde den Weg wie er jetzt ist besser.
NodeMCU sendet an Luftdaten.info und das Modul holt die Daten von dort.
Der andere Weg verkompliziert das ganze nur...
Der andere Weg ist sinnvoll, wenn man mehr Sensoren an den NodeMCU anschließt und nur die, für andere auch, relevanten Daten an Luftdaten.info senden will.
Zitat von: Frank_Huber am 24 Mai 2017, 10:54:16
Aber bitte nur optional.
Dafür sorgt ja das zu setzende Attribut. Nicht gesetzt => kein Versand.
Btw. Meine IoT-Komponenten haben, sofern möglich, alle keinen Kontakt zur Außenwelt. Und werden schon gar nicht unkontrolliert von außen mit neuer Firmware versehen.
Grüße Jörg
Hallo,
Ich beschäftige mich erst seit kurtzem mit dem SDS011&DHT22 und habe gestern meinen Sensor online gebracht.
Firmware: NRZ-2017-080
Habe auch ein eigenes Gehäuse entwickelt fall es jemand interessiert https://www.thingiverse.com/thing:2340778 (https://www.thingiverse.com/thing:2340778)
Wenn ich jetzt auf http://deutschland.maps.luftdaten.info/ (http://deutschland.maps.luftdaten.info/) gehe suche dort meinen Sensor und dort z.B. die ID 1234 steht muss ich dann meinen Sensor so definieren?
define Luft01 LuftdatenInfo (1234)
Wenn ich auf meinen Sensor gehe Http://192.168.x.x steht dort eine andere ID z.B. 12345678
Ich habe daher auch schon getestet
define Luft01 LuftdatenInfo (12345678)
define Luft01 LuftdatenInfo (192.168.x.x)
aber alles geht nicht ???
Wenn ich mit der ip Adresse abfrage, muss ich dann noch was beim Sensor konfigurieren?
Als Fehler erhalte ich immer
LuftdatenInfo (Luft01) - error while request: gethostbyname (1234) failed
Ich habe dann mal via api.luftdaten.info/v1/sensor/id eine abfrage gestartet und ich bekam eine Antwort.
longitude und latitude habe ich dann auch in der fhem.cfg angepasst., ging dann leider auch nicht.
Einfach nur 1234 ohne Klammern.
Hast den sensor per Email angemeldet? Ansonsten kommt der nicht auf die Web Seite
Gesendet von meinem S3_32 mit Tapatalk
Super DANKE läuft.
Manchmal ist es sooooo einfach ::)
Wie ist das eigentlich wenn ich einen Sensor in Osteuropa betreiben möchte, kann ich dann auch die Sensordaten dann importieren?
Ja klar, das Projekt ist nicht auf Deutschland beschränkt.
Gesendet von meinem S3_32 mit Tapatalk
Zitat von: Edi77 am 25 Mai 2017, 21:28:53
Wie ist das eigentlich wenn ich einen Sensor in Osteuropa betreiben möchte, kann ich dann auch die Sensordaten dann importieren?
Guck dir einfach mal die Map an, die Sensoren sitzen nicht mehr nur in DE 8)
http://world.maps.luftdaten.info/
Ja klar, der Sensor soll nach Belarus und dort in eine Großstadt.
Die scheinen aber auch da eine "Big Wall" zu haben, das wird wohl das größte Problem.
Hatte auch schon versucht mit einem RPi dort eine Verbindung aufzubauen via VPN was blockiert wurde.
Also kann das Modul LuftdatenInfo theoretisch von jedem Sensors wenn die ID bekannt ist die Daten abholen und speichern wenn ich das richtig verstehe.
In der Commandref steht ja "Bei einer Abfrage werden die beiden Positionsangaben verglichen und bei Abweichung eine Meldung ins Log geschrieben."
Der sensor schickt seine Daten an die projektwebseite. Von da holt das Modul die Daten ab. Wenn der sensor aufgrund von webfiltern natürlich nichts schicken kann wirds blöd. Dann kannst du die Daten nur direkt abrufen per IP. Dyndns sollte auch gehen.
Gesendet von meinem S3_32 mit Tapatalk
Soweit ich weiß hat man noch nicht mal Zugriff auf seinen Router, also DynDns wird auch schierig.
Weiß jemand über welchen Port die Daten gesendet werden?
Idealerweise Port 80?
Port 8086 auf api.luftdaten.info
Gesendet von meinem S3_32 mit Tapatalk
Und btw, für dyndns brauchst ned unbedingt Router Zugriff, kannst auch vom PC machen...
Gesendet von meinem S3_32 mit Tapatalk
Richtig, das geht auch, aber wenn vor Ort kein PC vorhanden ist der permanent läuft, und das Internet ist selbst in einer Großstadt ehr lahm ca. 1 - 3 MBit.
Ist halt nicht so einfach.
Zitat von: igami am 24 Mai 2017, 09:40:31
Könnte mir noch einer von denen die zwei Temperatur Sensoren verwenden das json schicken?
Hallo zusammen,
ich habe gesehen, dass JoWiemann den Sketch so umgebaut hat, dass zwei BME280 betrieben werden können.
Ich würde gerne zwei oder noch mehr DHT22 am Feinstaubsensor betreiben, falls das möglich ist.
Wie muss das Sketch dafür angepasst werden und wie wird der zweite DHT22 dann an das Board angeschlossen?
Gruß Mathias
Soweit ich weiß braucht jeder DHT einen eigenen GPIO.
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Also könnte ich einen zweiten DHT22 mit den im Bild angekreuzten Anschlüssen verbinden.
Nur wie ändere ich die Software, dass der zweite DHT ausgelesen wird?
Gruß Mathias
Zitat von: igami am 26 Mai 2017, 09:21:13
{"software_version": "NRZ-2017-080", "sensordatavalues":[{"value_type":"SDS_P1","value":"4.44"},{"value_type":"SDS_P2","value":"4.14"},{"value_type":"temperature","value":"36.50"},{"value_type":"humidity","value":"30.60"},{"value_type":"BME280_temperature","value":"32.79"},{"value_type":"BME280_humidity","value":"33.57"},{"value_type":"BME280_pressure","value":"100956.05"},{"value_type":"samples","value":"771097"},{"value_type":"min_micro","value":"180"},{"value_type":"max_micro","value":"167121"},{"value_type":"signal","value":"-83 dBm"}]}
Zitat von: pantau am 28 Mai 2017, 12:53:02
{"software_version": "NRZ-2017-080", "sensordatavalues":[{"value_type":"SDS_P1","value":"4.44"},{"value_type":"SDS_P2","value":"4.14"},{"value_type":"temperature","value":"36.50"},{"value_type":"humidity","value":"30.60"},{"value_type":"BME280_temperature","value":"32.79"},{"value_type":"BME280_humidity","value":"33.57"},{"value_type":"BME280_pressure","value":"100956.05"},{"value_type":"samples","value":"771097"},{"value_type":"min_micro","value":"180"},{"value_type":"max_micro","value":"167121"},{"value_type":"signal","value":"-83 dBm"}]}
Vielen Dank schon mal. Dann kann ich ja weiter machen.
Hat jemand von euch schon mehrere BME280 am laufen? Da wäre das json auch ineressant.
Ich stelle mir die Umsetzung so vor, dass man bei der DEF hinter der IP noch die Sensoren mit angibt deren Werte man haben möchte, also "<IP> SDS DHT" oder "<IP> BME". Nur bin ich mir noch nicht sicher wie gut das mit mehreren BME an einem Node funktioniert.
Mit der original Firmware funktioniert nur ein BME.
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Zitat von: Frosch am 28 Mai 2017, 12:30:56
Nur wie ändere ich die Software, dass der zweite DHT ausgelesen wird?
Gruß Mathias
Ist etwas Aufwand. Könnte ich aber einbauen.
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Eigentlich müsste doch auch ein BME reichen. Der Luftdruck sollte ja zwischen zwei Räumen nicht sonderlich stark schwanken.
Werden beide Sensoren auch zur API gepusht?
Ich hatte heute folgenden Eintrag im Log:
2017.05.27 13:49:48 1: PERL WARNING: Use of uninitialized value in index at ./FHEM/59_LuftdatenInfo.pm line 250.
2017.05.27 13:49:48 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.05.27 13:54:53 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.05.27 13:59:48 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.05.27 14:04:48 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.05.27 14:09:48 2: LuftdatenInfo (Luftdaten) - no second sensor found
Ansonsten gabs aber keine weiteren Auffälligkeiten.
Poste mal bitte ein list von dem Device.
Das wäre wie folgt:
Internals:
CONNECTION remote
DEF 1665
INTERVAL 300
NAME Luftdaten
NR 27
SENSORID1 1665
SENSORIDS implicit
STATE active
TIMEOUT 5
TYPE LuftdatenInfo
Helper:
Dblog:
Pm10:
Mydblog:
TIME 1496003993.82719
VALUE 2.88
Pm2.5:
Mydblog:
TIME 1496004293.81853
VALUE 2.68
Readings:
2017-05-28 22:44:53 PM10 2.88
2017-05-28 22:44:53 PM2.5 2.68
2017-05-05 16:12:23 latitude 48.307
2017-05-05 16:12:23 location 4020 Linz (Stadt)
2017-05-05 16:12:23 longitude 14.294
2017-05-28 22:44:53 state active
Attributes:
event-on-change-reading .*
room div
Kommt die Fehlermeldung denn immernoch?
Und hattest du vorher schon mal Termperatur und Luftfeuchte Daten?
Nein, die Meldung kam die paar Male und weder danach noch davor.
Der hatte bisher noch nie solche Daten geliefert(ist nicht meiner).
Ich kann es mir jetzt auf die schnelle nicht erklären. Wenn nun wieder alles gut ist würde ich es dabei belassen und du meldest dich wieder, falls es noch Mal Auftritt.
Hallo JoWiemann,
das wäre wirklich klasse wenn du das einbauen könntest.
Den Anschlüssen nach zu urteilen lassen sich insgesamt drei DHT22 direkt anschließen, oder weitere mit einer eigenen Stromversorgung.
Mal schauen ob die Energieversorgung des NodeMCU dazu ausreicht.
Das heißt dann auch, dass die offziellen Updates abgeschaltet werden müssen, richtig?
Gruß Mathias
Zitat von: igami am 28 Mai 2017, 15:58:02
Eigentlich müsste doch auch ein BME reichen. Der Luftdruck sollte ja zwischen zwei Räumen nicht sonderlich stark schwanken.
Werden beide Sensoren auch zur API gepusht?
Der BME hat ja auch noch Temp und Humidity.
Bei der original Firmware kann es nur einen BME geben, der dann auch gepuscht wird. Der BME unterstützt zwei Adressen, so dass zwei BME parallel betrieben werden können. Die Firmware scannt beide Adressen und selektiert eine gefundene, bei zwei BME die zweite, als den angeschlossenen BME. Der andere BME wird ausgeblendet.
Bei meiner Implementation werden beide BME aktiviert und das Pushen kann ausgewählt werden.
Gesendet von iPad mit Tapatalk
Grüße Jörg
Zitat von: JoWiemann am 29 Mai 2017, 10:39:07
Bei der original Firmware kann es nur einen BME geben, der dann auch gepuscht wird.
Und wenn man DHT und BME angeschlossen hat?
Zitat von: igami am 29 Mai 2017, 21:38:10
Und wenn man DHT und BME angeschlossen hat?
DHT und BME laufen parallel, da der DHT auf dem one-wire beruht und der BME auf I2C. DHT, BMP und BME sollte auch gleichzeitig funktionieren.
Grüße Jörg
Kann das jemand mal testen und mir das json schicken?
Zitat von: Frosch am 29 Mai 2017, 08:51:06
Hallo JoWiemann,
das wäre wirklich klasse wenn du das einbauen könntest.
Den Anschlüssen nach zu urteilen lassen sich insgesamt drei DHT22 direkt anschließen, oder weitere mit einer eigenen Stromversorgung.
Mal schauen ob die Energieversorgung des NodeMCU dazu ausreicht.
Das heißt dann auch, dass die offziellen Updates abgeschaltet werden müssen, richtig?
Gruß Mathias
Hallo Mathias,
anbei die Firmware für 3 DHT22, auf D7,D8,D9. Bei D9 musst Du aufpassen, weil das bei mir der RX ist und das Flashen nicht richtig funktioniert, wenn dort ein DHT22 dran hängt. Ansonsten den GPIO in der ext_def.h ändern und neu kompilieren.
Grüße Jörg
PS: Es sind alle aktuellen Änderungen von Luftdaten mit drin.
Hallo Jörg,
ich habe gerade versucht deine Firmware zu flashen. Leider wird der Vorgang immer wieder abgebrochen.
Ich habe alle angeschlossenen Kabel vom NodeMCU entfernt. Kann das mit dem von dir beschriebenen Problem an D9 zusammenhängen?
meißtens kommt: "didn't receive command response".
Ich probiere es mal weiter und versuche herauszufinden woran es liegt. Falls du eine Idee hast sag bescheid.
Und danke für das programmieren :)
Hier die Terminaleingabe:
~ $ sudo ~/.arduino15/packages/esp8266/tools/esptool/0.4.9/esptool -vv -cd nodemcu -cb 57600 -ca 0x00000 -cp /dev/ttyUSB0 -cf /media/Daten/Desktop/FHEM/Feinstaubsensor/alternative\ firmware/airrohr-firmware/airrohr-firmware.ino.nodemcu.bin
esptool v0.4.9 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
setting board to nodemcu
setting baudrate from 115200 to 57600
setting address from 0x00000000 to 0x00000000
setting port from /dev/ttyUSB0 to /dev/ttyUSB0
espcomm_upload_file
espcomm_upload_mem
opening port /dev/ttyUSB0 at 57600
tcgetattr
tcsetattr
serial open
opening bootloader
resetting board
trying to connect
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
trying to connect
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
Uploading 464160 bytes from /media/Daten/Desktop/FHEM/Feinstaubsensor/alternative firmware/airrohr-firmware/airrohr-firmware.ino.nodemcu.bin to flash at 0x00000000
erasing flash
size: 071520 address: 000000
first_sector_index: 0
total_sector_count: 114
head_sector_count: 16
adjusted_sector_count: 98
erase_size: 062000
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
setting timeout 15000
setting timeout 100
espcomm_send_command: receiving 2 bytes of data
writing flash
................................................................................ [ 17% ]
................................................................................ [ 35% ]
....................................warning: espcomm_send_command: didn't receive command response
warning: espcomm_send_command(FLASH_DOWNLOAD_DATA) failed
warning: espcomm_send_command: didn't receive command response
closing bootloader
error: espcomm_upload_mem failed
Das selbe Problem hatte ich mit DHT22 am D9. Ich konnte dann erst wieder flashen nachdem ich den Taster Flash beim einstecken der USB Kable gedrückt gehalten habe.
Grüße Jörg
PS: Ich arbeite beim Entwickeln allerdings mit Arduino IDE und flashe auch damit.
Hallo,
anbei eine neue Firmware, basierend auf der aktuellen: "NRZ-2017-085"
Für die Sensoren habe ich jetzt eine eigene Konfigurationsseite gemacht und es können nun für die Sensoren eigene Namen vergeben werden.
Grüße Jörg
Ich habe mir diesen Sensor mit einem WeMos D1 Mini ESP8266 besorgt.
Die Firmware ist aufgespielt.
Nun habe ich das Problem wie ich diesen Sensor in mein lokales WLAN einbinde.
Irgendwo habe ich entweder diesen Punkt übersehen oder er ist auf Luftdateninfo nicht angeführt.
Hat jemand einen Tipp wo ich dies nachschlagen kann?
Kommst Du auf das WLAN des Sensors? Sollte unter feinstaub-<irgendeineID> in der Liste der verfügbaren WLANs auftauchen.
Wie soll das funktionieren.
Dieses Teil muss sich doch erst einmal in ein Netzwerk eingliedern bevor es sich irgendwo hin verbinden kann.
Nein, wenn das Teil keine Netzwerkkonfiguration hat, macht es selber einen WLAN Access Point auf. Da logt man sich dann ein und konfiguriert das eigene WLAN. Dann ein reboot und der Sensor hängt dann im eigenen Netz.
Und wie finde ich diesen.
Unter WLAN ist kein Accesspoint zu finden der entsprechende Signalstärke besitzt.
Auch ist der Sensor unter http://192.168.4.1/ nicht zu finden.
Wenn ein paar Minuten nach anlegen der Versorgungsspannung kein WLAN mit Feinstaubsensor-<ID> erscheint, ist vielleicht was beim Flashen schiefgelaufen?
Häng den Sensor mal per USB an einen PC mit Arduino IDE und mach den Serial Monitor auf und boote dann den Sensor neu. Da solltest Du dann Debug output sehen.
Werde ich morgen nochmals testen.
Danke vorerst einmal.
Ich habe zwei mal die Firmware zur Sicherheit geflasht.
Einmal unter der Windows Shell und einmal unter Windows PowerShell.
Beide Male funktionierte das Flashen ohne Fehler.
Anschließend den WeMosD1 Mini ESP8266 stromlos gemacht und wieder am USB Port des PC's angeschlossen damit der WeMosD1 Strom bekommt.
Dennoch erscheint die Sensoreinheit nicht unter den WLAN Accesspoints mit Feinstaubsensor-<ID>.
Mit dem Serial Monitor tut sich aber auch nichts.
Die Einstellungen des Serial Monitors siehe Anhang.
Ich weiß wirklich nicht mehr was der Fehler ist.
WeMosD1 Mini ESP8266
http://www.ebay.at/itm/272575715215?_trksid=p2057872.m2749.l2649&var=571688572330&ssPageName=STRK%3AMEBIDX%3AIT
Hallo Chris,
ich flashe immer mit dem NodeMCU Flasher, siehe https://github.com/nodemcu/nodemcu-flasher/raw/master/Win32/Release/ESP8266Flasher.exe.
- COM Port auswählen
- Firmwaredatei auswählen (von luftdaten.info herunterladen und irgendwo speichern)
- Flash Size 4 MB bzw. Baudrate wählen (115200 ist sicher, aber langsam, schneller müsste aber auch gehen)
- Flashen.
Ich würde dann den WeMosD1 mini kurz von der Spannungsversorgung trennen, so dass er wieder sauber hochfahren kann.
Viel Erfolg.
Gruß PeMue
Soweit ich feststellen konnte funktionierte das Flashen der Sensoreinheit.
Das Ding ist sehr träge, was ich feststellen musste. Bis sich die Sensoreinheit unter den Accesspoints zeigt dauert das mindestens 25 Minuten.
Nun habe ich das nächste Problem, nähmlich das sich diese Sensoreinheit bei meinem Accesspoint verbinet.
Die SSID und das Passwort habe ich in der Sensoreinheit eingetragen und gespeichert.
Die MAC der Sensoreinheit wurde in meinem FRITZ!Box Accesspoint eingetragen.
Die Sensoreinheit habe ich danach stromlos gemacht und wieder neu gestartet.
Dennoch kommt keine Verbindung mit der FRITZ!Box zustande und die Sensoreinheit wird wieder als Accesspoint angezeigt.
Die aktuelle Firmware der Sensoreinheit ist NRZ-2017-086.
Update: 2017.06.05 07:52
Nach langem Testen hat sich die Sensoreinheit doch überreden lassen sich mit dem Accesspoint zu verbinden.
Trotzdem lauft es noch nicht zu friedenstellend da die Verbindungen immer wieder getrennt werden und die Sensoreinheit stromlos gemacht werden muss damit eine Verbindung wieder zustande kommt. Werde mich mit dem Firmware Lieferanten kurzschließen.
Hallo Chris,
nimm doch mal probeweise Jörg's Firmware aus diesem Post:
https://forum.fhem.de/index.php/topic,66674.msg642414.html#msg642414
Gruß PeMue
Ich habe es mit der aktuellen Firmware von luftdaten.info fürs Erste sowohl bei Luftdateninfo als auch bei FHEM zum Laufen gebracht.
Das Problem beim dieser Sensoreinheit ist die, dass nach einer Änderung der Konfiguration unbedingt ein Hardware Rest zu machen ist.
Konfiguration speichern => Stromlos machen => wieder mit Spannungsquelle versorgen.
Für FHEM weichen die Definition aber bei mir ab.
Um lokal die Daten auszulesen sieht die Definition so aus.
define SDS011 HTTPMOD http://User:Passwort@192.xxx.xxx.xxx/data.json 60
Im FhemWiki fehlen mir aber die entsprechenden Hinweise zur aktuellen Konfiguration, oder sind diese derzeit wo anders abgelegt?
Mahlzeit,
jetzt habe ich es endlich geschafft meinen Luftsensor bei luftdaten.info zu registrieren. Noch mal zur Erinnerung, ich betreibe einen ESP8266 mit den Sensoren SDS011 (Feinstaubmessung 10µm/2,5µm), DHT22 (Temperatur + rel. Luftfeuchte) und BMP180 (Luftdruck + Temperatur).
Bei der Registrierung habe ich auch freundlicherweise drei IDs von OK Lab Stuttgart für die drei Sensoren erhalten:
ZitatHallo Manuel,
ich habe deinen Sensor in die Datenbank eingetragen. Die IDs (z.B. für
die Karte) lauten:
3271: Feinstaub PM10 u. PM2.5
3272: Temperatur u. Luftfeuchte (Karte in Arbeit)
3273: Temperatur u. Luftdruck (Karte in Arbeit)
Link zur Karte: http://mainz.maps.luftdaten.info/
.......
Nun zu meiner Frage. Ist es zukünftig vorgesehen auch die dritte ID mit dem Modul auszulesen oder wird es bei zwei bleiben?
Zur Zeit nutze ich noch ein modifiziertes Modul mit welchem ich local die Daten von allen drei Sensoren auslese.
Gruß
Manuel
Ja, ist geplant, ich weiß nur noch nicht wie man mit dem zweiten Temperaturwert umgehen soll, da ja manche User den Sensor dann für einen ganz anderen Raum einsetzten und sich die DHT und BME/BMP Werte dann stark unterscheiden können. Hier war meine Idee mal, dass man auswählen kann welcher Sensor ausgewertet werden soll.
Werde mich bei Gelegenheit noch mal dransetzen.
@MaMi7880
Wo nutz du die Sensorwerte? Unter FHEM oder zur Visualisierung über luftdaten.info.
Wenn du die Sensoren nur unter FHEM nutzen willst reicht es doch wenn du die Daten direkt aus deinem lokalen Netzwerk abgreifst.
Da hast du die unterschiedlichsten Readings die du dann entsprechend weiter verarbeiten kannst.
Ich nutze die Daten sowohl als auch... Ich möchte schon sowohl für das Netzwerk "OK Lab Stuttgart" weiterhin Daten liefern also auch diese Daten für mich in FHEM nutzen.
Im Grunde genommen habe ich ja alles was ich brauche, lediglich greife ich momentan die Daten für FHEM local ab sende aber parallel über die API die Daten an OK Lab Stuttgart, was hin und wieder zu Problemen führt.
Wenn man jedoch den "zweiten" Zusatzsensor (in meinem Fall BMP180) ebenfalls über die API von OK Lab Stuttgart auslesen könnte, bräuchte ich man ein zusätzliches locales auslesen nicht mehr. Der zweite Temperaturwert ist eigentlich überflüssig, ich nutze ihn zur Zeit nur zur Plausibilitierung der/des anderen Außentemperaturwerte.
ZitatJa, ist geplant, ich weiß nur noch nicht wie man mit dem zweiten Temperaturwert umgehen soll, da ja manche User den Sensor dann für einen ganz anderen Raum einsetzten und sich die DHT und BME/BMP Werte dann stark unterscheiden können. Hier war meine Idee mal, dass man auswählen kann welcher Sensor ausgewertet werden soll.
Werde mich bei Gelegenheit noch mal dransetzen.
Super, dann warte ich einfach ab... Vielen Dank :)
BG
Manuel
Möchtest du die Plausibilitätsprüfung für OK Lab Stuttgart der beiden Temperaturen machen, oder nur lokal die Prüfung machen?
Zitat von: Burny4600 am 06 Juni 2017, 18:09:36
Möchtest du die Plausibilitätsprüfung für OK Lab Stuttgart der beiden Temperaturen machen, oder nur lokal die Prüfung machen?
Nein nur lokal. Ich muss das auch nicht unbedingt machen. Wichtig ist vom BMP180 der Luftdruck.
Zitat von: igami am 28 Mai 2017, 23:57:49
Ich kann es mir jetzt auf die schnelle nicht erklären. Wenn nun wieder alles gut ist würde ich es dabei belassen und du meldest dich wieder, falls es noch Mal Auftritt.
Heute war es mal wieder soweit und ich habe wieder einige Einträge:
2017.06.25 17:57:13 1: PERL WARNING: Use of uninitialized value in index at ./FHEM/59_LuftdatenInfo.pm line 250.
2017.06.25 17:57:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:02:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:07:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:12:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:17:13 2: LuftdatenInfo (Luftdaten) - no second sensor foundHier ein aktuelles List:
Internals:
CONNECTION remote
DEF 1665
INTERVAL 300
NAME Luftdaten
NR 27
SENSORID1 1665
SENSORIDS implicit
STATE active
TIMEOUT 5
TYPE LuftdatenInfo
Helper:
Dblog:
Pm10:
Mydblog:
TIME 1498405933.93265
VALUE 16.77
Pm2.5:
Mydblog:
TIME 1498405933.93265
VALUE 15.47
Readings:
2017-06-25 17:52:13 PM10 16.77
2017-06-25 17:52:13 PM2.5 15.47
2017-05-05 16:12:23 latitude 48.307
2017-05-05 16:12:23 location 4020 Linz (Stadt)
2017-05-05 16:12:23 longitude 14.294
2017-06-25 17:52:13 state active
Attributes:
event-on-change-reading .*
room div
Hast du heute was an deinem FHEM gemacht? Update, Neustart oder so?
Gestern OS + FHEM Update eingespielt, aber die Meldungen treten erst seit heute 2017.06.25 17:57:13 auf.
Aber dafür jetzt regelmäßig.
Hatte vorhin kurz auf die Webseite von luftdaten.info geschaut, da war der Sensor nicht auf der Karte ersichtlich.
Jetzt ist er wieder gelistet und zeigt im Diagramm(siehe Anhang) direkt auf luftdaten.info einige Stunden keine Daten an. Der Zeitraum müsste überein stimmen.
Sind die denn immer noch da? Normal sollte der Fehler nur einmal kommen.
So sieht das Logfile aktuelle aus:
2017.06.25 17:57:13 1: PERL WARNING: Use of uninitialized value in index at ./FHEM/59_LuftdatenInfo.pm line 250.
2017.06.25 17:57:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:02:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:07:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:12:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:17:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:22:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:27:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:32:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:37:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:42:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:47:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:52:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 18:57:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:02:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:07:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:12:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:17:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:22:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:27:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:32:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:37:13 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:42:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:47:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:52:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 19:57:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 20:02:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 20:07:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 20:12:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 20:17:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 20:22:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 20:27:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
2017.06.25 20:32:14 2: LuftdatenInfo (Luftdaten) - no second sensor found
Nach 20:32 ist erstmal Ruhe
Deckt sich das mit dem Zeitpunkt seitdem er wieder erreichbar ist?
Genau sagen kann ich es leider nicht, aber laut dem Diagramm zwei Beiträge davor müssten sich die Zeiten decken.
Ich glaube ich hab den Fehler.
Schuld ist dieser Code Block:
elsif($data eq "[]"){
if( ndex($param->{url}, $hash->{SENSORID2}) > -1
&& InternalVal($SELF, "SENSORIDS", "implicit") eq "implicit"
){
delete($hash->{SENSORID2});
Log3($SELF, 2, "$TYPE ($SELF) - no second sensor found");
}
else{
Log3($SELF, 2, "$TYPE ($SELF) - no data returned");
readingsSingleUpdate($hash, "state", "no data", 1);
}
}
Da es $hash->{SENSORID2} nicht gibt wir trotzdem der if Teil ausgeführt. Ich habe das nun um eine Prüfung auf die SENSORID2 erweitert, sodass er nun in den else Teil springen sollte und dann im Log die korrekte Fehlermeldung steht.
Ab morgen 8 Uhr per update verfügbar.
Herzlichen Dank für deine Unterstützung!
Ich werde berichten wie es sich verhalten wird wenn der Sensor wieder mal ausfallen sollte.
Ich würde mir auch gerne so einen Sensor bauen. Würde mich daher über weitere Updates freuen. Da ich jetzt in eine größere Stadt gezogen bin, interessiert mich wirklich, was dabei rauskommt.
Zitat von: zindagi am 28 Juni 2017, 09:29:15
Ich würde mir auch gerne so einen Sensor bauen. Würde mich daher über weitere Updates freuen. Da ich jetzt in eine größere Stadt gezogen bin, interessiert mich wirklich, was dabei rauskommt.
Rajko ist da ziemlich aktiv am programmieren. In der neuesten Version kann man das Meßintervall in der Konfiguration ändern.
Updates kommen immer OTA, installieren sich selbstständig, man braucht also nix zu machen.
Ich habe in meinem Blog einige Feinstaubsensoren getestet,
https://blog.moneybag.de/fhem-staub-sensor-sharp-gp2y1010au/
https://blog.moneybag.de/fhem-lcd-display-1602-fuer-feinstaubsensor-sds011/
https://blog.moneybag.de/sds011-feinstaubsensor-fuer-fhem/
aber der SDS011 ist der Beste und läuft am stabilsten (mit Wemos D1 mini).
Viel Spaß beim Nachbauen!
LG
/robin
Hallo zusammen,
als erstes vielen Dank an alle Beteiligten!
Hab den Sensor (Wemos D1 mini) über das Binary von Jörg aus Post 240 am laufen. SDS011, DHT22 und TSL2561 funktionieren, ein BMP280 streikt der BME280 ist leider noch unterwegs. Das Gehäuse fehlt noch deshalb momentan nur lokale Abfrage.
Jetzt noch zwei Fragen:
- ist die Abfrage des TSL2561 über das Modul möglich, dann könnte ich mir die Abfrage über HTTPMOD sparen?
- bzw. habt ihr den SDS011 waagerecht oder hochkant verbaut?
Gruß
Stefan
PS: hab Schwierigkeiten mit dem kompilieren, evtl. könnte Jörg ein aktuelles Binary einstellen.
Ich wollte ja noch die Erweiterung für die anderen Sensoren einbauen, hatte ich glatt vergessen :-[
Ich bräuchte für die Lokale abfrage einmal den kompletten json mit dem TSL2561 Sensor.
Hallo,
anbei die Abfrage:
{"software_version": "NRZ-2017-082", "sensordatavalues":[{"value_type":"SDS_P1","value":"2.76"},{"value_type":"SDS_P2","value":"2.66"},{"value_type":"DHT_13_temperature","value":"17.70"},{"value_type":"DHT_13_humidity","value":"64.40"},{"value_type":"TSL2561_Float_IR","value":"12177.00"},{"value_type":"TSL2561_Float_Full","value":"32931.00"},{"value_type":"TSL2561_Float_Visible","value":"494.00"},{"value_type":"samples","value":"498088"},{"value_type":"min_micro","value":"286"},{"value_type":"max_micro","value":"27706"},{"value_type":"signal","value":"-48"}]}
Was für Werte und Einheiten sind denn
{
"value_type": "TSL2561_Float_IR",
"value": "12177.00"
}, {
"value_type": "TSL2561_Float_Full",
"value": "32931.00"
}, {
"value_type": "TSL2561_Float_Visible",
"value": "494.00"
}
?
TSL2561 Float Infrarot 14519.00 Lux (IR)
TSL2561 Float gesamter Bereich. 30911.00 Lux (Breitband)
TSL2561 Float sichtbarer Bereich. 272.00 Lux (Helligkeit)
Hallo,
ich habe meine Version jetzt auf die aktuelle Version gehoben. Außerdem habe ich noch ein define für DEBUG in der ext_def.h eingebaut. Somit kann die Produktivversion ohne Debug Informationen kompiliert werden. Hierzu die Zeile #define DEBUG_INFO auskommentieren.
Grüße Jörg
Hallo Jörg,
Zitat von: JoWiemann am 03 Juli 2017, 15:46:00
... ich habe meine Version jetzt auf die aktuelle Version gehoben.
könntest Du bitte für solche wie mich, die mit der Arduino IDE auf Kriegsfuß stehen, die compilierte Version mit anhängen? Mit DEBUG Ausgabe wäre aus meiner Sicht ok.
Danke + Gruß
Peter
Ich vrtrete die Meinung ein Thread, ein Thema.
KÖnnen wir für die alternative Firmware einen eigenen Thread aufmachen? Sonst blickt da doch irgendwann keiner mehr durch ;)
Zitat von: igami am 03 Juli 2017, 15:59:22
Ich vrtrete die Meinung ein Thread, ein Thema.
KÖnnen wir für die alternative Firmware einen eigenen Thread aufmachen? Sonst blickt da doch irgendwann keiner mehr durch ;)
Na gut,
dann geht es hier weiter: https://forum.fhem.de/index.php/topic,73879.0.html
Grüße Jörg
sind auch andere Lichtsensoren vorgesehen?
Ich habe hier noch gy 302 und gy 30 hier liegen.
LG
/robin
Hab selber noch keinen Sensor gebastelt. :-[ Steht aber auf der ToDo Liste. Zwischenzeitlich nutze ich die Daten eines in der Nähe befindlichen Sensors ;D Zusätzlich habe ich das nicht offizielle airquality-Modul im Einsatz, womit ich die Daten einer "professionellen" Umweltstation empfange.
Nun zur Frage: bei beiden konnte ich bei heutigem Gewitter extreme Feinstaubwerte feststellen. Zeigen die Geräte Unfug an oder hat es möglicherweise etwas mit den Staubaufwirbelungen durch den mit dem Gewitter einhergehenden stürmischen Böen zu tun ?
Grüße Markus
Bei dem Eigenbau steht auf der Website, dass es bei hohen Luftfeuchtigkeiten zu falschen Werten kommt. Ich vermute, dass liegt daran, dass dann Wassertröpfchen gezählt werden.
Vielen Dank für das Modul, läuft prima mit meinem Sensor zusammen. Nur eines verstehe ich nicht: warum ist das Minimum-Timeout 300s? Mein Sensor misst deutlich öfter, und ich hätte gerne _alle_ Messwerte.
Als ich das programmiert habe wurden bei luftdaten.info immer 5 Datensätze auf einmal übertragen. Um die Auslastung der Server so gering wie möglich zu halten habe ich daher das Intervall auch auf 5 Minuten gesetzt. Bei einer lokalen Abfrage kann ich das aber noch rausnehmen. Da darf dann jeder selbst entscheiden ;)
Ich bekomme seit gestern keine Temperatur und Luftfeuchtigkeit mehr rein
ZitatLuftdatenInfo (Luftdaten) - no second sensor found
Liegt das an der API oder am Modul?
Dann sind keine Daten von der API zurück gekommen. Einfach Mal ein modify machen nach einer Zeit.
Vielen Dank für die schnelle Antwort
Daten kommen wieder an
Ob es an dem Neustart lag, den ich gemacht habe oder ob die API kann ich nicht sagen
Zitat von: igami am 10 Juli 2017, 16:10:23
Um die Auslastung der Server so gering wie möglich zu halten habe ich daher das Intervall auch auf 5 Minuten gesetzt. Bei einer lokalen Abfrage kann ich das aber noch rausnehmen. Da darf dann jeder selbst entscheiden ;)
Ja, bitte, das wäre toll. Aktuell patche ich nämlich immer in Deinem Code die 300 in eine 30 um.
Danke,
Thomas
Der Sensor hat aber auch nur ein begrenzte Lebensdauer in Betriebsstunden
Zitat von: igami am 10 Juli 2017, 22:35:35
Der Sensor hat aber auch nur ein begrenzte Lebensdauer in Betriebsstunden
Korrekt, an der Messfrequenz habe ich auch nichts geändert. Ich will halt nur alle gemessenen Werte auch in FHEM haben, um einzelne Spitzen sehen zu können.
Vielen Dank für die Änderung des Timeouts! Funktioniert!
Habe heute die restlichen Sensoren bekommen.
BME280 und DHT22.
Nun benötige ich die Konfigurationsanleitung um diese Sensoren unter FHEM zusätzlich zu aktivieren.
Am Display des Sensors werden alle Daten angezeigt.
Unter FHEM fehlen mir einige.
Gibt es eine vollständige Anleitung für alle Sensoren die mit HTTPMOD (data.json) lokal unter FHEM eingelesen werden?
Zitat von: igami am 10 Juli 2017, 22:35:35
Der Sensor hat aber auch nur ein begrenzte Lebensdauer in Betriebsstunden
Lohnt sich denn die Anschaffung und das Projekt bei der begrenzten Lebensdauer oder wird das ein Groschengrab...?
Ciao, -MN
Ich habe mir das teil auch schon angeschaut. Ich hoffe die werden bald eine Möglichkeit haben das ganze mit lora zu betreiben, dann haelt die batterie auch länger ;)
Gesendet von iPhone mit Tapatalk
Zitat von: pronson am 13 Juli 2017, 16:08:57
Ich habe mir das teil auch schon angeschaut. Ich hoffe die werden bald eine Möglichkeit haben das ganze mit lora zu betreiben, dann haelt die batterie auch länger ;)
Geht jetzt schon. Ist jedenfalls im Code implementiert. Allerdings zieht der Luftsensor relativ viel Strom. Von daher wird das mit Batteriebetrieb nichts werden.
PS: Was hat die Lebensdauer des Sensors - und woher kommt die Info der Betriebsstunden - mit Batteriebetrieb zu tun?
Grüße Jörg
PS Schau auch mal hier:https://github.com/rexfue/Feinstaub_LoRa_ESP8266
Grüße Jörg
Bei mir werden die folgenden Readings nicht eingelesen.
Luftdruck des BME280 Sensors. reading07Regex BME280_pressure
Temperatur und Feuchte von DHT22. reading10Regex DHT22_temperature und reading11Regex DHT22_humidity
Sind die Definitionen der Attribute richtig?
Zitat von: Burny4600 am 13 Juli 2017, 21:58:45
Bei mir werden die folgenden Readings nicht eingelesen.
Luftdruck des BME280 Sensors. reading07Regex BME280_pressure
Temperatur und Feuchte von DHT22. reading10Regex DHT22_temperature und reading11Regex DHT22_humidity
Sind die Definitionen der Attribute richtig?
Das sieht mir sehr nach HTTPMOD aus. Es gibt ein ofizielles Modul für den Sensor, mit dem man die Daten sowohl lokal wie auch von Luftdaten.info abrufen kann.
Zitat von: Morgennebel am 13 Juli 2017, 14:59:49
Lohnt sich denn die Anschaffung und das Projekt bei der begrenzten Lebensdauer oder wird das ein Groschengrab...?
Ciao, -MN
Wenn ich das alles richtig im Kopf habe hat der Sensor eine Lebensauer von ca. 8000. Betriebsstunden und bei einer Messung pro minute macht das das 4 Jahre. Wenn man nur alle 5 Minuten misst kommt man auf ca. 20 Jahre, was ich deutlich attraktiver finde ;)
ZitatDas sieht mir sehr nach HTTPMOD aus. Es gibt ein ofizielles Modul für den Sensor, mit dem man die Daten sowohl lokal wie auch von Luftdaten.info abrufen kann.
Das ist mir schon klar, nur bekomme ich keine Daten von BME280_pressure, DHT22_humidity und DHT22_temperature.
Von dem SDS011, BME280_humidity und BME280_temperature bekomme ich Daten.
Finde aber nirgends einen Hinweis warum diese Daten lokal nicht ausgelesen werden.
In der aktuellen Firmware kann das Messinterval konfiguriert werden. Da kannst Du dann auch Deine 5 Minuten (360 sek) konfigurieren. Das Messinterval ist allerdings vollkommen unabhängig vom Abfrageinterval des Fehm-Moduls.
Grüße Jörg
Hallo zusammen,
ich Bau mir gerade auch einen Sensor zusammen, leider habe ich wohl gerade VCC und GND am Sensor vertauscht. Hat jemand ne Ahnung was da jetzt kaputt sein könnte? Der Ventilator dreht nicht mehr und Daten kommen auch keine. Hab keine laut wieder auf einen neuen Sensor zu warten.
Was könnte also kaputt gegangen sein, was man evtl. Austauschen könnte, jemand eine idee?
Danke und Grüße
Christian
Originalzitat von Luftfahrt.info:
WICHTIGER HINWEIS: Die Spannungsversorgung am SDS011 darf nicht verpolt angeschlossen werden, da dies die Laserdiode im Inneren des Sensors zerstört. (Ja, ich habe das selber ausprobiert [emoji853] )
Gesendet von iPhone mit Tapatalk
Hi,
Zitat von: JoWiemann am 17 Juli 2017, 18:45:56
Originalzitat von Luftfahrt.info:
WICHTIGER HINWEIS: Die Spannungsversorgung am SDS011 darf nicht verpolt angeschlossen werden, da dies die Laserdiode im Inneren des Sensors zerstört. (Ja, ich habe das selber ausprobiert [emoji853] )
danke für die Info, neuer ist geordert, schauen wir mal wie schnell der aus DE da ist, kostet dann auch nur 30€.
Grüße
Christian
Zitat von: Christian Uhlmann am 17 Juli 2017, 19:35:56
Hi,
danke für die Info, neuer ist geordert, schauen wir mal wie schnell der aus DE da ist, kostet dann auch nur 30€.
Grüße
Christian
Und ich dachte sowas passiert nur mir ;-)
Hallo,
habe mal den orig. Feinstaubsensor in Fhem eingebunden
define LuftInfo LuftdatenInfo 192.168.100.206
Wenn ich mir nun die Messwerte des Sensors ansehe,
dann kann der Sensor in die Zukunft sehen.
Fhem-Server ca. 09:10 Uhr - Client-Rechner ca. 09:10 Uhr
aber die Messwerte von 09:13 Uhr.
Hat sich hier ein Fehler in der Sensor-Software (original *.bin von Luftdaten.info)
oder in der LuftDatenInfo.pm eingeschlichen
oder aber kommt es vom großen Fehler vor dem Bildschirm. 8)
Gruß
Thomas
Zitat von: ThomasW am 23 Juli 2017, 10:33:17
Fhem-Server ca. 09:10 Uhr - Client-Rechner ca. 09:10 Uhr
Wie hast du den Server überprüft? Die Uhr oben links zeigt die Uhrzeit des Client an, nicht vom FHEM server ;)
Die Uhrzeit kommt von FHEM selbst. Du kannst du einfach mal einen dummy erstellen und state setzen dann sollte da auch eine "falsche" Uhrzeit stehen.
Hallo igami,
Danke das war es.
Also doch die dritte Fehlerquelle
Gruß
Thomas
Welches ESP8266 Modul verwendet ihr für den Luftdaten Sensor.
Ich habe das WeMos D1 Mini ESP8266 V3 im Einsatz und Probleme die http Seiten des Sensors aufzurufen.
Jetzt wo ich FHEM auf den Typ Luftdateninfo mit lokalem Zugriff via IP umgestellt habe finde ich unter state des öffteren das Reading error.
LIST
Internals:
ADDRESS 192.168.17.132
CFGFN
CONNECTION local
DEF 192.168.17.132
INTERVAL 30
NAME SDS011L
NR 730
STATE error
TIMEOUT 5
TYPE LuftdatenInfo
READINGS:
2017-07-24 19:23:53 PM10 11.17
2017-07-24 19:23:53 PM2.5 8.33
2017-07-24 19:30:23 humidity 52.48
2017-07-24 19:30:23 pressure 97311.80
2017-07-24 19:30:23 signal -49
2017-07-24 19:23:50 softwareVersion NRZ-2017-092
2017-07-24 19:30:53 state error
2017-07-24 19:30:23 temperature 25.90
Attributes:
group Sensoren
room Wetterstation
Auch die Datenübertragung an Luftdateninfo funktioniert nicht so wie es soll.
Der Aufbau erfolgte aber nach Vorgabe Luftdaten.info.
Woran das liegt ist mir ein Rätsel.
Hallo zusammen,
hat schon jemand ein devStateIcon für Luftdaten.info welches er teilen kann?
Mir schwebt da etwas vor, dass es Farblich angezeigt wird je nach dem welchen Wert entweder PM10 oder PM2.5 hat so wie auf
http://deutschland.maps.luftdaten.info/#6/51.165/10.455
unten Links, bzw. hier https://feinstaub-stuttgart.info/fragen-antworten/ auch genauer erklärt?
Wenn nein, dann würde ich mal mein Brain anschmeißen und schauen was ich mit meiner begrenzten Fähigkeit und Zeit zusammenzimmern kann :)
Grüße
Christian
Moin Moin,
ich würde dies gern als mein erstes ESP8266-Projekt nachbauen. Der Sensor ist heute angekommen (anscheinend ist AliExpress manchmal schneller als eBay-Deutschland).
Frage: ich habe noch mehrere ESP-201 (http://smarpl.com/content/esp8266-esp-201-module-first-impressions) herumliegen, kann ich diese statt der NodeMCU verwenden? Die ESP-201 lassen eine "richtige" WiFi-Antenne zu und erhöhen die Reichweite.
Muß ich dabei irgendwas beachten?
Danke, -MN
Zitat von: Morgennebel am 26 Juli 2017, 17:21:00
Moin Moin,
ich würde dies gern als mein erstes ESP8266-Projekt nachbauen. Der Sensor ist heute angekommen (anscheinend ist AliExpress manchmal schneller als eBay-Deutschland).
Frage: ich habe noch mehrere ESP-201 (http://smarpl.com/content/esp8266-esp-201-module-first-impressions) herumliegen, kann ich diese statt der NodeMCU verwenden? Die ESP-201 lassen eine "richtige" WiFi-Antenne zu und erhöhen die Reichweite.
Muß ich dabei irgendwas beachten?
Danke, -MN
Hallo,
mindestens 4 MB Flash size müssen es schon sein.
Grüße Jörg
Ich habe den Sensor auch nachgebaut, mit Originalfirmware auf einem Wemos D1 mini. Läuft soweit perfekt. Nachts schalte ich im Haus das WLAN komplett ab. Allerdings verbindet sich der Wemos nicht automatisch mit dem wiedereingeschalteten WLAN, sondern ist in der Zeit vermutlich als AP sichtbar. Ich muß für den re-connect erst den Sensor neu starten. Gibt es eine Lösung für ein automatisches Wiederverbinden, falls das WLAN wieder erscheint?
Der nach dem Restart wieder mit dem WLAN verbundenen Sensor wir alllerdings dann nicht vom LuftdatenInfo-Modul erkannt und zyklisch abgefragt, sondern erst nach einem StatusRequest. Das Modul wird über Nacht ebenfalls stillgelegt und startet morgens wieder. Gibt es dafür noch eine Einstellung, oder müßte ich dafür automatisch morgens noch per timer einen StatusRequest absetzen?
Gruß
G.
Zitat von: Gernott am 27 Juli 2017, 21:40:45
Der nach dem Restart wieder mit dem WLAN verbundenen Sensor wir alllerdings dann nicht vom LuftdatenInfo-Modul erkannt und zyklisch abgefragt, sondern erst nach einem StatusRequest. Das Modul wird über Nacht ebenfalls stillgelegt und startet morgens wieder. Gibt es dafür noch eine Einstellung, oder müßte ich dafür automatisch morgens noch per timer einen StatusRequest absetzen?
Ich meine es müsste dann eine Fehlermeldung kommen, dass der Sensor nicht erreichbar ist.
Es gibt noch das Attribut disabledForIntervals (http://commandref.fhem.de/#disabledForIntervals) was genau das macht was du möchtest.
Zitat von: igami am 28 Juli 2017, 06:17:00
/#disabledForIntervals]disabledForIntervals[/url] was genau das macht was du möchtest.
Das Attribut hatte ich auch verwendet. Wenn das Intervall aber endet, bevor der Sensor wieder mit dem WLAN verbunden ist, dann bleibt das Modul inaktiv. - Ideal wäre es, die Firmware erkennt das Wiedererscheinen seines WLAN und verbindet sich dann automatisch. Dann wäre das Problem mit dem Modul auch behoben.
Korrektur 30.07.17Der Sensor verbindet sich nach Einschalten des WLAN-Routers sofort wieder mit dem AP, daran liegt es also nicht. Nur das fhem-Modul erkennt den Sensor nicht, wenn er wieder im WLAN ist. Könnte man das mit einer wiederkehrenden Abfrage im Modul lösen?
Hallo zusammen,
ich betreibe den Sensor jetzt mit der alternativen Firmware, einem SDS011, einem DHT22 und einem BME280.
Mir kommt der Wert für den Luftdruck (pressure) irgendwie falsch vor.
Bei mir sind sowohl auf der Webseite vom Sensor als auch im FHEM Modul der Wert "99958.97", das kommt mir irgendwie deutlich zu hoch vor.
Sensor Page:
BME280 Luftdruck 99960.16 Pascal
FHEM Reading:
2017-08-07 21:02:25 pressure 99960.16
Sind nicht eher so Werte wie 999.5897 üblich? Also um die tausend (+/- 200 oder so).
Ist da ein Fehler (vermutlich sogar in der original Firmware) oder habe ich was falsch verstanden?
Grüße
Christian
Der BME gibt den Luftdruck in Pascal aus. Durch 1000 werden daraus die üblichen hPa. Die Firmware macht weiterhin keinerlei Umrechnung auf die aktuelle Meereshöhe Deines Standortes. Auch das musst Du durch ein UserReading in Fhem selber machen.
Grüße Jörg
Hi,
Zitat von: JoWiemann am 07 August 2017, 21:25:23
Der BME gibt den Luftdruck in Pascal aus. Durch 1000 werden daraus die üblichen hPa. Die Firmware macht weiterhin keinerlei Umrechnung auf die aktuelle Meereshöhe Deines Standortes. Auch das musst Du durch ein UserReading in Fhem selber machen.
alles klar, vielen Dank für die Aufklärung, wieder was gelernt :)
Grüße
Christian
Und ich wundere mich warum ich seit Tagen keine plausiblen Staubwerte bekomme.... Wohnen da zwei Spinnen drin...
Hab aber dennoch nen Problem.
Der Dht22 bringt auch schon ewig 99,9 % Feuchte. Auch bei Sonnenschein und Trockenheit. Woran kann das liegen? Kaputt?
Gesendet von meinem S3_32 mit Tapatalk
Was nimmst du denn da für einen Versorgungsspannung für den DTH22 ?
LG
/robin
Übrigens gab es da ein Update von der (original-) Firmware. Es werden jetzt mehrere Sensoren untersützt
https://blog.moneybag.de/sds011-feinstaubsensor-fuer-fhem/
Na den Dht22 versorge ich vom NodeMCU wie auf der Projektseite angegeben. Der bleibt jetzt aber weg und kommt nen BME280 dran.
Gesendet von meinem S3_32 mit Tapatalk
Hallo,
so, Feinstaubsensor läuft, auch mit der entsprechend "missbrauchten" HM-UART Platine, siehe hier (https://forum.fhem.de/index.php/topic,56606.msg680074.html#msg680074). So wie die vom OK Lab Stuttgart gesagt haben, sollte ein Intervall kleiner 5 Minuten gewählt werden, damit die Onlinegrafiken lückenlos sind. Ich hatte 10 Minuten, bin aber dann doch auf 5 Minuten runtergegangen. Also beobachten und ggf. ändern.
Gruß PeMue
Mein SD liefert mir seit heute fallsche Werte. 999,9 und 1999,9. Also jeweils der Endanschlag. Jemand eine Idee? Sd kaputt?
Gesendet von meinem S3_32 mit Tapatalk
so, der SDS wurde über Garantie getauscht da defekt.
Aber jetzt was anderes zum Modul:
der BME280 misst z.B. 995.34 hPa, im Modul werden 99533.85 geliefert.
Also das Komma um zwei Stellen verschoben.
Zitat von: Frank_Huber am 13 September 2017, 10:40:58
so, der SDS wurde über Garantie getauscht da defekt.
Aber jetzt was anderes zum Modul:
der BME280 misst z.B. 995.34 hPa, im Modul werden 99533.85 geliefert.
Also das Komma um zwei Stellen verschoben.
Dann handelt es sich wohl um Pa anstelle von hPa.
Wie soll ich damit umgehen? In der comanndref ist hPa angegeben, was nicht korrekt ist. ich könnte nun den Wert durch 100 Teilen oder die commandref ändern.
Wenn Du mich fragst dann würde ich es dem Sensor anpassen, hier sind es auch die hPa.
Zitat von: Frank_Huber am 13 September 2017, 11:02:00
Wenn Du mich fragst dann würde ich es dem Sensor anpassen, hier sind es auch die hPa.
Habe hier (https://forum.fhem.de/index.php/topic,73879.msg685090.html#msg685090) eine überarbeitete Version des Moduls zum testen bereitgestellt. Dadrin ist es mit
$_->{value} = ($_->{value} > 10000 ? $_->{value} / 100 : $_->{value});
umgesetzt.
Mit dem morgigen Update hat das Modul eine andere Syntax für die DEF. Die Migration sollte automatisch erfolgen.
Es kann nun ein physikalisches Device in mehrere logische devices aufgeteilt werden. Dies wird benötigt, wenn mehrere gleiche Sensoren (z.B. Temperatursensoren) an einem Node MCU betrieben werden aber unterschiedliche Standorte haben.
Zitat von: Dersch am 16 Oktober 2017, 15:37:20
Also irgendwie geht es doch nicht
hier ist mal das List:
Internals:
CFGFN
DEF remote 4305 4306
INTERVAL 300
MODE remote
NAME Feinstaubsensor
NR 758
SENSORIDS 4305 4306
STATE P1:PM10 P2:7.27 T:0 H:36.50 D:dewpoint
TIMEOUT 5
TYPE LuftdatenInfo
READINGS:
2017-10-16 15:35:50 PM2.5 7.27
2017-10-16 15:35:50 humidity 36.50
2017-10-16 15:35:41 latitude 49.926
2017-10-16 15:35:42 location 64331 Weiterstadt
2017-10-16 15:35:41 longitude 8.608
2017-10-16 15:35:50 state active
2017-10-16 15:35:44 temperature 0
Attributes:
group Umweltsensoren
icon weather_pollen
room Dach
stateFormat P1:PM10 P2:PM2.5 T:temperature H:humidity D:dewpoint
Er aktualisiert doch nicht Temo und Humidity und PM10 kommt nun nicht mehr in den readings vor..
Da das ganze nichts mit der alternativen Firmware zu tun hat geht es hier weiter.
Irgendwie ist das JSON welches ich als Antwort bekomme nun anders aufgebaut. Das muss ich im Modul anpassen.
bei PM10 habe ich heute seit Mittag ca. auch Aussetzer.
rufe die Daten vom Server ab.
Modulversion 59_LuftdatenInfo.pm 14691 2017-07-11 09:11:30Z igami
Hat wohl eher nichts mit dem Modul zu tun.
Ja gut möglich, Jetzt funktioniert auch wieder alles wie es soll ohne weiteres zutun.
Hi,
bei mir hat es wohl beim Update die DEF zermehrt, da fehlte nach dem local die IP, und ich wundere mich, warum seit heute früh (Updatetime) ein error als Status kommt ;)
Ronny
Guten Morgen
Seit einigen Tagen habe ich im Logfile diesen Eintrag für drei Sensoren, woran liegt das?
error while request: connect to http://api.luftdaten.info:80 timed out
Fhem update gestern 16.10.2017
Grüße
Heinz
Das kann am Design der Firmware liegen. Immer dann, wenn die Sensoren abgefragt werden und der Versand nach Luftdaten erfolgt wird der Server gestoppt um möglichst konsistente Daten zu erzeugen und zu versenden. Erfolgt in diesem Zeitfenster eine Abfrage von Fhem, dann kommt es zum Timeout. In der Firmware ist ein Versand an einen lokalen Server vorgesehen. Vielleicht kann man ja das Fhem Modul so umbauen, dass es mit dieser Funktion nutzbar wird.
Gesendet von iPhone mit Tapatalk
Grüße Jörg
Zitat von: heinzfo am 17 Oktober 2017, 07:47:15
Seit einigen Tagen habe ich im Logfile diesen Eintrag für drei Sensoren, woran liegt das?
error while request: connect to http://api.luftdaten.info:80 timed out
Moin,
Das klingt dannach als ob der Luftdateninfo Server Schluckauf hat.
deckt sich auch mit meinen abgerufenen Daten.
Die Plots haben einige Aussetzer. Anfangs nur PM10, seit gestern auch PM2.5
Ok, Danke!
Gesendet von meinem SM-G930F mit Tapatalk
seit heute ca 8:00 ist der Server wohl wieder stabil.
Zitat von: Frank_Huber am 17 Oktober 2017, 14:02:50
seit heute ca 8:00 ist der Server wohl wieder stabil.
Ja, bis um 8 Uhr am Morgen gab es wohl ein Problem :(
Gruß PeMue
Zitat von: rcmcronny am 16 Oktober 2017, 20:59:28
Hi,
bei mir hat es wohl beim Update die DEF zermehrt, da fehlte nach dem local die IP, und ich wundere mich, warum seit heute früh (Updatetime) ein error als Status kommt ;)
Ronny
Da hatte ich leider einen Fehler in der Migration, ist aber mittlerweile schon behoben.
Zitat von: PeMue am 17 Oktober 2017, 15:58:43
Ja, bis um 8 Uhr am Morgen gab es wohl ein Problem :(
Gruß PeMue
Das kann ich bestätigen. Seit heute morgen 8 Uhr bekomme ich auch wieder alle Werte :)
Hallo igami,
heute ist mein SDS011 mit USB eingetroffen. Da mir noch der Wemos fehlt und ich den Sensor im Innenraum einsetzen möchte, stellte sich mir die Frage, warum überhaupt den Umweg über den Wemos gehen. Hast Du evtl. eine solche Erweiterung angedacht bzw. hältst Du sie überhaupt für sinnvoll, da ja dann doch komplett anderer Zugriff, Format, Ansteuerung des sds011 ?
Grüße Markus
Ich bin kein Hardware Bastler. Der Feinstaubsensor kommt ja ursprünglich von Luftdaten.info aus Stuttgart. Ich wollte die Daten lediglich in FHEM haben und habe dafür das Modul geschrieben.
Ich doch auch nicht ;) Deshalb wäre es ja so schön den SDS011 ohne jegliches Basteln an dem Rpi über USB(TTL)zu betreiben. Einziger Grund es nicht zu tun: kein FHEM-Modul >:(
Edit: Aber das wäre dann eher ein SDS011-Modul, als luftdaten.info
Hallo,
Ich bin Dominik aus Graz und das ist mein erster Post in diesem Forum.
Ich habe FHEM seit einer Weile am laufen und habe mich nun entschlossen den Feinstaubsensor zu bauen.
der DHT011 wird wohl noch eine weile auf sich warten lassen, aber der WEMOS ist bereits mit der orginalfirmware geflashed und DHT22 sowie BME280 sind verbunden und senden ihre Date bereits an:
https://opensensemap.org/explore/5a01b4ad03a566000f68f8e9
im FHEM habe ich die Box mittels
define myWeatherstation LuftdatenInfo local <IP>
angelegt - soweit so gut.
Nur scheint es das Problem zu geben, dass das Modul die Feuchte und Temperatur werte von DHT und BME nicht außeinander halten kann. (Wie das mit luftdaten.info online sein wird kann ich noch nicht sagen, da der eigentliche Partikelsensor noch fehlt).
Müsste ich hier noch ein paar zusätzliche Einstellungen machen, oder ist im Modul (?noch nicht?) vorgesehen?
Gruß
Dominik
Du musst noch ein weiteres Gerät als slave anlegen
Danke für den tip
ich habe nun beim master mit get Sensors die Liste der in FHEM zur fefügung gestellten Kanäle abgefragt (dort waren BME280_temperature BME280_pressure BME280_humidity usw enthalten).
und daraus abgeleitet.
define LDI_slave LuftdatenInfo local BME280_temperature BME280_pressure BME280_humidity
seitdem kann ich die werte des DHT22 am master sauber mitloggen und am slave die Werte des BME280 daher scheint es für mich gelöst.
Ist das so gedacht der müsste ich auch für den DHT einen Slave anlegen?
Gruß
Dominik
Nein, das ist so gedacht. Kannst du aber nach belieben noch trennen. Der Gedanke dahinter ist die verschiedenen physikalischen Standorte auch in FHEM zu trennen.
Moin,
läßt sich evtl. dieses hier in die Lösung integrieren: https://www.cooking-hacks.com/documentation/tutorials/geiger-counter-radiation-sensor-board-arduino-raspberry-pi-tutorial/ ?
Danke, -MN
Hallo
Vor 10 Tagen habe ich den DHT22 wegen falscher Feuchtigkeitswerte gegen einen BME280 getauscht. Der Nachbau ist Original, die Firmware ebenfalls (NRZ-2017-099).
Nachdem der Sensor vorher einwandfrei gelaufen ist, bekomme ich jetzt wiederholt nach 2,5 Tagen keine Werte vom SDS011 mehr. Der Sensor wird nicht mehr aktiviert (Lüfter läuft nicht an) und die Readings bleiben leer. Der BME liefert dagegen weiter fröhlich Daten.
Ein Reset im Webinterface des Sensors reaktiviert den SDS auch nicht. Nur eine Unterbrechung der Spannungsversorgung bringt ihn wieder für 2,5 Tage zum Laufen.
Hat jemand eine Ahnung, woran das liegen könnte? - Werde nochmal den DHT dranklemmen und schauen, ob der durchläuft.
Gruß
G.
Evtl am Netzteil?
Was hast denn dran hängen?
Mit dem Handy online, daher kurz gefasst...
Zitat von: Frank_Huber am 26 November 2017, 12:44:37
Evtl am Netzteil?
Was hast denn dran hängen?
Den SDS und nun den BME statt DHT. Netzteil ist eher nicht der Grund, es läuft ja einige Zeit.
Würd ich so nicht sagen. Kann auch am Netzteil liegen.
Sind es immer genau genau 2,5 Tage?
Was für ein Netzteil hast du?
Mit dem Handy online, daher kurz gefasst...
Ich beobachte den gleichen Fehler in meinem Setup: Habe ebenfalls den selben Aufbau aus Feinstaub Sensor und BME280.
Nach ca. 2-4 Tagen liefert der Feinstaub Sensor keine neuen Werte, der BME hingegen macht fröhlich weiter.
Es hilft bei mir auch nur ein Trennen der Stromversorgung.
Zitat von: nanocosmos am 26 November 2017, 22:35:01
Ich beobachte den gleichen Fehler in meinem Setup: Habe ebenfalls den selben Aufbau aus Feinstaub Sensor und BME280.
Nach ca. 2-4 Tagen liefert der Feinstaub Sensor keine neuen Werte, der BME hingegen macht fröhlich weiter.
Es hilft bei mir auch nur ein Trennen der Stromversorgung.
Aha, das klingt gut. Wenn sich noch ein Dritter meldet, haben wir ein systematisches Problem. - Läuft es ohne den BME durch?
Gruß
G.
ich habe einen BME und den SD am laufen.
der Sensor läuft in dem Setup seit Monaten durch.
Original-FW auf NodeMCU v3
Zitat von: Gernott am 26 November 2017, 12:28:54
Werde nochmal den DHT dranklemmen und schauen, ob der durchläuft.
UpdateMit dem DHT tritt das Problem nicht mehr auf, es läuft jetzt seit Sonntag. Werde im nächsten Schritt mal den BME280 dazuhängen und berichte dann wieder.
Hallo Igami
Ich habe einen SDS011, einen VEML und einen BME280 mit der Firmware NRZ-2017-100-AF-020 am Laufen. Alle paar Wochen bekomme ich vom NodeMCU v3 bzw. BME280 dann -1 bzw. 65536 retour.
2017-12-26_12:14:53 Feinstaub_1 PM10: 43.60
2017-12-26_12:14:53 Feinstaub_1 PM2.5: 21.43
2017-12-26_12:14:53 Feinstaub_1 UVIntensity: 4.95
2017-12-26_12:14:53 Feinstaub_1 temperature: 65536
2017-12-26_12:14:53 Feinstaub_1 humidity: -1
2017-12-26_12:14:53 Feinstaub_1 pressure: -1
2017-12-26_12:14:53 Feinstaub_1 pressureNN: 1013
2017-12-26_12:14:53 Feinstaub_1 signal: -75
Vermutlich ein Fehler beim Lesen der Sensordaten über den I2C Bus. Leider werden die falschen Werte dann auch in der Logdatei gespeichert und die Grafik schaut auch nicht schön aus. Könntest Du vielleicht die Datei ,,59_LuftdatenInfo.pm" dahingehend anpassen, dass bei -1 bzw. 65536 ,,error" als Reading übergeben wird und nicht die falschen Werte. Ich kenne mich mit Perl leider nicht aus.
Oder hat jemand eine Idee wie man dies über die Attribute abfangen könnte?
Danke
Jonny
Hallo,
die genannten Werte werden generiert, wenn beim Lesen vom Sensor ein Fehler erkannt worden ist. Das Filtern im Modul halte ich für nicht sinnvoll. Du kannst ja entweder ein UserReading erstellen, in dem die Werte heraus gefiltert werden oder Du machst es über eine Function im GPLOT.
Grüße Jörg
Mir soll es gleich sein. Ein "error" wird aber glaube ich auch als 0 im Plot dargestellt.
Zitat von: igami am 26 Dezember 2017, 19:42:31
Mir soll es gleich sein. Ein "error" wird aber glaube ich auch als 0 im Plot dargestellt.
Hm, ich würde da gerne kompatible zur original Firmware bleiben.
Grüße Jörg
Dann mache ich einfach nichts :)
ZitatZitat von: nanocosmos am 26 November 2017, 22:35:01
Ich beobachte den gleichen Fehler in meinem Setup: Habe ebenfalls den selben Aufbau aus Feinstaub Sensor und BME280.
Nach ca. 2-4 Tagen liefert der Feinstaub Sensor keine neuen Werte, der BME hingegen macht fröhlich weiter.
Es hilft bei mir auch nur ein Trennen der Stromversorgung.
Aha, das klingt gut. Wenn sich noch ein Dritter meldet, haben wir ein systematisches Problem. - Läuft es ohne den BME durch?
habt ihr das Problem irgendwie lösen können? Hab jetzt auch einen BME280 dazugehängt. Die Werte vom BME und DHT kommen normal. Der Feinstaub-Sensor hat seitdem nichts mehr geliefert.
Werden auf der Website denn Werte angezeigt?
Nein... da steht für den Feinstaub nur die Einheit. Bis zum Anschluss des BME hats super funktioniert
Dann berichte das bitte in dem anderen Thread (alternative Firmware (https://forum.fhem.de/index.php/topic,73879.0.html)) oder, falls du diese nicht nutzt, wende dich an luftdaten.info.
Ich schreibe nur das Modul um die Daten in FHEM bereit zu stellen.
Geht es denn wieder wenn du den bme abklemmst?
Wie ist deine pinbelegung?
Ich hab den sd mit bme und original Firmware schon lange problemlos am laufen.
Mit dem Handy online, daher kurz gefasst...
Sorry, und Attacke zurück. Ich hab das Gehäuse noch mal geöffnet und es war wohl ein Pin rausgerutscht jetzt geht wieder alles!
Edit: noch ein Vorschlag/Bitte für den Entwickler des Moduls. Ich bekomme permanent Log-Einträge, dass mein interner Feinstaubsensor nicht erreichbar ist. Kann an WLAN liegen oder wie hier bereits beschrieben daran, dass der Sensor gerade anderweitig beschäftigt ist. Da ich das Problem kenne und der Fehler nur ab und zu auftritt (für mich akzeptabel) würde ich die Log-Mitteilung gerne deaktivieren. Kann man das irgendwie einbauen oder reicht da ein Verbose 0?
Zitat von: StephanFHEM am 14 Januar 2018, 15:08:46
habt ihr das Problem irgendwie lösen können?
Nein, ist noch ungelöst:
https://github.com/opendata-stuttgart/sensors-software/issues/172
Zitat von: StephanFHEM am 14 Januar 2018, 16:16:51
Edit: noch ein Vorschlag/Bitte für den Entwickler des Moduls. Ich bekomme permanent Log-Einträge, dass mein interner Feinstaubsensor nicht erreichbar ist. Kann an WLAN liegen oder wie hier bereits beschrieben daran, dass der Sensor gerade anderweitig beschäftigt ist. Da ich das Problem kenne und der Fehler nur ab und zu auftritt (für mich akzeptabel) würde ich die Log-Mitteilung gerne deaktivieren. Kann man das irgendwie einbauen oder reicht da ein Verbose 0?
verbose 1 würde reichen
Ich bekomme die Meldungen selbst auch. Meine Vermutung ist, dass der Sensor gerade beschäftigt ist. Vielleicht baue ich aber ein verbose_network Attribut ein.
Der Feinstaubsensor mit Temperatur, Luftfeuchte und Luftdruck ist schon genial.
Nur kann ich meinen Sensor nicht in FHEM einbinden. Ich finde LuftdatenInfo nicht in der FHEM Referenz (jedenfalls bei meiner Installation). Auf der Internetseite unter
https://fhem.de/commandref.html
wird es jedoch aufgeführt. Ich habe auch Version 5.8 installiert.
Verstehe ich nicht.
Hallo zusammen,
in der c't im Dezember (Heft 01/2018) war ein Artikel über einen mobilen Feinstaubsensor, siehe https://www.heise.de/ct/ausgabe/2018-1-Feinstaub-unterwegs-messen-und-mit-GPS-Daten-aufzeichnen-3919188.html
@sky667: Schau doch mal, ob das Modul in Deiner Installation vorhanden ist (im Unterverzeichnis FHEM):
pi@blablub:/opt/fhem/FHEM $ ls -la | grep LuftdatenInfo
-rw-r--r-- 1 fhem dialout 26092 Okt 28 17:42 59_LuftdatenInfo.pm
Gruß PeMue
@PeMue: ich bin ziemlich unvorbereitet auf das ct-Projekt gesprungen. Einfache Anleitung, schneller Erfolg.
leider kommen die Fragen im 2ten Schritt!
a) leider hat das Projekt keinen Temperatur-/Luftfeuchtesensor
b) leider hat das Projekt keine Anbindung an luftdaten.info
c) leider bietet das Projekt keine Einbindung in fhem
d) leider scheint das Projekt den Dauerbetrieb des Sensors nicht zu berücksichtigen (ok für einen nur mobilen Einsatz ist das ok, aber ein Mischbetrieb?)
Mein learning: bevor ich wieder ein neues Thema anfasse: bei FHEM 'reinlesen!
Wo habt ihr eure Sensoren eigentlich montiert? In Bodennähe, auf dem Dach? Was ist bevorzugt als Ort?
Am Schuppendach. ca 3m Höhe, keine direkte Sonne.
(Pultdach, First am Norden. da dahinter der Sensor)
musste meinen Sensor allerdings mit Fliegengitter sichern.
hatte mehrfach eine Spinne im Ansaugschlauch nisten...
Mein Sensor sitzt am Balkongeländer an der Hauswand, bestimmt kein idealer Ort.
Hätte die Möglichkeit das auf dem Dach am Mast hinter der Sat Schüssel zu montieren ca. 11m hoch oder
Wettergeschützt an der Hauswand Nordseite ca. 2m hoch. Zur spinnenproblematik fällt mir ein Luftfilter aus dem Modellbau ein. Was meint ihr?
Grüße
Matze
Zitat von: smoudo am 10 Februar 2018, 20:55:01
Hätte die Möglichkeit das auf dem Dach am Mast hinter der Sat Schüssel zu montieren ca. 11m hoch oder
Wettergeschützt an der Hauswand Nordseite ca. 2m hoch. Zur spinnenproblematik fällt mir ein Luftfilter aus dem Modellbau ein. Was meint ihr?
Grüße
Matze
Hauswand Nord.
Dach hat evtl zuviel Luftzug.
Luftfilter könnte auch das Ergebnis verfälschen.
Nimm lieber nen fliegennetz. Mit Kabelbinder ums ht Rohr und gut is.
Mit dem Handy online, daher kurz gefasst...
Hallo
ich habe schon seit längerem einen Feinstaubsensor am Laufen und wollte diesen nun auch in FHEM einbinden. Ich möchte die Daten lokal abrufen und habe ihn mit
define out_sens_Feinstaub LuftdatenInfo local <lokaler IP>
konfiguriert.
Im Log (verbose 5) tauchen nun alle 30 Sekunden die folgenden Einträge auf
2018.02.12 21:12:28 5: LuftdatenInfo (out_sens_Feinstaub) - entering LuftdatenInfo_statusRequest
2018.02.12 21:12:28 5: LuftdatenInfo (out_sens_Feinstaub) - entering LuftdatenInfo_GetHttpResponse
2018.02.12 21:12:29 5: LuftdatenInfo (out_sens_Feinstaub) - entering LuftdatenInfo_ParseHttpResponse
2018.02.12 21:12:29 4: LuftdatenInfo (out_sens_Feinstaub) - returned data: {"software_version": "NRZ-2017-099", "age":"55", "sensordatavalues":[{"value_type":"SDS_P1","value":"46.20"},{"value_type":"SDS_P2","value":"16.97"},{"value_type":"temperature","value":"1.80"},{"value_type":"humidity","value":"70.20"},{"value_type":"samples","value":"620624"},{"value_type":"min_micro","value":"225"},{"value_type":"max_micro","value":"805850"},{"value_type":"signal","value":"-80"}]}
Verbindung scheint also prinzipiell mal zu funktionieren.
In anderen Beispielen in diesem Thread habe ich gesehen, dass nach der Zeile mit "returned data" noch weitere Zeilen mit "parsing SDS011 data" und den Sensorwerten.
z.B.
2017.04.16 07:45:38 5 : LuftdatenInfo (Luftdaten) - parsing SDS011 data
2017-04-16 07:45:38 LuftdatenInfo Luftdaten PM10: 6.50
2017-04-16 07:45:38 LuftdatenInfo Luftdaten PM2.5: 3.62
Da diese bei mir nicht erscheinen bin ich mir nicht ganz sicher, ob bei meiner Konfig schon alles i.O. ist. Zumindest würde es mir dann deutlich leichter fallen das Ganze in ein FileLog und einen Plot zu überführen. Kann mir jmd. sagen, was bei meiner Konfig noch fehlt?
Gruß Markus
Zitat von: Oger am 12 Februar 2018, 21:29:01
In anderen Beispielen in diesem Thread habe ich gesehen, dass nach der Zeile mit "returned data" noch weitere Zeilen mit "parsing SDS011 data" und den Sensorwerten.
Bei einer lokalen abfrage kommen diese Zeilen nicht.
Werden denn Readings erzeugt? Falls ja, ist alles richtig und fertig.
Vielen Dank, dann wäre das schon mal geklärt. Die Werte erscheinen auch in den Readings.
Dann muss ich mich wohl mal näher mit regex auseinandersetzen, um die Werte in ein FileLog zu überführen, so dass ich sie dann für einen Plot nutzen kann.
Habe es leider noch nicht hinbekommen mit regex die Werte aus dem JSON String in ein FileLog zu packen.
Der Einfachheit halber habe ich mir den Feinstaubsensor daher nochmal als remote definiert. Aber auch dort erhalte ich nicht die Ausgabe der einzelnen Werte im Logfile.
2018.02.19 09:01:52 5: LuftdatenInfo (out_sens_Feinstaub_rem) - entering LuftdatenInfo_statusRequest
2018.02.19 09:01:52 5: LuftdatenInfo (out_sens_Feinstaub_rem) - entering LuftdatenInfo_GetHttpResponse
2018.02.19 09:01:52 5: LuftdatenInfo (out_sens_Feinstaub_rem) - entering LuftdatenInfo_ParseHttpResponse
2018.02.19 09:01:52 4: LuftdatenInfo (out_sens_Feinstaub_rem) - returned data: [{"sampling_rate":null,"sensor":{"sensor_type":{"name":"SDS011","manufacturer":"Nova Fitness","id":14},"pin":"1","id":5931},"sensordatavalues":[{"value":"45.90","value_type":"P1","id":1767785319},{"value":"24.33","value_type":"P2","id":1767785320}],"location":{"altitude":"101.8","latitude":"49.367","country":"DE","longitude":"8.528","id":2991},"timestamp":"2018-02-19 07:56:33","id":816159800},{"sampling_rate":null,"sensor":{"sensor_type":{"name":"SDS011","manufacturer":"Nova Fitness","id":14},"pin":"1","id":5931},"sensordatavalues":[{"value":"40.65","value_type":"P1","id":1767800440},{"value":"23.00","value_type":"P2","id":1767800441}],"location":{"altitude":"101.8","latitude":"49.367","country":"DE","longitude":"8.528","id":2991},"timestamp":"2018-02-19 07:59:00","id":816166956}]
2018.02.19 09:01:52 5: LuftdatenInfo (out_sens_Feinstaub_rem) - parsing SDS011 data
Nach der Zeile mit parsing SDS011 data kommen keine weiteren Zeilen
Doch noch irgendein Fehler in meiner Konfig?
Oder bohre ich gerade an der falschen Stelle und es gibt einen einfacheren Weg die Daten in ein FileLog zu packen?
Gruß Markus
Sorry, habe wohl zu lange nichts mehr mit FHEM gemacht und war komplett auf dem Schlauch gestanden.
Musste ja einfach nur das Filelog mit regexp <Sensorname>:.* definieren und alles war gut.
Keine Ahnung warum ich so fixiert darauf war, dass die Werte im Logfile erscheinen müssen.
Hoffe ich habe nicht für zu viel Verwirrung gesorgt.
Gruß Markus
Hallo zusammen,
am 26. Januar sind meine Feinstaubwerte über 3 Tage kontinuierlich nach oben gegangen und hängen auf 500 (PM10) und etwa 250 (PM2.5) fest. Da der Sensor auf dem Dach hängt, möchte ich natürlich nicht rausgehen und nachschauen. Habe gerade rebootet, aber die Werte bleiben so hoch.
Entweder brennt jemand seinen Ofen in der Nähe ab oder der Sensor mag nicht mehr so recht.
Hat das jemand von Euch schon mal gehabt?
Danke + Gruß
Peter
Welches Gehäuse nutzt ihr? Finde die 2 HT bögen nicht sonderlich chick! Alternativen vorhanden?
Grüße
Matze
https://www.thingiverse.com/search?q=feinstaub (https://www.thingiverse.com/search?q=feinstaub)
lg, Stefan
Sieht gut aus! Hast du einen Drucker oder wo lässt du das machen?
Grüße
Matze
Habs selber gedruckt.
Hab mich zu Weihnachten damit selbst beschenkt :D
Dann hast du auf alle Fälle das richtige Geschenk bekommen ;D
Kannst du dir vorstellen für entsprechende Entlohnung + Porto mir auch eins zu drucken?
Hab meinem Laserdrucker zwar gut zugeredet aber das Ding will mit filament nichts zu tun haben ;)
Viele Grüße
Matze
Zitat von: smoudo am 23 Februar 2018, 18:05:18
Hab meinem Laserdrucker zwar gut zugeredet aber das Ding will mit filament nichts zu tun haben ;)
Versuch's doch mal mit Harz, vielleicht mag er das ;D ;D ;D
Btw: versuch's doch mal bei https://www.3dhubs.com/, vielleicht ist ein Hub bei Dir in der Nähe, die Preise sind m.E. ganz ok.
Gruß PeMue
Den Service kannte ich noch nicht. Die Preisspannen zwischen den Anbietern sind schon extrem.
In der Nähe ist zwar keiner, aber schicken lassen geht ja auch!
Bin mal gespannt wie das dann ankommt :) Ich werde berichten!
Viele Grüße
Matze
Vielleicht eine alternative
https://www.conrad.de/de/info-und-services/individuelle-produkt-services/3d-druck-service.html
Ich für meinen Teil bin mit dem Abwasserrohr ganz zufrieden :P
Ich bin aus der haustechnik Branche. Wenn ich mir sowas an die wand schraube, denkt die Nachbarschaft ich bin komplett durchgedreht und irgendein Spaßvogel drehts garantiert im und kippt was rein :D
Von daher bin ich mal auf den Druck gespannt!
Viele Grüße
Matze
Off Topic, die Branche ist aber keine gute Referenz für vernünftiges Design. Von daher kannst Du das so aufhängen.
Gesendet von iPhone mit Tapatalk
Grüße Jörg
Zitat von: JoWiemann am 24 Februar 2018, 10:40:58
Off Topic, die Branche ist aber keine gute Referenz für vernünftiges Design.
Die Zeiten von Moosgrün und dunklen Heizräumen sind zum Glück vorbei!
;D
Grüße
Matze
Wäre kein Problem, für jemanden solche Gehäuse zu drucken.
Gebt mir aber bitte noch eine Woche oder so Zeit, bis ich mein ABS-Filament bekommen habe.
Aktuell hab ich nur PLA hier, das ist ja nicht so unbedingt Outdoor-geeignet.
Ansonsten, wenn jemand was braucht -> PN
lg, Stefan
bekomme seit heute ca 14:30 keine Daten mehr von Luftdaten.info.
2018.03.26 16:55:40 2: LuftdatenInfo (Luftdaten_remote) - BME280 position differs from other sensor position
2018.03.26 16:55:40 2: LuftdatenInfo (Luftdaten_remote) - SDS011 position differs from other sensor position
2018.03.26 17:00:40 2: LuftdatenInfo (Luftdaten_remote) - BME280 position differs from other sensor position
2018.03.26 17:00:40 2: LuftdatenInfo (Luftdaten_remote) - SDS011 position differs from other sensor position
Verbose 5:
2018.03.26 17:46:09 5: LuftdatenInfo (Luftdaten_remote) - entering LuftdatenInfo_statusRequest
2018.03.26 17:46:09 5: LuftdatenInfo (Luftdaten_remote) - entering LuftdatenInfo_GetHttpResponse
2018.03.26 17:46:09 5: LuftdatenInfo (Luftdaten_remote) - entering LuftdatenInfo_GetHttpResponse
2018.03.26 17:46:13 5: LuftdatenInfo (Luftdaten_remote) - entering LuftdatenInfo_ParseHttpResponse
2018.03.26 17:46:13 4: LuftdatenInfo (Luftdaten_remote) - returned data: [{"sensordatavalues":[{"value_type":"P1","id":2106389073,"value":"55.00"},{"value_type":"P2","id":2106389074,"value":"31.13"}],"location":{"latitude":"49.0280","id":823,"altitude":"115.6","longitude":"8.4540","country":"DE"},"sampling_rate":null,"id":976492264,"sensor":{"sensor_type":{"manufacturer":"Nova Fitness","name":"SDS011","id":14},"id":1651,"pin":"1"},"timestamp":"2018-03-26 15:42:49"}]
2018.03.26 17:46:13 5: LuftdatenInfo (Luftdaten_remote) - parsing SDS011 data
2018.03.26 17:46:13 2: LuftdatenInfo (Luftdaten_remote) - SDS011 position differs from other sensor position
2018.03.26 17:46:13 5: LuftdatenInfo (Luftdaten_remote) - entering LuftdatenInfo_ParseHttpResponse
2018.03.26 17:46:13 4: LuftdatenInfo (Luftdaten_remote) - returned data: [{"sensordatavalues":[{"value_type":"temperature","id":2106389123,"value":"11.60"},{"value_type":"humidity","id":2106389124,"value":"51.00"},{"value_type":"pressure","id":2106389126,"value":"100335.60"},{"value_type":"pressure_at_sealevel","value":101734.78}],"location":{"latitude":"49.0280","id":823,"altitude":"115.6","longitude":"8.4540","country":"DE"},"sampling_rate":null,"id":976492289,"sensor":{"sensor_type":{"manufacturer":"Bosch","name":"BME280","id":17},"id":1652,"pin":"11"},"timestamp":"2018-03-26 15:42:50"}]
2018.03.26 17:46:13 5: LuftdatenInfo (Luftdaten_remote) - parsing BME280 data
2018.03.26 17:46:13 2: LuftdatenInfo (Luftdaten_remote) - BME280 position differs from other sensor position
Bei mir geht es Problemlos:
defmod Frank_Huber LuftdatenInfo remote 1651 1652
setstate Frank_Huber active
setstate Frank_Huber 2018-03-26 20:52:51 PM10 81.30
setstate Frank_Huber 2018-03-26 20:52:51 PM2.5 42.50
setstate Frank_Huber 2018-03-26 20:52:52 dewpoint 5.2
setstate Frank_Huber 2018-03-26 20:52:52 humidity 80.06
setstate Frank_Huber 2018-03-26 20:52:51 latitude 49.0280
setstate Frank_Huber 2018-03-26 20:52:52 location 76139 Karlsruhe
setstate Frank_Huber 2018-03-26 20:52:51 longitude 8.4540
setstate Frank_Huber 2018-03-26 20:52:52 pressure 1004.9502
setstate Frank_Huber 2018-03-26 20:52:52 state active
setstate Frank_Huber 2018-03-26 20:52:52 temperature 8.41
Danke!,
gelöscht und neu angelegt. geht wieder.
seltsam. FHEM Neustart und PI Reboot haben nicht geholfen.
Zitat von: Frank_Huber am 26 März 2018, 17:47:31
bekomme seit heute ca 14:30 keine Daten mehr von Luftdaten.info.
Kann ich bestätigen, Problem besteht bei mir auch.
Zitat von: Pyromane am 26 März 2018, 22:56:20
Kann ich bestätigen, Problem besteht bei mir auch.
Leg es neu an.
Raw def kopieren. Ohne state.
Löschen
Neu anlegen.
Irgend etwas im statefile scheint zu klemmen,
Mit dem Handy online, daher kurz gefasst...
Interessant, bei mir hat ein modify def gereicht um es wieder zum Leben erwecken.
Danke für die Unterstützung.
Auch bei mir >:( Und das defmod hat ihn wiederbelebt ;D
Danke fürs Teilen.
Hallo Gemeinde,
ich habe mir den MH-Z19 CO2 Sensor mal gekauft und per MQTT an Fhem eingebunden.
Ich habe darüber auch gebloggt.
https://blog.moneybag.de/fhem-luftqualitaet-messen-mit-dem-mh-z14-mh-z19-co2-sensor-und-espeasy-wemos/
Liefert gute Werte und ist stabil. Als Software kommt ESPEasy zum Einsatz.
LG
/robin
Hi Robin,
magst Du dazu einen eigenen Thread machen ? Testerfahrung(Edit: Einfluss Temp.,Hygro), Vergleichsdaten zum Voltcraft(der übrigens kein C-Programm benötigt).
Seit 2 Tagen kriege ich wieder connect_Fehler. diesmal belebt defmod das device nicht mehr. Habt Ihr keine Probleme ?
Grüße Markus
Zitat von: KölnSolar am 01 April 2018, 16:27:37Seit 2 Tagen kriege ich wieder connect_Fehler. diesmal belebt defmod das device nicht mehr. Habt Ihr keine Probleme ?
Doch, aber da die Map auf Luftdaten.info auch keine Daten anzeigt gehe ich von einem Fehler auf deren Seite aus.
Zitat von: KölnSolar am 01 April 2018, 16:27:37
Hi Robin,
magst Du dazu einen eigenen Thread machen ? Testerfahrung(Edit: Einfluss Temp.,Hygro), Vergleichsdaten zum Voltcraft(der übrigens kein C-Programm benötigt).
Seit 2 Tagen kriege ich wieder connect_Fehler. diesmal belebt defmod das device nicht mehr. Habt Ihr keine Probleme ?
Grüße Markus
Hallo Markus,
muss ich mal schauen und einige Tage mal neben dem Voltcraft legen.
Und Du hast Recht, es gibt ein Plugin. Ich nutze jedoch von Anfang an das C-Programm.
Und was meinst Du mit Connect-Fehler? bei mir läuft die luftdaten.info normal.
LG
/robin
Du hast vermutlich local definiert. Das funktioniert. Fremde muss ich über remote definieren und da haperts wohl bei deren Server. :'(
Zitat von: KölnSolar am 01 April 2018, 16:27:37
Hi Robin,
magst Du dazu einen eigenen Thread machen ? Testerfahrung(Edit: Einfluss Temp.,Hygro)
Grüße Markus
Mir fällt gerade ein: Man kannn die Sensoren nicht einfach vergleichen, weil der MH z19 nur CO2 misst, der SDS011 Feinstaub, der Voltcraft VOC (also gemisch).
Ich habe mir gestern mal den BME680 bestellt, welche auch VOC misst. Der ist nagelneu und kommt von Bosch.
Der ist beim Ali Aliexpress http://s.click.aliexpress.com/e/MZNBmIm mittlerweile bezahlbar.
Ich später mal in meinem Blog alle Sensoren nochmal nebeneinander legen und beschreiben.
LG
/robin
Hallo
Seit dem 26.3. ca. 14:45 Uhr kommen von meinen beiden luftdaten.info Sensoren keine Daten mehr über die Webseite API
Wenn ich es über local und IP Adresse mache, funktioniert es.
2018.04.18 00:02:57 2: LuftdatenInfo (Luft01) - SDS011 position differs from other sensor position
2018.04.18 00:03:12 2: LuftdatenInfo (Luft01a) - DHT22 position differs from other sensor position
2018.04.18 00:03:16 2: LuftdatenInfo (Luft02) - error while request: no data returned
Interessant ist auch das wenn ich die Map von luftdaten.info im Firefox öffne mit eine andere SensorID angezeigt wird wie mit dem IE und Chrome.
Habe beide getestet, geht aber nicht.
Klingt für mich so, als wenn da ein Problem mit dem Server besteht. Da kann ich dir aber nicht bei helfen.
Hast du schon mal versucht die beiden Sensoren neu zu definieren?
So wie es ein paar posts weiter oben beschrieben ist.
Etwas lesen vor dem posten hätte geholfen. [emoji6]
Die posts ab hier:
https://forum.fhem.de/index.php?topic=66674.msg786908.msg#786908
Gesendet von meinem Doogee S60 mit Tapatalk
Sorry, habe die Suchfunktion genutzt und diese hat diesen Beitrag wohl nicht gefunden :-\
Kurze Frage: In FHEM oder bei Luftdaten.info neu angelegt?
Zum Thema Gehäuse:
Habe selbst auch ein Gehäuse entwickelt und verbessert.
https://www.thingiverse.com/thing:2340778 (https://www.thingiverse.com/thing:2340778)
Als Material nutze ich PETG was gut Wetterbeständig ist.
Zitat von: Edi77 am 19 April 2018, 11:53:42
Kurze Frage: In FHEM oder bei Luftdaten.info neu angelegt?
FHEM: Raw config öffnen, code kopieren, device löschen und über raw config wieder importieren.
Zitat von: Edi77 am 19 April 2018, 11:53:42Kurze Frage: In FHEM oder bei Luftdaten.info neu angelegt?
Bei mir hatten in FHEM ein modify def geholfen.
Hallo,
ich bekomme seit meinem Serverumzug bei dem Modul die Fehlermeldung
Undefined subroutine &main::IsDevice called at ./FHEM/59_LuftdatenInfo.pm line 429.
und Fhem schmiert komplett ab.
Was könnte der Grund dafür sein?
Grüße
Ronny
Zitat von: FHEMAN am 04 Mai 2018, 23:54:18
Hallo,
ich bekomme seit meinem Serverumzug bei dem Modul die Fehlermeldung
Undefined subroutine &main::IsDevice called at ./FHEM/59_LuftdatenInfo.pm line 429.
und Fhem schmiert komplett ab.
Was könnte der Grund dafür sein?
Irgendwas klingelt da bezüglich FHEM-Update, finde aber gerade nix dazu.
Du hast keine aktuelle fhem.pl(sub IsDevice) würd ich spekulieren.
Hmm.. meine fhem.pl ist aktuell
$Id: fhem.pl 16675 2018-04-29 22:15:41Z rudolfkoenig $
und es gibt eine Funktion isDevice. Ich kann mir keinen Reim drauf machen. Abhängigkeiten sollten alle installiert sein. Ich bin jetzt auf Debian 9 unterwegs. Aber daran kann es doch nicht liegen?
Oder irgendwas mit der Perl Version? Ich habe
(fhem.pl:16675/2018-04-29 perl:5.024001 os:linux user:fhem pid:10883)
Zitat von: FHEMAN am 05 Mai 2018, 12:32:21
Hmm.. meine fhem.pl ist aktuell
$Id: fhem.pl 16675 2018-04-29 22:15:41Z rudolfkoenig $
und es gibt eine Funktion isDevice. Ich kann mir keinen Reim drauf machen. Abhängigkeiten sollten alle installiert sein. Ich bin jetzt auf Debian 9 unterwegs. Aber daran kann es doch nicht liegen?
isDevice ist aber nicht
IsDevice. Und genau da klingelt es. Sicher das alles aktuell ist?
Edith:
In der 16675 steht auch
IsDevice, genau wie in der aktuellen Version von 59_LuftdatenInfo. FHEM mal neu gestart?
Hallo zusammen.
Ich habe heute endlich geschafft meinen ESP8266 zu flashen und die Hardware zusammen zu basteln.
Nach erfolgreichem konfigurieren und installieren draußen am Haus,
ist mir aufgefallen, das der Wert der Temperatur um fast 2°C abweicht.
Genauer gesagt ist der Wert um 2°C höher, als der meiner Wetterstation und dem lokalen Wetterdienst.
Kann mir jemand sagen, woran das liegen könnte!?
Kann das an dem von mir wohl zu klein gewählten USB-Steckernetzteil liegen, das dort die Spannung nicht aussreicht????
Gib uns doch mal details zum Aufbau.
Was für ein Temperaturfühler?
Wie installiert?
Gesendet von meinem S60 mit Tapatalk
Oh Sorry.
Mach ich..... :
Hardware:
- MODE MCU ESP 8266 12e
- SDS011
- DHT22
Software:
- latest_de.bin Datei von luftdaten.info
Alles mit kurzen Jumperkabeln verbunden/verdrahtet und zwei HT-Bögen verstaut,
so wie es auf der Seite LUFTDATEN erklärt ist.
Der Sensor steht auf der Fensterbank im 1.OG auf der OST-Seite des Hauses und bekommt nur morgens zwischen ca. 8:00 und 9:00 Sonne.
Habe grad mal ein Netzteil mit 2A angeschlossen, aber immer noch eine Temperaturdifferenz von mindestens 1°C im vergleich zu meiner Wetterstation, Google und Lokalradio.
Bin über jeden Tipp dankbar....
Ist der dht tief in der Rohre drin?
Wobei 1 Grad ist für einen dht aber eigentlich OK.
Die sind nicht sooo genau.
Ich hab meinen nach ner Weile gegen einen bmp280 (mit Luftdruck) ausgetauscht.
Gesendet von meinem Doogee S60 mit Tapatalk
Hey!
Mein Problem hat sich wohl doch nach dem Tausch des Netzteils erledigt....
Die Werte stimmen nun....
Nun warte ich mal, wann mein Sensor in die Karte übernommen wird....
Danke trotzdem und schöne Pfingsten ! ! !
Noch jemand gerade Probleme Daten abzurufen?
Seit gestern Nacht kurz nach 1 ist bei mir Funkstille.
dito
Hallo Zusammen,
ich habe einen Luftdaten Sensor mit DHT22 sowie BME280 (local). Dadurch werden zwei Temperaturmessungen durchgeführt, die aufgrund der Sensorpositionen von einander abweichen.
Das aktuelle Modul liest pro Zyklus immer den Wert des DHT22 und des BME280 aus und schreibt diese auf das gleiche Reading "temperature". Dies führt dazu, dass die beiden Sensoren im Log nicht mehr aus einander gehalten werden können:
2018-07-06_17:14:26 Luftdaten PM10: 6.13
2018-07-06_17:14:26 Luftdaten PM2.5: 5.37
2018-07-06_17:14:26 Luftdaten temperature: 31.20
2018-07-06_17:14:26 Luftdaten humidity: 37.40
2018-07-06_17:14:26 Luftdaten pressure: 1002.66
2018-07-06_17:14:26 Luftdaten temperature: 32.09
2018-07-06_17:14:26 Luftdaten signal: -70
2018-07-06_17:14:26 Luftdaten active
2018-07-06_17:14:54 Luftdaten PM10: 6.13
2018-07-06_17:14:54 Luftdaten PM2.5: 5.37
2018-07-06_17:14:54 Luftdaten temperature: 31.20
2018-07-06_17:14:54 Luftdaten humidity: 37.40
2018-07-06_17:14:54 Luftdaten pressure: 1002.66
2018-07-06_17:14:54 Luftdaten temperature: 32.09
2018-07-06_17:14:54 Luftdaten signal: -70
2018-07-06_17:14:54 Luftdaten active
2018-07-06_17:15:24 Luftdaten PM10: 6.13
2018-07-06_17:15:24 Luftdaten PM2.5: 5.37
2018-07-06_17:15:24 Luftdaten temperature: 31.20
2018-07-06_17:15:24 Luftdaten humidity: 37.40
2018-07-06_17:15:24 Luftdaten pressure: 1002.66
2018-07-06_17:15:24 Luftdaten temperature: 32.09
2018-07-06_17:15:24 Luftdaten signal: -70
Entsprechend hässlich wird der SVG Plot (siehe Bild).
Folgender Patch schafft Abhilfe:
--- 59_LuftdatenInfo.pm.org 2018-07-06 19:40:56.532048756 +0200
+++ 59_LuftdatenInfo.pm 2018-07-06 20:27:28.844652588 +0200
@@ -478,10 +478,13 @@
elsif($_->{value_type} eq "signal"){
$_->{value_type} = "signal";
}
- elsif($_->{value_type} =~ /temperature$/){
+ elsif($_->{value_type} eq "temperature"){
$_->{value_type} = "temperature";
}
- elsif($_->{value_type} =~ /_watt/){
+ elsif($_->{value_type} eq "BMP_temperature"){
+ $_->{value_type} = "BMP_temperature";
+ }
+ elsif($_->{value_type} =~ /_watt/){
$_->{value_type} = "UVIntensity";
}
elsif($_->{value_type} =~ /_time$/){
Ich würde mich sehr freuen, wenn er im nächsten Release aufgenommen werden könnte.
Schöne Grüße und vielen Dank
Rene
Zitat von: svlsbrg am 06 Juli 2018, 20:47:51
ich habe einen Luftdaten Sensor mit DHT22 sowie BME280 (local). Dadurch werden zwei Temperaturmessungen durchgeführt, die aufgrund der Sensorpositionen von einander abweichen.
Dafür ist der Mode slave da
define <name> LuftdatenInfo slave <master-name> <sensor1 sensor2 ...>
Was du bei sensor eintragen musst erhältst du mit "get sensors"
Hallo,
scheinbar müsste man dann 2 Devices anlegen, oder? Ich finde diese Variante nicht sehr intuitiv.
Was spricht gegen die Lösung, die anderen Sensoren sauber als eigene readings anzulegen?
Schöne Grüße und vielen Dank
Rene
Zitat von: svlsbrg am 07 Juli 2018, 12:30:32
scheinbar müsste man dann 2 Devices anlegen, oder? Ich finde diese Variante nicht sehr intuitiv.
Was spricht gegen die Lösung, die anderen Sensoren sauber als eigene readings anzulegen?
Es gibt dann für jeden physikalischen Messpunkt ein Device mit einem temperature, etc. reading.
Wenn man alles in ein device packen würde müsste ich mir als Modulautor Sinnvolle Readings ausdenken und die user können nicht einfach auf temperature abfragen.
Zitat2018.07.12 03:04:31 2: LuftdatenInfo (Luftdaten_remote) - error while request: api.luftdaten.info: Verbindungsaufbau abgelehnt
bekommt das noch jemand?
Bei mir werden die Daten meines eigenen Sensors lokal abgegriffen und gelogt, von daher stören die Ausfälle bei luftdaten.info nicht. Ich zeige mir zu Referenzzwecken auch noch Daten eines Sensors aus der Nachbarchaft an. Hier erfolgt der Zugriff dann über api.luftdaten.info, von dort kommen immer wieder Logeinträge "Verbindung abgelehnt", z.B. fast die ganze letzte Nacht. Die Server sind anscheinend nicht immer online.
Ja, ging dann auch wieder.
Verbindung abgelehnt war imho noch nie. "normale" Störungen zeigen nur "Server offline"
ABer alles wieder OK. ;-)
Zitat von: svlsbrg am 07 Juli 2018, 12:30:32
scheinbar müsste man dann 2 Devices anlegen, oder? Ich finde diese Variante nicht sehr intuitiv.
Was spricht gegen die Lösung, die anderen Sensoren sauber als eigene readings anzulegen?
Es gibt noch eine Variante, die allerdings nicht dokumenter ist (muss ich noch nachholen). Setz das Attribut rawReading auf 1.
Zitat von: reibuehl am 02 April 2017, 19:16:25
Das State Attribut könnte meiner Meinung nach etwas "informativer" gestaltet werden. Ich hab es bei mir mal über das Attribut stateFormat abgeändert:
state = {sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("Feinstaub","PM10",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("Feinstaub","PM2.5",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("Feinstaub","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("Feinstaub","humidity",0))}
Damit sieht der State des Device dann so aus:
PM10: 17.0 µg/m³ / PM2.5: 15.3 µg/m³ / Temp: 16.5 °C / Hum: 57.6 %
Irgendwie bekomme ich es nicht hin das im State meine Temp und Hum gezeight wird. Meins sieht so aus:
STATE PM10: 20.5 µg/m³ / PM2.5: 11.2 µg/m³ / Temp: 0.0 °C / Hum: 0.0 %
Mein stateFormat sieht so aus:
{sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("SDS011","pm100",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("SDS011","pm25",0)
Zitat von: zgadgeter am 04 August 2018, 17:42:22
Mein stateFormat sieht so aus:
Das ist anscheinend nicht vollständig.
Hi Igami,
ich habe meinen Sensor local angebunden, ich bekomme nun sehr oft (<90%der Fälle der Abfragen) ein error, log zeigt:
2018.08.04 20:46:27 2: LuftdatenInfo (luftdatensensor1) - error while request: read from http://x.x.x.x:80 timed out
2018.08.04 21:06:05 2: LuftdatenInfo (luftdatensensor1) - error while request: http://x.x.x.x/data.json: empty answer received
Allerdings kann ich per SSH Shell und wget problemlos im 20sekunden takt die json Daten abrufen, es gibt nie ein timeout oder eine leere Antwort, hast Du eine Idee, was die Ursache hier sein könnte ?
Ich hatte die Definitionen alle entfernt und neu eingegeben, hat aber nichts gebracht.
Danke Ronny
Internals:
ADDRESS x.x.x.x
CFGFN
DEF local x.x.x.x
INTERVAL 300
MODE local
NAME luftdatensensor1
NR 164
STATE PM10: 0.00 µg/m³ / PM2.5: 0.00 µg/m³ / Temp: 0.00 °C / Hum: 0.00 %
TIMEOUT 5
TYPE LuftdatenInfo
READINGS:
2018-08-04 21:05:04 PM10 12.03
2018-08-04 21:05:04 PM2.5 11.23
2018-08-04 21:05:04 humidity 37.10
2018-08-04 21:05:04 signal -81
2018-08-04 16:32:46 softwareVersion NRZ-2018-103
2018-08-04 21:07:05 state error
2018-08-04 21:05:04 temperature 32.50
Attributes:
disable 0
room diverses2
stateFormat {sprintf("PM10: %.2f µg/m³ / ",ReadingsVal("Feinstaub","PM10",0)).sprintf("PM2.5: %.2f µg/m³ / ",ReadingsVal("Feinstaub","PM2.5",0)).sprintf("Temp: %.2f °C / ",ReadingsVal("Feinstaub","temperature",0)).sprintf("Hum: %.2f %%", ReadingsVal("Feinstaub","humidity",0))}
Verbose 5 sagt nur:
2018.08.04 21:17:07 5: LuftdatenInfo (luftdatensensor1) - entering LuftdatenInfo_statusRequest
2018.08.04 21:17:07 5: LuftdatenInfo (luftdatensensor1) - entering LuftdatenInfo_GetHttpResponse
2018.08.04 21:17:09 5: LuftdatenInfo (luftdatensensor1) - entering LuftdatenInfo_ParseHttpResponse
2018.08.04 21:17:09 2: LuftdatenInfo (luftdatensensor1) - error while request: http://x.x.x.x/data.json: empty answer received
Zitat von: rcmcronny am 04 August 2018, 21:16:15
hast Du eine Idee, was die Ursache hier sein könnte ?
Leider nein. Du könntest ja mal ein Presence auf den Feinstaubsensor definieren und schauen ob er da auch mal weg ist.
Schade,
PRESENCE ist definiert, das ist und bleibt aber bei present
Ich hab es nun mal auf den lokalen Intranet server umgebogen und der holt die Datei vom Sensor, mal gucken, wie sich das so verhält.
Sie bisher aber 1a aus, keine Fehler.
Könnte man bei verb 5 nicht noch das http get zeugs mit ausgeben, vielleicht sieht man da mehr infos ?
Ronny
Zitat von: igami am 04 August 2018, 20:14:44
Das ist anscheinend nicht vollständig.
Ja, stimmt, sorry, hier nochmal:
{sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("SDS011","pm100",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("SDS011","pm25",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("SDS011","humidity",0))}Ich komme selbst nicht auf den fehler, bin aber nicht erfahren hier.
Zitat von: rcmcronny am 04 August 2018, 21:16:15
Hi Igami,
ich habe meinen Sensor local angebunden, ich bekomme nun sehr oft (<90%der Fälle der Abfragen) ein error, log zeigt:
2018.08.04 20:46:27 2: LuftdatenInfo (luftdatensensor1) - error while request: read from http://x.x.x.x:80 timed out
2018.08.04 21:06:05 2: LuftdatenInfo (luftdatensensor1) - error while request: http://x.x.x.x/data.json: empty answer received
Ich glaube zwar nicht, daß es daran liegt, aber setze mal den Timeout auf 10. Standard ist 5 Sekunden.
Ich vermute eher ein WLAN-Problem
Zitat von: Gernott am 05 August 2018, 12:57:07
Ich glaube zwar nicht, daß es daran liegt, aber setze mal den Timeout auf 10. Standard ist 5 Sekunden.
Ich vermute eher ein WLAN-Problem
Wenn das ein "häufigeres" Problem ist werde ich den Standard auf 10 Sekunden anheben.
Zitat von: zgadgeter am 05 August 2018, 09:58:24
Ich komme selbst nicht auf den fehler, bin aber nicht erfahren hier.
Sieht für mich soweit ganz gut aus, nur dass das device SDS011 keine temperature und humidity Readings hat. Poste doch mal bitte ein list von dem device.
Zitat von: igami am 05 August 2018, 17:02:00Poste doch mal bitte ein list von dem device.
Hallo, anbei ein list von dem device:
Internals:
BUSY 0
DEF http://192.168.178.46/data.json 60
Interval 60
LASTSEND 1533481602.77883
MainURL http://192.168.178.46/data.json
ModuleVersion 3.5.1 - 5.7.2018
NAME SDS011
NR 222
STATE PM10: 20.5 µg/m³ / PM2.5: 11.2 µg/m³ / Temp: 0.0 °C / Hum: 0.0 %
TRIGGERTIME 1533481662.77707
TRIGGERTIME_FMT 2018-08-05 17:07:42
TYPE HTTPMOD
addr http://192.168.178.46:80
auth 0
buf
code 404
compress 1
conn
data
displayurl http://192.168.178.46/data.json
header Content-Type: application/json
host 192.168.178.46
httpheader HTTP/1.0 404 Not Found
Content-Type: text/html
Content-Length: 345
Connection: close
Date: Sat, 18 Oct 2014 04:13:14 GMT
Server: lighttpd/1.4.32
httpversion 1.0
hu_blocking 0
hu_filecount 148
hu_port 80
hu_portSfx
ignoreredirects 0
loglevel 4
path /data.json
protocol http
redirects 0
timeout 2
url http://192.168.178.46/data.json
value 0
QUEUE:
READINGS:
2017-12-19 15:38:29 pm100 20.47
2017-12-19 15:38:29 pm25 11.17
2018-08-05 17:06:42 relpressure 25.7
2017-12-19 15:38:29 software_version NRZ-2017-099
REQUEST:
data
header Content-Type: application/json
ignoreredirects 0
retryCount 0
type update
url http://192.168.178.46/data.json
value 0
sslargs:
Attributes:
reading01Name temperature
reading01Regex "temperature","value":"(0|\d*\.\d+)"}.*
reading02Name humidity
reading02Regex "humidity","value":"(0|\d*\.\d+)"}.*
reading03Name BMP_temperature
reading03Regex "BMP_temperature","value":"(0|\d*\.\d+)"}.*
reading04Name BMP_abs_pressure
reading04Regex "BMP_pressure","value":"(0|\d*+)"}.*
reading05Name software_version
reading05Regex "software_version": "(.*?)".*
reading06Name pm100
reading06Regex "SDS_P1","value":"(0|\d*\.\d+)"}.*
reading07Name pm25
reading07Regex "SDS_P2","value":"(0|\d*\.\d+)"}.*
requestHeader Content-Type: application/json
room LivingRoom,Wetter
stateFormat {sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("SDS011","pm100",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("SDS011","pm25",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("SDS011","humidity",0))}
userReadings relpressure { ReadingsVal("SDS011","BMP_abs_pressure",0)/100+25.7; }
userattr reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex reading04Name reading04Regex reading05Name reading05Regex reading06Name reading06Regex reading07Name reading07Regex requestHeader stateFormat
verbose 1
Zitat von: zgadgeter am 05 August 2018, 17:09:25
Hallo, anbei ein list von dem device:
Wenn du weiterhin HTTPMOD verwenden willst, beschreibe dein Problem in dem entsprechenden Forumsbereich. Ansonsten stell doch einfach auf das Modul LuftdatenInfo um ;)
define SDS011 LuftdatenInfo local 192.168.178.46
State Format kannst du dann so übernehmen.
Ansonsten ist es wie vermutet: dein Device hat keine temperature und humidity readings.
Zitat von: igami am 05 August 2018, 17:24:43
Wenn du weiterhin HTTPMOD verwenden willst, beschreibe dein Problem in dem entsprechenden Forumsbereich. Ansonsten stell doch einfach auf das Modul LuftdatenInfo um ;)
define SDS011 LuftdatenInfo local 192.168.178.46
State Format kannst du dann so übernehmen.
Ansonsten ist es wie vermutet: dein Device hat keine temperature und humidity readings.
Hi, und danke, ich probiere das mit dem Umstellen gleich. Aber anbei ist ein Screenshot von dem Device. Das ist Temp/Hum drauf...??
Zitat von: zgadgeter am 05 August 2018, 17:27:06
Das ist Temp/Hum drauf...??
Ja, da hast du einen Temp/Hum Sensor, der wird vom LuftdatenInfo Moudul automatisch erkannt.
Zitat von: igami am 05 August 2018, 17:24:43
Ansonsten stell doch einfach auf das Modul LuftdatenInfo um ;)
Ok, habe umgestellt, und hier ein list von dem device jetzt. Da ist Temp/Hum drin
ADDRESS 192.168.178.28
CFGFN
DEF local 192.168.178.28
INTERVAL 30
MODE local
NAME Feinstaubsensor
NR 2227
STATE PM10: 8.1 µg/m³ / PM2.5: 1.7 µg/m³ / Temp: 0.0 °C / Hum: 0.0 %
TIMEOUT 5
TYPE LuftdatenInfo
READINGS:
2018-08-05 17:32:31 PM10 8.10
2018-08-05 17:32:31 PM2.5 1.67
2018-08-05 17:32:31 humidity 37.39
2018-08-05 17:32:31 pressure 994.4911
2018-08-05 17:32:31 signal -71
2018-08-05 17:28:30 softwareVersion NRZ-2018-103
2018-08-05 17:32:31 state active
2018-08-05 17:32:31 temperature 30.53
Attributes:
stateFormat {sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("SDS011","pm100",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("SDS011","pm25",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("SDS011","humidity",0))}Nur hier nicht:
Feinstaubsensor
PM10: 8.1 µg/m³ / PM2.5: 1.7 µg/m³ / Temp: 0.0 °C / Hum: 0.0 %
Zitat von: zgadgeter am 05 August 2018, 17:33:24
Ok, habe umgestellt, und hier ein list von dem device jetzt. Da ist Temp/Hum drin
ADDRESS 192.168.178.28
CFGFN
DEF local 192.168.178.28
INTERVAL 30
MODE local
NAME Feinstaubsensor
NR 2227
STATE PM10: 8.1 µg/m³ / PM2.5: 1.7 µg/m³ / Temp: 0.0 °C / Hum: 0.0 %
TIMEOUT 5
TYPE LuftdatenInfo
READINGS:
2018-08-05 17:32:31 PM10 8.10
2018-08-05 17:32:31 PM2.5 1.67
2018-08-05 17:32:31 humidity 37.39
2018-08-05 17:32:31 pressure 994.4911
2018-08-05 17:32:31 signal -71
2018-08-05 17:28:30 softwareVersion NRZ-2018-103
2018-08-05 17:32:31 state active
2018-08-05 17:32:31 temperature 30.53
Attributes:
stateFormat {sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("SDS011","pm100",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("SDS011","pm25",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("SDS011","humidity",0))}
Nur hier nicht:
Feinstaubsensor
PM10: 8.1 µg/m³ / PM2.5: 1.7 µg/m³ / Temp: 0.0 °C / Hum: 0.0 %
Du musst das Attribut auch schon anpassen, wenn du nicht den selben Namen verwendest...
Besser noch du benutzt $name anstelle des Namens. Weiterhin müssen die Abfragen für PM10 und PM2.5 auch auf die Namen der Readings angepasst werden.
Zitat von: igami am 05 August 2018, 17:45:24
Du musst das Attribut auch schon anpassen, wenn du nicht den selben Namen verwendest...
Hi, ich habe es in der Zwischenzeit schon selbst gemerkt...wieder mal ein Bloeder Fehler. Funktioniert jetzt. Danke, Du hast mir wirklich geholfen...muss mich jetzt nochmals schlau machen wie ich die werte in ein Filelog bekomme so das ich eine Grafik bekomme...Danke!
Hoi,
Timeout auf 10s zu erhöhen bringt leider nix, mit meinen Server dazwischen läuft es 1a .. und der hat keine Probleme beim Abruf.
Das ist schon irgendwie sonderbar.
Naja bleibts erstmal so nun :D
Vielleicht findet sich hier ja noch eine Debug Möglichkeit, was wirklich da los ist.
Ronny
Zitat von: rcmcronny am 05 August 2018, 18:24:10
Vielleicht findet sich hier ja noch eine Debug Möglichkeit, was wirklich da los ist.
Verbose für das Device mal auf 5 setzen und sich das Log ansehen?
Hi Gernott,
hatte ich bereits, siehe im vorherigen Post mit allen Infos, viel steht da leider nicht da bei verb 5 ;)
Ronny
Zitat von: rcmcronny am 05 August 2018, 22:47:35
... viel steht da leider nicht da bei verb 5 ;)
Ah ja, mein Fehler, hatte nicht soweit zurückgelesen. Bei mir läuft dasselbe Setup ohne Probleme.
Eventuell kannst Du Dir in das Modul noch einige weitere Log-Ausgaben einbauen, um zu sehen, was genau bei der http-Abfrage zurückgegeben wird? Ach, sehe gerade, daß die Sensorabfrage vom Modul an HttpUtils_NonblockingGet weitergegeben wird. Vielleicht klemmt da was?
Gruß
G.
Jo, ich denke auch , das ich mit paar Logausgaben nur weiterkomme und denke auch das es am HttpUtils irgendwie liegen wird, mal schauen, wenn ich Lust habe, das genauer zu beleuchten ;)
Danke ;)
Ronny
Hoi,
so nun hab ich DEBUG Ausgaben eingebaut und nun geht natürlich wieder alles problemlos ... das ist schon suspekt. Ich lasse es mal weiterlaufen und hoffe mal, das es irgendwann nochmal triggert und ich mehr Infos habe ;)
Ronny
Zitat von: rcmcronny am 09 August 2018, 12:57:35
Hoi,
so nun hab ich DEBUG Ausgaben eingebaut und nun geht natürlich wieder alles problemlos ... das ist schon suspekt. Ich lasse es mal weiterlaufen und hoffe mal, das es irgendwann nochmal triggert und ich mehr Infos habe ;)
Ronny
Was für Ausgaben hast du denn noch eingebaut? Ich könnte das ja ins ofizielle Modul übernehmen.
Hi igami,
das waren nur par log3 meldungen wenn verbose 5 aktiv ist, aber da da nix bei rauskam bisher, das war mehr ein rumgepoke als anständig, wenn ich das irgendwie / wann mal nachstellen kann und da sinnvoll was ergänz werden kann, geb ich dir bescheid ;)
Ronny
Hallo igami, hallo Fhemianer,
ich gehöre auch zur Gemeinde der Feinstaubmesser. Und dachte,alles wäre so easy.
Nun muß ich hier reinplatzen...
Habe einen SDS011 nebst dem tty/USB Stecker bekommen und in den Raspi gesteckt.
Der Sensor funktioniert, da ich hier im Linux ( Ubuntu Mate 16.4) den Test über ein Python Script gemacht habe und der Werte liefert(AQI.py).
(Genauso dies über den dazugelieferten DHT22, der leider nur die Temperatur rausgibt( immer 1.0% HUM, nur deswegen wurde er aber gekauft, aber das am Rande))
Ich wollte nur lokale Auswertung, deswegen mit
define SDS011 LuftdatenInfo local 192.168.2.110
definiert
Es kommt sofort ein Error im State. Ich hoffe, man mußte nicht dennoch irgendeine FW runterladen, aber warum? Update ist gemacht
Es sollte ja wenigstens der Sensor errechbar sein über Button GET SDS011 Sensors nachvollziehbar, da steht dann aber : No Sensors found...hmmmmm.
Ach ja, vllt. interessant, im Monitor kommt ständig folgende Meldunge (en):
2018.08.21 19:00:31 5 : LuftdatenInfo (SDS011) - entering LuftdatenInfo_statusRequest
2018.08.21 19:00:31 5 : LuftdatenInfo (SDS011) - entering LuftdatenInfo_GetHttpResponse
2018.08.21 19:00:31 5 : LuftdatenInfo (SDS011) - entering LuftdatenInfo_ParseHttpResponse
2018.08.21 19:00:31 4 : LuftdatenInfo (SDS011) - returned data: <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>404 - Not Found</title> </head> <body> <h1>404 - Not Found</h1> </body> </html>
2018.08.21 19:00:31 2 : LuftdatenInfo (SDS011) - error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<?xml version="1.0" ...") at ./FHEM/59_LuftdatenInfo.pm line 314.
2018-08-21 19:00:31 LuftdatenInfo SDS011 error
Ich hatte mir zwar euren Thread ( schnell ) durchgelesen, aber keine konkreten Hinweis gefunden, Zwischenschritte zu unternehmen.Den JSON String brauche ich ja nur bei remote.
Oder doch?
Danke im Voraus..
Uwe
Das Modul basiert auf der original oder alternativen Firmware.
Den sds am RasPi wirst nicht auslesen können.
Besorg dir noch nen wemos oder nodemcu und nimm die Alternative Firmware.
Den Dht22 schmeisse weg, besorg dir lieber nen bmp280.
Zitat von: Uwe_Eta20 am 21 August 2018, 19:30:57
Hallo igami, hallo Fhemianer,
ich gehöre auch zur Gemeinde der Feinstaubmesser. Und dachte,alles wäre so easy.
Nun muß ich hier reinplatzen...
Habe einen SDS011 nebst dem tty/USB Stecker bekommen und in den Raspi gesteckt.
Der Sensor funktioniert, da ich hier im Linux ( Ubuntu Mate 16.4) den Test über ein Python Script gemacht habe und der Werte liefert(AQI.py).
(Genauso dies über den dazugelieferten DHT22, der leider nur die Temperatur rausgibt( immer 1.0% HUM, nur deswegen wurde er aber gekauft, aber das am Rande))
Ich wollte nur lokale Auswertung, deswegen mit
define SDS011 LuftdatenInfo local 192.168.2.110
definiert
Es kommt sofort ein Error im State. Ich hoffe, man mußte nicht dennoch irgendeine FW runterladen, aber warum? Update ist gemacht
Es sollte ja wenigstens der Sensor errechbar sein über Button GET SDS011 Sensors nachvollziehbar, da steht dann aber : No Sensors found...hmmmmm.
Ach ja, vllt. interessant, im Monitor kommt ständig folgende Meldunge (en):
2018.08.21 19:00:31 5 : LuftdatenInfo (SDS011) - entering LuftdatenInfo_statusRequest
2018.08.21 19:00:31 5 : LuftdatenInfo (SDS011) - entering LuftdatenInfo_GetHttpResponse
2018.08.21 19:00:31 5 : LuftdatenInfo (SDS011) - entering LuftdatenInfo_ParseHttpResponse
2018.08.21 19:00:31 4 : LuftdatenInfo (SDS011) - returned data: <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>404 - Not Found</title> </head> <body> <h1>404 - Not Found</h1> </body> </html>
2018.08.21 19:00:31 2 : LuftdatenInfo (SDS011) - error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<?xml version="1.0" ...") at ./FHEM/59_LuftdatenInfo.pm line 314.
2018-08-21 19:00:31 LuftdatenInfo SDS011 error
Ich hatte mir zwar euren Thread ( schnell ) durchgelesen, aber keine konkreten Hinweis gefunden, Zwischenschritte zu unternehmen.Den JSON String brauche ich ja nur bei remote.
Oder doch?
Danke im Voraus..
Uwe
Gesendet von meinem Doogee S60 mit Tapatalk
ich dachte, hier meisten hätten einen Raspi im Einsatz dafür..würde mich natürlich interessieren warum nicht, und ob das da keinen Ausweg gibt.
Gruss
Uwe
Der RasPi ist total oversized dafür. Viele haben den als fhem Server, aber nicht für die Luftdaten.
Gesendet von meinem Doogee S60 mit Tapatalk
Hallo zusammen,
jetzt weiß ich auch, warum mein Feinstaubsensor seit einer Weile nur noch hohe Werte anzeigt (siehe Bild). Hat jemand eine Idee, womit man die Öffnung für Kleintiere so verschließen kann, dass die Feinstaubmessung noch korrekt ist? Ich will ja nicht alle halb Jahre mal aufs Dach und das Rohr putzen :o
Danke + Gruß
PeMue
Das kommt mir sowas von bekannt vor. [emoji23][emoji23][emoji23]
Ich habe das "Problem" mit einem Fliegennetz über den HT Bögen gelöst.
Seit da keine Probleme mehr.
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 23 September 2018, 21:32:46
Ich habe das "Problem" mit einem Fliegennetz über den HT Bögen gelöst.
Dagegen hat vermutlich der Radarsensor (den ich da auch einbauen will) was. Aber die "kleine" Version (Fliegennetz über dem Schlauch) könnte ich mal probieren.
Danke für den Tipp.
Gruß Peter
Ich Kuck mal ob ich noch von dem Netz was da hab, dann schick ich dir was rüber.
Hier noch meine Lösung als Bild:
Gesendet von meinem Doogee S60 mit Tapatalk
Hab die Rest Stücke vom Netz wohl schon entsorgt.
Hab leider nix mehr da, sorry Peter...
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 24 September 2018, 21:35:42
Hab leider nix mehr da, sorry Peter...
Kein Problem, da müsste ich ggf. noch was da haben von einem selbst geschnittenen Fliegengitter.
Gruß Peter
So, es ist doch immer spannend, wenn man mal den Keller aufräumt. Da habe ich noch ein Gitter einer Lichtschachtabdeckung gefunden, das ich einfach über den Schlauch gezogen habe. Bin mal gespannt, wie lang das hält ;)
Gruß PeMue
Hallo,
ich möchte noch einmal das Thema mit dem "empty answer received" aufgreifen. Eine Lösung habe ich leider nicht nachlesen können.
Bei stellt sich es so dar.
Wenn das Modul die Daten mit dem eingestellten Intervall vom Sensor abholt funktioniert es ohne Probleme. Wenn ich dagegen ein at definiere indem ich sage
set <SensorDevice> stausRequest
bekomme ich immer einen "empty answer received" Fehler in das Logbuch geschrieben und die Daten bis auf state werden nicht mehr aktualisiert. state ist dann error.
Frage ich den Sensor via Browser ab /data.json bekomme ich immer ein json zurück.
Hintergrund ist, das ich via "at" alle Sensoren Zeitnah und in einem bestimmten Turnus abfragen möchte.
Internals:
ADDRESS 192.168.3.200
DEF local 192.168.3.200
INTERVAL 3600
MODE local
NAME LuftInfo
NR 313
STATE T: 1.85 H: 83.15 P: 1004.0152
TIMEOUT 20
TYPE LuftdatenInfo
Helper:
DBLOG:
PM10:
DbLog:
TIME 1545206847.30652
VALUE 26.57
PM2.5:
DbLog:
TIME 1545206847.30652
VALUE 22.10
humidity:
DbLog:
TIME 1545206847.30652
VALUE 83.15
pressure:
DbLog:
TIME 1545206847.30652
VALUE 1004.0152
temperature:
DbLog:
TIME 1545206847.30652
VALUE 1.85
READINGS:
2018-12-19 09:07:27 PM10 26.57
2018-12-19 09:07:27 PM2.5 22.10
2018-12-19 09:07:27 humidity 83.15
2018-12-19 09:07:27 pressure 1004.0152
2018-12-19 09:07:27 signal -82
2018-12-16 13:53:19 softwareVersion NRZ-2018-121C
2018-12-19 12:00:01 state error
2018-12-19 09:07:27 temperature 1.85
Attributes:
DbLogInclude PM10,PM2.5,humidity,pressure,temperature
interval 3600
room 3.7_Umwelt
stateFormat T: temperature H: humidity P: pressure
timeout 20
Hallo zusammen,
und da sag einer, dass die Feinstaubbelastung in den Ballungszentren nur durch Dieselfahrzeuge verursacht wird :o.
Auf jeden fall bringt mein Sensor wieder plausible Werte.
Wünsche allen ein gutes und vor allem gesundes Neues Jahr.
Gruß Peter
Deswegen ja auch die Diskussion, mancherorts sowas einzuschränken.
Stellenweise kommt man sich vor, wie in einer Nebelwand.
Und das ist garantiert weniger kondensierte Feuchtigkeit, als richtig fette Abbrandrückstände.
Hier in Karlsruhe noch gravierender.
Hab die Tage gehört/gelesen dass die Silvester-Nacht die gleiche Menge Staub freisetzt wie 15% alle Fahrzeuge über das ganze Jahr.
Ob was dran ist kann ich nicht sagen, so hohe Werte gab es aber das Jahr über nie.
Allerdings schaffen die adventskranzkerzen ähnlich hohe Werte.
Horst
Hallo zusammen,
ich habe jetzt meinen Feinstaubsensor ausgebaut, weil er dauernd in den Anschlag gegangen ist.
Nichts gefunden (Ansaugschlauch war ok, das Drahtgitter davor auch).
Im Zimmer betrieben: ok
Auf der Terasse betrieben: ok
Auf dem Dach betrieben: ok, bis heute (siehe Bild) >:(
Hat jemand eine Idee, was da schief läuft?
Mit verzweifelten Grüßen.
Peter
Ein Nachbar hat den Holzkamin in Betrieb gesetzt ? :-\
Ich hatte auch mal "Fehlanzeigen" bei Nebel bzw. sehr hoher Luftfeuchtigkeit.
Grüße Markus
Hallo Markus,
Zitat von: KölnSolar am 04 Januar 2019, 22:00:39
Ein Nachbar hat den Holzkamin in Betrieb gesetzt ? :-\
bei uns schneit/regnet es aber ;D.
Zitat von: KölnSolar am 04 Januar 2019, 22:00:39
Ich hatte auch mal "Fehlanzeigen" bei Nebel bzw. sehr hoher Luftfeuchtigkeit.
Einfach warten bis die Feuchtigkeit wieder sinkt? Oder ich montiere einfach mal das neue Sensormodul, allerdings nicht heute - auf dem Dach bei Schneeregen ist vermutlich keine gute Idee.
Gruß Peter
Hi Peter,
Zitatauf dem Dach bei Schneeregen ist vermutlich keine gute Idee
Das glaube ich auch. Ich hab da den Vorteil, dass ich meinen Sensor im Innenbereich nutze. kein Nebel, trocken, warm und mit sicherem Stand zu inspizieren. ;D
Für den Aussenbereich "stehle" ich mir einfach einen fremden Sensor aus der Nähe. Gibt ja genug. ;) Der ist bei dem hiesigen trüben Wetter übrigens seit gestern auch deutlich über den Grenzwerten(und seit heute Morgen mal wieder ausgefallen oder ist es mal wieder das Portal :-\)
Grüße Markus
Nachtrag: Beitrag unsinnig; technischer Defekt des Geräts.
Hallo allerseits, hallo @igami
als stolzer Betreiber so eines schönen Feinstaub-Dingens fiel mir folgendes Problem auf (bzw. wurde ich wegen Nichtaktualisierung FHEM/Label mit der Nase drauf gestupst, Beiträge ab #7: https://forum.fhem.de/index.php?topic=96905.new;topicseen#new):
Ich "überwache" drei Feinstaub-Dingser. Zwei fand ich in meiner Nähe, also remote. Und dann der eigene: Der ist wie im Wiki beschrieben lokal. Das sieht so aus:
define LuftZ LuftdatenInfo remote 15976
attr LuftZ event-on-change-reading PM2.5,PM10
attr LuftZ event-on-update-reading PM2.5,PM10
define LuftMochau LuftdatenInfo local 192.168.1.201
attr LuftMochau event-on-change-reading PM2.5,PM10
attr LuftMochau event-on-update-reading PM2.5,PM10
Ich habe mir das mal im Event-Monitor angesehen: Für die fremden Remote-Dingser werden alle 5 Minuten Events ausgelöst. Aber für meinen lokal angebunden Feinstaub-Dingser gibt es das nicht, nie.
Woran liegt das denn? Bin ich mal wieder zu doof? Oder macht das das LuftdatenInfo-Modul gar nicht? Wäre es in diesem Fall nicht schön, wenn es das machen könnte?
Hallo curt,
dazu gleich ein paar Fragen:
Ist die IP korrekt?
Sind in dem local Feinstaubsensor denn Readings vorhanden?
Was passiert nach einem "set statusRequest"?
Hast du schon einmal ins Logfile geschaut?
Bei meinem eigenen Feinstaubsensor (ebenfalls local) sehe ich Events.
Grüße
igami
Zitat von: igami am 13 Februar 2019, 05:54:51
dazu gleich ein paar Fragen:
Bitte aktuell standby.
Es ist wie immer, es geht schief.
Es gibt parallel https://forum.fhem.de/index.php/topic,96905.0.html - bitte mal meinen letzten Beitrag überfliegen.
Den hier angesprochenen Punkt kann ich leider nicht konkretisieren - bzg ist sogar falsch: Mein Sensor liefert aktuell KEINE Daten. Er reagiert auf Port 80, aber auch da keine Daten. Ich kann daher nicht liefern.
Ich habe parallel den Robin angepingt, von ihm habe ich mein FeinstaubDingens. Er hat auch schon reagiert.
Es macht aber keinen Sinn, dass ich ohne aktuell vorliegende Messwerte irgendwelche Thesen aufstelle. Daher: Bitte standby.
Danke.
Au weia. Es lag tatsächlich daran, dass der Sensor keine Daten mehr lieferte, obwohl er via Wlan erreichbar war.
Man beachte #481 als nicht geschrieben. Ich bitte um Entschuldigung.
Zitat von: curt am 14 Februar 2019, 18:58:40
Au weia. Es lag tatsächlich daran, dass der Sensor keine Daten mehr lieferte, obwohl er via Wlan erreichbar war.
Man beachte #481 als nicht geschrieben. Ich bitte um Entschuldigung.
Ist ja nichts schlimmes passiert ;)
Hallo,
Da der Feinstaubsensor bei uns an der Garage montiert ist, möchte ich einen zweiten BME280 verwenden um die Temperatur in der Garage mit aufzunehmen. Hierzu habe ich die alternative FW laufen, die das auch zulässt. Da neben dem SDS auch der erste BME Daten an Luftdaten.info schickt, lässt die FW keine Namensänderung (auch nicht den des zweiten BME) zu. Somit erscheinen im json beide Sensoren mit identischen Bezeichnern:
{"software_version": "NRZ-2018-111-AF-062", "age":"137", "sensordatavalues":[
{"value_type":"SDS_P1","value":"11.00"},
{"value_type":"SDS_P2","value":"4.90"},
{"value_type":"BME280_temperature","value":"7.96"},
{"value_type":"BME280_humidity","value":"57.90"},
{"value_type":"BME280_pressure","value":"100544.48"},
{"value_type":"BME280_pressure_nn","value":"103933.00"},
{"value_type":"BME280_temperature","value":"6.56"},
{"value_type":"BME280_humidity","value":"79.04"},
{"value_type":"BME280_pressure","value":"100552.92"},
{"value_type":"BME280_pressure_nn","value":"103942.00"},
{"value_type":"samples","value":"408675"},
{"value_type":"min_micro","value":"343"},
{"value_type":"max_micro","value":"27610"},
{"value_type":"signal","value":"-63"}]}
Mit dem Modul konnte ich nur den letzten Datensatz fangen (scheint auch logisch). Eine Slave Definition bringt auch keine anderen Ergebnisse. Gibt es dennoch eine Möglichkeit beide abzugreifen, oder wäre eine Lösung auf FW Seite sinnvoller? Oder habe ich etwas übersehen?
Danke u. Gruß
Andreas
Zitat von: antidote am 25 Februar 2019, 18:41:49
Gibt es dennoch eine Möglichkeit beide abzugreifen, oder wäre eine Lösung auf FW Seite sinnvoller? Oder habe ich etwas übersehen?
aktuell bietet das Modul leider keine Möglichkeit doppelte Bezeichnungen zu unterscheiden.
Alles klar, ich denke es ist auch sinnvoller die Bezeichner unterscheiden zu können. Ich habe eine Lösung über eine FW-Modifikation gefunden https://forum.fhem.de/index.php/topic,73879.msg912925.html#msg912925 (https://forum.fhem.de/index.php/topic,73879.msg912925.html#msg912925).
Hi,
bis vor kurzer Zeit ist mein FHEM noch recht stabil gelaufen.
Seit ein paar Wochen hängt sich der komplette Webzugriff auf. Daten werden weiterhin geloggt.
Ich vermute mein Luftdaten Sensor ist hier der Übeltäter. Eigentlich werden die Daten im Devise korrekt angezeigt. Auch der Plot ist vollständig.
Das hier bekomme ich im Logfile:
2019.03.25 23:47:17 2: LuftdatenInfo (Luftdaten) - error while request: http://192.168.123.50/data.json: empty answer received
2019.03.25 23:47:17 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4693.
2019.03.25 23:47:26 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/99_Utils.pm line 131.
2019.03.25 23:47:26 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/99_Utils.pm line 132
2019.03.26 00:00:44 1: PERL WARNING: Useless use of string eq in void context at (eval 1199) line 1.
2019.03.26 00:00:44 1: PERL WARNING: Useless use of string eq in void context at (eval 1200) line 1.
2019.03.26 00:00:47 1: PERL WARNING: Useless use of string eq in void context at (eval 1204) line 1.
2019.03.26 00:00:47 1: PERL WARNING: Useless use of string eq in void context at (eval 1205) line 1.
2019.03.26 00:00:49 1: PERL WARNING: Useless use of string eq in void context at (eval 1210) line 1.
2019.03.26 00:00:49 1: PERL WARNING: Useless use of string eq in void context at (eval 1211) line 1.
2019.03.26 00:01:17 1: PERL WARNING: Useless use of string eq in void context at (eval 1246) line 1.
2019.03.26 00:01:17 1: PERL WARNING: Useless use of string eq in void context at (eval 1247) line 1.
Hat jemand von euch eine Idee was die Ursache ist.
Viele Grüße
Andi
Eine Vermutung - die nicht stimmen muss.
Mit Browser müsstest Du ja den Sensor direkt aufrufen können. Was kommt bei
http://192.168.123.50/values
http://192.168.123.50/data.json
http://192.168.123.50/values
Feinstaubsensor
ID: 7935750
MAC: 80:7D:3A:79:17:06
Firmware: NRZ-2018-123B
Übersicht » Aktuelle Werte
36 Sekunden seit der letzten Messung.
Sensor Parameter Wert
SDS011 PM2.5 2.4 µg/m³
SDS011 PM10 12.2 µg/m³
DHT22 Temperatur - °C
DHT22 rel. Luftfeuchte - %
WiFi Signal -64 dBm
WiFi Qualität 72 %
Anzahl Messungen: 4206
http://192.168.123.50/data.json
software_version "NRZ-2018-123B"
age "71"
sensordatavalues
0
value_type "SDS_P1"
value "12.20"
1
value_type "SDS_P2"
value "2.40"
2
value_type "samples"
value "1727646"
3
value_type "min_micro"
value "80"
4
value_type "max_micro"
value "616663"
5
value_type "signal"
value "-63"
Sieht alles prima aus. (Bei mir waren irgendwann PM10 und PM2.5 leer, WebGateway ging).
Wir reden also wohl eher über die WebVerbindung zum Sensor, da steht ja "empty answer received". Im Grunde heißt das, dass da ein leeres Dokument ankam - wobei ich nicht so wirklich weiß, wie der Autor des Moduls das abfeiert. Das müsste man mal @igami fragen.
Ich würde vermuten, dass Dein Feinstaubsensor via Wlan angebunden ist (ist es so?) und es regnerisch und/oder neblig mit Luftfeuchte nahe 100% war (war so)? Und daher der Abruf der JSON-Seite nicht vollständig war.
@igami
Was macht Dein Modul, wenn die Verbindung geöffnet wurde, dann auch einige Bytes übertragen werden - und http dann auf timeout läuft? Wirft Dein Modul dann "empty answer received" aus?
ZitatIch würde vermuten, dass Dein Feinstaubsensor via Wlan angebunden ist (ist es so?) und es regnerisch und/oder neblig mit Luftfeuchte nahe 100% war (war so)? Und daher der Abruf der JSON-Seite nicht vollständig war.
Das kann gut sein. War ja ziemlich regnerisch die letzten paar Wochen.
Zitat von: curt am 26 März 2019, 01:39:43
@igami
Was macht Dein Modul, wenn die Verbindung geöffnet wurde, dann auch einige Bytes übertragen werden - und http dann auf timeout läuft? Wirft Dein Modul dann "empty answer received" aus?
Entschuldige bitte die späte Antwort.
In dem Modul wird httpUtils verwendet und von dort stammt auch die Meldung "empty answer received".
Und da sind wir dann leider im Falschen Bereich.
FHEM/HttpUtils.pm rudolfkoenig Automatisierung
Hi Igami,
kannst du mir das genauer erkären? Ist das httpUtils fehlerhaft. Wer kann da genau weiterhelfen und was muss er wissen?
Was muss ich machen damit es nicht mehr zum besagten Absturz kommt?
Viele Grüße
Andi
Du musst im Bereich Automatisierung ein neues Thema erstellen bzw. nach einem ähnlichen gucken. Rudolf Koenig ist Maintainer für httpUtils und kann dir ggf. weiter helfen. Welche Informationen er benötigt kann ich dir nicht beantworten.
Wenn das Luftdaten Modul beim Abruf einen Fehler zurück bekommt wird die weitere Verarbeitung abgebrochen und der Fehler in das Log geschrieben.
Auch mit der Firmware auf dem Feinstaubsensor habe ich nichts am Hut. Da müsstest du dich direkt an die Entwickler von luftdaten.info wenden.
Eigenartig.
Ich habe einen eigenen Sensor in Betrieb. Der tut auch fein, um den soll es nicht gehen. Gleichzeitig frage ich zwei weitere in meiner Nähe befindliche entfernte öffentlich verfügbare Sensoren ab - die tun beide seit 2019-04-18 11:38:00 nicht mehr. Nun soll man ja bei Webzugriffen Gelassenheit üben, Zeit heilt viele Wunden.
Aber nun habe ich mir mein Protokoll doch mal genauer angeschaut:
2019.04.21 04:41:31 2: LuftdatenInfo (Luft[...]) - SDS011 position differs from other sensor position
Ähmmm - was will diese Fehlermeldung des Moduls mir denn bitte sagen? (Wir reden über Sensoren, die andere Nutzer des Projekts öffentlich machten!)
Und: Hat noch jemand das Problem, dass er neuerdings veröffentlichte Sensoren nicht mehr abfragen kann?
ZitatÄhmmm - was will diese Fehlermeldung des Moduls mir denn bitte sagen? (Wir reden über Sensoren, die andere Nutzer des Projekts öffentlich machten!)
Definition von 2 Sensoren deren Position abweicht. ::)
ZitatHat noch jemand das Problem, dass er neuerdings veröffentlichte Sensoren nicht mehr abfragen kann?
Das passiert öfter, wenn die Sensoren nicht mehr in Betrieb sind. Probier mal ein modify u. andere Stationen.
Zitat von: KölnSolar am 21 April 2019, 07:15:50
ZitatÄhmmm - was will diese Fehlermeldung des Moduls mir denn bitte sagen? (Wir reden über Sensoren, die andere Nutzer des Projekts öffentlich machten!)
Definition von 2 Sensoren deren Position abweicht. ::)
Ich habe leider immer noch nicht verstanden. Die beiden fremden Sensoren sind doch nicht umgezogen. Wie ist das also gemeint, dieses "deren Position abweicht"?
Zitat von: KölnSolar am 21 April 2019, 07:15:50
Das passiert öfter, wenn die Sensoren nicht mehr in Betrieb sind. Probier mal ein modify u. andere Stationen.
Negativ. Laut http://deutschland.maps.luftdaten.info geht es den beiden fremden Sensoren ganz prima.
Raw def kopieren, gerät löschen und neu anlegen. (Import des kopierten Code)
Dann geht's wieder.
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: curt am 21 April 2019, 06:10:28
Eigenartig.
Ich habe einen eigenen Sensor in Betrieb. Der tut auch fein, um den soll es nicht gehen. Gleichzeitig frage ich zwei weitere in meiner Nähe befindliche entfernte öffentlich verfügbare Sensoren ab - die tun beide seit 2019-04-18 11:38:00 nicht mehr. Nun soll man ja bei Webzugriffen Gelassenheit üben, Zeit heilt viele Wunden.
Aber nun habe ich mir mein Protokoll doch mal genauer angeschaut:
2019.04.21 04:41:31 2: LuftdatenInfo (Luft[...]) - SDS011 position differs from other sensor position
Ähmmm - was will diese Fehlermeldung des Moduls mir denn bitte sagen? (Wir reden über Sensoren, die andere Nutzer des Projekts öffentlich machten!)
Und: Hat noch jemand das Problem, dass er neuerdings veröffentlichte Sensoren nicht mehr abfragen kann?
Fragst du beide Sensoren in einem FHEM Device ab? Falls ja sagt die Meldung korrekt aus, dass die Standorte der beiden Sensoren nicht überein stimmen. Falls nein brauche ich mehr Informationen.
ZitatNegativ
modify !
ZitatWie ist das also gemeint, dieses "deren Position abweicht"?
Wie wär es, wenn Du Deine def postest ? Dann lässt sich das am Bsp. erklären.
Zitat von: igami am 21 April 2019, 08:00:40
Fragst du beide Sensoren in einem FHEM Device ab? [...] Falls nein brauche ich mehr Informationen.
Nein, das sind drei Devices: Der eigene Sensor. Und dann zwei fremde, via luftdateninfo.
Zitat von: KölnSolar am 21 April 2019, 08:12:44
modify !
Ich habe nicht verstanden, weiß nicht, was gemeint ist.
Zitat von: KölnSolar am 21 April 2019, 08:12:44
Wie wär es, wenn Du Deine def postest ? Dann lässt sich das am Bsp. erklären.
Der eigene Sensor, der tut:
define Luftx LuftdatenInfo local 192.168.1.249
setuuid Luftx 5c4fa348-f33f-769b-156f-34c91fd3ef22559b
attr Luftx event-on-change-reading PM2.5,PM10,temperature
attr Luftx event-on-update-reading PM2.5,PM10,temperature
attr Luftx readingsSupervision 600,,PM10
attr Luftx room 64 Feinstaub
attr Luftx stateFormat {sprintf("%2.f - PM10",ReadingsVal("Luftx","PM10",0))}
Einer der beiden fremden Sensoren (die tun nicht mehr):
define LuftN LuftdatenInfo remote 7875
setuuid LuftN 5c47b0d0-f33f-769b-c892-cba2fae02f47b278
attr LuftN event-on-change-reading PM2.5,PM10
attr LuftN event-on-update-reading PM2.5,PM10
attr LuftN readingsSupervision 600,,PM10
attr LuftN room 64 Feinstaub
attr LuftN stateFormat {sprintf("%2.f - PM10",ReadingsVal("LuftN","PM10",0))}
Wie schon geschrieben, neu anlegen u d er läuft wieder.
Hatten wir vor paar Monaten schon mal...
Gesendet von meinem Doogee S60 mit Tapatalk
Nun ja - das ist alles sehr verblüffend. An magisches Zaubersalz mag ich nicht glauben. Auf Grund der mehrfachen Hinweise "neu anlegen" dachte ich zunächst an irgendwelche blockierenden alten Daten - und bereinigte fhem.save - alles raus, was irgendwie mit den beiden entfernten luftdaten-Sensoren zusammenhängt. Das Ergebnis dieser Operation war verblüffend: Beide entfernte Sensoren meldeten sich nun wieder - aber sehr sporadisch, quasi stochastisch.
Also höre ich auf @Frank_Huber - ein hero wird schon wissen was er sagt. Kann ja sein, dass da irgendwelche internals anders angelegt werden oderoder. Frank, es sieht tatsächlich so aus als ob die Neuanlage der beiden Devices das Problem löst. Allerdings - völlige Verblüffung: Die neu angelegten Devices sind völlig identisch (mal abgesehen von setuuid) - wirklich alles ist identisch. Damit ergibt sich tatsächlich die Frage, was hier überhaupt passiert.
Aber wartet - es wird noch besser, respektive schlechter!
Seitdem meldet nun mein EIGENER Sensor nicht mehr! (Selbigen baute ich nicht selbst, Robin war so freundlich. Dort ist so eine ganz kleine Platine verbaut, die das Ganze in mein Wlan bringt - falls das von fachlichem Interesse ist.)
@igami
Du bist doch der Maintainer des Moduls? Ich weiß, dass manche Maintainer sehr sensibel reagieren, daher erkläre ich vorab, dass ich dankbar bin und auch nichts kritisieren möchte. Ich möchte halt verstehen, was schief geht und ggf. meinen kleinen Beitrag zur Verbesserung liefern.
Kann es sein, dass mehrere Instanzen Deines Moduls sich versehentlich gegenseitig beeinflussen? Vergessene lokale Deklaration (my), diese Ecke?
Weiterer Hinweis: Für die beiden fremden, entfernten Sensoren nutze ich zwei Devices, siehe oben. Mein EIGENER Sensor ist das dritte Device und meldet via Wlan. Hier ist zum Verständnis wichtig, dass ich meinen EIGENEN Sensor nicht an luftdaten.info melden lasse. Mein Sensor ist autonom, nur ich selbst frage via Wlan ab. Könnte da das Problem sein?
OT:
Ich wünsche allen frohe Ostern!
Zitat von: curt am 22 April 2019, 05:48:43
Nun ja - das ist alles sehr verblüffend. An magisches Zaubersalz mag ich nicht glauben. Auf Grund der mehrfachen Hinweise "neu anlegen" dachte ich zunächst an irgendwelche blockierenden alten Daten - und bereinigte fhem.save - alles raus, was irgendwie mit den beiden entfernten luftdaten-Sensoren zusammenhängt. Das Ergebnis dieser Operation war verblüffend: Beide entfernte Sensoren meldeten sich nun wieder - aber sehr sporadisch, quasi stochastisch.
Also höre ich auf @Frank_Huber - ein hero wird schon wissen was er sagt. Kann ja sein, dass da irgendwelche internals anders angelegt werden oderoder. Frank, es sieht tatsächlich so aus als ob die Neuanlage der beiden Devices das Problem löst. Allerdings - völlige Verblüffung: Die neu angelegten Devices sind völlig identisch (mal abgesehen von setuuid) - wirklich alles ist identisch. Damit ergibt sich tatsächlich die Frage, was hier überhaupt passiert.
Bei der Abfrage von entfernten Sensoren wird immer der gelieferte Standort mit dem vorhandenen verglichen. Die Daten werden nur verarbeitet, wenn die Standorte übereinstimmen. Ich könnte mir nun vorstellen, dass sich an den Standortdaten bei Luftdaten Info etwas geändert hat (z.B. eine Nachkommastelle wurde eingespart oder so). Das ist allerdings reine Spekulation.
Weshalb sich sie Sensoren nur sporadisch melden kann ich nicht beantworten. Sind die Ausreißer auch in den Diagrammen auf Luftdaten.Info zu finden?
Zitat von: curt am 22 April 2019, 05:48:43
Seitdem meldet nun mein EIGENER Sensor nicht mehr! (Selbigen baute ich nicht selbst, Robin war so freundlich. Dort ist so eine ganz kleine Platine verbaut, die das Ganze in mein Wlan bringt - falls das von fachlichem Interesse ist.)
Was bedeutet er meldet sich nicht mehr (Fehlermeldung)?
Was für eine kleine Platine? Der NodeMCU hat doch WLAN an board ???
Zitat von: curt am 22 April 2019, 05:48:43
@igami
Du bist doch der Maintainer des Moduls? Ich weiß, dass manche Maintainer sehr sensibel reagieren, daher erkläre ich vorab, dass ich dankbar bin und auch nichts kritisieren möchte. Ich möchte halt verstehen, was schief geht und ggf. meinen kleinen Beitrag zur Verbesserung liefern.
Kann es sein, dass mehrere Instanzen Deines Moduls sich versehentlich gegenseitig beeinflussen? Vergessene lokale Deklaration (my), diese Ecke?
Habe gerade noch mal schnell überflogen, da sollte sich nichts gegenseitig beeinflussen.
Zitat von: curt am 22 April 2019, 05:48:43
Weiterer Hinweis: Für die beiden fremden, entfernten Sensoren nutze ich zwei Devices, siehe oben. Mein EIGENER Sensor ist das dritte Device und meldet via Wlan. Hier ist zum Verständnis wichtig, dass ich meinen EIGENEN Sensor nicht an luftdaten.info melden lasse. Mein Sensor ist autonom, nur ich selbst frage via Wlan ab. Könnte da das Problem sein?
Nein, sollte kein Problem sein, da es ja als "local" definiert ist.
Morgen igami,
Das passt zum log. Da hatte ich Einträge den Standort betreffend.
Nach neu anlegen ging wieder alles.
Donnerstag "Ausfall", Gestern durch Neuanlegn "repariert"
Werde das nächste Mal die Readings vorher/nachher vergleichen. [emoji1360]
Gesendet von meinem Doogee S60 mit Tapatalk
Hallo und frohe Ostern allen Lesern!
Ich möchte meine Erfahrungen mal hier mit einfließen lassen.
Ich hatte die selbe Fehlermeldung im .log wie oben beschrieben:
2019.04.22 08:07:22 2: LuftdatenInfo (FeinstaubLO) - SDS011 position differs from other sensor positionDaraufhin ging ich auf die Suche nach einem Lösungsvorschlag. Diesen fand ich hier von @Frank_Huber. Vielen Dank dafür!
Ich habe alle meine Sensoren, die ich remote über die SensorID abfrage, gelöscht und wieder neu angelegt. Nach dieser Prozedur ging alles wieder einwandfrei.
Das ließ mir aber keine Ruhe, denn die Ursache hat sich mir erst auf den zweiten Blick gezeigt. Der Hinweis darauf kam von @igami :
ZitatIch könnte mir nun vorstellen, dass sich an den Standortdaten bei Luftdaten Info etwas geändert hat (z.B. eine Nachkommastelle wurde eingespart oder so). Das ist allerdings reine Spekulation.
Will sagen, kein(!) Spekulation, lieber Maintainer. ;)
Um die ganze Sache zu belegen, hänge ich mal die raw von ein und demselben Sensor hier an:
altes define :
defmod FeinstaubLO LuftdatenInfo remote 14241
attr FeinstaubLO comment PM = myg/m3
attr FeinstaubLO devStateStyle style=text-align:right
attr FeinstaubLO group Weather
attr FeinstaubLO interval 3600
attr FeinstaubLO room Wetter
attr FeinstaubLO stateFormat location :   < 10µm = PM10 µg/m³   < 2.5µm = PM2.5 µg/m³
setstate FeinstaubLO 09212 Limbach-Oberfrohna :   < 10µm = 5.43 µg/m³   < 2.5µm = 4.80 µg/m³
setstate FeinstaubLO 2019-04-18 11:33:59 PM10 5.43
setstate FeinstaubLO 2019-04-18 11:33:59 PM2.5 4.80
setstate FeinstaubLO 2018-07-01 18:14:54 latitude 50.8640
setstate FeinstaubLO 2018-07-01 18:14:56 location 09212 Limbach-Oberfrohna
setstate FeinstaubLO 2018-07-01 18:14:54 longitude 12.7660
setstate FeinstaubLO 2019-04-22 01:28:25 state error
und nun das neue define :
defmod FeinstaubSA_Z_LO LuftdatenInfo remote 14241
attr FeinstaubSA_Z_LO comment PM = µg/m³
attr FeinstaubSA_Z_LO devStateStyle style=text-align:right
attr FeinstaubSA_Z_LO group Weather
attr FeinstaubSA_Z_LO interval 3600
attr FeinstaubSA_Z_LO room Wetter
attr FeinstaubSA_Z_LO stateFormat location :   < 10µm = PM10 µg/m³    < 2.5µm = PM2.5 µg/m³
setstate FeinstaubSA_Z_LO 09212 Limbach-Oberfrohna :   < 10µm = 3.93 µg/m³    < 2.5µm = 3.60 µg/m³
setstate FeinstaubSA_Z_LO 2019-04-22 10:12:28 PM10 3.93
setstate FeinstaubSA_Z_LO 2019-04-22 10:12:28 PM2.5 3.60
setstate FeinstaubSA_Z_LO 2019-04-22 10:02:28 latitude 50.864
setstate FeinstaubSA_Z_LO 2019-04-22 10:02:29 location 09212 Limbach-Oberfrohna
setstate FeinstaubSA_Z_LO 2019-04-22 10:02:28 longitude 12.766
setstate FeinstaubSA_Z_LO 2019-04-22 10:12:28 state active
Und es ist ganz deutlich zu sehen, bei "latitude" und bei "longitude" fehlt eine Nachkommastelle. Es fehlet die "0" !
Ich denke damit ist die Sache erklärt und ich freue mich, einen kleinen Beitrag geleistet zu haben.
wünsche euch einen schönen und sonnigen RestOsterMontag!
LG aus C! :)
Ich ändere es mal ab, dass lat/long nicht als Text, sondern als Zahl verglichen werden.
Zitat von: DefanC am 22 April 2019, 10:35:47
Und es ist ganz deutlich zu sehen, bei "latitude" und bei "longitude" fehlt eine Nachkommastelle. Es fehlet die "0" !
Ich denke damit ist die Sache erklärt und ich freue mich, einen kleinen Beitrag geleistet zu haben.
Danke @DefanC - leider ist die Sache nicht geklärt. Denn bei mir war vorher/nachher alles identisch, auch Koordinaten.
Zitat von: igami am 22 April 2019, 10:03:19
Bei der Abfrage von entfernten Sensoren wird immer der gelieferte Standort mit dem vorhandenen verglichen. Die Daten werden nur verarbeitet, wenn die Standorte übereinstimmen.
Bitte präziser:
Wer konkret vergleicht was? Ist das Dein Modul? Oder vergleicht luftdaten.info da was? Und warum das Ganze?
Zitat von: igami am 22 April 2019, 10:03:19
Weshalb sich sie Sensoren nur sporadisch melden kann ich nicht beantworten. Sind die Ausreißer auch in den Diagrammen auf Luftdaten.Info zu finden?
Ok, ich formulierte offenbar nicht verständlich. Alles zurück auf Start, ich berichte nochmals:
Eigener Feinstaubsensor, da ist wichtig zu wissen, dass der NICHT an luftdaten.info meldet! Meine Station gibt es so gesehen gar nicht. Der kam neu, konnte aber nicht wie eine frühere Station die Wlan-Strecke bewältigen. Ok, also Luftlinie 5 Meter vom Wlan-AP entfernt auf das Fensterbrett bei Morgensonne.
Kurz darauf stelle ich fest: Oha, die beiden entfernten Sensoren melden nicht mehr, also im Thread fragen. Antwort war wie gesagt "neu anlegen". Diese befriedigte mich nicht, da sich da ja nichts geändert hatte. So kam ich auf die Idee (es muss ja was anderes sein), zunächst einmal nur die entsprechenden Werte in fhem.save zu löschen.
Und das Ergebnis war hoch interessant, ich hoffe, dass das Dir @igami hilft: Es kamen wieder Werte. aber nicht alle fünf Minuten. Sondern scheinbar stochastisch, mal einer pro Stunde, mal einer in 90 Minuten.
Erst danach legte ich beide Stationen nach Löschung neu an. Sie sind (Screenshot) völlig identisch, insbesondere Koordinaten. (Ok, auf die Idee "list" kam ich nicht.) Seitdem liefern beide wieder im Takt von fünf Minuten.
Von daher würde ich mich zu der These versteigen wollen, dass es die Koordinate nicht (allein) sein kann, da klemmt offenbar noch etwas anderes.
Zitat von: igami am 22 April 2019, 10:03:19
Habe gerade noch mal schnell überflogen, da sollte sich nichts gegenseitig beeinflussen.
Nein, sollte kein Problem sein, da es ja als "local" definiert ist.
Wir müssen halt ein Auge drauf haben. Nun wissen wir ja, was wir im Falle des Falles dokumentieren müssen (list device vorher/nachher usw.). Denn da scheint irgendwo noch der Wurm drin zu sein - das muss ja gar nicht einmal primär in Deinem Modul sein. Da sind ja auch zig Möglichkeiten denkbar, dass luftdaten.info selbst rumzickt (da ist mir nicht so ganz klar, wie man das überhaupt debuggt).
Zitat von: igami am 22 April 2019, 10:03:19
Was bedeutet er meldet sich nicht mehr (Fehlermeldung)?
Was für eine kleine Platine? Der NodeMCU hat doch WLAN an board ???
Vermutlich andere Baustelle.
Ich habe keine Ahnung, was da verbaut ist. Es ist schon der zweite, der erste war via Webinterface noch erreichbar, hatte aber keine Messdaten mehr. Dieser zweite muss näher an den AP des Wlan. Vor allem aber setzt er mehrere Stunden aus, ist im Wlan überhaupt nicht erreichbar. Hier ist anzumerken, dass der Wlan-AP ein Raspberry Pi mit dicken Antennen ist. Zudem ist ein Repeater im Spiel, der echtes Mash kann und auch liefert. (Wenn alles läuft ist das ganz prima ... aber wehe, irgendwo zickt was rum ... Debugging kanst Du da im Grunde vergessen.)
Du schreibst sehr durcheinander. Ich versuche mal zusammenzufassen:
Dein eigener Sensor hat WLAN Probleme und damit hat das Thema nichts mehr mit FHEM zu tun (?)
Es wirkt für mich so, als wenn du nicht wüsstest was bei dem direkten bearbeiten von config / save Dateien zu beachten ist.
Das kann zu Problemen führen. Bitte einfach die Möglichkeiten von FHEMWEB nutzen. Für alle Befehle findest du Hilfe in der commandref.
Anstelle Einträge aus fhem.save zu löschen => deletereading <name> <reading>
Keine Daten ohne Fehlermeldung gibt es nicht (allerdings nur bei Loglevel >= 2).
Auch hast du noch nicht gesagt ob die Messwerte auf Luftdaten.info verfügbar waren. Vielleicht haben die Sensoren ja auch einen Aussetzer gehabt.
Da du vorher die Fehlermeldung bzgl. abweichender Standortdaten gehabt hast kann ich nicht glauben, dass diese vorher identisch waren. pics or it didn't happen
Der Vergleich wird von dem FHEM Modul durchgeführt um falsche ID Kombinationen (Feinstaub / Temperatur etc.) auszuschließen.
Zitat von: igami am 23 April 2019, 17:22:34
Du schreibst sehr durcheinander.
Das lässt sich schlecht vermeiden, wenn man in
einem Posting auf mehrere Themen eines anderen Postings eingeht. Alternativ müsste ich mehrere direkt folgende Postings absetzen.
Zitat von: igami am 23 April 2019, 17:22:34
Dein eigener Sensor hat WLAN Probleme und damit hat das Thema nichts mehr mit FHEM zu tun (?)
Der Verursacher ist nicht völlig klar - daher möchte ich diesen Punkt aus der Diskussion derzeit zurückziehen. (Das kann gut eine zeitliche Überschneidung nicht kausal zusammenhängender Dinge sein.)
Zitat von: igami am 23 April 2019, 17:22:34
Es wirkt für mich so, als wenn du nicht wüsstest was bei dem direkten bearbeiten von config / save Dateien zu beachten ist.
Ich denke, dass ich das weiß. Die darauf folgende Diskussion sollten wir uns sparen - schlage ich vor. Der eigentliche Punkt war das folgende stochastische Verhalten. Das wollte ich Dir berichten, kann ja sein, dass Dir solche Info hilft.
Zitat von: igami am 23 April 2019, 17:22:34
Auch hast du noch nicht gesagt ob die Messwerte auf Luftdaten.info verfügbar waren. Vielleicht haben die Sensoren ja auch einen Aussetzer gehabt.
Ich schaute in der Zeit mehrfach auf deren Deutschlandkarte. Und da waren sie da. Grafische Statistiken von denen kenne ich nicht, hatte offen gesagt auch nicht die Nerven, mir da alles genau anzusehen. Mir reichte die Erkenntnis, dass die beiden an luftdaten.info lieferten, ich diese Werte aber nicht in FHEM bekam.
Zitat von: igami am 23 April 2019, 17:22:34
Da du vorher die Fehlermeldung bzgl. abweichender Standortdaten gehabt hast kann ich nicht glauben, dass diese vorher identisch waren. pics or it didn't happen
Ich kam nicht auf die Idee "list" ... beim nächsten Mal. Aber auf "SEND PICS", da springe ich an. You've Mail.
Zitat von: igami am 23 April 2019, 17:22:34
Der Vergleich wird von dem FHEM Modul durchgeführt um falsche ID Kombinationen (Feinstaub / Temperatur etc.) auszuschließen.
Danke für die Erklärung.
Zitat von: curt am 24 April 2019, 01:08:42
Das lässt sich schlecht vermeiden, wenn man in einem Posting auf mehrere Themen eines anderen Postings eingeht. Alternativ müsste ich mehrere direkt folgende Postings absetzen.
sortiert würde reichen ;)
Zitat von: curt am 24 April 2019, 01:08:42
Ich denke, dass ich das weiß. Die darauf folgende Diskussion sollten wir uns sparen - schlage ich vor. Der eigentliche Punkt war das folgende stochastische Verhalten. Das wollte ich Dir berichten, kann ja sein, dass Dir solche Info hilft.
wenn du beschreibst was du genau gemacht hast kann ich damit was anfangen. aber einfach nur Sachen aus fhem.save zu löschen bringt nichts ohne weitere Aktionen
Zitat von: curt am 24 April 2019, 01:08:42
Ich schaute in der Zeit mehrfach auf deren Deutschlandkarte. Und da waren sie da. Grafische Statistiken von denen kenne ich nicht, hatte offen gesagt auch nicht die Nerven, mir da alles genau anzusehen. Mir reichte die Erkenntnis, dass die beiden an luftdaten.info lieferten, ich diese Werte aber nicht in FHEM bekam.
einfach auf die ID des Sensor klicken (siehe Anhang)
Zitat von: curt am 24 April 2019, 01:08:42
Ich kam nicht auf die Idee "list" ... beim nächsten Mal. Aber auf "SEND PICS", da springe ich an. You've Mail.
Fehlermeldungen stehen nicht bei list, sondern im Logfile
Zitat von: igami am 24 April 2019, 05:39:29
einfach auf die ID des Sensor klicken (siehe Anhang)
ich habe entweder die falschen Sensoren im Blick. Oder den falschen Browser. Da ist der letzte Wert - aber keine Grafik.
Zitat von: igami am 24 April 2019, 05:39:29
Fehlermeldungen stehen nicht bei list, sondern im Logfile
Kommunikation ist anstrengend :(
Die Fehlermeldung ist bekannt. Es ging da aber um die (andere) Frage, wie man am Besten vorher/nachher bei einer Device dokumentiert, die man löschen und neu anlegen muss.
Hallo zusammen,
gibt es eigentlich eine Möglichkeit die in FHEM empfangenen Daten an Luftdaten.info zu senden? Laut luftdaten.info API sollte das per JSON grundsätzlich möglich sein, aber wie würde das Vorgehen dafür aussehen?
Mein PMS7003 ist zusammen mit anderen Sensoren bereits in ESPEasy eingebunden. Da möchte ich ungern von weg nur um die Daten hochzuladen.
Besten Dank und Grüße
Aktuell gibt es diese Möglichkeit nicht. Wenn du mir allerdings Infos zukommen lässt wie die Übermittlung auszusehen hat kann ich das auch meine ToDo Liste nehmen (auch wenn da gerade wenig von abgearbeitet wird ::))
Hallo igami,
das ist ein super Angebot. Danke.
Auf github (https://github.com/corny/luftdaten-python/blob/master/main.py (https://github.com/corny/luftdaten-python/blob/master/main.py)) findet man eine Luftdaten.info-Firmware für einen Raspberry Pi. Die Funktion pushLuftdaten ist denke ich erfolgsversprechend was das submitten von Werten angeht. Ich habe das mal versucht so gut ich es verstanden habe auseinanderzunehmen und komme zu folgender Struktur:
https://api.luftdaten.info/v1/push-sensor-data/json={ "software_version": "python-dusty 0.0.1", "sensordatavalues": [{"value_type":"P1","value":"50.00"},{"value_type":"P2","value":"40.00"}] }, headers={ "X-PIN": 1, "X-Sensor": nnnnn }
Dabei ist python-dusty ein Service der auf dem Raspberry-Pi für das regelmäßige Senden zuständig ist.
Sensordatavalues enthält dann die eigentlichen Daten. P1 steht für den PM10, P2 für den PM2.5. Dahinter steht dann der zugehörige numerische Wert.
X-PIN bezeichnet den Sensortyp und wie er unter meine.Luftdaten.info definiert ist. Üblicherweise findet man X-PIN 1 für den Partikelsensor und X-PIN 7 oder 11 für den Environment-Sensor (DHT22 oder BME280).
Der Wert hinter X-Sensor steht dann für die numerische ID des Sensors. Den sieht man auch unter meine.Luftdaten.info.
Wenn ich den obigen Link bei mir eintippe passiert allerdings leider nichts.
Vielleicht kannst du da mehr mit anfangen.
Beste Grüße
Stephan
Edit: Eine API für manuelles posten der Daten gibt es unter anderem schon hier.
https://api.luftdaten.info/v1/push-sensor-data/
Dort sieht man auch unter Optionen welche Daten submitted werden können. Ich kopiere von dort einfach mal.
HTTP 200 OK
Allow: POST, OPTIONS
Content-Type: application/json
Vary: Accept
{
"name": "Post Sensor Data List",
"description": "This endpoint is to POST data from the sensor to the api.",
"renders": [
"application/json",
"text/html"
],
"parses": [
"application/json",
"application/x-www-form-urlencoded",
"multipart/form-data"
],
"actions": {
"POST": {
"sensor": {
"type": "integer",
"required": false,
"read_only": false,
"label": "Sensor"
},
"sampling_rate": {
"type": "integer",
"required": false,
"read_only": false,
"label": "Sampling rate",
"help_text": "in milliseconds",
"min_value": -2147483648,
"max_value": 2147483647
},
"timestamp": {
"type": "datetime",
"required": false,
"read_only": false,
"label": "Timestamp"
},
"sensordatavalues": {
"type": "field",
"required": true,
"read_only": false,
"label": "Sensordatavalues",
"child": {
"type": "nested object",
"required": true,
"read_only": false,
"children": {
"value": {
"type": "string",
"required": true,
"read_only": false,
"label": "Value"
},
"value_type": {
"type": "choice",
"required": true,
"read_only": false,
"label": "Value type",
"choices": [
{
"display_name": "1µm particles",
"value": "P0"
},
{
"display_name": "10µm particles",
"value": "P1"
},
{
"display_name": "2.5µm particles",
"value": "P2"
},
{
"display_name": "3µm particles",
"value": "P3"
},
{
"display_name": "4µm particles",
"value": "P4"
},
{
"display_name": "5µm particles",
"value": "P5"
},
{
"display_name": "duration 1µm",
"value": "durP1"
},
{
"display_name": "duration 2.5µm",
"value": "durP2"
},
{
"display_name": "ratio 1µm in percent",
"value": "ratioP1"
},
{
"display_name": "ratio 2.5µm in percent",
"value": "ratioP2"
},
{
"display_name": "samples",
"value": "samples"
},
{
"display_name": "min_micro",
"value": "min_micro"
},
{
"display_name": "max_micro",
"value": "max_micro"
},
{
"display_name": "Temperature",
"value": "temperature"
},
{
"display_name": "Humidity",
"value": "humidity"
},
{
"display_name": "Pa",
"value": "pressure"
},
{
"display_name": "meter",
"value": "altitude"
},
{
"display_name": "Pa (sealevel)",
"value": "pressure_sealevel"
},
{
"display_name": "Brightness",
"value": "brightness"
},
{
"display_name": "Dust density in mg/m3",
"value": "dust_density"
},
{
"display_name": "Dust voltage raw",
"value": "vo_raw"
},
{
"display_name": "Dust voltage calculated",
"value": "voltage"
},
{
"display_name": "1µm particles",
"value": "P10"
},
{
"display_name": "2.5µm particles",
"value": "P25"
},
{
"display_name": "duration 1µm",
"value": "durP10"
},
{
"display_name": "duration 2.5µm",
"value": "durP25"
},
{
"display_name": "ratio 1µm in percent",
"value": "ratioP10"
},
{
"display_name": "ratio 2.5µm in percent",
"value": "ratioP25"
},
{
"display_name": "door state (open/closed)",
"value": "door_state"
},
{
"display_name": "latitude",
"value": "lat"
},
{
"display_name": "longitude",
"value": "lon"
},
{
"display_name": "height",
"value": "height"
},
{
"display_name": "horizontal dilusion of precision",
"value": "hdop"
},
{
"display_name": "measured timestamp",
"value": "timestamp"
},
{
"display_name": "measured age",
"value": "age"
},
{
"display_name": "number of satelites",
"value": "satelites"
},
{
"display_name": "current speed over ground",
"value": "speed"
},
{
"display_name": "track angle",
"value": "azimuth"
},
{
"display_name": "Sound level min",
"value": "noise_LA_min"
},
{
"display_name": "Sound level max",
"value": "noise_LA_max"
},
{
"display_name": "Sound level L01",
"value": "noise_LA01"
},
{
"display_name": "Sound level L95",
"value": "noise_LA95"
},
{
"display_name": "Sound level Leq",
"value": "noise_LAeq"
},
{
"display_name": "Counts per second",
"value": "counts_per_second"
},
{
"display_name": "Counts per minute",
"value": "counts_per_minute"
},
{
"display_name": "MilliSievert",
"value": "radiation_msi"
}
]
},
"sensordata": {
"type": "integer",
"required": false,
"read_only": true,
"label": "Sensordata"
}
}
}
},
"software_version": {
"type": "string",
"required": false,
"read_only": false,
"label": "Software version",
"help_text": "sensor software version",
"max_length": 100
}
}
}
}
Hallo,
nun sag einer, dass der Feinstaubsensor nicht auch für andere Sachen gut ist.
Ich habe am u.A. am Freitag den Putz an der Wetterseite meines Hauses weggeklopft, Start war um 15:30 Uhr, Ende dann um 19:00 Uhr, mit Zusammenfegen sind wir kurz vor 20:00 Uhr fertig gewesen.
Die Sache scheint doch nicht ganz staubfrei über die Bühne zu gehen ??? ::);D.
Gruß Peter
Ist auch lustig, wenn man den Grill anwirft...sieht man sofort ;)
Gruß
Uwe
P.S.: Da hat gestern der Nachbar den Grill angeheizt...
Ich habe mich heute mal wieder mit meinem Feinstaubsensor beschäftigt, da der irgendwie nicht mehr richtig das tut, was er soll.
Als Sensorer gibt er mir an:
max_micro
min_micro
samples
signal
temperature
humidity
softwareVersion
Ich habe einen SDS11 und DHT22 verbaut.
"Früher" hatte ich mal PM10 und PM2.5 Werte. Die sind aber weg. Eben nur noch die Sensoren oben.
Und die bekomme ich auch nur für signal, temperature, und humidity ausgelesen.
softwareVersion = NRZ-2018-123B
==> Verbindung klappt.
define SDS012 LuftdatenInfo local 192.168.2.59
attr SDS012 userattr reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex reading04Name reading04Regex reading05Name reading05Regex reading06Name reading06Regex reading07Name reading07Regex requestHeader stateFormat
attr SDS012 reading01Name temperature
attr SDS012 reading01Regex "temperature","value":"(0|\d*\.\d+)"}.*
attr SDS012 reading02Name humidity
attr SDS012 reading02Regex "humidity","value":"(0|\d*\.\d+)"}.*
attr SDS012 reading03Name max_micro
attr SDS012 reading03Regex "max_micro","value":"(0|\d*\.\d+)"}.*
attr SDS012 reading04Name min_micro
attr SDS012 reading04Regex "min_micro","value":"(0|\d*+)"}.*
attr SDS012 reading05Name software_version
attr SDS012 reading05Regex "software_version": "(.*?)".*
attr SDS012 reading06Name samples
attr SDS012 reading06Regex "samples","value":"(0|\d*\.\d+)"}.*
attr SDS012 reading07Name pm25
attr SDS012 reading07Regex "SDS_P2","value":"(0|\d*\.\d+)"}.*
attr SDS012 requestHeader Content-Type: application/json
attr SDS012 room Feinstaub
attr SDS012 stateFormat {sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("SDS011","max_micro",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("SDS011","min_micro",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("SDS011","humidity",0))}
attr SDS012 verbose 1
Könnte bitte jemand seine Konfiguration / cfg posten.
DANKE
Grüße
Jörg
Hi,
zeig doch mal ein List vom Device.
Die Readings kommen doch vom Modul selbst, da muss man keine extra Attribute setzen (kann man aber natürlich).
Ich vermute mal, das dein SDS11 gestorben ist, und daher keine Werte mehr von Ihm kommen.
Meine Config sieht so aus (exclusive room usw) die IP hab ich auch geändert.
define luftdatensensor1 LuftdatenInfo local 1.2.3.4
attr luftdatensensor1 interval 300
attr luftdatensensor1 stateFormat {sprintf("PM10: %.2f µg/m³ / ",ReadingsVal("luftdatensensor1","PM10",0)).sprintf("PM2.5: %.2f µg/m³ / ",ReadingsVal("luftdatensensor1","PM2.5",0)).sprintf("Temp: %.2f °C / ",ReadingsVal("luftdatensensor1","temperature",0)).sprintf("Hum: %.2f %%", ReadingsVal("luftdatensensor1","humidity",0))}
attr luftdatensensor1 timeout 10
attr luftdatensensor1 verbose 1
Ronny
Zitat von: jnewton957 am 01 September 2019, 22:50:57
Ich habe mich heute mal wieder mit meinem Feinstaubsensor beschäftigt, da der irgendwie nicht mehr richtig das tut, was er soll.
Hast du kürzlich von HTTPMOD auf LuftdatenInfo umgestellt?
Zitat von: Christoph Morrison am 02 September 2019, 12:49:01
Hast du kürzlich von HTTPMOD auf LuftdatenInfo umgestellt?
Nein. Faktisch nur wieder neu angeschlossen und ausgelesen. Keine Veränderung am coding.
nternals:
ADDRESS 192.168.2.59
CFGFN /opt/fhem/FHEM/30_airquality.cfg
DEF local 192.168.2.59
FUUID 5d6c3036-f33f-524a-2f79-23da66d0ba8005b0
INTERVAL 30
MODE local
NAME SDS012
NR 2367
STATE PM10: 0.0 µg/m³ / PM2.5: 0.0 µg/m³ / Temp: 22.5 °C / Hum: 56.2 %
TIMEOUT 5
TYPE LuftdatenInfo
.attraggr:
.attrminint:
Helper:
DBLOG:
temperature:
DbLog:
TIME 1567743509.4151
VALUE 22.50
READINGS:
2019-09-01 20:18:50 .sensors humidity max_micro min_micro samples signal temperature
2019-09-06 06:18:29 dewpoint 13.3
2019-09-06 06:18:29 humidity 56.20
2019-09-06 06:18:29 signal -46
2019-09-01 20:18:50 softwareVersion NRZ-2018-123B
2019-09-06 06:18:29 state active
2019-09-06 06:18:29 temperature 22.50
Attributes:
reading01Name temperature
reading01Regex "temperature","value":"(0|\d*\.\d+)"}.*
reading02Name humidity
reading02Regex "humidity","value":"(0|\d*\.\d+)"}.*
reading03Name max_micro
reading03Regex "max_micro","value":"(0|\d*\.\d+)"}.*
reading04Name min_micro
reading04Regex "min_micro","value":"(0|\d*+)"}.*
reading05Name software_version
reading05Regex "software_version": "(.*?)".*
reading06Name samples
reading06Regex "samples","value":"(0|\d*\.\d+)"}.*
reading07Name pm25
reading07Regex "SDS_P2","value":"(0|\d*\.\d+)"}.*
requestHeader Content-Type: application/json
room Feinstaub
stateFormat {sprintf("PM10: %.1f µg/m³ / ",ReadingsVal("SDS011","max_micro",0)).sprintf("PM2.5: %.1f µg/m³ / ",ReadingsVal("SDS011","min_micro",0)).sprintf("Temp: %.1f °C / ",ReadingsVal("SDS011","temperature",0)).sprintf("Hum: %.1f %%", ReadingsVal("SDS011","humidity",0))}
userattr reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex reading04Name reading04Regex reading05Name reading05Regex reading06Name reading06Regex reading07Name reading07Regex requestHeader stateFormat
verbose 1
Hallo,
was sagt denn die Webseite des Sensors, sind da Werte usw da ?
Die Regexe sind sehr komisch, die braucht man doch gar nicht ?
Ronny
Danke für die Hilfe. Ich habe es hinbekommen. Letztlich war es ein alter USB Treiber UND ein Kabelbruch.
Hat eigentlich jemand Schwellwerte für PM10 und PM2.5 ?
Wiki sagt PM10 sollte <50 und PM2.5<25 sein.
Ab wann macht ihre denn gelb=warn bzw. sogar rot = Feinstaubalarm ??
Grüße
Jörg
Schön dass du es hinbekommen hast. Trotzdem bleibt die Frage: Warum hast du lauter Attribute für den LuftdatenInfo gesetzt, die man eigentlich gar nicht für LuftdatenInfo setzen kann/darf?
Vor allem auch,
Die DEF zeigt eine Anbindung g über IP, wie kann da ein USB Treiber reinfunken?
Alles noch sehr verwirrend und nicht nachvollziehbar...
Gesendet von meinem S60 mit Tapatalk
Inzwischen gibt es eine "Erweiterung" zum Feinstaubsensor - den Lärmsensor: https://luftdaten.info/einfuehrung-zum-laermsensor/
In der offiziellen "Feinstaubsensor Firmware" ist der Lärmsensor schon integriert (Sensor-Option "DNMS (Leq, LAeq)"). Das "Messmikrofon" erfordert aber noch einen eigenen Mikrocontroller (Teensy).
Hat hier jemand schon den Lärmsensor nachgebaut (https://luftdaten.info/laermsensor-bauen/) ? Ich bin etwas verwirrt ob der verschiedenen Varianten und einer Bezugsquelle für das PCB, aber eine "fliegende Verdrahtung" müsste ja Dank Schaltplan auch funktionieren...
p.s. evtl. ist das ein Thema für einen eigenen Thread?
Zitat von: dkreutz am 19 Dezember 2019, 13:13:42
Inzwischen gibt es eine "Erweiterung" zum Feinstaubsensor - den Lärmsensor: https://luftdaten.info/einfuehrung-zum-laermsensor/
Jetzt fehlt noch ein Geigerzähler und dann wäre das Ding in meinen Augen komplett ;).
Gruß PeMue
Zitat von: dkreutz am 19 Dezember 2019, 13:13:42
Hat hier jemand schon den Lärmsensor nachgebaut (https://luftdaten.info/laermsensor-bauen/) ?
Ich hatte vor Tagen das Projekt auch gefunden und wollte es auch im Forum ansprechen. Nein, nicht nachgebaut: Ich kann sowas gar nicht, ich hoffe auf den freundlichen Menschen aus dem Forum, der mir auch schon den Feinstaubsensor zusammenbaute.
Zitat von: dkreutz am 19 Dezember 2019, 13:13:42
p.s. evtl. ist das ein Thema für einen eigenen Thread?
Ja, das muss auf alle Fälle ein eigener Thread werden. Auch deshalb, weil ja ein eigenes Modul schön wäre. Dies deutet sich schon deshalb an, weil auf der WebSite steht, dass einige Auswertungen bei denen, also quasi "in der Cloud" passieren - und das dürfte nicht allen schmecken ... allen voran mir.
Zitat von: PeMue am 19 Dezember 2019, 17:16:00
Jetzt fehlt noch ein Geigerzähler und dann wäre das Ding in meinen Augen komplett ;).
Auf alle Fälle.
Und mir fällt da noch mehr ein. Wir müssen lediglich aufpassen, dass wir nicht irgendwann zu den Preppern gezählt werden. ;)
OT: GeigerZähler gibt es doch den DIYGeiger, den hab ich laufen , tut sehr gut :)
Ich glaube, ich muss meinen Feinstaubsensor mal im Jahr 2020 erneuern mit neuen Sensoren, wenn ich mir das so anschaue :D
Ronny
Zitat von: curt am 19 Dezember 2019, 17:59:06
Ich hatte vor Tagen das Projekt auch gefunden und wollte es auch im Forum ansprechen. Nein, nicht nachgebaut: Ich kann sowas gar nicht, ich hoffe auf den freundlichen Menschen aus dem Forum, der mir auch schon den Feinstaubsensor zusammenbaute.
Ja, das muss auf alle Fälle ein eigener Thread werden. Auch deshalb, weil ja ein eigenes Modul schön wäre. Dies deutet sich schon deshalb an, weil auf der WebSite steht, dass einige Auswertungen bei denen, also quasi "in der Cloud" passieren - und das dürfte nicht allen schmecken ... allen voran mir.
Hier der neue Thread zum Lärmsensor: https://forum.fhem.de/index.php/topic,106519.0.html
Hallo,
für viele ist CLOUD ein Reizwort, auch ich hab das nicht so gerne. Bitte beachtet aber dabei, Cloud kann auch nur der Ort für Ihren Server sein. Alleine um die Karte zu erstellen müssen die Daten sammeln und verarbeiten.
Ich finde das mit dem Feinstaub eine gute Sache, hier auf dem Land stört aber maximal ein Trecker ;-)
Grüße Peter
Zitat von: Peteruser am 26 Dezember 2019, 00:13:23
für viele ist CLOUD ein Reizwort,
Nein. Es geht nicht um Gefühle.
Es geht um das demokratische Recht der Selbstbestimmung.
Wenn jemand seine Daten teilen will - das ist sein gutes Recht. Das ist darüber hinaus bei solchen Projekten löblich. - Ich selbst teile meine Daten nicht. Und das Schöne ist: Ich muss das nicht einmal begründen.
Zitat von: Peteruser am 26 Dezember 2019, 00:13:23
auch ich hab das nicht so gerne. Bitte beachtet aber dabei, Cloud kann auch nur der Ort für Ihren Server sein. Alleine um die Karte zu erstellen müssen die Daten sammeln und verarbeiten.
Ganz schwerer Denkfehler, mit Verlaub.
Es ist sehr löblich, dass es Menschen gibt, die diese Daten teilen und das damit diese Karte entsteht. Aber ich würde mit Dir wetten wollen: Die Masse derer, die einen Feinstaubsensor betreiben, teilen die Daten nicht.
Zitat von: Peteruser am 26 Dezember 2019, 00:13:23
Ich finde das mit dem Feinstaub eine gute Sache, hier auf dem Land stört aber maximal ein Trecker ;-)
Darf ich schüchtern fragen, ob Du selbst einen Feinstaubsensor betriebst?
Ich lebe auch auf dem Lande. Meine Messwerte zeigen Überschreitungen, da würde die DUH sofort ein Fahrverbot für Diesel auf der Dorfstraße erlassen. Das ist weit jenseits dessen, was offiziell an einer Stadtkreuzung gemessen wird. Die Gründe dafür kenne ich recht genau, sie haben gar nichts mit Verkehr zu tun, aber das führt im Moment zu weit.
Den Feinstaubsensor (mir ist bewusst, dass er nicht geeicht ist und der Aufstellort auch nicht) kaufte ich mir, damit mir niemand etwas vom Pferd erzählt. Ich will einfach aus ersten Hand etwas wissen. Ohne weitere Ziele, ohne zu eifern: Eiferer gibt es schon genug. Aber das nur nebenbei.
Ich wollte lediglich begründen, dass man für das Projekt Feinstaubsensor KEINE Cloud braucht, wenn man sie nicht möchte.
Frohe Weihnachten!
Hallo,
ob ich einen betreibe?
Wenn jemand keine Sensordaten weitergeben will, dann haben die Stuttgarter tollerweise sogar das möglich gemacht die Messungen zu machen!
....ich selbst teile meine Daten nicht. Und das Schöne ist: Ich muss das nicht einmal begründen....
Da sind wir einer Meinung, der Rest dürte von jemand ausserhalb der IT stammen.
JA, bei mir läuft einer seit einiger Zeit und auch ich kenne das Problem mit Feinstaub hier seit ich die Messwerte kenne.
Ich finde, das Thema läuft irgendwie aus dem Ruder.
Grüße Peter
Zitat von: rcmcronny am 19 Dezember 2019, 21:31:11
OT: GeigerZähler gibt es doch den DIYGeiger, den hab ich laufen , tut sehr gut :)
Wie hast du den Geigerzähler integriert?
Ich hab es über MQTT eingebunden und FHEM sendet die Daten dann weiter (an radmon aktuell), funktioniert 1a.
Zitat
defmod owntracks_radmon MQTT_DEVICE
attr owntracks_radmon IODev mosquitto
attr owntracks_radmon event-on-update-reading cpm,dose,rssi
attr owntracks_radmon qos at-least-once
attr owntracks_radmon room mqtt
attr owntracks_radmon stateFormat CPM: cpm / Dose: dose µSV / RSSI: rssi
attr owntracks_radmon subscribeReading_cpm radmon/1/feeds/cpm
attr owntracks_radmon subscribeReading_dose radmon/1/feeds/dose
attr owntracks_radmon subscribeReading_rssi radmon/1/feeds/rssi
attr owntracks_radmon verbose 0
Bei Bedarf kann ich das DOIF für Radmon auch noch posten (aber so richtig passt das ja nicht hier her :) )
Wir könnten einen eigenen Thread aufmachen.
Ich habe zwar einen anderen Geigerzaehler (MightyOhm.com Geiger Counter) im Einsatz, denn ich nur zum Testen bisher im Einsatz hatte, aber jetzt diesen auch für FHEM verwenden werde.
Ich denke das würde sicher noch einige mehr interessieren.
Zitat von: Burny4600 am 05 Januar 2020, 13:05:11
Wir könnten einen eigenen Thread aufmachen.
Das wäre sicherlich sinnvoll.
Edit: hier (https://forum.fhem.de/index.php/topic,107057.0.html) geht es weiter ...
Zitat von: Burny4600 am 05 Januar 2020, 13:05:11
Ich habe zwar einen anderen Geigerzaehler (MightyOhm.com Geiger Counter) im Einsatz, denn ich nur zum Testen bisher im Einsatz hatte, aber jetzt diesen auch für FHEM verwenden werde.
Ich habe mir Ende des Jahres mal die v1.1 die CAJOE beim freundlichen Chinesen geholt, den hat Andreas Spiess in einem seiner Videos beschrieben. Ansonsten gibt es in TÜ/FR einen Makerspace, die gerade einen bauen. sbiermann wird diesen vermutlich auf dem FHEM Treffen in KA vorstellen.
Zitat von: Burny4600 am 05 Januar 2020, 13:05:11
Ich denke das würde sicher noch einige mehr interessieren.
Davon gehe ich aus ;).
Gruß Peter
Hallo Zusammen,
ich hab es auch endlich mal hin bekommen, den Sensor zu bauen.
Als Gehäuse hab ich die Hensel Box Variante von Thingiverse genommen, hat mir am besten gefallen.
Als temp sensor nehm ich den BME280.
Dazu hab ich mal ne frage, ich hab hier immer wieder das Gefühl, egal wie oft ich den sensor bisher irgendwo eingebaut hab, dass dieser keine richtigen Messwerte anzeigt.
Kann das jemand bestätigen?
Dazu habe ich noch eine Frage ob jemand den sensor schon in Homebridge gebracht hat?
Eventuell hat jemand ja schon ein mapping?
Zu dem Lärm Sensor, hier hab ich auch schon drüber nachgedacht, diesen nachzubauen.
Nur ist es nicht einfach die Teile zu besorgen. Besonders die Platine muss man wohl selbst fertigen lassen.
Was für eine Platine defintiv keinen sinn macht.
Microphone auf dem Brakeout Board gibt es bei Tindie leider aktuell auch nicht zu kaufen.
Danke und Gruß Robert
Zitat von: no_Legend am 29 April 2020, 11:35:35
Zu dem Lärm Sensor, hier hab ich auch schon drüber nachgedacht, diesen nachzubauen.
Nur ist es nicht einfach die Teile zu besorgen. Besonders die Platine muss man wohl selbst fertigen lassen.
Was für eine Platine defintiv keinen sinn macht.
Microphone auf dem Brakeout Board gibt es bei Tindie leider aktuell auch nicht zu kaufen.
Die Platine benötigt man ja nicht zwingend, nur ist ein fliegender Aufbau oder Breadboard halt nicht so schick und kompakt.
Für den Lärmsensor gibt es eigenen eigenen Thread - da wird auch die Teilebeschaffung diskutiert: https://forum.fhem.de/index.php/topic,106519.0.html
Habt Ihr auch Probleme mit dem remote-Zugriff ?
Ich hab die Probleme seit knapp einer Woche(seit 11.12.; letztes Update ist 1-2 Monate her). FHEM bzw. den Rpi habe ich noch nicht rebootet(weil ich das so ungern mache; FHEM-uptime 36 Tage). Ich habe 3 verschiedene Sensoren getestet.
Das Log zeigt 2021.12.17 06:23:15 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_statusRequest
2021.12.17 06:23:15 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_GetHttpResponse
2021.12.17 06:23:15 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_GetHttpResponse
2021.12.17 06:23:16 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_ParseHttpResponse
2021.12.17 06:23:16 4: LuftdatenInfo (Feinstaub) - returned data: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /v1/sensor/4711/
on this server.<br />
</p>
</body></html>
2021.12.17 06:23:16 2: LuftdatenInfo (Feinstaub) - error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<!DOCTYPE HTML PUBLI...") at ./FHEM/59_LuftdatenInfo.pm line 316.
2021.12.17 06:23:16 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_ParseHttpResponse
2021.12.17 06:23:16 4: LuftdatenInfo (Feinstaub) - returned data: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /v1/sensor/18717/
on this server.<br />
</p>
</body></html>
2021.12.17 06:23:16 2: LuftdatenInfo (Feinstaub) - error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<!DOCTYPE HTML PUBLI...") at ./FHEM/59_LuftdatenInfo.pm line 316.
Die Meldung ist ja selbsterklärend. Aber wieso ist der Zugriff nicht mehr erlaubt ? :-\
Schuld ist ja erst einmal der Datenlieferant. ;D Wurde evtl. das API geändert ?
Grüße Markus
Zitat von: KölnSolar am 17 Dezember 2021, 07:00:28
Habt Ihr auch Probleme mit dem remote-Zugriff ?
Ich hab die Probleme seit knapp einer Woche(seit 11.12.; letztes Update ist 1-2 Monate her). FHEM bzw. den Rpi habe ich noch nicht rebootet(weil ich das so ungern mache; FHEM-uptime 36 Tage). Ich habe 3 verschiedene Sensoren getestet.
Das Log zeigt 2021.12.17 06:23:15 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_statusRequest
2021.12.17 06:23:15 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_GetHttpResponse
2021.12.17 06:23:15 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_GetHttpResponse
2021.12.17 06:23:16 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_ParseHttpResponse
2021.12.17 06:23:16 4: LuftdatenInfo (Feinstaub) - returned data: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /v1/sensor/4711/
on this server.<br />
</p>
</body></html>
2021.12.17 06:23:16 2: LuftdatenInfo (Feinstaub) - error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<!DOCTYPE HTML PUBLI...") at ./FHEM/59_LuftdatenInfo.pm line 316.
2021.12.17 06:23:16 5: LuftdatenInfo (Feinstaub) - entering LuftdatenInfo_ParseHttpResponse
2021.12.17 06:23:16 4: LuftdatenInfo (Feinstaub) - returned data: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /v1/sensor/18717/
on this server.<br />
</p>
</body></html>
2021.12.17 06:23:16 2: LuftdatenInfo (Feinstaub) - error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<!DOCTYPE HTML PUBLI...") at ./FHEM/59_LuftdatenInfo.pm line 316.
Die Meldung ist ja selbsterklärend. Aber wieso ist der Zugriff nicht mehr erlaubt ? :-\
Schuld ist ja erst einmal der Datenlieferant. ;D Wurde evtl. das API geändert ?
Grüße Markus
Rufst du einen eigenen Sensor ab oder einen Fremden?
Kann es sein, dass es den Sensor garnicht mehr gibt?
Grüße Robert
ZitatRufst du einen eigenen Sensor ab oder einen Fremden?
fremd. Aber vielleicht ist das ja nicht mehr erlaubt ? :-\
ZitatKann es sein, dass es den Sensor garnicht mehr gibt?
Lt. Map(Website) gibt es die und liefern auch Daten.
Moin,
ich rufe meinen eigenen ab und das geht nach wie vor problemlos.
Grüße
Frank
Hmmm... Klingt ja dann, als ob fremd nicht mehr ginge. Aber wir geben doch gar keine Berechtigungsdaten mit auf den Weg. Sprich bei "remote" ist es doch immer der externe Zugriff ohne weitere Berechtigungsdaten "fremd". Oder hab ich was übersehen.
Hast Du Deinen "remote" definiert ? Wenn nicht, könntest Du es mal zum Test ausprobieren ?
Grüße Markus
Edit: Mein anderer, "local" definierter, funktioniert auch einwandfrei. Hab den "remote" mal gelöscht und neu angelegt. Ändert nichts. :'(
Zitat von: KölnSolar am 17 Dezember 2021, 09:12:53
Hmmm... Klingt ja dann, als ob fremd nicht mehr ginge. Aber wir geben doch gar keine Berechtigungsdaten mit auf den Weg. Sprich bei "remote" ist es doch immer der externe Zugriff ohne weitere Berechtigungsdaten "fremd". Oder hab ich was übersehen.
Hast Du Deinen "remote" definiert ? Wenn nicht, könntest Du es mal zum Test ausprobieren ?
Grüße Markus
Edit: Mein anderer, "local" definierter, funktioniert auch einwandfrei. Hab den "remote" mal gelöscht und neu angelegt. Ändert nichts. :'(
Vielleicht hat sich ja auch was an deren API geändert.
Genau sagen kann ich es dir aber nicht, benutzte ja auch nur local.
Hast du mal geschaut, wann es angefangen hat Fehler zu werfen?
Nicht das es mit der aktuelle log4j Lücke eventuell zu tun hat.
Edit: Da fällt mir ein, die haben sich doch umbenannt.
Heißen seit längerem sensor.community.
Nicht das der Dienst einfach nur noch über die neue URL zu erreichen ist?
Edit2:
Es scheint wohl echt so zu sein.
Laut svn hat das Plugin die daten von api.luftdaten.info geholt.
Auf der neuen seite steht aber die API kann per https://api.sensor.community/v1/push-sensor-data/ abgefragt werden.
Du kannst ja mal lokal in dem Plugin 59_LuftdatenInfo.pm die ULR austauschen und mal probieren.
Alternativ könnte auch der Maintainer des Paketes die URLs anpassen.
Kann dir aber nicht sagen wer das ist. Beim Plugin im Quelltext steht igami
Grüße Robert
Dachte ich hätte ihn remote definiert, ist aber lokal.
Werde ich testen.
Ein blich auf die Homepage http://luftdaten.info sagt aber auch:
Luftdaten.info is now Sensor.Community.
Also evtl mal die Domain in der Definition anpassen?
Zitat von: Frank_Huber am 17 Dezember 2021, 09:45:49
Dachte ich hätte ihn remote definiert, ist aber lokal.
Werde ich testen.
Ein blich auf die Homepage http://luftdaten.info sagt aber auch:
Luftdaten.info is now Sensor.Community.
Also evtl mal die Domain in der Definition anpassen?
Genau so ist es, unsere antworten haben sich gerade überschnitten. :-)
Siehe Edit2 im Post davor.
ZitatAlso evtl mal die Domain in der Definition anpassen
Aber das macht doch das Modul(also nicht konfigurierbar :'( )
Ich gucke Mal im Testsystem u. ins Modul.
Zitat von: KölnSolar am 17 Dezember 2021, 18:38:00
Aber das macht doch das Modul(also nicht konfigurierbar :'( )
Ich gucke Mal im Testsystem u. ins Modul.
Du musst es in Quelltext des Moduls ändern.
Es gibt sozusagen die alte api nicht mehr.
Entweder muss es der maintainer ändern, einer der Developer mit ausreichend rechten oder du probierter es aus und sagst den jungs Bescheid was se ändern sollen.
Ganz so einfach war es nicht. Irgendwo hab ich gelesen http://data.sensor.community/airrohr/v1/sensor/4711/
Mit Zeile 286 $param->{url} = "http://data.sensor.community/airrohr/v1/sensor/$arg/" funktioniert es wieder. :)
Danke Euch für den Schubser. Baust Du es ein Igami ?
Danke & Grüße
Markus
Edit: oder geht doch nicht ? Wartet noch.....ich probiere es geduldiger ::)
edit2: https://data.sensor.community/airrohr/v1/sensor/4711/ geht. aber nicht immer. timeout mit bösen freezes. nicht zu gebrauchen.
http://data.sensor.community/airrohr/v1/sensor/4711/ geht. aber nicht immer. timeout ohne freezes.
https://data.sensor.community/v1/sensor/4711/ geht gar nicht. 404 - not found
Zitat von: KölnSolar am 17 Dezember 2021, 20:22:28
Baust Du es ein Igami ?
Ich schaue es mir nach Weihnachten an
wiki zur API: https://github.com/opendata-stuttgart/meta/wiki/APIs
Hallo,
gibt es hierzu was neues?
Mein LuftdatenInfo state steht weiterhin auf "error".
Danke Sven
Hat etwas gedauert, aber ist nun geändert.
Hallo,
Kann es sein das es noch Probleme mit JSON gibt?
Bekomme auch nur error
2022.01.30 18:18:32 2: LuftdatenInfo (Luft) - error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<!DOCTYPE HTML PUBLI...") at ./FHEM/59_LuftdatenInfo.pm line 316.
Hallo..
Habe auch ständig "error while request: read from https://.... timed out" im Logfile , liegt dies am remote ?
Bei mir funktioniert es, aber ich bekomme keine PM1 geliefert. In der Map ist PM1 sichtbar, siehe Bild.
Zitat von: kkoeniger am 20 Juli 2023, 16:06:25Bei mir funktioniert es, aber ich bekomme keine PM1 geliefert. In der Map ist PM1 sichtbar, siehe Bild.
was siehst denn auf der lokalen Webseite des Sensors?
http://<deine_Sensor_IP>/values
Mein Sensor ist nicht lokal angebunden. Es ist eine LORA-Airstation3, zB so sichtbar (https://api-rrd.madavi.de:3000/grafana/d-solo/000000004/single-sensor-view?orgId=1&panelId=2&var-node=82127&from=1689771274526&to=1689857674526&viewPanel=2) .
Defintion:
[code]define kkluftdaten LuftdatenInfo remote 82127
attr kkluftdaten alias von Luftdaten.at
attr kkluftdaten devStateStyle style="font-weight:bold;;;;color:red;;;;font-size:15px;;;;"
attr kkluftdaten group Klima
attr kkluftdaten icon feinstaub_pm10
attr kkluftdaten room Umwelt
attr kkluftdaten stateFormat PM-10 [$name:PM10] ug/m3 / PM-2.5 [$name:PM2.5] ug/m3<br><br>Luftfeuchte [$name:humidity] % / Temperatur [$name:temperature] °C<br>\
am/um [$name:PM10:t] Uhr
attr kkluftdaten verbose 0
# CFGFN
# DEF remote 82127
# FUUID 64b93a05-f33f-90bb-cef8-2912358efd3abc56
# INTERVAL 300
# MODE remote
# NAME kkluftdaten
# NR 84499
# SENSORIDS 82127
# STATE PM-10 11 ug/m3 / PM-2.5 11 ug/m3<br><br>Luftfeuchte 59.3 % / Temperatur 26.6 °C<br>
#am/um 2023-07-21 11:19:49 Uhr
# TIMEOUT 5
# TYPE LuftdatenInfo
# eventCount 251
# .attraggr:
# .attrminint:
# READINGS:
# 2023-07-21 11:19:49 PM10 11
# 2023-07-21 11:19:49 PM2.5 11
# 2023-07-21 11:19:49 humidity 59.3
# 2023-07-20 15:43:38 latitude 47.77714515000
# 2023-07-20 15:43:40 location 7202 Gemeinde Bad Sauerbrunn
# 2023-07-20 15:43:38 longitude 16.32962107938
# 2023-07-21 11:19:49 state active
# 2023-07-21 11:19:49 temperature 26.6
# hmccu:
#
setstate kkluftdaten PM-10 11 ug/m3 / PM-2.5 11 ug/m3<br><br>Luftfeuchte 59.3 % / Temperatur 26.6 °C<br>\
am/um 2023-07-21 11:19:49 Uhr
setstate kkluftdaten 2023-07-21 11:19:49 PM10 11
setstate kkluftdaten 2023-07-21 11:19:49 PM2.5 11
setstate kkluftdaten 2023-07-21 11:19:49 humidity 59.3
setstate kkluftdaten 2023-07-20 15:43:38 latitude 47.77714515000
setstate kkluftdaten 2023-07-20 15:43:40 location 7202 Gemeinde Bad Sauerbrunn
setstate kkluftdaten 2023-07-20 15:43:38 longitude 16.32962107938
setstate kkluftdaten 2023-07-21 11:19:49 state active
setstate kkluftdaten 2023-07-21 11:19:49 temperature 26.6
[/code]
Ich habe es jetzt mit ioBroker und von dort via MQTT gelöst --> funktioniert.
Falls noch jemand ne ganz andere Variante braucht, um Sensordaten an sensor.community zu senden, hab ich hier ein externes .sh script gebaut. Via httpmod erhielt ich nur 400er als Response und habs nicht gecheckt (Header/Body Syntax Problem?).
Da mir das auf den Geist gegangen ist, hab ich das mit curl in einem bash script gelöst, das von fhem oder Cronjob alle 5 Minuten getriggert wird.
Voraussetzung: telnet in fhem aktiveren (define telnetPort telnet 7072)
Ihr müsst euere Sensor-ID, Device- und Readingnamen noch anpassen.
/opt/fhem/scripts/sensorcommunity.sh:
#!/bin/bash
P1_VALUE=$(echo '{ReadingsVal("MQTT2_DVES_476DD4","SDS0X1_PM10","")}' | nc -q 1 localhost 7072)
P2_VALUE=$(echo '{ReadingsVal("MQTT2_DVES_476DD4","SDS0X1_PM2.5","")}' | nc -q 1 localhost 7072)
timestamp=$(date '+%Y-%m-%d %H:%M:%S')
curl -s -X POST "https://api.sensor.community/v1/push-sensor-data/" \
-H "Content-Type: application/json" \
-H "X-Pin: 1" \
-H "X-Sensor: esp8266-1234567" \
-d "{\"software_version\": \"Tasmota 13.3.0(sensors)\", \"sensordatavalues\": [{\"value_type\": \"P1\", \"value\": \"$P1_VALUE\"},{\"value_type\": \"P2\", \"value\": \"$P2_VALUE\"}]}" \
| echo "[$timestamp] Server response: $(cat -)" >> logfile.log
Es wird hier außerdem eine logfile.log angelegt mit der Antwort des Servers.
Fhem:
define send_data_to_sensor_community at +*00:05:00 {system("/opt/fhem/scripts/sensorcommunity.sh &")}
oder einen Cronjob (als fhem-user) anlegen mit crontab -e und folgender Zeile:
(Upload alle 5 Minuten)
*/5 * * * * /opt/fhem/scripts/sensorcommunity.sh
Hallo!
Als Feinstaubsensornutzer ist mir aufgefallen, dass seit ein paar Tagen ne neue Firmware drauf ist und die Taupunkttemperatur aufgeführt ist. Kann zwar berechnet werden, wenn ich mich richtig informiert habe, wenn der Sensor die Taupunkttemperatur aber über die Schnittstelle sendet, wäre es etwas bequemer. Wurde das Thema bereits angesprochen? Über die Suche habe ich jetzt nichts finden können, oder ich habe nur falsch gesucht.
Danke für die Info
VG Tom