After doing a bunch of sequences I started to notice that some of them look kinda cool. I thought maybe I should start a thread on the "art" of these things..
Feel free to post your coolest looking working sequence.. though the point is not really function but form!
I don't know anything about using Node-RED, but most of those diagrams look elegant. A lot of examples on this board remind me of someone dropping a plate of spaghetti. Make my old (simple) brain hurt.
Ha! yeah before I started with it looked exactly like that to me too. Once I got into it the visualizations became less bizarre and more understandable. NR is really very simple at it's core. You can just do a lot of very powerful things with it. If you want something to tinker around with I highly recommend. Really adds to the HE experience.
Do you use this instead of Rule Machine? Or in addition to it? I’ve been looking for something which is capable of building automations without 480 taps on my phone for an if statement...and I’m also looking for something which can build reusable functions.
I’ve been toying with the idea of just using the maker api directly but haven’t looked into it too deeply yet. As a software person I just... Want to write code for these automations.
Yes as a matter of fact I just converted most of my rules over from all of my hubs. I recommend you give it a whirl if feasible. The visual dev aspect is fantastic. It's very easy to copy/change etc. They have things like subflows for certain kinds of reuse and "function nodes" which are custom javascript code blocks etc.
Happen to know which variant of JavaScript it is? There are certain dialects of node I’ll go pretty far out of my way to avoid.
What’s the response time using a system like this? For the options where you have it responding to a button press is it noticeable that hubitat is going out to another device on the network?
It adds a couple hundred milliseconds max, depending on how busy Hubitat is and what kind of hardware you run Node-RED on, When I was doing my benchmarking it was usually ~120ms, but I run my node-red docker container on server grade hardware so it's pretty zippy.
Typically not noticeable, but could be in some scenarios if you have a ton of back/forth in your logic I guess.
To add to @JasonJoel's response, my Hubitat logs indicate no discernible difference in motion lighting that done within NR vs motion lighting done using Hubitat (~275 ms vs ~300 ms for the time between motion detected and light turning on).
All of my interior motion lighting switches/dimmers are Lutron Caseta. If I use HE-paired motion detectors, and directly connect the Caseta Pro bridge to node-red, then my motion lighting is actually faster with node-red than with Hubitat alone (~150 ms vs ~275 ms).
My comment was mainly around the time it takes to get the value to/from hubitat. If the logic itself runs faster in node-red (which it often can depending on what hardware you are running node-red on), then you can actually see FASTER closed loop response times than using RM or Motion Lighting - even though it has to go 'off node'.
TLDR; The solution adds a little more latency getting values to/from the hub, but typically has faster logic execution. So net result = .
As others have said there may be a lag but not noticeable and depending upon the available resources of your server (I'm running it on a vm) it may offset any disparity. For me it is more than a worthwhile tradeoff for the flexibility/control/ease of use I get..
Node-RED runs on Node so the version of Javascript will totally depend on what version is included with your installation.