[SOLVED] Can anyone verify that HTU21D module is not buggy?

Dear all,

I just tried the module HTU21D (http://www.espruino.com/HTU21D) and it seems that I can get the temperature quite accurately but the humidity ever returns -6.
I figured out that the HTU21D may be compatible with the Sensiron SHT21. I tried to used the module SHT2xinstead. As before, temperature is correctly read but humidity returns null.
Did anyone use this/those modules recently and can confirm they work as expected?

Thank you!

my code:

var i2c = new I2C();
i2c.setup({scl: D17, sda: D19});//NRF52
var htu = require('HTU21D').connect( i2c );

var temperature;
var humidity;
function HTU21DRead() {
  htu.getTemperature( function(temp) {
    htu.getHumidity( function(hum) {
      temperature = temp;
      humidity = hum;
    });
  } );
}

setInterval("HTU21DRead()",1000);

And when I ask for temperature and humidity I get:

>temperature
=23.62461669921
>humidity
=-6

@tom.gidden / @tomgidden and @luwar might have some ideas as they have been involved in this module... I'm afraid I don't have one here to test with.

Your code adapted to pico, runs well on my pico.

// htu21d_00.js
// pico
// left 1:gnd, 2:vbat, 3:3v3, 4:b3

//I2C1.setup({scl:5,sda:4});
//pico left 7: B6, left 8: B7 //I2C1
//pico left 4: B3, right 5: B10 //I2C2
//propeller sda: P29, scl: P28



setBusyIndicator(LED1);

var i2c = new I2C();
//i2c.setup({scl: D17, sda: D19});//NRF52
i2c.setup( {scl: B6, sda: B7 } ); // pico soft i2c
var htu = require('HTU21D').connect( i2c );
var temperature;
var humidity;
function HTU21DRead() {
  htu.getTemperature( function(temp) {
    htu.getHumidity( function(hum) {
      temperature = temp;
      humidity = hum;
      console.log('tmp : ' + temperature);
      console.log('hum : ' + humidity);
    });
  } );
}
setInterval("HTU21DRead()",1000);

And output.

>
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v95 Copyright 2017 G.Williams
>
=undefined
tmp : 21.08276855468
hum : 35.24450683593
tmp : 21.08276855468
hum : 35.22161865234
tmp : 21.08276855468
hum : 35.23687744140
tmp : 21.08276855468
hum : 35.25213623046
tmp : 21.08276855468
hum : 35.259765625
tmp : 21.09349365234
hum : 35.28265380859
tmp : 21.08276855468
hum : 35.28265380859
tmp : 21.09349365234
hum : 35.28265380859
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v95 Copyright 2017 G.Williams
> 

Yes, the HTU21D is a SHT2x clone or vice versa.
Tomorrow I can check the module with a real sensor, but I already think it will work for me. There hasn't been any code change since I last tried it.

@Jean-Philippe_Rey
Could you try the other methods? Especially the synchronous variants readTemperature and readHumidity. I'm a little surprised, as the CRC-check didn't show any errors.

Which board do you use? I tested the module with a Pico.

Synchronous methods gives me the same results...

>htu.readHumidity()
=-6
>htu.readTemperature()
=23.78549316406

I am using a custom board based on NRF52. The firmware image is espruino_1v94_nrf52832_20171127.hex

I cannot easily check on one of my Picos because the sensor is really tiny and difficult to unsolder.
Agreeing to the code, the conversion function is looking like this:

-6 + 125 * this.readMeasuredData() / 65536;

Well if this.readMeasuredData() equals 0 the result will be -6, which is what I receive in my case...

Can you hold the NRF in reset (so the pins tristate), and connect to SDA/SCL/Gnd lines, so you can connect to a pico or anything? Try both hardware and software I2C if you can.

If you don't touch the wires used from JS code then they should hopefully be tristate anyway.

... but as you say, if it was amazingly dry (or wet) then you'd expect a value out of range... But it's unlikely you'd be getting exactly 0 as a humidity reading.

(For my part, as the original author of the Espruino module, I can't say. It worked when I wrote it, but I've long since switched to using a BME280 sensor for combined pressure, temperature, humidity. I've been meaning to upgrade to the BME680 that also does VOC air quality measurements. Sorry I'm of no help.)

I put a logic analyzer on the bus. After requesting humidity with htu.getHumidity(function(h){console.log(­h);}), here is what I got on the bus:

0x80 + ACK
0xE7 + ACK
pause 0.8 ms
0x81 + ACK
0x02 + NAK
pause 1.5 ms
0x80 + ACK
0xF5 + ACK
pause 18 ms
0x81 + ACK
0x00 + ACK
0x00 + ACK
0x00 + NAK

I confirm, the sensor sends zero values (last three 0x00)
for the default 12-bit resolution of the humidity conversion it takes max 16 ms to finish. In my case I got 18ms, which is long enough to let the sensor complete its conversion.

OK guys that's not a problem related to code...
Page 12 of HTU21D datasheet (the one from TE, not an equivalent from Silabs or Sensirion), it is written under "Diagnostic status" that if zeros comes out of the conversion buffer, it means that the sensor is in "open circuit" condition. In other terms, my IC is broken :-/
I just tried with another IC and this works perfectly. Sorry about time you guys spent helping me. I did not consider it could be an IC problem, as I was able to retrieve the temperature easily.

Interesting - thanks!

I'll add a note to the docs about that.

Hi Jean

I had the semi-same problem with HTU21D. It returned with open circuit humidity and temperature a lot of times. After it worked again (or not :)).
The I2C line uses 3 eeproms which work fine all time...
I reviewed my code.. the library...the eeprom... bus frequency...datasheet... my 4 htu sensors, everything... the fault and instability stayed the same.

The final solution was: I used 1K resistors to pull up the bus lines because of 4 devices on it. This was the mistake. with 0.5K it also did not worked, but with 2.7K all of my sensors became available immediately.