I have been looking for the answer for the error mentioned in the title but for the first time i haavent got an answer yet. We ll im trying to make my Raspberry pi read analog data but when i run the code in terminal window it gives me 'IOError: [Errno 5] Input/output error'.

The code im using to read analog data is shown below. Im using PCF8591 ADC converter.

from smbus import SMBus

bus = SMBus(0)

print "read a/d press ctrl + c to stop"

bus.write_byte(0x48, 0)
lastval = -1

while True:
  reada = bus.read_byte(0x48)
  if(abs(lastval-reada) > 2):

I understand it might be because of the version changed in raspberry pi and i should change SMBus(0) to SMBus(1). For this i checked my RPi version which is not the revised one. But still I tried to run the program by changing the SMBus number, still no luck with it.

The error I get is shown below:

Traceback (most recent call last):
  File "analogread.py", line 7, in <module>
    bus.write_byte(0x48, 0)
IOError: [Errno 5] Input/output error

Any help is appreciated. This is the basic block in my bigger project which im trying to execute. So, the fas thinster i get thing working the better i can build my application. Thank you


The cause to this might be that you're working remotely (SSH). After you disconnect the remote session, your program is still working and could try to print or interact to console, which is not available any more. This is what happened to me.

  • Understood, but how you overcome to resolve this issue. – sib10 Jun 13 '16 at 9:42
  • What i did is to use 'sudo username' to start the process then you can logout whitout interupting the process. Hope this help you. – adimitrov Jun 14 '16 at 10:10
  • 2
    nohup is another way to overcome this situation... – sib10 Jun 15 '16 at 19:57
  • 1
    Thank you so much for this! I spent hours trying to find out what was wrong and your answer explained the actual problem in seconds! I had a logging module and I overcame the error by adding try/except block around the log statements that print to the console because there was no use of print if no one is looking at it. – jatin3893 Oct 22 '16 at 14:41

These errors might be beyond programmer's control, caused by a random, yet usual, event.

One approach would be to try a couple of times before following with the error:

def try_io(call, tries=10):
    assert tries > 0
    error = None
    result = None

    while tries:
            result = call()
        except IOError as e:
            error = e
            tries -= 1

    if not tries:
        raise error

    return result

try_io(lambda: bus.write_byte(0x48, 0))

While this thread is old, I want to share my resuly hoping someone else might be helped as all posts I came across did not mention this potential fix.

I was encountering a similar issue, but with different hardware (MCP23017 and an LCD).

After chasing the problem for some time, I found the problem was not software, but rather hardware. Specifically the pull up resistors on the SCL and SDA lines.

The RPI (3 in my case) has 1.8k resistors and my LCD had some pull up resistors installed as well (~2.2k). Running the LCD never had a problem, but the MCP23017 would randomly disappear from the bus and reappear when running a scan by issuing command "i2cdetect -y 1".

Removing the extra pull up resistors on the LCD fixed the problem and all works perfectly now.


The cause to this might be that you're pushing out the read/write calls faster than your hardware can accept them. So add small delays between read/write operations:

from time import sleep
from smbus import SMBus

bus = SMBus(0)

bus.write_byte(0x48, 0)
sleep(0.2)  # Wait for device to actually settle down
lastval = -1

while True:
  reada = bus.read_byte(0x48)
  if(abs(lastval-reada) > 2):
  sleep(0.2) # This might be not needed.

Another possibility is that device is not actually present in this address. So if the timeouts don't help, try out i2c-tools (should be available via package management, unless you're using a custom software distribution) to check whether the device is actually available (sometimes it could be a wiring issue like forgotten GND):

i2cdetect -y [bus number]

Why i2c? Because SMBus is basically a modification of i2c bus with more strictly defined voltage levels and timings.

  • 1
    The i2cdetect program is what saved me here. The device was on the incorrect address. THANKS – Youngy Nov 24 '17 at 5:17

I experienced this problem when driving a 7-segment serial display over I2C with a model b+ rpi. I corrected the problem by adjusting the baud rate to match the device setting (9600). I believe the default is 100000.

To change the baud rate, I added the following line to /etc/modprobe.d/i2c.conf:

options i2c_bcm2708 baudrate=9600

After reboot, I verified the setting had taken effect with:

prompt$ sudo cat /sys/module/i2c_bcm2708/parameters/baudrate

Since then, I've had no problems with intermittent I/O errors.


I had the same problem in a RasPi -> ATMEGA communication and I resolve it on the slave. This error message occurs if your slave doesn't respond.

I tried the following code on RasPi, with an I2C slave connected on the I2C bus and configured with the 0x8 address :

from smbus import SMBus

I2C_Bus = SMBus(1)


I2C_Bus.write_byte(SLAVE_ADD, 0xAA)

Providing the I2C slave is well configured to acknowledge, it should work!


I know this topic is quite old but the same error occured with I2C and PCA9685 when I put values that were not in range. The way I figured it out was just simply disabling and enabling I2C:

  1. sudo raspi-config
  2. '5. Interfacing options'
  3. 'P5 I2C'
  4. 'No'
  5. 'OK'
  6. sudo reboot now
  7. sudo raspi-config
  8. '5. Interfacing options'
  9. 'P5 I2C'
  10. 'Yes'
  11. 'OK'
  12. sudo reboot now

After that, sudo i2cdetect -y 1 detects my I2C PWM module back again.

Your Answer

