0
\$\begingroup\$

In my project I have Sonoff TH10 and Sonoff TH16 - allf lashed with Tasmota 9.4.0 and several pcs of SI7021 probes. Problem is that only one SI7021 probe has stable connection, rest are unstable in terms of reporting measured values, that are sometimes (approx 50%) returning NULL instead of real values. When problem is ocuring log is full of messages:

08:23:37.604 DHT: Timeout waiting for start signal low pulse
08:23:39.574 DHT: Timeout waiting for start signal low pulse
08:23:41.608 DHT: Timeout waiting for start signal low pulse
08:23:43.588 DHT: Timeout waiting for start signal low pulse
08:23:45.567 DHT: Timeout waiting for start signal low pulse
08:23:47.591 DHT: Timeout waiting for start signal low pulse
08:23:49.568 DHT: Timeout waiting for start signal low pulse
08:23:51.610 DHT: Timeout waiting for start signal low pulse
08:23:53.561 DHT: Timeout waiting for start signal low pulse

and

STATUS10 = {"StatusSNS":{"Time":1621865135,"SI7021":{"Temperature":null,"Humidity":null,"DewPoint":null},"TempUnit":"C"}}

Strange thing is that problem seams to be depending on particular probe, not on TH module itself. The probe that is reading fine, works in every TH module, probes that have 50% reliability fails after while in any Sonoff TH module. All probes are same HW version 1.0 and i haven't done any modification in them at all. Only exception is, that the working one was purchased 1.5 year earlier. I have tried to flash earlier Tasmota versions 9.0, 8.0, but there was no difference.

Can it be that new probes are have different firmware or different chip versions, so some of the are working just fine and some of them have 50% failure rate? Can it be something obvious that I have missed.

\$\endgroup\$
1
  • \$\begingroup\$ hardware usually gets cheaper (worse) over time, or maybe you got a bad batch. \$\endgroup\$
    – dandavis
    May 25, 2021 at 7:38

1 Answer 1

0
\$\begingroup\$

I did some deep dive into timing and as result, I modified two values in Tasmota firmware. Problem is not related to HW failure in 99%, but for me it is not yet fully clear if the problem lays in unreliable ESP8266 internal clock or somewhere else.

It appears it can be also related to system actual load that impacts clock, as some users reported that they cannot read values after they they refresh console, or after 'while' after reboot, that can mean that system load stabilised a while after reboot.

I compiled own tasmota FW with modified values and loaded them into TH16 and TH10 with different SI7021 probes connected (one was working, one was not)

With modified values, reading stabilised and no more error messages are in weblog at both THx versions. Sure it needs more stabilisation time and observation to say, that this is final solution.

Further details: https://github.com/arendst/Tasmota/issues/12180

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.