Espruino on your (Xiaomi) humidity sensor

Posted on
  • Ok, that is a clickbait-y title, no real progress so far, but maybe there will be some :)

    I must admit, this was kind of an impulse buy after finding out that Xiaomi's Bluetooth temperature & humidity sensor probably has an nRF chip, and Sensiron sensor.
    Edit: Part no lLYWSDCGQ/01ZM, got from Aliexpress

    My original plan was to add a CCS811 (air quality sensor), and probably drop in an ISM radio because the walls in my house are thick (40-45cm), and 2.4Ghz just doesn't penetrate that thick walls well. At the time couldn't find more info about it, so just ordered.
    Or just use 'em in the rooms close to the Pi (to collect data) if all fails...

    Got them today. First impression & teardown with unsorted photos :

    The good:

    • Ordered 3 of them, the measured values are <0.5°C and <1% RH apart. Those things react fast to temp or humidity changes.
    • Nicely constructed, You can take it apart and reassemble no problems.
    • Looks like they really have Sensiron SHT30, manufactured in 2018. The sensor sits in a small opening, connected with a flex pcb to the main PCB.
    • It has test points! I think I have found power pins, SWD pins, and SDA, SCL to the SHT30.
    • The LCD driver has is manufactured by Rohm, and has a datasheet

    The bad:

    • Turns out, some more googling could have revealed the exact parts before purchasing...

    The ugly:

    It does have an nRF chip: nRF51802

    The nRF51802 is a low cost variant of the nRF51822, it has the same functionality, but has minor performance degradation in terms of:

    • 2 dB less RX sensitivity
    • Slightly higher RX and TX peak currents

    That's like the MCU in the micro:bit with worse RF performance :/

    Couldn't figure out the type of the DC-DC converter so far, so no idea how much current can it provide. Might not be enough for an ISM radio.

    And of course I need some extra pins too...

    So right now not so sure about Espruino. Maybe if I can strip out bluetooth from the nRF51 build to free up some memory? Or just try to do it in C? Or reassemble the unit, and place 'em in locations with good bluetooth reception? :)

  • This looks really cool. You mean this sensor?­-Intelligent-Temperature-Humidity/dp/B01­K3ZSREW/ref=asc_df_B01K3ZSREW/

    I'm afraid I can only see one photo at your link - please could you check you're pointing to the whole album?

    I'd never heard of the nRF51802 before - that's really interesting. It could probably still run Espruino though - you just won't get much code on it :)

    By the way, if you wanted to just read that sensor from an Espruino device, there's a post on it here:­333218/

  • Ooops, link to the photos is fixed now.
    Mine is a different device that has LCD & Bluetooth. There is also a whole series of zigbee Xiaomi sensors, IIRC one of those has an NXP chip. So check before buying, if anyone is interested!

    Part number is lLYWSDCGQ/01ZM Aliexpress link or search for "Xiaomi Mijia bluetooth wireless temperature and humidity sensor". Funny thing is, it's available from the Hungarian Xiaomi shop for less than banggood's price. Aliexpress was cheaper, so check prices :)

    Yeah, first couple of searches for nRF51802 resulted in nothing / older questions about this non-existent chip. Still there is no trivial direct link on Nordic's site, a search hit lead me there.

    Yes yes, saw that, that's the fallback plan :)

  • Some progress:
    Since the SWD pins have 2.54mm pitch, had some pogo pins & wanted to try those, decided to try to create a pogo pin adapter.
    Long story short: just soldering the wires probably would had been easier, but I'm in! If anyone interested in details, some more photos are at the same link, or AMA :)

    Flashed the Microbit firmware with Openocd & an ST-Link clone. Shows up on Bluetooth! Connect to it, and currently looking at 300 free vars :)

  • LCD is working, segments mapped!
    Now I have to figure out how to fit all I want in that chip...

    SHT30 part was ridiculously easy, RELP makes it sooo easy. Mapping the segments without the REPL would had been much more fun I guess.

    1 Attachment

    • IMG_20190518_223002.jpg
  • That's awesome! So you're now using the microbit firmware as-is?

    Unfortunately the microbit firmware has some odd pin mappings, so if you wanted to build your own firmware with a 1:1 mapping you'd have to tweak your pin values according to this table:­b/master/boards/

    I bet that'd end up being a really neat low power display for other Bluetooth devices though - is that infrared or just a light at the bottom of the case I can see?

  • Wanted to write some more details, but didn't have the time, so here are some bits:

    Created my own firmware based on the microbit, basically stripped out graphics & microbit specific functions plus changed the pin mapping. The board file is here

    And here is the first question: hardware I2C worked just fine, but hw SPI did not. SW SPI does work, my current guess is (didn't have time to rebuild & reflash & retry) that the Microbit board file defines SPI pins, but the LCD controller is connected to different pins, and that interferes.
    AFAIK you can use the HW SPI on any pin of the nRF, right? So if I just remove the SPI specific parts from the board file, it should be good to go?

    Oh, no, no IR, the SHT30 sits there :) There is a hole at the bottom (not visible) and at the front (the one you see) so the sensor has pretty good airflow. I don't have a better photo atm.

  • Odd about hardware SPI - maybe you could build with V=1 and just ensure that the file in libs/microbit isn't getting built in? Since that is what would likely be using the hardware SPI - I don't think anything outside of that gets used.

  • Well, removed SPI pin definitions from the board file, built with BOARD=HUMI RELEASE=1 V=1 make, but no luck.
    Calling the write() commands after the commented out SPI initialization does nothing. But software SPI does work.

    //SPI1.setup({mosi:D9, sck:D10})
    //function write(d){SPI1.write(d, D11)}
    var spi = new SPI();
    spi.setup({mosi:D9, sck:D10});
    function write(d){spi.write(d, D11);}
  • It is possible there is an issue with hardware SPI on the nRF51 - it may never have been tested.

    Honestly though software SPI really isn't that much worse (since in the current implementation even in hardware SPI the interpreter is sat there waiting for the hardware to finish sending)

  • Thanks!
    Thinking about it, there may be a hardware issue in either the nRF51, or in this low-price variant. Checked the communication with the original, and SPI clock frequency was in the ~150-160kHz range. But according to the datasheet the LCD driver can support 1 or 2 MHz clock rates...

    And next thing: any pointers about how to handle the segment LCD efficiently? Mapped the segments, but they are all over the place. Never done anything like this.
    The original firmware sends all data all the time, I guess that was easier for them.

  • Is the LCD attached via SPI or something like that? I'd say it almost certainly is easier to send all data all the time especially given the overhead of running JS.

    If there are 32 or less segments I'd just try and use a Uint32Array where each element is a mask of the segments that need to be turned on for a word.

    var segChars="0123456789abcdef";
    var segMask = new Uint32Array([.......]);

    The you just use 'or' to add all the segments you need together, and send the result as bytes.

  • Thanks!
    Yes, the LCD is driven by Rohm BU9795AFV thru SPI.
    Will give it a try

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Espruino on your (Xiaomi) humidity sensor

Posted by Avatar for AkosLukacs @AkosLukacs