Let's Control It

@Ath
Sorry for the beginner question, but how do I download the .bin with request?
I see files but I don't know how to download it.

Smotek7 wrote: ↑26 Feb 2022, 14:08 ... how do I download the .bin with request?
I see files but I don't know how to download it.

- Go to the PR #3965
- Scroll to the bottom, where it says "All checks have passed", and click the "Show all checks" link, then they will fold out.
- Select on of the "Details" links, the first one will do fine, it will show you the output of that build step.
- Click on the "Summary" link, left above the list of build steps.
- The right side will now show a schema of the build process, and a list of Artifacts.
- Download the Binaries(.zip) file from that list, it is ~660 MB in size.
- Extract the build you need, Binaries.zip contains a .zip file for each build, so you will need to get a 'test_d' .zip file, for the ESP model and flash you are using, as only that build contains this plugin.
- Extract the .bin from that zip, and upload. You can also upload the .bin.gz via OTA (Tools/Update Firmware button) when using a 4MB flash or bigger. (ESP32 doesn't have the .bin.gz file)
s
--------------------

For forced recalibration factor and manual/automatic calibration I already added the commands in this PR

I'll also add getMeasurementInterval and setMeasurementInterval commands (I'll abbreviate a bit) and also a Device configuration setting, as that does seem useful/appropriate to me.

Added commands 'scdgetinterval' and 'scdsetinterval', and a setting to pre-configure that.

Fixed a bug in the previous commit for handling command 'scdsetfrc'.

See PR #3965 for downloads, once the build has completed.

Unfortunately, the Github actions build failed, so here are 2 local builds for testing:

Outdated, latest build available from Github

I didn't know I had to click on Summary

I updated one sensor.
Activated ASC (The ABC label is probably a mistake)
scdgetabc now returns 1
I'll see what changes over time.

I can test on another scdsetfrc sensor
The question is when I set it, how do I verify if the value is in the sensor?
It could also display this value on the web.

I have an application note for calibration.
I don't understand what the scdsetcalibration setting mode is for.
If the Sensorion application is used
there is only a set ASC and a set FRC value.

The build you downloaded and tested is already outdated
I have just pushed some more commits (and earlier too, fixing that ABC to ASC and a bug inn setting the FRC), hopefully this time Github actions won't fail for no apparent reason.

Please re-download and test the latest build from the PR, TIA!
Edit: Build succeeded, so go ahead

Smotek7 wrote: ↑26 Feb 2022, 13:52 I'll test it on one sensor.

Any update on how your tests are progressing?

I tested FRC on 2 sensors, it works properly.
I did not test the ASC because the sensor needs to have a reference value for a certain time of day.
Then I have to prepare the environment, I can't try it in one place at home.
The function is intended sooner for office buildings where the building is emptied at night and CO2 drops to 400ppm

Smotek7 wrote: ↑26 Feb 2022, 13:52 If I understood correctly, automatic calibration takes at least 5 days.
I'm waiting to upload. It goes gradually ...
I'll test it on one sensor.

Any progress with testing this?

Hi,
I devoted time to something else.
But today I started testing autocalibration.

Hi all,

first, thanks for your work for the SCD30 sensor.

But I had a little problem to get the data from the sensor. In easyesp (https://github.com/letscontrolit/ESPEasy/releases last release)I can choose the "Gases - CO2 Senseair", enable it and use the I2C protocol.
I tried all I2C addresses without success. After some searching I fond in the dataset the the sensor uses 0x61 but it is not choosable in the drop down menu.
The I2C scanner (under tool menu) shows me also 0x61. A short sketch with Adafruit SCD30 library shows me Co2, Temp, Hum.

So, made I a thought error here or is there some other config needed?

Best regards ...Carsten

The SCD30 is not a SenseAir sensor.
The SenseAir plugin supports sensors like the S8 and S11 (also called "Sunrise")

These SenseAir sensors typically can be used via a serial (UART) connection.
ESPEasy also supports an I2C to UART bridge, but I do agree that this can be made a bit more clear what the "I2C" selection actually means for "Serial" sensors.

However, to begin with, you choose the wrong plugin. You need the SCD30 plugin.
See: https://espeasy.readthedocs.io/en/lates ... #p117-page
This one is only included in "Testing D" builds, or the "MAX" build (a build containing all, for ESP32 with 16M flash)

Hi,
thanks for your answer.

Yes you're so right and I was to stupid to choose the right plugin and this can't work with my SCD30 ... head bashing (was really to late yesterday).
I read the plugin name so often and did not recognises that I'm using the wrong.

Choosing the right "bin" and choosing the right plugin and it works (after a cold restart) as expected out of the box, THANKS!
My FHEM installation shows now all data from the sensor.

What I have noticed is that some of the changes needs a cold start from the ESP/Sensor with settings for FHEM but if all configured it works like a perfect.

One last question, today I use a ESP8266 D1 mini (https://www.az-delivery.de/products/d1-mini) and tried also a ESP32 Dev Cit v4 (https://www.az-delivery.de/products/esp-32-dev-kit-c-v4) without success, the "bin" (ESP_Easy_mega_20220427_test_D_ESP32_4M316k) restarts always on this device. How to find out the Problem?

SORRY for wasting your time but without your BIG hint I would be trying some some without success.

Best regards ...Carsten

When flashing via serial to an ESP32, you need to flash the version with "factory" in the filename of the bin you like to flash.

Later, if you plan to update the firmware via the web interface, you have to use the files without the "factory" in the name.

N.B. always use the same flash layout and filesystem (LittleFS is another filesystem, SPIFFS is the default file system)
If not, then the existing settings will be erased.


By the way, what settings you did needed a reboot of the ESP to function?

EDIT POST by myself

===============

Sorry for the late reply, i am always in Bonn during the week (Berlin - Bonn - Berlin) and at the weekend the family comes first, so i don't have much time to experiment with the ESP32.

Thanks for the "factory hint". Today I tried it it again without success. Console error message: When I use the the "espflasher" tool I get the messages: If I flash the esp with the chrome browser (https://td-er.nl/ESPEasy/) it flashed right and it is working but there is no SCD30 plugin (version 20211105).


To your question first I configured the sensor and it shows after a reboot the messaged data. Then I configured the "Controller" (FHEM) but my FHEM installation can't geht the data. After a physically power down (disconnect from the power) them was able to get the data.
So my next steps I get the esp32 working but I had still no ideas ... will more searching in the internet what the error means.

Best regards ...Carsten

please download a version *after* 2022-04-27, for ESP32 there have been fixes that are quite 'usable'.
You can download from Github Actions build, I just selected the most recent PR build there: https://github.com/letscontrolit/ESPEas ... 2479937379 (you need to be logged in to Github to be able to download)

Then use the similar flash command you just showed, with the similarly named .factory.bin file from the binaries.zip you download from the Github link.

@Ath,
wow, now it worked for me out of the box, many thanks!

Did some one test to adjust the temp offset for the sensor?
My sensor shows to high temperature so the offset should set to -1.50°C but it seems not working.
Is there a trick? Thanks and regards ....Carsten

I quickly checked the plugin code, and the temp offset is supplied to the sensor driver at startup, and using the 'scdgettmp' command, retrieves it from that same driver again.
Do you have multiple SDC30 sensor-tasks configured (and active) on that ESP, where the first one doesn't have the offset configured?

Thanks,
that was what I read in the docs.
No, only one SCD30 sensor and one non active BME280 sensor (deactivated, the temp offset for the BME280 works).


========= EDIT
offset in positive is also not working

========= EDIT 2
strange, now offset from 20 and the temp is falling down (it takes some more time that the sensor makes the offset)
ambient temp here is 25^C ========= EDIT 3
The humidity is also affected from temp offset ...lower temp more humidity (see pic), ambient hum is here 55%

Build: ESP_Easy_mega_20220616_test_D_ESP8266_4M1M Jun 16 2022

CaWi wrote: ↑20 Jun 2022, 11:28 No, only one SCD30 sensor and one non active BME280 sensor (deactivated, the temp offset for the BME280 works).

Ok, great.

CaWi wrote: ↑20 Jun 2022, 11:28 strange, now offset from 20 and the temp is falling down (it takes some more time that the sensor makes the offset)
ambient temp here is 25^C

========= EDIT 3
The humidity is also affected from temp offset ...lower temp more humidity (see pic), ambient hum is here 55%

All technical functionality is left to the device & driver/library used, 'I'm only playing the piano' , so any behavior, and probably that compensation too, is coming from there, not much I can (or want to) do about it, maybe this behavior is explained in the datasheet of the sensor, but I don't have that available where I am now. Will check later.

The relation between temperature and humidity is how it should be.

Air can only hold so much water per liter depending on the temperature.
With lower temperature, this maximum amount of water it can hold also gets lower.

Given some amount of water in the air, there is a lowest temperature at which the water in the air will condensate.
This is called the dew point temperature.
You will see water condensate on colder surfaces, like a window or your glasses when you walk from cold air outside to a warm a humid room.
Since the humidity is relative to the temperature, we always refer to the relative humidity in %.
At 100% the water in the air will condensate.

What the temperature compensation does on a sensor that measures both temperature and relative humidity is this:
- Compute absolute humidity based on measured temperature and relative humidity.
- Change temperature value according to the compensation value
- Compute relative humidity from absolute humidity and changed temperature.

Many thanks for the explanation.

Some other observation:
Offset with "-" number values not working

if I use the "+" offset value for the "calibration" (wrong way round) the temp goes slowly down to the right value AND when the "calibrated" value is reached the sensor lost the right showing temp and starts from the beginninnig ... count down again to the "calibrated" value .... and again. The offset values is saved incorrectly or could be only without decimal places (X.misssing)?

You might want to compare your notes with the documentation available at Sensirion, especially the Field Calibration application note might be helpful: https://sensirion.com/products/catalog/SCD30/

Thanks for all helping.
In the last week I did the calibration and it works (after new flashing the ESP) without "Restarting the calibration".

Great that it is now working as intended and for reporting it here

I'm done, thanks for your help!

A little problem,
Ambiente temp is 27°and the SCD30 shows 31°
The temp offset is set to -4.00°
Is there a bug with the temp offset?

Settings: scdgettemp outpt: I remember the that I saw this before ... actual FW: ESP_Easy_mega_20220809_collection_D_ESP8266_4M1M Aug 9 202

I didn't know what I'm doing wrong with the forum sw.

CaWi wrote: ↑13 Aug 2022, 17:28 A little problem,
Ambiente temp is 27°and the SCD30 shows 31°
The temp offset is set to -4.00°
Is there a bug with the temp offset?

I've had a look at the code, and the plugin is doing everything as expected, it's the SCD30 sensor (and library) that has a twist: This means that only 0 or positive values can be used for the temperature offset, as that's the only values the sensor will accept.
This is not reflected in the plugin behavior, but can be changed.

Thanks for looking to the code and confirming this behaviour.
I'm not able to correct the code so did you have a solution form me (us)?
Around 4°C difference is very much ... on or two would be ok for terrarium (second one) but 4 is to heavy.

Best regards ...Carsten

I'm not sure if this either can or needs to be 'fixed' as the chip doesn't allow negative compensation. It can be a relative value, so what is the result if you set it to 4?

Value set to 4: scdgettmp:

Can anyone advise how to track what could be causing the SCD30 sensor to freeze? After a certain time (a few hours or a few days), the sensor falls off, and only a cold reboot helps. The web interface is available all the time, but after sensor freeze, it is constantly displayed as disabled, and does not respond to ticking the "enable" switch. Only a reboot after a power cut brings the assembly back to life. Firmware ESP_Easy_mega_20230306_collection_D_ESP8266_4M1M

What value have you set the I2C Clock stretching to on the Tools/Advanced page? And you have selected Force Slow I2C Speed, as suggested in the documentation?

Ath wrote: ↑31 Mar 2023, 15:00 What value have you set the I2C Clock stretching to on the Tools/Advanced page? And you have selected Force Slow I2C Speed, as suggested in the documentation?

Everything seems to be according to the documentation, if I'm not mistaken. Screenshots are attached.

Since the 20230306 release we have added a new option in Tools/Advanced: "Check I2C devices when enabled", and this is enabled by default.
On a few other sensors we have seen issues with this check, so possibly we have to separately inhibit the check for this plugin too.

Can you turn that setting off and test for a couple of days, to see if that solves the issue?

And not unimportant, have you been running this device with an older release of ESPEasy, without these issues? As that would be a clear indicator that this device (also) doesn't like the check (on every Interval read action...).

Ath wrote: ↑31 Mar 2023, 16:40 Can you turn that setting off and test for a couple of days, to see if that solves the issue?

Done. Do these changes to the settings require a reboot or a cold reboot?

Ath wrote: ↑31 Mar 2023, 16:40 And not unimportant, have you been running this device with an older release of ESPEasy, without these issues?

No, I haven't used this sensor with older builds yet.

Now it works stably.

There is a question about accuracy.
Why do the values of the S8 and SDC20 sensors begin to differ by 30-70 ppm indoors, even though both show 400 ppm outdoors?
I compare "raw values" because the moving average looks unsuitable for use (green line)...

It looks like the ABC for the S8 is a bit off here.
As you can see, there is hardly any 'detail' near 400 ppm with your S8.

TD-er wrote: ↑06 Apr 2023, 21:20 It looks like the ABC for the S8 is a bit off here.

It doesn't appear to be S8 ABC because when the baseline shifts, it also shifts the outdoor air reading, as observed with two Sensair S8 sensors. In the provided example, the outdoor reading is 400 ppm, indicating that there is currently no S8 ABC shift since the last calibration.

No, what I mean is that the close to "400 ppm" doesn't hardly show any detail, just like it 'clips' at 400 ppm.
This means the actual reported values are roughly 50-ish ppm too low on the S8.
The SDC30_RAW does show much more detail and a believable decline in ppm values to 400 ppm.

Only thing I can't explain is why the S8 ppm values seem to show a declining trend where you wrote "indoor", while the SDC30_RAW doesn't seem to change.

TD-er wrote: ↑06 Apr 2023, 23:22 No, what I mean is that the close to "400 ppm" doesn't hardly show any detail, just like it 'clips' at 400 ppm.
This means the actual reported values are roughly 50-ish ppm too low on the S8.

With the Sensair S8, the baseline shifts after several ABC cycles and can show values of 300-200ppm, or even lower. There is no clipping at 400 ppm, as with the MH-Z14. This makes the S8 convenient because it immediately shows whether the baseline has shifted and by how much after being taken outside.

TD-er wrote: ↑06 Apr 2023, 23:22 Only thing I can't explain is why the S8 ppm values seem to show a declining trend where you wrote "indoor", while the SDC30_RAW doesn't seem to change.

Here is a sample for several days. A downward trend is observed about an hour or two after the sensors are moved from +10C outside to +23C inside. Apparently, after the sensors heat up to room temperature, the readings follow a more or less stable pattern. However, it is unclear which readings are closer to the truth, and why the shift is greater in some areas and smaller in others.

Maybe there is some correlation with air pressure?
Or relative humidity? (or both?)

Maybe a little "newbieish", but might help someone else on the search for the correct binary:
The binaries with the controller for the SCD30 are not called "test_D" anymore, but "collection_D".
In my case ESP_Easy_mega_20231225_collection_D_ESP8266_4M1M.bin did the trick and I'm able to configure the SCD30.

My SCD30s (4 pieces) should come today or tomorrow, so I'm about to exchange my Senseair S8 against the SCD30. I'm curious how this will work out.
I'll definitely need the FRC, as I'm using the CO2 sensors to control my ventilation system in our apartment and it's never guaranteed, that I'll reach 400PPM for one hour each day. Also a reason, why I bought a dual channel NDIRs.

Thank you very much for implementing the SCD30!

Here you can see which plugin is included in which build.
https://espeasy.readthedocs.io/en/lates ... al-plugins

The sensor should be included in both the "Collection D" as wel as "Climate" builds

Here the plugin docs page: https://espeasy.readthedocs.io/en/lates ... #p117-page

TD-er wrote: ↑10 Jan 2024, 19:07 Here you can see which plugin is included in which build.
https://espeasy.readthedocs.io/en/lates ... al-plugins

The sensor should be included in both the "Collection D" as wel as "Climate" builds

That's a great advice, thank you!
Yes, it's included in the "Climate" build, just flashed it and looking good.
I hope my sensors are here tomorrow, that I can test it right away.

TD-er wrote: ↑10 Jan 2024, 19:07 Here the plugin docs page: https://espeasy.readthedocs.io/en/lates ... #p117-page

Thank you, I've found that page already, but missed to get the link "Status" --> "build".

Great system btw - already using it for more then two years without any problems. Updated for the first time this December.

Currently, I have a BMP280 for temperature and a SHT21 for humidity together with the Senseair running.
Do you think the SCD30 internal sensors for temperature and humidity could replace the BMP280 and SHT21? As far as I've read it, the SCD30 sensors should be fairly precise.

I know the SCD30 does measure CO2 in a completely different way compared to the SenseAir units.
The SenseAir units may have a higher internal temperature compared to the environment, so the internal temp sensor of the SenseAir is a bit useless to measure ambiant temperature (is used for internal compensation of the CO2 measurement)

The SCD30's internal other sensors are probably only used for internal compensation of the CO2 measurement and probably made available for either corrections using formula we don't know or diagnostics.
But I guess the internal values will differ from those measured outside the SCD30 sensor.

And to be honest, I don't really know why you would exchange the SenseAir S8 for these?
When designing a new measurement box where space and perhaps power consumption is of utmost importance, then I can imagine why you want to use the SCD30 over the SenseAir ones. (maybe also when mounted in extremely vibrating environments like a moving vehicle)
But when it comes to accuracy of CO2 measurements, I doubt the SCD30's will be an improvement.

TD-er wrote: ↑11 Jan 2024, 08:23I know the SCD30 does measure CO2 in a completely different way compared to the SenseAir units.

Well, both are NDIR sensors (which is crucial), but the SCD30 is a dual channel, the S8 is single.

TD-er wrote: ↑11 Jan 2024, 08:23When designing a new measurement box where space and perhaps power consumption is of utmost importance, then I can imagine why you want to use the SCD30 over the SenseAir ones.

I'm not designing a new box, I just exchange the CO2 sensor. I have created my own design with enough space and easy to exchange components - as they are pluggable.

TD-er wrote: ↑11 Jan 2024, 08:23And to be honest, I don't really know why you would exchange the SenseAir S8 for these?

Let's start with my environment and what I need the CO2 measurement for:
I control my ventilation system in our apartment based on the CO2 values in each room. 2 adult, 2 kids. The lower the CO2, the lower runs the ventilation. At least permanent with 25%, going over 35% and 50% up to 100% starting from 1.100 ppm.
Although the ventilation is very good, it is not guaranteed, that the CO2 is dropping down to 400PPM within a 24 hours timeframe. Therefore nobody have to be at home - this is only sometimes during the weekdays, when the whole family is away for at least a couple of hours. This is often not the case (Homeoffice, illness, holidays, etc).
Long story short - not a really good environment for ASC.

When I started building my own CO2 / climate sensors for each room more then two years ago, I started testing the MH-Z19 (I had already Netatmo, but wanted to get away from the cloud API - but still good for some kind of reference).
The MH-Z19 was starting shifting in CO2 values quite quickly. The MH-Z19 is doing the ASC in the way, that it takes the lowest measured CO2 value within 24 hours and takes it as 400 ppm.

So I changed over to the SenseAir S8, because the ASC is done differently with this sensor. It takes the lowest CO2 value within 8 days.
This is suiting our environment better and working more or less OK for the last two years - but still I see some significant shifting in measurements. But don't get me wrong, it is still a very good sensor.

But now I want to switch to the SCD30 - which is a dual channel sensor. And dual channel could be even used in environments like greenhouses, hospitals, etc - or our apartment, as it calibrates constantly through its channel with defined and not changing gas in its chamber.
So FRC is needed in my case and the dual channel should guarantee a way lower drift compared to the single channel S8. A calibration once a year should be sufficient, as a drift of around 50 ppm per year is expected. Basically the calibration is needed to set it up in its end location and after transport / possible mechanical stress to the device.

TD-er wrote: ↑11 Jan 2024, 08:23But when it comes to accuracy of CO2 measurements, I doubt the SCD30's will be an improvement.

Basically I agree. The S8 is a very good sensor. But having 4 of them in use for 2 years now, I see they are drifting sometimes- up to obvious nonsense results - in our environment.
The two channel principle makes totally sense to me, to have a internally self adjusting sensor with a defined reference channel/chamber - which is giving me indeed more precise results over a way longer period of time.
Here is a nice article, explaining it.

But coming back to my question:

localhorst wrote: ↑11 Jan 2024, 00:10 Do you think the SCD30 internal sensors for temperature and humidity could replace the BMP280 and SHT21? As far as I've read it, the SCD30 sensors should be fairly precise.

Reading the specifications of the SCD30, the build in temperature and humidity sensors seem to be quite precise. Of course compensation would need to be done.

Sorry you're right, I didn't google it but just assumed it was one of those newer MEMS units.
The SCD30 is really not small.