.
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
1 Like
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
- example with authentication(ACL) (using
httpAdminand setneedsPermission) - example without authentication (using raw
httpNodeand no setneedsPermission)
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
1 Like
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
- HE send event on NR
- NR answer with 401
- HE resend event with basic auth headers
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?
1 Like
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
2 Likes
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:
- Get current value of the switch to know if it is ON or OFF. This is where you need to specify device dynamically in the device node as an input.
- Set switch to opposite value (if on, turn off - if off, turn on). This is where you need to specify device dynamically in the command node as an input.
2 Likes
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.
1 Like
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.
1 Like
Only selecting a single device is okay for me too as long as it can be done dynamically - we can most likely parse things prior to that to get multi-device behavior. Matching would not have to be done in the node itself (or did I miss something?)
I was thinking the same, could possibly do a split node or something to break everything into single messages if only 1-1 matching is available.
1 Like
I am working via NR to consolidate all of my device status info into MQTT (and InfluxDB for analysis). I am doing this to account for Hubitat devices, Homebridge devices and ZigBee2MQTT devices. Working with the Hubitat device nodes, before all became an attribute option, I could get current status when NR starts (at the cost of hammering my HE) and then get ongoing status as things change with one device node per attribute. This is a little messy but the complexity can be hidden in subnodes.
With the addition of the option of selecting all attributes in the device node, it appears that I get the same info upon initially triggering that node.
-
Does it also emit events for any change to any of the attributes of that device?
It seems to -
Does the output change format?
It seems to. When triggered, the payload seems be a set of objects each of which is the equivalent to the payload of a node configured to a specific attribute, but when an event happens on HE and is sent through, the payload seems to be just like the output of a node configured
-
Does either approach (one NR node per attribute or 1 all attributes node per device) a larger strain on HE Maker Api?
-
If there is a difference, is that only true of a NR to HE request or is it equally true of receiving events from HE?
Yeah the words were wrong. My enough was only on local network
Being on local network is not a reason to remove all piece of security.
You don't want necessary be bulletproof against Internet, but only against your son who is trying to spoof and remove the parent controlling.
There's a lot of use cases I guess and I don't really care.
The point is only being compatible with what Node-RED offers (and how to mitigate Basic auth attacks)
To get ZigBee2MQTT up and running on an RPI 4, would a USB stick like this one work? I ask because I have one sitting in a bin right here at my desk. The thought of just bypassing the middle man (HE) is intriguing
I don't see any mention of "CC2531" in the specs for the dongle, so I'd suspect "no" 
#embrace_mqtt
