Doubtful. the hubitat home assistant integration requires you to manually configure maker api.
The only thing I can think of that's already setup to change that IP address in maker api is the hubitat node red configuration node. It has a "configure webhook" button that will change the IP to whatever IP address you have in the text box above it.
New to Node-RED and hoping to lighten the load on my Hubitat hubs. This looks like it can help. Looks like HSM and HSM-setter are in the works or are they working and just not in the prod release? How would one get to those assuming I want to live dangerously.
I don't know about dangerously, but I've been getting/setting HSM using http request nodes.
Same, it's really not more difficult this way than with an actual node designed to do it.
Ahh. How about knowing when a certain mode is set so you can do things? Guess I could go off of the mode and retool some things to use that vs HSM state. Thanks!
HSM nodes are mostly done, but a little bit outdated from master code. Only functional testing is missing.
Since I refactor and change some behavior from original author code and I never used HSM feature, I would like a functional test before release them.
That being said, these nodes are helpers and can be done without them. They are nice if you want to keep HSM logic inside HE and want a pre-configured node and with a nice status in your NR. Like all hubitat nodes, you can use http request node to do the same thing, but it's nice to have pre-populated dropdown and status 
What do I mean by functional tests?
But if you (or anyone) are willing to make functional tests:
I know it can be hard for some of us to have a another setup than prod to make tests. So maybe I should only release these nodes and make several quick fix after if needed? 
Edit: branch is now rebased on master (to include new icons, systemStart and websocket feature)
I don't currently have HSM installed on my development hub, but I could certainly do so this weekend, if needed, and use my dev node-red instance to test.
It would be better if someone that actually uses HSM in production would test it though, as they know how they use it 'in real life'... I don't use HSM.
I've upgraded to the Hubitat Nodes 1.1 and also am using websocket.
One thing I've noticed, and it took me a while to figure out, is that websocket doesnt limit the data stream to selected devices, as does Maker (obvious now I think about it).
I'm getting duplicate device events, since I have a two HE hub system. Obviously with Maker, I only connected the devices that were physically on that hub. But now with websocket, I'm getting both hubs reporting if the device is Hubconnected. It only seems to make a difference with the tables that I stole from @JasonJoel.
Absolutely correct! Not only does websocket not dedupe events on a single device, it also blasts EVERYTHING out - not just what is selected in Maker API (as it is independent of/unrelated to Maker API).
Good point.
Just FYI for others, I worked on this testing tonight. So hopefully with a few adders/changes @fblackburn will be able to include the HSM nodes as well in a future release. 
I don't want to pollute the topic, but the de-dupe and Selection Filtering is why HubConnect has a NodeJS proxy server. It's probably one of the most important features, in my opinion. Largely because it makes the resultant WebSocket functionally equivalent to MakerAPI without the load on the Hub.
For those of us that already have a HubConnect NodeJS Server, the Websocket option might function as the only Node-Red connection I need. It's crossed my mind a couple of times, always when I have so many other things up in the air, I've never even tried it.
It would also be pretty easy for @fblackburn to add dedupe in his node set when using ws.... If new value = cached value, discard. Probably <5 lines of code.
Also a pretty interesting idea. You very well may be right/be able to use that directly - good thinking.
It doesn't work, out-of-the-box.
Probably the Hubitat Configuration Node is hard coded in just enough of the wrong way...
I can use a WebSocket Client to monitor the HubConnect NodeJS WS and everything is there, but that is just one side of the connection.
"Websocket error: {"errno":"ECONNREFUSED","code":"ECONNREFUSED","syscall":"connect","address":"192.168.7.129","port":80}"
Not much data to chase in that error message. 
Although the Port is incorrect. I entered "22010" in the Port field, but the error is showing 80 
Does anyone know how I might chase down this error. I've tried searching for node 3785, and nothing. This error is just after startup. I've opened the file (/usr/lib/node_modules/node-red/node_modules/@node-red/util/lib/) and it seems uncorrupted/fine.
I setup Node-red on a computer, maker API with some virtual devices, etc. It works but I miss something probably ridiculous...
I can inject numeric values (inject node) and the result is ok on my dashboard/device
I harvested some data from my modbus PLC (ok, I obtain the values - debug mode) and I want to inject them into HE. That's my problem. I obtain only msg.payload[X] where X is the payload position of my modbus area.
I probably forgot something about values, messages, conversion... where is my error ?
I'm not completely sure, but it looks like the Arguments field in the Command Node might only accept values, not JSONata, so I'd suggest adding a Change Node before the command node, and setting msg.arguments to msg.payload[58], then remove the arguments from within the Command Node.
Correct
Same result 
It seems that I lose something here.
As you can see, the result of my modbus poll is a number (967 Watts, a number, taken from an array), I did convert it from the beginning, and removing the argument has no consequences.
Don't you need to set msg.arguments not payload? Also if msg.payload[0] does not work try jsonata/payload[0] maybe. It should though..
Download the Hubitat app
