Qwiic Single Relay not detected when connected via Qwiic Mux Breakout

Qwiic System
1

Hello,

I have an original Qwiic Mux Breakout (SparkFun Qwiic Mux Breakout - 8 Channel (TCA9548A), BOB-14685, https://www.sparkfun.com/products/retired/14685) that is attached to a Raspberry Pi 3B+ via a Qwiic HAT (DEV-14459, https://www.sparkfun.com/products/14459).

There are several temperature/RH sensors with the same I2C address connected to the I2C Qwiic mux and everything works fine. When I run ```
i2cdetect -y 1


I also have a Qwiic Single Relay (COM-15093, [https://www.sparkfun.com/products/15093](https://www.sparkfun.com/products/15093)). When I connect it directly to the Qwiic HAT and re-run ```
i2cdetect -y 1
``` the address (0x18) shows up and and I am able to use the relay via my python program as intended. However, when I connect the Qwiic Single Relay to the mux its address does not show up and it is unusable. The odd thing is that it occasionally does work when connected to the mux. I have tried using various cables, different mux ports, disconnecting everything else, rebooting the rpi, reloading the i2c kernel modules, etc. but I still can't get the Qwiic Single Relay to consistently appear on the I2C network through the mux. I would simply use the Qwiic Single Relay connected directly to the Qwiic HAT but it needs to be daisy chained to one of the temp/RH sensors so I need to connect it via the mux in order to uniquely address that temp/RH sensor. 

I have replicated this problem with another Qwiic device. The rpi recognizes it when I connect it directly to the Qwiic HAT but not when it's connected to the mux directly or indirectly. Like the relay, it has recently worked on occasion for a few days at a time when connected via the mux before unexpectedly dropping off the I2C network. I suspect there is a problem with the mux itself. Is there anything else I could check before I order a new one?

Thanks.
2

TL,DR: if an I2C device is consistently detected by running “i2cdetect -y 1” when it is directly connected to a Raspberry Pi Qwiic HAT, but it is only inconsistently detected when it is connected indirectly to the Pi via a Qwiic Mux Breakout, should I assume the Qwicc Mux Breakout is faulty?

3

You have to send a command to the Qwiic MUX to tell it what channel you want to select, it defaults to no channel if I recall correctly. See the hookup guide for the Qwiic MUX for details on what commands to send to select or change channels.

4

Fixed it- thanks YellowDog! That was a dumb mistake on my part. I have a cron job on the Pi which is running a different python program that cycles through the Mux channels every hour, but it’s not using the SFE qwiic python package that is described in the hookup guide. My other program is not leaving the channels in a consistent state.

5

Here’s a followup question: if program1.py cycles through Mux channels 0-3 approximately once every hour to read sensor values and program2.py is accessing Mux channel 3 more frequently (roughly once per minute) how do I ensure that these two programs don’t ever contend with each other over which channels are enabled or disabled?

I suppose I could rely on cron timing to make sure program2.py never runs when program1.py is running but that seems messy.

Or I could have each program always disable a channel when it finishes reading it, so that all channels were disabled by default. Then whenever either program runs it could first check that all channels were disabled to be sure that the other program wasn’t still running. That just seems like it would be creating a race condition.

What I probably need is a way to determine- from either program- if the i2c bus is in use by the other program, but neither the qwicc API nor the smbus API provides such a method. How could I do that? I’m not a programmer, just a hobbyist, so the simpler the better.

6

In case someone is curious someday, I did find a nice python filelocking library that can be used for inter-process communication. My programs that share the i2C bus have been using this for several weeks without any bus contention issues. There is probably an easier way but this worked for me.

https://github.com/benediktschmitt/py-filelock