Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Controllable exhibit events are structured as "settable" properties

  • The Exhibit Broker should be subscribed to every property exposed in the capabilities registration

    • <hardware_id>/{peripheralName}/{propertyName}

  • Writing to properties

    • For every "settable" property, gumband hardware is subscribed to:

    • <hardware_id>/{peripheralName}/{propertyName}/set

  • Reading from properties

    • For every property the gumband hardware is subscribed to:

    • <hardware_id>/{peripheralName}/{propertyName}/get

    • Note: this callback is intended to initiate a publish to the associated property but ultimately this is handled in user code so implementation is not guaranteed.

  • See more SDK-Hardware Interface Notes

...

Dynamic Hardware ID

Status
colourYellow
titleFUTURE SPEC
- Note: This is a suggested method to address a potential issue - this future specification possibility and is not currently implemented.

If Hardware boots and no hardwareId exists in memory but an auth token exists, Hardware will attempt to assign itself directly to an Exhibit using this process. This can be used to mass-assign Hardware to an Exhibit.

Overview

  • Hardware listens to <mac_address>/new-hardware-id on Cloud Server

  • Hardware publishes hardwareId request to Cloud Server at topic new-hardware-id

  • Gumband uses auth token to lookup Exhibit and generate new Hardware assigned to that Exhibit

  • Gumband publishes hardwareId over Cloud Server at topic <mac_address>/new-hardware-id

  • Hardware can proceed with normal registration flow

Message Outline

...

  • Data flow = Hardware -> Cloud Server -> Gumband

  • Topic = new-hardware-id

Code Block
{
  "mac": "MAC_ADDRESS",
  "auth": "AUTH_TOKEN"
}

  • Data flow = Gumband -> Cloud Server -> Hardware

  • Topic = <mac_address>/new-hardware-id

Code Block
{
  "hardwareId": "HARDWARE_ID"
}