FHEM Forum

Hallo zusammen,

ich bin dabei einen Raum(-luft)sensor zu erstellen.

Motivation war/ist die Überwachung der Luftqualität / Raumtemp um mittelfristig eine zentrale Entlüftung zu steuern.

Stationärer Einsatz in mehreren Räumen, Netzbetrieb und Anbindung an fhem via Wifi. Der Sensor verfügt über ein Display sowie zwei farbige Siganl LEDs (Raumtemperatur; blau:zu kalt / grün ok / rot: zu warm - Luftqualität grün bis rot, gesteuert auch via Helligkeitssensor).

Erfasst und an fhem übertragen werden:
* Temperatur, Luftfeuchte (DHT22)
* CO2 ppm (Winsen MH-Z19, ~20€)
* VOC ppm (iAQ Core ND, ~25€)
* Helligkeit (2x GL5538)

Projektstand:
Die Firmware (Nodemcu vorerst die Sensoren und Display, ohne LUX und die LEDs) sowie die FHEM Module laufen, stabil, im Dauertestlauf auf einem Breadboard.

Ich habe ein passendes Gehäuse entworfen und gedruckt. Bilder und Schematic hänge ich an, für das das komplette Projekt lege ich ein git an.

Das Gehäuse inkl Halterung etc ist für gebräuchliche 7x5cm Lochrasterplatine entworfen.

Im nächsten Schritt würde ich jetzt die Schlatung auf Lochrasterplatinen übertragen und einsetzen. Wenn weitere user Interesse haben den Sensor aufzubauen,  könnte man eventuell eine Platine layouten und eine Sammelbestellung auslösen. Da würde ich mich sehr über Unterstützung (beim layouten) freuen (Gehäuse zum einpassen etc stelle ich gern zur Verfügung).

Sollte Interesse bestehen bitte hier melden.

herzliche Grüße
Joerg

29-01-2019 Schematics gelöscht, enthält einen Fehler und wird erneuert

Hallo,

finde ich spannend und ich würde auch unterstützen. Ich habe bereits 3 Eigenbau Sensoren mit Wemos Mini, MH-Z19, BME280 + OLED 1306 im Einsatz. MH-Z19 liefert gute Ergebnisse. BME280 + Wemos Mini muss entsprechend wg. Gehäuse-Temperaturentwicklung angepasst werden. Dafür hat der BME280 aber noch Luftdruck. Interessant wären auch der Vergleich der Werte zwischen MH-Z19, iAQ Core ND und dem CCS811 hinsichtlich Kosteneffizienz / Langzeitstabilität und Kalibrierung, Rekalibrierung.

Eine zentrale Lüftung steuere ich auch, allerdings mit zusätzlicher Überwachung der Umluft und Zuluft (Feinstaub, VOC, Co2, Temperatur, Luftfeuchte) - hier habe ich Siemens Sensoren im Einsatz. Aber auch die Raumluftsensoren tragen ihren Teil dazu bei.

Viele Grüße,
dmq

Hallo Joerg,

hört sich interessant an. Beim "Layouten" könnte ich etwas mitmischen.


Gruß

Papa Romeo

ZitatDHT22

Ich würde aus eigener Erfahrung auf einen anderen Sensor setzen. Das Datenblatt liest sich gut, aber ich habe es nichtmals geschaft 1 aus 10 Sensoren aus unterschiedlichsten Bezugsquellen zu finden, der nur annähernd und auf Dauer die korrekt Luftfeuchte gemessen hat. Dazu hatte ich mal einen Thread incl. Messkurven gestartet...

Alternativen wären mMn BME280, SHT3x, und vmtl. einige andere, die man aber aus verläßlichen Quellen in Deutschland oder Europa beziehen können sollte.

Zitat von: herrmannj am 21 Januar 2019, 00:24:44
Motivation war/ist die Überwachung der Luftqualität / Raumtemp um mittelfristig eine zentrale Entlüftung zu steuern.

Hallo Jörg,

das war auch die Motivation bei meinem Projekt: https://forum.fhem.de/index.php/topic,78619.435.html (https://forum.fhem.de/index.php/topic,78619.435.html)
Wir haben das Ganze schon mit dem Bosch-Sensor mit der LaCrosseGateway und RFM69-Nodes durchexerziert
und eigentlich dabei gute Erfahrungen gesammelt und der Sensor liefert ja alle erforderlichen Werte.
Genauso wie die CO2-Messung nicht einfach ein quasi "absoluter" Wert ist, wie z.B. Temperatur oder Lufdruck.
Sondern die Erfahrung zeigt, dass sich CO2 in der Vermischung mit Luft in etwa (in meiner Vorstellung) so manifestiert
wie Nebel im November. Bei hoher Durchmischung kleine Werte, nachts steigen dann die Werte an um dann wieder
durchmischt zu werden. Auch die Positionierung ist entscheidend, z.B. Nähe Heizung und ebenfalls die Sensor-Höhe im Raum.
CO2 ist ja ein inertes Gas, dh. ist schwierig Meßverfahrens-technisch  in Griff zu bekommen.
Den IAQcore hatte ich ebenfalls schon verwendet (https://forum.fhem.de/index.php/topic,60204.msg515657.html#msg515657) und Erfahrungen damit gesammelt.
Bei der Verwendung von NDIR CO2 Sensormodulen schreckt halt der rel. hohe Preis ab, macht aber Sinn, wenn man bereit ist das Geld auszugeben um rel. wenig Aufwand (BSEC)
zu treiben und nur eine serielle Abfrage, ohne großen Aufwand haben möchte (siehe aber auch die QY-BME680MCUV1-Module) ...

Wenn Du sowohl CO2 als auch VOC messen willst, ist das nicht redundant? Was ist, wenn die Werte nicht korrelieren?
Den DHT würde ich ebenfalls nicht empfehlen wollen: Habe bis zu 5 Stück im gleichen Raum im Einsatz und jeder  zeigt etwas anderes an (20..45%rH)  ;)

Lese aber gerne hier mit..  ;)

Grüße,
Jürgen

Wäre nicht vielleicht auch ein digitaler Lichtsensor am I2C Bus eleganter? Aka bht1750, tsl2561, ... Wie genau die eingestzten LDRs und der analoge Eingang des ESPs ist, habe ich allerdings noch nicht nachgesehen. Aus dem Bauch wäre mir digital lieber, wenn auch etwas mehr Aufwand.

Nichts desto trotz ein tolles Projekt, dass ich gerne begleiten würde.

Zitat von: dev0 am 21 Januar 2019, 09:54:57
Ich würde aus eigener Erfahrung auf einen anderen Sensor setzen. Das Datenblatt liest sich gut, aber ich habe es nichtmals geschaft 1 aus 10 Sensoren aus unterschiedlichsten Bezugsquellen zu finden, der nur annähernd und auf Dauer die korrekt Luftfeuchte gemessen hat. Dazu hatte ich mal einen Thread incl. Messkurven gestartet...

Alternativen wären mMn BME280, SHT3x, und vmtl. einige andere, die man aber aus verläßlichen Quellen in Deutschland oder Europa beziehen können sollte.

Ich hab im Haus 1wire Sensoren von tm3d verbaut. Modul 009 von hier: https://tm3d.de/shop/kategorien/module
liefert mittlerweile seit über 2 Jahren plausible Werte.

mit DHTs hab ich auch nur schlechte Erfahrungen.

schön, gibt ja doch einige Interessenten!

@Papa Romeo
sehr, sehr gern. Ich habe da keine Erfahrung und Du ersparst mir die Einarbeitung (plus Lehrgeld, fällt immer an  ;))! Thnx! Wenn Du mir eine pm mit Deiner Adresse schickst dann drucke und schicke ich Dir ein Gehäuse. Ansonsten, lets speak!

@Jürgen
klar, ich habe bei Euch viel mitgelesen  :)

Der IAQ Core (ergänzend zum Schaltplan ein "C", haben ja Dauerstrom ...) kostet zwar etwas mehr. Dafür ist das handling, auch Software seitig, halt super unkompliziert. Mein Eindruck, aus auch vielen anderen Quellen; der BME kostet weniger, dafür muss man eben viel mehr Sachen in der MCU machen welche der AMS gleich auf dem CHip macht. Und auf Jahre gerechnet existiert doch der Preisunterschied nicht mehr wirklich ...

ZitatWenn Du sowohl CO2 als auch VOC messen willst, ist das nicht redundant? Was ist, wenn die Werte nicht korrelieren?

Die korrelieren nicht!  :) Ich habe tatsächlich nur dem iaq angefangen (der misst nur VOC!) und schnell festgestellt dass das zwar witzig ist, in Wohnräumen aber zu kurz greift.  Da muss nur mal eben jemand frisch ein-parfümiert vorbeilaufen dann "explodieren" die Werte. Deswegen habe ich den MZ-Z19B nachträglich ergänzt - eben reinweg CO2. Jetzt hat man beide Werte und das funktioniert auch wirklich sehr gut. Wie man das dann weiter verarbeitet (Be- Entlüftungssteuerung etc) hängt sicher von vielen Faktoren ab und die Möglichkeiten sind ja dadurch gegeben.

In dem Zusammenhang ist auch interessant (der AMS und der BME liefern ja eCo2) den CO2 äquivalent zu betrachten. Ich habe irgendwo einen Aufsatz von einem AMS Ingenieur gefunden wo er das erklärt. Die haben einfach die VOC Werte genommen und auf den typischen CO2 Wertebereich skaliert (konstant  x ~3.61 beim AMS) um ein drop-in replacement für Lüftungsanlagen zu schaffen - ohne das die neu parametrisiert werden müssen.

Die beiden LDR habe ich eingeplant damit die beiden (Signal) Leuchtdioden ihre Helligkeit an die Umgebung anpassen können. Da würde ich jetzt nicht auf exakte Kalibrierung Wert legen. Macht in Innenräumen mMn eh nur bedingt Sinn. Oder? Das die Werte auch gleich an fhem gehen ist halt eher ein positiver Nebeneffekt.

Der DHT ist eine Baustelle, auch von den Libs her. Ich habe die Adafruit Lib angepasst (anpassen müssen) weil der hier und in vorhergehenden Projekten (bei mir) auch immer wieder Lesefehler bringt. Jetzt bin ich dem mal auf den Grund gegangen, das scheint auch durchaus bekannt zu sein. Mit Anpassungen an der Lib konnte ich die lesefehler jetzt allerdings von xx% auf 0,001% runtergringen. Ebenfalls in anderen Projekten hatte ich den DHT auf der Platine sitzen. Das führt aber zu Abweichungen bei der Genauigkeit weil sich das innen eben erwärmt. Hier habe ich den DHT jetzt per Kabelbrücke im Gehäuse abgesetzt (an die Außenwand). Wenn man den austauscht, dann müsste man das dann also auch nochmal mechanisch anpassen, sprich das Gehäuse verändern. Kennt jemand ein replacement das im housing identisch oder ähnlich ist ? Am besten nichts was auf der Platine platziert werden muss.

Das "Projekt Gesamtpaket" besteht ja auch nicht nur aus der Schaltung sondern auch aus dem Gehäuse sowie den passenden fhem modulen. Das Gehäuse hat einige Iterationen  ;) erfordert. Jetzt passen das eigentlich ganz gut. Paltinenhalterung, Displayhalterung (abweichen zum Schaltplan natürlich i2c), LED einpassungen, Gehäusedurchbrüche, Belüftung usw. Eine offene Baustelle gibt es da allerdings noch: ich hatte geplant vorne (vor das Display) eine dunkle Plexiglas scheibe zu setzen. Die sind scheinbar aber extrem schwer zu beschaffen. Die ganzen "Zuschneider" liefern alle nur >5cm Kantenlänge. Viel zu groß, 70x15mm wären ideal. Vielleicht hat jemand eine Idee ob man da was anderes mißbrauchen kann. Ansonsten ist das Gehäuse aber auch so ok. Die Scheibe wäre halt noch so das I Tüpfelchen (das Auge der Frau schaut ja auch drauf ;)).

Jut, dann teste ich mal wie sich die LDR verhalten (evtl sind dann schon alle damit zufrieden). Mal schauen was wir mit dem DHT machen. Ich hänge gleich noch die stl für das Gehäuse an den post und sammle dann mal alles für ein GIT zusammen. Wie gesagt, ist jetzt schon alles stabil lauffähig, sogar für produktiv Einsatz ready, halt noch ohne LEDs und LDR.

@Papa: many Thanks !!! Freut mich "ganz sehr"! Sag bitte was ich tun kann  :)

vg
Joerg

Hallo Joerg,

Zitat
Das "Projekt Gesamtpaket" besteht ja auch nicht nur aus der Schaltung sondern auch aus dem Gehäuse sowie den passenden fhem modulen

Das passt schon.  :D

Bin auch noch am grübeln, wie ich das Gehäuse am Besten hinbekomme, auch um das USB-Kabel besser zu führen.
Zur Zeit baue ich auch den ESP8266-Part der TFT-Software  auf, das ist einfacher wie mit dem Maple ... aber bevor ich nicht mit der SW fertig bin,
muss ich auch noch warten ....

Was mich interessieren würde, wäre der FHEM-Anteil, über MQTT- oder KV-Protokoll?

Grüße,
Jürgen

Moin,
das ist genau das was ich auch noch bauen wollte :-)
Ich habe zur Zeit einen Wemos D1 mini mit Mh-z19 hier auf dem Schreibtisch laufen und will da noch einen GY-49 MAX44009 Umgebungs Licht Sensor mit drauf haben und einen Si7021 oder ein BME280 mit OLED oder TFT Display.

Werde hier mal weiter mitlesen.

ZitatDie korrelieren nicht!  :) Ich habe tatsächlich nur dem iaq angefangen (der misst nur VOC!) und schnell festgestellt dass das zwar witzig ist, in Wohnräumen aber zu kurz greift.  Da muss nur mal eben jemand frisch ein-parfümiert vorbeilaufen dann "explodieren" die Werte. Deswegen habe ich den MZ-Z19B nachträglich ergänzt - eben reinweg CO2. Jetzt hat man beide Werte und das funktioniert auch wirklich sehr gut. Wie man das dann weiter verarbeitet (Be- Entlüftungssteuerung etc) hängt sicher von vielen Faktoren ab und die Möglichkeiten sind ja dadurch gegeben.

Die Erfahrung kann ich 1:1 bestätigen.

Ich habe bei meinem Sensor bisher Standard Gehäuse missbraucht - da ich zu dem Zeitpunkt noch keinen 3D-Drucker besaß.

Das Gehäuse von Joerg gefällt mir sehr gut. Ein anderes (wie ich finde ziemlich gelungenes) Design was ich mir noch abgespeichert hatte ist das hier:

https://github.com/kumekay/kuhomon/blob/master/demo.jpg

Der (espressif Entwickler) hat in seinem Projekt folgendes verbaut:

CO2 Sensor MH-Z19
ESP8266 (NodeMCU ESP12+ based)
SSD1306 0.96" 128x64 i2c OLED. Library: https://github.com/olikraus/u8g2
Humidity/Temperature SI7021 i2c. Library: https://github.com/LowPowerLab/SI7021
Pressure/Temperature BMP085 i2c. Library: https://github.com/adafruit/Adafruit-BMP085-Library

Mehr (STL etc.) unter:
https://github.com/kumekay/kuhomon

Grüße,
dmq

git ist aufgesetzt: https://github.com/herrmannj/AirQuality/

Ich habe den LDR implementiert. Damit der funktioniert benötigt er einen R parallel A0/GND. Größenordnung 330Ohm (vmtl ist etwas größer noch passender). Achtung ich arbeite auf einem NodeMCU1.0, der hat bereits einen Spannungsteiler drauf. Die ESP sind ja am A0 alle etwas unterschiedlich.

Für den anvisierten Zweck scheinen mir die Daten mehr als ausreichend. Vielleicht ist "LUX" im topic etwas hoch gegriffen, es kommen halt wie beim HM-MSEc-Dir Werte raus - hier zwischen 0..1024. Die Kennlinie des LDR ist gut logarithmisch, ausreichend um also sowohl intern (LEDs, Display?) damit zu arbeiten und auch innerhalb von fhem Werte zu haben ob es im Zimmer dunkel oder hell ist. Wenn man jetzt noch etwas Mathe macht dann wäre es sicher möglich da die richtigen LUX rauszurechnen. Aber macht das Sinn ? Ist ja nicht mal eine Linse drauf ...

Hier kommt jetzt natürlich die Positionierung der LDR im Gehäuse massiv zum tragen. Eingeplant habe ich rechts und links. Vorne und oben wären sicher schöner. Dann hätte man dort allerdings den optisch unschönen Gehäuse Durchbruch.

...bezüglich dem "Layouten" wäre das auch einer meiner Fragen gewesen, wo sitzen bzw. wo müssen die Sensoren sitzen, die nach außen "schielen" sollen / müssen.

So ein grober Bauteile / Modul Lageplan wäre von Vorteil.

... ich lese hier mal mit. Falls noch Bedarf am Layouten ist, bitte um Info.

Gruß Peter

Moin Jörg,

ich möchte eine ähnliche Sensorkombination in eine freie UP-Dose integrieren.
Von daher sehe ich hier Synergien.

Ich könnte beim Layouten, beim Fertigen (ReflowOven) und bei der Firmware unterstützen.
Als Firmwarebasis kommt bei mir das gemeinsam mit Boris Neubert entwickelte OmniESP-Framwork zum Einsatz.
https://github.com/Pfannex/OmniESP/wiki (https://github.com/Pfannex/OmniESP/wiki)

Mit welcher Firmware wolltest du den ESP betreiben?
Eigenbau, ESPEasy?

Gruß
Pf@nne

Hi,

ich habe schon einige Zeit ein eigenes Framework für diy Sensoren. Soft/stl und fw: https://github.com/herrmannj/AirQuality


vg
Joerg

Zitat von: Papa Romeo am 22 Januar 2019, 17:53:28
...bezüglich dem "Layouten" wäre das auch einer meiner Fragen gewesen, wo sitzen bzw. wo müssen die Sensoren sitzen, die nach außen "schielen" sollen / müssen.

So ein grober Bauteile / Modul Lageplan wäre von Vorteil.

Ich hänge ein Bild an wie ich das für die Lochraster gedacht hatte. Das muss nicht das Ende sein, wenn Du das Layout machst siehst Du vielleicht Punkte an die ich nicht gedacht habe. Wenn wir bei den Maßen und Bohrungen der Lochrasterplatine bleiben dann hätte das sicher Vorteile: man kann das Gehäuse auch für andere Lochrasterprojekte "missbrauchen".

Zum Foto:
links unten der MH-Z19B. Der hat "horizontal" ein 2.54mm Raster, vertikal weicht er etwas ab.
Der iAQ Core C rechts daneben.
Unten der DHT mit Halterung, den wollte ich per Kabel (jst) anbinden damit er thermisch "außen" ist.
Display ebenfalls per Stecker.
LED (hier nur eine) wird direkt ins Gehäuse geklemmt. und eben auch per Stecker angebunden. Die LEDs sind ja ws2812, sprich von da ein Kabel zur anderen.
Mit der Halterung für die LDR (auf dem Bild links neben der LED) bin ich noch nicht zufrieden. Die wackelt da. Eventuell kann man die mit langen Beinen an der Kante der Platine festlöten und ich überarbeite die Halterung so dass man die besser einklemmen kann ? Dann muss man halt beim Zusammenbau darauf achten dass die Beine lang genug sind und die etwas biegen. Was denkt ihr ?

Auf dem noch freien Platz müsste man dann die 3 Pullups (i2c und DHT), den R für die LDR und die Vor-Diode für die LEDs platzieren. Ich würde da konventionelle (nicht SMD) nehmen, dann kann man so ein Ding mal eben zwischen Sport- und Tagesschau zusammenbauen. Aufrecht sollte doch genug Platz sein, oder?


Was hältst Du von der Idee den Stecker für den DHT so zu beschaltet das man per Drahtbrücke auch den I2C wahlweise da drauf bekommt?  Der ist ja wegen dem Display sowieso auf der Ecke. Dann könnte man wahlweise  auch einen I2C temp/hum Sensor nehmen.

Ich schick Dir gerne Gehäuse / Platine etc zu. Auch MH-Z19 und IAQ (wobei ich die dann gern zurück hätte)

vg
joerg

nachtrag:
ob die i2c pull-ups, der DHT pull-up und die Vordiode da sind oder nicht macht bei mir auf dem Steckbrett Null Unterschied. Aber "mit" sind es eben die specs der Datenblätter.

ok...ist mal ein Anhalt.

Schaltplan:   Du hast einmal +5  Volt und dann noch Vcc gezeichnet. Auf Grund der Pullup wird Vcc mit 3,3 Volt gleichzusetzen sein.
                     Aber wo kommen die +5 Volt her?

Ich hab bisher meistens mit den WEMOS gearbeitet und die stellen einmal die + 5 Volt (USB) und dann noch die 3,3 Volt zu Verfügung...
vermiss ich hier....Zeichenfehler ?

Mit, auf SMD verzichten, gehe ich konform.

ist beim nodemcu genauso, 5v und 3.3v. Die 5v kommen am pin 30 des NodeMCu raus wenn man den via usb oder einem USB Netzteil versorgt. Der MH-Z19B hätte gern 5V. Die LEDs https://cdn.boxtec.ch/pub/diverse/P9823.pdf hätten gern 4.5 bis 6.5V und nehmen HIGH als >0.7xVDD.
Bei 5v - 0.6V = 4.4V * 0,7V landet man bei ~3.1V für HIGH. Wobei die nicht sonderlich empfindlich sind, geht auch ohne. Da mag es aber Exemplarstreuungen geben.

Wenn Du die LDR an die Platinenkante legst spart man den vierten Stecker.

vg
Joerg

Überrascht mich übrigens das sich doch so einige mit dem Thema beschäftigen. Hätte das jetzt eher für ein "exotisches" Topic gehalten zumal es ja auch schon Projekt gibt. Schön.

Ich habe, btw, keine Erfahrung mit dem Wemos. Wenn der irgendwie besser geeignet sein sollte und die IOs reichen kann man den auch nehmen. Nodemcu ist halt das was bei mir "rumlag" ...

ZitatIch habe, btw, keine Erfahrung mit dem Wemos. Wenn der irgendwie besser geeignet sein sollte und die IOs reichen kann man den auch nehmen. Nodemcu ist halt das was bei mir "rumlag" ...

Ist stabil, preislich attraktiv und gut ein Stück kleiner. Weiterhin gibt es auch eine Pro Variante mit U.FL Konnektor (wenn es dann doch mal weiter wird) und mehr Kapazität(en).

Joerg, danke für die Info. Wenn ich schon dabei bin, dann werde ich auch gleich ein Layout für den Wemos erstellen, da ich mit diesen Modulen bisher gute Erfahrungen gemacht habe. Auch die Option mit der absetzbaren Antenne, wie dmq schon schreibt, ist in Bezug auf Reichweite manchmal doch ganz gut.

Da der Kelch mit dem Platinenlayout dankenswerterweise an mir vorbeigeht würde ich in der Zeit eine FW für den Wemos erstellen.

Welchen nimmt man da? Beim Nodemcu sind nicht alle IO Pins für alles geeignet. Gibt es beim Wemos ähnliche Einschränkungen ?

ZitatWelchen nimmt man da?

Im Grunde passt für die Anforderung der Wemos D1 Mini.

https://wiki.wemos.cc/products:d1:d1_mini

Neben dem gibt es auch noch den Wemos D1 Mini Pro. Der ist von den PINs und der Größe identisch.

Folgende Unterschiede existieren:

WiFi 802.11 b/g/n module based on ESP8266EX with [b]16 MB flash, chip antenna and external antenna connector[/b]
External antenna connector – switch by re-soldering resistor 0(zero) ohm
Built-in ceramic antenna – good!
New CP2104 USB-TO-UART IC – why? more stable?
Same size as D1 mini, but more light (3.9g -> 2.5g) – for flying devices?

Quelle: https://www.cnx-software.com/2016/09/05/5-wemos-d1-mini-pro-esp8266-board-includes-16mb-flash/

Aufpassen: hier scheint es mittlerweile auch eine neue Version zu geben, die nicht zu der Größe etc. passt. Der "alte" ist aber überall noch verfügbar.

ZitatBeim Nodemcu sind nicht alle IO Pins für alles geeignet. Gibt es beim Wemos ähnliche Einschränkungen ?

Mir sind keine Einschränkungen bekannt - das PIN-Layout muss halt beachtet werden:

https://wiki.wemos.cc/products:d1:d1_mini

..was beim WEMOS  zu beachten ist, die GPIO´s 0,1,und 2 sollten beim Starten HIGH-Signal haben, damit der Boot-Vorgang richtig abläuft.

ich habe eine Lochrasterplatine bestückt und in Betrieb genommen.


MH-19 und AIQ: obwohl beide noch nicht mal vollständig eingebrannt sind funktionieren die perfekt. Natürlich kann ich das mangels Labor nicht gegenprüfen aber die Werte sind absolut plausibel auch der Messwerte Verlauf (Co2 und tvoc) entsprechen genau den Erwartungen.
LDR: Erstmal nur einer. Ich habe hier einen 1k zwischen A0 und Masse geschaltet (Breadboard 330ohm) der scheint etwas zu hoch. Bei 330 sind die Readings unterhalb Kerzenlicht fast 0, bei 1k ist das min 9 (allerdinsg immernoch etwas Restlicht). Alles in allem aber mehr als ok.

Die ganzen Kabelbrücken sind schon ein gefriemel. Gut, macht man ja auch nicht tagtäglich. Ich habe mich aber gefragt, und würde das direkt an die Leiterplatten Experten weitergeben, ob es nicht Sinn könnte hinter dem Display eine 2te Leiterplatte zu nehmen. Das könnten die LEDs (links/rechts) liegend drauf, die beiden LDRs dahinter, Display per Pfosten. Dann hat man nur noch ein Kabel (ca 8 Adern) zur "Hauptplatine" ? Klar, etwas mehr Aufwand beim Zusammenbau aber vmtl schon deutlich schöner. Preis (absolut) für 1 oder 2 bei einer Sammelbestellung ist vmtl nicht so gravierenend (?)

Wemos: der Wemos hat eigentlich ein IO zu wenig. Aber, und da kommt Haken aktuell:

Obwohl ich den DHT echt schon ganz weit vom ESp weggesetzt habe, eine Trennwand zwischen dem und dem Rest, direkt an der Gehäuseöffnung. Er zeigt trotzdem ca 2-3° zuviel an. Ich habe erst gedacht dass ich da eins der schwarzen Schafe erwischt habe. Also ich dann aber mit einem IR Thermometer nachgemessen habe: nee stimmt. Obwohl in dem Gehäuse echt gut Luft ist und die Beuteile jetzt alle auch keine Leistungsbauteile sind, reicht das um einige Grad Steigung (echt nicht viel) zu verursachen. Der DHT erwärmt sich dann von hinten, eben 2-3°, trotz der Trennwand und das reicht ... :(

Da bin ich jetzt noch ein wenig unschlüssig was man da jetzt macht. Mathematisch korreigieren bin ich mir nicht sicher und b) finde ich das auch unseriös. Weil der DHT ja soweiso nicht so viele Freunde hat: ich würde den jetzt Testweise mal gegen sowas austauschen (ok?): BME280 Breakout i2c: https://www.amazon.de/AZDelivery-GY-BME280-Barometrischer-Temperatur-Luftfeuchtigkeit/dp/B07HMQMW6M/ref=sr_1_1_sspa?ie=UTF8&qid=1548334128&sr=8-1-spons&keywords=bme280%2Bi2c&th=1

Ich hoffe das man den dann besser positionieren kann, der Chip ist ja mini und die Lüftungsschlitze im Gehäuse sind jeweils 5x5mm.

Dann könnte man auch direkt auf Wemos D1 mini umsatteln - der DHT bin entfällt ja dann.

git:
bisher waren ja verschiedene Module für Temp/hum , co2, tvo etc notwendig, ich habe da gestern eines draus gemacht.

Man benötigt 00_SLink.pm und 10_SLinkIAQ.pm. SLink installieren einziger Parameter ist die IP des _fhem_ Servers. Sensor starten, der macht einen AP mit ESP... auf, SSID und Schlüssel eingeben (mit timeout). Das wars. Den Rest macht autocreate. Wer spielen möchte aber nicht alle Peripherals hat: sollte eigentlich trotzdem laufen. Also MH-Z19 und NodeMCU auf einem breadboard sollten zb reichen um zumindest co2 zu bekommen.

vg
Joerg

Hallo Jörg,

Zitat#include "iAQcore.h"

hast Du dafür die Quelle?

Hab hier auch noch einen Weiteren zu einer Bestimmung zu überführen ...  ;)

Grüße,
Jürgen

Hallo Jörg,

ich hab mit dem "Layouten" angefangen und da ich, wie schon gesagt mehr auf den WEMOS "steh", hab ich mit Diesem angefangen. Damit du in deinem Programm in Bezug auf die GPIO´s nicht`s ändern musst, hab ich die GPIO´s beim WEMOS genau so belegt, wie du beim NODEMCU und ich wundere mich jetzt über deine Aussage, dass der WEMOS einen GPIO zu wenig hätte........

Bezüglich Wärmeproblem. Könnte man nicht in das Gehäuse eine Bucht machen und den DHT komplett nach Außen in diese Gehäuse-Bucht verlegen.

Zweite Platine: Hab ich mir auch schon überlegt, aber dann nicht mit Kabeln, sondern mit Pfostenstecker auf die Hauptplatine stecken.

Ich sollte auch noch mal die maximale Größe der Platine haben, die ins Gehäuse passen würde.

Könnte man die ganzen Module nicht über Pfostenbuchsen auf die Hauptplatine stecken. Würde die Gehäuse-Höhe dies hergeben.

Im Anhang mal das bisherige Layout ( ist noch nicht ganz fertig....LED´s fehlen noch))

Zitat von: juergs am 24 Januar 2019, 17:56:24
Hallo Jörg,hast Du dafür die Quelle?

Hab hier auch noch einen Weiteren zu einer Bestimmung zu überführen ...  ;)

Grüße,
Jürgen

https://github.com/maarten-pennings/iAQcore

vg
Joerg

Hallo Papa Romeo,

das sieht doch schon amtlich aus. Bei den Wemos Pins habe ich hier geschaut http://stefanfrings.de/esp8266/#wemosd1mini und ann an D1/2/5/6/7 gedacht, also 5. MH-z19: 2, IAQ-C: 2, DHT: 1, LEDs: 1 = 6. Wenn man jetzt den DHT durch den BME am i2c ersetzt würde das imho genau aufgehen.

Bucht und DHT: naja, "isoliert" ist der ja schon (ein wenig). Wenn man den jetzt komplett draußen dran schraubt. Kann man machen - aber sieht dann halt Kacke aus ;) Vielleicht bringen die BME280 da ja was.

Das Gehäuse hat jetzt 90x60x30, die Höhe  wird maßgeblich übers Display diktiert. Jetzt sitzen die auf Pfosten gelötet, da noch Buchsenleiste drunter sollte schon jetzt passen aber viel Luft drum ist bestimmt für die beiden Luftsensoren gut.

Lass Dich aber mal von den jetzigen Maßen nicht einschränken - das muss ja nicht so bleiben. Lass mal so machen wie es sinnvoll ist. Wenn ich das Gehäuse nochmal anpassen muss, dann ist das so und dann ist das ok!

Platine vorne mit Pfostenstecken ist eine super Idee ! Links/Rechts die LEDs, liegend auf der Platine und die LDRs auf der Rückseite dann spart man sich da beim Aufbau das ganze gefriemel.

Wenn niemand was besseres kennt würde ich die oben verlinkten BME boards mal bestellen und schauen wie es damit ausssieht. Dann würde der DHT sowieso rausfliegen ...

vg
Joerg

Achso, die verlinkte Quelle schreibt das der Spannungswandler wohl beim Wemos eher knapp bemessen ist. Max 50mA sollen wohl gehen. Ich interpretiere das für die 3.3v - da wären der IAQ (20mA) das Display und der BME. (MH-Z19 und LED hängen ja an 5V).

Ist das echt so knapp ? Mit Display und BME sind die weg. Wenn der den 5V meint dann wären wir sicher drüber.

ZitatWenn niemand was besseres kennt würde ich die oben verlinkten BME boards mal bestellen und schauen wie es damit ausssieht. Dann würde der DHT sowieso rausfliegen ...

Ich habe es leider auch nicht wirklich besser mit dem BME280 hinbekommen :( Habe Anpassungen in der Software gemacht. Insgesamt ist es aber der bessere Sensor.

Das Hauptproblem ist die doch beachtliche Abwärme welcher der ESP8266 generiert.

... Strom wäre kein Problem...könnte wie bei meinen Projekten einen AMS1117 auf der Lötseite unterbringen....könnt ich eigentlich gleich mal vorsehen und  z.B. ne Auswahl über nen Jumper möglich machen.

...ich komm beim WEMOS auch auf 6 GPIO´s die nutzbar sind. Muss ja eigentlich auch sein. Auf beiden sitzt ein ESP8266, der die Anzahl der I/O´s. vorgibt.

naja, wenn der DHT ersetzt wird dann ist es eh keine Frage mehr. Die IOs können wir, btw auch umbelegen wenn das irgendwo notwendig ist. Wirf doch den DHT gleich raus, hat eh keine Fanbase :)

Zitat von: dmq am 24 Januar 2019, 19:23:04
Ich habe es leider auch nicht wirklich besser mit dem BME280 hinbekommen :( Habe Anpassungen in der Software gemacht. Insgesamt ist es aber der bessere Sensor.

Das Hauptproblem ist die doch beachtliche Abwärme welcher der ESP8266 generiert.

Ja, und die anderen Sensoren machen halt auch bischen was. Ist echt nicht viel, reicht aber.

Trotzdem, es gibt immer eine Lösung! Manchmal muss man halt suchen. Die Platine von Papa ist ja offensichtlich kleiner als meine, also vielleicht doch ne Bucht. An der Rückseite vielleicht. Mal schauen wie das ist wenn der BME im Gehäuse dranhängt ...

Wenn die Stecker und die LDRs auf der Platine wegfallen wegen Front und Pfostenstecker dann ist die vmtl sogar erheblich kleiner als meine jetzige. Da wird sich schon ein luftiges Plätzchen für den BME finden. Tschaka!  ;)

ZitatTrotzdem, es gibt immer eine Lösung! Manchmal muss man halt suchen. Die Platine von Papa ist ja offensichtlich kleiner als meine, also vielleicht doch ne Bucht. An der Rückseite vielleicht. Mal schauen wie das ist wenn der BME im Gehäuse dranhängt ...

Ja, ich finde die Idee mit der Bucht gut. Einen Versuch ist es wert!

ok...dann schmeiß ich die DHT- und die Reserve I2C- Buchse raus, such mir das Datenblatt vom BME und schau mal wie ich dann den integriert bekomme.

 der ist i2c und muss vmtl sowieso abgesetzt montiert werden, also am Kabel. Da hast Du die i2c genau richtig gesetzt, das passt so

Wie  hast du dir das gedacht mit "den LDR´s auf der Rückseite". Sollten die nicht auch nach Außen schielen.  ::)

Der Vorschlag wurde ja schon gemacht, die ldr durch einen echten Lichtsensor (MAX44009/bht1750/tsl2561) zu ersetzen.
Ansonsten finde ich das schon ganz gut. Fehlt nur noch ein Präsenzmelder, dann hat man wirklich einen universellen Raumsensor, den man je nach Bedarf bestücken könnte.

Also hier dann mal ein Vorschlag mit "Frontplatine"...

Ich hab den DHT-Anschluss mal drauf gelassen, da er im Moment nicht stört. Für die LED´s  habe ich optional Löt-Möglichkeiten für die 5050-Bauform und für die 5 mm Version vorgesehen. Verbindung der beiden Platinen erfolgt durch eine 8-polige 2,54 mm Buchsenleiste auf der Hauptplatine und der entsprechenden abgewinkelte 8-poligen Siftleiste auf der Front-Platine. (...werde ich noch auf Grund der Stabilität auf eine 2 x 4 polige Doppelreihe abändern.)

ich melde mich heute Abend nochmal dazu. (sorry). VIELEN DANK! GREAT WORK!!!

Ich habe einen Vorschlag wie man die "Bucht" für den BME und die Displayplatine integrieren könnte angehängt. Das ist jetzt alles nicht maßhaltig sondern erst einmal zur illustration. Grün, die Frontplatine, Rot ein mögliches Fenster für den LDR (da muss dann sicher noch eine Führung ran), Gelb die Halterung für die BME Platine inklusive Doppelwand zur Isolation.

Wäre es möglich die Front a) breiter zu machen und b) den Pfostenstecker nicht symetrisch in die Mitte zu setzen? Genauere Maße kann ich aktuell nicht vorschlagen weil ich die Breite Deiner "Hauptplatine" nicht kenne. Ich denke mal die wird auch so bei 7cm sein ?

Wenn man von vorn draufschaut müsste die Hauptplatine etwa 10mm vom rechten Innenrand weg sein und zum linken Innenrand würden etwa 2cm für die BME "Bucht bleiben. (?)

Bei angenommen 90mm Frontplatinen Breite müssten die Pfosten dann so sitzen dass die Hauptplatine eben etwa 10mm von rechten Rand entfernt ist.

Doppelpfosten müssen imho nicht sein. Man muss eh bei Zusammenbau darauf achten dass die Haup- und Frontplatine mit Stecker Lötung möglichst genau 90° bilden. Die Front bäuchte links und rechts noch 2mm (+/-) für die Führung - zumindest wenn der Vorschlag im Anhang ok wäre.

vg
Joerg

... zu a: ... kann ich so breit machen wie du es brauchst.
... zu b: ... auch kein Problem ( sollte ich noch für einen NodeMCU planen, sollte er aber von vorn gesehen nicht zu weit rechts sitzen.

Die Masse meiner Platine sind wie deine,  7 x 5 cm.
Normal müsstest du meine Vorlagen 1:1 ausdrucken können.

Ich glaub den nodemcu lassen wir weg - ist halt jetzt ein Wemos.

Ich habe mich verrechnet. Für den BME bleibt nur 10mm was aber eigentlich auch kein Problem sein sollte. Sehe ich natürlich erst wenn der Postbote die hier abgibt. Sollte uns hier aber nicht aufhalten.

...das mit den Vorlagen ausdrucken funktioniert nicht. Hab´s gerade versucht. Wird alles zu groß.
Geht nur über PDF. Dort passt es dann mit 1 zu 1.
Kannst es  ausdrucken, ausschneiden und schauen wie es ins Gehäuse passt und mir mitteilen, wo´s zu eng wird oder wo noch Platz ist,
bzw. wo die Platine größer oder kleiner sein muss.

Hallo Jörg,

zum Komplettieren des Codes, benötige ich leider noch die Info über die Lib: "MHZ.h".

Danke +
Grüße,
Jürgen

Hallo Jürgen,

die ist in den Ardiono Bibliotheken verfügbar

vg
Joerg

Hallo Jörg,

ahhhh ... "MH-Z", hatte MHz (... wie KHz, Google mal nach Arduino/Esp und "MHZ")  im Sinn. Jetzt, wo Du es sagst  ;) ;D ;D ;D ;D

Wobei die ArduinoCore-Lib auch etwas widerspenstig war ...  :o

ich kann ein fertiges binary anhängen wenn Du möchtest

vg
joerg

Hallo Joerg,
"fertiges binary" wäre vielleicht für die Leute nicht schlecht, die sich nicht durch die Parametrierung
der Libs durch wühlen wollen.  ;)
Bei mir würde ich gerne die OLED-Anzeige durch TFT ersetzen.

Bei mir hatte ich ein anderes ESP-SDK installiert und musste schauen wie ich die ESP-Wifi-Libs, insbesondere BearSSL mit deren Abhängigkeiten
konfiguriert bekomme... Wollte mein bestehendes Lib-/STK-System nicht komplett ändern.

Den Wifi-Weg Richtung FHEM finde ich super, man spart sich dadurch den Umweg über ( in meinem Fall) die LaCrosseGateway und den RFM69.
Bei mir würde ich statt den BME280 den BME680 integrieren wollen, dann wäre das auch noch eine zusätzliche und kostengünstigere Variante.
Muss aber erst auch noch Erfahrungen damit sammeln und ausprobieren.  :D
Vieleicht wäre es auch besser, die Arduino + ESP-Umgebung dafür neu in einer VM zu installieren ...

Schöne Arbeit.

Grüße,
Jürgen

Ja, wobei die SSL zB automatisch eingefügt wurde, die benötigt man eigentlich gar nicht. Aber yes, ist ein diy Projekt und das kann/soll man natürlich anpassen wie man mag.

Moin Papa Romeo,

mein Ausdruck ist etwas kleiner, liegt vmtl am Drucker.

Hauptplatine passt perfekt (wenn ich den Druck gedanklich skaliere ;).
Bohrlöcher würde ich etwas kleiner machen (ca 2mm+) sonst rutscht der Schraubenkopf durch.
Der DHT Stecker liegt über der Halterung, passe ich im Gehäuse an.
Kannst Du Dir vorstellen aus dem DHT einen i2c zu machen ? Dann kann man doch noch einen i2c Helligkeitssensor aufstecken. Hatten sich ja einige gewünscht.

Frontplatine
Die LEDs müssten ca 15mm nach aussen rücken, Gesamtbreite sollte aber 90mm sein. (Dann bleiben 1mm Tolernaz links/rechts). Wenn das geht die LEDs bei 90 breite soweit an den Rand als möglich. Der horizontale Einbau ist aber richtig dmait man die abknicken kann.
Die LDRs können da bleiben wo Sie jetzt sind, Tick tiefer wäre noch schön aber ich kann das Fenster ja auch in den Deckel machen.

Der Pfostenstecker passt so nicht, ist aber auch echt tricky. Bin da jetzt doch skeptisch, das müsste alles auf den 10tel mm stimmen weil dadurch ja eine starre Verbindung zwischen Haupt und Front wird. Evtl doch kabel ? (Flachband oder litze, geht ja fix..) ?
Nicht das wir uns da jetzt ewig an dem Stecker aufhalten und am Ende gehts doch nicht weil alleine durch das löten und das breakout board schon viel Ungenauigkeit entsteht ?

Ich habe auf dem Foto ein Kartenspiel zum Verlgleich danaben gestellt, zum Vergleich. Wirkt sonst auf den Fotos größer als es in echt ist.

vg
Joerg

Hallo Jörg,

...ich denke ist genügend Platz für einen oder zwei weitere I2C Stecker.

Dass der Pfostenstecker nicht passen würde, war mir vorneweg schon klar. Deswegen mach mal bitte ein Foto von oben, dass ich sehe, wie weit ich die 8er Pfostenbuchse nach vorne verlagern / Platine verbreitern muss, damit es passt.

Kabelverbindung würde natürlich auch gehen...aber wenn man es perfekt machen kann.... ::) :P ;)

Hallo Jörg,

wie muss der Sensor/Device in FHEM definiert werden?

Einige Libs machten doch noch etwas Typ+Versions-Probleme:
SSD1306 + DHT + DHT_U + ADAFRUIT_SENSOR.
Hier wären zum Nachvollziehen die Angaben nicht schlecht. (Oder alle in ein Zip packen?)

Dann kann ich mich nun der Hardware widmen ...  :D

Jürgen

für FHEMdefine slink slink <fhem_ip>

Außerdem das 10_SLinkIAQ.pm ins FHEM Verzeichnis, das SLink Modul legt den Raumsensor mit autocreate an.

Zu den libs, hilft der Anhang ?

vg
Joerg

Foto von oben, wobei im Gehäuse natürlich Änderungen drin sind wegen der Front...

Hallo Jörg,

eine statische Anzeige erscheint schon, der iAQ konnte auch ausgelesen werden.
Allerdings fehlt noch der DHT22 und der MZ-19...

*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: (IP unset)
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.xxx.yyy
*WM: freeing allocated params!

Danach kommen nur println.....
Die IP ist im Adressraum vorhanden. Im Log und Eventmonitor kommt nichts an ...
Die Anzeige im OLED-Display bleibt statisch.
Dann füge ich noch ein DHT22 hinzu ... und der MZ-19 fehlt noch...
DHT zeigt 24.9°C und  1.0 % rH an ...

Gehe mal davon aus, dass fhem den Sensor abfragt ?
Kann ich manuell mit einer URL eine Abfrage initiieren?

.. vertagt...

Das kann ja nun alles sein.

Der Sensor muss ins Netzt genommen werden, dafür macht er ein eigenes Netz auf. Das sieht bei Dir ok aus.

Im wireshark sieht man auch das es Kommunikation gibt, mcast Adresse und port sind ok. Allerdings sind 2bytes als payload viel zu wenig, ich kann nur vermuten das da bei den Anpassungen am sketch was schiefgegangen ist. Evtl müsstest Du dort einige Serial.println einbauen um auf dem seriellen Monitor zu sehen was los ist.

Ich würde vielleicht anfangen einen in die loop zu setzen um zu sehen ob die durchläuft.

Das senden der msg ist recht geradlinig:
#349 wird getIaqReadings aufgerufen, das liegt ab#206
Die DEBUG_PRINT ausgaben funktionieren nicht (vmtl wird das in eienr der libs überschrieben). Da solltest Du also DEBUG_PRINT gegen serial.print austauschen (Ausgabe i2c error etc)
# 222 wäre das update fürs display
# 223 würden die eco2 und tvoc Werte in einen Puffer geschrieben.

Die Loop schaut dann ob was im Puffer steht, sendet das und löscht den.

Stell ausserdem mal das slink device auf verbose 5. Beim Start sollte dann im log stehen "SLink Service received from ...." mit der IP von fhem (nicht 127.0.0.1) - das ist eine Art selbst test - SLink schickt siuch selber eien msg.

#193 im Slink ist jetzt auskommentiert, den könntest Du nochmal reinnehmen. Dann siehst Du Nachrichten die reinkommen aber ein falsches Format haben (weil Du ja 2bytes payload hattest)

Steht denn überhaupt was im log ? Sowas sollte beim Start des Sensors drinstehen
sensor DA8333 (192.168.178.30) start, reason External System

vg
Joerg

Dass da 125 steht bedeutet nicht das der IAQ ausgelesen wurde. Das Display startet immer mit 125 ...

Nachtrag:)
Nein, der Sensor wird nicht abgefragt sondern sendet selbst periodisch (aktuell: co2, voc, temp 10sec, bri 1sec)

vg
Joerg

Ich habe mir gerade mal die ganzen Bibliotheken in der Arduino IDE installiert und die Dateien runtergeladen.
Bekomme aber bei der Überprüfung folgende Fehlermeldung:

fatal error: BearSSLHelpers.h: No such file or directory

#include <BearSSLHelpers.h>

Bin mir ziemlich sicher, das ich alle Libarys installiert habe.

die wurde bei mir automatisch installiert. Esp8266Wifi hat die installiert. Benötigt man aber nicht. Wir machen nix mit ssl

Ich versuche später mal die libs sauber aufzulisten, sollte aber mit ein wenig probieren auch so funktionieren

Ok :-)
Normalerweise sollte doch aber
#include <ESP8266WiFi.h>
reichen?

Zitatfatal error: BearSSLHelpers.h: No such file or directory

Das kommt, wenn man die Lib nicht richtig installiert. (Hatte ich auch).
Es geht nur, wenn man die  Esp8266Wifi gemäß den Angaben in github richtig installiert.
In preferences.txt https://arduino-esp8266.readthedocs.io/en/latest/installing.html#boards-manager (https://arduino-esp8266.readthedocs.io/en/latest/installing.html#boards-manager) die die Vorgabe-Url einträgt und dann im LibraryManager die Lib ESP8266Wifi installiert.
Dann passen die Libs und Tools. nur die Libs ins Lib-Verzeichnis kopieren erzeugt obige Fehlermeldung.

Grüße,
Jürgen

Jep danke, hat funktioniert, kompiliert jetzt ohne Fehlermeldung bis auf:

DHT_sensor_library/DHT.h:27:0: warning: "DEBUG_PRINT" redefined [enabled by default]

   #define DEBUG_PRINT(...) {}

Sollte sich aber ja erledigt haben, wenn der DHT nicht verwendet wird.

Zu der Multicast-Adresse: 239.255.255.250 (https://en.wikipedia.org/wiki/Multicast_address)

Hallo Jürgen,

ich weiß nicht ob das eine Frage ist.

Ja, das ist die Multicastadresse, port ist 2085

So können sich die Sensoren und auch mehrere FHEM im gleichen Netzwerk finden ohne das etwas konfiguriert werden muss. Das Protokoll ist Text, ich verwende das auch für andere Sensoren.

vg
Joerg

Hallo Jörg,
nein, war eher eine Feststellung, da mir die IP-Adresse zuerst unbekannt, bzw. suspekt vor kam.
Es ist nicht jeder intensiv auf UDP (SLPv2) (https://tools.ietf.org/html/rfc2608)  unterwegs  ;)

Hatte gestern keine Zeit mehr, besser zu testen.

ZitatAllerdings sind 2bytes als payload viel zu wenig...

Kann es sein, dass die Auskommentierung rein gehört?

void prepareMessage(char* payload ) {
  //sprintf(message, "T:IAQC;FW:1.0;ID:%06X;IP:%s;R:%ld;%s", ESP.getChipId(), WiFi.localIP().toString().c_str(), WiFi.RSSI(), payload);
  Serial.println(message);
};

Das würde auch die leeren println erklären ...

Ok, aber FHEM bekommt immer noch nichts mit, trotz verbose 5 ...

Mia culpa, hatte die Dateien noch nicht auf die Gruppe "dialout" gesetzt.
8,0K -rw-r--r--  1 fhem dialout 4,4K Jan 24 15:29 10_SLinkIAQ.pm
8,0K -rw-r--r--  1 fhem dialout 5,3K Jan 24 15:29 10_SLinkS0.pm
8,0K -rw-r--r--  1 fhem dialout 4,3K Jan 24 15:29 10_SLinkTH.pm


Ein Ping auf die IP des ESP geht, aber empfangen (https://forum.fhem.de/index.php?action=dlattach;topic=96241.0;attach=113866;image)  wird leider noch nichts.

Serial-Output:
MH-Z19 msg:T:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-55;F:BR;B:110;
T:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-55;F:TH_A;T:24.4;H:1.0;
Temp Hum msg:T:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-55;F:TH_A;T:24.4;H:1.0;
T:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-55;F:BR;B:108;



Teile des Telegramms:
^ÿúþ4úðtEXmVPÀ¨²5ïÿÿú%%D¤hT:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-56;F:BR;B:93;
^ÿúþ4úðtEXnVOÀ¨²5ïÿÿú%%DiT:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-56;F:BR;B:89;


ZitatStell ausserdem mal das slink device auf verbose 5. Beim Start sollte dann im log stehen "SLink Service received from ...." mit der IP von fhem (nicht 127.0.0.1) - das ist eine Art selbst test - SLink schickt sich selbst eine msg.
#193 im Slink ist jetzt auskommentiert, den könntest Du nochmal reinnehmen. Dann siehst Du Nachrichten die reinkommen aber ein falsches Format haben (weil Du ja 2bytes payload hattest)
Steht denn überhaupt was im log ? Sowas sollte beim Start des Sensors drinstehen
sensor DA8333 (192.168.178.30) start, reason External System

Nein ... :'(

Das list:
Internals:
   CFGFN     
   DEF        192.168.xxx.yyy
   NAME       slink
   NOTIFYDEV  global
   NR         145
   NTFY_ORDER 50-slink
   STATE      ???
   TYPE       SLink
   helper:
     mcaddr     ���5
Attributes:
   verbose    5

/edit: iAQ zeigt verschiedene VOC - Werte an 126...127.

Grüße,
Jürgen

Hallo Jürgen,

das ist so richtig. Serial.println kann man zum debuggen reinnehmen.
void prepareMessage(char* payload ) {
  sprintf(message, "T:IAQC;FW:1.0;ID:%06X;IP:%s;R:%ld;%s", ESP.getChipId(), WiFi.localIP().toString().c_str(), WiFi.RSSI(), payload);
  Serial.println(message);
};
Die Nachrichten sind, soweit ich das sehe, richtig. Dies ist eine komplette Nachrichtig für Helligkeit 108:
T:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-55;F:BR;B:108;
Hast Du das Slink device sicher mit der IP des fhem servers (nicht sensor etc) erstellt ? Also wenn dein fhem Server zb 192.168.178.30 hat dann würde eine definition so lauten:
define slink slink 192.168.178.30

Die Zeile 177in SLink.pm lautet aktuell so:
Log3 ($shash->{PARENT}, 5 , sprintf("SLink Service received from %s:%s packet %s", $herstraddr, $port, $msg));
Magst Du die einmal ändern auf

Log3 ($shash->{PARENT}, 0 , sprintf("SLink Service received from %s:%s packet %s", $herstraddr, $port, $msg));

und dann fhem komplett neu starten ?

Im log erwarte ich dann auf alle Fälle die Eigenmeldung: "T:SLink;FW:1.0;ID:$uniqueID;IP:0;R:0;F:SERVICE;START:Startup;\n"

Irgendwelche besonderheiten bei Deinem fhem ? OS, Docker etc ?

vg
Joerg

Hallo Jörg,

ah! Zwei Dinge:

ZitatHast Du das Slink device sicher mit der IP des fhem servers (nicht sensor etc) erstellt ? Also wenn dein fhem Server zb 192.168.178.30 hat dann würde eine definition so lauten:
Code: [Auswählen]
define slink slink 192.168.178.30

Nein, dachte die des Sensors !

Achtung:

Zitatsprintf(message, "T:IAQC;FW:1.0;ID:%06X;IP:%s;R:%ld;%s", ESP.getChipId(), WiFi.localIP().toString().c_str(), WiFi.RSSI(), payload);

ist bei Dir im Github-Code auskommentiert !!!!

ZitatIrgendwelche besonderheiten bei Deinem fhem ? OS, Docker etc ?

Nein Raspi3B+, Standard Installation.

Komischerweise kommt nicht die Start-Meldung des SLink-Devices im Logfile, trotz verbose 5.

Dann auf ein Neues ...  ;)
Danke!

Jürgen

Zitatist bei Dir im Github-Code auskommentiert !!!!

grmpf... Danke! Korrigiert

ZitatNein, dachte die des Sensors !

Das würde das ausbleiben der Eigenmeldung erklären

Alles andere sah bei Dir gut aus. Du hast auch den Aufbau der Meldungen gesehen, so kann man ganz einfach auch andere Funktionen (oder ganz andere Sensor typen) erstellen.

noch 'n Nachtrag: die eigene ip bei slink ist optional. Ich habe aber festgestellt das auf einigen OS nach mehrmaligem start von fhem es sonst nicht mehr geht. Konnte die genaue Ursache trotz einigen Versuchen nicht letztendlich einkreisen, denke das ist ein os bug (perl bug, Karma ? )
define slink slink sollte es in den meisten Fällen schon tun

Danke für die Hilfe.
Primär habe ichs verbockt:
hatte die 00_Slink.pm nicht mitkopiert, sondern nur die 10_Slink*.pm. (Grrr...)
Fhem neu gestartet, nachdem ich die FHEM-IP mit dem slink-Device definiert hatte und verbose 5 eingestellt hatte.
Meldet sich aber immer  noch nicht im Log ....

define slink slink

... has done the job !

Super. Jörg, vielen Dank für die Unterstützung.
+ viel über UDP und SLPv2 gelernt.

:D :)

Ja cool!

Wenn Du den Sensor erweitern möchtest und weitere/andere Funktionen benötigst dann sag gern Bescheid.

Komisch warum die IP nicht ging, müsste man evtl später nochmal untersuchen. Aber so wie Du es jetzt hast war es ganz ursprünglich.

ich sehe gerade Deinen 2ten screenshot. Da stimmt noch was nicht. Ich habe das neue IAQC modul scheinbar noch garnicht ins GIT gestellt, das macht Temp/Hum/Co2/tvoc/bri in einem Modul. Mach später am Abend.

Ja passt. Dann kann ich mir morgen darüber Gedanken machen, Danke.

Allerdings noch ein Problemchen:
2019.01.28 22:59:20 0: ERROR: Cannot autoload SLinkIAQC
2019.01.28 22:59:20 3: slink: Unknown code T:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-56;F:BR;B:96;, help me!
2019.01.28 22:59:21 0: ERROR: Cannot autoload SLinkIAQC
2019.01.28 22:59:21 3: slink: Unknown code T:IAQC;FW:1.0;ID:FAF074;IP:192.168.xxx.yyy;R:-57;F:BR;B:103;, help me!

Kann aber sehr wahrscheinlich auch an fehlenden Werten des MH-Z19  oder des DHTs (weil T leer ist aber im Oled-Display angezeigt wird) liegen ...
Aber das bekomme ich dann morgen heraus.

Grüße,
Jürgen

ne, hat sich überschnitten. Ich habe das autoload im slink angepasst aber das modul für mich behalten   ;D

Das IAQC muss ich hochladen.

ZitatWenn Du den Sensor erweitern möchtest und weitere/andere Funktionen benötigst dann sag gern Bescheid.

Sehr gerne, vielen Dank!

Grüße,
Jürgen

PS: Anbei meine Version des Sketches.

10_SLinkIAQC.pm  ist im git

Mist, jetzt wollte ich das gerade mal nachbauen und mir fällt auf das ich einen anderen MH-Z19 habe, als du.
Ich habe den unteren auf dem Bild.

Mit espeasy wurde der bei mir an RX/TX betrieben. Laut deinem Schaltplan sind diese bei dir an SR/H0 angeschlossen.
Im Script wird aber
// pin for pwm reading
#define MH_Z19_RX D4  // D7
#define MH_Z19_TX D0  // D6
angeben.

Ich werde mal testen ob das eventuell doch geht, nur paßt das bei mir dann erst mal mit der Platine nicht, was aber nicht schlimm ist, da ich auch das falsche OLED Display (1.3") habe.

Moin,

ja das ist der "nicht B".

Ich betreibe den aber auch an RX/TX - unter Umständen geht der direkt also ohne Änderungen.

vg
Joerg

stimmt, da ist mein Schaltplan falsch. Muss ich nachher mal auf der Platine von Papa Romeo schauen ...  :-X

Funktioniert an RX/TX, Werte scheinen auch ok zu sein.

Hm Mist, jetzt wollte ich den BME280 integrieren und habe irgendwie mein MH-Z zerschossen. Kommen keine Werte mehr.

Softwareseitig ?  Falls Du es nicht ohnehin weißt: in dunkler Umgebung sieht man innen die Lampe regelmäßig kurz aufblinken. (Das ndir machen die per filter, ist visible)

Meine BME280 sind auch heute gekommen.

Ja die kleine rote Lampe funktioniert noch, es kommen aber keine Daten mehr. Habe es vorsichtshalber eben noch mal mit espeasy versucht, da kommt auch nichts mehr.

Hilft zwar nicht direkt weiter:
https://forum.mysensors.org/topic/7761/mh-z19-teardown/2 (https://forum.mysensors.org/topic/7761/mh-z19-teardown/2)
weitere InfosF (https://translate.google.de/translate?sl=auto&tl=de&u=https%3A%2F%2Fhabr.com%2Fen%2Fpost%2F401363%2F)

Mit einem STM32F103 aufgebaut.

konntest Du die Ursache finden ?

Habe jetzt nochmal espeasy geflasht, Pins geändert und Kabel getauscht. Ich bekomme jetzt mit espeasy wieder Werte angezeigt.
Keine Ahnung ob es jetzt am Script liegt oder an den anderen Pins oder anderen Kabeln.

Zum Glück habe ich noch keinen neuen bestellt.

Du kannst ja mal Bescheid geben, wenn du den BME eingebaut hast, eventuell habe ich da ja ein Fehler gemacht.

Würde eigentlich noch ein Steckplatz für ein SPI TFT auf die Platine passen?

Hier mal meine geänderte Datei:

Ich habe heute die bme280 und die wemos erhalten und passe fw, housing und Schaltplan als nächstes darauf an. Für ein spi ist am wemos aber leider nichts mehr frei. Schön das der mhz keinen Schäden genommen hat.

Zitat von: juergs am 29 Januar 2019, 18:00:01
Hilft zwar nicht direkt weiter:
weitere Infos (https://translate.google.de/translate?sl=auto&tl=de&u=https%3A%2F%2Fhabr.com%2Fen%2Fpost%2F401363%2F)

Какие? Ты не говоришь по русски? Какой беспорядок!

Ich glaube, die Übersetzung russisch - englisch wäre dann doch ein bisschen besser.

Gruß Peter

Ach komm...  :)

ZitatIch glaube, die Übersetzung russisch - englisch wäre dann doch ein bisschen besser.

Na ja, kommt fast an chinesisch ran  ;) 8)
Schlimmer noch, Übersetzung: "Intelligentes Haus DIY oder mach es dir selbst, Elektronik für Anfänger "

2019.01.29 21:10:01 3: SLink: sensor 955744b881fa4f637c0e231396a072b0 (0) start, reason Startup
2019.01.29 21:10:02 2: autocreate: define SLinkIAQC_FAF074 SLinkIAQC FAF074
2019.01.29 21:10:02 2: autocreate: define FileLog_SLinkIAQC_FAF074 FileLog ./log/SLinkIAQC_FAF074-%Y.log SLinkIAQC_FAF074

Sieht gut aus ...

Jetzt muss ich nur noch die 1% Luftfeuchte in Griff bekommen ...  8) ;D

Grüße,
Jürgen

Perfekt. Die eco2 Werte habe ich in dem kombinierten Modul weggelassen da die ohnehin fest aus der tvoc skaliert werden. Außerdem sind die durch den mh-z mMn obsolet

Wie sieht es mit interesse an einer Sammmelbstellung des MH-Z19B (https://de.aliexpress.com/item/MH-Z19-MH-Z19B-NDIR-CO2-Sensor-Modul-Infrarot-Kohlendioxid-co2-gas-Sensor-0-5000ppm/32860834286.html?spm=a2g0x.10010108.1000014.2.58ec19a6EsAhdH&pvid=b0c53ca1-07f3-4dda-99df-b5c98acce35d&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.13338.107646.000000000000000&scm-url=1007.13338.107646.000000000000000&scm_id=1007.13338.107646.000000000000000) aus?
Ca. 18,13 € ?

Bei der Luftfeuchte wollten wir doch auf den bme280? Welchen hast du jetzt dran?

Zitat von: juergs am 29 Januar 2019, 21:21:32
Wie sieht es mit interesse an einer Sammmelbstellung des MH-z19B aus?
Bei Ali ca. 18,- € ?

Ja. Ich hatte auch erstmal nur 3 genommen zum testen. Wenn die Platine und der Rest steht können wir ja eine Sammelbestellung über alles andenken?

Zitat von: herrmannj am 29 Januar 2019, 21:21:51
Bei der Luftfeuchte wollten wir doch auf den bme280? Welchen hast du jetzt dran?

Den DHT22 aber die falsche Lib. Habe noch ein paar BMP280  ohne Luftfeuchte hier herumliegen .... 
Evtl. sogar den BME680 und dafür den AMS weglassbar ... Dann mit Luftdruck, Temp, Hum und IAQ ....
Dann aber mit "special" Bosch compile ...

@juergs
Löhnt sich das überhaupt, wird ja bei mehreren nicht billiger und es würde bei mehr als 25€ dann wohl auch noch Zoll drauf kommen?

An den BME680 hätte ich eventuell auch Interesse als Sensor. Der IAQ ist ja jetzt nicht so einfach zu bekommen.

Zitat von: herrmannj am 29 Januar 2019, 21:24:14
Ja. Ich hatte auch erstmal nur 3 genommen zum testen. Wenn die Platine und der Rest steht können wir ja eine Sammelbestellung über alles andenken?

Ja, wäre dann mit zwei dabei.

Jürgen

Zitat von: Starsurfer am 29 Januar 2019, 21:27:57
@juergs
Löhnt sich das überhaupt, wird ja bei mehreren nicht billiger und es würde bei mehr als 25€ dann wohl auch noch Zoll drauf kommen?

An den BME680 hätte ich eventuell auch Interesse als Sensor. Der IAQ ist ja jetzt nicht so einfach zu bekommen.

Wenn Peter die neuen Breakoutboards zurückbekommt, wäre da auch noch ein BH1750 mit drauf ...   
Habe aber auch noch ein paar Breakoutboards nur mit BME680 da, wenn Interesse besteht.
Der BME680 kostet etwa 9,90€ bei Reichelt + Board 0,26 €.

Zitats 25€ dann wohl auch noch Zoll drauf kommen?

Wäre dann bei zwei vielleicht sowieso fällig.  ;)
oder 2 mal einzeln ...

Außerdem ist demnächst eh chin. Neujahrsfest ...

Jürgen

ich habe die aiq-core bei digikey und die mhz bei banggood (https://www.banggood.com/MH-Z19-0-5000PPM-Infrared-CO2-Sensor-For-CO2-Indoor-Air-Quality-Monitor-UARTPWM-p-1094463.html?utm_design=41&utm_source=emarsys&utm_medium=Shipoutinform171129&utm_campaign=trigger-emarsys&utm_content=Winna&sc_src=email_2671705&sc_eh=cd8f85e1e31a75b31&sc_llid=9448772&sc_lid=104858042&sc_uid=pa7JzM5vXj&cur_warehouse=CN) bestellt.

edit: ich sehe gerade dass das wohl der alte ist den ich verlinkt habe

den bme680 zu integrieren überlasse ich euch  ;)

Gehäusetechnisch müsste man den dort hin setzen wo der bme280 hin soll sonst gibt es wieder Stress. Eine passende Gehäusevariante kann ich machen falls da Interesse besteht. Dann würde man den aiq unbestückt lassen. Der bme680 kommt mit i2c only klar oder ? (Kabel wäre ja da)

Bestimmt interessant den dann mal 1:1 mit dem aiq zu vergleichen

ZitatBestimmt interessant den dann mal 1:1 mit dem aiq zu vergleichen

Ja, das wäre spannend. Ich bin grundsätzlich auch an dem BME680 interessiert.

ZitatDer bme680 kommt mit i2c only klar oder ?

Ja, würde man z.B. auch den iAQ sockeln, könnte man austauschen  ;)
Aber grundsätzlich ginge anstatt BME280 auch.

Habe gerade meine OLED's bekommen, die sind ja winzig:-)
Hatte vorher nur 1,44" Oleds aber leider nur SPI.

Habe jetzt mal den MH-Z und den BME auf dem Steckbrett hier laufen, allerdings zur Zeit noch mit Espeasy. Nach zwei Tagen scheint sich der BME auch eingependelt zu haben und hat nur eine kleine Differenz zum TX29DHT. Luftdruck habe ich 1hpa Unterschied zu Proplanta.

Die Toleranz für HUM wird beim BME280 mit +/-3% angegeben.

Wobei der eigentliche schwierigere Teil ja ein Einbau im Gehäuse ohne thermische Beeinflussung ist. Ich habe gestern Abend einen Design Versuch gemacht mit dem ich aber noch nicht ganz happy bin. Ist halt auch echt fiepsig klein das Dingens ....

Auf dem Bild im Anhang ist es jetzt maßhaltig zum BME. Denn würde man aber nur mit Pinzette reinsetzen können und man verliert die komplette Lüftung auf dieser Gehäuse Seite. Die abgebildeten Wände sind nur 2mm - dünner ist nicht mehr sinnvoll. Ich setze darauf das mir da noch was besseres einfällt ...

Wäre vielleicht im Deckel mehr Platz?

Der ist ja flach und diese Kammer mit 2fach Isolierung würde man da auch nicht drucktechnisch umsetzen können. Ich denke darüber nach das an (oder in) die Deckelhalterung rein zu setzen. Die mechanische Fixierung ist auch nicht ohne - wenn von "hinten" diese Doppelkammer ist müsste man eine mögliche Schraube von Außen anbringen - geht gar nicht.

Aber da wird sich schon was finden ...  8)

Hast ja noch ein bißchen Zeit zum testen :-)
Ich habe noch etliche von diesen Gehäusen (https://www.conrad.de/de/axxatronic-cbrs01vwh-con-universal-gehaeuse-86-x-86-x-255-abs-weiss-1-st-1407855.html?PubID=2178175&WT.mc_id=affiliate_zanox_produktdaten&hk=WW1&insert=U0&utm_campaign=affiliate&utm_content=article&utm_medium=deeplink&utm_source=zanox&zanpid=2525724939890836480) hier rumliegen, allerdings eine Nummer kleiner (7x7x2,5cm). Da paßt von der Höhe gerade so ein gesockelter NodeMcu rein.
Oder schau mal hier: https://www.thingiverse.com/thing:3028730 (https://www.thingiverse.com/thing:3028730)

anbei mal ein Vergleich vom iAQcore (rot) und 3 verschiedene BME680 (blau).
Zum Signalverlauf muss man für den ersten BME aber fairerweise sagen, dass dieser Sendor in der Nähe
der Heizung liegt und somit natürlich mehr Schwankungen unterliegt.
Liegen aber alle im Bereich von 50 qcm.
Um wirklich 100% vergleichbare Werte zu bekommen, müsste man sie wirklich alle zusammen legen und vor Zug schützen...
Aber immerhin mal Anhaltswerte.

100% gleich wird man die nicht bekommen. Vermutlich reagieren die auch unterschiedlich auf verschiedene VOC Bestandteile, veröffentlicht haben das ja weder AMS noch BOSCH. Reagiert der AMS prompter ?

220ppm beim AMS ist gut: gute Luft bei Dir! - bei mir im Büro geht das gern mal gegen 500 ...

https://www.allum.de/stoffe-und-ausloeser/schadstoffe-der-innenraumluft/beurteilungswerte-fuer-die-innenraumluft#richtwerte

ZitatReagiert der AMS prompter

Ja, scheinbar. Auch das Folgen der Temperatur ist ersichtlich.
Bei BME #1 ist eine ältere BSEC-Variante zum Einsatz gekommen.
#2 + #3 haben das aktuelle BSEC als Grundlage. Auch hier sieht man zu #1 leichte Unterschiede.

Auf absolute Werte kommte es aber auch gar nicht an, die Tendez aber schon.
Also in Richtung, doch besser Lüften oder nicht. Ohne Sensor wird einem das gar nicht so klar.

 

Hallo Jörg,

habe jemand gefunden, der mir das Gehäuse ausdrucken kann.
Wenn du also die Druckdatei aktualisiert hast, kannst du sie mir vielleicht zukommen lassen.

Gruß

Papa Romeo

PS: Gehäuse ist da.

Hat schon jemand den bme280 erfolgreich eingebunden? Ich bin da anscheinend zu blöd für...

Hab leider nur ein BMP280 da ... (oder gleich ein BME680?)
Der ist ohne Luftfeuchte, aber die I2C-Anbindung ist die Gleiche ...

Zitat//All BME680 chips have the same ID: 0x61
//Please note that the Chip ID from the BME280 sensor is 0x60
//Reading the temperature value from the BME680 is identical to reading the temperature from the BME280

Grüße,
Jürgen

Im Prinzip egal, Hauptsache es kommt was an :-) In der Version die ich ein paar Beiträge vorher angehängt habe, funktioniert irgendwie gar nichts mehr.

Hallo Starsurfer,

prinzipiell kannst Du Dir die bme280.h und die bme280.cpp von der LGW "schnappen" (Grüße an HCS) (+ I2CBase.h + cpp) und
"einfach" ein BME-Objekt instanziieren:


  m_hasBME280 = m_bme.TryInitialize(0x76);


if (m_hasBME280) {
    bmeTemperature = m_bme.GetTemperature();
    bmePressure = m_bme.GetPressure();
    bmeHumidity = m_bme.GetHumidity();
  }

Den Rest mit Kompensation etc. kann man dann darum aufbauen...

Oder doch besser die Adafruit-Lib nehmen: https://github.com/adafruit/Adafruit_BME280_Library (https://github.com/adafruit/Adafruit_BME280_Library)

Würde es aber bevorzugen, ähnlich der LGW einfach im Setup zu prüfen ob Sensoren I2C-technisch da sind und diese dann abzufragen...
Also gleich ordentlich implementieren...

Noch eine andere Geschichte:

hatte erst vor kurzem einen neue Raspberry 3B+ aufgesetzt und betreibe
eine fhem-Instanz mit dem Sensor von Jörg und einer LaCrosseGateway_V1.30-Instanz mit 1 NanoGateway-BME680-Sensor.
Zusätzlich eine Docker-Instanz  mit eine LaCrosse-Gateway in der Version 1.32 und drei BME680-NanoGatewaway-Sensoren.

Der Raspi ist nicht wesentlich ausgelastet, dennoch hängt er sich in den letzten Tagen immer wieder nachts auf.
Beobachtet man das Geschen, fällt auf, dass der Netz- und Logfile-Traffic, den die LGWs und Jörgs Sensor erzeugen doch sehr hoch ist.

Macht es nicht Sinn, die Zykluszeiten etwas herunterzudrehen um fhem auch noch Zeit für andere Aufgaben zu geben
und die Logfile-Belastung herunterzuschrauben?

Die Ursache kann natürlich auch etwas ganz anderes sein ...  ;)

Jürgen
 

Die Adafruit Lib habe ich genommen und das Beispiel eingebaut, der BME wurde aber nicht erkannt. Ich werde das noch mal testen, eventuell lag das auch an der Verkabelung, der MH-Z hat ja auch auf einmal keine Daten mehr gesendet.

Wenn ich das richtig sehe, werden die Werte minütlich gesendet, wenn man das auf 3 Minuten ändert sollte das eigentlich auch reichen, denke ich.

Hmm, auffäällig sind die unterschiedlichen I2C-IDs (0x60 + 0x76) die Verwendung finden ...

... und

Zitat#define BME280_ADDRESS (0x77)

? ? ?

Da kann man vorher nur den "I2C_Scanner" laufen lassen...

Ist es vielleicht möglich, das sich das LGW aufhängt? Ich habe das hier bei zwei LGW's gehabt, die sich immer wieder aus dem WLAN verabschiedet haben und dann hat sich das FHEM WEB andauernd aufgehängt, es war fast unmöglich eine Seite im FHEM aufzurufen (auf einem Zotac Z-Box).

Laut espeasy Scanner: 0x76

Ah daran könnte es liegen:
// Create BME280 object
BME280_I2C bme; // I2C using address 0x77
// or BME280_I2C bme(0x76); // I2C using address 0x76


Ist das hier eigentlich ein echter BME680 (https://www.ebay.de/itm/Ultra-small-Pressure-CJMCU-680-BME680-Temperature-Humidity-Pressure-Sensor-se/283342179185?hash=item41f8828b71:g:nAYAAOSwptZcQFXM:rk:4:pf:1&frcectupt=true)

ZitatWenn ich das richtig sehe, werden die Werte minütlich gesendet, wenn man das auf 3 Minuten ändert sollte das eigentlich auch reichen, denke ich.

Die Hardwareabfragen laufen ca. alle 10 sek. :
unsigned long intervalDht     = 10000;    // default
unsigned long intervalIaq     = 10000;    // default
unsigned long intervalMhz19   = 10000;    // default
unsigned long intervalLdr     = 1000;    // default
unsigned long intervalLed     = 0;        //

Aber beispielhaft in Loop:

// send and clear IAQ msg if any
  if (WiFi.status() == WL_CONNECTED && strlen(iaqMsg) != 0) {
    prepareMessage(iaqMsg);
    DEBUG_PRINT("IAQ msg:");
    DEBUG_PRINT(message);
    Udp.beginPacketMulticast( ipMulti, portMulti, WiFi.localIP() );
    Udp.println(message);
    Udp.endPacket();
    strcpy(iaqMsg, "");
  };

Wird in Loop mit voller Bandbreite gesendet, sobald ein Messergebnis vorliegt.
Unabhängig, ob die Daten "dirty" sind oder nicht ...

Ja, BME läuft mit adafruit. Ich stelle den code ins git sobald die Anpassungen für Wemos und Test durch sind.

@Jürgen:
Ja, die Intervalle kann man anpassbar machen, ich finde es aber ganz in schon ok wenn man die Infos zeitnah im fhem hat. Im code esp code kannst Du das sonst selber probieren, die sind kommentiert. Alles loggen ist Wahnsinn, logisch.

Netzwerk"last" kommt da aber nicht zusammen, das sind um die 20-30byte alle paar Sekunden, das schafft ein Taschenrechner aus den 90ern ;). Der Absturz kommt von woanders.

Was ich habe ist _ein_ Sensor der alle x Tage mal einen Reset wegen Hardware Watchdog macht (der Sensor, nicht fhem). Da vermute ich aber eine Macke auf dem esp.

vg
joerg

Zitat von: juergs am 02 Februar 2019, 17:28:59
Die Hardwareabfragen laufen ca. alle 10 sek. :

Code Auswählen Erweitern

unsigned long intervalDht     = 10000;    // default
unsigned long intervalIaq     = 10000;    // default
unsigned long intervalMhz19   = 10000;    // default
unsigned long intervalLdr     = 1000;    // default
unsigned long intervalLed     = 0;        //

Aber beispielhaft in Loop:

Code Auswählen Erweitern

// send and clear IAQ msg if any
  if (WiFi.status() == WL_CONNECTED && strlen(iaqMsg) != 0) {
    prepareMessage(iaqMsg);
    DEBUG_PRINT("IAQ msg:");
    DEBUG_PRINT(message);
    Udp.beginPacketMulticast( ipMulti, portMulti, WiFi.localIP() );
    Udp.println(message);
    Udp.endPacket();
    strcpy(iaqMsg, "");
  };

Wird in Loop mit voller Bandbreite gesendet, sobald ein Messergebnis vorliegt.
Unabhängig, ob die Daten "dirty" sind oder nicht ...

Helligkeit jede Sekunde, der rest alle 10 Sekunden (auslesen und senden).

Aber nochmal, das ist keine "last" ...

Hallo Jörg, Starsurfer,

klar, es ist die Summe...  ;)

Die Hänger korrelieren allerdings mit dem Einsatz des , deshalb mein Verdacht ...
Lief vorher (vor 2-3 Tagen ohne Probleme).
Ist natürlich auch schwierig schwierig zu diagnostizieren woran es effektiv liegt.
Der Raspi muss dann hart resettet werden ( bin mal gespannt, wann das Filesystem platt macht .. ) 

Sorry, bin gerade an 3D-Gehäusen dran ...
Jürgen

Hallo Jörg,

ZitatHelligkeit jede Sekunde, der rest alle 10 Sekunden (auslesen und senden).

if (WiFi.status() == WL_CONNECTED && strlen(iaqMsg) != 0)
iaqMsg wird ja nicht nach dem Senden gelöscht...
Senden erfolgt in Loop "ungebremst" (DEBUG-Ausgaben bremsen noch etwas aus) ... oder liege ich falsch?

Jürgen

Wäre ein Bug aber ich behaupte, nee.

Wenn ein Messwert da ist wird er gesendet und gelöscht. Passt doch auch mit deinem Log oben

Hallo Jörg,

stimmt!

strcpy(iaqMsg, "");

Sorry, hatte es übersehen ...  :-[ ::)

BME, mal angedacht ...

BME280.SDO/ADR = Open = default = 0x77
                          = GND = 0x76

...nicht dass ihr denkt...ich bin raus....

... hab die Platinen mal an das Gehäuse von Jörg angepasst und es stehen insgesamt fünf I2C Schnittstellen zur Verfügung.
Drei auf der Haupt- und zwei auf der Front-Platine (weiß ja nicht was ihr noch alles einbauen wollt.. ;) ;D).
(Hab hier noch ein Geiger-Müller-Modul liegen....sollte vielleicht auch mal eingebunden werden... :o ;D  :P ::))

Die Anbindung des MHZ hab ich auch gleich auf RX/Tx geändert.

Zitat von: Papa Romeo am 02 Februar 2019, 18:40:07
Die Anbindung des MHZ hab ich auch gleich auf RX/Tx geändert.

Mist, hatte gerade überlegt ob man da nicht auch ein Nextion Display dran packen kann  :o ;)

Ah sorry falsch gelesen, du hast den Anschluß vom MH-Z auf TX/RX geändert und nicht am Wemos  ;D

..nee....hab´s nur am MHZ umgelegt. Tx und Rx am Wemos sind immer noch ungenutzt, außer Flashen und serieller Monitor natürlich...
Schaut´s euch mal bitte an, ob irgend etwas nicht passt oder was fehlt oder man noch vorsehen sollte.

@Joerg: Kannst du mir bitte die genauen Abstände der vier Befestigungslöcher zueinander aus deiner Gehäusedruck-Datei nennen.
             Ist auf Grund der Gehäuse-Höhe schlecht mit der Schieblehre zu messen.

ZitatHab hier noch ein Geiger-Müller-Modul liegen

i2c ??  ;D

Befestigung (aktuell) : Breite 66.0mm / Länge 46.0mm. (6mm über dem Boden)

Ich habe aber auch keinen Stress da später noch Anpassungen zu machen.

Ich drucke mir das morgen aus und gehe auch nochmal die Leiterbahnen durch, wenn ich soll. Dann können wir auch direkt bestellen. Ich würde 30Stück auf meine Kappe nehmen (5-7 würde ich nehmen) und den Rest dann gegen Material und Porto versenden. Wenn ich mehr bestellen soll sagt mir das.

@starsurfer
Ich habe auch noch 2 Nextions hier und würde, getrennt, auch noch eine Variante damit machen wollen. Lass(t) uns da aber in einem anderen thread sprechen.

vg
Joerg

sagt mal bitte, zum BME680:

Der macht Temp/Hum/Baro/tVOC oder ? Das heist, wenn man einen BME680 einsetzen wollen würde [sic] dann bräuchte man den BME280 nicht ? Richtig ?

Welche BME680 breakout Platine nimmt man ?

Danke vg
Joerg

Zitat von: herrmannj am 02 Februar 2019, 22:16:47
i2c ??  ;D

..natürlich nicht...war ein Gag. Der schickt im Moment seine Daten noch an ein Display und eine SD-Karte.

Ich habe mal den geordert:

https://www.aliexpress.com/item/1pcs-BME680-Digital-Temperature-Humidity-Pressure-Sensor-CJMCU-680-High-Altitude-Sensor-Module-Development-Board/32961369966.html?spm=a2g0s.9042311.0.0.3da24c4dUETgGy

Zitat von: herrmannj am 02 Februar 2019, 22:16:47

@starsurfer
Ich habe auch noch 2 Nextions hier und würde, getrennt, auch noch eine Variante damit machen wollen. Lass(t) uns da aber in einem anderen thread sprechen.

vg
Joerg

Klar kein Problem 😂

Echt jetzt, Geigerzähler? Wohnt ihr alle neben nen Kraftwerk? 😁
Mich würde noch ein Geräuschsensor, Bewegungsmelder/Präsenzmelder interessieren. Achja und ein Lux Sensor.

Zitat von: herrmannj am 02 Februar 2019, 22:24:13
sagt mal bitte, zum BME680:
Der macht Temp/Hum/Baro/tVOC oder ? Das heist, wenn man einen BME680 einsetzen wollen würde [sic] dann bräuchte man den BME280 nicht ? Richtig ?
Welche BME680 breakout Platine nimmt man ?

Ja, der macht alles, bis auf CO2, aber IAQ im Wertebereich 25..500. D.h. man könnte dann auf den iAQ +DHT22 verzichten.

Ich benutze zur Zeit die OSH-Breakout-Platine (https://oshpark.com/shared_projects/LXuNziGd) (0,26€/STck) und bestelle mir den BME680 (9,90€) von Reichelt.
Allerdings macht PeMue (https://forum.fhem.de/index.php/topic,78619.msg896963.html#msg896963) schon ein passendes Breakout mit BME680 + BH1750 (LUX).
Diese Variante würde ich besser empfehlen.

Fertige Variante für 15,98 € auf deren Beschaltung ich mich beziehe:
https://www.watterott.com/de/BME680-Breakout (https://www.watterott.com/de/BME680-Breakout)

Die Anbindung über I2C ist eher unproblematisch, aber das Gehäuse mit passenden Ausbrüchen vorzubereiten sehe ich eher als Herausforderung.

Jürgen


@Papa Romeo:

Der (https://www.aliexpress.com/item/1pcs-BME680-Digital-Temperature-Humidity-Pressure-Sensor-CJMCU-680-High-Altitude-Sensor-Module-Development-Board/32961369966.html?spm=a2g0s.9042311.0.0.3da24c4dUETgGy) ist ja dagegen ein echtes Schnäppchen...  :)

Und die serielle + I2C-Lösung: GY-MCU680V1 (https://de.aliexpress.com/item/GY-MCU680V1-BME680-Sensor-Modul-Temperatur-und-Feuchtigkeit-Luftdruck-Luft-Qualit-t-IAQ-MCU680-Modul/32902672818.html?spm=a2g0x.10010108.1000014.3.23ff36171JcSMM&pvid=e78fa2f1-ac7c-4b11-af0d-6665f95730e9&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.13338.107646.000000000000000&scm-url=1007.13338.107646.000000000000000&scm_id=1007.13338.107646.000000000000000)-Modul ebenso.

ZitatIch würde 30Stück auf meine Kappe nehmen (5-7 würde ich nehmen) und den Rest dann gegen Material und Porto versenden. Wenn ich mehr bestellen soll sagt mir das.

Hallo Jörg,
wäre auch mit 10 Platinen dabei.

Jürgen

ZitatWenn ich mehr bestellen soll sagt mir das.

Bin mit 4 Stk. dabei :)

ZitatD.h. man könnte dann auf den iAQ +DHT22 verzichten.

Somit dann natürlich auch auf den BME280 anstelle des DHT22.

Ich habe auch noch einen BME680 (gleiche Quelle wie Papa Romeo) hier liegen. Bisher nicht zum Einsatz gekommen, daher konnte ich vorerst auch nichts dazu sagen. Aber Jürgen hat ja dankenswerte Weise auch bereits Vergleichswerte aufgestellt. Das Gesamtdesign würde hierdurch schon schlanker (Komponentenliste) und kostengünstiger (BME680 vs iAQ+BME280) werden.

Zitat von: Starsurfer am 02 Februar 2019, 22:43:59
Echt jetzt, Geigerzähler? Wohnt ihr alle neben nen Kraftwerk?

..naja....nicht ganz 9 km Luftlinie zum AKW Grundremmingen  >:( :P

Zitat von: Papa Romeo am 03 Februar 2019, 00:20:34
..naja....nicht ganz 9 km Luftlinie zum AKW Grundremmingen  >:( :P

verstehe, Erweiterung für alpha,beta, gamma ist essentiell  :P

Zitat von: dmq am 03 Februar 2019, 00:12:30
Somit dann natürlich auch auf den BME280 anstelle des DHT22.

Ich habe auch noch einen BME680 (gleiche Quelle wie Papa Romeo) hier liegen. Bisher nicht zum Einsatz gekommen, daher konnte ich vorerst auch nichts dazu sagen. Aber Jürgen hat ja dankenswerte Weise auch bereits Vergleichswerte aufgestellt. Das Gesamtdesign würde hierdurch schon schlanker (Komponentenliste) und kostengünstiger (BME680 vs iAQ+BME280) werden.

Ich habe viele gelesen bevor ich mich entschieden habe (bme680 vs IAQ). Ja, der BME680 ist günstiger aber ich halte den AMS für den besseren (Software, Funktionalität, Stabilität). @Jürgen: was sagt der Langzeittest ?

Ich würde wohl auch 5-7 Platinen nehmen .

Wäre noch Platz für eine Pinleiste (+/-/rx/tx)?

..so in etwa...

Jep sieht gut aus, wobei 5V reichen würden für das Nextion Display.

Hallo Jörg,

ZitatIch habe viele gelesen bevor ich mich entschieden habe (bme680 vs IAQ). Ja, der BME680 ist günstiger aber ich halte den AMS für den besseren (Software, Funktionalität, Stabilität). @Jürgen: was sagt der Langzeittest ?

Eigentlich habe ich ja ein schlechtes Gewissen, wollte Deinen Thread nicht zu Gunsten des BME680 irgendwie beeinflussen.
Deine Design-Entscheidungen kann ich deshalb auch sehr gut nachvollziehen. Aber es gibt ja auch hinreichend Gründe,
ihn in die Überlegungen mit einzubeziehen.

Im Prinzip habe ich mich auch schon einige Zeit darüber kundig gemacht, wie das Thema mit welchen Sensoren am treffendsten in Hinblick Nutzen/Kosten
zu betrachten ist.

Ich muss Dir dahingehend zustimmen, dass der iAQ von AMS wirklich die bessere "Datenqualität" liefert, wobei man Datenqualität natürlich näher definieren muss.
Der AMS besitzt über seine aktiven Sensorfläche ein Filter-artiges Geflecht, welches eine Tiefpassfilter-artige Funktion ausübt.
Der BME hat eine kleine Bohrung und ist eher ungeschützt. Das erklärt, dass er wesentlich mehr auf Zugluft-Variationen reagiert und dies auch im Output zeigt.
Das ist also reine Abwägungsfrage, wie man den Output der beiden Sensoren interpretiert.
Letztendlich lassen sich beide Sensoren in etwa vergleichbar interpretieren. Wenn man die Bestückung selbst wählen kann,
ist das ja auch ein Vorteil. ;)

Auch der NCS811 von AMS wäre ein betrachtenswerter Kandidat. Allderings kam mein in China geordertes Exemplar mit abgelösten Kunstoff-Gehäuse daher.
Der Sensor war auch nicht mehr funktionsfähig. Er hatte noch ein BME280 auf dem Board. Deshalb hab ich diese Richtung nicht weiter verfolgt.

Dann bleiben also nur noch die Kostenfrage und den Benefit, den man durch zusätzliche Messstellen wie T, H und P gewinnt.
Zusätzlich könnte man noch den Platzbedarf ins Feld führen.

Für alle Sensoren ist entscheidend, wie man im Gehäuse eine saubere thermische Entkopplung hinbekommt, der Spannungsregler + ESP8266 heizen ja schon
ordentlich auf. Bei einem BME auf der LGW-Platine hatte ich 5..7 °C Offset. Von einer "genauen" Temperaturmessung kann man da trotz Abzug des Offsets nicht reden. 

Im Langzeittest hat bei mir das OLED-Display nur etwa ein Jahr gehalten und hatte dann deutliche Verwaschungs- und "Erosions"-Spuren im Erscheinungsbild.
Die Displays sind aber Spott-billig und zur Not kann man die ja bei Bedarf  schnell austauschen ...
Nachteil: In Räumen, wie z.B. Wohnzimmer oder Schlafzimmer ist die Helligkeit der OLED-Displays eher störend.
Hier lohnt sich auf alle Fälle eine Beleuchtungsabhängige Steuerung der Helligkeit.

Hat man diese Faktoren im Griff, kommt dann sehr schnell der Bedarf nach mehr Display-Funktionalität (siehe auch mein Thread) die sich dann nur
über Nextion, oder wie in meinem Fall über ein TFT-Display abhandeln lassen. Dann stößt man aber wieder an Gehäuse-Grenzen, wie man ein Display
dort integrieren könnte. Im Moment überlege ich, wie ich ein 128x160-Dsiplay hier noch per SPI mit angebunden bekomme.
Genauso habe ich hier auch ein Nextion und ein ePaper-Display hier noch herumliegen.

Letztendlich, wenn jeder seine Wünsche mit in das Projekt integriert, artet das wohl sehr schnell in eine höhere Komplexität aus,
die vielleicht nur noch von wenigen beherrschbar ist.

Momentan konstruiere ich noch die Integration des OLED-Displays in mein LGW-Gehäuse, sowie eine gut belüftete Aussparung für den BME680 Sensor.
Danach wende ich mich vom MapleMini ab und integriere die gewonnene Erfahrung  in die ES8266 Wemos-D1 Platform.
Hier gibt es meiner Ansicht nach die bessere bzw. komfortablere TFT-Library-Integration.
Da ist das Gehäuse wieder ein besonderes Kriterium, da der WA-Faktor Wohn- und Schlafzimmer geeignet sein sollte  :)

Um diese schöne Projekt nicht zu "stören", würde ich dann einfach einen neuen SpinOff-Thread dafür starten.

Prinzipiell gilt: "K-I-S-S" => Keep it simple  ;)

Dann hat der Sensor das Potenzial ein richtiger "Volks-Sensor" zu werden ...  :)

Grüße,
Jürgen

ZitatIm Langzeittest hat bei mir das OLED-Display nur etwa ein Jahr gehalten und hatte dann deutliche Verwaschungs- und "Erosions"-Spuren im Erscheinungsbild.
Die Displays sind aber Spott-billig und zur Not kann man die ja bei Bedarf  schnell austauschen ...

Auch das kann ich bestätigen. Einer meiner OLEDs war bereits nach 5 Monaten in dem Zustand. Ein anderes um die 12 Monate. Zwei weitere halten schon was länger. Ich halte mir immer ein paar auf Reserve, aber so richtig "schön" ist die Wegwerfmentalität nicht.

ZitatIch muss Dir dahingehend zustimmen, dass der iAQ von AMS wirklich die bessere "Datenqualität" liefert wobei man Datenqualität natürlich näher definieren muss.

Hätte ich auch vermutet, da es ein nur auf diese Aufgaben ausgerichtetes System ist (wie Du schon sagst: KISS - kann man also auch von 2 Seiten betrachten  ;) ).

Die Platine bietet jetzt ja im Grunde genug Möglichkeiten, sie mit den Sensoren zu bestücken, die man haben will. Der Code bietet ebenfalls eine gute Grundlage um daraus einen wunderbaren Multiroomsensor zu bauen.
Ich bin jedenfalls zufrieden 😂
Für andere Displays sollten wir dann wirklich einen neuen Threads aufmachen, ich habe hier auch noch ein paar unterschiedliche TFT s liegen.

ZitatFür andere Displays sollten wir dann wirklich einen neuen Threads aufmachen, ich habe hier auch noch ein paar unterschiedliche TFT s liegen.

Ja, bin auch immer im Disput mit Zeit, technischer Neugier und "getting things done".  ;) ;) ;)

ePaper und TFT gehen in die gleiche Richtung. Beherrschbar mit der eTFT-Lib. Nextion wäre ein Spezialfall und ich müsste mich auch hier erst
tiefer einarbeiten ... 
Denke aber, die "native" TFT-Programmierung ist zwar anfangs zeitaufwendiger, lässt aber dann alle "Freiheiten" und Nextion hat halt bereits Touch-Integration!
Das würde z.B. eine Bedienung mit RotaryEncoder sparen...

Könnte mir aber auch einen Gehäuse-Aufsatz auf Jörgs Gehäuse für ein TFT vorstellen ... ;) ;D
Wäre nur die Frage nach einer zusätzlich möglichen SPI-Integration ?
Vielleicht ein weiterer Wifi-less ESP, der an der RX/TX-Schnittstelle lauscht und das TFT bedient ...

Grüße,
Jürgen

ZitatJa, bin auch immer im Disput mit Zeit, technischer Neugier und "getting things done".   

Absolut -  :)
Wir sind ja aber hier in der Bastelecke - also genau richtig.
Sketch und fhem-module sind mit Absicht so angelegt das man da andere/weitere Funktionen so einfach wie möglich integrieren kann und ich helf da gerne.

Das die OLED altern war mir klar, so schnell hätte ich jetzt nicht gedacht. Müsste man wohl nochmal softwareseitig schauen was man da tun kann (das Dispaly möglichst wenig statisch machen) und eigentlich müsste die Konsequenz aus dem Wissen auch sein dass das Display mit Pfostensteckern austauschbar ist. Wird aber im aktuellen Gehäuse knapp ...

Für diese Variante hier halte ich die beiden Dioden für das primäre GUI, trotzdem ein guter Punkt. ..

...so könnte das mit dem steckbaren OLED funktionieren....

gute Idee! Den Rest dann halt Gehäuse-Feintuning wenn die Platine da ist ?

Zitat von: Starsurfer am 02 Februar 2019, 17:18:38
Ist das hier eigentlich ein echter BME680 (https://www.ebay.de/itm/Ultra-small-Pressure-CJMCU-680-BME680-Temperature-Humidity-Pressure-Sensor-se/283342179185?hash=item41f8828b71:g:nAYAAOSwptZcQFXM:rk:4:pf:1&frcectupt=true)

Preislich kann das sein, ich meine, da gibt es noch keine Fakes ...

Gruß Peter

Zitat von: Papa Romeo am 02 Februar 2019, 18:40:07
... hab die Platinen mal an das Gehäuse von Jörg angepasst und es stehen insgesamt fünf I2C Schnittstellen zur Verfügung.
Drei auf der Haupt- und zwei auf der Front-Platine (weiß ja nicht was ihr noch alles einbauen wollt.. ;) ;D).

Könntet Du noch eine am Rand für dieses breakout https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=114241;image (RM 1,27 mm!) einbauen?
Wenn ja, dann liefere ich die Pinbelegung nach.
Ziel: das breakout (BME680 + BH1750) um 90 ° gekippt einbauen und durch ein Loch im Gehäuse führen.

Danke + Gruß

Peter

@Papa

schmeiß doch den DHT Stecker raus, von der Position wär das mMn auch die perfekte Stelle für die Stiftleiste. Und i2c liegen eh schon da ...

Zitat von: Starsurfer am 02 Februar 2019, 22:43:59
Echt jetzt, Geigerzähler? Wohnt ihr alle neben nen Kraftwerk? 😁

Ja, GKN 1 wird gerade abgebaut. Ob das besser ist als der Betrieb muss sich erst noch herausstellen  ;).

Zitat von: Papa Romeo am 03 Februar 2019, 00:20:34
..naja....nicht ganz 9 km Luftlinie zum AKW Grundremmingen  >:( :P

Ok, jetzt weiß ich, wo in Süddeutschland ...

Zitat von: juergs am 02 Februar 2019, 22:48:59
Allerdings macht PeMue (https://forum.fhem.de/index.php/topic,78619.msg896963.html#msg896963) schon ein passendes Breakout mit BME680 + BH1750 (LUX). Diese Variante würde ich besser empfehlen.

Du setzt mich ganz schön unter Zugzwang.

ZitatPCBs in processing.

Mal sehen, ob sie die Platine vor dem Chinesischen Neujahr rausschicken.

Zitat von: herrmannj am 02 Februar 2019, 22:16:47
Ich würde 30 Stück auf meine Kappe nehmen (5-7 würde ich nehmen) und den Rest dann gegen Material und Porto versenden.

Ich nehme dann mal 2 Platinen, aber nur wenn es einen Schaltplan gibt und ich mein breakout verbauen kann  8) 8) 8)

Gruß Peter

Zitat von: herrmannj am 03 Februar 2019, 19:32:35
@Papa

schmeiß doch den DHT Stecker raus, von der Position wär das mMn auch die perfekte Stelle für die Stiftleiste. Und i2c liegen eh schon da ...

ok..ich schau mir´s an...

Zitat von: PeMue am 03 Februar 2019, 19:49:24
Ja, GKN 1 wird gerade abgebaut. Ob das besser ist als der Betrieb muss sich erst noch herausstellen  ;).
Gruß Peter

Unseres in Stade wird auch schon seid ein paar Jahren abgebaut und fertig sind sie noch lange nicht  :o

Hast du schon einen ungefähren Preis für dein Breakout Board?

Zitat von: Starsurfer am 03 Februar 2019, 20:00:29
Hast du schon einen ungefähren Preis für dein Breakout Board?

12,81 €  ;D ;D ;D

Zitat von: PeMue am 03 Februar 2019, 20:03:44
12,81 €  ;D ;D ;D

Ha, Peter, da liegst Du aber unter den Produktions- ähm Materialkosten ...  ;) ;D

Was kostet der BH1750?

Jürgen

Hallo Zusammen,
versuche gerade die LIB mit meiner Arduino-Installation irgendwie erfolgreich zum Laufen zu bringen.
Bin leider bisher gescheitert.
"...\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.0-rc1\libraries"
Dooferweise wird ein "Uninstall" der Lib "ESP8266Wifi" nicht angezeigt.

Würde gerne den BME680 Code erstellen, aber ungern meine Rest-Installationen verlieren wollen und neu installieren  :'(

über den Boardmanager. Es gibt aber schon 2.5.0-beta3

Wie hast Du das denn eingebunden ?

Zitat von: PeMue am 03 Februar 2019, 19:16:53
Könntet Du noch eine am Rand für dieses breakout https://forum.fhem.de/index.php?action=dlattach;topic=78619.0;attach=114241;image (RM 1,27 mm!) einbauen?
Wenn ja, dann liefere ich die Pinbelegung nach.
Ziel: das breakout (BME680 + BH1750) um 90 ° gekippt einbauen und durch ein Loch im Gehäuse führen.

...eine weitere I2C-Buchse im 1,27 mm Raster ist kein Problem aber ich brauche dann die Pin-Belegung des Breakout-Boards

"..aber ich brauche dann die Pin-Belegung des Breakout-Boards"

Mir ist nich ganz klar wie die Sichtweise auf die Platine ist.

Ich glaube sie entspricht dem Jumper J1-2 der LGW-Platine. Das wäre in diesem Fall:

• SDA
• SCL
• GND
• VCC

nur wie rum ....  ???

Pin 1 BH1750 = Vcc
Pin 1 + 7  BME680 = GND
Pin 8 + 6  BME680 = Vcc
Pin 2 BME680 = CSB
Pin 3 BME680 = SDA
Pin 4 BME680 = SCL

btw, ich bestelle mir eine bme680 und binde den ein

Zitatüber den Boardmanager. Es gibt aber schon 2.5.0-beta3
Wie hast Du das denn eingebunden ?

Habe leide eine noch ältere 2.4.0 RC1-Installation, die ESP8266Wifi-Lib will einfach nicht. 
Es wir mir nichts anderes übrigbleiben, als komplett neu zu installieren ....
Habe aber noch eine 2te Installation als Reserve ...

// edit: Ein Reboot löste das Problem ... tsss

Hier (https://forum.fhem.de/index.php/topic,78619.msg877169.html#msg877169) die zusammengefasste Einbindungs-Methode von hdgucken.
https://github.com/BoschSensortec/BSEC-Arduino-library (https://github.com/BoschSensortec/BSEC-Arduino-library)

Grüße,
Jürgen

es gibt auch eine adafruit lib. Spricht da was gegen ? https://github.com/adafruit/Adafruit_BME680

Zitat von: herrmannj am 03 Februar 2019, 21:45:05
es gibt auch eine adafruit lib. Spricht da was gegen ? https://github.com/adafruit/Adafruit_BME680

Mein letzter Wissensstand war, sie liefert die nur den GAS-Resitance Wert, aber nicht den IAQ-Wert.
Der ist meiner Meinung nach eher unbrauchbar ... Den BSEC-IAQ-Algorithmus hält Bosch unter Verschluss.

Der wir nur mit der Einbindung der statische vorkompilierte Lib libalgosec.a über den ESP-Linker erreicht.
Ist aber kein großer Act ... siehe oben den Hinweis auf hdguckens readme.

Der iaq2-Compile mit der ESP8266 2.5.0-3 funktioniert jetzt. Muss aber das Procedere für den BME ebenfalls dort einbauen...

Jürgen

Zitat von: Papa Romeo am 03 Februar 2019, 20:34:38
...eine weitere I2C-Buchse im 1,27 mm Raster ist kein Problem aber ich brauche dann die Pin-Belegung des Breakout-Boards

siehe Bilder, Pin 1 liegt oben, wenn das breakout links seitlich rausschaut.

Zitat von: juergs am 03 Februar 2019, 20:19:40
Was kostet der BH1750?

0,89 €. Naja, ich würde dann großzügig aufrunden  :)

Zitat von: juergs am 03 Februar 2019, 21:02:15
Pin 1 BH1750 = Vcc
Pin 1 + 7  BME680 = GND
Pin 8 + 6  BME680 = Vcc
Pin 2 BME680 = CSB
Pin 3 BME680 = SDA
Pin 4 BME680 = SCL

siehe angehängten Schaltplan.

Gruß Peter

...und warum nicht nach hinten rausschauen lassen ? Wäre unauffälliger.

wäre vmtl für den BH1750 ungünstig ...

,,, unkommentiert.

Zitat von: herrmannj am 03 Februar 2019, 22:33:10
wäre vmtl für den BH1750 ungünstig ...

...ist es auf der Rückseite des Gehäuses dunkler wie rechts und links ?

...wenn es links rausschauen soll, heißt das, dass die DHT-Halterung weg kommt.

Weiterhin sind, durch dem Einsatz des BH1750, dann auch der 330 Ohm Widerstand und die beiden LDR´s auf der Frontplatte passe...oder?

Wie soll das Breakout-Board mit der Platine verbunden werden ? 

Über Kabel ? --> Pinbelegung / Rastermaß der I2C-Buchse ist dann eigentlich "Wursch´d"

Fest, stehend ? (Aussagen: 90 Grad gedreht, Pin 1 ist oben) über gewinkelte Pfostenstecker mit der Hauptplatine --> Platine muss bis zur linken Gehäuse-Innenwand erweitert werden und die genaue Position des Breakout´s ist erforderlich bzw. passt Joerg dann den Ausschnitt im Gehäuse an die Platine an.

Zitat,, unkommentiert.

etwas auf der seriellen Ausgabe erkennbar oder warum bricht der am Nachmittag ab?

Zitat von: Papa Romeo am 04 Februar 2019, 07:44:24
...ist es auf der Rückseite des Gehäuses dunkler wie rechts und links ?

Vermutlich ja, wenn der Sensor in einer Schrankwand steht. Wenn er an der Wand hängt nicht.

Zitat von: Papa Romeo am 04 Februar 2019, 07:44:24
... wenn es links rausschauen soll, heißt das, dass die DHT-Halterung weg kommt.

Ich habe mir das Gehäuse nicht angeschaut, es geht auch an jeder anderen Seite (bis vielleicht auf hinten). Mein Kommentar ist so zu verstehen, dass wenn links, dann ist Pin 1 oben. Bei den anderen Seiten eben analog dazu.

Zitat von: Papa Romeo am 04 Februar 2019, 07:44:24
Wie soll das Breakout-Board mit der Platine verbunden werden ? 

Fest, stehend ? (Aussagen: 90 Grad gedreht, Pin 1 ist oben) über gewinkelte Pfostenstecker mit der Hauptplatine --> Platine muss bis zur linken Gehäuse-Innenwand erweitert werden und die genaue Position des Breakout´s ist erforderlich bzw. passt Joerg dann den Ausschnitt im Gehäuse an die Platine an.

Über 90 ° Pinleiste, möglichst am Rand der Platine, die Tiefe justiert man dann mit der Lötung an den "rausstehenden" Pins.

Gruß Peter

Zitat von: PeMue am 04 Februar 2019, 08:13:54
Mein Kommentar ist so zu verstehen, dass wenn links, dann ist Pin 1 oben. Bei den anderen Seiten eben analog dazu.

...links, von vorn auf das Gehäuse gesehen ? Wenn ich dein Beakout aber anschaue, dann wäre Pin1 doch unten oder schauen die Sensoren nach hinten ?

Zitat von: PeMue am 04 Februar 2019, 08:13:54
Über 90 ° Pinleiste, möglichst am Rand der Platine, die Tiefe justiert man dann mit der Lötung an den "rausstehenden" Pins.

Das mit den "rausstehenden Pins" ist mir nicht ganz klar.

...wäre es nicht vielleicht sinnvoll  wenn Joerg am Gehäuse links eine "Einbuchtung" ähnlich der Frontplatte und des OLED macht, wo man dann das Breakout einsetzen kann.
Man könnte man es plan mit dem Gehäuse machen und wäre nicht gleich sichtbar.

Kann ich gerne machen, aber vergesst die thermische Entkopplung nicht.

Der DHT lag ja in so eine Bucht und das hat nicht funktioniert weil er trotzdem noch ca 2°-3° von den inneren Bauteilen mitbekommen hat.

Für die BME280 / BME680 Breakout boards habe ich jetzt eine abgeschlossene Kammer gemacht die zur Not auch eine dünne Isolationsschicht verträgt. Ob das Notwendig ist sehe ich erst wenn es aus dem Drucker kommt und ich Messwerte habe. Da sind auch Schraubbefestigungen für BME drin, die Verbindung zur Hauptplatine per Kabel. Die Kammer wird gesteckt und kann bei einem Breakoutboard das mit Pfostensteckern befestigt wird weggelassen werden, da sind ja direkt die Gehäuseöffnungen. Da wird man dann aber wieder thermische Probleme bekommen vermute ich ...

...könnte man nicht schon den WEMOS und den Linearegler im Gehäuse schon etwas abschotten.
Durch Stege am Boden und im Deckel. (siehe weiße Linie um den WEMOS)

sicher, aber in meinem Prototypen ist der Linearregler nicht drin und der MHZ und der IAQ produzieren auch Wärme. (IR Thermo, ca 30° Oberfläche).

Das ist ja der Hauptpunkt warum der DHT rausfliegt, weil man die BME besser abschotten kann.

Ich bin da für alles offen. Ich wollte das eher als Hinweiß an PeMue geben, das ist halt so ein Ding was man erst sieht/erkennt wenn man alles ins Gehäuse baut. Dafür ja auch der Prototyp

Wie wäre es den, wenn der mh-z oben aus dem Gehäuse guckt, so wie hier z.b
https://blog.moneybag.de/wp-content/uploads/2018/03/mh-z19-case.jpg (https://blog.moneybag.de/wp-content/uploads/2018/03/mh-z19-case.jpg)

kann man, aber da sehe ich jetzt keine Notwendigkeit ... ?

Zitat von: herrmannj am 04 Februar 2019, 12:30:26
sicher, aber in meinem Prototypen ist der Linearregler nicht drin und der MHZ und der IAQ produzieren auch Wärme. (IR Thermo, ca 30° Oberfläche).

...klar, dann macht das abschotten so keinen Sinn.

Zitat von: herrmannj am 04 Februar 2019, 12:52:12
kann man, aber da sehe ich jetzt keine Notwendigkeit ... ?

Um ein bißchen wärme aus dem Gehäuse zu bekommen?

Zitatbißchen wärme

5V und angenommen 500mA sind 2,5 W. Das ist ordentlich!  ;)

Na dann wäre es doch nicht so "unsinnvoll", den aus dem Gehäuse zu befördern?
Wäre jetzt auf jedenfall mein Gedanke, muss aber natürlich nicht.

Die Intention ist schon klar, nur: der MH-Z19 hat ja an der Seite eine 2te Öffnung, man müsste den noch höher setzen. Jetzt noch Breakout Boards sichtbar nach außen. Mir schwebte eigentlich eher was Wohnzimmer taugliches vor.

Ich bin optimistisch das man das besser schafft. Das Gehäuse hat schon sehr viele Lüftungsdurchlässe. Ich habe hinten links die Durchbrüche nochmal vergrößert, da kommt die "Kammer" für BME etc hin. Bauteile außen, ich finde das machen wir erst wenn wirklich alles andere versagt hat  ;)

Jep kein Problem :-)
So ist das doch auch Wohnzimmer tauglich :-D

yep...is auch hübsch.. ;)

Zitat von: herrmannj am 04 Februar 2019, 15:35:34
... man müsste den noch höher setzen.

...würde ihn eh steckbar machen...dann ist er etwa 8mm höher...

Ist aber nicht von mir, aber schaut mal auf den Preis :o
https://www.reichelt.de/starterkit-wetterstation-transparent-tf-skit-ws1-p136175.html (https://www.reichelt.de/starterkit-wetterstation-transparent-tf-skit-ws1-p136175.html)

schade, wollte Dich gerade fragen ob Du Plexiglas connections hast.

Wobei, auch an dieser Stelle nochmal ein besonderer Dank an UweH der mich schon mit einer Ladung Frontplatten versorgt hat.

Zitat von: Starsurfer am 04 Februar 2019, 15:51:01
Ist aber nicht von mir, aber schaut mal auf den Preis :o
https://www.reichelt.de/starterkit-wetterstation-transparent-tf-skit-ws1-p136175.html (https://www.reichelt.de/starterkit-wetterstation-transparent-tf-skit-ws1-p136175.html)

..ok...nicht mehr ganz so hübsch.... ;D ;) ::)

Irgendwie will mich der Wemos ärgern,
ich habe jetzt noch mal eben das Script hochgeladen, was auch alles ohne Fehler funktioniert hat. Ich sehe das WLAN vom Wemos, kann mich damit verbinden, aber er spannt kein AP auf um das WLAN einzurichten.
Hat das Problem schon jemand gehabt?
Ich habe auch schon mit einer leeren Datei alles überschrieben, aber nichts. Im Serielen Monitor sehe ich nur Kauderwelsch mit 115200 Baud.

@Starsurfer:
Mit was flasht Du denn?
Hatte das gleiche Phänomen wie Du mit dem ESP8266Flasher.
Aus Verzweiflung habe ich einfach einen Sample-Sketch geflasht -> ging.
Dann den Aufruf der Arduino Ide  genommen und mit dem neuen Binary geflasht und siehe da, ging alles wieder mit AP usw.

Hier ein Beispiel unter Win10:

C:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\tools\esptool\0.4.9\esptool.exe -vv -cd nodemcu -cb 115200 -cp COM13 -ca 0x00000 -cf "D:\fhem\_fhem-5.9\contrib\arduino\36_LaCrosse-LaCrosseITPlusReader\firmware\JeeLink_LaCrosse.hex"

Anbei noch eine andere Variante. Auf die Adressen achten!

ZitatIch sehe das WLAN vom Wemos, kann mich damit verbinden, aber er spannt kein AP auf um das WLAN einzurichten.

Verstehe ich jetzt nicht. Wie kannst Du dich damit verbinden, wenn er keinen AP-Mode bietet? Oder meinst Du mit zuvor konfigurierter SSID als WLAN-Station?

Versuche bitte ansonsten mal ein ESPurna, Tasmota, ESPEasy zu flashen: gleiches Verhalten?

Ich habe in meinem Bestand leider auch einen Wemos der (zumindest für mich) absolut unberechenbar reagiert. 1. Boot: SSID, 2. Boot: keine SSID usw.

@PeMue
sehe ich das richtig: plus / minus ist in Deiner neuen BreakoutBoard-Variante vertauscht? (zu meinen Angaben, die sich auf LGW1.32 beziehen).
Frage deshalb, weil der Bestückungsdruck auf dem Board ein Plus für GND hergibt?
Das wäre dann auch auf der neuen LGW-Platine so?

Grüße,
Jürgen

Wenn die Rede vom Sketch ist, da ist ein super kurzes timeout für den wifimanager hinterlegt. Irgendwo im Setup, auch Mal nach timeout

// uncomment and run it once, if you want to erase all the stored information
  // wifiManager.resetSettings();

wifiManager.setTimeout(1); // TODO !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Habe jetzt testweise das AutoconnectwithoutTimout aus der WiFiManager Bibliothek geflasht, und da funktioniert alles.
Espeasy funktioniert auch ohne Probleme.
Geflasht mit der Arduino IDE.

Ich kann mich mit dem WLAN des Wemos verbinden aber die Setup Seite kommt nicht und unter 192.168.4.1 erhalte ich keine Verbindung.

Ich werde jetzt mal nach und nach die Sachen aus der iaq2.ino in das Beispielscript einbauen, mal sehen ob ich den Fehler finde.

Schreib Mal beim timeout 90 Sekunden rein.

Ich glaube es war auch nicht die 192.168.4.1, sondern eine 192.168.221.1 o.ä.

So, ich habe mal versucht die BOSCH-BSEC-Lib mit der 

Zitathardware\esp8266\2.5.0-beta2\tools\sdk\lib

zu konfigurieren:

Die Anleitung galt ja für die V2.4.0:

############################################
# Einbinden der BSEC Software für ESP8266: #
# Stand: 09.01.2018                        #
# ESP8266 Paket V2.4.0                     #
# BSEC V1.4.5.1                            #
############################################

1. Die "libalgobsec.a" muss nach "\Users\[Benutzername]\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.0\tools\sdk\lib\ kopiert werden !
    Das ist die "precompiled Lib" von Bosch Sensortec.

2. Die Linker Datei "hardware\esp8266\2.4.0\tools\sdk\ld\eagle.app.v6.common.ld" muß angepasst werden:
    nach der Zeile "*libm.a:(.literal .text .literal.* .text.*)" , die Zeile "*libalgobsec.a:(.literal .text .literal.* .text.*)" einfügen.

3. Als letztes muss noch ein Parameter in der Datei "hardware\esp8266\2.4.0\platform.txt" hinzugefügt werden:
    am Ende der Zeile "compiler.c.elf.libs= ... -lm -lgcc" folgendes anfügen " -lalgobsec" .


Änderungen:

1.) Die "libalgobsec.a" muss nach "\Users\[Benutzername]\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0-beta2\tools\sdk\lib\ kopiert werden !
    Das ist die "precompiled Lib" von Bosch Sensortec.

2.) in die Linker Datei
eagle.app.v6.common.ld.h
im Verzeichnis

Zitat"hardware\esp8266\2.5.0-beta2\tools\sdk\ld\

... nach der Zeile
"*libm.a:(.literal .text .literal.* .text.*)"

die Zeile

"*libalgobsec.a:(.literal .text .literal.* .text.*)"

einfügen.

3. Als letztes muss noch ein Parameter in der Datei "hardware\esp8266\2.5.0-beta2\platform.txt" hinzugefügt werden:
    am Ende der Zeile "compiler.c.elf.libs= ... -lm -lgcc" folgendes anfügen " -lalgobsec" .

Dann sollte bei einem Compile + Linkerlauf, ähnlich diesem Beispiel-Output folgende Info stehen:
(steht alles in einer Zeile!)

Zitat"C:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9/bin/xtensa-lx106-elf-gcc" -Wl,-Map
"-Wl,C:\Users\<user>\AppData\Local\Temp\arduino_build_984070/bsec_iot_example.ino.map" -g -Wall -Os -nostdlib -Wl,--no-check-sections -u app_entry -u _printf_float -u _scanf_float -Wl,-static
"-LC:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0-beta2/tools/sdk/lib" "-LC:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0-beta2/tools/sdk/ld"
"-LC:\Users\<user>\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0-beta2/tools/sdk/libc/xtensa-lx106-elf/lib"
"-Teagle.flash.4m.ld" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read  -o "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070/bsec_iot_example.ino.elf"
-Wl,--start-group "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\bme680.c.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\bme680_calculations.c.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\bsec_integration.c.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\RFMxx.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\SensorBase.cpp.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\sketch\bsec_iot_example.ino.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Wire\Wire.cpp.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\SPI\SPI.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Adafruit_GFX\glcdfont.c.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Adafruit_GFX\Adafruit_GFX.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\AS_BH1750\AS_BH1750.cpp.o" "C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\libraries\AS_BH1750\AS_BH1750A.cpp.o"
"C:\Users\<user>\AppData\Local\Temp\arduino_build_984070\core\core.a" -lhal -lphy -lpp -lnet80211 -llwip2-536-feat -lwpa -lcrypto -lmain -lwps -lbearssl -laxtls -lespnow -lsmartconfig -lairkiss
-lwpa2 -lstdc++ -lm -lc -lgcc  -lalgobsec -Wl,--end-group 
"-LC:\Users\<user>\AppData\Local\Temp\arduino_build_984070"

wollen wir uns nicht doch auf den IAQ core einigen ?  ;)

Zitatwollen wir uns nicht doch auf den IAQ core einigen ?

Ja, Du hast recht und die Lib presst det Janze noch in ein eigenes Code-Korsett mit Callback-Funktionen ...  :D
Sind doch nur 3 Sachen .... und die Bosch'ler leiten eine Ära der 3rd-Party Libs ein... schade!

Was ich bis jetzt noch nicht sagen kann, ist, ob das erfoderliche Timing, mit dem auch HCS in der LGW zu kämpfen hatte,
in dieser Form ausreichend ist ... Optimismus!  ;D :D ;)

Dann fange ich mal an auf- und umzubauen ...

Eine Klugsch**er-Anmerkung noch zum Gehäuse: Kamineffekt, also von unten vorne nach oben hinten bzw. zur Sensor abgewandten Seite .... 

Grüße,
Jürgen

Zitat von: Papa Romeo am 04 Februar 2019, 08:45:17
... links, von vorn auf das Gehäuse gesehen? Wenn ich dein Beakout aber anschaue, dann wäre Pin1 doch unten oder schauen die Sensoren nach hinten?

Das breakout steht quasi auf dem Kopf, siehe auch Bild (mit juergs breakout von OSHPark im 2,54 mm Raster).

Zitat von: Papa Romeo am 04 Februar 2019, 08:45:17
Das mit den "rausstehenden Pins" ist mir nicht ganz klar.

Die 90 ° Stifleisten werden so eingelötet, dass die lange Seite (im Bild) nach links raussteht. Dann kann man die Tiefe der Platine im Loch im Gehäuse variieren und die Pins nach dem Anlöten abknipsen.
Bei Bedarf kann man auch ganz lange gerade Stiftleisten nehmen und das breakout oben rausstehen lassen.

Ich hoffe, jetzt wird es ein bisschen klarer.

ZitatIch hoffe, jetzt wird es ein bisschen klarer.

Ahhh  :D ;D

So habe jetzt nochmal alles neu runtergeladen in den Sketchordner gepackt und auf den Wemos geflasht, wieder das gleiche, keine Setup Seite....
Ich gebe es für heute auf.

Zitat von: juergs am 04 Februar 2019, 19:41:45
@PeMue
sehe ich das richtig: plus / minus ist in Deiner neuen BreakoutBoard-Variante vertauscht? (zu meinen Angaben, die sich auf LGW1.32 beziehen).
Frage deshalb, weil der Bestückungsdruck auf dem Board ein Plus für GND hergibt?
Das wäre dann auch auf der neuen LGW-Platine so?

ja, aber ich schaue noch mal nach *unsicher werd*  ::) ::) ::) siehe Bild.

Gruß Peter

ZitatWas ich bis jetzt noch nicht sagen kann, ist, ob das erfoderliche Timing, mit dem auch HCS in der LGW zu kämpfen hatte,
in dieser Form ausreichend ist

Timing speziell zum BME680? Mir ist da nichts bekannt (darüber hinaus).

ZitatTiming speziell zum BME680? Mir ist da nichts bekannt (darüber hinaus).

Denke aber auch, dass es passen wird....

Zitat von: Starsurfer am 04 Februar 2019, 21:13:42
Ich gebe es für heute auf.

Da gibt es irgendwo die ESPTools für Windows (falls Du einen Windows Rechner hast) und damit kannst Du den kompletten WeMos löschen (Stichwort Kinzer oder Klippel).

Gruß Peter

@PMue:

Ich glaube sie entspricht dem Jumper J1-2 der LGW-Platine. Das wäre in diesem Fall:

    SDA
    SCL
    GND
    VCC

Ok, muss man sich merken: ;D

    SDA
    SCL
    VCC
    GND

https://www.esp8266.com/wiki/doku.php?id=loading_firmware (https://www.esp8266.com/wiki/doku.php?id=loading_firmware)
Kannte ich auch noch nicht ...  :)

Zitat von: PeMue am 04 Februar 2019, 21:08:35
Das breakout steht quasi auf dem Kopf, siehe auch Bild (mit juergs breakout von OSHPark im 2,54 mm Raster).
Die 90 ° Stifleisten werden so eingelötet, dass die lange Seite (im Bild) nach links raussteht. Dann kann man die Tiefe der Platine im Loch im Gehäuse variieren und die Pins nach dem Anlöten abknipsen.
Bei Bedarf kann man auch ganz lange gerade Stiftleisten nehmen und das breakout oben rausstehen lassen.

Ich hoffe, jetzt wird es ein bisschen klarer.

ok...PeMue...jetzt isses klar....dachte immer das Breakout soll "stehend" rein ( --> Pin1 ist oben...)

... die Verstellmöglichkeit könnte ich auch mit mehreren Lochreihen im 1,27 mm Raster machen....

...so wie es reinkommen soll, würde das auch dem Vorschlag einer Einbuchtung im Gehäuse entgegenkommen.

Zitat von: juergs am 04 Februar 2019, 21:02:06
Was ich bis jetzt noch nicht sagen kann, ist, ob das erfoderliche Timing, mit dem auch HCS in der LGW zu kämpfen hatte, in dieser Form ausreichend ist ... Optimismus!  ;D :D ;)

Ich denke, HCS hatte das Thema, dass er parallel Messages dekodieren musste.

Zitat von: juergs am 04 Februar 2019, 21:23:08
@PeMue:

Ich glaube sie entspricht dem Jumper J1-2 der LGW-Platine. Das wäre in diesem Fall:

    SDA
    SCL
    GND
    VCC

Ja, der 2,54 mm Jumper J1-2 hat exakt diese Belegung. Warum die 1,27 mm Variante eine andere Belegung hat, musst Du den Layouter fragen  ::) ::) ::). Absolut kein Sinn für Vereinheitlichung, man bekommt einfach keine guten Leute mehr  8) 8) 8)

Gruß Peter

Zitatman bekommt einfach keine guten Leute mehr  8) 8) 8)

Gruß Peter

Ja, ja schon klar  ;D ;D ;D ;D

Zitat:
"... just to confuse the russians"

@juergen

ich habe mir die adafruit lib für den bme280 genau angeschaut, die ist fast ein zu eins die Referenz Implementierung von Bosch. Für den BME680 habe ich mir nur das Interface angeschaut, Du hast recht, Temp,Hum,Pres und Resistance. Kein Wunder wenn ich mir die Klimmzüge anschaue mit den libs ...

Frage: die Resistance für VOC stellt ja die VOC dar. Hältst Du es für denkbar aus der Resistance des BME680, mit Hilfe der Werte vom AMS als Referenz, die Werte so aufzubereiten das dann da auch ppm rauskommt ? Die Kurven sahen in Deinen Plots ja ähnlich aus.

Also, den BME per adafruit einbinden, mit Hilfe des AMS Umrechnungsfaktor finden und ready ?

Moin,
habe mich heute morgen noch einmal darangesetzt und das Script von Anfang an neu aufgebaut. Jetzt funktioniert das WLAN Einrichten wieder und er sendet wieder Daten.
Eingebaut habe ich momentan nur den Mh-z und den BME280.
Allerdings habe ich mit dem senden der BME Daten ein Problem:
T:IAQC;FW:1.0;ID:178FA2;IP:192.168.178.176;R:-86;F:TH_A;T:22.8;H:;P:1025.2;
Wie man sieht ist H leer.

Hier der Code dafür, aufgebaut auf dem DHT Code:
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// BME280
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

char BMEMsg[512];
char str_temp[6];
char str_hum[6];
char str_press[6];

void getBMEReadings() {
  float h = bme.readHumidity();
  float t = bme.readTemperature();
  float p = bme.readPressure() / 100.0F;
  if (isnan(t) || isnan(h) || isnan(p)) {
    prevBMEMillis = millis() - intervalBME + 2000;  // retry in 2 sec
  } else {
    dtostrf(h, 3, 1, str_hum);
    dtostrf(t, 3, 1, str_temp);
    dtostrf(p, 3, 1, str_press);
    sprintf(BMEMsg, "F:TH_A;T:%s;H:%s;P:%s;", str_temp, str_hum, str_press);
  };
};

Also habe ich eine Debug Ausgabe für die Serielle Konsole eingebaut:
void printBMEValues() {
    Serial.print("Temperature = ");
    Serial.print(bme.readTemperature());
    Serial.println(" *C");

    Serial.print("Pressure = ");

    Serial.print(bme.readPressure() / 100.0F);
    Serial.println(" hPa");

    Serial.print("Approx. Altitude = ");
    Serial.print(bme.readAltitude(SEALEVELPRESSURE_HPA));
    Serial.println(" m");

    Serial.print("Humidity = ");
    Serial.print(bme.readHumidity());
    Serial.println(" %");

    Serial.println();
}

Ausgabe:
Temperature = 22.94 *C
Pressure = 1025.29 hPa
Approx. Altitude = -99.75 m
Humidity = 30.84 %

Humidity ist also da.

2. Welche Datei muss ich im FHEM Ordner anpassen/erweitern damit die Werte in FHEM angelegt werden, 10_SLinkTH.pm?

Hallo Jörg,

ZitatFrage: die Resistance für VOC stellt ja die VOC dar. Hältst Du es für denkbar aus der Resistance des BME680, mit Hilfe der Werte vom AMS als Referenz, die Werte so aufzubereiten das dann da auch ppm rauskommt ? Die Kurven sahen in Deinen Plots ja ähnlich aus.
Also, den BME per adafruit einbinden, mit Hilfe des AMS Umrechnungsfaktor finden und ready ?

die Überlegung war ja naheliegend. Es haben sich schon einige versucht.
Ich glaube, mit genug Time & Material würde das auch machbar sein, nur fehlt es mir daran  :'(

Komme vermutlich erst am WoE dazu mich um die Implementierung zu kümmern.

Jürgen

Hallo Starsurfer

warum bei Dir kein Hum ankommt wundert mich. Ich bin noch dabei den Sketch auf Wemos anzupassen (u.a.) aber hier ist der sketch mit dem ich den BME teste, Du müsstest die Signatur im sprintf wieder auf die gleiche wie beim DHT setzen (F:THP zu F:TH_A und pressure raus) dann hast Du die Daten in fhem (10_SlinkIAQC.pm). Anpassungen wären sonst in SLink und SLinkIAQ - aber lass, ist ja sowieso noch "under construction".

btw: wie genau stimmen Deinen HUM Werte? Ich habe eine konstanten offset von 7% ...

Testsketch
// WEMOS D1 mini: Arduino Board Lolin/Wemos D1 R2 & mini
// Libs:
// Adafruit unified sensor library
// Adafruit BME280 library

// uncomment for Serial debugging statements
#define DEBUG_SERIAL

#ifdef DEBUG_SERIAL
#define DEBUG_BEGIN Serial.begin(115200)
#define DEBUG_PRINT(x) Serial.println(x)
#else
#define DEBUG_PRINT(x)
#define DEBUG_BEGIN
#endif

#include <Adafruit_BME280.h>
#include <Wire.h>
#include <Adafruit_Sensor.h>

// timer vars
// Signal LED
unsigned long prevLedMillis     = millis(); // counter main loop for signaling led
unsigned long prevBme280Millis  = millis(); // counter main loop for BME 280
unsigned long prevIaqMillis     = millis(); // counter main loop for iaq
unsigned long prevMhz19Millis   = millis(); // counter main loop for MH-Z19
unsigned long prevLdrMillis     = millis(); // counter main loop for LDR
unsigned long sigLedOn          = 50;       // ms for led on
unsigned long sigLedOff         = 450;      // ms for led off
unsigned long intervalBme280    = 10000;    // default
unsigned long intervalIaq       = 10000;    // default
unsigned long intervalMhz19     = 10000;    // default
unsigned long intervalLdr       = 1000;     // default
unsigned long intervalLed       = 0;        //

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// BME 280
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
char bme280Msg[64];   // ie.
Adafruit_BME280 bme;  // I2C
char str_temp[6];
char str_hum[6];
char str_pressure[16];

void getBme280Readings() {
  float t = bme.readTemperature();
  float h = bme.readHumidity();
  float p = bme.readPressure();
  //display.setTempHum(t, h);
  dtostrf(t, 4, 1, str_temp);
  dtostrf(h, 4, 1, str_hum);
  dtostrf(p / 100.0F, 3, 1, str_pressure);
  sprintf(bme280Msg, "F:THP;T:%s;H:%s;P:%s;", str_temp, str_hum, str_pressure);
  DEBUG_PRINT(bme280Msg);
};

void setup() {
 
  DEBUG_BEGIN; //for terminal debugging
  DEBUG_PRINT();

  // Enable I2C for Wemos D1 mini SDA:D2 / SCL:D1
  Wire.begin(D2, D1);
  Wire.setClockStretchLimit(1000); // Default is 230us, see line78 of https://github.com/esp8266/Arduino/blob/master/cores/esp8266/core_esp8266_si2c.c
  Wire.setClock(1000000L);

  if (! bme.begin(0x76, &Wire)) {
    DEBUG_PRINT("Could not find a valid BME280 sensor, check wiring and address!");
  };
 
};

void loop() {

  unsigned long currentMillis = millis();
 
  if (currentMillis - prevBme280Millis > intervalBme280) {
    prevBme280Millis = currentMillis;
    getBme280Readings();
  };
 
};


Habe das mal eingebaut und lade gerade hoch und teste das mal.
Habe mittlerweile auch den MAX4009 Lichtsensor eingebaut und funktioniert, wird auch in FHEM angelegt, da ich den LDR Code dafür nutze.
Die Luftfeuchtigkeit liegt mit knapp 8% daneben, gegen ein TX29DHT, der ein paar cm weiter weg steht.
Ein zweiter BME280 mit espeasy am Nodemcu liegt nur mit knapp 4% daneben, der liegt fast neben den Wemos.

Habe die Datei mal angehängt, die includes am Anfang sind auch deutlich weniger geworden :-)


Nachtrag:
Jetzt habe ich Luftfeuchtigkeit:
T:IAQC;FW:1.0;ID:178FA2;IP:192.168.178.176;R:-84;F:CO2;C:519;
T:IAQC;FW:1.0;ID:178FA2;IP:192.168.178.176;R:-84;F:TH_A;T:22.8;H:31.7;P:10.3;


Hallo Jürgen,

ja, ist kein revolutionärer Gedanke ...  ;)

Hier habe ich was gefunden: https://forums.pimoroni.com/t/bme680-observed-gas-ohms-readings/6608/15

Die Theorie vom user "Billy_the_nid", die ich plausibel finde, lautet so:

Die Werte werden hauptsächlich von Alterung, den Heating settings und der Luftfeuchte beeinflusst.
"Alterung" ist klar -> "automatic baseline correction"
"Heating" -> haben wir in der Hand wobei ich eh nicht genau verstehe warum man das anpassen kann. Genauer: was bewirkt das, warum genau dreht man da.
"Humitidy" -> da hat er sogar eine Formel zur Korrektur (die verstehe ich aber noch nicht)

Mein BME680 kommt auch erst Ende der Woche. Den habe ich sowieso nur bestellt damit ich das auch supporten kann. Ich nehme den mal zum testen. Wenn die Anpassung mit PEMue an den Platinen fertig ist dann bestelle. Bis die dasind ist der BME schon mal eingebrannt, dann bauae ich einen zum Datensammeln draussen auf.

Dort erwarte ich dann konstante und niedrige VOC, das heist ein/wei Wochen Daten sammeln und loggen und wenn der Wettergott es gut meint hat man dann bei konstantem VOC genügend Feuchteschwankungen um, vielleicht, zu sehen wir sich das auswirkt. Im nächsten Schritt würde es dann darum gehen ob man eine Formel findet das zu korrigieren. Zeitleiste also x Wochen plus.

Parallel, bzw lange vorher, hast Du die Bosch libs laufen.

An alle die still oder laut mitlesen: nehmt einen AMS ... (den habe ich am Tag nach einer Party(!) erstmals in Betrieb genommen. Zeit vom Öffnen der Verpacken bis Daten in fhem unter 60 Minuten ....)

ZitatDie Luftfeuchtigkeit liegt mit knapp 8% daneben, gegen ein TX29DHT, der ein paar cm weiter weg steht.

Wie bei mir, habe 2 Thermometer daneben stehen (HM und NoName).

Zeigt der 8% zu wenig an ?

Ja 8% zu wenig. Habe aber noch nicht verfolgt ob das konstant gleich bleibt.

Ich habe Beiträge im Netz gefunden die das ähnlich beschrieben. Für die Adafruit lib gibt es hier einen bugreport https://github.com/adafruit/Adafruit_BME280_Library/issues/44
der möglicherweise was damit zu tun hat. Allerdings habe ich die lib dahingehen geändert und das hat nichts gebracht - da habe ich es wieder ausgebaut ... also einfach 7% bzw 8% draufrechnen. Das heist ich muss in den sketch was einbauen damit man eine Korrektur hinterlegen kann.

Mal schauen ob das noch von anderen beobachtet wird. Bei mir ist die Diff schon über Tage konstant, ich hatte erst die Hoffnung dass sich das noch einläuft ... wie es scheint eher nein ;)

Ich hatte heute erst beim suchen ein BME Script gesehen, wo man einen Offset eingeben konnte, war aber glaube ich für die Temperatur. Die liegt bei mir knapp 1 C zu hoch.
Habe oben mal mein aktuelles Script mit dazu gepackt.

bei der Temp verstehe ich das ja noch. Da habe ich im Bosch Datasheet gelesen das die auch Anpassungen anbieten (Großserie, nicht uns;) ) wenn der Sensor in einem Gehäuse mit Wärmequellen liegt. Die rechnen das also echt raus. Bei der Hum verstehe ich es nicht, schon garnicht 7/8%, das ist auch viel zu viel für den geplanten Einsatz (Dewpoint, Lüftung etc).

Wenn es dazu kommt baue ich das aber so dass man den offset von fhem aus hinterlegen kann.

Offset ist eine Sache, aber ob es dynamisch in der Steigung auch passt ?

muss man sehen. passt hum bei Dir?

Zitatmuss man sehen. passt hum bei Dir?

Ich habe mehere BME680 im Einsatz, so einige LaCrosse etc- Sensoren im Einsatz.
Aber alle differieren in den von Euch angegebenen Toleranzen. So 8..10% scheint mir "normal" zu sein.
Viel Schlimmer sind die DHTs mit 20% und mehr Abweichung...
Schaue heute Abend mal genauer drauf.
Hatte aber auch eine gute Webseite zur Kalibrierung der Luftfeuchte: Stichw. gesättigte Salzlösung.  ;)

Zum BME680 noch eine interessant klingende "Alternative" :
https://github.com/kriswiner/BME680 (https://github.com/kriswiner/BME680)

oder der NCS811, der Nachfolger des iAQ:
https://github.com/kriswiner/CCS811 (https://github.com/kriswiner/CCS811)

Moin,
ich habe jetzt die Abfrage des BME280 auf 2,5min hoch gesetzt, das hat schon deutlich was gebracht.
Ich habe jetzt nur noch 1 Grad zu viel, allerdings ist die Luftfeuchtigkeit immer noch viel zu niedrig.
Eventuell werde ich noch mal einen Si7021/HTU-21 testen und den BME nur für den Luftdruck nehmen.

Kennt ihr vielleicht noch andere Sensoren, die "Genauer" sind? Wie ist das den mit dem BME680?

TFT habe ich gestern auch mal getestet, aber mein 2,8 Zoll hat wieder andere Pin Beschriftungen, als normal und bin deshalb nicht weiter gekommen. Allerdings werde ich es wohl doch mit einem Nexus versuchen, da ich gerne 4.3 Zoll hätte. Ich habe hier noch so schone 4.3 Zoll TFT's liegen, aber die scheiden aufgrund der Anzahl der Pins leider aus  :o
Oder ich versuche nen ESP an den Mega zu bekommen, damit ich die noch verwenden kann  ;D

ZitatKennt ihr vielleicht noch andere Sensoren, die "Genauer" sind? Wie ist das den mit dem BME680?

Das mit der Luftfeuchte ist in der Tat ein Sache für sich.
Ich stufe bei mir empirisch die Luftfeuchte auf ca. 48% ein, die ein BME680 anzeigt.
LaCrosse-Sensor (Temp/Hum) #1  51%    19.3 °C
LaCrosse-Sensor (Temp/Hum) #2  45%    20.6 °C
Pearl NCS7245    (Temp/Hum)       40%    21.0 °C
CUL_TX_123      (DHT22)               40.9% 20.6 °C
LaCrosse_25      (BME680)             47%    20.6 °C
LaCrosse_0CT:   (BME680)             30%    26    °C
LaCrosse_10T:   (BME680)             33%    25.3 °C
LaCrosse_76T:   (BME680)             31%    26.9 °C 

Also ohne Kalibrierung und Offsetkompensation scheint das nichts zu werden, oder?

Die hohen Temperaturen der BMEs kommen durch die Nähe zur Heizung, was auch die niedrigen HUM-Werte erklären könnte.
Aber alle in einem Bereich von ca. 5qm ...

Jürgen

Noch mal zu meinen Raspi-Abstürzen, weil jetzt täglich um ca. 04:00 Uhr:

Habe mein Brightness-Eingang nicht beschalten, d.h. er floatet.
So wie es aussieht wird jede Änderung ohne definierte Zykluszeit übertragen ....
Muss ich noch mal genauer anschauen ... und alles entkoppeln.

das mit der Zykluszeit verstehe ich nicht. Leg den A0 doch auf Masse. Die Abstürze haben mit Sicherheit eine andere Ursache ...

Zitatdas mit der Zykluszeit verstehe ich nicht.

Sorry, habe mich falsch ausgedrückt: "gefühlt".  ;)

Mein bestellter MH-z19 ist angekommen ...  :)

Wie mißt du die Helligkeit?

Hat schon mal jemand den SHT31-D verwendet und kann was darüber sagen?

Mein BlueDot BME680 ist eingetroffen. In Bezug auf VOC ist er im burn-in, sprich (VOC) abwarten ...

Temp ist ok, mehr oder weniger identisch mit 2 HM Thermometer
Hum ist ungenau, ca 5.5%. Ich verwende hier (wie auch beim BME280) einen Offset, das scheint auch zu funktionieren.
Pressure passt in etwa (vs 1000.9 hPa Netz)

THP ist der BME280, THPV der BME680, dort ist R die Resistance (VOC)

23:48:15.690 -> F:IAQ;C:615;V:171;R:179710;
23:48:15.830 -> F:CO2;C:499;
23:48:25.344 -> F:THP;T:22.0;H:35.9;P:995.8;
23:48:25.719 -> F:THPV;T:22.1;H:35.1;P:996.0;R:64212;
23:48:25.719 -> F:IAQ;C:615;V:171;R:179710;
23:48:25.813 -> F:CO2;C:502;
23:48:35.326 -> F:THP;T:22.0;H:35.9;P:995.7;
23:48:35.701 -> F:THPV;T:22.1;H:35.1;P:996.0;R:64360;
23:48:35.701 -> F:IAQ;C:607;V:169;R:180597;
23:48:35.842 -> F:CO2;C:505;
23:48:45.355 -> F:THP;T:22.0;H:35.9;P:995.8;
23:48:45.730 -> F:THPV;T:22.2;H:35.0;P:996.0;R:64558;
23:48:45.730 -> F:IAQ;C:604;V:168;R:180953;
23:48:45.823 -> F:CO2;C:505;

Man findet im Netz eine ganze Menge Aufsätze zum Thema MOX und HUM oder drift, mal mehr mal weniger hilfreich. Ich denke der BME680 wird sich auch ohne die BSEC libs einsetzen lassen, wenn man die ABC speichert eventuell sogar besser.

@Papa: ich habe den Track zum Stand der Platine verloren. Da war noch ein update mit dem Pfosten gewünscht oder ist die bestellbar ? Ich konnte die Bahnen nicht komplett überprüfen weil man von oben nicht immer das unten sieht. Außerdem scheinen ich Bahnen an vielen Stellen zu berühren aber Du weißt offensichtlich was Du machst, von mir aus also ready.

vg
Joerg

Das in den Bildern ist der letzte Stand, da ich keine weiteren Infos zum Gehäuse habe, ob das so steht oder wesentliche Änderung erfolgt sind, bzw. im Schaltplan Pin-Belegungen korrigiert oder geändert wurden.

Ich hab mal versucht das Ganze etwas "aufzudrösseln", damit Lage, Bezeichnungen usw. der Bauteile besser zu erkennen ist.

Bitte nochmal kontrollieren.

1,27 mm Pfostenleiste links: Bitte checken ob die Lage bzw. Belegung stimmt, da Gnd und Vcc von der "normalen" Belegung abweicht.

Ich habe mir noch mal wegen den Raspi-Abstürzen fogendes angeschaut und fand es informativ:

https://blog.chanoa.de/fhem-performance (https://blog.chanoa.de/fhem-performance)
https://forum.fhem.de/index.php/topic,16103.msg111482.html#msg111482 (https://forum.fhem.de/index.php/topic,16103.msg111482.html#msg111482)

Zitatactive-timers: 3; max-active timers: 3; max-timer-load: 1  min-tmrHandlingTm: 0.9ms; max-tmrHandlingTm: 11.4ms; totAvgDly: 1.5ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
FileLog_SLinkIAQC_FAF074                 FileLog_Get                           3184        1    3184.90  3184.90     0.00     0.00 09.02. 10:47:57 HASH(FileLog_SLinkIAQC_FAF074); FileLog_SLinkIAQC_FAF074; CURRENT; INT; 2019-02-09_00:00:00; 2019-02-09_23:59:59; 4:SLinkIAQC_FAF074.tvoc\x3a::; 4:SLinkIAQC_FAF074.temperature\x3a::
FileLog_bme680_cc                        FileLog_Get                             72        3     139.86    46.62     0.00     0.00 09.02. 10:47:57 HASH(FileLog_bme680_cc); FileLog_bme680_cc; CURRENT; INT; 2019-02-09_00:00:00; 2019-02-09_23:59:59; 4:bme680_cc.T\x3a::; 4:bme680_cc.humidity\x3a::
tmr-LaCrosseGateway_OnConnectTimer       HASH(0x2a69d68)                         11        1      11.05    11.05     1.49     1.49 09.02. 10:47:14 HASH(LGW)
LGW                                      LaCrosseGateway_Read                    10      131     293.12     2.24     0.00     0.00 09.02. 10:48:04 HASH(LGW)
FileLog_SLinkIAQC_FAF074                 FileLog_Log                              5      112      75.15     0.67     0.00     0.00 09.02. 10:46:50 HASH(FileLog_SLinkIAQC_FAF074); HASH(SLinkIAQC_FAF074)
FileLog_EC3000_7C0C                      FileLog_Log                              5       11      17.82     1.62     0.00     0.00 09.02. 10:47:31 HASH(FileLog_EC3000_7C0C); HASH(EC3000_7C0C)
FileLog_LaCrosse_25                      FileLog_Log                              5       16      16.07     1.00     0.00     0.00 09.02. 10:48:04 HASH(FileLog_LaCrosse_25); HASH(LaCrosse_25)
MapleCUL433                              CUL_Read                                 4        4      18.45     4.61     0.00     0.00 09.02. 10:46:31 HASH(MapleCUL433)
FileLog_bme680_cc                        FileLog_Set                              3        1       3.58     3.58     0.00     0.00 09.02. 10:47:54 HASH(FileLog_bme680_cc); FileLog_bme680_cc; ?
tmr-FW_closeInactiveClients              0                                        1        2       2.34     1.17     1.59     1.44 09.02. 10:47:13 0
WEB                                      FW_Read                                  1        3       3.97     1.32     0.00     0.00 09.02. 10:47:54 HASH(WEB)
FileLog_bme680_cc                        FileLog_Log                              0        1       0.80     0.80     0.00     0.00 09.02. 10:47:20 HASH(FileLog_bme680_cc); HASH(bme680_cc)
FileLog_LaCrosse_08                      FileLog_Log                              0       13       8.51     0.65     0.00     0.00 09.02. 10:47:15 HASH(FileLog_LaCrosse_08); HASH(LaCrosse_08)
eventTypes                               eventTypes_Notify                        0      169      43.99     0.26     0.00     0.00 09.02. 10:48:04 HASH(eventTypes); HASH(LaCrosse_25)
FileLog_CUL_TX_123                       FileLog_Log                              0        2       1.38     0.69     0.00     0.00 09.02. 10:46:33 HASH(FileLog_CUL_TX_123); HASH(CUL_TX_123)
FileLog_CUL_TX_105                       FileLog_Log                              0        1       0.69     0.69     0.00     0.00 09.02. 10:47:44 HASH(FileLog_CUL_TX_105); HASH(CUL_TX_105)
FileLog_CUL_TX_106                       FileLog_Log                              0        1       0.67     0.67     0.00     0.00 09.02. 10:47:45 HASH(FileLog_CUL_TX_106); HASH(CUL_TX_106)
Logfile                                  FileLog_Log                              0      169      41.57     0.25     0.00     0.00 09.02. 10:48:04 HASH(Logfile); HASH(LaCrosse_25)
allowed_WEB                              allowed_Authenticate                     0        3       0.78     0.26     0.00     0.00 09.02. 10:47:54 HASH(allowed_WEB); HASH(WEB_192.168.xxx.yyy_54892); HASH(0x2424cb0)
LGW                                      LaCrosseGateway_Notify                   0      169       9.83     0.06     0.00     0.00 09.02. 10:47:36 HASH(LGW); HASH(EC3000_7C0C)
allowed_WEB                              allowed_Authorize                        0       11       0.74     0.07     0.00     0.00 09.02. 10:46:18 HASH(allowed_WEB); HASH(WEB_192.168.xxx.yyy_54882); cmd; apptime
FileLog_SLinkIAQC_FAF074                 FileLog_regexpFn                         0        1       0.09     0.09     0.00     0.00 09.02. 10:47:57 FileLog_SLinkIAQC_FAF074; 4:SLinkIAQC_FAF074.tvoc\x3a:: 4:SLinkIAQC_FAF074.temperature\x3a::
FileLog_bme680_cc                        FileLog_regexpFn                         0        3       0.19     0.06     0.00     0.00 09.02. 10:47:57 FileLog_bme680_cc; 4:bme680_cc.T\x3a:: 4:bme680_cc.humidity\x3a::
WEB                                      FW_Notify                                0      169       3.51     0.02     0.00     0.00 09.02. 10:46:45 HASH(WEB); HASH(SLinkIAQC_FAF074)
bme680_cc                                CustomSensor_Set                         0        1       0.04     0.04     0.00     0.00 09.02. 10:47:54 HASH(bme680_cc); bme680_cc; ?
WEB_192.168.xxx.yyy_54901                 FW_Read                                  0        1       0.00     0.00     0.00     0.00                 

ZitatMulticast wird aber von docker nicht unterstützt. Wenn es als container laufen soll, muss dieser mit der Option "--network=host" gestartet werden.

Die 2. FHEM-Installation unter Docker habe ich mal abgeschalten und lagere sie auf ein RASPI-Zero aus ...

Sorry, wenn zu Off-Topic...

Jürgen

Moin Papa,

Gehäuse: ich zitiere "80% machen ist besser als 100% wollen"  ;). Wenn die Platine erstmal da ist sieht man bestimmt noch Sachen die angepasst werden können/müssen. Ich schau mir die Bahnen morgen an, denke aber das wird passen also ab dafür. https://jlcpcb.com ? Irgendwas beachten ?

Moin Jürgen,

die Abstürze kommen von was anderem. Was steht denn im log ?
FileLog: würde ich begrenzen. Mit fhem Bordmitteln (readingFnAttribute->event-min-interval), dann wird die Anzeige aber auch nur entsprechend des Intervalls aktualisiert. Sonst SlinkIAQ -> dummy ,bei dem event-min-interval und den dann loggen.

Multicast und Docker habe ich "befürchtet", liegt aber eben am Docker. Ansonsten verwende ich Multicast genau weil es von verschiedenen Instanzen gelesen werden kann.

Btw: mich würde interessieren welche Widerstandswerte ein eingebrannter BME680 liefert (320°,150ms, 10 Sekunden intervall). Kommst Du da problemlos ran ?

vg
joerg

ZitatMoin Jürgen,

die Abstürze kommen von was anderem. Was steht denn im log ?
FileLog: würde ich begrenzen. Mit fhem Bordmitteln (readingFnAttribute->event-min-interval), dann wird die Anzeige aber auch nur entsprechend des Intervalls aktualisiert. Sonst SlinkIAQ -> dummy ,bei dem event-min-interval und den dann loggen.
Multicast und Docker habe ich "befürchtet", liegt aber eben am Docker. Ansonsten verwende ich Multicast genau weil es von verschiedenen Instanzen gelesen werden kann.
Btw: mich würde interessieren welche Widerstandswerte ein eingebrannter BME680 liefert (320°,150ms, 10 Sekunden intervall). Kommst Du da problemlos ran ?

Hallo Jörg,
danke für die Hinweise, muss leider priorisieren ..  die Abstürze kommen später dran. Der Raspi bleibt belibt einfach, mit grüner LED a,n stehen ...
Mit dem PiZero ist es dann eh entkoppelt....

Die BME680-Widerstandswerte kann ich Dir gerne liefern.  (evtl. erst morgen ..)


@Papa
hast Du für die "Lochraster-Fraktion" ein aktuelles Schaltbild mit den Erweiterungen?

Grüße,
Jürgen

Schaltbild bin eigentlich ich der Bringschuld, aber auch eher morgen

Hallo Jörg,

ZitatMan findet im Netz eine ganze Menge Aufsätze zum Thema MOX und HUM oder drift, mal mehr mal weniger hilfreich. Ich denke der BME680 wird sich auch ohne die BSEC libs einsetzen lassen, wenn man die ABC speichert eventuell sogar besser.

Ich weiß zwar nicht, was Du mit MOX + ABC meinst, aber wenn Du zuversichtlicht bist, nur zu ... ;D  ;)

Zitatburn-in, sprich (VOC/IAQ) abwarten ...

ca. 4 Tage ...

Verhalten mit BSEC ist so, dass nach dem Einschalten eine Phase mit IAQ=25 für ca. 5 Minuten kommt, danach geht der IAQ Wert für ca. 2 Minuten auf 0 und fängt dann erst an realistische Werte anzunehmen ...
Wobei BSEC die Möglichkeit bietet auch Werte abzuspeichern und wieder aufzurufen ... diese Funktionalität haben wir aber nicht genutzt.
Liegt aber vielleicht auch daran, dass  Bosch die Vorgehensweise nicht unbedingt "verständlich" genug erklärt ...  ;)

Anbei Beispiel-Readings mit GAS-R in Ohm und IAQ-Werten... (für IAQ werden Temperatur und Luftfeuchte mit dem Widerstandswert verrechnet).
Auffällig ist bei mir, die meiner Meinung nach, zu niedrige Luftfeuchte. Allerdings ohne klare Kalibierung, schwer einzuschätzen.

... und  heutiger eher etwas unüblicher VOC/IAQ Verlauf.
1. iAQCore + DHT22
2./3./4. BME680

Interessant, wie sich die Kurven ähnlich sind ...  :)
Könnte den Tiefpassfilter des IAQ-Wertes noch etwas besser gestalten...

Hallo Jürgen,

MOX = Metalloxidsensor, der verändert seinen Widerstandswert durch Elektronenaustausch bei Anwesenheit der Zielgase
ABC = Automatic Baseline Correction, damit wird Exemplar Streuung und Drift ausgeglichen.

Ohne Kenntnis der  BSEC Lib habe ich auch die 5 Minuten nach dem Start. Solange braucht der Sensor min um halbwegs stabil zu sein. Das verrechnen mit Temp/Hum ist mir logisch. Wirft witzigerweise auch die Frage auf wie der IAQ-C das macht, evtl ignorieren die das?

Ich nehme auch beim BME680 nicht den rohen Widerstandswert sondern verechne schon: R(clean) / R(gas) und Tiefpass. Entsprechende Korrekturen für Temp und Hum muss ich noch entwickeln. Nach 24h sieht das aber jetzt schon sehr brauchbar aus, jetzt kommen halt Werte zwischen 1.0 (clean) und 1.25 (~ca 300ppm vom IAQ) raus. Ziel wäre auch beim BME680 auf ppm zu kommen.

Die Hum korrigiere ich mit einem festem Offset, das scheint sich zu bewähren und ist über die Woche beim BME280 konsistent zu 2 Vergleichs Thermometern.

Hättest Du einen Wemos und einen BME680 "über" um ihn in Deinem "cluster" mitlaufen zu lassen wenn ich Dir entweder ino oder binary schicke ? Da hat man ja wirklich einen schönen Vergleich. ...

vg
joerg

nach einigen Minuten starren auf deine charts, ich glaube das mit der Hum für tVOC Korrektur ist echt so, man sieht das zwischen 11:00 und 13:00 schön. Die Luftfeuchte steigt (hast vmtl gelüftet oder so), der IAQ-C geht stärker nach oben und der BME steigt langsamer weil die BSEC den Effekt der Luftfeuchte rausrechnen. Da kann man auch schön die Dimension, oder besser den Faktor sehen, also den Einfluss von 1% Luftfeuchte auf die genauen ppm.

Das Wasser in der Luft wird genau wie Gas behandelt (was es bei 320° defakto auch ist) aber es sind eben deutlich mehr Wasser als GAS Moleküle da. Allerdings reagiert es auf (mit) dem Sensor dann schwächer. Genau dafür ist Dein chart echt gold wert...

Edit:

Schätzung aus Deinem Chart 11:30: 17° / 60%rH:
Das wären 8.68g/m³ Wasser. Bei 1293g/m³ Luft sind das ~6700ppm Wasser von denen aber nur ~200ppm in den Wert einzufließen scheinen (Vergleich und Schätzung der Werte IAQ vs BME im Chart).

Die Rechnung ist natürlich nicht vollständig (sogar falsch) weil weder der IAQ-C noch der BME bei 0%rH seine Nullung auf clean Air bekommen hat. Der Anstieg vor / um 11:30 scheint ja von 50%rH auf 60%rH zu sein. 50% bei 17° (genauer sehe ichs nicht) wären 7.23g, das wären 1.45g Differenz also ca 1000ppm Wasser welche die BSEC lib mit ca 1/3..1/5 (deutliches plus minus) auf den VOC anrechnet. Hat man schon mal eine Hausnummer auch wenn noch und vorerst nur eine Theorie ist...

ZitatHättest Du einen Wemos und einen BME680 "über" um ihn in Deinem "cluster" mitlaufen zu lassen wenn ich Dir entweder ino oder binary schicke ? Da hat man ja wirklich einen schönen Vergleich. ...

Klar....  ;) :) ;D

Ich war auch fleißig. Habe es jetzt hinbekommen einen 1.8 TFT anzuschließen, allerdings leider nur am Nodemcu. Habe ich am Wemos nicht hin bekommen, ist mir aber eigentlich immer noch nen bisschen zu klein.

Hallo Starsurfer,

schön, mit Uhr. Details?

Mit dem Wemos kann ich Dir vielleicht weiterhelfen:
Hier wir es ebenfalls eingesetzt: https://forum.fhem.de/index.php/topic,95498.0.html (https://forum.fhem.de/index.php/topic,95498.0.html)
Mit Bezugsquelle und Beschaltung, ist aber nicht das Sainsmart, hat aber noch die Hintergrund-LED (BL) herausgeführt. ;) :)
wemos D1 ---------- TFT Display
D0--------------------1-RST
D1--------------------2-CS
D2--------------------3-D/C
D5--------------------5-CLK
D6--------------------7-BL
D7--------------------4-DIN
3.3V------------------6-VCC
GND------------------8-GND

Ist das Sainsmart-Display 1.8" mit SPI-Interface.
Funktioniert bei mir ... und hoffe die halten länger als die OLEDs...  ;)

Anmerkung:
Der RES-Pin des Displays kann auch mit dem RES-Ausgang des Wemos verbunden werden.
/edit:

ZitatDas Problem ist, das diese Display alle unterschiedliche Pin Bezeichnungen haben

Nein, da der gleiche Controller dahintersteckt ist die Funktion vorgegeben:
SDA (MOSI) + SCK + A0 (=RS/DC)  + CS + RES + LED(=BL) + VCC + GND

Das Problem ist, das diese Display alle unterschiedliche Pin Bezeichnungen haben. Das auf dem Bild hier, habe ich nach dieser Anleitung (https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/tft-mit-nodemcu-lolin-v3?ls=de) eingerichtet. Die stammt aus den Beispielen der Bibliothek TFT_eSPI.
Später soll das mal eine NTP Uhr werden mit Winter/Sommerzeit.

Aber ich werde nachher vielleicht noch einen neuen Thread aufmachen, wo wir verschieden Display testen können,

Besteht eigentlich die Möglichkeit, etwas an den ESP über FHEM zu senden?
Ich würde z.B. die Aussentemp irgendwie da hin bekommen, geht das? 

Zitat von: Starsurfer am 10 Februar 2019, 14:08:27
Besteht eigentlich die Möglichkeit, etwas an den ESP über FHEM zu senden?
Ich würde z.B. die Aussentemp irgendwie da hin bekommen, geht das?

SLink selber ist so aufgebaut das die Sensoren nicht mit einem FHEM Server verheiratet werden. Die senden und FHEM hört zu, eben auch mehrere Instanzen.
Im Sketch ist unten ein auskommentierter Block, der stammt aus einem S0 Sensor und da kann man Kalibrierungswerte senden. Für den Raumsensor baue ich das auch ein damit man Temp und Hum kalibrieren kann.

Für ständige Updates von externen Werten, so wie die Temperatur bei Dir würde ich aber eher MQTT nehmen, da gibt es ja libs.

Kurze Statusmeldung

@Papa
die Platinen sehen gut aus (richtig). Wenn ich bedenke das Du das alles von Hand geroutet hast: respekt!!! Ich habe noch nie welche bestellt, muss ich was beachten ? Ich vermute ich benötige auch die files..
Der DHT pin wäre jetzt frei falls Du noch den Geigerzähler möchtest ...

Der Schaltplan ist aktualisiert, im Anhang.

Der BME680 hat mir echt noch einiges abverlangt. Insbesondere die Korrekturen für Temp und Hum hatten es nochmal in sich. Das sieht jetzt aber alles sehr gut aus. Der sketch läuft aktuell lokal, die fhem module müssen nachgezogen werden: folgt asap.

vg
joerg

Hallo Jörg,
dass der BME680 nicht einfach ist war schon klar. Bin mal gespannt, wie sich die Kompensation mit Feuchte und Temperatur anfühlt.

Bei Deinem Schaltplan war mir noch aufgefallen dass die 2 Pullups für den I2C-Bus fehlen. Könnte aber auch sein, dass die in einem
Sensormodul verbaut sein könnten...

Bei dem MH-Z19B wäre noch meine Frage, weil er unter TTL-Pegel (5V) läuft, RX+TX auch TTL-Pegel haben?
Müsste man da nocht ein R-Netzwerk vorsehen, um die 5V-Toleranz des ESP nicht zu strapazieren?
Oder hat er doch 3V3-Pegel am Ausgang?

Hast Du Dich für Display = Nextion entschieden?

Grüße,
Jürgen   

stimmt, die pullups fehlen. Laut Datenblatt sollten die, geht aber auch ohne. Auf der Platine von Papa sind sie vorgesehen

Der MH-Z19 hat 3.3V am Interface
Product Model MH-Z19B
Target Gas CO2
Working voltage 4.5 ~ 5.5 V DC
Average current < 60mA (@5V)
Peak current 150mA (@5V)
Interface level 3.3 V(Compatible with 5V) [/u]
https://www.winsen-sensor.com/d/files/infrared-gas-sensor/mh-z19b-co2-ver1_0.pdf

Display: geht ja beides. Für die normalen Raumsensoren wollte ich erstmal bei oled bleiben. Insgesamt haben wir ja so eine Art Baukasten mit verschiedenen Optionen. Später wollte ich eine zweite Variante mit Nextion machen, dazu muss man im sketch halt den Display Teil austauschen.

War der Meinung das das nicht mit Nextion geht, aber muss revidieren:
https://www.youtube.com/watch?v=eDn7LFyoEm8 (https://www.youtube.com/watch?v=eDn7LFyoEm8)

Ich habe das noch nicht probiert aber die Steckerleiste die Papa für Starsurfer eingesetzt hat sollte perfekt reichen.

update:

im git https://github.com/herrmannj/AirQuality

esp/iaq_wmos_oled_ams.ino:
aktualisierter sketch, angepasst auf wemos und bme280,bme680,IAQ Core C, MH-Z19B. (Display, LDR, LED ist hier nicht drin)

Im Kopf des sketch sind defs die man auskommentieren kann wenn man die device nicht verwendet. Die Zahlen dahinter sind die i2c Adressen, im Zweifel bitte anpassen weil die je nach break out board anders sind:
#define USE_BME280 0x76
#define USE_BME680 0x77
#define USE_IAQCOREC
#define USE_MHZ19B
FHEM/00_SLink.pm
FHEM/10_SLinkIAQC.pm
müssen auch eingespielt werden.

Das FHEM Modul ist auf die Version des sketches angepasst und primär um zu testen (daher auch einige zusätzliche debug). Es werden zb temp readings für den BME280 _und_ den BME680 erzeugt (mit prefix). In der Praxis wird man natürlich entweder den einen oder den anderen, kaum beide nehmen.

Im Modul wird, unter anderem, auch Taupunkt(°C) und die absolute Feuchte(g/m³) angezeigt da es ja perspektivisch auch um die Lüftungsuntersützung geht. Screenshot im Anhang

Ergänzung:
für die Berrechnung der VOC sind eine einigermaßen richtige Temperatur und Luftfeuchte (Messung) wichtig. Im sketch in den Zeilen 49/50 sind Korrekturwerte, derzeit hardkodiert (zukünftig per fhem zu setzen). Die wirken jetzt auf den BME280 und den BME680, im Zweifel also den BME680 mit Hilfe eines vertrauenswürdigen Thermometers kalibrieren. Der BME680 muss "lernen" was saubere Luft ist, benötigt also im Betrieb mindestens einmal einen gelüfteten Raum. Bei einem reset vergisst er das aktuell wieder.

Hallo Jörg,

vielen Dank fürs Teilen. Das sieht ja richtig gut aus!
Werde es gerne aufbauen und bei mir, wie besprochen zum Vergleich mitlaufen lassen ...  :D

Grüße,
Jürgen

Vielen Dank, werde es die Tage auch mal testen. Muss aber erst einen bme680 bestellen.

...ist zwar "offtopic"...aber da wir kurz mal darüber geredet haben und ich das eigentlich schon ernst gemeint habe.

...ich hab meinem Geigerzähler einen ESP verpasst und kann die Daten jetzt in FHEM mitloggen.

Und jetzt weißt du wenn die nebenan die Brennstäbe tauschen?

Man sieht ja dann immerhin (bedenkliche) Entwicklungen ...

@Papa: hast Du einen Link oder Namen zu dem Sensor?

Zitat von: dmq am 14 Februar 2019, 19:58:15
Man sieht ja dann immerhin (bedenkliche) Entwicklungen ...

Naja, die Jungs, die neben einem Kernkraftwerk leben, haben halt Jodtabletten im Haus und wollen dann schon wissen, was so abgeht  ;)

Gruß Peter

Und ich, der neben dem ehemaligen (?) Kernforschungszentrum lebt!
... könnte das auch gebrauchen ....  :) ;)

... und ich habe ein Zwischenstand zu berichten:

Wemos D1 mit einem BME680 verheiratet.
Der Wifimanager will bei mir die 192.168.244.1, statt die 192.168.4.1.
Wäre vielleicht nicht schlecht, vorher ein Lebenszeichen im SerialMonitor zu bekommen,
bzw. den Hinweis auf den WifiManager ...  ;)

Nur mal den BME per define eingeschalten.

Dann tut sich im SerialMonitor lang nichts, dann kommen die Ausgaben:

T:IAQC;FW:1.0;ID:45482A;IP:192.168.xxx.yyy;R:-39;F:THPV;T:21.49;H:37.51;AH:7.07;D:6.41;P:1021.4;V:183;R:40416;DB:1999718;DF:38588.621;DR:1.0474;

Dann noch die fhem-Seite updaten und mal schauen, ob  Daten in  FHEM ankommen ...

Jep!

2019-02-14_20:28:57 SLinkIAQC_45482A BME680_temperature: 21.31
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_rH: 37.65
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_aH: 7.02
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_dewpoint: 6.31
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_pressure: 1021.2
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_tvoc: 146
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_DBG_R: 58857
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_DBG_BASE_C: 2892976
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_DBG_FILTERED: 57862.809
2019-02-14_20:28:57 SLinkIAQC_45482A BME680_DBG_RATIO: 1.0172
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_temperature: 21.31
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_rH: 37.65
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_aH: 7.02
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_dewpoint: 6.31
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_pressure: 1021.2
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_tvoc: 144
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_DBG_R: 58775
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_DBG_BASE_C: 2892976
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_DBG_FILTERED: 57954.027
2019-02-14_20:29:07 SLinkIAQC_45482A BME680_DBG_RATIO: 1.0156
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_temperature: 21.31
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_rH: 37.65
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_aH: 7.02
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_dewpoint: 6.31
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_pressure: 1021.2
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_tvoc: 144
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_DBG_R: 58940
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_DBG_BASE_C: 2897056
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_DBG_FILTERED: 58052.625
2019-02-14_20:29:17 SLinkIAQC_45482A BME680_DBG_RATIO: 1.0153


Muss erst mal einen Überblick gewinnen.  ;)
Dann den iAQ mit dem MHz19 versehen und umprogrammieren ...

Ein zweiter BME680-Sensor daneben zeigt : IAQ = 132 an.  :D
Der SLINK-BME ist schon "eingebrannt" .

Die nächlichen hohen Werte ... !

@dmq: https://rhelectronics.net/store/diy-geiger-counter-kit.html

Preis ist ohne Zählrohr ....

Ich hatte gar nicht mitbekommen, dass Andreas Spiess dazu (Geiger Counter) auch mal gebloggt hat.

https://www.youtube.com/watch?v=K28Az3-gV7E

"Build your own 50$ connected Geiger Counter"

@Papa Romeo
bin mir nicht sicher ob das untergegangen ist: die Platine scheint ok zu sein (Befestigungslöcher > 2.5mm?). Ich würde gern bestellen. Welche files benötige ich da und muss ich noch was beachten ?
Den  Geigerzähler kann ich Dir wirklich gern softwareseitig mit integrieren wenn Du möchtest!

@juergs
unten der Plot IAQ Core vs BME680. (Blau MH-z19/co², Grün und rot die beiden VOC). Gegen 17:00 habe ich die baseline versaut (angeatmet), da habe ich jetzt softwareseitig nachgearbeitet. Ich werde den Filter beim tVOC raus nehmen und ein weiteres reading mit tVOC Average reinnehmen, das wird dann entsprechend träge.

Die Linien beim BME680 und beim IAQ Core passen fast 1:1 ... Mission accomplished  8)

zum Geigerzähler hatte ich auch irgendwo mal eine noch einfachere (geniale) Schaltung gesehen. Arduino PWM -> Spule, Diode (Hochspannung) -> tube und Ausgang (glaube noch ein Transistor?) auf den Arduino. Waren keine 10 externen Bauteile, fast alle passiv ..

ja, war glaube ich von Elektor. Hab ich auch noch irgendwo rumliegen ...

...ihr meint das mit der PIN-Diode, also der Foto-Diode BPW34.

ne, sondern normale Geigertube aber minimal extern beschaltet.

Die BPW34 könnte man doch mal mit dem Feinstaubsensor verheiraten ... :) (nächstes Projekt...)

...brauchst ja nicht viel.....Hochspannung und einen Impulsverstärker.....

Zitat von: herrmannj am 14 Februar 2019, 21:31:15
zum Geigerzähler hatte ich auch irgendwo mal eine noch einfachere (geniale) Schaltung gesehen. Arduino PWM -> Spule, Diode (Hochspannung) -> tube und Ausgang (glaube noch ein Transistor?) auf den Arduino. Waren keine 10 externen Bauteile, fast alle passiv ..

eventuell das......https://www.elektormagazine.de/files/attachment/219

ich meinte diesen https://hackaday.io/project/12933-esp8266-geiger-counter

ok...genial...wie ich sagte...HV und Impulsverstärker... ;) ;D ::)

Oder doch BPW34: http://www.elektronik-labor.de/Projekte/Alpha.html (http://www.elektronik-labor.de/Projekte/Alpha.html)
Verbesserter Strahlungszähler (https://www.google.com/search?q=%22Verbesserter+Strahlungsmesser%22+Schaltplan&tbm=isch&source=univ&client=firefox-b-d&sa=X&ved=2ahUKEwif-5e1kL7gAhWHfFAKHVLvB9EQsAR6BAgEEAE&biw=1600&bih=1074)
opengeiger.de (http://opengeiger.de/elektronik.html)

ZitatDie abgesetzte Sensorplatine mit BPW34 und OPV liefert gefilterte Impulse. Damit konnten auch Betastrahlen gemessen werden. Die Verstärkerplatine kann man mit einer offenen Fotodiode BPX61 bestücken, dann wir auch Alpha sichtbar.
Der besondere Clou ist, dass jeder Impuls vermessen und seriell ausgegeben wird. Wenn man also einen PC anschließt, kann man das Energie-Spektrum der Strahlung messen. Dass ist mehr als ein Geigerzähler kann, denn da werden alle Impulse auf gleiche Höhe gebügelt. Die Impulshöhe einer PIN-Diode ist dagegen proportional zur Energie.

Das wäre doch ein neues Projekt.  :D

...wieso nicht...wäre dabei...

Ok, aber zurück zu den Anomalien  ;) ;D :o
Irgendwie reagiert mein BME680-"System" heute anders als gewohnt ...
Relativ sehr hohe tVOC/IAQ-Werte ....
Hoher Luftdruck?  ::)

Delta T - vielleicht Strahlungswärme des Wemos (Raumheizung ist aus) ...

Man sieht deutlich, wie die Luftfeuchteänderung (Dusche) in den BSEC-Algoritmus eingreift.
Aktiviere mein 2tes Docker-System noch mal zur Gegenprobe mit  zwei weiteren BME680 (nanoLGW)-Sensoren.

Hallo Jürgen,

ja, die Werte IAQ Werte vom BME udn der TVOC Wert weichen ab (vermute das meinst Du).

Ich habe heute noch feintuning an der Kalibrierung gemacht und hoch geladen. Da sind Trägheiten (filter) angepasst und kalibriert wird erst wenn der Wert 60 Sekunden stabil ist um kurze Störungen (Sensor angehaucht) auszufiltern.

Bei Dir stimmt die Kalibrierung nicht. Schau mal bitte das der Offset für Temp und Hum so gut es geht stimmt.

Im Plot sieht man das der Sensor gegen 3:30 evtl resettet wurde, er fängt auf alle Fälle wieder bei 125ppm an. Um 8:00 hast Du gelüftet (die Zacken sind im neuen sketch besser/raus). Auf alle Fälle kalibriert der sich sofort wieder auf 125ppm da steht der IAQ noch auf 150 von 250 ...

Die Kalibrierung läuft so (vereinfacht)
Ein hoher Widerstandswert steht für gute Luft. Der sketch merkt sich den höchsten Widerstand und setzt den mit 125ppm gleich. Wenn sich die VOC Anteile verringern und dabei ein höherer Widerstand festgestellt wird, dann ersetzt er die aktuelle Baseline und gilt als 125ppm. Tatsächlich ist es viel komplexer,der Einfluß von Temp und Hum sowei drift wird rausgerechnet.

ersetze nochmal den sketch mit dem heutigen. So 15 Min nach dem Start würde ich dann so lüften das sowohl der BSEC als auch der sektch bei auf Null Landen, so wie in Deinem plot um 16:00 - 17:00

Ich hänge mal meinen Plot von heute Nachmittag an, gleicher Effekt:kurz nach 12 waren die völlig asynchron (AMS und BME), da hatte ich neu gestartet. Dann habe ich gelüftet damit bei sich "nullen" (baseline setzen) und seit dem laufen beide doch gut parallel. Der Zustand den ich kurz nach 12 hatte, der war bei Dir, jetzt würden die auch paralleler laufen. Allerdings sehe ich an den Zacken auf 100 umm 16 und 17 das da noch was geht, das ist eben mit der Filterung von heute verbessert.

Hallo Jörg,

ja danke, das dachte ich mir schon ....
Das mit dem Reset könnte auch durch den ESP-Watchdog hervorgerufen sein ...

Muss mir mein System erst wieder "einrichten" um den Überblick zu bewahren.
Zur Zeit habe ich auch noch zwei unterschiedliche LGW-Konfiguration, die mit Docker hängt sich,
wie schon berichtet ab-und-zu auf. Läuft leider nicht so stabil wie gewünscht.

ZitatEin hoher Widerstandswert steht für gute Luft. Der sketch merkt sich den höchsten Widerstand und setzt den mit 125ppm gleich. Wenn sich die VOC Anteile verringern und dabei ein höherer Widerstand festgestellt wird, dann ersetzt er die aktuelle Baseline und gilt als 125ppm. Tatsächlich ist es viel komplexer,der Einfluß von Temp und Hum sowei drift wird rausgerechnet.

Dann gilt es einen Reset erst mal zu vermeiden ... Das scheint aber auch die Vorgehensweise @BSEC zu sein.

Wiederhole das mit Deiner neuen Version und schaue mir das Ganze mal genauer an, hatte zugegebenermaßen bisher zu wenig Zeit  :-[

Hier (https://github.com/gschorcht/bme680-esp-idf) noch ein paar Infos...

ja BSEC wird macht das auch so (alle anderen auch). Habe mir echt viele Forschungspapers dazu reingezogen, das ist ja aber auch das Spannende, man lernt was  :)

watchdog wäre blöd, müsstest Du aber im fhem log finden. Ein reset ist im Augenblick kontraproduktiv, der verhaut sofort die Baseline.

Im code habe ich schon vorbereitet die Baseline im NV zu speichern weil man ja im echten Leben das Ding auch mal vom Strom trennen können muss. Werde ich aber erst später scharf schalten damit nicht während der Tests das EEPROM zu viele Schreibzyklen bekommt.

Hallo Jörg,

Du könntest noch im Code:
iaqcore.begin();
  #endif
};

das #endif vor die geschweifte Klammer schieben .... hat bei mir der Compiler angemosert.
Ursache: hatte iAQ auskommentiert  ;)

Die Warnungen:
iaq_wmos_oled_ams_v4.ino:277:152: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'int32_t {aka int}' [-Wformat=]
kann man ignorieren.

in der Tat. Danke. Erledigt

Neuer Versuch.
Alle 4 Sensoren am offenen Fenster eingeschalten.
Der QY-BME680MCU-scheint die Werte gespeichert zu halten und ließ sich nicht beirren nach dem Wiedereinschalten dort weiterzumachen
wo er ausgeschalten wurde  :D
Die Zuordnung der Momentanwerte in den Gplots muss ich auch nochmal prüfen ...

ZitatSo 15 Min nach dem Start würde ich dann so lüften, dass sowohl der BSEC als auch der Sektch bei auf Null Landen,

mache ich morgen noch mal ...

Heute Morgen sehr hohe IAQ-Werte, dann mal komplett die Wohnung durchgelüftet!
Das  schreit praktisch nach einer automatischen Belüftung.
Wobei die Ursache dafür noch offen is, obwohl ich den
verdächtigen Bad-Entlüftungskanal abgeklebt hatte.
Theorie leider nicht bestätigt... 

Hallo Jürgen,

steht der mit dem Display in der Nähe von den anderen ?

Die Werte vom SLinkIAQC (~250ppm?) sehen ganz normal, und ungefährlich aus - so wie man die in einem Inneraum erwartet.

Hier mal Leitwerte vom Umweltbundesamt an denen ich mich für die Anzeige via LED orientieren möchte: https://www.umweltbundesamt.de/themen/gesundheit/kommissionen-arbeitsgruppen/ausschuss-fuer-innenraumrichtwerte-vormals-ad-hoc#textpart-1

Normalerweise erfolgt die Angabe in ppm (part per million) wobei 300ppm den 0,3mg/m³ aus der Verlinkung entsprechen. Da liegst Du mit 250ppm (0,25mg/m³) absolut drin, solche Werte habe ich auch wenn nichts spezielles ist (speziell wie backen, reinigen, parfüm etc - dann gerne auch deutlich höher). Die IAQ Werte von BESC kann ich nicht bewerten weil die proprietär sind...

Deine SLink werte sehen für mich so absolut plausibel und ok aus. Lass Dich da nicht verrückt machen...  ;)

hallo Jörg,

Zitatsteht der mit dem Display in der Nähe von den anderen ?

Ja, ca. 30 cm.

Ok, der Hinweis auf den Unterschied zwischen IAQ und PPM ist hier wirklich angebracht.
Allerdings hatte ich so hohe IAQ-Werte bisher noch nicht... Nach dem Lüften gingen sie auch wieder fast auf Normalwerte herunter ...

Für die PPM-Messung muss man noch ein Bewertungs-"Gefühl" entwickeln ...  ;)

iaq-metrics (https://svach.lbl.gov/advancing-iaq-metrics/)
Heise (https://www.heise.de/developer/artikel/Ueberraschungsei-fuer-Wetterfroesche-dank-BME680-ESP8266-Arduino-ThingSpeak-3979158.html)

IAQ Index Classification:

    0 .. 50 Good
    51 .. 100 Average
    101 .. 150 Little bad
    151 .. 200 Bad
    201 .. 300 Worse
    301 .. 500 Very bad


bei der "iaq-metrics/" - da sind ganz verschiedene möglich und jeder macht was eigenes wodurch jede Vergleichbarkeit entfällt. Die Verlinkung passt auf jeden Fall nicht wirklich zu den BESQ Werten ...

Geh zu den ppm über - die werden in allen seriösen Quellen verwendet. Der Anhang und der Link im letzten post sind gute Orientierungen.

Von der Idee her nicht schlecht:
tabletop-weather-station-case (https://www.tinkerforge.com/de/shop/tabletop-weather-station-case.html) zu tabletop-weather-station (https://www.tinkerforge.com/de/shop/kits/tabletop-weather-station.html)
air-quality-bricklet (https://www.tinkerforge.com/de/shop/air-quality-bricklet.html)
lcd-128x64-bricklet (https://www.tinkerforge.com/de/shop/lcd-128x64-bricklet.html)
Display scheint mir etwas teuer ...
Wobei ich den xmc1404 (https://www.infineon.com/cms/de/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-cortex-m/32-bit-xmc1000-industrial-microcontroller-arm-cortex-m0/xmc1404-f064x0128-aa/) auch noch nicht kannte...

Zitatjeder macht was eigenes wodurch jede Vergleichbarkeit entfällt

Ja, schon. Allerdings hat sich bei mir schon eine Bewertungs-Einschätzung auf IAQ-Werte gebildet.

Aber man muss erst mal Erfahrungen sammeln....  :)

Um Erfahrung zu teilen; ich lasse den BME680 aktuell auf dem Bread Board (Schreibtisch) laufen um Langzeiterfahrung zu sammeln. Der BME680 ist extrem empfindlich für Wasser in der Luft, die werden aus Temp und Hum berechnet.

Im screenshot unten habe ich heute Mittag gelüftet, danach zeigte der BME680 (rot) ca 100ppm mehr als der AMS (grün) an, der als Referenz mitläuft.

Diagnose:
während des Lüftens hat der Sketch eine base line Kalibrierung durchgeführt. Dabei lag der Sensor in der Sonne. Dadurch hat das Thermometer eine zu hohe Temperatur gemeldet welche in die Kalibrierung eingeflossen sind. Ich habe das gerade nachgerechnet, vmtl lag die tatsächliche Temperatur nur ca knapp 1°, max 2° tiefer. Das macht bereits 100ppm Unterschied. Die "Parallelität"  zwischen dem AMS und dem BME680 stimmen trotzdem gut.

Interessant ist dass der AMS, lag auch in der Sonne, weniger davon betroffen ist. Möglicherweise ist der verbaute Sensor da physikalisch einfach viel weniger von der Feuchte beeinflusst.

Softwareseitig denke ich noch über eine Lösung dafür nach. Aktuell ist das so gelöst dass der Sensor sich kalibriert wenn der Wert "sauber" > 60 Sekunden anhält und die Relative Luftfeuchte läuft durch einen Tiefpass. Ich werde wahrscheinlich zusätzlich einen Tiefpass für Temp einbauen und nur kalibrieren wenn die Temp und Hum innerhalb eines Fensters von 0.1%(?) über 2..5(?) Minuten stabil ist. Das soll dem Sensor Zeit geben beim Lüften (das ist ja die "normale" Situation welche eine Kalibrierung triggert) sich besser auf die wirkliche Temperatur einzupendeln.

Jürgen:

konntest Du noch Erfahrungen sammeln? (BME680)

vg
Joerg

Hallo Jörg,

sorry, bin gerade am Umbauen auf einen neuen Rechner mit I7 und 4K-Display und muss noch meine gesamte Hardware-Infrastruktur migrieren.
Ein riesen Aufwand, sehe aber gerade wieder Land ... ;D 
Also leider dieses WoE noch etwas anderweitig beschäftigt ...

Im Moment sieht es aber noch gut aus, liegt aber daran dass ich noch keine Zeit zum Eianrbeiten gefunden habe.
Melde mich aber gerne wieder, wenn es Neues zu berichten gibt ... 

Muss auch noch weitere BME's + BH1750 bestellen und hoffe aber auch, dass PeMues Adapter-Platine auch demnächst eintrudelt... ;-)
Den BH1750  gibt es eher auf Breakoutplatinen, aber nicht als Bauteil ...

Wie sieht es mit Deinen Platinen aus?

Grüße,
Jürgen 

Zitat von: juergs am 23 Februar 2019, 19:39:30
Muss auch noch weitere BME's + BH1750 bestellen und hoffe aber auch, dass PeMues Adapter-Platine auch demnächst eintrudelt... ;-)
Den BH1750  gibt es eher auf Breakoutplatinen, aber nicht als Bauteil ...

Die Platinen sind verschickt, allerdings sind noch keine Tracking Informationen verfügbar. I.d.R. waren das so 15-20 Tage, da sind wir 4 drüber. Allerdings habe ich ca. 8 Tage wegen dem chinesischen Neujahr verloren.
Bei mir ist auch ein BH175 drauf, allerdings weiß ich gerade nicht, wieviele ich momentan da habe  :o.

Gruß Peter

Hallo Peter,
das hört sich ja gut an.
Irgendwie feiern die Chinesen länger Neujahr als wir  ::) ;)
reichelt hat den BH1750 leider nicht, nur als Breakoout.
Glaube hdgucken hatte Segor erwähnt...

Jürgen

Was war den jetzt mit den Platinen zu dem Projekt, läuft da schon eine Bestellung?

..soviel ich weiß, ist Joerg in die Offensive gegangen...

Jawoll, ist er.

Ich gebe mal meine Erfahrungen mit dem BME680 (als VOC Sensor) hier rein.

Vorab, ich werde mich, bzgl der Firmware, auf den AMS IAQ Core + BME280 konzentrieren aber sowohl von Gehäuse als auch vom FHEM Modul weiterhin alle unterstützen die hier auf den BME680 gehen wollen.

Mit dem BME680 habe ich mir sehr intensiv beschäftigt, Ziel war es den BME680 ohne die BSEC "Blackbox libs" zu betreiben. Vielleicht möchte das jemand weiterführen und die verbleibenden Probleme zu lösen. Hier die gesammelten Erkenntnisse:

Zur Funktion, im BME680 ist neben einem Temp, Hum und Pressure Sensor (weitgehend identisch zum BME280) auch ein Metalloxyd VOC Sensor verbaut. Das ist Quasi ein Widerstand dessen Leitwert bei Anwesenheit von Zielgasen steigt (der Widerstandswert sinkt). Dessen Roh Werte kann man auslesen. Allerdings ist der Widerstandswert nicht als absoluter Messwert zu betrachten, im Sinne von 100kOhm entsprechen so und so viel VOC. Stattdessen ist der Widerstandswert von eine Fülle von Parametern abhängig. Dazu gehören Exempalrstreunung, Alterung, Temperatur und Luftfeuchte. Diese Parameter beeinflussen die Werte durchaus um Zehnerpotenzen. Daher kann man das immer nur als relative Änderung sehen. Praktisch macht man das in dem man über einen gewissen Zeitraum auf den höchsten auftretenden Widerstandswert achtet und den dann mit "reiner Luft" gleichsetzt. Anschliesend werden dann alle Widerstandswerte relativ zu diesem betrachtet. Weil sich die Kennlinie ständig ändert muss man das dauernd widerholen, etwa 1-2 Wochen sind gängige Werte.

Ich habe viele Messreihen durchgeführt und dabei jeweils den AMS als Referenz genommen.

In vielen Veröffentlichungen wird der Einfluß der relativen Luftfeuchte (manchmal auch plus Temperatur) betrachtet. Mir erschien es logischer nicht die relative sondern die absolute Luftfeuchte zu betrachten. Diese Annahme hat sich in der Praxis bestätigt, der Einfluss ist dabei exponentiell:

R(bereinigt) = R * (absoluteFeuchte ^1.5)

Für die Berechnung des Anteiles VOC habe ich aus den Messreihen folgende Formel abgeleitet:

Ratio = R(clean) / R(voc)
VOC = 1250 * ln(Ratio) +125

Wobei R(clean) der gespeicherte und um den Einfluss der Luftfeuchte bereinigte Basiswert ist. R(voc) der aktuelle Widerstandswert, ebenfalls bereingt um die Luftfeuchte.

Das hat in den Test hier auch gut funktioniert (Referenz der AMS). Der relative Verlauf der so berechnten Werte (gegenüber dem AMS) kommt im Durchschnitt ausreichend gut hin. Im Einzellfall reagieren beide offensichtlich etwas unterschiedlich auf verschiedene Gase, alles in allem passt es.

Aber:
die absolute Anzeige der Werte ist extrem von der Baseline Kalibrierung abhängig. Bei entsprechend trockener und kalter Luft erreiche ich durchaus 450kOhm, wärme mglw feuchtere Aussenluft (genauso "clean") gibt aber auch 180kOhm. Da der Einfluss der Luftfeuchte jetzt exponentiell ist kommt man dort ganz schnell in Bereiche die unterhalb der Messtoleranz (Hum/Temp) des BME liegen.

Defacto ist es mir nicht gelungen eine Möglichkeit zu finden die Baseline Kalibrierung automatisch mit ausreichender Genauigkeit durchzuführen. Beide Kennlinien (Feuchtekalibrierung und ratio) sind nicht linear. Wenn die Kalibrierung nur um Prozentbruchteile fehlerhaft ist dann sorgt das dafür dass die berechneten VOC einen Offset von vielen, zb 200 oder 300ppm, haben was also für den praktischen Einsatz ungeeignet ist. (Beim AMS und auch in der BESC lib wird das alles intern erledigt).

Ich veröffentlich hier Formeln und Erkenntnisse damit, wer mag, darauf aufsetzen kann.

vg
Joerg

Ich habe noch zu den Grundlagen folgendes gefunden:
Design and characterization for semiconductor gas sensors (http://deeea.urv.cat/public/PROPOSTES/pub/pdf/2444pub.pdf)

Hallo Zusammen,

• gibt es etwas Neues zu den Platinen?


• Findet der perl-code ins reguläre fhem-Update?

Hier noch etwas Cooles als Vorschlag: Widget-Dashboard (http://www.technoblogy.com/show?2F5D)
Wobei das Farb-OLED mit ca. 30$ doch etwas teuer ist...  ;D
Grüße,
Jürgen

Die Platinen sind frisch eingetroffen. Leider bin ich, zu meiner Schande, noch nicht zum Aufbau und damit zur Funktionsprüfung gekommen. ..

Den perl code kann ich gern einchecken, allerdings muss man sich fragen ob sich das für so ein Projekt mit so begrenzter Teilnehmerzahl lohnt. (?) Alternativ wäre ein Pflege via git

..gut Ding, will Weile haben... ;)

Moin,
habe bei mir jetzt folgende Hardware laufen:
- Nodemcu v2
- 1.8 TFT (ST7735)
- BME280
- MAX44009
- MHZ19 (noch nicht im Code eingebaut)

Aktuelle Uhrzeit über NTP, auf dem Display.

Gesendet wird bei meiner Version über MQTT, da ich später noch die Außentemperatur mit auf dem Display anzeigen lassen will.
Der Code ist noch nicht ganz fertig und noch etwas chaotisch, aber vielleicht kann der ein oder andere ja damit schon was anfangen.

Arduino Code:
/*
Based on clock sketch by Gilchrist 6/2/2014 1.0
Updated by Bodmer
A few colour codes:

code  color
0x0000  Black
0xFFFF  White
0xBDF7  Light Gray
0x7BEF  Dark Gray
0xF800  Red
0xFFE0  Yellow
0xFBE0  Orange
0x79E0  Brown
0x7E0 Green
0x7FF Cyan
0x1F  Blue
0xF81F  Pink
*/
#define DEBUG_SERIAL

#ifdef DEBUG_SERIAL
#define DEBUG_BEGIN Serial.begin(115200)
#define DEBUG_PRINT(x) Serial.println(x)
#else
#define DEBUG_PRINT(x)
#define DEBUG_BEGIN
#endif

#define USE_BME280 0x76
#define USE_MHZ19B
#define USE_MAX
#define USE_TFT

#include <ESP8266WiFi.h>          //https://github.com/esp8266/Arduino
#include <DNSServer.h>
#include <ESP8266WebServer.h>
#include "WiFiManager.h"          //https://github.com/tzapu/WiFiManager
#include <PubSubClient.h>         // mqtt client
#include <ESP8266WiFi.h>
#include <Wire.h>

//BME280
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>
//MAX44009
#include <MAX44009.h> //https://github.com/dantudose/MAX44009
MAX44009 light;
//MHZ19
#include <MHZ.h>                          // MH-Z19b: https://github.com/tobiasschuerg/MH-Z-CO2-Sensors
#include <SoftwareSerial.h> // Software Serial, used by MH-Z19b
//TFT
#include <TFT_eSPI.h> // Graphics and font library for ST7735 driver chip
#include <SPI.h>
TFT_eSPI tft = TFT_eSPI();  // Invoke library, pins defined in User_Setup.h

//for LED status
#include <Ticker.h>
Ticker ticker;

#define mqtt_port 1883
char mqtt_server[] = "192.168.178.87";
WiFiClient espClient;
PubSubClient client(espClient);

//NTP
#include <NTPtimeESP.h>
#define DEBUG_ON
NTPtime NTPch("fritz.box");   // Choose server pool as required
strDateTime dateTime;

#define heartbeat_topic "ESP_Sensor/Wohnzimmer/heartbeat/state"
#define wifisignal_topic "ESP_Sensor/Wohnzimmer/wifi/state"
#define abs_dewPoint_topic "/Haus/Wohnzimmer/abs_dewPoint"
#define abs_humidity_topic "/Haus/Wohnzimmer/abs_humidity"
#define humidity_topic "/Haus/Wohnzimmer/humidity"
#define lux_topic "/Haus/Wohnzimmer/lux"
#define pressure_topic "/Haus/Wohnzimmer/pressure"
#define temp_topic "/Haus/Wohnzimmer/temp"
bool heartbeat = 1;

// Interval to report mqtt data in seconds
unsigned long currentMillis = millis();
unsigned long prevLedMillis   = millis(); // counter main loop for signaling led
unsigned long prevBMEMillis   = millis(); // counter main loop for dht
unsigned long prevMhz19Millis = millis(); // counter main loop for MH-Z19
unsigned long prevLUXMillis   = millis(); // counter main loop for LDR
unsigned long prevHearbeatMillis = 15000;    // default
unsigned long intervalHearbeat = 15000;    // default
unsigned long sigLedOn        = 50;       // ms for led on
unsigned long sigLedOff       = 450;      // ms for led off
unsigned long intervalBME     = 50000;    // default
unsigned long intervalMhz19   = 10000;    // default
unsigned long intervalLUX     = 10000;    // default
unsigned long intervalLed     = 0;        //
uint32_t targetTime = 0;       // for next 1 second timeout
unsigned long delayTime;
//////////////////////////////////////////////////////////////////////////////////

byte omm = 99;
boolean initial = 1;
byte xcolon = 0;
unsigned int colour = 0;
uint8_t hh= 0;
uint8_t mm= 0;
uint8_t ss= 0;

static uint8_t conv2d(const char* p) {
  uint8_t v = 0;
  if ('0' <= *p && *p <= '9')
    v = *p - '0';
  return 10 * v + *++p - '0';
}

float absHum(float temp, float hum) {
  double sdd, dd;
  sdd=6.1078 * pow(10,(7.5*temp)/(237.3+temp));
  dd=hum/100.0*sdd;
  return (float)216.687*dd/(273.15+temp);
};

float dewPoint(float temp, float hum) {
  double A = (hum/100) * pow(10, (7.5*temp / (237+temp)));
  return (float) 237*log10(A)/(7.5-log10(A));
};

void configModeCallback (WiFiManager *myWiFiManager) {
  Serial.println("Entered config mode");
  Serial.println(WiFi.softAPIP());
  //if you used auto generated SSID, print it
  Serial.println(myWiFiManager->getConfigPortalSSID());
}

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// BME280
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
#define SEALEVELPRESSURE_HPA (1013.25)
Adafruit_BME280 bme280; // I2C
  char str_temp[6];
  char str_hum[6];
  char str_absHum[6];
  char str_dewPoint[6];
  char str_pressure[16];

void getBMEReadings() {
  float t_offset = 0.65F;
  float h_offset = 7.0F;
  float h = bme280.readHumidity() + h_offset;
  float t = bme280.readTemperature() - t_offset;
  float a = absHum(t, h);
  float d = dewPoint(t, h);
  float p = bme280.readPressure() / 100.0F;
  dtostrf(t, 3, 2, str_temp);
  dtostrf(h, 3, 2, str_hum);
  dtostrf(a, 3, 2, str_absHum);
  dtostrf(d, 3, 2, str_dewPoint);
  dtostrf(p, 3, 1, str_pressure);
};

void printTFT_BME_Values(){
  tft.setTextColor(TFT_WHITE, TFT_BLACK);
  tft.drawCentreString(str_temp, 10, 82, 1);
  tft.drawCentreString ("\xF7" "C", 45, 82, 1);
  tft.drawCentreString(str_hum, 10, 93, 1);
  tft.drawCentreString ("%", 45, 93, 1);
  tft.drawCentreString(str_pressure, 10, 105, 1);
  tft.drawCentreString ("hpa", 45, 105, 1);
}

void printBMEValues() {
    Serial.print("Temperature = ");
    Serial.print(bme280.readTemperature());
    Serial.println(" *C");
    Serial.print("Pressure = ");
    Serial.print(bme280.readPressure() / 100.0F);
    Serial.println(" hPa");
    Serial.print("Approx. Altitude = ");
    Serial.print(bme280.readAltitude(SEALEVELPRESSURE_HPA));
    Serial.println(" m");
    Serial.print("Humidity = ");
    Serial.print(bme280.readHumidity());
    Serial.println(" %");
    Serial.println();
}

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// MAX44009
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
#define Addr 0x4A
char str_lux[16];
void getLUXReadings() {
  float lux = light.get_lux();
  dtostrf(lux, 3, 2, str_lux);
  Serial.print("Light (lux):    ");
  Serial.println(str_lux);
};
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
void tick(){
  //toggle state
  int state = digitalRead(LED_BUILTIN);  // get the current state of GPIO1 pin
  digitalWrite(LED_BUILTIN, !state);     // set pin to the opposite state
};

void setup() {
  DEBUG_BEGIN; //for terminal debugging
  DEBUG_PRINT();

  // Enable I2C for ESP8266 NodeMCU boards [VDD to 3V3, GND to GND, SDA to D2, SCL to D1]
  Wire.begin(D2, D1);
  //set led pin as output
  pinMode(LED_BUILTIN, OUTPUT);

  tft.init();
  tft.setRotation(1);
  tft.fillScreen(TFT_BLACK);
  tft.fillCircle(3, 3, 2, TFT_RED); //WLAN keine Verbindung

  setup_wifi();

  tft.setTextColor(TFT_RED, TFT_BLACK); // Note: the new fonts do not draw the background colour
  tft.drawCentreString("Innen:",15,65,2);
  tft.drawCentreString("Aussen:",120,65,2);

  targetTime = millis() + 1000;

#ifdef USE_BME280
  if (! bme280.begin(USE_BME280)) {
    DEBUG_PRINT("Could not find a valid BME280 sensor, check wiring and address!");
  };
#endif

#ifdef USE_MAX //MAX44009
  if(light.begin())
    {
        Serial.println("Could not find a valid MAX44009 sensor, check wiring!");
    while(1);
  }
#endif
}

void loop() {

unsigned long currentMillis = millis();

  // first parameter: Time zone in floating point (for India); second parameter: 1 for European summer time; 2 for US daylight saving time; 0 for no DST adjustment; (contributed by viewwer, not tested by me)
  dateTime = NTPch.getNTPtime(1.0, 1);
  // check dateTime.valid before using the returned time
  // Use "setSendInterval" or "setRecvTimeout" if required
  if(dateTime.valid){
    NTPch.printDateTime(dateTime);
    Serial.println(dateTime.valid);
    byte actualHour = dateTime.hour;
    byte actualMinute = dateTime.minute;
    byte actualsecond = dateTime.second;
    int actualyear = dateTime.year;
    byte actualMonth = dateTime.month;
    byte actualday =dateTime.day;
   // byte actualwday =dateTime.wday;
    byte actualdayofWeek = dateTime.dayofWeek;

   hh= dateTime.hour;
   mm= dateTime.minute;
   ss= dateTime.second;
  }

 
   if (targetTime < millis()) {
     targetTime = millis()+1000;
     ss++;              // Advance second
     if (ss==60) {
       ss=0;
       omm = mm;
       mm++;            // Advance minute
       if(mm>59) {
         mm=0;
         hh++;          // Advance hour
         if (hh>23) {
          hh=0;
         }
       }
     }

    if (ss==0 || initial) {
      initial = 0;
      tft.setTextColor(TFT_WHITE, TFT_BLACK);
      tft.setCursor (8, 52);
      tft.print(dateTime.dayofWeek);
      tft.print("  ");
      tft.print(dateTime.day);
      tft.print(".");
      tft.print(dateTime.month);
      tft.print(".");
      tft.print(dateTime.year);

      //tft.setTextColor(TFT_BLUE, TFT_BLACK);
      //tft.drawCentreString("It is windy",120,48,2); // Next size up font 2

      //tft.setTextColor(0xF81F, TFT_BLACK); // Pink
      //tft.drawCentreString("12.34",80,100,6); // Large font 6 only contains characters [space] 0 1 2 3 4 5 6 7 8 9 . : a p m
    }

    // Update digital time
    byte xpos = 6;
    byte ypos = 0;
   
    if (omm != mm) { // Only redraw every minute to minimise flicker
      tft.setTextColor(0x39C4, TFT_BLACK);  // Leave a 7 segment ghost image, comment out next line!
      tft.drawString("88:88",xpos,ypos,7); // Overwrite the text to clear it
      tft.setTextColor(0xFBE0, TFT_BLACK); // Orange
      omm = mm;

      if (hh<10) xpos+= tft.drawChar('0',xpos,ypos,7);
      xpos+= tft.drawNumber(hh,xpos,ypos,7);
      xcolon=xpos;
      xpos+= tft.drawChar(':',xpos,ypos,7);
      if (mm<10) xpos+= tft.drawChar('0',xpos,ypos,7);
      tft.drawNumber(mm,xpos,ypos,7);
    }


    if (ss%2) { // Flash the colon
      tft.setTextColor(0x39C4, TFT_BLACK);
      xpos+= tft.drawChar(':',xcolon,ypos,7);
      tft.setTextColor(0xFBE0, TFT_BLACK);
    }
   
  }

  // If we are waking up from a sleep, we need to re-establish a connection with
  // the mqtt server.
  if ( !client.connected() ) {
    reconnect();
  }

  client.loop();

if (currentMillis - prevHearbeatMillis > intervalHearbeat) {
  prevHearbeatMillis = currentMillis;
  heartbeat = !heartbeat;
  Serial.println("Send heartbeat");
  client.publish(heartbeat_topic, String(heartbeat).c_str(), true);
  long rssi = WiFi.RSSI();
  Serial.println("Send wifi signal strenght");
  client.publish(wifisignal_topic, String(rssi).c_str(), true);
  };

#ifdef USE_BME280
  if (currentMillis - prevBMEMillis > intervalBME) {
    prevBMEMillis = currentMillis;
    getBMEReadings();
    printBMEValues();
    printTFT_BME_Values();
    client.publish(temp_topic, str_temp);
    client.publish(humidity_topic, str_hum);
    client.publish(abs_humidity_topic, str_absHum);
    client.publish(abs_dewPoint_topic, str_dewPoint);
    client.publish(pressure_topic, str_pressure);
  };
#endif

#ifdef USE_MAX
  if (currentMillis - prevLUXMillis > intervalLUX) {
    prevLUXMillis = currentMillis;
    getLUXReadings();
    client.publish(lux_topic, str_lux);
  };
#endif
}

void setup_wifi(){
  delay(10);
  // start ticker with 0.5 because we start in AP mode and try to connect
  ticker.attach(0.6, tick);
  WiFiManager wifiManager;
  wifiManager.setAPCallback(configModeCallback);
  if (!wifiManager.autoConnect()) {
    DEBUG_PRINT("failed to connect and hit timeout");
    ESP.reset();
    delay(1000);
  }
  DEBUG_PRINT("connected...yeey :)");
  Serial.println("");
  Serial.println("WiFi connected");
  Serial.println("IP address: ");
  Serial.println(WiFi.localIP());
  ticker.detach();
  digitalWrite(LED_BUILTIN, LOW);
  tft.fillCircle(3, 3, 3, TFT_GREEN); //WLAN keine Verbindung
  client.setServer( mqtt_server, mqtt_port );
  client.setCallback(callback);
  WiFi.mode(WIFI_STA);
}

void reconnect() {
  // Loop until we're reconnected
  while (!client.connected()) {
    Serial.print("Connecting to MQTT Server ...");
    // Attempt to connect (clientId, username, password)
    if ( client.connect("ESP Device") ) {
      Serial.println( "[DONE]" );
      //client.subscribe("/Garten/temp");
      //client.subscribe("/Garten/hum");
    } else {
      Serial.print( "[FAILED] [ rc = " );
      Serial.print( client.state() );
      Serial.println( " : retrying in 5 seconds]" );
      // Wait 5 seconds before retrying
      delay( 5000 );
    }
  }
}

void callback(char* topic, byte* payload, unsigned int length) {
    Serial.print("Received message [");
    Serial.print(topic);
    Serial.print("] ");
    char msg[length+1];
    for (int i = 0; i < length; i++) {
        Serial.print((char)payload[i]);
        msg[i] = (char)payload[i];
    }
    Serial.println();

    msg[length] = '\0';
    Serial.println(msg);

    if(strcmp(msg,"on")==0){
        digitalWrite(13, HIGH);
    }
    else if(strcmp(msg,"off")==0){
        digitalWrite(13, LOW);
    }
}


Hallo Zusammen,

Das ist ein sehr spannendes Projekt. Ich gehe davon aus, dass ihr inzwischen einige Sensoren in Betrieb genommen habt. Gibt es erste Erfahrungsberichte? Sachen die ihr ändern würdet? Könnt ihr allenfalls einige Fotos Posten?

Danke und Gruss, Nicolas

Hallo Nicolas,

herzlich Willkommen!

Die bisher einzigen Prototypen laufen vmtl bei mir. Ich war die vergangenen Wochen beruflich sehr stark eingespannt und wollte vor dem Versand der Platinen erst sicherstellen das sie fehlerfrei funktionieren. Seit 2 Tagen arbeite ich wieder am Projekt.

Aktuell habe ich noch 10 Platinen aus der Bestellung übrig die ich (first come, first serve) versenden kann.

Es gibt einige kleine Punkte zu beachten, betreffen die Frontplatine:

- die LEDs laufen am Wemos nicht mit den 5V lassen sich jedoch problemlos mit 3.3V betreiben. Das geht am einfachsten indem
    a) die Diode auf dem Mainboard nicht bestückt wird
    b) kein 5V Leitungen zwischen Main und Front installiert werden.
    c) eine kleine Brücke zwischen 3,3V und 5V auf der Frontplatine gesetzt wird (Anschlüsse liegen direkt nebeneinander)

-  bei Verwendung der PL9823-F5 (nicht SMD): LEDs so weit wie möglich nach Außen einlöten. Zu erst die jeweils äußeren Pins fixieren, danach einpassen. Die Lötaugen sind etwas zu weit innen, deshalb durch passendes Löten ausgleichen. Passprobe.

- der Widerstand für die LDR auf dem Board zwischen VCC und dem LDR, er müsste zwischen LDR und Masse. Das geht problemlos indem man ihn passend einlötet, schräg, und als Masse den freien i2C Port verwendet.

Ein Display habe ich mir zerschossen, die gibt es in zwei Ausführungen wobei VCC und GND vertauscht sind.

Bei meiner Tochter läuft jetzt seit Wochen einer der Prototypen. Da wird nur eine der LEDs vereinfacht angesteuert und kein Display. Sie ist bereits so begeistert und passt ihr Verhalten (lüften) wirklich darauf an. Auf das Display könnte man möglicherweise komplett verzichten.

Software aktualisiere ich im GIT sobald die nächste MVP Stufe erreicht ist.

Meldungen für Platinen gern per pm (+Adresse)

vg
Joerg

Hallo Jörg,

Zitat von: PeMue am 03 Februar 2019, 19:49:24
Ich nehme dann mal 2 Platinen, aber nur wenn es einen Schaltplan gibt und ich mein breakout verbauen kann  8) 8) 8)

Ist das noch auf Deinem Schirm? Breakouts sind auch noch da, falls ihr sie braucht. Details zur Bezahlung per PM?

Gruß Peter

Zitat von: PeMue am 25 April 2019, 22:01:05
Hallo Jörg,Ist das noch auf Deinem Schirm? Breakouts sind auch noch da, falls ihr sie braucht. Details zur Bezahlung per PM?

Gruß Peter

Schick mal Deine Adresse bitte.

..oh Mann...ihr mit euren Schaltplänen.... :D ;D ;D ;D ;D ;) ::)

Zitat von: Papa Romeo am 25 April 2019, 22:29:51
..oh Mann...ihr mit euren Schaltplänen.... :D ;D ;D ;D ;D ;) ::)

ich habe extra nix dazu gesagt ;D

...hätte eigentlich auch alles da....müsste es nur noch zusammenlöten und den Sketch aufspielen....stecke aber im Moment zu tief und zu viel ("zu viel" --> Aussage meiner Frau) in meinen eigenen Projekten drin. ::)

Zitat von: Papa Romeo am 09 März 2019, 20:56:59
..gut Ding, will Weile haben... ;)

Bei mir läuft jetzt die mqtt Version seid knapp einer Woche, allerdings auf dem Steckbrett mit 1.44 " TFT. Ist mir aber definitiv zu klein, das Display.

welchen tft hast du denn genommen ?

Meiner sieht aus, wie dieser:
https://i0.wp.com/henrysbench.capnfatz.com/wp-content/uploads/2016/02/ILI9163-1_44-in-Display-Pin-Outs.png?w=318 (https://i0.wp.com/henrysbench.capnfatz.com/wp-content/uploads/2016/02/ILI9163-1_44-in-Display-Pin-Outs.png?w=318)
Den mhz19 musste ich aber auf pwm messung umstellen.

Hallo Zusammen,
freut mich, dass hier auch wieder Aktivität aufgenommen wird.

Meine Idee ist es, die Erkenntnisse aus dem Projekt Wetterstation (https://forum.fhem.de/index.php/topic,52403.0.html) auch mit dem BME-Sensor zu verschmelzen bzw. zu erweitern.

Ich benutze hierzu dieses Display TFT-2-4-Touch-Shield-V1-0-0-for-LOLIN-WEMOS-D1-mini-2-4-inch (https://de.aliexpress.com/store/product/TFT-2-4-Touch-Shield-V1-0-0-for-LOLIN-WEMOS-D1-mini-2-4-inch/1331105_32919729730.html?spm=a2g0x.12010615.8148356.4.5f9d7dbcl3Dtmc) mit dem ESP8266-Wemos D1.
Das Display hat den Vorteil, dass man den ESP auf die Displayplatine mit aufstecken kann.
Da die Steckerleiste doppelt ausgeführt ist, kann man Erweiterungen sehr leicht aufstecken.  Der Aufbau fällt dadurch auch sehr kompakt aus.
Hierbei bin  ich gerade am Ausarbeiten einer passenden Platine und am Einarbeiten in KiCAD.  ::)

Außerdem bin ich dabei, die Sensordaten zusätzlich in die IOT-Cloud (https://forum.fhem.de/index.php/topic,99812.0.html)  zu versenden.

Zitat..gut Ding, will Weile haben... ;)

//--- settings for LOLIN TFT2.4 with Wemos D1 mini-pinout
//---
#define TFT_DC      D8     //D2
#define TFT_CS      D0     //D1
#define TFT_LED     D4     //D8

/* #define HAVE_TOUCHPAD */
#define TOUCH_CS    D3
#define TOUCH_IRQ   255

Grüße,
Jürgen

Den BME680 habe ich in die Wetterstation mit eingebunden:
https://forum.fhem.de/index.php/topic,52403.msg934892.html#msg934892 (https://forum.fhem.de/index.php/topic,52403.msg934892.html#msg934892)

Den TFT habe ich mir gestern gerade bestellt :-)
Eigentlich sollten da doch die i2c Pins für den bme280 und den max Sensor und ein pwm Pin für den MHz frei sein?

Ja, die Pins sind frei.
Ich ergänze die Doku noch ...  ;D

Schade ist heute noch nicht angekommen. Hat jemand ein Tip für ein passendes Gehäuse für den TFT?

3D-gedruckt, wenn die Implementirung durch ist.
Der Sensor muss irgendwie/irgendwo clever positioniert werden um die Einflüsse des ESP
so gering wie möglich zu halten ...

Das Gehäuse hier passt nicht?

Hallo Jörg,

ich denke eher, starsurfer meint sowas: thingiverse (https://www.thingiverse.com/thing:3566958) aus der Implementierung: Wetterstation (https://forum.fhem.de/index.php/topic,52403.msg934892.html#msg934892)

Dort ist die Grafik um 180 Grad gedreht und der Wemos kommt dadurch nach unten.

Mir schwebt etwas Ähnliches vor, ist mir aber noch etwas zu klobig. Der/die Sensor(en) im Standfuß integriert würde ich bevorzugen. 
Mache mal eine Zeichnung ....  ;)

Jetzt muss ich doch etwas intensiver an Deine Umsetzung!  ;) :)

Grüße,
Jürgen

Also für die Wetterstation habe ich das 2,8 von hier genommen: https://www.thingiverse.com/thing:2172068

Ist echt schick.

Grüße Jörg

Jep so etwas habe ich mir vorgestellt. Den MHZ vielleicht nach hinten in den Standfuß und den MAX44009und BME rechts und Links neben das Display. Der MAX44009 braucht ja dann noch irgendwie ein Loch um die Helligkeit auch messen zu können.

@herrmannj
Ich bin mir nicht sicher ob der TFT in dein Gehäuse paßt, außerdem müßte es irgendwie Füße bekommen, damit es aufrecht stehen kann.
Wenn dich die Diskussion hier zu den TFT's stört, sagst du bitte Bescheid, dann diskutieren wir das in einem extra Thread.

aktuell bin ich in einem anderen Projekt recht eingespannt.

Trotzdem hier mal die aktuelle FW Version.

Beim Zusammenbau:
- die LEDs an der Front müssen leicht versetzt eingebaut werden (vor dem Löten mech. ausprobieren/einpassen)
- U+ für die LEDs _nicht_ über die 5V via Diode sondern direkt die 3.3V nehmen (liegen ohnehin auf der Frontplatine)
- der Widerstand für die LDRs sollte 1k sein (FW bereits darauf angepasst) _und_ von LDR (ESP A0) auf Masse gehen, also nur ein Pin wie vorgesehen, der andere Masse!

Die Firmware legt im Augenblich tVoc auf die Linke, Co2 auf die Rechte LED - das ist ganz witzig aber nicht das finale Ziel. Farben sind aktuell Lila (400ppm) -> Grün (ca 800pmm) -> Gelb -> Rot. Noch höher wird dann wieder Lila weil die Werte noch nicht geclippt sind.