Oh ..."all when Hubitat stayed online" it is not normal, do you have any log in Node-RED? If initialization fail, you should have a bunch (one for each node) of log that explain the reason.
Click on the arrow beside the deploy button
Yep both, Node-RED and Hubitat logs should be useful 
The "unavailable" node after a reboot is definitely going to be an issue long term., I've only seen it a few times, but for the integration to be relied upon it needs to gracefully handle reboot. Whether that means that there needs to be throttling on the large # of messages on restart/re-connection or automatic retries on unavailable nodes, I don't know...
I'll try to be more diligent in getting some logs next time I see it happen. Step 1 is I need to figure out how to view the node-red logs in my docker instance. lol.
Me too.
I too have seen this several times. Something that works for me is to have inject nodes on each flow recover device status about 10-20 seconds after startup. If I try it sooner (eg. 0.1 second), I get error messages.
This almost sounds like that it has nothing to do with load but with execution time / conditions at startup...
EdIt: and just a reference, with the Homebridge plugin, I really “hammer” MakerAPI on boot, depending how many devices are shared and I haven’t seen a behavior like this
I did a reboot of Node-Red and left Hubitat online. Here is a screenshot of a flow sequence after teh reboot. The two device nodes shown are "uninitialized," as are all other device nodes in all other flows.
I see no entries in the Hubitat logs but do see the below when I inject a message into the flow pictured above.
10 Mar 20:01:29 - [error] [hubitat device:Kitchen Pico Remote] TypeError: Cannot read property 'forEach' of undefined
Doing a manual restart of the flows does bring all devices back online. This seems like an undesirable solution long term, but it works for now.
Thanks for everyone's help on this.
Yeah I agree. I will probably try the retries on unavailable nodes approach
For docker, the log is redirected to the output: docker logs <image_name>
Your issue is not related to the Uninitialized problem. When you start Node-RED, the device nodes are just not initialized and you need to wait before. The solution proposed for the other issue can also solve your case (because it will add synchronization between input and initialization)... BUT is only a side effect 
IMO it's a load issue .. I can easily reproduce it if I restart a flow with 50 device nodes. I have often 1-2 nodes uninitialized because HE return 500
My guess is that if all requests was delay with 10-20 ms each, then there will be no error
This error is not obvious, but it's because hubitat doesn't return the device and the code just crash. It is the exact confirmation that I wanted, thank you
Also, I've fixed this error handler issue in the next version
Hot damn - that's fast!!
Got it working with Cast Node and it seems much faster than the Chromecast Integration. It is MUCH faster than my Echos but I have Echo Speaks installed on my ST hub. The only issue is that it is not using the same voice. My Mini uses a male voice but it's a woman when using Cast Node.
Oh, and one more BIG issue. I have used the node 5-6 times and literally EVERYTIME I have inserted one, I have forgotten to enter the IP address, deployed, and then got pissed that it didn't work. I have now implemented @stephack's idea and have the Cast Node ready to go with IP address already entered on a Template Flow tab.
I hope there is no misunderstanding, I only fix the error handling to throw the real error ... I don't fix initialization issue 
Is there a way to utilize the status of the Hubitat Safety Monitor like with Mode Node? I can get around it with virtual switches but I searched this thread and there is no mention of it.
That's my belief/guess too.
I got jinxed! I had never seen the forEach error mentioned above until just a minute ago 
(Fan = the dry contact of a Zooz double switch)
You can make an HttpRequest to do so
So:
http://hubitat_ip/apps/api/maker_api_app_id/hsm?access_token=token
There is nothing currently in his palette for HSM, but with just a few simple built in NR nodes you can both get a list of available HSM modes or even set the mode via a call to Hubitat Maker API. (Note: you can also set the mode)
Related to the above, here is a simple example to change the node. Just build the parts of the Hubitat Maker API url and set it with the "httprequest" node
It would be awesome if you could share this sequence - thanks so much!
FWIW, I can read/change the Mode very easily using URLs structured as described by @morningz. However, I'm unable to change the HSM mode using similar URLs.
Here is the Flow I put together last night and this morning for my own Mode Manager. I'm finding NR so much faster than HE rules/apps
To help with the HSM monitor I installed the app and took a crack at it, but i don't see any reason why your URL you posted on the new thread wouldn't work.
Good luck doing this in Rule Machine ™ lol
As I sit here in my office, i have a Samsung button right here for quick control. There is a Zooz double switch on the wall that controls the ceiling light and fan. There is a lamp with a Hue bulb in the corner of office and a Hue Play behind my monitors. An Ecobee sensor rounds out the device list.
That big nasty function looks worse than it actually is, which is quite simple on the inside with just a single switch statement driving all the combinations (41 lines total)
Absolutely loving NR, I ultimately need to decide whether or not to continue running it on the Pi Zero it is currently running on or moving my flows to a Docker instance on an always-running Mac Mini I have here in the house.
I did learn the hard way last night on making a flow that completely breaks NR. I had to go onto the Pi via Cyberduck and manually edit the flow.json file to remove the offensive flow. To note: don't create an Http Listener node and automatically inject (and oops: repeat) on it
"Process Action" node:
Download the Hubitat app
