I've never tried to use it on a Pi zero and wouldn't really know what the issue could be. It might be some defective contact or instability in the w1 kernel modules. I'm pretty confident that from the Python side and this module there is nothing you can do about this.

However, I'll keep this issue open for a few more days just in case someone else had similar experiences and might be able to help you. 🎉

I can tell you it's not a PiZero problem with the module, since I've used it on them since way back when.

You could try a different pin and see if that helps.
Or check contacts and power.
(this is on the Pi forum too iirc?)

Saying that, not sure if any of mine have used a recent buster image.

I've never tried to use it on a Pi zero and wouldn't really know what the issue could be. It might be some defective contact or instability in the w1 kernel modules. I'm pretty confident that from the Python side and this module there is nothing you can do about this.

However, I'll keep this issue open for a few more days just in case someone else had similar experiences and might be able to help you. 🎉

I agree that it should have to do somehow with the pi zero since it is very reproducible. Tested it with 3 different zeros - all behaved the same. No issues on the larger Pi.

My workaround is that I read the sensor permanently all 2 seconds in its own thread and write the measurements in a variable that I read out when ever I need it. Its not time critical, so this solution is ok.

I can tell you it's not a PiZero problem with the module, since I've used it on them since way back when.

You could try a different pin and see if that helps.
Or check contacts and power.
(this is on the Pi forum too iirc?)

Saying that, not sure if any of mine have used a recent buster image.

Yes - its in the Pi forum. I've put it there first, since I thought its more Pi related. I've received a comment that I should message the developer and thats why I've put it here.

The sensor sits on a custom made pcb, so switching the pin in that setup is not possible, but I'll investigate further with connecting the sensor directly and use different pins.

Similar issue here fwiw.
Same setup - pi-zero, kernel 5.4.83, w1thermsensor version 2.0.0, python 3.7.3.

File "/usr/local/lib/python3.7/dist-packages/w1thermsensor/core.py", line 267, in get_temperature
raw_temperature_line = self.get_raw_sensor_strings()[1]
File "/usr/local/lib/python3.7/dist-packages/w1thermsensor/core.py", line 250, in get_raw_sensor_strings
raise SensorNotReadyError(self)
w1thermsensor.errors.SensorNotReadyError: Sensor 3c01d6075020 is not yet ready to read temperature

These errors turn up intermittently. No pattern. I'm reading a single sensor every 10s. Sometimes it might fail after an hour or so. Sometimes after 8hrs.

I got the same error

Traceback (most recent call last):
  File "thermsensor_lcd.py", line 71, in <module>
    temp = sensor.get_temperature() #temp en celcius
  File "/usr/local/lib/python3.7/dist-packages/w1thermsensor/core.py", line 267, in get_temperature
    raw_temperature_line = self.get_raw_sensor_strings()[1]
  File "/usr/local/lib/python3.7/dist-packages/w1thermsensor/core.py", line 250, in get_raw_sensor_strings
    raise SensorNotReadyError(self)
w1thermsensor.errors.SensorNotReadyError: Sensor 0001d607c028 is not yet ready to read temperature

It is a hardware issue. I think it is a wire issue. I am using the cable jumper dupont and I soldered it with tin.
The problem was in the Data cable.

I have the same problem on two Raspberry Pi Model B first generation, ie the single core. I agree that there is nothing wrong with the python code, but I suspect that the python implementation itself of the function readlines is flaky, perhaps only on low-performance devices.

To investigate, I wrote a simple shell script and ran it parallel to my python code, which produced many SensorNotYetReady errors:

cd /sys/bus/w1/devices
while :; do for el in `ls | grep 28`; do echo $el && cat $el/w1_slave; done; done

When the sensor returns nothing, this produces two (or more) subsequent rows where only the sensor ID is listed. I noticed that this simple code rarely produces no result, whereas the python code very frequently returns no result and throws the above exception.
I then subclassed W1ThermSensor and overloaded the method get_raw_sensor_strings as follows. Note that I replaced the readlines section with a subprocess that also uses the cat command. This reduced the empty reading significantly, but they still appear, and appear more frequently than running the shell script. My guess is that the python implemtation somehow 'gives up' too early when reading the file.

   def get_raw_sensor_strings(self) :
        """Reads the raw strings from the kernel module sysfs interface
        :returns: raw strings containing all bytes from the sensor memory
        :rtype: str
        :raises NoSensorFoundError: if the sensor could not be found
        :raises SensorNotReadyError: if the sensor is not ready yet
        """
        try:
            s = subprocess.check_output(['cat', self.sensorpath], 
                timeout=sys_conf.sensor__update_timeout, encoding='utf8')
            data = s.splitlines()
            #with self.sensorpath.open("r") as f:
            #    data = f.readlines()
        except IOError:
            raise NoSensorFoundError(
                "Could not find sensor of type {} with id {}".format(self.name, self.id)
            )

        if (
            len(data) < 1
            or data[0].strip()[-3:] != "YES"
            or "00 00 00 00 00 00 00 00 00" in data[0]
        ):
            raise SensorNotReadyError(self)

        return data

I'll investigate on a later model Pi, next.

I have now tested this on Pi models 2, 3, and 4. Result: no read errors whatsoever on any of them.
Steps to reproduce:

1. Read w1 devices on 1st generation pi - this results in many read errors as stated above
2. Move the sd card to a 2nd, 3rd or 4th generation pi - no read errors

I agreed that there is nothing wrong with the python code. Also, because reading the w1 devices from a bash shell rarely fails, by implication there must be some defect in the underlying python os.read code. My guess is that it doesn't wait long enough for the driver to return the result, ie. some kind of timing problem.

I raise a defect with python.

I had the same problem with my Pi Zero. However, updating the firmware with rpi-update to 6.1.12 (as of today) solved this issue for me.