...

• If the authentication fails or the HW fails to respond to the authentication request then the GBTT server ignores all data on this socket (but does not explicitly close it).

• Any events/topics published without first authenticating will be responded with an errorevent on the info topic (see INFO). Note no other subscribe or publish is allowed during the authentication handshake or the auth will fail, so it’s important not to send anything else until this is completed.

• All topic subscriptions (other than authenticate) will be rejected until the auth sequence is completed.

Hardware Registration

This occurs whenever the initial connection is made to the MQTT cloud server after authentication, this contains the device capabilities only. To obtain actual property states readable topics can be polled.

Registration can also occur when a registration request is received from the server (the sync INFO topic “register” command).

• Once authenticated, the HW sends Gumband registration event to the Cloud Server and Exhibit Server at the topic: <hardware_id>/registration

• Registration events should be logged on the server side

• Registration events have an initial JSON message body identifying the device and the total number of peripherals, followed by individual registration messages for each property of every peripheral. Outline below:

...

{
  "hardwareId": ##,
  "peripheral": "lamp", 
  "property": "power",
  "order": ##,
  "numProperties": ##,
  "type": "xxxxx",
  "length": 1,
  "settable": true,
  "gettable": true,
  "hidehidden": true,
  "info":"Mouse Over Text"
}

...

Note:

1. For Debug only

2. Should be implemented on every connection but only required if the hardware does not already have a saved exhibit server address or if the address has changed

3. If the hardware already holds an exhibit address this will happen in parallel with the master connection

Exhibit Registration

...

...

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.

• If the cloud wants read the status of specific peripheral properties it can then poll all readable properties: <hardware_id>/{peripheral_name}/{property_name}/get

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

...