API Documentation Requests

UPDATE:
NOTE to Community Contributors:
Chris Merck provided this suggestion on 1/20/2020:

ORIGINAL POST:

When ADDING A DEVICE:

  1. Update “type” parameter to include “AC” for air conditioners.
    I tested and this is working (shows in both Android and iOS apps after adding via API), but this parameter option is not listed in documentation – and I expect I just got lucky with my common sense guess working. Also note: the device I added is a placeholder; I do not have an actual A/C unit to test with this

When ADDING A COMMAND:

  1. Provide list of “action” parameters which are available (and any related “argument” values)
    I was able to find TurnOff by querying existing devices and their commands, but PowerOff, PowerToggle, etc were my first common sense guesses and failed due to ‘unknown action’.
  2. Provide list of “icon” slugs
    I was able to find “button_io” by querying existing devices and their commands.
    SIDE NOTE: the “button_io” shows appropriately in Android app with Power label, but only shows as a blank circle in iOS app with no label

When ADDING A SIGNAL:

  1. “bps” seems to be required, at least with IR commands - documentation seems to indicate it has a default value of 40000 if not supplied, but the PUT fails without “bps” defined.
  2. “reps” seems to be required, at least with IR commands - documentation seems to indicate it has a default value of 1 if not supplied, but the PUT fails without “reps” defined.

all testing done 3/7/2019 with BD***** (Snowbird revision) BOND on firmware v 2.5.1-44-g9d5c43d-jacob-uglydb and both Android and iOS apps on v 1.139.0

When ADDING A COMMAND:

  1. Provide a list of other parameters and their respective valid values.
    (e.g., for an action of “StartDimmer”, there is an “action_release” parameter with “Stop” as a valid value for that parameter)

When GETTING LIST OF DEVICES:

  1. Screenshots show curl command mistakenly using -X instead of the correct -H for passing BOND-Token header
1 Like

Is v2/bridge/name (and other elements in v2/bridge/) safe to assume for official and future firmware?
They aren’t (yet) documented in the official spec.
If so, is there an equivalent to bridge and the child elements within v2/ for SBB devices?
(I’ve had to abandon use of my old beta SBB kit for now so it makes it hard for me to check)

1 Like

Thanks for the requests here… we will get some clarifications out!