AM2301 loses connection after a couple of hours

[rhavin42]

Make sure these boxes are checked [x] before submitting your issue - Thank you!

• [X] Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues)
• [X] Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting)
• [X] Searched the problem in the forum (https://forum.digital-pig.com/)
• [X] Searched the problem in the discussion group (https://groups.google.com/d/forum/sonoffusers)
• [X] Hardware used : sonoff basic
• [X] Provide the output of command status 0 :

  
  20:57:26 CMD: status 0
  20:57:26 RSL: Received Topic /status, Data Size 1, Data 0

20:57:26 RSL: Group 0, Index 1, Command STATUS, Data 0 20:57:26 MQT: stat/bigfridge/STATUS = {"Status":{"Module":1,"FriendlyName":["Big Fridge"],"Topic":"bigfridge","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}} 20:57:26 MQT: stat/bigfridge/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://domus1:80/api/arduino/sonoff.ino.bin","RestartReason":"Power on","Uptime":"0T15:06:10","StartupUTC":"2018-07-09T04:51:16","Sleep":0,"BootCount":79,"SaveCount":157,"SaveAddress":"F8000"}} 20:57:26 MQT: stat/bigfridge/STATUS2 = {"StatusFWR":{"Version":"5.14.0","BuildDateTime":"2018-05-15T15:29:54","Boot":6,"Core":"2_30","SDK":"1.5.3(aec24ac9)"}} 20:57:26 MQT: stat/bigfridge/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":4,"SysLog":0,"LogHost":"domus1","LogPort":514,"SSId":["automation","porkerpantle"],"TelePeriod":300,"SetOption":["00000109","55818000"]}} 20:57:26 MQT: stat/bigfridge/STATUS4 = {"StatusMEM":{"ProgramSize":526,"Free":476,"Heap":16,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3}} 20:57:26 MQT: stat/bigfridge/STATUS5 = {"StatusNET":{"Hostname":"bigfridge-2772","IPAddress":"192.168.1.23","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"84:F3:EB:A7:4A:D4","Webserver":2,"WifiConfig":1}} 20:57:26 MQT: stat/bigfridge/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.102","MqttPort":1883,"MqttClientMask":"DVES%06X","MqttClient":"DVES_A74AD4","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 20:57:27 MQT: stat/bigfridge/STATUS7 = {"StatusTIM":{"UTC":"Mon Jul 09 19:57:26 2018","Local":"Mon Jul 09 20:57:26 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":1,"Sunrise":"04:57","Sunset":"20:53"}} 20:57:27 DHT: Timeout waiting for start signal high pulse 20:57:27 MQT: stat/bigfridge/STATUS10 = {"StatusSNS":{"Time":"2018-07-09T20:57:27"}} 20:57:27 MQT: stat/bigfridge/STATUS11 = {"StatusSTS":{"Time":"2018-07-09T20:57:27","Uptime":"0T15:06:11","Vcc":3.221,"POWER":"OFF","Wifi":{"AP":2,"SSId":"porkerpantle","RSSI":92,"APMac":"E4:F4:C6:F6:79:75"}}}

**(Please, remember to close the issue when the problem has been addressed)**

I have a Sonoff Basic connected to a AM2302 (DHT22) It's wired up to the sonoff using approx 5 ft of flat gray phone line cord. The AM2302 is mounted to a pre-built board, like [this](https://www.aliexpress.com/item/1PCS-DHT22-Digital-Temperature-and-Humidity-Sensor-AM2302-Module-PCB-with-Cable-For-arduino/32800098583.html)

This PCB already has a 4.7k resistor between 3.3 and data pin, along with a capacitor (I've also tried removing both the cap and resistor since the 2302 has a built in 4.7k resistor with the same result) This setup works flawlessly until I place the sensor in my refrigerator or freezer, with the sonoff outside the fridge and just the flat gray phone cable with sensor running up under the door and to the bottom of the fridge.

This works great for anywhere between 3-12 hours when it stops recording temp/humidity and starts logging

````DHT: Timeout waiting for start signal high pulse" ````

The only way to recover from this is to disconnect the Sonoff from AC power and plug it back in again. Disconnecting the sensor, reconnecting it and doing a restart from the web interface will not fix it.

I cannot for the life of me figure out what is going on to cause this issue when I place one of these in the fridge or freezer (It's a pretty standard stainless steel side by side fridge/freezer combo). When it's working it logs ~40-44 F for the fridge, and ~0-5F for the freezer.

I have another sonoff configured exactly the same way in a mini fridge behind the bar, and it's been working flawlessly for about a week, with about the same temp range. So I figured something was wrong with either the sonoff or the temp sensor, so I moved the one that was working from the mini fridge to the big fridge and sure enough within about 3 hours it stopped reading new temps and starting logging that error message.

Yesterday my new order of Sonoffs and AM2302s came in, so I spent the evening flashing Tasmota on them and hooking up the AM2302s and I put 3 of the sensors in the fridge, I checked this morning and only 1 of the 3 was still working

I've tried everything I can think of, connecting the sensor to GPI14, GPIO1 and GPIO3, switching out the flat 4 wire phone cable for a cat5 cable, moving the sonoff to different power outlets, all with the same results, it works for a few hours then quits.

I can't for the life of me figure out what sort of black hole is contained in my fridge but something strange is going on. I have an order of DS18B20s on order and will try with them when they arrive since I don't really need humidity, just temperature.

here are the statuses of the other 3 modules I connected last night
## Device 1 (Still Working)

10:40:22 RSL: Received Topic /status, Data Size 1, Data 0 10:40:22 RSL: Group 0, Index 1, Command STATUS, Data 0 10:40:22 MQT: stat/sonoff/STATUS = {"Status":{"Module":1,"FriendlyName":["Sonoff"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}} 10:40:22 MQT: stat/sonoff/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://sonoff.maddox.co.uk/tasmota/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T13:13:41","StartupUTC":"2018-07-11T04:26:41","Sleep":0,"BootCount":6,"SaveCount":20,"SaveAddress":"F8000"}} 10:40:22 MQT: stat/sonoff/STATUS2 = {"StatusFWR":{"Version":"5.14.0","BuildDateTime":"2018-05-15T15:29:54","Boot":6,"Core":"2_30","SDK":"1.5.3(aec24ac9)"}} 10:40:23 MQT: stat/sonoff/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":4,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["porkerpantle",""],"TelePeriod":300,"SetOption":["00008109","55818000"]}} 10:40:23 MQT: stat/sonoff/STATUS4 = {"StatusMEM":{"ProgramSize":526,"Free":476,"Heap":19,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3}} 10:40:23 MQT: stat/sonoff/STATUS5 = {"StatusNET":{"Hostname":"sonoff-3724","IPAddress":"192.168.1.26","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"84:F3:EB:8C:4E:8C","Webserver":2,"WifiConfig":2}} 10:40:23 MQT: stat/sonoff/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.102","MqttPort":1883,"MqttClientMask":"DVES%06X","MqttClient":"DVES_8C4E8C","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 10:40:23 MQT: stat/sonoff/STATUS7 = {"StatusTIM":{"UTC":"Wed Jul 11 17:40:23 2018","Local":"Wed Jul 11 10:40:23 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":-7,"Sunrise":"20:59","Sunset":"12:52"}} 10:40:23 DHT: Received 01, FE, 00, 2E, 2D =? 2D 10:40:23 MQT: stat/sonoff/STATUS10 = {"StatusSNS":{"Time":"2018-07-11T10:40:23","AM2301":{"Temperature":40.3,"Humidity":51.0},"TempUnit":"F"}} 10:40:23 MQT: stat/sonoff/STATUS11 = {"StatusSTS":{"Time":"2018-07-11T10:40:23","Uptime":"0T13:13:42","Vcc":3.205,"POWER":"OFF","Wifi":{"AP":1,"SSId":"porkerpantle","RSSI":94,"APMac":"E4:F4:C6:F6:79:75"}}}

## Device 2 (Stopped Working)

10:40:42 RSL: Received Topic /status, Data Size 1, Data 0 10:40:42 RSL: Group 0, Index 1, Command STATUS, Data 0 10:40:42 MQT: stat/sonoff/STATUS = {"Status":{"Module":1,"FriendlyName":["Sonoff"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}} 10:40:42 MQT: stat/sonoff/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://sonoff.maddox.co.uk/tasmota/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T13:13:07","StartupUTC":"2018-07-11T04:27:35","Sleep":0,"BootCount":7,"SaveCount":23,"SaveAddress":"F5000"}} 10:40:43 MQT: stat/sonoff/STATUS2 = {"StatusFWR":{"Version":"5.14.0","BuildDateTime":"2018-05-15T15:29:54","Boot":6,"Core":"2_30","SDK":"1.5.3(aec24ac9)"}} 10:40:43 MQT: stat/sonoff/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":4,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["porkerpantle",""],"TelePeriod":300,"SetOption":["00008109","55818000"]}} 10:40:43 MQT: stat/sonoff/STATUS4 = {"StatusMEM":{"ProgramSize":526,"Free":476,"Heap":19,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3}} 10:40:43 MQT: stat/sonoff/STATUS5 = {"StatusNET":{"Hostname":"sonoff-6739","IPAddress":"192.168.1.27","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"B4:E6:2D:3A:DA:53","Webserver":2,"WifiConfig":2}} 10:40:43 MQT: stat/sonoff/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.102","MqttPort":1883,"MqttClientMask":"DVES%06X","MqttClient":"DVES_3ADA53","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 10:40:43 MQT: stat/sonoff/STATUS7 = {"StatusTIM":{"UTC":"Wed Jul 11 17:40:43 2018","Local":"Wed Jul 11 10:40:43 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":-7,"Sunrise":"20:59","Sunset":"12:52"}} 10:40:43 DHT: Timeout waiting for start signal high pulse 10:40:43 MQT: stat/sonoff/STATUS10 = {"StatusSNS":{"Time":"2018-07-11T10:40:43"}} 10:40:43 MQT: stat/sonoff/STATUS11 = {"StatusSTS":{"Time":"2018-07-11T10:40:43","Uptime":"0T13:13:08","Vcc":3.218,"POWER":"OFF","Wifi":{"AP":1,"SSId":"porkerpantle","RSSI":88,"APMac":"E4:F4:C6:F6:79:75"}}}

## Device 3 (Stopped Working)

10:41:04 RSL: Group 0, Index 1, Command STATUS, Data 0 10:41:04 MQT: stat/sonoff/STATUS = {"Status":{"Module":1,"FriendlyName":["Sonoff"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}} 10:41:04 MQT: stat/sonoff/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://sonoff.maddox.co.uk/tasmota/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T13:13:11","StartupUTC":"2018-07-11T04:27:53","Sleep":0,"BootCount":9,"SaveCount":26,"SaveAddress":"FA000"}} 10:41:04 MQT: stat/sonoff/STATUS2 = {"StatusFWR":{"Version":"5.14.0","BuildDateTime":"2018-05-15T15:29:54","Boot":31,"Core":"2_30","SDK":"1.5.3(aec24ac9)"}} 10:41:04 MQT: stat/sonoff/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":3,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["porkerpantle",""],"TelePeriod":300,"SetOption":["00008109","55818000"]}} 10:41:04 MQT: stat/sonoff/STATUS4 = {"StatusMEM":{"ProgramSize":526,"Free":476,"Heap":19,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3}} 10:41:05 MQT: stat/sonoff/STATUS5 = {"StatusNET":{"Hostname":"sonoff-3108","IPAddress":"192.168.1.28","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"DC:4F:22:4B:6C:24","Webserver":2,"WifiConfig":2}} 10:41:05 MQT: stat/sonoff/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.102","MqttPort":1883,"MqttClientMask":"DVES%06X","MqttClient":"DVES_4B6C24","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 10:41:05 MQT: stat/sonoff/STATUS7 = {"StatusTIM":{"UTC":"Wed Jul 11 17:41:05 2018","Local":"Wed Jul 11 10:41:05 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":-7,"Sunrise":"20:59","Sunset":"12:52"}} 10:41:05 DHT: Timeout waiting for start signal high pulse 10:41:05 MQT: stat/sonoff/STATUS10 = {"StatusSNS":{"Time":"2018-07-11T10:41:05"}} 10:41:05 MQT: stat/sonoff/STATUS11 = {"StatusSTS":{"Time":"2018-07-11T10:41:05","Uptime":"0T13:13:12","Vcc":3.142,"POWER":"OFF","Wifi":{"AP":1,"SSId":"porkerpantle","RSSI":78,"APMac":"E4:F4:C6:F6:79:75"}}}

[ascillato]

Hi,

Recently, several sensor drivers were updated. Can you compile and try this last tasmota version of the development branch?

[rhavin42]

Yeah, I can try that when I get home this evening, just need to get a build env setup.

[rhavin42]

same issue using 6.1.0a started it up at 12:33:10 failed at 14:20:12

so this time it lasted just under 2 hours. I've had it go for as short as about an hour, and as long as about 6 hours before this failure appears. it started spamming me every 2-3 seconds with 'Timeout waiting for start signal high pulse.' Here is the log right when it failed.

14:19:34 WIF: Checking connection...
14:19:34 WIF: Connected
14:19:56 WIF: Checking connection...
14:19:56 WIF: Connected
14:20:12 DHT: Timeout waiting for start signal high pulse
14:20:14 DHT: Timeout waiting for start signal high pulse
14:20:17 DHT: Timeout waiting for start signal high pulse
14:20:17 WIF: Checking connection...
14:20:17 WIF: Connected
14:20:19 DHT: Timeout waiting for start signal high pulse
14:20:21 DHT: Timeout waiting for start signal high pulse
14:20:23 DHT: Timeout waiting for start signal high pulse
14:20:25 DHT: Timeout waiting for start signal high pulse
14:20:28 DHT: Timeout waiting for start signal high pulse

again here is the status 0 output

15:26:54 SRC: WebConsole from 192.168.1.100
15:26:54 RSL: Received Topic /status, Data Size 1, Data 0
15:26:54 RSL: Group 0, Index 1, Command STATUS, Data 0
15:26:54 MQT: stat/bigfridge/STATUS = {"Status":{"Module":1,"FriendlyName":["Big Fridge"],"Topic":"bigfridge","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}}
15:26:54 MQT: stat/bigfridge/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://domus1:80/api/arduino/sonoff.ino.bin","RestartReason":"Software/System restart","Uptime":"0T02:53:44","StartupUTC":"2018-07-11T19:33:10","Sleep":0,"BootCount":86,"SaveCount":173,"SaveAddress":"F5000"}}
15:26:54 MQT: stat/bigfridge/STATUS2 = {"StatusFWR":{"Version":"6.1.0a","BuildDateTime":"2018-07-11T11:41:11","Boot":6,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
15:26:54 MQT: stat/bigfridge/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":4,"SysLog":3,"LogHost":"192.168.1.102","LogPort":514,"SSId":["automation","porkerpantle"],"TelePeriod":300,"SetOption":["00000109","55818000"]}}
15:26:54 MQT: stat/bigfridge/STATUS4 = {"StatusMEM":{"ProgramSize":541,"Free":460,"Heap":16,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3,"Features":["00000809","0FDAE794","0C000000","37B6179E","00000000"]}}
15:26:54 MQT: stat/bigfridge/STATUS5 = {"StatusNET":{"Hostname":"bigfridge-2772","IPAddress":"192.168.1.23","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"84:F3:EB:A7:4A:D4","Webserver":2,"WifiConfig":1}}
15:26:54 MQT: stat/bigfridge/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.102","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_A74AD4","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
15:26:54 MQT: stat/bigfridge/STATUS7 = {"StatusTIM":{"UTC":"Wed Jul 11 22:26:54 2018","Local":"Wed Jul 11 15:26:54 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":-7,"Sunrise":"20:59","Sunset":"12:52"}}
15:26:54 MQT: stat/bigfridge/STATUS10 = {"StatusSNS":{"Time":"2018-07-11T15:26:54","AM2301":{"Temperature":nan,"Humidity":nan},"TempUnit":"F"}}
15:26:54 MQT: stat/bigfridge/STATUS11 = {"StatusSTS":{"Time":"2018-07-11T15:26:54","Uptime":"0T02:53:44","Vcc":3.219,"POWER":"OFF","Wifi":{"AP":2,"SSId":"porkerpantle","RSSI":66,"APMac":"E4:F4:C6:F6:79:75"}}}

I'm still really confused. The one Sonoff/AM2302 is still up and working now for over 18 hours, while the other 3 have failed.

I'm going to take the sensor out of the fridge, and just place it next to the sonoff, restart it and see if it fails.

[ascillato]

Seems a powering problem or sensor problem. Did you measure the voltage?

[rhavin42]

Now this is interesting. Ones that failed: 3.318v @ sensor 3.305v @ sensor 3.306v @ sensor

One that's still working: 3.324v @ sensor

Do you think I'm that close to tolerance on the sensors that .006v (from the highest voltage from the ones that failed, to the one that's still working) is just enough to get it working? I know that the AM2301 is supposedly rated for 3.3-6v operating voltage.

I went and measured the voltage of the one in the other fridge that's been working for over a week and it's at 3.307v

The temps inside the fridges are about the same, 2-3 F difference between them, with the mini fridge (working) being higher.

[arendst]

Could be cable length and crosstalk problems too.

Try to configure AM2301 as SI7021 and see what happens...

[rhavin42]

So it still failed after the standard 3ish hours even just sitting at room temp. I have it setup as a SI7021 now and will report back success/failure.

Could be cable length and crosstalk problems too.

As far as this, the cable is about 5ft long of standard 28awg flat 4 conductor phone cable with:

black -> gnd red -> 3.3v green -> signal yellow -> n/c

from my understanding of crosstalk, putting a ground wire between the signal and any other wires would help. So do you think that hooking it up like this would help eliminate crosstalk?

black -> gnd red -> 3.3v green -> gnd yellow -> signal

Edit: I also have access to spools of cat6 cable, but had it fail when I hooked it up this way: Blue -> 3.3v Brown -> gnd Orange -> signal

I know that cat6 cable is supposed to reduce crosstalk, but I'm not sure what wires of what pairs to connect to what to reduce it. I've tried searching, but of course all the results refer to high frequency multi wire network communication and nothing really about power + 1 wire data over ethernet.

[GasTurbineMan]

I am having a similar issue with 2 DS18B20 sensors attached to a recently flashed 6.1.0a core 2.3.0 devices. I am building my own bins, and have 2 other devices running 2 sensors each without issue. My initial issue was on my Sonoff Basic "Device 31". I configured module GPIO14 as 04 DS18x20 just like the others and at first, both sensors appeared on the Web Interface as would expect. But next morning, I noticed they no longer appeared on Web Interface. After some failed testing, I finally swapped "Device 31" out with a newly flashed "Device 35". Powered up Device 35 and configured as 04 DS18x20 and both sensors showed up with valid temperature readings. Within a couple of hours, no sensors detected. I reflashed #31 with same bin and hooked sensors back to it. It initially saw them but within a few minutes, they disappeared. My connections are short (less than 3 meters) and I am using a 4.7K ohm resistor (also tried 10k ohm). I then flashed Theo's "all sensors" bin - but no success with it either.

Looking at console, on restart, I see the following: 00:00:00 Project sonoff Sonoff (Topic sonoff, Fallback DVES_A7D41C, GroupTopic sonoffs) Version 6.1.0a-2_3_0 00:00:00 WIF: Connecting to AP1 Wind in mode 11N as sonoff-5148... 00:00:03 WIF: Connected 00:00:03 HTP: Web server active on sonoff-5148 with IP address 172.16.85.31 00:00:03 UPP: Multicast (re)joined 00:00:04 MQT: Attempting connection... 00:00:05 MQT: Connected 00:00:05 MQT: tele/sonoff/LWT = Online (retained) 00:00:05 MQT: cmnd/sonoff/POWER = 00:00:05 MQT: stat/sonoff/RESULT = {"Command":"Unknown"} 00:00:05 MQT: tele/sonoff/INFO1 = {"Module":"Sonoff Basic","Version":"6.1.0a","FallbackTopic":"DVES_A7D41C","GroupTopic":"sonoffs"} 00:00:05 MQT: tele/sonoff/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff-5148","IPAddress":"172.16.85.31"} 00:00:05 MQT: tele/sonoff/INFO3 = {"RestartReason":"Fatal exception:3 flag:2 (EXCEPTION) epc1:0x4020ccd9 epc2:0x00000000 epc3:0x00000000 excvaddr:0x40035778 depc:0x00000000"} 00:00:05 MQT: stat/sonoff/RESULT = {"POWER":"ON"}

Not sure if the "Fatal exception:3 flag 2" in tele/sonoff/INFO3 is a clue or not. I have some more sensors arriving tomorrow - maybe I have bad sensors.

[GasTurbineMan]

FYI, in my user_config.h file, I have #define USE_DS18x20_LEGACY enabled.

[rhavin42]

what kind of wire are you using to connect your sensors to the sonoff? and how do you have it pinned?

I tried the suggestions from arendst yesterday, and configured my AM2302 to SI7021 but same issue, failed with same message within a few hours.

I'm going to try re-wiring the sensors today and tie a ground wire between signal and 3.3v, just to see what happens, but I don't have high hopes.

I just got my batch of DS18B20 in yesterday, I have a rig setup with 3 of them going on a breadboard, and like 1M of cat6 cable, so far they have been perfect. I'm still waiting for the actual production mounting boards I ordered to come in before I switch out a bunch of my AM2302s to DS18B20s and we'll see what happens.

Oddly enough I have about 3 other AM2302s spread around the house with cable lengths varying from 6 inches to 1M and they have not had an issue ever. I really thing that sensor->sonoff combos just need to get along perfectly for these to work, I guess I got lucky with the other 3 that are working.

[GasTurbineMan]

All of my sensors are factory wiring (non shielded) less than 2 meters in length. On the ones I have that are working (with v6.1.0a) I actually spliced in some CAT5 cable to make the total length around 5-6 meters, teed into another factory 2 meter cable going onto the Sonoff. It works well. The other one I have working is just 2 sensors, 2 meters each wired to a Sonoff Basic. It works well.

The ones I have problems with is 2 sensors from same batch as above, 2 meters each in length, all factory cables, non-shielded. Today, I moved the pull up resistor from the terminal strip located less than 1 meter away from the Sonoff directly to the Sonoff 5-pin header. At first, the WebGui showed the 2 sensors and I thought my problem had been solved, but within 5 minutes, the sensors were no longer detected.

My non-common denominator is the ones that are working are a different batch of Sonoff Basics. They arrived with header holes open. The 2 Sonoffs that are acting up are from a batch that arrived with pin-holes filled with solder. I cleared them out and soldered in my header. They flashed without issue, so I don’t think there is anything wrong with them – but that is the ONLY difference I know of.

From: rhavin42 notifications@github.com Sent: Friday, July 13, 2018 2:17 PM To: arendst/Sonoff-Tasmota Sonoff-Tasmota@noreply.github.com Cc: GasTurbineMan rglokey@gmail.com; Comment comment@noreply.github.com Subject: Re: [arendst/Sonoff-Tasmota] AM2301 loses connection after a couple of hours (#3187)

what kind of wire are you using to connect your sensors to the sonoff? and how do you have it pinned?

I tried the suggestions from arendst yesterday, and configured my AM2302 to SI7021 but same issue, failed with same message within a few hours.

I'm going to try re-wiring the sensors today and tie a ground wire between signal and 3.3v, just to see what happens, but I don't have high hopes.

I just got my batch of DS18B20 in yesterday, I have a rig setup with 3 of them going on a breadboard, and like 1M of cat6 cable, so far they have been perfect. I'm still waiting for the actual production mounting boards I ordered to come in before I switch out a bunch of my AM2302s to DS18B20s and we'll see what happens.

Oddly enough I have about 3 other AM2302s spread around the house with cable lengths varying from 6 inches to 1M and they have not had an issue ever. I really thing that sensor->sonoff combos just need to get along perfectly for these to work, I guess I got lucky with the other 3 that are working.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3187#issuecomment-404928010 , or mute the thread https://github.com/notifications/unsubscribe-auth/AlsMjCPf4ZozKsSa3Wg1RcyUJMlCd6H2ks5uGPIlgaJpZM4VLkMJ . https://github.com/notifications/beacon/AlsMjIV7t--dUT-8sjcfCyMRPO1fC1JXks5uGPIlgaJpZM4VLkMJ.gif

[GasTurbineMan]

I actually just plugged Sonoff#31 back in and the sensors showed up. Reading in degrees F as configured, I went to the console to monitor activity. A few minutes later, I see where it lost connection to my MQTT server and had to reestablish connection. When it did, the next tele/sonoff31/SENSOR readout showed 32 degrees C each and then no longer appeared.

[rhavin42]

From what I've gotten, there are 2 versions: Sonoff TH_V1.1 2017-5-5 and Sonoff Basic R2 V1.0 2017-10-11

The last batch that I got, that I've been hooking up as temp sensors are all the Basic R2 versions. All but one of the TH_V1.1s that I have are shoved in wall boxes, and I'm not about to go fish them out just to test to see if temp sensors work better on them.

I'm still waiting for my DS18B20 mounting boards to come in, but the 3 that I have had hooked up via breadboard to a TH_V1.1 have been rock solid for a few days now.

[rhavin42]

So I wired up a new wire to the AM2302 with a ground wire between 3.3v and signal, so the wiring now looks like this: black -> gnd red -> 3.3v green -> gnd yellow -> signal

Same issue, after about 3 hours it loses communication to sensor. Just to try something different, I hooked up a different AM2302 to that Sonoff to see if it behaved better. My boards for the DS18B20s should be here today sometime, gonna get them soldered up and see what happens with this stupid thing.

[GasTurbineMan]

This is an early update, but I swapped out a known good Sonoff Basic TH_V1.1 to the 2 sensors that had been giving me issues on the R2 Sonoff Basic and the TH_V1 is working great so far with the 2 sensors that had "disappeared" earlier. I am going to let it sit and watch the console for a few hours, but early thoughts are the Sonoff Basic R2 V1.0 2017-10-11 may have an issue with sensors.

Odd that the R2's worked initially but then failed to see the sensors. I will report back to confirm whether or not it is definitely a R2 board issue.

[GasTurbineMan]

My issues with dropped sensors is definitely limited to the R2 boards I saw a comment by Theo in another post that cited the R2 has a different power supply circuit which may be causing our issues.

[rhavin42]

I finally got my DS18B20s with resistor/capacitor board on them a couple of days ago. swapped out the AM2302 sensors for DS18B20. Everything has been 100% rock solid for going on 3 days now. I noticed that in addition to communication issues, the AM2302s temperature readings were all over the map, some as high as 5 degrees F off from a known good calibrated thermometer I have.

I think I'm going to just give up on the AM2302 sensors and just use the 18B20 from here on out. As I don't really have need for humidity in addition to temperature.

Just to check in with you, GasTurbineMan, you said you were using the DS18B20s and having issues with them? because mine are all now working great on V2 or V1.1 boards. my cables are all about 1M in length, using just the 4 conductor flat phone wire I described earlier. One of my V2s is even running dual sensors. I did remove one of the 4.7k resistors from the second sensor board to ensure I would only have 1 pullup resistor in the chain and that pullup resistor is sitting right next to one of the sensors.

[GasTurbineMan]

I am running multiple DS18B20’s with a single pull up resistor mounted at the Sonoff device. My sensors are the waterproof design (round ¼” sensor about 2” long) No issues on any of my original Sonoff Basics but having issues with the R2 Sonoff Basic.

I will do some more research on the net and look into adding a capacitor as well since you are not having any issues.

From: rhavin42 notifications@github.com Sent: Friday, July 20, 2018 2:16 PM To: arendst/Sonoff-Tasmota Sonoff-Tasmota@noreply.github.com Cc: GasTurbineMan rglokey@gmail.com; Comment comment@noreply.github.com Subject: Re: [arendst/Sonoff-Tasmota] AM2301 loses connection after a couple of hours (#3187)

I finally got my DS18B20s with resistor/capacitor board on them a couple of days ago. swapped out the AM2302 sensors for DS18B20. Everything has been 100% rock solid for going on 3 days now. I noticed that in addition to communication issues, the AM2302s temperature readings were all over the map, some as high as 5 degrees F off from a known good calibrated thermometer I have.

I think I'm going to just give up on the AM2302 sensors and just use the 18B20 from here on out. As I don't really have need for humidity in addition to temperature.

Just to check in with you, GasTurbineMan, you said you were using the DS18B20s and having issues with them? because mine are all now working great on V2 or V1.1 boards. my cables are all about 1M in length, using just the 4 conductor flat phone wire I described earlier. One of my V2s is even running dual sensors. I did remove one of the 4.7k resistors from the second sensor board to ensure I would only have 1 pullup resistor in the chain and that pullup resistor is sitting right next to one of the sensors.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3187#issuecomment-406701373 , or mute the thread https://github.com/notifications/unsubscribe-auth/AlsMjEA-_gccmyuEdwGGcmQdERqPYCP-ks5uIiyGgaJpZM4VLkMJ . https://github.com/notifications/beacon/AlsMjDXL0AQ79RHUh6fkJIzWIBGH9E-xks5uIiyGgaJpZM4VLkMJ.gif

[GasTurbineMan]

I am running into conflicting instructions on exactly where to put the capacitor in the sensor wiring connection. May be due to different issues that are the capacitor is trying to resolve (ie noise, RF, etc)

In the mean time, I have hooked up my same 2 sensors that were disappearing on my 31 and 35 devices to my 33 device and it has been rock solid for over 24 hours. All 3 Sonoffs are from same batch and all flashed with v6.1.1b but seems that 33 got reflashed after PlatformIO did some updates of its own. Maybe that did something?

Would be interested in knowing if anyone else out there is running R2 Sonoff Basics with DS18B20 sensors and NOT having any issues.

[GasTurbineMan]

I now have multiple DS18B20 sensors working rock solid on 3 different Sonoff Basic R2's (2017-10-11 board), so my earlier thought that there may be an issue running sensors on the R2 was inaccurate. Not really sure why they were not working on my original 2 R2's - could have been a driver issue on the bin build which has since been updated - but in any case, my issue has been resolved.

[ascillato2]

Hi,

Have you managed to solve your issue?

[rhavin42]

My issues on this seem to have been solved. I'm chalking it up to a batch of bad AM2302 sensors. I can't think of anything else it could have been. It looks like GasTurbineMan's issues have been resolved as well. I'll go ahead and mark this as closed.

[crxporter]

rhavin - did you ever figure out what was wrong? I have an AM2302 that is doing just what you've described (running for a few hours then needing to be unplugged to reset) and I won't be super excited if the fix was "replace the sensor" because I used it for weeks straight plugged into other systems during testing (ran great plugged into a raspberry pi running home assistant and previously my wemos d1 mini running espeasy).

Unfortunately I trusted that it would work and went ahead and "permanently" installed it (hot glue) so while it's not completely impossible to replace, I would really like to learn how to fix it!

I'm running on a wemos d1 mini with the newest Tasmota release (not dev)

[rhavin42]

The best I was able to come up with is either the AM2301 or the sonoff is very picky as to which device it can communicate stably with. Through my testing I found that certain AM2301s would work better with different sonoff modules.

That's probably exactly what you didn't want to hear, as you permanently installed the sensors. Instead of switching out the sensors, are you able to switch out the sonoff?

My ultimate advice, is unless you absolutely need the humidity sensor, the DS18B20 is a much better sensor.

[crxporter]

I do want to keep the humidity - as it's running over our stovetop to turn on/off the vent fan, my ultimate plan is when humidity (steam from the stovetop) is above 80% the fan will turn on. I would switch out pieces but, like I said, I went ahead and installed everything because I had it working for multiple weeks straight on other hardware.

The Wemos D1 mini is soldered to a board with other hardware, the AM2302 is glued in, etc...

I'll just keep watching updates and see if it ever starts working better!

[olonsoft]

I have the same problem. I am using wemos mini D1 testing on a breadboard. My AM2302 sensor gives nan results after a few hours. Compiled and flashed yesterday.

[wfdudley]

I have several Basic R2 Version 1 units with AM2301's attached, and they ALL start reporting "nan" as the values for Temperature and Humidity after a few hours. Restarting the Sonoff by command does not fix the problem. Only removing power from the Sonoff and re-applying power cause the AM2301's to report numbers again. One of my AM2301's is an official Itead Studios device, the others are devices I picked up via Ebay and wired to the Sonoffs with short leads (15cm or less). My ugly fix is to plug the Sonoff's into a "timer outlet" thingy that interrupts the power every few hours. Sonoffs are running version 6.2.0.1. The Itead Studio AM2301 running on 5.12.0e seems to be more robust, as it has been running for several days without failing. More data to come. Unlike the AM2301's, the DS18x20's work 100% reliably.

[Ant1q]

Hello! I have same isue with DHT-22. It configured as AM2301 on Sonoff S20 ("Sonoff S2X","Version":"6.2.1"), after a few hours it starts generate svalue":"nan;nan;0" BTW It sensor I use to check temperature in domoticz, so i try to made self-check to igrore "nan"-mensurens and notice that if i change configuretion for pin from AM2301 to DHT-11 (that generate 'nan' too), and after that return AM2301 it continues generate 'nan', until I plug-out S20 from socket.

[demian85]

Hi guys, I'm having issues with a wemos D1 mini after upgrading to Tasmota v6.3 Basically, what does this mean? Timeout waiting for start signal high pulse? I have a AM2302 sensor connected to D1, an IR receiver to D6 and a motion sensor to D5, none of them seem to work after the upgrade and all I see in the web admin is null values for the sensor :/ Sensor has a 4.7k pull up resistor. Tasmota v5.14 was working properly!

[sblantipodi]

Hi @arendst , I'm running my Wemos D1 Mini with the Tasmota Sonoff.bin firmware 6.3.0 using a DHT22 temp and humidity sensor. I'm still experiencing the same issue of all the others.

After some hours the DHT22 sensor starts sending NaN values instead of temp and humidity values.

If I reboot the sonoff I continue to see NaN values, if I disconnect the power and reconnect it the sensor start with good readings again.

Is there a solution to this that seems a common problem? This isssue should not be closed since it isn't resolved yet.

Thanks

[demian85]

It turns out that the error Timeout waiting for start signal high pulse occurs when there is any kind of wiring issue and the sensor is not receiving proper signals. It seems to work properly after leaving the breadboard with all the stuff connected in a box and not touching it. If I open the admin console and I move a wire, I may start getting that error above.

[sblantipodi]

It turns out that the error Timeout waiting for start signal high pulse occurs when there is any kind of wiring issue and the sensor is not receiving proper signals. It seems to work properly after leaving the breadboard with all the stuff connected in a box and not touching it. If I open the admin console and I move a wire, I may start getting that error above.

@demian85 thanks for the reply, my esp and my sensor are embedded in the wall inside a box like a normal thermostat, no one can move it since the box is closed.

[solidminds]

Any updates on this issue? Im having same problems with AM2301 and following firmware:

Program Version: 6.4.0(sonoff) Core: 2_4_2/2.2.1

[rhavin42]

I just eventually gave up and switched to ds18b20s. They’ve been working flawlessly for 6 months. I figured I could live without humidity.

[wojciej]

Hey, I know that this topic is already closed but someone might find it useful.

In my case I have added a AM2301 sensor to Sonoff RF Bridge on a GPIO5 and I got exactly the same situation. When I have power on my RF Bridge I got data from sensor and then after not defined amount of time I was getting null and DHT: Timeout waiting for start signal high pulse

I have found 2 reasons for that:

1. Lack of 4.7k resistor between 3,3V and Data - as pointed out on this picture showing DHT22 sensor plugged in RPI full article However this change itself did not solved the issue - due to the second reason - and I was still getting: DHT: Timeout waiting for start signal high pulse

2. Power source to week for my RF Bridge - I have realised that plugging it to other device is ok for normal working but when I have added temperature sensor it was not enough anymore.

After adding 4.7k resistor and changing power supply everything stared to work without any problems.

Hope this will help someone in the future.

[pawels72]

Take Vcc for AM2301 from 5V instead of 3.3V. This solved problem on my sonoff.

[rhavin42]

I didn’t think the sonoff (basic) has a 5v pin. I think it’s all 3.3v

[pawels72]

You're right, there is no pin with 5V but You can get it from stabiliser 5V->3.3V: https://www.google.com/search?q=sonoff+pinout+5v&client=firefox-b-d&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjh7q6NvqDhAhWqmIsKHZXjD_EQ_AUIDigB&biw=1920&bih=944#imgrc=er6MlToHgJRNuM:

[pawels72]

Unfortunately, after some days sensor disappeared :/

[sblantipodi]

AM2301 are crap sensor that panics for voltages or temperature spikes. I had a pretty inconsistent experience why using it for a thermostat. Upgraded it to a bme280 and now works flawlessly

[pawels72]

I'll try with bme280 but for now, I modified sources to read sensor every 8 seconds instead of every 2 seconds. This is last try before sensor change.

[pawels72]

No problem for 7 days. Vcc of DHT is 3.3V.

[pawels72]

DHT died again, sblantipodi You were right :)

[HNJAMeindersma]

Try to configure AM2301 as SI7021 and see what happens...

Solved it for me, thanks @arendst.

New type of implementation of the original AM2301 which requires a different protocol?