Not sure if this is an issue inside
node-red-mcu, but anytime the generated node-red flows running on my ESP-32 hit an error, the whole unit restarts... and fails again.
In my particular flow, I just added a
node-red-node-serial-in node, which causes this stack trace in xsbug-log:
#xsbug-log connected to "main" Wi-Fi connected to "S&J-Poolhouse" IP address 192.168.1.107 # Break: importNow: module "events" not found! #0: importNow #1: require /home/srickus/develop/node-red-mcu-plugin/mcu_modules/require/require.js:5 #2: (anonymous-522) /home/srickus/.node-red/node_modules/node-red-node-serialport/25-serial.js:5 #3: forEach #4: RED.build /home/srickus/develop/node-red-mcu-plugin/node-red-mcu/nodered.js:156 #5: (anonymous-243) /home/srickus/.node-red/mcu-plugin-cache/sqd9j8rnmna/main.js:20 #6: (host) XS abort: unhandled exception
I know the support for the
node-red-node-serial collection is still wet behind the ears, so I'm not totally surprised it did not work out of the gate. Any idea when we can read/write serial data through the gpio Tx/Rx pins? The bigger question is whether this is the right node to use, I suppose. :*(
But this topic is more about error handling when something like this goes wrong on the MCU code -- right now my mcu is reconnecting to the wifi network like every 5 seconds! As soon as the connection is established, there is this unhandled expection -- perhaps the generated code should catch all of these and just stop? Or at least impose a logarithmically increasing delay before trying again.
Seems like the closer I get to getting my MCU device deployed, the more obscure the errors -- but this is all very exciting, especially for those of us who only get to write code in the "bits-n-bytes" world, not in the world of "events-n-atoms".