There are many manufacturers, and one Hubitat. It isn't hard to figure out that it would be much more convenient to configure listening ports on the receiver side than to work with dozens+ of manufacturers to change their product.
The aggregation point - Hubitat for Home Automation items in this discussion - is the one that needs to be flexible in terms of ports it can listen on.
Not the 'hill I'm going to die on', so to speak. I will continue to use external devices and push the data into Hubitat via MakerAPI. But I do think it would greatly simplify things to have Hubitat listen on the port and do the parsing there - remove one link in the chain, reduce code/logic to support.
But why??? A rPI is an open development platform, Hubitat is not, it is an Home Automation Platform. Two very different functions. What would be the benefit of getting rid of the rPIs?
Yes. Same as I'm doing in node.js or Node-Red today on an external device.
"Perfection is the enemy of progress...."
Yes, there are scenarios where it could be impossible, or inconvenient. But for the 99% of times the ports are unused in existing Hubitat functionality, it would be a definite win.
No need to not do it at all because some edge case may not work.
Fewer pieces = less support effort/less admin overhead by the end users. By that same logic Hubitat shouldn't have an integration for Google, Alexa, Life360, etc... etc... etc...
I actually think there is a much bigger risk here. Opening up ports also increases risk from a security perspective. And yes, Hubitat can say "do it at your own risk". However, if there would be ever a security related incident, no matter what "port" it was one, it is the brand that suffers, not the individual that opened that port simply because the brand allowed the individual to do so.
There are external ways of doing what I need to do - so I'm not losing sleep over it. Would I like to have fewer 'moving parts' to support? Yes. But it is not a huge issue for me right now.
The flip side of the coin is that the more of the logic people do in external systems, the less valuable Hubitat is and the easier it is to switch to a different system in the future.
If Hubitat is just a conduit to pull in zigbee and zwave, but little else, then as zigbee support improves in other options I think Hubitat will lose customer base.
I think it is more strategic for them to WANT users to use Hubitat as much as possible, and make it a key part of their home automation solution.
As long as they leave event socket open, you could pretty easily do ALL of your logic/code external of Hubitat if you really wanted to. I've done a reasonable amount of performance metric collection on doing exactly that, and it is pretty darn fast (although measurably slower than doing it locally)...
But as Dan already stated - all of this is for Hubitat to decide on, not us.
I'm not a big fan of having multiple rPIs around a home just to support the piece of software that literally belongs to the HUB. I don't see any issues of having MQTT broker in hubitat, but again, this is from my, long term development experience. Probably there are different issues from HE core team that I'm not aware of. I bet there are issues.
But the facts are
MQTT Broker is a hub software and it is super weird to have it installed on some device, outside of HE
MQTT Broker is not CPU intense, so I'm sure it won't be a problem for HE hardware to serve
Having MQTT Interface which can provide just a client style for HE makes HE hub not a hub, but just a device, client, that guys are calling from the devices like rPI when they need "a really cool integration". This is mostly a political thing... Is HE a hub or a client? )))
Hubitat is a hub, there is no question about it. Yes, it is not a MQTT broker, I get that, but they also never advertised that they were and there is not any kind of standard out there that all hubs need to be a MQTT broker.
I’ll be honest, i have no use for MQTT, however, here is how I would go about it:
Instead of asking for any kind of port access, I would ask for Hubitat to implement the MQTT broker function with the justification on why it would be good not only for you, but several customers of theirs. That is how the MQTT client was implemented, the first person asked, several community members also expressed interest and the Hubitat team saw that they wouldn’t just implement something for one or two people. It is not just about the MQTT broker function itself, but also about testing, UI adaptation, maintenance and support.
The team is great, they are always happy to expand on their functionality, but it needs to fit into their view of their product and be used by more than a handful of people. Otherwise there is no ROI.
You could make a similar case for SMTP NTP DNS databases etc etc.
For me as a heavy MQTT user I am sure my usage will impact HE’s performance.. simple solution for me I would stay external. I wouldn’t even bridge. Is it easier for non technical users to have an internal broker.. yes.
I sit in between the positions. Would I like to be able to process TCP and UDP traffic via listen ports on HE. Yes and I think for a controller that differentiates itself on local connectivity it’s a surprising omission.
Will other manufacturers continue to use their own published control ports.. yes.. will they support HE’s single port ... no never.
Do I think a HE MQTT broker makes sense. Well it’s not for me but has an ease of use factor for novice users... and mustn’t impact performance.
There are other issues.. could an internal broker support secure encrypted incoming and outgoing connections for bridging etc ??
My real issue is that MQTT is not for novice users and is not plug and play and shows little evolutionary changes in that regard for capability discovery. So really because of this we don’t need a novice broker on HE and having one would create a support problem. Interested advanced MQTT users will either already have or very easily be able to supply a broker.. and these more advanced users will usually prefer that solution
