Closed muei closed 4 months ago
The same problem.
After update to esp-idf-svc
version 0.49.0, it's been working fine with 0.48.
My last working Cargo.toml:
[dependencies]
anyhow = "1.0.86"
embassy-futures = "0.1.1"
# esp-idf-svc = { version = "0.48", default-features = false }
esp-idf-svc = { git = "https://github.com/esp-rs/esp-idf-svc", rev = "b6c85f0c0b15fd823ba61119fe1361c227eee504" }
log = { version = "0.4.21", default-features = false }
thiserror = "1.0.61"
[build-dependencies]
embuild = "0.31.3"
# https://github.com/esp-rs/std-training/issues/253
[patch.crates-io]
embedded-svc = { git = "https://github.com/esp-rs/embedded-svc", rev = "7cf5654d685830879656d5c7f987de659ba3e587" }
esp-idf-hal = { git = "https://github.com/esp-rs/esp-idf-hal", rev = "e4e608908ed3deaa0be09d3de6bcc2478ba796ac" }
My last working config.toml:
[build]
target = "riscv32imc-esp-espidf"
[target.riscv32imc-esp-espidf]
linker = "ldproxy"
# runner = "espflash --monitor" # Select this runner for espflash v1.x.x
runner = "espflash flash --monitor" # Select this runner for espflash v2.x.x
rustflags = [ "--cfg", "espidf_time64"] # Extending time_t for ESP IDF 5: https://github.com/esp-rs/rust/issues/110
[unstable]
build-std = ["std", "panic_abort"]
[env]
MCU="esp32c3"
# Note: this variable is not used by the pio builder (`cargo build --features pio`)
ESP_IDF_VERSION = "v5.1.3"
# Workaround for https://github.com/esp-rs/esp-idf-template/issues/174 until
# https://github.com/esp-rs/esp-idf-hal/pull/387 gets released and the template
# updated.
CRATE_CC_NO_DEFAULTS = "1"
This has fortunately nothing to do with new vs old esp-idf-svc
version and is actually caused by the speed (and number of re-connect attempts) with which the MQTT examples you are trying happen to work in your concrete network.
In the MQTT blocking and async examples, there was a race condition between the client trying to connect, and our code trying to call client.subscribe(...)?
.
The thing is, if the client fails to connect fast enough (or tries to connect, fails, and then re-tries after a while), we may end up calling client.subscribe(...)?
when the client is not (yet) connected, and as a result, the subscribe
call would fail, and the whole example would fail.
I updated the examples to just call subscribe
in a loop and re-try on unsuccessful subscribe every 0.5s, so it should work for you now (I was able to reproduce your problem with a c3 and ESP IDF 5.2.2; couldn't reproduce it with an xtensa esp32 and ESP-IDF 5.1.2).
Here's my log, and how it should hopefully look the same for you with the updated examples:
I (3323) wifi:set rx beacon pti, rx_bcn_pti: 14, bcn_timeout: 25000, mt_pti: 14, mt_time: 10000
I (3333) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (3343) mqtt_client: Wifi connected
I (3343) wifi:<ba-add>idx:0 (ifx:0, c4:ad:34:30:cf:a9), tid:0, ssn:3, winSize:64
I (4343) esp_netif_handlers: sta ip: 192.168.30.150, mask: 255.255.255.0, gw: 192.168.30.1
I (4343) mqtt_client: Wifi netif up
I (4353) mqtt_client: About to start the MQTT client
I (4363) mqtt_client: MQTT Listening for messages
I (4363) mqtt_client: [Queue] Event: BeforeConnect
E (4373) mqtt_client: Client has not connected
E (4373) mqtt_client: Failed to subscribe to topic "esp-mqtt-demo": ESP_FAIL, retrying...
E (4873) mqtt_client: Client has not connected
E (4873) mqtt_client: Failed to subscribe to topic "esp-mqtt-demo": ESP_FAIL, retrying...
I (4963) mqtt_client: [Queue] Event: Connected(session: false)
I (5373) mqtt_client: Subscribed to topic "esp-mqtt-demo"
I (5573) mqtt_client: [Queue] Event: Subscribed(12331)
I (5873) mqtt_client: Published "Hello from esp-mqtt-demo!" to topic "esp-mqtt-demo"
The E (4373) mqtt_client: Failed to subscribe to topic "esp-mqtt-demo": ESP_FAIL, retrying...
is key. It used to fail the whole example before. Now it would just re-try until it (hopefully) succeeds.
Attempted multiple mqtt servers, but were unable to connect,logs below