Enter the SHT30

tmpFF8AThe SHT30 is a chip able to measure temperature and humidity and it is very tiny. It is available on a “shield” board for as little as £1.76 including shipping – and will work with any system able to handle I2c – such as my own ESP8266 kitchen-sink code.

Now, ask yourself,  why would we want yet another temperature/humidity chip?

Don’t we already have the DHT11 and similar? Read on.

So first things first. For temperature we have the excellent Dallas DS18b20 – a 3-pin device (power, signal, ground) which can even run on parasitic power and hence be classed as a 2-pin device. We have the DHT11 and DHT22 and others, able to measure temperature, humidity and when it comes to the BME chips - even pressure (and incidentally ALL of this are already working on my ESP8266 software.

Well, limiting the conversation to those chips/boards able to handle both temperature and humidity, the DHT11 is rubbish – it’s the blue unit you see on many of these kits featuring a million sensors. It does not last long, is cheap and nasty and not very accurate.  The DHT22 on the other hand, lasts longer and is accurate. It is also nearly (or more than) twice the price of the SHT30.

Claimed accuracy for the SHT30 is +=3%RH and +-0.3C -  hence as I’ve done elsewhere I’ve limited reporting to the nearest integer – something I’ve always found just fine for heating systems and other applications.

Nothing new to learn here if you’re familiar with my code – the new number is 5 – that is {temp_type:5} and you are up and running.

A couple of things to note. This particular board has no regulator and so in my case, not using a WEMOS ESP, I used ground, 3v3 and D1 and D2.  Please note that they seem to have screwed up SCL and SDA – because when using this with the larger WEMOS ESP8266+SSD1306 display board, I had to cross over D1 and D2 to get the board to show up on the system. No matter. I have a command {i2c_scan} for that.

If you are doing your own thing note that this chip is particularly easy to drive, fire two values out to the I2c and read  back 6 values – and you only need 4 of them. There is a 0.5 second delay between starting the chip off and reading values… I get around that delay by only using it the first time I take readings – from there on the LAST thing I do is trigger the sampling – so that it is ready and waiting for the next time around. This also works well for the Dallas chip. See also support for the BMP and BME I2c chips – the latter is lovely – but not cheap.

For more info on the ESP8266 software see the Home Control 2017 blog entry. There is a “library” here for Arduino/ESP8266 people – but really – very simple…

Facebooktwittergoogle_pluspinterestlinkedin

34 thoughts on “Enter the SHT30

  1. Please note - any question on this chip - you might want to consult our friend Google as I'm travelling for the next few days (but with a pile of interesting post expected late in the week!).

    1. I am at a total loss as to how it is that the Italian site is often cheaper than the main international site - but you are correct. £1.35 including postage to the UK - amazing - and ordered...

    1. Yes, indeed, much smaller... very handy. Cost is always critical though because you're competing with other similarly priced items. At under £1.50 that first one may not be as pretty - but it seems unbeatable.

        1. For clarification:

          BMP280 = pressure (based on altitude) and temperature
          BME280 = temperature, humidity and pressure
          SHT30 - temperature and humidity
          DHT22 - temperature and humidity
          DALLAS - temperature

        2. I started switching to the BME/BMP280's from the DHT22's a while back. the DHT22's are also rubbish. They give wildly different and inconsistent results - better than the 11's by a long way but vastly worse than the 280's.

          Not sure if the SHT30's are new, I did look at the SHT21's previously. Similar specs I seem to remember.

          As far as I can see, even with the newer sensors, getting an accurate reading of humidity better than +/- 5% is pretty unlikely. To many variables affect the reading. Even a small variation in temperature can have a fairly large impact for example. Air flows equally have a massive impact.

  2. I had some problems using the WEMOS SHT30 shield with the WEMOS D1 Mini Board under the SHT30: it produced a lot of heat, so the SHT30 measurements where about 2 degrees higher than expected. Sadly the humidity values are influenced by the temperature, so they are also somehow wrong.

    So before using that combination, check the results against another temperature probe nearby and calibrate the SHT30 readings in software. I ignored the possibly wrong humidity values, because I don't know the correct relation between temperature and humidity.

    1. I make good use of the double and triple WeMos base boards so that I can mount the ESP8266 module to one side of any sensor rather than above/below as I too originally had issues with WeMos sensor shields getting warm, especially when mounted in an enclosure.

      Dual Base: -

      https://www.aliexpress.com/item/WEMOS-D1-mini-Dual-Base-Shield-Double-Socket-NodeMCU-ESP8266-Board-for-Arduino-Wholesales-in-Stock/32744703872.html

      I can't find a link to the recently introduced triple base right now (not sure if they are genuine WeMos items either as there are a lot of clone boards and shields out there).

        1. Ahh well spotted. I bought quite a few when I first spotted them for sale and I buy so much stuff from both Banggood and AliExpress and constantly price compare that I forget which stuff I bought from which Chinese site!

          The triple boards are my favourite as it means you can have an ESP, a sensor and a small OLED all side by side in a project.

    2. I brought one of the Wemos DHT22 based boards and that is all but useless because of the heat the base gives off. I did tilt the sensor up away from the board which helps but not enough to get any kind of useful humidity reading, the temperature difference has a very large impact on that.

      1. Sorry to remind you Pete, but can you please add {hightemperature?} for the SHT30 when you next do an update.
        Also a couple of corrections for your manual...

        temp_type not showing option 5 for SHT30
        Updated date still showing 3 Oct

        Thanks

  3. I use this 'hat' on top of a Wemos mini pro and to avoid the heating effect found it effective to make the ESP drop into deep sleep. With the RST pin connected to GPIO16 (that's D0 on the Wemos board) you can set the sleep time to whatever. I do the sensing as soon as it wakes, *then* do the wifi & mqtt work before returning to deep sleep.

    1. AHAH! Thank you Tim, you've just saved me several milliamps.... so do the sensing - turn on the MQTT, send message, get message that says shut down, shut down - good - I like it - my current version does the sensing aftwards. Very good.

      1. Well, not quite what I was describing but actually a good general purpose way to do similar.
        I simply (re)start, read sensors, connect ot wifi, send mqtt message, go to (deep)sleep. Adding the 'go to sleep on command message' could make for an interestingly flexible system.

        1. Well, each to their own but I would absolutely want to be certain that the MQTT broke machine has the message and has processed it.

          But you know, I was thinking... so the biggest hit here is the WIFI hit. if this is not needed immediately (for example for data logging), it might make sense to consider storing data, depending on how much there is of it, in the RTC RAM and, say blasting it out over WIFI once a day (or whatever)... that way the process of powering up, taking a reading and going to sleep will GENERALLY take much less time and use much less power. a Quick checksum on the RTC RAM would tell you if it has valid data??? Thought?

          1. With the proviso that you only have 128 4byte slots in the RTC memory and you are probably going to have to store timestamp data as well as the sensor readings rather than relying on the server timestamping on arrival.

            1. Ok, so let's assume you are correct about the 128 4-byte slots - IGRR seems to concur - and these are supported in the SDK.. https://github.com/esp8266/Arduino/blob/master/libraries/esp8266/examples/RTCUserMemory/RTCUserMemory.ino - personally I thought it was less than that but that;'s what get for thinking...

              You lose a byte or two for a checksum... this is actually better than it at first seems if we use a little thought...

              At the time you send a package of information to the Pi, make sure you have the time - this is easily done - if you send the information to the Pi by MQTT and wait for a reply. The reply should contain a TIMESTAMP.

              So that's 4 bytes gone - but let's say you're polling a temperature and humidity sensor every 15 minutes... you need 96 slots a day - and so ONE byte will store the differential timestamp.

              that leaves 3 bytes for temperature and humidity - 12 bits each - that should be enough to keep most folk happy.

              And you have around 124 of those but you only need 96.

              So your RTC Ram is enough to let you store timestamps and 96 12-bit values a day.

              The ESP8266 deep sleep is trivial to use and gives you several hours sleep if you want - in this case we'd need only 15 minutes sleep and it is also equally easy on power up to check the type of power up (ie wake from deep sleep etc).

              So - 96 15-minute logs of two lots of timestamped 12 bit data.

              I'm sure with a little thinking one could increase that.

  4. I have one of these shields on a Wemos D1, but since I updated the ROM to 2.3.15 it goes into a reboot loop unless I turn off the sensor using {temperature_port:0}. Worked fine on 2.3.13, but unfortunately I no longer have a copy of that one.

Leave a Reply

Your email address will not be published. Required fields are marked *