In order to enable or disable working with components (e.g creating, destroying, transferring data, etc.), a device needs to declare its intention by providing information about every distinct component type. This functionality is available through several methods - a "set types" request, used for adding and/or removing Control Unit types to/from a device, a "get types" request - a helper method for getting currently available component types in the scope of the device, and a "delete type" request - another helper method with trimmed down payload, used only for removing Control Unit types from the scope of the device.

Set Types

Request

Topic

Payload

• "token" - this field is mandatory and is part of the security concept for the messaging protocol. For more information check the Security section in the MQTT Device Management Model page.

• "requestId" and "needAck" - these fields are required if:

  • message delivery acknowledgment is required;

  • confirmation of successful request is required (success is defined as an absence of error);

  • data is expected as a result of the request;

    Note that if the fields are omitted no response of any kind will be sent by the backend and if an error has occurred the device won't be notified of it.

• "sessionId" - this field is optional and is used for session-based communication - for more information see the Session Management page.

• "resetOld" - this field is optional and can be used for deleting all existing Control Unit types in the scope of the device.

• "cuInfos" - this field is mandatory and must contain an array of objects with the following fields:

  • "eventType" - this field is mandatory and must be either "CU_TYPE_APPEARED" or "CU_TYPE_DISAPPEARED"

  • "cuType" - this field is mandatory

  • "cuVersion" - this field is mandatory

  • "isAbstract" - this field is mandatory and should be set to true if the component type is abstract supertype

    Each object in the array should contain the information of a distinct Control Unit type, i.e. distinct type - version combination.

Response

Topic

Payload

• "requestId" - this field will be included only if it was present in the request message and its value will match the value sent with the request.

• "error" - this field will be included only if an error occurred during the fulfilling of the request. Note that if the field is present, the payload will not contain any other fields, except for "requestId".

• "types" - this field will always be included and it will contain an array of component types without provided Metadata, i.e. Metadata must be provided (see Metadata) before interaction of any kind is possible with components of that type.

Get Types

Request

Topic

Payload

• "token" - this field is mandatory and is part of the security concept for the messaging protocol. For more information check the Security section in the MQTT Device Management Model page.

• "requestId" and "needAck" - these fields are required if:

  • message delivery acknowledgment is required;

  • confirmation of successful request is required (success is defined as an absence of error);

  • data is expected as a result of the request;

    Note that if the fields are omitted no response of any kind will be sent by the backend and if an error has occurred the device won't be notified of it.

Response

Topic

Payload

• "requestId" - this field will be included only if it was present in the request message and its value will match the value sent with the request.

• "error" - this field will be included only if an error occurred during the fulfilling of the request. Note that if the field is present, the payload will not contain any other fields, except for "requestId".

• "typeVersions" - this field will always be included and will contain the currently available component types with all their versions in the scope of the device. Note that this field does not hold any information about provided Metadata for the components, i.e. component types without provided Metadata but added to the device (via "set types" with "CU_TYPE_APPEARED" event) will still be listed here.

Delete Type

Request

Topic

Payload

• "token" - this field is mandatory and is part of the security concept for the messaging protocol. For more information check the Security section in the MQTT Device Management Model page.

• "requestId" and "needAck" - these fields are required if:

  • message delivery acknowledgment is required;

  • confirmation of successful request is required (success is defined as an absence of error);

  • data is expected as a result of the request;

    Note that if the fields are omitted no response of any kind will be sent by the backend and if an error has occurred the device won't be notified of it.

• "sessionId" - this field is optional and is used for session-based communication - for more information see the Session Management page.

Response

Topic

Payload

• "requestId" - this field will be included only if it was present in the request message and its value will match the value sent with the request.

• "error" - this field will be included only if an error occurred during the fulfilling of the request. Note that if the field is present, the payload will not contain any other fields, except for "requestId".