P135; SCD4x Pugin doesn't seem to save the settings
Sminter4 opened this issue · 10 comments
I like to use the SCD40 module for my CO2 measurements.
I created a custom build for this purpose. With the following settings in “Custom.h”:
#define USES_P135 // SCD4x
#define P135_FEATURE_RESET_COMMANDS 1 // Enable/Disable quite spacious (~950 bytes) 'selftest' and 'factoryreset' subcommands
Build: ESP_Easy_mega_20240225_custom_312_ESP8266_4M1M Feb 25 2024
On the configuration page there are values that are obviously not saved. This includes:
altitude; Temp offset; Automatic self-calibration
The check marks in the GUI are still set, but when I read the values using a command, all values are "0".
In my case, for example, this is "let,76,[SCD40#SerialNumber]"
[#GetAltitude]
[#GetTempOffset]
[#SerialNumber]
[#GetSelfCalibration]
https://espeasy.readthedocs.io/en/latest/Plugin/P135.html
Is it wanted like that?
[#GetAltitude]
[#GetTempOffset]
[#SerialNumber]
[#GetSelfCalibration]
These should use the task name before the #
Like if you named the task "SCD40":
[SCD40#GetAltitude]
[SCD40#GetTempOffset]
[SCD40#SerialNumber]
[SCD40#GetSelfCalibration]
Also I wonder why you're building "custom_312_ESP8266" and not the one at the top of the list?
"312" is using the latest Arduino code base and "274" is using version 2.7.4, which is still the better choice at this moment as it uses less memory and there are still some other quirks with the latest SDK version for ESP8266.
I don't really get what you mean by settings not being saved.
The title of this issue seems clear enough, but I can't really imagine what isn't being saved as this plugin mainly uses the standard save functions and thus other plugins/tasks should see the same issue.
Maybe I expressed myself misleadingly.
The settings on the plugin GUI cannot be read using commands.
The missing part was a copy and paste error. Of course I wrote the commands like this:
[SCD40#GetAltitude]
[SCD40#GetTempOffset]
[SCD40#GetSelfCalibration]
(Thanks for the tip about the Arduino version. That wasn't clear to me. I recreated the build. This time with the 274. Unfortunately, my Wemos D1 mini always keeps the 312 version. But that seems to be another error.. .)
When your ESP doesn't succesfully update the new build, you can try to disable some tasks and try to update again via the web interface.
When just giving the command taskdisable,N with N being the taskindex, it will only be disabled in memory and thus be re-enabled after a reboot. (when you do some kind of save, the disabled state will be saved of course)
Calibrating the sensor is an exceptional procedure, that should not be needed to do if you have a new sensor. That's why by default that feature is not included in the build.
More importantly, do the regular output values of the sensor give an expected result?
For any of this to work, the sensor has to be connected and (the task) enabled.
Maybe it's a better plan to install the Climate or the Collection E build on your Wemos, that's pre-built, and known to work.
The tip helped. By deactivating the plugins, I was able to successfully load the 274 version.
However, this build is unstable. Now when I load bmp photos onto my ST7735, the Wemos d1 mini crashes.
Then I loaded the 312 version again. This does not crash when loading photos.
Both versions behave the same when reading out the values for the SCD40. The result is always "0".
[SCD40#GetAltitude]
[SCD40#GetTempOffset]
[SCD40#GetSelfCalibration]
Only reading out the serial number works.
[SCD40#SerialNumber]
Loading the Collection E version doesn't help me. Otherwise I can no longer use the ST7735...
At least you can try to see if the plugin behaves differently.
Another thing to check is to see if the unit maybe crashing when you try to save the settings?
Display plugins tend to use quite a lot of RAM as does saving settings.
If you somehow run out of memory, the ESP may crash before the settings are saved.
Another thing you can try is to disable the display task and then try to save the settings.
I have been looking at the source code of this plugin, and I think it is also fixed in the upcoming build (now building)
I forgot to ask you for testing before triggering the new build. :(
Can you test if it has now been fixed?
The latest code currently in the mega branch is what is now being used to make the new "March" build.
@Sminter4 I finally identified the bug, and fixed it. Can you test using this GH Actions run build, and report your findings?
(Changed link because of an uncaught typo in the code)