Maybe I am missing something but I stopped using HSM and instead am using a combination of MQTT and Global (file context) variables in NR.
1 Like
I don't use HSM any more either - I do that functionality in Node-RED.
I do still set the mode on the Hubitat hub, though. Why? Not sure really as I don't use the mode in Hubitat at all, just use it in node-red. So there is really no reason for me to use the Hubitat mode, versus a node-red/mqtt variable.
Old habits die hard I guess.
3 Likes
Yep do exactly the same... also because we can. 
3 Likes
I was just struggling to think of what benefits there are to setting HSM when all logic could be based with modes...
Motion flow evolution
this is obvious simple
but turn off instantly after motion stops
The next step
this keep lights in if any new motion occurs
now my question is, how to keep lights on if motion stays active more then reset time without a blink?
Most of us use a stoptimer (preferably the stoptimer varidelay, as it is the best one) for this.
Example:
If motion=active, stop the OFF timer and turn ON the light.
If motion=inactive, start the OFF timer.
For the part on the right, some people check the current on/off status before sending the command, and some just send the on/off command regardless. Your choice.
On newer flows I don't usually check any more, but I do put in a rate limiter set to something like 1 msg/s to prevent unintended high frequency commands being sent to the hub (which has happened to me a few times in really weird circumstances, so now I prevent that).
Something more like:
And then other times I like to use two switch nodes instead of one to make the layout prettier. No functional difference, though:
Or, if you are a 'node conservationist' you could also use just one command node by setting the msg.command somewhere:
The 3 pictures immediately above all do the exact same thing.
And if you do a lot of motion lighting, you could wrap the whole middle part of the last picture into a subflow.
Which ends up looking nice and tidy like this:
With a subflow of something like this (OFF TIMER time set by an environment variable called "time_delay") that you can re-use anywhere you need motion lighting:
8 Likes
+1 ..
.. Completely agree!!!
This is a great example of the power and simplicity of NR with some nice "code" (partial-sequence) reuse thrown in.
Very cool thanks for posting this...
1 Like
Subflows are under used by many newcomers, but are really useful and powerful.
Yes, you can just copy/paste the nodes over and over, and that works fine. At least until you want to edit the logic on all flows.... 
- this.
With the discovery of "environment variables" (subflow "properties") my subflow usage really took off...
Very easy way to create node-like constructs that act like nodes without writing actual nodes. 
A great way to standardize behavior across your entire set of flows.
is there way to do this without outside components?
Just with build-in nodes.
I'm experimenting quite a lot, so I also restoring system a plenty.
With outside components you have to reinstall all contrib nodes and its just difficult to remember after 4 weeks not looking at it, what needs to be reinstalled or what timer i used (because there is a million of them).
In the node-red directory "$HOME/.node-red/" the "package.json" file contains all the components you installed. You can bring this over when you want to transfer things. Just do an "npm install" in the directory afterwards.
No need to forego using community nodes.
https://nodered.org/docs/user-guide/runtime/adding-nodes#the-packagejson-file
Not really, no.
- Technically you could by manually handling all Hubitat events via the POST updates, and commands back to the hub with manually crafted HTTP messages, and replace "stoptimer varidelay" with the in-box "delay" node (would have to redo all of the stop/reset logic too - many "reset" and "delay" nodes needed for the same functionality stoptimer does).
- I'm not making any examples for that though, as it would be a pain in the arse for no good reason. And it wouldn't be a topic for this thread anyway, as this is all about using the Hubitat node set for Node-RED... Not general Node-RED + Maker API support.
Here is another funny example. I originally did my mode lighting without subflows. And just copied/pasted a lot of ondes until I decided how I want it to work long term.
Now I'm going back and rectifying that.
These two flows do the exact same thing. Obvious which one is easier to follow, and understand long term. (two outputs from the subflow to handle cases where I use the component version of my motion dimmer driver, and thus the output goes to two different devices in Hubitat - but when it doesn't I just pump both outputs to a single device as shown).
1 Like
What no "status" output on the subflow???? Inconceivable!
1 Like
Not on that one, no. 
EDIT: The good part, though, is if I change my mind later there is only one place to add it.
I was fortunate enough to became aware of subflows very early on in my NR journey, and I pretty much decided from the get-go that I would use a subflow for my motion lighting. Now, after several iterations and almost total rewrites of that subflow, I'm very glad that I made that decision early on. I've been adding a lot of features and configurable options to my motion subflow over the past few weeks. It's now getting close to something like the Motion Lighting app in Hubitat, except all I have to do is drag and drop a few nodes and wires. It's so easy now to set up a new motion lighting automation
2 Likes
Oh, goodie, I get to redo mine. 
Nice job 
In this case is my node red is running in docker on NAS synology and i don't have admin permissions.
So easiest for me is just restore backup with fresh clean install and import saved node flow.
1 Like
I've been using subflows where I can. I recently created a subflow with a single node ( 
) to avoid typing in the Pushover credentials in multiple flows.
I got a little confused with subflow properties. I was able to define them and use them in the subflow but then wasn't sure how to pass the properties into the subflow without hard coding them. I set them at the flow level and then tried to use a change node but that did not work 
Yeah the limitation is they have to be static I think. I did see "buffer" in the variable type selection so maybe that's a way. Otherwise adding a property to the message object or global variables would work... I would probably add a property to the message object - it's cleaner.
1 Like
