Closed UniKyrn closed 2 years ago
This config got my Lilygo module working - had to install it plugged into the Pi's USB port at first, but now works OTA:
(It was the platform_version: 3.3.2
that finally worked for me. The core versions may have been patched by now?
substitutions:
display_name: 'ESP32 C3 Test'
device_description: 'ESP32 C3 Test for the Lilygo ESP01 board'
friendly_name: 'ESP32 C3 Test'
device_name: esp32c3-test-new
node_name: esp32c3_test_new
esphome:
name: ${device_name}
platformio_options:
board_build.flash_mode: dio
comment: ${device_description}
on_boot:
- priority: 800.0
then:
- component.update: ${node_name}_uptime_raw
- component.update: wifisignal
esp32:
board: esp32-c3-devkitm-1
framework:
type: esp-idf
platform_version: 3.3.2
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
password: "12345"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot in case wifi connection fails
ap:
ssid: "Esp32C3-Test-New"
password: "12345"
light:
- platform: status_led
name: "Onboard LED"
pin: GPIO3
id: esp32c3_onboard_led
icon: mdi:led-off
effects:
- strobe:
- strobe:
name: Strobe Fast
colors:
- state: true
duration: 100ms
- state: false
duration: 100ms
- strobe:
name: Heartbeat
colors:
- state: true
duration: 100ms
- state: false
duration: 100ms
- state: true
duration: 100ms
- state: false
duration: 1000ms
button:
- platform: restart
name: ${display_name} restart
text_sensor:
- platform: wifi_info
ip_address:
name: ${display_name} IP Address
ssid:
name: ${display_name} Connected SSID
bssid:
name: ${display_name} Connected BSSID
- platform: template
name: ${friendly_name} Uptime
id: ${node_name}_uptime
icon: mdi:clock-start
binary_sensor:
- platform: status
name: ${display_name} Status
sensor:
- platform: wifi_signal
name: ${display_name} WiFi Singal Strength
id: wifisignal
update_interval: 120s
- platform: uptime
name: "${friendly_name} Uptime Sensor"
id: ${node_name}_uptime_raw
update_interval: 60s
on_raw_value:
then:
- logger.log:
format: "Raw Value of Uptime sensor: %f, %f"
args: ['id(${node_name}_uptime_raw).raw_state', 'id(${node_name}_uptime_raw).state']
level: INFO
- text_sensor.template.publish:
id: ${node_name}_uptime
state: !lambda |-
int seconds = round(id(${node_name}_uptime_raw).raw_state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
return (
(days ? to_string(days) + "d " : "") +
(hours ? to_string(hours) + "h " : "") +
(minutes ? to_string(minutes) + "m " : "") +
(to_string(seconds) + "s")
).c_str();
The error changes, the key seems to be the Platform Version, but it still is missing a package. Are you on a Dev Branch by chance?
Tool Manager: Installing platformio/toolchain-riscv-esp @ ~1.80400.0 Error: Could not find the package with 'platformio/toolchain-riscv-esp @ ~1.80400.0' requirements for your system 'linux_aarch64'
No, latest release. But this config was done a few releases back. I can test again on the board..
Tested the same Yaml as per above on my HA on my RPi and it installed both OTA and when plugged into my Windows11 machine, in a little ESP01-USB-Serial board.
How are you compiling and installing from ESPHome (OTA, USB, USB on HA?)
I'm trying to compile using ESPHome 2022.6.2 inside my HA install on a RasPi4. I never get to the install stage, it won't compile to even try and install. If it works for you, then your system must have the packages somehow, while mine doesn't..
ESPHome knows the toolchain is missing, tries to download it, but the package it wants to install is missing.
Error: Could not find the package with 'espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2' requirements for your system 'linux_aarch64'
The only thing I can see that may be different is I am running on a 32bit RPi 3, whereas you are on a Pi 4 and on 64bit.... Maybe that is the key to the issue?
Could be, which is why I think it is an ESPHome issue. The toolchains they want to install are not correct for all the various architecture types.
Sounds like a possible solution!
Well, I've stumbled into the same exact issue. Changing the platform version to 3.3.2
gives me the same error @UniKyrn saw.
I'll be watching this issue for updates and if I discover anything, I'll post it here.
Thank's! I still think it's just a config problem, the link to that arch library using a Pi at the compile platform is just wrong.
On Fri, Jul 8, 2022 at 8:07 PM Tyler Kostuch @.***> wrote:
Well, I've stumbled into the same exact issue. Changing the platform version to 3.3.2 gives me the same error @UniKyrn https://github.com/UniKyrn saw.
I'll be watching this issue for updates and if I discover anything, I'll post it here.
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/3408#issuecomment-1179467676, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXDYQYQOPZZTYWV74ACFF43VTDUILANCNFSM5Z4WKBQQ . You are receiving this because you were mentioned.Message ID: @.***>
Well, I got pass that error with this, but I now have a new error 😅
esphome:
name: test-display
platformio_options:
platform_packages:
- framework-espidf @ 3.40300.0
esp32:
board: esp-wrover-kit
framework:
type: esp-idf
platform_version: 3.4.0
But now, I am getting the following:
src/main.cpp: In function 'void setup()':
src/main.cpp:2713:60: error: invalid new-expression of abstract class type 'esphome::lilygo_t5_47_display::LilygoT547Display'
t5_display = new lilygo_t5_47_display::LilygoT547Display();
^
In file included from src/esphome.h:29,
from src/main.cpp:3:
src/esphome/components/lilygo_t5_47_display/LilygoT547Display.h:18:7: note: because the following virtual functions are pure within 'esphome::lilygo_t5_47_display::LilygoT547Display':
class LilygoT547Display : public PollingComponent, public display::DisplayBuffer {
^~~~~~~~~~~~~~~~~
In file included from src/esphome.h:21,
from src/main.cpp:3:
src/esphome/components/display/display_buffer.h:373:23: note: 'virtual esphome::display::DisplayType esphome::display::DisplayBuffer::get_display_type()'
virtual DisplayType get_display_type() = 0;
^~~~~~~~~~~~~~~~
Well, I got pass that error with this, but I now have a new error 😅
esphome: name: test-display platformio_options: platform_packages: - framework-espidf @ 3.40300.0 esp32: board: esp-wrover-kit framework: type: esp-idf platform_version: 3.4.0
But now, I am getting the following:
src/main.cpp: In function 'void setup()': src/main.cpp:2713:60: error: invalid new-expression of abstract class type 'esphome::lilygo_t5_47_display::LilygoT547Display' t5_display = new lilygo_t5_47_display::LilygoT547Display(); ^ In file included from src/esphome.h:29, from src/main.cpp:3: src/esphome/components/lilygo_t5_47_display/LilygoT547Display.h:18:7: note: because the following virtual functions are pure within 'esphome::lilygo_t5_47_display::LilygoT547Display': class LilygoT547Display : public PollingComponent, public display::DisplayBuffer { ^~~~~~~~~~~~~~~~~ In file included from src/esphome.h:21, from src/main.cpp:3: src/esphome/components/display/display_buffer.h:373:23: note: 'virtual esphome::display::DisplayType esphome::display::DisplayBuffer::get_display_type()' virtual DisplayType get_display_type() = 0; ^~~~~~~~~~~~~~~~
Can you try commenting out anything that has to do with display in your config and try to compile again that way? just to see if it works.
The toolchain issue is because Espressif didn't provide a 64-bit ARM compile for that release. @UniKyrn, that arch is correct for a pi if it's running a 64-bit OS. The solution is what was found, you need to use a platform version that will get you a later toolchain release.
Version core-2022.7.7 Installation Type Home Assistant OS Development false Supervisor true Docker true User root Virtual Environment false Python Version 3.10.5 Operating System Family Linux Operating System Version 5.15.32-v8 CPU Architecture aarch64 Timezone America/Los_Angeles Configuration Directory /config Ok, I'm on the 64 version ...
On Tue, Aug 2, 2022 at 12:46 AM Samuel Sieb @.***> wrote:
The toolchain issue is because Espressif didn't provide a 64-bit ARM compile for that release. @UniKyrn https://github.com/UniKyrn, that arch is correct for a pi if it's running a 64-bit OS. The solution is what was found, you need to use a platform version that will get you a later toolchain release.
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/3408#issuecomment-1202137121, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXDYQYSUQCQVGQ4YUXKFTIDVXDG6BANCNFSM5Z4WKBQQ . You are receiving this because you were mentioned.Message ID: @.***>
I am having the same issue with ESPhome (2022.9.0) PI4 wireless updates
Processing espglow (board: esp32-c3-devkitm-1; framework: espidf; platform: platformio/espressif32 @ 3.5.0)
--------------------------------------------------------------------------------
Tool Manager: Installing espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2
INFO Installing espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2
Error: Could not find the package with 'espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2' requirements for your system 'linux_aarch64'
# Home Assistant Glow
#
# Read your electricity meter by means of the pulse LED on your
# meter, useful if you do not have a serial port (P1).
#
substitutions:
device_name: home-assistant-glow
friendly_name: REMOVED
project_version: "3.1.0"
device_description: "Measure your energy consumption with the pulse LED on your smart meter"
pulse_pin: GPIO9
status_led: GPIO5
# imp/kWh rate ⬇ #
pulse_rate: '1000'
# Webserver credentials ⬇ #
# web_username: 'glow'
# web_password: 'REMOVED'
dashboard_import:
package_import_url: github://klaasnicolaas/home-assistant-glow/home_assistant_glow.yaml
esphome:
name: espglow
platformio_options:
board_build.flash_mode: dio
comment: '${device_description}'
project:
name: "klaasnicolaas.home-assistant-glow"
version: "${project_version}"
esp32:
board: esp32-c3-devkitm-1
variant: ESP32C3
framework:
type: esp-idf
sdkconfig_options:
CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
reboot_timeout: 120s
manual_ip:
static_ip: 10.1.1.133
gateway: 10.1.1.254
subnet: 255.255.255.0
dns1: 10.1.1.254
#captive_portal:
# Enable logging
logger:
# Enable improv over serial
improv_serial:
# Enable Home Assistant API
api:
services:
- service: reset_total_energy
then:
- button.press:
id: button_reset_total
password: "REMOVED"
ota:
safe_mode: true
reboot_timeout: 10min
num_attempts: 5
password: "REMOVED"
#web_server:
# port: 80
# auth:
# username: '${web_username}'
# password: '${web_password}'
output:
# - platform: gpio
# pin: GPIO5
# id: output_blue
- platform: gpio
pin: GPIO2
id: output_red
- platform: gpio
pin: GPIO4
id: output_green
light:
- platform: binary
internal: true
id: led_red
name: Red
output: output_red
# Status LED for connection
status_led:
pin:
# Blue LED
number: ${status_led}
button:
- platform: restart
name: "Restart - Glow"
- platform: template
name: "Reset - Total Energy"
id: button_reset_total
on_press:
- pulse_meter.set_total_pulses:
id: sensor_energy_pulse_meter
value: 0
# Sensors for ESP version and WIFI information
text_sensor:
# Installed version
- platform: template
name: "Glow - Installed version"
id: glow_version
icon: "mdi:label-outline"
entity_category: diagnostic
lambda: |-
return {"${project_version}"};
update_interval: 6h
- platform: version
hide_timestamp: true
name: '${friendly_name} - ESPHome Version'
- platform: wifi_info
ip_address:
name: '${friendly_name} - IP Address'
icon: mdi:wifi
ssid:
name: '${friendly_name} - Connected SSID'
icon: mdi:wifi-strength-2
sensor:
# WiFi signal
- platform: wifi_signal
name: "${friendly_name} - WiFi Signal"
update_interval: 120s
# Pulse meter
- platform: pulse_meter
name: '${friendly_name} - Power Consumption'
id: sensor_energy_pulse_meter
unit_of_measurement: 'W'
state_class: measurement
device_class: power
icon: mdi:flash-outline
accuracy_decimals: 0
pin: ${pulse_pin}
# internal_filter: 100ms
on_value:
then:
- light.turn_on:
id: led_red
- delay: 0.5s
- light.turn_off:
id: led_red
filters:
# multiply value = (60 / imp value) * 1000
# - multiply: 60
- lambda: return x * ((60.0 / ${pulse_rate}) * 1000.0);
total:
name: '${friendly_name} - Total Energy'
id: sensor_total_energy
unit_of_measurement: 'kWh'
icon: mdi:circle-slice-3
state_class: total_increasing
device_class: energy
accuracy_decimals: 3
filters:
# multiply value = 1 / imp value
# - multiply: 0.001
- lambda: return x * (1.0 / ${pulse_rate});
# Total day useage
- platform: total_daily_energy
name: '${friendly_name} - Daily Energy'
id: sensor_total_daily_energy
power_id: sensor_energy_pulse_meter
unit_of_measurement: 'kWh'
icon: mdi:circle-slice-3
state_class: total_increasing
device_class: energy
accuracy_decimals: 3
filters:
# Multiplication factor from W to kW is 0.001
- multiply: 0.001
# Enable time component to reset energy at midnight
# https://esphome.io/components/time.html#home-assistant-time-source
time:
- platform: homeassistant
id: homeassistant_time
@jysaloma there's no need to paste your config. The explanation has already been given. There's nothing esphome can do about this other than moving to a newer platformio and Arduino framework. That is in progress, but is currently blocked by issues in the newer Arduino framework.
Then the solution to this issue seems obvious, ESPHome should not claim it supports the board until such a time as it actually does.
On Wed, Sep 21, 2022 at 12:53 PM Samuel Sieb @.***> wrote:
@jysaloma https://github.com/jysaloma there's no need to paste your config. The explanation has already been given. There's nothing esphome can do about this other than moving to a newer platformio and Arduino framework. That is in progress, but is currently blocked by issues in the newer Arduino framework.
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/3408#issuecomment-1254158408, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXDYQYQYQR5VU6XKRYZ45HDV7NRRZANCNFSM5Z4WKBQQ . You are receiving this because you were mentioned.Message ID: @.***>
It does support the board though... I am on a 32-bit platform and have several ESP32C3 boards installed and working fine.
I'm sure it used to state that C3, S2, S3 boards were experimental? Can't see that anymore 😕
Yeah, I remember that warning also. Then it went away and a series of boards was added to the support list, so I pushed the button on a hardware order from AliExpress.
Which of course didn't end well.
Then the solution to this issue seems obvious, ESPHome should not claim it supports the board until such a time as it actually does.
Where do you see any claim that the board is supported? However, other people are using it. You just have to specify the right platform options. And maybe not use an ARM system for the compiling.
When I adopted the board, I was given a default configuration and asked to select the correct board type from a list.
https://registry.platformio.org/platforms/platformio/espressif32/boards?p=4
I was forwarded to that list by ESPHome, so I believed anything on that list was supported. In deed, when I try to compile the sample, I don't get a board error, I get a toolchain error. I have tried specifying the framework based on suggestions here, no joy.
This is, as I've said, on an RPi4 64bit. It might work someplace, but it doesn't work everyplace and an RPi4 is a reasonably popular platform.
esphome:
name: esp01c3
platformio_options:
board_build.flash_mode: dio
platform_packages:
- toolchain-riscv32-esp @ 8.4.0+2021r1
- toolchain-xtensa-esp32s2 @ 8.4.0+2021r1
esp32:
board: esp32-c3-devkitm-1
framework:
type: esp-idf
sdkconfig_options:
CONFIG_COMPILER_OPTIMIZATION_SIZE: y
CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y
CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y
CONFIG_ESP_TASK_WDT_TIMEOUT_S: "10"
Try editing your config like this.
I was forwarded to that list by ESPHome, so I believed anything on that list was supported. In deed, when I try to compile the sample, I don't get a board error, I get a toolchain error. I have tried specifying the framework based on suggestions here, no joy.
Tool Manager: Installing espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r1 INFO Installing espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r1 Error: Could not find the package with 'espressif/toolchain-xtensa-esp32s2 @ 8.4.0+2021r1' requirements for your system 'linux_aarch64'
Nope, can't find that toolchain either.
Given that some boards/architectures are not working, my suggestion is that the popup asking the user to select a board type from the webpage linked to, should link to a webpage your team maintains, that lists what combinations you know do and don't work. It shouldn't link straight to the platformio.org page, since you have no control over what boards might get listed there.
Give users a way to update your list with changes and at least they will have a way to know, before they buy hardware, whether it is expected to work.
Compile the ESPhome firmware on a non-64 bit pi platform? My 32 bit on a pi 3 works perfectly fine with these C3 boards.
That's not a fix, it's a band-aid. What happens when the next board only compiles on an x86 system?
Never said it was a fix? You seem REALLY annoyed at the open source DIY project for not fully supporting your setup 100%?
Can you not buy some ESP32 boards and use those until the platform and underlying framework are worked on and updated - just looking for solutions for you here? Is there something specific that you needed the newer C3 variant of the ESP32 for, or could a standard ESP32 work for you (or even ESP8266)? What does your project need to accomplish - lets see if we can find a new path for you to go down?
That's not a fix, it's a band-aid. What happens when the next board only compiles on an x86 system?
I guess you'll have to use an x86 system to compile it. What do you expect us to do? We can only use the toolchains that are provided. We have no control over that. And really, I'm done with this discussion now.
What triggers me about all of this is that when I reported an issue, I got a lot of excuses and reasons why it wouldn't/couldn't be fixed, but I heard no solutions as to how to avoid the same problem in the future, That is why I suggested you link to your own site and curated list of boards/archs that you know work, or don't. Your user base gets no warning, which bothers me.
As for using other boards, I already have lots of them, the C3 was a new addition.
How to compile with arduino framework and not idf? I was able to do it before, but not anymore. As I was trying to put ble_proxy into the firmware I ended up updating and now i'm unable to make the board boot.
Thing is in the past I was somehow possible to do it, but now I just can't, so kinda sad.
As for other boards - esp01-c3 is needed formfactor for my usecase
The problem
When Trying to adopt a LilyGo ESP32C3 into ESPHome, it fails because of a missing package.
Which version of ESPHome has the issue?
2022.6.2
What type of installation are you using?
Home Assistant Add-on
Which version of Home Assistant has the issue?
No response
What platform are you using?
ESP32-IDF
Board
LILYGO® TTGO T-OI Plus ESP32-C3 RISC-V MCU Wireless Module Development Circuits Board
Component causing the issue
toolchain
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response