How to find out reason for Sonoff SI7021 probe unstable connection?

Question

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.

Answer 1

The Github link provides the answer, but a shorter summary and an update may be helpful:

• Older and newer sensors have different timings.

• The driver in Tasmota (mine: 12.4.0.1; THR316D) can be set up to this by using DhtDelay:

  DhtDelay1 500,40

Default in Tasmota 12.4.0.1:

19:18:41.812 CMD: DhtDelay
19:18:41.828 MQT: stat/tasmota_BCD54C/RESULT = {"DhtDelay1":[400,30]}

Note:

• DhtDelay was added in 12.4.0.
• Use DhtDelay1 for the first sensor.
• after a restart in 12.4.0.1 the default value is back. (seems not to be saved) => see Issue 17944 for solutions (rule or autoexec.bat)

or use a rule as solution:

Rule1 ON System#Init DO DhtDelay 480,40 ENDON
Rule1 1

or (on ESP32) use the 'autoexec.be' berry script file.

1. use the menu "Consoles" -> "Manage File system" -> "Create and edit new file" to create a file, name it "autoexec.be".
2. insert the Berry Code below into the file and save it.

Berry Code (Syntax here):

tasmota.cmd('DhtDelay 480,40')

Answer 2

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