I have been able to configure my Bond Bridge to connect to my own MQTT broker using the v2 API, but I don’t know where to go from there. Is there any documentation that describes how to interact with the Bond Bridge via MQTT?
To be honest, redirecting the MQTT endpoint is untested. We’ve got lots the redirect implemented but not used for anything yet, so there’s likely to be bugs. That said, the API is just the HTTP api tunneled over MQTT messages!
Also, consider that if you redirect MQTT, you will be unable to use any Bond cloud integration (Alexa etc) nor the Bond Home app when away from home.
I’d strongly suggest the HTTP API. (Or, like to hear why MQTT still makes sense.)
1 Like
That said, the API is just the HTTP api tunneled over MQTT messages!
Could you elaborate? To my understanding of how the MQTT protocol works, there’s no equivalent to a GET request. So what would be the MQTT equivalent of GET /v2/devices? How does token authentication work?
I’d strongly suggest the HTTP API. (Or, like to hear why MQTT still makes sense.)
Many smart home / IoT solutions already support MQTT, so instead of having to build a custom handler for the BondHome API it would be nice to reuse the existing MQTT functionality.
There has been discussion of this over on the OpenHAB forums.
For tunneling we simply wrap the HTTP body in another layer of JSON containing the HTTP method/status etc. — Yes we’d need to get you docs on that.
MQTT and HTTP (as we use it) are layer 5 protocols (Session), but the Bond API is layer 7 (Application).
So, you would still need to write a custom handler for Bond API, to handle such things as discovering devices on the bridge, figuring out their names, and calling the actions appropriately.
To handle the problem of push feedback on the local API we implemented BPUP (another layer 5 protocol) which can work well in conjunction with HTTP.
Buuuut, if you really want to use the MQTT transport and are ok with losing the Bond Home official cloud connection, then you can (once we get tests in place and documentation to you). But it’s hard to see how very different layer 7 protocols can coexist on the same MQTT broker? Perhaps you also need to be able to specify a relative sub topic?
After I manage to add a few more hours to each day, I definitely plan to start on a binding for Bond.
I have a list of things sitting in that pile for me too - please share when you find the way to accomplish!!
I’ve starting something here: https://github.com/SRGDamia1/openhab2-addons/tree/bondhome/bundles/org.openhab.binding.bondhome
All it can do right now is discover the fans.
1 Like
Is this using HTTP or MQTT?
I’m using HTTP and BPUP.
I’ve pushed the local utility that I have been using to connect the Bond Home API + BPUP to MQTT at https://github.com/ssmall/bondhome-mqtt
I would love to see this functionality in the Bond Home Bridge itself; if I connect my bridge to an MQTT broker, it could set up these same topics.
1 Like
Since you’ve got it working over BPUP: the MQTT message payload would be the same as the BPUP payload, so, most importantly, "m" the HTTP-equivalent method, "b" the body, and "s" is the HTTP-equivalent status. We’ll get around to testing the api/mqtt endpoint so that you could use a custom broker, and making this clear in the docs.
There’re two differences I can think of: the "B" (Bond ID) is not necessary for anything other than BPUP, and the "t" (topic) is not needed, as it is extracted from the MQTT topic.
The Bond will subscribe to v2/<Bond ID>/down/#, where the wildcard # is equivalent to the HTTP endpoint less v2/, and publish to v2/<Bond ID>/up/<topic>
One example: the MQTT equivalent to HTTP GET v2/devices is an MQTT message on the topic v2/<Bond ID>/down/devices with a payload of {"m": 0} (but 0 (GET) is the default for "m" (method), so this payload could simply be {})
If you have a device, the Bond would then publish an MQTT message on the topic v2/<Bond ID>/up/devices with a payload of {"s": 200, ..., "b": {<dev_id>: <dev_hash>}}
You can add request IDs with "i", which is especially useful if you intend to use multiple transports, as our mobile apps do, or in general to link “requests” to “responses”.
Note: you can also send “requests” over BPUP this way, it’s not just a push protocol.
Pull Request to the docs with basically the same info as above: https://github.com/bondhome/api-v2/pull/4
The MQTT broker to which the Bond is connected is treated as trusted, token authentication is not necessary. Make sure you use the server_cert fields in api/mqtt to avoid man-in-the-middle attacks.
@jacob Could you please elaborate how to send “requests” over BPUP ? I tried it and it didn’t work for me. Since there is no concept of topics on BPUP, how would I query a specific branch or send an Action over BPUP.
eg. using ncat to make a UDP connection to Port 30007
c:\> ncat -u 192.168.1.18 30007
{"B":"KNKSACG91894"}
{"m": 0}
{"B":"KNKSACG91894"}
As you can see from the above. When I send the default (“m”:0) or HTTP Get request, I expected to see the devices, but I am returned the same ack message back.