Add hawkBit firmware management extension

[dominiquekleeven]

Closes #33

---

Adds a hawkBit firmware extension that connects OpenRemote Manager to the hawkBit Management API, exposes firmware management endpoints, and syncs selected OpenRemote assets as hawkBit targets.

Core Functionality

• Registers firmware meta items for marking assets as firmware targets (FIRMWARE_TARGET) and syncing selected attributes as hawkBit metadata (FIRMWARE_METADATA).
  • FIRMWARE_TARGET causes the asset to be synced as a target to hawkBit.
  • FIRMWARE_METADATA causes the attribute and its value to be synced as metadata to the target within hawkBit. This enables hawkBit to use attribute-aware target filters for grouping purposes.
• Creates, updates, and deletes hawkBit targets in response to OpenRemote asset events.
• Updates OpenRemote firmware target info attributes with hawkBit controllerId and securityToken.
• Proxies firmware management endpoints for targets, software modules, distribution sets, target filters, and rollouts.
• Adds OpenRemote read/write admin authorization and configured-realm access checks around firmware endpoints.
• Adds artifact upload support for hawkBit software modules. (required a bit of a workaround, but streams the uploaded file to the hawkBit endpoint).

Core Files

• HawkbitFirmwareService.java: Starts the integration, configures the hawkBit client, registers API resources, and handles asset/attribute sync.
• HawkbitResponseProxy.java: Copies hawkBit responses back through OpenRemote while preserving status, body, and media type.
• manager/hawkbit/*Client.java: RESTEasy clients for hawkBit Management API resources.
• manager/resource/*ResourceImpl.java: OpenRemote API resource implementations that authorize requests and proxy them to hawkBit.
• model/resource/*Resource.java: Public OpenRemote firmware endpoint definitions and role requirements.
• FirmwareMetaItemType.java: Defines firmwareTarget and firmwareMetadata meta items.
• FirmwareModelProvider.java: Registers firmware meta items with the OpenRemote model.
• README.md: Documents setup, limitations, API coverage, deployment examples, and proxy configuration.

Caveats

• The integration is currently limited to a single OpenRemote realm configured by HAWKBIT_REALM.
• This extension is intended to be used with the companion hawkBit/OpenRemote management UI service: https://github.com/openremote/service-hawkbit-ui

Testing

• Added mock based testing for checking whether asset events / attribute events trigger the appropriate 'client' call, e.g. sync behaviour.
• Added simple tests for the proxy behaviour.

Notes

• The large changed file count and addition count is mostly caused by license headers + model interfaces. The actual logic and behaviour is fairly minimal in terms of complexity/LoC.
• Not all hawkBit management API endpoints are integrated, only those who are deemed necessary to enable basic firmware/OTA management.

[dominiquekleeven]

Would be nice to get this merged fairly quickly as I want to deploy the extension to staging for a custom project. Happy to go through the additions/changes if needed.

[wborn]

This PR is being reviewed with AI first.

The overall extension structure and hawkBit integration look good. No definite blocking issues were identified, but there are a few lifecycle, security, and documentation points worth clarifying.

Inline comments contain the details.

[wborn]

The security-token handling and firmwareTarget validation/documentation concerns from the earlier review look resolved.

One lifecycle issue remains in the existing review thread: removing the firmware meta item is documented as non-destructive, while deleting the corresponding OpenRemote asset or attribute should still remove the hawkBit counterpart. The current implementation does not preserve that cleanup behavior after the meta item has already been removed.

The event-ordering concern noted inline is worth considering as well, but it is not treated as blocking without evidence that the race occurs in normal operation.

With the lifecycle issue addressed, the rest of the changes look good.

This review was AI-assisted.

[wborn]

Suggested change

	HawkbitFirmwareService.java Starts the integration, syncs assets and registers API resources
	HawkbitResponseProxy.java Proxies hawkBit client responses for OpenRemote APIs
	HawkbitFirmwareService.java Starts the integration, syncs assets and registers API resources
	HawkbitResponseProxy.java Proxies hawkBit client responses for OpenRemote APIs

[wborn]

Suggested change

	HawkbitDistributionSetTypesClient.java RESTEasy client proxy for distribution set types
	HawkbitSoftwareModuleTypesClient.java RESTEasy client proxy for software module types
	HawkbitDistributionSetTypesClient.java RESTEasy client proxy for distribution set types
	HawkbitSoftwareModuleTypesClient.java RESTEasy client proxy for software module types

[wborn]

The demo is useful, but this has grown into a fairly substantial integration environment rather than an example specific to the extension. It includes a complete Compose stack, service-account bootstrapping, device simulation, fleet/rollout scenarios, and even a patched service-hawkbit-ui server.

Would it make sense to move the full demo into a dedicated demo/custom-project repository and keep this repository focused on the extension implementation, tests, and concise configuration/documentation? A separate demo repository could also manage and pin compatible OpenRemote, hawkBit, and UI versions independently.

This review was AI-assisted.