I2C Multiplexer (TCA9548A) Reset Pin

[knighToFdemonS]

Hello,

i have a multiplexer in my project and want to utulize the reset pin function. Ive noticed that this pin is configurable in the config but in the documentation it says "This feature is not yet used in any I2C device plugin."
(https://espeasy.readthedocs.io/en/lates ... ultiplexer)
Is this still current state? As far as I understand this, this feature would need to be used by specific I2C plugins itself.
Due to I saw the option(advanced) "Try to clear I2C bus if stuck" (which is off by default), I wanted to ask if this somehow works together?
For example, if ESPEasy trys to clear the bus, then it also sends a reset signal for the multiplexer (pin gets pulled low)? Or is that not how it works?
Can I just issue a command to pull this pin low for 1sec?

Thank you.

[Ath]

Any particular device you use that requires this? As the only I2C sensors I know that are causing I2C bus-issues are the ATH10 & AHT15 temperature/humidity sensors, but those are of mediocre quality anyway, out of production by the original manufacturer, and have properly working replacements in the, also supported by ESPEasy, AHT20 and AHT21 sensors.

You can connect a free GPIO to the reset pin of the multiplexer, and pull it low for a reset, but as a) these multiplexers don't seem to be used often, and b) we get no support questions about them, I have the impression they either work very well, in isolating I2C devices, or they really are not used often
And resetting the multiplexer for 1 second feels like stopping the world, a reset pulse of a few milliseconds should be enough, but when/how would you want to detect & trigger that?, as the I2C auto-reset/untangle feature seems to work quite well (it's tested quite extensively when it was introduced, and is also used by other large ESP software projects).

[knighToFdemonS]

Thank you for your reply.
I have 6 Adafruit Stemma Soil Sensors on an 8-channel multiplexer. So far its working fine but sometimes, i dont know why (currently iam suspicious of one particular sensor), the i2c-bus or a device on there gets stuck after like an hour of runtime and the cpu-load on the esp32 spikes to 100% and the webinterface starts to timeout. Resetting the multiplexer seems to help in this particular case and after 1-2 reboots its fine again.
Im trying to understand problems with the i2c-bus in general to debug the problem. Sorry for asking not directly, but my knowledge is still lacking.
Thats why I was asking how the reset-pin works in ESPEasy and about the "try to clear i2c bus if stuck" option. Currently iam trying to have this option disabled and see what ESPEasy will do in case of a bad sensor. I can see the "clearing i2c stack..." in the log but it pops up like 10times per second, so im guessing this spikes the cpu?!?
can i see somewhere which process overloads the cpu?

[Ath]

Thats why I was asking how the reset-pin works in ESPEasy and about the "try to clear i2c bus if stuck" option. Currently iam trying to have this option disabled and see what ESPEasy will do in case of a bad sensor. I can see the "clearing i2c stack..." in the log but it pops up like 10times per second, so im guessing this spikes the cpu?!?

That's a very likely cause, combined with the I2C bus having (probably) timeout issues

can i see somewhere which process overloads the cpu?

Well, it isn't Windows or Linux that's the base for ESPEasy and the Arduino framework . There are most likely some ways to get that type of information from the underlying 'OS' (RTOS on ESP32), but that's not made available in ESPEasy, and I haven't worked on that low-level type of development to give an authoritative answer on that (The more you know, the more you know you don't know )

When having Timing statistics enabled, on the Tools/Advanced page, you can see where the actual time is going to, that already helps a lot. (NB: Don't enable RAM tracking, that'll cause more performance issues, and should only be used during debugging the code)