It is a mechanism to avoid having more than one configuration node listen on the same path
Can you check if you have more than one hubitat config node in the configuration nodes menu top right
I do. I always have had 2, as I have 2 hubs so setup 2 configs from day 1. But each of them has a different webhook path - at least that is how I set it up after upgrading to 0.0.19...
Hub 151:
/hubitat151/webhook
Hub 161:
/hubitat161/webhook
It was not supported (before 0.0. 19) and you was lucky that your 2 hubs didn't have the same devices ID, otherwise it will conflict
Yeah, I know.
I was careful about checking device IDs on devices while having 2 configs.
On 0.0.19 when I do a setLevel to a light with an argument of 50, I get this error on the Hubitat side. Kind of looks like the argument is not getting passed at all.
dev:772020-03-01 01:34:21.408 pm errororg.codehaus.groovy.runtime.metaclass.MethodSelectionException: Could not find which method setLevel() to invoke from this list: public java.lang.Object user_driver_Botched1_GE_Z_Wave_Plus_Dimmer_495#setLevel(java.lang.Object) public java.lang.Object user_driver_Botched1_GE_Z_Wave_Plus_Dimmer_495#setLevel(java.lang.Object, java.lang.Object) (setLevel)
Very simple flow:
Totally my fault, with a quick fix over the nigh .... so sorry 
I will fix it, test it and publish a new version
No worries at all! Minor issue in the big scheme of things!
Back on the 2 config thing...
I do have 2 configs:
Not sure why I get the underscore appended, as each webhook path is obviously different. That said, I am getting events in any case, so it seems to be working, regardless of the "_" shown.
Another interesting observation is that if I delete the underscore, update and deploy, I then get another underscore. So each time I update, I get another underscore. 
EDIT: that isn't 100% true. I was up to three underscores, when I went for 4 it went back to only 1 underscore. So not as consistent as I thought. sorry for the misinformation.
Thanks for testing, you can see the real endpoint the server listen on the node-red log
You should see something like this:
Starting endpoint for /hubitat/webhook
I'm on it
EDIT: I will remove this helper and leave it to the user not do that 
1 Like
is Node-Red restartable without going into SSH to do so? (I'm running NR on a Pi)
Don't think so. No way I know anyway.
I figured "npm restart node-red" would be the method to do the task but it said "no such folder or directory", I just ended up saying "sudo reboot" and I'm on 0.19
Great work on this guys, it feels like Stringify is back (oh how I've missed Stringify)
1 Like
This will work if you're in the directory that contains the package.json for node-red.
0.0.21 published, should be available soon on NR
Fix the arguments issue and remove the webhookPath underscore helper
Oh, side note... You CAN use an EXEC node, run node-red-restart and restart node-red from the gui/a flow... Use with caution/at your own risk, though.
If you do this and put your node-red into an infinite reboot loop, don't come crying to me! 
2 Likes
Just updated. testing now.
EDIT 1 - setLevel works again.
EDIT 2 - No more underscore on webhook path after updating.
Nice job. 
1 Like
0.0.19 broke my Hubitat config w/o any way to update it
0.0.21 brought it back 
2 Likes
And now with 0.0.21 I should have the side benefit of using multiple hubs in the supported way, instead of the bootleg way I was doing it before.
2 Likes
All flows now working again after upgrade, thanks!
Had to delete the underscore, then deploy.
2 Likes
I'm using 0.21 and I'm not getting status updates from Hubitat devices (motion, illuminance etc). I was until I updated from about 12 hours ago.
I've correctly configured the webbooks and got the green tick on the configuration node, but no updates.
Edit: the mode node works, not the device nodes (not updating with status from Hubitat).
