IKEA VINDRIKTNING Raumluftsensor

Begonnen von juppzupp, 16 August 2021, 11:26:07

Vorheriges Thema - Nächstes Thema

juppzupp

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.


Christoph Morrison

#17
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.

juppzupp

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.

Christoph Morrison

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.

Pfriemler

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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

juppzupp

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.

sash.sc

Es scheint jetzt in der dev von tasmota die unterstützung für den sensor zu geben !
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Pfriemler

Seit 9.5.0.7, als UNRELEASED. Kann das hier jemand für einen WEMOS kompilieren? Ich leider nicht (Unordnung in den Bibs).
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

kaizo

Klar. hier eine Firmware für den Wemos D1 als *.bin

Gruß
Kai
FHEM 6.x  auf i3
1x Maplecun FS20, HM, 1x CUL f. WMbus
1x Arduino Nano für Lacrosse, 1x für Empfang WH1080,
1x Arduino Uno+Ethernet-Shield & Firmata für 1Wire
1x Raspberry Pi für Einbindung Junkers-Heizgerät mit HT3-Schnittstelle, div. Sonoff+EspEasy+Tasmota über MQTT

point3r

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.


Pfriemler

#26
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!!!

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Pfriemler

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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

point3r

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() { } :)

Pfriemler

#29
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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."