ESPurna stops sending sensor data in MQTT messages.

[xoseperez]

Originally reported by: Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown)

---

I have SonOff with 5 Dallas 18B20 sensors running, it works fine as long as I keep the web interface open but after closing it somehow after a few hours the unit stops sending the sensor data via MQTT. When I logon to the web interface it resumes sending data.

Do you have some information on how to debug this situation to see what is going wrong?

[xoseperez]

Can you connect to the device via telnet while it is not sending messages to see the debug log?
You will first have to enable telnet access on STA mode in the web UI. The just use any telnet client and point it to the device IP. You should start seeing debug messages on the console. By default the device should try to send sensor data via MQTT every minute, unless you have changed that setting.

[xoseperez]

Original comment by Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown):

---

The sensor error occurred out of nothing. the moment I connect to the web socked and request a page it recovers.
I have the unit now running with Sensor debugging active maybe that brings something new.

[xoseperez]

Original comment by Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown):

---

in the second log Sensor debug was on and the unit stopped responding. It is now in a state telnet is not possible anymore and web socked is also not working.

It will need a hard reset now, as I'm not at home this has to wait.
A other unit that is running with 1 sensor connected keeps running now already for multiple days without a problem.
I have just setup a third unit with two sensors connected and will wait if that also will gives issues and later add a sensor and try until it stops

[xoseperez]

Original comment by Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown):

---

I tried a other ESP8266 to this string of sensors, have set Sensor debugging on and off and now changed "define DS_PARASITE" to 0 as I use a external pull up resistor.
Still get ERROR : [SENSOR] Error reading data from Dallas @ GPIO2 (error: 5)

Do you know the meaning of error number 5?

[xoseperez]

Original comment by Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown):

---

Discovered a small difference.. With "define DS_PARASITE" to 0 I see the message: [SENSOR] Error reading data from Dallas @ GPIO14 (error: 5) come by in the debug terminal but the unit recovers and continues. If "define DS_PARASITE" to 1 it never comes out of the error state.

[xoseperez]

Original comment by Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown):

---

I have been testing all kind of things replacing sensors, redo wiring changed timings in the OneWire library and so on. This is the result of what I learned and can come out handy for others having OneWire sensor problems.

Cable length and type of cable:
It seems after searching internet cat5 cable is the best cable to use, I can conclude shielded audio cable is a no go if the length exceed 2 meters.

Kind of sensor network:
You can connect your sensors in a spoke or daisy chain network. Spoke will work up to 2 meter cable length but daisy chain is definitely the way to go.

Pull-up resistor:
All data sheet say 4K7, this is right and many people choose to have the resistor near to the controller- ESP or Arduino. Having the resistor near to the controller is wrong put the resistor near to the most far away sensor in the daisy chain. You can add two resistors if you use really long cables than place one at the controller the other one at the most far away sensor in the daisy chain. 4K7 is not a 100% always good working value if you use long cables a lower resistor works better, never go lower than 1K2

So my error messages are gone now having all sensors in a daisy chain on cat5 cable total length approximately 23 meters a 4k7 resistor at the far end and one 4k7 resistor near the controller resulting in a pull-up resistor of 2K35

Back to the issue I reported. It stays strange ESPurna gets in a sensor error 5 state and doesn't come out anymore until you open the web interface, as if opening the web interface is triggering a re-initialization of the sensors. It might be handy to reinitialize the sensors after multiple read error's on the other hand in that case faults with wiring and resistors or a bad sensor will not be seen as easy as the software is covering the error. So it is up to Xose to decide if re-initialization of the sensors is the right thing to implement. In my opinion a few comment lines in the DallasSensor.h file explaining the different error messages and possible solutions is sufficient.

[xoseperez]

Great info. Thanks for sharing @AlbertWeterings.

I've been working on making the sensor code more resilient and recover from error states. I'm doing two kinds of tests:

• hot-plug (boot the device and plug the sensor when it's already running)
• hot-unplug-plug (boot the device with the sensor plugged, unplug it and plug it again)

The first case is not working for all sensors at the moment. Specially not working for I2C sensors since they check the I2C address at boot. The second one would also be the case where the sensor errors for whatever reason. This is also - IMHO - the most common case since most of the times you will boot the device with the sensors attached or reboot it after attaching them. I've done some changes to the sensors code to enable this second scenario (also for the Dallas sensors). Right now the code is in the dev branch as I'm still testing it. My goal is to release the code with next version soon.

[xoseperez]

Will be released with 1.12.2