How to use deploymentGroups

DeploymentGroups are created, managed and assigned through Thingsee Open Services API. The responsibility of the management operations are under customer; this can be done from mobile applications (installer application) or from the customer cloud.

What is the best granularity for the groups?

You can estimate the maximum size by thinking how many devices can be updated at once. If you think that all the devices can be under service break without phasing them into separate maintenance slots, then you can put all your devices into a single group. Even though this may sound as an easy solution, we have learned that more group the better as it gives you much more control how the bulk operations are deployed to the live service.

The minimum size of the group is typically defined by an installation location. You can set a single location, e.g. "Haltian HQ" as a group, and then have device bulk operations directed only to that specific group.

The last parameter that may affect your grouping is the data-routing. Thingsee comes as a default with an MQTT broker where the data is published under a topic constructed from a deploymentGroup information. This may help you to build your cloud service as you are able to subscribe to different deploymentGroups thus receiving data from a specific group only. Note that you shouldn’t use this as a dynamic user management or access-control method. You will authenticate to MQTT broker using certificates assigned to a topic level, but the deploymentGroup level is not part of that certificate. Instead we will use deploymentGroup prefix information (see below) to assign certificate-based authentication.

DeploymentGroup (groupId)

DeploymentGroup (groupId) is a logical collection of devices. Every Thingsee device (tuid) belongs to a single deploymentgroup. When the devices are manufactured they are unassigned and available for further assignments. The purpose of a deploymentgroup information is to split the device population into logical groups using the following naming convention

{Thingsee Deployment Prefix} + {Customer Deployment Id}

Thingsee Deployment Prefix

Following Thingsee Deployment Prefixes are available as a default. The prefix is always 6-alpha-characters using 2-alpha identifiers for

{environment} + {country code } + {reserved}

Note that the country-specific identifier and endpoint index is designed to be used in cases where the same customer has a different end-point or cloud-technology per country (or a customer within a country). Thingsee Operations Cloud uses only the prefix to determine the end-point for the data; Customer Deployment Id is ignored by Thingsee Operations Cloud.


  • un unassigned (available for installations)
  • pr production
  • dm demo
  • rd development

Country code


  • reserved for future use (which we never do, but we will still reserve these, just in case)


Prefix Description
unxx00 unassigned devices without any specific information about country
rdxx00 Development devices without any specific information about country
prfi00 Production devices in Finland
pruk00 Production devices in UK
rduk00 Development devices in UK

Customer Deployment Id

This is the part that is fully in your control. Use your own logic to build the id, so that eventually the full groupId becomes something like

  • prfi00haltianhq
  • prfi00northernfinland
  • prus00siliconvalleyoffice

You should keep deploymentGroup name (incl. prefix) in 64 characters or less. Thingsee CLOUD doesn’t enforce any limits for now, but to keep unnecessary data load and bandwidth requirements in minimum, you shouldn’t be too verbose when creating the groups. Someday we may enforce limits through the system.