BPUP - Possible Enhancements to Source of Command / Action ("x")

Integrations
1

Since I find the Action history potentially useful for troubleshooting integrations, and because I understand it’s not feasible to have in the Bond app directly per the post below, I wonder if there is an opportunity to have a local network logger running for a Bond owner with just a couple tweaks to the current BPUP implementation?

When I started thinking this morning of a local network logger a Bond owner could run, based on BPUP, I realized that it’s a little difficult to tell at a glance what is truly “Bond app” initiated vs what is Google (and presumably Alexa etc) initiated vs what is Local API direct call initiated – at least from what I’m seeing.

The Local API initiated feels a little more easily spotted, but I think there’s room for a slight update to what goes in the “x” part (source transport) of the BPUP notification.
As in, if x = ‘http’ or ‘mqtt’, maybe it could specify which service was the source, if it came from a known “linked service” integration. If not from a linked service and not from the Bond app, then it is assumed to be the Local API directly called (and optionally could show from what IP address the API call was sent)?

Changes initiated in Bond App, an initial “x” of ‘bond’, followed immediately by an “x” of ‘bond’:

BPUP data payload received: (8/9/2023 8:57:01 AM)
	{"B":"ZPxxxxxxx","d":0,"v":"v3.15.5-beta","t":"devices/aabbccdd/state","i":"05000033ae51c1e0","f":100,"s":200,"m":0,"x":"bond","b":{"power":1,"light":0,"flame":1,"_":"d44ea720","__":"d44ea720"}}

BPUP data payload received: (8/9/2023 8:57:01 AM)
	{"B":"ZPxxxxxxx","d":0,"v":"v3.15.5-beta","t":"devices/00000000aabbccdd/actions/ToggleLight","i":"01000039826c505c","f":228,"s":200,"m":2,"x":"bond","b":{"argument":null,"no_tx":true,"_":"00000000","__":"00000000"}}

Changes initiated via local API from third party controller, an initial “x” of ‘bond’, followed immediately by an “x” of ‘http’:

BPUP data payload received: (8/9/2023 8:57:32 AM)
	{"B":"ZPxxxxxxx","d":0,"v":"v3.15.5-beta","t":"devices/aabbccdd/state","i":"0500009081f4656b","f":100,"s":200,"m":0,"x":"bond","b":{"power":1,"light":0,"flame":1,"_":"d44ea720","__":"d44ea720"}}

BPUP data payload received: (8/9/2023 8:57:32 AM)
	{"B":"ZPxxxxxxx","d":0,"v":"v3.15.5-beta","t":"devices/aabbccdd/actions/TurnLightOff","i":"06000067d5b5d2f0","f":132,"s":200,"m":2,"x":"http","b":{"_":"00000000","__":"00000000"}}

Changes initiated via Google Home app, an initial “x” of ‘bond’, followed immediately by an “x” of ‘mqtt’ (not sure if this would vary based on if a user has a Thread / Matter / Google Home Hub, as I do, vs someone that only uses Google Assistant on a phone):

BPUP data payload received: (8/9/2023 8:57:51 AM)
	{"B":"ZPxxxxxxx","d":0,"v":"v3.15.5-beta","t":"devices/aabbccdd/state","i":"05000099f2322a63","f":100,"s":200,"m":0,"x":"bond","b":{"power":1,"light":1,"flame":1,"_":"7a2636b1","__":"7a2636b1"}}

BPUP data payload received: (8/9/2023 8:57:51 AM)
	{"B":"ZPxxxxxxx","d":0,"v":"v3.15.5-beta","t":"devices/aabbccdd/actions/SetFlame","i":"0cbbf54ff3110053","f":132,"s":200,"m":2,"x":"mqtt","b":{"argument":100,"_":"00000000","__":"00000000"}}
1 Like
2

I hear you. Actually the source of the request is encoded into the first byte of the request ID. But indeed it would be nice to break it out into a separate “requestor” key with human-readable value.

2 Likes
3

Oh! Is this the mapping currently?

Bond App:

"i":"01..."

or

"i":"05..."

Local API:

"i":"06..."

Google Home and/or Assistant:

"i":"0c..."
1 Like
4

Hey @residualimages
That’s correct! Since I work on the iOS app, I can confirm to you that the iOS is 02.
Also, may be worth mentioning that 3rd party integrations should use values above A0 - being A0 for Home Assistant.

1 Like
5

Okay, cool!
So 01 might be the Bond Android app?
02 is the Bond iOS app.
Wonder what the 05 is? :face_with_monocle:

Endy is there a way when sending an API command to specify this ‘source transport’, in order to be compliant with that recommendation?
Or does an incoming command’s source have to be recognized / determined by the Bridge software, and then it simply enumerates the known sources back out as the ‘x’ / source transport?

6

I confirmed that 01 is Android app, and 05 is from the Bond (like the reply), does it make sense to you? :smile:

You specify the source transport in the first byte on the randomly generated request ID.

1 Like
7

Sorry to keep being a pest. Is that Request ID something that is only sent via mqtt clients?
I tried with a normal http call and a Header of Request-ID, RequestID, X, I and maybe a few others, but no dice; all the calls just say "x":"http".

Or is this supposed to be part of the BOND-Flags Header?

Specifically asking since most of my integrations use http, but I could see how occasionally it might be useful to denote which integrations are calling which http requests.

8

There’s three things going on.

The request ID (BOND-UUID header) is a 64-bit ID with some structure to it. The first byte (the most-significant byte) indicates Requestor Class, such as iOS App or Control4. — But this approach is prone to collisions and misimplementations, and requires registration, so we need a better way for the community.

The x field on MQTT/BPUP indicates the Source Transport, such as http or mqtt or bpup.

Note that these are different concepts. For example, the iOS app may use any transport to communicate.

BOND-Flags does not contain any information about the requestor.

What about Bond-Client-Name and Bond-Client-Version headers where the integration author can put a string identifying the integration? Example:

Bond-Integration-Name: home-assistant
Bond-Integration-Version: 3.2.1

This would be entirely uncontrolled, just for info purposes…

2 Likes
9

Sorry I was getting a bit muddled on what comes from where.

It’s not a high priority, just would be useful for troubleshooting / auditing occasionally.
But I like the sound of your brainstorm option.