I got the HTTP part working, but my issues above are all way after all that jazz anyways. I've definitely got valid and decrypted OwnTracks data into my NR setup without MQTT or uncessarily opening up ports
I'm literally hard coding a (fake) location in a function node and passing it to a WorldMap node and can't get it to display the passed data, whether generated from an OwnTracks update or hardcoded as demonstrated above 
FWIW, I don't have any ports open either - everything is through a VPN. This is what the world-map with tracking looks like ...
Yeah, i've seem your previous posts of all of it working (it's what prompted me to get it rolling myself).... but that didn't/doesn't help with the issue i'm having :-/
I have HTTP working just fine, my issues are downstream from that process
.
Ah! figured it out!
Removed the "icon" from the message and now it works... that must be an older/breaking-change feature
Super strange: passing in an "emoji name" as it has listed in the options doesn't break the functionality but at the same time doesn't show either...
Oh - I forgot!! Removing icon from the function node was one of hte changes I made when I switched from trying WebHookRelay to MQTT.
.
Soooo.... cloooooose..... but from what I've been reading/researching nothing is going to fix my Ecobee reliance except replacing it lol
Why do you have two Maker API's ?
.
Something I read earlier in this post... i've got a lot of devices so I spread them across two endpoints thinking i wouldn't be hammering away at one...
I've been refactoring all my rules all weekend though (as I've really embraced MQTT), I'm sure could make do with one, but I don't feel like changing it at the moment
That's what I did a few months ago - replaced an ecobee3 and 6 sensors with a Honeywell T6 Pro zwave thermostat and 8 Konke sensors.
I can live with my Ecobee and the Hubitat app lol. It just would have been fun to clear the decks, but I guess I was always going to have one (or two!) Maker apps running anyways.
I don't even mess with the thermostat at all at this point, it's well trained for my quiet life.
Looks like the HE palette device node exposes plenty of data for it... someday down the road when i get serious about NR Dashboard I'll toy around with it more.
Big Warning
I found a new way to break a formerly very function HE to NR connection. I recently added basic authentication to my NR installation. What took me a while to realize was that as a result, I stopped getting the webhook feedback from HE to NR. After trying to redo the webhook many times, I finally realized that I had to put username/password authentication into the webhook URL for it to work. Thus:
http://NRserver/hubitat/webhook/ (working before adding authentication req on NR)
to
http://NRserver/hubitat/webhook/ (no longer working after adding authentication req on NR)
to
http://username:password@NRserver/hubitat/webhook/ (working again with authentication req on NR)
This is clearly not the most secure way to do things, but it does get the job done. Any thoughts on a more secure way to do this?
Yes the incoming event always has the deviceId property. Then you can take it and inject into the deviceId message property as input for command. It would be an exact match
I'm not sure to understand why we need to make dynamic deviceId for the device node? With the event node you can do the same thing
Do you talk about the authentication integrated in Node-RED or a custom proxy?
EDIT: If it's Node-RED authentication
Node-RED authentication is only for UI endpoints. I explicitly remove all kind of authentication to the webhook endpoint
httpAdmin and set needsPermission)httpNode and no set needsPermission)Maker API doesn't support basic authentication (or I don't know how to set it).
It ignores the username:password@ part and just send the event to the http://NRserver/hubitat/webhook/
From earlier version I always tested with authenticated Node-RED and never had issue. You probably have another issue. You can safely remove the username:password@ in your config, because if you inspect the request sent, then HE doesn't set any headers
The most secure way I know is setting a random path (ex: with uuid): /hubitat/webhook/a101fe32-af80-4bf8-981f-89e98649bcd8
This behavior (using uuid in path) is already in a PR
I find it interesting that you are having such a different experience from me. I am not able to follow the examples in the code, but what I am experiencing is that when I use the configure webhook button, it builds it into HE without any basic authentication. Without that basic authentication, I don't get updates to push from HE to NR. When I (manually) put the username:password@ part into the HE maker configuration, then the pushes get through to the nodes.
Does that make any sense or do you have another suggestion of what is going on? Here is what is in my setting.js with username and hashed password changed to protect the guilty:
// Securing Node-RED
// -----------------
// To password protect the Node-RED editor and admin API, the following
// property can be used. See Redirecting⌠for details.
//adminAuth: {
// type: "credentials",
// users: [{
// username: "admin",
// password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
// permissions: ""
// }]
//},
adminAuth: {
type: "credentials",
users: [
{
username: "username",
password: "$X2a$0x8$QpxjyOO.x17xjwqxJdxKBgx57nCO0x6RpFMSZkzuyKqXXXXXXXX",
permissions: ""
}
]
},
// To password protect the node-defined HTTP endpoints (httpNodeRoot), or
// the static content (httpStatic), the following properties can be used.
// The pass field is a bcrypt hash of the password.
// See RedirectingâŚ
//httpNodeAuth: {user:"user",pass:"$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN."},
httpNodeAuth: {
username: "username",
password: "$X2a$0x8$QpxjyOO.x17xjwqxJdxKBgx57nCO0x6RpFMSZkzuyKqXXXXXXXX",
},
Wow nice, thank you for this !!
As usual, I didn't read documentation until the end 
(I skipped the last section: HTTP Node security)
With wireshark we can see
This duplicate message is annoying ... but well it's on Maker API implementation (or maybe a RFC, I don't know well how basic auth should works)
Oh it's because basic auth is unsecure (clear) and if we don't want to send credential to everyone, it mitigates this issue with a challenge (more on apache doc 4.6 )
I'm glad you found a way to properly authenticate webhook endpoint. For now I will link your post on the first post, thanks 
Basic auth behind SSL/TLS proxy should be enough secure, no?
Doesnât matter how secure something is, someone out there is not going to think itâs secure enough. #tough_crowd
I donât understand why all that is necessary if oneâs setup is local only... if someone is able to send message to Maker or NR, thatâs small potatoes to someone being on your network in the first place!
If this stuff is exposed to the internet in the stock security model (read: nothing): yikes lol
I think it is the best that is available for Node Red at the moment.
Because in the scenario listed, when you want to toggle the random switch you need to:
If I am understanding what you are talking about being able to dynamically select which device is used in the HE nodes seems like a very powerful addition if feasible.
That in conjunction with a good HE device naming scheme means you could do things like "switch all 'upstairs-*' switches on/off" with far fewer nodes and automagically include newer devices as the get added to Maker API.. Lots of possibilities...
edit: also thinking this would be great for "initialization" routines on redeploy/restart or certain mode related tasks.
I think how useful it is depends on how @fblackburn implements it.
If it is by device id # only, I don't think that will be as useful, as that is not something readily available in all cases. If you could match full/partial/regex with the device label/name, that could have a lot of potential though.
And then, as you point out, if name matching is allowed would it have the ability to match a single device or multiple devices? For my uses I would be happy with single device, but I don't have a use case like @erktrek mentioned above.
Download the Hubitat app
