We have a good idea of what explains these differences, and of course are working on them. But we're talking about fairly small differences. Of course, if one had x times the speed in a processor, these differences go away or get much smaller. But, the point is that the perceptible difference would not be perceived as being worth the price. The tests above were against a fast Zigbee switch device. Try it with a Z-Wave dimmer, or a Lutron dimmer, with some fade time built in. Is shaving off 100 msecs even going to be noticed?
We have an approaching-an-asymptote sort of performance thing when dealing with CPU speed. 8x the cpu speed will move you further out on the curve, no doubt, but is it worth it? We think not, by a long shot.
I'm only about 7 months into this technology, having finally ditched my X10 system, so I've been watching from the sidelines a lot as I delve into this new world. I can't help but think there is a LOT of reason why it's called a "hub" instead of "I'll even wash your windows" and perhaps folks have come to expect too much from such a device. I could easily argue that much of Hubitat's abilities are misplaced and simply there to provide an entry point for HA for "new" folks in the HA world. A intro, if you will. Clearly it fills that bill quite well and also provides plenty of options for more sophisticated/ambitious users to move beyond while keeping a fully capable HUB at the core. The more I've learned about the diversity of this community and the use cases Hubitat enables at a very reasonable cost the more I appreciate the choices the company has made. Where else in any technology can you get so much for so little? My hat's off to the folks that make this possible.
I agree. Hubitat is better than every other “hub”. I mentioned home assistant to my mom “you trynna kill me, I got diabetes, raspberry pie will kill me”
So it’s wink, hubitat, or st and I’d say hubitat is the superior product
I’m not sure what your referencing but I’m sure “how do I load the json without a floppy disk? Any way whos jays son? I thought he only had a daughter with that pretty lady from Puerto Rico”
First, thanks to Bruce (@bravenel) for the extensive information and responses. Are there any tech reporters out there. There is a LOT of information in this thread on the operations, issues, and concerns in the overall SmartHome implementation as it stands today and going forward. Good for our users and good for general users to get them to come-on over. The article should include some of the specific Hubitat features:
User controlled internet activity (security and privacy),
Independent from Wide Area Network connectivity (in case of WAN / Power failure (with separate battery backup for local WiFi and Hub.
Tablet and Phone app accessible on local WiFi and (user option) Wide Area Network.
Browser accessible setup and modification and installation.
Customizable Dashboard but also an automatic dashboard available (this actually could be improved to assist novice users - but that is another topic).
Note it is not as easy as Amazon / Google, but it is more powerful, capable, and independent of the World Wide Web (at user option).
This being said, this thread is a MUST READ for all users!!!!!!!!!!!!!
Agree except for the users that want to detect manual switch or power activities on LAN devices and want sub-minute polling. A lot of these can cause a lot of activity. If TCP or UDP there is the message overhead in Hubitat. It is better using the ALPHA rawSocket. I am doing some testing on loaded and unloaded networks to determine the point where this may occur. I do this to improve the Kasa integration which has added the polling at user request.
Sure, I was referring to the latency introduced by network calls. You definitely still have the opportunity for launching self inflicted DOS attacks on your hubs and devices.
Thanks. You are absolutely correct. Just try accidentally creating a UDP comms send loop during development and pressing execute. It absolutely freezes the browser user interface. Requires a manual reboot (plug/unplug). You learn quickly to NOT do that. (another good thing about Hubitat: What you do to Hubitat affect you but not others.)
The discussion is:
Processing automation on hub and triggering actions
vs
Processing automation off hub, sending over lan and triggering actions.
While sending over lan shouldn't introduce much delay, it should still be slower than not sending anything over the lan. Simply because that extra step of sending over lan does add ms to the whole process. BUT the opposite is happening. It's faster. So why?
Well, that's the thing. Since we're talking operations that takes hundreds of milliseconds the actual lan latency in this processing is basically within the margin of error. It doesn't really matter.
It's also not really an apples to apples benchmark. The difference may be due to the different code paths within Hubitat (like the event deduplication that the websocket API seems to bypass) just as well as differences in implementation between Hubitat and Node-RED. Just looking at this benchmark the interesting part is comparing the Maker API/websocket to the MQTT app for integrating Node-RED. If latency is important it seems like the Maker API (with or without websocket) is slightly faster. That's kinda cool to know. That, plus the fact that offloading processing to Node-RED doesn't introduce a whole lot of latency.
Yeah, got that from @JasonJoel and I took a look. Nothing there interests me as I don't even have any need for NR at this time, let alone a "pay for every update on top of initial cost" solution. But I understand that my needs/wants are quite small and simple compared to the large body of users in this forum. Still, good to know what's out there just for general principles.
Unforunately, for many who have switched to node red, we're not talking hundreds of milliseconds. We're talking full seconds and in some cases multiple seconds.
You've got some theories that you posted above, others have different theories. Unfortunately I don't think we'll ever fully know why. It's promising though that staff have identified areas of improvement that may be contributing to these slow downs so the gap may eventually get to the point where we truly are talking hundreds of milliseconds.
I'd love to know the response time with that! Anybody?
