WIFFI-wz … der Wohnzimmersensor

[dondaik]

also hier "sieht" der sensor den rauch einer zigarette - klar kommt auf den abstand an - man muss ihn "eichen" und ggf am fenster anbringen.

[Homoran]

Wenn denn nun aber im Schlafzimmer die Luftqualität ungesund wird, da CO2 steigt, so erkennt der Wiffi das nicht? Spuckt der Luftgütesensor denn einen Wert aus, der das Fenster sinnvoll zum Öffnen bewegt?

Der Luftgütesensor ist ziemlich empfindlich.
Während des Lüftens auf 100% kalibriert, hat er nach wenigen Stunden beim Fernsehen schon bald einen Wert um die 50%. Nach längerem nicht-lüften, wie jetzt bei der Hitze geht er auch schon mal auf 30% runter. Nach 5-10 Minuten Lüften ist er wieder top.
Ich weiss nicht wie groß eure Schlafzimmer sind, und ob da schon mal jemand am CO2 erstickt ist, aber ab wann die Luft ungesund wird kann man zwar berechnen, kommt aber IMHO so schnell nicht vor.

Aber gerade an dieser Aufgabe liegt das Problem:
Fenster zu bis Luft schlecht wird
Jetzt Lüften!
Während des Lüftens wirft der Nachbar die Zigarre an.
Ich könnte wetten, dass der wiffi trotzdem weiter bessere Luft anzeigt, weil immer noch mehr gute Luft einströmt, als vorher drin war.

Nur meine persönliche Meinung. Habe keinen zigarrenrauchenden Nachbarn, und den wiffi im Wohnzimmer.

Gruß
Rainer

[klassisch]

So konfiguriere ich meinen BME280:....

Interessant. Welche Lib nutzt Du?
Mache gerade einige Experimente mit der BME280_t.
Aber da kann ich ich den Betriebsmode und die oversampling-Settings leider nicht erkennen. Ausser

Code: Alles auswählen

    write8(BME280_REGISTER_CONTROLHUMID, 0x03); // Set before CONTROL (DS 5.4.3)
    write8(BME280_REGISTER_CONTROL, 0x3F);

sehe ich da nichts.
Und ob die Lib auch immer alles richtig interpretiert weiß ich auch nicht.
Folgendes Bild:

Die blaue Linie zeigt einen HM Sensor recht nahe beim Haus, die schwarze den BME280 etwas weiter weg. Die Unterschiede der Absolutwerte sind nicht Gegenstand meines jetzigen Posts - die gab es auch mit den DHTs. Dazu komme ich evtl. später mal.
Was mich stört sind die Peaks, die interessanterweise immer ca. 1K nach unten gehen, immer eine Messperiode (10 Sekunden) lang.
Eine Reduktion der I2C, die ich irgendwann mal gestern Abend vorübergehend eingeführt habe, war ohne durchschlagenden Erfolg.
Eine Outlier suppression im Postprocessing ergont zwar wieder schöne Kurven, ist aber eher Flickwerk. Ein solides Generieren und Einlesen der Messwerte wäre das eigentliche Ziel.

[mape]

Aus dem Grund, dass es keine Lib gibt die den forced mode nutzt, verwende ich gar keine.
Ich verwende auch keine Filter weder im Chip noch hinterher. Ich Sample alle 2min. Was interessiert dich eine Temperatur alle 10sec?
Meiner Meinung nach unnötig.

[klassisch]

Vielen Dank, Markus, für die Antwort.
Respekt! Den BME händisch auslesen und alles selbst konvertieren übersteigt derzeit mein verfügbares Produkt aus Fähigkeit und investierbarer Zeit.
Der Dondaik hat mich auf diese Lib https://github.com/embeddedadventures/BME280 BME280_MOD_1022 hingewiesen. Die vermittelt den Eindruck, als sei sie an eine (wahrscheinlich ältere) Bosch Lib angelehnt. Jedenfalls finden sich dort etliche gleiche/ähnliche Bezeichnungen.
Und die funktioniert.
Wie ich gerade sehe, scheint sie aber auch ab und an solche spikes zu produzieren. Vielleicht doch der Sensor oder gar die Temp?
Ja, alle 2 min ein solider Meßwert müßte für die meisten Wetter- / Zimmertemp Anwendungen ausreichen. Früher hatt ich gar keinen und es ging auch. Aber seit ich welche habe, geht die Trockenhaltung im Keller besser.
Da ich derzeit WLAN und Batteriebetrieb für eine schwierige Kombination halte, betreibe ich die Dinger mit Netzteil. Und dann ist es praktisch egal, wie oft gemessen wird. Mit mehr Messungen kann man halt das Rauschen reduzieren. Das war bei den DHTs wohl stärker und da hat sich auch ein FIR-Filter "gelohnt".
Die Übertragung an die CCU erfolgt ohnehin nur bei "größeren" Änderungen (0.5K) oder mind. alle 10 min.
Vergleiche derzeit verschiedene Anbringungsorte und da ergibt sich ein deutlicher Unterschied, der die sonstigen messtechnischen Anstrenungen relativiert.

[funkleuchtturm]

Hier eine Info für die WIFFI-wz Gemeinde:
Es gibt ein neues Firmware-Update wiffi_wz_38 für den WIFFI-wz. Neben vielen Detailverbesserungen wurde die Ansteuerung des Temperatur- und Feuchtesensors DHT22 deutlich verbessert. Siehe dazu die Erläuterungen: http://homematic-forum.de/forum/viewtop ... 31&t=32514
Die aktuelle Firmware kann hier heruntergeladen werden : http://www.stall.biz/project/der-wiffi- ... mmersensor

[jossel]

Hallo Zusammen,

ich habe gestern meinen WIFFI mal auf die neue Neue Firmware „wiffi_wz_41“ geupdatet.
Hat auch wunderbar funktioniert.

Nun gibt es aber das Problem, das ich ihn nicht mehr ins Netzwerk bekomme.
Meine SSID hat ein Leerzeichen!
Ich bekomme es einfach nicht hin, die SSID mit Leerzeichen in den Wiffi zu schreiben. Er nimmt die SSID einfach nicht an.

Jemand eine Idee?

Gruß aus Leipzig
Thomas

[dondaik]

leerzeichen entfernen , ist eine, für mich, nicht übliche schreibweise. ansonsten es ggf mal mit dem "ersatzzeichen" versuchen glaube %20...
und den sensor fest im router eintragen, die MAC sollte ja bekannt sein..
ansonsten: mail an eugen ( er ist ja der ASP ) und downgraden

[funkleuchtturm]

Nun gibt es aber das Problem, das ich ihn nicht mehr ins Netzwerk bekomme.
Meine SSID hat ein Leerzeichen!

Hallo Thomas,
der Wiffi müßte das klaglos annehmen und automatisch anstelle des Leerzeichens ein Ersatzzeichen %20 einfügen, was dann auch so angezigt und abgespeichert wird. Vermutlich hast Du den Befehl nicht richtig eingegeben. Richtig ist:
192.168.4.1/?ssid:my ssid:
Abgespeichert wird dann als ssid: my%20ssid , womit eigentlich der Router klar kommen müßte.

... und sonst alles klar ??
Viele Grüße

[dondaik]

guten morgen... noch ein frühaufsteher.
auf den (regen)tag