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)
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.
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.
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!
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.
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
Holy hell!!! I updated and watched in the logs how quick devices initialized on a restart. It usually takes 30-40+ seconds and took less than 10. WOW!! Great update!
Obviously with so much having changed 'under the hood' everyone should be especially vigilant in looking for issues like initialization problems, device nodes not updating as expected, or command nodes not working as expected.
That said, it has been working very well for me, so I hope others have the same experience!
I just realized that I now have to go thru all of my command nodes and remove the redundancy of the command in the name of node and in status below node. OCD people don't look!!!!!!!!
Question: Is there anyway to set a timeout for "http request" GET?
Seems when it can't connect it takes upwards to a minute before it finally times out.
this +1
