Tasmota: CCS811 stops working

[Chaot1]

Make sure these boxes are checked [x] before submitting your issue - Thank you!

• [ x ] Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues)
• [x ] Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting)
• [x ] Searched the problem in the forum (https://forum.digital-pig.com/)
• [x ] Searched the problem in the discussion group (https://groups.google.com/d/forum/sonoffusers)
• [ x] Hardware used :
• [x ] Provide the output of command status 0 :

STATUS 0 OUTPUT HERE:
stat/sonoff/STATUS = {"Status":{"Module":19,"FriendlyName":["Buero"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}}

(Please, remember to close the issue when the problem has been addressed)

Thank you for implementing the CCS811 . But i have a small Problem:
When i start the CCS811 it reads the correct status an i can see him on the SonoffDEV website. But after 1 or 2 Hours the CCS811 disappears. When i restart the Sonoff it appears again.

Connected on GPIO 4 and 5
Bridge between WAK and GND (on CCS 811 to activate)
No other items connected

[martin072]

HI,

I have seen strange behaviour with the CCS on the ESP. In the end this worked for me:

./Library/Arduino15/packages/esp8266/hardware/esp8266/2.4.1/cores/esp8266/core_esp8266_si2c.c"
Line 74: Changed twi_setClockStretchLimit(230) to twi_setClockStretchLimit(460);

It does not seem to affect other i2c devices I use (Oled and BME260), maybe this helps?

reference: https://github.com/AKstudios/CCS811-library/issues/3#issuecomment-336360650

[gemu2015]

in Tasmota Adafruit Lib Clockstretchlimit is already set to 1000 =>

ifdef ESP8266

Wire.setClockStretchLimit(1000);

endif

I use this Sensor since a couple of month without any problems.
also the new Tasmota implementation runs without problems.
however i use a very stable 3.3 V power supply with an Esp07, (no sonoff) may be it is a power supply issue?
is use these pins =>
GPIO12 = SDA (d6)
GPIO14 = SCL (d5)

[ascillato2]

Hi,

Closing this issue as there is no feedback. Please, ask to reopen if needed. Thanks

[Chaot1]

Ok, i think this Sensor is not usable for me.
Exactly after 50 Minutes it stops working and i have to restart the whole board to get actual data.
I think it is a problem on the "Awake" signal. I use a wire to hold it on GND. Maybe it must be switched every n-minutes

[moneybag]

Same problem here, after a couple of hours the sensor is gone. /awake to ground.
Interesting: i have to connect and disconnect to usb power a few times until the sensor is recognized.

[qingz2004]

I have the same problem with version 6.3.0.5. My work around is to connect the rst to a GPIO, and use a rule to toggle the rst every half hour.

[pesone]

I have got it working now for more then 10 Days without any reset or power reboot.

What i did is to increase the value for updating CCS811 to 30 seconds in

sonoff/xsns_31_ccs811.ino > line 43

as my teleperiod is set 30 and i dont need no more measurements meanwhile.

...
#define EVERYNSECONDS 30

void CCS811Update(void)  // Perform every n second
{
...

and to adjust > line 73

  } else {
    // failed, count up
    ecnt++;
    if (ecnt > 2) { 
      // after 60 seconds, restart 
      ccs.begin(CCS811_ADDRESS);
    }

I have set sleep to 250.

[qingz2004]

I tried it.
It does not freeze any more, but the data I got is not realistic.

[pesone]

I have two of them. Both with similar values

22:04:23 MQT: tele/Test/SENSOR = {"Time":"2019-01-25T22:04:23","CCS811":{"eCO2":1309,"TVOC":138}}

22:13:53 MQT: tele/Test/STATE = {"Time":"2019-01-25T22:13:53","Uptime":"11T00:22:33","SleepMode":"Dynamic",...

If open a window for a couple of minutes tvoc value goes near 0

[qingz2004]

Flash back to original firmware, I get this.

[pesone]

i would suggest to

• erease flash before flashing new firmware and
• afterwards give the the sensor a couple of hours to settle
• a power reboot could help as well
• For testing purposes you could compile with no sensor except ccs811

As said before, my two sensors (Adafruit and a chinese product with no label) seems to work fine and measurements are similar.
Another SGP30 delivers completly different values but the curve and peaks are very similar, when i open a window or expose the sensor to voc

Good luck

[qingz2004]

Grabbed a new Wemos, erased and flashed Tasmota with updated CCS811 driver. I2C were frozen after a few minutes, and the data read out was still bad before frozen.

12:48:18 CMD: i2cscan
12:48:18 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x5a"}
12:53:13 MQT: tele/sonoff/SENSOR = {"Time":"2019-01-26T12:53:13","CCS811":{"eCO2":7426,"TVOC":1070}}
13:00:32 CMD: I2cscan
13:00:32 RSL: stat/sonoff/RESULT = {"I2CScan":"Error 4 at 0x01"}

[mike2nl]

@Chaot1 @martin072 @gemu2015 @ascillato2 @moneybag

• depending on the sensor breakout board you have to check if the WAKE
  input is on ground = 0V
• This sensor uses I2C address 0x5A. make sure with a s2cscan that the address has no conflicts
• if you have the Adafruit board check on the 3V3 output is enough voltage. They have two versions. One with a older model of regulator and when you power it with 3V3 only via the I2C bus it can be the voltage issue. A known one.
  I have a breakout board from Adafruit with the newer regulator and have to ground the WAKE input.
  I can be that some breakout boards have done it with a 10K resistor.

• Check this in any case. When that input has a bad level (floating) it can be that the sensor is stopping to messaure any longer. And that floating level can change in time because many other things. Funny is the same time when it is happen. So test it guys.
• Give some feedback please...

[andrethomas2]

re-opening on request from @mike2nl

[mike2nl]

@gemu2015
Update:
there is possible a I2C bus freezing after a certain time. Yes you read it right...
I came to that because with another CCS811 sensor i got hat event from all the users too.
So far i have seen there are some changings in the core 2.5.0-beta 3 too. When i
understand that right and possible that brings other things up.

I found things in the adafruit cpp file in wire.begin. About the use of i2c timeing stretching it can freeze the bus. A certain wwit time (delay) is needed for that to overcome that issue.

And i won't believe it but i found it in the Sparkfun library. Yeah so as always you can't trust all ada libs for 100% because the most libraries are not tested against the esp8266, we all know that ;-)

I will test that tomorrow with the other library from Sparkfun with some changes in the code i think. When this works i will rewrite the whole driver without using a library at all.

Next part we miss a value. Named millis, see data sheet. Have to investigate what that means.
We have eCO2 in ppm and TVOC in ppb. So there are more changes to get this straight.

But 1st the timing issue fix. Possible we can fix it shortly (cross my fingers)

• Still need some feedback about that WAKE input from you all.

[andrethomas]

The datasheet seems to suggest that the host controller needs to have clock stretching enabled.

The behaviour could be because this is not being done and that the CCS811 is holding the I2C bus ransom.

I see it is in the library for the CCS811 as follows

void Adafruit_CCS811::_i2c_init()
{
    Wire.begin();
    #ifdef ESP8266
    Wire.setClockStretchLimit(1000);
    #endif
}

Its not uncommon for slow I2C sensors to require clock stretching so this is fine, but it may be worth playing with a higher value... I cannot find anything specific in the datasheet which should have specified the clock stretch period required and I do not have this sensor so I cannot hook it up to a scope to see if the conditions are met.

The timing mentioned by @mike2nl also seems to be a bit picky as outlined in the datasheet

I'm sure @mike2nl has taken all the above into consideration so I'm actually just posting for posterity purposes with the view that it might spark other ideas of what could be going wrong.

[pesone]

Tasmota Version | 6.4.1(sonoff)
2_4_2/2.2.1(cfd48f3)

This is status of my CCS811 adafruit breakout board on a sonoff basic

21:29:03 MQT: tele/Abluft/STATE = {"Time":"2019-01-31T21:29:03","Uptime":"16T04:17:42","SleepMode":"Dynamic","Sleep":250,"LoadAvg":3,"POWER":"OFF",...
21:29:03 MQT: tele/Abluft/SENSOR = {"Time":"2019-01-31T21:29:03","CCS811":{"eCO2":530,"TVOC":19}}

I can't do any measuring, because it is too much effort to remove tit from its place.
But i remember that i have to connect

• WAKE to GND
  on the Adafruit Board, otherwise it won't start.

Status of a other breakoutboard CJMCU-8118 see above.

• WAKE-10K-GND (INPUT is STABLE Measured between VCC = 3.26V)

• ADD-GND

As im not a developer and i don't know what im doing, i can only put in the
History of my observations:

• First i bought the adafruit board and it won't work. The IC2 freezes. Sensor disapeared and to get it work for another couple of minutes i have to do a power reboot.

• I tought the expensive adafruit breakoutboard could be broken, and i orderd another cheap Breakoutboard CJMCU-8118

• But the same behaviour as with adafruit

• i've started playing around with clockstretchlimit, with no luck (i had the impression higher values faster freezing)

• i have done 100 testings for sure and finally i've got them working

what i've done is

• I've compiled with no sensors except CCS881 in my_user_config
• Clockstretchlimit 500 (i have read about this somewhere else)
• and see post above (But this shouldn't have impact because all values bigger then 5 worked for me)

It can't be just a coincidence that two different boards start working with no issues,
and if i flash back to "standard-tasmota-master" they show the freezing behaviour.
This is reproducable at least for me.

[andrethomas]

@pesone Thanks for sharing - I'm sure @mike2nl will find it useful... really wish I had one of these to help out though.

[mike2nl]

@pesone @andrethomas @arendst @ascillato2 @gemu2015
Update for today:

• Code for detecting sensor type, config and start complete re-written without using any library.
• No use of a Library at all. All defines in code.
• No stretching will be used for first test today.

Have to do some things in code to test the first test steps. When the debugging tells me what i wish to see i will look further in it.
Also i found out that some of the CCS811 breakout boards have a NTC on board for the temperature compenstation. There is a register to set and i think i have found a way to check for a NTC.
Next step will be read the values and after that a define will be given to use a BME280 which is possible used in the same setup.
So lots of work but i hope i get it done.
BTW: Andre has looked ones over the first idea of code. He means give it a go.

[gemu2015]

@mike2nl
sorry that i can not contribute. i bought this sensor about a year ago together with the sgp30, adapted both drivers and from the beginning i did not have any issues. ( the ccs811 is compensated with a sht3x) i then sealed the sensors with hot glue so that i can not even verify the exact hardware parts involved.
comparing both parts at the same location gave very similar curves but sometimes shifted values for both signals.

[mike2nl]

@gemu2015 - no issue at all ;-)
@pesone @gemu2015 @ascillato2 @andrethomas
Short Update:

• first test wit a library from Maarten Pennings looks very prommising. made a test over 2 hours and it works. If an error is happen on the bus (esp8266 worst stretching mechanism) he shows it.
• the lib is currently filled with a lot of print functions, so she is too big. That i will change to get much smaller. The library looks much more stable to me then the Adafruit. The Adafruit is missing things and has done it not 100%.
• Maarten has also some currently changes to the I2C driver in ESP8266/Arduino. These changes are not in beta 3 now. But i have added his changes and the bus is responding faster and much better with the CCS811 sensor. Brings me to the SHT and TSL issue too. Will test this with the i2c code changings.
• Jason gave me the helping link to the issue at the esp8266/arduino git. Thank You @Jason2866 for that. I had overseen that link so i think we have a solution about all the issues.
• In any case i will made a new driver with that library from Maarten. Possible add all the lib stuff we need to the driver code. @gemu2015 and me we hate to have much libs at all, haha.

Last but not least we have progress now!

[qingz2004]

Any news on this?

[Frogmore42]

Most likely this sensor has the same issues I ran into on the SCD30. I believe the underlying issue is poor handling of clock stretching by the esp8266. Even core 2.5.0 does not handle this correctly. Many of the implementations of sensors ignore CRC and other errors which can completely lock up the i2c bus. The good news is that it is possible to recover from that. The library I created for the SCD30 shows one way of checking and reporting errors. The implementation in sensor 42 shows one way of handling the errors and resetting the i2c bus when things get really bad.

[gemu2015]

there must be sensor hardware differences too. my ccs has absolutely no issues. it now ran for 178 days without any reset.

Tasmota 6.1.1.7, core 2.3, sleep 0

the ccs811 firmware should not be the reason because until recently there was only version 1.1 available.

CCS811 Firmware - Revision History
Version Changes

2-0-1 Firmware build including all 2-0-0 features accept management of the burn in period

2-0-0 MOX sensor need a burn-in period of several days of operation from first power on before
eCO2 and TVOC readings stabilize. The burn-in period is now managed so that stable
readings are available after only 60 minutes of operation after first power on
Extend eCO2 maximum output value to 64000 ppm
Extend TVOC maximum output value to 64000 ppm
Removed NTC functionality. Pin 8 not measured and left undriven
Added "Internal_State" variable to the command register map
Improved the algorithm which computes eTVOC and eCO2

1-1-0 Initial Version

[Frogmore42]

Could be. I believe it is a timing issue. When I had the sensor set to deliver updates every 2 seconds and checked every second it was much more likely to run into the issue. When I had it update every 30 seconds it never happened. When I ignored CRC errors it happened more frequently. When I soft reset the SCD30 after a CRC error I actually got more issues than if I just waited till the next second to check again.

Both sensors use clock stretching and the esp8266 implementation of i2c has known issues, so it is not surprising the sensors have issues on the esp8266.

[gemu2015]

according to maarten pennings the CSS811 issues on ESP8266 can be solved by a wait just before Wire.requestFrom in the CSS811 read sequence in file Adafruit_CCS811.cpp (see below)
since i can not reproduce the issue, may be someone with the issue may test this fix.

void Adafruit_CCS811::read(uint8_t reg, uint8_t *buf, uint8_t num)
{
uint8_t value;
uint8_t pos = 0;

//on arduino we need to read in 32 byte chunks
while(pos < num){

    uint8_t read_now = min((uint8_t)32, (uint8_t)(num - pos));
    Wire.beginTransmission((uint8_t)_i2caddr);
    Wire.write((uint8_t)reg + pos);
    Wire.endTransmission();
            delayMicroseconds(50); // maarten pennings suggestion
    Wire.requestFrom((uint8_t)_i2caddr, read_now);

    for(int i=0; i<read_now; i++){
        buf[pos] = Wire.read();
        pos++;
    }
}

}

[qingz2004]

Tried. No luck.

[Frogmore42]

The code show is doing no error checking, so it is not surprising that it is not working. Many examples in the Arduino world are quite simplistic and work great as long as everything goes down the "happy path" (where everything just works all of the time). The CCS811 and the SCD30 are NOT sensors that work with the esp8266 in the "happy path". If you want success with them, the code has to handle the things that can and do happen that are outside the "happy path".

The specific code sample above is only waiting 50 uSec for data to be available before requesting it. That is likely not enough time for the CCS811 to prepare it (at least some of the time). When it does request the data, it doesn't bother to see if the request was actually fulfilled. It just blindly reads the data.

This was what I found in the available libraries for the SCD30. The official library for the SCD30 from Sensiron was a little better, but it had too many dependencies to be easily usable with Tasmota. So, I wrote a new library for it. The code window is not working for me, so look at this:

The key thing here is checking the result from requestFrom(). The check for available() is not really necessary, since the result from requestFrom() pretty much assures there is data available.

But, this is the section that made it start working for me:

The key piece is waiting (1ms worked fine for me) between sending the command to the sensor which requests it to send data and actually trying to read data. The examples I saw for Arduino did no waiting and all had issues working with the esp8266. I believe this is due to the underlying issue in the libraries for the esp8266. Waiting seems to work around the issue, at least most of the time.

The code for the SCD30 and the sensor code has additional retry methods and the really big hammer of resetting the whole i2c bus. When I slowed things down for the SCD30, I rarely have to use the really big hammer. Before getting the code working well, I would have to reset every few min at the most. Now, it can go for days without needing to reset the i2c bus.

I don't have a CCS811 and given what I have seen of it and the SCD30, I have no desire to have one. But, the technique I used for the SCD30, should also work the CCS811.

[jpduhen]

@Frogmore42 Since I’m not a programmer, could you please show the particular file to edit and what lines need to change for the CSS811 to get working, when using Platformio to compile Tasmota?

[Frogmore42]

@jpduhen that would not be easy. The code for the CSS811 does not follow best practices for dealing with hardware (it takes quite a few shortcuts, not a problem … until it is). A quick look at the code shows this function:
void Adafruit_CCS811::read(uint8_t reg, uint8_t *buf, uint8_t num)

add a delay between:
Wire.endTransmission();
and
Wire.requestFrom((uint8_t)_i2caddr, read_now);

I used delay(1);
this was enough for the scd30 most of the time. To really solve the problem is going to take someone who is really interested in solving it who has one and enough time and patience to figure out exactly what is going wrong. Making i2c work reliably is not easy in the best of circumstances. Since it seems there are issues with the esp8266 implementation/support of clock stretching, it might be better to get a different sensor.

[jpduhen]

@Frogmore42 I’ll 1st try suggestion one, and let you know if it fixes things, if not, I’ll go for suggestion 2 ;-)

[jpduhen]

@Frogmore42 SUCCESS!! Now 4 hrs stable. I think you nailed it!

This is what I edited:

[Frogmore42]

Glad it worked out. I suspect that it will still have issues, but they won't be as frequently.

[qingz2004]

Does not work form me. Disappeared in 3 hours.

[jpduhen]

14 hours here and still going OK. Do you use 6.5.0 with the 2.3.0-core?

[qingz2004]

6.4.1.22 with 2.4.2 core.
Last not even one hour.

[jpduhen]

I had massive problems with core 2.4.2. Half a year of instability in Wifi connections from my sensors and switches, socket-errors in mosquitto-MQTT. Glad the 6.5.0 release is on core 2.3.0 again. Perhaps you should try it also.

[qingz2004]

Just tried.
Still no luck.
Less than 18 minutes.

[Jason2866]

@qingz2004 you can try i2c clock streching fix for arduino core https://github.com/maarten-pennings/I2C-tool/blob/master/I2Ctest8266/README.md#how-to-fix
Core 2.3.0 is for pitty I2C devices in general not a good choice.
Try latest Arduino core stage with the I2C fix
It will be finally nailed when the complete rewrite of the driver from @mike2nl is done.
When? It is done when it is done ;-)

[jpduhen]

You can also try this fix, then compile Tasmota with Arduino IDE, worked for me earlier:

where you can change dir-names according to the core you're using in Ardoino IDE (core 2.3.0, 2.4.2 or 2.5.0) whatever you like using. You have to install these "boards" in Arduino IDE via Board selection - Board manager menu:

and then select your core (here I'm using 2.3.0:

[qingz2004]

@Jason2866 @jpduhen Thanks for the suggestions, but I'm using PlatformIO.

[joba-1]

Pio uses the same esp cores, just search for the file yourself. For me it

is somewhere below $HOME/.platformio

iphone so i typo

[Jason2866]

@qingz2004 i use Platformio too... Search where @joba-1 wrote. It is there ;-)

[jpduhen]

@qingz2004 Yes, found it too:

[Frogmore42]

Doesn't really do anything since this code follows that:
'void Adafruit_CCS811::_i2c_init()
{
Wire.begin();
#ifdef ESP8266
Wire.setClockStretchLimit(1000);
#endif
}'

[jpduhen]

OK, then this is not a possible solution.
@Frogmore42 twi_setClockStretchLimit() is the same variable as Wire.setClockStretchLimit()? I guessed it was a different one. As I said, I'm not a programmer.

[Frogmore42]

If you want it longer, just change it in the CCS811 code. The SCD30 code I wrote uses a VERY large number. It sort of helps but does not solve the problem always. Maybe when the underlying issue is resolved in the core things will work better. But, errors happen. Not dealing with them doesn't make them go away 😉. Example code rarely deals with errors. That is left as an exercise for the reader.

[jpduhen]

CCS811 still working on my TH10 by the way, 1 day and 14 hrs now:

23:23:29 MQT: tele/TH10/STATE = {"Time":"2019-03-24T23:23:29","Uptime":"1T13:55:34","....
23:23:29 MQT: tele/TH10/SENSOR = {"CCS811":{"eCO2":1872,"TVOC":224},"PressureUnit":"hPa","TempUnit":"C"}

[qingz2004]

@Jason2866 Tried i2c clock streching fix for arduino core https://github.com/maarten-pennings/I2C-tool/blob/master/I2Ctest8266/README.md#how-to-fix.
Tried both core 2.3.0 and 2.50.0 with PlatformIO, none of them works for me.

[jpduhen]

@qingz2004 That’s frustrating. If you like I can try to build a tasmota-version for you on Arduino IDE, maybe that will fix things for now?

[qingz2004]

@jpduhen Sure, thanks! Please let me try your load, and see if the problem is in the load or my CCS811 module. I already tried the CCS811 on different NodeMCU.

[jpduhen]

@qingz2004 Try this one:

https://www.dropbox.com/s/vmbp7d5ylwbcdkm/nodeMCU-CCS811.bin?dl=0

[qingz2004]

@jpduhen Thanks! It worked for less than 18 minutes. So not the firmware.
Have to wait for the driver from @mike2nl or get another CCS811.

[jpduhen]

OK, that’s so frustrating !

[gemu2015]

@qingz2004
mine is running since 200 days without any error or stopping.
i compiled a version thats logging the 3 version parameters for:

hardware version
firmware version
app version

my numbers are => CCS811 Vers: HW:18 FW:16 APP:17

you may give it a try

1 mb flash =>https://www.dropbox.com/s/uoweb4ad6y2ft3u/ccs811.bin.zip?dl=0

[qingz2004]

@gemu2015 Thanks! Will definitely try it when I get home.

[qingz2004]

@gemu2015 Flashed. How to check the version number?

[qingz2004]

Good news.
After 7 and half hours, still good.

[gemu2015]

@qingz2004

OK, first lets check your versions.
version is logged to the console in debug mode on initializing the chip.
setup=>configure logging=>web log level=debug
then restart the module and check the console log

there are NO differences against the Tasmota main version of the driver, BUT
from the very beginning i used the chip in "compensation mode" that is i used the sht31 for humidity and temperature compensation.

having that in mind i only changed ONE thing in the current driver.
when there is no compensation from another chip i did set the compensation to default.
that forces the ccs811 to reevaluate its internal calculations on every reading.
may be that this makes it that stable as in my case. you can simply change the code of the standard tasmota driver with my code snippet below to prove this.

in xsns_31_ccs811.ino

replace
if (global_update) { ccs.setEnvironmentalData((uint8_t)global_humidity, global_temperature); }

with
if (global_update) {
ccs.setEnvironmentalData((uint8_t)global_humidity, global_temperature);
} else {
// these are the default values
ccs.setEnvironmentalData(50,25.0);
}

[qingz2004]

@gemu2015 14 hours, still good.
Here is my version. Same as yours.
CCS811 Vers: HW:18 FW:16 APP:17

[qingz2004]

@gemu2015 Tried your code with Tasmota 6.5.0.1 and core 2.5.0. CCS811 stopped working after one and half hour.
There must be something else.
Do you still have all the files when you did the compilation?
Or can you compile it in English? I don't know German.

[gemu2015]

it seems to be a very strange interaction.
probably try again with core 2.3 as i do, there are significant changes in i2c in 2.5
or take my fork and adapt it to your needs. it is a bit outdated, but i only bring it up to date from time to time. => https://github.com/gemu2015/Sonoff-Tasmota

[qingz2004]

@gemu2015 Missing user_config_override.h file from your github. It is not enabled in platformio.ini, but still need the file, otherwise, I got error. And if I do not define CCS811 in the override file, CCS811 will not be recognized.
So I used my override file, and compiled. CCS811 lasted only half hour. And it does not display version number in console.
May I have your override file? Your load is very small (484K), you must removed a lot of stuff.

[gemu2015]

i disabled everything i did not need to gain space for my display drivers.
possibly there is a conflicting i2c driver enabled in the standard config.
attached is my user_config_ovveride i used to compile your (and my) working version
enabled is ccs811, sht31 and sh1106 display driver

maybe we can figure out which driver causes the clash.

user_config_override.h.zip

[qingz2004]

I see DUSE_CONFIG_OVERRIDE is commented out in platformio.ini. Why the file user_config_ovveride.h is still used?

[gemu2015]

you may also enable this in my_user_config.h

define USE_CONFIG_OVERRIDE

[qingz2004]

I see. You enabled it in your fork.
Will try your override file when I get home.
Did you change the library file?
Thanks!

[gemu2015]

ok at a short look if found that some of the enabled i2c sensors in the standard config try to (re)connect to their sensors every second. one of them may have a conflict with ccs811
we need to reenable one after the other to find the bad guy.

[qingz2004]

Compiled with your user_config_override (changed wifi to mine). Running for two hours, still good.

[gemu2015]

it turns out that there is interference of another i2c driver
one of these

define USE_SHT

define USE_HTU

define USE_BMP

define USE_BH1750

define USE_SGP30

define USE_LM75AD

there has been a hint in a previous post that @pesone got it running with the following comment =>
I've compiled with no sensors except CCS881 in my_user_config

i am short of time and can not determine which driver fails. but all of them regularly (FUNC_EVERY_SECOND) try to update their sensors (and eventually reinit them, i doubt if that is a good idea)

so temporary solution is to disable all other not needed i2c sensor drivers. i guess it will then run also in latest tasmota.

[Frogmore42]

It is a good idea if one wants to not require restarting the device if a sensor is not attached and/or flakey. But, I don't doubt that it can cause an issue the CCS811. I believe the CCS811 (like the SCD30) is very particular about i2c and extra traffic is probably not a good thing for it. Turning off all the other sensors is a fine idea and maybe that will increase the reliability for you. That is one of the reasons each of the sensors has a unique #define controlling it.

[jpduhen]

I have it working together with a BME280 on one I2C bus on a sonoff TH10,

and that works fine for me. I did however disable all other drivers when I complied the tasmota-firmware for the TH10, leaving just the ones for the BME280 and the CCS811.

[qingz2004]

Almost 17 hours. Still good.
Moving to the latest code with other sensors disabled.

[jpduhen]

@qingz2004 looks good so far, fingers crossed!

[qingz2004]

Latested Tasmota (ver 6.5.0.3) with core 2.3.0, no modification on CCS811 driver or Arduino libraries, but removed lots of sensors by using @gemu2015 user_config_override file.
Running for 3 hours. Still good.

[qingz2004]

Enable I2C for CCS811, SHT3X, SHT, display SH1106, SSD1306, LCD.
Running for 6 hours. Still good. Now I'm adding more I2C sensors.

[qingz2004]

Enable I2C for CCS811, SHT3X, SHT, LM75AD, BH1750, HTU, removed display.
Running for 13 hours. Still good.
I'm not sure if it's a problem.
I put the load at 10pm est, and the eCO2 and TVOC kept updating till 12AM, then stay the same after that all the time.
Did an I2C scan, found the device. So it did not crash.

[qingz2004]

Based on previous setting, added SGP30 and added display driver back, CCS811 crashed in 20 minutes.
Looks like the trouble is from SGP30.
Made another load without SGP30 but with everything else the same.
Hope this load will last.

[gemu2015]

ok found the bug in sgp30. sgp30 calls twi_init and twi_init sets the clock stretch limit to default
again (230) which is to few for ccs811.

i still think it is not a good idea to initialize sensors that are not physically available.

at least there should be an interface to disable drivers that are in the code but not needed to avoid unnecessary digital noise and power consumption.

[qingz2004]

Running for 2 hours, still good.
Looks like we identified the bad guy who stops the CCS811.

[Frogmore42]

@qingz2004 I am glad you found a solution.
The simple method that exists today is to not include drivers in the code at all if you do not need them. That has the additional benefit of reducing the code space used and might make it possible to do single step OTA.

Having said that I agree the SGP driver should not always init the i2c bus. When I wrote the driver the SCD30, I decided not to do that. But, I knew that Tasmota already took care of it, so it was not necessary. The Adafruit driver is trying to be friendly to beginners, by still working if the user hasn't already set up i2c. But, it really doesn't follow best practices for a reliable i2c driver. It should be rewritten to be more reliable and cooperative for a multiple sensor environment. But, that would take time and effort by someone who understands i2c well and the environment (Tasmota and esp8266 i2c). I don't know who is really going to want to take that on.

I'll bet the SGP driver caused some of the issues I saw with the SCD30. As far as checking for the existence of the sensor every second, I don't believe it is really necessary normally. But, having it there makes it easier to figure out wiring issues, since a restart is not needed every time.

As far as having some configuration to indicate which sensors are really being used, that would take at least a bit for every sensor type, plus the configuration of those bits (pretty easy to define a setoptionXX for them).

[arendst]

With debug enabled and compiled you have an option to enable drivers and sensors on the fly. I don't know the correct syntax anymore but have a look at xdrv_99_debug.ino

[moneybag]

#define CO2_LOW 800 // Below this CO2 value show green light (needs PWM or WS2812 RG(B) led and enable with SetOption18 1)
#define CO2_HIGH 1200 // Above this CO2 value show red light (needs PWM or WS2812 RG(B) led and enable with SetOption18 1)

doesnt work for this sensor.

[Jason2866]

eCO2 isnt CO2....

[moneybag]

bad, would be great to implement this, like this
https://blog.moneybag.de/fhem-tvoc-co2-temperatur-luftfeuchte-luftdruck-luftqualitaet-messen/

[jpduhen]

@moneybag For accurate CO2 measurements I use this sensor: https://nl.aliexpress.com/wholesale?catId=523&initiative_id=AS_20190404114833&SearchText=mh-z19

[moneybag]

yep, i tested this sensor, too. works very stable.
https://blog.moneybag.de/fhem-luftqualitaet-messen-mit-dem-mh-z14-mh-z19-co2-sensor-und-espeasy-wemos/

[Jason2866]

offtopic... Use MHZ19b it is a good sensor (price...) and is supported from Tasmota and WS2812 stripe works with it. MHZ19 is a real CO2 sensor.
eCO2 Sensors are equivalent carbon dioxide

[gemu2015]

why not use rules for signaling ?
much more flexible without recompiling

[moneybag]

good idea, gemu2015

[moneybag]

Jason2866 : eCO2 Sensors are equivalent carbon dioxide
Jason2866 : eCO2 isnt CO2....

i am confused

[gemu2015]

https://www.sustainablebusinesstoolkit.com/difference-between-co2-and-co2e/

[Frogmore42]

Good link, but not the right one. eCO2 and CO2e are not the same thing. The CCS811 measures a wide range of volatile organic compounds (VOC) These are things like alcohols and terepenes. The CCS811 has no sensitivity to actual CO2. The CCS811 has an algorithm that makes an assumption that all VOCs in the air are the result of human respiration. It then provides an estimate of the equivalent CO2 level. The theory is that this eCO2 value is good enough to indicate more ventilation is needed. But, it would not work so well in my house. I have a gas stove, which emits actual CO2. The CCS811 is not able to detect this so it would under report the value. Similarly, if you or someone in your house/location uses a lot of perfume it would over report the CO2 level, but more ventilation might be necessary anyway.

[gemu2015]

the article does NOT claim they are the same! CO2 is exactly that gas, CO2e is an estimated value derived from TVOC that has an equivalent warming effect like that value of CO2.

[moneybag]

Good news. I tested the ccs811 with a minimum of sensors in the device list and compiled the tasmota source. It works stable now!
By the way i compared the sensors voltcraft air quality, mhz19 and ccs811 and made a chart of those 3 ones. All sensors are in the same room.

https://blog.moneybag.de/wp-content/uploads/2019/04/Screenshot-2019-04-08-20.15.22.jpg

Looked very similar.

[Chaot1]

Ok, i'll try it again the next days.
My last ccs811 had a "accidential" meeting with a hammer but i still have one in stock.

[moneybag]

Is there a chart available, where i can see what values are good or bad?
My ccs811 shows:

CCS811_TVOC | 118 | 2019-04-09 10:02:30
-- | -- | --
CCS811_eCO2 | 1175 | 2019-04-09 10:02:30

and i dont know if i can compare it with usual co2 values.
edit: TVOC https://www.allaboutcircuits.com/news/a-new-multi-pixel-metal-oxide-gas-sensor-with-an-i2c-interface-in-a-small-p/

[gemu2015]

this link explains TVOC and limits =>

https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/9_Gas_Sensors/Sensirion_Gas_Sensors_SGP3x_TVOC_Concept.pdf

better don't interpret or use eCO2 for indoor air quality better use real CO2 sensor

[moneybag]

I made a Blog-Post in my Blog (german), works fine now!
07:02:00 MQT: tele/ccs811bme280/UPTIME = {"Time":"2019-04-19T07:02:00","Uptime":"12T21:00:43"}

https://blog.moneybag.de/revisit-tvoc-eco2-temperatur-luftfeuchte-luftdruck-luftqualitaet-messen/

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.

[probonopd]

How did you get this sensor compiled in?

wget -c https://downloads.egenix.com/python/install-pyrun
bash install-pyrun --python=3.5 appdir/usr/
appdir/usr/bin/pip3 install -U platformio
./appdir/usr/bin/platformio upgrade
./appdir/usr/bin/platformio update

git clone https://github.com/arendst/Tasmota
cd Tasmota/

# Configure Tasmota as needed - THIS SEEMINGLY DOES NOT WORK YET
sed -i -e 's|//#define USE_CONFIG_OVERRIDE|#define USE_CONFIG_OVERRIDE|g' ./tasmota/my_user_config.h
echo '#define USE_CCS811' > ./tasmota/user_config_override.h

../appdir/usr/bin/platformio run -e tasmota

# Check whether CCS811 has been compiled on
strings ./.pioenvs/tasmota/firmware.bin | grep 811
# (nothing)

When I compile like this, the CCS811 does _not_ show up in the menu...

[Jason2866]

Why do you expect that the string 811 appears in firmware.bin?
What output do you get with the command i2cscan?

[andrethomas]

It might make an effective difference if you actually put the correct line in the user_config_override.h

You're doing

echo '#define USE_CCS81' > ./tasmota/user_config_override.h

instead of

echo '#define USE_CCS811' > ./tasmota/user_config_override.h

[Jason2866]

@andrethomas sharp eyes 😀

[probonopd]

Stupid me. Thank you so much! (Edited above to fix my mistake.) Now CCS881 is compiled in as I can see:

me@host:~/Tasmota$ strings build_output/firmware/tasmota.bin | grep CCS
{s}CCS811 eCO
{m}%d ppm{e}{s}CCS811 TVOC{m}%d ppb{e}
,"CCS811":{"eCO2":%d,"TVOC":%d}
CCS811

__But__ it still does not show up in the menu when I go to Configuration -> Configure Module -> GPIO14 Sensor -> (Pulldown menu)

Am I doing it wrong?

[meingraham]

I _think_ the point is that you define the I²C GPIO and then the CCS811 will be found on the bus... and because you've compiled in the code to support the sensor, when the sensor is detected, it'll be able to "speak" to it properly. You do not configure a CCS811 in the GPIO configuration.

[probonopd]

Uh, this seems to be more complicated than I thought. I expected to select the sensor from the drop down menu and have MQTT messages magically appear. How are you using the CCS811?

[andrethomas]

The sensor is I2C so since the same pins are used for multiple I2C sensors you need to configure SCL and SDA pins according to how you wired it to the ESP82xx

[probonopd]

Thank you very much, with your help I got this to work.

tl;dr: One cannot just attach the sensor and expect it to show up in the menu, one must compile a custom version of the firmware, then set I2C SD and I2C SCL as shown above, and one needs to connect the WAK pin of the sensor to GND (otherwise the sensor will not be detected). If one does this, then the sensor values will be shown on the Tasmota frontpage, and will be sent over MQTT.

[martin072]

Would Like to share my experiences with the CCS sensor and Tasmota as well. I have one of these sensors running on own coded system and that seems to work fine. With the latest Tasmota 8.1.0 the sensor appears fine when the unit boots. But after a certain time it disappears. A reboot will get it working again, but same result.. mostly within a day it will stop working again.

[martin072]

For those of you that still experiencing issues with this sensor, I have enabled DEBUG_THEO and then gave the command I2CStretch 460 after a reboot. This seemed to have sorted out the problem of the sensor disappearing after a few hours for me. It is now running for 2 days and 12 hours with Tasmota 8.1.0 and the sensor still works..

//edit
Unfortunately it stopped working again just after I posted this message :(

[Dees7]

Hello.
Have the same trouble.
Tasmota 8.2.0.5
1-2 hours and device disappears. I see it in i2cscan. But no data in mqtt and web.

How can I debug to find root of trouble?

[Dees7]

I was able to fix it with pulling up reset\scl\sda to +3.3V and installing capacitor (might be pullup "reset" is enought).
Connecting Wake to GPIOx I can turn sensor on and off (but it not needed in normal. It is enought to pull down)

(sorry for russian pic)

Now it works well. But only if CCS811 is a single i2c sensor. If I connect any more sensor (for example BME280) then after ~1h CCS811 stops working. I see CCS811 with i2cscan but it doesn't show data.

[zakamik]

Documentation to this module suggests to pull RST pin to VDD to avoid possible false triggers due to interference. I had the same issue when board suddenly stopped working at any random period of time. After pulling reset pin up with 6.8K I now have stable up time of more than 2 days.
Hope this helps.