As mentioned above, raw_temperature is only available when CONFIG_IDF_TARGET_ESP32 is defined. You are defining CONFIG_IDF_TARGET_ESP32S3 which is not the same thing. I guess you are using an ESP32S3 and not an ESP32. See here.

@fivdi Yes I am using a esp32s3, however esp32s3 also has a raw temp sensor, so it should be available for it too

For me most of ESP32S3 have no more internal sensor temperature (it's a long history..) Espressif maintain the library because for some production they active it.. Try in C you will see if it's active or not ...

sens_reg.h is in esp32s3 dir in idf 5.0.2
(components\soc)
but as I tell you on my previous post test before on pure C with arduino IDE ...

I modified esp32mod.c and got a initial read of the internal temperature using the v5 API ...
https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-reference/peripherals/temp_sensor.html#:~:text=The%20ESP32%2DC3%20has%20a,compensate%20for%20the%20temperature%20measurement.
After the conditional compile option for the esp32 (circa line 172) I added a brute force copy from the ESP-IDF example:

#if CONFIG_IDF_TARGET_ESP32C3
#include "driver/temperature_sensor.h"
STATIC mp_obj_t esp32_raw_temperature(void) {
  temperature_sensor_config_t temp_sensor_config = TEMPERATURE_SENSOR_CONFIG_DEFAULT(10,50);
  temperature_sensor_handle_t temp_sensor=NULL;
  temperature_sensor_install(&temp_sensor_config, &temp_sensor);
  temperature_sensor_enable(temp_sensor);
  float tvalue;
  temperature_sensor_get_celsius(temp_sensor, &tvalue);
  temperature_sensor_disable(temp_sensor);
  temperature_sensor_uninstall(temp_sensor);
  return mp_obj_new_int((int)(tvalue+0.5));
}
STATIC MP_DEFINE_CONST_FUN_OBJ_0(esp32_raw_temperature_obj, esp32_raw_temperature);

#endif

Then one needs to add this definition for the esp32 module actions after the ESP32 definition (after oriiginal line 205):

    #if CONFIG_IDF_TARGET_ESP32C3
    { MP_ROM_QSTR(MP_QSTR_raw_temperature), MP_ROM_PTR(&esp32_raw_temperature_obj) },
    #endif

This seemed to work for my ESP32C3 (SEEED XIAO) - but I have not tested this thoroughly yet. I also wonder if this fix will work with any ESP32 board- the API seems general for all.

Caveats:

• Hacky read of float then convert to int ...
• I wonder if there is a more direct sensor read option? (Remember- the 32C is a RISC-V processor not eXtensa as the other variants)
• installation could be supported directly, instead of every call install/enable/read/disable/uninstall.
• no error handling in this demonstration

Many thanks @ricksorensen I will look at that but don't forget that Espressif enable/ disable these internal sensors at the line production... What about to put a simple dht11 outside that cost nothing !..

The internal temperature sensor is not really useful to tell the ESP32-outside temperature. Even with external sensors you have to take into account, that reading the value too frequent may heat up the sensor.

You could try to install& enable the sensor only once at the first call and keep it installed and enabled after that.
About the value: Which value did you expect? The sensor tells the internal temperature of the ESP32 chip, which is always higher than the temperature of the environment. For the internal temperature of the ESP32 39°C seems reasonable.

Yes. It could be a separate call. I also tried to just run install once and keep enable/disable. But that did not work.

Current consumption before call to esp32.raw_temperature(): 13 - 14mA
Current consumption after call to esp32.raw_temperature(): 15mA
After starting WIFi: avg. 25mA.

Side note: It's winter here. I can cool down the MCU with my finger from 33°C to 30°C.

Tried again including enable/disable. Now it works, and the current consumption stays low. Changed code:

#if CONFIG_IDF_TARGET_ESP32C3
#include "driver/temperature_sensor.h"

STATIC mp_obj_t esp32_raw_temperature(void) {
    static temperature_sensor_handle_t temp_sensor = NULL;
    if (temp_sensor == NULL) {
        temperature_sensor_config_t temp_sensor_config = TEMPERATURE_SENSOR_CONFIG_DEFAULT(20, 100);
        ESP_ERROR_CHECK(temperature_sensor_install(&temp_sensor_config, &temp_sensor));
    }
    ESP_ERROR_CHECK(temperature_sensor_enable(temp_sensor));
    float tvalue;
    ESP_ERROR_CHECK(temperature_sensor_get_celsius(temp_sensor, &tvalue));
    ESP_ERROR_CHECK(temperature_sensor_disable(temp_sensor));
    return mp_obj_new_int((int)(tvalue+0.5));
}
STATIC MP_DEFINE_CONST_FUN_OBJ_0(esp32_raw_temperature_obj, esp32_raw_temperature);

#endif

I tried to return a float instead of the int, but that's not worth the effort. Testing it, the digit behind the dot was always 7. The test result above had a constant .2 for the values. The only addition to the function could be adding an optional argument(s) for the range.

27.7
27.7
28.7
28.7
25.7
23.7
22.7
21.7
21.7
21.7
21.7
21.7
21.7
21.7
22.7
22.7
23.7
23.7
23.7
23.7
24.7
24.7
24.7
25.7
25.7
25.7

Adding optional arguments to set the range's min and max, the code would look like:

STATIC mp_obj_t esp32_raw_temperature(size_t n_args, const mp_obj_t *args) {
    static temperature_sensor_handle_t temp_sensor = NULL;
    if (temp_sensor == NULL) {
        temperature_sensor_config_t temp_sensor_config = TEMPERATURE_SENSOR_CONFIG_DEFAULT(20, 100);
        if (n_args > 0) {
            temp_sensor_config.range_min = mp_obj_get_int(args[0]);
        }
        if (n_args > 1) {
            temp_sensor_config.range_max = mp_obj_get_int(args[1]);
        }
        ESP_ERROR_CHECK(temperature_sensor_install(&temp_sensor_config, &temp_sensor));
    }
    ESP_ERROR_CHECK(temperature_sensor_enable(temp_sensor));
    float tvalue;
    ESP_ERROR_CHECK(temperature_sensor_get_celsius(temp_sensor, &tvalue));
    ESP_ERROR_CHECK(temperature_sensor_disable(temp_sensor));
    return mp_obj_new_float((mp_float_t)tvalue);
}
STATIC MP_DEFINE_CONST_FUN_OBJ_VAR_BETWEEN(esp32_raw_temperature_obj, 0, 2, esp32_raw_temperature);

The settings would be effective only on the first call to raw_temperature. In my tests, it did not make any difference which range was chosen. Even setting min larger than max did not make a difference.

Scanning through the esp source code, setting the range is waste of code, since it will be adapted automatically depending on the actual value.

I cannot replicate that behavior here. The first value is always reasonable. Since you use Thonny, please try the same without Thonny using a simple reliable terminal emulator like Putty and paste the above code to REPL with the sequence:

Ctrl-E

Ctrl-D

You could as well upload that test code as a script to the board and run from REPL using e.g. Putty:

import <test_scrip>

Update: I can replicate that behavior by adding a call to temperature_sensor_uninstall(temp_sensor) to be executed on soft reset. Then I get a sequence of falling temp values until it reaches a certain level. That does not happen after a power cycle, hard reset or machine.reset() call. This sequence does not depend on the waiting time after soft reset. And it does definitely not reflect the real temperature of the device. So maybe a bug in the idf.

60
41
39
37
36
35
35
34
33
33

Clearing a static symbol in temperature_sensor_uninstall() in the esp_idf I can reduce the number of wrong values to 1. That could be then dropped by reading the temperature twice on the first call and dropping the first value. No good style though.
So better do not uninstall the sensor on soft reset.

This is my updated modesp32.c file, including support for ESP32S2 and ESP32S3.

modesp32.zip

@ricksorensen Do you want to make a PR for it?
There is still an inconsistency now between the ESP32 and the other MCUs. For ESP32, the return value is really a "raw" quantity with unknown physical unit and scale. For the other MCUs its not raw, but a degree Celsius value. So the name "raw_temperature" of the method is misleading. Maybe it should better be "mcu_temperature" or just "temperature".

OK. This is the actual state of the file. I renamed "raw_temperature" to "temperature" for the new supported boards. The documentation has to be adapted.
Edit: you might rename it back to raw_temperature, but there must be a few words in the documentation about the difference between the MCU families.

modesp32.zip

I made a fast test with an ESP32C and two ESP32 starting up at a) room 21°C, b) kitchen fridge at -18°C, c) kitchen stove at 65° C. Temperatures checked with a DS18B20. The ESP32 devices were taken out of the fridge/oven for testing, with like 30 seconds between taking out and test start. The ESP32C3 device stayed in the fridge during test. Results:

        ESP32C3  ESP32S2_1  ESP32S2_2  ESP32S3  ESP32_1 ESP32_2
-18°C    -17      -32        -18        -20      100     -
 21°C     22       17         19         20      114     100
 60°C     62       54         59         61      122     112

The numbers are the first values after boot. The values in brackets for the ESP32S2_1 are those after about 20 seconds operation.

Keeping in mind the low thermal capacity of the devices, the heat up during device start and the +/- 1 error of digital instruments, the results for the ESP32C3, ESP32S2_2 and ESP32S3 are very good. The ESP32S2_1 is far too low of at low and high temperatures, which does not change when the default range is adapted. The ESP32 results are hardly useful. That may be the reason why espressif dropped support for it.

How about cpu_temperature?

Whatever you prefer. I had considered mcu_temperature as well, but went for the shorter word.

In my last (not sent) version I renamed the function & object for mcu_temperature to esp32_mcu_temperature() and esp32_mcu_temperature_obj as well. This is just internal stuff in modesp32.c, so no need to change it. Sorry for not mentioning before.

STATIC mp_obj_t esp32_mcu_temperature(void) {
    static temperature_sensor_handle_t temp_sensor = NULL;
    float tvalue;
    if (temp_sensor == NULL) {
        temperature_sensor_config_t temp_sensor_config = TEMPERATURE_SENSOR_CONFIG_DEFAULT(0, 80);
        ESP_ERROR_CHECK(temperature_sensor_install(&temp_sensor_config, &temp_sensor));
    }
    ESP_ERROR_CHECK(temperature_sensor_enable(temp_sensor));
    ESP_ERROR_CHECK(temperature_sensor_get_celsius(temp_sensor, &tvalue));
    ESP_ERROR_CHECK(temperature_sensor_disable(temp_sensor));
    return mp_obj_new_int((int)(tvalue + 0.5));
}
STATIC MP_DEFINE_CONST_FUN_OBJ_0(esp32_mcu_temperature_obj, esp32_mcu_temperature);

and

    { MP_ROM_QSTR(MP_QSTR_mcu_temperature), MP_ROM_PTR(&esp32_mcu_temperature_obj) },

It complained about the lines being too long. you can change previous commits with rebase -i <commit-hash>. See the git docs for git rebase.
Edit: Tools like sublime-merge allow to directly edit commit messages. Editing the commit content with that tool is possible as well, but it is more clear to use the command line version instead.

When you do a git log --oneline in your branch, you get something like:

0ff60bc5b (HEAD -> esp32xn_temp) esp32/modesp32: Support reading chip temperature on ESP32C3/S2/S3.
755dee14c esp32/quickref.rst: Correct spelling.
3f1975fdb esp32/quickref.rst: Add documentation for new mcu_temperature().
05d3b2230 (origin/master, origin/HEAD) docs/library: Document SSLContext cert methods and asyncio support.
bfd6ad94f extmod/asyncio: Add ssl support with SSLContext.

So if you want to change the commit message of 3f1975fdb, run git rebase -i 05d3b2230. Then you get in the editor an action list of commits:

pick 3f1975fdb esp32/quickref.rst: Add documentation for new mcu_temperature().
pick 755dee14c esp32/quickref.rst: Correct spelling.
pick 0ff60bc5b esp32/modesp32: Support reading chip temperature on ESP32C3/S2/S3.

Note the the ordering of lines is reversed. Since you want to change commit 3f1975fdb, replace the word pick by edit, and save & store that action list. Then, your branch is rolled back to commit 3f1975fdb. To just change the commit message, use git commit --amend. Git will open an editor with the commit message, which you can edit & save. Then run git rebase --continue.
If you just want to change the commit message, you can use the action reword instead of edit, which brings you immediately into the editor to change the message. That includes automatically the steps of git commit --amend and git rebase --continue.

If it is just the last commit, which you want to change, you can edit the source files of the commit, save them and run 'git commit -a --amend'. The -a will pick up the changed files and the --amend allows to edit the commit message.

Note: With this action list of commits you can as well re-order commits (just move the lines) or combine two commits into one (action squash).

@ricksorensen The above table with test results is updated. I added results for ESP32S2 and ESP32S3 boards.