Did you check out the PMs both @aaiyar and I sent you? 
He suggested using armbian and I recommended installing using the RPi install script from Node-RED.
The links are in the messages. Happy to help further if you PM me.. 
1 Like
Thanks for that.
My deal is that I am away from my home due to covid. I live outside the US and can't return home. Been stuck in CA since Feb now, with no end in sight. So all I can do right now is educate myself, take notes, and wait until I can return to pull the trigger.
I did just buy the C-7 to take back home. Then the migration bit from my C-4. Afterwhich I will start the XU4/node red project.
But for now, I am tying to get my head around node red vrs RM.
1 Like
Yeah that situation sucks - sorry to hear.. do you have access to your network at home?
The best way to check out NR is to actually run it and play around with the UI etc.
Here is a link to installing it on Windows..
1 Like
Thanks, maybe I'll try that.
2 Likes
Speaking of Node-RED installs, does anyone here that uses a RPi use DietPi or are most just using Raspbian Lite?
I use raspbian lite for my rpis. But that said I run all my node-red instances in docker, lxc containers, or VMs.
2 Likes
I am using ubuntu server right now but have also used raspbian lite... both have worked well.
I've posted this elsewhere and it's also posted in an earlier part of this massive thread but if not going the docker route the install script provided by Node-RED works great.
1 Like
I run Node Red in a jail on a Truenas server. I haven't measured the response time, but it is just as fast if not faster than RM from the point of view of a user experience.
2 Likes
While I've found the combination of HE + NR to be very compelling it's not for everyone. RM and the lighter weight apps are great for most people who just want things to work out of the box.
With the introduction of more and more useful HE apps from both the staff and community devs the functional "need" for external systems is reduced. However resource utilization will always be an issue given the HW constraints. One way to mitigate this is by adding yet another HE with the radios off using it exclusively for apps / virtual devices. Another is by connecting a platform agnostic system like NR - externally separating the logic from the device management in a user controlled opensource platform.
Either strategy has advantages/disadvantages and are not mutually exclusive - I generally favor the NR approach as it seems to be the most flexible for my use-case. Having said that certain HE apps like the Alexa Skill are very useful and so am in the process of enlisting an old C-4 with no usb stick to handle all cloud and networking apps. I like being able to isolate that stuff from the rest of my setup.
2 Likes
Everyone's use case is different. 
For me the #1 reason I will be sticking with external logic processing is code portability. In the long run, 99% of my time is spent on my logic, and I do not like the idea that if my hub dies or if I decide to change to HA/z2m/new hub du jour I lose all of my investment in my logic.
Keeping it in node-red makes it portable between hubs. I've switched from hubitat to HA to z2m and back to Hubitat again since moving my logic to node-red. And each time within 1-2 hours I had 100% of my logic working again, and working EXACTLY like it did on the previous hub.
To me, that equals sweat equity protection and freedom from being locked in to the radio hub I chose to use. Can't do that with built in apps or RM.
The second reason I like it is that with node-red I get to chose the hardware it runs on. I want more capacity/faster processing? I upgrade my hardware. I want fault tolerance? I can run it in a docker swarm or high availability VM. Etc.
In fact, this weekend I moved my 3 node-red instances from my low powered docker swarm to my high powered ProxMox cluster. Only took a few minutes and I lost nothing in the process. Can't do that with built in apps or RM.
10 Likes
Yes I agree completely!!! Well said!! Freedom to choose and the flexibility to change.
+1
1 Like
Since I feel like I reread the same question/answer every month (about pros/cons NR vs RM), I linked your answers in the first post. I'm too lazy bad to explain a detailed comparison, but maybe pinning your answers can help others
5 Likes
Thanks Francois! And Happy Holidays to you - I hope you have been getting some relaxing time off in the tundra. 
3 Likes
Now we just got to get folks to read the first post
Just kidding! Season’s greetings, and thanks so much for developing this integration!
5 Likes
Happy new year! This group has made my Hubitat journey so much easier and for that, a big "THANK YOU".
Quick question - I'm trying to get the "illuminance" attribute from an Aeotec Multisensor 6 at a particular time (using an Inject Node) but I can't seem to get this to work. In fact, I can't "read" any attributes on demand (I tried with attribute set to "all"). The "Device" node will publish changes as and when attributes change. Is there anything that I am missing? Thanks for your help.
1 Like
You can't force read attributes. The device node only returns whatever data was sent to it from the hub - it doesn't go manually fetch/request it from the end device.
If sending a REFRESH command to the device causes it to re-send the value you need, then you could try that. But that would be device specific on what it does when sent a REFRESH command. Also note that for battery operated devices sending too many REFRESH commands could impact battery life.
2 Likes
Then you are out of luck. I hate the Aeotec Multisensor 6 - they never worked the way I wanted/needed (have 4 of them in my junk drawer).
Luckily my Weatherflow weather station sends outside illuminance (the only illuminance I need) every minute.
4 Likes
This seems strange but the device node is not publishing motion events either. I know it is registering motion (I can see it light up). Also, I have another MakerAPI instance that is publishing the event to the "event" node and logging it to a database. Any ideas?
I would test that Maker API instance more... For incoming data the node-red integration literally just listens for the POST events from the hub and logs the events.
So a few thoughts - either the device isn't actually making an EVENT (can check the device details event log - not the hub log. Just because something shows up in the hub log doesn't mean it actually made an EVENT) or the POST events aren't making it to the node-red instance or you have both Maker API instances sending to the same POST endpoint on the node-red instance (which will do weird things).
Or something else, but there just aren't that many 'moving pieces' in this integration.
