How to fix ADC2 on ESP32-S3 platform

ESPHome
1

Hello!

Assuming that esp32-s3 is a supported platform by now, I am stuck with some error messages, indicative that when it comes to ADC2, esphome could be operating in parallel, imaginary reality.

The code

esp32:
  board: esp32s3box
  framework:
    type: arduino

sensor:
  - platform: adc
    id: battery_voltage
    pin:
      number: GPIO14

produces an error

Failed config sensor.adc: ESP32S3 doesn't support ADC on this pin when Wi-Fi is configured.

This is kind of untrue. esp32 errata doesn’t apply to esp32-s3 to the full extent. Who can fix that misconception about ADC2 and Wi-Fi, please?

Using the hint 'ignore_pin_validation_error: true', I enter into an uncharted territory. Instead of ignoring the pin validation error, esphome puts a different excuse forward: 'GPIO14 is not a reserved pin'. Excuse me! Reserved by whom?! And what for?

This bug results in developers going an extra mile, with introduction of redundant code and more importantly new bugs.

External component

external_components:
  - source: github://kaeltis/esphome-lilygo-t547plus
    components: ["lilygo_t5_47_battery"]

simply does analogRead(14), turns EPD power on and off unnecessarily, introduces an extra delay(100) and hard codes 2x unnecessary for this component libraries ("Wire", version="2.0.0") and ("LilyGoEPD47", repository="https://github.com/Xinyuan-LilyGO/LilyGo-EPD47", version="v0.3.0").

What’s the easiest way to get past 'not a reserved pin' on esp32-s3, please? Assuming, of course, that component adc is using a reference code and is supported on esp32-s3.

The full log is like follows 
t547plus.yaml
~~~~~~~~~~~~~
esp32:
board: esp32s3box
framework:
  type: arduino

sensor:
- platform: adc
  id: battery_voltage
  pin:
    number: GPIO14
    #ignore_pin_validation_error: true
---

esphome compile t547plus.yaml        
<snip />
Failed config

sensor.adc: [source t547plus.yaml:65]

ESP32S3 doesn't support ADC on this pin when Wi-Fi is configured.
platform: adc
id: battery_voltage
pin: 
  number: 14
  mode: 
    input: True
    output: False
    open_drain: False
    pullup: False
    pulldown: False
  inverted: False
  ignore_pin_validation_error: False

---

esphome compile t547plus.yaml
<snip />
Failed config

sensor.adc: [source t547plus.yaml:65]
platform: adc
id: battery_voltage

GPIO14 is not a reserved pin.
pin: 
  number: GPIO14
  ignore_pin_validation_error: True

/question
/bugreport

2

Perhaps don’t use the Arduino framework

ESP-IDF framework

This is an alternative base framework for ESP32 chips, and recommended for variants of the ESP32 like ESP32S2, ESP32S3, ESP32C3 and single-core ESP32 chips.

3

Thank you, @nickrout , for your suggestion!

Having esp32.framework.type: esp-idf results in exactly the same set of errors :face_with_raised_eyebrow:.

esp32.framework.type: esp-idf 
esp32:
  board: esp32s3box
  framework:
    type: esp-idf

From architectural point of view, having a meta language / meta framework which is detached from reality is a barely viable option. The battery component I was referring to has been introduced two years ago. Two years is more than enough for esphome to accommodate the then new esp32-s3.

Does something similar to 'ignore_pin_validation_error: true' exist to overcome 'not a reserved pin' or to make it ‘reserved’ otherwise?

4

Exactly what device do you have?

5

It’s Lilygo T5 e-Paper 4.7 Inch ESP32-S3 Development Driver Board V2.14.

ADC pin 14 is documented on the product pin diagram picture in the middle of the page and on schematics.

Rerefence code, provided by the vendor, compiles well on platformio and Arduino. It’s confirmed as fully functional. It reads as

#https://github.com/Xinyuan-LilyGO/LilyGo-EPD47/tree/esp32s3
#elif defined(CONFIG_IDF_TARGET_ESP32S3)
#define BATT_PIN   (14)

<snip />
analogRead(BATT_PIN)

I’ve checked with the sensor.adc code. It looks fully functional to me. I’d guess the issue sits with the meta language interpreter?

6

As you are trying to use a custom component developed by someone else, why don’t you ask there?

Lilygo notoriously publish incorrect schematics.

And why are you using esp32s3box, which is s different device?

7

As you are trying to use a custom component

I am using standard component ADC. Esphome bug prevents me from using legitimate pin 14 on supported esp32-s3 platform.

Why should I talk to custom component developers, please? Isn’t sensors.adc something standard?

Lilygo notoriously publish incorrect schematics.

This is of no relevance to the esphome bug. Furthermore, I confirm battery voltage is measured correctly using vendor-wired GPIO14. It’s working using reference Arduino and platformio development platforms. It fails to build on esphome meta language interpreter because of a two year old misconception which isn’t backed up by espressif documentation.

Reality check: is esp32-s3 officially supported / experimental / dev branch only?

why are you using esp32s3box, which is s different device

I dislike platformio. To start with, it’s esphome who forces me to use platformio to build the firmware. I wish I could avoid platformio bugs altogether:

  • It all starts on platformio registry
  • Filter MCU column by ESP32S3
  • Sort Flash column in descending order
  • Line eight, Espressif ESP32-S3-Box is what it translates to on esphome YAML

Please, pay attention to yet another bug / misconception, this time on platformio side. Column RAM reads 320 KiB for all the entries with 16 MiB flash. Contrary to platformio misbelief, ESP32-S3-WROOM-1-N16R8 does exist (page 3).

I am not asking to fix platformio bugs here. It’s esphome what’s being unreasonable to me, and I can definitely accomplish a subset of my objectives if I don’t use esphome. Isn’t the illustration of the bugs introduced by custom component developers a good reason to fix esphome? Developers are simply trying to overcome esphome bugs and misconceptions.

Which part of the esphome repository is responsible for YAML interpreter, please?

1 Like
8

That is a custom external component. I suggest you take this to esphome GitHub, and to start minding your manners towards people who are just trying to help.

9

That is a custom external component.

The reference you quote was an illustration of an anti-pattern. This is what esphome project forces people to do.

My code below has nothing to do with the custom component. I am after sensors.adc on pin 14. Who shall I talk to to convince them that pin 14 can be used by ADC2 on esp32-s3 platform? Who owns the YAML interpreter? What is the challenge to admit that essential espressif documentation update has been missed?

I wanted to give community back a bug free update for the latest Lilygo T5 4.2 inch epaper screen. The screen is perfectly operable for my purposes using the reference vendor’s code. No esphome is required.

10

Take it to esphome GitHub.