search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.1k stars 4.79k forks source link

Tasmota 9.4 contact with SI7021 is unreliable #12180

Closed AlfaBravoX closed 3 years ago

AlfaBravoX commented 3 years ago

PROBLEM DESCRIPTION

I have one pcs of TH10 and one pcs of TH16 and 3 pcs of SI7021. Only one SI7021 connection is reliable, rest are unstable in term of reporting measured values returning randomly NULL instead of real values. when this is happening log is full of messages 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 THx module. If the working probe is connected to any THx it works, if probe that sometimes giving NULL is connected to any THx it fails after while anywhere. I admit i connected probe to THx not powering THx off, but I did that with all probes and and it they sometimes measure correct, sometimes they give NULL. Only one pcs of SI7021 never returns Null and measures correctly. Yes it should be considered if SI7021 are not partially broken by removing them on the fly, but AFAIK the chip would be totally broken or working. I am not sure if some semi-broken status can exist on SI7021.

REQUESTED INFORMATION

- [ ] Provide the output of this command: `Status 0`:
```lua
  STATUS 0 output here:
5:05:35.714 MQT: _myproject/sonoff/stat/heating/STATUS = {"Status":{"Module":0,"DeviceName":"Topeni ","FriendlyName":["Topeni "],"Topic":"heating","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":8,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":1,"PowerRetain":0,"InfoRetain":0,"StateRetain":1}}
15:05:35.749 MQT: _myproject/sonoff/stat/heating/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://ota.tasmota.com/tasmota/release/tasmota.bin.gz","RestartReason":"Software/System restart","Uptime":"0T00:06:11","StartupUTC":"2021-05-24T13:59:24","Sleep":50,"CfgHolder":4617,"BootCount":37,"BCResetTime":"2021-04-21T18:55:15","SaveCount":282,"SaveAddress":"F9000"}}
15:05:35.785 MQT: _myproject/sonoff/stat/heating/STATUS2 = {"StatusFWR":{"Version":"9.4.0(tasmota)","BuildDateTime":"2021-04-23T10:07:22","Boot":7,"Core":"2_7_4_9","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"390/699"}}
15:05:35.804 MQT: _myproject/sonoff/stat/heating/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":4,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["-myssid","-891w"],"TelePeriod":300,"Resolution":"558180E0","SetOption":["00008209","2805C8000100060000005A0A000000000000","00000280","00006000","00000080"]}}
15:05:35.840 MQT: _myproject/sonoff/stat/heating/STATUS4 = {"StatusMEM":{"ProgramSize":599,"Free":404,"Heap":24,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"146085","FlashFrequency":40,"FlashMode":3,"Features":["00000809","8FDAC787","04368001","000000CF","010013C0","C000F981","00004004","00001000","00000020"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,27,29,30,35,37,45","Sensors":"1,2,3,4,5,6"}}
15:05:35.875 MQT: _myproject/sonoff/stat/heating/STATUS5 = {"StatusNET":{"Hostname":"heating-3553","IPAddress":"192.168.2.123","Gateway":"192.168.2.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.2.1","Mac":"84:CC:A8:97:2D:E1","Webserver":2,"WifiConfig":4,"WifiPower":17.0}}
15:05:35.899 MQT: _myproject/sonoff/stat/heating/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.2.4","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_972DE1","MqttUser":"DVES_USER","MqttCount":1,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4}}
15:05:35.924 MQT: _myproject/sonoff/stat/heating/STATUS7 = {"StatusTIM":{"UTC":"2021-05-24T14:05:35","Local":"2021-05-24T15:05:35","StartDST":"2021-03-28T02:00:00","EndDST":"2021-10-31T03:00:00","Timezone":"+01:00","Sunrise":"04:57","Sunset":"20:36"}}
15:05:35.947 MQT: _myproject/sonoff/stat/heating/STATUS10 = {"StatusSNS":{"Time":1621865135,"SI7021":{"Temperature":null,"Humidity":null,"DewPoint":null},"TempUnit":"C"}}
15:05:35.960 MQT: _myproject/sonoff/stat/heating/STATUS11 = {"StatusSTS":{"Time":1621865135,"Uptime":"0T00:06:11","UptimeSec":371,"Heap":24,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"ON","Wifi":{"AP":1,"SSId":"_myssid","BSSId":"00:A6:CA:27:FA:30","Channel":1,"RSSI":50,"Signal":-75,"LinkCount":1,"Downtime":"0T00:00:03"}}}



### TO REPRODUCE
_Steps to reproduce the behavior: Connect SI7021 Probe to TH16 or TH10 and configure module to TH(4) and gpio 14 SI7021

### EXPECTED BEHAVIOUR
_A clear and concise description of what you expected to happen: there should not be messages like these _myproject/sonoff/stat/heating/STATUS10 = {"StatusSNS":{"Time":1621865135,"SI7021":{"Temperature":null,"Humidity":null,"DewPoint":null},"TempUnit":"C"}} and system never should report null 

### SCREENSHOTS
This show clearly that there is about 50% gap in data gathering. Graph is taken from HASS.

![image](https://user-images.githubusercontent.com/11148591/119361750-4b615980-bcac-11eb-9052-1ae08ad36a28.png)

### ADDITIONAL CONTEXT
_Add any other context about the problem here._

**(Please, remember to close the issue when the problem has been addressed)**
ascillato2 commented 3 years ago

Hi,

Sorry, but Tasmota can not fix the hardware issue of your sensor. You should contact your seller for a refund or for giving new sensors.

dbiczo commented 3 years ago

It appears that ascillato2 is too quick to dismiss this issue as being solely hardware related. I have exactly the same issue. The problem does not appear with older firmware 5.12.0 while the Si7021 sensor gives random null readings with firmware 9.4.0

AlfaBravoX commented 3 years ago

I was surprised too, that ascillato2 has closed the issue so quickly. I did not say it is HW problem, I just said, that I handled probe not powering sonoff off, so i am not sure if this can be somehow connected. But the working one I have, I also handled a dirty way (multiple times) and it had been working for ages. I think there can be also some slight HW changes in recent probe manufacturing batch that is causing this, because 2 years old one i have works well. But this does not mean new are broken. I am happy to help with debugging if tasmota folks will ask.

dbiczo commented 3 years ago

I agree there appears to be some variation in manufacturing as one of my Si7021 sensors works properly with 9.4.0 firmware and 3 don't. I have tested one that doesn't work with the new firmware and it works properly with the old 5.12.0 firmware. I have powered off my devices when changing the sensors and still see the problem.

AlfaBravoX commented 3 years ago

@ascillato2 , based on evidence from @dbiczo , can you please reopen the issue?

ascillato2 commented 3 years ago

Reopening as requested.

As you are the ones that have this "new" sensor, please, share the timings they do with an oscilloscope when the sensor starts. With the new and the old sensors, in order to try to adjust for both.

AlfaBravoX commented 3 years ago

OK, i did some deep dive into timing and as result, I modified two values in xsns_06_dht.ino:

in line 100 case GPIO_SI7021: // iTead SI7021 delayMicroseconds(30); <<-- is new val replacing 20

and in line 139

if (DhtWaitState(sensor, 0) && DhtWaitState(sensor, 1) && DhtWaitState(sensor, 0)) { for (i = 0; i < 40; i++) { if (!DhtWaitState(sensor, 1)) { break; } delayMicroseconds(30); <<-- is new val replacing 35

For me it is not clear if the problem lays in unreliable 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 .bin with modified values and loaded them into TH16 and TH10 with different SI7021 probes connected (one was working, one was not)

With above modified values, reading stabilised and no more error messages are in webloag at both THx versions. Sure it needs more stabilisation time and observation to say, that this is solution. If @dbiczo or anyone else wants to try , here is modified .bin: tasmota_ob_dht_mod.bin.zip

Last but not least, @ascillato2 if this is solution, how about to introduce new SetOptionXXX to enable end users to fine tune probes timing themself? It can reduce many posts in different forums how to solve such flickery connections.

dbiczo commented 3 years ago

Great work @AlfaBravoX. I owe you a beer. I have been running your modified 9.4.0 firmware on two TH16 switches, one with a previously working SI7021 sensor and one with a not working SI7021 sensor. After 3 hrs there has been no noticeable null values.

I thought the same as you with the timings being affected by processing load and tried modifying sleep values, both dynamic and normal, with no effect.

I will try AM2301 and DS18B20 sensors to confirm new timings still work with those and report back in a couple of days.

AlfaBravoX commented 3 years ago

@dbiczo glad it is working for you. After 24 hours of running updated firmware on two THs, I had Zero failures in reading in none of them. Also DHT: Timeout waiting for start signal low pulse has gone.

SI7021_fix

MarkCiliaVincenti commented 3 years ago

I'm having the same issues with 4 new Si7021 sensors I just received (the older ones work fine). When will this fix make it to a release please?

AlfaBravoX commented 3 years ago

I'm having the same issues with 4 new Si7021 sensors I just received (the older ones work fine). When will this fix make it to a release please?

@MarkCiliaVincenti did you try to load above attached FW? Does it fix your issue?

MarkCiliaVincenti commented 3 years ago

I'm having the same issues with 4 new Si7021 sensors I just received (the older ones work fine). When will this fix make it to a release please?

@MarkCiliaVincenti did you try to load above attached FW? Does it fix your issue?

Not yet, I was hoping it would get approved and I'd get an official release :) I will give it a try later if I find some time. I'd like to know where those newer numbers came from though, and would such a change work with the older sensors too?

AlfaBravoX commented 3 years ago

@MarkCiliaVincenti , I think the info you are looking for is in the thread history already. Regarding numbers - no oscilloscope measurement was done. I dont have LAB ready now, just consider it as slight timing tolerance adjustment.

cpettis commented 3 years ago

I'm having the same problem, but when I try to upload the modified firmware OTA, I keep getting a "Upload buffer miscompare" error.

sfromis commented 3 years ago

Ideally, the bin file in the archive should've been the .bin.gz version for easier upgrading. Still, when upgrading via file upload, you will most often need to first upgrade to tasmota-minimal before upgrading to the intended new binary.

cpettis commented 3 years ago

Upgrading to tasmota-minimal first worked. Thanks.

sfromis commented 3 years ago

Building a binary with the suggested timing changes, my old Sonoff TH16 with SI7021 still works after upgrading.

Still I find it hard to say that the changes are what "should" be done, as the change to line 139 is reverting an earlier change, suggesting that "something" worked better with a delay of 35 instead of 30 milliseconds. Thus, the philosophical principle of "Chesterton's fence" seems to apply.

And the change to line 100, now with the same delay interval, has a comment referring to an issue in ESPEasy, https://github.com/letscontrolit/ESPEasy/issues/1798 where someone did some testing. However, without a deeper understanding, I can't argue either way here.

sfromis commented 3 years ago

Since the timing changes seems to help at least in some situations, I suppose that it could be feasible to make the timing configurable during build, or possibly also for runtime, as "something to try".

MarkCiliaVincenti commented 3 years ago

I built my own firmware using those changes too. So far so good!

AlfaBravoX commented 3 years ago

Since the timing changes seems to help at least in some situations, I suppose that it could be feasible to make the timing configurable during build, or possibly also for runtime, as "something to try". @sfromis when I shared the build with changed timers, I also suggested to introduce new SetOptionXXX register. I am not sure if devs got this message, so later perhaps I will issue PR

dbiczo commented 3 years ago

The new timings appear to be working with AM2301 and DS18B20 sensors as well as old and new SI7021 sensors. It would be nice to have a solution for the standard release version.

dbiczo commented 3 years ago

Thanks @AlfaBravoX & @ascillato2

MarkCiliaVincenti commented 3 years ago

Thanks, looking forward to the stable release, hope it won't be long!

AlfaBravoX commented 3 years ago

Thanks, looking forward to the stable release, hope it won't be long!

Sure happy i could help, it will be compiled as DEV build, that is compiled on daily basis http://ota.tasmota.com/tasmota/

colbat001 commented 2 years ago

It appears that this problem may have re-appeared, I've been using Sonoff TH16 with version1 of the SI71201 sensors which are fine. Have just purchased 6 additional sensors and these are stamped V2 on the PCB (both SI71201 and AM2031). When installed data is very patchy (around 40%), When swopped back to V1 sensors all is fine. Anyone else experiencing these problems ? Purchased the sensors at different times and suppliers so can't believe it the sensors - but the V2 ones are behaving different.

AlfaBravoX commented 2 years ago

Hmm painful. One idea on top of my mind would be to use just for testing older tasmota FW, which still have original timing values (see my post from [29 May 2021]) and load this FW to module and see if V2 sensors are working. Because it may be, that old values were fine-tunned for V2. If this is confirmed as working, then code needs to extended so, it will be able to check which sensor version is inserted and use relevant timing. Unfortunately I unable to comment if tasmota FW can distinguish version of inserted sensors.

mtausk commented 2 years ago

Hi all, I recently bought six pieces of th16 with si7021 (sonoff am2301 v2.0 2020-01-20) and I experience lots of gaps (null readings) at least on 4 of them, too, even after upgrade to the newest tasmota development version. It seems it is necessary to revisit/reopen this issue and work on the fix systematically. I think that ordinary users just like most of us are not capable of doing that and some oscilloscope professionals need to step in. image image

colbat001 commented 2 years ago

Yes, I agree have now tried previous Tasmota versions from 9,01 and am still experiencing the null readings. Would possibly be best if a set option value was added to facilitate the timings of these two events.(line 100 & 139) I've tried to have a look xsns_06_dht.ino but there now seems quite a few versions and although I know of someone who could possibly help modify this, its over my head of how to and where to start.

AlfaBravoX commented 2 years ago

I have also different versions of si7021 and my problem started when i had old ones and bought new ones 2 years later. Both were in the same box so I could not even visually determinate which one is which. The patch I made is still working for multiple versions, but perhaps problems that were reported 5 days ago are for another version than those two I tested on. I am not sure how many versions are being manufactured and what electrical components are used. At such precise timing in microseconds range we are speaking here, even using same component value (ie. capacitors from different vendors) can produce problems. I was proposing to introduce SetOptionXXX to hold timing in DB earlier, but there is maybe smarter solution I am not aware of.

AlfaBravoX commented 2 years ago

in https://github.com/arendst/Tasmota/pull/7468 there is specification and datasheet for SI7021:

SI7021 Specs: https://www.silabs.com/documents/public/data-sheets/Si7021-A20.pdf

Protocol: Reverse-engineered on https://github.com/arendst/Tasmota/issues/735 (comment):

MCU PULLS LOW data bus for at 500us to activate sensor MCU PULLS UP data bus for ~40us to ask sensor for response <-- this value is currently set to 30us now at line 103 at xsns_06_dht.ino SENSOR starts sending data (LOW 40us then HIGH ~25us for "0" or ~75us for "1") SENSOR sends "1" start bit as a response SENSOR sends 16 bits (2 bytes) of a humidity with one decimal (i.e. 35.6% is sent as 356) SENSOR sends 16 bits (2 bytes) of a temperature with one decimal (i.e. 23.4C is sent as 234) SENSOR sends 8 bits (1 byte) checksum of 4 data bytes

Can someone who owns not working SI7021, fork xsns_06_dht.ino and change line 104 to 40us instead of 30um, compile, load and test?

barbudor commented 2 years ago

IMHO everybody is misunderstanding those 20us (2 years ago), 30us (last year) or 40us. What I'm expecting these 20us, 30us or 40us to be is not the MCU/ESP to actively maintaining the signal HIGH but most probably a different response time from the sensor that has changed across different generations/models.

What I don't see in this code is where the pin is changed from OUTPUT to INPUT. AFAIK, by default the ESP pins are not open-drain. So if the ESP is maintaining a actively/forced HIGH signal, it's just preventing the sensor to drive the line low for its start-bit and from there, everything is probably going wrong.

From my point of view, right after 95: digitalWrite(dht_pin_out, HIGH), the pin should be switched to INPUT and the ESP should wait for the start bit without any additional delay. Only from the falling edge of the start bit from the sensor, timings should be considered.

AlfaBravoX commented 2 years ago

@barbudor interesting. now is time to test it. unfortunately I dont have non working SI7021 available, so i cannot serve.

jurwouw75 commented 1 year ago

OK, i did some deep dive into timing and as result, I modified two values in xsns_06_dht.ino:

in line 100 case GPIO_SI7021: // iTead SI7021 delayMicroseconds(30); <<-- is new val replacing 20

and in line 139

if (DhtWaitState(sensor, 0) && DhtWaitState(sensor, 1) && DhtWaitState(sensor, 0)) { for (i = 0; i < 40; i++) { if (!DhtWaitState(sensor, 1)) { break; } delayMicroseconds(30); <<-- is new val replacing 35

For me it is not clear if the problem lays in unreliable 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 .bin with modified values and loaded them into TH16 and TH10 with different SI7021 probes connected (one was working, one was not)

With above modified values, reading stabilised and no more error messages are in webloag at both THx versions. Sure it needs more stabilisation time and observation to say, that this is solution. If @dbiczo or anyone else wants to try , here is modified .bin: tasmota_ob_dht_mod.bin.zip

Last but not least, @ascillato2 if this is solution, how about to introduce new SetOptionXXX to enable end users to fine tune probes timing themself? It can reduce many posts in different forums how to solve such flickery connections.

This man deserves an award You solved a problem for me that has been bugging me for over a year!

calum-mcfarlane commented 1 year ago

Still seeing this issue (ie, lots of null values returned) in Tasmota 12.3.1 flashed onto a Sonoff TH16. What's strange (to me) is that sometimes it will work fine for hours at a time, and at other times it will return mostly null values.

I have another TH16 with Tasmota 12.2 on it, and that one is working just fine (never returns null values). The Sonoff THS01 sensors are "V1.0" according to the PCB inside the plastic housing. I'm not in a position to build my own versions of Tasmota but I think this latest version will have the timing changes from this thread in it.

I don't know if the comment by @barbudor is relevant here but the timing changes have definitely not provided a universal fix for this issue.

rt400 commented 1 year ago

i have the same problem sometime i have reading and sometime i got NULL connect to esp32 with tasmota 12.3.1.4v

dragonflyuk commented 1 year ago

I'm also seeing it in the latest version 12.4.0, I previously had the same Sonoff, with the same sensor working reliably under version 6.xx

I know I should have left things as they were, but new devices, seemed to have better WiFi, so I reflashed with fresh firmware, to bring them up to date.

AlfaBravoX commented 1 year ago

@ascillato2 we have 3 more reports that sensor connectivity remains unreliable. i am seeing that Dht driver has now multiple versions. Can you share what is current direction of fixing this ? According what I see in ChangeLog 20230215 - v7 Dht driver should have this addressed, but it looks there are still issues.

arendst commented 1 year ago

Commenting in closed issues doesn't help you or others.

Read the changelogs and use command dhtdelays to configure your sensors specific delays.

As you noticed there are/were already 7versions of this driver. Three of them are still in the repository. Feel free to fall back to a previous version and try your luck.

In the end you'll end up with the latest version of the driver allowing the delay change by user.

AlfaBravoX commented 1 year ago

Thanks @arendst for explanation this. And I am happy that my initial proposal was implemented ;-) IMHO this will bring final stability and solution:

@AlfaBravoX May 29, 2021 - how about to introduce new SetOptionXXX to enable end users to fine tune probes timing themself? It can reduce many posts in different forums how to solve such flickery connections.

oh yes I know

@arendst Commenting in closed issues doesn't help you or others.

People were still reporting issue here, so thanks for watching this even if issue is marked closed.

dragonflyuk commented 1 year ago

For the benefit of others that find this thread, and missed the relevance of the release notes like myself, I'm seeing a much improved reliability, after using the DhtDelay command. I found the timings in another thread posted by @arendst ,

DhtDelay 500,40

arendst commented 1 year ago

Take a look here (https://github.com/arendst/Tasmota/issues/17944) where a script is used to find an equilibrium