FYI
ESP8266 "parasitär" an den raumluftsensor, daten dann über mqtt in fhem.
https://github.com/Hypfer/esp8266-vindriktning-particle-sensor
Hatte auch schon erwogen das zu berichten - läuft bei mir seit ein paar Tagen im gleichen Raum wie ein CO2-Sensor. Das Verhalten korreliert nur wenig mit der Raumluftbelastung. Ab morgen teste ich in der Hobbywerkstatt.
Ich werde das Averaging im Sketch noch etwas erweitern und mein fliegender Aufbau wird mit einem generischen ESP8266 mit 3,3V-Linearregler und Pegel-Spannungsteiler einziehen.
Noch geiler fände ich es, wenn Theo Arends Universalwaffe sich den Sensor einverleibt. Leider bin ich für einen entsprechenden Beitrag zu doof.
Ich habe den Sensor mit MQTT (nicht MQTT2) und mit expJSON eingebunden.
defmod IKEA_VIN1 MQTT_DEVICE
attr IKEA_VIN1 IODev myBroker
attr IKEA_VIN1 event-on-change-reading pm25,state
attr IKEA_VIN1 room Klima,Spielwiese
attr IKEA_VIN1 stateFormat Partikel 2,5 µm: [$name:pm25] µg/m³ ([$name:pm25:t])
attr IKEA_VIN1 subscribeReading_state esp8266-vindriktning-particle-sensor/VINDRIKTNING-499A3A/state
Edit: Für alle die doch nicht basteln wollen: Es kursiert das Gerücht, dass IKEA den Sensor in Bälde in einer neuen Version mit Tradfri-Kopplung anbietet. Natürlich wird der dann teurer sein als ein unsmarter mit angeflanschtem ESP...
Kommt halt darauf an, wie man Raumluftbelastung definiert.
Das Ding misst optisch Partikel.
Bei mir tut es das gut. Ich kann kochen, saugen, etc ablesen.
Der Lüfter ist mir zu laut. Auf GitHub hat der Ersteller diesen ja permanent auf 3.3V gelegt, ich habe einen 92 Ohm Widerstand in die Masse Leitung eingebracht.
Zitat von: juppzupp am 17 August 2021, 23:42:07
Kommt halt darauf an, wie man Raumluftbelastung definiert.
Das Ding misst optisch Partikel. Bei mir tut es das gut. Ich kann kochen, saugen, etc ablesen.
Dass er mich als Mensch atmend im Raum nicht erkennt, ist ja klar. Laufe ich durch den Raum oder bewege viel Papier, sieht man das schon. Aber er macht auch "Welle" (also anfallartig erhöhte Werte), wo es bei geschlossener Tür und Fenster und ohne Personen im Raum eigentlich nichts passieren dürfte. Oder aber ich habe doch Untermieter oder eine Fliege hat bei ihren nächtlichen Kunstflügen irgendwas aufgewirbelt.
edit: kurz nach fünf war definitiv keiner im Raum. Möglicherweise handelt es sich bei so etwas aber wirklich nur um einen einmaligen Sensor(auslese)ausrutscher(fehler), der natürlich auch durch das im Sketch durchgeführte Averaging schlägt. Ich habe schon einige solcher seltsamen Spikes gesehen.
Viele dieser Ausrutscher dürften gar nicht zu sehen sein, weil der Sensor weit häufiger als 10x in der Minute ausgelesen wird, aber nur der Mittelwert aus den letzten 5 Messungen alle 30 (!) Sekunden gesendet wird.
Ein Spike von 50 wie kurz nach fünf Uhr bei sonst 13 im Schnitt könnte ja durch einen einmaligen Sensor-Wert von knapp 200 erreicht sein.
Bin versucht, den Mittelwert mal über 20 Werte zu nehmen (Types.h Z5 und SerialCom.h Z37 und Z42, wenn ich es richtig gesehen habe). Vielleicht noch Ausrutscher auf einen bestimmten Wert begrenzen (z.B. das 2fache des letzten Sensorwertes) - das dämpft einzelne Ausrutscher gut, lässt aber dauerhafte Änderungen dennoch gut schnell durchkommen.
ZitatDer Lüfter ist mir zu laut.
Laut ist er eigentlich nicht, macht halt nur nervige Töne. 3 Meter weg im Büro und das dauerlaufende NAS im Hintergrund höre ich natürlich nichts mehr. Im Schlafzimmer könnte ich den nicht haben, aber da wäre ein Dauerlauf besser als das ständige Gejaule beim An- und Ausgehen. Über Mods diesbezüglich habe ich auch schon nachgedacht, aber mir ist vom Wirkprinzip her nicht klar, ob der Sensor den Durchzug während der Messungen braucht oder ob es tatsächlich nur um einen regelmäßigen Luftaustausch in der Messkammer geht (nach Würdigung aller Umstände gehe ich stark von letzterem aus, das Datenblatt sagt absolut nichts dazu und IKEA hat den Lüfter selbst angeflanscht). Schlecht wäre außerdem, wenn der reduzierte Luftstrom zu dauerhaften Ablagerungen führen würde.
Kurz nach 12 den Raum verlassen, kurz vor 8 wieder im Wohnzimmer. Ohne Spitzen über Nacht.
Zitat von: juppzupp am 16 August 2021, 11:26:07ESP8266 "parasitär" an den raumluftsensor, daten dann über mqtt
Könntest du dein Device als RAW definition posten? Bei mir wirds automatisch anders angelegt, und ich bekomme kein Reading zur Luftqualität :(
Ich hab's nicht angelegt, hat mqtt2 für mich gemacht.
defmod MQTT2_VINDRIKTNING_D29EED MQTT2_DEVICE VINDRIKTNING_D29EED
attr MQTT2_VINDRIKTNING_D29EED DbLogExclude wifi_ip,wifi_rssi,wifi_ssid
attr MQTT2_VINDRIKTNING_D29EED comment Green to Yellow and Yellow to Red in the Ikea firmware are at around 30 and 100μg/m³.
attr MQTT2_VINDRIKTNING_D29EED event-min-interval .*:300
attr MQTT2_VINDRIKTNING_D29EED event-on-change-reading .*
attr MQTT2_VINDRIKTNING_D29EED readingList VINDRIKTNING_D29EED:esp8266-vindriktning-particle-sensor/VINDRIKTNING-D29EED/status:.* status\
VINDRIKTNING_D29EED:homeassistant/sensor/esp8266-vindriktning-particle-sensor/VINDRIKTNING-D29EED_wifi/config:.* { json2nameValue($EVENT) }\
VINDRIKTNING_D29EED:homeassistant/sensor/esp8266-vindriktning-particle-sensor/VINDRIKTNING-D29EED_pm25/config:.* { json2nameValue($EVENT) }\
VINDRIKTNING_D29EED:esp8266-vindriktning-particle-sensor/VINDRIKTNING-D29EED/state:.* { json2nameValue($EVENT) }
attr MQTT2_VINDRIKTNING_D29EED room MQTT2_DEVICE
attr MQTT2_VINDRIKTNING_D29EED stateFormat pm25
setstate MQTT2_VINDRIKTNING_D29EED 0
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-15 16:32:06 IODev mqtt_server
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 availability_topic esp8266-vindriktning-particle-sensor/VINDRIKTNING-D29EED/status
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 device_identifiers_1 VINDRIKTNING-D29EED
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 device_manufacturer Ikea
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 device_model VINDRIKTNING
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 device_name VINDRIKTNING-D29EED
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 device_sw_version 2021.08.0
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 icon mdi:air-filter
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 json_attributes_template {"ssid": "{{value_json.wifi.ssid}}", "ip": "{{value_json.wifi.ip}}"}
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 json_attributes_topic esp8266-vindriktning-particle-sensor/VINDRIKTNING-D29EED/state
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 name VINDRIKTNING-D29EED PM 2.5
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 20:41:17 pm25 0
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 state_topic esp8266-vindriktning-particle-sensor/VINDRIKTNING-D29EED/state
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 status online
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 unique_id VINDRIKTNING-D29EED_pm25
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 unit_of_measurement μg/m³
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 17:57:50 value_template {{value_json.pm25}}
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 20:41:17 wifi_ip 192.168.0.129
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 20:41:17 wifi_rssi -57
setstate MQTT2_VINDRIKTNING_D29EED 2021-08-18 20:41:17 wifi_ssid fhem
Komisch. weder mit dem durch MQTT2 bei mir erstelltem Device, noch mit deiner Definition bekomme ich readings zu pm25 oder wifi. Habe auch deine .bin probiert als auch selbst kompiliert. Irgend eine Idee?
So wird es bei mir automatisch angelegt:
defmod MQTT2_VINDRIKTNING_DC3C2A MQTT2_DEVICE VINDRIKTNING_DC3C2A
attr MQTT2_VINDRIKTNING_DC3C2A readingList VINDRIKTNING_DC3C2A:esp8266-vindriktning-particle-sensor/VINDRIKTNING-DC3C2A/status:.* status\
VINDRIKTNING_DC3C2A:homeassistant/sensor/esp8266-vindriktning-particle-sensor/VINDRIKTNING-DC3C2A_wifi/config:.* { json2nameValue($EVENT, 'config_', $JSONMAP) }\
VINDRIKTNING_DC3C2A:homeassistant/sensor/esp8266-vindriktning-particle-sensor/VINDRIKTNING-DC3C2A_pm25/config:.* { json2nameValue($EVENT, 'config_', $JSONMAP) }
attr MQTT2_VINDRIKTNING_DC3C2A room MQTT2_DEVICE
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 IODev mqtt2_server
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_availability_topic esp8266-vindriktning-particle-sensor/VINDRIKTNING-DC3C2A/status
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_device_identifiers_1 VINDRIKTNING-DC3C2A
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_device_manufacturer Ikea
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_device_model VINDRIKTNING
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_device_name VINDRIKTNING-DC3C2A
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_device_sw_version 2021.08.0
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_icon mdi:air-filter
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_json_attributes_template {"ssid": "{{value_json.wifi.ssid}}", "ip": "{{value_json.wifi.ip}}"}
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_json_attributes_topic esp8266-vindriktning-particle-sensor/VINDRIKTNING-DC3C2A/state
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_name VINDRIKTNING-DC3C2A PM 2.5
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_state_topic esp8266-vindriktning-particle-sensor/VINDRIKTNING-DC3C2A/state
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_unique_id VINDRIKTNING-DC3C2A_pm25
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_unit_of_measurement μg/m³
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 config_value_template {{value_json.pm25}}
setstate MQTT2_VINDRIKTNING_DC3C2A 2021-08-18 21:08:59 status online
Kannst du noch an die serielle? Ich würde da schauen was die console ausspuckt. Verkabelung checken. D2 an einem WeMos.
Zitat von: juppzupp am 18 August 2021, 14:10:54
Kurz nach 12 den Raum verlassen, kurz vor 8 wieder im Wohnzimmer. Ohne Spitzen über Nacht.
Jetzt wird es putzig: Im Vorratskeller sind die Werte deutlich smoother.
Mir fällt noch auf, dass Du Werte um null hast. Bei mir geht unter 12 kaum was. Ich habe schon im Web gelesen, dass die Sensoren teils sehr unterschiedliche Werte liefern.
Heute ist mir ein neues WLAN in meinem Haus aufgefallen. Auf die Bezeichnung "ESP-499A3A" konnte ich mir erst keinen Reim machen. Fing übers Handy fand keine offenen Ports. Die MAC-Adresse taucht nicht in meiner Liste auf. Dienste wie dein-ip-check.de finden zu der Mac keinen Hersteller. Dann habe ich herausbekommen, dass die MAC bis auf die erste Ziffer identisch mit dem WEMOS am PM-Sensor ist. Und tatsächlich: sobald ich den ausstrome, ist das WLAN weg, und nach dem Einstromen sofort wieder da. Reproduzierbar. Dann fand ich heraus, dass die Zahl hinter ESP genau die hinter VINDRIKTNING im MQTT-Topic ist oder bei MQTT2 in der Def ist.
Was macht das Ding da? Einen Repeater?
Das hatte ich noch nie bei einem ESP-Sketch. Jemand ähnliche Erfahrungen gemacht?`juppzupp müsste ein SSID "ESP-D29EED" finden.
Mit diesem Sketch nicht, aber nem anderen. Könnte ein "Feature" des WiFi Manager sein.
Seltsam, seltsam. Der Wifi-Manager war in der Tat etwas zickig beim Einrichten.
edit: https://forum.arduino.cc/t/esp8266-broadcasting-unwanted-open-wifi-network/481543
Sehr bekanntes Problem. Werde die Lösung morgen probieren.
@ReviloEgros:
In der readingList von juppzupp gibt es einen Eintrag mehr:
VINDRIKTNING_D29EED:esp8266-vindriktning-particle-sensor/VINDRIKTNING-D29EED/state:.* { json2nameValue($EVENT) }
D29EED müsstest Du bei Dir durch DC3C2A ersetzen.
Ich weiß nicht, irgendwie war das mit dem alten MQTT einfacher ...
nochmal nachgemessen ...
Also gemessen wird in 33-Sekunden-Zyklen ingesamt 7x. Der Lüfter wird gestartet, läuft eine Weile, dann erfolgt eine Sensorabfrage, nach ~1s Abstand die 2., die 3.-7. nach jeweils rund ~2,2s. Nach 12 Sekunden sind die Messungen durch und es folgen 21 Sekunden Pause, in der der Lüfter zwischendurch ausgeht.
Etwas trickreich im Code, wird jeweils ein Mittelwert über 5 Werte gebildet und gesendet. Tatsächlich kommt so in einem 30-Sekunden-Rhythmus eigentlich immer - wenn auch knapp - ein neuer Mittelwert heraus (entweder alle in einer Ausleseperiode oder über eine Lüfterpause). So wie von mir gedacht kann man die Mittelwertbildung nicht beliebig verlängern, oder man arbeitet wirklich mit einem gleitenden Mittelwert, den man nach jedem Sensorwert neu berechnet und dann aber nur stichprobenartig alle 30 Sekunden publishet.
Nach dem Muster wäre es auch denkbar, dem Verhalten des Sensors zu folgen, z.B. kommende Messwerte in einen ausreichend großen Puffer zu lesen und nach dem Ausbleiben von Sensordaten (in der Lüfterpause) nach Timeout die Werte zu mitteln und zu publishen, dabei offensichtliche Ausreißer zu ignorieren. Dann Puffer löschen und auf neue Daten warten.
Mein Sensor lief seit gestern in einem anderen Raum praktisch den gleichen (Grundrausch-)Wert von 12-13, macht aber heute morgen kurz vor sechs (alles schlief, Raum fensterlos und Tür geschlossen) einen Sprung nach unten auf ~4 und bleibt dort weiter konstant. Uhrzeit von FHEM stimmt.
Muss man das verstehen?
Ich habe inzwischen auch einen (von dreien) am Start und eine Weile gegen einen PM2.5 von ELV (https://de.elv.com/elv-feinstaub-messgeraet-pm10-pm25-pm40-pm100-komplettbausatz-154618) (SPS30 von Sensiron) laufen lassen. Meine Einheit liefert konstant 3 µg mehr, als der SPS30 misst.
Also meiner hat auch nur morgens wenn wir den Raum betreten einen Messwert, sonst Null Null null. Ich werde den Lüfter Mal auf auf permanent 3.3v hängen.
und hier noch ein paar infos :
https://revspace.nl/VINDRIKTNING
https://threadreaderapp.com/thread/1415291684569632768.html
Ich habe mir eine Version gebaut, die
- keine HASS-Autoconfig mehr sendet (konfigurierbar)
- die übermittelten Daten besser struktiert
{
"bme280":{
"temperature":26.67,
"pressure":1007.412,
"altitude":80.87687,
"humidity":45.80566
},
"particle_sensor":{
"pm25":6
},
"wifi":{
"ssid":"MorrisonNetIoT",
"ip":"192.168.0.154",
"rssi":-48
}
}
- einen BME280 unterstützt (Temperatur, Luftfeuchte, Luftdruck)
https://github.com/christoph-morrison/esp8266-vindriktning-particle-sensor/tree/bme280
Werkelt seit gestern brav im Wohnzimmer.
So sieht meine FHEM-Dev dafür aus:
defmod house.groundfloor.livingroom.security.particle_sensor.furnace MQTT2_DEVICE
attr house.groundfloor.livingroom.security.particle_sensor.furnace userattr pm25_correction_value unit
attr house.groundfloor.livingroom.security.particle_sensor.furnace IODev general.interfaces.mqtt.local.0
attr house.groundfloor.livingroom.security.particle_sensor.furnace alias Feinstaubsensor am Kamin
attr house.groundfloor.livingroom.security.particle_sensor.furnace devStateIcon rssi_good:mdt-wifi-strength-3@42BC0A rssi_medium:mdt-wifi-strength-2@sandybrown \
rssi_bad:mdt-wifi-strength-1@E50005 rssi_check:mdt-wifi-strength-1-alert@gray\
device_alive:mdt-heart-pulse@42BC0A device_dead:mdt-skull-crossbones-outline@E50005
attr house.groundfloor.livingroom.security.particle_sensor.furnace event-on-change-reading particle_sensor_pm25,particle_sensor_pm25_adjusted,rssi_device,sensor_status,activity
attr house.groundfloor.livingroom.security.particle_sensor.furnace group Raumluftüberwachung
attr house.groundfloor.livingroom.security.particle_sensor.furnace icon feinstaub_pm25@black
attr house.groundfloor.livingroom.security.particle_sensor.furnace pm25_correction_value -2
attr house.groundfloor.livingroom.security.particle_sensor.furnace readingList hab/devices/sensors/environment/particle-sensor/3ABDDB/state:.+ { json2nameValue($EVENT) }\
hab/devices/sensors/environment/particle-sensor/3ABDDB/status:.+ sensor_status
attr house.groundfloor.livingroom.security.particle_sensor.furnace readingsWatcher 60,0,particle_sensor_pm25,particle_sensor_pm25_adjusted
attr house.groundfloor.livingroom.security.particle_sensor.furnace room EG->Wohnbereich->Sicherheit,EG->Wohnbereich
attr house.groundfloor.livingroom.security.particle_sensor.furnace stateFormat [$name:particle_sensor_pm25_adjusted] [$name:unit]\
[$name:activity_state]\
[$name:rssi_quality]
attr house.groundfloor.livingroom.security.particle_sensor.furnace unit μg/m³
attr house.groundfloor.livingroom.security.particle_sensor.furnace userReadings particle_sensor_pm25_adjusted:particle_sensor_pm25:.+ {\
return (\
::ReadingsNum($name, q(particle_sensor_pm25), 0) \
+ ::AttrVal($name, q(pm25_correction_value), 0)\
);;\
},\
rssi_device:wifi_rssi:.+ {\
return ::ReadingsVal($name, q(wifi_rssi), undef);;\
},
rssi_device benötige ich für eine Systemfunktion, die mir aus dem RSSI-Wert eine Gut-Mäßig-Schlecht-Einschätzung für ein dSI macht. readingsWatcher macht das gleiche für activity, die ich für eine Systemfunktion brauche, die mir ein activity_state-Reading generiert.
Durch den zusätzlichen Verbraucher, der BME280, hat sich übrigens die Messung leicht geändert und ich benötige nun einen Offset von -2 um an die Werte des besseren SPS30 zu kommen. Ich hatte den Vindriktning (übrigens schwedisch für Windrichtung) versehentlich mal mit nur etwa 4,9V versorgt und schon kamen zehnmal höhere Werte raus.
Leitungsaufnahme liegt mit BME280 bei peak 120mA, im "Leerlauf" bei etwa 80mA.
Ist ein Messwert von "0" überhaupt plausibel ?
Das ding erkennt wirklich immer nur morgens wenn wir den raum betreten einen spike.
heute morgen war die putzfrau da, und ich hätte erwartet den sauger "sehen" zu können. (hat ja letzte woche funktioniert)
oder ob ich es beim "testen" mit nebel (wert 1000) übertrieben habe ? oder ob das ding sich selber "kalibriert" ?
fragen über fragen.
Keiner der drei die ich aufgebaut habe, hat dauerhaft einen Wert von 0 gezeigt. Du solltest die Dinger mal an einen seriellen Monitor anschließen und gucken was der Sensor meldet. Zum Testen ob der Sensor überhaupt funktioniert benutze ich übrigens Rauchmeldertestspray.
Also ich hatte irgendwo mal einen Beitrag gelesen, wo auch jemand drei Sensoren mit gänzlich unterschiedlichen Werten hatte, und auch viel Nullen dabei. Mit dem seriellen Monitor am WEMOS mit dem Sketch bekommt man zumindest die einzelnen Werte (und nicht nur den Mittelwert) angezeigt, aber ich bezweifle, dass das zielführend ist. Aus den Sensorwerten direkt werde ich nicht schlau, ich durchblicke aktuell noch nicht mal die Gültigkeitsprüfung durch den Sketch.
Interessanter finde ich da eher Christophs Beobachtung mit der Spannungsabhängigkeit der Messung. Und lasse den Lüfter mal mit 5V laufen, das soll auch einen Unterschied machen.
Selbstkalibrierung hatte ich auch schon überlegt - anders kann ich mir den Sprung nach unten bei mir nicht vorstellen. Aktuell bleibt es bei 3-4, auch genau da wo ich zu Anfang 12-15 gemessen hatte.
Meine nächste Version mit der Mittelung über die Messzyklen des Originalboards ist fast fertig, aber zum Testen komme ich diese Woche nicht mehr.
Mein "Fazit" sofern man das so nennen kann, fällt ernüchternd aus.
Wir haben den raum um 745 betreten. keine änderung.
von 830-1030 war die putzfrau da, schätzungsweise war die mit sauger und allem pipapo so gegen 10 in dem raum.
die spitzen gegen 12 und 14 kann ich nicht erklären. keine menschen, keine haustiere.
Es scheint jetzt in der dev von tasmota die unterstützung für den sensor zu geben !
Seit 9.5.0.7, als UNRELEASED. Kann das hier jemand für einen WEMOS kompilieren? Ich leider nicht (Unordnung in den Bibs).
Klar. hier eine Firmware für den Wemos D1 als *.bin
Gruß
Kai
Zitat von: Pfriemler am 18 August 2021, 22:27:56
Seltsam, seltsam. Der Wifi-Manager war in der Tat etwas zickig beim Einrichten.
edit: https://forum.arduino.cc/t/esp8266-broadcasting-unwanted-open-wifi-network/481543
Sehr bekanntes Problem. Werde die Lösung morgen probieren.
Hatte ich auch schon einige Male, bei mir war die Lösung,
vor dem WiFi.begin() folgende Zeile zu ergänzen:
WiFi.mode(WIFI_STA); // standalone, can be WIFI_AP, WIFI_STA, or WIFI_AP_STA.
Zitat von: point3r am 04 September 2021, 19:23:23
Hatte ich auch schon einige Male, bei mir war die Lösung, vor dem WiFi.begin() folgende Zeile zu ergänzen:
WiFi.mode(WIFI_STA); // standalone, can be WIFI_AP, WIFI_STA, or WIFI_AP_STA.
Soweit so gut, aber wo zum Donnergrummel ist das Statement im Sketch? Ich finde es nicht. Vermutlich bin ich zu blöd dazu.
Zitat von: kaizo am 04 September 2021, 17:31:44
Klar. hier eine Firmware für den Wemos D1 als *.bin
Ge-ni-al. Geflasht, läuft, Sensor liefert Daten. Wie geil ist das denn?
VIELEN DANK!!!
Nachtrag: Den drei Werten der Tasmota-Sensorabfrage muss man nicht nachtrauern. Aus den beigefügten Plots ergibt sich zumindest eine eindeutige Korrelation zwischen den Werten für 1, 2.5 und 10 µm, ich habe die sehr unterschiedlichen Werte mal irgendwie normiert, was im Detail immer ähnliche Änderungen, aber längerfristig fließende Grundwerte offenbart.
Es reicht völlig, den PM2.5 zu beobachten.
Mein Sensor liefert nunmehr wieder höhere Werte und es sind auch einzelne Ausreißer wieder zu sehen. Die Werte ändern sich öfter in der Oberfläche, gemäß der "TelePeriod" der Tasmota-Software (default 300 Sekunden, hier auf 60 reduziert) werden aber nur gelegentlich Werte übertragen, bei denen ich aber keinerlei Mittelung vermute.
Auch hier haben die Wertänderungen gegen 7.30 Uhr und gegen Mittag gar nichts mit dem Geschehen im Raum zu tun. . Zwischen 19 und 20 Uhr habe ich im Raum Staub gesaugt. Nach 20 Uhr war niemand mehr im Raum. Ich verstehe nicht, warum es diese Sprünge gibt.
Werde es wohl doch nochmal mit der Mittelung und Limitierung von Ausreißern versuchen müssen.
Zitat von: Pfriemler am 05 September 2021, 15:50:38
Soweit so gut, aber wo zum Donnergrummel ist das Statement im Sketch? Ich finde es nicht. Vermutlich bin ich zu blöd dazu.
Glaube ich eher nicht - ist in der void Setup() { } :)
Zitat von: point3r am 07 September 2021, 19:42:54
Glaube ich eher nicht - ist in der void Setup() { } :)
Dann haben wir unterschiedliche Versionen. WIFI.begin wird hier offenbar versteckt über eine der Bibliotheken aufgerufen, es gibt nur ArduinoOTA.begin in setupOTAn und natürlich verstreute Serial.begin.
Ist aber für mich nur noch kosmetischer Natur: Erstens liefern Umschreibereien aus mir unbekannten Ursachen sinnlose Werte (rechnet schlicht falsch, vermutlich ein idiotischer Typ/Zuweisungsfehler) und funktionieren nicht wie gewünscht, zweitens greift der nach dem zwischenzeitlichen Tasmota auf dem gleichen Wemos geflashte Originalsketch (also ohne meine Mods) auf offenbar noch immer gespeicherte WLAN-Daten zurück, ohne sich allerdings mit dem MQTT-Server auf dem Raspi zu verbinden. (ESPtool meint zwar den Flash komplett zu löschen, tut das aber offenbar nicht). Ich kann also auch keine neuen Daten eingeben. Das ist der Punkt, an dem ich das Projekt dann beerdige.
Nutze auf einem inzwischen implantierten nackten ESP mit vorgeschaltetem 3,3-Längsregler und Spannungsteiler jetzt doch wieder Tasmota (ich vergaß schon wieder, wieviel Lötaufwand einem so ein Wemos abnimmt). Ausreißer hatte ich seither keine, die Werte sind irgendwie stabil.
Habe zudem noch einen übrigen DS18B20 installiert, der liefert aber konstant um 2-3 Grad zu hohe Werte, obwohl er im Zuluftstrom vor dem Partikelsensor hängt (egal ob vor dem Loch oder direkt hinter den Lüftungslöchern des Gehäuses) - offenbar wird das Gehäuseinnere trotz Lüfter doch nachhaltig wärmer, im Schnitt werden ja
nun ca 0,6 ca 0,3-0,4 Watt gezogen. Und jetzt zusammengebaut erscheint mir das Lüfterheulen wieder lauter, stört mich auch bei laufendem PC und Server drei Meter hinter mir. Hätte mir vorgestern fast noch einen zweiten gekauft (Berlin hat wieder welche), lasse ich jetzt wohl bleiben.
Hallo,
das Billigteil mit Bastelfaktor reizt zum Kauf und Hack.
Allerdings lese ich hier auch von nicht nachvollziehbaren Werten, bzw. Werten, die keine erwartete Korrelation zwischen Aktivität im Raum und Messwert zeigen. Hat sich schon eine Meinung herausgebildet, ob das Teil irgendwie als Schätzeisen wirklich taugt?
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 13 September 2021, 15:27:19
Allerdings lese ich hier auch von nicht nachvollziehbaren Werten, bzw. Werten, die keine erwartete Korrelation zwischen Aktivität im Raum und Messwert zeigen. Hat sich schon eine Meinung herausgebildet, ob das Teil irgendwie als Schätzeisen wirklich taugt?
Ich hab's oben schon geschrieben: Bei mir arbeiten die Teile nachvollziehbar. Grundrauschen am Tag, mit Testspray oder im Bad nach dem Duschen / beim Eindeodorieren meldet das Ding zuverlässig hohe Werte. Ich habs gegen einen besseren Sensor gebenchmarkt und da war mit einem Offset alles nachvollziehbar.
Mein Eindruck ist, dass die Werte viel davon abhängen, wie gut man man 5V hinbekommt. Meine Sensoren haben bei 4,9V schon durchgängig höhere Werte gemeldet. Auch nicht alle D1 sind gleich gut.
Zumindest ob sie mit 4,97 oder 5,14V (Messwerte meines USB-Messadapters, recht genau) versorgt werden scheint ihnen egal zu sein. Auch mein Sensor liefert inzwischen Grundrauschen ohne spontane Ausreißer seit Tagen, und die Werte scheinen mehr vom Aufstellort als vom Netzteil abzuhängen. Und tatsächlich werden Änderungen (Luftzug durch Personen oder Luftaustausch durch Lüften) deutlich angezeigt. Ich kauf mir wohl doch noch einen ;D.
edit: der zweite ist da. Läuft testweise über den WEMOS und am PC gespeist und liefert Werte zwischen 170 und 220. Spannung am Board ist 4,6 Volt. Umgesteckt auf USB-C, Netzteil: 4,97V, Messwert 11.
Das Ding ist sehr spannungsempfindlich!
Danke erstmal für die Antworten zur Qualität des Dings.
Spannungsthema: wir reden doch von der Spannung, die das Netzteil liefert, das an dem Ding angeschlossen wird. Der Sensor wird doch direkt aus dem Netzteil versorgt und der ESP8266, der die Messdaten abgreift und weiterverteilt, hängt da mit dran?
Was bedeutet Deine Aussage
ZitatAuch nicht alle D1 sind gleich gut.
in diesem Kontext, Christoph Morrison?
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 14 September 2021, 13:47:38
Spannungsthema: wir reden doch von der Spannung, die das Netzteil liefert, das an dem Ding angeschlossen wird. Der Sensor wird doch direkt aus dem Netzteil versorgt und der ESP8266, der die Messdaten abgreift und weiterverteilt, hängt da mit dran?
Genau.
Zitat von: Dr. Boris Neubert am 14 September 2021, 13:47:38
Was bedeutet Deine Aussage
in diesem Kontext, Christoph Morrison?
Kaum jemand hier, vermute ich, benutzt echte Lolin Wemos D1, sondern irgendwelche Klone. Da gibt es Hersteller/Chargen, bei denen z.B. am LDO gespart wurde, der aus den 5VCC 3V3 für den ESP macht. Das heißt nicht, dass er nicht drauf ist, sondern dass die Qualiät nicht gut ist und die Leistung des Chips eh schon kritisch ist und wenn man dann noch das Vindriktning-Board mit Lüfter dran hat, ein nicht so tolles Netzteil oder vielleicht ein schlechtes USB-C-Kabel, kann es am Ende dazu führen, dass man a) unplausibel hohe Werte bekommt oder b) der ESP8266 nicht mehr zuverlässig läuft.
Siehe z.B.
https://github.com/bbqkees/Wemos-the-Clone-Wars
Vor allem wenn man dann noch den Low-Noise-Mod macht, den Hypfer beschrieben hat, der den Lüfter aus dem 3V3-Rail des Wemos speist.
Danke, Christoph, die Erläuterungen zu den Klonen sind nicht nur hier beim Windrichtungsdings nützlich!
Beim nächsten Ikea-Besuch nehm ich mal ein Teil mit.