Unable to make release due to "no rule to make target 'sht_git_version.c'. It appears the files are missing since the rename.

I will download the older version and rename, however thought you would want to know.

the fun "sht4x_read()" in "sht4x.c" should read out 6bytes of temp and hum data but not 4bytes

int16_t sht4x_read(int32_t* temperature, int32_t* humidity) {
uint16_t words[2];
...

here is sames not correct according to the manual by the first view:

I2C bus operates with 8-bit data packages. Information from the sensor to the master has a checksum after
every second 8-bit data package.
Humidity and temperature data will always be transmitted in the following way: The first value is the
temperature signal (2 * 8-bit data + 8-bit CRC), the second is the humidity signal (2 * 8-bit data + 8-bit CRC).

The master may abort a read transfer after the 16-bit data if it does not require a checksum.

Laziness in example programs confusing people...

and the uint32 data is 1000 times, by divide 1000 is float / double actual num is kinda not appear in the manual...
i looked it for several times,,

Most of the driver code is written in a way that the sensirion_i2c_hal files are not required and the required functions can be written in user application code with the actual driver code only importing sensirion_i2c.h.

The decoupling is nice but 'sensirion_sleep_usec' is used in say 'sht3x.c' and not defined in either the sensirion_common or sensirion_i2c files unlike all the other functions required for proper linkage.

This leads to compilation warnings as there is not proper linking.

[build] /home/workspace/drivers/sensirion/sht3x/sht3x.c: In function 'sht3x_read_serial':
[build] /home/workspace/drivers/sensirion/sht3x/sht3x.c:156:5: warning: implicit declaration of function 'sensirion_sleep_usec' [-Wimplicit-function-declaration]
[build]   156 |     sensirion_sleep_usec(SHT3X_CMD_DURATION_USEC);
[build]       |     ^~~~~~~~~~~~~~~~~~~~

Proposals:

• define an extern sensirion_sleep_usec(uint32_t) in each sensor driver header file or the sensirion_i2c file instead of within sensirion_i2c_hal
• include sensirion_i2c_hal within the includes statements of the driver file (e.g sht3x) so that the prototype exist before the driver is imported within the user code

I want to be able to set high and low limits for the sensor to wake up an mcu using the alert mode as described here:
https://www.repcomsrl.com/wp-content/uploads/2016/06/SHT3x_Alert_Mode_DIS_V1.pdf

Looking at the code it doesn't seem to mention anything about this though.

Full disclosure, I'm NOT using this library, but that shouldn't (?) be irrelevant to the issue.

In your "sht3x.h", you have a single timeout value of 15000.
Based on the datasheet, I surmise that is just set to cover all measurement possibilities from 2.5ms EXCEPT for 15.5ms in Table 5 on page 7 of Sensirion_Humidity_Sensors_SHT3x_Datasheet_digital.pdf.

And I know that does NOT mean it will take 15ms to read. It could come back with the result sooner.
But based on my testing so far (again, not using the library), I'm finding issues with the reading times.

***You can skip to the "***" part below this next part because I did a different test with completely different results, but similar ms confusion...

For low repeatability with no clock stretching, it starts out great with <1ms, BUT then every subsequent read ends up being OVER 15ms.
But for high repeatability, it starts out bad with 23ms before settling in ~15ms.
Times in us are shown at the end of each line, where the "reads" have the time surrounded by '*'.

Low:

I (265) sht3x: xQueueReceive-2416 280270 - 280298 = 28
I (281) sht3x: xQueueReceive-1 286302 - 286304 = 2
I (281) sht3x: SHT3X_CMDS_Read 291316 - 292046 = *730*
I (5273) sht3x: xQueueReceive-2416 304349 - 5313727 = 5009378
I (5273) sht3x: xQueueReceive-1 5314288 - 5314290 = 2
I (5289) sht3x: SHT3X_CMDS_Read 5314904 - 5330544 = *15640*
I (10265) sht3x: xQueueReceive-2416 5346234 - 10345975 = 4999741
I (10265) sht3x: xQueueReceive-1 10346539 - 10346541 = 2
I (10281) sht3x: SHT3X_CMDS_Read 10347680 - 10362790 = *15110*
I (15257) sht3x: xQueueReceive-2416 10378483 - 15378223 = 4999740
I (15257) sht3x: xQueueReceive-1 15378787 - 15378789 = 2
I (15273) sht3x: SHT3X_CMDS_Read 15380014 - 15395038 = *15024*

High:

I (272) sht3x: xQueueReceive-2400 287013 - 287042 = 29
I (288) sht3x: xQueueReceive-1 293054 - 293056 = 2
I (320) sht3x: SHT3X_CMDS_Read 298060 - 321169 = *23109*
I (5280) sht3x: xQueueReceive-2400 323412 - 5320471 = 4997059
I (5280) sht3x: xQueueReceive-1 5321031 - 5321033 = 2
I (5296) sht3x: SHT3X_CMDS_Read 5321646 - 5337286 = *15640*
I (10272) sht3x: xQueueReceive-2400 5352976 - 10352719 = 4999743
I (10272) sht3x: xQueueReceive-1 10353283 - 10353285 = 2
I (10288) sht3x: SHT3X_CMDS_Read 10354424 - 10369534 = *15110*
I (15264) sht3x: xQueueReceive-2400 10385227 - 15384967 = 4999740
I (15264) sht3x: xQueueReceive-1 15385531 - 15385533 = 2
I (15280) sht3x: SHT3X_CMDS_Read 15386758 - 15401782 = *15024*

Any thoughts as to why, "low" in particular has 15ms reads?
You can see I have a 5 second delay in the loop after each read/write.

***Pick it up here

So I did another test which was more direct rather than using freertos task/queues.
Now BOTH Low and High have very low read times of <1ms.

Low:

I (286) sht3x: write 281713 - 282136 = 423
I (302) sht3x: read 297695 - 298425 = *730*; 54.091000%, 68.439003F
I (5294) sht3x: write 5329941 - 5330283 = 342
I (5310) sht3x: read 5346076 - 5346775 = *699*; 54.147999%, 68.668999F
I (10302) sht3x: write 10378318 - 10378659 = 341
I (10318) sht3x: read 10394452 - 10395150 = *698*; 54.061001%, 68.462997F
I (15310) sht3x: write 15426695 - 15427036 = 341
I (15326) sht3x: read 15442829 - 15443527 = *698*; 54.139000%, 68.540001F
I (20318) sht3x: write 20475072 - 20475413 = 341
I (20334) sht3x: read 20491206 - 20491905 = *699*; 54.046001%, 68.640999F
I (25326) sht3x: write 25523449 - 25523790 = 341
I (25342) sht3x: read 25539582 - 25540281 = *699*; 54.160000%, 68.668999F

High:

I (295) sht3x: write 290684 - 291109 = 425
I (311) sht3x: read 306662 - 307390 = *728*; 54.063999%, 68.515999F
I (5303) sht3x: write 5338910 - 5339252 = 342
I (5319) sht3x: read 5355039 - 5355737 = *698*; 54.066002%, 68.540001F
I (10311) sht3x: write 10387287 - 10387627 = 340
I (10327) sht3x: read 10403416 - 10404115 = *699*; 54.084000%, 68.491997F
I (15319) sht3x: write 15435664 - 15436004 = 340
I (15335) sht3x: read 15451793 - 15452492 = *699*; 54.042999%, 68.491997F
I (20327) sht3x: write 20484041 - 20484381 = 340
I (20343) sht3x: read 20500170 - 20500869 = *699*; 54.061001%, 68.462997F
I (25367) sht3x: write 25564676 - 25565016 = 340
I (25383) sht3x: read 25580805 - 25581503 = *698*; 54.033001%, 68.491997F
I (30375) sht3x: write 30613053 - 30613393 = 340
I (30391) sht3x: read 30629182 - 30629880 = *698*; 54.078999%, 68.415001F
I (35383) sht3x: write 35661430 - 35661770 = 340
I (35399) sht3x: read 35677559 - 35678257 = *698*; 54.088001%, 68.415001F
I (40391) sht3x: write 40709807 - 40710147 = 340
I (40407) sht3x: read 40725936 - 40726635 = *699*; 54.049999%, 68.462997F

General code:

        uint8_t lcmd[2] = {0x24, 0x16}, lres[6]; //Only difference between Low and High is "0x16" -> "0x00"
        int64_t lstart, lstop;

        esp_err_t lesp_err_t = i2c_initialize();

        vTaskDelay((SHT3X_MAX_TIMEOUT_MSEC / portTICK_PERIOD_MS));

        for (;;)
        {
            /*Stopwatch the "write"*/
            lstart = esp_timer_get_time();
            lesp_err_t = i2c_write(pI2c_port_t, pSht3x_i2c_addr_t, lcmd, 2, (SHT3X_MAX_TIMEOUT_MSEC / portTICK_PERIOD_MS));
            lstop = esp_timer_get_time();
            ESP_LOGI(gTAG, "write %llu - %llu = %llu", lstart, lstop, (lstop - lstart));

            vTaskDelay((SHT3X_MAX_TIMEOUT_MSEC / portTICK_PERIOD_MS));

            /*Stopwatch the "read"*/
            lstart = esp_timer_get_time();
            lesp_err_t = i2c_read(pI2c_port_t, pSht3x_i2c_addr_t, lres, 6, (SHT3X_MAX_TIMEOUT_MSEC / portTICK_PERIOD_MS));
            lstop = esp_timer_get_time();
            ESP_LOGI(gTAG, "read %llu - %llu = %llu; %f%%, %fF", lstart, lstop, (lstop - lstart), ConvertHumidityTickToPercent((lres[3] << 8) | (lres[4])), ConvertTemperatureTickToFahrenheit((lres[0] << 8) | (lres[1])));

            vTaskDelay(5000 / portTICK_PERIOD_MS);
        }

So, I guess the question pretty much still stands as to why Low and High Repeatability have similar times when I was expecting Low to take ~2.5ms and High to take ~12.5ms, but definitely neither to take < 1ms (which seems great to me anyway, right?).
They both also seem to have similar repeatability (accuracy? Assuming that means multiple samples are taken on the chip-side).

EDIT0: It may just be the case that I don't know what the "-" means for the "Minimum" value in the table. Perhaps it means the minimum is unknown, or could be anything.

EDIT1: After moving things around and putting in test points, I see that one spot I had my stopwatch set that was registering 15ms was checking xMessageBufferIsEmpty and if not, then delay 15ms.
I'm pretty sure that was my original issue in the first Low/High codeblocks, but will check it after I wake up.

EDIT2: Well that's just bizarre. That wasn't the fix. I ended up creating a barebones task, adding a queue, then adding message sections, sending queue command from a different task and receiving the message from the other task, and that was fine.
Guess I have some digging to do... though still doesn't answer the Low/High times/results essentially being the same.
Ooookay, changing logging verbosity from Verbose to Info made the biggest difference with 10s of ms to 100s of us, even if the Verbose logging wasn't even being used (only printing Info-level logs).

I read the official website said that the HT version of the kernel supports the SHT3x driver,

SHT3x | 4.8 | June 2, 2016

but I did not see the configuration of the SHT31 in the configuration, I am based on the website [https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black] configured BBB firmware. The kernel version is 4.18.

I have configured the relevant content in the device tree.

&i2c1 {
	pinctrl-names = "default";
	pinctrl-0 = <&i2c1_pins>;

	status = "okay";
	clock-frequency = <100000>;

	sht31: sht31@44 {
		compatible = "sensirion,sht31";
		reg = <0x44>;
	};
};

debian@BBB:~$ sudo i2cdetect -r -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
debian@BBB:~$

How can I enable the SHT31 driver?

Hi team,

Just to mention that when going through the sensor integration process, it appears your driver sht3x.h/c is hardcoding the sensor address to the default one and does not allow the use of the alternative one. It also means as in our application we use 2 sensors (one facing indoors, the other facing outdoors) that dynamic addressing to one or the other address is not possible in the current state.

I will submit a PR in that sense, probably as well for the alert support.

I apologize I'm not that savvy in GitHub about how to leave comments, this isn't an "issue" it is a feature request. Would you be kind enough to port an example for the Raspberry Pi Pico using the c SDK only? Meaning no C++ and just pure C. I tried following your instructions to port the I2C SDK objects needed to meet your code but sadly I have failed countless times. I have about 4 of the SHT45 sensors I would really love to use. I don't use Arduino or MicroPython or even Adafruits code (since it's Arduino C++ based). I only program in pure C using the Pico C SDK.

I would imagine it would take one of your engineers 10 minutes to code this, I'll even pay for a pico if you want just let me know how to fund this and I will! I know it is a big ask from essentially one user but it would go far in the community of Pico fans. I found several others stuck in my situation as well. I sincerely hope you give this some thought and write it out for the pico as an example. The board is blowing up in popularity and there are still many of us who use plain C and Visual Studio Code to interface with it. I would be forever grateful if you could assist the Pico crowd!

I would bet your engineers would need nothing more than this to code it out:
https://www.raspberrypi.com/documentation/pico-sdk/rp2__common_2hardware__i2c_2include_2hardware_2i2c_8h.html

Hoping you hear the voice of just one customer (who has been loyal to your company with some of your other sensors!)
Respectfully,

Anglerfish27