B4R Question ESP32 WebSocket against nodeJS


Active Member
Licensed User
Longtime User
I I'm trying to connect an ESP with rWEbSocketClient (1.20), to an external nodeJS server. I am using WS NPM (https://www.npmjs.com/package/ws), but I'm willing to use any NPM that would work with webSockets (no MQTT!).

When I check the ESP output, if the nodeJS server is down, it fails correctly, but if I start my server, el ESP crashes and reboot.

Using ExpressIf ESP32 1.0.2 & ESP8266 2.5.2 on the Arduino IDE, and enabled #define DEBUGGING

WIFI CONNECTED <--ESP has connected to the Wifi AP
CNX OK <!-- Connection OK, so proceed to connect to WebSocketServer

Client connected
Sending websocket upgrade headers
Analyzing response headers
Websocket established
Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x40084e50  PS      : 0x00060630  A0      : 0x8008505a  A1      : 0x3ffb3ed0 
A2      : 0x3ffb32d0  A3      : 0x00060623  A4      : 0x00060620  A5      : 0x00000001 
A6      : 0x00060223  A7      : 0x00000000  A8      : 0xa5a5a5a5  A9      : 0x8015d410 
A10     : 0x00000003  A11     : 0x00060623  A12     : 0x00060620  A13     : 0x00000001 
A14     : 0x00060423  A15     : 0x00000000  SAR     : 0x00000019  EXCCAUSE: 0x0000001c 
EXCVADDR: 0xa5a5a5c1  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff 
Backtrace: 0x40084e50:0x3ffb3ed0 0x40085057:0x3ffb3ef0 0x40086639:0x3ffb3f10 0x4000bec7:0x3ffb3f30 0x4011191b:0x3ffb3f50 0x4011197b:0x3ffb3f70 0x401119c3:0x3ffb3f90 0x4011828a:0x3ffb3fb0 0x4011844c:0x3ffb3fd0 0x401102fc:0x3ffb3ff0 0x40088b69:0x3ffb4020
ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
mode:DIO, clock div:1
entry 0x400806a8

Is there any updated library that would work with any standard WS server? or at least how to debug this "meditation errors"



Active Member
Licensed User
Longtime User
Because the client has its own infrastructure and backend already mounted. Although on my thoughts it could be a middleware between the actual nodeJS and the ESP32, but the client does not want this solution, they want something more clean based in what they have actually (that does work)

They have chosen ESP32, because it very difficult to corrupt, not the case with their actual hardware on RPI, which the SD is very volatile, although we have managed to lower the risk by putting the whole SD as read-only, except for a couple of dirs mounted on RAM. This works well, but the mess comes up when there is a shutdown, then power comes back, and when the RPI is at boot stage, if there is another power loss, the SD has a very high change of getting corrupted.

We also looked at Android Things, which has a very reliable SD protection system, but Android is becoming very unstable, they restricted for 100 devices, maintain only legacy support, etc. Client stations are located in the middle of the mountains range in Chile, so changing the OS for 180 units up in the mountains it´s not an easy task.

So we come down that every solution has it downside, and that’s why we were looking on the file system robustness of the ESP
Upvote 0