In my plant room I had an old emonPi with 6 DS18B20 and an emonTH with another 5 of them. I changed the connections round so all 11 came off my new emonPi2 (RPi4, November 2023). It worked but I had to reduce the frequency as it seemed a little slow in reading them all. I settled on reading every 29 seconds and having feeds with frequency of 30 seconds.
It was working nicely so I added the IDs & names to the config.
2 weeks later, they stopped reading. I was away so investigation had to wait until I was back.
On getting home I did a full update and rebooted. All 11 temperature readings started again but on looking at the inputs page, it was very slow to refresh and at the bottom I could see that there were a number of spurious DS18B20 sensors listed.
The IDs were feasible but not correct, for instance 28-a40000000006 was one.
They all start 28-, then something in hex thatās not long enough (typically up to 4 characters), then padded with zeros and ending with 6 to make it the correct length.
Soon the emonPi2 became unresponsive so I shut down from the button on the device.
I unplugged the sensors and restarted the emonPi2, went to inputs and ran the ācleanā API, which āDeleted 22182 inputsā.
I added autoconf = 0 to the [hub] section of the emonhub configuration and shut down, plugged the sensors in and started up again.
It started okay but soon started creating new IDs, becoming unresponsive etc. So I spent a bit more time checking connections, config, rebooting etc but in the end just unplugged the sensors and ran the clean API again.
I need data from the sensors when we put the heating on so in the meantime - any suggestions?
Hello @christian what are you seeing for typical timing in between DS18B20 temperature sensor reads on your system? looking at my emonhub log here I see something like 450ms per sensor?
That should be able to get through 11 sensors in decent timeā¦ do you see any difference in performance if you test with 6 sensors vs 11?
The reading of these sensors is handled at a lower system level (outside of emonHub), Sensors are listed in /sys/bus/w1/devices, eg:
pi@emonpi:~ $ ls -l /sys/bus/w1/devices
total 0
lrwxrwxrwx 1 root root 0 Aug 21 14:42 28-00000eba6462 -> ../../../devices/w1_bus_master1/28-00000eba6462
lrwxrwxrwx 1 root root 0 Aug 21 14:42 28-00000ee9c756 -> ../../../devices/w1_bus_master1/28-00000ee9c756
lrwxrwxrwx 1 root root 0 Aug 21 14:42 28-00000ee9d1b9 -> ../../../devices/w1_bus_master1/28-00000ee9d1b9
lrwxrwxrwx 1 root root 0 Aug 21 14:42 28-00000ee9daba -> ../../../devices/w1_bus_master1/28-00000ee9daba
lrwxrwxrwx 1 root root 0 Aug 21 14:42 28-00000ee9e8f4 -> ../../../devices/w1_bus_master1/28-00000ee9e8f4
lrwxrwxrwx 1 root root 0 Aug 25 18:00 w1_bus_master1 -> ../../../devices/w1_bus_master1
and read by reading e.g:
cat /sys/bus/w1/devices/28-00000eba6462/w1_slave
It might be worth trying a process of elimination, adding one sensor at a time to see if the issue is introduced by a particular faulty sensor or cable arrangement?
From memory I recall being surprised it seemed that it was > 1 second per sensor but from your recommendations, Iāll connect to one of the two expansion boards and see what happens (tomorrow!).
If you command the sensor to āconvertā the temperature and wait for it to do so, each sensor might take up to something like 750 ms (from memory) to process. If you send a global āconvertā command to all the sensors, it will take the same time to wait for the first reading - but all the sensors have worked on the āconversionā in parallel, so each has their reading ready to transmit. That takes about 15 ms per sensor. EmonLibCM works this way. EmonLib DB does not offer the ability to read temperatures (receiving the data takes too long).
This is commanding and reading two sensors (not at maximum resolution, hence conversion takes about half the time):
The blue trace is power to the sensors, yellow is the data bus. The short burst of data just after power is applied is the global āconvertā command, then after enough time has elapsed, the two sensors are asked in turn to transmit their readings - the two bursts 380 ms later. When the last block of data has been received, power is removed.
So 11 sensors at maximum resolution should be capable of being done in under 1 second.
My experience is adding too many of these sensors isnāt a good idea. It simply doesnāt like it from a timing perspective and is unreliable. I have a couple of WeMos D1 Minis running Tasmota to gather the info and post on - 6 per device IIRC.
I have tried several combinations, the number of sensors connected or total length of CAT5 cable in use doesnāt materially change how long it takes to read each individual sensor.
I am using 2 of your terminal block breakout boards and the DS18B20s are on either 1m or 3m cables.
4 take ~450ms to read
5 take ~800ms to read
2 take ~1580ms to read
So clearly I have a couple not working nicely which are on 1m cables and nearest breakout board to the emonPi so not much length of wire involved. They are both from the same batch of 3 with IDs 28-800000082599 & 28-8000000829f5, the third with a similar ID reads in 800ms. Iāll redo the connections into the breakout board and see if anything changes but I suspect it wonāt.
Thanks - 11 sensors is quite a lot, Iām trying to āsimplify the estateā.
Weāre planning on removing the buffer cylinder before heating season, which will mean I can remove 2 sensors.
It would be nice if I can get them working from the emonPi2 but if not I may change the old emonTH to do them instead, I just have a bit of a fear of doing the firmware update
Have you read this thread about non-compliant DS18B20s? Ds18b20 and emonTX3CM firmware - If you donāt want the back story, start at post 78 and carry on from there.
Another thing to consider when the number of sensors get high and youāre doing simultaneous conversions is the possibility of Vcc sag on the bus as they all start sucking current at the same time. I run 100 sensors per bus without issue, but I do directed conversions, one at a time.
If you can put a scope on the supply line you might be able to determine if thatās the issue - and if it is you could potentially alleviate it by adding more cat5 cores in parallel to the supply and and GND.
Those two comments lead me to suspect itās a star configuration (predominantly).
From the timings in Trystanās post, I donāt know, though it looks as if he does the same. But it should still take less than 1 s to read a sensor - 11 s total.
Could the problem be mismatched transmission lines and reflections here, there and everywhere?
The reading of these sensors is handled by w1-gpio, my understanding is that this is a kernel module in Linux that provides support for 1-Wire communication but beyond that I havent delved into the inner workings at all. There is documentation for this functionality here 1-WIRE at Raspberry Pi GPIO Pinout and a bit more here Kernel driver w1-gpio ā The Linux Kernel documentation.
As such itās a different environment to what we are used to discussing here which has been mostly avr micro controller based implementations.
emonHub interacts with the w1-gpio kernel module by reading files that this module creates (examples of which Iāve included above).
I will setup a test here with 12 of our shop sensors to see what the result is
Itās been working fine for a few days - no new inputs created.
WRT the 2 very slow sensors, I have some other DS18B20s connected to emonTHs so Iāll swap them over as I donāt think it matters how long those ones take.
The proof will be to look at the 1-wire bus as transactions take place, and record the timing - and from what Iāve just read, you might need to manually decode some of the messages to find out what they are, because of this:
Let's see how one can read EEPROM context:
1. one must write control buffer, i.e. buffer containing command byte
and two byte address. At this step bus is reset and appropriate device
is selected using either W1_SKIP_ROM or W1_MATCH_ROM command.
Then provided control buffer is being written to the wire.
2. reading. This will issue reading eeprom response.
It is possible that between 1. and 2. w1 master thread will reset bus
for searching and slave device will be even removed, but in this case
0xff will be read, since no device was selected.
I read that as saying there might be other bus commands intervening between transactions for any particular sensor, hence a need to fully understand what each message is.
