Is there any way to support the hdс1080 sensor?

https://ru.aliexpress.com/item/HDC1080-G­Y-213V-HDC1080/32831368023.html?spm=a2g0­v.search0204.3.22.357d669aa7cVil&transAb­Test=ae803_3&ws_ab_test=searchweb0_0%2Cs­earchweb201602_6_10065_10068_319_317_106­96_453_10084_454_10083_10618_10307_10301­_537_536_10059_10884_10887_321_322_10915­_10103_10914_10911_10910%2Csearchweb2016­03_52%2CppcSwitch_0&algo_pvid=98b0ef6b-5­0e1-4ff6-8589-5786a06d7d20&algo_expid=98­b0ef6b-50e1-4ff6-8589-5786a06d7d20-3

Shouldn't be too hard, just I guess no one has that particular sensor.
Send me one :)

Thr 2019.06.20

Please add link to product datasheet

http://www.ti.com/lit/ds/symlink/hdc1080­.pdf

Looks like a straightforward I2C device, creating a module for it shouldn't be particularly hard.

Thr 2019.06.20

Are you able to interface at this time? (no?) e.g. As the link is to the supplier page, has the purchase been made, or are we still speculating at this point?

If yes, what are the results of just trying the snippet for the common temp/humid sensor:

http://www.espruino.com/DHT11

If no, use the source and modify as needed, as @AkosLukacs points out. It appears that @DrAzzy and I agree, after I viewed that source.

http://www.espruino.com/modules/DHT11.js­

DHT11 is not the best starting point, because the HDC1080 has I2C interface, but the DHT11 has a one-wire interface.
One sensor listed on the I2C page would be a better starting point.

Fri 2019.06.21

Ahhh, . . . hadn't realized the interface difference. Thanks for that tidbit, @AkosLukacs

Maybe the BMP280 Environment sensor code snippet would better assist here:

http://www.espruino.com/BMP280

var i2c = new I2C();
i2c.setup({ scl : D5, sda: D4 });

var b = new ArrayBuffer(4);
var v = new DataView(b);

setInterval( function() {
   var d = i2c.readFrom(0x40, 4);
    print(d);
    v.setUint8(1,d[0]);
    v.setUint8(0,d[1]);
    v.setUint8(3,d[2]);
    v.setUint8(2,d[3]);
    var temp =(v.getUint16(1)/65536)*165-40;
    var hum =(v.getUint16(3)/65536)*100;
    print(temp);
    print(hum);

  setTimeout(function(){
  i2c.writeTo(0x40, 0);
  },500);
}, 1000 );

Thr 2019.08.22

Nice compact little snippet @Alexandr

Would you mind posting some output so that we may better visualize the solution while sampling please.

I wasn't able to get @Alexandr 's code give the correct values so I tried doing it differently.

I tested the sensor with an Arduino and a library for the HDC1080 and then transferred the whole shield over to the Pixl.js for testing.

var exports={};

var C = {
  I2C_ADDRESS : 0x40,
};

function HDC1080(i2c, deviceAddress) {
  this.i2c = i2c;
  this.deviceAddress = deviceAddress;
}

HDC1080.prototype.read = function() {
  this.i2c.writeTo(this.deviceAddress, 0);
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const data = this.i2c.readFrom(this.deviceAddress, 4);
      const temp = data[1] | data[0] << 8;
      const hum = data[3] | data[2] << 8;
      resolve({
        temp: (temp / 65536) * 165.0 - 40.0,
        humidity: (hum / 65536) * 100.0,
      });
    }, 25);
  });
};

exports.connect = function (i2c, deviceAddress) {
  return new HDC1080(i2c, deviceAddress || C.I2C_ADDRESS);
};

I2C1.setup({sda:SDA, scl:SCL});
var hdc = exports.connect(I2C1);
setInterval(() => {
  hdc.read().then((e) => {print(e);});
}, 1000);

It's a bit raw for now but that's how it looks like right now, ready to be done as a module.

I do have a question for @Gordon , I had to use promises because I needed to wait a few ms for the sensor to be ready after setting the pointer for the read (otherwise I get an I2C exception). There isn't any ready pin for this sensor.

Would promises be the way to go, or is there some other way to "delay" the I2C read but still maintain a somewhat sychronous flow?

Edit: obligatory screenshot'

1 Attachment

@parasquid What about a callback implementation?

Callbacks are an option, but I tend to like promises more :P But still, that makes the actual call "nested" in a sense.

I'm looking for a possible way to just do

var data = hdc.read();

and it "just works." This would be possible with async/await but from what I can see it's not yet available in Espruino (yet).

If Espruino had a delay I can do away with the setTimeout and just delay for a few ms at that point and everything should work (this is actually how the Arduino libraries do it) but delay doesn't sound like the Espruino way of doing things.

Well there is no wait, but you can use digitalPulse instead.