issues
issues copied to clipboard
esphome
compiliation fails for raspberry pi pico after update
The problem
A previously working device no longer compiles after updating to 2023.12.1
INFO ESPHome 2023.12.1
INFO Reading configuration /config/esphome/picow.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing picow (board: rpipicow; framework: arduino; platform: https://github.com/maxgerhardt/platform-raspberrypi.git)
--------------------------------------------------------------------------------
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
- framework-arduinopico @ 1.30600.0 (3.6.0)
- tool-rp2040tools @ 1.0.2
Flash size: 2.00MB
Sketch size: 1.00MB
Filesystem size: 1.00MB
Maximium Sketch size: 1044480 EEPROM start: 0x101ff000 Filesystem start: 0x100ff000 Filesystem end: 0x101ff000
Dependency Graph
|-- WiFi @ 1.0.0
|-- LEAmDNS @ 1.2
|-- Updater @ 1.0
|-- noise-c @ 0.1.4
|-- MD5Builder @ 1.0.0
|-- lwIP-Ethernet @ 1
|-- lwIP_CYW43 @ 1
|-- SPI @ 1.0
Linking .pioenvs/picow/firmware.elf
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: unrecognized option '--no-warn-rwx-segments'
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
*** [.pioenvs/picow/firmware.elf] Error 1
========================= [FAILED] Took 23.62 seconds =========================
Which version of ESPHome has the issue?
2023.12.1
What type of installation are you using?
Home Assistant Add-on
Which version of Home Assistant has the issue?
2023.12.3
What platform are you using?
RP2040
Board
rpipicow
Component causing the issue
platform
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
I had the same problem updating to 2023.12.0, I rolled back to 2023.11.6 recompiled, installed 2023.12.0 again and was able to recompile with no issues. I have just updated to 2023.12.1 and the picow compiles with no issues. Hope this helps.
That worked here. I noticed that gcc was updated to a version 12 build when dropping esphome back to 2023.11.6 so seemingly the bug was not triggering an update of the toolchain correctly.
I had the same problem updating to 2023.12.0, I rolled back to 2023.11.6 recompiled, installed 2023.12.0 again and was able to recompile with no issues. I have just updated to 2023.12.1 and the picow compiles with no issues. Hope this helps.
This process didn't work for me; what did work was removing the PlatformIO files (on my system it was ~/.platformio) and recompiling a configuration, which triggered a redownload of the toolchain. I'm not sure if this is an esphome bug, a PlatformIO bug, or a bug in maxgerhardt/platform-raspberrypi.
Same issue here.
INFO ESPHome 2023.12.3
INFO Reading configuration /config/esphome/front-door.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing front-door (board: rpipicow; framework: arduino; platform: https://github.com/maxgerhardt/platform-raspberrypi.git)
--------------------------------------------------------------------------------
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
- framework-arduinopico @ 1.30600.0 (3.6.0)
- tool-rp2040tools @ 1.0.2
Flash size: 2.00MB
Sketch size: 1.00MB
Filesystem size: 1.00MB
Maximium Sketch size: 1044480 EEPROM start: 0x101ff000 Filesystem start: 0x100ff000 Filesystem end: 0x101ff000
Dependency Graph
|-- WiFi @ 1.0.0
|-- LEAmDNS @ 1.2
|-- Updater @ 1.0
|-- noise-c @ 0.1.4
|-- MD5Builder @ 1.0.0
|-- lwIP-Ethernet @ 1
|-- lwIP_CYW43 @ 1
|-- SPI @ 1.0
Linking .pioenvs/front-door/firmware.elf
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: unrecognized option '--no-warn-rwx-segments'
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
*** [.pioenvs/front-door/firmware.elf] Error 1
========================= [FAILED] Took 22.97 seconds =========================
If you're using the addon, then you need to ssh into the host or container to access the files. The easier method would be to re-install the addon.
Assuming you are running HA OS and have the ssh addon installed and configured
ssh [email protected]
sudo docker ps
Made a note of the container ID of esp home bb1547142a11
I entered the shell of the container
docker exec -it bb1547142a11 /bin/bash
rm ~/.platformio/*
Then I re-tried the install from the UI and I had the same issue So then I did (still inside the esphome addon docker container)
rm -r /data/cache/platformio/*
I re-tried the firmware install/update, there was a long time downloading and unpacking software... And it worked, although it took 1033.84 seconds
Yes, the /data location was the right place. And you deleted all the cached data, so it has to download again. Sounds like you need something a bit more powerful to compile on though. :-)
Have the same issue, but am unable to see the docker containers. `mycomputer ~ % ssh [email protected] [email protected]'s password:
| | | | /\ () | | | | | |__| | ___ _ __ ___ ___ / \ ___ ___ _ | | __ _ _ __ | | | __ |/ _ | ' \ _ \ / _ \ / /\ \ / __/ __| / __| __/ \ | ' | __| | | | | () | | | | | | / / ____ \ __ \ __ \ || (| | | | | | || ||_/|| || |_|_| // __//|/__,|| ||_|
Welcome to the Home Assistant command line.
System information IPv4 addresses for end0: 192.168.1.12/24 IPv6 addresses for end0: fe80::300:6cab:c4f8:8124/64
OS Version: Home Assistant OS 11.2 Home Assistant Core: 2023.12.3
Home Assistant URL: http://homeassistant.local:8123 Observer URL: http://homeassistant.local:4357 [core-ssh ~]$ sudo docker ps -bash: sudo: command not found [core-ssh ~]$ docker ps -bash: docker: command not found [core-ssh ~]$`
This is the version I run: Core 2023.12.3 Supervisor 2023.12.0 Operating System 11.2 Frontend. 20231208.2
Hmm possible that when you ssh you are directly entering the home assistant core container. Rather than the host OS machine running the containers...
Prologue: 2023.12.5 did not fix this for me.
Ah... not in the core, it's in the addon's docker container. Makes sense.
I didn't touch the .platformio file, just deleted the raspberrypi files:
rm -r /data/cache/platformio/raspberrypi*
And it worked for me.
Thanks @HarvsG & @danielkent-net
For anyone else on HA OS, here's how to enable this access: https://developers.home-assistant.io/docs/operating-system/debugging/
Was unable to get the USB-method to work referenced in the developers URL. Tried formatting both in FAT and in ext4, and even made sure the privileges on the file "authorized_keys" were correct. No go!
The command would look successful:
[core-ssh .ssh]$ ha os import Command completed successfully.
but still no login, just the "Connection refused" for port 22222. Reboot also did absolutely nothing but waste time!
Even tried to connect a monitor and a keyboard to my HA-blue, screen worked fine, but keyboard refused to work!
Eventually found out I could add the repo: https://github.com/adamoutler/Addons Then installed the plugin: "HassOS SSH port 22222 Configurator" Configured the "id_rsa.pub": "ssh-rsa xxyywwzzz_etc" in the plugin. Made sure to turn off protection mode, then hit the start button and observe the logs. Rebooted HA, and port 22222 should now be accessible form the host. I uninstalled the Add-On at this point.
After logging in, ran "docker ps |grep esphome" and noted the CONTAINER ID of "ghcr.io/esphome/esphome-hassio". Then ran "docker exec -it 4ac1b0663a3b /bin/bash". Then instead of doing "rm -r /data/cache/platformio/raspberrypi*" I only removed "raspberrypi" with "rm -rf /data/cache/platformio/platforms/raspberrypi/".
All working now!
2023.12.5 also did not fix this for me. But shutting down the regular install, running the dev version, and installing from there works fine. Virtualized Hassio, tried the remove directory and there was no match.
On Mon, Dec 25, 2023 at 4:55 PM Odin Brodersen @.***> wrote:
Was unable to get the USB-method to work referenced in the developers URL. Tried formatting both in FAT and in ext4, and even made sure the privileges on the file "authorized_keys" were correct. No go! The command would look successful: [core-ssh .ssh]$ ha os import Command completed successfully. but still no login, just the "Connection refused" for port 22222.
Even tried to connect a monitor and a keyboard to my HA-blue, screen worked fine, but keyboard refused to work!
Eventually found out I could add the repo: https://github.com/adamoutler/Addons Then installed the plugin: "HassOS SSH port 22222 Configurator" Configured the "id_rsa.pub": "ssh-rsa xxyywwzzz_etc" in the plugin. Made sure to turn off protection mode, then hit the start button and observe the logs. Rebooted HA, and port 22222 should now be accessible form the host. I uninstalled the Add-On at this point.
After logging in, ran "docker ps |grep esphome" and noted the CONTAINER ID of "ghcr.io/esphome/esphome-hassio". Then ran "docker exec -it 4ac1b0663a3b /bin/bash". Then instead of doing "rm -r /data/cache/platformio/raspberrypi*" I only removed "raspberrypi" with "rm -rf /data/cache/platformio/platforms/raspberrypi/".
All working now!
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/5262#issuecomment-1869128939, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADS77O5BS4V7V35M6BZAGDYLHY3PAVCNFSM6AAAAABA6V7OCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZGEZDQOJTHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Unfortunately all of the above fail for me, including removing and reinstalling the extension. Same error as shown above
Luckily I had created a backup with my 2023.11.6 version, before I upgraded to 2023.12.5
So when I encountered the error, I clicked on my backup file -> Partial backup (restore) -> only selected ESPHome under Add-ons -> Restore
After the restore, I noticed logs weren't coming through, but then I rebooted Home Assistant, and now everything is working fine again.
I'm running esphome/esphome in a Docker container
Removing the folder config/.esphome/platformio/ was my solution. rm -r /config/.esphome/platformio/. I can now compile on RP2040
Can confirm removing /data/cache/platformio/* in the esp home docker container fixed the compilation
We encountered the same issue when updating our GGreg20_V3 Geiger counter example for RPi Pico W. We have ESPHome deployed as a Home Assistant integration in a virtual machine.
The solution for us was to restore with a partial backup back to the version with which there was no problem (December 2023). And after that, without any other action, we immediately upgraded to the newest version using the update. At the same time, our ESPHome configuration files were not affected - all the latest versions of the files were saved with the changes made in recent days.
BR, Oleksii IoT-devices, LLC
I used the beta version today, and it compiled and uploaded. Beta 2023.12.7
On Sat, Dec 23, 2023 at 1:38 PM jshep321 @.***> wrote:
Same issue here with 2023.12.3. I can't find the .platformio directory to save my life (even using sudo find ...)
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/5262#issuecomment-1868348829, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADS77JY6CE52JAMGHTHRQ3YK4QLRAVCNFSM6AAAAABA6V7OCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYGM2DQOBSHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
After talking with people on the discord, we found that uninstalling esphome and re-installing it fixed the issue. This has been tested on two instances so far.
In my previous message, I got esphome working again by downgrading the version, from 2023.12.5 to 2023.11.6
Today, I upgraded esphome from the previous non-broken version I was using 2023.11.6, to 2023.12.9. Pi Pico compilation works on both these versions.
Yes, everything went well with us too with the upgrade to the latest 2023.12.9 version of ESPHome for our repository Raspberry Pico W + GGreg20_V3 Geiger counter
Everything is working fine now.
But at first, as described earlier, we had to do a downgrade (2023.12.5 -> 2023.11.6) from backups.
Still broken. 2023,12,9 I will not remove an existing install to make this work. You need to fix this
On Sat, Dec 23, 2023 at 1:38 PM jshep321 @.***> wrote:
Same issue here with 2023.12.3. I can't find the .platformio directory to save my life (even using sudo find ...)
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/5262#issuecomment-1868348829, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADS77JY6CE52JAMGHTHRQ3YK4QLRAVCNFSM6AAAAABA6V7OCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYGM2DQOBSHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Then it will stay broken. There's nothing esphome can do about this. It's a platformio issue. Re-installing the addon is quick and easy, so I don't know what your problem is with that.
Did it, and it didnt work. Hey... your windshield wipers dont work. Nothing that can be done about it. I want a solution where it just works. Where I dont need to play with it, uninstall it, all because someone didnt do their regression testing.
On Tue, Feb 20, 2024 at 7:32 PM Samuel Sieb @.***> wrote:
Then it will stay broken. There's nothing esphome can do about this. It's a platformio issue. Re-installing the addon is quick and easy, so I don't know what your problem is with that.
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/5262#issuecomment-1955517472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADS77KWZXNOD2E4KNB6TBTYUU6BNAVCNFSM6AAAAABA6V7OCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJVGUYTONBXGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I am getting this error using the esphome docker image. I've wiped everything I could find that appeared to be a cache, and it seems to work now. This issue isn't just limited to the HA plugin.
