API command responses

  • 1
  • Question
  • Updated 3 years ago
  • Answered
Here's another one for you Eric:

When my (non GUI) controller sends a command to the API I expect and always receive the response message, e.g.

15:06:30.837 | [API>] C26|slice tune 0 18.070275
15:06:30.846 | [<API] R26|0|

15:26:03.903 | [API>] C35|filt 0 -330 330
15:26:03.940 | [<API] R35|0|

For most commands, that's all I get but for the slice audio gain command I get more:

15:06:45.201 | [API>] C32|audio client 0 slice 0 gain 91
15:06:45.272 | [<API] R32|0|
15:06:45.275 | [<API] SD3D79865|slice 0 audio_gain=91 audio_pan=50 audio_mute=1

The API has effectively echoed back the setting I just gave it (and some other information for good measure).

I'm wondering why this would be? On the one hand I can see a valid argument that my app knows what setting it just asked for and it got a good response back, so it doesn't need anything else. Conversely, I can see that echoing back the change is a useful thing to do.

I tend to think that echoing back the all changes would be a good thing. It would certainly reduce the complexity of my code a bit. Is there any reason why some commands do and some do not?

TIA, John, 'WGV.
Photo of John G3WGV

John G3WGV

  • 200 Posts
  • 37 Reply Likes
  • In discovery mode

Posted 3 years ago

  • 1
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 919 Posts
  • 346 Reply Likes
Official Response
In general, we try to avoid sending back a status message with the same information that a client has just handed to the radio assuming the command worked properly.  This is to minimize bandwidth and avoid latency issues when you grab a slider and move it from 0 to 100 (100 events) in <1 sec (e.g. you really don't want to see the slider move through those same 100 values as the radio processes those commands).  We will typically send a status update to all subscribed clients other than the one that sent the command.

This general idea is sometimes complicated by the fact that often your command will set A which changes B which changes C which may come back and align A.  We do what we can to recognize these kind of situations and prevent them, but this becomes increasingly difficult to catch intuitively as the software becomes more complex (more features, etc).

I've written this particular example up in issue #4254.  We'll look into it and see what we can find.