I thought I had better try it with the simulator first, without the contrib node, and I can't get that to go. I set it to Simulator, Node MCU and when I build I get
Starting build process...
Host system check: #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023
MCU Build system check: p1.1.2-post + #14cd68e @ m3.7.0-0-g74aa31c
HOME directory check: /home/colinl
Creating build environment for platform sim/nodemcu.
Working directory: /home/colinl/.node-red/mcu-plugin-cache/xbu2qex629n
> cd /home/colinl/.node-red/mcu-plugin-cache/xbu2qex629n
Creating build script file...
> /bin/bash ./build.sh
# nodered2mcu flows
# xsc main.xsb
# mcrez resources
# xsc flows.xsb
# xsl modules
Total resource size: 4760 bytes
# cc mc.resources.c
### 2262 instances, 2341 keys, 109 colors, 0 holes
### warning: wifi: default() timer: no const
### warning: wifi: default() state_next: no const
### warning: wifi: default() state: no const
### warning: wifi: default.get mode() mode: no const
### warning: wifi: default.scan() scanning: no const
### warning: nodered: Node.prototype.send() RED.#compatibility: not frozen
### warning: nodered: Node.prototype.send() RED.#compatibility[0]() DelayNode() maxKeptMsgsCount() _maxKeptMsgsCount: no const
### warning: nodered: Node.prototype.send() RED.build() msgQueue: no const
### warning: nodered: Node.prototype.send() RED.build() compatibilityClasses: no const
### warning: mustache: default: not frozen
### warning: mustache: default.tags: not frozen
### warning: mustache: default.clearCache() defaultWriter: not frozen
### warning: mustache: default.clearCache() defaultWriter.templateCache: not frozen
### warning: mustache: default.clearCache() defaultWriter.templateCache._cache: not frozen
### warning: WebSocket: default() URLParts() urlRegExp: no const
### warning: WebSocket: default() URLParts() authorityRegExp: no const
### warning: embedded:network/http/server/options/serversendevents: default: not frozen
### warning: embedded:network/http/server/options/webpage: default: not frozen
### warning: embedded:network/http/server/options/websocket: default: not frozen
### warning: httpserver: default.add() server: no const
### warning: securesocket: default() Session() cacheManager: not frozen
### warning: fetch: fetch() Client() clients: no const
# cc mc.xs.c
# ld mc.so
Then it brings up the mcsim window with a picture of a node MCU, but then a "Mcsim is not responding" popup appears with Force Quit and Wait. If I wait then it just reappears a few seconds later, and the simple flow is not running.
If I add the contrib node and build it shows a similar output and the mcsim window appears, but this time it doesn't say not responding. The flows still aren't running though. I don't get the missing module error though.
On the null message sending, it isn't unusual to send a null message, which in the normal node-red does nothing. That particular bit of code is pretty silly though. Quite what I was thinking when I wrote that I don't know.
I am not too worried about the simulator not running at the moment.
Sorry, I had no intension to blame you for anything - but report my observations. The runtime needs a bit of additional polishing to handle as well those cases with ease.
I can confirm that there's something strange w/ the sim; I keep you posted...
I have tried to investigate the build problem with esp8266, but I don't know enough about the tools to work out what is going on. I installed the esp32 toolset and it does build ok for esp32, but not for esp8266 (hardware rather than sim, the sim does build).
So I am stuck for the moment, sadly.
[Edit] I tried a couple of other contrib nodes and I get the same error with them, so it seems that for some reason I can't build contrib nodes for esp8266.
I'm not sure, what @Colin did - but take it, create a flow, build & see what happens.
Despite the strange effects when building for ESP8266 Colins node worked without modification...
Well the good news is that it now builds ok, and the inject nodes work ok
Unfortunately if I have any contrib node (well, I have tried three) then after flashing, the target immediately crashes.
According to my experience: No. [Edit:] ... for runtime memory; Yes if the flow build doesn't fit into the flash memory - which I've never seen so far with standard builds.
Welcome to the world of XS : You may define the "Creation Params" to change the (runtime) memory layout of your device. Here's a starting point in the documentation...
A bit more information. If I don't enter a wifi SSID then I can add my contrib node and it runs correctly. I have put breakpoints on the RED.nodes.createNode() line in my node and also in the trigger node (from the mcu folder) and on startup it hits the trigger node and then my node and all is well. In the xsbug log it says No Wi-Fi SSID. If I provide the ssid and pwd then in xsbug it says wifi connected and gives the ip address and then crashes before it gets to the createNode breakpoints.
Without the contrib node wifi (and MQTT if I add a node) works ok.
Does that give you any ideas where the problem might be? If not can you tell me where I might put some breakpoints to try and work out where it is going wrong?
xsbug provides a setting to Break on Start.
That gives you the earliest option to stop the flow and walk with the debugger through the generated code.
If it crashed before, it's an issue in the host code & thus a case for the Moddable team.
It seems to be some sort of timing issue. If I put a breakpoint here
in node-red-mcu/setupwifi.js, then it hits it on startup and when I tell it to continue it runs ok, but if I don't have a breakpoint somewhere in that area then it crashes. I am trying to tie it down further.
: You may define the "Creation Params" to change the (runtime) memory layout of your device. Here's a 
