CO2-meters voor in huis

[TD-er]

balk schreef op zaterdag 5 augustus 2017 @ 15:42:
[...]

Ik heb recentelijk ook espeasy icm mhz19 gebruikt en liep tegen iets soortgelijks herinner ik me nu. De code checkt of de mhz19 betrouwbare waardes uitspuugt. Als de sensor net aan staat of als hij in de zon of tocht ligt dan komt er niks uit. Laat de sensor eens een paar uur rustig liggen. Kijk ook zo nu en dan in de log van espeasy.

De S-waarde staat netjes op 64, dus die is stabiel.
ESP-easy log:

code:

26034969 : MHZ19: PPM value: 701 Temp/S/U values: 24/64/11051.00

Domoticz log (zowel MQTT en HTTP-push)

code:

2017-08-05 15:46:35.460 MQTT: Topic: domoticz/in, Message: {"idx":73}
2017-08-05 15:46:35.549 Python: Changed: ID: 73 Name: ESPeasy CO2, Type: 243, subType: 31, switchType: 0, s_value: 701.0000, n_value: 0, n_value_string: 701.0000, last_update_string: 2017-08-05 15:45:35

Edit:
Ik heb maar even een issue aangemaakt op de Github van ESPeasy: https://github.com/letscontrolit/ESPEasy/issues/465

[ Voor 6% gewijzigd door TD-er op 05-08-2017 16:08 . Reden: Github issue gemaakt. ]

[TD-er]

Weet iemand of de ESP easy firmware toevallig ook Automatic Baseline Calibration aanzet? Of als 'ie er niets mee doet, of ABC mogelijk aan staat vanuit de fabriek?
Vanmorgen was een van de sensoren hier namelijk een tijdlang op 400ppm en loopt nu weer heel langzaam iets op.
Dus het heeft er alle schijn van dat 'ie de laagste waarde van gisteren als "400 ppm" beschouwt.
De andere sensor vertoont nog niet dergelijk gedrag, of is de meting in elk geval veel logischer dan met deze sensor.

[ThinkPad]

Ik reboot de ESP automatisch (via cronjob op ander apparaat roep ik de reboot URL aan) elke nacht omdat ik zeker wil weten dat de uitlezing correct functioneert.

Ik stuur dan 2 min na de reboot ook voor de zekerheid het commando om de ABC uit te zetten.

[TD-er]

@ThinkPad
Heb je toevallig ook de url, danwel het commando om de ABC uit te zetten?
Dan zal ik 'm nog even een keer 'ijken' op m'n werk (in de bossen van Dwingeloo, veel schoner zal de lucht niet worden) en zal ik de ABC van de andere uitzetten.

[ThinkPad]

0 6 * * * /usr/bin/curl -m 30 --silent "http://192.168.6.18/?cmd=reboot" > /dev/null 2>&1
2 6 * * * /usr/bin/curl -m 30 --silent "http://192.168.6.18/control?cmd=mhzabcdisable" > /dev/null 2>&1

En voor calibreren (let niet op de 'zero', hij zet hem niet op nul maar op 400):
http://192.168.6.18/control?cmd=mhzcalibratezero

[TD-er]

ThinkPadd schreef op zondag 6 augustus 2017 @ 10:17:
[...]
En voor calibreren (let niet op de 'zero', hij zet hem niet op nul maar op 400):
http://192.168.6.18/control?cmd=mhzcalibratezero

Zet 'ie dan de huidige waarde op 400, of de laagst gemeten waarde? En laagst gemeten sinds wanneer? Laatste reboot?

[ThinkPad]

Huidige waarde als 400

[TD-er]

ThinkPadd schreef op zondag 6 augustus 2017 @ 13:05:
Huidige waarde als 400

Prima, dat is min of meer praktisch uitvoerbaar

Ik heb gelijk maar even een Github issue aangemaakt, want dit wil je niemand aandoen.
De init procedure moet gewoon de ABC uitzetten en iemand die dat echt wil, kan het aanzetten.
Maar ik kan me niet voorstellen dat iemand dat echt wil. Een reset zou je wel willen.

[ThinkPad]

Maar heb je al een bron waaruit blijkt dat het default aan staat dan? Misschien staat het dat wel en is mijn commando puur om het uit te zetten, nadat je het met de hand hebt aangezet.

Edit: ik lees net het issue en keek naar de screenshots. Heb ik hier nooit gezien, zou het dan toch by default aan staan?

Ik denk dat @infernix dat wel weet, die heeft destijds ook de aanpassingen gedaan die inmiddels zijn meegenomen in de ESPEasy releases.

[ Voor 17% gewijzigd door ThinkPad op 06-08-2017 22:23 ]

[infernix]

ABC is default aan ja. En als je die uitzet gaat ie weer aan bij powercycle.

Maar je kunt niet zomaar uitzetten bij poweron, want als je poweron doet van de sensor terwijl je CO2 in de 1k zit, dan gaat ie dat als baseline van 400 zien vrees ik. En dan krijg je dus permanent verkeerde waardes tenzij je toevallig eerst hele tijd ramen en deuren open had.

Dus t is een tradeoff: de default ABC aan t.o.v. automatisch uit en er vanuit gaan dat de gebruiker intelligent is en correcte calibratie uitvoert. Dat laatste is geen goed uitgangspunt, dat weet iedereen Wat wel evt zou kunnen is een setting maken in ESPEasy zodat je ABC kunt disablen bij poweron.

En je idee wat je op github aankaart om dan de ABC uit te zetten en dan zelf ABC te maken in ESPEasy gaat ook niet werken wat je daarmee doet is alleen het ABC window vergroten danwel verkleinen. Heb ik al mee gespeeld, heeft niet de werking die je zoekt.

[TD-er]

Uit de code blijkt niet dat 'ie aangezet is, maar mijn sensoren hebben geen enkele schrijf-actie gehad, alleen leesacties en die zijn dus wel overduidelijk de draad kwijt.
Zijn 2 sensoren van verschillende aanbieders en ze zijn beide na ruwweg 24h onafgebroken werken compleet de weg kwijt met enorme sprongen in de data tot gevolg.
Nu net de ene weer buiten voorzien van een nieuwe baseline en lijkt in elk geval goed te werken met realistische waarden. (1200 ppm in een ruimte waar al uren niemand is, met raam open was niet realistisch bijv.)

Het lijkt er dus op dat de ABC in de 2 sensoren die ik heb beide vanuit de fabriek aan staan, of in elk geval nu aan te staan. En ABC is iets wat je helemaal niet standaard aan wilt hebben staan.
Sterker nog, het resetten van de 2e sensor lijkt ook niet helemaal lekker te werken. Deze sensor ligt nu buiten, maar de temperatuur lijkt te snel af te nemen, waardoor je eerst na een reset een bogus waarde ziet, dan iets van 475 of 476 en dan weer een veel te hoge waarde. (of er zit een inbreker naast de sensor te wachten tot we naar bed gaan )

[infernix]

Ik zei al, ABC is default aan ja. Dat default == de sensor hardware. Dus mag je de fabrikant over mailen als je dat niet wilt

Over de (in)accuracy van de sensor heb ik al eerder gepost.

En wbt temperatuur, calibreren op een andere temp dan de temp waar de sensor zich in bevindt heeft geen zin. CO2 meting lijkt namelijk gecorreleerd aan temp.

[ Voor 46% gewijzigd door infernix op 06-08-2017 22:56 ]

[TD-er]

infernix schreef op zondag 6 augustus 2017 @ 22:33:
Ik zei al, ABC is default aan ja. Dat default == de sensor hardware. Dus mag je de fabrikant over mailen als je dat niet wilt

Over de (in)accuracy van de sensor heb ik al eerder gepost.

Ik snap dat dat gedrag is vanuit de firmware. Neemt niet weg dat een product als ESP easy de aangewezen middleman is om ongewenst gedrag van de firmware te omzeilen
Dat van de fabrikant mailen, dat wil ik wel eens doen, maar dan meer om te vragen of ze het protocol volledig willen beschrijven/vrijgeven Voor zover ik weet, is dat namelijk nog steeds alleen maar door reverse-engineering verkregen en dus niet compleet. Zeker interessant leesvoer (ook dat Russische forum ) maar jammer genoeg nog niet alles duidelijk.
Hen verzoeken om gedrag van de firmware aan te passen lijkt me een beetje zinloos

En onnauwkeurig in de zin van een constante en voorspelbare afwijking, is niet erg. Als je maar voorspelbaar gedrag hebt en dat is met zo'n ABC die (IMHO veel te vaak) ingrijpt zeker niet voorspelbaar meer te noemen.

[infernix]

Tsja je moet die dingen gewoon gebruiken als range. Ik heb ze nu al maanden lang met ABC aan en dat gaat prima zolang je gewoon a) voldoende ventileert (met ramen! niet enkel MV) en b) de waardes grof inschat.

code:

{%- set co2_bedroom_1 = ((states.sensor.bedroom_1_co2.state|int - 600 ) / ( 1500 - 600 )) * 100 %}
{%- set co2_bedroom_2 = ((states.sensor.bedroom_2_co2.state|int - 600 ) / ( 1500 - 600 )) * 100 %}

Dit zet de sensor waarden om in een percentage waarbij 600ppm 0% is en 1500ppm 100% en daar drijf ik dan de MV PWM mee aan. Hoogste waarde wint. YMMV maar dit werkt hier uitstekend.

[TD-er]

Het valt me trouwens op dat de sensor zelf meerdere entries heeft, per temperatuur.
De sensor ligt nog steeds buiten en daar koelt het nu snel af. Zolang de integer waarde van de sensor-temp nog gelijk is, schommelt 'ie na reset van het nulpunt netjes rond de 400-430 ppm. Als de temp 1 graad lager is, is bij gelijke RAW waarde de PPM-waarde hoger. Echter kom je dan nog een graadje lager, dan is de RAW waarde en de PPM-waarde ineens weer compleet anders en is de PPM weer rond de 1000 ppm.
Weer een reset en het verhaaltje begint weer van voren af aan.
Mogelijk dat de interne ABC al die dingen weet af te leiden, maar het heeft er alle schijn van dat de handmatige reset alleen 1 tabel-entry update.

Dat verklaart ook waarom de 'reset' van de eerste sensor vrij makkelijk leek te gaan. Toen was de buiten temperatuur nog vrijwel gelijk aan die hier binnen.

Edit:
Ik zat me net te bedenken dat de relatieve luchtvochtigheid natuurlijk ook omhoog vliegt, nu het buiten afkoelt.
Dat kan ook effect hebben op de meetwaarde en/of de interpretatie ervan.

[ Voor 10% gewijzigd door TD-er op 06-08-2017 23:40 ]

[Lennart_1337]

Lennart_1337 schreef op maandag 31 juli 2017 @ 14:08:
[...]

Ik zit hier ook naar te kijken, zag op het Homey forum dat iemand bezig is met support voor Homey.
Ziet er goed uit maar geen idee of het apparaat betrouwbaar is.
Ook vind ik de handleiding erg summier, op de foto's zie je ook onderin het scherm iets met ventilatie en de stand daarvan maar kan er niks over in de handleiding vinden.
Verder zit er ook een VOC sensor in en staat dit ook op het scherm en de foto's maar komt de handleiding niet verder dan 'optional'; zit het erin of niet
Beetje onduidelijk dus allemaal.

Ik heb navraag gedaan bij MCO:

In the pictures I see ventilation level icons on the bottomside of the screen.
But the manuel doesn't mention this, is there documentation about this?

1. Our current MH9 do not have any output terminals for direct control the ventilation system, it need be customized according to ventilation system spec which provided by the customers who want to cooperate with us for OEM/ODM projects, the current version just work as a sensor.

The manuel says: "VOC (optional)", is this not supported by every MH9? do I have to buy something extra for the VOC functionality?

2. For VOC(optional), actually we have been selling MH9 to our dealers with VOC sensor, but you can only read VOC level from MH9 screen, since by now Z-Wave protocol do not have command to read VOC level. If you do not need VOC sensor, you can ask for this special requirement from your supplier.

VOC levels:
The manuel says: "VOC (optional)", is this not supported by every MH9? do I have to buy something extra for the VOC functionality?

3. For cable connectivity, there is no need to connect with other wires besides the power, unless you require the customization e.g. controling the ventilation system according to indoor air quality.

Handig dus om te weten dat de afbeeldingen dus dingen tonen die het apparaat in zijn huidige vorm niet kan. VOC level is grappig maar dus niet met zwave uit te lezen.

Helaas nog nergens iets over de nauwkeurigheid kunnen vinden

[TD-er]

Iemand nog een idee hoe je de MH-Z19 nu goed kunt herkalibreren?

Zoals je ziet, zit 'ie een groot deel van de tijd (met de buitendeur open) op de 400 ppm en als 'ie maar een beetje stijgt, zit 'ie gelijk op de 1000+ ppm.
Dit is dus met ABC enabled en dat ding is compleet de weg kwijt.
Ik heb 'm al een paar keer 's avonds buiten gehad om het nulpunt opnieuw vast te leggen, maar dat helpt dus eigenlijk niet. (voor 11 uur vanmorgen geen meting, want Domoticz hing, dus geen enkele sample vastgelegd)
Kennelijk heeft 'ie om 17:50 weer een ABC gedaan, want het is weer compleet chaos.
Om 11:25 heb ik 'm zelf een zero gegeven nadat de meting al even op een minimum van 600 ppm stond (met de deur open).
Maar zoals je kunt zien was de boel om even na 16h ook al chaos met van die enorme sprongen toen we thuiskwamen en om 16:45 de deur open.

In elk geval is dit de sensor die eigenlijk niet meer voorspelbaar werkt. Ik zal proberen om 'm geforceerd op ABS disabled te houden wanneer er een geloofwaardig nulpunt vastgelegd is.

[infernix]

TD-er schreef op zondag 13 augustus 2017 @ 21:52:
In elk geval is dit de sensor die eigenlijk niet meer voorspelbaar werkt. Ik zal proberen om 'm geforceerd op ABS disabled te houden wanneer er een geloofwaardig nulpunt vastgelegd is.

Misschien heb je een maandagochtend sensor? heb je er maar 1?

[TD-er]

infernix schreef op maandag 14 augustus 2017 @ 18:19:
[...]


Misschien heb je een maandagochtend sensor? heb je er maar 1?

Nope, heb er 2 en de 3e is onderweg
Beide zijn in elk geval niet happy op dit moment en vertonen vergelijkbaar wangedrag van een overduidelijk verkeerd afgesteld nulpunt.

[TD-er]

Nog even terugkomend op die nulpunt kalibratie...

Als antwoord op mijn vraag: "Zet 'ie dan de huidige waarde op 400, of de laagst gemeten waarde? En laagst gemeten sinds wanneer? Laatste reboot?"

ThinkPadd schreef op zondag 6 augustus 2017 @ 13:05:
Huidige waarde als 400

Ik zat net de datasheet van de S8 sensor door te lezen en het heeft er alle schijn van dat de MH-Z19 er op z'n minst op gebaseerd is. Zelfs de afmetingen en de pin-out lijken gelijk te zijn.
Blz 6(8 ) van die datasheet gaat over de nulpunt kalibratie.

For post calibration convenience, in the event that one cannot wait for the ABC algorithm to
cure any calibration offset two manual calibration procedures are offered. A switch input is
defined for the operator or master system to select one of the two prepared calibration codes.
Optional calibrations are bCAL (background calibration), which requires that the sensor is
exposed to fresh air (400 ppm CO2) and CAL (zero calibration), which requires the sensor
measuring cell to be completely evacuated from CO2 e.g. by exposing it to Nitrogen or Soda
Lime CO2 scrubbed air. Make sure that the sensor environment is steady and calm!

Het lijkt er op dat die nulpunt-kalibratie best een tricky operatie is en zeker niet naar de 400 ppm gaat.
Ze maken daar ook een onderscheid in bCAL (400 ppm niveau) en CAL (0 ppm)
Als je de pin-beschrijving leest van de calibratie, dan is er een verschil in functionaliteit afhankelijk van hoe lang je de pin actief zet:

Digital input forcing background calibration.
Configured as digital input (when closed for minimum 4, max 8 seconds) bCAL (background calibration) assuming 400 ppm CO2 sensor exposure

Zero calibration (when closed for minimum 16 seconds) CAL (zero calibration) assuming 0 ppm CO2 sensor exposure

Dat zou ook verklaren waarom mijn ene (MH-Z19) sensor nu praktisch onbruikbaar is na een paar keer aanroepen van de 'calibratezero' functie.
Die nulpunt kalibratie zou je dus niet zomaar moeten aanroepen en zeker niet vlak na elkaar.

---

Hier trouwens een voorbeeld van een goed werkende sensor wiens ABC aan staat en na een dag zonder ventilatie dus het nulpunt veel te hoog heeft ingesteld.

Om 12:40 heeft de ABC 'toegeslagen' en is de concentratie ineens bijgesteld van 916 naar 631, oftewel geeft daarna ruwweg 300ppm te laag aan.

[ Voor 37% gewijzigd door TD-er op 19-08-2017 12:06 ]

[ThinkPad]

Hoe lees je de MH-Z19 uit? Via ESPEasy?

Je hebt namelijk 'calibrate zero' en 'calibrate span'. Die laatste moet bij 0 ppm gebeuren meen ik, met een testgas in de sensor. Die eerste kun je hem gewoon buiten leggen voor een halfuurtje/uurtje zonder wind en niet in de zon en dan kalibreren, dan staat hij op 400 ppm.

Misschien kan @infernix het beter uitleggen, die heeft toen e.e.a. aan code gepushed naar de ESPEasy repository. Hij weet de verschillen tussen de calibratiemodi beter denk ik.

[infernix]

spanpoint moet je doen op ik dacht 2000 ppm, dus die moet je nooit doen; als die spanpoint waarde permanent wordt opgeslagen en je doet dat ooit met een andere ppm dan de sensor verwacht dan vermoed ik dat je 'm weg kan gooien (tenzij je gas koopt en een exact 2000ppm situatie creert). kan ook wel 5000ppm zijn.

zero point calibration mag gewoon rond de 400ppm zijn; zie spec sheet http://www.winsen-sensor....or/mh-z19b-co2-ver1_0.pdf "NOTE：ZERO POINT is 400PPM, PLS MAKE SURE THE SENSOR HAD BEEN WORKED UNDER 400PPM FOR OVER 20MINUTES" - wat je uit de specsheet van een andere sensor door een andere fabrikant haalt lijkt me niet heel relevant.

anyhow ik blijf het zeggen, deze sensoren zijn gewoon niet heel exact maar zijn prima als indicator. als je niet goed kunt ventileren (bijv je hebt geen ramen in de ruimte en geen MV), koop dan voor betere precisie en accuraatheid een andere sensor.

[Wolfram55]

Ik heb er nu 3 .... althans 2 werkende en 1 die het niet doet.

De 1e heb ik volgens mij niks mee gedaan. Geen reset of wat dan ook. Maar ben er niet 100% zeker meer van.
De 2e ben ik mee aan het "klooien" gegaan. MHZreset en abc ..... en die doet het dus niet meer
De 3e niks mee gedaan ..... en dat weet ik 100% zeker.

De 1e draait nu zo'n maand of 5 en de 3e paar weken.

Heb ze beide volledig hetzelfde geplaatst ( in 'n doosje zoals van @ThinkPad ) en met dezelfde lader en wemos. Ook liggen ze gebroederlijk naast elkaar.

Afgelopen maandag ben ik ze dus bij wijze van test gaan monitoren.




Wat mij opvalt is dat de 1e dag het verschil 90ppm was en dat werd naargelang de tijd verstreek minder tot gelijk.

Wat U-waarde betreft:
de 2e spike ( bij 8/16 16:00 ) ging er een raampje open. Overige spikes zijn niet te plaatsten.
Afgelopen nacht gebroederlijk naast/op elkaar wat waardes betreft.

De temperatuur vindt ik ook best wel ok.

Wat ik hiermee wil zeggen, het lijkt erop dat ze best wel lang nodig hebben om te stabaliseren en ..... maar dat weet ik natuurlijk helemaal niet .... het gaan "spelen" met parameters of calibreren ...... is dat verstandig ??

[ThinkPad]

Dat idee had ik inderdaad ook, dat ze best een poos nodig hebben om te stabiliseren.
De sensor werkt hier prima. Misschien is het aantal ppm niet helemaal nauwkeurig, maar hij voldoet hier prima om de MV op een hogere stand te zetten zodra er meer dan één iemand in huis is.

[TD-er]

@ThinkPad Ik lees ze inderdaad uit met ESP easy.

infernix schreef op zaterdag 19 augustus 2017 @ 17:42:
spanpoint moet je doen op ik dacht 2000 ppm, dus die moet je nooit doen; als die spanpoint waarde permanent wordt opgeslagen en je doet dat ooit met een andere ppm dan de sensor verwacht dan vermoed ik dat je 'm weg kan gooien (tenzij je gas koopt en een exact 2000ppm situatie creert). kan ook wel 5000ppm zijn.

zero point calibration mag gewoon rond de 400ppm zijn; zie spec sheet http://www.winsen-sensor....or/mh-z19b-co2-ver1_0.pdf "NOTE：ZERO POINT is 400PPM, PLS MAKE SURE THE SENSOR HAD BEEN WORKED UNDER 400PPM FOR OVER 20MINUTES" - wat je uit de specsheet van een andere sensor door een andere fabrikant haalt lijkt me niet heel relevant.

Die specsheet van de andere fabrikant geeft aan dat ze 2 modi hebben, waarbij de 2e modi (0-punt) vrij goed beschrijft wat er volgens mij met een van mijn sensoren mis is.
Probleem is namelijk dat ik bij de 400ppm kalibratie per ongeluk 2x vlak achter elkaar een zero-commando heb gegeven. Probleem was namelijk dat ik vergeten was het IP-adres aan te passen in de query van het afstellen van het 400ppm punt, toen beide sensoren al even buiten lagen in 't donker. Die ene die 2x een zero punt commando na elkaar had ontvangen was dus helemaal van slag sindsdien.

infernix schreef op zaterdag 19 augustus 2017 @ 17:42:
anyhow ik blijf het zeggen, deze sensoren zijn gewoon niet heel exact maar zijn prima als indicator. als je niet goed kunt ventileren (bijv je hebt geen ramen in de ruimte en geen MV), koop dan voor betere precisie en accuraatheid een andere sensor.

Het probleem met die ene sensor is dus dat 'ie waarden van 400 - 450 aangeeft en de volgende waarde is rond de 1000. Het bereik is dan ook kleiner dan met de andere sensor, terwijl ze naast elkaar liggen.
De curve is dus wel te herkennen, maar de meetwaarde is totaal onbruikbaar.

Die andere is prima bruikbaar, mits de ABC niet roet in het eten gooit. De datasheet van die S8 sensor geeft aan dat hun ABC kijkt over een periode van 60 dagen en dan ook nog heel geleidelijk gaat corrigeren. Dat klinkt veel bruikbaarder.
Waarschijnlijk zal die ook over meer samples middelen waardoor je een veel rustiger gedrag krijgt en meer de trend volgt en niet pieken oppikt.

[infernix]

TD-er schreef op zaterdag 19 augustus 2017 @ 21:05:
Die specsheet van de andere fabrikant geeft aan dat ze 2 modi hebben, waarbij de 2e modi (0-punt) vrij goed beschrijft wat er volgens mij met een van mijn sensoren mis is.

Volgens mij speculeer je op basis van de specsheet van een compleet ander product wat er met deze sensor aan de hand is? Zie ik de logica niet echt van in.

Als je niet per ongeluk (of bewust) spanpoint calibration hebt gedaan, leg dat ding dan eens weg in een ruimte die frequent frisse lucht ziet en kijk eens wat ie doet als ie een paar weken draait. Gewoon met ABC. En misschien heb je gewoon pech en heb je 'm gesloopt of heb je slechte productie modellen. 't Is de goedkoopste CO2 sensor die bestaat dus is niet echt uit te sluiten.

De datasheet van die S8 sensor geeft aan dat hun ABC kijkt over een periode van 60 dagen en dan ook nog heel geleidelijk gaat corrigeren. Dat klinkt veel bruikbaarder.

Yes, een duurdere sensor is ongetwijfeld beter

[ThinkPad]

Ik zou een nieuwe MH-Z19 bestellen, deze is verklooid omdat je 2x die calibratie hebt gedaan vermoed ik.

[TD-er]

ThinkPadd schreef op zaterdag 19 augustus 2017 @ 21:22:
Ik zou een nieuwe MH-Z19 bestellen, deze is verklooid omdat je 2x die calibratie hebt gedaan vermoed ik.

Nieuwe is al (een tijdje) onderweg, alleen duurt zo lang he.

infernix schreef op zaterdag 19 augustus 2017 @ 21:11:
[...]

Volgens mij speculeer je op basis van de specsheet van een compleet ander product wat er met deze sensor aan de hand is? Zie ik de logica niet echt van in.

Probleem met die MH-Z19 is dat er heel weinig van gedocumenteerd is vanuit de fabrikant. De rest is proefondervindelijk vastgesteld.
En aangezien dat andere product van een andere fabrikant er in zoveel vlakken op lijkt, zou het mij niet verbazen als er op andere vlakken ook 'inspiratie' is opgedaan. Vandaar dat ik daar zat te kijken.

infernix schreef op zaterdag 19 augustus 2017 @ 21:11:
Als je niet per ongeluk (of bewust) spanpoint calibration hebt gedaan, leg dat ding dan eens weg in een ruimte die frequent frisse lucht ziet en kijk eens wat ie doet als ie een paar weken draait. Gewoon met ABC. En misschien heb je gewoon pech en heb je 'm gesloopt of heb je slechte productie modellen. 't Is de goedkoopste CO2 sensor die bestaat dus is niet echt uit te sluiten.

Het is inderdaad mogelijk dat het een maandagmorgenmodel betreft.
Hij ligt al een aantal dagen op en plek die met enige regelmaat goed geventileerd is en toch niet te vochtig. (vocht heeft volgens mij ook invloed op IR-absorptie)
Maar goed, we hebben nu een onbruikbare sensor, dus prima slachtoffer om eens te kijken of ik de nulpunt-kalibratie mode kan herhalen.
Indien wel, dan lijkt me dat reden voor een softwarematige beveiliging dat je 't reset commando niet vaker dan eens per minuut mag uitvoeren.

infernix schreef op zaterdag 19 augustus 2017 @ 21:11:
Yes, een duurdere sensor is ongetwijfeld beter

Jammer alleen dat 'ie zoveel duurder is

[ Voor 4% gewijzigd door TD-er op 19-08-2017 21:32 ]

[Dirickteur]

Is het ook mogelijk om de gemeten temperatuur in Domoticz te krijgen? Ik heb de nieuwste build geïnstalleerd (2.0.0 dev11) op de ESP.

[Sabbi]

Ik heb nu ook een MH-Z19 in gebruik, het MH-Z19B model, zonder test-punten maar wel met 'RoHS' op de printplaat. (zie deze post van Wolfram55). Ik krijg ook alleen geldige waardes terug als ik hem met 5 volt voed, 3.3 volt werkt niet. Maar de sensor werkt wel gewoon, en een calibratie doet het ook goed.

In het bericht dat deze naar m'n ESP8266 terugstuurt krijg ik nooit een Stability waarde mee, deze is altijd nul. Je kan hem dan ook niet direct met ESPEasy gebruiken omdat die hier een waarde in verwacht. Ik heb zelf een optie gebouwd om dat uit te zetten.

Ik stuur de data nu met MQTT door naar Cayenne, de data ziet er goed uit:

[TD-er]

Negeer je dan nu geen enkele meetwaarde, doordat je de S-waarde niet kunt gebruiken?

Edit:
Hmm, die onderste uit die post heb ik ook net binnen gekregen zie ik

[ Voor 63% gewijzigd door TD-er op 25-08-2017 21:34 ]

[Sabbi]

TD-er schreef op vrijdag 25 augustus 2017 @ 21:23:
Negeer je dan nu geen enkele meetwaarde, doordat je de S-waarde niet kunt gebruiken?

Edit:
Hmm, die onderste uit die post heb ik ook net binnen gekregen zie ik
[afbeelding]

Ik ben er vrijwel zeker van dat de S waarde die het originele model doorgeeft alleen een softwarematige error-detectie is. Dat wil zeggen, als de meetwaarde meer dan X procent afwijkt van de vorige 10 metingen, wordt die waarde op nul gezet. Hiermee kan je de jitter/spikes uit de data wegfilteren.

Een plaatje uit de blogpost die dit gedrag beschreef:


Hier zie je dus de afwijkende metingen en de momenten dat S laag wordt gemaakt. Het valt op dat er steeds een dip is, en dat dan langzaam de waarde weer stijgt. Deze opvallende dips kan ik in de grafieken van de MH-Z19B niet terugvinden. Het lijkt me dan ook dat Winsen het B model ofwel heeft verbeterd dat deze dips niet meer voorkomen of zelf al een smoothing heeft toegepast waardoor de dips niet meer in de output terecht komen, waardoor het S veld doorgeven niet meer nodig is.

[TD-er]

Klinkt wel als een bruikbare verbetering.
Zeker omdat er ook nog steeds een PWM-output op zit die met het gebruik van de S-waarde behoorlijk zinloos is, omdat je dan de seriële uitgang niet gebruikt, dus niet weet wanneer 'ie onbruikbaar is.

[jvdzande]

Ik heb ook een MH-Z19B een week in gebruik en deze geeft ook geen S en U waarde terug, maar werkt verder prima. Heb ook naar een handleiding op het internet gezocht en deze geeft ook aan dat die bytes 0 zijn:
http://www.winsen-sensor....or/mh-z19b-co2-ver1_0.pdf

Ik heb de beschikbare ESPEASY _P049_MHZ19.ino wat aangepast zodat die hier goed mee omgaat door gewoon de S test aan te passen. Ook heb ik de logica van het lezen van de waarden wat aangepast en gewoon doorleest todat die 0xFF & 0x86 heeft gelezen en dan gewoon de volgende 6 bytes. Dit zorgt ervoor dat hij gelijk de juiste waarde kan lezen bij het opstarten en geen " fix buffer alignment" process meer hoeft te doen.
Verder nog wat wijzigingen in ESPEASY gemaakt zodat hij prima de waarde naar Domoticz via HTTP maakt naar een dummy AirQuality device en verder geen Rule nodig is.

[ Voor 10% gewijzigd door jvdzande op 27-08-2017 22:47 ]

[infernix]

Sabbi schreef op vrijdag 25 augustus 2017 @ 13:13:
In het bericht dat deze naar m'n ESP8266 terugstuurt krijg ik nooit een Stability waarde mee, deze is altijd nul. Je kan hem dan ook niet direct met ESPEasy gebruiken omdat die hier een waarde in verwacht. Ik heb zelf een optie gebouwd om dat uit te zetten.

Kun je eens een boot log posten van die sensor? Kan kijken of er verschil is zodat we kunnen detecteren of 't een is die S waardes stuurt.

jvdzande schreef op zondag 27 augustus 2017 @ 22:40:Ik heb de beschikbare ESPEASY _P049_MHZ19.ino wat aangepast zodat die hier goed mee omgaat door gewoon de S test aan te passen. Ook heb ik de logica van het lezen van de waarden wat aangepast en gewoon doorleest todat die 0xFF & 0x86 heeft gelezen en dan gewoon de volgende 6 bytes. Dit zorgt ervoor dat hij gelijk de juiste waarde kan lezen bij het opstarten en geen " fix buffer alignment" process meer hoeft te doen.

Kun je daar een PR voor sturen naar upstream?

[ Voor 36% gewijzigd door infernix op 29-08-2017 12:40 ]

[jvdzande]

Kun je daar een PR voor sturen naar upstream?

Ik weet niet of dit gewenst is, omdat er nog al wat werk is gedaan in het orgineel rond het testen van de U en S waarden voor die versie van de MHZ19? Mijn github versie is hier beschikbaar mocht je er naar willen kijken: https://github.com/jvanderzande/ESPEasy

Jos

[Sabbi]

@infernix , hier heb je vier bootlogs van de MH-Z19B. Verticaal afgedrukt om makkelijker patronen te zien. Hij gooit de eerste +- 12 bytes er meteen uit, is dan een paar seconden langzaam FF aan het sturen, en sluit dan in 1 keer af met de 5 bytes op het einde.

0		0	
29	29	29	29
AD	AD	AD	AD
C9	9	9	9
18	FF	BF	FF
39	2D	2D	2D
39	30	30	30
72	7A	7A	7A
A	21	21	21
59	38	38	38
21	21	21	21
FE	FE	FE	FE
FF	FF	FF	FF
FF	FF	FF	FF
FF	FF	FF	FF
FF	FF	FF	FF
FF	FF	FF	FF
FF	FF	FF	FF
FF	FF	FF	FF
FF	FF	FF	FF
FF	FF	FF	FF
FF	FF	FF	FF
28	28	28	28
8C	8C	8C	8C
21	21	21	21
F5	F5	F5	F5
FF	FF	FF	FF

Voor automatisch het begin van een bericht zoeken bij lezen van de sensor zou ik het zo doen:

Zolang er geen 0xFF gelezen is blijft hij dan doorlezen/wachten tot hij de start van het bericht detecteert.

[TD-er]

Ondanks dat ik heel actief de "ABC disable" naar de MH-Z19 stuur, blijft 'ie de boel weer verzieken met die ABC.
In de datasheet van versie 1, staat de ABC niet genoemd en in versie "B" dus wel.
Kan er iemand bevestigen dat de ABC disable naar behoren werkt bij de "niet-B" versie?
Oftewel de versie die de "undocumented" status-bit (64 = goed, anders = slecht) laat zien in de output.

Alternatief wat ik nu ga proberen is om de sensor telkens na minder dan 24 uur te resetten.

[jvdzande]

Sabbi schreef op dinsdag 29 augustus 2017 @ 23:31:
Voor automatisch het begin van een bericht zoeken bij lezen van de sensor zou ik het zo doen:
[afbeelding]
Zolang er geen 0xFF gelezen is blijft hij dan doorlezen/wachten tot hij de start van het bericht detecteert.

Ik heb de code op deze manier aangepast en werkt prima voor mij:

code:

          long start = millis();
          int counter = 0;
          int skipped = 0;
          String log = F("MHZ19: skipped bytes before 255/134: ");
          while (((millis() - start) < PLUGIN_READ_TIMEOUT) && (counter < 9)) {
            if (Plugin_049_SoftSerial->available() > 0) {
              mhzResp[counter] = Plugin_049_SoftSerial->read();
              if ( counter == 0 && mhzResp[0] == 0xFF ) {
                counter++;
              }
              else if (counter > 0) {
                if ( mhzResp[0] == 0xFF && mhzResp[1] == 0x86) {
                  counter++;
                } else {
                  log += String(mhzResp[0]); log += "/";
                  mhzResp[0] = mhzResp[1];
                  skipped++;
                }
              }
            } else {
              delay(10);
            }
          }

Jos

[jvdzande]

TD-er schreef op woensdag 30 augustus 2017 @ 22:37:
Ondanks dat ik heel actief de "ABC disable" naar de MH-Z19 stuur, blijft 'ie de boel weer verzieken met die ABC.

Krijg jij ook deze response van jouw MHZ19 na het disable commando? Ik krijg hem van mijn MHZ19b:
skipped bytes before 255/134: 255/121/1/0/0/0/0/0/134/

Jos

[ Voor 3% gewijzigd door jvdzande op 31-08-2017 20:26 ]

[Dirickteur]

Hallo!

Ik heb ook een MH-Z19 icm een Espeasy draaien. Ik zie dat de sensor ook temperatuur meet, maar ik krijg deze waarde niet in Domoticz. Kunnen jullie mij daarbij helpen? Ik heb versie 2.0.0 dev11

Alvast bedankt.

[TD-er]

jvdzande schreef op donderdag 31 augustus 2017 @ 20:26:
[...]

Krijg jij ook deze response van jouw MHZ19 na het disable commando? Ik krijg hem van mijn MHZ19b:
skipped bytes before 255/134: 255/121/1/0/0/0/0/0/134/

Daar zal ik vanavond eens op letten.
Klinkt trouwens meer als een 'restart' van de sensor waarna de reader weer in sync moet komen met de datastroom vanaf de sensor.
Voor zover ik me kan herinneren heb ik dat niet voorbij zien komen.

[jvdzande]

Dirickteur schreef op vrijdag 1 september 2017 @ 08:24:
Hallo!

Ik heb ook een MH-Z19 icm een Espeasy draaien. Ik zie dat de sensor ook temperatuur meet, maar ik krijg deze waarde niet in Domoticz. Kunnen jullie mij daarbij helpen? Ik heb versie 2.0.0 dev11

Alvast bedankt.

Je kunt dit doen door een Rule in ESPEASY aan te maken die er ongeveer zo uitziet:

code:

on MHZ19#PPM do
  SendToHTTP,IP-DOMOTICZ,Poort-DOMOTICZ,/json.htm?type=command&param=udevice&idx=IDXPPM&nvalue=[MHZ19#PPM]  
endon

Vervang deze Teksten met de juiste gegevens: IP-DOMOTICZ / Poort-DOMOTICZ / IDXPPM / MHZ19#PPM
De laatste moet je vervangen voor de gegevens in ESPEASY voor naam van het device#PPM, wel tussen [] zetten.

Jos

[Verwijderd]

Hier de TFA Dostmann 'AirCO2ntrol Mini' CO2 Monitor (<60 euro op amazon.de) sinds een kleine twee jaar in gebruik, tot grote tevredenheid.

Ik gebruik een python script om de sensor uit te lezen, maar er is ook een nodejs implementatie.

[ Voor 29% gewijzigd door Verwijderd op 02-09-2017 21:14 ]

[jvdzande]

jvdzande schreef op dinsdag 29 augustus 2017 @ 18:30:
[...]
Ik weet niet of dit gewenst is, omdat er nog al wat werk is gedaan in het orgineel rond het testen van de U en S waarden voor die versie van de MHZ19? Mijn github versie is hier beschikbaar mocht je er naar willen kijken: https://github.com/jvanderzande/ESPEasy

Ik heb even een aparte branch in Github gemaakt met alleen de aanpassingen voor MHZ19b die ik heb gemaakt tov de huidige Mega branch: https://github.com/jvanderzande/ESPEasy/tree/MHZ19b

• Updated reading serial stream to keep reading until 255/134 is found to
  avoid the need for Byte alignment steps.
• Updated the Sensor type to allow ddirect updating of Domoticz dummy
  Voltcraft CO-20 sensor by specifuing its IDX in the config.
• Removed the S and U logic as those aren't supported in the b model

[TD-er]

Voor wie ermee bezig wil, ik heb zonet de MH-Z19 als Fritzling part gemaakt:
https://github.com/TD-er/...s/tree/GijsFritzlingParts
(en ook 2 OLEDs toegevoed, de 128x32 en de 128x64 met een andere pin-out)

Edit:
Tijdelijk even niet gebruiken voor een print. De maten lijken niet helemaal correct te zijn.
Wellicht een probleem tussen export naar SVG in Inkscape en import in Fritzing.
Ga ik vanavond verbeteren.

[ Voor 32% gewijzigd door TD-er op 10-09-2017 14:12 . Reden: Maten kloppen niet. ]

[ergu]

jvdzande schreef op maandag 4 september 2017 @ 18:25:
[...]

Ik heb even een aparte branch in Github gemaakt met alleen de aanpassingen voor MHZ19b die ik heb gemaakt tov de huidige Mega branch: https://github.com/jvanderzande/ESPEasy/tree/MHZ19b

• Updated reading serial stream to keep reading until 255/134 is found to
  avoid the need for Byte alignment steps.
• Updated the Sensor type to allow ddirect updating of Domoticz dummy
  Voltcraft CO-20 sensor by specifuing its IDX in the config.
• Removed the S and U logic as those aren't supported in the b model

Hallo jvdzande, ik heb ook een b versie en ik krijg netjes een ppm en temperatuur waarde. Ik wil graag jouw versie flashen maar weet niet hoe ik je versie moet compileren. Is er ergens een uitleg?
Dit is wat ik met de officiele EASY MEGA versie krijg:
MHZ19: Unstable reading, ignoring! PPM value: 546 Temp/S/U values: 18/0/817.00
Sensor is op dit moment op de vensterbank (raam is open), vandaar de PPM waarde van 546.

Alvast bedankt! Ergu

[ Voor 11% gewijzigd door ergu op 10-09-2017 17:12 ]

[TD-er]

Volgens mij kan die patch nog wat simpeler, want een 0 als S-waarde komt met de niet-B versie niet voor.
Dus
if (S==0 || S==64) {
// Gebruik de data
}

[jvdzande]

ergu schreef op zondag 10 september 2017 @ 17:03:
[...]

Hallo jvdzande, ik heb ook een b versie en ik krijg netjes een ppm en temperatuur waarde. Ik wil graag jouw versie flashen maar weet niet hoe ik je versie moet compileren. Is er ergens een uitleg?
Dit is wat ik met de officiele EASY MEGA versie krijg:
MHZ19: Unstable reading, ignoring! PPM value: 546 Temp/S/U values: 18/0/817.00
Sensor is op dit moment op de vensterbank (raam is open), vandaar de PPM waarde van 546.

Alvast bedankt! Ergu

Ik heb gewoon de tutorial van de espeasy website gevolgd: https://www.letscontrolit...y#Source_code_development

Jos

[jvdzande]

TD-er schreef op zondag 10 september 2017 @ 18:56:
Volgens mij kan die patch nog wat simpeler, want een 0 als S-waarde komt met de niet-B versie niet voor.
Dus
if (S==0 || S==64) {
// Gebruik de data
}

Ik heb de hele S test uit de laatste versie gehaald en het lezen van de C1101 naar PLUGIN_ONCE_A_SECOND verplaatst om zo direct het antwoord van de sensor te lezen wanneer een van de commando's gegeven wordt. Die sturen bij mij allemaal een bevestiging voor zover getest. Deze bevestigingen worden ook herkent en een bericht in het log van gegeven.

Mijn versie update verder de sensor direct in Domoticz via HTTP en de gespecificeerde IDX voor de AIRQUALITY sensor. Met de temp doe ik verder niks omdat die toch niet de juiste temperatuur aangeeft.

[ergu]

Oké,dank je wel. ik ga het morgen proberen.

[ergu]

Hallo,

Ik heb de versie van Jos op twee van deze sensors ( MHZ19b) versie geflashd (op D1 mini) . Ik zie wel de waarde van Co2 woord gelezen en 0nder het tab Device getoond.

Op dezelfde D1 mini heb ik ook een DHT22 geprikt en ik kan ook de waardes van temperatuur en relatieve luchtvochtigheid lezen.



Op een RP 3 heb ik een mqtt met openhab draaien. Ik kan de waardes van temperatuur en luchtvochtigheid naar mqtt versturen en uilezen maar niet van Co2.

Als ik in terminal dit type,

^{[11:15:47] openhabian@openHABianPi:~$ mosquitto_sub -h localhost -t /KamerRobin/#}

krijg ik wel de waardes slechts van temperatuur en luchtvochtigheid.

^{18.60
63.30
18.60
63.30
18.60
63.30}

De onderstaande commando geeft ook geen resultaat:
_{mosquitto_sub -h localhost -t /KamerRobin/CO2-sensor/PPM}


Ik heb via de forum op github https://github.com/letscontrolit/ESPEasy/issues/465

discussies gevolg om wijzer van te worden maar het lukt me niet om Co2 waarde via mqtt uit te lezen.

Heeft iemand enige idee hoe ik dit kan fixen?

Alvast dank.

[ Voor 0% gewijzigd door ergu op 17-09-2017 12:03 . Reden: spel fout ]

[jvdzande]

@ergu,
ik heb een nieuw type toegevoegd aan ESPEASY om zo de HTTP interface voor domoticz te kunnen aanpassen, omdat de URL die nodig is voor een AIRQUALITY device anders is. Deze aanpassing zit in _C001.INO:

code:

            case (SENSOR_TYPE_AIRQUALITY):
              url += F("&nvalue=");
              url += toString(UserVar[event->BaseVarIndex], ExtraTaskSettings.TaskDeviceValueDecimals[0]);

Ik heb dit device niet aan de mqtt logica toegevoegd omdat ik dit niet gebruik en ook niet kan testen. Misschien dat iemand met kennis hiervan kan helpen? Waarschijnlijk moet er iets in _C005.INO worden aangepast in jouw geval.

Jos

[ Voor 5% gewijzigd door jvdzande op 17-09-2017 20:56 ]

[TD-er]

De kortste klap is om ze via Domoticz HTTP te laten lopen.
Via MQTT kan wel, maar dan moet je die patch uit de discussie die je linkt gebruiken. (is net in de mega branch opgenomen) en dus die bouwen.
De MQTT patch zit nog niet in de binary firmware files die je kunt downloaden.

[jvdzande]

@ergu ,
Ik heb de Mega aanpassingen in mijn kopie ge-Merged en in _C002.ino (mqtt) ook de AIRQUALITY sensor aan toegevoegd door de triple sensor to kopiëren, dus je zou het even kunnen testen: https://github.com/jvanderzande/ESPEasy/tree/MHZ19b

Gr/Jos

[ Voor 4% gewijzigd door jvdzande op 18-09-2017 20:28 . Reden: toevoeging ]

[ergu]

Oké, dank jullie wel. Dan ga ik wachten tot de nieuwe release afwachten. Ondertussen zoek ik natuurlijk een andere manie om de waardes naar mqqt te sturen.

[ergu]

Hoi Jos, ik zag je laatste bericht net niet.

Ik ga hem meteen testen...

[ Voor 5% gewijzigd door ergu op 18-09-2017 22:00 ]

[Wolfram55]

Nieuwe Esp-Easy .... dev 12 heeft default "Auto Base Calibration" op "normaal" staan.
De andere optie is ÄBC "disabled".

Wat ik begrijp is dat de laatste de voorkeur heeft (?).
Mijn ervaring is met degene waar ik niet "geknoeid" heb met instellingen het nog steeds doen en die hebben als ik het goed heb default ABC disbled vanuit de fabriek.

Zo ja .... waarom is die niet default dan?

[TD-er]

Wolfram55 schreef op vrijdag 22 september 2017 @ 16:43:
Nieuwe Esp-Easy .... dev 12 heeft default "Auto Base Calibration" op "normaal" staan.
De andere optie is ÄBC "disabled".

Wat ik begrijp is dat de laatste de voorkeur heeft (?).
Mijn ervaring is met degene waar ik niet "geknoeid" heb met instellingen het nog steeds doen en die hebben als ik het goed heb default ABC disbled vanuit de fabriek.

Zo ja .... waarom is die niet default dan?

Als programmeur/submitter van die optie, wil ik daar wel wat over uitleggen
Allereerst lijkt die optie alleen met de "B"-versie van de sensor te werken. De oudere versie negeert die optie gewoon.
Daarnaast was er tijdens het uitwerken een discussie ontstaan waarin het ene argument was "de fabrikant heeft het zo bedoeld" (ABC aan, de default dus) en mijn argument is: "Je wilt dit niet, wanneer je niet elke dag heel goed ventileert" (ABC uit dus)

Daar het een nieuwe optie is, kwamen we tot de oplossing om standaard gedrag gelijk te houden. Vandaar dus deze situatie.

[Wolfram55]

@TD-er dat had ik al begrepen ja . Je kwam al vlot ivm dit ergens voorbij.

Even voor de duidelijkheid nog. Ze zijn alleen te onderscheiden door de onderkant ?

De "gewone" eerste versie:


De B-versie


Ik had het dus verkeerd in m'n kop zitten. Dacht dat ABC default uit was.

Jouw gevoel en ervaring is niet dat als je met dit soort parameters aan de gang gaat dat je de mhz verknalt? Dat gevoel had ik nl met 1tje hier en mede daardoor ben ik huiverig geworden handmatig dit soort commando's te geven.

[jvdzande]

Ik heb ook een B versie en gebruik in mijn ESPEASY versie de logica die @TD-er in de orgineele versie heeft gemaakt om de ABC initieel aan/uit te zetten. Ik krijg keurig een bevestiging van het commando en het werkt prima:

code:

MHZ19: Sent sensor ABC Disable!
MHZ19: PPM value: 385 Temp/U: 24/26.00
MHZ19: Received ABC Enable/Disable acknowledgment!

.. en heb tot nu toe geen problemen gehad. het draait al een aantal weken en kan je verzekeren dat ik al heel wat keer de Wemos heb herladen om weer een nieuwe versie te testen.

Jos

[TD-er]

@Wolfram55 Het is door handmatig het zero-commando te geven mogelijk om de sensor te bricken. Althans met de originele versie is dat zo.
Dus juist daarom wil je het niet handmatig doen, maar volautomatisch.
Wat er gebeurt met die optie aan, is dat het "disable" commando gestuurd wordt, zodra er een valide meting is na herstart sensor of ESPeasy.

Door vaak vlak na elkaar het reset commando te geven via de URL kun je de sensor bricken.
Dus eigenlijk zou daar ook nog een patch voor moeten komen dat er minimaal een X aantal seconde tussen de commando's zit.

[jvdzande]

jvdzande schreef op maandag 18 september 2017 @ 20:03:
Ik heb de Mega aanpassingen in mijn kopie ge-Merged en in _C002.ino (mqtt) ook de AIRQUALITY sensor aan toegevoegd door de triple sensor to kopiëren, dus je zou het even kunnen testen: https://github.com/jvanderzande/ESPEasy/tree/MHZ19b

Ik heb nog een aantal wijzigingen in deze github versie gemaakt om mqtt goed te laten werken en @ergu heeft nu bevestigd dat het ook voor hem werkt.

[TD-er]

@jvdzande Deze commit bedoel je?

[jvdzande]

@TD-er , Dat zijn inderdaad de laatste (extra) aanpassingen bovenop de eerder gemelde aanpassingen die ik al in _C002.ino had gemaakt tbv "SENSOR_TYPE_AIRQUALITY".

[TD-er]

@jvdzande Weet je zeker dan dat de case in de file "src/_C011.ino" correct is?
Geen break aan het eind en hij doet ook niets.
Dat was het eerste wat mij opviel bij het bekijken van de diffs.
Verder niet getest.

[jvdzande]

@TD-er , Ik heb eerlijkgezegd de simpele benadering genomen en alle locaties voor "SENSOR_TYPE_TRIPLE" gezocht en die min of meer gedupliceerd.
Het werkte daarna prima. Op zich had ik het liefst een bestaande generieke sensor type gebruikt maar dit device heeft in het Domoticz HTTP request de NValue nodig ipv de standaard SValue, vandaar heb ik maar een nieuwe SENSOR definitie gemaakt.

[Wolfram55]

TD-er schreef op zondag 24 september 2017 @ 13:41:
@Wolfram55 Het is door handmatig het zero-commando te geven mogelijk om de sensor te bricken. Althans met de originele versie is dat zo.
Dus juist daarom wil je het niet handmatig doen, maar volautomatisch.
Wat er gebeurt met die optie aan, is dat het "disable" commando gestuurd wordt, zodra er een valide meting is na herstart sensor of ESPeasy.

Door vaak vlak na elkaar het reset commando te geven via de URL kun je de sensor bricken.
Dus eigenlijk zou daar ook nog een patch voor moeten komen dat er minimaal een X aantal seconde tussen de commando's zit.

Kijk ...... das nie zo mooi

Nu geloof ik niet dat ik dat verschillende keren achter elkaar gedaan heb maar toch.

In principe zouden alle "sukkel" manieren om de sensor te bricken er zo snel mogelijk moeten worden beveiligt

Verder is deze optie dus de enigste in de dev12. Lees hier van vele die er mee bezig zijn maar die van jouw is dus de enige ?

[TD-er]

Ik was sowieso nog van plan een commit te maken die dat aanpakt, maar er staat nog een aantal dingetjes van mijn kant in progress.
Ik heb het niet herhaald op een 2e sensor die ik heb liggen, vond het toch iets te prijzig puur als bevestiging
Maar ik denk dat iedereen het er wel mee eens is dat low-level commando's in korte tijd herhalen wellicht geen goed idee is, dus een delay toevoegen waarbinnen commando's niet herhaald mogen worden, lijkt me geen probleem.

[Wolfram55]

Heb vlg mij mijn 1e MHZ19 naar de euwige jachtvelden geholpen .

Begein ervaringsdeskundige te worden ....

Heeft maanden goed gewerkt en toen wilde ik van 2 wemosjes 1 maken.

Weet niet waar het mis is gegaan en dat is nog het meest vervelende misschien.
Zou kunnen verkeerd aangesloten gehad.

Op een werkende getest maar nada.

Dit is de log :

code:

349 : INIT : SPI not enabled
1236 : WIFI : AP Mode disabled
1236 : WIFI : AP Mode ssid will be woonkamer_117 with address 192.168.4.1
1236 : IP : Static IP :192.168.1.117
1238 : WIFI : Connecting wireless attempt #1
4296 : WIFI : Connected! IP: 192.168.1.117 (woonkamer_117)
4299 : MHZ19: Init OK
4408 : MQTT : Connected to broker
4413 : Subscribed to: /woonkamer/#
4418 : WD : Uptime 0 ConnectFailures 0 FreeMem 20296
22372 : MHZ19: Error, timeout while trying to read
22373 : MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0
34418 : WD : Uptime 1 ConnectFailures 0 FreeMem 20200
64419 : WD : Uptime 1 ConnectFailures 0 FreeMem 20200
82602 : MHZ19: Error, timeout while trying to read
82603 : MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0

Komt alleen maar Init OK en daarna repeteerd Error en Unknown.

Commando mhzreset maakte geen verschil

In 1e instantie dev12 maar nu op werkende wemos met dev11

[TD-er]

Licht het gloeidraadje nog wel op?
En je weet zeker dat de Rx/Tx goed zitten?

Je zou ook even kunnen kijken of er nog wat op de PWM-output staat.

[ Voor 31% gewijzigd door TD-er op 29-09-2017 21:40 ]

[Wolfram55]

Draadjes lichten nog op ja.
De RX/TX hoe bedoel je goed? Heb van een wemosje waarop 'n andere werkt de draadjes 1 op 1 overgezet en nada .....


PWM-output ??

[TD-er]

Er zit ook een pin op de sensor die een PWM signaal geeft.
Aan de puls-breedte kun je dan ook de CO2 concentratie aflezen.
Staat wel in de datasheet wat de berekening is.
N.B. Is wel afhankelijk van de range van de sensor (2000ppm/5000ppm)

Maar goed, wellicht eerst maar even kijken met een multimeter met frequentie-teller of er daar nog wel een signaal op staat.
PWM pin zit aan de 4-pin kant van de sensor.

[Wolfram55]

Ah ok ....PWM-pin

Ik was hier al "bang" voor dat ik niet de juiste meetapparatuur heb. Een multimeter met frequentieteller heb ik niet. Een heel simpele Skandia 600v 10A en 1 condensatormetertje.

Onlangs kwam er bij de sale van Banggood een zelf te bouwen scoop voorbij voor weinig. Wel over getwijfeld maar toch maar niet gedaan ( https://www.banggood.com/...th-Housing-p-1093865.html ). Is nu €7,- duurder.
Dit is typisch iets voor een oscilloscoop of is dat voor een esp hobbyist overkill?
De Hantek 6022BE leek me wel wat ..... ( https://www.banggood.com/...-925842.html?rmmds=search ) maar ben geen expert dus weet niet goed hoe of wat.
En .... het is hier verschrikkelijk off-topic vrees ik.

De 4e (MH-Z19) stond al op mijn verlanglijstje om te bestellen om te fungeren als 3e meetpunt in huis (keuken). Zal dan als vervanging moeten gaan dienen voor de 2e .

Enige voordeel is is dat ze wel goedkoper worden. Rond de €17,- inmiddels vlg mij

[Wolfram55]

Hoe weet je nu wanneer je een "A" of B versie MH-Z19 bestel?

De laatste x heb ik https://nl.aliexpress.com...shipping/32697750985.html besteld omdat die onderkant hetzelfde was als mijn 1e ( die dus nu overleden is ). Het witte friemeltje in het midden ...

Zie nergens iets wat duidt op de B versie. Zal wel andere bril nodig hebben

[TD-er]

Wolfram55 schreef op zaterdag 30 september 2017 @ 13:09:
Hoe weet je nu wanneer je een "A" of B versie MH-Z19 bestel?

De laatste x heb ik https://nl.aliexpress.com...shipping/32697750985.html besteld omdat die onderkant hetzelfde was als mijn 1e ( die dus nu overleden is ). Het witte friemeltje in het midden ...

Zie nergens iets wat duidt op de B versie. Zal wel andere bril nodig hebben

Zie deze post, een halve pagina verder omhoog
Wolfram55 in "CO2-meters voor in huis"

Probleem is alleen wel dat de foto's op de Ali-sites niet altijd door henzelf zijn genomen en dus kan de uiteindelijke levering anders zijn.
De laatste 2 die ik via Banggood had binnengekregen zijn de nieuwe versies, terwijl de foto bij het product nog de oude was.

Lijkt me het handigste dat je bestelt bij een die een aardige doorloopsnelheid heeft in de verkoop, al is dat geen garantie natuurlijk. Die kopen ook maar partijen op.

[Wolfram55]

Goh .... die wolfram55 ......

Het is dus in weze 1 gok ..... dat is dan weer niet bevredigend . Daar is €20,- dan weer net ff iets te veel voor.

Tegenwoordig bestel ik idd daar waar de bestellingen wat aantallen het hoogst zijn

[ Voor 11% gewijzigd door Wolfram55 op 30-09-2017 13:55 ]

[TD-er]

@Wolfram55 Ah wat stom van me... had even usernamen moeten bekijken

[Wolfram55]

LoL ... dacht dat je die door had

[TD-er]

Nee was een oprechte onbedoelde grap

Maar ik heb hier nu een kleine maand een "A" versie draaien met mijn "ABC-disable" functie in ESP-easy en het valt me op dat er dagen bij zitten waarbij de concentratie niet op de 400 ppm uitkomt, maar net erboven (minimum van net boven de 400 ppm) en toch niet een merkbare jump in de metingen zoals eerst.

(ja ik heb vannacht tot in de vroege uurtjes zitten nerden in de huiskamer )

Dus ondanks dat deze sensor geen response lijkt te geven, op ABC-disable, werkt het nu best OK.
Maar goed, wellicht dat de huiskamer bij ons lang genoeg leeg is tijdens een etmaal om nagenoeg de 400 ppm aan te tikken zodat het nog steeds goed bruikbaar is.

Ik blijf het trouwens opvallend vinden dat de CO2 concentratie zo enorm snel toeneemt bij koken (op gas).
We hebben best wel een grote ruimte (huiskamer + zithoek + keuken) maar toch loopt 'ie met 3 pitten aan binnen no-time zo'n 1000 ppm op.
Best wel een eye-opener voor mij.

[Wolfram55]

TD-er schreef op zaterdag 30 september 2017 @ 14:19:
Nee was een oprechte onbedoelde grap

Dat heb je er van als je het laat maakt ...... Het scherpe gaat er dan een beetje vanaf

Maar ik heb hier nu een kleine maand een "A" versie draaien met mijn "ABC-disable" functie in ESP-easy en het valt me op dat er dagen bij zitten waarbij de concentratie niet op de 400 ppm uitkomt, maar net erboven (minimum van net boven de 400 ppm) en toch niet een merkbare jump in de metingen zoals eerst.


Dus ondanks dat deze sensor geen response lijkt te geven, op ABC-disable, werkt het nu best OK.
Maar goed, wellicht dat de huiskamer bij ons lang genoeg leeg is tijdens een etmaal om nagenoeg de 400 ppm aan te tikken zodat het nog steeds goed bruikbaar is.

Mijn beide ( beide B ) komen mooi elka dag/nacht op 400 .... zonder enig extra commando.

Ik blijf het trouwens opvallend vinden dat de CO2 concentratie zo enorm snel toeneemt bij koken (op gas).
We hebben best wel een grote ruimte (huiskamer + zithoek + keuken) maar toch loopt 'ie met 3 pitten aan binnen no-time zo'n 1000 ppm op.
Best wel een eye-opener voor mij.

Had dit ook al ervaren met kaarsen aan in de kamer.
En daarom wilde ik ook een 3e voor in de keuken. Kook ook op gas (nog).

[ergu]

Heef iemand ervaring met Acer Air Monitor? --> http://home.cloud.acer.com/airmonitor/
Apparaat beschikt de volgende sensoren.

Sensoren

• Fijnstof (PM2.5/PM10)
• TVOC
• CO2
• Temperatuur
• Luchtvochtigheid
• Omgevingslichtsensor

Op ibood vandaag is er een super aanbieding.

http://www.ibood.com/elec...15ee7caa5a04256983b491239


Het is met IFTT en Amazon Echo geïntegreerd maar ik kan nog nergens iets over open API kunnen vinden. Het zou handig zijn om het met je home automation te integreren.

[!null]

@ergu Interessant!

Ik zie liever ook een open API. Maar dit is wel een mooie alles in 1 oplossing, hij kan wel erg veel meten. En met IFTTT kun je hem alsnog aan je eigen software koppelen toch?
(al zou ik dat ook liever lokaal doen)

[ergu]

Met IFTT zijn de mogelijkheden beperkt. Zie hier.

https://ifttt.com/Air_Monitor

Ik heb hem tocht gekocht met het idee dat open API op den duur gaat komen. Een open API kan natuurlijk de verkoop cijfers positief beïnvloeden. Hopelijk komt er snel een open API.

[!null]

Je zou wat kunnen knutselen via een Google Drive Spreadsheet, maar het is inderdaad beperkt.
Je wil gewoon een trigger kunnen definieren, om vervolgens ventilatie hoger te zetten.

[Sabbi]

ergu schreef op donderdag 26 oktober 2017 @ 11:42:
Heef iemand ervaring met Acer Air Monitor? --> http://home.cloud.acer.com/airmonitor/
Apparaat beschikt de volgende sensoren.

Sensoren

• Fijnstof (PM2.5/PM10)
• TVOC
• CO2
• Temperatuur
• Luchtvochtigheid
• Omgevingslichtsensor

Op ibood vandaag is er een super aanbieding.

http://www.ibood.com/elec...15ee7caa5a04256983b491239


Het is met IFTT en Amazon Echo geïntegreerd maar ik kan nog nergens iets over open API kunnen vinden. Het zou handig zijn om het met je home automation te integreren.

Let op dat deze alleen een VOC sensor heeft, met daarvan afgeleid CO2:

* Air Monitor uses a CO2 equivalent unit derived from the amount of VOCs detected in the air.

[Speedy-Andre]

Toch wel een leuk ding die Acer omdat hij vrij portable is.
Ik heb net een fijnstof sensor binnen die met een ESP kan werken, echter wel wat werk voor ik de data heb
Met ifttt kan hij m'n Hue lampen al vast laten waarschuwen als ik eigenlijk niet meer kan ademen

[balk]

TD-er schreef op zaterdag 30 september 2017 @ 14:19:
Ik blijf het trouwens opvallend vinden dat de CO2 concentratie zo enorm snel toeneemt bij koken (op gas).
We hebben best wel een grote ruimte (huiskamer + zithoek + keuken) maar toch loopt 'ie met 3 pitten aan binnen no-time zo'n 1000 ppm op.
Best wel een eye-opener voor mij.

Even opgezocht: ik gebruik tijdens een gemiddelde kookbeurt 50 tot 100 liter aardgas, zeg 0,075 m3. Bij verbranding geeft dat 0,075m3 CO2 (en wat waterdamp). Mijn huiskamer is circa 100 m3. Bij matige verversing zal de CO2 concentratie dus 1000000 * ( 0,075 / 100) = 750 ppm toenemen. Niet gek dat je dan boven de 1000 uit komt! Ik had me dit ook nooit gerealiseerd

[TD-er]

Ik heb de oude MH-Z19 sensor (de niet B-versie) in mijn ESPeasy setup zitten.
Vanaf eind augustus heb ik erin zitten dat 'ie nogal pro-actief die ABC-functie uitzet, ookal ondersteunt de sensor dat commando officieel niet.

Afgelopen week heb ik de ABC-functie weer aangezet met dit tot gevolg:

Zoals te zien, ventileren we in elk geval deze week te weinig, maar dat was de afgelopen weken ook al het geval.
N.B. er zit op 25 okt een vreemde lijn in, maar dat is ontbrekende data doordat Domoticz was vastgelopen.
Op 26 okt is ABC weer aangezet.


In het "jaaroverzicht" van de afgelopen 3 maanden is in elk geval te zien dat de ABC-disable functie wel degelijk lijkt te werken op deze oude sensor, mits je 'm maar vaak genoeg toepast.
De patch hiervoor zit al enige tijd (release v2.0.0-dev12) in de mega branch van ESPeasy.

[Sabbi]

TD-er schreef op dinsdag 31 oktober 2017 @ 00:37:
[...]
[afbeelding]
In het "jaaroverzicht" van de afgelopen 3 maanden is in elk geval te zien dat de ABC-disable functie wel degelijk lijkt te werken op deze oude sensor, mits je 'm maar vaak genoeg toepast.
De patch hiervoor zit al enige tijd (release v2.0.0-dev12) in de mega branch van ESPeasy.

Mooi om te zien hoe de sensor zich langere tijd houdt zonder auto-calibratie! Verbazend dat er eigenlijk geen sensor drift te zien is, en dat de min steeds op +-400 blijft. Je bent niet stiekem nog elke avond de esp aan het rebooten?

[TD-er]

Sabbi schreef op dinsdag 31 oktober 2017 @ 08:41:
[...]


Mooi om te zien hoe de sensor zich langere tijd houdt zonder auto-calibratie! Verbazend dat er eigenlijk geen sensor drift te zien is, en dat de min steeds op +-400 blijft. Je bent niet stiekem nog elke avond de esp aan het rebooten?

Nope, geen reboot. Sterker nog, tot vanavond had 'ie een uptime van ongeveer een maand.
Ik had 'm een tijd geleden, op een mooie dag, een nullijn kalibratie gegeven vanuit buiten, toen de hele dag de tuindeur open had gestaan.
Hopelijk dat 'ie nu weer een goed ijkpunt heeft, nadat ik gisteren de buitendeur een tijdje open heb gehad.

[dunklefaser]

TD-er schreef op dinsdag 31 oktober 2017 @ 20:45:
[...]

Nope, geen reboot. Sterker nog, tot vanavond had 'ie een uptime van ongeveer een maand.
Ik had 'm een tijd geleden, op een mooie dag, een nullijn kalibratie gegeven vanuit buiten, toen de hele dag de tuindeur open had gestaan.
Hopelijk dat 'ie nu weer een goed ijkpunt heeft, nadat ik gisteren de buitendeur een tijdje open heb gehad.

De ca. 400 ppm als de ijkpunt in de buitenlucht voor het CO₂ gehalte klopt alleen voor de buitenlucht ver weg van de bebouwde kom. - Stadslucht buiten heeft volgens deze bron gemiddeld 700 ppm aan CO₂. - Ik verwacht niet dat je, op welk moment dan ook, de 400 ppm in de stad zou kunnen meten. De ABC functie heeft hoe dan ook in de stad met een target van 400 ppm geen realiteitsgehalte.
- Gelukkig wonen we allemaal niet in de stad .
Met een nieuwe tSense heb ik vandaag bij mij in de tuin bij Wijchens meer minimaal ca. 500 ppm als bodemwaarde kunnen registreren.
Uiteraard moet ik dat nog meerdere keren en over een wat langere periode checken.

YMMV

[TD-er]

@dunklefaser Ik woon aan de rand van een dorp midden in de provincie Groningen.
Dus daar zal de concentratie aardig tegen de 400 ppm zitten gok ik zo
Of de koeien van de boerderij een paar-100 meter verderop staan flink CO2 te produceren

[dunklefaser]

TD-er schreef op zaterdag 4 november 2017 @ 00:33:
@dunklefaser Ik woon aan de rand van een dorp midden in de provincie Groningen.
Dus daar zal de concentratie aardig tegen de 400 ppm zitten gok ik zo
Of de koeien van de boerderij een paar-100 meter verderop staan flink CO2 te produceren

Ja - en het resultaat van het wapperen van de koeienstaarten is dan echte schetenwap ,
tenminste als de wind goed staat.
Trouwens - vair - bestaat dit bedrijfje nog?
De website in ieder geval ziet niet echt up-to-date uit.

[ocaj]

dunklefaser schreef op zaterdag 4 november 2017 @ 09:50:
Trouwens - vair - bestaat dit bedrijfje nog?
De website in ieder geval ziet niet echt up-to-date uit.

Zie http://vair-monitor.com/2...hipping-temporarily-hold/

Dit bedrijfje is een eenmanszaak dat momenteel gezinsuitbreiding heeft. Dat kan je leven aardig overhoop gooien, maar als het stof wat neergedaald is (lees: als je er aan begint te wennen) dan gaat hij misschien weer gewoon verder.

(ik had ook al naar dat spul zitten kijken, ziet er verder prima en betaalbaar uit)

[Caros]

Cupid673 schreef op dinsdag 20 juni 2017 @ 11:57:
Heeft iemand toevallig ervaring met de MCO meters?

http://www.mcohome.com/show_list.php?id=15&sid=51

Heeft iemand hier toevallig ondertussen al ervaring mee?

[ThinkPad]

Afgelopen weekend een verjaardag, de CO₂ stond bijna de hele avond op 2000 ppm met een man of 15 in huis. Aan voorkant en achterkant woning stonden de ventilatieroosters open en de Itho werd door m'n domotica op 100% gestuurd vanwege de slechte luchtkwaliteit.

Maar eigenlijk merk je gewoon dat het niet toereikend is en er een raam open moet. Maar met dit weer (graad of 7° buiten 's avonds ) doe je dat ook niet zo snel, dan gaan mensen klagen over tocht

[ Voor 13% gewijzigd door ThinkPad op 07-11-2017 10:19 ]

[Theo]

Iemand die ervaring heeft met de HT-2000 standalone CO2 meter? Ik zoek een standalone oplossing om in huis de CO2 waardes te kunnen meten om daarmee de ventilatie af te kunnen stellen en te controleren.

[DeGallier]

Verwijderd schreef op zaterdag 2 september 2017 @ 18:28:
Hier de TFA Dostmann 'AirCO2ntrol Mini' CO2 Monitor (<60 euro op amazon.de) sinds een kleine twee jaar in gebruik, tot grote tevredenheid.

Ik heb deze ook aangeschaft en een wemos d1 mini op de Cali Port aangesloten. Ik vond op github een 'hacker' die al het nodige voorwerk gedaan had. Hij heeft inmiddels ook een artikel hierover geschreven.
Ikzelf gebruik iewat aangepaste code die deepsleep gebruikt. Voor bij elkaar 65 euro een prima co2 meter met display die via wifi elke 5 minuten de waarde doorgeeft aan domoticz en tussentijds slaapt.

Stroom kan zowel via de co2mini als via de wemos geleverd worden dmv micro-usb.

https://www.hackerspace-bamberg.de/Co2_Monitor

[Speedy-Andre]

Vreemd, ook met voeding en pc software voor die prijs

https://www.amazon.de/For...fRID=D040E1D2RYS2G0RXP1YH

Als een pc kan communiceren, waarom dan nog op een andere manier?