I added the “adafruit/Adafruit NeoPixel” library to User_config.h for OMG signalling . At first the result was a bit disappointing. The LED on the ESP32-C3-DevKitC-02 showed only green light (INFO LED). After stopping mosquitto it looked better, a slow red pulse (ERROR LED). With green dimmed I can see intermittent blue flashes (SEND RECEIVCE LED) now.
@argafal Can you test my code on your Lolin board? You can access my changes at GitHub. I also pushed a copy of my OMG build environments. At the very bottom of env_prod.ini you find how I added library and build flags. See you.
@mrickma What a nice addition. I am testing it right now.
-
The first impression is good. I renamed your
env_prod.initoprod_env.iniso that is found bypio. I updated the pin definition for the NeoPixel to match the board:'-DANEOPIX_IND_DATA_GPIO=7'. I also changed the trigger pin to 9. The LED shows a status depending on MQTT connection (blue during boot, red pulse if unconnected, green if connected). Very nice! -
I cannot really see the blue flashes at all. Maybe they would need to be a little bit longer, or the green a bit dimmer while keeping blue at the same level. maybe green overrides blue too quickly by accident, I don’t know.
-
If I stop the MQTT server, the NeoPixel blinks red. Good. However, if I restart the MQTT server, OMG does not always reconnect until I manually trigger a reboot by pressing the RST button. Odd.
-
OMG died randomly. This may or may not be related to your changes, I don’t know. The error message on the serial output was
[185110][E][WiFiClient.cpp:268] connect(): socket error on fd 49, errno: 113, "Software caused connection abort". OMG tried to reconnect, but it never came back, full log of the serial output at the end of this post. A manual reboot (RST button) brought it back to life.
Reconnecting to /dev/ttyACM3 Connected!
E (1402) wifi:sta is connecting, return error
[ 1395][E][WiFiSTA.cpp:317] begin(): connect failed! 0x3007
E (1443) wifi:Set status to INIT
[ 3908][E][Preferences.cpp:483] getString(): nvs_get_str len fail: BTConfig NOT_FOUND
[ 4996][E][esp32-hal-misc.c:128] disableCore0WDT(): Failed to remove Core 0 IDLE task from WDT
[185110][E][WiFiClient.cpp:268] connect(): socket error on fd 49, errno: 113, "Software caused connection abort"
E (207178) wifi:Association refused temporarily, comeback time 1024 mSec
E (208209) wifi:Set status to INIT
E (251264) wifi:Association refused temporarily, comeback time 1024 mSec
E (252296) wifi:Set status to INIT
E (263474) wifi:Association refused temporarily, comeback time 1024 mSec
E (264508) wifi:Set status to INIT
E (331435) wifi:Association refused temporarily, comeback time 1024 mSec
E (335449) wifi:Association refused temporarily, comeback time 1024 mSec
E (336479) wifi:Set status to INIT
P.S. Maybe instead of blinking blue upon receiving a message a brief “turning off the green” status would be more visible?
I observed the C3 board and an MQTT listener at the same time for a while. The blue flash is a hit and miss.
- Sometimes I can see it really clearly. That is often when there are multiple messages at the same time.
- Sometimes there is a message but no blue flash at all. That is often when it is a single message.
@argafal Thanks a lot for testing !!! The principle errors in your log are from “framework-arduinoespressif32”, i.e. very far down. I have no idea how to avoid them.
What I have done is writing some definitions in C/C++ code. They are not very elaborate and positioned in a header file. When OMG is up and wants to signal the work is done by two lines of functions: the color is xyz, show it. These functions just tell the LED library what OMG wants.
We both realized that the blue LED is only shortly seen or not at all. I think that the send / receive times are short and sometimes too short for us to perceive in between the green (human color vision). A blue island in the green ocean? Perhaps I should change colors.
I think that the errors which you reported are really decisive. Bit-banging an RGB LED adds another task which the framework may not reliably handle on ESP32C3 socs. Anyhow, I will start a long time test with my setup and see wether I get your errors. If yes, then it was a nice try. See you.
1 Like
@argafal As I am writing this, the ESP32-C3-DevKitC-02 got beyond 125000 uptime (>34h). The RGB led continues to show green with short intermittent blue send/receive flashes. There is no sign of reboot in the logs. The serial log shows just two errors within its first second of recording. They seem setup related and harmless. I really wonder about the difference in errors between your and my test. Of course we have different boards. But the ESP32C3 and build environments should be about the same. There may be a Good Witch around here.
My next steps are: testing visibility of color changes, need of serial output to be read and of course a long term run without serial grabbing. See you.
1 Like
I have changed colors for better visibility: gold (send/receive) on a dimmed blue background (info) suits me best.
With a short test program I found that the ESP32-C3-DevKitC-02 did not depend on reading serial output. It has a CP210x UART Bridge The Lolin and Seed ESP21C3 boards recently tested here do USB/serial conversion internal to the soc. That my explain the difference.
In my next long time test the DevKitC was just connected to power supply with serial logging intact. I stopped the board after >42h. There were two reboots, no crash. For me that is tolerable but open to improvement.
@1technophile @argafal: Now the DevKitC was connected to power supply, had logging disabled and was using the espressif32@6.1.0 platform. Uptime increased steadily beyond 43h, no reboots and alike. I am really satisfied.
You can find my changes in the wroom32c3 branch of my OMG fork at github. I wonder whether changes like that adapted for the “Bump ESP32 platform” would be acceptable for OMG.
I have also tested OMG’s esp32c3-dev-m1-ble environment (uses FastLED) again, but now using the espressif32@6.1.0 platform. I still get the “Guru Meditation Error: Core 0 panic’ed (Interrupt wdt timeout on CPU0)”, followed by core dump and reboot every 16 sec. So my verdict remains that OMG currently can not use FastLED for the Espressif ESP32-C3-DevKitC-02. See you.
@mrickma: I want am going to test your branch/new colours. I’m excited to see it! 
Two questions:
-
Which environment contains the correct definitions?
Found it:esp32c3-dev-c2-ble -
Is there still a parameter to dim the LED? You had it in the previous and I quite liked it. I cannot see it right now, but I might be lost in the many different environment definitions.
Time for testing it first
They are the esp32c3-dev-c2-ble and env:esp32c3-dev-c2-ble-no-serial environments. I have just fixed a naming bug in the latter. For simplicity:
[env:esp32c3-dev-c2-ble]
platform = espressif32@6.1.0 ; override
board = esp32-c3-devkitm-1
board_build.partitions = min_spiffs.csv
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ble}
${libraries.decoder}
adafruit/Adafruit NeoPixel@^1.11.0
build_flags =
${com-esp.build_flags}
'-DZgatewayBT="BT"'
'-DANEOPIX_IND_DATA_GPIO=8'
'-DANEOPIX_IND_NUM_LEDS=1'
; '-DANEOPIX_BRIGHTNESS=10' ; 0 - 255, default 20
'-DRGB_INDICATORS=2'
'-DNO_INT_TEMP_READING=true' ; No internal temperature reading on ESP32 C3 or S3
'-DTRIGGER_GPIO=7'
'-DGateway_Name="OpenMQTTGateway_ESP32C3_DKC02"'
custom_description = BLE gateway on Espressiv ESP32-C3-DevKitC-02
[env:esp32c3-dev-c2-ble-no-serial]
extends = env:esp32c3-dev-c2-ble
build_flags =
${env:esp32c3-dev-c2-ble.build_flags}
'-DLOG_LEVEL=LOG_LEVEL_SILENT'
'-DWM_DEBUG_LEVEL=0'
custom_description = BLE gateway on Espressiv ESP32-C3-DevKitC-02 without logging
Thank you for testing! See you.
@mrickma
First of all, I really like your branch. How neat to have the little LED working, makes me happy to see it blink. Nicely done!
Could you integrate the following changes in environment.ini? With them the NeoPixel on Lolin C3 mini works out of the box:
diff --git a/environments.ini b/environments.ini
index 74b2416..9979122 100644
--- a/environments.ini
+++ b/environments.ini
@@ -1582,16 +1582,15 @@ lib_deps =
${libraries.wifimanager32}
${libraries.ble}
${libraries.decoder}
+; 07 Mar 2023: usage FastLED results in nearly immediate reboots
+; therefore the Adafruit NeoPixel library is used for the RGB LED
+ adafruit/Adafruit NeoPixel@^1.11.0
build_flags =
${com-esp.build_flags}
'-DZgatewayBT="BT"'
-; FastLED must be disabled. FastLED is not compatible with this board at the current moment.
-; The LED pins must still be defined, to avoid an error loop on pin definitions.
-; These are dummy definitions and are not actually used. Any choice 2 - 10, 20, 21 should be fine.
-; See https://community.openmqttgateway.com/t/watchdog-kills-omg-on-esp32-c3-within-seconds/2192/15
- '-DLED_SEND_RECEIVE=10'
- '-DLED_INFO=6'
- '-DLED_ERROR=7'
+ '-DANEOPIX_IND_DATA_GPIO=7'
+ '-DANEOPIX_IND_NUM_LEDS=1'
+ ; '-DANEOPIX_BRIGHTNESS=10' ; 0 - 255, default 20
+ '-DRGB_INDICATORS=2' ; 2 = use Adafruit NeoPixel library
; The momentary switch on the board is connected to GPIO9
'-DTRIGGER_GPIO=9'
'-DNO_INT_TEMP_READING=true' ; No internal temperature on ESP32 C3 or S3
For the colours: I tried a few other combinations to satisfy my curiosity. I appreciate the effort you put into finding those two colours (blue and gold) to work together. It’s really not easy at all to find a good pair! 
Personally, however, I’m not a big fan of the blue as the base tone. To me the green said “success” so very clearly and felt easier to intuitively understand. I also find blue to be a bit intrusive. I tried the following: a dim green as the base to show that the device is active. And a brighter green flash when receiving/sending data. To me it looked quite convincing. But of course I can see how this is totally a matter of taste and how you might want to keep blue/gold!
One other small proposal: I noticed that the LED stays blue (green) while rebooting the device. I would have expected it to be red. So I added two lines to initialize the LED colour. Full diff below.
diff --git a/main/User_config.h b/main/User_config.h
index 8bdca76..3d8bc63 100644
--- a/main/User_config.h
+++ b/main/User_config.h
@@ -492,16 +492,17 @@ Adafruit_NeoPixel leds(ANEOPIX_IND_NUM_LEDS, ANEOPIX_IND_DATA_GPIO, ANEOPIX_LED_
// no ANEOPIX_CRITICAL_LED and FASTLED_IND_DATA_GPIO2 with Adafruit_NeoPixel
// preprocessor calculates color values
# define ANEOPIX_RED ((0x3F * ANEOPIX_BRIGHTNESS) >> 8) << 16 // dimmed /4
-# define ANEOPIX_GOLD (((0xFF * ANEOPIX_BRIGHTNESS) >> 8) << 16) | \
- (((0xD7 * ANEOPIX_BRIGHTNESS) >> 8) << 8)
-# define ANEOPIX_GREEN ((0xFF * ANEOPIX_BRIGHTNESS) >> 8) << 8
+# define ANEOPIX_GREEN ((0xFF * ANEOPIX_BRIGHTNESS) >> 8) << 8 // bright green = sending
+# define ANEOPIX_GREEN_DIM ((0x3F * ANEOPIX_BRIGHTNESS) >> 8) << 8 // dimmed /4
# define ANEOPIX_BLUE (0x3F * ANEOPIX_BRIGHTNESS) >> 8 // dimmed /4
# define ANEOPIX_BLACK 0
# define SetupIndicators() \
pinMode(RGB_LED_POWER, OUTPUT); \
digitalWrite(RGB_LED_POWER, HIGH); \
- leds.begin();
+ leds.begin(); \
+ leds.setPixelColor(ANEOPIX_ERROR_LED, ANEOPIX_RED); \
+ leds.show();
# define ErrorIndicatorON() \
leds.setPixelColor(ANEOPIX_ERROR_LED, ANEOPIX_RED); \
leds.show();
@@ -509,13 +510,13 @@ Adafruit_NeoPixel leds(ANEOPIX_IND_NUM_LEDS, ANEOPIX_IND_DATA_GPIO, ANEOPIX_LED_
leds.setPixelColor(ANEOPIX_ERROR_LED, ANEOPIX_BLACK); \
leds.show();
# define SendReceiveIndicatorON() \
- leds.setPixelColor(ANEOPIX_SEND_RECEIVCE_LED, ANEOPIX_GOLD); \
+ leds.setPixelColor(ANEOPIX_SEND_RECEIVCE_LED, ANEOPIX_GREEN); \
leds.show();
# define SendReceiveIndicatorOFF() \
leds.setPixelColor(ANEOPIX_SEND_RECEIVCE_LED, ANEOPIX_BLACK); \
leds.show();
# define InfoIndicatorON() \
- leds.setPixelColor(ANEOPIX_INFO_LED, ANEOPIX_BLUE); \
+ leds.setPixelColor(ANEOPIX_INFO_LED, ANEOPIX_GREEN_DIM); \
leds.show();
# define InfoIndicatorOFF() \
leds.setPixelColor(ANEOPIX_INFO_LED, ANEOPIX_BLACK); \
P.S. What does '-DRGB_INDICATORS=2' do, and why is it necessary to have?
In OMG DRGB_INDICATORS=true is used. In C/C++ definition “true” translates into “1”. So setting it to “n” offers other possibilities. “2” in this case means use adafruit/Adafruit NeoPixel library for the RGB LED. See you.
edit: C++ definitons: false = 0, true = 1
so your choice >1
Got it. That might deserve a comment in the environment defintions:
'-DRGB_INDICATORS=2' ; 2 = use Adafruit NeoPixel library
You are right. I have just added it. See you.
@argafal I apologize for being a bit slow. When committing your first diff I would like to write “authored by <your email>” in the message. May I take the address which I found at github for the original Lolin commit?
In your next diff you are going for the color of hope, whereas my colors were dominated by trust. Additionally there may be an official OMG color scheme which I have not found yet. I would like to make color schemes adjustable. Your green scheme may become default. For the blue scheme of trust one would have to use a -DANEOPIX_COLOR_SCHEME=1 directive during build.
Your addition to the “SetupIndicators()” is really sensible. I would like to see reboots too. Give me some time. See you.
@mrickma: Yes. You can use the one from my lolin_c3_mini pull request. They way I see it, you do not need to mention me: I copied & pasted those lines directly form you, so all credit should go your direction! Do as you see fit. For the colours, please choose as you like them best. You know, I’m just happy to see the little NeoPixel shine. Awesome addition to the project! I really like that you made that effort. See you.
@argafal: I had some time today. You find the result at GitHub. Please check the changes to your lolin_c3_mini_with_serial build environment. I had some difficulties applying the first of your patches from above. The gnu patch utility may have been overly picky.
In main/User_config.h you find a possible solution to accommodate both your green and my blue based color preferences. Your colors are default. To get the gold on blue choice specify -DANEOPIX_COLOR_SCHEME=1 for the build.
I think color during boot time should be well visible but not the same as for error. What do you think about hot pink? At least it sounds terrible enough for signaling reboots.
Please test my changes and suggest improvements. See you.
I love the aqua for booting. Nice pick, I want it too.
I also realized that the golden flash works well with either the blue or the green dim base colour.
That made me end up with the following diff. Only the base colour is different now. I added the option to the lolin_c3_mini environment, with a comment.
$ git diff
diff --git a/environments.ini b/environments.ini
index 7faf6c6..5a85c77 100644
--- a/environments.ini
+++ b/environments.ini
@@ -1593,6 +1593,7 @@ build_flags =
'-DANEOPIX_IND_DATA_GPIO=7'
'-DANEOPIX_IND_NUM_LEDS=1'
; '-DANEOPIX_BRIGHTNESS=10' ; 0 - 255, default 20
+ ; -DANEOPIX_COLOR_SCHEME=1 ; Alternative LED colour scheme: 1 = blue/gold. 0 = green/gold
'-DRGB_INDICATORS=2' ; 2 = use Adafruit NeoPixel library
; The momentary switch on the board is connected to GPIO9
'-DTRIGGER_GPIO=9'
diff --git a/main/User_config.h b/main/User_config.h
index 7461510..5738142 100644
--- a/main/User_config.h
+++ b/main/User_config.h
@@ -512,10 +512,10 @@ Adafruit_NeoPixel leds(ANEOPIX_IND_NUM_LEDS, ANEOPIX_IND_DATA_GPIO, ANEOPIX_LED_
// signalling color combinations tested for good visibility
# if ANEOPIX_COLOR_SCHEME == 0
# define ANEOPIX_ERROR ANEOPIX_RED_DIM
-# define ANEOPIX_SENDRECEIVE ANEOPIX_GREEN // bright green = sending
+# define ANEOPIX_SENDRECEIVE ANEOPIX_GOLD // bright gold = sending
# define ANEOPIX_INFO ANEOPIX_GREEN_DIM // dimmed green = info
# define ANEOPIX_OFF ANEOPIX_BLACK
-# define ANEOPIX_BOOT ANEOPIX_HOTPINK
+# define ANEOPIX_BOOT ANEOPIX_AQUA
# else
# define ANEOPIX_ERROR ANEOPIX_RED_DIM
# define ANEOPIX_SENDRECEIVE ANEOPIX_GOLD // bright gold = sending
My 2 cents: it is not worth maintaining two different colour schemes and an option for it. I am happy if blue/gold becomes the new default and the other option gets removed entirely.
@argafal I have applied your diffs and cleaned up afterwards. You find the code at the usual place. Please check. In my main/User_config.h there are 73 lines of code for Adafruit_NeoPixel and 74 lines for FastLED. I think that is tolerable and would vote for keeping the versatility of color schemes. At least we spent quite some time staring at our RGB LEDs wondering what OMG was doing.
How is your “Lolin C3 mini v2.1.0” doing in terms of errors and reboots? My “ESP32-C3-DevKitC-02” still runs very well with the adafruit/Adafruit NeoPixel library. So I would regard the problem solved.
If you agree I will open a new thread to ask 1technophile to review and integrate our stuff into OpenMQTTGateway code.
1 Like
The Lolin C3 mini works nicely. I have not encountered any problems so far. I agree that it would be nice to integrate your NeoPixel changes. Full support for a pull request.
Good job, @mrickma!