Node-RED nodes for hubitat

What do you mean by "recover"? Like continue mid flow in case the hub or NR restarts mid flow?

That's a complex subject.... Depends very much on what the flow NEEDS in order to recover!

One thing that can be done is an inject node into the trigger/device node to force it to update.

Here's an example of that I use on mode based lighting:

Another is to setup a filesystem context to store variables that persist node-red reboots.

1 Like

Is this the best way to reboot a hub from Node Red? I currently do it from Synology (curl), but want to bring it over to Node Red.

image

1 Like

Mine is a little different I do this url -
http://hubIP:8080/hub/reboot

Can't remember exactly why I do port 8080, I assume because that is a separate process that is independent of the main UI process. So if the main UI locks up, port 8080 often still works.

1 Like

Port 80 and port 8080 are the same process, I bet you did because you copied the url from an old RM rule and you needed to use port 8080 in RM as RM couldn’t talk to the hub via port 80. Just a hunch though

3 Likes

Really? I thought it was separate. Curses wrong again!!!! Corrected the previous post. Thanks!!!

Almost certainly correct!

1 Like

Port 8081 is a different process but 80 and 8080 are the same

2 Likes

Yup, I was mixing it all up. Must have been thinking of 8081.

2 Likes

Some cool stuff coming in the next version of the nodes! Looking at the outstanding issues/request list @fblackburn must be getting close to releasing it (:crossed_fingers:).

Hopefully he won't mind me talking about a few of the changes...

The #1 thing I'm excited about is the global cache. Instead of each device node keeping its own data cache and initializing independently, there is a global cache shared by all device nodes. This mainly benefits users that re-use a lot of the same device/attributes (like me). For those users overall memory usage and (arguably most importantly) initialization and update speed/hub loading during initialization goes down.

For instance, if you used the same deivce in 50 different places, it had to initialize those 50 nodes by making 50 calls to Maker API. Now it would do 1. (yes, there were already ways around that - link in/out, etc.... But that isn't obviously to most users)

Status text on command nodes is my 2nd favorite new feature.

So instead of just this (what does that command node do? Who knows? Have to open it up to find out I guess...):
image

You get this (ah, now I see what the command node does without opening it!). Note - to reduce confusion the "configured command action" status text is distinguished from a "current value" status text on a device node by the ">>" prefix and having no colored ring to indicate connection type:
image

As always all credit goes to Francois - for his time, skills, and hard work on these nodes!

12 Likes

Awesome news thanks for giving us a heads up!! Will we be able to store the global cache to a file storage context I wonder?

No, the cache is still in memory only. Not a lot of reason to make it persistent as it doesn't take THAT long to rebuild. Plus most would probably want the cache checked for changes on a reboot anyway.

Oh, thing #3 in new release is command node throttling. So if you have a flow that triggers say 10 command nodes all at once it with throttle them to prevent maker API from erroring out.

2 Likes

I think I’ve figured it out with Node-RED😳. Just need to test it a bit more and will post details (hopefully soon).

2 Likes

Anyone looking to use Node-RED to log into HE with security enabled, I have posted the detailed solution in this thread:

Using Node-RED to log into HE and download a backup

Hope this helps!

3 Likes

not at all, thank you to try to keep this thread on the track :laughing:

Since the community is very responsive and the global cache is a major refactor, I want to wait until I have some free time (2-3 hours in a row) to fix potential issue, before releasing new version (by the next week)

Warning: the global cache is only for DEVICE node, not MODE/HSM nodes. If you want the same logic for MODE/HSM, then open an issue. Since I don't use these nodes I cannot know if it would be useful or not :man_shrugging:


There are other small changes, you can look at the 1.3.0 CHANGELOG (still not released)

6 Likes

LOL. I picked the one example that did NOT apply. And I knew it was the device node only - I just wasn't thinking. Sorry about any confusion there. I edited my original post to fix it.

Good question for others to comment on as well.

I use 26 mode nodes right now (only because I haven't gone back and changed it to a single node plus link in/out like I have in other places I had redundancy).

I was using 26 mode nodes, but I just changed it to 1 + link in/out nodes / global variable.

No idea if 26 is a lot more/less than anyone else though.

1 Like

I'm sure I have a high count of mode nodes as well. It would be a good add.

can you explain this to a newbie node red user

You can use the "Link In/Out" nodes to "connect" nodes across different flows (tabs on the UI) - something like this:

See the dashed line? That's a "wire" running from a "Link Out" node (attached to the inject node) to the "Link In" nodes which are connected to the debug nodes. These "Link In" nodes and the nodes that follow can be placed ANYWHERE on any tab in the UI and will route messages from the "Link Out" node... creating one large extended sequence. Very handy if you want to limit a resource intensive node or share some common events between sequences.

For the mode node you'd have one sequence containing the node and the output would be connected to a "Link In" node. You would then create as many "Link Out" nodes as needed to handle your mode stuff instead of using a Mode node for each.

Hope this helps clarify things :grimacing:

4 Likes

  • I use global.mode variable for mode checking inside of other flows (see "mode" switch nodes in picture below).
  • I use the mode node + link out to trigger other flows on mode change.
  • I use the inject node 10s after startup + mode node + link out node to trigger mode event at startup (to ensure logic is in correct state).

Link in to a random delay to the rest of ther flow to set behavior based on mode.

mode switch node:

3 Likes

It does indeed thanks!

3 Likes