RP2040 Support #1924
Comments
|
Thanks for working on support for RP2040 in esphome! I understand this is probably a bit early to ask, but what's holding I2C back? I'd love to be able to attach a BME280 sensor, which requires I2C to be defined. currently results in: |
|
When trying to compile for a Pico W ( If I add a valid |
|
I also wanted to control the onboard LED on the Pico W. On the regular Pico, I can do so with GPIO 25: output:
# For Raspberry Pi Pico (non-W)
- platform: gpio
pin:
number: 25
mode: output
id: LEDIs there any way to control |
|
The LED now works with: output:
# For Raspberry Pi Pico W
- platform: gpio
pin:
number: 32 # 25 for Pico (non-W)
mode: output
id: LEDBut for some reason whenever I try adding WiFi config, e.g. (With or without fast_connect, and with valid ssid/password stored in ...it results in a crash — with And if I monitor the serial port Here's a minimum example that I've confirmed seems to go into that crash/non-connect loop on two different Pico W's on two different WiFi 2.4 GHz networks (both tested working on an ESP32): ---
esphome:
name: rpi-pico
rp2040:
board: rpipicow
framework:
platform_version: https://github.com/maxgerhardt/platform-raspberrypi.git
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
fast_connect: true
logger:
level: DEBUG |
|
@bertvdijk Thanks for testing this. I have merged a PR today to fix I2C due to API differences (So much for Arduino frameworks/libraries having a common API) I have tested this code with my i2c pn532 and it is reading nfc tags correctly. Jesse |
|
@jesserockz @balloob — Thanks for the help over the past day; I am still having the WiFi issue, and I've tried on two different Pico W's, and two different ESP32s (all brand new); the ESP32s connected without issue, with the same configuration, whereas the Pico W's did not (they did the connect/boot loop). I also tested on two different WiFi networks—one an ASUS router the other a Netgear, both 2.4 GHz networks that I have other ESP and Pi/Pico devices on. And both networks also worked fine when I flashed the MicroPython examples within this repo—I could access the webserver running on the Pico W from my Mac on the same network. I also tested with two different USB cables and on two different USB ports on my Mac, and also separately on a fresh install of Raspberry Pi OS directly on my Raspberry Pi 4. In all cases, it keeps doing that WiFi connect/boot loop :( So I've created a set of reproducible steps using the official Docker image. Can you please try the same thing and triple-check that it works on your end. If it does, I think I'm just cursed or something:
Then monitor serial output and see if the Pico W connects or just gets stuck in a boot loop (on my Mac, I used CoolTerm and watched |
|
@geerlingguy I've just tried this with a virgin Pico-W captured with Minicom under Linux.
Once it gets to this point it then just sits there but it is connecting fine, no loops & I can ping the pico. |
|
@peter-mount - Thanks so much! So the exact same setup works for you — can you share what type of WiFi router you have? I also heard from @mietz8 on Twitter (https://twitter.com/mietz8/status/1586053083594985473) that he's getting a boot loop. |
|
@geerlingguy Linksys Velop AC3900 Mesh WiFi (dual band) with 3 nodes in the mesh. |
Tested on fresh new PicoW, fresh copy of µPython is running fine. |
|
I was able to compile the UF2 on a remote Ubuntu box that has docker on it, and copy the UF2 on to my Pico W using my Windows 10 box. Power cycling the device and quickly connecting to it via Putty on COM8 and I managed to get at least this last bit of the output. Putty won't keep the window open to capture everything form initial boot so if anyone knows of a good Windows utility I can use to monitor Serial COM ports through disconnects, I can try something other than Putty. As for my router, using a Unifi UDM-Pro + UAP-FlexHD with I believe the standard settings for the 2.4 GHz network I have the Pico W connecting to. |
|
Okay, adding more info here since I've been up to my neck in debugging:
Tested with fast_connect both enabled and disabled. So it looks like any newer WiFi 6 routers that default to setting up their 2.4 GHz networks in ax / WiFi 6 mode might have an issue here (strangely, they don't have an issue under MicroPython on the same Pico W...). I had to manually set my ASUS WiFi 6 router (RT-AX86U) into Legacy mode to get esphome on the Pico W to connect and not do the reboot/crash loop:
I did not have to set it into the Legacy mode for either the Pico W with MicroPython or the ESP32 with the same esphome configuration. |
|
Is the WiFi library being used by ESPHome missing some WiFi connection settings or needs some additional checks for newer 2.4 GHz networks. Maybe the MicroPython network library has some newer WiFi code that can correctly handle newer WiFi networks. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
This is not a place to discuss how to run Pico. I thought I had made this clear by marking the original issue as off-topic. Stop posting about this. This issue is to track development and that's what all replies need to be about. |
|
Is this the right place to track RP2040 support for the bluetooth_proxy component? |
|
@brunsy - That should probably be elsewhere. Right now, at least, bluetooth support (though supposedly supported at the hardware level) is not even an official feature of the Pico W.
|
|
Not sure if this is the correct place to report missing functionality but I've come across the following issues while attempting to replace Espressif devices with Raspberry Pico W. It's currently not possible to use the Time component (platforms: sntp, homeassistant) in ESPhome with RP2040. and:
First example (time platform sntp): Second example (time platform homeassistant):
It's not possible to use the MQTT in ESPHome with RP2040.
and: |
|
Hi @bertvdijk, thanks for the report. I have fixed the MQTT on the other hand will probably not be implemented by me for now. I won't stop someone else sorting it out though. I will mark is an unavailable in esphome/esphome#4025 |
|
@jesserockz Can you give a quick summary of what you think would be needed for mqtt support? I'm a heavy mqtt user in my setup. |
|
@jesserockz Is this the right place to track RP2040 support for the |
|
Hi everyone, Thanks, |
Does this mean RP2040 is now merged into the main branch?! |
|
It's already released: https://esphome.io/changelog/2022.11.0.html |
Just an update on this seems like the issue lies in DHCP if you switch to using a manual IP (see below) then there is no need to mess with router settings. |
Describe the problem you have/What new integration you would like
Mainstream support for RP2040
Here is a list of things that have not be written or tested:
Pico devices fail to get enough random bytes for encrypted connections
[11:06:51][D][api:102]: Accepted 192.168.1.160[11:06:51][E][api.socket:735]: Failed to acquire random bytes, rebooting!Please leave a comment below if there are more things to add to this list, or you have a PR that solves something for the RP2040
The text was updated successfully, but these errors were encountered: