You are right. It is possible that it's not RPi but the SHT31 sensor which is in faulty state and thus only restarting the sensor makes it work.1. Are you sure that it is the restart of the RPi rather than the peripherals that makes it work?
2. When it is in the failing state, what does "raspi-gpio get 2-3" report?
There was also a situation that it was in faulty state for 2 days and then it started working again without any intervention.
The sensor is on /dev/i2c1 while the LCD is really on i2c-10.
When the sensor is in faulty state then i2cdetect reacts very slow (every address takes several seconds). The exactly same situation happens when I execute the testing application twice (and thus /dev/i2c1 is accessed by two processes at the same time).
Maybe, I mixed several issues. I just noticed that errors with "edt_ft5x06 10-0038" appears in kernel log now although the system is in the working state (display and touch work). But the error line "[drm:dsi_handle_error.part.0 [vc4]] *ERROR* DSI1: LP0 contention error" has always the same timestamp as the compressor switch off (but not every switch off results in this error).
I can provide more info when it gets into the faulty state again.
Statistics: Posted by kolsi — Mon Jun 10, 2024 10:53 am