Correct. I just did that on 800+ nodes... The other option would be to shut down node-red and search/replace the deviceids in flows.json I guess (EDIT: Yeah, like @jason-lane already said. lol). I did it by hand as I also took the opportunity to remove a bunch of nodes through more intelligent change nodes/logic to set commands/arguments. Got rid of maybe 200 nodes or so worth.
Maybe a future version of the node set will allow overriding device with name OR deviceid. That could potentially prevent the issue (if you named the devices the same on the new hub, of course). Or maybe the Hubitat migration service will keep all deviceids the same on the migrated system, which would be nice.
Being a rookie with NR I'm interested to see what you did here. Might you have a before & after flow as an example? I'm sure I'd learn from it as I only recently tossed my function nodes in favor of change nodes for reading/writing context variables. I'd read something about doing so but it wasn't until I imported a flow that @aaiyar posted in the examples topic that I saw how to do it.
In general though, I had a lot of places where for GE motion dimmers I would set the dimmer level, default level %, motion setting, and light timeout.
I liked doing that with 4 different command nodes, as it makes the flow VERY easy to read and follow. The side effect of doing that, though, means I had to edit 4 nodes when I changed hubs.
Now I use a change nodes to set the msg.command and msg.arguments going into a single command node. So in the future, just 1 node to update if I change hubs. Yes, there are now more change nodes, but those are static.
It is handy to reduce the number of nodes - which actually is a good thing because each node keeps its own cache of values. So if you use the same device in 4 nodes, there are 4 copies of the attributes floating around out there.
If the node sets ever changes to using a global cache (I believe Francois was looking into/testing that) that redundancy would go away, of course.
But I'll say that the flows are a little harder to follow/read. Not horribly so, but I did prefer the look/feel with 4 command nodes more.
I have 1 switch that throws the same error every time. When my outside illum goes over 30000 it triggers a boolean that triggers atimer to turn off the lights in my master bedroom.
Yeah, I need to delete almost everything that is coming in. the msg.argument from a previous flow that brings the illum in is making it all the way here.
