Versions Compared

Key

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

...

Code Block
{
  "text": "<event message text>",
  "value": <event value>
}

Exhibit Events

...

...

Controllable exhibit events are structured as "settable" properties

...

Properties

  • Properties are user defined endpoints that control individual aspects of the application (motor speed, light color, power on/off etc.).

  • Properties are grouped into a specific “Peripherals” which serves only as a hierarchical organizational structure.

Writing Properties

  • Any property with write permissions is a “settable” property.

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

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

    Writing to properties

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

  • Data sent to this endpoint will be received by the gumband hardware and routed to the appropriate callback.

  • The message body is a raw data byte packet (not ASCII or JSON encoded)

Reading Properties

  • Every property is readable or “gettable” however a Publish can be triggered at any time by the user code so this does not need to be polled in normal operation.

  • Gumband hardware will publish property data to the following topic, therefore the GBTT Broker should be subscribed to this topic for every property exposed in the capabilities registration:

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

    Reading from properties
  • For every property the gumband hardware is subscribed to the following topic and the value of a property can be actively requested by publishing to it:

    • <hardware_id>/{peripheralName}/{propertyName}/getNote: this callback is intended

Note

The “get” publish triggers a read callback which is a request to initiate a publish to the associated property but ultimately this callback is handled in user code so implementation is not guaranteed.

Property Data Packet

...

Dynamic Hardware ID

Status
colourYellow
titleFUTURE SPEC
- Note: This is 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"
}