Segment Discovery Message

glp/0/:/ev/discovery/segment


The edge server publishes a discovery message to the outgoing segment discovery topic defined with the edge server's bridge connection glp/0/:/ev/discovery/segment.  The edge server publishes this discovery message periodically, for example every 15 minutes, when it is unprovisioned.  While provisioned, the edge server does not publish discovery messages.

A local CMS Lite may provision the segment and assign an automatic segment identifier. When this occurs, the edge server continues with the normal CMS discovery process, but reports its locally assigned segment identifier.  The CMS must adopt this identifier when it provisions the segment.

Properties

The segment discovery message content is a JSON encoded segment discovery object with the following properties:

Field Name

Type

Description

macid

string

The designated MACID

Example: "AF-E0-D3-01-02-03"

sid

string

The currently assigned segment identifier, if any. Otherwise undefined.  

A local CMS Lite may provision the segment and assign an automatic segment identifier. When this occurs, the edge server continues with the normal CMS discovery process, but reports its locally assigned segment identifier. The CMS must adopt this identifier when it provisions the segment.

Example: “AF-E0-D3-01-02-03”

product

string

Edge server’s short product name, if known.

Example: "EnOcean XYZ-5678"

version

string

Edge server's version number.

Example: "1.30.045"

loc

object

Edge server's location, if known. Set to null if not known. See Location Object for a description of the loc property.

Example:                                                                                       

    {   /* location: */
       desc: "pole 23S",
       lat: 51.5059,
       lng: -0.33302
    }

error

string

Most recent discovery error.

accessobject

(Optional) Access request.

A provisioned segment has read access to its own request channel, write access to its feedback and event channels, and read/write access to its binary channel by default.

A segment can request access permissions to other segments with this access request object. This is used by IAP/MQ cloud applications or tools that import system configuration data from other sources, affecting one or more existing segments.

Every key within the access request topic is an IAP/MQ topic filter, with a value of:

rto request read access                                                          
wto request write access
rw  to request read and write access

Wildcards are permitted, but it is generally best to request specific permissions. The CMS or the human user who approves the access request is more likely to permit specific requests than a request for read and write access to glp/# or glp/0/+/.

Access permission requests are either granted in full or denied in full. When denied, the CMS does not provision the segment. When granted, the CMS provisions the segment.

From the segment’s perspective, access permission is always granted if the segment is being provisioned.

Example:                                                                                       

{   /* access request obj */
  “glp/0/T5j6s/rq/#”: “w”,
  “glp/0/T5j6s/ev/#”: “r”,
  “glp/0/T5j6s/fb/#”: “r”,
  “glp/0/T5j6s/bin/#”: “rw”
}

protocolslist

(Optional) Supported protocols.

The list of protocols that the edge server can support to connect to the CMS broker. The possible values are:

mqttplain MQTT                                                                  
mqtts        secure MQTT
wsMQTT over plain WebSocket
wssMQTT over secure WebSocket

This allows the CMS to select the best choice when provisioning the segment, and prevents the CMS from provisioning the segment with access credentials that it may not support.

If the segment’s list of supported protocols does not include at least one acceptable to the CMS, errors can result and the segment may not be provisioned.