Detect I2C bus errors to restart I2C

[pimlie]

Is it possible to detect I2C bus errors in a Rule? See here for the device/sensors I'm using.

I2C generally works fine, but sometimes it does not 🙃 Not sure, I guess there is some interference on my board. But before I look into the hardware cause, I would like to fix this in Tasmota.

Here is my rule:

#define USER_RULE2 \
"ON SHT3X#Temperature DO DisplayText [s1l1c1]T: %value%C ENDON " \
"ON SHT3X#Humidity DO DisplayText [s1l1c11]H: %value%% ENDON " \
"ON S8#CarbonDioxide DO DisplayText [s1l2c1]CO2: %value% ppm ENDON " \
"ON PMS5003#PM2.5 DO DisplayText [s1l3c1]PM2.5: %value% ENDON " \
"ON PMS5003#PM10 DO DisplayText [s1l3c11]PM10: %value% ENDON " \
"ON PMS5003#PB0.3 DO DisplayText [s1l4c1]PB.3: %value% ENDON " \
"ON SGP40#TVOC DO DisplayText [s1l5c1]TVOC: %value% ENDON " \
"ON tele-DisplayText [s1l6c1] ENDON"

And here is the log output when I2C got stuck:

17:39:12.212 MQT: stat/tasmota_B4D6D5/RESULT = {"DisplayText":"[s1l4c1]PB.3: 710"}
17:39:12.233 SGP4X error: Error writing to I2C bus
17:39:12.267 RUL: SGP40#TVOC $^ ERROR performs 'backlog DisplayText [s1l5c1]TVOC: 100; RuleTimer1 10'
17:39:12.297 MQT: stat/tasmota_B4D6D5/RESULT = {"DisplayText":"[s1l5c1]TVOC: 100"}
17:39:12.448 SGP4X error: Error writing to I2C bus
17:39:12.495 MQT: stat/tasmota_B4D6D5/RESULT = {"T1":10,"T2":0,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}
17:39:12.702 SGP4X error: Error writing to I2C bus
17:39:12.948 SGP4X error: Error writing to I2C bus

It might be worth mentioning that all commands in the Rule keep triggering, even though none of the sensor values are changing. You can see I tried matching the SGP40#TVOC value to error, but that doesn't work ofc as the reported value is still the last successfully measured value of 100.

Also even though none of the sensor values changes anymore, only the SGP4X driver returns an error. To get the I2C bus unstuck again, I would like to be able to add a event command to that SGP4X error so I can call i2cdriver82 1 to restart the i2c bus. But that doesn't seem to be possible atm?

--edit--
Maybe a generic Log trigger for Rule's would be cool to add? Or are Rule's basically deprecated in favor of ESP+berry?

[sfromis]

Indeed, you can only have rule triggers when the basis is JSON (the built-in triggers also goes via JSON not shown in the console). Not available for messages in general. With ESP32 and Berry, you'd have a feature where it is possible to handle all log messages (with care), but not with ESP8266.

More generally, I'd say that when getting those "Error writing to I2C bus", that's the issue to debug and fix, instead of aiming for workarounds on top.

Maybe the driver for SHT4X should be fixed to not report old values when it fails to communicate with the sensor. Sensor values dropping out could also be used by rules to trigger a restart, for users wanting kludgy workarounds....

[pimlie]

To be clear, none of the sensor values are updating anymore when SGP4X logs the I2C error. So neither the SHT3X nor the S8 nor the PMS5003 update their values anymore, even though all the individual Rule commands keeps triggering with old values. In the example output above it starts with the PB.3 output of the PMS5003, but that was also an old value.

Will try to debug the I2C error but it only happens once every few hours. So it might not be that easy to fix/resolve :(

Update: Sorry I was wrong, the values reported by the ruel commands in the logs do update. So it's just the display that doesn't update at all anymore, might be a clue where I have to search for the issue ;)

[pimlie]

It seems the issue was an unstable I2C bus due to mixing 3.3V & 5V sensors. The OLED was also connected through I2C, so after the I2C bus became unstable you just couldn't send display commands anymore.

So it would still be nice if you could somehow detect I2C errors. If the SGP4X driver error can really be trusted, then maybe just fire some error event with value I2C so you can use that in a rule. Ofc its better to just fix the error if possible, but that might nog be always possible (or at least not easily) :)