I’m running a Bond Bridge Pro on firmware v3.21.3.1. I have a repeating command being sent to the Bond Bridge Pro every 60 seconds that contains just the newline command. That returns the following string via UDP -
{“B”:“ZPGE43123”,“d”:0,“v”:“v3.21.3.1”}\n
I don’t receive any other UDP messages for changes in state of the fan.
Is there something I’m missing? Do I need to be on the Beta firmware to enable BPUP?
I’m not aware of a regression here, but we don’t have an automated test. Will try to check this on our release testing.
@merck - Can you please advise the current status of BPUP on the Bond Bridge Pro? I just wish to clarify if there’s an issue in my home network or whether the fault is in current firmware (v3.21.3.1).
@Icarus my apologies for the late reply.
I can confirm that:
BPUP is operational on v3.21.3.1 / BD-1750:
BPUP is operational on a recent dev version (similar to the current v4.4.1-beta):
And that I am a huge mythology fan:
Hi @merck. Thanks for the reply. I’ve just updated to v3.21.3.6 on a Bond Bridge Pro. As before, I get a successful reply to the keep-alive transmission of \n. The reply is -
{“B”:“ZPGE43039”,“d”:0,“v”:“v3.21.3.6”}\n
I don’t see any other UDP responses to On/Off or speed change.
The Bond Bridge Pro is powered via POE. Is there anything I might try to narrow down the issue?
For info, the \n command is sent via a Loxone Miniserver using /dev/udp/10.1.1.39/30007
Do you have any other machine available on that network to test some listening scripts?
I power my Pro with PoE and have had no problems with my ongoing BPUP monitoring scripts, across all versions up to and including 4.4.1 beta.
Yes, I’ve got a couple of Raspberry Pi’s. Both have Node Red. I would welcome testing the listening scripts you mentioned.
You can try using netcat. Use the “nc” command as shown in my screenshots above. I’m running this from macOS but the commands on Linux should be very similar if not identical.
You might also try using Wireshark on the RPi to see what’s going on at the packet-level.
Hello @merck. I believe I’ve narrowed down the problem to a fundamental limitation in the Loxone home automation system.
There is a known issue with sending and receiving on the same UDP port in the Loxone Miniserver. To resolve the issue, a client (eg. Bond Bridge Pro), would need to reply on a different UDP port.
Ideally, pinging the Bond Bridge Pro on 30007 with \n would continue. A modification to provide the response on a different port like 30008 should fix the issue (or an additional response on an adjacent port, 30007 plus 30008).
Appreciate this is an edge-case for a small eco-system. It would be appreciated if this might be considered for future firmwares.
Hey Icarus,
Let me clarify: there be two ways to use BPUP:
(1) works best on Ethernet, (2) on Wi-Fi.
Sounds like Loxone could use either. (And a bug report.)
Success! Thank you.
The clarification with ‘enable broadcast’ was the clue I needed.
I can receive the status updates on UDP port 30007 now. It also confirms the issue is with Loxone and it’s inability to both transmit and receive on the same UDP port.
If anyone using Loxone follows this thread, be aware that the PATCH command is not supported in Loxone (only GET, POST, PUT and DELETE). To enable Broadcast, a curl command needs to be run from a different device directed at the Bond Pro bridge -
curl -X PATCH -H “Content-Type: application/json” -d ‘{“_token”:“abcdefghijklmnop”,“broadcast”: true}’ http://BondBridgeIPaddress/v2/api/bpup
Does this sound like a way to enable Loxone to do the ‘faked’ PATCH command? Back in the day I had asked for a way to issue different commands for Bond to interpret, other than what an integration platform offered directly. Worked a treat.
(Note @merck – this “_m”: 4 for PATCH, “_m”: 2 for POST, etc feature is still used by some of us but I don’t think the documentation ever mentioned it)
@merck - I used the Bond API to write my own integration. I hadn’t checked the Loxone Library for a Bond template. Notwithstanding, there isn’t a reference to BPUP enablement in the template.
@residualimages - The ‘faked’ PATCH command would be a worthy addition to the Loxone template. Or inclusion in the documentation.
For what it’s worth, the Bond API reads very well. But the ‘enable broadcast’ method is buried so deep in the document, I had honestly missed it.
The section that lists the ‘\n’ method would benefit with a hyperlink to the ‘enable broadcast’ method.
