Support publishing service telemetry data

[reubenmiller]

Is your feature improvement request related to a problem? Please describe.

If a service health endpoint has been registered to thin-edge.io via the tedge/health/{service_name} endpoint, sending measurements to tedge/measurements/{service_name} should not result in the creation of a child device in Cumulocity.

Describe the solution you'd like

A dedicated MQTT topics which allows services to publish Inventory, Measurements, Events and Alarms. This would allow services to publish additional information about the status of the service, e.g. CPU, RAM usage, additional running meta info (e.g. process ids, run command).

The new topic names could be called.

tedge/health/{service}/measurements
tedge/health/{service}/events
tedge/health/{service}/alarms
tedge/health/{service}/inventory

Describe alternatives you've considered

Alternatively, when the tedge-mapper-c8y received a message on the tedge/measurement/{service_name} topic, it could check if the name has been registered via the tedge/health/{service_name} endpoint, and skip register a new child logic (e.g. skip sending the topic=c8y/s/us payload=101,{service_name},{service_name},thin-edge.io-child

Additional context

Cumulocity IoT has two different smart rest messages which involve the registration/creation of a linked entity.

Type	SmartREST Template ID
Create a child device	101
Create a service	102

Both SmartREST message templates will create a managed object with the given External Identity, however 101 will link the created managed object as a childDevice, where as the 102 message will link the device as a childAddition. The different types of managed object links control how the managed object is treated in the UI (and other api for that matter).

[albinsuresh]

The registration of services has already been done in #2266 and the entity store now has the external ID of the services as well. So, all that is left is to send the telemetry data to that external ID, just like it's done for devices, using their external ID. For example, a measurement for a service with the external ID myDatabaseService would be as follows:

{
    "externalSource":{
        "externalId":"myDatabaseService",
        "type":"c8y_Serial"
    },
    "type": "c8y_TemperatureMeasurement",
    "time": "2023-09-29T17:57:00+05:30",
    "c8y_TemperatureMeasurement": {
        "T": {
            "value": 20,
            "unit": "C"
        }
    }
}

The mechanism to generate payloads like this from a given external_id already exists in the mapper(used already for child devices). The same can be used for services as well.

The rules are the same while using SmartREST as well. Just use the external ID of the service in the topic like c8y/s/us/myDatabaseService for a service on the main device. And similarly for a service on a child device, publish to c8y/s/us/childExternalId/myDatabaseService.

To generate such hierarchical topics for a service the smartrest_publish_topic_for_entity API in the c8y_mapper_ext::converter can be used.

[reubenmiller]

Note: The suggested mqtt api in this ticket is no longer applicable and the new MQTT interface is used instead.

See the system tests included in the following PR:

• send measurement to main/child device services #2335

[gligorisaev]

QA has thoroughly checked the feature and here are the results:

• Test for ticket exists in the test suite.
• tests/RobotFramework/tests/cumulocity/telemetry/child_device_telemetry.robot
• tests/RobotFramework/tests/cumulocity/telemetry/thin-edge_device_telemetry.robot
• QA has tested the bug and could not reproduce it anymore.