Add Sensirion SHT4x I²C Temperature and Humidity sensor

[iz8mbw]

Hi!
Is it possible to add Sensirion SHT4x (SHT40, SHT41, SHT45) I2C Temperature and Humidity sensor in ESPEasy?

Libraries and docs:
https://github.com/Sensirion/arduino-sht
https://github.com/Sensirion/embedded-sht
https://github.com/Sensirion/arduino-i2c-sht4x
https://github.com/adafruit/Adafruit_SHT4X
https://github.com/UncleRus/esp-idf-lib
https://github.com/ArtronShop/ArtronShop_SHT45
http://www.esp32learning.com/code/sht40-digital-humidity-sensor-and-esp32-board-example.php

Datasheet: https://sensirion.com/media/documents/33FD6951/640B22DB/Datasheet_SHT4x.pdf

Many thanks!

[TD-er]

Have you already tried if it may -by accident- work with the SHT1x or SHT3x plugins?

[iz8mbw]

No, but the library/driver of SHT4x seems to be different from SHT3x.

[tonhuisman]

The same request was already posted in the forum, and it is on my local TODO list (though I haven't reserved a plugin ID for it yet), so no ETA.

[iz8mbw]

Yes, I see the first request to add this family of sensors is dated December 2021.
SHT4x is the fourth generation of these very good quality sensors.
I read there is not an ETA and not yet a reserved Plugin ID anyway I hope you will cover SHT4x very soon.
Thanks!

[iz8mbw]

A SHT41 sensor board should arrive soon and so I can help for testing.

[tonhuisman]

I have reserved PluginID P153 for this plugin.

[iz8mbw]

Great!!!

[tonhuisman]

@iz8mbw I've created a PR for this sensor series (SHT40/SHT41/SHT43/SHT45), available from this Actions run, once that's finished.
Please test, and report your findings here or in the PR conversation.

[iz8mbw]

Hi @tonhuisman many thanks.
For now cannot test yet since still waiting for shipment delivery.
I'll let you know when I receive the sensor.

[iz8mbw]

Hi @tonhuisman I'm still waiting for delivery, I'll write you when I receive the SHT41 sensor and I'll test it.
Stay tuned.
Ciao!

[iz8mbw]

Hi @tonhuisman.
Finally the SHT41 sensor was delivered and here my feedback during the test.
Using the default configuration like this:

I can read the sensors without any issues.

But I notices some problems depending on the configuration.
I have noticed if/when the sensor is not connected or there is an I/O Error (read error) ESPEasy return 0 °C and 0 % instead to return "nan".

About the "Heater" setting in "Startup Configuration", when I select it (all Heater combinations) the sensor reports a high temperature value and a low humidity value (ok this make sense due to Heater) but after that no more values are returned, so it hangs at:

so, to synthesize, if/when "Heater" is enabled in the setting "Startup Configuration" after the "Heater" command non more reading cannot be done also if I switch back from "Heater" to "High Resolution" (so if I disable the "Heater").
On the log I see:

About Resolution, the sensor works well at High Resolution (default), but there are some combinations between "Startup Configuration" and "Normal Configuration" that make sensor unreadable and on the log I have;

Here the combinations between "Startup Configuration" and "Normal Configuration" that generates the read errors SHT4x: READ CRC Error, data: 0xffffffffffff:

Startup Configuration: High / Normal Configuration: Low
Startup Configuration: High / Normal Configuration: Medium
Startup Configuration: Medium / Normal Configuration: Low

Many thanks!

[TD-er]

But I notices some problems depending on the configuration.
I have noticed if/when the sensor is not connected or there is an I/O Error (read error) ESPEasy return 0 °C and 0 % instead to return "nan".

That's never done on any plugin as far as I can remember.
Thing is, when the PLUGIN_INIT fails, it will never set the output as PLUGIN_READ is never called.
You could uncheck "Check I2C devices when enabled" on the Tools->Advanced page, as this will at least not disable the task if the sensor is not found.
But that might cause a really slow responding ESP device as it constantly will try to access a not connected sensor.

[iz8mbw]

For SHT3x (Plugin 068) sensor it works returning "nan" if for example I disconnect VCC or I2C signals (between the sensor and the ESP32) and on the log there is:

So for SHT3x (Plugin 068) there is some that recognize "read error" and so stop to provide values (since it returns "nan") and stop to send values to MQTT.
(I have "Check I2C devices when enabled" unchecked on all my ESP32 boards).

[tonhuisman]

@iz8mbw
I'll have a look in what I can do about these issues.

How long is the wiring between the sensor and the ESP?

[iz8mbw]

@tonhuisman 20 centimeters

[iz8mbw]

Hi @tonhuisman did you have time to give a look at the issues when Heater is enabled and when some combinations between "Startup Configuration" and "Normal Configuration" generates read errors?
Thanks.

[tonhuisman]

No, I've been busy with a different project, sorry. Will pick it up soon, though.

[tonhuisman]

@iz8mbw I've added PR #4698 to fix the checksum error issue when using the heater as a Startup configuration. Can you please test that once this GH Actions run is completed?

[iz8mbw]

Hi @tonhuisman just tested and it works very well!
Many thanks for the fix.
@TD-er you can merge #4698 into master,

Thanks!

[tonhuisman]

@iz8mbw I've also tried to implement reporting NaN when an error occurs, like checksum error, read errors or command-sending errors. Available in this GH Actions run (same PR, one commit later then previous Actions run 😛)
For this to be able to work, the Tools/Advanced setting Check I2C devices when enabled must be disabled.

[iz8mbw]

@tonhuisman YES!!!! It works as expected! Now it returns NaN if I disconnect VCC to the sensor and/or if I disconnect SDA and/or SCL signals to the sensor.
Is it possible implement NaN when an error occurs also for HDC10xx Plugin? (see #4643).

Thanks!

[iz8mbw]

In my opinion reporting NaN when an error occurs (like read errors or command-sending errors) should be included by default on every sensor/plugin.
What I mean is that reading errors can happens and them should be recognised and managed.

[TD-er]

I do agree, but.....
You have to realize there are lots and lots of installs out there which may have been running for years now and never had to deal with NaN values.
So making the behavior equal (and more logical) for all plugins may not be the best option here as you also have to deal with legacy installs.

[iz8mbw]

Sorry but if I have a 25 C of temperature and for some reason the I2C cable is cutted and ESPEasy reports 125 C of temperature (instead of 25 C) do you think it makes sense? Better NaN that let's the user understand that there is a problem instead to report a wrong (and no sense) value

[iz8mbw]

Also in Documentation can be specified that ESPEasy reports NaN in case of Read errors instead to reports no sense values such ss 0 C or 125 C or other no sense values

[TD-er]

Like I said, it for sure makes sense to allow for proper error signalling.
But when a user has a working system with JSON parsing, such a setup may crash when it expects numerical values and in JSON a "NaN" isn't a numerical value.

Just as an example of what may happen on installed setups.

[iz8mbw]

I get your point and I want to add if NaN is reported then no values are sent to MQTT and for sure this is an advantage

[TD-er]

We are already working on some more generic solution, but there are some caveats in implementing it right away for all.

[iz8mbw]

Thanks 👍