Clarify reset behavior for `/iolink/v2/gateway/reset` endpoint

[thbauer-pepperl-fuchs]

I would suggest improving the description of the /iolink/v2/gateway/reset endpoint to better clarify what exactly
happens during a reset operation.

Current description:

Invoke a reset of the IO-Link Gateway.
This may reset all configuration data and interrupt all communications channels.
It is recommended to log this within the EventLog.

From my point of view, this description is somewhat ambiguous. I would appreciate more specific documentation about what
exactly gets reset when this endpoint is invoked.

Suggested clarifications:

From my point of view, the possible reactions in the device could include:

• Just power cycle the IO-Link devices
• Reset all endpoints to the default value in the OpenAPI
• Remove all given IODDs from the Master
• Reset all configured IO-Link values like parameters
• Reset also the Network config to factory defaults (Attention: loss of network connection possible, reboot later?)
• Reset the system log, events to delete persistence (Attention: affects security and traceability)
• Reset MQTT config

I would recommend specifying which of these actions are actually performed, or if there are different reset
levels/options available. This would help developers understand the exact behavior and potential side effects when using
this endpoint.

Alternative:

Enhancing the /iolink/v2/gateway/reset endpoint with the following approach:

1. Add GET method to discover available reset options

GET /iolink/v2/gateway/reset

This would return an array of available reset options that the device supports:

[
  "iodds",
  "masters",
  "events",
  "mqtt",
  "network"
]

2. Enhance POST method to accept selective reset

POST /iolink/v2/gateway/reset

I would recommend allowing the POST request to accept a JSON object specifying which components should be reset:

{
  "iodds": true,
  "masters": false,
  "events": false,
  "mqtt": true,
  "network": false
}

This approach would provide several benefits:

• Discoverability: Clients can query available reset options via GET
• Flexibility: Users can selectively reset only specific components
• Safety: Reduces risk of unintended configuration loss or network disconnection
• Backward compatibility: If no body is provided, the endpoint could perform a full reset (current behavior)

I believe this would give developers much better control and understanding of the reset functionality.

[roesekoSICKAG]

As discussed in the WG meeting of 2026-02-04:
Suggestion accepted. @thbauer-pepperl-fuchs please provide a proposal for the next meeting. Will it only delete data (e.g. IODDs) or reset the configuration also to the default values?

[roesekoSICKAG]

As discussed in the WG meeting of 2026-03-16:
Only the description will be adjusted in order to be backward compatible and to minify the changes. Add to description something like "It is recommended to log this within the EventLog after deletion of the log."
The original idea will be postponed to the next release 2.x.x.