Initializing the connection and polling for Updates

After establishing a WiFi connection, as described in the first part, the communication with the camera needs to be initialized. This post describes how you can obtain all necessary cookies and keep property data in sync by polling for updates.

The Canon EOS C100 II requires certain cookies as part of the request headers for the communication to work. The acid cookie is the most important since it is comparable to a session id. In addition, the productId and brlang cookies are a requirement for the getUpdate endpoint.

acid      = 2ee;    // random session id
productId = VKIX00; // product id
brlang    = 0;      // numeric language code

To get hold of the values, perform a login followed by a getDeviceInfo request.

The login endpoint is the only endpoint that does not require any cookies. However, you need to be aware that only one client can be connected simultaneously, and there is a 30-second cooldown between sessions.

Set-Cookie: acid=2ee; path=/

{ "res": "ok" }

In the example above, the acid cookie has the value 2ee, which we need to save for future requests.

To retrieve the product id and language code from the camera, you can perform a getDeviceInfo request. Besides other fields, its response body contains the properties productId and lang, which is some kind of numeric language field.

Cookie: acid=2ee;

{
  "res": "ok",
  "modelName": "",
  "manufacturer": "",
  "serialNum": "",
  "lang": 0,
  "mode": 1,
  "productId": "VKIX00"
}

As you can see, the header uses the acid cookie obtained from the login request. According to the getDeviceInfo response body, we can add productId=VKIX00 and brlang=0 to our client cookies.

Now that we have acquired all necessary cookies, we can continue exploring the Browser Remote API’s endpoints.

When controlling the camera through the Browser Remote API, you can still change settings directly on the camera, like adjusting the shutter angle. Therefore, we must poll for updates periodically to keep the properties between our client and the camera in sync.

For this purpose, we can use the getcurprop endpoint, which takes one query parameter seq. This parameter is also part of the response body and acts as an event sequence counter, meaning each time an event occurs, the response body contains its incremented value for the next request.

The initial getcurprop request with seq set to 0 is a treasure chest for reverse engineering the Browser Remote API since it contains the state of all properties the camera reports.

Cookie: acid=2ee; productId=VKIX00; brlang=0;

{
  "res": "ok",
  "seq": 1,
  "mode": "Ctrl",
  "rec": "Stby",
  "com": 1,
  "batt": 4,
  "tc": "02:29:22:14",
  "cbtn": "f0i1af4ai1fm1",
  "camid": "C100II  ",
  "Ocf": {
      "sel": "A",
      "artime": 130,
      "brtime": -1
  },
  "Owbm": {
      "pv": "Kelvin",
      "en": 1
  },
  "Owbv": {
      "pv": "3800",
      "en": 1
  },
  "Oav": {
      "pv": "1.8",
      "en": 1
  },
  "Ossm": {
      "pv": "angle",
      "en": 1
  },
  "Ossv": {
      "pv": "180.00",
      "en": 1
  },
  "Ogcm": {
      "pv": "iso",
      "en": 1
  },
  "Ogcv": {
      "pv": "[850]",
      "en": 1
  },
  "Oam": {
      "pv": "Manual",
      "en": 0
  },
  "nd": 2,
  "fframe": "contin",
  "pushai": "stop",
  "aes": "non",
  "aesbtn": "PM",
  "faceficon": "off"
}

When analyzing the JSON data, we can make sense of lots of properties just by their name or value. However, for the non-obvious ones, the best bet for finding out their meanings is changing settings on the camera and polling for subsequent event data.

For subsequent requests, use the seq number the camera reported in the previous update response, e. g. /api/cam/getcurprop?seq=1. Compared to the initial response, subsequent responses only contain the properties that changed.

As a bonus, here are two more response bodies for reference:

{
  "res": "ok",
  "seq": 1,
  "com": 1
}

When no value has changed, the response does not contain any property data, and the seq counter remains the same.

 {
   "res": "ok",
   "seq": 2,
   "com": 2,
   "batt": 3,
   "cbtn": "f0i1af4ai1fm1",
   "Oav": {
     "pv": "2.0",
     "en": 1
   },
   "Oam": {
     "pv": "Manual",
     "en": 0
   }
 }

This response body informs that the battery level batt dropped to 3 and the aperture value Oav changed to 2.0. Additionally, the seq counter changed to 2, which becomes the seq query parameter for the following getcurprop request.

Here is an overview of the getcurprop response’s properties, including the values I have come across. So, be aware that this model description is still a work in progress due to the nature of reverse engineering.