I've done it before. 
1 Like
Thanks. You are absolutely correct. Just try accidentally creating a UDP comms send loop during development and pressing execute. It absolutely freezes the browser user interface. Requires a manual reboot (plug/unplug). You learn quickly to NOT do that. (another good thing about Hubitat: What you do to Hubitat affect you but not others.)
Dave
Homeseer
2 Likes
I think you're missing the biggest part of it.
The discussion is:
Processing automation on hub and triggering actions
vs
Processing automation off hub, sending over lan and triggering actions.
While sending over lan shouldn't introduce much delay, it should still be slower than not sending anything over the lan. Simply because that extra step of sending over lan does add ms to the whole process. BUT the opposite is happening. It's faster. So why?
1 Like
Well, that's the thing. Since we're talking operations that takes hundreds of milliseconds the actual lan latency in this processing is basically within the margin of error. It doesn't really matter.
It's also not really an apples to apples benchmark. The difference may be due to the different code paths within Hubitat (like the event deduplication that the websocket API seems to bypass) just as well as differences in implementation between Hubitat and Node-RED. Just looking at this benchmark the interesting part is comparing the Maker API/websocket to the MQTT app for integrating Node-RED. If latency is important it seems like the Maker API (with or without websocket) is slightly faster. That's kinda cool to know. That, plus the fact that offloading processing to Node-RED doesn't introduce a whole lot of latency.
Response to post #67...
Yeah, got that from @JasonJoel and I took a look. Nothing there interests me as I don't even have any need for NR at this time, let alone a "pay for every update on top of initial cost" solution. But I understand that my needs/wants are quite small and simple compared to the large body of users in this forum. Still, good to know what's out there just for general principles.
Unforunately, for many who have switched to node red, we're not talking hundreds of milliseconds. We're talking full seconds and in some cases multiple seconds.
You've got some theories that you posted above, others have different theories. Unfortunately I don't think we'll ever fully know why. It's promising though that staff have identified areas of improvement that may be contributing to these slow downs so the gap may eventually get to the point where we truly are talking hundreds of milliseconds.
That's EXACTLY what I saw with my first try at NR a few months back. At that time I had to run NR in Docker. NR version 1.06.
With the NR update to version 1.1 last week I found I don't need Docker anymore and I got the numbers I posted to start this topic.
Yes, and that sucks. I'm not trying to downplay those issues. I'm just saying that the results of this specific benchmark shouldn't be interpreted as there's something "bad" or inefficient going on in Hubitat. But it also doesn't say that there isn't.
1 Like
How do you run node red if not in docker and what hardware?
The box is a Dell Precision T3600, quad core, hyperthreaded, 8GB RAM. I run Arch Linux on all my systems and, in addition to the officially supported package repositories, there is one that is user supported/maintained and that's where NR came from for my case. I believe you can install nativly on most machines but check here for your specifics Running Node-RED locally : Node-RED
1 Like
Correct, I've run it natively on an Intel NUC with Ubuntu, an Odroid XU4 with Ubuntu and an Odroid N2 with Armbian.
2 Likes
I'm new to Hubitat, moving off ST as we speak. I'm not a programmer but am considered fairly technical. While I am going through this migration I am looking at how best to architect the hardware and software for the future so I can minimize the pain of upgrades and potential future migrations. This thread has been an excellent read. Last month i made the jump with two C7's to divide the workload (and having played with Hubconnect am my ST hub) I will keep the ST for devices it is good with (Arlo, Nexx Garage). I am now thinking through how to implement a good local backup which leads me to a device thats on all the time (thinking RPI). and if I have the RPi perhaps I should be looking at node red as well, Which would further separate the workload to devices that are optimized for their task. I have about 150 devices Wifi, Zigbee, Zwave and getting into bluetooth that will be on the hubs.
This is a long way to get to my question. Is this creating a brittle solution that is a maintenance nightmare? Am I over engineering?
More moving parts always = more administration/maintenance long term. That's a simple fact.
HOW MUCH more depends on the system, and the skills of the admin. No one can really answer that for you.
got scolded 
1 Like
Please start a new topic as your question is not related to this one. Thanks.
Understood, Thought it was germain based on your July 5 comment. Please consider it a newbee mistake.
