Adafruit ESP32-S2 Feather using WipperSnapper no longer detects on board LC709203F battery monitor over I2C at address 0x0b

[khpacific]

Issue Copied from original report submitted via "report bugs" feature on Adafruit IO: Both of my ESP32-S2 lost the ability to report battery V and %. I updated one board from Beta.59 to Beta.65 and then to Beta.67 after some connection issues. The board uses a soldered on LC709203F and the New Component I2C scan reports the Possible Device Address as 0xb which looks like it's missing a digit and should be 0x0b according to the board documentation. When the scan finishes it reports "No matching, unused addresses found!" The devices page I2C scan does not show the address on the grid, but it does report the AHT20 sensor I've connected over stemma and the onboard BME280.

I'm not sure if this is a wipper or IO issue as the other board I have has not been updated from Beta.59 and hasn't been touched in months but still shows the same address issue for the LC709203F component that used to work.

Addition: I realize this component was recently discontinued and replaced but does that also mean support was removed for it?

Board Adafruit ESP32-S2 Feather with BME280 Sensor - STEMMA QT - 4MB Flash + 2 MB PSRAM PID: 5303

To Reproduce Follow the "new component" steps at io.adafruit.com for Devices, Pick the device, New Component, select LC709203F from the options presented. Use the I2C scan at io.adafruit.com, Devices, Pick the device.

Expected behavior The on board LC709203F is discoverable at address 0x0b per the docs and can be added as a component.

Which components are connected to your device Adafruit AHT20 - Temperature & Humidity Sensor Breakout Board - STEMMA QT / Qwiic PID: 4566 Lithium Ion Cylindrical Battery - 3.7v 2200mAh PID: 1781

Screenshots

Desktop (please complete the following information):

• OS: Windows 10 22H2, build 19045.3208
• Browser: Firefox
• Version: 115.0.2
• Browser: Chrome
• Version: 115.0.5790.110

Board connects via Wifi to Adafruit IO

[brentru]

@khpacific Hi, I tested this with an Adafruit ESP32-S2 Feather running Beta 67 and did not have issues with the I2C scan or new component form for the LC709203F.

Addition: I realize this component was recently discontinued and replaced but does that also mean support was removed for it?

We did not discontinue support for it within WipperSnapper.

I'm not sure if this is a wipper or IO issue as the other board I have has not been updated from Beta.59 and hasn't been touched in months but still shows the same address issue for the LC709203F component that used to work.

It actually might be an issue with your specific Feather board. Did you purchase it recently? As of June 14, 2023 - We have changed the battery monitor chip from the now-discontinued LC709203 to the MAX17048.

---

Test results

I2C Scan

New Component form

[khpacific]

Hi @brentru, Edit: Thanks for the answers It was purchased on 1/23/23. But seeing your screenshot of the scan made me realize I hadn't tried unplugging the AHT20, I had only unplugged the battery for testing. After removing the battery and AHT20 then resetting the board, the LC709203F appeared in the scan results. I added back the AHT20, reset, still there. Added back the battery, reset, still there. With the battery and the sensor plugged I created the component again and this time it was found and accepted.

The problem seems to be resolved as it's available and reporting regardless of the other components now. Though the address like in your screenshot of the component creation still shows as 0xb. I'm assuming having a 0 between x and b is not important for the address?

[brentru]

@khpacific Glad the issue was fixable on your end!

@lorennorman

Though the address like in your screenshot of the component creation still shows as 0xb. I'm assuming having a 0 between x and b is not important for the address?

Is this an edge case with the web form showing 0xb? The component definition lists 0x0B as the address: https://github.com/adafruit/Wippersnapper_Components/blob/main/components/i2c/lc709203f/definition.json#L4

[lorennorman]

Yep, at first glance I believe this is a purely cosmetic issue in the web where we're accidentally dropping a leading zero before building the full hex string. Making a note to chase this down soon.

Thanks for the thorough report and screenshots, @khpacific!