Great minds!!! 
Or, if you decide you want each of the Hubitat node types to be a different color after a palette update:
1 Like
I feel like I should also be making a Matrix reference here as well... Blue and Red nodes, do you get different outcomes depending on which one you choose? Not a serious question btw...
1 Like
There is only the "red" pill here sorry. 
1 Like
Oh wow.. that's next level stuff. 
No one answer to this. I for one am leaving everything on node-red. It is much easier to program for me, I can backup/restore with a few clicks, and can run it on as fast/slow hardware as I feel like.
2 Likes
Unfortunately, if a request is received by an endpoint that doesn't exist, node-red will not show log.
But if you want a lot of more log about hubitat nodes, then you can active the debug logging in the NR config file and you will have a lot of stuff.
I'm not using hassio (I didn't know that was a wrapper of Home assistant), but thank you I'll add hassio as alias of HA in the FAQ
I would think motion lightning on a remote controller hub would run quicker now that Hub Mesh is using multicast. One of my goals is that my device hubs will run zero applications, just the zdevices and drivers to ensure the maximum performance level. I really like NR and see the flexibility, I guess this goes back to HE enabling a remote PC with the ability to see the multicast stream. This would be end state as it would remove all the MakerAPI bloated HTTP calls. It's been made clear the web sockets integration with NR is not stable and may be removed in the future. Again, trying to remove http for all the device communication.
Maybe, maybe not. If it is it would be to the tune of tens of ms - not a huge difference.
But each to their own! There isn't any 1 right or wrong way of doing things. I see no real issue with HTTP. 
All of my automations are running plenty fast for me. Going through any work at this point to shave off 50ms isn't something I'm interested in.
2 Likes
The more middleware, the more latency when issuing multiple concurrent calls. I agree http is pretty fast, but when sending a large group of a commands concurrently we see slowness. Perhaps multicast would help this.
Maybe! Good luck.
1 Like
If you are able to do some benchmark, I will be curious about an order of magnitude of the speed vs the websocket
Integrate hubitat multicast logic into a third software party will be the same level of support as the websocket: e.g: not documented by the HE team, then not officially supported
Anyways, the purpose of the websocket integration in these nodes is exactly for what you're trying to do. Add a specific config with websocket enabled and use it in your motion flows (with the de-dup logic if needed). It should be a very quick test to know if it enough or not for you
2 Likes
I supposed you are correct. 
Why would I need to use the events node and dedup when I can just add the device node directly? Isn't this method supported under websockets?
THanks!
This is what I do and I haven't had any problems. 
So far, yes.
Yes, using webhook and websocket in parallel
Note that device node will not dedup events sent when using websocket. This process is done by Maker API, it's why webhook don't have this issue
2 Likes
New version released 1.4.0 
-
device: allow to override device with the device ID (e.i. msg.deviceId = 12)
-
config: supporthttpNodeRootoption for webhook configuration (e.g. Homme Assistant use/endpoint)
- improve logs about unsupported dataType
Thanks to the community for feedbacks 
7 Likes
Thumbs up! So basically use websocket for use cases that require quick events (i.e. motion lighting, etc)?
Yes exactly 
Nice, just curious. Is there a noticeable or measurable difference?
Most here, including myself, have found a few tens of milliseconds difference. Noticeable? To some, yes but not to me. I still use websocket for ML just because I can.
2 Likes
