I have been running a Wemos D1 Mini Pro with a TCA9548A I2C Multiplexer and some BH1750 sensors successfully for weeks, but while updating ESPHome from version 2021.9.3 to version 2021.10.1 I was getting some errors about options that have been removed.
This is an excerpt from the install log:
INFO Reading configuration /config/esphome/d1pv2-01.yaml…
INFO Detected timezone ‘Europe/Amsterdam’
Failed config
This option has been removed.
scan: True [source /config/esphome/d1pv2-01.yaml:47]
sensor.bh1750: [source /config/esphome/d1pv2-01.yaml:71]
platform: bh1750
name: D1PV2-01 BH1750 Illuminance 1
id: d1pv2_01_bh1750_1
This option has been removed, please see the tca9584a docs for the updated way to use multiplexers.
multiplexer: [source /config/esphome/d1pv2-01.yaml:75]
id: multiplex0
channel: 6
resolution: 0.5
measurement_duration: 69
update_interval: 30s
accuracy_decimals: 2
This is the applicable part from the ESPHome config.yaml:
The strange thing is that I cannot find any info in the current ESPHome release notes about changes to the TCA9548A, and also the TCA9548A documentation is still exactly the same as one month ago.
Does anybody have a clue what is going wrong here?
This problem is still not solved.
Whatever are try, it currently is impossible to upgrade this ESP8266 setup to ESPHome version 2021.10.1
Was anyone with a comparable set-up (ESP8266 with an I2C multiplexer) able to upgrade?
I have exactly the same combination here (8266 + tca9548a) and I witness the exact same problem: Compile errors “This option has been removed.” since ESPHome 21.10.
Didn’t have time to try which option exactly throws the error. Maybe on the weekend.
Thanks Jörg!
Although it is an unfortunate problem it is good to know that I am not the only one.
There must have been something broken in this new release.
The compile errors mention these options as being removed for my set-up:
In the tca9548a setup: scan: true
In the sensor setup: multiplexer:
But I have no idea at the moment how to work around that.
OK, so I think that I found the location of these “option has been removed” warnings in the ESPHome Source Code. These come from two “init.py” files:
esphome/esphome/components/i2c/__init__.py
def i2c_device_schema(default_address):
"""Create a schema for a i2c device.
:param default_address: The default address of the i2c device, can be None to represent
a required option.
:return: The i2c device schema, `extend` this in your config schema.
"""
schema = {
cv.GenerateID(CONF_I2C_ID): cv.use_id(I2CBus),
cv.Optional("multiplexer"): cv.invalid(
"This option has been removed, please see "
"the tca9584a docs for the updated way to use multiplexers"
),
}
if default_address is None:
schema[cv.Required(CONF_ADDRESS)] = cv.i2c_address
else:
schema[cv.Optional(CONF_ADDRESS, default=default_address)] = cv.i2c_address
return cv.Schema(schema)
The new config syntax is shown in this issue report. I have copied the example YAML below.
It uses dedicated bus_ids for each channel of the multiplexer, and the sensors now have to reference the new bus_ids instead of a multiplexer id and channel.
But wait!
You should not recompile your ESPHome YAMLs just now!
There is still an issue in ESPHome 21.10.1 that will prevent the new multiplexer code from working correctly. See this PR which will be rolled out with ESPHome 2021.10.2.
Yes!
After updating ESPHome to 2021.10.2 and modifying the ESP8266 Yaml in accordance with the now also updated docs for the TCA9548A compiling went fine, and every is working again.
Just for completeness (the example from the ESPHome Issue report #2598 appears to be incorrect): the updated TCA9548A doc now specifies this for the multiplexer setup:
Hi,
I’m new esphome user and unfortunately facing the issue with trying to compile using above multiplexer setup :(.
First of all can’t even save code with ‘i2c_id: i2c0’
Do you have any idea why ?
I use esphome 2021.10.2
Hi Rafał,
Can you give some more background info? In which interface are you trying to save the code, and can you show your code and any error messages that you get?
Hi Rafał,
if your i2c_id: line does not compile, this is probably because you forgot the i2c: definition for the bus in your YAML. This may happen because the example code in the tca9548a page is incomplete (= reduced to the essential parts). Here is a full example. But you still have to add your usual intro segments like esphome:, wifi:, logger:, api: and ota:.
Hi Jörg,
You’re the Men. Looking at yours example I’ve notice that in i2c dafinition you give id to i2c bus - that’s somthing I did miss. I was confused by the configuration description - * i2c_id** (Optional): The I²C Bus ID Defaults to false, - insted of → should refer to i2c bus configuration id :(,
Thanks for your accurate hint,
Now the code is compiling, In the evening I’ll check if it works :),
I’m still puzzling about something related to the I2C Multiplexer usage.
In the TCA9548A docs it currently is not specified that one can and/or should specify the I2C “address” for sensors, like you do in your example:
If you omit the address the sensor component will use a default value. For your BH1750 this is 0x23.
Have a look into the docs of BH1750:
address (Optional, int): Manually specify the I²C address of the sensor. Defaults to 0x23 (address if address pin is pulled low). If the address pin is pulled high, the address is 0x5C.
In my case I needed an address that deviated from the default of my SHT3X-D component (0x45 instead of 0x44). So I had to use the address property.
The scan: option really only changes the log output (and costs a bit of boot time).
It is not necessary for normal operation. But it shows, which I2C clients are found on the bus and displays them in the log. This is very helpful when the ESP does not connect to your I2C clients and you are analyzing the problem.
If you set scan: to true (or omit it, which defaults to true), you will find something like this in your log:
This does not mean that the ESP will use these addresses. It is a simple scan that shows you the clients that are available on the bus. You still have to connect them using the address property of a corresponding sensor in your YAML (or the default address of a sensor, as explained above).
@Jpsy Hi know its 2 years later no but Im struggeling since 3 days with my DHT20 sensors (basically aht10; I2C communication) connected via a TCA9548A to an ESP32 in ESPHome.
I tried the example config of the ESP Home Website aswell as your givin YAML Code, I always get the notification in the log that the communication with the aht10 failed.
The first thing I noticed here is that you are missing all pull-up resistors on the I2C busses on both sides of the TCA9548A. This can very well ruin your I2C communication and make it unstable. Missing pull-ups are an issue that is found so often on I2C circuit diagrams on the web that I always wonder how all these circuits could ever have worked.
You have to add the following pull-ups
3.3V –[ ]– SCL
3.3V –[ ]– SDA
3.3V –[ ]– SC0
3.3V –[ ]– SD0
(And also to the other SCn / SDn if they are in use.)
The resistance of the pull-ups is rather uncritical. 4.7 kΩ should be fine in most cases.
I also recommend to clamp A0 / A1 / A2 to GND and !RST to 3.3V.
Check the datasheet of TCA9548A. There is a circuit diagram of a typical application on page 18:
Hi @Jpsy Thanks for answering, I tried out the wiring as recommended (see in the pictures) but actually with the resistors (5,1K) the log tells me no I2C devices found. Without the resistors same as before: I2C devices found (0x38) but later communication with AHT10 failed
Im almost giving up and buy DHT11 which only neet any gpio
Looks all good to me.
What is your I2C frequency? Start low (50kHz) and only increase it if it works flawlessly.
Do you have the parts at hand to build a second circuit without reusing any parts from the existing unit? This is what I usually do when I try to spot defective hardware. When the second one works I swap parts until it fails.
