Closed poerlemans closed 3 years ago
Only 9 out of 10 working is actually an achievement already.
It's always the same sensor that fails. It is the sensor "Ketelwater, in". This sensor is detected (see the logs), but is always combined with the message: "Message skipped because it was too big to fit in TCP buffer - This is only cosmetic". The same set of sensors was functioning quit well with an EspEasy firmware. The wiring was not changed when going from EspEasy to EspHome. I was already thinking to go for an extra hub on the NodeMCU board, but there might be a solution for my problem with the actual setup. I didn't observed somewhere a remark that there is a maximum on the number of temperature sensors.
I tried a lot to overcome my problem. Nothing helped! I went back to EspEasy and all 10 temperature sensors came online immediately. If someone has suggestions: I'm still open for tests.
I believe there are dallas sensors ESPHome just cannot handle, do you have the possibility of changing that one not working with another sensor?
The 10 DS18B20 sensors are all the same (waterproof sensors with cable of about 1 meter; see: https://www.hobbyelectronica.nl/product/ds18b20-waterdicht/). As I wrote already, it's always the same sensor (the first in a serie of 10 identical sensors; see the logs) that is causing the troubles. I have no other DS18B20 sensors here, so it's difficult for me to carry out test.
Yes I understand what you say makes sense, however there are several reports of those sensors "randomly" not working, randomly here means you just don't know the cause.
Oke, it might have to do with malfunctioning of this troubleful sensor. But should EspEasy be more friendly with respect to this troubleful sensor? All 10 sensors are operating now without any trouble on the EspEasy operating system.
My best bet is that ESPHome has an issue that causes some dallas sensors to not work. Figuring out the issue is not easy, the programmer would need one of this trouble sensors to figure out what's going wrong.
One option would be that it's the internal pullups ESPHome enables - I don't believe other FWs do that. ESPHome enables the internal pullups on the ESP to support parasitic power mode. Maybe that is somehow interfering with the dallas sensors.
My 50 cents, I have like 10 years of experience with 1 wire ...
Maxim 1wire guidelines are good to study anyway: https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/148.html
Answers to these question could be useful:
As already described above (reaction 6), I use 10 identical DS18B20 waterproof sensors (see link above). Cable length for each sensor about 1 meter. The 10 power lines (3.3V), the 10 digital data lines and the 10 zero Volt lines are soldered and three lines are connected to the NodeMCU. Between the data line and the 3.3V line a resistor of 4700 Ohm is soldered. I think it can be described as star topology Power to the sensors is provided by the NodeMCU 3.3V connection
I would definitely read the document that @lwqcz linked. In particular:
Precautions with Star Topologies Testing has shown that unswitched star-type network topologies (i.e., those with several branches diverging at the master) are the most difficult to make reliable. The junction of various branches presents highly mismatched impedances; reflections from the end of one branch can travel distances equal to nearly the weight of the network (rather than the radius) and cause data errors. For this reason, the unswitched star topology is not recommended, and no guarantees can be made about its performance.
If you're going to try to run a bunch of devices with long wire lengths, I would definitely power them from the 5v Vin from the USB port, rather than trying to use the onboard 3v3 regulator. The regulator is frequently of low quality and cannot supply reliable power when you start adding more chips beyond just the esp.
Oke, you might have be right. But I now have the NodeMCU loaded with EspEasy firmware and I obtain in this situation very reliable temperature data. No disturbances or unrealistic sata at all!
No disturbances or unrealistic sata at all!
But do you use some kind of debug mode? Glitches could be simply filtered out. For further debugging, an oscilloscope would be rather useful. I would recommend a better 3V3 power supply and tree type bus instead of star topology.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I have setup a NodeMCU v2 board with 10 Dallas temperature sensors. Only 9 sensors are registrated. I don't know how to improve this. I tried "esp8266_store_log_strings_in_flash: false" in the config but this had no effect.
The vloerverwarming.yaml file and log file are given below:
Operating environment/Installation (Hass.io/Docker/pip/etc.): Ubuntu with docker containers
Ubuntu based docker system (15 containers) running on Intel NUC
ESP (ESP32/ESP8266, Board/Sonoff): ESP8266
Affected component: Dallas temperature sensors
Description of problem: Only 9 measurement are reported (10 sensors present). Does this has to do something with the message: "Message skipped because it was too big to fit in TCP buffer - This is only cosmetic"??
Problem-relevant YAML-configuration entries:
Logs (if applicable):
Additional information and things you've tried: