Hi,
I noticed that you can’t create more than one mqtt device/broken within HA. I was working on a custom integration that distributes sensor information via a public mqtt. Obviously my first approach was to send data using the HA mqtt format. But, given the constraint of only allowing one mqtt - this no longer seems like the best approach. So, in the end, it would be python code that talks to a public mqtt broker that I operate and maybe I would follow my own schema instead of the HA schema and I’ll transform my schema json into sensor data within the integration. Before i go too far down the rabbit hole on writing code - is this an acceptable approach to build a custom integration?
I haven’t yet crossed over whether a custom integration can keep a persistent connection option to an mqtt server. That’s on the list of problems i need to look into also.
I haven’t yet searched the HA codebase for examples of other integrations using the same approach either.
a local one for local things (like my frigate) and a remote one for scenario specific purposes. maybe mqtt isn’t the best protocol to use. but it seems like a good way to scale the scenario i have. the scenario is japan specific seismic events using japan specific real time earthquake network. i can issue one publish about an earthquake event and many clients can receive it in real time at the same time.
yeah i thought about it. but, i was trying to offer an integration that is click button simple. i’m a dev, so i can build things. having to build an integration with instructions that people if (one broker) then do this or else hack your mqtt config in home assistant to add brdging → it’s not very beautiful approach. something more elegant would be NOT having some limit on the number of brokers you can talk to within home assistant. not sure why it’s only one now.
An MQTT broker supports configuration and the Mosquito broker can be configured to support bridging. Search the forum for ‘MQTT bridge’ and there are several discussions over the past few years including configuration instructions. It’s my impression (based on being an active member here for over 5 years) that’s it’s not a widespread need but it is used by some.
Then I assume you will be submitting it for inclusion in HACS. Otherwise a custom integration must be installed manually and that tends to be a hurdle for some users.
Feel free to write a custom integration if you feel that’s the better approach. Check the Feature Requests section; there may be an existing request for multi-broker support so you’ll have a willing audience to test it. Good luck with your project.
i found this response the describes why only one broker is supported. so, yeah, i guess i’ll write an integration. it won’t be a HACS integration - instead a native HA integration.
What I’m trying to say is a single broker can be used for many things at the same time. Plenty of bandwidth. Just because the broker is run on the HA machine, it doesn’t mean HA cares about stuff you add in random places. HA only looks for things where it looks for things.
For instance, Tasmota and Z2M both have their own topics on the HA broker to keep track of it’s own business. When those want to share something with HA it puts that in a different topic on the broker where HA looks for it.
As a matter of fact, the Broker is really got nothing to do with HA. It is an addon running in it’s own docker with it’s own OS. HA signs in and looks to certain topics for information it cares about.
No reason you can’t log in with another project and store stuff there. WAY better than a public broker where thousands of people are sharing (in a manner not unlike HA’s broker) or writing scratch code you have to troubleshoot.
A native integration presupposes that the Core development team accepts your PR (to enhance the existing MQTT integration). Part of the acceptance process is that they see value in the PR and are willing to maintain and support the new feature.
I suggest you begin a discussion in the Architecture repository (sharing your proposal) to get feedback from the dev team.