Kai,

I did another test just now. When the device is starte up, I do only one write action to the device, to put pin0 to input and all the others to output.
Otherwise, I don't write anymore to the device, I only read out the status of the pins.

When pressing the key (see original scheme), the level on the input pin goes low, when releasing the switch, the level goes high again.

Moreover, when I check the interrupt line, then I see two nice pulses on this pin: one when I press the button, one when I release the button (you know that I still read the IO expander, otherwise the interrupt line would not go high again).
That's really the behaviour what I want, but then in combination with other pins that are configured as outputs (so that I have the 'freedom' of configuring in- and outputs on the same device).

So, the device is still working fine, despite all the things that have been said about device (was 'shaggy' and 'damaged' and so on). I think it's a proof the device is still in a 'super' condition... ;-)

But I'm still puzzled why the device doesn't behave like that when also sending someting to the device.
As Erik suggested in his very first reaction, it indeed seems like I'm sending a '0' to that input pin, when sending data to the other pins. But I simply don't see where this happens in my code, if it happens! That's my (big) frustration for the moment...
Don't know if you already had a look to the code I posted? Maybe you'll see what I'm possibly doing wrong...

Anyway, I'm already one step further.

The next test I'm going to do, is sending a whole byte to the device driver (using pcf8574_set_Byte(): see the code I posted), iso. sending only one bit to modify the level of a pin configured as an output.
By doing this, I'm excluding the exotic _crol_ and '~' and other actions that I have to do when sending only the bit that has to be changed in the byte to the driver (using pcf8574_set_Bit(): see the code I posted)

Best rgds,

--Geert