Works like a charm, thanks @1technophile !
For anyone that should be interested, here’s a working _env.ini for Seeed Studio XIAO ESP32C3 (basically, what @1technophile posted minus the Neopixel part that is not available on this module):
[platformio]
default_envs = esp32c3-dev-m1-ble
[env:esp32c3-dev-m1-ble]
platform = ${com.esp32_c3_s3_platform}
board = esp32-c3-devkitm-1
board_build.partitions = min_spiffs.csv
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ble}
${libraries.decoder}
${libraries.fastled}
build_flags =
${com-esp.build_flags}
'-DZgatewayBT="BT"'
'-DNO_INT_TEMP_READING=true' ; Internal temperature reading not building on ESP32 C3 or S3
custom_description = BLE gateway on the Seeed Studio XIAO ESP32C3
I’m using a Seeed XIAO C3
(really exciting board: cheap, has integrated battery charging circuit, great BLE/Wifi reception and it is also the smallest dev board around) (but no rgb)
I am new to OpenMQTTGateway and I am very impressed by its quality of documentation. It helped me to get a Seed Studio XIAO ESP32C3 running, leds and button external. I wrote a prod_env.ini based on the airm2m_core_esp32c3 environment, gpio pins changed. The XIAO is running rock solid.
@mrickma : I read your code and comment: you reference a number of LEDs, but as you say, this board has only one… what is the GPIO address of the onboard one? Thanks
@1technophile: I would be pleased! You can publish everything which I post here under a open-source license without asking. @ilgrank: I do not know at the moment. I guess it is either 0 or 1. The board sends errors when you set the pinMode for a GPIO not present.
@1technophile : Alas, it seems you were right about instability. Today it was the first day I’ve put the C3 (running 1.4.0) in place of the previous ESP32 (running 1.2.0)
It ran fine for 6966 seconds, and then stopped responding.
Alas, it is in a remote location and it does not respond to MQTT restart commands, I’ll have to investigate further when I get back to it
btw, its last message in OpenMQTTGateway/SYStoMQTT had these values:
(showing just the ‘interesting’ ones)
Boards can restart after a few hours, we are suspecting a conflict between the wifi and ble coexistence but haven’t found the root cause yet. For example my Olimex Ethernet gateway is rock solid and nerver restart.
But on my regular ESP32 they never stay stuck.
I need to put my C3 sitting longer.
What was the configuration used when he got stuck?
My guess was wrong. I could not switch the on board led of the Seed C3 using GPIO. Then I looked into the Seeed Studio XIAO ESP32C3 schematic and found the led integrated into some power supply circuit but not connected to any GPIO of the C3. So I think that it can not be used for OMG led output.
@ilgrank:
In a different thread argafal and I have exchanged C3 experiences. argafal has a Lolin C3 mini v2.1.0 board. There were three problems,
terrible slowdown by overrun of serial output
complete crash
random reboots
The slowdown was fixed by suppressing serial logging when our boards were not connected to a terminal. For me it also decreased frequency of reboots in that situation.
Complete crashes could be avoided by changing OMG’s standard ${com.esp32_c3_s3_platform} to a newer version. After using espressif32@5.3.0 and newer we had no more complete crash.
argafal is still suffering from occasional reboots. In contrast my Seed C3 is running pretty stable now: “uptime”:84483 without serial connection and logging, “uptime”:48007 with logging and serial connection enabled. In both cases I stopped the C3 manually.
I repost my current configuration because it belongs into this thread:
; Custom configuration file for the Seed XIAO ESP32C3 dev
; Wed, 01 Mar 2023 20:10:45 +0100
;
; Currently there were two problems
; 1. In long term runs ESP32C3 terminate with an assert failure.
; Therefore the standard platform is overridden with a currently newer one.
; One may have to repeat Wifi and MQTT configuration after changing platform.
; 2. Serial output if no terminal is connected slows down everything else.
; For this situation chose the xxx_no_serial variant for default_envs.
; -------------------------------------------------------------------------
[platformio]
default_envs = seeed_xiao_esp32c3
[env:seeed_xiao_esp32c3]
;platform = ${com.esp32_c3_s3_platform} ; standard, problems
platform = espressif32@5.3.0 ; override
board = seeed_xiao_esp32c3
board_build.partitions = min_spiffs.csv
monitor_speed = 115200
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ble}
${libraries.decoder}
build_flags =
${com-esp.build_flags}
'-DZgatewayBT="BT"'
'-DLED_SEND_RECEIVE=10' ; GPIO: 2 - 10, 20, 21
'-DLED_INFO=8'
'-DLED_ERROR=9'
'-DTRIGGER_GPIO=7'
'-DNO_INT_TEMP_READING=true' ; No internal temperature on ESP32 C3 or S3
'-DGateway_Name="OMG_xiao_c3.1"'
custom_description = BLE gateway on Xiao C3
custom_hardware = Seed XIAO ESP32C3 dev
[env:seeed_xiao_esp32c3_no_serial]
extends = env:seeed_xiao_esp32c3
build_flags =
${env:seeed_xiao_esp32c3.build_flags}
'-DLOG_LEVEL=LOG_LEVEL_SILENT' ; shut up
'-DWM_DEBUG_LEVEL=0'
I was posting my current config when I noticed that while I had removed the LEDs from the build flags, I had forgotten to remove ${libraries.fastled}
So I have recompiled just now with this config:
While waiting to try your config (again, thanks!) I wanted to point that while I came to the same conclusion as you for the red LED (i.e., that it is hardwired to the charging circuit, and not* to a GPIO), there’a line in the official docs that seems to suggest otherwise:
The XIAO ESP32C3 will not have any LED on when it is battery powered (unless you have written a specific program), please do not judge whether the XIAO ESP32C3 is working or not by the condition of the LED, please judge it reasonably by your program.
…that’s why I had hope to be able to control it (or at lest turn it off )
Just a quick update: after removing ${libraries.fastled}, I’m at more than 56000 seconds of uptime, and no sign of hangs or reboots so far! Hurray!
(strangely, I always experienced hangs and not reboots as @1technophile described)
I do still plan to experiment with turning off as much as unnecessary (serial logging) as possible, in order to consume as little power as possible (being that the system runs on solar-powered batteries), so I will do some more test on this matter…
Another update: the C3 arrived at 57490 seconds of uptime (roughly 16 hours) and then hang again.
Now trying @mrickma suggestions
Of course, I’ll have to wait for 16+ hours to tell if it has solved the problem or not, but for now I can tell the average power consumption stayed the same (usually, this is a good indicator of “how much stuff is going on”) at roughly 75mA
