Sonoff TH10 'bricks' after flashing with basic Blynk script

Yup I eventually got that working. What I can’t get to work is the sensor read-out. I’ve spend hours pouring over the code of Arends and I can distill it reasonably well, but he has too much dependencies, structures, definitions and declarations all over his code which makes it impossible (for me) to distill the part I need. Here’s a link to the file that contains most that is required. I got so far that this is required to initialize:

  for (byte i = 0; i < MAX_GPIO_PIN; i++) {
    uint8_t mpin = 1;
    if ((mpin >= GPIO_DHT11) && (mpin <= GPIO_SI7021)) {
      if (DhtSetup(i, mpin)) {
        mpin = GPIO_DHT11;
      }
    }
  }

given this:

#define GPIO_DHT11 1
#define GPIO_SI7021 3
#define MAX_GPIO_PIN 18

and this part should get the data:

Xsns06(0); //initialize sensor
Xsns06(4); //prepare readout
Xsns06(5); //readout

but…there are a couple of structures and functions also in those parts of the code that prevent me from compiling it.

Well I won’t dig into it, but what I understand from my yesterday’s evening reading, is that all is needed is a change in some delay() loop. They were discussing, that a change to delayMicroseconds() eventually made it working. And it was a modification to DHT library under AM2301 sensor support.

yes, that change applied to arendst tasmota library which I what I was talking about. What is required is a set of pulses and then a read-out but im completely clueless how he does it. I can find the section but it could as well be in arabic.
And I understand you won’t go through it, even distilled its quite some code AND its heavily dependent on a lot of includes…

And what about comparing it to the ‘usual’ DHT library? Narrowing ( probably looking for some #ifdef’s) the search to those parts that apply to AM2301 sensor?

yeah I figured you meant that, I’m currently looking into it. That code is much much more comprehensible but I can’t find any pulses, I’ll need to reread the fix.

edit, which is:

So, I took my logic analyzer and reverse engineered it. I can send more details later, if needed, but it looks their “one wire” protocol is quite simple. First, the host need to send 0.5ms low pulse, then go high for ~40us, and then move to tri-state (INPUT) to let the sensor send data back. The sensor sends totally 1bit+5 bytes/41 bits (MSB order). At first, the sensor sends a “start bit” that is “1”. Next two bytes/16 bits are humidity with one decimal (i.e. 35.6% is sent as 356), two bytes/16 bits after that are temperature in Celsius, again with one decimal (i.e. 23.4C is sent as 234), and finally the last byte/8 bits is a checksum. When sensor sends logical “1” it pulls the line HIGH to ~75us, when it sends logical “0”, it pulls the line HIGH to ~25us. There is about 40us (LOW) between HIGH pulses. Checksum is basically a (8-bit) sum of 4 data bytes. I also wrote a simple test code and got right values from the sensor without ITEAD’s firmware, so, I believe my revers engineering is correct.

it will be a last resort to try this, in the mean time I’ve email kkuisman hoping he still has that test script lying around.