Get internal temperature sensor value with EspEasy

Message

bo2be · #1 Post by **bo2be** » 21 Sep 2023, 14:57

Pardon me if I miss the solution in the docs, but is there a command or a dummy sensor to get the internal temperature sensor value of an ESP32 with EspEasy?
Especially with ESP32-S2 or ESP32-C3.
https://docs.espressif.com/projects/esp ... ensor.html

Ath · #2 Post by **Ath** » 21 Sep 2023, 15:14

There is currently no plugin to read the internal ESP temperature. I'm not really sure why that would be needed, other than to see if it is overheating for some reason, but then, what would be the measure to resolve that?
I've been 'monitoring' the internal temperature of my RPi for years, but that graph is quite useless, as it nearly a flat-line. I'd expect that to be nearly the same for an ESP.

NB: It is also available on the ESP32-S3.

TD-er · #3 Post by **TD-er** » 21 Sep 2023, 16:13

Hmm I'm sure I had it once added to the 'sysinfo' plugin.
Apparently not.
And I can't remember why I had not pushed it or decided to remove it again.

bo2be · #4 Post by **bo2be** » 23 Sep 2023, 10:40

So DT-er, if you have the opportunity to reactivate it, but only if it is easy.

TD-er · #5 Post by **TD-er** » 23 Sep 2023, 12:31

I will look into this for a short while, mainly to see why I decided to later not included it in the main branch.

I know support for either one of the internal temp sensor or the Hall Effect sensor (which is supported in the internal analog plugin) will be removed in the new upcoming ESP IDF.
So if it is the internal temp sensor, then I will not add it to ESPEasy for obvious reasons.

TD-er · #6 Post by **TD-er** » 23 Sep 2023, 13:06

Looks like they added support for it on the newer ESP32 revisions, so it looks like it will be there for a while.

Added an issue for it.
https://github.com/letscontrolit/ESPEasy/issues/4817

Not sure about the ESP32 classic as that one doesn't seem to have a temperature sensor according to the Espressif documentation, but I'm rather sure it is present.
See: https://docs.espressif.com/projects/esp ... rison.html

bo2be · #7 Post by **bo2be** » 23 Sep 2023, 17:29

TD-er wrote: ↑23 Sep 2023, 12:31 I will look into this for a short while, mainly to see why I decided to later not included it in the main branch.

I know support for either one of the internal temp sensor or the Hall Effect sensor (which is supported in the internal analog plugin) will be removed in the new upcoming ESP IDF.
So if it is the internal temp sensor, then I will not add it to ESPEasy for obvious reasons.

Never mind, thanks for the search.

Ath · #8 Post by **Ath** » 23 Sep 2023, 22:13

I've added PR #4820 that includes support for the internal temperature sensor of the ESP32 MCUs. You can download a build (see below), for testing.
Please report your findings here on in the Github issue or pull request threads.

Ath · #9 Post by **Ath** » 24 Sep 2023, 09:48

I've applied a few fixes, see below.

bo2be · #10 Post by **bo2be** » 24 Sep 2023, 19:11

Got it for S2!
Temp fluctuates from 39°C to 44°C with 3 seconds between measures.
I will smooth with a Let,1,0.02*[intern#internaltemp]+0.98*[var#1]
to see if I can correlate with the environmental temp variations.
News next days.
Thanks for test release.

Ath · #11 Post by **Ath** » 24 Sep 2023, 20:22

Well, there can be several reasons the temperature is fluctuating, as it is internal to the chip, and depending on the instructions executed more or less heat will be produced.
That's why I asked what it would be used for, as there isn't much you can do about the temperature, only register it. It won't help in heating your room

. And also, the original ESP32 doesn't even have a real temperature sensor on board, so as a surrogate the temperature is determined from the frequency drift of an internal oscillator, by comparing it to the crystal frequency. That's rather error-prone. For the other processors, there is some compensation applied to the reading from the temp. sensor by the library functions, provided by Espressif, so a somewhat realistic value will be shown.

TD-er · #12 Post by **TD-er** » 24 Sep 2023, 20:36

If you filter it with that IIR filter as posted, it might be somewhat useful as it will like an average over quite a lot of samples.

bo2be · #13 Post by **bo2be** » 25 Sep 2023, 16:59

Not yet the Graal
I will retest with more filtering
expected curve :

: Temp reference 2023-09-25.png (83.4 KiB) Viewed 12998 times

Current S2 record

: Temp S2 2023-09-25.png (91.8 KiB) Viewed 12998 times

New results expected.

TD-er · #14 Post by **TD-er** » 25 Sep 2023, 17:55

Not sure what you mean by this 'expected curve' as it is the internal chip temperature of the ESP.
The ESP is in an enclosed space so there will probably be a somewhat constant temperature offset between the chip temperature and the environment.
Given the rather poor heat exchange of the ESP, I will not be surprised if this is about 20C higher than the environment temperature.

In your "expected curve" chart, there is a rather linear trend from 19C @20h to 17C @08h. Past 08h the temperature seems to rise a bit more.
There are some similar trends visible in the "TempS2-163" chart. But they are too noisy to clearly see.
However the trend doesn't seem to go 2 degree C down in the same time frame.

But since it is the internal temperature sensor of the chip, it should not be used to measure room temperature.
I think there are very few practical use cases of this sensor.
One may be to measure temperature immediately when waking from deep sleep and the other is to get some very rough idea whether an enclosure may need some extra ventilation as 10 degree C error may still be "good enough".

bo2be · #15 Post by **bo2be** » 25 Sep 2023, 18:35

You are right for the temperature shift due to the internal heating and the surround air speed creates an additional factor. I was more interested with the variations of temperature rather than the absolute value. More, your explanation for the way the internal temperature measurement is built is also a difficulty to expect a good accuracy. I agree for the idea of measuring just after a wake up of the Esp in order to decrease the gap between environmental temp an internal temp but this forbids multiples measures to get an average value.
I do not want to oversized the importance of this topic even if I do some rough tests for the fun.

: ESP32-S2 internal temp test.jpg (56.28 KiB) Viewed 12992 times

TD-er · #16 Post by **TD-er** » 25 Sep 2023, 18:55

Maybe you can add some metal clamp to the ESP chip so you can create a thermal coupling between the 18B20 and the ESP.

bo2be · #17 Post by **bo2be** » 25 Sep 2023, 21:42

For this night, I prefer a separate measure in order to not influence the 18B20 with the Esp heat. Tomorrow, if I find the time, I'll try to glue a other 18B20 at his back side.
I take also this opportunity to add a second Esp32-S2 in the neighborhood, to see the difference in the internal temperature value.
I risk to be short of time for the next 3 days. To be continued

TD-er · #18 Post by **TD-er** » 25 Sep 2023, 21:44

Or... just skip sleep, that will give you a few extra hours per day

Ath · #19 Post by **Ath** » 26 Sep 2023, 08:43

Fixed the temperature of ESP32 (Classic) to often show 0 Kelvin. Now it will do a retry on the measurement, and if it still fails, return the previously measured value. Also for ESP32 Classic it will run a measurement every second, to increase the chance of a successful measurement, or at least to have the most recent successfully read temperature.
Download from this GH Actions run

bo2be · #20 Post by **bo2be** » 26 Sep 2023, 10:09

I also formerly tried to get an internal temperature value every second and encountered skipped values.
So, I do measure every 2 seconds now.
For the last night run of measures, an other issue occurred with the strong filter. There was some random "jumps" on the curve perhaps not related to the internal temperature measurement. I need to fix this point.
D18B20 curve:

: D18B20 2023-09-26 08-57-14.png (74.87 KiB) Viewed 12937 times

Strong filter is applied on Internal temperature values. Notice that the internal temp value is shifted down with -22°C before sending to Domoticz.

Code: Select all

On ITemp204#internaltemp do
 Let,1,0.001*[ITemp204#internaltemp]+0.999*[var#1]
 TaskValueSet,2,1,[VAR#1]-22
endon

Two Esp32S2 are tested

: Esp32S2internalTempTest.jpg (70.18 KiB) Viewed 12937 times

First ESP internal temp recording

: S2-T163 Internal 2023-09-26 08-59-16.png (81.54 KiB) Viewed 12937 times

Second Esp

: S2-T204 Internal 2023-09-26 09-00-25.png (83.77 KiB) Viewed 12937 times

I need to fix this issue before further useful measures.

TD-er · #21 Post by **TD-er** » 26 Sep 2023, 13:42

At least try to use the build linked by Ton as that will probably also help in getting a more stable reading.
I don't trust those sudden jumps in your chart when using such a 'strong' IIR filter.

bo2be · #22 Post by **bo2be** » 26 Sep 2023, 18:20

I downloaded the build linked by Ton (Thanks to him) and load it on My EspS2 n° 204.
Let see the behavior.
On both I added some rules to record the 4 highest values and the 4 lower ones. In addition, I added a counter of repeated values.
To be continued.

Ath · #23 Post by **Ath** » 26 Sep 2023, 20:58

The pull request has been merged, and will be included in the next release of ESPEasy, that's planned for later this week, assuming we don't find any major/blocking issues.

Testers are always welcome to help, and report any findings, a Github issue has been opened for that, over here: #4825

bo2be · #24 Post by **bo2be** » 28 Sep 2023, 07:33

Good news. We will surely find a useful application to that.
My former tests were not significant.
I am launching new ones using the logs in order to record values every 2 seconds via a rsyslog server.
First preliminary results show that the internal temperature request seems to be stable at +/- 5°C. But my numerical filtering with

Code: Select all

Let,1,0.001*[ITemp204#internaltemp]+0.999*[var#1]

sometimes gives bad results.
More details tomorrow.

bo2be · #25 Post by **bo2be** » 29 Sep 2023, 09:19

Tests are in progress.
Pb of random jumps in the filtered curve.
Jumps in the curve are not directly related to the level of filtering 'test with 3 values without change).
The Esp reboots randomly after between 2 minutes and one hour. The Main menu Uptime confirms these reboots.

Up to now, I don-t know the reasons for these reboots.
The two releases have the same behavior.
ESP_Easy_mega_20230923_normal_ESP32s2_4M316k_CDC.bin
ESP_Easy_mega_20230925_normal_ESP32s2_4M316k_CDC.bin
Same behavior on my ESP32-S2 n° 163 and N° 204.Each ESP is powered with a different power supply.

New tests to try to find factors which could be related to these reboots.
ESP32-S2 n° 163, N° 204 and N° 207.
Release :
ESP_Easy_mega_20230925_normal_ESP32s2_4M316k_CDC.bin
Rules :

Code: Select all

On System#Boot do
   Let,3,0  
Endon

On Compteur#NbSec do
 Let,3,[var#3]+2
 logentry,204¤[var#3]
Endon

The logentry is used to load a log file via Rsyslog.

Devices :
ESP32-S2 n° 163 : No internal temperature measure
ESP32-S2 n° 204 : With internal temperature measure
ESP32-S2 n° 207 : With WIFI power measure

Some former tests this night have shown the possibility of 12h of stability but conditions were not similar, so I need to review tests.
Let see in some hours.

TD-er · #26 Post by **TD-er** » 29 Sep 2023, 09:29

The sysinfo page will show you what was the last scheduled thing to do before the reboot and the reboot reason.

Such reboots are absolutely not normal.

I have only one unit here which had a crash right before the last boot:

Boot: Exception (2)
Reset Reason: Exception
Last Action before Reboot: PLUGIN_READ: timer, id: 2

So you need to look for something like this on the sysinfo page (top section)

N.B. that crash of that specific node (a Sonoff S20) was when I had plugged in a vacuum cleaner in the Sonoff and didn't want to unplug it as it had already 200 days uptime... So it was probably some current/voltage spike when turning off the vacuum cleaner.
Now it has 90 days uptime.

bo2be · #27 Post by **bo2be** » 29 Sep 2023, 15:41

Sorry I see your message only now and I have reboot after changing test conditions half an hour ago. I did it because no reboot occurs after 5.5 hours.
Now the rules make filtering calculation in order to try to reproduce the random reboot.

Code: Select all

On System#Boot do
   Let,3,0  
   Let,1,0
Endon

On Compteur#NbSec do
 Let,1,0.01*[ITemp204#It]+0.99*[var#1]
 TaskValueSet,2,1,[VAR#1]-22
 Let,3,[var#3]+2
 logentry,204¤[var#3]¤[var#1]
Endon

TD-er · #28 Post by **TD-er** » 29 Sep 2023, 15:47

That logentry command seems to be using unicode characters, or at least not the default 7-bit ASCII.
That's never been tested.

chromo23 · #29 Post by **chromo23** » 29 Sep 2023, 15:53

TD-er wrote: ↑29 Sep 2023, 15:47 That logentry command seems to be using unicode characters, or at least not the default 7-bit ASCII.
That's never been tested.

Well, i use unicode characters as devices/value names and in rules for quiet some time now. I surprisingly never had any issues...

bo2be · #30 Post by **bo2be** » 29 Sep 2023, 15:58

The 3 Esp are in the same condition
After 836 seconds n°207 rebooted. Sysinfo page, top section indicates:

Time Source: ESPEasy p2p (163)
Time Wander: 0.0 [ppm]
Uptime: 0 days 0 hours 22 minutes
Load: 22.84% (LC=7105)
CPU Eco Mode: false
Boot: Soft Reboot (25)
Reset Reason: CPU0: Software reset digital core
Last Action before Reboot: PLUGIN_READ: Task ITemp207
SW WD count: 0

ITemp207 is related to device 1

: ITemp207 2023-09-29 15-50-47.png (30.34 KiB) Viewed 12732 times

A new reboot occurs 1742 seconds after

System Info
Unit Number: 207
Local Time: 2023-09-29 13:53:04
Time Source: ESPEasy p2p (163)
Time Wander: 0.0 [ppm]
Uptime: 0 days 0 hours 5 minutes
Load: 23.77% (LC=5497)
CPU Eco Mode: false
Boot: Soft Reboot (26)
Reset Reason: CPU0: Software reset digital core
Last Action before Reboot: PLUGIN_READ: Task ITemp207
SW WD count: 0

The 2 other ESP are stable after more than 3000 seconds.
To be continued.

TD-er · #31 Post by **TD-er** » 29 Sep 2023, 16:00

ESPEasy doesn't do anything with Unicode.
We're not using std::wstring or wchar_t.

So as long as there isn't a byte with 0 as value, it is just dealt with as if it is a character.
However, it has not been tested (by me) and I can think of some numerical parsing which may perhaps cause issues when processing unicode data.

But when ESPEasy units are crashing, checking for non-ASCII characters would be one of my first things to look for.

TD-er · #32 Post by **TD-er** » 29 Sep 2023, 16:03

Both crashing units are ESP32-S2?

TD-er · #33 Post by **TD-er** » 29 Sep 2023, 16:32

Looking at the code of the ESP-IDF, I found a bug in there.

https://github.com/espressif/esp-idf/bl ... mpsensor.c

temp_sensor_get_config() always returns ESP_OK.
Even when REGI2C_READ_MASK may return a bogus value.
This may cause tsens->dac_offset to be outside the range of 0...TSENS_DAC_MAX.
Since this offset value is directly used to index an array, you may get a crash when used like that.

So I guess we should make a work-around for the temp_sensor_read_celsius() function as that one is clearly buggy in the ESP_IDF code.

TD-er · #34 Post by **TD-er** » 29 Sep 2023, 21:11

Working on some fixes for the temp sensor and also made a few tweaks

Sample interval is 1 sec and you can see the interval of some tasks...

Or when ECO mode was enabled:

This kinda makes it even a usable sensor

TD-er · #35 Post by **TD-er** » 29 Sep 2023, 21:54

bo2be wrote: ↑29 Sep 2023, 15:41 Sorry I see your message only now and I have reboot after changing test conditions half an hour ago. I did it because no reboot occurs after 5.5 hours.
Now the rules make filtering calculation in order to try to reproduce the random reboot.
[...]

Can you please let your nodes run this build over night to see if it is now stable?
https://github.com/letscontrolit/ESPEas ... 6356259841

You also no longer need to filter yourself to get nice usable charts.

See: https://github.com/letscontrolit/ESPEasy/pull/4834

bo2be · #36 Post by **bo2be** » 30 Sep 2023, 09:25

TD-er wrote: ↑29 Sep 2023, 16:03 Both crashing units are ESP32-S2?

Yes, up to now, I test only ESP32-S2 (n°163, 204, 207)
My ESP32-C3 is still in procurement.

bo2be · #37 Post by **bo2be** » 30 Sep 2023, 09:28

TD-er wrote: ↑29 Sep 2023, 21:54 Can you please let your nodes run this build over night to see if it is now stable?
https://github.com/letscontrolit/ESPEas ... 6356259841

I am downloading it an will test it

bo2be · #38 Post by **bo2be** » 30 Sep 2023, 14:21

Mid day results:

ESP32S2n°207
Release of the 29th:
https://github.com/letscontrolit/ESPEas ... 6356259841
Tasks
- measuring Internal temperature every 2 seconds
- Count the nb of seconds for logs
Rules without filter:

Code: Select all

On System#Boot do
   Let,3,0   // compteur seconds
Endon
On ITemp207#It do
 TaskValueSet,2,1,[ITemp207#It]
 Let,3,[var#3]+2 // compteur seconds
 logentry,207¤[var#3]¤[var#1]
Endon

RESULTS n°207: 1 reboot after 842 seconds and no reboot since 13830 seconds.
Unit Number: 207
Local Time: 2023-09-30 11:53:07
Time Source: ESPEasy p2p (163)
Time Wander: -83.3 [ppm]
Uptime: 0 days 3 hours 52 minutes
Load: 100.00% (LC=9)
CPU Eco Mode: false
Boot: Soft Reboot (64)
Reset Reason: CPU0: Software reset digital core
Last Action before Reboot: PLUGIN_READ: Task ITemp207
SW WD count: 0

ESP32S2n°204
Release of the 29th:
https://github.com/letscontrolit/ESPEas ... 6356259841
Tasks
- measuring Internal temperature every 2 seconds
- Filtering (to be similar with the former release)
- Count the nb of seconds for logs
Rules without filter:

Code: Select all

On System#Boot do
   Let,3,0  
   Let,1,0
Endon

On ITemp204#It do
 Let,1,0.01*[ITemp204#It]+0.99*[var#1]  // filtering
 TaskValueSet,2,1,[VAR#1] // for Domoticz 
 Let,3,[var#3]+2 //nb of seconds
 logentry,204¤[var#3]¤[var#1]¤[ITemp204#It]  //For logs Rsyslog
Endon

RESULTS n°204: 1 reboot after 9850 seconds and no reboot since 3600 seconds.
Notice the contact loss during more than half an hour.

Sep 30 12:35:15 e204.home E204-204_EspEasy: ACT : logentry,204 9848 43.964701194099 43.46
Sep 30 12:35:15 e204.home E204-204_EspEasy: ACT : logentry,204 9850 43.959654182158 43.46
Sep 30 13:08:11 e204.home E204-204_EspEasy: ACT : logentry,204 4 0.811551 41.07
Sep 30 13:08:14 e204.home E204-204_EspEasy: ACT : logentry,204 6 1.21833549 41.49

Interesting also to compare the behavior between the former release and the last one.
Each jump corresponds with a reboot.
Former release (lot of reboots)

: ESP 204 former release 2023-09-30 14-11-00.png (89.48 KiB) Viewed 12647 times

Last release (only one reboot)

: Esp 204 last release 2023-09-30 14-12-21.png (70.12 KiB) Viewed 12647 times

Next time, (I m short of time) I 'll detail ESP32-S2 n°163 which runs with the former release but I change the rules to limit at only one request to measure the internal temperature per cycle of 2 seconds. The number of reboots decrease to only one, similar to ESP32S2 n° 204 with the new release.
No simple...

TD-er · #39 Post by **TD-er** » 30 Sep 2023, 15:28

OK, so the issue caused by the temperature reading is now solved.
It is really hard to tell what may have caused those reboots, so I will not make that a breaking issue to halt making a new build.

bo2be · #40 Post by **bo2be** » 30 Sep 2023, 16:20

I totally agree with you and the number of users who will measure this parameter so intensively is to be considered extremely rare.
News about tests
ESP32S2n°207 : No reboot since 11h.
ESP32S2n°204 : No reboot since 12h30.
ESP32S2n°163 : No reboot since 12h30 (old release).
I kept the old release in test to try to see the influence of the rules:
ESP_Easy_mega_20230925_normal_ESP32s2_4M316k_CDC

With several calls in the rules

: ESP32S2-163 old release.png (85.17 KiB) Viewed 12634 times

With less calls same release
I put the internal value in the VAR#99

: ESP32S2-163 old release less measure call.png (73.71 KiB) Viewed 12634 times

An other strange thing, as I am currently writing this post, I frequently switch to the web window of my ESP32S2 n°163 and suddenly I loose contact. Then I try to see the window of my ESP32S2 n°204, it bugs also! n°207 is still running. It happened the same thing at 12h30 and this corresponded to the reboot of these two units.
Now, 163 is restarting
Unit Number: 163
Local Time: 2023-09-30 13:58:16
Time Source: ESPEasy p2p (171)
Time Wander: 0.0 [ppm]
Uptime: 0 days 0 hours 6 minutes
Load: 100.00% (LC=5)
CPU Eco Mode: false
Boot: Soft Reboot (299)
Reset Reason: CPU0: Software reset digital core
Last Action before Reboot: PLUGIN_READ: Task ITemp163
SW WD count: 0

Unit Number: 204 is still unreachable.
Before this crash I notice the n° 204 Time Source: ESPEasy p2p (163)

I definitely update the release to the last one
And I will parameter a NTP server. and reboot all units.

TD-er · #41 Post by **TD-er** » 30 Sep 2023, 17:52

Sometimes an access point may also decide to force nodes to disconnect.
This can be for various reasons.
But on modern access points the most common reason is due to "band steering".
Or in other words it will tell a client to disconnect so it might reconnect to 5 GHz band or in case of a WiFi mesh network to offload to another AP.

When forcing to only connect using 802.11g instead of 802.11n, you will no longer receive those "band steering" disconnects.

On all generations of access points one may also get disconnected when the AP isn't set to a fixed WiFi channel.
When set to auto channel, an access point may periodically scan for less occupied channels.
It depends on exactly when the client tries to talk to the AP whether it may actually get disconnected.

On the Tools->Advanced page at the bottom, there is a checkbox to allow for quick reconnects, which is essentially for these kinds of disconnects.

bo2be · #42 Post by **bo2be** » 30 Sep 2023, 18:54

TD-er wrote: ↑30 Sep 2023, 17:52 On the Tools->Advanced page at the bottom, there is a checkbox to allow for quick reconnects, which is essentially for these kinds of disconnects.

Thanks for the advice.

I gess this is the box named:
Restart WiFi Lost Conn:

TD-er · #43 Post by **TD-er** » 30 Sep 2023, 20:39

Nope, I meant these 2: https://espeasy.readthedocs.io/en/lates ... fi-connect

And I had another look at the ESP-IDF 4.4.x code for ESP32-S2 and no wonder it crashes due to WatchDog reset.
This code is just plain wrong.
So I have to look at the ESP-IDF 5.x code to see if it has been fixed there.
Or else I have to submit a few bug fixes to Espressif.

What's wrong is that they use semaphores with a timeout.
However they never check to see if the take request was successful.
And the next statement is to wait in a while loop till the sensor is ready.
However when the semaphore was locked, this probably means the internal temp sensor was also read from some other call and after a read the ready flag is reset.
So the ready flag will never ever be set to 1 again in that while loop and thus the board resets.

bo2be · #44 Post by **bo2be** » 01 Oct 2023, 11:59

Thanks for the analysis.
I confirm the resets on ESP32S2.
I am still running some tests to see if there is a difference between two Esp or if the call is frequent or less frequent.
E.g. my n° 207 is particularly stable.

bo2be · #45 Post by **bo2be** » 18 Oct 2023, 18:22

Hello everybody,
Just some results to confirm that internal measure with ESP32s2 leads random reset of the module. In the meantime I received an ESP32c3 which doesn't show this issue even after 2 days of continuous working with the same conditions.

3 ESP32s2 were tested with one internal temperature measure every 5 seconds and a counter is increased. Note that in the following curves it is the counter result and not the temperature which is showed.

The saw teeth shape of below curves reveals the random reboot frequency of the module.

: 163 2023-10-05 08-31-16.png (72.23 KiB) Viewed 12192 times

: 204 2023-10-05 08-32-09.png (76.39 KiB) Viewed 12192 times

: 207 2023-10-05 08-32-46.png (82.93 KiB) Viewed 12192 times

A new flash with the mega-20231013 release doesn't change the behavior.

: Esp32s2-163 2023-10-18 18-09-59.png (189.86 KiB) Viewed 12192 times

Same test with an ESP32c3 is correctly working.

: Esp32C3-208 2023-10-18 18-08-51.png (65.07 KiB) Viewed 12192 times

The wifi reception level of the ESP32c3 is even better than the ESP32s2!

Perhaps Expressif will update its ESP32s2 ESP-IDF. Awaiting this update, I will use the ESP32c3. Thank TD-er for the module advice.

TD-er · #46 Post by **TD-er** » 18 Oct 2023, 18:36

There is a clear bug in the ESP-IDF 4.x code related to the temp sensor for ESP32-S2.
And since they're now moving towards IDF 5.1, I don't think they will ever fix this bug for IDF 4.x
I'm hard at work implementing support for IDF 5.1, which is a lot of work as a lot has changed. (complete project re-structure)
But right now, I've most working and I will also look into the internal temp sensor implementation and if this bug is still present, I will file a report to the Espressif team working on IDF.

TD-er · #47 Post by **TD-er** » 19 Oct 2023, 08:32

I have an ESP32, ESP32-S2 and ES32-C3 running with ESP-IDF 5.1 and temperature sensor support since I implemented it (9 hours ago...) and they are all running fine without any reboot so far.
So if they cross the 24h mark (and I don't make any mistake which may trigger a reboot on the S2 as it is connected to an USB port on my PC), then I guess that can be considered 'stable' on the IDF 5.1 branch.

Have to think what to do with internal temperature sensor support on IDF < 5 for the S2.
I think I will disable it there, or add a big warning in the docs to only use it as an internal variable (less calls, less likely to run into a deadlock while acquiring a mutex lock which is the bug in the old IDF code for the S2)

bo2be · #48 Post by **bo2be** » 19 Oct 2023, 10:41

Hello TD-er. Thanks for the answer and I agree that the use of this sensor is very limited. Your choice will be the best and if you add a warning you can always mention the advice to use a C3 type or other.

TD-er · #49 Post by **TD-er** » 19 Oct 2023, 11:16

Well the sensors do seem to be useful afterall, now that I have implemented some filtering and error checking.
The sensors in the S2 and C3 do seem to be quite accurate also as I could "cool" them with my thumb and after a while the reported temperatures were just about the same as my body temperature. (checked with a personal IR temperature device on my thumb)
So it can be useful to keep track of how hot it gets inside some enclosure.

TD-er · #50 Post by **TD-er** » 22 Oct 2023, 17:09

I had to reboot that S2 board once while it was running for about 24h and now it is running for 3 days 4h 30 mins, so I guess the temp sensor on S2 while running IDF 5.1 is running stable.

Who is online