1.9.0

New Features

• The Mongo DB based registry now supports enforcement of registration limits configured at the tenant level.
  In particular, the maximum number of devices and the maximum number of credentials per device can be set in
  a tenant's registration-limits property. Please refer to the Mongo DB User Guide for details.
• Hono now sends a device provisioning notification when a device or a gateway is successfully auto-provisioned.
• Northbound applications sending request/response Command & Control messages via Kafka will now receive
  a notification about a failed command delivery via a command response message. See the
  Command & Control API for Kafka for details.
• The Mongo DB based device registry implementation now supports transparent (symmetric) encryption of Pre-Shared Key
  secrets. Please refer to the user guide for details regarding configuration.

Fixes & Enhancements

• The value of the properties auto-provisioned and auto-provisioning-notification-sent had always been false when
  retrieving device registration information using the MongoDB based registry implementation. This has been fixed.
• The LoRA protocol adapter will now skip registering itself for receiving commands for a given gateway device if
  that gateway device has no command endpoint defined. The adapter will now also free command consumer resources when
  the idle timeout of the corresponding tenant (configured via the hono.lora.tenantIdleTimeout property) has elapsed
  and the tenant is already removed or disabled.
• The device registry implementations have already supported the limitation of the body size of requests to the
  /tenants and /credentials resources of the HTTP based Device Registration Management API.
  However, the admin guides did not cover the corresponding HONO_REGISTRY_HTTP_MAXPAYLOADSIZE configuration variable
  yet. The /devices resources have been added to the scope of the feature and the admin guides have been amended
  accordingly.
• The protocol adapters now invoke the set last known gateway Command Router service operation a lot less frequently,
  reducing the load on the Command Router component if gateways send messages on behalf of devices at a high rate.
  The last known gateway entry for a device is now set with a delay of at most 400ms as part of a batch request.
• The keyStorePassword and trustStorePassword properties of the Hono clients now also support specifying a file
  to read the password from. If the property value starts with file: then the value after the prefix is interpreted as
  as the path to a file to read the password from.
• The registry implementations failed to reject a request to update a device's empty set of credentials, e.g. right
  after the device has been created, if the request contained a secret having an ID. In fact, the registry
  implementations would have accepted such a request even if the secrets did not contain a password/key/etc at all
  but only the identifier. This has been fixed.
• A potential issue processing Command & Control messages from a Kafka cluster while Command Router instances are
  getting stopped or started has been fixed.
• The rate at which the Command Router component handles Command & Control messages from a Kafka cluster is now
  limited to prevent potential memory issues and reduce the load on dependent services. The limit value is adopted from
  the configured max.poll.records Kafka consumer configuration value.
• The default properties of the Hono CLI tool have been updated to match typical Hono installations. It provides now
  3 types of profiles that need to be combined: 1. select the "mode": receiver or command; 2. select the "target":
  sandbox or local (aims for deployment in Minikube but works for every deployment of the Helm chart); 3. select the
  "messaging-type": kafka (if not set, it defaults to AMQP-based messaging). For details refer to the file
  application.yml of the CLI module.

Deprecations

• The file based device registry implementation has been deprecated and will be removed in a future version of Hono.
  Please use the Mongo DB or JDBC based registry implementations instead. The JDBC based registry can be configured
  to use an H2 database in either embedded or in-memory mode. The former can be used to persist data to the local
  file system while the latter keeps all data in memory only.
• The MongoDB based registry implementation no longer supports the configuration variables for disabling modification
  of existing data. In real life deployments this feature has no meaning because write access to data will need to
  be authorized more explicitly anyway, e.g. at the tenant level.

API Changes

• The client classes used by the protocol adapters for accessing the device registry, the Command Router
  and the south bound C&C APIs have been reorganized into dedicated modules.
  In particular, the adapter, adapter-amqp and adapter-kafka modules have been resolved into modules
  command, command-amqp, command-kafka, registry, registry-amqp, telemetry, telemetry-amqp and
  telemetry-kafka. This allows Hono's components to define more specific dependencies on client classes
  that they require. This change should have no effect on application clients.
• The set last known gateway Command Router API operation has been extended to also support setting multiple
  values in one request.

End of life

• The Maven profiles for compiling in support for exporting metrics to Graphite and InfluxDB have been removed.