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 (
).
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...):
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:
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 
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 
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 
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
The worst part about moving all my RM rules to Node-Red is I don't know if the Hubitat updates are slowing my device down anymore.
1 Like
But why does it matter? If your node-red logic is performing, the rest isn't your problem.
They could make RM twice as fast as node-red and I still would not switch back at this point. I really like the layout, multi platform support, and flexibility of node-red flows.
I also like how node-red protects my intellectual property and hard work in the long term by remaining home automation hub agnostic. I've remade all my rules at least 10 times across 6-7 different hubs/systems.... No more!
9 Likes
this +1
3 Likes
This and the fact that my pi setup has been the most solid piece of my HA setup. I mean it just works. Always lol. My hub died last year and I did not manage to get a new one setup for a few months. The pi just sat there and waited. No reboot or reinstall. Just got the new hub setup. Changed some ips and my flows from a year before kicked right into action.
When I first started using it with HE not many at all were into it. Now that these awesome hubitat nodes are there it is that much easier.
2 Likes
New version 1.3.0 
changes
-
command: add status text about the current command/arguments configuration
-
device: use global cache shared by all device nodes and only initialize it once by device ID -
command: throttling requests to prevent errors from Maker API -
command: updatesetLeveltemplate to add an example with new syntax:{"hex":"15fe21"} - fix websocket error status on partial deployment
Special thank you to @JasonJoel for testing and idea to improve nodes
12 Likes
Beautiful work guys.
Thank you!
1 Like
Agreed, it doesn't matter, but it sucks that even with all of them disabled, my hub is still visibly slow with the latest update. I'll not go back either - it's so nice to have my goodnight routine to actually turn everything off quickly. Guess I get to go back to 2.2.2.129 
1 Like
