Okay so I have a crazy request... apologies but thought I'd toss it out there anyway.
In working with multiple hubs and trying to create generic subflows I've run into some difficulties with having to hard code a bunch of things. Wonder if it would be possible to do something like the following:
Create a unique "configId" for each Hub config. (there might already be one did not check)
Have a msg.configId you could pass to the HE command/device node that would select the proper config to use. Another possibility would be to enhance msg.deviceId to optionally include the configId with the deviceId something like this format:
"[configId]/[deviceId]".
For events node, allow for multiple hub selections or have a separate "configIds" field that allows a comma separated list of configId's. The event node would then respond with events from those selected configs and also return a msg.configId for each generated event message.
It's really not a big deal as I've already created some base hard-coded subflows: "HubGrpEvents", "HubGrpRequest" and "HubGrpCommand" that handle grouping of hubs and hub events.. but it might be nice for longer term maintenance/subflow flexibility.
It's already there. And the other requests are covered as a result of it. When you edit either a command or device node you can create multiples on the Server field.
That's cool.. how do I do that? Do you mean from the drop down selection?
What I'm looking for is a way to set the hub config for a command or device node via a message property if possible. Kind of like you can do with deviceId as part of the msg inputs.
Yep. In that selection you'll see all the configs you have created and "Add new hubitat config..." which brings up the same config "dialog" you used to create the others. There is probably some limit on how many you can create but I don't know what it is and I'll bet that it's far more than you'll ever need.
EDIT: I have just one HE but I have 2 configs, one for websocket and one for webhook.
My purpose in all this is to create device groups in Node-RED similar to HE. For one hub it's fine but if you want to include devices from multiple hubs then it gets tricky.
I actually have this working now but my "base" subflows require me to "hard code" various command, device and request nodes with all the hubs. Would be nice to be able to do it programmatically or via message passing.
I am running Node-Red on a windows laptop. It just hums away in the background on an old laptop running Windows 10 I used mostly for Auto diagnostics/tuning but upgraded. I've run it on a pi then repurposed it, so copied my flows over and have it running 24/7. The biggest downfall so far is the auto update in windows I forgot disable. I did prefer it on the pi as it always just ran, no update hiccups.
Honestly, I like the idea as user, but a little less as developer of it
As I said, I don't have the setup or utility to use it, so I cannot argue its usefulness or not.
I would also like to know the opinion of others about this
There was a time not too long ago where I was having Z-wave device issues on my main hub and sometimes the whole Maker instance would get locked up. As a test I separated my Z-Wave and Zigbee devices into different Maker instances. I think it helped just not completely sure but I've been running that way for a while now and have had no overload issues.
Since a single HE hub has the capability for multiple Maker instances it would seem like a good thing to be able to handle multiple configs via inputs anyway. I kinda like the idea of being able to add an optional "hubConfigId" to the deviceId property.. like this.
msg.deviceId = "hubConfigId/deviceId"
That way nothing has to change on the front end and the existence of a "/" would indicate a Hub Config selection... just my crazy rambling thoughts though...
I have been using NR and love the async non blocking capability along with huge community node offering. Very powerful but a little more to manage with additional points of failure. Overall I'm glad I made the move, but curious about a hub mesh setup with NR. Not sure they could be used together to improve performance.. ideas?
Do you mean reverse engineering the hub mesh multicast packets so that node-red would receive updates using the multicast packets and send data back via hub mesh multicast packets ? Sniffing the packets is technically doable if encryption is not turned on.
That said, I'm not sure it is WORTH the time to do it though.
Yep, not sure what type of multicasting they are using but ideally we could add a PC running NR into the HE mesh. This would get rid of all the bloated http calls to and from NR.
Technically possible. Someone just needs to start sniffing it out and reverse engineering the packet format. Just find someone with the time, and desire, to do that.
And the other requests are covered as a result of it. When you edit either a command or device node you can create multiples on the Server field.
and you talk to me about dynamic multi-hub configuration ... I think I'm not ready for this conversation 
