Gumband needs some way to make sure its knowledge of peripheral properties are up to date if the Gumband server or MQTT go down at any point and publication messages are missed. In these cases, a SYNC request will be made to each out of date board as soon as the server comes back up. 

...

Sync topic: <hardware_id>/sync

...

Immediately after registration every Gumband Hardware device subscribes to this sync topic so should always be ready to receive it.

...

In response to a sync topic the hardware will issue a registration and resubscribe to all topics.

...

INFO Messages

Gumband Cloud Server needs a way to signal each hardware device to send simple control commands. In this case, the information is published to the device INFO topic to which each device subscribes first (before publishing its initial authentication/registration). The INFO topic is also used during the initial handshake to share the exhibit broker host details.

...

...

{
  "hardwareId": "<ID>""
  "uptime": "######",
  "exhibitIP": "<IP_ADDR>" 
  "exhibitState": "1/0/-1"
  "Temptemp": "##.##"
  "Voltagevoltage": "##.##"
}

• Board metrics

  • Uptime - Time in minutes since last reboot

  • Exhibit IP - The exhibit server IP currently saved on the hardware

  • Exhibit State - The state of the connection from the exhibit hardware to the exhibit server (0 = No connection, 1 = Connection, -1 = Not Set)

  • Temperature - Hardware temperature in degrees C (this is actually the Die temp for most current hardware)

  • Voltage - System supply voltage in V

• The time of the last heartbeat should be loggedis displayed on the “Overview” page under “Last Updated”

Logs

• Gumband debug, error and log messages are published to the Cloud Server at the topic:

  • <hardware_id>/log/debug

  • <hardware_id>/log/error

  • And should have the message body:

...

{
  "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}/set

  Reading/Polling properties

  For every property

• Data sent to this endpoint will be received by the gumband hardware

  is subscribed to:

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

• Note that 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.

The Exhibit 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}

Dynamic Hardware ID

Note: This is a suggested method to address a potential issue - this 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

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

Data flow = Gumband -> Cloud Server -> Hardware

Topic = <mac_address>/new-hardware-id

{
  "hardwareId": "HARDWARE_ID"
}

• 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}/get

• See more SDK-Hardware Interface Notes

Property Data Packet

...