Without making any claims about what chip is more accurate my statement still stands that most people don't need anything more accurate than a DHT. If your house reads 1 or 2 or even three degrees high or low who cares? turn the heat up or down. Using it in a process that demands .1 or .2 degrees accuracy you would have to build a corrections chart and that's probably beyond most peoples ability or desire. The DHT is and was a good reliable chip properly designed. I haven't looked at any temp/humidity sensors for a long while as my goody box had a huge supply of DHT's in it. Like anything I'm sure there are newer maybe more accurate solutions out there. I won't argue that point. But to flat say the DHT is unreliable and not accurate enough for most home applications is not fair. Also, back when the 18b20 first came out and I'm talking 25 years I soldered up a proto board with one on it to just to poke around to see what it could do. That board still sits on my desk right now and still runs. Interestingly every few weeks maybe a month or two that board locks up and has to be powered down then back up. It was never designed to be permanent and I didn't put much thought into the design so sometimes a spike must sneak in and down it. Again, good hardware design is necessary for any important project and I didn't put in enough ground plane, or filtering or something on that board. But then, I didn't care if it had issues, it was simply an experiment. For any important project design, design, and design not just code but hardware too.
Actually, that does make a very significant difference to comfort and to the cost of running a Victorian house.
However, not sure why we are arguing about this. All I'm trying to do is to steer people who don't have experience with sensors away from the DHT which is a legacy sensor that isn't needed today. If you have a load and are happy with them, fine.
Indeed, which brings us back to the original issue which was DHTs locking up.
here is an update.
the reboot was done yesterday at 23h00.
and here is the status.
As you can see, the first one (white) stopped working around 12h after the reboot and the second one stopped around 17h afterthe reboot.
really weird, why the first one stopped before the second one and not at the same time. nothing changed, I just let the raspberry alone.
let see next week with the other sensors. later this year, I'll try with the BME280 with my other project.
Just to add my 2 cents
I added support for DHT11 to my ScratchGPIO project and found that my device just stops giving readings - its never lasted overnight 
I received a DHT22 the other day and going to see if that is any more reliable
Sorry to be late to this discussion. I think the error shown in the plot is the residual, after each device has been individually trimmed at one temperature to remove the linear error. The manufacturer has an application note showing how to remove the quadratic term. This requires comparing the specific device being calibrated with a highly accurate one over a range of temperature and some computation or a table lookup to make the correction. The numerical work could certainly be handled by NR. The physical measurement could be within the reach of some in this forum, and the result would be a device with an accuracy of better than +/-0.05Ā°C. (!)
And I think that doing it in-chip would make the device comparatively expensive and possibly less reliable.
Hey
Just to let you know, I received a sensor ds18b20 . The installation is easy and using the node-red-contrib-ds18b20-sensor, its' easy to configure.
A graphic. The pic is due to the use of an hairdryer to shrink some tubing. 
well joy is over...
I've installed a second DS18B20 and both are frozen and even if I remove the second one, the first one doesn't refresh and is stuck at 20,062Ā°
really strange
Hi, do you have a pullup resistor between + and data?
Yes.
What is strange is that it worked until I added the second sensor
Where did you get the sensors from? There are a lot of fake ones out there, especially if you bought them ready in metal cases and cable attached. These fakes have different issues like inaccurate readings, some won't work if there are multiple sensors on the bus...
I stumbled upon a similar issue a while ago on the ESPEasy issue tracker, here: https://github.com/letscontrolit/ESPEasy/issues/2643
Eventually leading to this nice overview:
This could cause a problem. The serial interface works reliable on one bus. A āstarā cable configuration is not working well. Perhaps you should use another gpio for your second sensor.
I have some of these on different levels in my ponds (under water) and no problems for many years now. But every one on a their own gpio connected to an esp8266.
But I had problems with a particular order from china too (water proof version) with no reading at all. (Money was refunded - but time in finding the issue was spend)
I've bought 1 of them in an electronic shop and the other one on internet.
I've removed the second added sensor and ran those 2 lines
modprobe w1-gpio
modprobe w1-therm
the first sensor seems to work again. I'll try again to add the second one to see if they both fail or not.
I'll let you know.
Try it with each one separately before trying both.
How long are the wires to the sensors?
one wire is 1m long
one is 5m long
and the last one is around 15m long
I am using DHT22 sensor for years in 2 emonTH device (the predecessor of https://shop.openenergymonitor.com/emonth-v2-temperature-humidity-node/ ) they are sending about every 10 minutes the temperature/humidity/voltage.
It is running reliably for months until the battery get depleted and then it is always fixed by replacing one of the 2 batteries.
So it is definitely possible to use DHT22 sensors without having the freeze issue. (You can't blame it all on the sensor )
The accuracy of the reported temperature is good.
The accuracy of the reported relative humidity is not that good (drifting issues / 5%-10% differences seen when comparing between 2 DHT22 sensors).
Like others have said, If you have to buy a new temperature/humidity sensor I would also recommend to consider another sensor instead of DHT11 or DHT22 but I won't claim that you cannot use the DHT22 sensor.
15 and 5 metres connected direct to the GPIO may be too long, dependent on how electrically noisy your environment is. It may be ok or it may not, so try them all on short cables initially to make sure that it works like that. Ideally with 1-Wire they should be daisy chained rather than star connected, sometimes a star will work, sometimes it won't, you can only try it and see.
For long wires then ideally you should use a 1-wire interface board rather than connect direct to the processor.
Also can I check you are taking all three wires to the devices, 0v, Vcc and data.
Also check your power supply. You can certainly get some odd results if the power is just a little weak.
That is normally not the way to do it. Replacing only one Battery can lead to negative charge on the older one, not only could destroy the old one it could result in leaking. Depending on your circuit it may work but the general rule is to replace all batteries at once with the same type preferable the same brand and package. This is not marketing this results on physics.
It always annoys me when I see household products with li-ion cells in serial without without any load balancing. This depends totally on the assumption that the used cells are acting precisely the same which they normally donāt especially over time. This is such a big waste on resources but perhaps intended by the manufacturer. If you tread cells well they can be used more than 1000 times and load balancing costs only a few cents. People have to throw totally fine products in the bin like my drilling machine with 3 cells in series wich I open every year or so and charge each cell individually to balance the cells. The same time I could bought 3 machines of the same type, sorry Bosch (your BMExxx are nice but how you treat your li-ion cells and customers not)
I hope you don't have pullups on all sensors, you only need one per bus.
