The smallest module — properties and elements

Example module: hello.

A module’s data model is a two-level hierarchy:

• a property (PropertyMulti) — a named group, with a label, a permission, and a position in the display tree;
• which contains one or more elements (ElementBase and its derivatives: ElementBool, ElementString, ElementInt…) — each an individually typed value.

This is an important difference from INDI, where a “vector” (the equivalent of a property) only contains elements of a single type. An OST property can freely mix types — see The type catalog.

Declaring a property in JSON

{
"p":{
  "hello": {
    "label": "Hello",
    "permission": 0,
    "devcat": "",
    "group": "",
    "order": "1",
    "hasprofile": false,
    "e": {
      "message": {
        "type": "string",
        "label": "Message",
        "order": "1",
        "value": "Hello, world!"
      }
    }
  }
}
}

• permission: 0 = read-only, 1 = write-only (never actually used — see below), 2 = read/write.
• devcat/group: position in the display tree on the client side — top level and sub-level. Left empty here, since a single property needs no grouping at all. See Server-side updates for their practical use, and Creating properties dynamically for the naming pitfall between JSON and C++.
• hasprofile: whether this property can be saved/loaded as a named profile — see Profiles.
• e: the property’s elements, keyed by name. Each element has at least type, label, order.

The module’s constructor has nothing else to do but load this file:

Hello::Hello(QString name, QString label, QString profile, QVariantMap availableModuleLibs)
    : Basemodule(name, label, profile, availableModuleLibs)
{
    Q_INIT_RESOURCE(hello);
    loadOstPropertiesFromFile(":hello.json");
}

And since this property is read-only and the module has no action to handle, Hello doesn’t need to override any method: the default (empty) implementation of onExternalEvent() is enough.