Closed Chaot1 closed 5 years ago
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
in Tasmota Adafruit Lib Clockstretchlimit is already set to 1000 =>
Wire.setClockStretchLimit(1000);
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)
Hi,
Closing this issue as there is no feedback. Please, ask to reopen if needed. Thanks
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
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.
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.
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.
I tried it.
It does not freeze any more, but the data I got is not realistic.
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
Flash back to original firmware, I get this.
i would suggest to
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
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"}
@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...
re-opening on request from @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)
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.
Tasmota Version | 6.4.1(sonoff) 2_4_2/2.2.1(cfd48f3)
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-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
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.
@pesone Thanks for sharing - I'm sure @mike2nl will find it useful... really wish I had one of these to help out though.
@pesone @andrethomas @arendst @ascillato2 @gemu2015 Update for 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.
@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.
@gemu2015 - no issue at all ;-) @pesone @gemu2015 @ascillato2 @andrethomas Short Update:
Last but not least we have progress now!
Any news on this?
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.
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
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.
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++;
}
}
}
Tried. No luck.
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.
@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?
@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.
@Frogmore42 I’ll 1st try suggestion one, and let you know if it fixes things, if not, I’ll go for suggestion 2 ;-)
@Frogmore42 SUCCESS!! Now 4 hrs stable. I think you nailed it!
This is what I edited:
Glad it worked out. I suspect that it will still have issues, but they won't be as frequently.
Does not work form me. Disappeared in 3 hours.
14 hours here and still going OK. Do you use 6.5.0 with the 2.3.0-core?
6.4.1.22 with 2.4.2 core. Last not even one hour.
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.
Just tried.
Still no luck.
Less than 18 minutes.
@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 ;-)
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:
@Jason2866 @jpduhen Thanks for the suggestions, but I'm using PlatformIO.
Pio uses the same esp cores, just search for the file yourself. For me it is somewhere below $HOME/.platformio -- iphone so i typo
@qingz2004 i use Platformio too... Search where @joba-1 wrote. It is there ;-)
@qingz2004 Yes, found it too:
Doesn't really do anything since this code follows that: 'void Adafruit_CCS811::_i2c_init() { Wire.begin();
Wire.setClockStretchLimit(1000);
#endif
}'
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.
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.
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"}
@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.
@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?
Make sure these boxes are checked [x] before submitting your issue - Thank you!
status 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