Endpoint for data collection start/stop

[FabrizioMoggio]

collecting data to measure the energy performance is a task in the Network that could be not efficient to always keep alive if there is no need for information.

A new Endpoint to start and stop the the measures could be useful.

With this Endpoint the data collection starts only after an explicit request from the API Consumer.

[FabrizioMoggio]

proposal: consider this feature in the Sync26 release

[FabrizioMoggio]

I'm wondering, I don't see this feature as a possible Intent from the API Consumer. It would just complicate the API Logic and its usability. It is related to the costs of collecting the data. This costs maybe could be exposed to the Customer. So we have two scenarios:

1. The costs are not exposed to the customer: the new endpoint is not required
2. The costs are exposed to the customer: isn't it better for the API Consumer to just subscribe or unsubscribe the API rather then implementing a logic that considers starting and stopping the data collection forcing everyone to manage the the lacks of data in the possible requests.

[FabrizioMoggio]

In this context it is important to clearly separate business-level responsibilities from API runtime logic.

At the business level, the API subscription lifecycle (activation, renewal, cancellation) is managed through the developer portal. This layer governs contractual aspects such as billing, access rights, and service entitlement. Decisions related to cost exposure or whether data collection should be economically justified belong to this layer.

At the API logic level, the system is responsible only for processing requests and delivering energy or carbon footprint calculations according to the defined intents. It should not expose internal operational controls such as starting or pausing measurement collection, as these concern infrastructure and cost management rather than functional service capabilities.

Maintaining this separation ensures a cleaner API design, avoids unnecessary complexity for API consumers, and keeps infrastructure management concerns decoupled from functional service behavior.

[FabrizioMoggio]

Conclusion: this fetaure is not needed