Tasmota 9.4 contact with SI7021 is unreliable #12180
Comments
|
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. |
|
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 |
|
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. |
|
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. |
|
@ascillato2 , based on evidence from @dbiczo , can you please reopen the issue? |
|
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. |
ascillato2
added
awaiting feedback
|
OK, i did some deep dive into timing and as result, I modified two values in in line 100 and in line 139
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: 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. |
|
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. |
|
@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
|
|
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? |
|
@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. |
|
I'm having the same problem, but when I try to upload the modified firmware OTA, I keep getting a "Upload buffer miscompare" error. |
|
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. |
|
Upgrading to tasmota-minimal first worked. Thanks. |
|
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, letscontrolit/ESPEasy#1798 where someone did some testing. However, without a deeper understanding, I can't argue either way here. |
|
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". |
|
I built my own firmware using those changes too. So far so good! |
|
|
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. |
as per arendst#12180 adjusting slightly timers
|
Thanks @AlfaBravoX & @ascillato2 |
|
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/ |
|
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. |
|
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. |
|
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. |
|
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 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. |
|
in https://github.com/arendst/Tasmota/pull/7468 there is specification and datasheet for SI7021: SI7021 Protocol: MCU PULLS LOW data bus for at 500us to activate sensor 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? |
|
IMHO everybody is misunderstanding those 20us (2 years ago), 30us (last year) or 40us. What I don't see in this code is where the pin is changed from OUTPUT to INPUT. From my point of view, right after |
|
@barbudor interesting. now is time to test it. unfortunately I dont have non working |
ascillato2
removed
the
awaiting feedback
This man deserves an award |
|
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. |
|
i have the same problem |
|
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. |
|
@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. |
|
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. |
|
Thanks @arendst for explanation this. And I am happy that my initial proposal was implemented ;-) IMHO this will bring final stability and solution:
oh yes I know
People were still reporting issue here, so thanks for watching this even if issue is marked closed. |
|
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 ,
|
|
Take a look here (#17944) where a script is used to find an equilibrium |
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 pulseand
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
Backlog Template; Module; GPIO 255:Backlog Rule1; Rule2; Rule3:Status 0:weblogto 4 and then, when you experience your issue, provide the output of the Console log: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.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: