1.10.0

1.10.0

New Features

• The JDBC and Mongo DB based registry implementations now support configuration of a regular expression that should
  be used to validate authentication identifiers (user names) of hashed-password credentials. Please refer to the
  corresponding Admin Guides for details.
• The Command Router component is now able to determine the state of protocol adapter instances, preventing command
  & control messages to be sent to already terminated adapter instances. Hono Kubernetes deployments where not all
  protocol adapters are part of the same Kubernetes cluster and namespace that the Command Router component is in,
  need to disable this feature via the hono.commandRouter.svc.kubernetesBasedAdapterInstanceStatusServiceEnabled
  property. Please refer to the Command Router Admin Guide for details.
• The authentication provider used to guard access to the Mongo DB based registry implementation's HTTP endpoint
  can now be configured using environment variables. Please refer to the registry's Admin Guide for details.
• The Registry Management API has been extended with an operation to delete all devices (including credentials) of a
  tenant. Both the Mongo DB and the JDBC based registry implementations support this operation.
• The protocol adapters and the Command Router component now by default report a set of metrics concerning the clients
  used for sending and receiving messages via Kafka. Please refer to the Hono Kafka Client Configuration Guide for
  additional information.

Fixes & Enhancements

• The Quarkus based variants of Hono's components now support configuring the Hot Rod client with a key and/or
  trust store in order to enable TLS secured connections to Infinispan servers and to authenticate using a
  client certificate.
• The MongoDB based DeviceManagementService erroneously removed the original device registration when trying to
  register a new device using the existing device's identifier. This has been fixed.
• The Mongo DB based registry implementation now uses a proper DB index to find credentials by type and authentication
  ID. This will speed up query execution significantly when there are a lot of devices registered for a tenant.
• The JDBC based device registry's get Credentials operation used by the protocol adapters now also supports
  matching credentials against a given client context.
• The device registry implementations did not return a JSON object in a response to a failed request as specified
  in the Device Registry Management API. This has been fixed.
• The MongoDB based registry erroneously rejected requests that would result in multiple tenants having an empty
  set of trusted CAs. This has been fixed.
• The ttl header in downstream messages with Kafka had been set in seconds instead of milliseconds, as defined
  by the API specification. This has been fixed.

1.9.1

Fixes & Enhancements

• The Quarkus based variants of Hono's components now support configuring the Hot Rod client with a key and/or
  trust store in order to enable TLS secured connections to Infinispan servers and to authenticate using a
  client certificate.
• The MongoDB based DeviceManagementService erroneously removed the original device registration when trying to
  register a new device using the existing device's identifier. This has been fixed.
• The Mongo DB based registry implementation now uses a proper DB index to find credentials by type and authentication
  ID. This will speed up query execution significantly when there are a lot of devices registered for a tenant.
• The JDBC based device registry's get Credentials operation used by the protocol adapters now also supports
  matching credentials against a given client context.
• The device registry implementations did not return a JSON object in a response to a failed request as specified
  in the Device Registry Management API. This has been fixed.
• The tracing output in error scenarios has been improved in the Mongo DB based device registry.
• The MongoDB based registry erroneously rejected requests that would result in multiple tenants having an empty
  set of trusted CAs. This has been fixed.

1.8.3

Fixes & Enhancements

• The Quarkus based variants of Hono's components now support configuring the Hot Rod client with a key and/or
  trust store in order to enable TLS secured connections to Infinispan servers and to authenticate using a
  client certificate.
• The Mongo DB based registry implementation now uses a proper DB index to find credentials by type and authentication
  ID. This will speed up query execution significantly when there are a lot of devices registered for a tenant.
• The MongoDB based registry erroneously rejected requests that would result in multiple tenants having an empty
  set of trusted CAs. This has been fixed.

1.8.2

Fixes & Enhancements

• The MQTT adapter didn't close the CONNECT tracing span and didn't report metrics on failed connection attempts. This
  has been fixed.
• 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.

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.

1.8.1

Fixes & Enhancements

• Letting the trace sampling settings of the Hono components be defined via sampling strategies served by the Jaeger
  Collector did not work for components using Quarkus native images. This has been fixed.
• Command messages with no payload could not be sent to an MQTT device. This has been fixed.
• The value of the properties auto-provisioned and auto-provisioning-notification-sent are always false while
  retrieving device registration information using the MongoDB based registry implementation. This has been fixed now.
• The Command Router service could have gotten into a state of very high CPU utilization when protocol
  adapters submitted non-existing tenant IDs for which command routing should be re-enabled. This has been fixed.
• The LoRA protocol adapter will now 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.

1.7.4

Fixes & Enhancements

• Letting the trace sampling settings of the Hono components be defined via sampling strategies served by the Jaeger
  Collector did not work for components using Quarkus native images. This has been fixed.
• Command messages with no payload could not be sent to an MQTT device. This has been fixed.
• The value of the properties auto-provisioned and auto-provisioning-notification-sent are always false while
  retrieving device registration information using the MongoDB based registry implementation. This has been fixed now.
• The Command Router service could have gotten into a state of very high CPU utilization when protocol
  adapters submitted non-existing tenant IDs for which command routing should be re-enabled. This has been fixed.
• The LoRA protocol adapter will now 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.

1.8.0

New Features

• The CoAP adapter now supports authentication of client certificates using ECDSA based cipher suites.
• The JDBC-based device registry implementation now supports the automatic creation of the database schema, both for
  device registration and tenant data. This is especially useful for experimental setups where an embedded database,
  such as H2 provides, is sufficient. To enable
  automatic schema creation, activate the application profile create-schema.
• Hono's components now support configuration of supported TLS cipher suites. The cipher suites can be configured
  separately for both the endpoints exposed by the components as well as the clients used for accessing service
  endpoints exposed by other components. Please refer to the corresponding admin guides for details regarding the
  corresponding configuration variables.
• Hono now supports auto-provisioning of gateways. For more information please refer to the
  Gateway Provisioning concept and to the Device Registry Management API on how to configure a tenant's trusted
  CA authority for that.
• Now the tenant configuration supports a new property namely auto-provisioning-device-id-template in it's trusted CA
  section. During auto-provisioning of devices and gateways, the device identifier is generated based on this template
  and used for the device registration. For more information please refer to the Device Provisioning concept and to the
  Device Registry Management API on how to configure a tenant's trusted CA authority for that.
• The Hono CLI supports now Kafka as a messaging system. Please refer to the module's
  README file for examples of using the CLI to receive events and
  telemetry data and send commands.
• The example business application supports now Kafka as a messaging system. Please refer to the
  Developer Guide for details.

Fixes & Enhancements

• The CoAP adapter did not correctly track the time it took to forward a command message to a device. This has been fixed.
• Sending requests using the Hono AMQP request-response client erroneously increased the hono.downstream.timeout metric.
  This has been fixed.
• Support for uplink messages from the Embedded LNS on MultiTech gateways.
• The hono.connections.attempts metric has been extended with a cipher-suite tag which contains the name of the
  cipher suite that is used in a device's attempt to establish a TLS based connection to an adapter.
• The Quarkus based Command Router native image failed to start an embedded cache that was configured to persist data
  to the local file system. This has been fixed.
• The delivery of a command message sent to an AMQP device potentially didn't get settled if the connection to the
  AMQP device got disconnected. This has been fixed.
• The Prometheus based resource limit checks' performance has been improved. This should result in considerably less
  load on the Prometheus server when failing over all of a crashed/stopped adapter instance's device connections.
• The Hono component container images now contain the Gson library which is required by the Jaeger client for
  processing sampling strategy configuration retrieved from the Jaeger Collector.
• The Kafka based implementation of the north bound application client
  org.eclipse.hono.application.client.kafka.impl.KafkaApplicationClientImpl now supports sending commands and
  receiving responses in a request/response fashion.

Deprecations

• The org.eclipse.hono.client.ApplicationClientFactory, org.eclipse.hono.client.AsyncCommandClient and
  org.eclipse.hono.client.CommandClient classes have been deprecated. Client code should use
  org.eclipse.hono.application.client.ApplicationClient instead.

1.7.3

Fixes & Enhancements

• The Hono component container images now contain the Gson library which is required by the Jaeger client for
  processing sampling strategy configuration retrieved from the Jaeger Collector.

1.7.2

Fixes & Enhancements

• The Quarkus based Command Router native image failed to start an embedded cache that was configured to persist data
  to the local file system. This has been fixed.
• The delivery of a command message sent to an AMQP device potentially didn't get settled if the connection to the
  AMQP device got disconnected. This has been fixed.