[
{
	"uri": "https://www.eclipse.org/hono/docs/dev/",
	"title": "Documentation",
	"tags": [],
	"description": "",
	"content": "Documentation The place of Eclipse Hono™ is within an IoT cloud. The goal is simplified device connectivity for Business Applications (or Solutions). It abstracts away the multiple specifics of different device-side connection protocols from a backend application perspective. Hono defines a small set of APIs to communicate in a unified way with very different devices, whether they use, for example, connection-oriented protocols such as MQTT and AMQP 1.0 or stateless protocols such as HTTP. As a result, Hono frees developers of IoT backend applications from the need to know device protocols in detail and allows them to add or change connection protocols without having to modify their applications.\nFor each supported connection protocol, Hono contains a microservice called Protocol Adapter, which maps the connection protocol of the device to Hono\u0026rsquo;s APIs. Those APIs are offered via a central messaging system. Each of the messaging APIs has a so-called northbound API for the Business Applications. The southbound APIs are used by protocol adapters to forward messages from devices to the applications and vice versa. Messages flowing from devices to Business Applications are called downstream messages since this is the primary communication direction in practice. The other communication direction is called upstream. These are messages sent from a Business Application to a device via the Command \u0026amp; Control API.\nThe APIs defined by Hono for messaging are Telemetry, Event, and Command \u0026amp; Control. The Telemetry API is intended to send arbitrary data, e.g. from sensors, downstream. Events are downstream messages as well, intended less frequent but more important messages. Depending on the provided messaging network, events can be persisted and delivered later on if an application faces a limited downtime. The Command \u0026amp; Control API allows to send messages, like commands, from northbound applications upstream and optionally return a response from a device.\nThe Getting Started guide helps to familiarize oneself with Hono by practical example. If interested in a specific protocol, the corresponding User Guide explains the usage comprehensively.\nTo learn the concepts more in-depth, start reading about the architecture and Hono\u0026rsquo;s concept of a Device Identity. The concept page Multi-tenancy explains how Hono allows isolating multiple sets of devices and data. Connecting Devices shows different ways to connect a device (directly or via a gateway), and Device Provisioning explains some options to register devices in Hono.\nTopics related to the operation of Hono are explained in the Admin Guide and the Deployment documentation.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/",
	"title": "Concepts",
	"tags": [],
	"description": "",
	"content": "Concepts Understand the concepts behind Eclipse Hono™.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/device-identity/",
	"title": "Device Identity",
	"tags": [],
	"description": "",
	"content": "This page describes how devices are represented and identified throughout Hono and its APIs.\nThe main purpose of Hono is to provide a uniform API for applications to interact with devices, regardless of the particular communication protocol the devices natively use. In order to do so, Hono uses a unique logical identifier to refer to each device individually.\nHono does not make any assumptions about the format of a device identifier (or device-id for short). It basically is a string which is defined at the time a device is being provisioned. Once created, the device can be referred to by this identifier when using Hono\u0026rsquo;s APIs until the device is being removed from the system.\nTenant Hono supports the logical partitioning of devices into groups called tenants. Each tenant has a unique identifier, a string called the tenant-id, and can be used to provide a logical grouping of devices belonging e.g. to the same application scope or organizational unit. Each device can thus be uniquely identified by the tuple (tenant-id, device-id). This tuple is broadly used throughout Hono\u0026rsquo;s APIs when addressing a particular device.\nDevice Registration Hono components use the Device Registration API to access device registration information. The API defines the assert Registration operation for verifying a device\u0026rsquo;s registration status. In many real world scenarios there will already be a component in place which keeps track of devices and which supports the particular provisioning process being used to bring devices into life. In such cases it makes sense to simply implement the Device Registration API as a facade on top of the existing component.\nIn addition to that, Hono defines a Device Registry Management API, which can be implemented to take advantage of standardized operations for managing devices and credentials. This API is optional because Hono components do not require it during runtime.\nHono comes with a MongoDB and a simple file based implementations of both APIs. The file based implementation, which keeps all data in memory, is to be used only for demonstration purposes and is not supposed to be used in production scenarios.\nDevice Authentication Devices connect to protocol adapters in order to publish telemetry data or events. Downstream applications consuming this data often take particular actions based on the content of the messages. Such actions may include simply updating some statistics, e.g. tracking the average room temperature, but may also trigger more serious activities like shutting down a power plant. It is therefore important that applications can rely on the fact that the messages they process have in fact been produced by the device indicated by a message\u0026rsquo;s source address.\nHono relies on protocol adapters to establish a device\u0026rsquo;s identity before it is allowed to publish downstream data or receive commands. Conceptually, Hono distinguishes between two identities\n an identity associated with the authentication credentials (termed the authentication identity or auth-id), and an identity to act as (the device identity or device-id).  A device therefore presents an auth-id as part of its credentials during the authentication process which is then resolved to a device identity by the protocol adapter on successful verification of the credentials.\nIn order to support the protocol adapters in the process of verifying credentials presented by a device, the Credentials API provides means to look up secrets on record for the device and use this information to verify the credentials.\nThe Credentials API supports registration of multiple sets of credentials for each device. A set of credentials consists of an auth-id and some sort of secret information. The particular type of secret determines the kind of information kept. Please refer to the Standard Credential Types defined in the Credentials API for details. Based on this approach, a device may be authenticated using different types of secrets, e.g. a hashed password or a pre-shared key, depending on the capabilities of the device and/or protocol adapter.\nOnce the protocol adapter has resolved the device-id for a device, it uses this identity when referring to the device in all subsequent API invocations, e.g. when forwarding telemetry messages downstream to the AMQP Messaging Network.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/tenancy/",
	"title": "Multi-Tenancy",
	"tags": [],
	"description": "",
	"content": "Hono is designed to structure the set of all internally managed data and data streams into strictly isolated subsets. This includes the registration data and credentials of devices, internal users that are used for authentication, and the Business Applications that are part of such subsets as well.\nThis way of strict isolation is generally known as multi-tenancy, where a tenant is the term for such a subset. Such an isolation is essential for enabling a scalable distributed architecture to handle independent subsets as if each subset had its own installation (which would be much harder to maintain and would not benefit from runtime cost sharing).\nHono\u0026rsquo;s multi-tenancy concept is based on handling tenants as own entities. All functionality of Hono is provided in the context of a previously created tenant - except the creation of a tenant itself.\nIn the following the different aspects of multi-tenancy in Hono are addressed and a full overview of the concept is given.\nThe Tenant API By means of the Tenant API Hono handles tenants as own entities. The API defines how to retrieve the details of a specific tenant. This offers the possibility to handle arbitrary properties on the level of a tenant (see e.g. Protocol adapter configuration). For convenience, there are CRUD operations for the handling of tenants, which can be found in the Device Registry Management API.\nProtocol Adapters respect the Tenant API When a device connects to one of Hono\u0026rsquo;s protocol adapters, the adapter determines the tenant this device belongs to. How this is done is described in the User Guide. After the tenant is determined, the adapter retrieves the details of the determined tenant by means of the Tenant API. Only if the tenant exists and is enabled the adapter further processes the data of the device that is connecting. Otherwise the connection will be closed.\nProtocol Adapter Configuration Protocol adapters retrieve parts of their configuration on a tenant level by using the details of the determined tenant. This includes e.g. if a specific protocol adapter is enabled at all for this tenant, allowing to define tenants with only a subset of Hono\u0026rsquo;s functionality. This feature is foreseen to be especially important for production setups.\nExample: a tenant that\n can use the MQTT protocol adapter but is not allowed to use the HTTP protocol adapter  Please refer to the Tenant API to find out which protocol adapter properties can be configured at the tenant level.\nAMQP 1.0 Endpoints The AMQP 1.0 endpoints for all APIs of Hono are scoped to a tenant, by using the scheme \u0026lt;api-name\u0026gt;/TENANT/....\nExamples:\n telemetry/TENANT event/TENANT registration/TENANT  This separates the AMQP endpoints from each other on a tenant level.\nThe only exception to this is the Tenant API which does not follow this scheme since it is addressing the tenants themselves.\nDevices and Tenants A physical device will usually be represented in Hono as an entity in the device registry, having a unique identity and belonging to exactly one tenant. All data sent from a device, as well as from the application to the device, is therefore treated as belonging to the corresponding tenant.\nThe following diagram shows the relation between tenants, devices and their credentials:\n  Tenants, Devices and Credentials   Tenant based Flow Control An important detail in Hono\u0026rsquo;s architecture is that data sent downstream is transported via the tenant scoped AMQP 1.0 links from the protocol adapters to the AMQP 1.0 network. Each tenant has its own pair of AMQP 1.0 links and is treated independently from other tenants regarding the back pressure mechanism that AMQP 1.0 offers. This enables a Business application to limit the rate at which it consumes AMQP 1.0 messages per tenant.\nFor the other direction, when commands are sent from the application to the device, the rate is also limited per tenant.\nAuthorization at Tenant Level Hono\u0026rsquo;s components authenticate each other by means of the Authentication API. The returned token for a successful authentication contains authorization information that is addressing the AMQP 1.0 endpoints. Since the endpoints (as outlined above) are scoped to a tenant, this enables to configure tenants that are authorized to only a subset of Hono\u0026rsquo;s full functionality.\nExample: a tenant (defined by means of authorization configuration) that\n is allowed to send telemetry data downstream but is not allowed to send event data  This is done by not including the event endpoint in the authorization token for these tenants.\nBusiness Applications and Tenants The northbound Business applications are always connecting to the AMQP 1.0 endpoints of Hono. By means of the authentication and authorization setup and the fact that the endpoints are scoped to a tenant, the Business application is only acting in the context of one tenant.\nSeparation of Tenants Tenants are separated from each other in all of Hono\u0026rsquo;s components. Here is a summary of how this is implemented:\n the registration of devices are strictly scoped to a tenant the credentials of devices are strictly scoped to a tenant protocol adapters can be enabled/disabled for a tenant the downstream data flow is isolated for every tenant the upstream data flow (Command \u0026amp; Control) is isolated for every tenant Business applications need to authenticate to the AMQP 1.0 network and are by that mechanism scoped to their tenant  Hints for Production To be flexible for the different needs of production setups, Hono tries to make as few assumptions about the combination of the different APIs as possible. This means e.g. that the Device Registry does not enforce referential integrity of the APIs:\n devices can be created for a tenant that is not existing (yet) credentials can be created for a tenant and/or a device that is not existing (yet) tenants can be deleted and leave their scoped devices and credentials still in the configuration (which may not be usable anymore, since the tenant is missing)  These are points that production setups may want to implement differently.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/device-provisioning/",
	"title": "Device Provisioning",
	"tags": [],
	"description": "",
	"content": "This page describes how devices are provisioned in Hono, i.e. how their digital representation is generated. For each device, registration information is stored that defines a device identity. Each device belongs to exactly one tenant. Each device must have at least one set of credentials that are used to authenticate to Hono.\nTo get an understanding of what is meant by the terms tenant, device registration and credentials, it is recommended to read the Device Identity page first.\nSo in order to use a device with Hono, it has to be provisioned. This means that registration information and at least one credential record must be stored in the device registry.\nThere are different ways to perform device provisioning.\nManual Device Provisioning Devices can be provisioned using Hono\u0026rsquo;s Device Registry Management API via HTTP.\nIf the desired tenant does not yet exist, it must be created first. How to do this is described in the tenants section of the Device Registry Management API.\nThe actual Device Provisioning is then performed by adding devices as described under devices section of the Device Registry Management API. This creates both a device identity and an (empty) credentials record. The last step is to add real credentials as described in the credentials section of the Device Registry Management API.\nAutomatic Device Provisioning The term Auto-Provisioning denotes a feature of Hono where the Device Registry automatically generates the credentials and registration information for a device the first time it connects. Auto-Provisioning is supported by Hono\u0026rsquo;s protocol adapters for devices that authenticate with client certificates or for devices that are connected via a gateway.\nPrerequisites Hono does not require a specific Device Registry implementation, but only specifies a set of APIs that must be provided by a compatible implementation. Since the main part of the Auto-Provisioning has to be done by the Device Registry, the used implementation must explicitly support this feature.\nClient certificate based Auto-Provisioning This feature can be enabled by supplying a certificate authority (CA) for a certain tenant:\nStep 1: Configure the Tenant The CA to be used by the devices needs to be configured. The following tasks must be performed:\n Create tenant Configure the trusted CA for the tenant Enable the feature for the CA  If the Device Registry implementation provides the Management API, this could be done in a single step. For details refer to the Tenant API specification.\nThe Device Registry generates a unique device identifier during auto-provisioning. If auto-provisioning-device-id-template is configured in the corresponding tenant\u0026rsquo;s CA entry, then the device registry generates the device identifier based on the configured template. If not configured, then a random unique device identifier is generated. Refer to the Device Registry Management API for more details on how to configure a tenant\u0026rsquo;s trusted CA authority for that.\nStep 2: Connect an unregistered Device to Hono   Automatic Provisioning of a Device   Hono\u0026rsquo;s protocol adapters query the APIs of the Device Registry during Device Authentication. First, the Tenant API is queried. If the Tenant configuration returned contains the CA used for authentication and the feature is switched on for this CA, the protocol adapter assumes that automatic provisioning must be performed. It puts the device\u0026rsquo;s certificate into the query to enable the device registry to do the provisioning.\nIf the Device Registry does not find any credentials for the device, it takes the information from the client certificate to create both credentials and device registration data for it.\nThe Device Registry is expected to perform the following steps:\n Generate a unique device-id Create device Create credentials Send a Device Provisioning Notification Optional: Provision device in external systems  After successfully sending a device provisioning notification, the corresponding device registration is updated with auto-provisioning-notification-sent as true. Whenever a protocol adapter sends a request to the Device Registry to fetch credentials, this property is verified provided that the device or gateway is auto-provisioned. If it is false a device provisioning notification is sent followed by setting auto-provisioning-notification-sent to true. This is to ensure that the notification is sent at least once.\nThe newly created credentials are returned to the protocol adapter in the response as if they had been present before.\nThe following query of the Device Registration API returns the previously generated registration data.\nThe provisioning is, of course, a one-time action, on subsequent connections the APIs simply return the stored records.\nAutomatic Gateway Provisioning Auto-provisioning of gateways involves the same steps as Automatic Device Provisioning. An extra attribute namely auto-provision-as-gateway is needed in the tenant\u0026rsquo;s trusted CA configuration to enable auto-provisioning of gateways. If this attribute is set to true then the device registry provisions any unregistered devices that authenticate with a client certificate issued by this tenant\u0026rsquo;s trusted CA as gateways, provided that the attribute auto-provisioning-enabled is also set to true. Refer to the Device Registry Management API for more details on the tenant\u0026rsquo;s trusted CA configuration.\nGateway based Auto-Provisioning It refers to auto-provisioning of edge devices that are connected via gateways. Enabling gateway based auto-provisioning requires configuration of the gateway device:\nStep 1: Configure the Gateway Device The gateway device must have the corresponding authority (auto-provisioning-enabled) set. Refer to the Management API for creating or updating a corresponding device.\nStep 2: Connect an unregistered Device via Gateway to Hono   Automatic Provisioning of a Device via gateway   The yet unregistered edge device sends telemetry data via a gateway (1) to a protocol adapter which then checks if the edge device is already registered by calling the assert operation of Device Registration API (2). If the device registration service finds that the device isn\u0026rsquo;t registered yet and the gateway has the auto-provisioning-enabled authority set, it creates the edge device (3).\nSubsequently, after it made sure that it hasn\u0026rsquo;t already done so, it sends an Device Provisioning Notification with the hono_registration_status application property being set to NEW to the AMQP network (4). Once the event has been accepted by the peer (5), the registration service marks the event as delivered (6). The persistent flag guarantees that the Device Provisioning Notification is sent AT_LEAST_ONCE. (NB: applications may receive duplicates of the Device Provisioning Notification!).\nFinally, the device registration service returns the registration information to the protocol adapter (7) which then forwards the telemetry data to the AMQP network (8).\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/connecting-devices/",
	"title": "Connecting Devices",
	"tags": [],
	"description": "",
	"content": "One of the most important features of Eclipse Hono™ is to abstract away the specific communication protocols used by devices. This page describes the different ways of how devices can be connected to Hono.\nBefore a device can connect to Hono and upload data or receive commands from downstream applications, it needs to be provisioned to the system. As part of device provisioning, the device is associated with the tenant that it belongs to and gets assigned a logical identifier which is unique within the tenant.\nDevices can be generally partitioned into two groups: devices which natively support the Internet Protocol (IP) for communication and devices that don\u0026rsquo;t.\nDevices falling into the former group can connect to Hono directly using any of the IP based protocols supported by Hono\u0026rsquo;s protocol adapters. Devices from the latter group often use radio based or serial line communication protocols that are limited to a local area and require a gateway in order to connect to one of Hono\u0026rsquo;s protocol adapters via IP.\nThe diagram below shows a device that supports the MQTT protocol and connects directly to Hono\u0026rsquo;s MQTT protocol adapter and another device that uses Bluetooth LE for connecting locally to a gateway which then connects to Hono\u0026rsquo;s MQTT adapter.\n  Connecting to a Protocol Adapter directly The most straight forward scenario is a device connecting to one of Hono\u0026rsquo;s protocol adapters directly via IP based network infrastructure. For this to work, the device needs to use a communication protocols supported by one of the adapters and needs to be able to use the resource endpoints exposed by that particular protocol adapter as described in its user guide.\nIn this case the connected device\u0026rsquo;s identity will be resolved as part of authentication during connection establishment. For this to work, a set of credentials needs to be provisioned for the device which needs to be appropriate for usage with one of the adapter\u0026rsquo;s supported authentication schemes.\nConnecting via a Device Gateway In some cases, a device may not be able to directly connect to one of Hono\u0026rsquo;s protocol adapters. An example is a device that uses a serial bus or radio waves for local communication. Such devices can be connected to a protocol adapter by means of a device gateway which acts on behalf of the device(s) when communicating with Hono. A device gateway is often implemented as a (small) hardware box close to the devices, running some gateway software which translates hence and forth between the device and one of Hono\u0026rsquo;s protocol adapters.\nFrom the perspective of a protocol adapter, the gateway looks just like any other device having its own device identity and credentials.\nThe following diagram illustrates how a gateway publishes data on behalf of a device that uses Bluetooth for local communication with the gateway.\n   The device establishes a Bluetooth connection with the gateway. The gateway sends an MQTT CONNECT packet to Hono\u0026rsquo;s MQTT adapter to establish an MQTT connection. The packet contains the gateway\u0026rsquo;s credentials. The MQTT adapter determines the tenant from the username contained in the CONNECT packet and retrieves the hashed password that is on record for the gateway from the Credentials service. The Credentials service returns the hashed password. The MQTT adapter checks the password and accepts the connection request. The device sends some sensor readings via Bluetooth to the gateway. The gateway forwards the sensor data in an MQTT PUBLISH packet to the MQTT adapter. The topic name contains the identifier of the device that the gateway acts on behalf of. The MQTT adapter invokes the Device Registration service\u0026rsquo;s assert Device Registration operation to check if the gateway is authorized to act on behalf of the device. The Device Registration service confirms the gateway\u0026rsquo;s authorization. The MQTT adapter accepts the sensor data from the gateway and forwards it downstream.  Note that the device itself is not authenticated by the MQTT adapter in this case. The responsibility for establishing and verifying the device identity lies with the gateway in this setup. It is therefore not necessary to provision credentials for the devices to Hono.\nThe Device Registry Management API\u0026rsquo;s /devices resource can be used to register gateways and devices. The gateways that are authorized to act on behalf of a device can be set by means of the device\u0026rsquo;s via and viaGroups properties. This is useful in cases where a device may roam among multiple gateways.\nWhen sending commands to a device, Hono needs to determine which of the authorized gateways should be used to forward the command message to the device. For this purpose, Hono\u0026rsquo;s protocol adapters keep track of the last known gateway which has acted on behalf of each device by means of the Device Connection API.\nGateway Groups In larger deployments with many gateways it can become cumbersome to list all possible gateways in the via property of each device explicitly. This becomes even more of a burden when gateways are added and/or removed frequently. To help with such situations it is possible to define groups of gateways using Hono\u0026rsquo;s Device Registry Management API.\nA gateway group can be defined implicitly by means of adding the group\u0026rsquo;s identifier to the list in the memberOf property of a (gateway) device that should belong to the group. The gateway group ID can then be added to the viaGroups property of those devices that all gateways in the gateway group are authorized to act on behalf of.\nNote that the Device Registration API, which is used by protocol adapters to verify if a gateway may act on behalf of a device, has no notion of gateway groups. Thus, the response message of the Device Registration API\u0026rsquo;s assert Device Registration operation does not contain the IDs of gateway groups in its via property but instead contains the IDs of all (gateway) devices that are a member of any of the authorized gateway groups.\n Note Hono\u0026rsquo;s example device registry does not support nested gateway groups.  Connecting via a Protocol Gateway Hono already comes with a set of standard protocol adapters which support the most widely used (IP based) IoT protocols like HTTP, MQTT and AMQP 1.0. Devices using one of these protocols might be able to directly connect to the corresponding adapter as described in the previous section. However, even if the device supports MQTT it might still not be possible to connect to the MQTT adapter because the device expects to use a topic structure that differs from the one employed by the MQTT adapter. In other cases devices might use a proprietary, highly optimized, binary (IP based) protocol for communication with back end infrastructure.\nHono supports connecting such devices to one of the standard protocol adapters by means of a protocol gateway. A protocol gateway is a software service which translates hence and forth between the device\u0026rsquo;s proprietary protocol and the protocol used by the Hono protocol adapter. This concept is very similar to the device gateway described above. The main difference is that a protocol gateway is usually deployed in the back end (close to the protocol adapter) whereas a device gateway is usually deployed close to the devices that are connected to the gateway using a mechanism that is usually constrained to a local area.\nThe diagram below illustrates how two devices use a proprietary IP based protocol to connect to a protocol gateway in the back end which in turn is connected to Hono\u0026rsquo;s standard AMQP 1.0 protocol adapter.\n  The devices publish data to the protocol gateway using the proprietary IP based protocol. The gateway then puts the data into AMQP 1.0 messages and forwards them to the Hono AMQP adapter using the AMQP 1.0 protocol.\nThe requirements and prerequisites for this approach are the same as those for the standard device gateway scenario. Authentication and authorization of gateways works in the same way.\nGeneric MQTT Protocol Gateway Template The repository hono-extras contains a generic template for an MQTT protocol gateway. This template allows you to develop a production-ready protocol gateway with minimal effort, with which you can connect existing MQTT-enabled devices to Hono. For example, you can use other topic names or structures, or you can transform, enrich, compress, or encrypt the payload.\nExample Code Hono\u0026rsquo;s examples module contains code for a simple protocol gateway illustrating how devices using a binary TCP based protocol can be connected to Hono\u0026rsquo;s AMQP adapter.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/device-notifications/",
	"title": "Device Notifications",
	"tags": [],
	"description": "",
	"content": "Business Applications need to know when an attempt to send a command to device is feasible, e.g. because the device is then known to be connected to a protocol adapter. Devices and Protocol Adapters can indicate to Business Applications a device\u0026rsquo;s intent to e.g. receive commands using specific notifications.\nTime until Disconnect Notification Devices and Protocol Adapters can notify an application about the fact that a device is connected and ready to receive one or more commands by means of including a time \u0026lsquo;til disconnect (ttd) property in telemetry or event messages.\nThe ttd property value indicates the time that the device will stay connected to the protocol adapter. Using this value together with the creation-time of the message, an application can determine whether an attempt to send a command to the device has a reasonable chance of succeeding. The ttd property can be included in any regular telemetry or event message. However, if a device does not have any telemetry data or event to upload to the adapter, it can also use an empty notification instead.\nHono includes utility classes that application developers can use to register a callback to be notified when a device sends a ttd notification. See Hono\u0026rsquo;s example module for details where such a notification callback is used. Please refer to the Telemetry API and the Event API for further details.\nThe following table defines the possible values of the ttd property and their semantics:\n   TTD Description     \u0026gt; 0 The value indicates the number of seconds that the device will stay connected. Devices using a stateless protocol like HTTP will be able to receive a single command only before disconnecting.   -1 The device is now connected (i.e. available to receive upstream messages) until further notice.   0 The device is now disconnected (i.e. not available anymore to receive upstream messages).    Determining a Device\u0026rsquo;s Connection Status An application receiving a downstream message containing a ttd property can check if the device is currently connected (and thus ready to receive a command) by\n adding the ttd value to the creation-time to determine the expiration time, and then comparing the current time with the expiration time  If the current time is after the expiration time, the device should be assumed to already have disconnected again.\nSource of the ttd Value While it seems to be natural that a device itself indicates when it is ready to receive a command, it may not always be possible or desirable to do so. A device could e.g. be not capable to specify the value for ttd in its message, or all devices of a particular setup would always use the same value for ttd, so it would not make much sense to provide this value always again. Additionally different protocols may or may not let a sender set specific values for a message, so a device using a specific protocol may not be able to provide a value for the ttd property at all. For these reasons there are (resp. may be) additional ways of setting the value of ttd:\n Hono\u0026rsquo;s Tenant and Device Registration APIs support the inclusion of default values for application-properties in the AMQP 1.0 message. By these means a device can be configured to always have a specific value for ttd. In a future extension there may be a configuration value per tenant and protocol adapter that sets the value of ttd if it was not provided by other means already (like provided to the protocol adapter or by setting a default value).  Hono\u0026rsquo;s HTTP protocol adapter Hono\u0026rsquo;s HTTP protocol adapter supports the setting of the ttd value in requests explicitly - please refer to the HTTP Adapter for details. Alternatively the default property values for devices from the Device Registry can be used (described above).\nHono\u0026rsquo;s MQTT protocol adapter The MQTT protocol adapter automatically sends a Time until disconnect notification with a ttd value of -1 for a device that subscribes to the appropriate command topic (refer to the MQTT Adapter user guide for details).\nWhen a device unsubscribes again, the adapter automatically sends a Time until disconnect notification with a ttd value of 0.\nExamples The following sequence diagram shows a Time until disconnect notification while sending a telemetry message downstream via the HTTP protocol adapter:\n  Device command readiness with telemetry data   The following sequence diagram shows a Time until disconnect notification by sending an empty event message downstream via the HTTP protocol adapter:\n  Device command readiness with explicit event  "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/command-and-control/",
	"title": "Command &amp; Control",
	"tags": [],
	"description": "",
	"content": "Business applications can send commands to devices following the Command \u0026amp; Control API. This concept page describes how this API is used by applications to send commands and describes how Hono\u0026rsquo;s protocol adapters process the commands so that they reach their target device.\n Note The description below shows the command \u0026amp; control handling using the Device Connection service. That service is now deprecated and will be replaced by the service implementing the Command Router API. See the last chapter for an overview of how commands are routed if protocol adapters are configured to use the Command Router service instead of the Device Connection service.  Commands can be sent following a request/response or a one-way pattern. For Request/Response commands, there is always a response expected from the device.\nGeneral concept The following sequence diagram gives an overview of a device indicating its availability for receiving commands, of a business application sending a command to the device and of the device sending back a command response.\nThe application and the adapter connect to the AMQP Network, which forwards the transfer - for clarity this is not shown in the diagram below.\n  Request/Response Command overview   In (1) the device subscribes for commands (if connecting to the AMQP or MQTT adapter) or indicates that it will stay connected for a given amount of time to receive a command (if connecting to the HTTP adapter), using the ttd (\u0026ldquo;time till disconnect\u0026rdquo;) parameter.\nThe protocol adapter will then create the necessary AMQP consumer link with the AMQP messaging network if it doesn\u0026rsquo;t exist already (for more details see below) and will send a notification to the application that the device is ready to receive commands (2).\nAfter having created a sender link on the command/TENANT address, the application can then send commands, with the target device given in the AMQP message to address command/TENANT/4711 (3). If a command response is expected, the command response address command_response/TENANT/${replyId} (with replyId being an arbitrary identifier chosen by the application) is to be set as reply-to property in the command message and a corresponding receiver link is to be opened by the application. For one-way commands, both is to be omitted.\nAfter receiving the command, the protocol adapter instance will forward the command to the device (4) and send a disposition update back to the application (5).\nIn case of a Request/Response command, the device can then send a command response (6) that will be forwarded by the protocol adapter back to the application (7).\nCommand \u0026amp; Control involving a gateway Hono has special support for sending commands to devices that are connected via a gateway to Hono. Such devices are configured in the Hono device registration service in such a way, that certain gateways may act on behalf of the device.\nWhen sending commands, the northbound applications do not have to know to which gateway the command target device is connected to. The application sends the command with the device address and Hono will direct the command to a gateway that has subscribed for such commands and that is configured to act on behalf of the command target device. If there are multiple matching gateways, the one that the command target device was last connected to is chosen. The information about which gateways are subscribed and which gateway a device has last communicated by is managed via the device connection service.\nCommand consumer links in the protocol adapter The protocol adapter opens 2 kinds of consumer links to receive commands.\n  A tenant-scoped link on the address command/${tenant}.\nThis is the link address used by applications to send commands. Upon receiving a command message on this link, the protocol adapter checks whether the command target device id needs to be mapped to a gateway. Furthermore it is checked to which particular protocol adapter instance the target device (or mapped gateway) is actually connected. Since this kind of link is opened from all protocol adapter instances receiving commands for the tenant, a command message is first received by any one of these protocol adapter instances. Therefore, if necessary, the command will be delegated to the adapter instance that is connected to the target device or to the gateway receiving commands for the device. That is done by forwarding the command to the AMQP messaging network on a link with the address command_internal/${adapterInstanceId} (see below).\n  A link per protocol adapter instance on the address command_internal/${adapterInstanceId}.\nOn this link, commands will be received that have been forwarded from another protocol adapter instance. This link address is only used for communication between protocol adapter instances, so attaching to this link address should not be enabled for applications.\n  Example with multiple adapters involved The following diagrams show the message flow if the command message is first received on a protocol adapter instance that the target device is not connected to.\n  Command subscription   In the scenario here there is a protocol adapter instance #2 through which a command subscription for the example tenant was already made (0).\nThe device subscribes for commands (1) and the protocol adapter creates the receiver link (2) on the tenant-scoped link. The protocol adapter then updates the command-handling protocol adapter instance for device information (3), assigning the device 4711 to adapter instance id #1. Following that, the notification about the device subscription is sent to the application via the AMQP messaging network (4).\n  Command handling   Upon receiving the notification, the application prepares sender and command response receiver links (1,2) and sends the command message to the AMQP messaging network. Here it is received by protocol adapter instance #2. The protocol adapter then queries the command-handling protocol adapter instances information for the device id of the command message (4). In this case here, the protocol adapter instance #1 is returned (5). The command then gets forwarded to the AMQP messaging network on the address for adapter instance #1 (6). The protocol adapter instance #1 will receive the message (7) and forward it to the device (8). As the last step, an accepted disposition will be sent back to the application (9).\n  Command response handling   The command response message is sent back to the application from the protocol adapter via the AMQP messaging network.\nGateway subscriptions Gateway subscribing for commands for a particular device The following sequence diagrams show the different steps involved in having a gateway subscribe for commands of a particular device.\n  Command subscription   The gateway \u0026ldquo;gw-1\u0026rdquo; is connected to a protocol adapter and subscribes to commands for a device 4711 (1). This device has to be configured so that the gateway may act on its behalf (see Configuring Gateway Devices for details).\nThe protocol adapter creates the tenant-scoped consumer link on the command/TENANT address (if it doesn\u0026rsquo;t already exist) (2) and then updates the command-handling protocol adapter instance for device information (3), assigning the device 4711 to adapter instance id #1.\nJust like it is done when a protocol adapter handles any kind of message from a gateway acting on behalf of a device, the protocol adapter updates the last-known gateway information here, sending a request to the device connection service (4). The notification event is then sent containing the device id 4711 (5)\n  Command handling   After the application has prepared the sender and consumer links (1,2), it sends the command message on the command/TENANT link with the AMQP message to property set to command/TENANT/4711 and reply-to set to the address of the command response consumer link (command_response/TENANT/${replyId} with replyId being an arbitrary identifier chosen by the application) (3). After receiving the command message, the protocol adapter determines the command-handling protocol adapter instances information for the device id of the command message (4). In this case here, the protocol adapter instance #1 is returned (5), meaning that the command is already at the right adapter instance. As the subscription for commands to device 4711 was done by gateway \u0026ldquo;gw-1\u0026rdquo;, the command gets forwarded to that gateway (6). It is then the responsibility of the gateway to forward the command to the device 4711. After the gateway has acknowledged the command message, an accepted disposition will be sent back to the application (7).\n  Command response handling   When the device sends a command response via the gateway (1), the protocol adapter forwards the command message on the command_response/TENANT/${replyId} link to the application (2).\nGateway subscribing for commands for all its devices A gateway may also subscribe for commands sent to all the different devices that the gateway acts on behalf of. Such a scenario is shown in the following sequence diagram.\n  Command subscription   The gateway subscribes for commands just like a normal device would, only using its id gw-1 (1). The protocol adapter creates the tenant-scoped consumer link on the command/TENANT address (if it doesn\u0026rsquo;t already exist) (2) and then updates the command-handling protocol adapter instance for device information (3), assigning the device \u0026lsquo;gw-1\u0026rsquo; to adapter instance id #1. The subscription notification sent to the application contains the gateway id gw-1. That means that either the application has to know about the gateway, or that it just assumes that the devices it sends commands to (and that are connected to the gateway) are always available for receiving commands. This may especially be the case for long-lasting command subscriptions (with the MQTT or AMQP adapter).\n  Command handling   After the application has prepared the sender and consumer links (1,2), it sends the command message on the command/TENANT link with the AMQP message to property set to command/TENANT/4711 and reply-to set to the address of the command response consumer link (command_response/TENANT/${replyId} with replyId being an arbitrary identifier chosen by the application) (3). After receiving the command message, the protocol adapter determines the command-handling protocol adapter instances information for the device id of the command message (4).\nIn the example above, there is no adapter instance associated with the device 4711. Therefore it is checked whether there are adapter instances handling commands for the gateways, configured to possibly act on behalf of the device. If there is an adapter instance associated with the last known gateway of the device, that instance is returned as the result. Otherwise, and in the example above, the command handling adapter instance for any of these gateways is returned (the choice being random if there are multiple instances). In the above example that is the instance #1 associated with gateway gw-1 (5).\nThen the command gets forwarded to that gateway (6). It is the responsibility of the gateway to forward the command to the device 4711. After the gateway has acknowledged the command message, an accepted disposition will be sent back to the application (7).\nHandling of the command response is done in the same way as shown in the chapter above for a gateway subscribing for a particular device and is therefore omitted here.\nIf a gateway has already subscribed for commands for all its device, it may still subscribe for commands for a particular device (and the other way around). The particular device subscription has precedence then in choosing over which subscription protocol/channel to send the command to the gateway.\n\nNew approach using the Command Router service The following diagrams show the message flow if protocol adapters are configured to use the Command Router service instead of the Device Connection service.\n  Command subscription   In the scenario the device subscribes for commands (1) and the protocol adapter registers the command consumer with the Command Router service, associating the device with its protocol adapter instance identifier (2). The Command Router service creates a receiver link scoped to the device\u0026rsquo;s tenant (3) if it doesn\u0026rsquo;t exist yet. Following that, the notification about the device subscription is sent to the application via the AMQP messaging network (4).\n  Command handling   Upon receiving the notification, the application prepares sender and command response receiver links (1,2) and sends the command message to the AMQP messaging network. The message is received by the Command Router service component (3), which will determine the protocol adapter instance #1 that is able to handle the command message. The command then gets forwarded to the AMQP messaging network on the address for adapter instance #1 (4). The protocol adapter instance #1 will receive the message (5) and forward it to the device (6). As the last step, an accepted disposition will be sent back to the application (7).\n  Command response handling   The command response message is sent back to the application from the protocol adapter via the AMQP messaging network.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/resource-limits/",
	"title": "Resource limits",
	"tags": [],
	"description": "",
	"content": "Resource limits such as the maximum number of device connections allowed per tenant or the allowed data volume of the messages over a period of time per tenant can be set in Hono.\nHono specifies an API ResourceLimitChecks that is used by the protocol adapters for the verification of the configured resource limits. A default implementation of this API is shipped with Hono. This default implementation uses the live metrics data retrieved from a Prometheus server to verify the resource-limits, if configured. To enable and use this default implementation, please refer to the protocol adapter admin guides. Based on the requirements, a custom version of the above API can be implemented and used. The resource-limits for a tenant can be set using the tenant configuration. Please refer to the Tenant API for more details.\nConnections Limit Before accepting a new connection request from a device, the number of existing connections is checked against the configured limit by the protocol adapters. The connection request is declined if the limit is exceeded.\nThe MQTT and AMQP protocol adapters keep the connections longer opened than their counterparts such as HTTP. Thereby the MQTT and AMQP adapters are enabled to check the connection limits before accepting any new connection to a device.\nConnection Duration Limit Before accepting a new connection request from a device, the overall amount of time that the devices have already been connected to protocol adapters for that tenant is checked against the configured limit by the protocol adapters. The connection request is declined if the connection duration limit has been already reached. This limit is only supported by protocol adapters that maintain connection state with authenticated devices. In particular, the HTTP adapter does not support this metric.\nThe default Prometheus based implementation uses connection duration as the factor to limit the connections. This default implementation supports two modes of connection duration limit calculation namely days and monthly. For more details on how to set the mode refer to the Tenant API. If the period is not set explicitly, then the mode is assumed as monthly in the default implementation.\nIn the monthly mode, further device connections are only allowed, if the overall amount of time that the devices have already been connected from the beginning till the end of the current (Gregorian) calendar month does not exceed the configured max-minutes value. But for the first month, on which the connection duration limit became effective, the effective connection duration limit is calculated based on the max-minutes with respect to the remaining days in that month from the effective-since date.\nBelow is a sample resource limit configuration for a tenant, where it has been defined that the connection duration limit became effective on 10.Jul.2019 and the maximum connection duration limit for every month is 50,000 minutes. It means that from August 2019, the connection limit check ensures that no more connections are allowed for that tenant, if that limit of 50,000 minutes is already reached. But in case of July 2019, the month on which the message limit became effective, the effective connection duration limit is calculated by finding the average limit for a day from the configured max-minutes and then multiplying it with the number of days from the effective-since date till the end of that month. In this case it is calculated as (50,000 minutes / 31 days) x 22 days, which is 35,483 minutes. It means that for the month of July 2019, no more new connections are allowed, if the limit of 35,843 minutes is already reached.\n\u0026#34;resource-limits\u0026#34;: { \u0026#34;connection-duration\u0026#34;: { \u0026#34;effective-since\u0026#34;: \u0026#34;2019-07-10T14:30:00Z\u0026#34;, \u0026#34;max-minutes\u0026#34;: 50000, \u0026#34;period\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;monthly\u0026#34; } } } In the days mode, further device connections are only allowed, if the overall amount of time that the devices have already been connected for the configured no-of-days does not exceed the max-minutes value. In the below sample configuration, the mode is configured as days and the accounting duration as 30 days. In this case the connection duration limit check ensures that new connections are accepted, only if the connection duration usage for every 30 days from 10.Jul.2019 (effective-since) does not exceed the 50,000 minutes limit.\n\u0026#34;resource-limits\u0026#34;: { \u0026#34;connection-duration\u0026#34;: { \u0026#34;effective-since\u0026#34;: \u0026#34;2019-07-10T14:30:00Z\u0026#34;, \u0026#34;max-minutes\u0026#34;: 50000, \u0026#34;period\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;days\u0026#34;, \u0026#34;no-of-days\u0026#34;: 30 } } } Messages Limit Hono supports limiting the number of messages that devices and north bound applications of a tenant can publish to Hono during a given time interval. Before accepting any telemetry or event or command messages from devices or north bound applications, it is checked by the protocol adapters that if the message limit is exceeded or not. The incoming message is discarded if the limit is exceeded.\nThe default Prometheus based implementation uses data volume as the factor to limit the messages. The data volume already consumed by a tenant over the given time interval is compared with the configured message limit before accepting any messages. The default implementation supports two modes of message limits calculation namely days and monthly. For more details on how to set the mode refer to the Tenant API. If the period is not set explicitly, then the mode is assumed as monthly in the default implementation.\nIn the monthly mode, the message limit check ensures that the data usage from the beginning till the end of a (Gregorian) calendar month does not exceed the max-bytes value. But for the first month on which the message limit became effective, the effective max-bytes are calculated based on the max-bytes with respect to the remaining days in that month from the effective-since date.\nBelow is a sample resource limit configuration for a tenant and it has been defined that the message limit became effective on 10.Jul.2019 and the maximum bytes allowed for a month is 2 GB. It means that from August 2019, the message limit check ensures that the data usage in a month does not exceed 2 GB. But in case of July 2019, the month on which the message limit became effective, the effective max-bytes is calculated by finding the average limit for a day from the max-bytes and multiplying it with the number of days from the effective-since date till the end of that month. In this case it is calculated as (2 GB / 31 days) x 22 days which is 1.4 GB. It means that for the month of July 2019, the data usage should not exceed 1.4GB.\n\u0026#34;resource-limits\u0026#34;: { \u0026#34;data-volume\u0026#34;: { \u0026#34;effective-since\u0026#34;: \u0026#34;2019-07-10T14:30:00Z\u0026#34;, \u0026#34;max-bytes\u0026#34;: 2147483648, \u0026#34;period\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;monthly\u0026#34; } } } In the days mode, the message limit check ensures that the data usage for the defined no-of-days does not exceed the max-bytes value. In the below sample configuration, the mode is configured as days and the accounting duration as 30 days. In this case the message limit check ensures that the data usage for every 30 days from 10.Jul.2019 (effective-since) does not exceed the 2GB limit.\n\u0026#34;resource-limits\u0026#34;: { \u0026#34;data-volume\u0026#34;: { \u0026#34;effective-since\u0026#34;: \u0026#34;2019-07-10T14:30:00Z\u0026#34;, \u0026#34;max-bytes\u0026#34;: 2147483648, \u0026#34;period\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;days\u0026#34;, \u0026#34;no-of-days\u0026#34;: 30 } } } "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/concepts/connection-events/",
	"title": "Connection Events",
	"tags": [],
	"description": "",
	"content": "Hono\u0026rsquo;s protocol adapters can use connection events to indicate the connection status of a device. In particular, an adapter can notify downstream components about a newly established connection with a device or about a device having disconnected.\nThe connection status of devices using stateful protocols like MQTT and AMQP can usually be determined quite easily because these protocols often require peers to explicitly open or close a connection and often also support a kind of heart beat which can be used to determine if a connection is still alive. However, for stateless protocols like HTTP or CoAP, there is no clear definition of what it actually means that a device is connected. It is obvious that a device is connected when it is sending an HTTP request. However, the adapter has no way of knowing if the device has gone to sleep after it has received the adapter\u0026rsquo;s response to its request.\nThat said, connection events indicating an established connection with a device can usually be taken as face value. However, connection events indicating the disconnection of a device may only represent the protocol adapters view of the device\u0026rsquo;s connection status. For example, the HTTP adapter might consider a device disconnected because it hasn\u0026rsquo;t received any requests from the device for some time. However, the device itself might as well be up and running (i.e. not sleeping) and simply have no data worth publishing.\nThe mechanism of firing connection events is pluggable with the default implementation simply forwarding connection status information to the logging framework. Hono also comes with an alternative implementation which forwards connection status information by means of Connection Events via the Events API.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/",
	"title": "User Guide",
	"tags": [],
	"description": "",
	"content": "User Guide Learn how Eclipse Hono™ enables you to quickly send data from devices to business applications and vice versa.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/mongodb-based-device-registry/",
	"title": "MongoDB Based Device Registry",
	"tags": [],
	"description": "",
	"content": "The MongoDB based Device Registry component provides implementations of Hono\u0026rsquo;s Tenant API, Device Registration API and Credentials API. As such, it exposes AMQP 1.0 based endpoints for retrieving the relevant information. Protocol adapters use these APIs to determine a device\u0026rsquo;s registration status, e.g. if it is enabled and if it is registered with a particular tenant, and to authenticate a device before accepting any data for processing from it.\nIn addition to the above APIs, this Device Registry also exposes HTTP endpoints for managing the contents of the Device Registry according to the Device Registry Management API. It uses a MongoDB database to persist tenant, device and credentials data into separate collections.\nFor more information on how to configure the MongoDB based device registry, see MongoDB based Device Registry configuration.\nAuthentication This Device Registry secures its HTTP Endpoints using basic authentication mechanism. Thereby the clients connecting to the MongoDB based Device Registry are required to authenticate. For more information on how to enable the authentication and configure it, please refer to the hono.registry.http.authenticationRequired property in the MongoDB based Device Registry configuration.\nManaging Tenants Please refer to the Device Registry Management API for information about managing tenants.\nRegistration Limits The registry supports the enforcement of registration limits defined at the tenant level. The registry enforces\n the maximum number of devices that can be registered for a tenant and the maximum number of credentials that can be registered for each device of a tenant.  In order to enable enforcement of any of these limits for a tenant, the corresponding registration-limits property needs to be set explicitly on the tenant like in the example below:\n{ \u0026#34;registration-limits\u0026#34;: { \u0026#34;max-devices\u0026#34;: 100, \u0026#34;max-credentials-per-device\u0026#34;: 5 } }  Global Maximum Device per Tenant Limit The registry can be configured with a global limit for the number of devices that can be registered per tenant. The value can be set via the registry\u0026rsquo;s HONO_REGISTRY_SVC_MAX_DEVICES_PER_TENANT configuration variable. The maximum number of devices allowed for a particular tenant is determined as follows:\n If the tenants\u0026rsquo;s registration-limits/max-devices property has a value \u0026gt; -1 then that value is used as the limit. Otherwise, if the HONO_REGISTRY_SVC_MAX_DEVICES_PER_TENANT configuration variable has a value \u0026gt; -1 then that value is used as the limit. Otherwise, the number of devices is unlimited.    Managing Devices Please refer to the Device Registry Management API for information about managing devices.\nManaging Credentials Please refer to the Device Registry Management API for information about managing credentials.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/jdbc-based-device-registry/",
	"title": "JDBC Based Device Registry",
	"tags": [],
	"description": "",
	"content": "The JDBC based Device Registry component provides implementations of Hono\u0026rsquo;s Tenant API, Device Registration API and Credentials API. As such it exposes AMQP 1.0 based endpoints for retrieving the relevant information. Protocol adapters use these APIs to determine a device\u0026rsquo;s registration status, e.g. if it is enabled and if it is registered with a particular tenant, and to authenticate a device before accepting any data for processing from it.\nIn addition to the above APIs, this Device Registry also exposes HTTP endpoints for managing the contents of the Device Registry according to the Device Registry Management API. It uses a JDBC compliant database to persist the data. By default, this registry supports H2 and PostgreSQL. For more information on how to configure the JDBC based device registry, see JDBC based Device Registry configuration.\nManaging Tenants Please refer to the Device Registry Management API for information about managing tenants.\n Warning The JDBC based device registry doesn\u0026rsquo;t support search tenants operation defined by the Device Registry Management API.  Managing Devices Please refer to the Device Registry Management API for information about managing devices.\n Warning The JDBC based device registry doesn\u0026rsquo;t support search devices operation defined by the Device Registry Management API.  Managing Credentials Please refer to the Device Registry Management API for information about managing credentials.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/file-based-device-registry/",
	"title": "File Based Device Registry",
	"tags": [],
	"description": "",
	"content": "The Device Registry component provides exemplary implementations of Hono\u0026rsquo;s Tenant API, Device Registration API and Credentials API.\nAs such it exposes AMQP 1.0 based endpoints for retrieving the relevant information and persists data to the local file system.\n Deprecation The file based device registry has been deprecated and will be removed in a future version of Hono. Please use the Mongo DB or JDBC based registry implementations instead.  In addition, the Device Registry also exposes HTTP resources for managing the contents of the registry according to the Device Registry Management API.\n Warning The Device Registry is not intended to be used in production environments. In particular, access to the HTTP resources described below is not restricted to authorized clients only.  Managing Tenants Please refer to the Device Registry Management API for information about managing tenants.\n Note The file based device registry neither supports the Device Registry Management API\u0026rsquo;s search tenants nor the search devices operation.  Managing Devices Please refer to the Device Registry Management API for information about managing devices.\nManaging Credentials Please refer to the Device Registry Management API for information about managing credentials.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/http-adapter/",
	"title": "HTTP Adapter",
	"tags": [],
	"description": "",
	"content": "The HTTP protocol adapter exposes HTTP based endpoints for Eclipse Hono™\u0026rsquo;s south bound Telemetry, Event and Command \u0026amp; Control APIs.\nDevice Authentication The HTTP adapter by default requires clients (devices or gateway components) to authenticate during connection establishment. The adapter supports both the Basic HTTP authentication scheme as well as client certificate based authentication as part of a TLS handshake for that purpose.\nThe adapter tries to authenticate the device using these mechanisms in the following order\nClient Certificate When a device uses a client certificate for authentication during the TLS handshake, the adapter tries to determine the tenant that the device belongs to, based on the issuer DN contained in the certificate. In order for the lookup to succeed, the tenant\u0026rsquo;s trust anchor needs to be configured by means of registering the trusted certificate authority. The device\u0026rsquo;s client certificate will then be validated using the registered trust anchor, thus implicitly establishing the tenant that the device belongs to. In a second step, the adapter then uses the Credentials API\u0026rsquo;s get operation with the client certificate\u0026rsquo;s subject DN as the auth-id and x509-cert as the type of secret as query parameters.\nNB The HTTP adapter needs to be configured for TLS in order to support this mechanism.\nHTTP Basic Auth The username provided in the header must have the form auth-id@tenant, e.g. sensor1@DEFAULT_TENANT. The adapter verifies the credentials provided by the client against the credentials that the configured Credentials service has on record for the client. The adapter uses the Credentials API\u0026rsquo;s get operation to retrieve the credentials on record with the tenant and auth-id provided by the device in the username and hashed-password as the type of secret as query parameters.\nThe examples below refer to devices 4711 and gw-1 of tenant DEFAULT_TENANT using auth-ids sensor1 and gw1 and corresponding passwords. The example deployment as described in the Deployment Guides comes pre-configured with the corresponding entities in its device registry component. Please refer to the Credentials API for details regarding the different types of secrets.\nNB There is a subtle difference between the device identifier (device-id) and the auth-id a device uses for authentication. See Device Identity for a discussion of the concepts.\nMessage Limits The adapter rejects\n a client\u0026rsquo;s request to upload data with status code 429 Too Many Requests and any AMQP 1.0 message containing a command sent by a north bound application  if the message limit that has been configured for the device\u0026rsquo;s tenant is exceeded.\nPublish Telemetry Data (authenticated Device)  URI: /telemetry Method: POST Request Headers:  (optional) authorization: The device\u0026rsquo;s auth-id and plain text password encoded according to the Basic HTTP authentication scheme. If not set, the adapter expects the device to present a client certificate as part of the TLS handshake during connection establishment. (required) content-type: The type of payload contained in the request body. (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) qos-level: The QoS level for publishing telemetry messages. The adapter supports at most once (0) and at least once (1) QoS levels. The default value of 0 is assumed if this header is omitted.   Request Body:  (required) Arbitrary payload encoded according to the given content type.   Response Headers:  (optional) content-type: A media type describing the semantics and format of payload contained in the response body. This header will only be present if the response contains a command to be executed by the device which requires input data. (optional) hono-command: The name of the command to execute. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-req-id: An identifier that the device must include in its response to a command. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-target-device: The id of the device that shall execute the command. This header will only be present if the response contains a command to be executed by the device and if the response goes to a gateway that acts on behalf of the target device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 200. (optional) Error details, if status code is \u0026gt;= 400.   Status Codes:  200 (OK): The telemetry data has been accepted for processing. The response contains a command for the device to execute. 202 (Accepted): The telemetry data has been accepted for processing. Note that if the qos-level request header is omitted (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer. However, if the QoS level header is set to 1 (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 400 (Bad Request): The request cannot be processed. Possible reasons for this include:  The content type header is missing. The request body is empty. The QoS header value is invalid.   401 (Unauthorized): The request cannot be processed because the request does not contain valid credentials. 403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no consumer of telemetry data for the given tenant connected to Hono, or the consumer has not indicated that it may receive further messages (not giving credits). If the QoS level header is set to 1 (at least once semantics), the reason may be:  The consumer has indicated that it didn\u0026rsquo;t process the telemetry data. The consumer failed to indicate in time whether it has processed the telemetry data.        This is the preferred way for devices to publish telemetry data. It is available only if the protocol adapter is configured to require devices to authenticate (which is the default).\nExamples\nPublish some JSON data for device 4711:\ncurl -i -u sensor1@DEFAULT_TENANT:hono-secret -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://127.0.0.1:8080/telemetry HTTP/1.1 202 Accepted content-length: 0 Publish some JSON data for device 4711 using at least once QoS:\ncurl -i -u sensor1@DEFAULT_TENANT:hono-secret -H \u0026#39;content-type: application/json\u0026#39; -H \u0026#39;qos-level: 1\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://localhost:8080/telemetry HTTP/1.1 202 Accepted content-length: 0 Publish some JSON data for device 4711, indicating that the device will wait for 10 seconds to receive the response:\ncurl -i -u sensor1@DEFAULT_TENANT:hono-secret -H \u0026#39;content-type: application/json\u0026#39; -H \u0026#39;hono-ttd: 10\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://localhost:8080/telemetry HTTP/1.1 200 OK hono-command: set hono-cmd-req-id: 1010a7249aa5-f742-4376-8458-bbfc88c72d92 content-length: 23 { \u0026#34;brightness\u0026#34;: 87 } Publish some JSON data for device 4711 using a client certificate for authentication:\n# in base directory of Hono repository: curl -i --cert demo-certs/certs/device-4711-cert.pem --key demo-certs/certs/device-4711-key.pem --cacert demo-certs/certs/trusted-certs.pem -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; https://localhost:8443/telemetry HTTP/1.1 202 Accepted content-length: 0 NB The example above assumes that the HTTP adapter is configured for TLS and the secure port is used.\nPublish Telemetry Data (unauthenticated Device)  URI: /telemetry/${tenantId}/${deviceId} Method: PUT Request Headers:  (required) content-type: The type of payload contained in the request body. (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) qos-level: The QoS level for publishing telemetry messages. The adapter supports at most once (0) and at least once (1) QoS levels. The default value of 0 is assumed if this header is omitted.   Request Body:  (required) Arbitrary payload encoded according to the given content type.   Response Headers:  (optional) content-type: A media type describing the semantics and format of payload contained in the response body. This header will only be present if the response contains a command to be executed by the device which requires input data. (optional) hono-command: The name of the command to execute. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-req-id: An identifier that the device must include in its response to a command. This header will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 200. (optional) Error details, if status code is \u0026gt;= 400.   Status Codes:  200 (OK): The telemetry data has been accepted for processing. The response contains a command for the device to execute. 202 (Accepted): The telemetry data has been accepted for processing. Note that if the qos-level request header is omitted (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer. However, if the QoS level header is set to 1 (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 400 (Bad Request): The request cannot be processed. Possible reasons for this include:  The content type header is missing. The request body is empty. The QoS header value is invalid.   403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter. The given device does not belong to the given tenant.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no consumer of telemetry data for the given tenant connected to Hono, or the consumer has not indicated that it may receive further messages (not giving credits). If the QoS level header is set to 1 (at least once semantics), the reason may be:  The consumer has indicated that it didn\u0026rsquo;t process the telemetry data. The consumer failed to indicate in time whether it has processed the telemetry data.        This resource MUST be used by devices that have not authenticated to the protocol adapter. Note that this requires the HONO_HTTP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nPublish some JSON data for device 4711:\ncurl -i -X PUT -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://127.0.0.1:8080/telemetry/DEFAULT_TENANT/4711 HTTP/1.1 202 Accepted content-length: 0 Publish some JSON data for device 4711 using at least once QoS:\ncurl -i -X PUT -H \u0026#39;content-type: application/json\u0026#39; -H \u0026#39;qos-level: 1\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://127.0.0.1:8080/telemetry/DEFAULT_TENANT/4711 HTTP/1.1 202 Accepted content-length: 0 Publish some JSON data for device 4711, indicating that the device will wait for 10 seconds to receive the response:\ncurl -i -X PUT -H \u0026#39;content-type: application/json\u0026#39; -H \u0026#39;hono-ttd: 10\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://localhost:8080/telemetry/DEFAULT_TENANT/4711 HTTP/1.1 200 OK hono-command: set hono-cmd-req-id: 1010a7249aa5-f742-4376-8458-bbfc88c72d92 content-length: 23 { \u0026#34;brightness\u0026#34;: 87 } Publish Telemetry Data (authenticated Gateway)  URI: /telemetry/${tenantId}/${deviceId} Method: PUT Request Headers:  (optional) authorization: The gateway\u0026rsquo;s auth-id and plain text password encoded according to the Basic HTTP authentication scheme. If not set, the adapter expects the gateway to present a client certificate as part of the TLS handshake during connection establishment. (required) content-type: The type of payload contained in the request body. (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) qos-level: The QoS level for publishing telemetry messages. The adapter supports at most once (0) and at least once (1) QoS levels. The default value of 0 is assumed if this header is omitted.   Request Body:  (required) Arbitrary payload encoded according to the given content type.   Response Headers:  (optional) content-type: A media type describing the semantics and format of payload contained in the response body. This header will only be present if the response contains a command to be executed by the device which requires input data. (optional) hono-command: The name of the command to execute. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-req-id: An identifier that the device must include in its response to a command. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-target-device: The id of the device that shall execute the command. This header will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 200. (optional) Error details, if status code is \u0026gt;= 400.   Status Codes:  200 (OK): The telemetry data has been accepted for processing. The response contains a command for the device to execute. 202 (Accepted): The telemetry data has been accepted for processing. Note that if the qos-level request header is omitted (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer. However, if the QoS level header is set to 1 (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 400 (Bad Request): The request cannot be processed. Possible reasons for this include:  The content type header is missing. The request body is empty. The QoS header value is invalid.   401 (Unauthorized): The request cannot be processed because the request does not contain valid credentials. 403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The tenant that the gateway belongs to is not allowed to use this protocol adapter. The device belongs to another tenant than the gateway. The gateway is not authorized to act on behalf of the device. The gateway associated with the device is not registered or disabled.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no consumer of telemetry data for the given tenant connected to Hono, or the consumer has not indicated that it may receive further messages (not giving credits). If the QoS level header is set to 1 (at least once semantics), the reason may be:  The consumer has indicated that it didn\u0026rsquo;t process the telemetry data. The consumer failed to indicate in time whether it has processed the telemetry data.        This resource can be used by gateway components to publish data on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the parameters from the URI are used to identify the device that the gateway publishes data for.\nThe protocol adapter checks the gateway\u0026rsquo;s authority to publish data on behalf of the device implicitly by means of retrieving a registration assertion for the device from the configured Device Registration service.\nExamples\nPublish some JSON data for device 4712:\ncurl -i -X PUT -u gw@DEFAULT_TENANT:gw-secret -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://127.0.0.1:8080/telemetry/DEFAULT_TENANT/4712 HTTP/1.1 202 Accepted content-length: 0 Publish some JSON data for device 4712 using at least once QoS:\ncurl -i -X PUT -u gw@DEFAULT_TENANT:gw-secret -H \u0026#39;content-type: application/json\u0026#39; -H \u0026#39;qos-level: 1\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://127.0.0.1:8080/telemetry/DEFAULT_TENANT/4712 HTTP/1.1 202 Accepted content-length: 0 Publish some JSON data for device 4712, indicating that the gateway will wait for 10 seconds to receive the response:\ncurl -i -X PUT -u gw@DEFAULT_TENANT:gw-secret -H \u0026#39;content-type: application/json\u0026#39; -H \u0026#39;hono-ttd: 10\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://localhost:8080/telemetry/DEFAULT_TENANT/4712 HTTP/1.1 200 OK hono-command: set hono-cmd-req-id: 1010a7249aa5-f742-4376-8458-bbfc88c72d92 content-length: 23 { \u0026#34;brightness\u0026#34;: 87 } NB The example above assumes that a gateway device has been registered with hashed-password credentials with auth-id gw and password gw-secret which is authorized to publish data on behalf of device 4712.\nPublish an Event (authenticated Device)  URI: /event Method: POST Request Headers:  (optional) authorization: The device\u0026rsquo;s auth-id and plain text password encoded according to the Basic HTTP authentication scheme. If not set, the adapter expects the device to present a client certificate as part of the TLS handshake during connection establishment. (required) content-type: The type of payload contained in the request body. (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) hono-ttl: The time-to-live in number of seconds for event messages.   Request Body:  (required) Arbitrary payload encoded according to the given content type.   Response Headers:  (optional) content-type: A media type describing the semantics and format of payload contained in the response body. This header will only be present if the response contains a command to be executed by the device which requires input data. (optional) hono-command: The name of the command to execute. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-req-id: An identifier that the device must include in its response to a command. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-target-device: The id of the device that shall execute the command. This header will only be present if the response contains a command to be executed by the device and if the response goes to a gateway that acts on behalf of the target device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 200. (optional) Error details, if status code is \u0026gt;= 400.   Status Codes:  200 (OK): The event has been accepted for processing. The response contains a command for the device to execute. 202 (Accepted): The event has been accepted for processing. 400 (Bad Request): The request cannot be processed. Possible reasons for this include:  The content type header is missing. The request body is empty but the event is not of type empty-notification.   401 (Unauthorized): The request cannot be processed because the request does not contain valid credentials. 403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed because there is no consumer of events for the given tenant connected to Hono, or the consumer didn\u0026rsquo;t process the event.    This is the preferred way for devices to publish events. It is available only if the protocol adapter is configured to require devices to authenticate (which is the default).\nExample\nPublish some JSON data for device 4711:\ncurl -i -u sensor1@DEFAULT_TENANT:hono-secret -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;alarm\u0026#34;: true}\u0026#39; http://127.0.0.1:8080/event HTTP/1.1 202 Accepted content-length: 0 Publish an Event (unauthenticated Device)  URI: /event/${tenantId}/${deviceId} Method: PUT Request Headers:  (required) content-type: The type of payload contained in the request body. (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) hono-ttl: The time-to-live in number of seconds for event messages.   Request Body:  (required) Arbitrary payload encoded according to the given content type.   Response Headers:  (optional) content-type: A media type describing the semantics and format of payload contained in the response body. This header will only be present if the response contains a command to be executed by the device which requires input data. (optional) hono-command: The name of the command to execute. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-req-id: An identifier that the device must include in its response to a command. This header will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 200. (optional) Error details, if status code is \u0026gt;= 400.   Status Codes:  200 (OK): The event has been accepted and put to a persistent store for delivery to consumers. The response contains a command for the device to execute. 202 (Accepted): The event has been accepted and put to a persistent store for delivery to consumers. 400 (Bad Request): The request cannot be processed. Possible reasons for this include:  The content type header is missing. The request body is empty but the event is not of type empty-notification.   403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter. The given device does not belong to the given tenant.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed because there is no consumer of events for the given tenant connected to Hono, or the consumer didn\u0026rsquo;t process the event.    This resource MUST be used by devices that have not authenticated to the protocol adapter. Note that this requires the HONO_HTTP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nPublish some JSON data for device 4711:\ncurl -i -X PUT -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;alarm\u0026#34;: true}\u0026#39; http://127.0.0.1:8080/event/DEFAULT_TENANT/4711 HTTP/1.1 202 Accepted content-length: 0 Publish an Event (authenticated Gateway)  URI: /event/${tenantId}/${deviceId} Method: PUT Request Headers:  (optional) authorization: The gateway\u0026rsquo;s auth-id and plain text password encoded according to the Basic HTTP authentication scheme. If not set, the adapter expects the gateway to present a client certificate as part of the TLS handshake during connection establishment. (required) content-type: The type of payload contained in the request body. (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) hono-ttl: The time-to-live in number of seconds for event messages.   Request Body:  (required) Arbitrary payload encoded according to the given content type.   Response Headers:  (optional) content-type: A media type describing the semantics and format of payload contained in the response body. This header will only be present if the response contains a command to be executed by the device which requires input data. (optional) hono-command: The name of the command to execute. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-req-id: An identifier that the device must include in its response to a command. This header will only be present if the response contains a command to be executed by the device. (optional) hono-cmd-target-device: The id of the device that shall execute the command. This header will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 200. (optional) Error details, if status code is \u0026gt;= 400.   Status Codes:  200 (OK): The event has been accepted and put to a persistent store for delivery to consumers. The response contains a command for the device to execute. 202 (Accepted): The event has been accepted and put to a persistent store for delivery to consumers. 400 (Bad Request): The request cannot be processed. Possible reasons for this include:  The content type header is missing. The request body is empty but the event is not of type empty-notification.   401 (Unauthorized): The request cannot be processed because the request does not contain valid credentials. 403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The tenant that the gateway belongs to is not allowed to use this protocol adapter. The device belongs to another tenant than the gateway. The gateway is not authorized to act on behalf of the device. The gateway associated with the device is not registered or disabled.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed because there is no consumer of events for the given tenant connected to Hono, or the consumer didn\u0026rsquo;t process the event.    This resource can be used by gateway components to publish data on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the parameters from the URI are used to identify the device that the gateway publishes data for.\nThe protocol adapter checks the gateway\u0026rsquo;s authority to publish data on behalf of the device implicitly by means of retrieving a registration assertion for the device from the configured Device Registration service.\nExamples\nPublish some JSON data for device 4712:\ncurl -i -X PUT -u gw@DEFAULT_TENANT:gw-secret -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://127.0.0.1:8080/event/DEFAULT_TENANT/4712 HTTP/1.1 202 Accepted content-length: 0 NB The example above assumes that a gateway device has been registered with hashed-password credentials with auth-id gw and password gw-secret which is authorized to publish data on behalf of device 4712.\nCommand \u0026amp; Control The HTTP adapter enables devices to receive commands that have been sent by business applications. Commands are delivered to the device by means of an HTTP response message. That means a device first has to send a request, indicating how long it will wait for the response. That request can either be a telemetry or event message, with a hono-ttd header or query parameter (ttd for time till disconnect) specifying the number of seconds the device will wait for the response. The business application can react on that message by sending a command message, targeted at the device. The HTTP adapter will then send the command message as part of the HTTP response message with status 200 (OK) to the device. If the HTTP adapter receives no command message in the given time period, a 202 (Accepted) response will be sent to the device (provided the request was valid).\nSpecifying the Time a Device will wait for a Response The adapter lets devices indicate the number of seconds they will wait for a response by setting a header or a query parameter.\nUsing an HTTP Header The (optional) hono-ttd header can be set in requests for publishing telemetry data or events.\nExample:\ncurl -i -u sensor1@DEFAULT_TENANT:hono-secret -H \u0026#39;content-type: application/json\u0026#39; -H \u0026#39;hono-ttd: 60\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://127.0.0.1:8080/telemetry HTTP/1.1 202 Accepted content-length: 0 Using a Query Parameter Alternatively the hono-ttd query parameter can be used:\ncurl -i -u sensor1@DEFAULT_TENANT:hono-secret -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; http://127.0.0.1:8080/telemetry?hono-ttd=60 HTTP/1.1 202 Accepted content-length: 0 Commands handled by gateways Authenticated gateways will receive commands for devices which do not connect to a protocol adapter directly but instead are connected to the gateway. Corresponding devices have to be configured so that they can be used with a gateway. See Configuring Gateway Devices for details.\nA gateway can send a request with the hono-ttd header or query parameter on the /event or /telemetry URI, indicating its readiness to receive a command for any device it acts on behalf of. Note that in this case, the business application will be notified with the gateway id in the device_id property of the downstream message.\nAn authenticated gateway can also indicate its readiness to receive a command targeted at a specific device. For that, the /event/${tenantId}/${deviceId} or /telemetry/${tenantId}/${deviceId} URI is to be used, containing the id of the device to receive a command for. The business application will receive a notification with that device id.\nIf there are multiple concurrent requests with a hono-ttd header or query parameter, sent by the command target device and/or one or more of its potential gateways, the HTTP adapter will choose the device or gateway to send the command to as follows:\n A request done by the command target device or by a gateway specifically done for that device, has precedence. If there are multiple, concurrent such requests, the last one will get the command message (if received) in its response. Note that the other requests won\u0026rsquo;t be answered with a command message in their response event if the business application sent multiple command messages. That means commands for a single device can only be requested sequentially, not in parallel. If the above doesn\u0026rsquo;t apply, a single hono-ttd request on the /event or /telemetry URI, sent by a gateway that the command target device is configured for, will get the command message in its response. If there are multiple, concurrent such requests by different gateways, all configured for the command target device, the request by the gateway will be chosen, through which the target device has last sent a telemetry or event message. If the target device hasn\u0026rsquo;t sent a message yet and it is thereby unknown via which gateway the device communicates, then one of the requests will be chosen randomly to set the command in its response.  Sending a Response to a Command (authenticated Device)  URI: /command/res/${commandRequestId} or /command/res/${commandRequestId}?hono-cmd-status=${status} Method: POST Request Headers:  (optional) authorization: The device\u0026rsquo;s auth-id and plain text password encoded according to the Basic HTTP authentication scheme. If not set, the adapter expects the device to present a client certificate as part of the TLS handshake during connection establishment. (optional) content-type: A media type describing the semantics and format of the payload contained in the request body. This header may be set if the result of processing the command on the device is non-empty. In this case the result data is contained in the request body. (optional) hono-cmd-status: The status of the command execution. If not set, the adapter expects that the URI contains it as request parameter at the end.   Request Body:  (optional) Arbitrary data representing the result of processing the command on the device.   Status Codes:  202 (Accepted): The response has been successfully delivered to the application that has sent the command. 400 (Bad Request): The request cannot be processed because the command status is missing. 401 (Unauthorized): The request cannot be processed because the request does not contain valid credentials. 403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no application listening for a reply to the given commandRequestId. The application has already given up on waiting for a response.      This is the preferred way for devices to respond to commands. It is available only if the protocol adapter is configured to require devices to authenticate (which is the default).\nExample\nSend a response to a previously received command with the command-request-id req-id-uuid for device 4711:\ncurl -i -u sensor1@DEFAULT_TENANT:hono-secret -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;brightness-changed\u0026#34;: true}\u0026#39; http://127.0.0.1:8080/command/res/req-id-uuid?hono-cmd-status=200 HTTP/1.1 202 Accepted content-length: 0 Sending a Response to a Command (unauthenticated Device)  URI: /command/res/${tenantId}/${deviceId}/${commandRequestId} or /command/res/${tenantId}/${deviceId}/${commandRequestId}?hono-cmd-status=${status} Method: PUT Request Headers:  (optional) content-type: A media type describing the semantics and format of the payload contained in the request body (the outcome of processing the command). (optional) hono-cmd-status: The status of the command execution. If not set, the adapter expects that the URI contains it as request parameter at the end.   Request Body:  (optional) Arbitrary data representing the result of processing the command on the device.   Status Codes:  202 (Accepted): The response has been successfully delivered to the application that has sent the command. 400 (Bad Request): The request cannot be processed because the command status is missing. 403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this might be:  The given tenant is not allowed to use this protocol adapter. The given device does not belong to the given tenant.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no application listening for a reply to the given commandRequestId. The application has already given up on waiting for a response.      This resource MUST be used by devices that have not authenticated to the protocol adapter. Note that this requires the HONO_HTTP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nSend a response to a previously received command with the command-request-id req-id-uuid for the unauthenticated device 4711:\ncurl -i -X PUT -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;brightness-changed\u0026#34;: true}\u0026#39; http://127.0.0.1:8080/command/res/DEFAULT_TENANT/4711/req-id-uuid?hono-cmd-status=200 HTTP/1.1 202 Accepted content-length: 0 Sending a Response to a Command (authenticated Gateway)  URI: /command/res/${tenantId}/${deviceId}/${commandRequestId} or /command/res/${tenantId}/${deviceId}/${commandRequestId}?hono-cmd-status=${status} Method: PUT Request Headers:  (optional) authorization: The gateway\u0026rsquo;s auth-id and plain text password encoded according to the Basic HTTP authentication scheme. If not set, the adapter expects the gateway to present a client certificate as part of the TLS handshake during connection establishment. (optional) content-type: A media type describing the semantics and format of the payload contained in the request body (the outcome of processing the command). (optional) hono-cmd-status: The status of the command execution. If not set, the adapter expects that the URI contains it as request parameter at the end.   Request Body:  (optional) Arbitrary data representing the result of processing the command on the device.   Status Codes:  202 (Accepted): The response has been successfully delivered to the application that has sent the command. 400 (Bad Request): The request cannot be processed because the command status is missing. 403 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this might be:  The given tenant is not allowed to use this protocol adapter. The given device does not belong to the given tenant. The gateway is not authorized to act on behalf of the device. The gateway associated with the device is not registered or disabled.   404 (Not Found): The request cannot be processed because the device is disabled or does not exist. 413 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 429 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 503 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no application listening for a reply to the given commandRequestId. The application has already given up on waiting for a response.      This resource can be used by gateway components to send the response to a command on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the parameters from the URI are used to identify the device that the gateway publishes data for.\nThe protocol adapter checks the gateway\u0026rsquo;s authority to send responses to a command on behalf of the device implicitly by means of retrieving a registration assertion for the device from the configured Device Registration service.\nExamples\nSend a response to a previously received command with the command-request-id req-id-uuid for device 4712:\ncurl -i -X PUT -u gw@DEFAULT_TENANT:gw-secret -H \u0026#39;content-type: application/json\u0026#39; --data-binary \u0026#39;{\u0026#34;brightness-changed\u0026#34;: true}\u0026#39; http://127.0.0.1:8080/command/res/DEFAULT_TENANT/4712/req-id-uuid?hono-cmd-status=200 HTTP/1.1 202 Accepted content-length: 0 NB The example above assumes that a gateway device has been registered with hashed-password credentials with auth-id gw and password gw-secret which is authorized to publish data on behalf of device 4712.\nDownstream Meta Data The adapter includes the following meta data in the application properties of messages being sent downstream:\n   Name Type Description     device_id string The identifier of the device that the message originates from.   orig_adapter string Contains the adapter\u0026rsquo;s type name which can be used by downstream consumers to determine the protocol adapter that the message has been received over. The HTTP adapter\u0026rsquo;s type name is hono-http.   orig_address string Contains the (relative) URI that the device has originally posted the data to.   ttd integer Contains the effective number of seconds that the device will wait for a response. This property is only set if the HTTP request contains the hono-ttd header or request parameter.    The adapter also considers defaults registered for the device at either the tenant or the device level. The values of the default properties are determined as follows:\n If the message already contains a non-empty property of the same name, the value if unchanged. Otherwise, if a default property of the same name is defined in the device\u0026rsquo;s registration information, that value is used. Otherwise, if a default property of the same name is defined for the tenant that the device belongs to, that value is used.  Note that of the standard AMQP 1.0 message properties only the content-type and ttl can be set this way to a default value.\nEvent Message Time-to-live Events published by devices will usually be persisted by the AMQP Messaging Network in order to support deferred delivery to downstream consumers. In most cases the AMQP Messaging Network can be configured with a maximum time-to-live to apply to the events so that the events will be removed from the persistent store if no consumer has attached to receive the event before the message expires.\nIn order to support environments where the AMQP Messaging Network cannot be configured accordingly, the protocol adapter supports setting a downstream event message\u0026rsquo;s ttl property based on the hono-ttl property set as a header or a query parameter in the event requests by the devices. Also the default ttl and max-ttl values can be configured for a tenant/device as described in the Tenant API.\nTenant specific Configuration The adapter uses the Tenant API to retrieve tenant specific configuration for adapter type hono-http. The following properties are (currently) supported:\n   Name Type Default Value Description     enabled boolean true If set to false the adapter will reject all data from devices belonging to the tenant.   max-ttd integer 60 Defines a tenant specific upper limit for the time until disconnect property that devices may include in requests for uploading telemetry data or events. Please refer to the Command \u0026amp; Control concept page for a discussion of this parameter\u0026rsquo;s purpose and usage.\nThis property can be set for the hono-http adapter type as an extension property in the adapter section of the tenant configuration.\nIf it is not set, then the default value of 60 seconds is used.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/mqtt-adapter/",
	"title": "MQTT Adapter",
	"tags": [],
	"description": "",
	"content": "The MQTT protocol adapter exposes an MQTT topic hierarchy for publishing telemetry data and events to downstream consumers and for receiving commands from applications and sending back responses.\nThe MQTT adapter is not a general purpose MQTT broker. In particular the adapter\n supports MQTT 3.1.1 only. does not maintain session state for clients and thus always sets the session present flag in its CONNACK packet to 0, regardless of the value of the clean session flag provided in a client\u0026rsquo;s CONNECT packet. ignores any Will included in a client\u0026rsquo;s CONNECT packet. only supports topic names/filters for devices to publish and subscribe to that are specific to Hono\u0026rsquo;s functionality as described in the following sections. does not support retaining messages. However, if an event or telemetry message\u0026rsquo;s retain flag is set to 1 then the corresponding AMQP 1.0 message being sent downstream by the adapter will contain an x-opt-retain message annotation containing the boolean value true. A downstream consumer may then react according to the presence of this annotation.  Authentication The MQTT adapter by default requires clients (devices or gateway components) to authenticate during connection establishment. The adapter supports both the authentication based on the username/password provided in an MQTT CONNECT packet as well as client certificate based authentication as part of a TLS handshake for that purpose.\nThe adapter tries to authenticate the device using these mechanisms in the following order\nClient Certificate When a device uses a client certificate for authentication during the TLS handshake, the adapter tries to determine the tenant that the device belongs to based on the issuer DN contained in the certificate. In order for the lookup to succeed, the tenant\u0026rsquo;s trust anchor needs to be configured by means of registering the trusted certificate authority. The device\u0026rsquo;s client certificate will then be validated using the registered trust anchor, thus implicitly establishing the tenant that the device belongs to. In a second step, the adapter uses the Credentials API\u0026rsquo;s get operation to retrieve the credentials on record, including the client certificate\u0026rsquo;s subject DN as the auth-id, x509-cert as the type of secret and the MQTT client identifier as client-id in the request payload.\nNB The adapter needs to be configured for TLS in order to support this mechanism.\nUsername/Password When a device wants to authenticate using this mechanism, it needs to provide a username and a password in the MQTT CONNECT packet it sends in order to initiate the connection. The username must have the form auth-id@tenant, e.g. sensor1@DEFAULT_TENANT. The adapter verifies the credentials provided by the client against the credentials that the configured Credentials service has on record for the client. The adapter uses the Credentials API\u0026rsquo;s get operation to retrieve the credentials on record, including the tenant and auth-id provided by the client in the username, hashed-password as the type of secret and the MQTT client identifier as client-id in the request payload.\nThe examples below refer to devices 4711 and gw-1 of tenant DEFAULT_TENANT using auth-ids sensor1 and gw1 and corresponding passwords. The example deployment as described in the Deployment Guides comes pre-configured with the corresponding entities in its device registry component.\nNB There is a subtle difference between the device identifier (device-id) and the auth-id a device uses for authentication. See Device Identity for a discussion of the concepts.\nResource Limit Checks The adapter performs additional checks regarding resource limits when a client tries to connect and/or send a message to the adapter.\nConnection Limits The adapter rejects a client’s connection attempt with return code\n 0x03 (Connection Refused: server unavailable), if the maximum number of connections per protocol adapter instance is reached 0x05 (Connection Refused: not authorized), if the maximum number of simultaneously connected devices for the tenant is reached.  Connection Duration Limits The adapter rejects a client’s connection attempt with return code 0x05 (Connection Refused: not authorized), if the connection duration limit that has been configured for the client’s tenant is exceeded.\nMessage Limits The adapter\n rejects a client\u0026rsquo;s connection attempt with return code 0x05 (Connection Refused: not authorized), discards any MQTT PUBLISH packet containing telemetry data or an event that is sent by a client and rejects any AMQP 1.0 message containing a command sent by a north bound application  if the message limit that has been configured for the device’s tenant is exceeded.\nConnection Events The adapter can emit Connection Events for client connections being established and/or terminated. Please refer to the common configuration options for details regarding how to enable this behavior.\nThe adapter includes the client identifier from the client\u0026rsquo;s MQTT CONNECT packet as the Connection Event\u0026rsquo;s remote-id.\nPublishing Telemetry Data The MQTT adapter supports the publishing of telemetry data by means of MQTT PUBLISH packets using either QoS 0 or QoS 1. Using QoS 1 will result in the adapter sending an MQTT PUBACK packet to the client once the message has been settled with the accepted outcome by the AMQP 1.0 Messaging Network.\nThis requires that\n the AMQP 1.0 Messaging Network has capacity to process telemetry messages for the client\u0026rsquo;s tenant and the messages published by the client comply with the format defined by the Telemetry API.  The protocol adapter checks the configured message limit before accepting any telemetry messages. An exceeded message limit will cause an error.\nAny kind of error when processing an incoming telemetry message will be reported back to the client if the client has subscribed on a dedicated error topic. See Error Reporting via Error Topic for details.\nIf such an error subscription by the client exists, the error will by default be ignored after it got published on the error topic, otherwise the connection to the client will be closed. The handling of errors can further be controlled by means of an on-error property bag parameter set on the telemetry message topic. Refer to Error Handling for details.\nThe devices can optionally indicate the content type of the payload by setting the content-type property explicitly in the property-bag. The property-bag is an optional collection of properties intended for the receiver of the message. A property bag is only allowed at the very end of a topic. It always starts with a /? character, followed by pairs of URL encoded property names and values that are separated by \u0026amp;. For example, a property bag containing two properties seqNo and importance looks like this: /topic/name/?seqNo=10034\u0026amp;importance=high.\nPublish Telemetry Data (authenticated Device)  Topic: telemetry or t Authentication: required Payload:  (required) Arbitrary payload    This is the preferred way for devices to publish telemetry data. It is available only if the protocol adapter is configured to require devices to authenticate (which is the default). When using this topic, the MQTT adapter determines the device\u0026rsquo;s tenant and device identity as part of the authentication process.\nExample\nPublish some JSON data for device 4711:\nmosquitto_pub -u \u0026#39;sensor1@DEFAULT_TENANT\u0026#39; -P hono-secret -t telemetry -m \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish some JSON data for device 4711 using a client certificate for authentication:\n# in base directory of Hono repository: mosquitto_pub -p 8883 -t telemetry -m \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; --cert demo-certs/certs/device-4711-cert.pem --key demo-certs/certs/device-4711-key.pem --cafile demo-certs/certs/trusted-certs.pem NB The example above assumes that the MQTT adapter is configured for TLS and the secure port is used.\nPublish Telemetry Data (unauthenticated Device)  Topic: telemetry/${tenant-id}/${device-id} or t/${tenant-id}/${device-id} Authentication: none Payload:  (required) Arbitrary payload    This topic can be used by devices that have not authenticated to the protocol adapter. Note that this requires the HONO_MQTT_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nPublish some JSON data for device 4711:\nmosquitto_pub -t telemetry/DEFAULT_TENANT/4711 -m \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish Telemetry Data (authenticated Gateway)  Topic: telemetry/${tenant-id}/${device-id} or t/${tenant-id}/${device-id} Authentication: required Payload:  (required) Arbitrary payload    This topic can be used by gateway components to publish data on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the parameters from the topic name are used to identify the device that the gateway publishes data for.\nThe protocol adapter checks the gateway\u0026rsquo;s authority to publish data on behalf of the device implicitly by means of retrieving a registration assertion for the device from the configured Device Registration service.\nExamples\nPublish some JSON data for device 4712 via gateway gw-1:\nmosquitto_pub -u \u0026#39;gw@DEFAULT_TENANT\u0026#39; -P gw-secret -t telemetry/DEFAULT_TENANT/4712 -m \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; NB The example above assumes that a gateway device with ID gw-1 has been registered with hashed-password credentials with auth-id gw and password gw-secret.\nPublishing Events The MQTT adapter supports the publishing of events by means of MQTT PUBLISH packets using QoS 1 only. The adapter will send an MQTT PUBACK packet to the client once the event has been settled with the accepted outcome by the AMQP 1.0 Messaging Network.\nThis requires that\n the AMQP 1.0 Messaging Network has capacity to process events for the client\u0026rsquo;s tenant and the events published by the client comply with the format defined by the Event API.  The protocol adapter checks the configured message limit before accepting any event messages. An exceeded message limit will cause an error.\nAny kind of error when processing an incoming event message will be reported back to the client if the client has subscribed on a dedicated error topic. See Error Reporting via Error Topic for details.\nIf such an error subscription by the client exists, the error will by default be ignored after it got published on the error topic, otherwise the connection to the client will be closed. The handling of errors can further be controlled by means of an on-error property bag parameter set on the event message topic. Refer to Error Handling for details.\nThe devices can optionally indicate a time-to-live duration for event messages and the content type of the payload by setting the hono-ttl and content-type properties explicitly in the property-bag. The property-bag is an optional collection of properties intended for the receiver of the message. A property bag is only allowed at the very end of a topic. It always starts with a /? character, followed by pairs of URL encoded property names and values that are separated by \u0026amp;. For example, a property bag containing two properties seqNo and importance looks like this: /topic/name/?seqNo=10034\u0026amp;importance=high.\nThe MQTT adapter currently does not use any properties except hono-ttl.\nPublish an Event (authenticated Device)  Topic: event or e Authentication: required Payload:  (required) Arbitrary payload    This is the preferred way for devices to publish events. It is available only if the protocol adapter has been configured to require devices to authenticate (which is the default).\nExample\nUpload a JSON string for device 4711:\nmosquitto_pub -u \u0026#39;sensor1@DEFAULT_TENANT\u0026#39; -P hono-secret -t event -q 1 -m \u0026#39;{\u0026#34;alarm\u0026#34;: 1}\u0026#39; Upload a JSON string for device 4711 with time-to-live as 10 seconds:\nmosquitto_pub -u \u0026#39;sensor1@DEFAULT_TENANT\u0026#39; -P hono-secret -t event/?hono-ttl=10 -q 1 -m \u0026#39;{\u0026#34;alarm\u0026#34;: 1}\u0026#39; Publish an Event (unauthenticated Device)  Topic: event/${tenant-id}/${device-id} or e/${tenant-id}/${device-id} Authentication: none Payload:  (required) Arbitrary payload    This topic can be used by devices that have not authenticated to the protocol adapter. Note that this requires the HONO_MQTT_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nPublish some JSON data for device 4711:\nmosquitto_pub -t event/DEFAULT_TENANT/4711 -q 1 -m \u0026#39;{\u0026#34;alarm\u0026#34;: 1}\u0026#39; Publish some JSON data for device 4711 with time-to-live as 15 seconds:\nmosquitto_pub -t event/DEFAULT_TENANT/4711/?hono-ttl=15 -q 1 -m \u0026#39;{\u0026#34;alarm\u0026#34;: 1}\u0026#39; Publish an Event (authenticated Gateway)  Topic: event/${tenant-id}/${device-id} or e/${tenant-id}/${device-id} Authentication: required Payload:  (required) Arbitrary payload    This topic can be used by gateway components to publish data on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the parameters from the topic name are used to identify the device that the gateway publishes data for.\nThe protocol adapter checks the gateway\u0026rsquo;s authority to publish data on behalf of the device implicitly by means of retrieving a registration assertion for the device from the configured Device Registration service.\nExamples\nPublish some JSON data for device 4712 via gateway gw-1:\nmosquitto_pub -u \u0026#39;gw@DEFAULT_TENANT\u0026#39; -P gw-secret -t event/DEFAULT_TENANT/4712 -q 1 -m \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; NB The example above assumes that a gateway device with ID gw-1 has been registered with hashed-password credentials with auth-id gw and password gw-secret.\nCommand \u0026amp; Control The MQTT adapter enables devices to receive commands that have been sent by business applications by means of sending an MQTT SUBSCRIBE packet containing a device specific topic filter as described below. Devices can subscribe with QoS 1 or QoS 0. The adapter indicates the outcome of the subscription request by sending back a corresponding SUBACK packet. The SUBACK packet will contain Success - QoS 0 (0x00) or Success - QoS 1 (0x01) for a valid command topic filter indicating QoS 0 or 1 and will contain the Failure (0x80) value for an invalid or unsupported filter. When a device no longer wants to receive commands anymore, it can send an MQTT UNSUBSCRIBE packet to the adapter, including the same topic filter that has been used to subscribe.\nWhen a device has successfully subscribed, the adapter sends an empty notification on behalf of the device to the downstream AMQP 1.0 Messaging Network with the ttd header set to -1, indicating that the device will be ready to receive commands until further notice. Analogously, the adapter sends an empty notification with the ttd header set to 0 when a device unsubscribes from commands.\nCommands can be sent following a request/response pattern or being one-way.\nFor Request/Response commands, devices send their responses to commands by means of sending an MQTT PUBLISH message to a topic that is specific to the command that has been executed. The MQTT adapter accepts responses being published using either QoS 0 or QoS 1.\nThe MQTT adapter checks the configured message limit before accepting any command requests and responses. In case of incoming command requests from business applications, if the message limit is exceeded, the Adapter rejects the message with the reason amqp:resource-limit-exceeded. And for the incoming command responses from devices, the Adapter rejects the message and closes the connection to the client.\nThe following sections define the topic filters/names to use for subscribing to and responding to commands. The following shorthand versions of topic path segments are supported:\n c instead of command q instead of req s instead of res  The following variables are used:\n ${command} : An arbitrary string that indicates the command to execute, e.g. setBrightness. The command is provided by the application that sends the command. ${req-id} (only for Request/Response commands) : The unique identifier of the command execution request. The identifier is passed to the device as part of the name of the topic that the command is published to. The device needs to publish its response to the command to a topic which includes this identifier, thus allowing the adapter to correlate the response with the request. ${status} : The HTTP status code indicating the outcome of executing the command. This status code is passed on to the application in the AMQP message\u0026rsquo;s status application property.   Wild card characters in topic filters The topic filters defined below make use of MQTT\u0026rsquo;s wild card characters in certain places of topic filters. However, the MQTT adapter does not support the general usage of wild card characters in topic filters in any other way than defined below.  Receiving Commands (authenticated Device) An authenticated device MUST use the following topic filter for subscribing to commands:\ncommand/[${tenant-id}]/[${device-id}]/req/#\nBoth the tenant and the device ID are optional. If specified, they MUST match the authenticated device\u0026rsquo;s tenant and/or device ID. Note that the authentication identifier used in the device\u0026rsquo;s credentials is not necessarily the same as the device ID.\nThe protocol adapter will publish commands for the device to the following topic names\n one-way command/${tenant-id}/${device-id}/req//${command} request-response command/${tenant-id}/${device-id}/req/${req-id}/${command}  The tenant-id and/or device-id will be included in the topic name if the tenant and/or device ID had been included in the topic filter used for subscribing to commands.\n Deprecation Previous versions of Hono required authenticated devices to use command/+/+/req/# for subscribing to commands. This old topic filter is deprecated. Devices MAY still use it until support for it will be removed in a future Hono version.  Examples\nThe following command can be used to subscribe to commands resulting in command messages being published to a topic that does not include tenant nor device ID:\nmosquitto_sub -v -u \u0026#39;sensor1@DEFAULT_TENANT\u0026#39; -P hono-secret -t command///req/# A request/response command with name setBrightness from an application might look like this:\ncommand///req/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/setBrightness { \u0026#34;brightness\u0026#34;: 79 } A corresponding one-way command might look like this:\ncommand///req//setBrightness { \u0026#34;brightness\u0026#34;: 79 } Note that the topic in the latter case doesn\u0026rsquo;t contain a request identifier.\nThe following command can be used to subscribe to commands resulting in command messages being published to a topic that includes the tenant ID:\nmosquitto_sub -v -u \u0026#39;sensor1@DEFAULT_TENANT\u0026#39; -P hono-secret -t c/DEFAULT_TENANT//q/# Note the usage of the abbreviated names (c and q instead of command and req) and the inclusion of the tenant ID in the topic filter.\nA corresponding request/response command with name setBrightness from an application might look like this:\nc/DEFAULT_TENANT//q/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/setBrightness { \u0026#34;brightness\u0026#34;: 79 } A corresponding one-way command might look like this:\nc/DEFAULT_TENANT//q//setBrightness { \u0026#34;brightness\u0026#34;: 79 } Note that the topic also includes the abbreviated names and the tenant identifier because the topic filter used for subscribing did contain the tenant ID as well.\nReceiving Commands (unauthenticated Device) An unauthenticated device MUST use the topic filter command/${tenant-id}/${device-id}/req/# to subscribe to commands.\nExample\nmosquitto_sub -v -t command/DEFAULT_TENANT/4711/req/# The adapter will then publish Request/Response commands for the device to topic command/${tenant-id}/${device-id}/req/${req-id}/${command} and one-way commands to topic command/${tenant-id}/${device-id}/req//${command}.\nFor example, a request/response command with name setBrightness from an application might look like this:\ncommand/DEFAULT_TENANT/4711/req/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/setBrightness { \u0026#34;brightness\u0026#34;: 79 } A corresponding one-way command might look like this:\ncommand/DEFAULT_TENANT/4711/req//setBrightness { \u0026#34;brightness\u0026#34;: 79 } Note that the topic in the latter case doesn\u0026rsquo;t contain a request identifier.\nReceiving Commands (authenticated Gateway) Gateway components can receive commands for devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. Corresponding devices have to be configured so that they can be used with a gateway. See Configuring Gateway Devices for details.\nAn authenticated gateway MUST use one of the following topic filters for subscribing to commands:\n   Topic Filter Description     command//+/req/# Subscribe to commands for all devices that the gateway is authorized to act on behalf of.   command/${tenant-id}/+/req/# Subscribe to commands for all devices that the gateway is authorized to act on behalf of.   command//${device-id}/req/# Subscribe to commands for a specific device that the gateway is authorized to act on behalf of.   command/${tenant-id}/${device-id}/req/# Subscribe to commands for a specific device that the gateway is authorized to act on behalf of.    The protocol adapter will publish commands for devices to the following topic names\n one-way command//${device-id}/req//${command} or command/${tenant-id}/${device-id}/req//${command} request-response command//${device-id}/req/${req-id}/${command} or command/${tenant-id}/${device-id}/req/${req-id}/${command}  The ${tenant-id} will be included in the topic name if the tenant ID had been included in the topic filter used for subscribing to commands.\n Deprecation Previous versions of Hono required authenticated gateways to use command/+/+/req/# for subscribing to commands. This old topic filter is deprecated. Gateways MAY still use it until support for it will be removed in a future Hono version.  When processing an incoming command message, the protocol adapter will give precedence to a device-specific command subscription matching the command target device, whether the subscription comes from a gateway or the device itself. If there are multiple such subscriptions from multiple gateways and/or from the device itself, the subscription initiated last will get the command messages.\nIf no device-specific command subscription exists for a command target device, but one gateway, that may act on behalf of the device, has subscribed to commands for all its devices, then the command message is sent to that gateway.\nIf multiple gateways have initiated such generic subscriptions, the protocol adapter may have to decide to which gateway a particular command message will be sent to. In case the command target device has already sent a telemetry, event or command response message via a gateway and if that gateway has created such a command subscription, that gateway will be chosen. Otherwise one gateway that may act on behalf of the command target device and that has an open subscription will be chosen randomly to receive the command message.\nSubscribe to all Devices\nA subscription to commands for all devices that a gateway acts on behalf of looks like this:\nmosquitto_sub -v -u \u0026#39;gw@DEFAULT_TENANT\u0026#39; -P gw-secret -t command/DEFAULT_TENANT/+/req/# A request/response command for device 4711 with name setBrightness from an application might then look like this:\ncommand/DEFAULT_TENANT/4711/req/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/setBrightness { \u0026#34;brightness\u0026#34;: 79 } Note that the tenant identifier is included in the topic name that the command has been published to because it had been included in the topic filter used for subscribing to the commands.\nSubscribe to a specific Device\nA subscription to commands for a specific device can be done like this:\nmosquitto_sub -v -u \u0026#39;gw@DEFAULT_TENANT\u0026#39; -P gw-secret -t c//4711/q/# Note the usage of the abbreviated names (c and q instead of command and req) in the topic filter.\nA corresponding one-way command might look like this:\nc//4711/q//setBrightness { \u0026#34;brightness\u0026#34;: 79 } Note that the topic also includes the abbreviated names and does not include the tenant identifier because the topic filter used for subscribing did not contain the tenant ID either.\nSending a Response to a Command (authenticated Device) An authenticated device MUST send the response to a previously received command to the topic command///res/${req-id}/${status}.\nExample\nAfter a command has arrived as in the above example, you send a response using the arrived ${req-id}:\nmosquitto_pub -u \u0026#39;sensor1@DEFAULT_TENANT\u0026#39; -P hono-secret -t command///res/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/200 -m \u0026#39;{\u0026#34;lumen\u0026#34;: 200}\u0026#39; Sending a Response to a Command (unauthenticated Device) An unauthenticated device MUST send the response to a previously received command to the topic command/${tenant-id}/${device-id}/res/${req-id}/${status}.\nExample\nAfter a command has arrived as in the above example, you send a response using the arrived ${req-id}:\nmosquitto_pub -t command/DEFAULT_TENANT/4711/res/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/200 -m \u0026#39;{\u0026#34;lumen\u0026#34;: 200}\u0026#39; Sending a Response to a Command (authenticated Gateway) An authenticated gateway MUST send a device\u0026rsquo;s response to a command it has received on behalf of the device to the topic command//${device-id}/res/${req-id}/${status}.\nExample\nAfter a command has arrived as in the above example, the response is sent using the ${req-id} from the topic that the command had been published to:\nmosquitto_pub -u \u0026#39;gw@DEFAULT_TENANT\u0026#39; -P gw-secret -t command//4711/res/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/200 -m \u0026#39;{\u0026#34;lumen\u0026#34;: 200}\u0026#39; Error Reporting via Error Topic The default behaviour when an error occurs while publishing telemetry, event or command response messages is for the MQTT adapter to close the network connection to the device, as mandated by the MQTT 3.1.1 spec.\nAn alternative way of dealing with errors involves keeping the connection intact and letting the MQTT adapter publish a corresponding error message on a specific error topic to the device. To enable that behaviour, the device sends an MQTT SUBSCRIBE packet with a topic filter as described below on the same MQTT connection that is also used for publishing the telemetry, event or command response messages. Devices can subscribe with QoS 0 only. The adapter indicates the outcome of the subscription request by sending back a corresponding SUBACK packet. The SUBACK packet will contain Success - QoS 0 (0x00) for a valid error topic filter and will contain the Failure (0x80) value for an invalid or unsupported filter. In order to again activate the default error handling behaviour, the device can send an MQTT UNSUBSCRIBE packet to the adapter, including the same topic filter that has been used to subscribe.\nThe following sections define the topic filters to use for subscribing to error messages and the resulting error message topic. Instead of the error topic path segment, the shorthand version e is also supported.\nThe following variables are used:\n ${endpoint-type}: The endpoint type of the device message that caused the error. Its value is either telemetry, event or the respective shorthand version. In case of a command response device message command-response or c-s is used. ${correlation-id}: The identifier that may be used to correlate the error message with the device message that caused the error. The identifier is either the value of a correlation-id property bag value contained in the device message topic, or the identifier is the packet-id of the device message if it was sent with QoS 1. Otherwise, a value of -1 is used. ${error-status}: The HTTP status code of the error that was caused by the device message.   Examples Since the subscription on the error topic needs to be done on the same MQTT connection that is also used for publishing the telemetry, event or command response messages, the Mosquitto MQTT Command Line Client cannot be used. The MQTT CLI tool with its shell mode is an alternative that supports using one MQTT connection for both subscribing and publishing.  Receiving Error Messages (authenticated Device) An authenticated device MUST use the following topic filter for subscribing to error messages:\nerror/[${tenant-id}]/[${device-id}]/#\nBoth the tenant and the device ID are optional. If specified, they MUST match the authenticated device\u0026rsquo;s tenant and/or device ID. Note that the authentication identifier used in the device\u0026rsquo;s credentials is not necessarily the same as the device ID.\nThe protocol adapter will publish error messages for the device to the following topic name\nerror/[${tenant-id}]/[${device-id}]/${endpoint-type}/${correlation-id}/${error-status}\nThe tenant-id and/or device-id will be included in the topic name if the tenant and/or device ID had been included in the topic filter used for subscribing to error messages.\nExample\nAn example using the MQTT CLI that will produce an error output provided there is no downstream consumer for the device messages.\nmqtt shell con -V 3 -h [MQTT_ADAPTER_IP] -u [DEVICE]@[TENANT] -pw [PWD] sub -t error///# --qos 0 --outputToConsole pub -t telemetry -m \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; --qos 1 Using an explicit correlation id:\npub -t telemetry/?correlation-id=123 -m \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; --qos 1 Receiving Error Messages (unauthenticated Device) An unauthenticated device MUST use the following topic filter for subscribing to error messages:\nerror/${tenant-id}/${device-id}/#\nThe protocol adapter will publish error messages for the device to the following topic name\nerror/${tenant-id}/${device-id}/${endpoint-type}/${correlation-id}/${error-status}\nReceiving Error Messages (authenticated Gateway) An authenticated gateway MUST use one of the following topic filters for subscribing to error messages:\n   Topic Filter Description     error//+/#error/${tenant-id}/+/# Subscribe to error messages for all devices that the gateway is authorized to act on behalf of.   error//${device-id}/#error/${tenant-id}/${device-id}/# Subscribe to error messages for a specific device that the gateway is authorized to act on behalf of.    The protocol adapter will publish error messages for the device to the following topic name\nerror/[${tenant-id}]/[${device-id}]/${endpoint-type}/${correlation-id}/${error-status}\nThe tenant-id and/or device-id will be included in the topic name if the tenant and/or device ID had been included in the topic filter used for subscribing to error messages.\nError Message Payload The MQTT adapter publishes error messages with a UTF-8 encoded JSON payload containing the following fields:\n   Name Mandatory JSON Type Description     code yes number The HTTP error status code. See the table below for possible values.   message yes string The error detail message.   timestamp yes string The date and time the error message was published by the MQTT adapter. The value is an ISO 8601 compliant combined date and time representation in extended format.   correlation-id yes string The identifier that may be used to correlate the error message with the device message that caused the error. The identifier is either the value of a correlation-id property bag value contained in the device message topic, or the identifier is the packet-id of the device message if it was sent with QoS 1. Otherwise a value of -1 is used.    The error message\u0026rsquo;s code field may contain the following HTTP status codes:\n   Code Description     400 Bad Request, the request cannot be processed. A possible reason for this is an invalid PUBLISH topic.   403 Forbidden, the device\u0026rsquo;s registration status cannot be asserted.   404 Not Found, the device is disabled or does not exist.   413 Request Entity Too Large, the request body exceeds the maximum supported size.   429 Too Many Requests, the tenant\u0026rsquo;s message limit for the current period is exceeded.   503 Service Unavailable, the request cannot be processed. Possible reasons for this include:There is no consumer of telemetry data for the given tenant connected to Hono, or the consumer has not indicated that it may receive further messages (not giving credits). If the QoS level header is set to 1 (at least once semantics), the reason may be: The consumer has indicated that it didn\u0026rsquo;t process the telemetry data. The consumer failed to indicate in time whether it has processed the telemetry data.    Example payload:\n{ \u0026#34;code\u0026#34;: 400, \u0026#34;message\u0026#34;: \u0026#34;malformed topic name\u0026#34;, \u0026#34;timestamp\u0026#34;: \u0026#34;2020-12-24T19:00:00+0100\u0026#34;, \u0026#34;correlation-id\u0026#34;: \u0026#34;5\u0026#34; } Error Handling When a device publishes a telemetry, event or command response message and there is an error processing the message, the handling of the error depends on whether there is a error topic subscription for the device and whether a on-error property bag parameter was set on the topic used for sending the message.\nIf no error subscription is in place and no on-error parameter was set, the default error handling behaviour is to close the MQTT connection to the device. If the device has a subscription on the error topic (on the same MQTT connection the device uses for sending messages), the default behaviour is to keep the MQTT connection open unless a terminal error happens. The errors that are classified as terminal are listed below.\n The adapter is disabled for the tenant that the client belongs to. The authenticated device or gateway is disabled or not registered. The tenant is disabled or does not exist.   Note When a terminal error occurs, the connection will always be closed irrespective of any on-error parameter or error subscription.  The following table lists the different behaviours based on the value of the on-error property bag parameter and the existence of an error subscription:\n   on-error topic parameter Error subscription exists Description     default or value not set no The connection to the device will get closed (like with the disconnect option).   disconnect no The connection to the device will get closed.   ignore no The error will be ignored and a PUBACK for the message that caused the error will get sent.   skip-ack no The error will be ignored and no PUBACK for the message that caused the error will get sent.   default or value not set yes After having sent an error message on the error topic, the error will be ignored and a PUBACK for the message that caused the error will get sent (like with the ignore option).   disconnect yes After having sent an error message on the error topic, the connection to the device will get closed.   ignore yes After having sent an error message on the error topic, the error will be ignored and a PUBACK for the message that caused the error will get sent.   skip-ack yes After having sent an error message on the error topic, the error will be ignored and no PUBACK for the message that caused the error will get sent.    Example\nAn authenticated device wanting to have errors always be ignored can for example publish telemetry messages on this topic:\ntelemetry/?on-error=ignore\nCustom Message Mapping This protocol adapter supports transformation of messages that have been uploaded by devices before they get forwarded to downstream consumers.\n Experimental This is an experimental feature. The names of the configuration properties, potential values and the overall functionality are therefore subject to change without prior notice.  This feature is useful in scenarios where devices are connected to the adapter via a gateway but the gateway is not able to include the device ID in the topic that the gateway publishes data to. The gateway will use the plain telemetry or event topics in this case. The message payload will usually contain the identifier of the device that the data originates from.\nThe same functionality can also be used to transform the payload of messages uploaded by a device. This can be used for example to transform binary encoded data into a JSON document which can be consumed more easily by downstream consumers.\nThe mechanism works as follows:\n  A client uploads a message to the MQTT adapter.\n  The adapter invokes the Device Registration service\u0026rsquo;s assert Registration operation using either the authenticated device\u0026rsquo;s identifier, if the topic does not contain a device ID, or the device ID from the topic.\n  If the assertion succeeds, the adapter creates the downstream message using the original message\u0026rsquo;s payload and the asserted device ID as the origin device.\n  If the assert Registration response payload contains a value for the mapper property, the adapter tries to find a mapper endpoint configuration for the given value. If a mapper endpoint with a matching name has been configured for the adapter,\n the adapter sends an HTTP request to the endpoint which contains the original message\u0026rsquo;s payload in the request body. If the response body is not empty, it is used as the downstream message\u0026rsquo;s payload, replacing the original payload. If the response contains a device_id header and its value is different from the original device ID, then the adapter invokes the assert Registration operation again, this time using the mapped device ID instead of the original device ID. If the assertion succeeds, the adapter uses the asserted (mapped) device ID for the downstream message.    The adapter forwards the downstream message.\n  Please refer to the Device Registry Management API for how to register a mapper for a device. Please refer to the MQTT Adapter Admin Guide for how to configure custom mapper endpoints.\nDownstream Meta Data The adapter includes the following meta data in messages being sent downstream:\n   Name Location Type Description     device_id application string The identifier of the device that the message originates from.   orig_adapter application string Contains the adapter\u0026rsquo;s type name which can be used by downstream consumers to determine the protocol adapter that the message has been received over. The MQTT adapter\u0026rsquo;s type name is hono-mqtt.   orig_address application string Contains the name of the MQTT topic that the device has originally published the data to.   x-opt-retain message-annotations boolean Contains true if the device has published an event or telemetry message with its retain flag set to 1    The adapter also considers defaults registered for the device at either the tenant or the device level. The values of the default properties are determined as follows:\n If the message already contains a non-empty property of the same name, the value if unchanged. Otherwise, if a default property of the same name is defined in the device\u0026rsquo;s registration information, that value is used. Otherwise, if a default property of the same name is defined for the tenant that the device belongs to, that value is used.  Note that of the standard AMQP 1.0 message properties only the content-type and ttl can be set this way to a default value.\nEvent Message Time-to-live Events published by devices will usually be persisted by the AMQP Messaging Network in order to support deferred delivery to downstream consumers. In most cases the AMQP Messaging Network can be configured with a maximum time-to-live to apply to the events so that the events will be removed from the persistent store if no consumer has attached to receive the event before the message expires.\nIn order to support environments where the AMQP Messaging Network cannot be configured accordingly, the MQTT protocol adapter supports setting a downstream event message\u0026rsquo;s ttl property based on the hono-ttl property set as property-bag at the end of the event topic. Also the default ttl and max-ttl values can be configured for a tenant/device as described in the Tenant API.\nTenant specific Configuration The adapter uses the Tenant API to retrieve tenant specific configuration for adapter type hono-mqtt. The following properties are (currently) supported in the Adapter object:\n   Name Type Default Value Description     enabled boolean true If set to false the adapter will reject all data from devices belonging to the tenant.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/amqp-adapter/",
	"title": "AMQP Adapter",
	"tags": [],
	"description": "",
	"content": "The AMQP protocol adapter allows clients (devices or gateway components) supporting the AMQP 1.0 protocol to publish messages to Eclipse Hono™\u0026rsquo;s Telemetry, Event and Command \u0026amp; Control endpoints.\nDevice Authentication By default, all Hono protocol adapters require clients (devices or gateway components) to authenticate during connection establishment. This is the preferred way for devices to publish data via protocol adapters. The AMQP adapter supports both the SASL PLAIN and SASL EXTERNAL authentication mechanisms. The former uses a username and password to authenticate to the adapter while the latter uses an X.509 client certificate.\nThis guide provides examples for publishing telemetry and events for authenticated (using SASL PLAIN) and unauthenticated clients.\nNB The AMQP adapter can be configured to allow unauthenticated devices to connect by setting configuration variable HONO_AMQP_AUTHENTICATION_REQUIRED to false.\nSASL PLAIN Authentication The AMQP adapter supports authenticating clients using a username and password. This means that clients need to provide a username and a password when connecting to the AMQP adapter. The username must match the pattern [auth-id@tenant], e.g. sensor1@DEFAULT_TENANT.\nThe adapter verifies the credentials provided by the client against the credentials that the configured Credentials service has on record for the client. If the credentials match, the client device can proceed to publish messages to Hono.\nThe examples below refer to devices 4711 and gw-1 of tenant DEFAULT_TENANT using auth-ids sensor1 and gw1 and corresponding passwords. The example deployment as described in the Deployment Guide comes pre-configured with the corresponding entities in its device registry component.\nNB There is a subtle difference between the device identifier (device-id) and the auth-id a device uses for authentication. See Device Identity for a discussion of the concepts.\nSASL EXTERNAL Authentication When a device uses a client certificate for authentication, the TLS handshake is initiated during TCP connection establishment. If no trust anchor is configured for the AMQP adapter, the TLS handshake will succeed only if the certificate has not yet expired. Once the TLS handshake completes and a secure connection is established, the certificate\u0026rsquo;s signature is checked during the SASL handshake. To complete the SASL handshake and authenticate the client, the adapter performs the following steps:\n The adapter extracts the client certificate\u0026rsquo;s Issuer DN from the client certificate The adapter invokes the Tenant service to look up the tenant matching the DN. In order for the lookup to succeed, the tenant’s trust anchor needs to be configured by means of registering the trusted certificate authority. If the lookup succeeds, the tenant returned by the Tenant service is the tenant that the device belongs to. The adapter verifies the device’s client certificate\u0026rsquo;s signature using the trust anchor registered for the tenant. Finally, the adapter authenticates the client certificate using Hono\u0026rsquo;s credentials API. In this step, the adapter uses the client certificate’s Subject DN (as authentication identifier) and x509-cert (for the credentials type) in order to determine the device ID.  NB The AMQP adapter needs to be configured for TLS in order to support this mechanism.\nResource Limit Checks The adapter performs additional checks regarding resource limits when a client tries to connect and/or send a message to the adapter.\nConnection Limits The adapter immediately closes a newly established connection with an amqp:unauthorized-access error if\n the maximum number of connections per protocol adapter instance is reached, or if the maximum number of simultaneously connected devices for the client\u0026rsquo;s tenant is reached.  Please refer to resource-limits for details.\nConnection Duration Limits The adapter immediately closes a newly established connection with an amqp:unauthorized-access error if the connection duration limit that has been configured for the client\u0026rsquo;s tenant is exceeded.\nMessage Limits The adapter\n immediately closes a newly established connection with an amqp:unauthorized-access error and rejects any AMQP 1.0 message containing  telemetry data or an event uploaded by a client a command sent by a north bound application    if the message limit that has been configured for the device\u0026rsquo;s tenant is exceeded.\nConnection Events The adapter can emit Connection Events for client connections being established and/or terminated. Please refer to the common configuration options for details regarding how to enable this behavior.\nThe adapter includes the client\u0026rsquo;s AMQP container-id as the Connection Event\u0026rsquo;s remote-id.\nLink Establishment The AMQP adapter supports the Anonymous Terminus for Message Routing specification and requires clients to create a single sender link using the null target address for publishing all types of messages to the AMQP adapter.\nUsing AT MOST ONCE delivery semantics, the client will not wait for the message to be accepted and settled by the downstream consumer. However, with AT LEAST ONCE, the client sends the message and waits for the message to be delivered to and accepted by the downstream consumer. If the message cannot be delivered due to a failure, the client will be notified.\nThe client indicates its preferred message delivery mode by means of the snd-settle-mode and rcv-settle-mode fields of its attach frame during link establishment. Clients should use mixed as the snd-settle-mode and first as the rcv-settle-mode in order to be able to use the same link for sending all types of messages using different delivery semantics as described in the following sections.\nError Handling The AMQP adapter distinguishes between two types of errors when a message is published using AT LEAST ONCE delivery semantics:\n An error caused by the client side, e.g invalid message address, content-type, adapter disabled for tenant etc. An error caused by the server side, e.g no downstream consumers registered, downstream connection loss etc.  For a client side error, the adapter settles the message transfer with the rejected outcome and provides an error description in the corresponding disposition frame. In the case of a server-side error, the adapter settles the message with the released outcome, indicating to the client that the message itself was OK but it cannot be delivered due to a failure beyond the control of the client. In the latter case, a client may attempt to re-send the message unaltered.\nIn case of terminal errors the AMQP connection to the device is closed. The errors that are classified as terminal are listed below.\n The adapter is disabled for the tenant that the client belongs to. The authenticated device or gateway is disabled or not registered. The tenant is disabled or does not exist.  AMQP Command-line Client For purposes of demonstrating the usage of the AMQP adapter, the Hono CLI Module contains an AMQP command-line client for interacting with the AMQP adapter. The client can be used to send telemetry or events and to receive/respond to command request messages.\nThe command-line client supports the following parameters (with default values):\n --spring.profiles.active=amqp-send: Profile for sending telemetry data or events to Hono. --spring.profiles.active=amqp-command: Profile for receiving and responding to command request messages. --message.address: The AMQP 1.0 message address (default: telemetry) --message.payload: The message payload body (default: '{\u0026quot;temp\u0026quot;: 5}') --hono.client.host: The host name that the AMQP adapter is running on (default: localhost) --hono.client.port: The port that the adapter is listening for incoming connections (default: 5672)  To run the client to send a telemetry message to Hono, open a terminal and execute the following:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-send --hono.client.username=sensor1@DEFAULT_TENANT --hono.client.password=hono-secret Accepted{} The client prints the outcome of the operation to standard out. The outcome above (Accepted) indicates that the request to upload the data has succeeded.\nNB There are two JAR files in the hono/cli/target directory. The JAR to use for the client is the hono-cli-$VERSION-exec.jar and not the hono-cli-$VERSION.jar file. Running the latter will not work and will output the message: no main manifest attribute, in hono-cli-$VERSION.jar\nPublishing Telemetry Data The client indicates the delivery mode to use when uploading telemetry messages by means of the settled and rcv-settle-mode properties of the AMQP transfer frame(s) it uses for uploading the message. The AMQP adapter will accept messages using a delivery mode according to the following table:\n   settled rcv-settle-mode Delivery semantics     false first The adapter will forward the message to the downstream AMQP 1.0 Messaging Network and will forward any AMQP disposition frame received from the AMQP 1.0 Messaging Network to the client as is. It is up to the client\u0026rsquo;s discretion if and how it processes the disposition frame. The adapter will accept any re-delivered message. Sending unsettled messages allows for clients to implement either AT LEAST ONCE or AT MOST ONCE delivery semantics, depending on whether a client actually waits for and considers the disposition frames it receives from the adapter or not. This is the recommended mode for uploading telemetry data.   true first The adapter will acknowledge and settle any received message spontaneously before forwarding it to the downstream AMQP 1.0 Messaging Network. The adapter will ignore any AMQP disposition frames it receives from the AMQP 1.0 Messaging Network. Sending pre-settled messages allows for clients to implement AT MOST ONCE delivery semantics only. This is the fastest mode of delivery but has the drawback of less reliable end-to-end flow control and potential loss of messages without notice.    All other combinations are not supported by the adapter and will result in the message being ignored (pre-settled) or rejected (unsettled).\nPublish Telemetry Data (authenticated Device)  Authentication: SASL PLAIN or SASL EXTERNAL Message properties:  (required) to: either telemetry or t (optional) content-type: The type of payload contained in the message body. The given content type will be used in the AMQP message being forwarded downstream if not empty. Otherwise, the content type of the downstream message will be set to application/octet-stream if the payload is not empty and no default content type has been defined for the origin device or its tenant (see Downstream Meta Data.   Message Body:  (optional) Arbitrary payload contained in either a single AMQP Data or AmqpValue section. Note that the adapter only supports values of type string or array of bytes in the AmqpValue section. Values of other types will be ignored.   Outcomes:  accepted: The message has been successfully forwarded downstream. released: The message could not be processed by the adapter due to a (temporary) problem that has not been caused by the client. Potential reasons include that there is no active downstream consumer for messages from the device. rejected: The message could not be processed by the adapter because the client and/or the message did not fulfill some requirements. The rejected outcome\u0026rsquo;s error field will indicate the reason why the message could not be processed. Possible error conditions include:  hono:bad-request: The message does not meet all formal requirements, e.g. a required property is missing. amqp:unauthorized-access: The adapter is not enabled for the tenant that the client belongs to. amqp:resource-limit-exceeded: One of the Resource Limit Checks has failed for the tenant that the client belongs to. amqp:precondition-failed: The message does not fulfill certain requirements, e.g adapter cannot assert device registration etc.      When a device publishes data to the telemetry address, the AMQP adapter automatically determines the device\u0026rsquo;s identity and tenant during the authentication process.\nExamples\nPublish some JSON data for device 4711:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-send --hono.client.username=sensor1@DEFAULT_TENANT --hono.client.password=hono-secret Publish some JSON data for device 4711 using a client certificate for authentication:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-send --hono.client.port=5671 --hono.client.certPath=config/hono-demo-certs-jar/device-4711-cert.pem --hono.client.keyPath=config/hono-demo-certs-jar/device-4711-key.pem --hono.client.trustStorePath=config/hono-demo-certs-jar/trusted-certs.pem --hono.client.hostnameVerificationRequired=false Publish Telemetry Data (unauthenticated Device)  Authentication: SASL PLAIN or SASL EXTERNAL Message properties:  (required) to: either telemetry/${tenant-id}/${device-id} or t/${tenant-id}/${device-id} (optional) content-type: The type of payload contained in the message body. The given content type will be used in the AMQP message being forwarded downstream if not empty. Otherwise, the content type of the downstream message will be set to application/octet-stream if the payload is not empty and no default content type has been defined for the origin device or its tenant (see Downstream Meta Data.   Message Body:  (optional) Arbitrary payload contained in either a single AMQP Data or AmqpValue section. Note that the adapter only supports values of type string or array of bytes in the AmqpValue section. Values of other types will be ignored.   Outcomes:  accepted: The message has been successfully forwarded downstream. released: The message could not be processed by the adapter due to a (temporary) problem that has not been caused by the client. Potential reasons include that there is no active downstream consumer for messages from the device. rejected: The message could not be processed by the adapter because the client and/or the message did not fulfill some requirements. The rejected outcome\u0026rsquo;s error field will indicate the reason why the message could not be processed. Possible error conditions include:  hono:bad-request: The message does not meet all formal requirements, e.g. a required property is missing. amqp:unauthorized-access: The adapter is not enabled for the tenant that the client belongs to. amqp:resource-limit-exceeded: One of the Resource Limit Checks has failed for the tenant that the client belongs to. amqp:precondition-failed: The message does not fulfill certain requirements, e.g adapter cannot assert device registration etc.      This address format is used by devices that have not authenticated to the protocol adapter. Note that this requires the adapter\u0026rsquo;s HONO_AMQP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nPublish some JSON data for device 4711:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-send --message.address=t/DEFAULT_TENANT/4711 Publish Telemetry Data (authenticated Gateway) A device that publishes data on behalf of another device is called a gateway device. The message address is used by gateway components to publish data on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the message address is used to identify the device that the gateway publishes data for.\nExamples\nA gateway connecting to the adapter using gw@DEFAULT_TENANT as username and gw-secret as password and then publishing some JSON data for device 4711:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-send --hono.client.username=gw@DEFAULT_TENANT --hono.client.password=gw-secret --message.address=t/DEFAULT_TENANT/4711 In this example, we are using message address t/DEFAULT_TENANT/4711 which contains the device that the gateway is publishing the message for.\nPublishing Events The adapter supports AT LEAST ONCE delivery of Event messages only. A client therefore MUST set the settled property to false and the rcv-settle-mode property to first in all transfer frame(s) it uses for uploading events. All other combinations are not supported by the adapter and result in the message being rejected.\nPublish an Event (authenticated Device)  Authentication: SASL PLAIN or SASL EXTERNAL Message properties:  (required) to: either event or e (optional) content-type: The type of payload contained in the message body. The given content type will be used in the AMQP message being forwarded downstream if not empty. Otherwise, the content type of the downstream message will be set to application/octet-stream if the payload is not empty and no default content type has been defined for the origin device or its tenant (see Downstream Meta Data.   Message Body:  (optional) Arbitrary payload contained in either a single AMQP Data or AmqpValue section. Note that the adapter only supports values of type string or array of bytes in the AmqpValue section. Values of other types will be ignored.   Outcomes:  accepted: The message has been successfully forwarded downstream. released: The message could not be processed by the adapter due to a (temporary) problem that has not been caused by the client. rejected: The message could not be processed by the adapter because the client and/or the message did not fulfill some requirements. The rejected outcome\u0026rsquo;s error field will indicate the reason why the message could not be processed. Possible error conditions include:  hono:bad-request: The message does not meet all formal requirements, e.g. a required property is missing. amqp:unauthorized-access: The adapter is not enabled for the tenant that the client belongs to. amqp:resource-limit-exceeded: One of the Resource Limit Checks has failed for the tenant that the client belongs to. amqp:precondition-failed: The message does not fulfill certain requirements, e.g adapter cannot assert device registration etc.      This is the preferred way for devices to publish events. It is available only if the protocol adapter has been configured to require devices to authenticate (which is the default).\nExample\nUpload a JSON string for device 4711:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-send --hono.client.username=sensor1@DEFAULT_TENANT --hono.client.password=hono-secret --message.address=event --message.payload=\u0026#39;{\u0026#34;alarm\u0026#34;: 1}\u0026#39; Publish an Event (unauthenticated Device)  Authentication: SASL PLAIN or SASL EXTERNAL Message properties:  (required) to: either event/${tenant-id}/${device-id} or e/${tenant-id}/${device-id} (optional) content-type: The type of payload contained in the message body. The given content type will be used in the AMQP message being forwarded downstream if not empty. Otherwise, the content type of the downstream message will be set to application/octet-stream if the payload is not empty and no default content type has been defined for the origin device or its tenant (see Downstream Meta Data.   Message Body:  (optional) Arbitrary payload contained in either a single AMQP Data or AmqpValue section. Note that the adapter only supports values of type string or array of bytes in the AmqpValue section. Values of other types will be ignored.   Outcomes:  accepted: The message has been successfully forwarded downstream. released: The message could not be processed by the adapter due to a (temporary) problem that has not been caused by the client. rejected: The message could not be processed by the adapter because the client and/or the message did not fulfill some requirements. The rejected outcome\u0026rsquo;s error field will indicate the reason why the message could not be processed. Possible error conditions include:  hono:bad-request: The message does not meet all formal requirements, e.g. a required property is missing. amqp:unauthorized-access: The adapter is not enabled for the tenant that the client belongs to. amqp:resource-limit-exceeded: One of the Resource Limit Checks has failed for the tenant that the client belongs to. amqp:precondition-failed: The message does not fulfill certain requirements, e.g adapter cannot assert device registration etc.      This address format is used by devices that have not authenticated to the protocol adapter. Note that this requires the adapter\u0026rsquo;s HONO_AMQP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExample\nPublish some JSON data for device 4711:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-send --message.address=e/DEFAULT_TENANT/4711 --message.payload=\u0026#39;{\u0026#34;alarm\u0026#34;: 1}\u0026#39; Publish an Event (authenticated Gateway) Example\nA gateway connecting to the adapter using gw@DEFAULT_TENANT as username and gw-secret as password and then publishing some JSON data for device 4711:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-send --hono.client.username=gw@DEFAULT_TENANT --hono.client.password=gw-secret --message.address=e/DEFAULT_TENANT/4711 In this example, we are using message address e/DEFAULT_TENANT/4711 which contains the device that the gateway is publishing the message for.\nCommand \u0026amp; Control The AMQP adapter enables devices to receive commands that have been sent by business applications by means of opening a receiver link using a device specific source address as described below. When a device no longer wants to receive commands anymore, it can simply close the link.\nWhen a device has successfully opened a receiver link for commands, the adapter sends an empty notification on behalf of the device to the downstream AMQP 1.0 Messaging Network with the ttd header set to -1, indicating that the device will be ready to receive commands until further notice. Analogously, the adapter sends an empty notification with the ttd header set to 0 when a device closes the link or disconnects.\nDevices send their responses to commands by means of sending an AMQP message with properties specific to the command that has been executed. The AMQP adapter accepts responses being published using either at most once (QoS 0) or at least once (QoS 1) delivery semantics. The device must send the command response messages using the same (sender) link that it uses for sending telemetry data and events.\nThe AMQP adapter checks the configured message limit before accepting any command requests and responses. In case of incoming command requests from business applications or the command responses from devices, if the message limit is exceeded, the Adapter rejects the message with the reason amqp:resource-limit-exceeded.\nReceiving Commands A device MUST use the following source address in its attach frame to open a link for receiving commands:\n command (authenticated device) command (authenticated gateway receiving commands for all devices it acts on behalf of) command/${tenant}/${device-id} (unauthenticated device) command/${tenant}/${device-id} (authenticated gateway receiving commands for a specific device it acts on behalf of)  The adapter supports AT LEAST ONCE delivery of command messages only. A client therefore MUST use unsettled for the snd-settle-mode and first for the rcv-settle-mode fields of its attach frame during link establishment. All other combinations are not supported and result in the termination of the link.\nOnce the link has been established, the adapter will send command messages having the following properties:\n   Name Mandatory Location Type Description     subject yes properties string Contains the name of the command to be executed.   reply-to no properties string Contains the address to which the command response should be sent. This property will be empty for one-way commands.   correlation-id no properties string This property will be empty for one-way commands, otherwise it will contain the identifier used to correlate the response with the command request.   device_id no application-properties string This property will only be set if an authenticated gateway has connected to the adapter. It will contain the id of the device (connected to the gateway) that the command is targeted at.    Authenticated gateways will receive commands for devices which do not connect to a protocol adapter directly but instead are connected to the gateway. Corresponding devices have to be configured so that they can be used with a gateway. See Configuring Gateway Devices for details.\nA gateway can open a link to receive commands for all devices it acts on behalf of. An authenticated gateway can also open a receiver link for commands targeted at a specific device.\nWhen processing an incoming command message, the protocol adapter will give precedence to a device-specific command consumer matching the command target device, whether it was created by a gateway or by the device itself. If multiple such consumer links have been created, by multiple gateways and/or from the device itself, the gateway or device that last created the consumer link will get the command messages.\nIf no device-specific command consumer exists for a command target device, but one gateway, that may act on behalf of the device, has opened a generic, device-unspecific command consumer link, then the command message is sent to that gateway.\nIf multiple gateways have opened a generic command consumer link, the protocol adapter may have to decide to which gateway a particular command message will be sent to. In case the command target device has already sent a telemetry, event or command response message via a gateway and if that gateway has opened a command consumer link, that gateway will be chosen. Otherwise one gateway that may act on behalf of the command target device and that has opened a command consumer link will be chosen randomly to receive the command message.\nClients MUST settle command messages using one of the following outcomes:\n accepted: The command message has been accepted for processing. released: The command message can not be processed by the client due to a (temporary) problem at the client side. rejected: The command message can not be processed by the client because the message does not fulfill some requirements. The rejected outcome\u0026rsquo;s error field SHOULD indicate the reason why the message can not be processed.  Sending a Response to a Command A device only needs to respond to commands that contain a reply-to address and a correlation-id. However, if the application expects a response, then devices must publish a response back to the application. Devices may use the same anonymous sender link for this purpose that they also use for sending telemetry data and events.\nThe adapter supports AT LEAST ONCE delivery of command response messages only. A client therefore MUST set the settled property to false and the rcv-settle-mode property to first in all transfer frame(s) it uses for uploading command responses. All other combinations are not supported by the adapter and result in the message being rejected.\n Authentication: SASL PLAIN or SASL EXTERNAL Message properties:  (required) to: MUST contain the value of the reply-to property of the command request message. (required) correlation-id: MUST contain the value of the correlation-id property of the command request message. (optional) content-type: The type of payload contained in the message body.   Message application-properties:  (required) status: MUST contain an integer status code indicating the outcome of processing the command at the device (see Command \u0026amp; Control API for details).   Message Body:  (optional) Arbitrary payload contained in either a single AMQP Data or AmqpValue section. Note that the adapter only supports values of type string or array of bytes in the AmqpValue section. Values of other types will be ignored.   Outcomes:  accepted: The message has been successfully forwarded downstream. released: The message could not be processed by the adapter due to a (temporary) problem that has not been caused by the client. Potential reasons include that there is no active downstream consumer for messages from the device. rejected: The message could not be processed by the adapter because the client and/or the message did not fulfill some requirements. The rejected outcome\u0026rsquo;s error field will indicate the reason why the message could not be processed. Possible error conditions include:  hono:bad-request: The message does not meet all formal requirements, e.g. a required property is missing. amqp:unauthorized-access: The adapter is not enabled for the tenant that the client belongs to. amqp:resource-limit-exceeded: One of the Resource Limit Checks has failed for the tenant that the client belongs to. amqp:precondition-failed: The message does not fulfill certain requirements, e.g adapter cannot assert device registration etc.      Examples The AMQP adapter client can be used to simulate a device which receives commands and sends responses back to the application. The command line client is used to simulate an application sending commands to devices and receiving command responses from devices.\nStart the AMQP adapter client, as follows:\n# in directory: hono/cli/target/ java -jar hono-cli-*-exec.jar --spring.profiles.active=amqp-command --hono.client.username=sensor1@DEFAULT_TENANT --hono.client.password=hono-secret After successfully starting the client, a message indicating that the device is ready to receive commands will be printed to standard output. The device is now waiting to receive commands from applications.\nTo send a command to the device, open a new terminal shell and start the command application, as shown below:\n# in directory: hono/cli/ java -jar target/hono-cli-*-exec.jar --hono.client.host=localhost --hono.client.username=consumer@HONO --hono.client.password=verysecret --spring.profiles.active=command,ssl  Note Change into the cli directory before running the command above to start the command application. If you change into the target directory (i.e cli/target), then the client will not be able to locate to certificate needed to connect to the messaging network.  Once the command application starts successfully, enter a command name, payload and content-type of the command to send to the device.\n\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt; Enter name of command for device [DEFAULT_TENANT:4711] (prefix with \u0026#39;ow:\u0026#39; to send one-way command): setBrightness \u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt; Enter command payload: some-payload \u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt;\u0026gt; Enter content type: text/plain After sending the command, the device (i.e. AMQP command client) will print out the command name and payload that it receives and automatically sends a command response to the application.\nReceived Command Message : [Command name: setBrightness, Command payload: some-payload] Command response sent [outcome: Accepted{}] Downstream Meta Data The adapter includes the following meta data in the application properties of messages being sent downstream:\n   Name Type Description     device_id string The identifier of the device that the message originates from.   orig_adapter string Contains the adapter\u0026rsquo;s type name which can be used by downstream consumers to determine the protocol adapter that the message has been received over. The AMQP adapter\u0026rsquo;s type name is hono-amqp.   orig_address string Contains the AMQP target address that the device has used to send the data.    The adapter also considers defaults registered for the device at either the tenant or the device level. The values of the default properties are determined as follows:\n If the message already contains a non-empty property of the same name, the value if unchanged. Otherwise, if a default property of the same name is defined in the device\u0026rsquo;s registration information, that value is used. Otherwise, if a default property of the same name is defined for the tenant that the device belongs to, that value is used.  Note that of the standard AMQP 1.0 message properties only the content-type and ttl can be set this way to a default value.\nEvent Message Time-to-live Events published by devices will usually be persisted by the AMQP Messaging Network in order to support deferred delivery to downstream consumers. In most cases the AMQP Messaging Network can be configured with a maximum time-to-live to apply to the events so that the events will be removed from the persistent store if no consumer has attached to receive the event before the message expires.\nIn order to support environments where the AMQP Messaging Network cannot be configured accordingly, the protocol adapter supports setting a downstream event message\u0026rsquo;s ttl property based on the default ttl and max-ttl values configured for a tenant/device as described in the Tenant API.\nTenant specific Configuration The adapter uses the Tenant API to retrieve tenant specific configuration for adapter type hono-amqp. The following properties are (currently) supported:\n   Name Type Default Value Description     enabled boolean true If set to false the adapter will reject all data from devices belonging to the tenant and respond with a amqp:unauthorized-access as the error condition value for rejecting the message.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/coap-adapter/",
	"title": "CoAP Adapter",
	"tags": [],
	"description": "",
	"content": "The CoAP protocol adapter exposes CoAP based endpoints for Eclipse Hono™\u0026rsquo;s south bound Telemetry, Event and Command \u0026amp; Control APIs.\nDevice Authentication The CoAP adapter by default requires clients (devices or gateway components) to authenticate during connection establishment. The adapter (currently) supports the use of pre-shared keys (PSK) and X.509 certificates as part of a DTLS handshake for that purpose. Additional variants mentioned in Securing CoAP might be added in the future.\nPSK The identity provided in the ClientKeyExchange must have the form auth-id@tenant, e.g. sensor1@DEFAULT_TENANT. The adapter performs the handshake using the credentials which the configured Credentials service has on record for the client. The adapter uses the Credentials API\u0026rsquo;s get operation to retrieve the credentials on record with the tenant and auth-id provided by the device in the identity and psk as the type of secret as query parameters.\nThe examples below refer to devices 4711 and gw-1 of tenant DEFAULT_TENANT using auth-ids sensor1 and gw1 and corresponding secrets. The example deployment as described in the Deployment Guides comes pre-configured with the corresponding entities in its device registry component. Please refer to the Credentials API for details regarding the different types of secrets.\nNB There is a subtle difference between the device identifier (device-id) and the auth-id a device uses for authentication. See Device Identity for a discussion of the concepts.\nX.509 When a device uses a client certificate for authentication during the DTLS handshake, the adapter tries to determine the tenant that the device belongs to, based on the issuer DN contained in the certificate. In order for the lookup to succeed, the tenant\u0026rsquo;s trust anchor needs to be configured by means of registering the trusted certificate authority. The device\u0026rsquo;s client certificate will then be validated using the registered trust anchor, thus implicitly establishing the tenant that the device belongs to.\nIn a second step, the adapter then determines the device identifier using the Credentials API\u0026rsquo;s get operation with the client certificate\u0026rsquo;s subject DN as the auth-id and x509-cert as the type of secret as query parameters.\nNB The CoAP adapter needs to be configured for DTLS in order to support this mechanism. X.509 based authentication of clients is only supported with elliptic curve cryptography (ECC) based keys.\nMessage Limits The adapter rejects\n a client\u0026rsquo;s request to upload data with status code 429 Too Many Requests and any AMQP 1.0 message containing a command sent by a north bound application  if the message limit that has been configured for the device\u0026rsquo;s tenant is exceeded.\nCoAP Content Format Codes CoAP doesn\u0026rsquo;t use a textual identifier for content types. Instead, numbers are used, which are maintained by the IANA. The IANA - CoAP Content Formats page lists all (currently) registered codes and the corresponding media types.\nPublish Telemetry Data (authenticated Device) The device is authenticated using PSK.\n URI: /telemetry Method: POST Type:  CON: at least once delivery semantics NON: at most once delivery semantics   Request Options:  (optional) content-format: The type of payload contained in the request body. Required, if request contains payload.   Query Parameters:  (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) empty: Marks the request as an empty notification.   Request Body:  (optional) Arbitrary payload encoded according to the given content type. Maybe empty, if URI-query: empty is provided.   Response Options:  (optional) content-format: A media type describing the semantics and format of payload contained in the response body. This option will only be present if the response contains a command to be executed by the device which requires input data. Note that this option will be empty if the media type contained in the command (AMQP) message\u0026rsquo;s content-type property cannot be mapped to one of the registered CoAP content-format codes. (optional) location-query: The hono-command query parameter contains the name of the command to execute. This option will only be present if the response contains a command to be executed by the device. (optional) location-path: The location path is command for one-way-commands and command_response/\u0026lt;command-request-id\u0026gt; for commands expecting a response. In the latter case, the location-path option contains exactly the URI-path that the device must use when sending its response to the command. This option will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device. (optional) Error details, if status code is \u0026gt;= 4.00.   Response Codes:  2.04 (Changed): The data in the request body has been accepted for processing. The response may contain a command for the device to execute. Note that if the message type is NON (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer (yet). However, if the message type is CON (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 4.00 (Bad Request): The request cannot be processed. Possible reasons include:  the request body is empty, and the URI-query option doesn\u0026rsquo;t contain the empty parameter.   4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no consumer of telemetry data for the given tenant connected to Hono, or the consumer has not indicated that it may receive further messages (not giving credits). If the message type is CON (at least once semantics), the reason may be:  The consumer has indicated that it didn\u0026rsquo;t process the telemetry data. The consumer failed to indicate in time whether it has processed the telemetry data.        This is the preferred way for devices to publish telemetry data. It is available only if the protocol adapter is configured to require devices to authenticate (which is the default).\nExamples\nThe examples provided below make use of the coap-client command line tool which is part of the libcoap project. Precompiled packages should be available for different Linux variants.\nPublish some JSON data for device 4711 using default message type CON (at least once):\ncoap-client -u sensor1@DEFAULT_TENANT -k hono-secret -m POST coaps://hono.eclipseprojects.io/telemetry -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39;  Note coap-client only reports error response-codes, so the expected 2.04 response code will not be printed to the terminal.  Publish some JSON data for device 4711 using message type NON (at most once):\ncoap-client -u sensor1@DEFAULT_TENANT -k hono-secret -N -m POST coaps://hono.eclipseprojects.io/telemetry -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish some JSON data for device 4711, indicating that the device will wait for 10 seconds to receive the response:\ncoap-client -u sensor1@DEFAULT_TENANT -k hono-secret -m POST coaps://hono.eclipseprojects.io/telemetry?hono-ttd=10 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; { \u0026#34;brightness\u0026#34;: 87 }  Note In the example above the response actually contains payload that should be used as input to a command to be executed by the device. This is just for illustrative purposes. You will usually get an empty response because there is no downstream application attached which could send any commands to the device.  Publish Telemetry Data (unauthenticated Device)  URI: /telemetry/${tenantId}/${deviceId} Method: PUT Type:  CON: at least once delivery semantics NON: at most once delivery semantics   Request Options:  (optional) content-format: The type of payload contained in the request body. Required, if request contains payload.   Query Parameters:  (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) empty: Marks the request as an empty notification.   Request Body:  (optional) Arbitrary payload encoded according to the given content type. Maybe empty, if URI-query: empty is provided.   Response Options:  (optional) content-format: A media type describing the semantics and format of payload contained in the response body. This option will only be present if the response contains a command to be executed by the device which requires input data. Note that this option will be empty if the media type contained in the command (AMQP) message\u0026rsquo;s content-type property cannot be mapped to one of the registered CoAP content-format codes. (optional) location-query: The hono-command query parameter contains the name of the command to execute. This option will only be present if the response contains a command to be executed by the device. (optional) location-path: The location path is command for one-way-commands and command_response/\u0026lt;command-request-id\u0026gt; for commands expecting a response. In the latter case, the location-path option contains exactly the URI-path that the device must use when sending its response to the command. This option will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 2.05 (Content). (optional) Error details, if status code is \u0026gt;= 4.00.   Response Codes:  2.04 (Changed): The data in the request body has been accepted for processing. The response may contain a command for the device to execute. Note that if the message type is NON (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer (yet). However, if the message type is CON (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 4.00 (Bad Request): The request cannot be processed. Possible reasons include:  the request body is empty, and the URI-query option doesn\u0026rsquo;t contain the empty parameter.   4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter. The given device does not belong to the given tenant.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no consumer of telemetry data for the given tenant connected to Hono, or the consumer has not indicated that it may receive further messages (not giving credits). If the message type is CON (at least once semantics), the reason may be:  The consumer has indicated that it didn\u0026rsquo;t process the telemetry data. The consumer failed to indicate in time whether it has processed the telemetry data.        This resource MUST be used by devices that have not authenticated to the protocol adapter. Note that this requires the HONO_COAP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nPublish some JSON data for device 4711 using default message type CON (at least once):\ncoap-client -m PUT coap://hono.eclipseprojects.io/telemetry/DEFAULT_TENANT/4711 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish some JSON data for device 4711 using message type NON (at most once):\ncoap-client -N -m PUT coap://hono.eclipseprojects.io/telemetry/DEFAULT_TENANT/4711 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish some JSON data for device 4711, indicating that the device will wait for 10 seconds to receive the response:\ncoap-client -m PUT coap://hono.eclipseprojects.io/telemetry/DEFAULT_TENANT/4711?hono-ttd=10 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; { \u0026#34;brightness\u0026#34;: 87 } Publish Telemetry Data (authenticated Gateway)  URI: /telemetry/${tenantId}/${deviceId} Method: PUT Type:  CON: at least once delivery semantics NON: at most once delivery semantics   Request Options:  (optional) content-format: The type of payload contained in the request body. Required, if request contains payload.   Query Parameters:  (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) empty: Marks the request as an empty notification.   Request Body:  (optional) Arbitrary payload encoded according to the given content type. Maybe empty, if URI-query: empty is provided.   Response Options:  (optional) content-format: A media type describing the semantics and format of payload contained in the response body. This option will only be present if the response contains a command to be executed by the device which requires input data. Note that this option will be empty if the media type contained in the command (AMQP) message\u0026rsquo;s content-type property cannot be mapped to one of the registered CoAP content-format codes. (optional) location-query: The hono-command query parameter contains the name of the command to execute. This option will only be present if the response contains a command to be executed by the device. (optional) location-path: The location path is command/${tenantId}/${deviceId} for one-way-commands and command_response/${tenantId}/${deviceId}/\u0026lt;command-request-id\u0026gt; for commands expecting a response. In the latter case, the location-path option contains exactly the URI-path that the device must use when sending its response to the command. Note that in both cases the ${tenantId}/${deviceId} path segments indicate the device that the command is targeted at. This option will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 2.05 (Content). (optional) Error details, if status code is \u0026gt;= 4.00.   Response Codes:  2.04 (Changed): The data in the request body has been accepted for processing. The response may contain a command for a device to execute. Note that if the message type is NON (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer (yet). However, if the message type is CON (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 4.00 (Bad Request): The request cannot be processed. Possible reasons include:  the request body is empty, and the URI-query option doesn\u0026rsquo;t contain the empty parameter.   4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The tenant that the gateway belongs to is not allowed to use this protocol adapter. The device belongs to another tenant than the gateway. The gateway is not authorized to act on behalf of the device. The gateway associated with the device is not registered or disabled.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no consumer of telemetry data for the given tenant connected to Hono, or the consumer has not indicated that it may receive further messages (not giving credits). If the message type is CON (at least once semantics), the reason may be:  The consumer has indicated that it didn\u0026rsquo;t process the telemetry data. The consumer failed to indicate in time whether it has processed the telemetry data.        This resource can be used by gateway components to publish data on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the parameters from the URI are used to identify the device that the gateway publishes data for.\nThe protocol adapter checks the gateway\u0026rsquo;s authority to publish data on behalf of the device implicitly by means of retrieving a registration assertion for the device from the configured Device Registration service.\nExamples\nPublish some JSON data for device 4712 using default message type CON (at least once):\ncoap-client -u gw@DEFAULT_TENANT -k gw-secret -m PUT coaps://hono.eclipseprojects.io/telemetry/DEFAULT_TENANT/4712 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish some JSON data for device 4712 using message type NON (at most once):\ncoap-client -u gw@DEFAULT_TENANT -k gw-secret -N -m PUT coaps://hono.eclipseprojects.io/telemetry/DEFAULT_TENANT/4712 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish some JSON data for device 4712, indicating that the gateway will wait for 10 seconds to receive the response:\ncoap-client -u gw@DEFAULT_TENANT -k gw-secret -m PUT coaps://hono.eclipseprojects.io/telemetry/DEFAULT_TENANT/4712?hono-ttd=10 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; { \u0026#34;brightness\u0026#34;: 87 } NB The examples above assume that a gateway device has been registered with psk credentials with auth-id gw and secret gw-secret which is authorized to publish data on behalf of device 4712.\nPublish an Event (authenticated Device) The device is authenticated using PSK.\n URI: /event Method: POST Type:CON Request Options:  (optional) content-format: The type of payload contained in the request body. Required, if request contains payload.   Query Parameters:  (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) empty: Marks the request as an empty notification.   Request Body:  (optional) Arbitrary payload encoded according to the given content type. Maybe empty, if URI-query: empty is provided.   Response Options:  (optional) content-format: A media type describing the semantics and format of payload contained in the response body. This option will only be present if the response contains a command to be executed by the device which requires input data. Note that this option will be empty if the media type contained in the command (AMQP) message\u0026rsquo;s content-type property cannot be mapped to one of the registered CoAP content-format codes. (optional) location-query: The hono-command query parameter contains the name of the command to execute. This option will only be present if the response contains a command to be executed by the device. (optional) location-path: The location path is command for one-way-commands and command_response/\u0026lt;command-request-id\u0026gt; for commands expecting a response. In the latter case, the location-path option contains exactly the URI-path that the device must use when sending its response to the command. This option will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 2.05 (Content). (optional) Error details, if status code is \u0026gt;= 4.00.   Response Codes:  2.04 (Changed): The data in the request body has been accepted for processing. The response may contain a command for the device to execute. Note that if the message type is NON (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer (yet). However, if the message type is CON (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 4.00 (Bad Request): The request cannot be processed. Possible reasons include:  the request body is empty, and the URI-query option doesn\u0026rsquo;t contain the empty parameter.   4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed because there is no consumer of events for the given tenant connected to Hono, or the consumer didn\u0026rsquo;t process the event.    This is the preferred way for devices to publish events. It is available only if the protocol adapter is configured to require devices to authenticate (which is the default).\nExamples\nThe examples provided below make use of the coap-client command line tool which is part of the libcoap project. Precompiled packages should be available for different Linux variants.\nPublish some JSON data for device 4711 using default message type CON (at least once):\ncoap-client -u sensor1@DEFAULT_TENANT -k hono-secret -m POST coaps://hono.eclipseprojects.io/event -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39;  Note coap-client only reports error response-codes, so the expected 2.04 response code will not be printed to the terminal.  Publish some JSON data for device 4711, indicating that the device will wait for 10 seconds to receive the response:\ncoap-client -u sensor1@DEFAULT_TENANT -k hono-secret -m POST coaps://hono.eclipseprojects.io/event?hono-ttd=10 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; { \u0026#34;brightness\u0026#34;: 87 }  Note In the example above the response actually contains payload that should be used as input to a command to be executed by the device. This is just for illustrative purposes. You will usually get an empty response because there is no downstream application attached which could send any commands to the device.  Publish an Event (unauthenticated Device)  URI: /event/${tenantId}/${deviceId} Method: PUT Type:CON Request Options:  (optional) content-format: The type of payload contained in the request body. Required, if request contains payload.   Query Parameters:  (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) empty: Marks the request as an empty notification.   Request Body:  (optional) Arbitrary payload encoded according to the given content type. Maybe empty, if URI-query: empty is provided.   Response Options:  (optional) content-format: A media type describing the semantics and format of payload contained in the response body. This option will only be present if the response contains a command to be executed by the device which requires input data. Note that this option will be empty if the media type contained in the command (AMQP) message\u0026rsquo;s content-type property cannot be mapped to one of the registered CoAP content-format codes. (optional) location-query: The hono-command query parameter contains the name of the command to execute. This option will only be present if the response contains a command to be executed by the device. (optional) location-path: The location path is command for one-way-commands and command_response/\u0026lt;command-request-id\u0026gt; for commands expecting a response. In the latter case, the location-path option contains exactly the URI-path that the device must use when sending its response to the command. This option will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 2.05 (Content). (optional) Error details, if status code is \u0026gt;= 4.00.   Response Codes:  2.04 (Changed): The data in the request body has been accepted for processing. The response may contain a command for the device to execute. Note that if the message type is NON (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer (yet). However, if the message type is CON (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 4.00 (Bad Request): The request cannot be processed. Possible reasons include:  the request body is empty, and the URI-query option doesn\u0026rsquo;t contain the empty parameter.   4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter. The given device does not belong to the given tenant.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed because there is no consumer of events for the given tenant connected to Hono, or the consumer didn\u0026rsquo;t process the event.    This resource MUST be used by devices that have not authenticated to the protocol adapter. Note that this requires the HONO_COAP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nPublish some JSON data for device 4711 using default message type CON (at least once):\ncoap-client -m PUT coap://hono.eclipseprojects.io/event/DEFAULT_TENANT/4711 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish some JSON data for device 4711, indicating that the device will wait for 10 seconds to receive the response:\ncoap-client -m PUT coap://hono.eclipseprojects.io/event/DEFAULT_TENANT/4711?hono-ttd=10 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; { \u0026#34;brightness\u0026#34;: 87 } Publish an Event (authenticated Gateway)  URI: /event/${tenantId}/${deviceId} Method: PUT Type:CON Request Options:  (optional) content-format: The type of payload contained in the request body. Required, if request contains payload.   Query Parameters:  (optional) hono-ttd: The number of seconds the device will wait for the response. (optional) empty: Marks the request as an empty notification.   Request Body:  (optional) Arbitrary payload encoded according to the given content type. Maybe empty, if URI-query: empty is provided.   Response Options:  (optional) content-format: A media type describing the semantics and format of payload contained in the response body. This option will only be present if the response contains a command to be executed by the device which requires input data. Note that this option will be empty if the media type contained in the command (AMQP) message\u0026rsquo;s content-type property cannot be mapped to one of the registered CoAP content-format codes. (optional) location-query: The hono-command query parameter contains the name of the command to execute. This option will only be present if the response contains a command to be executed by the device. (optional) location-path: The location path is command/${tenantId}/${deviceId} for one-way-commands and command_response/${tenantId}/${deviceId}/\u0026lt;command-request-id\u0026gt; for commands expecting a response. In the latter case, the location-path option contains exactly the URI-path that the device must use when sending its response to the command. Note that in both cases the ${tenantId}/${deviceId} path segments indicate the device that the command is targeted at. This option will only be present if the response contains a command to be executed by the device.   Response Body:  (optional) Arbitrary data serving as input to a command to be executed by the device, if status code is 2.05 (Content). (optional) Error details, if status code is \u0026gt;= 4.00.   Response Codes:  2.04 (Changed): The data in the request body has been accepted for processing. The response may contain a command for a device to execute. Note that if the message type is NON (at most once semantics), this status code does not mean that the message has been delivered to any potential consumer (yet). However, if the message type is CON (at least once semantics), then the adapter waits for the message to be delivered and accepted by a downstream consumer before responding with this status code. 4.00 (Bad Request): The request cannot be processed. Possible reasons include:  the request body is empty, and the URI-query option doesn\u0026rsquo;t contain the empty parameter.   4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The tenant that the gateway belongs to is not allowed to use this protocol adapter. The device belongs to another tenant than the gateway. The gateway is not authorized to act on behalf of the device. The gateway associated with the device is not registered or disabled.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed because there is no consumer of events for the given tenant connected to Hono, or the consumer didn\u0026rsquo;t process the event.    This resource can be used by gateway components to publish data on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the parameters from the URI are used to identify the device that the gateway publishes data for.\nThe protocol adapter checks the gateway\u0026rsquo;s authority to publish data on behalf of the device implicitly by means of retrieving a registration assertion for the device from the configured Device Registration service.\nExamples\nPublish some JSON data for device 4712 using default message type CON (at least once):\ncoap-client -u gw@DEFAULT_TENANT -k gw-secret -m PUT coaps://hono.eclipseprojects.io/event/DEFAULT_TENANT/4712 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; Publish some JSON data for device 4712, indicating that the gateway will wait for 10 seconds to receive the response:\ncoap-client -u gw@DEFAULT_TENANT -k gw-secret -m PUT coaps://hono.eclipseprojects.io/event/DEFAULT_TENANT/4712?hono-ttd=10 -t application/json -e \u0026#39;{\u0026#34;temp\u0026#34;: 5}\u0026#39; { \u0026#34;brightness\u0026#34;: 87 } NB The examples above assume that a gateway device has been registered with psk credentials with auth-id gw and secret gw-secret which is authorized to publish data on behalf of device 4712.\nCommand \u0026amp; Control The CoAP adapter enables devices to receive commands that have been sent by business applications. Commands are delivered to the device by means of a response message. That means a device first has to send a request, indicating how long it will wait for the response. That request can either be a telemetry or event message, with a hono-ttd query parameter (ttd for time till disconnect) specifying the number of seconds the device will wait for the response. The business application can react on that message by sending a command message, targeted at the device. The CoAP adapter will then send the command message as part of the response message to the device.\nCommands handled by gateways Authenticated gateways will receive commands for devices which do not connect to a protocol adapter directly but instead are connected to the gateway. Corresponding devices have to be configured so that they can be used with a gateway. See Configuring Gateway Devices for details.\nA gateway can send a request with the hono-ttd query parameter on the /event or /telemetry URI, indicating its readiness to receive a command for any device it acts on behalf of. Note that in this case, the business application will be notified with the gateway id in the device_id property of the downstream message.\nAn authenticated gateway can also indicate its readiness to receive a command targeted at a specific device. For that, the /event/${tenantId}/${deviceId} or /telemetry/${tenantId}/${deviceId} URI is to be used, containing the id of the device to receive a command for. The business application will receive a notification with that device id.\nIf there are multiple concurrent requests with a hono-ttd query parameter, sent by the command target device and/or one or more of its potential gateways, the CoAP adapter will choose the device or gateway to send the command to as follows:\n A request done by the command target device or by a gateway specifically done for that device, has precedence. If there are multiple, concurrent such requests, the last one will get the command message (if received) in its response. Note that the other requests won\u0026rsquo;t be answered with a command message in their response event if the business application sent multiple command messages. That means commands for a single device can only be requested sequentially, not in parallel. If the above doesn\u0026rsquo;t apply, a single hono-ttd request on the /event or /telemetry URI, sent by a gateway that the command target device is configured for, will get the command message in its response. If there are multiple, concurrent such requests by different gateways, all configured for the command target device, the request by the gateway will be chosen, through which the target device has last sent a telemetry or event message. If the target device hasn\u0026rsquo;t sent a message yet and it is thereby unknown via which gateway the device communicates, then one of the requests will be chosen randomly to set the command in its response.  Sending a Response to a Command (authenticated Device) The device is authenticated using PSK.\n URI: /command_response/${commandRequestId} Method: POST Type: CON Request Options:  (optional) content-type: A media type describing the semantics and format of the payload contained in the request body. This option must be set if the result of processing the command on the device is non-empty. In this case the result data is contained in the request body.   Query Parameters:  (required) hono-cmd-status: An HTTP status code indicating the outcome of processing the command.   Request Body:  (optional) Arbitrary data representing the result of processing the command on the device.   Response Codes:  2.04 (Changed): The response has been successfully delivered to the application that has sent the command. 4.00 (Bad Request): The request cannot be processed because the command status or command request ID are missing/malformed. 4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no application listening for a reply to the given commandRequestId. The application has already given up on waiting for a response.      This is the preferred way for devices to respond to commands. It is available only if the protocol adapter is configured to require devices to authenticate (which is the default).\nExample\nSend a response to a previously received command with the command-request-id req-id-uuid for device 4711:\ncoap-client -u sensor1@DEFAULT_TENANT -k hono-secret coaps://hono.eclipseprojects.io/command_response/req-id-uuid?hono-cmd-status=200 Sending a Response to a Command (unauthenticated Device)  URI: /command_response/${tenantId}/${deviceId}/${commandRequestId} Method: PUT Type: CON Request Options:  (optional) content-type: A media type describing the semantics and format of the payload contained in the request body. This option must be set if the result of processing the command on the device is non-empty. In this case the result data is contained in the request body.   Query Parameters:  (required) hono-cmd-status: An HTTP status code indicating the outcome of processing the command.   Request Body:  (optional) Arbitrary data representing the result of processing the command on the device.   Response Codes:  2.04 (Changed): The response has been successfully delivered to the application that has sent the command. 4.00 (Bad Request): The request cannot be processed because the command status or command request ID are missing/malformed. 4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter. The given device does not belong to the given tenant.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no application listening for a reply to the given commandRequestId. The application has already given up on waiting for a response.      This resource MUST be used by devices that have not authenticated to the protocol adapter. Note that this requires the HONO_HTTP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false.\nExamples\nSend a response to a previously received command with the command-request-id req-id-uuid for the unauthenticated device 4711:\ncoap-client -u sensor1@DEFAULT_TENANT -k hono-secret coaps://hono.eclipseprojects.io/command_response/DEFAULT_TENANT/4711/req-id-uuid?hono-cmd-status=200 -e \u0026#39;{\u0026#34;brightness-changed\u0026#34;: true}\u0026#39; Sending a Response to a Command (authenticated Gateway)  URI: /command_response/${tenantId}/${deviceId}/${commandRequestId} Method: PUT Type: CON Request Options:  (optional) content-type: A media type describing the semantics and format of the payload contained in the request body. This option must be set if the result of processing the command on the device is non-empty. In this case the result data is contained in the request body.   Query Parameters:  (required) hono-cmd-status: An HTTP status code indicating the outcome of processing the command.   Request Body:  (optional) Arbitrary data representing the result of processing the command on the device.   Response Codes:  2.04 (Changed): The response has been successfully delivered to the application that has sent the command. 4.00 (Bad Request): The request cannot be processed because the command status or command request ID are missing/malformed. 4.03 (Forbidden): The request cannot be processed because the device\u0026rsquo;s registration status cannot be asserted. Possible reasons for this include:  The given tenant is not allowed to use this protocol adapter. The given device does not belong to the given tenant. The gateway is not authorized to act on behalf of the device. The gateway associated with the device is not registered or disabled.   4.04 (Not Found): The request cannot be processed because the device is disabled or does not exist. 4.13 (Request Entity Too Large): The request cannot be processed because the request body exceeds the maximum supported size. 4.29 (Too Many Requests): The request cannot be processed because the tenant\u0026rsquo;s message limit for the current period is exceeded. 5.03 (Service Unavailable): The request cannot be processed. Possible reasons for this include:  There is no application listening for a reply to the given commandRequestId. The application has already given up on waiting for a response.      This resource can be used by gateway components to send the response to a command on behalf of other devices which do not connect to a protocol adapter directly but instead are connected to the gateway, e.g. using some low-bandwidth radio based technology like SigFox or LoRa. In this case the credentials provided by the gateway during connection establishment with the protocol adapter are used to authenticate the gateway whereas the parameters from the URI are used to identify the device that the gateway publishes data for.\nThe protocol adapter checks the gateway\u0026rsquo;s authority to send responses to a command on behalf of the device implicitly by means of retrieving a registration assertion for the device from the configured Device Registration service.\nExamples\nSend a response to a previously received command with the command-request-id req-id-uuid for device 4712:\ncoap-client -u gw@DEFAULT_TENANT -k gw-secret coaps://hono.eclipseprojects.io/command_response/DEFAULT_TENANT/4712/req-id-uuid?hono-cmd-status=200 -e \u0026#39;{\u0026#34;brightness-changed\u0026#34;: true}\u0026#39; NB The example above assumes that a gateway device has been registered with psk credentials with auth-id gw and secret gw-secret which is authorized to publish data on behalf of device 4712.\nDownstream Meta Data The adapter includes the following meta data in the application properties of messages being sent downstream:\n   Name Type Description     device_id string The identifier of the device that the message originates from.   orig_adapter string Contains the adapter\u0026rsquo;s type name which can be used by downstream consumers to determine the protocol adapter that the message has been received over. The CoAP adapter\u0026rsquo;s type name is hono-coap.   orig_address string Contains the (relative) URI that the device has originally posted the data to.   ttd integer Contains the effective number of seconds that the device will wait for a response. This property is only set if the request contains the hono-ttd URI-query option.    The adapter also considers defaults registered for the device at either the tenant or the device level. The values of the default properties are determined as follows:\n If the message already contains a non-empty property of the same name, the value if unchanged. Otherwise, if a default property of the same name is defined in the device\u0026rsquo;s registration information, that value is used. Otherwise, if a default property of the same name is defined for the tenant that the device belongs to, that value is used.  Note that of the standard AMQP 1.0 message properties only the content-type and ttl can be set this way to a default value.\nEvent Message Time-to-live Events published by devices will usually be persisted by the AMQP Messaging Network in order to support deferred delivery to downstream consumers. In most cases the AMQP Messaging Network can be configured with a maximum time-to-live to apply to the events so that the events will be removed from the persistent store if no consumer has attached to receive the event before the message expires.\nIn order to support environments where the AMQP Messaging Network cannot be configured accordingly, the protocol adapter supports setting a downstream event message\u0026rsquo;s ttl property based on the hono-ttl property set as a query parameter in the event requests by the devices. Also the default ttl and max-ttl values can be configured for a tenant/device as described in the Tenant API.\nTenant specific Configuration The adapter uses the Tenant API to retrieve tenant specific configuration for adapter type hono-coap. The following properties are (currently) supported:\n   Name Type Default Value Description     enabled boolean true If set to false the adapter will reject all data from devices belonging to the tenant.   max-ttd integer 60 Defines a tenant specific upper limit for the time until disconnect property that devices may include in requests for uploading telemetry data or events. Please refer to the Command \u0026amp; Control concept page for a discussion of this parameter\u0026rsquo;s purpose and usage.\nThis property can be set for the hono-coap adapter type as an extension property in the adapter section of the tenant configuration.\nIf it is not set, then the default value of 60 seconds is used.   timeoutToAck integer - This property has the same semantics as the corresponding property at the adapter level. However, any (non-null) value configured for a tenant takes precedence over the adapter level value for all devices of the particular tenant.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/kura-adapter/",
	"title": "Kura Adapter",
	"tags": [],
	"description": "",
	"content": "The Kura protocol adapter exposes an MQTT topic hierarchy allowing Eclipse Kura™ based gateways to publish control and data messages to Eclipse Hono™\u0026rsquo;s Telemetry and Event endpoints.\n Note The Kura adapter is supposed to be used with gateways running Kura version 3.x. Gateways running Kura version 4 and later should connect to the MQTT adapter instead.  Authentication The Kura adapter by default requires devices (gateways) to authenticate during connection establishment. The adapter supports both the authentication based on the username/password provided in an MQTT CONNECT packet as well as client certificate based authentication as part of a TLS handshake for that purpose.\nThe adapter tries to authenticate the device using these mechanisms in the following order\nClient Certificate When a device uses a client certificate for authentication during the TLS handshake, the adapter tries to determine the tenant that the device belongs to based on the issuer DN contained in the certificate. In order for the lookup to succeed, the tenant\u0026rsquo;s trust anchor needs to be configured by means of registering the trusted certificate authority. The device\u0026rsquo;s client certificate will then be validated using the registered trust anchor, thus implicitly establishing the tenant that the device belongs to. In a second step, the adapter uses the Credentials API\u0026rsquo;s get operation to retrieve the credentials on record, including the client certificate\u0026rsquo;s subject DN as the auth-id, x509-cert as the type of secret and the MQTT client identifier as client-id in the request payload.\nNB The adapter needs to be configured for TLS in order to support this mechanism.\nUsername/Password When a device wants to authenticate using this mechanism, it needs to provide a username and a password in the MQTT CONNECT packet it sends in order to initiate the connection. The username must have the form auth-id@tenant, e.g. sensor1@DEFAULT_TENANT. The adapter verifies the credentials provided by the client against the credentials that the configured Credentials service has on record for the client. The adapter uses the Credentials API\u0026rsquo;s get operation to retrieve the credentials on record, including the tenant and auth-id provided by the client in the username, hashed-password as the type of secret and the MQTT client identifier as client-id in the request payload.\nPlease refer to the Eclipse Kura documentation on how to configure the gateway\u0026rsquo;s cloud service connection accordingly. It is important to set the gateway\u0026rsquo;s topic.context.account-name to the ID of the Hono tenant that the gateway has been registered with whereas the gateway\u0026rsquo;s client-id needs to be set to the corresponding Hono device ID. The auth-id used as part of the gateway\u0026rsquo;s username property needs to match the authentication identifier of a set of credentials registered for the device ID in Hono\u0026rsquo;s Credentials service. In other words, the credentials configured on the gateway need to belong to the corresponding device ID.\nNB There is a subtle difference between the device identifier (device-id) and the auth-id a device uses for authentication. See Device Identity for a discussion of the concepts.\nResource Limit Checks The adapter performs additional checks regarding resource limits when a client tries to connect and/or send a message to the adapter.\nConnection Limits The adapter rejects a client\u0026rsquo;s connection attempt with return code 0x05, indicating Connection Refused: not authorized, if\n the maximum number of connections per protocol adapter instance is reached, or if the maximum number of simultaneously connected devices for the tenant is reached.  Please refer to resource-limits for details.\nConnection Duration Limits The adapter rejects a client\u0026rsquo;s connection attempt with return code 0x05, indicating Connection Refused: not authorized, if the connection duration limit that has been configured for the client\u0026rsquo;s tenant is exceeded.\nMessage Limits The adapter\n discards any MQTT PUBLISH packet containing telemetry data or an event that is sent by a client and rejects any AMQP 1.0 message containing a command sent by a north bound application  if the message limit that has been configured for the device\u0026rsquo;s tenant is exceeded.\nConnection Events The adapter can emit Connection Events for client connections being established and/or terminated. Please refer to the common configuration options for details regarding how to enable this behavior.\nThe adapter includes the client identifier from the client\u0026rsquo;s MQTT CONNECT packet as the Connection Event\u0026rsquo;s remote-id.\nPublishing Data Once the gateway has established a connection to the Kura adapter, all control and data messages published by applications running on the gateway are sent to the adapter and mapped to Hono\u0026rsquo;s Telemetry and Event API endpoints as follows:\n The adapter treats all messages that are published to a topic starting with the configured HONO_KURA_CONTROL_PREFIX as control messages. All other messages are considered to be data messages. control messages with QoS 0 are forwarded to Hono\u0026rsquo;s telemetry endpoint whereas messages with QoS 1 are forwarded to the event endpoint. The corresponding AMQP 1.0 messages that are sent downstream have a content type of application/vnd.eclipse.kura-control. data messages with QoS 0 are forwarded to the telemetry endpoint whereas messages with QoS 1 are forwarded to the event endpoint. The corresponding AMQP 1.0 messages that are sent downstream have a content type of application/vnd.eclipse.kura-data.  Downstream Meta Data The adapter includes the following meta data in messages being sent downstream:\n   Name Location Type Description     device_id application string The identifier of the device that the message originates from.   orig_adapter application string Contains the adapter\u0026rsquo;s type name which can be used by downstream consumers to determine the protocol adapter that the message has been received over. The Kura adapter\u0026rsquo;s type name is hono-kura-mqtt.   orig_address application string Contains the name of the MQTT topic that the Kura gateway has originally published the data to.    The adapter also considers defaults registered for the device at either the tenant or the device level. The values of the default properties are determined as follows:\n If the message already contains a non-empty property of the same name, the value if unchanged. Otherwise, if a default property of the same name is defined in the device\u0026rsquo;s registration information, that value is used. Otherwise, if a default property of the same name is defined for the tenant that the device belongs to, that value is used.  Note that of the standard AMQP 1.0 message properties only the content-type and ttl can be set this way to a default value.\nEvent Message Time-to-live Events published by devices will usually be persisted by the AMQP Messaging Network in order to support deferred delivery to downstream consumers. In most cases the AMQP Messaging Network can be configured with a maximum time-to-live to apply to the events so that the events will be removed from the persistent store if no consumer has attached to receive the event before the message expires.\nIn order to support environments where the AMQP Messaging Network cannot be configured accordingly, the protocol adapter supports setting a downstream event message\u0026rsquo;s ttl property based on the default ttl and max-ttl values configured for a tenant/device as described in the Tenant API.\nTenant specific Configuration The adapter uses the Tenant API to retrieve tenant specific configuration for adapter type hono-kura-mqtt. The following properties are (currently) supported:\n   Name Type Default Value Description     enabled boolean true If set to false the adapter will reject all data from devices belonging to the tenant.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/sigfox-adapter/",
	"title": "Sigfox Adapter",
	"tags": [],
	"description": "",
	"content": "The Sigfox protocol adapter exposes an HTTP endpoint for connecting up with the Sigfox backend for publishing telemetry, events and use command \u0026amp; control.\n Tech preview This protocol adapter is not considered production ready. Its APIs might still be subject to change without warning.  Pre-requisites This Sigfox adapter only connects to the Sigfox backend system (backend.sigfox.com). It does not allow direct access to Sigfox devices.\nSo you need to set up your Sigfox devices on backend.sigfox.com and then configure the callbacks connect to your installation of Hono.\nDevices and credentials In a nutshell, the Sigfox adapter requires a single device identity, acting as a gateway device. This identity will be used to connect to Hono. All devices registered with Sigfox (the actual Sigfox devices), will be registered in Hono to allow this first identity as their gateway device.\nSetup example The following sub-sections walk you through an example setup.\nRegistering devices This example assumes that the Sigfox protocol adapter is available as https://iot-sigfox-adapter.my.hono.\nCreate a new gateway device with the following registration:\n{ \u0026#34;device-id\u0026#34;: \u0026#34;sigfox-backend\u0026#34; } Create new credentials for the gateway device. For example, using a username of sigfox and a password of test12:\n{ \u0026#34;auth-id\u0026#34;: \u0026#34;sigfox\u0026#34;, \u0026#34;device-id\u0026#34;: \u0026#34;sigfox-backend\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;secrets\u0026#34;: [ { \u0026#34;pwd-plain\u0026#34;: \u0026#34;test12\u0026#34; } ], \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34; } Create a new device, referencing the previous gateway device. The device id must be your Sigfox device ID (e.g. 1AB2C3):\n{ \u0026#34;device-id\u0026#34;: \u0026#34;1AB2C3\u0026#34;, \u0026#34;via\u0026#34;: \u0026#34;sigfox-backend\u0026#34; } Setting up callbacks Log in to the Sigfox backend at https://backend.sigfox.com and then open up the view Device Type -\u0026gt; Callbacks.\nCreate a new \u0026ldquo;Custom\u0026rdquo; callback, with the following settings (replacing \u0026lt;TENANT\u0026gt; with the name of the tenant):\n Type: DATA – UPLINK Channel: URL Url pattern: https://iot-sigfox-adapter.my.hono/data/telemetry/\u0026lt;TENANT\u0026gt;?device={device}\u0026amp;data={data} Use HTTP Method: GET Headers  Authorization – Basic … (see note below)   Send SNI: ☑ (Enabled)   Credentials At the moment you need to manually put in the Authorization header, you cannot put the credentials into the URL, as there is a bug in the Sigfox backend, which cannot be fixed by Hono. The backend does not properly escape the @ character, and thus sends foo%40tenant instead of foo@tenant to the Hono protocol adapter.\nAs a workaround, you can explicitly set the Authorization header to a value of Basic \u0026lt;base64 encoded credentials\u0026gt;. You can encode the credentials using:\necho -n \u0026#34;sigfox@tenant:password\u0026#34; | base64 To get the full value, including the Basic you may use:\necho \u0026#34;Basic $(echo -n \u0026#34;sigfox@tenant:password\u0026#34; | base64)\u0026#34;   Enabling command \u0026amp; control It is possible to enable command \u0026amp; control as well. For this you need to:\n Switch the Type of the DATA callback from UPLINK to BIDIR Add the ack query parameter to the Url pattern, e.g. https://iot-sigfox-adapter.my.hono/data/telemetry/\u0026lt;TENANT\u0026gt;?device={device}\u0026amp;data={data}\u0026amp;ack={ack}   Command requirements Sigfox allows only a very specific payload in command messages. You must send exactly 8 bytes of data. It only supports one way commands.  Events You can send events by using the path /data/event on the URL.\nConsuming data Use the standard way of consuming Hono messages.\nKnown bugs and limitations  Only the simple URL and only data (no service or device events are currently supported. "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/",
	"title": "Admin Guide",
	"tags": [],
	"description": "",
	"content": "Admin Guide Learn how to operate Eclipse Hono™ and look up the configuration options of its components.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/common-config/",
	"title": "Common Configuration",
	"tags": [],
	"description": "",
	"content": "Many Hono components support a common set of configuration options. This section describes those options.\nEach component which supports the following options explicitly states so. If it doesn\u0026rsquo;t, then these options are not supported by this component.\nJava VM Options The Java VM started in Hono\u0026rsquo;s components can be configured with arbitrary command line options by means of setting the JDK_JAVA_OPTIONS environment variable.\n   Environment Variable Mandatory Default Description     JDK_JAVA_OPTIONS no - Any options that should be passed to the Java VM on the command line, e.g. -Xmx128m    Vert.x Options The vert.x framework instance used to run Hono\u0026rsquo;s components on can be configured using the following environment variables or corresponding command line options:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_VERTX_DNS_QUERY_TIMEOUT\n--hono.vertx.dnsQueryTimeout no 5000 The amount of time (in milliseconds) after which a DNS query is considered to be failed. Setting this variable to a smaller value may help to reduce the time required to establish connections to the services this adapter depends on. However, setting it to a value that is too small for any DNS query to succeed will effectively prevent any connections to be established at all.   HONO_VERTX_MAX_EVENT_LOOP_EXECUTE_TIME\n--hono.vertx.maxEventLoopExecuteTime no PT2S The maximum duration that a task on the event loop may run without being considered to block the event loop. The value needs to be a string that represents an ISO-8601 Duration.   HONO_VERTX_PREFER_NATIVE\n--hono.vertx.preferNative no false Enables/disables epoll() support on Linux/MacOS. See the notes below for an explanation of the benefits of enabling epoll. It is generally safe to set this property to true because Netty will disable native transport if the platform doesn\u0026rsquo;t support it.    \nUsing Native Transport on Linux/MacOS Using epoll() on Linux/MacOS may provide better performance for applications which have a high I/O throughput. Especially when the application supports an asynchronous I/O model. This is true for most Hono components and applications using Hono.\nThe Netty framework supports using epoll() on Linux/MacOS x86_64 based systems.\nIn order to use epoll, the HONO_VERTX_PREFER_NATIVE environment variable needs to be set to true on startup.\nProtocol Adapter Options AMQP 1.0 Messaging Network Connection Configuration Protocol adapters require a connection to the AMQP 1.0 Messaging Network in order to forward telemetry data and events received from devices to downstream consumers.\nThe connection to the messaging network is configured according to Hono Client Configuration with HONO_MESSAGING being used as ${PREFIX}. Since there are no responses being received, the properties for configuring response caching can be ignored.\nKafka based Messaging Configuration Protocol adapters can be configured to allow publishing messages to an Apache Kafka® cluster instead of an AMQP Messaging Network. Which messaging to be used, can be configured at the tenant or for all tenants if a protocol adapter is only configured with one messaging system. For details refer to Hono Kafka Client Configuration.\nThe Kafka client is configured according to Hono Kafka Client Configuration.\nCommand \u0026amp; Control Connection Configuration Protocol adapters require an additional connection to the AMQP 1.0 Messaging Network in order to receive commands from downstream applications and send responses to commands back to applications.\nThe connection is configured according to Hono Client Configuration with HONO_COMMAND being used as ${PREFIX}. The properties for configuring response caching can be ignored.\nTenant Service Connection Configuration Protocol adapters require a connection to an implementation of Hono\u0026rsquo;s Tenant API in order to retrieve information for a tenant.\nThe connection to the Tenant Service is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_TENANT and the additional values for response caching apply.\nThe adapter caches the responses from the service according to the cache directive included in the response. If the response doesn\u0026rsquo;t contain a cache directive no data will be cached.\nDevice Registration Service Connection Configuration Protocol adapters require a connection to an implementation of Hono\u0026rsquo;s Device Registration API in order to retrieve registration status assertions for connected devices.\nThe connection to the Device Registration Service is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_REGISTRATION.\nThe adapter caches the responses from the service according to the cache directive included in the response. If the response doesn\u0026rsquo;t contain a cache directive no data will be cached.\nNote that the adapter uses a single cache for all responses from the service regardless of the tenant identifier. Consequently, the Device Registration Service client configuration\u0026rsquo;s responseCacheMinSize and responseCacheMaxSize properties determine the overall number of responses that can be cached.\nCredentials Service Connection Configuration Protocol adapters require a connection to an implementation of Hono\u0026rsquo;s Credentials API in order to retrieve credentials stored for devices that needs to be authenticated. During connection establishment, the adapter uses the Credentials API to retrieve the credentials on record for the device and matches that with the credentials provided by a device.\nThe connection to the Credentials Service is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_CREDENTIALS.\nThe adapter caches the responses from the service according to the cache directive included in the response. If the response doesn\u0026rsquo;t contain a cache directive no data will be cached.\nNote that the adapter uses a single cache for all responses from the service regardless of the tenant identifier. Consequently, the Credentials Service client configuration\u0026rsquo;s responseCacheMinSize and responseCacheMaxSize properties determine the overall number of responses that can be cached.\n\nDevice Connection Service Connection Configuration  Deprecation The Device Connection service is deprecated and will be replaced by the Command Router service, implementing the Command Router API. For now, depending on which of these service components is used, protocol adapters may configure the use of either the Device Connection service or the Command Router service as described below.  Protocol adapters connect to an implementation of Hono\u0026rsquo;s Device Connection API in order to determine the gateway that a device is connected via to a protocol adapter. This information is required in order to forward commands issued by applications to the protocol adapter instance that the gateway is connected to.\nThe connection to the Device Connection service is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_DEVICECONNECTION.\nResponses from the Device Connection service are never cached, so the properties for configuring the cache are ignored.\nDirect Connection to Data Grid Protocol adapters can alternatively be configured to directly access a data grid for storing and retrieving device connection information using Infinispan\u0026rsquo;s Hotrod protocol. This has the advantage of saving the network hop to the Device Connection service. However, this is only beneficial if the Device Connection service implementation itself uses a remote service (like a data grid) for storing the data.\nThe following table provides an overview of the configuration variables and corresponding command line options for configuring the connection to the data grid:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_DEVICECONNECTION_SERVER_LIST\n--hono.deviceConnection.serverList yes - A list of remote servers in the form: host1[:port][;host2[:port]].....   HONO_DEVICECONNECTION_AUTH_SERVER_NAME\n--hono.deviceConnection.authServerName yes - The server name to indicate in the SASL handshake when authenticating to the server.   HONO_DEVICECONNECTION_AUTH_USERNAME\n--hono.deviceConnection.authUsername yes - The username to use for authenticating to the server.   HONO_DEVICECONNECTION_AUTH_PASSWORD\n--hono.deviceConnection.authPassword yes - The password to use for authenticating to the server.    In general, the service supports all configuration properties of the Infinispan Hotrod client using hono.deviceConnection instead of the infinispan.client.hotrod prefix.\n\nCommand Router Service Connection Configuration  Note The Command Router service will replace the Device Connection service. For now, depending on which of these service components is used, protocol adapters may configure the use of either the Device Connection service as described above or the Command Router service.  Protocol adapters connect to an implementation of Hono\u0026rsquo;s Command Router API in order to supply information with which a Command Router service component can route command \u0026amp; control messages to the protocol adapters that the target devices are connected to.\nThe connection to the Command Router service is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_COMMANDROUTER.\nResponses from the Command Router service are never cached, so the properties for configuring the cache are ignored.\nResource Limits Checker Configuration The adapter can use metrics collected by a Prometheus server to enforce certain limits set at the tenant level like the overall number of connected devices allowed per tenant.\nThe following table provides an overview of the configuration variables and corresponding command line options for configuring the checker.\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     HONO_RESOURCELIMITS_PROMETHEUSBASED_HOST\n--hono.resourceLimits.prometheusBased.host no localhost The host name or IP address of the Prometheus server to retrieve the metrics data from. This property needs to be set in order to enable the Prometheus based checks.   HONO_RESOURCELIMITS_PROMETHEUSBASED_PORT\n--hono.resourceLimits.prometheusBased.port no 9090 The port of the Prometheus server to retrieve metrics data from.   HONO_RESOURCELIMITS_PROMETHEUSBASED_CACHEMINSIZE\n--hono.resourceLimits.prometheusBased.cacheMinSize no 20 The minimum size of the cache to store the metrics data retrieved from the Prometheus server. The cache is used for storing the current amount of data exchanged with devices of tenants.   HONO_RESOURCELIMITS_PROMETHEUSBASED_CACHEMAXSIZE\n--hono.resourceLimits.prometheusBased.cacheMaxSize no 1000 The maximum size of the cache to store the metrics data retrieved from the Prometheus server.   HONO_RESOURCELIMITS_PROMETHEUSBASED_CACHETIMEOUT\n--hono.resourceLimits.prometheusBased.cacheTimeout no 60 The number of seconds after which the cached metrics data should be considered invalid.   HONO_RESOURCELIMITS_PROMETHEUSBASED_CONNECTTIMEOUT\n--hono.resourceLimits.prometheusBased.connectTimeout no 1000 The maximum number of milliseconds that the adapter waits for a TCP connection to a Prometheus server to be established.   HONO_RESOURCELIMITS_PROMETHEUSBASED_QUERYTIMEOUT\n--hono.resourceLimits.prometheusBased.queryTimeout no 500 The number of milliseconds after which a request to a Prometheus server is closed. Setting zero or a negative value disables the timeout.    In addition to the properties listed above, the resource limit checker also supports the properties listed below as documented in the Hono Client Configuration. These properties might be useful if a reverse proxy in front of the Prometheus server requires the client to use TLS and/or provide credentials for authentication.\n HONO_RESOURCELIMITS_PROMETHEUSBASED_CREDENTIALSPATH HONO_RESOURCELIMITS_PROMETHEUSBASED_HOSTNAMEVERIFICATIONREQUIRED HONO_RESOURCELIMITS_PROMETHEUSBASED_KEYPATH HONO_RESOURCELIMITS_PROMETHEUSBASED_KEYSTOREPASSWORD HONO_RESOURCELIMITS_PROMETHEUSBASED_KEYSTOREPATH HONO_RESOURCELIMITS_PROMETHEUSBASED_PASSWORD HONO_RESOURCELIMITS_PROMETHEUSBASED_SECUREPROTOCOLS HONO_RESOURCELIMITS_PROMETHEUSBASED_TLSENABLED HONO_RESOURCELIMITS_PROMETHEUSBASED_TRUSTSTOREPATH HONO_RESOURCELIMITS_PROMETHEUSBASED_TRUSTSTOREPASSWORD HONO_RESOURCELIMITS_PROMETHEUSBASED_USERNAME  Connection Event Producer Configuration Some of the protocol adapters report the establishment and termination of a connection with a device by means of a Connection Event Producer.\nThe producer being used by the adapter can be configured as follows:\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     HONO_CONNECTIONEVENTS_PRODUCER\n--hono.connectionEvents.producer no logging The type of connection event producer to use for reporting the establishment/termination of device connections. Supported values are\nnone - No information is reported at all.\nlogging - All information is reported at INFO level via the logging framework.\nevents - All information is being sent downstream as Connection Events.   HONO_CONNECTIONEVENTS_LOGLEVEL\n--hono.connectionEvents.logLevel no info The level to log connection information at. Supported values are debug and info.    The events based connection event producer sets the TTL of event messages that it emits to the max TTL configured at the tenant level.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/auth-server-config/",
	"title": "Auth Server Configuration",
	"tags": [],
	"description": "",
	"content": "The Auth Server component exposes a service endpoint implementing Eclipse Hono™\u0026rsquo;s Authentication API. Other services use this component for authenticating clients and retrieving a token asserting the client\u0026rsquo;s identity and corresponding authorities.\nThis component serves as a default implementation of the Authentication API only. On startup, it reads in all identities and their authorities from a JSON file from the file system. All data is then kept in memory and there are no remote service APIs for managing the identities and their authorities.\nThe Auth Server is implemented as a Spring Boot application. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nService Configuration In addition to the following options, this component supports the options described in Common Configuration.\nThe server can be configured by means of environment variables or corresponding command line options. The following table provides an overview of the configuration variables and corresponding command line options that the server supports:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_APP_MAX_INSTANCES\n--hono.app.maxInstances no #CPU cores The number of verticle instances to deploy. If not set, one verticle per processor core is deployed.   HONO_AUTH_AMQP_BIND_ADDRESS\n--hono.auth.amqp.bindAddress no 127.0.0.1 The IP address of the network interface that the secure port should be bound to.\nSee Port Configuration below for details.   HONO_AUTH_AMQP_CERT_PATH\n--hono.auth.amqp.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_AUTH_AMQP_KEY_PATH.\nAlternatively, the HONO_AUTH_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_AUTH_AMQP_INSECURE_PORT\n--hono.auth.amqp.insecurePort no - The insecure port the server should listen on.\nSee Port Configuration below for details.   HONO_AUTH_AMQP_INSECURE_PORT_BIND_ADDRESS\n--hono.auth.amqp.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure port should be bound to.\nSee Port Configuration below for details.   HONO_AUTH_AMQP_INSECURE_PORT_ENABLED\n--hono.auth.amqp.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_AUTH_AMQP_INSECURE_PORT or the default AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   HONO_AUTH_AMQP_KEY_PATH\n--hono.auth.amqp.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. Note that the private key is not protected by a password. You should therefore make sure that the key file can only be read by the user that the server process is running under. This option must be used in conjunction with HONO_AUTH_CERT_PATH.\nAlternatively, the HONO_AUTH_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_AUTH_AMQP_KEY_STORE_PASSWORD\n--hono.auth.amqp.keyStorePassword no - The password required to read the contents of the key store.   HONO_AUTH_AMQP_KEY_STORE_PATH\n--hono.auth.amqp.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_AUTH_AMQP_KEY_PATH and HONO_AUTH_AMQP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_AUTH_AMQP_NATIVE_TLS_REQUIRED\n--hono.auth.amqp.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_AUTH_AMQP_PORT\n--hono.auth.amqp.port no 5671 The secure port that the server should listen on.\nSee Port Configuration below for details.   HONO_AUTH_AMQP_SECUREPROTOCOLS\n--hono.auth.amqp.secureProtocols no TLSv1.2 A (comma separated) list of secure protocols that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_AUTH_AMQP_SUPPORTEDCIPHERSUITES\n--hono.auth.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_AUTH_AMQP_TRUST_STORE_PASSWORD\n--hono.auth.amqp.trustStorePassword no - The password required to read the contents of the trust store.   HONO_AUTH_AMQP_TRUST_STORE_PATH\n--hono.auth.amqp.trustStorePath no - The absolute path to the Java key store containing the CA certificates the service uses for authenticating clients. The key store format can be either JKS, PKCS12 or PEM indicated by a .jks, .p12 or .pem file suffix respectively.   HONO_AUTH_SVC_PERMISSIONS_PATH\n--hono.auth.svc.permissionsPath yes - The path to the JSON file defining the identities and corresponding authorities on Hono\u0026rsquo;s endpoint resources. For backwards compatibility with previous releases, the path may contain a file:// prefix.   HONO_AUTH_SVC_SIGNING_KEY_PATH\n--hono.auth.svc.signing.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for signing tokens asserting an authenticated client\u0026rsquo;s identity and authorities. When using this variable, other services that need to validate the tokens issued by this service need to be configured with the corresponding certificate/public key. Alternatively, a symmetric key can be used for signing (and validating) by setting the HONO_AUTH_SVC_SIGNING_SHARED_SECRET variable. If none of these variables is set, the server falls back to the key indicated by the HONO_AUTH_AMQP_KEY_PATH variable. If that variable is also not set, startup of the server fails.   HONO_AUTH_SVC_SIGNING_SHARED_SECRET\n--hono.auth.svc.signing.sharedSecret no - A string to derive a symmetric key from that is used for signing tokens asserting an authenticated client\u0026rsquo;s identity and authorities. The key is derived from the string by using the bytes of the String\u0026rsquo;s UTF8 encoding. When setting the signing key using this variable, other services that need to validate the tokens issued by this service need to be configured with the same key. Alternatively, an asymmetric key pair can be used for signing (and validating) by setting the HONO_AUTH_SVC_SIGNING_KEY_PATH variable. If none of these variables is set, startup of the server fails.   HONO_AUTH_SVC_SIGNING_TOKEN_EXPIRATION\n--hono.auth.svc.signing.tokenExpiration no 600 The number of seconds after which the tokens created by this service for asserting an authenticated client\u0026rsquo;s identity should be considered invalid. Other Hono components will close AMQP connections with clients after this period in order to force the client to authenticate again and create a new token. In closed environments it should be save to set this value to a much higher value, e.g. several hours.   HONO_AUTH_SVC_SUPPORTED_SASL_MECHANISMS\n--hono.auth.svc.supportedSaslMechanisms no EXTERNAL, PLAIN A (comma separated) list of the supported SASL mechanisms to be advertised to clients. This option may be set to specify only one of EXTERNAL or PLAIN, or to use a different order.    The variables only need to be set if the default value does not match your environment.\nPort Configuration The Auth Server can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The server will fail to start if none of the ports is configured properly.\nSecure Port Only The server needs to be configured with a private key, a certificate holding the public key and a trust store in order to open a TLS secured port.\nThere are two alternative ways for setting the private key and certificate:\n Setting the HONO_AUTH_AMQP_KEY_STORE_PATH and the HONO_AUTH_AMQP_KEY_STORE_PASSWORD variables in order to load the key \u0026amp; certificate from a password protected key store, or setting the HONO_AUTH_AMQP_KEY_PATH and HONO_AUTH_AMQP_CERT_PATH variables in order to load the key and certificate from two separate PEM files in PKCS8 format.  In order to set the trust store, the HONO_AUTH_AMQP_TRUST_STORE_PATH variable needs to be set to a key store containing the trusted root CA certificates. The HONO_AUTH_AMQP_TRUST_STORE_PASSWORD variable needs to be set if the key store requires a pass phrase for reading its contents.\nWhen starting up, the server will bind a TLS secured socket to the default secure AMQP port 5671. The port number can also be set explicitly using the HONO_AUTH_AMQP_PORT variable.\nThe HONO_AUTH_AMQP_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-TLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled either by\n explicitly setting HONO_AUTH_AMQP_INSECURE_PORT to a valid port number, or by implicitly configuring the default AMQP port (5672) by simply setting HONO_AUTH_AMQP_INSECURE_PORT_ENABLED to true.  The server issues a warning on the console if HONO_AUTH_AMQP_INSECURE_PORT is set to the default secure AMQP port (5671).\nThe HONO_AUTH_AMQP_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-TLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nDual Port In test setups and some production scenarios Hono server may be configured to open one secure and one insecure port at the same time.\nThis is achieved by configuring both ports correctly (see above). The server will fail to start if both ports are configured to use the same port number.\nSince the secure port may need different visibility in the network setup compared to the secure port, it has its own binding address HONO_AUTH_AMQP_INSECURE_PORT_BIND_ADDRESS. This can be used to narrow the visibility of the insecure port to a local network e.g., while the secure port may be visible worldwide.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The Auth Server will then use arbitrary (unused) port numbers determined by the operating system during startup.\nMetrics Configuration See Monitoring \u0026amp; Tracing Admin Guide for details on how to configure the reporting of metrics.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/mongodb-device-registry-config/",
	"title": "MongoDB Based Device Registry Configuration",
	"tags": [],
	"description": "",
	"content": "The MongoDB based Device Registry component provides an implementation of Eclipse Hono™\u0026rsquo;s Device Registration, Credentials and Tenant APIs. Protocol adapters use these APIs to determine a device\u0026rsquo;s registration status, e.g. if it is enabled and if it is registered with a particular tenant, and to authenticate a device before accepting any data for processing from it. In addition to the above, this Device Registry also provides an implementation of Device Registry Management APIs for managing tenants, registration information and credentials of devices.\nThe Device Registry is implemented as a Spring Boot application, and the data is persisted in a MongoDB database. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nService Configuration The following table provides an overview of the configuration variables and corresponding command line options for configuring the MongoDB based Device Registry. In addition to the following options, this component also supports the options described in Common Configuration.\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_CREDENTIALS_SVC_CACHE_MAX_AGE\n--hono.credentials.svc.cacheMaxAge no 180 The maximum period of time (seconds) that information returned by the service\u0026rsquo;s operations may be cached for.   HONO_CREDENTIALS_SVC_COLLECTION_NAME\n--hono.credentials.svc.collectionName no credentials The name of the MongoDB collection where the server stores credentials of devices.   HONO_CREDENTIALS_SVC_HASH_ALGORITHMS_WHITELIST\n--hono.credentials.svc.hashAlgorithmsWhitelist no empty An array of supported hashing algorithms to be used with the hashed-password type of credentials. When not set, all values will be accepted.   HONO_CREDENTIALS_SVC_MAXBCRYPTCOSTFACTOR\n--hono.credentials.svc.maxBcryptCostFactor no 10 The maximum cost factor that is supported in password hashes using the BCrypt hash function. This limit is enforced by the device registry when adding or updating corresponding credentials. Increasing this number allows for potentially more secure password hashes to be used. However, the time required to compute the hash increases exponentially with the cost factor.   HONO_CREDENTIALS_SVC_MAX_BCRYPT_ITERATIONS\n--hono.credentials.svc.maxBcryptIterations no 10 DEPRECATED Please use HONO_CREDENTIALS_SVC_MAXBCRYPTCOSTFACTOR instead.\nThe maximum cost factor that is supported in password hashes using the BCrypt hash function. This limit is enforced by the device registry when adding or updating corresponding credentials. Increasing this number allows for potentially more secure password hashes to be used. However, the time required to compute the hash increases exponentially with the cost factor.   HONO_CREDENTIALS_SVC_RECEIVER_LINK_CREDIT\n--hono.credentials.svc.receiverLinkCredit no 100 The number of credits to flow to a client connecting to the Credentials endpoint.   HONO_MONGODB_CONNECTION_STRING\n--hono.mongodb.connectionString no - The connection string used by the Device Registry application to connect to the MongoDB database. If HONO_MONGODB_CONNECTION_STRING is set, it overrides the other MongoDB connection settings.\nSee Connection String URI Format for more information.   HONO_MONGODB_CONNECTION_TIMEOUT_IN_MS\n--hono.mongodb.connectionTimeoutInMs no 10000 The time in milliseconds to attempt a connection before timing out.   HONO_MONGODB_DB_NAME\n--hono.mongodb.dbName no - The name of the MongoDB database that should be used by the Device Registry application.   HONO_MONGODB_HOST\n--hono.mongodb.host no localhost The host name or IP address of the MongoDB instance.   HONO_MONGODB_PORT\n--hono.mongodb.port no 27017 The port that the MongoDB instance is listening on.   HONO_MONGODB_PASSWORD\n--hono.mongodb.password no - The password to use for authenticating to the MongoDB instance.   HONO_MONGODB_SERVER_SELECTION_TIMEOUT_IN_MS\n--hono.mongodb.serverSelectionTimeoutInMs no 1000 The time in milliseconds that the mongo driver will wait to select a server for an operation before raising an error.   HONO_MONGODB_USERNAME\n--hono.mongodb.username no - The user name to use for authenticating to the MongoDB instance.   HONO_REGISTRY_AMQP_BIND_ADDRESS\n--hono.registry.amqp.bindAddress no 127.0.0.1 The IP address of the network interface that the secure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_CERT_PATH\n--hono.registry.amqp.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_AMQP_KEY_PATH.\nAlternatively, the HONO_REGISTRY_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_AMQP_INSECURE_PORT\n--hono.registry.amqp.insecurePort no - The insecure port the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_INSECURE_PORT_BIND_ADDRESS\n--hono.registry.amqp.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_INSECURE_PORT_ENABLED\n--hono.registry.amqp.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_REGISTRY_AMQP_INSECURE_PORT or the default AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_KEY_PATH\n--hono.registry.amqp.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_AMQP_CERT_PATH. Alternatively, the HONO_REGISTRY_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_AMQP_KEY_STORE_PASSWORD\n--hono.registry.amqp.keyStorePassword no - The password required to read the contents of the key store.   HONO_REGISTRY_AMQP_KEY_STORE_PATH\n--hono.registry.amqp.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_REGISTRY_AMQP_KEY_PATH and HONO_REGISTRY_AMQP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_REGISTRY_AMQP_NATIVE_TLS_REQUIRED\n--hono.registry.amqp.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_REGISTRY_AMQP_PORT\n--hono.registry.amqp.port no 5671 The secure port that the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_SECUREPROTOCOLS\n--hono.registry.amqp.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_REGISTRY_AMQP_SUPPORTEDCIPHERSUITES\n--hono.registry.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_REGISTRY_HTTP_AUTHENTICATION_REQUIRED\n--hono.registry.http.authenticationRequired no true If set to true the HTTP endpoint of the Device Registry requires clients to authenticate when connecting to the Device Registry. The MongoDB based Device Registry currently supports basic authentication and the user credentials are to be stored in a MongoDB collection with name user. For more information on how to manage users please refer to Mongo Auth Provider.   HONO_REGISTRY_HTTP_BIND_ADDRESS\n--hono.registry.http.bindAddress no 127.0.0.1 The IP address of the network interface that the secure HTTP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_CERT_PATH\n--hono.registry.http.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_HTTP_KEY_PATH.\nAlternatively, the HONO_REGISTRY_HTTP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_HTTP_DEVICE_ID_PATTERN\n--hono.registry.http.deviceIdPattern no ^[a-zA-Z0-9-_\\.:]+$ The regular expression to use to validate device ID. Please refer to the java pattern documentation.   HONO_REGISTRY_HTTP_INSECURE_PORT\n--hono.registry.http.insecurePort no - The insecure port the server should listen on for HTTP requests.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_INSECURE_PORT_BIND_ADDRESS\n--hono.registry.http.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure HTTP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_INSECURE_PORT_ENABLED\n--hono.registry.http.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_REGISTRY_HTTP_INSECURE_PORT or the default AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_KEY_PATH\n--hono.registry.http.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_HTTP_CERT_PATH. Alternatively, the HONO_REGISTRY_HTTP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_HTTP_KEY_STORE_PASSWORD\n--hono.registry.http.keyStorePassword no - The password required to read the contents of the key store.   HONO_REGISTRY_HTTP_KEY_STORE_PATH\n--hono.registry.http.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_REGISTRY_HTTP_KEY_PATH and HONO_REGISTRY_HTTP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_REGISTRY_HTTP_MAXPAYLOADSIZE\n--hono.registry.http.maxPayloadSize no 16000 The maximum size of an HTTP request body in bytes that is accepted by the registry.   HONO_REGISTRY_HTTP_PORT\n--hono.registry.http.port no 5671 The secure port that the server should listen on for HTTP requests.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_SECUREPROTOCOLS\n--hono.registry.http.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_REGISTRY_HTTP_SUPPORTEDCIPHERSUITES\n--hono.registry.http.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_REGISTRY_HTTP_TENANT_ID_PATTERN\n--hono.registry.http.tenantIdPattern no ^[a-zA-Z0-9-_\\.]+$ The regular expression to use to validate tenant ID. Please refer to the java pattern documentation.   HONO_REGISTRY_SVC_CACHE_MAX_AGE\n--hono.registry.svc.cacheMaxAge no 180 The maximum period of time (seconds) that information returned by the service\u0026rsquo;s operations may be cached for.   HONO_REGISTRY_SVC_COLLECTION_NAME\n--hono.registry.svc.collectionName no devices The name of the MongoDB collection where the server stores registered device information.   HONO_REGISTRY_SVC_MAX_DEVICES_PER_TENANT\n--hono.registry.svc.maxDevicesPerTenant no -1 The number of devices that can be registered for each tenant. It is an error to set this property to a value \u0026lt; -1. The value -1 indicates that no limit is set.   HONO_REGISTRY_SVC_RECEIVER_LINK_CREDIT\n--hono.registry.svc.receiverLinkCredit no 100 The number of credits to flow to a client connecting to the Device Registration endpoint.   HONO_TENANT_SVC_CACHE_MAX_AGE\n--hono.tenant.svc.cacheMaxAge no 180 The maximum period of time (seconds) that information returned by the service\u0026rsquo;s operations may be cached for.   HONO_TENANT_SVC_COLLECTION_NAME\n--hono.tenant.svc.collectionName no tenants The name of the MongoDB collection where the server stores tenants information.   HONO_TENANT_SVC_RECEIVER_LINK_CREDIT\n--hono.tenant.svc.receiverLinkCredit no 100 The number of credits to flow to a client connecting to the Tenant endpoint.    The variables only need to be set if the default value does not match your environment.\nPort Configuration The Device Registry supports configuration of both, an AMQP based endpoint as well as an HTTP based endpoint proving RESTful resources for managing registration information and credentials. Both endpoints can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  See Port Configuration for more information.\n Note The environment variables to use for configuring the REST endpoint are the same as the ones for the AMQP endpoint, substituting _AMQP_ with _HTTP_.  Authentication Service Connection Configuration See Authentication Service Connection Configuration for more information.\nMetrics Configuration See Monitoring \u0026amp; Tracing Admin Guide for details on how to configure the reporting of metrics.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/jdbc-device-registry-config/",
	"title": "JDBC Based Device Registry Configuration",
	"tags": [],
	"description": "",
	"content": "The JDBC based Device Registry components provides an implementation of Eclipse Hono™'s Device Registration, Credentials and Tenant APIs. Protocol adapters use these APIs to determine a device\u0026rsquo;s registration status, e.g. if it is enabled and if it is registered with a particular tenant, and to authenticate a device before accepting any data for processing from it. In addition to the above, this Device Registry also provides an implementation of Device Registry Management APIs for managing tenants, registration information and credentials of devices.\nThe application is implemented as a Spring Boot application, and it uses a JDBC compliant database to persist data. In provides the following features:\n Run only the registration and credentials service, or run including the tenant service. By default, supports H2 and PostgreSQL Supports different JDBC connections for read-only and read-write operations, to support read-only replicas  Note: The provided container images contains only the H2 and PostgreSQL configuration and JDBC driver. While it is possible to use other JDBC compliant databases, database specific configuration and JDBC driver have to be provided by the user.\nService Configuration The following table provides an overview of the configuration variables and corresponding command line options for configuring the JDBC based Device Registry. In addition to the following options, this component also supports the options described in Common Configuration.\nThe configuration uses the section ADAPTER for configurations of the protocol adapter facing services, and the section MANAGEMENT for management facing services. As adapters only require read-only operations, this can be used to direct adapters to services instances, which are backed by read-only replicas. Which can improve performance and availability.\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_REGISTRY_JDBC_ADAPTER_URL --hono.registry.jdbc.adapter.url yes - The JDBC URL to the database.   HONO_REGISTRY_JDBC_ADAPTER_DRIVERCLASS --hono.registry.jdbc.adapter.driverClass no The default driver registered for the JDBC URL. The class name of the JDBC driver.   HONO_REGISTRY_JDBC_ADAPTER_USERNAME --hono.registry.jdbc.adapter.username no - The username used to access the database.   HONO_REGISTRY_JDBC_ADAPTER_PASSWORD --hono.registry.jdbc.adapter.password no - The password used to access the database.   HONO_REGISTRY_JDBC_ADAPTER_MAXIMUMPOOLSIZE --hono.registry.jdbc.adapter.maximumPoolSize no Depends on the connection pool implementation. 15 for C3P0. The maximum size of the connection pool.   HONO_REGISTRY_JDBC_ADAPTER_TABLENAME --hono.registry.jdbc.adapter.tableName no - The name of the table the datastore uses. If the datastore requires multiple tables, this is the prefix.   HONO_REGISTRY_JDBC_MANAGEMENT_URL --hono.registry.jdbc.management.url yes - The JDBC URL to the database.   HONO_REGISTRY_JDBC_MANAGEMENT_DRIVERCLASS --hono.registry.jdbc.management.driverClass no The default driver registered for the JDBC URL. The class name of the JDBC driver.   HONO_REGISTRY_JDBC_MANAGEMENT_USERNAME --hono.registry.jdbc.management.username no - The username used to access the database.   HONO_REGISTRY_JDBC_MANAGEMENT_PASSWORD --hono.registry.jdbc.management.password no - The password used to access the database.   HONO_REGISTRY_JDBC_MANAGEMENT_MAXIMUMPOOLSIZE --hono.registry.jdbc.management.maximumPoolSize no Depends on the connection pool implementation. 15 for C3P0. The maximum size of the connection pool.   HONO_REGISTRY_JDBC_MANAGEMENT_TABLENAME --hono.registry.jdbc.management no - The name of the table the datastore uses. If the datastore requires multiple tables, this is the prefix.   HONO_REGISTRY_SVC_TASKEXECUTORQUEUESIZE --hono.registry.svc.taskExecutorQueueSize no 1024 The size of the executor queue for hashing passwords.   HONO_REGISTRY_SVC_CREDENTIALSTTL --hono.registry.svc.credentialsTtl no 1m The TTL for credentials responses.   HONO_REGISTRY_SVC_REGISTRATIONTTL --hono.registry.svc.registrationTtl no 1m The TTL for registrations responses.   HONO_REGISTRY_SVC_MAXBCRYPTITERATIONS --hono.registry.svc.maxBcryptIterations no 10 The maximum number of allowed bcrypt iterations.   HONO_TENANT_JDBC_ADAPTER_URL --hono.tenant.jdbc.adapter.url yes - The JDBC URL to the database.   HONO_TENANT_JDBC_ADAPTER_DRIVERCLASS --hono.tenant.jdbc.adapter.driverClass no The default driver registered for the JDBC URL. The class name of the JDBC driver.   HONO_TENANT_JDBC_ADAPTER_USERNAME --hono.tenant.jdbc.adapter.username no - The username used to access the database.   HONO_TENANT_JDBC_ADAPTER_PASSWORD --hono.tenant.jdbc.adapter.password no - The password used to access the database.   HONO_TENANT_JDBC_ADAPTER_MAXIMUMPOOLSIZE --hono.tenant.jdbc.adapter.maximumPoolSize no Depends on the connection pool implementation. 15 for C3P0. The maximum size of the connection pool.   HONO_TENANT_JDBC_ADAPTER_TABLENAME --hono.tenant.jdbc.adapter.tableName no - The name of the table the datastore uses. If the datastore requires multiple tables, this is the prefix.   HONO_TENANT_JDBC_MANAGEMENT_URL --hono.tenant.jdbc.management.url yes - The JDBC URL to the database.   HONO_TENANT_JDBC_MANAGEMENT_DRIVERCLASS --hono.tenant.jdbc.management.driverClass no The default driver registered for the JDBC URL. The class name of the JDBC driver.   HONO_TENANT_JDBC_MANAGEMENT_USERNAME --hono.tenant.jdbc.management.username no - The username used to access the database.   HONO_TENANT_JDBC_MANAGEMENT_PASSWORD --hono.tenant.jdbc.management.password no - The password used to access the database.   HONO_TENANT_JDBC_MANAGEMENT_MAXIMUMPOOLSIZE --hono.tenant.jdbc.management.maximumPoolSize no Depends on the connection pool implementation. 15 for C3P0. The maximum size of the connection pool.   HONO_TENANT_JDBC_MANAGEMENT_TABLENAME --hono.tenant.jdbc.management.tableName no - The name of the table the datastore uses. If the datastore requires multiple tables, this is the prefix.   HONO_TENANT_SVC_TENANTTTL --hono.tenant.service.tenantTtl no 1m The TTL for tenant responses.   HONO_REGISTRY_AMQP_BIND_ADDRESS\n--hono.registry.amqp.bindAddress no 127.0.0.1 The IP address of the network interface that the secure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_CERT_PATH\n--hono.registry.amqp.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_AMQP_KEY_PATH.\nAlternatively, the HONO_REGISTRY_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_AMQP_INSECURE_PORT\n--hono.registry.amqp.insecurePort no - The insecure port the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_INSECURE_PORT_BIND_ADDRESS\n--hono.registry.amqp.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_INSECURE_PORT_ENABLED\n--hono.registry.amqp.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_REGISTRY_AMQP_INSECURE_PORT or the default AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_KEY_PATH\n--hono.registry.amqp.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_AMQP_CERT_PATH. Alternatively, the HONO_REGISTRY_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_AMQP_KEY_STORE_PASSWORD\n--hono.registry.amqp.keyStorePassword no - The password required to read the contents of the key store.   HONO_REGISTRY_AMQP_KEY_STORE_PATH\n--hono.registry.amqp.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_REGISTRY_AMQP_KEY_PATH and HONO_REGISTRY_AMQP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_REGISTRY_AMQP_NATIVE_TLS_REQUIRED\n--hono.registry.amqp.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_REGISTRY_AMQP_PORT\n--hono.registry.amqp.port no 5671 The secure port that the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_SECUREPROTOCOLS\n--hono.registry.amqp.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_REGISTRY_AMQP_SUPPORTEDCIPHERSUITES\n--hono.registry.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_REGISTRY_HTTP_AUTHENTICATION_REQUIRED\n--hono.registry.http.authenticationRequired no true If set to true the HTTP endpoint of the Device Registry requires clients to authenticate when connecting to the Device Registry. The JDBC based Device Registry currently supports basic authentication and the user credentials are to be stored in the database. For more information on how to manage users please refer to JDBC Auth Provider.   HONO_REGISTRY_HTTP_BIND_ADDRESS\n--hono.registry.http.bindAddress no 127.0.0.1 The IP address of the network interface that the secure HTTP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_CERT_PATH\n--hono.registry.http.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_HTTP_KEY_PATH.\nAlternatively, the HONO_REGISTRY_HTTP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_HTTP_DEVICE_ID_REGEX\n--hono.registry.http.deviceIdRegex no ^[a-zA-Z0-9-_]+$ The regular expression to use to validate device ID. Please refer to the java pattern documentation.   HONO_REGISTRY_HTTP_INSECURE_PORT\n--hono.registry.http.insecurePort no - The insecure port the server should listen on for HTTP requests.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_INSECURE_PORT_BIND_ADDRESS\n--hono.registry.http.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure HTTP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_INSECURE_PORT_ENABLED\n--hono.registry.http.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_REGISTRY_HTTP_INSECURE_PORT or the default AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_KEY_PATH\n--hono.registry.http.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_HTTP_CERT_PATH. Alternatively, the HONO_REGISTRY_HTTP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_HTTP_KEY_STORE_PASSWORD\n--hono.registry.http.keyStorePassword no - The password required to read the contents of the key store.   HONO_REGISTRY_HTTP_KEY_STORE_PATH\n--hono.registry.http.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_REGISTRY_HTTP_KEY_PATH and HONO_REGISTRY_HTTP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_REGISTRY_HTTP_MAXPAYLOADSIZE\n--hono.registry.http.maxPayloadSize no 16000 The maximum size of an HTTP request body in bytes that is accepted by the registry.   HONO_REGISTRY_HTTP_PORT\n--hono.registry.http.port no 5671 The secure port that the server should listen on for HTTP requests.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_SECUREPROTOCOLS\n--hono.registry.http.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_REGISTRY_HTTP_SUPPORTEDCIPHERSUITES\n--hono.registry.http.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_REGISTRY_HTTP_TENANT_ID_REGEX\n--hono.registry.http.tenantIdRegex no ^[a-zA-Z0-9-_.]+$ The regular expression to use to validate tenant ID. Please refer to the java pattern documentation.    The variables only need to be set if the default value does not match your environment.\nPort Configuration The Device Registry supports configuration of both, an AMQP based endpoint and an HTTP based endpoint proving RESTful resources for managing registration information and credentials. Both endpoints can be configured to listen for connections on:\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  See Port Configuration for more information.\n Note The environment variables to use for configuring the REST endpoint are the same as the ones for the AMQP endpoint, substituting _AMQP_ with _HTTP_.  Authentication Service Connection Configuration See Authentication Service Connection Configuration for more information.\nMetrics Configuration See Monitoring \u0026amp; Tracing Admin Guide for details on how to configure the reporting of metrics.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/file-based-device-registry-config/",
	"title": "File Based Device Registry Configuration",
	"tags": [],
	"description": "",
	"content": "The File based Device Registry component provides an exemplary implementation of Eclipse Hono™\u0026rsquo;s Device Registration, Credentials, Tenant and Device Connection APIs.\nProtocol adapters use these APIs to determine a device\u0026rsquo;s registration status, e.g. if it is enabled and if it is registered with a particular tenant, and to authenticate a device before accepting any data for processing from it.\nThere is no particular technical reason to implement these three APIs in one component, so for production scenarios there might be up to three different components each implementing one of the API\u0026rsquo;s.\nThe Device Registry component also exposes HTTP based resources for managing tenants and the registration information and credentials of devices.\nThe Device Registry is implemented as a Spring Boot application. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\n Deprecation The file based device registry 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. Please refer to the H2 documentation for details.  Service Configuration In addition to the following options, this component supports the options described in Common Configuration.\nThe following table provides an overview of the configuration variables and corresponding command line options for configuring the Device Registry.\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_APP_TYPE\n--hono.app.type no file The device registry implementation to use. This may be either file or dummy. In the case of dummy a dummy implementation will be used which will consider all devices queried for as valid devices, having the access credentials hono-secret. Of course this shouldn\u0026rsquo;t be used for productive use.   HONO_CREDENTIALS_SVC_CACHE_MAX_AGE\n--hono.credentials.svc.cacheMaxAge no 180 The maximum period of time (seconds) that information returned by the service\u0026rsquo;s operations may be cached for.   HONO_CREDENTIALS_SVC_FILENAME\n--hono.credentials.svc.filename no /var/lib/hono/device-registry/\ncredentials.json The path to the file where the server stores credentials of devices. Hono tries to read credentials from this file during start-up and writes out all identities to this file periodically if property HONO_CREDENTIALS_SVC_SAVE_TO_FILE is set to true.\nPlease refer to Credentials File Format for details regarding the file\u0026rsquo;s format.   HONO_CREDENTIALS_SVC_HASH_ALGORITHMS_WHITELIST\n--hono.credentials.svc.hashAlgorithmsWhitelist no empty An array of supported hashing algorithms to be used with the hashed-password type of credentials. When not set, all values will be accepted.   HONO_CREDENTIALS_SVC_MAXBCRYPTCOSTFACTOR\n--hono.credentials.svc.maxBcryptCostFactor no 10 The maximum cost factor that is supported in password hashes using the BCrypt hash function. This limit is enforced by the device registry when adding or updating corresponding credentials. Increasing this number allows for potentially more secure password hashes to be used. However, the time required to compute the hash increases exponentially with the cost factor.   HONO_CREDENTIALS_SVC_MAX_BCRYPT_ITERATIONS\n--hono.credentials.svc.maxBcryptIterations no 10 DEPRECATED Please use HONO_CREDENTIALS_SVC_MAXBCRYPTCOSTFACTOR instead.\nThe maximum cost factor that is supported in password hashes using the BCrypt hash function. This limit is enforced by the device registry when adding or updating corresponding credentials. Increasing this number allows for potentially more secure password hashes to be used. However, the time required to compute the hash increases exponentially with the cost factor.   HONO_CREDENTIALS_SVC_MODIFICATION_ENABLED\n--hono.credentials.svc.modificationEnabled no true When set to false the credentials contained in the registry cannot be updated nor removed.   HONO_CREDENTIALS_SVC_RECEIVER_LINK_CREDIT\n--hono.credentials.svc.receiverLinkCredit no 100 The number of credits to flow to a client connecting to the Credentials endpoint.   HONO_CREDENTIALS_SVC_SAVE_TO_FILE\n--hono.credentials.svc.saveToFile no false When set to true the server will periodically write out the registered credentials to the file specified by the HONO_CREDENTIALS_SVC_FILENAME property.   HONO_CREDENTIALS_SVC_STARTEMPTY\n--hono.credentials.svc.startEmpty no false When set to true the server will not try to load credentials from the file specified by the HONO_CREDENTIALS_SVC_FILENAME property during startup.   HONO_DEVICE_CONNECTION_SVC_MAX_DEVICES_PER_TENANT\n--hono.deviceConnection.svc.maxDevicesPerTenant no 100 The number of devices per tenant for which connection related data is stored. It is an error to set this property to a value \u0026lt;= 0.   HONO_REGISTRY_AMQP_BIND_ADDRESS\n--hono.registry.amqp.bindAddress no 127.0.0.1 The IP address of the network interface that the secure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_CERT_PATH\n--hono.registry.amqp.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_AMQP_KEY_PATH.\nAlternatively, the HONO_REGISTRY_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_AMQP_INSECURE_PORT\n--hono.registry.amqp.insecurePort no - The insecure port the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_INSECURE_PORT_BIND_ADDRESS\n--hono.registry.amqp.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_INSECURE_PORT_ENABLED\n--hono.registry.amqp.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_REGISTRY_AMQP_INSECURE_PORT or the default AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_KEY_PATH\n--hono.registry.amqp.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_AMQP_CERT_PATH. Alternatively, the HONO_REGISTRY_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_AMQP_KEY_STORE_PASSWORD\n--hono.registry.amqp.keyStorePassword no - The password required to read the contents of the key store.   HONO_REGISTRY_AMQP_KEY_STORE_PATH\n--hono.registry.amqp.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_REGISTRY_AMQP_KEY_PATH and HONO_REGISTRY_AMQP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_REGISTRY_AMQP_NATIVE_TLS_REQUIRED\n--hono.registry.amqp.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_REGISTRY_AMQP_PORT\n--hono.registry.amqp.port no 5671 The secure port that the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_REGISTRY_AMQP_SECUREPROTOCOLS\n--hono.registry.amqp.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_REGISTRY_AMQP_SUPPORTEDCIPHERSUITES\n--hono.registry.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_REGISTRY_HTTP_TENANT_ID_PATTERN\n--hono.registry.http.tenantIdPattern no ^[a-zA-Z0-9-_\\.]+$ The regular expression to use to validate tenant ID. Please refer to the java pattern documentation.   HONO_REGISTRY_HTTP_DEVICE_ID_PATTERN\n--hono.registry.http.deviceIdPattern no ^[a-zA-Z0-9-_\\.:]+$ The regular expression to use to validate device ID. Please refer to the java pattern documentation.   HONO_REGISTRY_HTTP_BIND_ADDRESS\n--hono.registry.http.bindAddress no 127.0.0.1 The IP address of the network interface that the secure HTTP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_CERT_PATH\n--hono.registry.http.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_HTTP_KEY_PATH.\nAlternatively, the HONO_REGISTRY_HTTP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_HTTP_INSECURE_PORT\n--hono.registry.http.insecurePort no - The insecure port the server should listen on for HTTP requests.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_INSECURE_PORT_BIND_ADDRESS\n--hono.registry.http.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure HTTP port should be bound to.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_INSECURE_PORT_ENABLED\n--hono.registry.http.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_REGISTRY_HTTP_INSECURE_PORT or the default HTTP port number (8080) if not set explicitly.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_KEY_PATH\n--hono.registry.http.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_HTTP_CERT_PATH. Alternatively, the HONO_REGISTRY_HTTP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_REGISTRY_HTTP_KEY_STORE_PASSWORD\n--hono.registry.http.keyStorePassword no - The password required to read the contents of the key store.   HONO_REGISTRY_HTTP_KEY_STORE_PATH\n--hono.registry.http.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_REGISTRY_HTTP_KEY_PATH and HONO_REGISTRY_HTTP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_REGISTRY_HTTP_MAXPAYLOADSIZE\n--hono.registry.http.maxPayloadSize no 16000 The maximum size of an HTTP request body in bytes that is accepted by the registry.   HONO_REGISTRY_HTTP_PORT\n--hono.registry.http.port no 8443 The secure port that the server should listen on for HTTP requests.\nSee Port Configuration below for details.   HONO_REGISTRY_HTTP_SECUREPROTOCOLS\n--hono.registry.http.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_REGISTRY_HTTP_SUPPORTEDCIPHERSUITES\n--hono.registry.http.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_REGISTRY_REST_TENANT_ID_PATTERN\n--hono.registry.rest.tenantIdPattern no ^[a-zA-Z0-9-_\\.]+$ The regular expression to use to validate tenant ID. Please refer to the java pattern documentation.\nDeprecated Use HONO_REGISTRY_HTTP_TENANT_ID_PATTERN instead.   HONO_REGISTRY_REST_DEVICE_ID_PATTERN\n--hono.registry.rest.deviceIdPattern no ^[a-zA-Z0-9-_\\.:]+$ The regular expression to use to validate device ID. Please refer to the java pattern documentation.\nDeprecated Use HONO_REGISTRY_HTTP_DEVICE_ID_PATTERN instead.   HONO_REGISTRY_REST_BIND_ADDRESS\n--hono.registry.rest.bindAddress no 127.0.0.1 The IP address of the network interface that the secure HTTP port should be bound to.\nSee Port Configuration below for details.\nDeprecated Use HONO_REGISTRY_HTTP_BIND_ADDRESS instead.   HONO_REGISTRY_REST_CERT_PATH\n--hono.registry.rest.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_REST_KEY_PATH.\nAlternatively, the HONO_REGISTRY_REST_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.\nDeprecated Use HONO_REGISTRY_HTTP_CERT_PATH instead.   HONO_REGISTRY_REST_INSECURE_PORT\n--hono.registry.rest.insecurePort no - The insecure port the server should listen on for HTTP requests.\nSee Port Configuration below for details.\nDeprecated Use HONO_REGISTRY_HTTP_INSECURE_PORT instead.   HONO_REGISTRY_REST_INSECURE_PORT_BIND_ADDRESS\n--hono.registry.rest.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure HTTP port should be bound to.\nSee Port Configuration below for details.\nDeprecated Use HONO_REGISTRY_HTTP_INSECURE_PORT_BIND_ADDRESS instead.   HONO_REGISTRY_REST_INSECURE_PORT_ENABLED\n--hono.registry.rest.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_REGISTRY_REST_INSECURE_PORT or the default HTTP port number (8080) if not set explicitly.\nSee Port Configuration below for details.\nDeprecated Use HONO_REGISTRY_HTTP_INSECURE_PORT_ENABLED instead.   HONO_REGISTRY_REST_KEY_PATH\n--hono.registry.rest.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_REGISTRY_REST_CERT_PATH. Alternatively, the HONO_REGISTRY_REST_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.\nDeprecated Use HONO_REGISTRY_HTTP_KEY_PATH instead.   HONO_REGISTRY_REST_KEY_STORE_PASSWORD\n--hono.registry.rest.keyStorePassword no - The password required to read the contents of the key store.\nDeprecated Use HONO_REGISTRY_HTTP_KEY_STORE_PASSWORD instead.   HONO_REGISTRY_REST_KEY_STORE_PATH\n--hono.registry.rest.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_REGISTRY_REST_KEY_PATH and HONO_REGISTRY_REST_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.\nDeprecated Use HONO_REGISTRY_HTTP_KEY_STORE_PATH instead.   HONO_REGISTRY_REST_PORT\n--hono.registry.rest.port no 8443 The secure port that the server should listen on for HTTP requests.\nSee Port Configuration below for details.\nDeprecated Use HONO_REGISTRY_HTTP_PORT instead.   HONO_REGISTRY_SVC_CACHE_MAX_AGE\n--hono.registry.svc.cacheMaxAge no 180 The maximum period of time (seconds) that information returned by the service\u0026rsquo;s operations may be cached for.   HONO_REGISTRY_SVC_FILENAME\n--hono.registry.svc.filename no /var/lib/hono/device-registry/\ndevice-identities.json The path to the file where the server stores identities of registered devices. Hono tries to read device identities from this file during start-up and writes out all identities to this file periodically if property HONO_REGISTRY_SVC_SAVE_TO_FILE is set to true.\nPlease refer to Device Identities File Format for details regarding the file\u0026rsquo;s format.   HONO_REGISTRY_SVC_MAX_DEVICES_PER_TENANT\n--hono.registry.svc.maxDevicesPerTenant no 100 The number of devices that can be registered for each tenant. It is an error to set this property to a value \u0026lt;= 0.   HONO_REGISTRY_SVC_MODIFICATION_ENABLED\n--hono.registry.svc.modificationEnabled no true When set to false the device information contained in the registry cannot be updated nor removed from the registry.   HONO_REGISTRY_SVC_RECEIVER_LINK_CREDIT\n--hono.registry.svc.receiverLinkCredit no 100 The number of credits to flow to a client connecting to the Device Registration endpoint.   HONO_REGISTRY_SVC_SAVE_TO_FILE\n--hono.registry.svc.saveToFile no false When set to true the server will periodically write out the registered device information to the file specified by the HONO_REGISTRY_SVC_FILENAME property.   HONO_REGISTRY_SVC_SIGNING_KEY_PATH\n--hono.registry.svc.signing.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for signing tokens asserting a device\u0026rsquo;s registration status. When using this variable, other services that need to validate the tokens issued by this service need to be configured with the corresponding certificate/public key. Alternatively, a symmetric key can be used for signing (and validating) by setting the HONO_REGISTRY_SVC_SIGNING_SHARED_SECRET variable. If none of these variables is set, the server falls back to the key indicated by the HONO_REGISTRY_AMP_KEY_PATH variable. If that variable is also not set, startup of the server fails.   HONO_REGISTRY_SVC_SIGNING_SHARED_SECRET\n--hono.registry.svc.signing.sharedSecret no - A string to derive a symmetric key from that is used for signing tokens asserting a device\u0026rsquo;s registration status. The key is derived from the string by using the bytes of the String\u0026rsquo;s UTF8 encoding. When setting the signing key using this variable, other services that need to validate the tokens issued by this service need to be configured with the same key. Alternatively, an asymmetric key pair can be used for signing (and validating) by setting the HONO_REGISTRY_SVC_SIGNING_KEY_PATH variable. If none of these variables is set, startup of the server fails.   HONO_REGISTRY_SVC_SIGNING_TOKEN_EXPIRATION\n--hono.registry.svc.signing.tokenExpiration no 10 The expiration period to use for the tokens asserting the registration status of devices.   HONO_REGISTRY_SVC_STARTEMPTY\n--hono.registry.svc.startEmpty no false When set to true the server will not try to load device identities from the file specified by the HONO_REGISTRY_SVC_FILENAME property during startup.   HONO_TENANT_SVC_CACHE_MAX_AGE\n--hono.tenant.svc.cacheMaxAge no 180 The maximum period of time (seconds) that information returned by the service\u0026rsquo;s operations may be cached for.   HONO_TENANT_SVC_FILENAME\n--hono.tenant.svc.filename no /var/lib/hono/device-registry/\ntenants.json The path to the file where the server stores tenants. Hono tries to read tenants from this file during start-up and writes out all identities to this file periodically if property HONO_TENANT_SVC_SAVE_TO_FILE is set to true.\nPlease refer to Tenants File Format for details regarding the file\u0026rsquo;s format.   HONO_TENANT_SVC_MODIFICATION_ENABLED\n--hono.tenant.svc.modificationEnabled no true When set to false the tenants contained in the registry cannot be updated nor removed.   HONO_TENANT_SVC_RECEIVER_LINK_CREDIT\n--hono.tenant.svc.receiverLinkCredit no 100 The number of credits to flow to a client connecting to the Tenant endpoint.   HONO_TENANT_SVC_SAVE_TO_FILE\n--hono.tenant.svc.saveToFile no false When set to true the server will periodically write out the registered tenants to the file specified by the HONO_TENANTS_SVC_TENANT_FILENAME property.   HONO_TENANT_SVC_STARTEMPTY\n--hono.tenant.svc.startEmpty no false When set to true the server will not try to load tenants from the file specified by the HONO_TENANT_SVC_FILENAME property during startup.    The variables only need to be set if the default value does not match your environment.\nPort Configuration The file based Device Registry supports configuration of both an AMQP based endpoint exposing the Tenant, Device Registration and Credentials APIs as well as an HTTP based endpoint providing resources for managing tenants, registration information and credentials as defined by the Registry Management API. Both endpoints can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The registry will fail to start if none of the ports is configured properly.\nThe following sections apply to configuring both the AMQP and the HTTP endpoint. The environment variables to use for configuring the HTTP endpoint are the same as the ones for the AMQP endpoint, substituting _AMQP_ with _HTTP_, e.g. HONO_REGISTRY_HTTP_KEY_PATH instead of HONO_REGISTRY_AMQP_KEY_PATH.\nSecure Port Only The server needs to be configured with a private key and certificate in order to open a TLS secured port.\nThere are two alternative ways for doing so:\n Setting the HONO_REGISTRY_AMQP_KEY_STORE_PATH and the HONO_REGISTRY_AMQP_KEY_STORE_PASSWORD variables in order to load the key \u0026amp; certificate from a password protected key store, or setting the HONO_REGISTRY_AMQP_KEY_PATH and HONO_REGISTRY_AMQP_CERT_PATH variables in order to load the key and certificate from two separate PEM files in PKCS8 format.  When starting up, the server will bind a TLS secured socket to the default secure port (5671 for AMQP and 8443 for HTTP). The port number can also be set explicitly using the HONO_REGISTRY_AMQP_PORT variable.\nThe HONO_REGISTRY_AMQP_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default, the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-TLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled either by\n explicitly setting HONO_REGISTRY_AMQP_INSECURE_PORT to a valid port number, or by implicitly configuring the default port (5672 for AMQP and 8080 for HTTP) to be used by setting HONO_REGISTRY_AMQP_INSECURE_PORT_ENABLED to true.  The server issues a warning on the console if one of the insecure ports is set to the corresponding default secure port.\nThe HONO_REGISTRY_AMQP_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default, the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-TLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nDual Port In test setups and some production scenarios Hono server may be configured to open one secure and one insecure port at the same time.\nThis is achieved by configuring both ports correctly (see above). The server will fail to start if both ports are configured to use the same port number.\nSince the secure port may need different visibility in the network setup compared to the secure port, it has its own binding address HONO_REGISTRY_AMQP_INSECURE_PORT_BIND_ADDRESS. This can be used to narrow the visibility of the insecure port to a local network e.g., while the secure port may be visible worldwide.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The Device Registry will then use arbitrary (unused) port numbers determined by the operating system during startup.\nAuthentication Service Connection Configuration The Device Registry requires a connection to an implementation of Hono\u0026rsquo;s Authentication API in order to authenticate and authorize client requests.\nThe connection is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_AUTH. Since Hono\u0026rsquo;s Authentication Service does not allow caching of the responses, the cache properties can be ignored.\nIn addition to the standard client configuration properties, following properties may be set for the connection:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_AUTH_VALIDATION_CERT_PATH\n--hono.auth.validation.certPath no - The absolute path to the PEM file containing the an X.509 certificate that the service should use for validating tokens issued by the Authentication service. Alternatively, a symmetric key can be used for validating tokens by setting the HONO_AUTH_VALIDATION_SHARED_SECRET variable. If none of these variables is set, startup of the service fails.   HONO_AUTH_VALIDATION_SHARED_SECRET\n--hono.auth.validation.sharedSecret no - A string to derive a symmetric key from which is used for validating tokens issued by the Authentication service. The key is derived from the string by using the bytes of the String\u0026rsquo;s UTF8 encoding. When setting the validation key using this variable, the Authentication service must be configured with the same key. Alternatively, an X.509 certificate can be used for validating tokens by setting the HONO_AUTH_VALIDATION_CERT_PATH variable. If none of these variables is set, startup of the service fails.   HONO_AUTH_SUPPORTED_SASL_MECHANISMS\n--hono.auth.supportedSaslMechanisms no EXTERNAL, PLAIN A (comma separated) list of the SASL mechanisms that the device registry should offer to clients for authentication. This option may be set to specify only one of EXTERNAL or PLAIN, or to use a different order.    Metrics Configuration See Monitoring \u0026amp; Tracing Admin Guide for details on how to configure the reporting of metrics.\nDevice Identities File Format The Device Registry supports persisting the device identities and their registration information to a JSON file in the local file system. The Getting started Guide includes an example configuration which illustrates the file format used. The configuration file\u0026rsquo;s location is /deploy/src/main/deploy/example-device-identities.json.\nCredentials File Format The Device Registry supports persisting the devices' credentials to a JSON file in the local file system. The Getting started Guide includes an example configuration which illustrates the file format used. The configuration file\u0026rsquo;s location is /deploy/src/main/deploy/example-credentials.json.\nTenants File Format The Device Registry supports persisting tenants to a JSON file in the local file system. The configuration file\u0026rsquo;s location is /deploy/src/main/deploy/example-tenants.json.\nConfiguring Gateway Devices The Device Registry supports devices to act on behalf of other devices. This is particularly useful for cases where a device does not connect directly to a Hono protocol adapter but is connected to a gateway component that is usually specific to the device\u0026rsquo;s communication protocol. It is the gateway component which then connects to a Hono protocol adapter and publishes data on behalf of the device(s). Examples of such a set up include devices using SigFox or LoRa for communication.\nIn these cases the protocol adapter will authenticate the gateway component instead of the device for which it wants to publish data. In order to verify that the gateway is authorized to publish data on behalf of the particular device, the protocol adapter should include the gateway\u0026rsquo;s device identifier (as determined during the authentication process) in its invocation of the Device Registration API\u0026rsquo;s assert Device Registration operation.\nThe Device Registry will then do the following:\n Verify that the device exists and is enabled. Verify that the gateway exists and is enabled. Verify that the device\u0026rsquo;s registration information contains a property called via and that its value is either the gateway\u0026rsquo;s device identifier or a JSON array which contains the gateway\u0026rsquo;s device identifier as one of its values.  Only if all conditions are met, the Device Registry returns an assertion of the device\u0026rsquo;s registration status. The protocol adapter can then forward the published data to the AMQP Messaging Network in the same way as for any device that connects directly to the adapter.\nThe example configuration file (located at /deploy/src/main/deploy/example-device-identities.json) includes a device and a corresponding gateway configured in this way.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/command-router-config/",
	"title": "Configuring the Command Router Service",
	"tags": [],
	"description": "",
	"content": "The Command Router service provides an implementation of Eclipse Hono™\u0026rsquo;s Command Router API.\nProtocol Adapters use the Command Router API to supply information with which a Command Router service component can route command \u0026amp; control messages to the protocol adapters that the target devices are connected to.\nThe Command Router component provides an implementation of the Command Router API which uses a remote data grid for storing information about device connections. The data grid can be scaled out independently from the Command Router service components to meet the storage demands at hand.\nThe Command Router component is implemented as a Spring Boot application. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nThe adapter supports the following standard configuration options:\n Common Java VM Options Common vert.x Options Monitoring Options  Service Configuration The following table provides an overview of the configuration variables and corresponding command line options for configuring the Command Router component.\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_APP_MAX_INSTANCES\n--hono.app.maxInstances no #CPU cores The number of Verticle instances to deploy. If not set, one Verticle per processor core is deployed.   HONO_COMMANDROUTER_AMQP_BIND_ADDRESS\n--hono.commandRouter.amqp.bindAddress no 127.0.0.1 The IP address of the network interface that the secure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_COMMANDROUTER_AMQP_CERT_PATH\n--hono.commandRouter.amqp.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_COMMANDROUTER_AMQP_KEY_PATH.\nAlternatively, the HONO_COMMANDROUTER_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_COMMANDROUTER_AMQP_INSECURE_PORT\n--hono.commandRouter.amqp.insecurePort no - The insecure port the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_COMMANDROUTER_AMQP_INSECURE_PORT_BIND_ADDRESS\n--hono.commandRouter.amqp.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_COMMANDROUTER_AMQP_INSECURE_PORT_ENABLED\n--hono.commandRouter.amqp.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_COMMANDROUTER_AMQP_INSECURE_PORT or the default AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   HONO_COMMANDROUTER_AMQP_KEY_PATH\n--hono.commandRouter.amqp.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_COMMANDROUTER_AMQP_CERT_PATH. Alternatively, the HONO_COMMANDROUTER_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_COMMANDROUTER_AMQP_KEY_STORE_PASSWORD\n--hono.commandRouter.amqp.keyStorePassword no - The password required to read the contents of the key store.   HONO_COMMANDROUTER_AMQP_KEY_STORE_PATH\n--hono.commandRouter.amqp.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_COMMANDROUTER_AMQP_KEY_PATH and HONO_COMMANDROUTER_AMQP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_COMMANDROUTER_AMQP_NATIVE_TLS_REQUIRED\n--hono.commandRouter.amqp.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_COMMANDROUTER_AMQP_PORT\n--hono.commandRouter.amqp.port no 5671 The secure port that the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_COMMANDROUTER_AMQP_RECEIVER_LINK_CREDIT\n--hono.commandRouter.amqp.receiverLinkCredit no 100 The number of credits to flow to a client connecting to the service\u0026rsquo;s AMQP endpoint.   HONO_COMMANDROUTER_AMQP_SECUREPROTOCOLS\n--hono.commandRouter.amqp.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_COMMANDROUTER_AMQP_SUPPORTEDCIPHERSUITES\n--hono.commandRouter.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.    The variables only need to be set if the default value does not match your environment.\nPort Configuration The Command Router component supports configuration of an AMQP based endpoint that can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The server will fail to start if none of the ports is configured properly.\nSecure Port Only The server needs to be configured with a private key and certificate in order to open a TLS secured port.\nThere are two alternative ways for doing so:\n Setting the HONO_COMMANDROUTER_AMQP_KEY_STORE_PATH and the HONO_COMMANDROUTER_AMQP_KEY_STORE_PASSWORD variables in order to load the key \u0026amp; certificate from a password protected key store, or setting the HONO_COMMANDROUTER_AMQP_KEY_PATH and HONO_COMMANDROUTER_AMQP_CERT_PATH variables in order to load the key and certificate from two separate PEM files in PKCS8 format.  When starting up, the server will bind a TLS secured socket to the default secure AMQP port 5671. The port number can also be set explicitly using the HONO_COMMANDROUTER_AMQP_PORT variable.\nThe HONO_COMMANDROUTER_AMQP_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-TLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled either by\n explicitly setting HONO_COMMANDROUTER_AMQP_INSECURE_PORT to a valid port number, or by implicitly configuring the default AMQP port (5672) by simply setting HONO_COMMANDROUTER_AMQP_INSECURE_PORT_ENABLED to true.  The server issues a warning on the console if HONO_COMMANDROUTER_AMQP_INSECURE_PORT is set to the default secure AMQP port (5671).\nThe HONO_COMMANDROUTER_AMQP_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-TLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nDual Port In test setups and some production scenarios Hono server may be configured to open one secure and one insecure port at the same time.\nThis is achieved by configuring both ports correctly (see above). The server will fail to start if both ports are configured to use the same port number.\nSince the secure port may need different visibility in the network setup compared to the secure port, it has its own binding address HONO_COMMANDROUTER_AMQP_INSECURE_PORT_BIND_ADDRESS. This can be used to narrow the visibility of the insecure port to a local network e.g., while the secure port may be visible worldwide.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The Command Router component will then use arbitrary (unused) port numbers determined by the operating system during startup.\nCommand \u0026amp; Control Connection Configuration The Command Router component requires a connection to the AMQP 1.0 Messaging Network in order to receive commands from downstream applications and forward them on a specific link on which the target protocol adapter will receive them.\nThe connection is configured according to Hono Client Configuration with HONO_COMMAND being used as ${PREFIX}. The properties for configuring response caching can be ignored.\nTenant Service Connection Configuration The Command Router component requires a connection to an implementation of Hono\u0026rsquo;s Tenant API in order to retrieve information for a tenant.\nThe connection to the Tenant Service is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_TENANT and the additional values for response caching apply.\nThe adapter caches the responses from the service according to the cache directive included in the response. If the response doesn\u0026rsquo;t contain a cache directive no data will be cached.\nDevice Registration Service Connection Configuration The Command Router component requires a connection to an implementation of Hono\u0026rsquo;s Device Registration API in order to retrieve registration status assertions for the target devices of incoming command messages.\nThe connection to the Device Registration Service is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_REGISTRATION.\nThe adapter caches the responses from the service according to the cache directive included in the response. If the response doesn\u0026rsquo;t contain a cache directive no data will be cached.\nNote that the adapter uses a single cache for all responses from the service regardless of the tenant identifier. Consequently, the Device Registration Service client configuration\u0026rsquo;s responseCacheMinSize and responseCacheMaxSize properties determine the overall number of responses that can be cached.\nData Grid Connection Configuration The Command Router component requires either an embedded cache or a remote data grid, using the Infinispan Hotrod protocol to store device information.\nThe following table provides an overview of the configuration variables and corresponding command line options for configuring the common aspects of the service:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_COMMANDROUTER_CACHE_COMMON_CACHENAME\n--hono.commandRouter.cache.common.cacheName no command-router The name of the cache   HONO_COMMANDROUTER_CACHE_COMMON_CHECKKEY\n--hono.commandRouter.cache.common.checkKey no KEY_CONNECTION_CHECK The key used to check the health of the cache. This is only used in case of a remote cache.   HONO_COMMANDROUTER_CACHE_COMMON_CHECKVALUE\n--hono.commandRouter.cache.common.checkValue no VALUE_CONNECTION_CHECK The value used to check the health of the cache. This is only used in case of a remote cache.    The type of cache (embedded or remote) is determined during startup by means of the HONO_COMMANDROUTER_CACHE_REMOTE_SERVERLIST configuration variable. If the variable has a non empty value, a remote cache is configured. Otherwise, an embedded cache is configured.\nRemote cache The following table provides an overview of the configuration variables and corresponding command line options for configuring the connection to the data grid:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_COMMANDROUTER_CACHE_REMOTE_SERVERLIST\n--hono.commandRouter.cache.remote.serverList yes - A list of remote servers in the form: host1[:port][;host2[:port]].....   HONO_COMMANDROUTER_CACHE_REMOTE_AUTHSERVERNAME\n--hono.commandRouter.cache.remote.authServerName yes - The server name to indicate in the SASL handshake when authenticating to the server.   HONO_COMMANDROUTER_CACHE_REMOTE_AUTHREALM\n--hono.commandRouter.cache.remote.authRealm yes - The authentication realm for the SASL handshake when authenticating to the server.   HONO_COMMANDROUTER_CACHE_REMOTE_AUTHUSERNAME\n--hono.commandRouter.cache.remote.authUsername yes - The username to use for authenticating to the server.   HONO_COMMANDROUTER_CACHE_REMOTE_AUTHPASSWORD\n--hono.commandRouter.cache.remote.authPassword yes - The password to use for authenticating to the server.   HONO_COMMANDROUTER_CACHE_REMOTE_SASLMECHANISM\n--hono.commandRouter.cache.remote.saslMechanism yes - The SASL mechanism to use for authenticating to the server.    In general, the service supports all configuration properties of the Infinispan Hotrod client using hono.commandRouter.cache.remote instead of the infinispan.client.hotrod prefix.\nEmbedded cache The following table provides an overview of the configuration variables and corresponding command line options for configuring the embedded cache:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_COMMANDROUTER_CACHE_EMBEDDED_CONFIGURATIONFILE\n--hono.commandRouter.cache.embedded.configurationFile yes - The absolute path to an Infinispan configuration file. Also see the Infinispan Configuration Schema.    Authentication Service Connection Configuration The Command Router component requires a connection to an implementation of Hono\u0026rsquo;s Authentication API in order to authenticate and authorize client requests.\nThe connection is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_AUTH. Since Hono\u0026rsquo;s Authentication Service does not allow caching of the responses, the cache properties can be ignored.\nIn addition to the standard client configuration properties, following properties need to be set for the connection:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_AUTH_VALIDATION_CERT_PATH\n--hono.auth.validation.certPath no - The absolute path to the PEM file containing the public key that the service should use for validating tokens issued by the Authentication service. Alternatively, a symmetric key can be used for validating tokens by setting the HONO_AUTH_VALIDATION_SHARED_SECRET variable. If none of these variables is set, the service falls back to the key indicated by the HONO_AUTH_CERT_PATH variable. If that variable is also not set, startup of the service fails.   HONO_AUTH_VALIDATION_SHARED_SECRET\n--hono.auth.validation.sharedSecret no - A string to derive a symmetric key from which is used for validating tokens issued by the Authentication service. The key is derived from the string by using the bytes of the String\u0026rsquo;s UTF8 encoding. When setting the validation key using this variable, the Authentication service must be configured with the same key. Alternatively, an asymmetric key pair can be used for validating (and signing) by setting the HONO_AUTH_SIGNING_CERT_PATH variable. If none of these variables is set, startup of the service fails.    Metrics Configuration See Monitoring \u0026amp; Tracing Admin Guide for details on how to configure the reporting of metrics.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/device-connection-config/",
	"title": "Configuring the Device Connection Service",
	"tags": [],
	"description": "",
	"content": "The Device Connection service provides an implementation of Eclipse Hono™\u0026rsquo;s Device Connection API.\nProtocol adapters use this API to store and retrieve information about the gateway that a device is using to connect to Hono\u0026rsquo;s protocol adapters. This information is necessary for routing commands to the particular protocol adapter instance that the gateway used by the device is connected to.\n Deprecation The Device Connection service is deprecated and will be replaced by the Command Router service, implementing the Command Router API. For now, either the Device Connection service or the Command Router service may be used by protocol adapters.  The Device Connection component provides a production grade implementation of the Device Connection API which uses a remote data grid for storing information about device connections. The data grid can be scaled out independently from the Device Connection service components to meet the storage demands at hand.\nThe Device Connection component is implemented as a Spring Boot application. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nService Configuration In addition to the following options, this component supports the options described in Common Configuration.\nThe following table provides an overview of the configuration variables and corresponding command line options for configuring the Device Connection component.\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_APP_MAX_INSTANCES\n--hono.app.maxInstances no #CPU cores The number of Verticle instances to deploy. If not set, one Verticle per processor core is deployed.   HONO_DEVICECONNECTION_AMQP_BIND_ADDRESS\n--hono.deviceConnection.amqp.bindAddress no 127.0.0.1 The IP address of the network interface that the secure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_DEVICECONNECTION_AMQP_CERT_PATH\n--hono.deviceConnection.amqp.certPath no - The absolute path to the PEM file containing the certificate that the server should use for authenticating to clients. This option must be used in conjunction with HONO_DEVICECONNECTION_AMQP_KEY_PATH.\nAlternatively, the HONO_DEVICECONNECTION_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_DEVICECONNECTION_AMQP_INSECURE_PORT\n--hono.deviceConnection.amqp.insecurePort no - The insecure port the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_DEVICECONNECTION_AMQP_INSECURE_PORT_BIND_ADDRESS\n--hono.deviceConnection.amqp.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure AMQP port should be bound to.\nSee Port Configuration below for details.   HONO_DEVICECONNECTION_AMQP_INSECURE_PORT_ENABLED\n--hono.deviceConnection.amqp.insecurePortEnabled no false If set to true the server will open an insecure port (not secured by TLS) using either the port number set via HONO_DEVICECONNECTION_AMQP_INSECURE_PORT or the default AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   HONO_DEVICECONNECTION_AMQP_KEY_PATH\n--hono.deviceConnection.amqp.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the server should use for authenticating to clients. This option must be used in conjunction with HONO_DEVICECONNECTION_AMQP_CERT_PATH. Alternatively, the HONO_DEVICECONNECTION_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_DEVICECONNECTION_AMQP_KEY_STORE_PASSWORD\n--hono.deviceConnection.amqp.keyStorePassword no - The password required to read the contents of the key store.   HONO_DEVICECONNECTION_AMQP_KEY_STORE_PATH\n--hono.deviceConnection.amqp.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the server should use for authenticating to clients. Either this option or the HONO_DEVICECONNECTION_AMQP_KEY_PATH and HONO_DEVICECONNECTION_AMQP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_DEVICECONNECTION_AMQP_NATIVE_TLS_REQUIRED\n--hono.deviceConnection.amqp.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_DEVICECONNECTION_AMQP_PORT\n--hono.deviceConnection.amqp.port no 5671 The secure port that the server should listen on for AMQP 1.0 connections.\nSee Port Configuration below for details.   HONO_DEVICECONNECTION_AMQP_RECEIVER_LINK_CREDIT\n--hono.deviceConnection.amqp.receiverLinkCredit no 100 The number of credits to flow to a client connecting to the service\u0026rsquo;s AMQP endpoint.   HONO_DEVICECONNECTION_AMQP_SECUREPROTOCOLS\n--hono.deviceConnection.amqp.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_DEVICECONNECTION_AMQP_SUPPORTEDCIPHERSUITES\n--hono.deviceConnection.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that are supported when negotiating TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.    The variables only need to be set if the default value does not match your environment.\nPort Configuration The Device Connection component supports configuration of an AMQP based endpoint that can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The server will fail to start if none of the ports is configured properly.\nSecure Port Only The server needs to be configured with a private key and certificate in order to open a TLS secured port.\nThere are two alternative ways for doing so:\n Setting the HONO_DEVICECONNECTION_AMQP_KEY_STORE_PATH and the HONO_DEVICECONNECTION_AMQP_KEY_STORE_PASSWORD variables in order to load the key \u0026amp; certificate from a password protected key store, or setting the HONO_DEVICECONNECTION_AMQP_KEY_PATH and HONO_DEVICECONNECTION_AMQP_CERT_PATH variables in order to load the key and certificate from two separate PEM files in PKCS8 format.  When starting up, the server will bind a TLS secured socket to the default secure AMQP port 5671. The port number can also be set explicitly using the HONO_DEVICECONNECTION_AMQP_PORT variable.\nThe HONO_DEVICECONNECTION_AMQP_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-TLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled either by\n explicitly setting HONO_DEVICECONNECTION_AMQP_INSECURE_PORT to a valid port number, or by implicitly configuring the default AMQP port (5672) by simply setting HONO_DEVICECONNECTION_AMQP_INSECURE_PORT_ENABLED to true.  The server issues a warning on the console if HONO_DEVICECONNECTION_AMQP_INSECURE_PORT is set to the default secure AMQP port (5671).\nThe HONO_DEVICECONNECTION_AMQP_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-TLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nDual Port In test setups and some production scenarios Hono server may be configured to open one secure and one insecure port at the same time.\nThis is achieved by configuring both ports correctly (see above). The server will fail to start if both ports are configured to use the same port number.\nSince the secure port may need different visibility in the network setup compared to the secure port, it has its own binding address HONO_DEVICECONNECTION_AMQP_INSECURE_PORT_BIND_ADDRESS. This can be used to narrow the visibility of the insecure port to a local network e.g., while the secure port may be visible worldwide.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The Device Connection component will then use arbitrary (unused) port numbers determined by the operating system during startup.\nData Grid Connection Configuration The Device Connection component requires either an embedded cache or a remote data grid, using the Infinispan Hotrod protocol to store device information.\nThe following table provides an overview of the configuration variables and corresponding command line options for configuring the common aspects of the service:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_DEVICECONNECTION_COMMON_CACHENAME\n--hono.deviceConnection.common.cacheName no device-connection The name of the cache   HONO_DEVICECONNECTION_COMMON_CHECKKEY\n--hono.deviceConnection.common.checkKey no KEY_CONNECTION_CHECK The key used to check the health of the cache. This is only used in case of a remote cache.   HONO_DEVICECONNECTION_COMMON_CHECKVALUE\n--hono.deviceConnection.common.checkValue no VALUE_CONNECTION_CHECK The value used to check the health of the cache. This is only used in case of a remote cache.    The type of the cache is selected on startup by enabling or disabling the profile embedded-cache. If the profile is enabled the embedded cache is used, otherwise the remote cache is being used. The remote cache is the default.\nRemote cache The following table provides an overview of the configuration variables and corresponding command line options for configuring the connection to the data grid:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_DEVICECONNECTION_REMOTE_SERVERLIST\n--hono.deviceConnection.remote.serverList yes - A list of remote servers in the form: host1[:port][;host2[:port]].....   HONO_DEVICECONNECTION_REMOTE_AUTHSERVERNAME\n--hono.deviceConnection.remote.authServerName yes - The server name to indicate in the SASL handshake when authenticating to the server.   HONO_DEVICECONNECTION_REMOTE_AUTHREALM\n--hono.deviceConnection.remote.authRealm yes - The authentication realm for the SASL handshake when authenticating to the server.   HONO_DEVICECONNECTION_REMOTE_AUTHUSERNAME\n--hono.deviceConnection.remote.authUsername yes - The username to use for authenticating to the server.   HONO_DEVICECONNECTION_REMOTE_AUTHPASSWORD\n--hono.deviceConnection.remote.authPassword yes - The password to use for authenticating to the server.    In general, the service supports all configuration properties of the Infinispan Hotrod client using hono.deviceConnection.remote instead of the infinispan.client.hotrod prefix.\nEmbedded cache The following table provides an overview of the configuration variables and corresponding command line options for configuring the embedded cache:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_DEVICECONNECTION_EMBEDDED_CONFIGURATIONFILE\n--hono.deviceConnection.embedded.configurationFile yes - The absolute path to an Infinispan configuration file. Also see the Infinispan Configuration Schema.    Authentication Service Connection Configuration The Device Connection component requires a connection to an implementation of Hono\u0026rsquo;s Authentication API in order to authenticate and authorize client requests.\nThe connection is configured according to Hono Client Configuration where the ${PREFIX} is set to HONO_AUTH. Since Hono\u0026rsquo;s Authentication Service does not allow caching of the responses, the cache properties can be ignored.\nIn addition to the standard client configuration properties, following properties need to be set for the connection:\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_AUTH_VALIDATION_CERT_PATH\n--hono.auth.validation.certPath no - The absolute path to the PEM file containing the public key that the service should use for validating tokens issued by the Authentication service. Alternatively, a symmetric key can be used for validating tokens by setting the HONO_AUTH_VALIDATION_SHARED_SECRET variable. If none of these variables is set, the service falls back to the key indicated by the HONO_AUTH_CERT_PATH variable. If that variable is also not set, startup of the service fails.   HONO_AUTH_VALIDATION_SHARED_SECRET\n--hono.auth.validation.sharedSecret no - A string to derive a symmetric key from which is used for validating tokens issued by the Authentication service. The key is derived from the string by using the bytes of the String\u0026rsquo;s UTF8 encoding. When setting the validation key using this variable, the Authentication service must be configured with the same key. Alternatively, an asymmetric key pair can be used for validating (and signing) by setting the HONO_AUTH_SIGNING_CERT_PATH variable. If none of these variables is set, startup of the service fails.    Metrics Configuration See Monitoring \u0026amp; Tracing Admin Guide for details on how to configure the reporting of metrics.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/http-adapter-config/",
	"title": "HTTP Adapter Configuration",
	"tags": [],
	"description": "",
	"content": "The HTTP protocol adapter exposes HTTP based endpoints for Eclipse Hono™\u0026rsquo;s south bound Telemetry, Event and Command \u0026amp; Control APIs.\nThe adapter is implemented as a Spring Boot application. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nThe adapter supports the following standard configuration options:\n Common Java VM Options Common vert.x Options Common Protocol Adapter Options Monitoring Options  Service Configuration The following table provides an overview of the configuration variables and corresponding command line options for configuring the HTTP adapter.\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_APP_MAX_INSTANCES\n--hono.app.maxInstances no #CPU cores The number of verticle instances to deploy. If not set, one verticle per processor core is deployed.   HONO_HTTP_AUTHENTICATION_REQUIRED\n--hono.http.authenticationRequired no true If set to true the protocol adapter requires devices to authenticate when connecting to the adapter. The credentials provided by the device are verified using the configured Credentials Service. Devices that have failed to authenticate are not allowed to publish any data.   HONO_HTTP_BIND_ADDRESS\n--hono.http.bindAddress no 127.0.0.1 The IP address of the network interface that the secure port should be bound to.\nSee Port Configuration below for details.   HONO_HTTP_CERT_PATH\n--hono.http.certPath no - The absolute path to the PEM file containing the certificate that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_HTTP_KEY_PATH.\nAlternatively, the HONO_HTTP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_HTTP_DEFAULTS_ENABLED\n--hono.http.defaultsEnabled no true If set to true the protocol adapter uses default values registered for a device to augment messages published by the device with missing information like a content type. In particular, the protocol adapter adds default values registered for the device as (application) properties with the same name to the AMQP 1.0 messages it sends downstream to the AMQP Messaging Network.   HONO_HTTP_INSECURE_PORT\n--hono.http.insecurePort no - The insecure port the protocol adapter should listen on.\nSee Port Configuration below for details.   HONO_HTTP_INSECURE_PORT_BIND_ADDRESS\n--hono.http.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure port should be bound to.\nSee Port Configuration below for details.   HONO_HTTP_INSECURE_PORT_ENABLED\n--hono.http.insecurePortEnabled no false If set to true the protocol adapter will open an insecure port (not secured by TLS) using either the port number set via HONO_HTTP_INSECURE_PORT or the default port number (8080) if not set explicitly.\nSee Port Configuration below for details.   HONO_HTTP_KEY_PATH\n--hono.http.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_HTTP_CERT_PATH. Alternatively, the HONO_HTTP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_HTTP_KEY_STORE_PASSWORD\n--hono.http.keyStorePassword no - The password required to read the contents of the key store.   HONO_HTTP_KEY_STORE_PATH\n--hono.http.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the protocol adapter should use for authenticating to clients. Either this option or the HONO_HTTP_KEY_PATH and HONO_HTTP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_HTTP_SNI\n--hono.http.sni no false Set whether the server supports Server Name Indication. By default, the server will not support SNI and the option is false. However, if set to true then the key store format , HONO_HTTP_KEY_STORE_PATH, should be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_HTTP_NATIVE_TLS_REQUIRED\n--hono.http.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_HTTP_MAX_PAYLOAD_SIZE\n--hono.http.maxPayloadSize no 2048 The maximum allowed size of an incoming HTTP request\u0026rsquo;s body in bytes. Requests with a larger body size are rejected with a 413 Request entity too large response.   HONO_HTTP_PORT\n--hono.http.port no 8443 The secure port that the protocol adapter should listen on.\nSee Port Configuration below for details.   HONO_HTTP_REALM\n--hono.http.realm no Hono The name of the realm that unauthenticated devices are prompted to provide credentials for. The realm is used in the WWW-Authenticate header returned to devices in response to unauthenticated requests.   HONO_HTTP_SECUREPROTOCOLS\n--hono.http.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_AMQP_SUPPORTEDCIPHERSUITES\n--hono.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that the adapter may use in TLS sessions with devices. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_HTTP_TENANT_IDLE_TIMEOUT\n--hono.http.tenantIdleTimeout no 0ms The duration after which the protocol adapter removes local state of the tenant (e.g. open AMQP links) with an amount and a unit, e.g. 2h for 2 hours. See the Spring Boot documentation for an explanation of the format. The value 0ms disables the timeout.    The variables only need to be set if the default value does not match your environment.\nPort Configuration The HTTP protocol adapter can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The HTTP protocol adapter will fail to start if none of the ports is configured properly.\nSecure Port Only The protocol adapter needs to be configured with a private key and certificate in order to open a TLS secured port.\nThere are two alternative ways for doing so:\n Setting the HONO_HTTP_KEY_STORE_PATH and the HONO_HTTP_KEY_STORE_PASSWORD variables in order to load the key \u0026amp; certificate from a password protected key store, or setting the HONO_HTTP_KEY_PATH and HONO_HTTP_CERT_PATH variables in order to load the key and certificate from two separate PEM files in PKCS8 format.  When starting up, the protocol adapter will bind a TLS secured socket to the default secure port 8443. The port number can also be set explicitly using the HONO_HTTP_PORT variable.\nThe HONO_HTTP_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-TLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled either by\n explicitly setting HONO_HTTP_INSECURE_PORT to a valid port number, or by implicitly configuring the default port (8080) by simply setting HONO_HTTP_INSECURE_PORT_ENABLED to true.  The protocol adapter issues a warning on the console if HONO_HTTP_INSECURE_PORT is set to the default secure HTTP port (8443).\nThe HONO_HTTP_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-TLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nDual Port The protocol adapter may be configured to open both a secure and a non-secure port at the same time simply by configuring both ports as described above. For this to work, both ports must be configured to use different port numbers, otherwise startup will fail.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The protocol adapter will then use arbitrary (unused) port numbers determined by the operating system during startup.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/mqtt-adapter-config/",
	"title": "MQTT Adapter Configuration",
	"tags": [],
	"description": "",
	"content": "The MQTT protocol adapter exposes an MQTT topic hierarchy for Eclipse Hono™\u0026rsquo;s south bound Telemetry, Event and Command \u0026amp; Control APIs.\nThe adapter is implemented as a Spring Boot application. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nThe adapter supports the following standard configuration options:\n Common Java VM Options Common vert.x Options Common Protocol Adapter Options Monitoring Options  Service Configuration The following table provides an overview of the configuration variables and corresponding command line options for configuring the MQTT adapter.\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     HONO_APP_MAX_INSTANCES\n--hono.app.maxInstances no #CPU cores The number of verticle instances to deploy. If not set, one verticle per processor core is deployed.   HONO_CONNECTION_EVENTS_PRODUCER\n--hono.connectionEvents.producer no logging The implementation of connection events producer which is to be used. This may be logging or events.\nSee Connection Events   HONO_MQTT_AUTHENTICATION_REQUIRED\n--hono.mqtt.authenticationRequired no true If set to true the protocol adapter requires devices to authenticate when connecting to the adapter. The credentials provided by the device are verified using the configured Credentials Service. Devices that have failed to authenticate are not allowed to publish any data.   HONO_MQTT_BIND_ADDRESS\n--hono.mqtt.bindAddress no 127.0.0.1 The IP address of the network interface that the secure port should be bound to.\nSee Port Configuration below for details.   HONO_MQTT_CERT_PATH\n--hono.mqtt.certPath no - The absolute path to the PEM file containing the certificate that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_MQTT_KEY_PATH.\nAlternatively, the HONO_MQTT_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_MQTT_COMMAND_ACK_TIMEOUT\n--hono.mqtt.commandAckTimeout no 100 Deprecated. Use HONO_MQTT_SEND_MESSAGE_TO_DEVICE_TIMEOUT instead. The amount of time (milliseconds) after which the sending of a command to a device using QoS 1 is considered to be failed. The value of this variable should be increased in cases where devices are connected over a network with high latency.   HONO_MQTT_SEND_MESSAGE_TO_DEVICE_TIMEOUT\n--hono.mqtt.sendMessageToDeviceTimeout no 1000 The amount of time (milliseconds) after which the sending of a command or an error message to a device using QoS 1 is considered to be failed. The value of this variable should be increased in cases where devices are connected over a network with high latency.   HONO_MQTT_DEFAULTS_ENABLED\n--hono.mqtt.defaultsEnabled no true If set to true the protocol adapter uses default values registered for a device to augment messages published by the device with missing information like a content type. In particular, the protocol adapter adds default values registered for the device as (application) properties with the same name to the AMQP 1.0 messages it sends downstream to the AMQP Messaging Network.   HONO_MQTT_INSECURE_PORT_BIND_ADDRESS\n--hono.mqtt.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure port should be bound to.\nSee Port Configuration below for details.   HONO_MQTT_INSECURE_PORT_ENABLED\n--hono.mqtt.insecurePortEnabled no false If set to true the protocol adapter will open an insecure port (not secured by TLS) using either the port number set via HONO_MQTT_INSECURE_PORT or the default MQTT port number (1883) if not set explicitly.\nSee Port Configuration below for details.   HONO_MQTT_KEY_PATH\n--hono.mqtt.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_MQTT_CERT_PATH. Alternatively, the HONO_MQTT_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_MQTT_KEY_STORE_PASSWORD\n--hono.mqtt.keyStorePassword no - The password required to read the contents of the key store.   HONO_MQTT_KEY_STORE_PATH\n--hono.mqtt.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the protocol adapter should use for authenticating to clients. Either this option or the HONO_MQTT_KEY_PATH and HONO_MQTT_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_MQTT_SNI\n--hono.mqtt.sni no false Set whether the server supports Server Name Indication. By default, the server will not support SNI and the option is false. However, if set to true then the key store format , HONO_MQTT_KEY_STORE_PATH, should be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_MQTT_MAX_CONNECTIONS\n--hono.mqtt.maxConnections no 0 The maximum number of concurrent connections that the protocol adapter should accept. If not set (or set to 0), the protocol adapter determines a reasonable value based on the available resources like memory and CPU.   HONO_MQTT_MAX_PAYLOAD_SIZE\n--hono.mqtt.maxPayloadSize no 2048 The maximum allowed size of an incoming MQTT message\u0026rsquo;s payload in bytes. When a client sends a message with a larger payload, the message is discarded and the connection to the client gets closed.   HONO_MQTT_NATIVE_TLS_REQUIRED\n--hono.mqtt.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_MQTT_PORT\n--hono.mqtt.port no 8883 The secure port that the protocol adapter should listen on.\nSee Port Configuration below for details.   HONO_MQTT_SECUREPROTOCOLS\n--hono.mqtt.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_MQTT_SUPPORTEDCIPHERSUITES\n--hono.mqtt.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that the adapter may use in TLS sessions with devices. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_MQTT_TENANT_IDLE_TIMEOUT\n--hono.mqtt.tenantIdleTimeout no 0ms The duration after which the protocol adapter removes local state of the tenant (e.g. open AMQP links) with an amount and a unit, e.g. 2h for 2 hours. See the Spring Boot documentation for an explanation of the format. The value 0ms disables the timeout.    The variables only need to be set if the default values do not match your environment.\nPort Configuration The MQTT protocol adapter can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The MQTT protocol adapter will fail to start if none of the ports is configured properly.\nSecure Port Only The protocol adapter needs to be configured with a private key and certificate in order to open a TLS secured port.\nThere are two alternative ways for doing so:\n either setting the HONO_MQTT_KEY_STORE_PATH and the HONO_MQTT_KEY_STORE_PASSWORD variables in order to load the key \u0026amp; certificate from a password protected key store, or setting the HONO_MQTT_KEY_PATH and HONO_MQTT_CERT_PATH variables in order to load the key and certificate from two separate PEM files in PKCS8 format.  When starting up, the protocol adapter will bind a TLS secured socket to the default secure MQTT port 8883. The port number can also be set explicitly using the HONO_MQTT_PORT variable.\nThe HONO_MQTT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-TLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled either by\n explicitly setting HONO_MQTT_INSECURE_PORT to a valid port number, or by implicitly configuring the default MQTT port (1883) by simply setting HONO_MQTT_INSECURE_PORT_ENABLED to true.  The protocol adapter issues a warning on the console if HONO_MQTT_INSECURE_PORT is set to the default secure MQTT port (8883).\nThe HONO_MQTT_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-TLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nDual Port The protocol adapter may be configured to open both a secure and a non-secure port at the same time simply by configuring both ports as described above. For this to work, both ports must be configured to use different port numbers, otherwise startup will fail.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The protocol adapter will then use arbitrary (unused) port numbers determined by the operating system during startup.\nCustom Message Mapping This protocol adapter supports transformation of messages that have been uploaded by devices before forwarding them to downstream consumers. This message mapping can be used to overwrite the deviceID, add additional properties and change the payload.\n Experimental This is an experimental feature. The names of the configuration properties, potential values and the overall functionality are therefore subject to change without prior notice.  The following table provides an overview of the configuration variables and corresponding command line options for configuring the external service endpoint(s) for transforming messages:\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     HONO_MQTT_MAPPERENDPOINTS_\u0026lt;mapperName\u0026gt;_HOST\n--hono.mqtt.mapperEndpoints.\u0026lt;mapperName\u0026gt;.host no - The host name or IP address of the service to invoke for transforming uploaded messages. The \u0026lt;mapperName\u0026gt; needs to contain the service name as set in the mapper property of the device\u0026rsquo;s registration information.   HONO_MQTT_MAPPERENDPOINTS_\u0026lt;mapperName\u0026gt;_PORT\n--hono.mqtt.mapperEndpoints.\u0026lt;mapperName\u0026gt;.port no - The port of the service to invoke for transforming uploaded messages. The \u0026lt;mapperName\u0026gt; needs to contain the service name as set in the mapper property of the device\u0026rsquo;s registration information.   HONO_MQTT_MAPPERENDPOINTS_\u0026lt;mapperName\u0026gt;_URI\n--hono.mqtt.mapperEndpoints.\u0026lt;mapperName\u0026gt;.uri no - The URI of the service to invoke for transforming uploaded messages. The \u0026lt;mapperName\u0026gt; needs to contain the service name as set in the mapper property of the device\u0026rsquo;s registration information.    Implementation An implementation of the mapper needs to be provided. Following data will be provided to the mapper:\n HTTP headers:  orig_address content-type all strings configured during registration   Body  The payload of the message is provided in the body of the mapping request    When the mapper responds successfully(=200), the adapter will map the returning values as follows:\n The header with key device_id will overwrite the current deviceID. The remaining HTTP headers will be added to the downstream message as additional properties. The returned body will be used to replace the payload. "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/amqp-adapter-config/",
	"title": "AMQP Adapter Configuration",
	"tags": [],
	"description": "",
	"content": "The AMQP protocol adapter exposes AMQP based endpoints for Eclipse Hono™\u0026rsquo;s south bound Telemetry, Event and Command \u0026amp; Control APIs.\nThe adapter is implemented as a Spring Boot application. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nThe adapter supports the following standard configuration options:\n Common Java VM Options Common vert.x Options Common Protocol Adapter Options Monitoring Options  Service Configuration The following table provides an overview of the configuration variables and corresponding command line options for configuring the AMQP adapter.\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     HONO_AMQP_AUTHENTICATION_REQUIRED\n--hono.amqp.authenticationRequired no true If set to true the protocol adapter requires devices to authenticate when connecting to the adapter. The credentials provided by the device are verified using the configured Credentials Service. Devices that have failed to authenticate are not allowed to publish any data.   HONO_AMQP_BIND_ADDRESS\n--hono.amqp.bindAddress no 127.0.0.1 The IP address of the network interface that the secure port should be bound to.\nSee Port Configuration below for details.   HONO_AMQP_CERT_PATH\n--hono.amqp.certPath no - The absolute path to the PEM file containing the certificate that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_AMQP_KEY_PATH.\nAlternatively, the HONO_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_AMQP_DEFAULTS_ENABLED\n--hono.amqp.defaultsEnabled no true If set to true the protocol adapter uses default values registered for a device to augment messages published by the device with missing information like a content type. In particular, the protocol adapter adds default values registered for the device as (application) properties with the same name to the AMQP 1.0 messages it sends downstream to the AMQP Messaging Network.   HONO_AMQP_IDLE_TIMEOUT\n--hono.amqp.idleTimeout no 60000 The time interval (milliseconds) to wait for incoming traffic from a device before the connection should be considered stale and thus be closed. Setting this property to 0 prevents the adapter from detecting and closing stale connections.   HONO_AMQP_SEND_MESSAGE_TO_DEVICE_TIMEOUT\n--hono.amqp.sendMessageToDeviceTimeout no 1000 The time interval (milliseconds) to wait for a device to acknowledge receiving a (command) message before the AMQP link used for sending the message will be closed. Setting this property to 0 means the adapter waits indefinitely for a device to acknowledge receiving the message.   HONO_AMQP_INSECURE_PORT_BIND_ADDRESS\n--hono.amqp.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure port should be bound to.\nSee Port Configuration below for details.   HONO_AMQP_INSECURE_PORT\n--hono.amqp.insecurePort no 5672 The port number that the protocol adapter should listen on for insecure connections.\nSee Port Configuration below for details.   HONO_AMQP_INSECURE_PORT_ENABLED\n--hono.amqp.insecurePortEnabled no false If set to true the protocol adapter will open an insecure port (not secured by TLS) using either the port number set via HONO_AMQP_INSECURE_PORT or the default AMQP port number (1883) if not set explicitly.\nSee Port Configuration below for details.   HONO_AMQP_KEY_PATH\n--hono.amqp.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_AMQP_CERT_PATH. Alternatively, the HONO_AMQP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_AMQP_KEY_STORE_PASSWORD\n--hono.amqp.keyStorePassword no - The password required to read the contents of the key store.   HONO_AMQP_KEY_STORE_PATH\n--hono.amqp.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the protocol adapter should use for authenticating to clients. Either this option or the HONO_AMQP_KEY_PATH and HONO_AMQP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_AMQP_SNI\n--hono.amqp.sni no false Set whether the server supports Server Name Indication. By default, the server will not support SNI and the option is false. However, if set to true then the key store format, HONO_AMQP_KEY_STORE_PATH, should be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_AMQP_MAX_CONNECTIONS\n--hono.amqp.maxConnections no 0 The maximum number of concurrent connections that the protocol adapter should accept. If not set (or set to 0), the protocol adapter determines a reasonable value based on the available resources like memory and CPU.   HONO_AMQP_MAX_FRAME_SIZE\n--hono.amqp.maxFrameSize no 16384 The maximum size (in bytes) of a single AMQP frame that the adapter should accept from the device. When a device sends a bigger frame, the connection will be closed.   HONO_AMQP_MAX_PAYLOAD_SIZE\n--hono.amqp.maxPayloadSize no 2048 The maximum allowed size of an incoming AMQP message in bytes. When a client sends a message with a larger payload, the message is discarded and the link to the client is closed.   HONO_AMQP_MAX_SESSION_FRAMES\n--hono.amqp.maxSessionFrames no 30 The maximum number of AMQP transfer frames for sessions created on this connection. This is the number of transfer frames that may simultaneously be in flight for all links in the session.   HONO_AMQP_NATIVE_TLS_REQUIRED\n--hono.amqp.nativeTlsRequired no false The server will probe for OpenSSL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_AMQP_PORT\n--hono.amqp.port no 5671 The secure port that the protocol adapter should listen on.\nSee Port Configuration below for details.   HONO_AMQP_SECURE_PROTOCOLS\n--hono.amqp.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_AMQP_SUPPORTEDCIPHERSUITES\n--hono.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that the adapter may use in TLS sessions with devices. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_AMQP_TENANT_IDLE_TIMEOUT\n--hono.amqp.tenantIdleTimeout no 0ms The duration after which the protocol adapter removes local state of the tenant (e.g. open AMQP links) with an amount and a unit, e.g. 2h for 2 hours. See the Spring Boot documentation for an explanation of the format. The value 0ms disables the timeout.   HONO_APP_MAX_INSTANCES\n--hono.app.maxInstances no #CPU cores The number of verticle instances to deploy. If not set, one verticle per processor core is deployed.    The variables only need to be set if the default values do not match your environment.\nPort Configuration The AMQP protocol adapter can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The AMQP protocol adapter will fail to start if none of the ports is configured properly.\nSecure Port Only The protocol adapter needs to be configured with a private key and certificate in order to open a TLS secured port.\nThere are two alternative ways for doing so:\n either setting the HONO_AMQP_KEY_STORE_PATH and the HONO_AMQP_KEY_STORE_PASSWORD variables in order to load the key \u0026amp; certificate from a password protected key store, or setting the HONO_AMQP_KEY_PATH and HONO_AMQP_CERT_PATH variables in order to load the key and certificate from two separate PEM files in PKCS8 format.  When starting up, the protocol adapter will bind a TLS secured socket to the default secure port 5671. The port number can also be set explicitly using the HONO_AMQP_PORT variable.\nThe HONO_AMQP_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-TLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled either by\n explicitly setting HONO_AMQP_INSECURE_PORT to a valid port number, or by implicitly configuring the default adapter port (5672) by simply setting HONO_AMQP_INSECURE_PORT_ENABLED to true.  The protocol adapter issues a warning on the console if HONO_AMQP_INSECURE_PORT is set to the default secure port (5671) used by the adapter for secure connections.\nThe HONO_AMQP_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-TLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nDual Port The protocol adapter may be configured to open both a secure and a non-secure port at the same time simply by configuring both ports as described above. For this to work, both ports must be configured to use different port numbers, otherwise startup will fail.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The protocol adapter will then use arbitrary (unused) port numbers determined by the operating system during startup.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/coap-adapter-config/",
	"title": "CoAP Adapter Configuration",
	"tags": [],
	"description": "",
	"content": "The CoAP protocol adapter exposes CoAP based endpoints for Eclipse Hono™\u0026rsquo;s south bound Telemetry, Event and Command \u0026amp; Control APIs.\nThe adapter is implemented as a Spring Boot application using Eclipse Californium™ for implementing the CoAP protocol handling. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nThe adapter supports the following standard configuration options:\n Common Java VM Options Common vert.x Options Common Protocol Adapter Options Monitoring Options  Service Configuration The following table provides an overview of the configuration variables and corresponding command line options for configuring the CoAP adapter.\n   Environment Variable\nCommand Line Option Mandatory Default Description     HONO_APP_MAX_INSTANCES\n--hono.app.maxInstances no #CPU cores The number of verticle instances to deploy. If not set, one verticle per processor core is deployed.   HONO_COAP_AUTHENTICATION_REQUIRED\n--hono.coap.authenticationRequired no true If set to true the protocol adapter requires devices to authenticate when connecting to the adapter. The credentials provided by the device are verified using the configured Credentials Service. Devices that fail to authenticate are not allowed to connect to the adapter.   HONO_COAP_BIND_ADDRESS\n--hono.coap.bindAddress no 127.0.0.1 The IP address of the network interface that the secure port should be bound to.\nSee Port Configuration below for details.   HONO_COAP_CERT_PATH\n--hono.coap.certPath no - The absolute path to the PEM file containing the certificate that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_COAP_KEY_PATH.\nAlternatively, the HONO_COAP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate. Note that the CoAP adapter supports ECDSA based keys only.   HONO_COAP_COAP_THREADS\n--hono.coap.coapThreads no 2 The number of threads to use for processing CoAP message exchanges at the protocol layer.   HONO_COAP_CONNECTOR_THREADS\n--hono.coap.connectorThreads no 2 The number of threads to use for receiving/sending UDP packets. The connector will start the given number of threads for each direction, outbound (sending) as well as inbound (receiving).   HONO_COAP_DTLS_THREADS\n--hono.coap.dtlsThreads no 32 The number of threads to use for processing DTLS message exchanges at the connection layer.   HONO_COAP_DTLS_RETRANSMISSION_TIMEOUT\n--hono.coap.dtlsRetransmissionTimeout no 2000 The timeout in milliseconds for DTLS retransmissions.   HONO_COAP_DEFAULTS_ENABLED\n--hono.coap.defaultsEnabled no true If set to true the protocol adapter uses default values registered for a device to augment messages published by the device with missing information like a content type. In particular, the protocol adapter adds default values registered for the device as (application) properties with the same name to the AMQP 1.0 messages it sends downstream to the AMQP Messaging Network.   HONO_COAP_EXCHANGE_LIFETIME\n--hono.coap.exchangeLifetime no 247000 The exchange lifetime in milliseconds. According RFC 7252, that value is 247s. Such a large time requires also a huge amount of heap. That time includes a processing time of 100s and retransmissions of CON messages. Therefore a practical value could be much smaller.   HONO_COAP_INSECURE_NETWORK_CONFIG\n--hono.coap.insecureNetworkConfig no - The absolute path to a Californium properties file containing network configuration properties that should be used for the insecure CoAP port. If not set, Californium\u0026rsquo;s default properties will be used.   HONO_COAP_INSECURE_PORT\n--hono.coap.insecurePort no - The insecure port the protocol adapter should listen on.\nSee Port Configuration below for details.   HONO_COAP_INSECURE_PORT_BIND_ADDRESS\n--hono.coap.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure port should be bound to.\nSee Port Configuration below for details.   HONO_COAP_INSECURE_PORT_ENABLED\n--hono.coap.insecurePortEnabled no false If set to true the protocol adapter will open an insecure port (not secured by TLS) using either the port number set via HONO_COAP_INSECURE_PORT or the default port number (5683) if not set explicitly.\nSee Port Configuration below for details.   HONO_COAP_KEY_PATH\n--hono.coap.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_COAP_CERT_PATH. Alternatively, the HONO_COAP_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate. Note that the CoAP adapter supports ECDSA based keys only.   HONO_COAP_KEY_STORE_PASSWORD\n--hono.coap.keyStorePassword no - The password required to read the contents of the key store.   HONO_COAP_KEY_STORE_PATH\n--hono.coap.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the protocol adapter should use for authenticating to clients. Either this option or the HONO_COAP_KEY_PATH and HONO_COAP_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively. Note that the CoAP adapter supports ECDSA based keys only.   HONO_COAP_MAX_CONNECTIONS\n--hono.coap.maxConnections no 0 The maximum number of concurrent DTLS connections that the protocol adapter should accept. If set to 0, the protocol adapter determines a reasonable value based on the available resources like memory and CPU.   HONO_COAP_MAX_PAYLOAD_SIZE\n--hono.coap.maxPayloadSize no 2048 The maximum allowed size of an incoming CoAP request\u0026rsquo;s body in bytes. Requests with a larger body size are rejected with a 4.13 Request entity too large response.   HONO_COAP_MESSAGE_OFFLOADING_ENABLED\n--hono.coap.messageOffloadingEnabled no true Enables to clear payload and serialized messages kept for deduplication in order to reduce the heap consumption. Experimental.   HONO_COAP_NETWORK_CONFIG\n--hono.coap.networkConfig no - The absolute path to a Californium properties file containing network configuration properties that should be used for the secure CoAP port. If not set, Californium\u0026rsquo;s default properties will be used.   HONO_COAP_PORT\n--hono.coap.port no - The secure port that the protocol adapter should listen on.\nSee Port Configuration below for details.   HONO_COAP_TENANT_IDLE_TIMEOUT\n--hono.coap.tenantIdleTimeout no 0ms The duration after which the protocol adapter removes local state of the tenant (e.g. open AMQP links) with an amount and a unit, e.g. 2h for 2 hours. See the Spring Boot documentation for an explanation of the format. The value 0ms disables the timeout.   HONO_COAP_TIMEOUT_TO_ACK\n--hono.coap.timeoutToAck no 500 Timeout in milliseconds to send an ACK for a CoAP CON request. If the response is available before that timeout, a more efficient piggybacked response is used. If the timeout is reached without having received a response, an empty ACK is sent back to the client and the response is sent in a separate CON once it becomes available. Special values: -1 means to always piggyback the response in an ACK and never send a separate CON; 0 means to always send an ACK immediately and include the response in a separate CON.    The variables only need to be set if the default value needs to be changed.\nPort Configuration The CoAP protocol adapter can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The CoAP protocol adapter will fail to start if none of the ports is configured properly.\nSecure Port Only The protocol adapter opens a DTLS secured port if any of the following criteria are met\n The HONO_COAP_KEY_STORE_PATH and HONO_COAP_KEY_STORE_PASSWORD environment variables are set in order to load a key and certificate from a password protected key store or the HONO_COAP_KEY_PATH and HONO_COAP_CERT_PATH environment variables are set in order to load a key and certificate from two separate PEM files in PKCS8 format or the HONO_COAP_PORT environment variable is set to a valid port number.  When starting up, the protocol adapter will bind a DTLS secured UDP socket to the configured port. If the port is not set explicitly, the default CoAP secure port 5684 is used.\nThe HONO_COAP_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-DTLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled by\n explicitly setting HONO_COAP_AUTHENTICATION_REQUIRED to false and either  explicitly setting HONO_COAP_INSECURE_PORT to a valid port number or implicitly configuring the default insecure CoAP port (5683) by setting HONO_COAP_INSECURE_PORT_ENABLED to true.    The protocol adapter issues a warning on the console if HONO_COAP_INSECURE_PORT is set to the default secure CoAP port (5684).\nThe HONO_COAP_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-DTLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\n Note The insecure port will only be bound if the HONO_COAP_AUTHENTICATION_REQUIRED variable is set to false because CoAP authenticates clients (devices) as part of the DTLS handshake. Thus, requiring devices to authenticate effectively rules out setting up a non-DTLS secured port.  Dual Port The protocol adapter may be configured to open both a secure and a non-secure port at the same time simply by configuring both ports as described above. For this to work, both ports must be configured to use different port numbers, otherwise startup will fail.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The protocol adapter will then use arbitrary (unused) port numbers determined by the operating system during startup.\nAuthentication The CoAP protocol is UDP based and as such uses the DTLS protocol to secure the communication between a client (device) and a server (adapter). The CoAP adapter also uses the DTLS handshake to prove its identity to devices and to authenticate the devices themselves. The DTLS protocol allows for different cipher suites to be used for doing so. These suites mainly differ from each other in the type of secret being used for proving the participants' identity to each other.\nOne class of suites is based on a secret that is shared between the client and the server, very much like in a username/password based authentication scheme. This class of suites is called pre-shared key or PSK-based and is very popular for use cases where the devices are very constrained regarding CPU and memory. Another class of cipher suites is based on certificates which use asymmetric encryption for proving possession of the secret (the private key).\nThe CoAP adapter supports cipher suites from both classes but only supports cipher suites from the latter class which use ECDSA algorithm for authentication. In particular, this means that the client and/or server need to use elliptic curve cryptography (ECC) based keys instead of RSA based ones.\nWhen enabling the secure port without configuring an ECC based key and certificate, the adapter will only use PSK based cipher suites for authentication. When configuring an ECC based key and certificate, the adapter will also offer certificate based cipher suites to the client to use for authentication.\nIn any case the device\u0026rsquo;s credentials need to be registered with the device registry. Please refer to the Standard Credential Types and the Device Registry Management API for additional information.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/kura-adapter-config/",
	"title": "Kura Adapter Configuration",
	"tags": [],
	"description": "",
	"content": "The Kura protocol adapter exposes an MQTT topic hierarchy allowing Eclipse Kura™ based gateways to access Eclipse Hono™\u0026rsquo;s south bound Telemetry, Event and Command \u0026amp; Control APIs.\nThe adapter is implemented as a Spring Boot application. It can be run either directly from the command line or by means of starting the corresponding Docker image created from it.\nThe adapter supports the following standard configuration options:\n Common Java VM Options Common vert.x Options Common Protocol Adapter Options Monitoring Options  Service Configuration The following table provides an overview of the configuration variables and corresponding command line options for configuring the MQTT adapter.\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     HONO_APP_MAX_INSTANCES\n--hono.app.maxInstances no #CPU cores The number of verticle instances to deploy. If not set, one verticle per processor core is deployed.   HONO_KURA_AUTHENTICATION_REQUIRED\n--hono.kura.authenticationRequired no true If set to true the protocol adapter requires devices to authenticate when connecting to the adapter. The credentials provided by the device are verified using the configured Credentials Service. Devices that have failed to authenticate are not allowed to publish any data.   HONO_KURA_BIND_ADDRESS\n--hono.kura.bindAddress no 127.0.0.1 The IP address of the network interface that the secure port should be bound to.\nSee Port Configuration below for details.   HONO_KURA_CERT_PATH\n--hono.kura.certPath no - The absolute path to the PEM file containing the certificate that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_KURA_KEY_PATH.\nAlternatively, the HONO_KURA_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_KURA_CONTROL_PREFIX\n--hono.kura.controlPrefix no $EDC The topic.control-prefix to use for determining if a message published by a Kura gateway is a control message. All messages published to a topic that does not start with this prefix are considered data messages.   HONO_KURA_CTRL_MSG_CONTENT_TYPE\n--hono.kura.ctrlMsgContentType no application/vnd.eclipse.kura-control The content type to set on AMQP messages created from Kura control messages.   HONO_KURA_DATA_MSG_CONTENT_TYPE\n--hono.kura.dataMsgContentType no application/vnd.eclipse.kura-data The content type to set on AMQP messages created from Kura data messages.   HONO_KURA_DEFAULTS_ENABLED\n--hono.kura.defaultsEnabled no true If set to true the protocol adapter uses default values registered for a device to augment messages published by the device with missing information like a content type. In particular, the protocol adapter adds default values registered for the device as (application) properties with the same name to the AMQP 1.0 messages it sends downstream to the AMQP Messaging Network.   HONO_KURA_INSECURE_PORT\n--hono.kura.insecurePort no - The insecure port the protocol adapter should listen on.\nSee Port Configuration below for details.   HONO_KURA_INSECURE_PORT_BIND_ADDRESS\n--hono.kura.insecurePortBindAddress no 127.0.0.1 The IP address of the network interface that the insecure port should be bound to.\nSee Port Configuration below for details.   HONO_KURA_INSECURE_PORT_ENABLED\n--hono.kura.insecurePortEnabled no false If set to true the protocol adapter will open an insecure port (not secured by TLS) using either the port number set via HONO_KURA_INSECURE_PORT or the default MQTT port number (1883) if not set explicitly.\nSee Port Configuration below for details.   HONO_KURA_KEY_PATH\n--hono.kura.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the protocol adapter should use for authenticating to clients. This option must be used in conjunction with HONO_KURA_CERT_PATH. Alternatively, the HONO_KURA_KEY_STORE_PATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_KURA_KEY_STORE_PASSWORD\n--hono.kura.keyStorePassword no - The password required to read the contents of the key store.   HONO_KURA_KEY_STORE_PATH\n--hono.kura.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the protocol adapter should use for authenticating to clients. Either this option or the HONO_KURA_KEY_PATH and HONO_KURA_CERT_PATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_KURA_SNI\n--hono.kura.sni no false Set whether the server supports Server Name Indication. By default, the server will not support SNI and the option is false. However, if set to true then the key store format , HONO_KURA_KEY_STORE_PATH, should be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   HONO_MQTT_MAX_CONNECTIONS\n--hono.mqtt.maxConnections no 0 The maximum number of concurrent connections that the protocol adapter should accept. If not set (or set to 0), the protocol adapter determines a reasonable value based on the available resources like memory and CPU.   HONO_KURA_MAX_PAYLOAD_SIZE\n--hono.kura.maxPayloadSize no 2048 The maximum allowed size of an incoming MQTT message\u0026rsquo;s payload in bytes. When a client sends a message with a larger payload, the message is discarded and the connection to the client gets closed.   HONO_KURA_NATIVE_TLS_REQUIRED\n--hono.kura.nativeTlsRequired no false The server will probe for OpenSLL on startup if a secure port is configured. By default, the server will fall back to the JVM\u0026rsquo;s default SSL engine if not available. However, if set to true, the server will fail to start at all in this case.   HONO_KURA_PORT\n--hono.kura.port no 8883 The secure port that the protocol adapter should listen on.\nSee Port Configuration below for details.   HONO_KURA_SECUREPROTOCOLS\n--hono.kura.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   HONO_AMQP_SUPPORTEDCIPHERSUITES\n--hono.amqp.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that the adapter may use in TLS sessions with devices. Please refer to JSSE Cipher Suite Names for a list of supported names.   HONO_KURA_TENANT_IDLE_TIMEOUT\n--hono.kura.tenantIdleTimeout no 0ms The duration after which the protocol adapter removes local state of the tenant (e.g. open AMQP links) with an amount and a unit, e.g. 2h for 2 hours. See the Spring Boot documentation for an explanation of the format. The value 0ms disables the timeout.   HONO_KURA_SEND_MESSAGE_TO_DEVICE_TIMEOUT\n--hono.kura.sendMessageToDeviceTimeout no 1000 The amount of time (milliseconds) after which the sending of a command to a device using QoS 1 is considered to be failed. The value of this variable should be increased in cases where devices are connected over a network with high latency.    The variables only need to be set if the default values do not match your environment.\nPort Configuration The Kura protocol adapter can be configured to listen for connections on\n a secure port only (default) or an insecure port only or both a secure and an insecure port (dual port configuration)  The Kura protocol adapter will fail to start if none of the ports is configured properly.\nSecure Port Only The protocol adapter needs to be configured with a private key and certificate in order to open a TLS secured port.\nThere are two alternative ways for doing so:\n either setting the HONO_KURA_KEY_STORE_PATH and the HONO_KURA_KEY_STORE_PASSWORD variables in order to load the key \u0026amp; certificate from a password protected key store, or setting the HONO_KURA_KEY_PATH and HONO_KURA_CERT_PATH variables in order to load the key and certificate from two separate PEM files in PKCS8 format.  When starting up, the protocol adapter will bind a TLS secured socket to the default secure MQTT port 8883. The port number can also be set explicitly using the HONO_KURA_PORT variable.\nThe HONO_KURA_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. Setting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nInsecure Port Only The secure port will mostly be required for production scenarios. However, it might be desirable to expose a non-TLS secured port instead, e.g. for testing purposes. In any case, the non-secure port needs to be explicitly enabled either by\n explicitly setting HONO_KURA_INSECURE_PORT to a valid port number, or by implicitly configuring the default MQTT port (1883) by simply setting HONO_KURA_INSECURE_PORT_ENABLED to true.  The protocol adapter issues a warning on the console if HONO_KURA_INSECURE_PORT is set to the default secure MQTT port (8883).\nThe HONO_KURA_INSECURE_PORT_BIND_ADDRESS variable can be used to specify the network interface that the port should be exposed on. By default the port is bound to the loopback device only, i.e. the port will only be accessible from the local host. This variable might be used to e.g. expose the non-TLS secured port on a local interface only, thus providing easy access from within the local network, while still requiring encrypted communication when accessed from the outside over public network infrastructure.\nSetting this variable to 0.0.0.0 will let the port being bound to all network interfaces (be careful not to expose the port unintentionally to the outside world).\nDual Port The protocol adapter may be configured to open both a secure and a non-secure port at the same time simply by configuring both ports as described above. For this to work, both ports must be configured to use different port numbers, otherwise startup will fail.\nEphemeral Ports Both the secure as well as the insecure port numbers may be explicitly set to 0. The protocol adapter will then use arbitrary (unused) port numbers determined by the operating system during startup.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/hono-client-configuration/",
	"title": "Hono Client Configuration",
	"tags": [],
	"description": "",
	"content": "The org.eclipse.hono.client.HonoConnection factory can be used to create AMQP 1.0 connections to Hono\u0026rsquo;s service components.\nThe factory uses environment variables and/or command line options to configure the connection to the service and the caching of responses to service invocations. All variables used for configuring the connection factory for a particular service share a common prefix. This way, multiple sets of variables can be used to configure multiple factories for connecting to different service endpoints without interfering with each other. For example, the set of variables for configuring the connection factory for the Device Registration service may use the common prefix HONO_REGISTRATION whereas the set for configuring the factory for the Credentials service may use HONO_CREDENTIALS.\nConnection Properties The following table provides an overview of the configuration variables and corresponding command line options for configuring the AMQP connection to the service. Note that the variables map to the properties of classes org.eclipse.hono.config.ClientConfigProperties and org.eclipse.client.RequestResponseClientConfigProperties which can be used to programmatically configure a client.\nThe variable names contain ${PREFIX} as a placeholder for the particular common prefix being used. The ${prefix} placeholder used in the command line option name is the same as ${PREFIX}, using all lower case characters and . instead of _ as the delimiter, e.g. the variable prefix HONO_CREDENTIALS corresponds to the command line option prefix hono.credentials).\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     ${PREFIX}_AMQPHOSTNAME\n--${prefix}.amqpHostname no - The name to use as the hostname in the client\u0026rsquo;s AMQP open frame during connection establishment. This variable can be used to indicate the virtual host to connect to on the server.   ${PREFIX}_CERTPATH\n--${prefix}.certPath no - The absolute path to the PEM file containing the certificate that the client should use for authenticating to the server. This variable must be used in conjunction with ${PREFIX}_KEY_PATH.\nAlternatively, the ${PREFIX}_KEYSTOREPATH variable can be used to configure a key store containing both the key as well as the certificate.   ${PREFIX}_CONNECTTIMEOUT\n--${prefix}.connectTimeout no 5000 The maximum amount of time (milliseconds) that the client should wait for the AMQP connection to be opened. This includes the time for TCP/TLS connection establishment, SASL handshake and exchange of the AMQP open frame. This property can be used to tune the time period to wait according to the network latency involved with the connection between the client and the service.   ${PREFIX}_CREDENTIALSPATH\n--${prefix}.credentialsPath no - The absolute path to a properties file that contains a username and a password property to use for authenticating to the service.\nThis variable is an alternative to using ${PREFIX}_USERNAME and ${PREFIX}_PASSWORD which has the advantage of not needing to expose the secret (password) in the client process' environment.   ${PREFIX}_FLOWLATENCY\n--${prefix}.flowLatency no 20 The maximum amount of time (milliseconds) that the client should wait for credits after a link to the service has been established.   ${PREFIX}_HOST\n--${prefix}.host no localhost The IP address or name of the host to connect to. NB This needs to be set to an address that can be resolved within the network the client runs on. When running as a Docker container, use Docker\u0026rsquo;s --network command line option to attach the local container to the Docker network that the service is running on.   ${PREFIX}_HOSTNAMEVERIFICATIONREQUIRED\n--${prefix}.hostnameVerificationRequired no true A flag indicating whether the value of the ${PREFIX}_HOST variable must match the distinguished name or any of the alternative names asserted by the server\u0026rsquo;s certificate when connecting using TLS.   ${PREFIX}_IDLETIMEOUT\n--${prefix}.idleTimeout no 16000 Sets the amount of time in milliseconds after which a connection will be closed when no frames have been received from the remote peer. This property is also used to configure a heartbeat mechanism, checking that the connection is still alive. The corresponding heartbeat interval will be set to idleTimeout/2 ms.   ${PREFIX}_INITIALCREDITS\n--${prefix}.initialCredits no 200 The number of credits that a consuming client will initially issue to the service (sender) after link creation. This value effectively limits the number of messages that can be in flight unsettled.   ${PREFIX}_KEYPATH\n--${prefix}.keyPath no - The absolute path to the (PKCS8) PEM file containing the private key that the client should use for authenticating to the server. Note that the private key is not protected by a password. You should therefore make sure that the key file can only be read by the user that the client process is running under. This variable must be used in conjunction with ${PREFIX}_CERTPATH. Alternatively, the ${PREFIX}_KEYSTOREPATH variable can be used to configure a key store containing both the key as well as the certificate.   ${PREFIX}_KEYSTOREPASSWORD\n--${prefix}.keyStorePassword no - The password required to read the contents of the key store. If the value starts with file: then the string after the prefix is interpreted as the path to a file to read the password from.   ${PREFIX}_KEYSTOREPATH\n--${prefix}.keyStorePath no - The absolute path to the Java key store containing the private key and certificate that the client should use for authenticating to the server. Either this variable or the ${PREFIX}_KEYPATH and ${PREFIX}_CERTPATH variables need to be set in order to enable SASL External based authentication to the server. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively.   ${PREFIX}_LINKESTABLISMENTTIMEOUT\n--${prefix}.linkEstablishmentTimeout no 1000 The maximum amount of time (milliseconds) that the client should wait for the service\u0026rsquo;s attach frame during link establishment. This property can be used to tune the time period to wait according to the network latency involved with the communication link between the client and the service.   ${PREFIX}_MAXFRAMESIZE\n--${prefix}.maxFrameSize no -1 The maximum size (in bytes) of a single AMQP frame that the client should accept from the peer. When a peer sends a bigger frame, the connection will be closed. The default value of -1 indicates that no limit is to be imposed.   ${PREFIX}_MAXMESSAGESIZE\n--${prefix}.maxMessageSize no -1 The maximum size of messages (in bytes) that the client should accept from a peer. The default value of -1 indicates that messages of any size should be accepted.   ${PREFIX}_MINMESSAGESIZE\n--${prefix}.minMessageSize no 0 The minimum max-message-size (in bytes) that the client requires a peer to accept. The default value of 0 indicates that no minimum size is required. Sender link establishment will fail, if the max-message-size conveyed by the peer in its attach frame is smaller than this property\u0026rsquo;s value.   ${PREFIX}_MAXSESSIONFRAMES\n--${prefix}.maxSessionFrames no -1 The maximum number of AMQP transfer frames for sessions created on this connection. This is the number of transfer frames that may simultaneously be in flight for all links in the session. The default value of -1 indicates that no limit is to be imposed.   ${PREFIX}_NAME\n--${prefix}.name no - The name to use as the container-id in the client\u0026rsquo;s AMQP open frame during connection establishment.   ${PREFIX}_PASSWORD\n--${prefix}.password no - The password to use for authenticating to the service.   ${PREFIX}_PORT\n--${prefix}.port no 5671 The port that the service is listening on.   ${PREFIX}_SENDMESSAGETIMEOUT\n--${prefix}.sendMessageTimeout no 1000 The maximum number of milliseconds to wait for a delivery update after an event or command message was sent before the send operation is failed. Setting this value to a higher value increases the chance of successful service invocation in situations where network latency is high.   ${PREFIX}_RECONNECTATTEMPTS\n--${prefix}.reconnectAttempts no -1 The number of attempts (in addition to the original connection attempt) that the client should make in order to establish an AMQP connection with the peer before giving up. The default value of this property is -1 which means that the client will try forever.   ${PREFIX}_RECONNECTDELAYINCREMENT\n--${prefix}.reconnectDelayIncrement no 100 The factor (milliseconds) used in the exponential backoff algorithm for determining the delay before trying to re-establish an AMQP connection with the peer. The delay after an initial, failed connection attempt will be the value of the ${PREFIX}_RECONNECTMINDELAY variable. Each subsequent connection attempt will use a random delay between the minimum delay and the value determined by exponentially increasing the delay by the ${PREFIX}_RECONNECTDELAYINCREMENT factor. The overall limit of the delay time is defined by the ${PREFIX}_RECONNECTMAXDELAY variable.   ${PREFIX}_RECONNECTMAXDELAY\n--${prefix}.reconnectMaxDelay no 7000 The maximum number of milliseconds to wait before trying to re-establish an AMQP connection with the peer.   ${PREFIX}_RECONNECTMINDELAY\n--${prefix}.reconnectMinDelay no 0 The minimum number of milliseconds to wait before trying to re-establish an AMQP connection with the peer.   ${PREFIX}_REQUESTTIMEOUT\n--${prefix}.requestTimeout no 200 The maximum number of milliseconds to wait for a response before a service invocation is failed. Setting this value to a higher value increases the chance of successful service invocation in situations where network latency is high.   ${PREFIX}_SECUREPROTOCOLS\n--${prefix}.secureProtocols no TLSv1.3,TLSv1.2 A (comma separated) list of secure protocols (in order of preference) that are supported when negotiating TLS sessions. Please refer to the vert.x documentation for a list of supported protocol names.   ${PREFIX}_SUPPORTEDCIPHERSUITES\n--${prefix}.supportedCipherSuites no - A (comma separated) list of names of cipher suites (in order of preference) that the client may negotiate in TLS sessions. Please refer to JSSE Cipher Suite Names for a list of supported names.   ${PREFIX}_TLSENABLED\n--${prefix}.tlsEnabled no false If set to true the connection to the peer will be encrypted using TLS and the peer\u0026rsquo;s identity will be verified using the JVM\u0026rsquo;s configured standard trust store.\nThis variable only needs to be set to enable TLS explicitly if no specific trust store is configured using the ${PREFIX}_TRUSTSTOREPATH variable.   ${PREFIX}_TRUSTSTOREPATH\n--${prefix}.trustStorePath no - The absolute path to the Java key store containing the CA certificates the client uses for authenticating to the service. This property must be set if the service has been configured to support TLS. The key store format can be either JKS, PKCS12 or PEM indicated by a .jks, .p12 or .pem file suffix respectively.   ${PREFIX}_TRUSTSTOREPASSWORD\n--${prefix}.trustStorePassword no - The password required to read the contents of the trust store. If the value starts with file: then the string after the prefix is interpreted as the path to a file to read the password from.   ${PREFIX}_USERNAME\n--${prefix}.username no - The username to use for authenticating to the service. This property (and the corresponding password) needs to be set in order to enable SASL Plain based authentication to the service.    Response Caching The clients created by a Hono client factory support the caching of responses received in response to service invocations. Caching can greatly improve performance by preventing costly invocations of remote service operations. However, it usually only makes sense for resources that do not change too frequently. The Hono client follows the approach to caching used in HTTP 1.1. In particular, it supports cache directives that a service includes in the response messages it sends back to the Hono client.\nIn order to enable caching, the org.eclipse.hono.client.impl.HonoClientImpl factory class needs to be configured with a cache manager using the setCacheManager method. Any specific client created by the factory will then cache responses to service invocations based on the following rules:\n If the response contains a no-cache directive, the response is not cached at all. Otherwise, if the response contains a max-age directive, the response is cached for the number of seconds determined as the minimum of the value contained in the directive and the value of the ${PREFIX}_RESPONSECACHEDEFAULTTIMEOUT variable. Otherwise, if the response message does not contain any of the above directives and the response\u0026rsquo;s status code is one of the codes defined in RFC 2616, Section 13.4 Response Cacheability, the response is put to the cache using the default timeout defined by the ${PREFIX}_RESPONSECACHEDEFAULTTIMEOUT variable as the maximum age.  The following table provides an overview of the configuration variables and corresponding command line options for configuring the Hono client\u0026rsquo;s caching behavior.\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     ${PREFIX}_RESPONSECACHEMINSIZE\n--${prefix}.responseCacheMinSize no 20 The minimum number of responses that can be cached.   ${PREFIX}_RESPONSECACHEMAXSIZE\n--${prefix}.responseCacheMaxSize no 1000 The maximum number of responses that can be cached. It is up to the particular cache implementation, how to deal with new cache entries once this limit has been reached.   ${PREFIX}_RESPONSECACHEDEFAULTTIMEOUT\n--${prefix}.responseCacheDefaultTimeout no 600 The default number of seconds after which cached responses should be considered invalid. The value of this property serves as an upper boundary to the value conveyed in a max-age cache directive and is capped at 86400, which corresponds to 24 hours.    Using TLS The factory can be configured to use TLS for\n authenticating the server during connection establishment and (optionally) authenticating to the server using a client certificate (if the server supports this)  In order to authenticate the server by means of the server\u0026rsquo;s certificate, the factory needs to be configured with a trust anchor containing the certificate authorities that the client trusts. The trust anchor can be configured explicitly by means of the ${PREFIX}_TRUSTSTOREPATH and ${PREFIX}_TRUSTSTOREPASSWORD variables. This is most useful in cases where the server\u0026rsquo;s certificate has not been signed by one of the public root CAs that are contained in the JRE\u0026rsquo;s standard trust store. However, if the server does use a certificate signed by such a public CA, then it is sufficient to set the ${PREFIX}_TLSENABLED variable to true in order for the client to support TLS when connecting to the server.\nThe client can also be configured to authenticate to the server by means of an X.509 client certificate if the server is configured to support this. The ${PREFIX}_CERTPATH and ${PREFIX}_KEYPATH variables can be used to set the paths to PEM files containing the certificate and private key. Alternatively, the ${PREFIX}_KEYSTOREPATH and ${PREFIX}_KEYSTOREPASSWORD variables can be used to set the path and password of a key store which contains both the certificate as well as the private key.\nThe factory supports TLS 1.2 only by default for negotiating TLS sessions with servers. Additional protocols can be enabled by setting the ${PREFIX}_SECUREPROTOCOLS variable to a comma separated list of protocol names as defined in the vert.x documentation. However, great care should be taken when enabling older protocols because most of them are vulnerable to attacks.\nAddress rewriting In some multi-tenant messaging environments external can have their addresses internally mapped to enforce consistent namespaces. For example, the addresses can be prefixed by the virtual host the client uses to connect or some other internal identifier. So address like telemetry/DEFAULT_TENANT would be internally represented as test-vhost/telemetry/DEFAULT_TENANT for example.\nTo successfully address those external clients, infrastructure Hono components need to apply the same mapping rules. The client factory can be configured to automatically rewrite addresses when opening links to the AMQP network. The ${PREFIX}_ADDRESSREWRITERULE variable contains rewrite rule for addresses based on the regular expressions.\n   Environment Variable\nCommand Line Option Mandatory Default Value Description     ${PREFIX}_ADDRESSREWRITERULE\n--${prefix}.addressRewriteRule no - The address rewrite rule in the \u0026quot;$PATTERN $REPLACEMENT\u0026quot; format.    The rule is defined in the \u0026quot;$PATTERN $REPLACEMENT\u0026quot; format, where the pattern and replacement use the standard Java regular expression syntax. The pattern should match the address or otherwise the original address will be used.\nFor example, setting HONO_ADDRESSREWRITERULE to ([a-z_]+)/([\\\\w-]+) test-vhost/$1/$2 would result in adding the test-vhost/ prefix to all addresses used by the client.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/hono-kafka-client-configuration/",
	"title": "Hono Kafka Client Configuration",
	"tags": [],
	"description": "",
	"content": "Protocol adapters can be configured to use Kafka for the messaging. The Kafka client used there can be configured with environment variables and/or command line options.\n Tech preview The support of Kafka as a messaging system is currently a preview and not yet ready for production. The implementation as well as its APIs may change with the next version.  Configure for Kafka based Messaging The selection of whether to use AMQP or Kafka for the messaging can be configured on the tenant. This requires that protocol adapters must have the configurations for both messaging networks. To configure a tenant to use Kafka, the tenant configuration must contain a field ext, which contains a field with the key messaging-type and the value kafka (to use AMQP, the value must be amqp). The following example shows a tenant that is configured to use Kafka for messaging:\n{ \u0026#34;tenant-id\u0026#34;: \u0026#34;TEST_TENANT\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;ext\u0026#34;: { \u0026#34;messaging-type\u0026#34;: \u0026#34;kafka\u0026#34; } } If the configuration of a protocol adapter contains only the connection to one messaging system, this will be used. NB: If only one messaging network is configured at protocol adapters, make sure that tenants are not configured to use another.\nProducer Configuration Properties The org.eclipse.hono.client.kafka.CachingKafkaProducerFactory factory can be used to create Kafka producers for Hono\u0026rsquo;s Kafka based APIs. The producers created by the factory are configured with instances of the class org.eclipse.hono.client.kafka.KafkaProducerConfigProperties which can be used to programmatically configure a producer.\nThe configuration needs to be provided in the form HONO_KAFKA_PRODUCERCONFIG_${PROPERTY} as an environment variable or as a command line option in the form hono.kafka.producerConfig.${property}, where ${PROPERTY} respectively ${property} is any of the Kafka client\u0026rsquo;s producer properties. The provided configuration is passed directly to the Kafka producer without Hono parsing or validating it.\nThe following properties can not be set using this mechanism because the protocol adapters use fixed values instead in order to implement the message delivery semantics defined by Hono\u0026rsquo;s Telemetry and Event APIs.\n   Kafka Producer Config Property Fixed Value     key.serializer org.apache.kafka.common.serialization.StringSerializer   value.serializer io.vertx.kafka.client.serialization.BufferSerializer   enable.idempotence true     Enable Kafka based Messaging The Kafka client requires the property bootstrap.servers to be provided. This variable is the minimal configuration required to enable Kafka based messaging.  Using TLS The factory can be configured to use TLS for authenticating the brokers in the Kafka cluster during connection establishment and optionally for authenticating to the broker using a client certificate. To use this, a Kafka Producer configuration as described in Kafka documentation - section \u0026ldquo;Security\u0026rdquo; needs to be provided. The properties must be prefixed with HONO_KAFKA_PRODUCERCONFIG_ and hono.kafka.producerConfig. respectively as shown in Producer Configuration Properties. The complete reference of available properties and the possible values is available in Kafka documentation - section \u0026ldquo;Producer Configs\u0026rdquo;.\nConsumer Configuration Properties Consumers for Hono\u0026rsquo;s Kafka based APIs are configured with instances of the class org.eclipse.hono.client.kafka.consumer.KafkaConsumerConfigProperties which can be used to programmatically configure a consumer.\nThe configuration needs to be provided in the form HONO_KAFKA_CONSUMERCONFIG_${PROPERTY} as an environment variable or as a command line option in the form hono.kafka.consumerConfig.${property}, where ${PROPERTY} respectively ${property} is any of the Kafka client\u0026rsquo;s consumer properties. The provided configuration is passed directly to the Kafka consumer without Hono parsing or validating it.\nThe following properties can not be set using this mechanism because the protocol adapters use fixed values instead.\n   Kafka Consumer Config Property Fixed Value     key.deserializer org.apache.kafka.common.serialization.StringDeserializer   value.deserializer io.vertx.kafka.client.serialization.BufferDeserializer     Enable Kafka based Messaging The Kafka client requires the property bootstrap.servers to be provided. This variable is the minimal configuration required to enable Kafka based messaging.  Using TLS The factory can be configured to use TLS for authenticating the brokers in the Kafka cluster during connection establishment and optionally for authenticating to the broker using a client certificate. To use this, a Kafka Consumer configuration as described in Kafka documentation - section \u0026ldquo;Security\u0026rdquo; needs to be provided. The properties must be prefixed with HONO_KAFKA_CONSUMERCONFIG_ and hono.kafka.consumerConfig. respectively as shown in Consumer Configuration Properties. The complete reference of available properties and the possible values is available in Kafka documentation - section \u0026ldquo;Consumer Configs\u0026rdquo;.\nAdmin Client Configuration Properties Admin clients for Hono\u0026rsquo;s Kafka based APIs are configured with instances of the class org.eclipse.hono.client.kafka.KafkaAdminClientConfigProperties which can be used to programmatically configure an admin client.\nThe configuration needs to be provided in the form HONO_KAFKA_ADMINCLIENTCONFIG_${PROPERTY} as an environment variable or as a command line option in the form hono.kafka.adminClientConfig.${property}, where ${PROPERTY} respectively ${property} is any of the Kafka client\u0026rsquo;s admin client properties. The provided configuration is passed directly to the Kafka admin client without Hono parsing or validating it.\n Enable Kafka based Messaging The Kafka client requires the property bootstrap.servers to be provided. This variable is the minimal configuration required to enable Kafka based messaging.  Using TLS The factory can be configured to use TLS for authenticating the brokers in the Kafka cluster during connection establishment and optionally for authenticating to the broker using a client certificate. To use this, a Kafka admin client configuration as described in Kafka documentation - section \u0026ldquo;Security\u0026rdquo; needs to be provided. The properties must be prefixed with HONO_KAFKA_ADMINCLIENTCONFIG_ and hono.kafka.adminClientConfig. respectively as shown in Admin Client Configuration Properties. The complete reference of available properties and the possible values is available in Kafka documentation - section \u0026ldquo;Admin Configs\u0026rdquo;.\nCommon Configuration Properties Configuration properties that are common to all the client types described above can be put in a common configuration section. This will avoid having to define duplicate configuration properties for the different client types.\nRelevant properties are bootstrap.servers and the properties related to authentication and TLS configuration (see chapters above).\nThe properties must be prefixed with HONO_KAFKA_COMMONCLIENTCONFIG_ and hono.kafka.commonClientConfig. respectively.\nA property with the same name defined in the configuration of one of the specific client types above will have precedence over the common property.\nRequired Kafka Version Hono\u0026rsquo;s protocol adapters (and other components) use the Kafka clients in version 2.6. It is recommended to provide a Kafka cluster with a version number equal or higher to this. While you might get Hono to work with older Kafka brokers, this has not been tested. If you experience any issues using Hono with an older Kafka version, please try to connect it to a recent Kafka cluster instead before raising an issue.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/amqp-network-config/",
	"title": "AMQP 1.0 Messaging Network Configuration",
	"tags": [],
	"description": "",
	"content": "The Qpid Dispatch Router, together with the Apache Artemis message broker, serves as the default AMQP 1.0 Messaging Network that is used in Hono\u0026rsquo;s example deployment as described in the Deployment Guides.\nThe Dispatch Router component exposes service endpoints implementing the north bound part of Hono\u0026rsquo;s Telemetry, Event and Command \u0026amp; Control APIs which are used by applications to interact with devices.\nDispatch Router Configuration The Dispatch Router is part of the Apache Qpid project. Hono uses Dispatch Router by means of the EnMasse project\u0026rsquo;s Dispatch Router Docker image created from the Qpid project source code.\nThe Dispatch Router can be configured by means of configuration files. Hono includes an example configuration in the deploy/src/main/config/qpid folder which is used by the example deployment scripts. Please refer to the Dispatch Router documentation for details regarding the configuration file format and options.\nArtemis Broker Configuration The Artemis Broker is part of the Apache ActiveMQ project. Hono uses Artemis by means of the EnMasse project\u0026rsquo;s Artemis Docker image created from the Artemis project source code.\nThe Artemis Broker can be configured by means of configuration files. Hono includes an example configuration in the deploy/src/main/config/artemis folder which is used by the example deployment scripts. Please refer to the Artemis documentation for details regarding the configuration file format and options.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/secure_communication/",
	"title": "Secure Communication",
	"tags": [],
	"description": "",
	"content": "The individual components of an Eclipse Hono™ installation, e.g. the protocol adapters, AMQP Messaging Network, Hono Auth etc., and the clients attaching to Hono in order to send and receive data all communicate with each other using AMQP 1.0 over TCP. The Hono components and the clients will usually not be located on the same local network but will probably communicate over public networking infrastructure. For most use cases it is therefore desirable, if not necessary, to provide for confidentiality of the data being transferred between these components. This section describes how Hono supports confidentiality by means of Transport Layer Security (TLS) and how to configure it.\nEnabling TLS All of Hono\u0026rsquo;s components can be configured to use TLS for establishing an encrypted communication channel with peers. When a client initiates a connection with a server, the TLS handshake protocol is used to negotiate parameters of a secure channel to be used for exchanging data. The most important of those parameters is a secret (symmetric) encryption key that is only known to the client and the server and which is used to transparently encrypt all data being sent over the connection as long as the connection exists. With each new connection, a new secret key is negotiated.\nUsing TLS in this way requires configuring the server component with a cryptographic private/public key pair and a certificate which binds an identity claim to the public key. It is out of scope of this document to describe the full process of creating such a key pair and acquiring a corresponding certificate. The demo-certs module already contains a set of keys and certificates to be used for evaluation and demonstration purposes. Throughout the rest of this section we will use these keys and certificates . Please refer to the demo-certs/README.md file for details regarding how to create your own keys and certificates.\nWithin a Hono installation the following communication channels can be secured with TLS:\n Applications connecting to Dispatch Router - Client applications consuming e.g. Telemetry data from Hono connect to the AMQP Messaging Network. This connection can be secured by configuring the client and the messaging network for TLS. Device Registry connecting to Auth Server - The Device Registry connects to the Auth Server in order to verify client credentials and determine the client\u0026rsquo;s authorities. This (internal) connection can (should) be secured by configuring the Auth Server and Device Registry for TLS. Protocol Adapter to Device Registry - A protocol adapter connects to the Device Registry in order to retrieve assertions regarding the registration status of devices. This (internal) connection can be secured by configuring the protocol adapter and the Device Registry for TLS. Protocol Adapter connecting to AMQP Messaging Network - A protocol adapter connects to the messaging network in order to forward telemetry data and commands hence and forth between downstream components (client applications) and devices. This (internal) connection can be secured by configuring the Dispatch Router and the protocol adapters for TLS. Devices connecting to a Protocol Adapter - Devices use TLS to both authenticate the protocol adapter and to establish an encrypted channel that provides integrity and privacy when transmitting data. Note that the specifics of if and how TLS can be used with a particular protocol adapter is specific to the transport protocol the adapter uses for communicating with the devices. Liveness/readiness probes connecting to Service Health Checks - Systems like Kubernetes are periodically checking the health status of the individual services . This communication can be secured by configuring the health check of the individual services to expose a secure endpoint.  Auth Server The Auth Server supports the use of TLS for connections to clients. Please refer to the Auth Server admin guide for details regarding the required configuration steps.\nThe demo-certs/certs folder includes the following demo keys and certificates to be used with the Auth Server for that purpose.\n   File Description     auth-server-key.pem The example private key for creating signatures.   auth-server-cert.pem The example certificate asserting the server\u0026rsquo;s identity.   trusted-certs.pem Trusted CA certificates to use for verifying signatures.    Dispatch Router The Dispatch Router reads its configuration from a file on startup (the default location is /etc/qpid-dispatch/qdrouterd.conf). Please refer to the Dispatch Router documentation for details regarding the configuration of TLS/SSL.\nThe demo-certs/certs folder includes the following demo keys and certificates to be used with the Dispatch Router for that purpose:\n   File Description     qdrouter-key.pem The example private key for creating signatures.   qdrouter-cert.pem The example certificate asserting the server\u0026rsquo;s identity.   trusted-certs.pem Trusted CA certificates to use for verifying signatures.    File Based Device Registry The file based Device Registry supports the use of TLS for connections to protocol adapters and the Auth Server. Please refer to the file based Device Registry admin guide for details regarding the required configuration steps.\nThe demo-certs/certs folder contains the following demo keys and certificates to be used with the file based Device Registry for that purpose.\n   File Description     auth-server-cert.pem The certificate of the Auth Server, used to verify the signatures of tokens issued by the Auth Server.   device-registry-key.pem The example private key for creating signatures.   device-registry-cert.pem The example certificate asserting the server\u0026rsquo;s identity.   trusted-certs.pem Trusted CA certificates to use for verifying signatures.    MongoDB Based Device Registry The MongoDB based Device Registry supports the use of TLS for connections to protocol adapters and the Auth Server. Please refer to the MongoDB based Device Registry admin guide for details regarding the required configuration steps.\nThe demo-certs/certs folder contains the following demo keys and certificates to be used with the MongoDB based Device Registry for that purpose.\n   File Description     auth-server-cert.pem The certificate of the Auth Server, used to verify the signatures of tokens issued by the Auth Server.   device-registry-key.pem The example private key for creating signatures.   device-registry-cert.pem The example certificate asserting the server\u0026rsquo;s identity.   trusted-certs.pem Trusted CA certificates to use for verifying signatures.    CoAP Adapter The CoAP adapter supports the use of TLS for its connections to the Tenant service, the Device Registration service, the Credentials service and the AMQP Messaging Network. The adapter also supports the use of DTLS for connections with devices. For this purpose, the adapter can be configured with a server certificate and private key. Please refer to the CoAP adapter admin guide for details regarding the required configuration steps.\nThe demo-certs/certs folder contains the following demo keys and certificates to be used with the CoAP adapter for that purpose.\n   File Description     coap-adapter-key.pem The example private key for creating signatures.   coap-adapter-cert.pem The example certificate asserting the adapter\u0026rsquo;s identity.   trusted-certs.pem Trusted CA certificates to use for verifying signatures.    HTTP Adapter The HTTP adapter supports the use of TLS for its connections to the Tenant service, the Device Registration service, the Credentials service and the AMQP Messaging Network. The adapter also supports the use of TLS for connections with devices. For this purpose, the adapter can be configured with a server certificate and private key. Please refer to the HTTP adapter admin guide for details regarding the required configuration steps.\nThe demo-certs/certs folder contains the following demo keys and certificates to be used with the HTTP adapter for that purpose.\n   File Description     http-adapter-key.pem The example private key for creating signatures.   http-adapter-cert.pem The example certificate asserting the adapter\u0026rsquo;s identity.   trusted-certs.pem Trusted CA certificates to use for verifying signatures.    MQTT Adapter The MQTT adapter supports the use of TLS for its connections to the Tenant service, the Device Registration service, the Credentials service and the AMQP Messaging Network. The adapter also supports the use of TLS for connections with devices. For this purpose, the adapter can be configured with a server certificate and private key. Please refer to the MQTT adapter admin guide for details regarding the required configuration steps.\nThe demo-certs/certs folder contains the following demo keys and certificates to be used with the MQTT adapter for that purpose.\n   File Description     mqtt-adapter-key.pem The example private key for creating signatures.   mqtt-adapter-cert.pem The example certificate asserting the adapter\u0026rsquo;s identity.   trusted-certs.pem Trusted CA certificates to use for verifying signatures.    Kura Adapter The Kura adapter supports the use of TLS for its connections to the Tenant service, the Device Registration service, the Credentials service and the AMQP Messaging Network. The adapter also supports the use of TLS for connections with devices. For this purpose, the adapter can be configured with a server certificate and private key. Please refer to the Kura adapter admin guide for details regarding the required configuration steps.\nThe demo-certs/certs folder contains the following demo keys and certificates to be used with the Kura adapter for that purpose.\n   File Description     kura-adapter-key.pem The example private key for creating signatures.   kura-adapter-cert.pem The example certificate asserting the adapter\u0026rsquo;s identity.   trusted-certs.pem Trusted CA certificates to use for verifying signatures.    Client Application When the connection between an application client and Hono (i.e. the Dispatch Router) is supposed to be secured by TLS (which is a good idea), then the client application needs to be configured to trust the CA that signed the Dispatch Router\u0026rsquo;s certificate chain. Clients can use the org.eclipse.hono.client.HonoConnection.newConnection(ClientConfigProperties) method to establish a connection to Hono. The org.eclipse.hono.config.ClientConfigProperties instance passed in to the method needs to be configured with the trust store containing the CA\u0026rsquo;s certificate. Please refer to the Hono Client configuration guide for details regarding the corresponding configuration properties that need to be set.\nThe demo-certs/certs folder contains the following demo keys to be used with client applications for that purpose.\n   File Description     trusted-certs.pem Trusted CA certificates to use for verifying signatures.    Using OpenSSL Hono\u0026rsquo;s individual services are implemented in Java and therefore, by default, use the SSL/TLS engine that comes with the Java Virtual Machine that the services are running on. In case of the Docker images provided by Hono this is the SSL engine of OpenJDK. While the standard SSL engine has the advantage of being a part of the JVM itself and thus being available on every operating system that the JVM is running on without further installation, it provides only limited performance and throughput when compared to native TLS implementations like OpenSSL.\nIn order to address this problem, the Netty networking library that is used in Hono\u0026rsquo;s components can be configured to employ the OpenSSL instead of the JVM\u0026rsquo;s SSL engine by means of Netty\u0026rsquo;s Forked Tomcat Native (tcnative) module.\nThe tcnative module comes in several flavors, corresponding to the way that the OpenSSL library has been linked in. The statically linked versions include a specific version of OpenSSL (or BoringSSL for that matter) and is therefore most easy to use on supported platforms, regardless of whether another version of OpenSSL is already installed or not. In contrast, the dynamically linked variants depend on a particular version of OpenSSL being already installed on the operating system. Both approaches have their pros and cons and Hono therefore does not include tcnative in its Docker images by default, i.e. Hono\u0026rsquo;s services will use the JVM\u0026rsquo;s default SSL engine by default.\nConfiguring Containers When starting up any of Hono\u0026rsquo;s Docker images as a container, the JVM will look for additional jar files to include in its classpath in the container\u0026rsquo;s /opt/hono/extensions folder. Thus, using a specific variant of tcnative is just a matter of configuring the container to mount a volume or binding a host folder at that location and putting the desired variant of tcnative into the corresponding volume or host folder.r Assuming that the Auth Server should be run with the statically linked, BoringSSL based tcnative variant, the following steps are necessary:\n Download tcnative matching the platform architecture (linux-x86_64). Put the jar file to a folder on the Docker host, e.g. /tmp/tcnative. Start the Auth Server Docker image mounting the host folder:  docker run --name hono-auth-server --mount type=bind,src=/tmp/tcnative,dst=/opt/hono/extensions,ro ... eclipse/hono-service-auth Note that the command given above does not contain the environment variables and secrets that are usually required to configure the service properly.\nWhen the Auth Server starts up, it will look for a working variant of tcnative on its classpath and (if found) use it for establishing TLS connections. The service\u0026rsquo;s log file will indicate whether the JVM\u0026rsquo;s default SSL engine or OpenSSL is used.\nUsing a Docker volume instead of a bind mount works the same way but requires the use of volume as the type of the --mount parameter. Please refer to the Docker reference documentation for details.\nServer Name Indication (SNI) Server Name Indication can be used to indicate to a server the host name that the client wants to connect to as part of the TLS handshake. This is useful in order to be able to host multiple virtual servers on a single network address. In particular, SNI allows server components to select a server certificate that matches the domain name indicated by the client using SNI.\nHono\u0026rsquo;s protocol adapters support virtual servers by means of SNI as described above. Devices can then connect to a protocol adapter using any one of the configured virtual domain names.\nThe following steps a re necessary in order to configure the protocol adapters with multiple virtual servers:\n  Create Server Certificate(s)\nWhen a device establishes a connection to one of Hono\u0026rsquo;s protocol adapters using one of its virtual domain names, then it includes the domain name in its TLS hello message by means of the SNI extension. The server can then use this information to determine the matching server certificate and corresponding private key that is required to perform the TLS handshake.\nIt is therefore necessary to create a private key and certificate for each virtual server to be hosted. The virtual server\u0026rsquo;s domain name needs to be added to the certificate\u0026rsquo;s Subject Alternative Name (SAN) list in order for Hono to be able to determine the key/certificate pair to use for the TLS handshake with the device. Please refer to the vert.x SNI guide for details on how this works under the hood.\nHono\u0026rsquo;s protocol adapters then need to be configured with the server certificates and keys. In order to do so, the certificates and corresponding private keys need to be added to a key store. Hono supports the JKS and PKCS12 key store formats for that purpose. Once the key store has been created, Hono\u0026rsquo;s protocol adapters need to be configured with the path to the key store by means of the adapters' KEY_STORE_PATH configuration variable. Please refer to the protocol adapter admin guides for details on how to configure the key store path.\n  Enable SNI for Hono\u0026rsquo;s Protocol Adapters\nHono\u0026rsquo;s protocol adapters can be configured to support SNI by means of the SNI configuration variable. Please refer to the protocol adapter admin guides for details on how to set this variable.\n  Verify Configuration\nThe setup can be verified by means of the command line tools that are part of OpenSSL. Assuming that the MQTT protocol adapter\u0026rsquo;s IP address is 10.100.84.23, its secure endpoint is bound to port 31884 and it has been configured with a certificate using domain name my-hono.eclipse.org, then the following command can be used to test if a TLS secured connection with the adapter using that virtual host name can be established successfully:\nopenssl s_client -connect 10.100.84.23:31884 -servername my-hono.eclipse.org  "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/monitoring-tracing-config/",
	"title": "Monitoring &amp; Tracing",
	"tags": [],
	"description": "",
	"content": "The individual components of an Eclipse Hono™ installation need to work together in order to provide their functionality to devices and applications. Under normal circumstances these interactions work flawlessly. However, due to the nature of distributed systems, any one (or more) of the components may crash or become otherwise unavailable due to arbitrary reasons. This page describes how Hono supports operations teams by providing insights into the individual service components and their interactions with each other by means of reporting metrics and tracing the processing of individual messages through the system.\nWhen a device uploads telemetry data to the HTTP adapter, the adapter invokes operations on the Device Registration, Credentials and the Tenant services in order to authenticate and authorize the device before sending the telemetry data downstream to the AMQP 1.0 Messaging Network. The overall success of this process and the latency involved before the message reaches the consumer is determined by the individual interactions between the service components.\nMonitoring In a production environment, an operations team will usually want to keep track of some key performance indicators (KPI) which allow the team to determine the overall health of the system, e.g. memory and CPU consumption etc. Hono supports the tracking of such KPIs by means of metrics it can be configured to report. The metrics are usually collected in a time series database like InfluxDB or Prometheus and then visualized on a monitoring dash-board built using frameworks like Grafana. Such a dash-board can usually also be configured to send alarms when certain thresholds are exceeded.\nMetrics usually provide insights into the past and current status of an individual component. The values can be aggregated to provide a picture of the overall system\u0026rsquo;s status. As such, metrics provide a great way to monitor system health and, in particular, to anticipate resource shortages and use such knowledge to pro-actively prevent system failure.\nConfiguring a Metrics Back End Hono uses Micrometer for providing metrics. It is possible to drop in any Micrometer compatible back end. Hono also uses the Micrometer integration with Spring Boot and Vert.x.\nPlease refer to the Micrometer documentation for details regarding the configuration of a specific Micrometer back end. In most cases, you only need to add the back end specific jar files to the class path and add back end specific configuration properties to the application.yml file.\nThe Hono build supports configuration of the Prometheus metrics back end by means of the metrics-prometheus Maven profile.\nNote that the profile is not active by default, i.e. you need to explicitly activate it when starting the build using Maven\u0026rsquo;s -P command line parameter:\nmvn clean install -Pmetrics-prometheus ... Using Prometheus Most of the metrics back ends have data being pushed to from the components reporting the metrics. However, Prometheus is different in that it polls (or scrapes) all components periodically for new metrics data. For this to work, the Prometheus server needs to be configured with the IP addresses of the components to monitor. In the example deployment that comes with Hono, the Prometheus server is configured with the names of the Kubernetes services corresponding to the Hono components that it should scrape. The components themselves need to expose a corresponding HTTP endpoint that the Prometheus server can connect to for scraping the meter data. All Hono components that report metrics can be configured to expose such an endpoint via their Health Check server which already exposes endpoints for determining the component\u0026rsquo;s readiness and liveness status.\nHealth Check Server Configuration All of Hono\u0026rsquo;s service components and protocol adapters contain a Health Check server which can be configured to expose several HTTP endpoints for determining the component\u0026rsquo;s status. In particular, the server exposes a /readiness, a /liveness and an optional /prometheus URI endpoint.\nThe former two endpoints are supposed to be used by container orchestration platforms like Kubernetes to monitor the runtime status of the containers that it manages. These endpoints are always exposed when the health check server is started.\nThe /prometheus endpoint can be used by a Prometheus server to retrieve collected meter data from the component. It is only exposed if Prometheus has been configured as the metrics back end as described above.\nThe health check server can be configured by means of the following environment variables:\n   Environment Variable\nCommand Line Option Default Value Description     HONO_HEALTHCHECK_BINDADDRESS\n--hono.healthCheck.bindAddress 127.0.0.1 The IP address of the network interface that the health check server\u0026rsquo;s secure port should be bound to. The server will only be started if this property is set to some other than the default value and corresponding key material has been configured using the HONO_HEALTHCHECK_KEYPATH and HONO_HEALTHCHECK_CERTPATH variables.   HONO_HEALTHCHECK_CERTPATH\n--hono.healthCheck.certPath - The absolute path to the PEM file containing the certificate that the secure server should use for authenticating to clients. This option must be used in conjunction with HONO_HEALTHCHECK_KEYPATH.\nAlternatively, the HONO_HEALTHCHECK_KEYSTOREPATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_HEALTHCHECK_INSECUREPORTBINDADDRESS\n--hono.healthCheck.insecurePortBindAddress 127.0.0.1 The IP address of the network interface that the health check server\u0026rsquo;s insecure port should be bound to. The server will only be started if this property is set to some other than the default value.   HONO_HEALTHCHECK_INSECUREPORT\n--hono.healthCheck.insecurePort 8088 The port that the insecure server should listen on.   HONO_HEALTHCHECK_KEYPATH\n--hono.healthCheck.keyPath - The absolute path to the (PKCS8) PEM file containing the private key that the secure server should use for authenticating to clients. This option must be used in conjunction with HONO_HEALTHCHECK_CERTPATH. Alternatively, the HONO_HEALTHCHECK_KEYSTOREPATH option can be used to configure a key store containing both the key as well as the certificate.   HONO_HEALTHCHECK_PORT\n--hono.healthCheck.port 8088 The port that the secure server should listen on.   HONO_HEALTHCHECK_KEYSTOREPASSWORD\n--hono.healthCheck.keyStorePassword - The password required to read the contents of the key store.   HONO_HEALTHCHECK_KEYSTOREPATH\n--hono.healthCheck.keyStorePath - The absolute path to the Java key store containing the private key and certificate that the secure server should use for authenticating to clients. Either this option or the HONO_HEALTHCHECK_KEYPATH and HONO_HEALTHCHECK_CERTPATH options need to be set in order to enable TLS secured connections with clients. The key store format can be either JKS or PKCS12 indicated by a .jks or .p12 file suffix respectively. The HONO_HEALTHCHECK_KEYSTOREPASSWORD variable can be used to set the password required for reading the key store.     Failure to start The component/service will fail to start if neither the secure not the insecure server have been configured properly.  Tracing In normal operation the vast majority of messages should be flowing through the system without any noteworthy delays or problems. In fact, that is the whole purpose of Hono. However, that doesn\u0026rsquo;t mean that nothing can go wrong. For example, when a tenant\u0026rsquo;s device administrator changes the credentials of a device in the Credentials service but has not yet updated the credentials on the device yet, then the device will start to fail in uploading any data to the protocol adapter it connects to. After a while, a back end application\u0026rsquo;s administrator might notice, that there hasn\u0026rsquo;t been any data being received from that particular device for quite some time. The application administrator therefore calls up the Hono operations team and complains about the data being lost somewhere.\nThe operations team will have a hard time determining what is happening, because it will need to figure out which components have been involved in the processing of the device and why the data hasn\u0026rsquo;t been processed as usual. The metrics alone usually do not help much here because metrics are usually not scoped to individual devices. The logs written by the individual components, on the other hand, might contain enough information to correlate individual entries in the log with each other and thus trace the processing of the message throughout the system. However, this is usually a very tedious (and error prone) process and the relevant information is often only logged at a level (e.g. DEBUG) that is not used in production (often INFO or above).\nIn order to address this problem, Hono\u0026rsquo;s service components are instrumented using OpenTracing. OpenTracing provides Vendor-neutral APIs and instrumentation for distributed tracing. The OpenTracing web page provides a list of supported tracer implementations from which users can choose in order to collect (and examine) the tracing information generated by Hono\u0026rsquo;s individual components.\nConfiguring a Tracer Hint: The description in this chapter applies to any compatible OpenTracing implementation. For an easier approach to configure usage of Jaeger tracing, see the next chapter.\nHono\u0026rsquo;s components use the OpenTracing Tracer Resolver mechanism to find and initialize a concrete OpenTracing implementation during startup of the component. The discovery mechanism is using Java\u0026rsquo;s ServiceLoader and as such relies on the required resources to be available on the class path.\nWhen starting up any of Hono\u0026rsquo;s Docker images as a container, the JVM will look for additional jar files to include in its class path in the container\u0026rsquo;s /opt/hono/extensions folder. Thus, using a specific implementation of OpenTracing is just a matter of configuring the container to mount a volume or binding a host folder at that location and putting the implementation\u0026rsquo;s jar files and resources into the corresponding volume or host folder.\n Note This also means that (currently) only Tracer implementations can be used with Hono that also implement the Tracer Resolver mechanism.  Configuring usage of Jaeger tracing (included in Docker images) In case Jaeger tracing shall be used, there is an alternative to putting the jar files in the container\u0026rsquo;s /opt/hono/extensions folder as described above. This is to have the Jaeger tracing jar files be included in the Hono Docker images by using the jaeger Maven profile when building Hono. For example, building the HTTP adapter image with the Jaeger client included:\n# in directory: hono/adapters/http-vertx/ mvn clean install -Pbuild-docker-image,jaeger Note that when running the created docker image, the environment variables for configuring the Jaeger client still need to be set. Please refer to the Jaeger documentation for details.\nEnforcing the recording of traces for a tenant Typically, in production systems, the tracing components will be configured to not store all trace spans in the tracing backend, in order to reduce the performance impact. For debugging purposes it can however be beneficial to enforce the recording of certain traces. Hono allows this by providing a configuration option in the Tenant information with which all traces concerning the processing of telemetry, event and command messages for that specific tenant will be recorded. Furthermore, this enforced trace sampling can be restricted to only apply to messages sent in the context of a specific authentication identifier. Please refer to the description of the tracing object in the Tenant Information for details.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/dev-guide/",
	"title": "Developer Guide",
	"tags": [],
	"description": "",
	"content": "Developer Guide Learn how to build Eclipse Hono™ and how to integrate your custom components with it.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/dev-guide/building_hono/",
	"title": "Building from Source",
	"tags": [],
	"description": "",
	"content": "Hono can be deployed using the pre-built Docker images available from our Docker Hub repositories. However, customizing and/or extending Hono\u0026rsquo;s functionality requires building the images from source code.\nThis page provides step by step instructions for getting the source code and building the Hono\u0026rsquo;s Docker images from it.\nPrerequisites for building Hono Docker Creating Hono\u0026rsquo;s container images using the Hono build process requires a Docker daemon running either locally or on another host you have access to. Please follow the instructions on the Docker web site to install Docker on your platform.\nIn case the docker daemon is not running locally, the following environment variable needs to be set in order for the examples in the remainder of this page to run successfully:\nexport DOCKER_HOST=tcp://${host}:${port} with ${host} and ${port} reflecting the name/IP address and port of the host where Docker is running on.\nJava Hono is written in Java and therefore requires a Java Development Kit (JDK) version 11 or higher installed on your computer. Please follow the JDK vendor\u0026rsquo;s instructions for installing Java on your operating system.\nMaven Hono\u0026rsquo;s build process is based on Apache Maven. You need at least Maven 3.5 in order to build Hono. Please follow the installation instructions on the Maven home page.\nGit A Git client is required if you want to contribute changes/improvements to the Hono project. It is not necessary for simply building Hono locally. Please refer to the Git Downloads page for installation instructions.\nGetting the Hono Source Code Either\n download the latest release archive and extract the archive to a local folder or clone the Hono source code repository from GitHub: git clone https://github.com/eclipse/hono.git This will create a hono folder in the current working directory and clone the whole repository into that folder.\n  Starting the Hono Build Process Run the following from the source folder:\nexport DOCKER_HOST # in the \u0026#34;hono\u0026#34; folder containing the source code mvn clean install -Pbuild-docker-image,metrics-prometheus,jaeger This will build all libraries, Docker images and example code.\n Be patient The first build might take several minutes because Docker will need to download all the base images that Hono is relying on. However, most of these will be cached by Docker so that subsequent builds will be running much faster.  Gathering Code Coverage Information for Unit Tests Hono\u0026rsquo;s unit tests can be configured to gather code coverage information during execution using the JaCoCo Maven plugin. The plugin is disabled by default and can be enabled by setting the jacoco.skip maven property to false:\n# in the \u0026#34;hono\u0026#34; folder containing the source code mvn clean install -Djacoco.skip=false -Pbuild-docker-image,metrics-prometheus,jaeger The plugin will produce a target/jacoco.exec file in each module which contains the (binary) coverage data. It will also produce XML data files under target/site/jacoco in each module. Tools like SonarQube can be used to collect and properly format this data.\nUsing custom Image Names The container images being created will have names based on the following pattern: ${docker.registry-name}/${docker.image.org-name}/${project.artifactId}:${project.version}.\nThe variables in the name are standard Maven properties. The default value for the docker.registry-name property is index.docker.io. The default value for docker.image.org-name is eclipse. The following build command creates Hono\u0026rsquo;s images using the quay.io registry and the custom repository name:\nmvn clean install -Pbuild-docker-image,metrics-prometheus,jaeger -Ddocker.registry-name=quay.io -Ddocker.image.org-name=custom Building native Images The build process supports building native Docker images using the GraalVM for some of Hono\u0026rsquo;s components. In order to do so, the build-native-image Maven profile needs to be activated:\n# in the \u0026#34;hono\u0026#34; folder containing the source code mvn clean install -Pbuild-native-image,metrics-prometheus,jaeger  Experimental Support for native images is an experimental feature. The build-native-image and the build-docker-image profiles are mutually exclusive. However, they can be built one after the other.  Pushing Images The container images that are created as part of the build process can be automatically pushed to a container registry using the docker-push-image Maven profile:\nmvn clean install -Pbuild-docker-image,metrics-prometheus,jaeger,docker-push-image Note that the container registry might require authentication in order to push images. The build uses the Docker Maven Plugin for creating and pushing images. Please refer to the plugin documentation for details regarding how to configure credentials for the registry.\nRunning the Integration Tests The source code for Hono comes with a test suite for integration testing. To trigger these tests, change to the tests folder and execute:\n# in the \u0026quot;hono/tests\u0026quot; folder containing the test suite mvn verify -Prun-tests The tests are executed against the Docker images of the Hono components. Because of that, it is necessary to build the respective images as described above before the execution of the tests. The respective Readme.md file in the folder hono/tests contains more information regarding the test suite.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/dev-guide/amqp_adapter_client/",
	"title": "AMQP Adapter Client for Java",
	"tags": [],
	"description": "",
	"content": "Eclipse Hono™ comes with a Java client for the AMQP adapter. It is intended for the implementation of (prototype) devices, (protocol) gateways or (end-to-end) tests. The client is based on Eclipse Vert.x.\nThe starting point is the class AmqpAdapterClientFactory.\nThe factory provides methods to get a receiver for receiving commands and a sender for each of the following actions:\n send a telemetry message send an event message send a response to a previously received command   Do not re-use sender instances The senders manage the underlying AMQP sender links, which are restored after temporary interruption of the connection (HonoConnection manages the automatic reconnection). To achieve this, a caching mechanism is used, so that defective links are replaced by new ones. The sender must be always retrieved from the factory when sending because otherwise the link might no longer exist. So, do not hold references to sender objects and re-use them for subsequent send operations!  For examples of how to use the client, see the example implementation in the AmqpExampleDevice class.\nUsage in a Gateway There are two ways to subscribe to commands for use in a gateway:\n Gateway subscribing for commands for a specific device: The gateway subscribes individually for each connected device by creating a command consumer for the specific device. Gateway subscribing for commands for all its devices: The gateway subscribes for commands sent to all the different devices that the gateway acts on behalf of by creating a command consumer that is not scoped on a specific device.  Subscribing for all devices does not work if multiple instances of the gateway are running at the same time, because a command is only sent to one receiver, and this may be an instance that has no connection to the device. On the other hand, subscribing for a specific device once it connects to the gateway instance (and closing the subscription once it disconnects) may not work for device-oriented protocols that are not connection-based.\nTracing The AMQP Adapter Client supports tracing of the messages with OpenTracing. To use tracing, each of the senders returned by the factory can be cast to an interface with the same name and the prefix \u0026ldquo;Traceable\u0026rdquo; (e.g. cast TelemetrySender to TraceableTelemetrySender). The traceable interfaces provide send methods with an additional SpanContext parameter.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/dev-guide/java_client_consumer/",
	"title": "Consuming Messages from Java",
	"tags": [],
	"description": "",
	"content": "To illustrate how Eclipse Hono™ can be integrated with Java code, a simple application is provided that consumes telemetry and event data for devices belonging to the default tenant.\nIt also includes support for Command and Control:\nif indicated by a received downstream message that contains a ttd value (refer to Device notifications for details) it tries to send a command to the device. If the value of ttd indicates that the device stays connected for an unlimited time (ttd == -1), the application will periodically repeat to send a command until notified the device is disconnected again (ttd == 0).\nThis application shall serve as a blueprint to integrate your existing java source code with Hono. Its code is found in the example module in the package org.eclipse.hono.vertx.example.\nThe provided classes are kept as simple as possible (in the tradition of a classical \u0026ldquo;Hello World\u0026rdquo; implementation) while still covering the most relevant messaging patterns (downstream and upstream messages). For this purpose they make use of simple constant definitions and deal with exceptions as rarely as possible. You may want to change the level of detail that should be logged to the console by editing the contained resources/logback.xml file.\nPlease refer to the javadoc of the classes for details.\n Note Note that production ready code likely has to think more about error handling and logging than this simple blueprint.  Configure the example For simplicity, all configurations are defined as Java constants inside the class HonoExampleConstants.\nIf you have Hono running in Docker under localhost, the example should work out of the box.\nSome configuration values can be overridden by providing them as property to the application.\nThis includes the host and the port of the AMQP network. In the standard setup of Hono they should be configured to the qdrouter from the Apache Qpid project. In production scenarios this might be a large setup of AMQP routers, brokers, etc.\nPlease refer to the class HonoExampleConstants to find out which part of the application can be configured by properties.\nRun the example The application waits for messages until you press any key or kill it.\nIt is started by\n# in directory: hono/examples/hono-client-examples/ mvn clean package mvn exec:java -Dexec.mainClass=org.eclipse.hono.vertx.example.HonoExampleApplication or \u0026mdash; if e.g. the host of the AMQP network should be changed \u0026mdash;\nmvn exec:java -Dexec.mainClass=org.eclipse.hono.vertx.example.HonoExampleApplication -Dconsumer.host=192.168.99.100 Telemetry and Event messages Depending on the logger configuration, all received downstream messages are printed to the console.\nPlease note that consumers do not connect with Hono directly, but rather with an AMQP router network.\nCommand and Control By using a helper class provided by Hono, a callback in the application code is invoked when a downstream message was received that signals the device will stay connected to the protocol adapter for some time (see Device notifications for details).\nInside this callback an arbitrary simple command is sent down to the device (once or periodically) and the response is logged to the console.\nEncryption of communication For the encrypted communication with Hono, the necessary truststore is already installed and used by the Hono client.\nIf you want to integrate the code with your own software, please copy the provided truststore (hono/demo-certs/certs/trusted-certs.pem) from the Hono project to the resources directory of your project and adopt the code pointing to the file location.\nKafka based Messaging To use Kafka based messaging instead of an AMQP network, set the property kafka to true provide the host and port of a bootstrap server:\nmvn exec:java -Dexec.mainClass=org.eclipse.hono.vertx.example.HonoExampleApplication -Dconsumer.host=192.168.99.100 -Dconsumer.port=9092 -Dkafka=true Additional properties for the Kafka producers and consumers can be added in the code, for example to enable encrypted communication. For the available configuration options refer to the Kafka documentationhttps://kafka.apache.org/documentation/#configuration.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/dev-guide/custom_http_adapter/",
	"title": "Implement a Custom Hono HTTP Protocol Adapter",
	"tags": [],
	"description": "",
	"content": "Eclipse Hono™ comes with a default HTTP Adapter which can be used to interact with devices via HTTP. The default HTTP Adapter also serves as a blueprint for implementing a custom HTTP protocol adapter.\nThis section will guide you through the steps to build your own custom HTTP protocol adapter.\nPrerequisites You should be familiar with the setup and start of Hono. Refer to the Getting Started guide.\nThe standard HTTP Adapter Hono\u0026rsquo;s HTTP Adapter supports telemetry and event data processing. Please refer to the HTTP Adapter User Guide and HTTP Adapter Admin Guide for details regarding the usage and configuration of the HTTP Adapter.\nYou can find the source of the HTTP Adapter at https://github.com/eclipse/hono/tree/master/adapters/http-vertx.\nAnatomy of the standard HTTP Adapter Like many other Hono components, the HTTP Adapter is built on top of the Vert.x framework.\nThe HTTP Adapter\u0026rsquo;s VertxBasedHttpProtocolAdapter class is derived from an abstract base class. This base class implements the standard functionality for component initialization, receiving HTTP requests from devices or external clients, and forwarding of data to the downstream AMQP Messaging Network.\nDerive a custom HTTP Protocol Adapter Use the standard HTTP Adapter as a blueprint.\nAdding Routes In Vert.x, a route is a mapping of an HTTP request to a handler. Inside a route, Vert.x provides a RoutingContext instance which gives access to the HTTP request (and response) object containing the HTTP headers.\nThe standard HTTP Adapter overrides the abstract method addRoutes(), provided by the base class, and adds routes for processing telemetry data and events.\n// route for uploading telemetry data router.route(HttpMethod.PUT, String.format(\u0026#34;/telemetry/:%s/:%s\u0026#34;, PARAM_TENANT, PARAM_DEVICE_ID)) .handler(ctx -\u0026gt; uploadTelemetryMessage(ctx, getTenantParam(ctx), getDeviceIdParam(ctx))); The route for telemetry data parses the HTTP request, extracts the tenant and deviceId parameters from the request URL path, and forwards the message payload to the method uploadTelemetryMessage(), provided by the base class.\nNB Note the Vert.x place holder indicators : inside the URL path pattern /telemetry/:%s/:%s. Vert.x makes matching place holders available as request parameters. See Capturing path parameters in the Vert.x documentation.\nThe route for events looks very similar to the route for telemetry data. It forwards the event message payload to the uploadEventMessage() method.\nPlease refer to the Telemetry API and Event API for details about the different Hono APIs.\nIn the custom HTTP protocol adapter adapt the routes according to your needs.\nBuild and run the custom HTTP Protocol Adapter If you have Hono running, you can launch your custom HTTP protocol adapter as a Docker Container or a Spring Boot application.\nYou may adopt the Maven profile build-docker-image from the Maven POM file of the standard HTTP Adapter into your custom adapter\u0026rsquo;s Maven POM file.\nFollow the guidelines for running the HTTP Adapter in HTTP Adapter. Don\u0026rsquo;t forget to configure the custom protocol adapter to bind to a different port than the standard HTTP Adapter if you intend to run them both at the same time. See the Port Configuration section of the HTTP Adapter documentation for details.\nUsing the custom HTTP Protocol Adapter Now that you have your custom HTTP protocol adapter up and running, you can use any HTTP client, like curl or HTTPie, to publish data to your custom adapter.\nNote that before publishing data to your custom HTTP protocol adapter, you need to start a consumer for the tenant you intend to publish data for. Otherwise you will not be able to successfully send data. For this purpose, you may use the example consumer as described in the Getting Started guide.\nFurther extend the custom HTTP Protocol Adapter The abstract base class includes additional hooks which you may use to plug into the adapter\u0026rsquo;s life cycle:\n   Hook Description     preStartup() called before start of adapter\u0026rsquo;s HTTP server   onStartupSuccess() called after successful start of adapter   preShutdown() called before stop of adapter\u0026rsquo;s HTTP server   postShutdown called after successful stop of adapter   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/",
	"title": "API",
	"tags": [],
	"description": "",
	"content": "API Documentation of the APIs defined by Eclipse Hono™.\nFor an overview of the available APIs, see the architecture documentation.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/telemetry/",
	"title": "Telemetry API Specification",
	"tags": [],
	"description": "",
	"content": "The Telemetry API is used by Protocol Adapters to send telemetry data downstream. Business Applications and other consumers use the API to receive data published by devices belonging to a particular tenant.\nThe Telemetry API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to Hono using AMQP 1.0 in order to invoke operations of the API as described in the following sections. Throughout the remainder of this page we will simply use AMQP when referring to AMQP 1.0.\nSouthbound Operations The following operations can be used by Protocol Adapters to forward telemetry data received from devices to downstream consumers like Business Applications.\nForward Telemetry Data Preconditions\n Adapter has established an AMQP connection with the AMQP Messaging Network. Adapter has established an AMQP link in role sender with the AMQP Messaging Network using target address telemetry/${tenant_id} where ${tenant_id} is the ID of the tenant that the client wants to upload telemetry data for. The device for which the adapter wants to send telemetry data has been registered (see Device Registration API).  The adapter indicates its preferred message delivery mode by means of the snd-settle-mode and rcv-settle-mode fields of its attach frame during link establishment.\n   snd-settle-mode rcv-settle-mode Delivery semantics     unsettled, mixed first Using unsettled for the snd-settle-mode allows for adapters to implement both AT LEAST ONCE or AT MOST ONCE delivery semantics, depending on whether the adapter waits for and considers the disposition frames it receives from the AMQP Messaging Network or not. This is the recommended mode for forwarding telemetry data.   settled first Using settled for the snd-settle-mode allows for adapters to implement AT MOST ONCE delivery semantics only. This is the fastest mode of delivery but has the drawback of less reliable end-to-end flow control and potential loss of messages without notice.    All other combinations are not supported by Hono and may result in the termination of the link or connection (depending on the configuration of the AMQP Messaging Network).\nMessage Flow\nAs indicated above, it is up to the discretion of the protocol adapter whether it wants to use AT LEAST ONCE or AT MOST ONCE delivery semantics.\nHono\u0026rsquo;s HTTP adapter allows devices to indicate, which delivery semantics they want to use when uploading telemetry data. The HTTP adapter always forwards messages unsettled and either ignores the outcome of the message transfer (AT MOST ONCE) or waits for the downstream peer to accept the message (AT LEAST ONCE) before acknowledging the reception of the message to the device.\nThe following sequence diagram illustrates the flow of messages involved in the HTTP Adapter forwarding an unsettled telemetry data message to the downstream AMQP Messaging Network implementing AT MOST ONCE delivery semantics.\n  Forward telemetry data flow (AT MOST ONCE)    Device 4711 PUTs telemetry data to the HTTP Adapter  HTTP Adapter transfers telemetry data to AMQP 1.0 Messaging Network. HTTP Adapter acknowledges the reception of the data to the Device.   AMQP 1.0 Messaging Network acknowledges reception of the message which is ignored by the HTTP Adapter.   Note In the example above the HTTP adapter does not wait for the outcome of the transfer of the message to the AMQP Messaging Network before sending back the HTTP response to the device. If the messaging network had sent a disposition frame with the rejected instead of the accepted outcome, the HTTP adapter would still have signaled a 202 status code back to the device. In this case the data would have been lost without the device noticing.  The following sequence diagram illustrates the flow of messages involved in the HTTP Adapter forwarding an unsettled telemetry data message to the downstream AMQP Messaging Network implementing AT LEAST ONCE delivery semantics.\n  Forward telemetry data flow (AT LEAST ONCE)    Device 4711 PUTs telemetry data to the HTTP Adapter, indicating QoS Level 1.  HTTP Adapter transfers telemetry data to AMQP 1.0 Messaging Network. AMQP 1.0 Messaging Network acknowledges reception of the message. HTTP Adapter acknowledges the reception of the data to the Device.    When the AMQP Messaging Network fails to settle the transfer of a telemetry message or settles the transfer with any other outcome than accepted, the protocol adapter MUST NOT try to re-send such rejected messages but SHOULD indicate the failed transfer to the device if the transport protocol provides means to do so.\nMessage Format\nThe following table provides an overview of the properties a client needs to set on a Forward Telemetry Data message.\n   Name Mandatory Location Type Description     content-type yes properties symbol A content type indicating the type and characteristics of the data contained in the payload, e.g. text/plain; charset=\u0026quot;utf-8\u0026quot; for a text message or application/json etc. The value may be set to application/octet-stream if the message payload is to be considered opaque binary data.   creation-time no properties timestamp The instant in time when the message has been created (see the AMQP 1.0 specification for details). This property is mandatory if ttd is set, otherwise it is optional.   device_id yes application-properties string The identifier of the device that the data in the payload is originating from.   ttd no application-properties int The time \u0026lsquo;til disconnect indicates the number of seconds that the device will remain connected to the protocol adapter. The value of this property must be interpreted relative to the message\u0026rsquo;s creation-time. A value of -1 is used to indicate that the device will remain connected until further notice, i.e. until another message indicates a ttd value of 0. In absence of this property, the connection status of the device is to be considered indeterminate. Backend Applications might use this information to determine a time window during which the device will be able to receive a command.    The body of the message MUST consist of a single AMQP Data section containing the telemetry data. The format and encoding of the data MUST be indicated by the content-type and (optional) content-encoding properties of the message.\nAny additional properties set by the client in either the properties or application-properties sections are preserved by Hono, i.e. these properties will also be contained in the message delivered to consumers.\nNorthbound Operations Receive Telemetry Data Hono delivers messages containing telemetry data reported by a particular device in the same order that they have been received in (using the Forward Telemetry Data operation). Hono MAY drop telemetry messages that it cannot deliver to any consumers. Reasons for this include that there are no consumers connected to Hono or the existing consumers are not able to process the messages from Hono fast enough.\nHono supports multiple non-competing Business Application consumers of telemetry data for a given tenant. Hono allows each Business Application to have multiple competing consumers for telemetry data for a given tenant to share the load of processing the messages.\nPreconditions\n Client has established an AMQP connection with Hono. Client has established an AMQP link in role receiver with Hono using source address telemetry/${tenant_id} where ${tenant_id} represents the ID of the tenant the client wants to retrieve telemetry data for.  Hono supports both AT MOST ONCE as well as AT LEAST ONCE delivery of telemetry messages. However, clients SHOULD use AT LEAST ONCE delivery in order to support end-to-end flow control and therefore SHOULD set the snd-settle-mode field to unsettled and the rcv-settle-mode field to first in their attach frame during link establishment.\nA client MAY indicate to Hono during link establishment that it wants to distribute the telemetry messages received for a given tenant among multiple consumers by including a link property subscription-name whose value is shared by all other consumers of the tenant. Hono ensures that messages from a given device are delivered to the same consumer. Note that this also means that telemetry messages MAY not be evenly distributed among consumers, e.g. when only a single device sends data. NB This feature is not supported yet.\nIn addition a client MAY include a boolean link property ordering-required with value false during link establishment in order to indicate to Hono that it does not require messages being delivered strictly in order per device but instead allows for messages being distributed evenly among the consumers. NB This feature is not supported yet.\nMessage Flow\nThe following sequence diagram illustrates the flow of messages involved in a Business Application receiving a telemetry data message from Hono. The delivery mode used is AT LEAST ONCE.\n  Receive Telemetry Data    AMQP 1.0 Messaging Network delivers telemetry message to Business Application.  Business Application acknowledges reception of message.     Note The Business Application can only consume telemetry messages that have been uploaded to Hono after the Business Application has established the link with the AMQP 1.0 Messaging Network. This is because telemetry messages are not durable, i.e. they are not persisted in Hono in order to be forwarded at a later time.  Message Format\nThe format of the messages containing the telemetry data is the same as for the Forward Telemetry Data operation.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/event/",
	"title": "Event API Specification",
	"tags": [],
	"description": "",
	"content": "The Event API is used by Protocol Adapters to send event messages downstream. Business Applications and other consumers use the API to receive messages published by devices belonging to a particular tenant.\nThe Event API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to Hono using AMQP 1.0 in order to invoke operations of the API as described in the following sections. Throughout the remainder of this page we will simply use AMQP when referring to AMQP 1.0.\nSouthbound Operations The following operations can be used by Protocol Adapters to forward event messages received from devices to downstream consumers like Business Applications.\nForward Event Preconditions\n Adapter has established an AMQP connection with the AMQP Messaging Network. Adapter has established an AMQP link in role sender with the AMQP Messaging Network using target address event/${tenant_id} where ${tenant_id} is the ID of the tenant that the client wants to upload event messages for. The device for which the adapter wants to send an event has been registered (see Device Registration API).  Hono supports AT LEAST ONCE delivery of Event messages only. A client therefore MUST use unsettled for the snd-settle-mode and first for the rcv-settle-mode fields of its attach frame during link establishment. All other combinations are not supported by Hono and may result in the termination of the link or connection (depending on the configuration of the AMQP Messaging Network).\nThe AMQP messages used to forward events to the AMQP Messaging Network MUST have their durable property set to true. The AMQP Messaging Network is expected to write such messages to a persistent store before settling the transfer with the accepted outcome.\nMessage Flow\nThe following sequence diagram illustrates the flow of messages involved in the MQTT Adapter forwarding an event to the downstream AMQP Messaging Network.\n  Forward event flow    Device 4711 publishes an event using MQTT QoS 1.  MQTT Adapter transfers data to AMQP 1.0 Messaging Network. AMQP 1.0 Messaging Network acknowledges reception of the message. MQTT Adapter acknowledges the reception of the message to the Device.    When the AMQP Messaging Network fails to settle the transfer of an event message or settles the transfer with any other outcome than accepted, the protocol adapter MUST NOT try to re-send such rejected messages but MUST indicate the failed transfer to the device if the transport protocol provides means to do so.\nMessage Format\nSee Telemetry API for definition of message format.\nNorthbound Operations Receive Events Hono delivers messages containing events reported by a particular device in the same order that they have been received in (using the Forward Event operation).\nHono supports multiple non-competing Business Application consumers of event messages for a given tenant. Hono allows each Business Application to have multiple competing consumers for event messages for a given tenant to share the load of processing the messages.\nPreconditions\n Client has established an AMQP connection with Hono. Client has established an AMQP link in role receiver with Hono using source address event/${tenant_id} where ${tenant_id} represents the ID of the tenant the client wants to retrieve event messages for.  Hono supports AT LEAST ONCE delivery of Event messages only. A client therefore MUST use unsettled for the snd-settle-mode and first for the rcv-settle-mode fields of its attach frame during link establishment. All other combinations are not supported by Hono and result in the termination of the link.\nMessage Flow\nThe following sequence diagram illustrates the flow of messages involved in a Business Application receiving an event message from Hono.\n  Receive event data flow (success)    AMQP 1.0 Messaging Network delivers event message to Business Application.  Business Application acknowledges reception of message.    Message Format\nSee Telemetry API for definition of message format.\nWell-known Event Message Types Hono defines several well-known event types which have specific semantics. Events of these types are identified by means of the AMQP message\u0026rsquo;s content-type.\nEmpty Notification An AMQP message containing this type of event does not have any payload, so the body of the message MUST be empty.\nThe AMQP 1.0 properties an event sender needs to set for an empty notification event are defined in the Telemetry API.\nThe relevant properties are listed again in the following table:\n   Name Mandatory Location Type Description     content-type yes properties symbol MUST be set to application/vnd.eclipse-hono-empty-notification   ttd no application-properties int The time \u0026lsquo;til disconnect as described in the Telemetry API.    NB An empty notification can be used to indicate to a Business Application that a device is currently ready to receive an upstream message by setting the ttd property. Backend Applications may use this information to determine the time window during which the device will be able to receive a command.\nConnection Event Protocol Adapters may send this type of event to indicate that a connection with a device has been established or has ended. Note that such events can only be sent for authenticated devices, though, because an event is always scoped to a tenant and the tenant of a device is established as part of the authentication process.\nThe AMQP message for a connection event MUST contain the following properties in addition to the standard event properties:\n   Name Mandatory Location Type Description     content-type yes properties symbol Must be set to application/vnd.eclipse-hono-dc-notification+json   device_id yes application-properties string The ID of the authenticated device    Each connection event\u0026rsquo;s payload MUST contain a UTF-8 encoded string representation of a single JSON object with the following fields:\n   Name Mandatory Type Description     cause yes string The cause of the connection event. MUST be set to either connected or disconnected.   remote-id yes string An identifier of the device that is the subject of this event, e.g. an IP address:port, client id etc. The format and semantics of this identifier is specific to the protocol adapter and the transport protocol it supports.   source yes string The type name of the protocol adapter reporting the event, e.g. hono-mqtt.   data no object An arbitrary JSON object which may contain additional information about the occurrence of the event.    The example below might be used by the MQTT adapter to indicate that a connection with a device using client identifier mqtt-client-id-1 has been established:\n{ \u0026#34;cause\u0026#34;: \u0026#34;connected\u0026#34;, \u0026#34;remote-id\u0026#34;: \u0026#34;mqtt-client-id-1\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;hono-mqtt\u0026#34;, \u0026#34;data\u0026#34;: { \u0026#34;foo\u0026#34;: \u0026#34;bar\u0026#34; } } Device Provisioning Notification Device registries may send this event to convey provisioning related changes regarding a device. This may be used as a hook for northbound applications if further application specific logic should be implemented upon provisioning changes.\nAn AMQP message containing this type of event does not have any payload, so the body of the message MUST be empty.\nThe relevant properties are listed again in the following table:\n   Name Mandatory Location Type Description     content-type yes properties symbol MUST be set to application/vnd.eclipse-hono-device-provisioning-notification   hono_registration_status yes application-properties string Contains NEW if the device has been newly provisioned.   tenant_id yes application-properties string The tenant id denoting the tenant of the device.   device_id yes application-properties string The id of the device.   gateway_id no application-properties string This property contains a value only if the device\u0026rsquo;s registration status has been changed by a gateway acting on behalf of the device. In such a case, the property contains the identifier of the gateway, otherwise the property will not be included.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/command-and-control/",
	"title": "Command &amp; Control API Specification",
	"tags": [],
	"description": "",
	"content": "The Command \u0026amp; Control API of Eclipse Hono™ is used by Business Applications to send commands to connected devices.\nCommands can be used to trigger actions on devices. Examples include updating a configuration property, installing a software component or switching the state of an actuator.\nHono distinguishes two types of commands. The first type is one-way only. In this case the sender of the command does not expect the device to send back a message in response to the command. This type of command is referred to as a one-way command in the remainder of this page. One-way commands may be used to e.g. notify a device about a change of state.\nThe second type of commands expects a response to be sent back from the device as a result of processing the command. In this case the response contains a status code which indicates whether the command could be processed successfully. If so, the response may also include data representing the result of processing the command. This type of command is plainly referred to as a command because it represents the default case.\nThe Command \u0026amp; Control API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to Hono using AMQP 1.0 in order to invoke operations of the API as described in the following sections. Throughout the remainder of this page we will simply use AMQP when referring to AMQP 1.0.\nSend a One-Way Command Business Applications use this operation to send a command to a device for which they do not expect to receive a response from the device.\nPreconditions\n The Business Application has established an AMQP connection with the AMQP 1.0 Network. The Business Application has established an AMQP link in role sender with the target address command/${tenant_id}, where ${tenant_id} is the ID of the tenant that the device belongs to. This link is used by the Business Application to send command messages.  The following sequence diagram illustrates the establishment of the required link:\n  Application connecting to the AMQP 1.0 Messaging Network   Message Format\nThe following table provides an overview of the properties the Business Application needs to set on a one-way command message.\n   Name Mandatory Location Type Description     to yes properties string MUST contain the target address command/${tenant_id}/${device_id} of the message, where ${device_id} is the ID of the device to send the message to.   subject yes properties string The name of the command to be executed by the device.   content-type no properties string If present, MUST contain a Media Type as defined by RFC 2046 which describes the semantics and format of the command\u0026rsquo;s input data contained in the message payload. However, not all protocol adapters will support this property as not all transport protocols provide means to convey this information, e.g. MQTT 3.1.1 has no notion of message headers.   message-id no properties string An identifier that uniquely identifies the message at the sender side.    The command message MAY contain arbitrary payload to be sent to the device in a single AMQP Data section. The value of the message\u0026rsquo;s subject property may provide a hint to the device regarding the format, encoding and semantics of the payload data.\nHono indicates the outcome of the operation by means of the following AMQP delivery states:\n   Delivery State Description     accepted The command has been delivered to the device for processing.   released The command has not been delivered to the device or can not be processed by the device due to reasons that are not the responsibility of the sender of the command. Possible reasons are:The device is (currently) not connected.In case the transport protocol supports acknowledgements: The device hasn\u0026rsquo;t sent an acknowledgement in time or has indicated that the message cannot be processed.There was an error forwarding the command to the device.   rejected The command has not been delivered to or processed by the device because the command message does not contain all required information. Another reason may be that a message limit has been exceeded.    Note that Hono relies on the particular protocol adapter to deliver commands to devices. Depending on the used transport protocol and the adapter\u0026rsquo;s implementation, the accepted outcome may thus indicate any of the following:\n An attempt has been made to deliver the command to the device. However, it is unclear if the device has received (or processed) the command. The device has acknowledged the reception of the command but has not processed the command yet. The device has received and processed the command.  Examples\nThe following sequence diagram shows the successful delivery of a one-way command called switchOn to device 4711 of the DEFAULT_TENANT:\n  Successfully send a One-Way Command   The following sequence diagram shows how the delivery of the same one-way command fails because the device is not connected:\n  Device not connected   The following sequence diagram illustrates how a malformed command sent by a Business Application gets rejected:\n  Malformed Command message   Send a (Request/Response) Command Business Applications use this operation to send a command to a device for which they expect the device to send back a response.\n\nPreconditions\n The Business Application has established an AMQP connection with the AMQP 1.0 Network. The Business Application has established an AMQP link in role sender with the target address command/${tenant_id}, where ${tenant_id} is the ID of the tenant that the device belongs to. This link is used by the Business Application to send command messages. The Business Application has established an AMQP link in role receiver with the source address command_response/${tenant_id}/${reply_id}. This link is used by the Business Application to receive the response to the command from the device. This link’s source address is also used as the reply-to address for the request messages. The ${reply_id} may be any arbitrary string chosen by the application.  The following sequence diagram illustrates the establishment of the required links:\n  Application connecting to the AMQP 1.0 Messaging Network   Command Message Format\nThe following table provides an overview of the properties the Business Application needs to set on a command message.\n   Name Mandatory Location Type Description     to yes properties string MUST contain the target address command/${tenant_id}/${device_id} of the message, where ${device_id} is the ID of the device to send the message to.   subject yes properties string MUST contain the command name to be executed by a device.   content-type no properties string If present, MUST contain a Media Type as defined by RFC 2046 which describes the semantics and format of the command\u0026rsquo;s input data contained in the message payload. However, not all protocol adapters will support this property as not all transport protocols provide means to convey this information, e.g. MQTT 3.1.1 has no notion of message headers.   correlation-id no properties string MAY contain an ID used to correlate a response message to the original request. If set, it is used as the correlation-id property in the response, otherwise the value of the message-id property is used. Either this or the message-id property MUST be set.   message-id no properties string MAY contain an identifier that uniquely identifies the message at the sender side. Either this or the correlation-id property MUST be set.   reply-to yes properties string MUST contain the source address that the application expects to receive the response from. This address MUST be the same as the source address used for establishing the client\u0026rsquo;s receiver link (see Preconditions above).    The command message MAY contain arbitrary payload to be sent to the device in a single AMQP Data section. The value of the command message\u0026rsquo;s subject value may provide a hint to the device regarding the format, encoding and semantics of the payload data.\nHono uses following AMQP delivery states to indicate the outcome of sending the command to the device:\n   Delivery State Description     accepted The command has been delivered to the device for processing.   released The command has not been delivered to the device or can not be processed by the device due to reasons that are not the responsibility of the sender of the command. Possible reasons are:The device is (currently) not connected.In case the transport protocol supports acknowledgements: The device hasn\u0026rsquo;t sent an acknowledgement in time or has indicated that the message cannot be processed.There was an error forwarding the command to the device.   rejected The command has not been delivered to or processed by the device because the command message does not contain all required information. Another reason may be that a message limit has been exceeded.    Note that Hono relies on the particular protocol adapter to deliver commands to devices. Depending on the used transport protocol and the adapter\u0026rsquo;s implementation, the accepted outcome may thus indicate any of the following:\n An attempt has been made to deliver the command to the device. However, it is unclear if the device has received (or processed) the command. The device has acknowledged the reception of the command but has not processed the command yet.  An application can determine the overall outcome of the operation by means of the response to the command that is sent back by the device. An application should consider execution of a command to have failed, if it does not receive a response within a reasonable amount of time.\nResponse Message Format\nThe following table provides an overview of the properties set on a message sent in response to a command.\n   Name Mandatory Location Type Description     content-type no properties string If present, MUST contain a Media Type as defined by RFC 2046 which describes the semantics and format of the command\u0026rsquo;s input data contained in the message payload. However, not all protocol adapters will support this property as not all transport protocols provide means to convey this information, e.g. MQTT 3.1.1 has no notion of message headers.   correlation-id yes properties string MUST contain the correlation ID used to match the command message with the response message containing the result of execution on the device.   device_id yes application-properties string The identifier of the device that sent the response.   status yes application-properties integer MUST indicate the status of the execution. See table below for possible values.   tenant_id yes application-properties string The identifier of the tenant that the device belongs to.    The status property must contain an HTTP 1.1 response status code:\n   Code Description     2xx The command has been processed successfully.   4xx The command could not be processed due to a client error, e.g. malformed message payload.   5xx The command could not be processed due to an internal problem at the device side.    The semantics of the individual codes are specific to the device and command. For status codes indicating an error (codes in the 400 - 599 range) the message body MAY contain a detailed description of the error that occurred.\nIf a command message response contains a payload, the body of the message MUST consist of a single AMQP Data section containing the response message data.\nExamples\nThe following sequence diagram illustrates how a Business Application sends a command called getReading to device 4711 of the DEFAULT_TENANT and receives a response from the device:\n  Successfully send a Command   The sending of a command may fail for the same reasons as those illustrated for sending a one-way command. Additionally, the sending of a command may be considered unsuccessful by an application if it does not receive the response from the device in a reasonable amount of time:\n  Command times out  "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/kafka-api/",
	"title": "Kafka-based APIs",
	"tags": [],
	"description": "",
	"content": "The Kafka-based APIs of Eclipse Hono™ provide an alternative to the existing APIs based on AMQP 1.0. With these APIs, clients publish data to as well as consume data from an Apache Kafka® cluster instead of using an AMQP messaging network.\n Tech preview The support of Kafka as a messaging system is currently a preview and not yet ready for production. The APIs are subject to change without prior notice.  Kafka-based Messaging Using Kafka instead of AMQP comes with slightly different behavior. Kafka provides a Publish/Subscribe messaging style. Every message is sent by a producer to a topic in a Kafka cluster, where it will be persisted by (multiple) brokers. Each topic consists of a configurable number of partitions. The key of a message determines to which partition it will be written. Each partition is replicated to a configurable number of brokers in the cluster to provide fault-tolerance if a broker goes down.\nA Kafka message (also called record) consists of a key, a value, a timestamp, and headers.\nMultiple consumers can read the messages at the same time and they can read them repeatedly (if an error occurred). This decoupling of producer and consumers has the consequence that a producer does not get feedback about the consumption of messages, it does not know if and when a message will be read by any consumer(s). For example, a protocol adapter can only confirm to the device that the Kafka cluster successfully persisted a telemetry message, not if a Business Application received it.\nMessages are usually deleted from a topic at some point – regardless of whether they have been processed by a consumer. Care should therefore be taken to set each topic\u0026rsquo;s log retention time to a reasonable value in the Kafka configuration.\nSee the Kafka documentation for details about Kafka\u0026rsquo;s configuration properties.\nQuality of Service The Kafka client\u0026rsquo;s acks configuration property is used to configure what acknowledgements a producer expects from the cluster for each message. The value of this property determines the maximum Quality of Service level the producer can achieve. Kafka supports the following settings:\n 0: the producer does not wait for any acknowledgements. This provides no guarantees. 1: the producer requests only an acknowledgement from one broker. If the broker goes down before others finished replication, then the message will be lost. all (or equivalent -1): the producer requests an acknowledgement that confirms that the message has successfully been replicated to the required number of brokers. This guarantees that the message will not be lost as long as at least one of the replicas remains alive.  Message Ordering For each partition of a topic, Kafka guarantees that consumers receive messages in the same order that the producer has written them to the partition. Hono\u0026rsquo;s protocol adapters, therefore, use the device identifier as the key when writing messages to downstream topics, thus making sure that messages originating from the same device always end up in the same partition. For example, each protocol adapter must always send telemetry data reported by a particular device to the same partition (e.g. by using the same partitioner implementation) in the same order that they have been received in.\nThe following producer configuration properties influence if the order of the messages can be guaranteed by Kafka:\n retries max.in.flight.requests.per.connection enable.idempotence  Setting acks to 0 effectively disables retries. If retries are set to a value greater than zero and max.in.flight.requests.per.connection is set to a value greater than 1, Kafka no longer guarantees that messages are stored in the order they have been sent. The only exception is the idempotent producer, which can handle max.in.flight.requests.per.connection to be up to 5 with retries enabled while still maintaining the message order (since Kafka version 1.0.0). Note that the idempotent producer option requires special privileges for the producer\u0026rsquo;s user to be configured.\nAT LEAST ONCE Producers To provide AT LEAST ONCE delivery semantics, a producer MUST wait for the acknowledgements from all in-sync replicas before sending the acknowledgement back to the client. This can be achieved e.g. by setting acks to all or, implicitly, by setting enable.idempotence to true.\nThe producer MUST retain the order in which it received messages from a client. This requires that if retries is set to a value greater than zero, max.in.flight.requests.per.connection must be set to 1. Alternatively, enable.idempotence can be set to true. Disabling retries might cause messages to fail in case of high load or transient transmission failures, so this is not recommended.\nThe recommended configuration for AT LEAST ONCE producers has the following properties: enable.idempotence=true, acks=all, max.in.flight.requests.per.connection=5, leaving retries unset (which defaults to Integer.MAX), and setting delivery.timeout.ms to a reasonable value. This configuration is supported from Kafka version 1.0.0 on.\nAT MOST ONCE Producers Every producer that does not wait for acknowledgements from all in-sync replicas or does not consider them before sending an acknowledgement back to the client, is considered to provide only AT MOST ONCE delivery semantics. To achieve this, several strategies are possible:\n The producer can disable acknowledgements (acks=0). This is the fastest mode of delivery but has the drawback of a potential loss of messages without notice. The producer can enable acknowledgements, but not wait for the acknowledgements from the Kafka cluster before acknowledging the message to its client.  The producer MUST retain the order in which it received messages from a client. This requires to either set retries to 0 or to set max.in.flight.requests.per.connection to 1.\nNB: To send messages with both delivery semantics with the same producer, it MUST be configured for AT LEAST ONCE. Such a producer may ignore the outcome of the produce operation for AT MOST ONCE messages.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/telemetry-kafka/",
	"title": "Telemetry API for Kafka Specification",
	"tags": [],
	"description": "",
	"content": "The Telemetry API is used by Protocol Adapters to send telemetry data downstream. Business Applications and other consumers use the API to receive data published by devices belonging to a particular tenant.\nThe Telemetry API for Kafka is an alternative to the Telemetry API for AMQP. With this API, clients publish telemetry data to an Apache Kafka® cluster instead of an AMQP Messaging Network.\nSee Kafka-based APIs for fundamental information about Hono\u0026rsquo;s Kafka-based APIs. The statements there apply to this specification.\n Tech preview The support of Kafka as a messaging system is currently a preview and not yet ready for production. The APIs are subject to change without prior notice.  Southbound Operations The following operation can be used by Protocol Adapters to send telemetry data received from devices to downstream consumers like Business Applications.\nProduce Telemetry Data The protocol adapter writes messages to the tenant-specific topic hono.telemetry.${tenant_id} where ${tenant_id} is the ID of the tenant that the client wants to upload telemetry data for.\nPreconditions\n Either the topic hono.telemetry.${tenant_id} exists, or the broker is configured to automatically create topics on demand. The client is authorized to write to the topic. The device for which the adapter wants to send telemetry data has been registered (see Device Registration API).  Message Flow\nIt is up to the discretion of the protocol adapter whether it wants to use AT LEAST ONCE or AT MOST ONCE delivery semantics according to AT LEAST ONCE Producers respectively AT MOST ONCE Producers.\nThe recommended Kafka producer properties for AT LEAST ONCE delivery are: enable.idempotence=true, acks=all, max.in.flight.requests.per.connection=5, leaving retries unset, and setting delivery.timeout.ms to a reasonable value (supported from Kafka version 1.0.0 on).\nThe following sequence diagram illustrates the flow of messages involved in the HTTP Adapter producing a telemetry data message to the Kafka cluster implementing AT MOST ONCE delivery semantics.\n  Produce telemetry data flow (AT MOST ONCE)    Device 4711 PUTs telemetry data to the HTTP Adapter  HTTP Adapter produces telemetry data to the Kafka Cluster. HTTP Adapter acknowledges the reception of the data to the Device.    The following sequence diagram illustrates the flow of messages involved in the HTTP Adapter producing a telemetry data message to the Kafka cluster implementing AT LEAST ONCE delivery semantics.\n  Produce telemetry data flow (AT LEAST ONCE)    Device 4711 PUTs telemetry data to the HTTP Adapter, indicating QoS Level 1.  HTTP Adapter produces telemetry data to the Kafka Cluster. Kafka Cluster acknowledges reception of the message. HTTP Adapter acknowledges the reception of the data to the Device.    When a Kafka producer raises an exception while sending a telemetry message to Kafka, the protocol adapter MUST NOT try to re-send such rejected messages but SHOULD indicate the failed transfer to the device if the transport protocol provides means to do so.\nUse AT LEAST ONCE and AT MOST ONCE in a Protocol Adapter\nIf a protocol adapter should support both delivery semantics, a single producer MUST be used and it MUST be configured for AT LEAST ONCE. It may not wait for acknowledgements of AT MOST ONCE messages.\nA protocol adapter MUST NOT use two producers sending telemetry data for the same device. Otherwise, the messages from a device with different QoS levels could be out of order, as Kafka does not guarantee the message order between multiple producer instances.\nMessage Format\nThe key of the message MUST be the device ID.\nMetadata MUST be set as Kafka headers on a message. The following table provides an overview of the headers a client needs to set on a Produce Telemetry Data message.\n   Name Mandatory Type Description     content-type yes string A content type indicating the type and characteristics of the data contained in the message value as a valid MIME type, e.g. text/plain; charset=\u0026quot;utf-8\u0026quot; for a text message or application/json etc. The value may be set to application/octet-stream if the message message value is to be considered opaque binary data. See RFC 2046 for details.   content-encoding no string The content encoding as defined in section 3.5 of RFC 2616.   creation-time no long The instant in time (milliseconds since the Unix epoch) when the message has been created. This header is mandatory if ttd or ttl is set, otherwise, it is optional.   device_id yes string The identifier of the device that the data in the message value is originating from.   qos no int The quality of service level of the message. Supported values are 0 for AT MOST ONCE and 1 for AT LEAST ONCE.   ttd no int The time \u0026lsquo;til disconnect indicates the number of seconds that the device will remain connected to the protocol adapter. The value of this header must be interpreted relative to the message\u0026rsquo;s creation-time. A value of -1 is used to indicate that the device will remain connected until further notice, i.e. until another message indicates a ttd value of 0. In absence of this property, the connection status of the device is to be considered indeterminate. Backend Applications might use this information to determine a time window during which the device will be able to receive a command.   ttl no long The time-to-live in milliseconds. A consumer of the message SHOULD discard the message if the sum of creation-time and ttl is greater than the current time (milliseconds since the Unix epoch).    Protocol adapters MAY add additional headers to the Kafka record.\nThe value of the message MUST consist of a byte array containing the telemetry data. The format and encoding of the data MUST be indicated by the content-type and (optional) content-encoding headers of the message.\nNorthbound Operations The following operation can be used by Business Applications to receive telemetry data from Kafka.\nConsume Telemetry Data Hono delivers messages containing telemetry data reported by a particular device in the same order that they have been received in (using the Produce Telemetry Data operation). Business Applications consume messages from the tenant-specific topic hono.telemetry.${tenant_id} where ${tenant_id} represents the ID of the tenant the client wants to retrieve telemetry data for.\nPreconditions\n Either the topic hono.telemetry.${tenant_id} exists, or the broker is configured to automatically create topics on demand. The client is authorized to read from the topic. The client subscribes to the topic with a Kafka consumer.  A consumer can provide AT MOST ONCE or AT LEAST ONCE delivery semantics depending on the offset commit strategy it implements. If a message has the qos Kafka header with the value 1, the consumer is expected to provide proper AT LEAST ONCE semantics, and therefore MUST NOT commit the message offset before it has been fully processed.\nMessage Flow\nThe following sequence diagram illustrates the flow of messages involved in a Business Application consuming a telemetry data message from the Kafka cluster. The delivery mode used is AT LEAST ONCE.\n  Consume Telemetry Data    Business Application polls telemetry messages from Kafka Cluster.  Kafka Cluster returns a batch of messages.   Business Application processes the messages. Business Application commits the offset of the last processed telemetry message.  Kafka Cluster acknowledges the commit.    Message Format\nThe format of the messages containing the telemetry data is the same as for the Produce Telemetry Data operation.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/event-kafka/",
	"title": "Event API for Kafka Specification",
	"tags": [],
	"description": "",
	"content": "The Event API is used by Protocol Adapters to send event messages downstream. Business Applications and other consumers use the API to receive messages published by devices belonging to a particular tenant.\nThe Event API for Kafka is an alternative to the Event API for AMQP. With this API, clients publish event messages to an Apache Kafka® cluster instead of an AMQP Messaging Network.\nSee Kafka-based APIs for fundamental information about Hono\u0026rsquo;s Kafka-based APIs. The statements there apply to this specification.\n Tech preview The support of Kafka as a messaging system is currently a preview and not yet ready for production. The APIs are subject to change without prior notice.  Southbound Operations The following operation can be used by Protocol Adapters to send event messages received from devices to downstream consumers like Business Applications.\nProduce Event The protocol adapter writes messages to the tenant-specific topic hono.event.${tenant_id} where ${tenant_id} is the ID of the tenant that the client wants to upload event messages for.\nPreconditions\n Either the topic hono.event.${tenant_id} exists, or the broker is configured to automatically create topics on demand. The client is authorized to write to the topic. The device for which the adapter wants to send event messages has been registered (see Device Registration API).  Message Flow\nHono supports AT LEAST ONCE delivery of Event messages only, as defined in Telemetry API for Kafka.\nThe following sequence diagram illustrates the flow of messages involved in the MQTT Adapter producing an event to the Kafka cluster.\n  Produce event flow    Device 4711 publishes an event using MQTT QoS 1.  MQTT Adapter produces an event message to the Kafka Cluster. Kafka cluster acknowledges reception of the message. MQTT Adapter acknowledges the reception of the message to the Device.    When a Kafka producer raises an exception while sending an event message to Kafka, the protocol adapter MUST NOT try to re-send such rejected messages but MUST indicate the failed transfer to the device if the transport protocol provides means to do so.\nMessage Format\nSee Telemetry API for Kafka for the definition of the message format.\nNorthbound Operations The following operation can be used by Business Applications to receive event messages from Kafka.\nConsume Events Hono delivers messages containing events reported by a particular device in the same order that they have been received in (using the Produce Event operation). Business Applications consume messages from the tenant-specific topic hono.event.${tenant_id} where ${tenant_id} represents the ID of the tenant the client wants to retrieve event messages for.\nPreconditions\n Either the topic hono.event.${tenant_id} exists, or the broker is configured to automatically create topics on demand. The client is authorized to read from the topic. The client subscribes to the topic with a Kafka consumer.  Hono supports AT LEAST ONCE delivery of Event messages only. A consumer is expected to provide proper AT LEAST ONCE semantics and therefore MUST NOT commit offsets of messages that have not yet been fully processed.\nMessage Flow\nThe following sequence diagram illustrates the flow of messages involved in a Business Application consuming an event message from the Kafka cluster.\n  Consume event flow (success)    Business Application polls event messages from Kafka Cluster.  Kafka Cluster returns a batch of messages.   Business Application processes the messages. Business Application commits the offset of the last processed event message.  Kafka Cluster acknowledges the commit.    Message Format\nSee Telemetry API for Kafka for the definition of the message format.\nWell-known Event Message Types Hono defines several well-known event types which have specific semantics. Events of these types are identified by means of the message\u0026rsquo;s content-type header.\nEmpty Notification A Kafka message containing this type of event does not have any payload so the value of the message MUST be empty.\nThe headers an event sender needs to set for an empty notification event are defined in the Telemetry API for Kafka.\nThe relevant headers are listed again in the following table:\n   Name Mandatory Type Description     content-type yes string MUST be set to application/vnd.eclipse-hono-empty-notification   ttd no int The time \u0026lsquo;til disconnect as described in the Telemetry API for Kafka.    NB An empty notification can be used to indicate to a Business Application that a device is currently ready to receive an upstream message by setting the ttd property. Backend Applications may use this information to determine the time window during which the device will be able to receive a command.\nConnection Event Protocol Adapters may send this type of event to indicate that a connection with a device has been established or has ended. Note that such events can only be sent for authenticated devices, though, because an event is always scoped to a tenant and the tenant of a device is established as part of the authentication process.\nThe Kafka message for a connection event MUST contain the following headers in addition to the standard event headers:\n   Name Mandatory Type Description     content-type yes string MUST be set to application/vnd.eclipse-hono-dc-notification+json.   device_id yes string The ID of the authenticated device.    Each connection event\u0026rsquo;s message value MUST contain a UTF-8 encoded string representation of a single JSON object with the following fields:\n   Name Mandatory Type Description     cause yes string The cause of the connection event. MUST be set to either connected or disconnected.   remote-id yes string An identifier of the device that is the subject of this event, e.g. an IP address:port, client id etc. The format and semantics of this identifier is specific to the protocol adapter and the transport protocol it supports.   source yes string The type name of the protocol adapter reporting the event, e.g. hono-mqtt.   data no object An arbitrary JSON object which may contain additional information about the occurrence of the event.    The example below might be used by the MQTT adapter to indicate that a connection with a device using client identifier mqtt-client-id-1 has been established:\n{ \u0026#34;cause\u0026#34;: \u0026#34;connected\u0026#34;, \u0026#34;remote-id\u0026#34;: \u0026#34;mqtt-client-id-1\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;hono-mqtt\u0026#34;, \u0026#34;data\u0026#34;: { \u0026#34;foo\u0026#34;: \u0026#34;bar\u0026#34; } } "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/command-and-control-kafka/",
	"title": "Command &amp; Control API for Kafka Specification",
	"tags": [],
	"description": "",
	"content": "The Command \u0026amp; Control API of Eclipse Hono™ is used by Business Applications to send commands to connected devices.\nCommands can be used to trigger actions on devices. Examples include updating a configuration property, installing a software component or switching the state of an actuator.\nHono distinguishes two types of commands. The first type is one-way only. In this case the sender of the command does not expect the device to send back a message in response to the command. This type of command is referred to as a one-way command in the remainder of this page. One-way commands may be used to e.g. notify a device about a change of state.\nThe second type of commands expects a response to be sent back from the device as a result of processing the command. In this case the response contains a status code which indicates whether the command could be processed successfully. If so, the response may also include data representing the result of processing the command. This type of command is plainly referred to as a command because it represents the default case.\nThe Command \u0026amp; Control API for Kafka is an alternative to the Command \u0026amp; Control API for AMQP. With this API, clients send command messages to an Apache Kafka® cluster instead of an AMQP Messaging Network.\nSee Kafka-based APIs for fundamental information about Hono\u0026rsquo;s Kafka-based APIs. The statements there apply to this specification.\n Tech preview The support of Kafka as a messaging system is currently a preview and not yet ready for production. The APIs are subject to change without prior notice.  Send a One-Way Command Business Applications use this operation to send a command to a device for which they do not expect to receive a response from the device. For that, the Business Application connects to the Kafka Cluster and writes a message to the tenant-specific topic hono.command.${tenant_id} where ${tenant_id} is the ID of the tenant that the client wants to send the command for.\nPreconditions\n Either the topic hono.command.${tenant_id} exists, or the broker is configured to automatically create topics on demand. The Business Application is authorized to write to the topic.  Message Flow\n The Business Application writes a command message to the topic hono.command.${tenant_id} on the Kafka Cluster. Hono consumes the message from the Kafka Cluster and forwards it to the device, provided that the target device is connected and is accepting commands.  Message Format\nThe key of the message MUST be the ID of the device that the command is targeted at.\nMetadata MUST be set as Kafka headers on a message. The following table provides an overview of the headers the Business Application needs to set on a one-way command message.\n   Name Mandatory Type Description     device_id yes string The identifier of the device that the command is targeted at.   subject yes string The name of the command to be executed by the device.   content-type no string If present, MUST contain a Media Type as defined by RFC 2046 which describes the semantics and format of the command\u0026rsquo;s input data contained in the message payload. However, not all protocol adapters will support this property as not all transport protocols provide means to convey this information, e.g. MQTT 3.1.1 has no notion of message headers.    The command message MAY contain arbitrary payload, set as message value, to be sent to the device. The value of the message\u0026rsquo;s subject header may provide a hint to the device regarding the format, encoding and semantics of the payload data.\nSend a (Request/Response) Command Business Applications use this operation to send a command to a device for which they expect the device to send back a response. For that, the Business Application connects to the Kafka Cluster and writes a message to the tenant-specific topic hono.command.${tenant_id} where ${tenant_id} is the ID of the tenant that the client wants to send the command for. The Business Application can consume the corresponding command response from the hono.command_response.${tenant_id} topic.\nIn contrast to a one-way command, a request/response command contains a response-required header with value true and a correlation-id header, providing the identifier that is used to correlate a response message to the original request.\nPreconditions\n Either the topics hono.command.${tenant_id} and hono.command_response.${tenant_id} exist, or the broker is configured to automatically create topics on demand. The Business Application is authorized to write to the hono.command.${tenant_id} topic and read from the hono.command_response.${tenant_id} topic. The Business Application is subscribed to the hono.command_response.${tenant_id} topic with a Kafka consumer.  Message Flow\n The Business Application writes a command message to the topic hono.command.${tenant_id} on the Kafka Cluster. Hono consumes the message from the Kafka Cluster and forwards it to the device, provided that the target device is connected and is accepting commands. The device sends a command response message. Hono writes that message to the hono.command_response.${tenant_id} topic on the Kafka Cluster. The Business Application consumes the command response message from the hono.command_response.${tenant_id} topic.  Command Message Format\nThe key of the message MUST be the ID of the device that the command is targeted at.\nMetadata MUST be set as Kafka headers on a message. The following table provides an overview of the headers the Business Application needs to set on a request/response command message.\n   Name Mandatory Type Description     correlation-id yes string The identifier used to correlate a response message to the original request. It is used as the correlation-id header in the response.   device_id yes string The identifier of the device that the command is targeted at.   response-required yes boolean MUST be set with a value of true, meaning that the device is required to send a response for the command.   subject yes string The name of the command to be executed by the device.   content-type no string If present, MUST contain a Media Type as defined by RFC 2046 which describes the semantics and format of the command\u0026rsquo;s input data contained in the message payload. However, not all protocol adapters will support this property as not all transport protocols provide means to convey this information, e.g. MQTT 3.1.1 has no notion of message headers.    The command message MAY contain arbitrary payload, set as message value, to be sent to the device. The value of the message\u0026rsquo;s subject header may provide a hint to the device regarding the format, encoding and semantics of the payload data.\nAn application can determine the overall outcome of the operation by means of the response to the command. The response is either sent back by the device, or in case the command could not be successfully forwarded to the device, an error command response message is sent by the Hono protocol adapter or Command Router component.\nResponse Message Format\nThe key of the message MUST be the ID of the device that the command response is from.\nMetadata MUST be set as Kafka headers on a message. The following table provides an overview of the headers set on a message sent in response to a command.\n   Name Mandatory Type Description     correlation-id yes string MUST contain the value of the correlation-id header of the request message that this is the response for.   device_id yes string The identifier of the device that sent the response.   status yes integer MUST indicate the status of the execution. See table below for possible values.   content-type no string If present, MUST contain a Media Type as defined by RFC 2046 which describes the semantics and format of the command\u0026rsquo;s input data contained in the message payload. However, not all protocol adapters will support this property as not all transport protocols provide means to convey this information, e.g. MQTT 3.1.1 has no notion of message headers.\nIf the response is an error message sent by the Hono protocol adapter or Command Router component, the content type MUST be application/vnd.eclipse-hono-delivery-failure-notification+json.    The status header must contain an HTTP 1.1 response status code.\nThe command response message MAY contain arbitrary payload, set as message value, to be sent to the business application.\nResponse Message sent from Device\nIn a response from a device, the semantics of the status code ranges are as follows:\n   Code Description     2xx The command has been processed successfully.   4xx The command could not be processed due to a client error, e.g. malformed message payload.   5xx The command could not be processed due to an internal problem at the device side.    The semantics of the individual codes are specific to the device and command. For status codes indicating an error (codes in the 400 - 599 range) the message body MAY contain a detailed description of the error that occurred.\nResponse Message sent from Hono Component\nIf the command response message represents an error message sent by the Hono protocol adapter or Command Router component, with the content-type header set to application/vnd.eclipse-hono-delivery-failure-notification+json, the possible status codes are:\n   Code Description     4xx The command has not been delivered to or processed by the device because the command message does not contain all required information. Another reason may be that a message limit has been exceeded.   5xx The command has not been delivered to the device or can not be processed by the device due to reasons that are not the responsibility of the sender of the command. Possible reasons are:The device is (currently) not connected.In case the transport protocol supports acknowledgements: The device hasn\u0026rsquo;t sent an acknowledgement in time or has indicated that the message cannot be processed.There was an error forwarding the command to the device.    The payload MUST contain a UTF-8 encoded string representation of a single JSON object with the following fields:\n   Name Mandatory Type Description     error yes string The error message describing the cause for the command message delivery failure.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/tenant/",
	"title": "Tenant API Specification",
	"tags": [],
	"description": "",
	"content": "The Tenant API is used by Hono\u0026rsquo;s protocol adapters to retrieve information that affects all devices belonging to a particular tenant. A tenant is a logical entity, which groups together a set of devices. The information registered for a tenant is used for example to determine if devices belonging to the tenant are allowed to connect to a certain protocol adapter or if devices are required to authenticate.\nThis document describes the Tenant API\u0026rsquo;s operations and the payload data format used by them. Please refer to Multi Tenancy for details regarding the way Hono supports multiple tenants.\nThe Tenant API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to Hono using an AMQP 1.0 client in order to invoke operations of the API as described in the following sections.\n\nPreconditions for invoking the Tenant API  Client has established an AMQP connection with the Tenant service. Client has established an AMQP link in role sender on the connection using target address tenant. This link is used by the client to send request messages to the Tenant service. Client has established an AMQP link in role receiver on the connection using source address tenant/${reply-to} where reply-to may be any arbitrary string chosen by the client. This link is used by the client to receive responses to the requests it has sent to the Tenant service. This link\u0026rsquo;s source address is also referred to as the reply-to address for the request messages.    Client connecting to Tenant service   Get Tenant Information Clients use this operation to retrieve information about a tenant.\nMessage Flow\nThe following sequence diagram illustrates the flow of messages involved in a Client retrieving tenant information.\n  Client retrieving tenant information   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to get tenant information:\n   Name Mandatory Location AMQP Type Description     correlation-id no properties message-id MAY contain an ID used to correlate a response message to the original request. If set, it is used as the correlation-id property in the response, otherwise the value of the message-id property is used. Either this or the message-id property MUST be set.   message-id no properties string MAY contain an identifier that uniquely identifies the message at the sender side. Either this or the correlation-id property MUST be set.   reply-to yes properties string MUST contain the source address that the client wants to receive response messages from. This address MUST be the same as the source address used for establishing the client\u0026rsquo;s receive link (see Preconditions).   subject yes properties string MUST be set to get.    The body of the request message MUST consist of a single Data section containing a UTF-8 encoded string representation of a single JSON object.\nThe JSON object MUST contain exactly one of the following search criteria properties:\n   Name Mandatory JSON Type Description     subject-dn no string The subject DN of the trusted certificate authority\u0026rsquo;s public key in the format defined by RFC 2253.   tenant-id no string The identifier of the tenant to get.    The following request payload may be used to look up the tenant with identifier ACME Corporation:\n{ \u0026#34;tenant-id\u0026#34;: \u0026#34;ACME Corporation\u0026#34; } The following request payload may be used to look up the tenant for which a trusted certificate authority with subject DN O=ACME Corporation, CN=devices has been configured:\n{ \u0026#34;subject-dn\u0026#34;: \u0026#34;CN=devices,O=ACME Corporation\u0026#34; } Response Message Format\nThe following table provides an overview of the properties contained in a response message to a get tenant information request:\n   Name Mandatory Location AMQP Type Description     correlation-id yes properties message-id Contains the message-id (or the correlation-id, if specified) of the request message that this message is the response to.   content-type no properties string MUST be set to application/json if the invocation of the operation was successful and the body of the response message contains payload as described below.   status yes application-properties int Contains the status code indicating the outcome of the operation. Concrete values and their semantics are defined for each particular operation.   cache_control no application-properties string Contains an RFC 2616 compliant cache directive. The directive contained in the property MUST be obeyed by clients that are caching responses.    The response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     200 OK, The response message body contains the requested tenant information.   400 Bad Request, the request message did not contain all mandatory properties.   403 Forbidden, the client is not authorized to retrieve information for the given tenant.   404 Not Found, there is no tenant matching the given search criteria.    For status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred. In this case, the response message\u0026rsquo;s content-type property SHOULD be set accordingly.\nOtherwise the response message contains the information for the requested tenant as described in the following sections.\n\nTenant Information Format Tenant information is carried in a single Data section of the response message as a UTF-8 encoded string representation of a single JSON object. It is an error to include payload that is not of this type.\nThe table below provides an overview of the standard members defined for the JSON response object:\n   Name Mandatory JSON Type Description     adapters no array A list of configuration options valid for certain adapters only. The format of a configuration option is described here Adapter Configuration Format. NB If the element is provided then the list MUST NOT be empty. NB Only a single entry per type is allowed. If multiple entries for the same type are present it is handled as an error. NB If the element is omitted then all adapters are enabled in their default configuration.   defaults no object Arbitrary default properties for devices belonging to the tenant. The properties can be used by protocol adapters to augment downstream messages with missing information, e.g. setting a default content type or time-to-live.   enabled yes boolean If set to false the tenant is currently disabled. Protocol adapters MUST NOT allow devices of a disabled tenant to connect and MUST NOT accept data published by such devices.   minimum-message-size no number The minimum message size in bytes. If it is set then the payload size of the telemetry, event and command messages are calculated in accordance with the configured value and then reported to the metrics. See Metrics for more details.   resource-limits no object Any resource limits that should be enforced for the tenant, e.g. the maximum number of concurrent connections and the maximum data volume for a given period. Refer to Resource Limits Configuration Format for details.   tenant-id yes string The ID of the tenant.   tracing no object A set of options regarding the tracing of messages for the tenant. See Tracing Format for a definition of the content model of the object.   trusted-ca no array The list of trusted certificate authorities to use for validating certificates presented by devices of the tenant for authentication purposes. See Trusted Certificate Authority Format for a definition of the content model of the objects contained in the array. NB If the element is provided then the list MUST NOT be empty.    The JSON object MAY contain an arbitrary number of additional members with arbitrary names which can be of a scalar or a complex type. This allows for future well-known additions and also allows to add further information which might be relevant to a custom adapter only.\nExamples\nThe JSON structure below contains example information for tenant TEST_TENANT. Note that the structure contains some custom properties at both the root level (customer) as well as the adapter configuration level (deployment) and also defines a default TTL for downstream messages.\n{ \u0026#34;tenant-id\u0026#34;: \u0026#34;TEST_TENANT\u0026#34;, \u0026#34;defaults\u0026#34;: { \u0026#34;ttl\u0026#34;: 30 }, \u0026#34;enabled\u0026#34;: true, \u0026#34;customer\u0026#34;: \u0026#34;ACME Inc.\u0026#34;, \u0026#34;resource-limits\u0026#34;: { \u0026#34;max-connections\u0026#34;: 100000, \u0026#34;data-volume\u0026#34;: { \u0026#34;max-bytes\u0026#34;: 2147483648, \u0026#34;period\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;days\u0026#34;, \u0026#34;no-of-days\u0026#34;: 30 }, \u0026#34;effective-since\u0026#34;: \u0026#34;2019-07-27T14:30:00Z\u0026#34; } }, \u0026#34;adapters\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;hono-mqtt\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;device-authentication-required\u0026#34;: true }, { \u0026#34;type\u0026#34;: \u0026#34;hono-http\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;device-authentication-required\u0026#34;: true, \u0026#34;deployment\u0026#34;: { \u0026#34;maxInstances\u0026#34;: 4 } } ] } Tracing Format The table below provides an overview of the members defined for the tracing JSON object:\n   Name Mandatory Type Default Value Description     sampling-mode no string default Defines in how far OpenTracing spans created when processing messages for this tenant shall be recorded (sampled) by the tracing system. The value default lets the default sampling mechanism be used. The value all marks the spans related to this tenant so that they should all be sampled. The value none marks the spans as not to be sampled. The mode defined here may be overridden for a particular auth-id by means of the sampling-mode-per-auth-id property.   sampling-mode-per-auth-id no object  Defines in how far OpenTracing spans created when processing messages for this tenant and a particular auth-id shall be recorded (sampled) by the tracing system. The child properties have the auth-id as name. A child property value of default lets the default sampling mechanism be used. The child property value all marks the spans related to this tenant and the auth-id so that they should all be sampled. The child property value none marks the spans as not to be sampled. The mode defined for a particular auth-id has precedence over the value defined by the sampling-mode property.    Trusted CA Format The table below provides an overview of the members of a JSON object representing a trusted CA:\n   Name Mandatory Type Default Value Description     subject-dn yes string - The subject DN of the trusted root certificate in the format defined by RFC 2253.   public-key yes string - The Base64 encoded binary DER encoding of the trusted root certificate\u0026rsquo;s public key.   algorithm no string RSA The name of the public key algorithm. Supported values are RSA and EC.   auto-provisioning-enabled no boolean false If set to true, protocol adapters MAY request auto-provisioning of devices that authenticate with a client certificate issued by this CA. Otherwise, protocol adapters MUST NOT request auto-provisioning.    NB CAs of the same tenant MAY share the same subject DN, e.g. allowing for the definition of overlapping validity periods. However, CAs of different tenants MUST NOT share the same subject DN in order to allow for the unique look-up of a tenant by the subject DN of one of its trusted CAs.\nExamples\nBelow is an example payload for a response to a get request for tenant TEST_TENANT. The tenant is configured with two trusted certificate authorities, each using a different public key algorithm. Only one of them is configured to be used for auto-provisioning.\n{ \u0026#34;tenant-id\u0026#34; : \u0026#34;TEST_TENANT\u0026#34;, \u0026#34;enabled\u0026#34; : true, \u0026#34;trusted-ca\u0026#34;: [{ \u0026#34;subject-dn\u0026#34;: \u0026#34;CN=ca,OU=Hono,O=Eclipse\u0026#34;, \u0026#34;public-key\u0026#34;: \u0026#34;PublicKey==\u0026#34;, \u0026#34;auto-provisioning-enabled\u0026#34;: false, \u0026#34;algorithm\u0026#34;: \u0026#34;RSA\u0026#34; }, { \u0026#34;subject-dn\u0026#34;: \u0026#34;CN=ca,OU=Hono,O=ACME Inc.\u0026#34;, \u0026#34;public-key\u0026#34;: \u0026#34;ECKey==\u0026#34;, \u0026#34;auto-provisioning-enabled\u0026#34;: true, \u0026#34;algorithm\u0026#34;: \u0026#34;EC\u0026#34; }] } Adapter Configuration Format The table below contains the properties which are used to configure a Hono protocol adapter:\n   Name Mandatory JSON Type Default Value Description     type yes string - The type of the adapter which this configuration belongs to.   enabled no boolean false If set to false the tenant is not allowed to receive / send data utilizing the given adapter.   device-authentication-required no boolean true If set to false, devices are not required to authenticate with the adapter before sending / receiving data.    Protocol adapters SHOULD use the configuration properties set for a tenant when interacting with devices of that tenant, e.g. in order to make authorization decisions etc.\nThe JSON object MAY contain an arbitrary number of additional members with arbitrary names of either scalar or complex type. This allows for future well-known additions and also allows to add further information which might be relevant to a custom adapter only.\nResource Limits Configuration Format The table below contains the properties which are used to configure a tenant\u0026rsquo;s resource limits:\n   Name Mandatory JSON Type Default Value Description     max-connections no number -1 The maximum number of concurrent connections allowed from devices of this tenant. The default value -1 indicates that no limit is set.   max-ttl no number -1 The maximum time-to-live (in seconds) to use for events published by devices of this tenant. Any default TTL value specified at either the tenant or device level will be limited to the max value specified here. If this property is set to a value greater than -1 and no default TTL is specified for a device, the max value will be used for events published by the device. A value of -1 (the default) indicates that no limit is set. Note that this property contains the TTL in seconds whereas the AMQP 1.0 specification defines a message\u0026rsquo;s ttl header to use milliseconds.   connection-duration no object - The maximum connection duration allowed for the given tenant. Refer to Connection Duration Configuration Format for details.   data-volume no object - The maximum data volume allowed for the given tenant. Refer to Data Volume Configuration Format for details.    Protocol adapters SHOULD use the max-connections property to determine if a device\u0026rsquo;s connection request should be accepted or rejected.\nProtocol adapters SHOULD use the max-ttl property to determine the effective time-to-live for events published by devices as follows:\n If a non-default max-ttl is set for the tenant, use that value as the effective ttl, otherwise set effective ttl to -1. If the event published by the device  contains a ttl header and effective ttl is not -1 and the ttl value (in seconds) provided by the device is smaller than the effective ttl, use the device provided ttl value as the new effective ttl. does not contain a ttl header but a default ttl value is configured for the device (with the device level taking precedence over the tenant level) and effective ttl is not -1 and the default value is smaller than the effective ttl, use the default ttl value as the new effective ttl.   If effective ttl is not -1, set the downstream event message\u0026rsquo;s ttl header to its value (in milliseconds).  The JSON object MAY contain an arbitrary number of additional members with arbitrary names of either scalar or complex type. This allows for future well-known additions and also allows to add further information which might be relevant to a custom adapter only.\nConnection Duration Configuration Format The table below contains the properties which are used to configure a tenant\u0026rsquo;s connection duration limit:\n   Name Mandatory JSON Type Default Value Description     effective-since yes string - The point in time at which the current settings became effective, i.e. the start of the first accounting period based on these settings. The value MUST be an ISO 8601 compliant combined date and time representation in extended format.   max-minutes no number -1 The maximum connection duration in minutes allowed for the tenant for each accounting period. MUST be an integer. Minus one indicates that no limit is set.   period no object - The mode and length of an accounting period, i.e. the resource usage is calculated based on the defined number of days or on a monthly basis. For more information, please refer to the resource limits period.    Protocol adapters that maintain connection state SHOULD use this information to determine if a connection request from a device should be accepted or not. For more information, please refer to the connection duration limit concept.\nData Volume Configuration Format The table below contains the properties which are used to configure a tenant\u0026rsquo;s data volume limit:\n   Name Mandatory JSON Type Default Value Description     effective-since yes string - The point in time at which the current settings became effective, i.e. the start of the first accounting period based on these settings. The value MUST be an ISO 8601 compliant combined date and time representation in extended format.   max-bytes no number -1 The maximum number of bytes allowed for the tenant for each accounting period. MUST be an integer. A negative value indicates that no limit is set.   period no object - The mode and length of an accounting period, i.e. the data usage can limited based on the defined number of days or on a monthly basis. For more information, please refer to the resource limits period.    Protocol adapters SHOULD use this information to determine if a message originating from or destined to a device should be accepted for processing.\nResource Limits Period Configuration Format The table below contains the properties that are used to configure a tenant\u0026rsquo;s resource limits period:\n   Name Mandatory JSON Type Default Value Description     mode yes string - The mode of the resource usage calculation. The default implementation supports two modes namely days and monthly.   no-of-days no number - When the mode is set as days, then this value represents the length of an accounting period , i.e. the number of days over which the resource usage is to be limited. MUST be a positive integer.    Delivery States used by the Tenant API A Tenant service implementation uses the following AMQP message delivery states when receiving request messages from clients:\n   Delivery State Description     ACCEPTED Indicates that the request message has been received and accepted for processing.   REJECTED Indicates that the request message has been received but cannot be processed. The disposition frame\u0026rsquo;s error field contains information regarding the reason why. Clients should not try to re-send the request using the same message properties and payload in this case.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/command-router/",
	"title": "Command Router API Specification",
	"tags": [],
	"description": "",
	"content": "Protocol Adapters use the Command Router API to supply information with which a Command Router service component can route command \u0026amp; control messages to the protocol adapters that the target devices are connected to.\n Note The Command Router API will replace the now deprecated Device Connection API.  The Command Router API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to the service component using an AMQP 1.0 client in order to invoke operations of the API as described in the following sections.\n\nPreconditions for invoking the Command Router API  Client has established an AMQP connection with the Command Router service. Client has established an AMQP link in role sender on the connection using target address cmd_router/${tenant_id}. This link is used by the client to send request messages to the Command Router service. Client has established an AMQP link in role receiver on the connection using source address cmd_router/${tenant_id}/${reply-to} where reply-to may be any arbitrary string chosen by the client. This link is used by the client to receive responses to the requests it has sent to the Command Router service. This link\u0026rsquo;s source address is also referred to as the reply-to address for the request messages.    Client connecting to Command Router service   Register command consumer for device Clients use this command to register a protocol adapter instance as the consumer of command \u0026amp; control messages for a device or gateway currently connected to that particular adapter instance.\nClients can provide an optional lifespan parameter to make the registration entry expire after the given number of seconds. Note that implementations of this API have to support this feature, otherwise the Command Router service component might fail to correctly route command messages.\nThis API doesn\u0026rsquo;t mandate checks on the validity of the given device in order not to introduce a dependency on the Device Registration API. However, implementations of this API may choose to perform such checks or impose a restriction on the overall amount of data that can be stored per tenant in order to protect against malicious requests.\nMessage Flow\n  Client registers the command consumer for a device   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to register the command consumer for a device in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to register-cmd-consumer.   adapter_instance_id yes application-properties string The identifier of the protocol adapter instance that currently handles commands for the device or gateway identified by the device_id property.   device_id yes application-properties string MUST contain the ID of the device that is subject to the operation.   lifespan no application-properties int The lifespan of the mapping entry in seconds. After that period, the registration entry shall be treated as non-existent by the Command Router service component. A negative value, as well as an omitted property, is interpreted as an unlimited lifespan.    The body of the message SHOULD be empty and will be ignored if it is not.\nResponse Message Format\nA response to a register command consumer for device request contains the Standard Response Properties.\nThe response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     204 OK, the command consumer registration entry for the device has been created or updated.   400 Bad Request, the command consumer registration entry for the device has not been created or updated due to invalid or missing data in the request.    Implementors of this API may return a 404 status code in order to indicate that no device with the given identifier exists for the given tenant. However, performing such a check is optional.\nFor status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nUnregister command consumer for device Clients use this command to unregister a command consumer for the given device. The consumer registration entry to be removed is identified by the provided protocol adapter instance handling command \u0026amp; control messages for a given device. The registration entry for the device is only removed, if the adapter instance identifier of the current registration entry matches the one given in the request.\nThis API doesn\u0026rsquo;t mandate checks on the validity of the given device in order not to introduce a dependency on the Device Registration API. However, implementations of this API may choose to perform such checks or impose a restriction on the overall amount of data that can be stored per tenant in order to protect against malicious requests.\nMessage Flow\n  Client unregisters the command consumer for a device   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to remove the consumer registration entry for a device in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to unregister-cmd-consumer.   adapter_instance_id yes application-properties string The identifier of the protocol adapter instance to remove the registration entry for. Only if this adapter instance is currently associated with the device or gateway identified by the device_id property, the registration entry will be removed.   device_id yes application-properties string MUST contain the ID of the device that is subject to the operation.    The body of the message SHOULD be empty and will be ignored if it is not.\nResponse Message Format\nA response to a unregister command consumer for device request contains the Standard Response Properties.\nThe response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     204 OK, the command consumer registration entry for the device has been removed.   400 Bad Request, the request message does not contain all required properties.   412 Precondition failed, the registration entry for the device has not been removed because there is no command consumer registration entry matching the adapter instance assigned to the device. This may happen if the mapping entry has already been removed or its lifespan has elapsed. The entry could also have been updated with a different adapter instance identifier before, which could for example mean the device lost its connection to the protocol adapter and has reconnected to a different adapter instance. The original adapter instance trying to remove the mapping entry at some point after that will result in a 412 error response because the instance identifier doesn\u0026rsquo;t match.    Implementors of this API may return a 404 status code in order to indicate that no device with the given identifier exists for the given tenant. However, performing such a check is optional.\nFor status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nSet last known Gateway for Device Clients use this command to set the gateway that last acted on behalf of a given device.\nThere are two variants of this command, one providing a single gateway and device identifier combination via request application-properties and one providing a map of multiple such combinations in the request payload.\nAs this operation is invoked frequently by Hono\u0026rsquo;s components, implementors may choose to keep this information in memory. This API doesn\u0026rsquo;t mandate checks on the validity of the given device or gateway IDs in order not to introduce a dependency on the Device Registration API. However, implementations of this API may choose to perform such checks or impose a restriction on the overall amount of data that can be stored per tenant in order to protect against malicious requests.\nMessage Flow\n  Client sets the last known gateway for a device   Request Message Format - Setting single entry\nThe following table provides an overview of the properties a client needs to set on a message to set the last known gateway for a device in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to set-last-gw.   device_id yes application-properties string MUST contain the ID of the device that is subject to the operation.   gateway_id yes application-properties string The identifier of the gateway that last acted on behalf of the device identified by the device_id property. For a device that connects to the adapter directly instead of through a gateway, the value of this property MUST be the same as the value of the device_id application property.    The body of the message SHOULD be empty and will be ignored if it is not.\nRequest Message Format - Setting multiple entries\nThe following table provides an overview of the properties a client needs to set on a message to set multiple last known gateway and device pairs in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to set-last-gw.    The body of the request MUST consist of a single Data section containing a UTF-8 encoded string representation of a single JSON object. The device identifiers are to be used as fields, the corresponding gateway identifiers as string values. Note that the number of entries supported in the object may be limited by the maximum message size negotiated between the service and the client. In such a case, a client may use multiple consecutive requests to overcome this limitation.\nExample payload for setting gateway-1 as last known gateway for the devices device-1 and device-2.\n{ \u0026#34;device-1\u0026#34;: \u0026#34;gateway-1\u0026#34;, \u0026#34;device-2\u0026#34;: \u0026#34;gateway-1\u0026#34; } Response Message Format\nA response to a set last known gateway for device request contains the Standard Response Properties.\nThe response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     204 OK, the update of the last known gateway(s) for the device(s) was successful.   400 Bad Request, the update of the last known gateway(s) for the device(s) failed due to invalid or missing data in the request.    Implementors of this API may return a 404 status code for the single entry operation in order to indicate that no device and/or gateway with the given identifier exists for the given tenant. However, performing such a check is optional.\nFor status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nEnable Command Routing A Protocol Adapter uses this operation to inform the Command Router service about the tenants that the devices belong to that are connected to the adapter and which have subscribed to commands.\nDuring normal operation, the Command Router is able to keep track of these tenants implicitly as part of the information provided in invocations of the register command consumer operation. Depending on the service\u0026rsquo;s implementation, this information might be lost after an unexpected restart. Protocol adapters will perceive such a case by means of a loss of their AMQP connection to the service. Once the connection has been re-established, an adapter can then use this operation to help the Command Router service recover and re-establish the downstream network links which are required to receive and forward commands.\nMessage Flow\n  Client submits tenant IDs to enable command routing for   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to enable command routing in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to enable-command-routing.    The body of the request MUST consist of a single Data section containing a UTF-8 encoded string representation of a single JSON array containing tenant identifiers. Note that the number of tenant identifiers supported in the array may be limited by the maximum message size negotiated between the service and the client. In such a case, a client may use multiple consecutive requests to overcome this limitation.\nThe following request payload may be used to re-enable command routing of tenants one, two and three:\n[ \u0026#34;one\u0026#34;, \u0026#34;two\u0026#34;, \u0026#34;three\u0026#34; ] Response Message Format\nA response to an enable command routing request contains the Standard Response Properties.\nThe response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     204 OK, the tenant identifiers have been accepted for processing. Note that this status code does not necessarily mean that command routing has already been enabled (again) for the given tenant identifiers. Implementors may also choose to accept the tenant identifiers and then (asynchronously) start to process them afterwards. In such a case, implementors are advised to implement adequate re-try logic for enabling command routing for each tenant identifier.   400 Bad Request, the body does not contain a valid JSON array of strings.    For status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nStandard Message Properties Due to the nature of the request/response message pattern of the operations of the Command Router API, there are some standard properties shared by all of the request and response messages exchanged as part of the operations.\nStandard Request Properties The following table provides an overview of the properties shared by all request messages regardless of the particular operation being invoked.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to the value defined by the particular operation being invoked.   correlation-id no properties message-id MAY contain an ID used to correlate a response message to the original request. If set, it is used as the correlation-id property in the response, otherwise the value of the message-id property is used. Either this or the message-id property MUST be set.   message-id no properties string MAY contain an identifier that uniquely identifies the message at the sender side. Either this or the correlation-id property MUST be set.   reply-to yes properties string MUST contain the source address that the client wants to received response messages from. This address MUST be the same as the source address used for establishing the client\u0026rsquo;s receive link (see Preconditions).    Standard Response Properties The following table provides an overview of the properties shared by all response messages regardless of the particular operation being invoked.\n   Name Mandatory Location AMQP Type Description     correlation-id yes properties message-id Contains the message-id (or the correlation-id, if specified) of the request message that this message is the response to.   status yes application-properties int Contains the status code indicating the outcome of the operation. Concrete values and their semantics are defined for each particular operation.   cache_control no application-properties string Contains an RFC 2616 compliant cache directive. The directive contained in the property MUST be obeyed by clients that are caching responses.    Delivery States Hono uses the following AMQP message delivery states when receiving request messages from clients:\n   Delivery State Description     ACCEPTED Indicates that the request message has been received and accepted for processing.   REJECTED Indicates that Hono has received the request but was not able to process it. The error field contains information regarding the reason why. Clients should not try to re-send the request using the same message properties in this case.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/device-connection/",
	"title": "Device Connection API Specification",
	"tags": [],
	"description": "",
	"content": "The Device Connection API is used by Protocol Adapters to set and retrieve information about the connections from devices or gateways to the protocol adapters.\n Deprecation The Device Connection API is deprecated and will be replaced by the Command Router API.  The Device Connection API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to the Device Connection service component using an AMQP 1.0 client in order to invoke operations of the API as described in the following sections.\n\nPreconditions for invoking the Device Connection API  Client has established an AMQP connection with the Device Connection service. Client has established an AMQP link in role sender on the connection using target address device_con/${tenant_id}. This link is used by the client to send commands concerning device connections to Hono. Client has established an AMQP link in role receiver on the connection using source address device_con/${tenant_id}/${reply-to} where reply-to may be any arbitrary string chosen by the client. This link is used by the client to receive responses to the requests it has sent to the Device Connection service. This link\u0026rsquo;s source address is also referred to as the reply-to address for the request messages.    Client connecting to Device Connection service   Set last known Gateway for Device Clients use this command to set the gateway that last acted on behalf of a given device.\nAs this operation is invoked frequently by Hono\u0026rsquo;s components, implementors may choose to keep this information in memory. This API doesn\u0026rsquo;t mandate checks on the validity of the given device or gateway IDs in order not to introduce a dependency on the Device Registration API. However, implementations of this API may choose to perform such checks or impose a restriction on the overall amount of data that can be stored per tenant in order to protect against malicious requests.\nMessage Flow\n  Client sets the last known gateway for a device   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to set the last known gateway for a device in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to set-last-gw.   gateway_id yes application-properties string The identifier of the gateway that last acted on behalf of the device identified by the device_id property. If a device connects directly instead of through a gateway, the device\u0026rsquo;s identifier MUST be specified here.    The body of the message SHOULD be empty and will be ignored if it is not.\nResponse Message Format\nA response to a set last known gateway for device request contains the Standard Response Properties.\nThe response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     204 OK, the last known gateway for the device has been updated.   400 Bad Request, the last known gateway has not been updated due to invalid or missing data in the request.    Implementors of this API may return a 404 status code in order to indicate that no device and/or gateway with the given identifier exists for the given tenant. However, performing such a check is optional.\nFor status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nGet last known Gateway for Device Clients use this command to retrieve the gateway that last acted on behalf of a given device.\nMessage Flow\n  Client retrieving the last known gateway for a device   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to retrieve the last known gateway for a device in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to get-last-gw.    The body of the message SHOULD be empty and will be ignored if it is not.\nResponse Message Format\nA response to a get last known gateway for device request contains the Standard Response Properties as well as the properties shown in the following table:\n   Name Mandatory Location AMQP Type Description     content-type no properties string MUST be set to application/json if the invocation of the operation was successful and the body of the response message contains payload as described below.    The result of a successful invocation is carried in a single Data section of the response message as a UTF-8 encoded string representation of a single JSON object. It is an error to include payload that is not of this type.\nThe response message JSON object has the following properties:\n   Name Mandatory JSON Type Description     gateway-id yes string The ID of the last known gateway for the device.   last-updated no string The date that the information about the last known gateway for the device was last updated. The value MUST be an ISO 8601 compliant combined date and time representation in extended format.    The response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     200 OK, the payload contains the gateway ID.   400 Bad Request, the request message does not contain all required information/properties.   404 Not Found, there is no last known gateway assigned to the device.    Implementors of this API may return a 404 status code in order to indicate that no device with the given identifier exists for the given tenant. However, performing such a check is optional.\nFor status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nSet command-handling protocol adapter instance for device Clients use this command to set the protocol adapter instance that currently handles command \u0026amp; control messages for a given device.\nClients can provide an optional lifespan parameter to make the protocol adapter instance entry expire after the given number of seconds. Note that implementations of this API have to support this feature, otherwise protocol adapters, as the clients of this API, might fail to correctly route command messages.\nThis API doesn\u0026rsquo;t mandate checks on the validity of the given device in order not to introduce a dependency on the Device Registration API. However, implementations of this API may choose to perform such checks or impose a restriction on the overall amount of data that can be stored per tenant in order to protect against malicious requests.\nMessage Flow\n  Client sets the command-handling protocol adapter instance for device   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to set the command-handling protocol adapter instance for a device in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to set-cmd-handling-adapter-instance.   adapter_instance_id yes application-properties string The identifier of the protocol adapter instance that currently handles commands for the device or gateway identified by the device_id property.   lifespan no application-properties int The lifespan of the mapping entry in seconds. After that period, the mapping entry shall be treated as non-existent by the Device Connection API methods. A negative value, as well as an omitted property, is interpreted as an unlimited lifespan.    The body of the message SHOULD be empty and will be ignored if it is not.\nResponse Message Format\nA response to a set command-handling adapter instance for device request contains the Standard Response Properties.\nThe response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     204 OK, the command-handling adapter instance for the device has been updated.   400 Bad Request, the adapter instance for the device has not been set or updated due to invalid or missing data in the request.    Implementors of this API may return a 404 status code in order to indicate that no device with the given identifier exists for the given tenant. However, performing such a check is optional.\nFor status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nRemove command-handling protocol adapter instance for device Clients use this command to remove the information, which protocol adapter instance is currently handling command \u0026amp; control messages for the given device. The mapping information is only removed, if the currently associated adapter instance matches the one given in the request.\nThis API doesn\u0026rsquo;t mandate checks on the validity of the given device in order not to introduce a dependency on the Device Registration API. However, implementations of this API may choose to perform such checks or impose a restriction on the overall amount of data that can be stored per tenant in order to protect against malicious requests.\nMessage Flow\n  Client removes the command-handling protocol adapter instance information for device   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to remove the mapping information regarding the command-handling protocol adapter instance for a device in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to remove-cmd-handling-adapter-instance.   adapter_instance_id yes application-properties string The identifier of the protocol adapter instance to remove the mapping information for. Only if this adapter instance is currently associated with the device or gateway identified by the device_id property, the mapping entry will be removed.    The body of the message SHOULD be empty and will be ignored if it is not.\nResponse Message Format\nA response to a remove command-handling adapter instance for device request contains the Standard Response Properties.\nThe response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     204 OK, the adapter instance mapping information for the device has been removed.   400 Bad Request, the request message does not contain all required properties.   412 Precondition failed, the adapter instance for the device has not been removed because there is no matching command-handling adapter instance assigned to the device.    Implementors of this API may return a 404 status code in order to indicate that no device with the given identifier exists for the given tenant. However, performing such a check is optional.\nFor status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nGet command-handling protocol adapter instances for device Clients use this command to get information about the adapter instances that can handle command \u0026amp; control messages for the given device.\nAs part of the request message, the client is supposed to provide the list of gateways that may act on behalf of the given device. The client may get this list via the Device Registration API\u0026rsquo;s assert Device Registration operation.\nThis API doesn\u0026rsquo;t mandate checks on the validity of the given device and the gateway list in order not to introduce a dependency on the Device Registration API.\nThe command implementation MUST determine the adapter instances by applying the following rules (in the given order):\n If an adapter instance is associated with the given device, this adapter instance is returned as the single returned list entry. Otherwise, if there is an adapter instance registered for the last known gateway associated with the given device, this adapter instance is returned as the single returned list entry. The last known gateway has to be contained in the given list of gateways for this case. Otherwise, all adapter instances associated with any of the given gateway identifiers are returned.  That means that for a device communicating via a gateway, the result is reduced to a single element list if an adapter instance for the device itself or its last known gateway is found. The adapter instance registered for the device itself is given precedence in order to ensure that a gateway having subscribed to commands for that particular device is chosen over a gateway that has subscribed to commands for all devices of a tenant.\nMessage Flow\n  Client retrieving the list of command-handling adapter instances for a device   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to retrieve the command-handling adapter instances for a device in addition to the Standard Request Properties.\n   Name Mandatory Location AMQP Type Description     content-type yes properties string MUST be set to application/json.   subject yes properties string MUST be set to get-cmd-handling-adapter-instances.    The body of the message MUST consist of a single AMQP Data section containing a UTF-8 encoded string representation of a single JSON object. The JSON object has the following properties:\n   Name Mandatory JSON Type Description     gateway-ids yes array The IDs of the gateways that may act on behalf of the given device. This list may be obtained via the Device Registration API\u0026rsquo;s assert Device Registration operation.    Example of a request payload:\n{ \u0026#34;gateway-ids\u0026#34;: [\u0026#34;gw-1\u0026#34;, \u0026#34;gw-2\u0026#34;, \u0026#34;gw-3\u0026#34;] } Response Message Format\nA response to a get command-handling adapter instances for device request contains the Standard Response Properties as well as the properties shown in the following table:\n   Name Mandatory Location AMQP Type Description     content-type no properties string MUST be set to application/json if the invocation of the operation was successful and the body of the response message contains payload as described below.    The result of a successful invocation is carried in a single Data section of the response message as a UTF-8 encoded string representation of a single JSON object. It is an error to include payload that is not of this type.\nThe response message JSON object has the following properties:\n   Name Mandatory JSON Type Description     adapter-instances yes array A non-empty array of JSON objects that represent the command-handling adapter instances along with the device or gateway id.    Each entry in the adapter-instances array has the following properties:\n   Name Mandatory JSON Type Description     adapter-instance-id yes string The ID of the protocol adapter instance handling command \u0026amp; control messages for the device given in the device-id property.   device-id yes string The ID of the gateway or device that the protocol adapter instance given by the adapter-instance-id is handling command \u0026amp; control messages for. This ID is not necessarily the device_id given in the request message, it may be the ID of one of the gateways acting on behalf of the device.    An example of a response message with a single adapter instance result, returned for example if an adapter instance is registered for the given device:\n{ \u0026#34;adapter-instances\u0026#34;: [ { \u0026#34;adapter-instance-id\u0026#34;: \u0026#34;adapter-1\u0026#34;, \u0026#34;device-id\u0026#34;: \u0026#34;4711\u0026#34; } ] } An example of a response message with multiple contained adapter instances, returned for example if no adapter instance is registered for the given device or its last used gateway, and therefore a list of all adapter instances for the gateways of the device is returned:\n{ \u0026#34;adapter-instances\u0026#34;: [ { \u0026#34;adapter-instance-id\u0026#34;: \u0026#34;adapter-1\u0026#34;, \u0026#34;device-id\u0026#34;: \u0026#34;gw-1\u0026#34; }, { \u0026#34;adapter-instance-id\u0026#34;: \u0026#34;adapter-1\u0026#34;, \u0026#34;device-id\u0026#34;: \u0026#34;gw-2\u0026#34; } ] } The response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     200 OK, the payload contains the adapter instances.   400 Bad Request, the request message does not contain all required information/properties.   404 Not Found, there is no command-handling adapter instance assigned to the device.    Implementors of this API may also return a 404 status code in order to indicate that no device with the given identifier exists for the given tenant. However, performing such a check is optional.\nFor status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred.\nStandard Message Properties Due to the nature of the request/response message pattern of the operations of the Device Connection API, there are some standard properties shared by all of the request and response messages exchanged as part of the operations.\nStandard Request Properties The following table provides an overview of the properties shared by all request messages regardless of the particular operation being invoked.\n   Name Mandatory Location AMQP Type Description     subject yes properties string MUST be set to the value defined by the particular operation being invoked.   correlation-id no properties message-id MAY contain an ID used to correlate a response message to the original request. If set, it is used as the correlation-id property in the response, otherwise the value of the message-id property is used. Either this or the message-id property MUST be set.   message-id no properties string MAY contain an identifier that uniquely identifies the message at the sender side. Either this or the correlation-id property MUST be set.   reply-to yes properties string MUST contain the source address that the client wants to received response messages from. This address MUST be the same as the source address used for establishing the client\u0026rsquo;s receive link (see Preconditions).   device_id yes application-properties string MUST contain the ID of the device that is subject to the operation.    Standard Response Properties The following table provides an overview of the properties shared by all response messages regardless of the particular operation being invoked.\n   Name Mandatory Location AMQP Type Description     correlation-id yes properties message-id Contains the message-id (or the correlation-id, if specified) of the request message that this message is the response to.   status yes application-properties int Contains the status code indicating the outcome of the operation. Concrete values and their semantics are defined for each particular operation.   cache_control no application-properties string Contains an RFC 2616 compliant cache directive. The directive contained in the property MUST be obeyed by clients that are caching responses.    Delivery States Hono uses the following AMQP message delivery states when receiving request messages from clients:\n   Delivery State Description     ACCEPTED Indicates that the request message has been received and accepted for processing.   REJECTED Indicates that Hono has received the request but was not able to process it. The error field contains information regarding the reason why. Clients should not try to re-send the request using the same message properties in this case.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/device-registration/",
	"title": "Device Registration API Specification",
	"tags": [],
	"description": "",
	"content": "The Device Registration API is used by Hono\u0026rsquo;s protocol adapters to get information about devices connecting to the adapters.\nThe Device Registration API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to Hono using an AMQP 1.0 client in order to invoke operations of the API as described in the following sections.\n\nPreconditions for invoking the Device Registration API  Client has established an AMQP connection with the Device Registration service. Client has established an AMQP link in role sender on the connection using target address registration/${tenant_id}. This link is used by the client to send request messages to the Device Registration service. Client has established an AMQP link in role receiver on the connection using source address registration/${tenant_id}/${reply-to} where reply-to may be any arbitrary string chosen by the client. This link is used by the client to receive responses to the requests it has sent to the Device Registration service. This link\u0026rsquo;s source address is also referred to as the reply-to address for the request messages.    Client connecting to Device Registration service   Assert Device Registration Clients use this command to verify that a device is registered for a particular tenant and is enabled.\nMessage Flow\nThe following sequence diagram illustrates the flow of messages involved in a Client asserting a device\u0026rsquo;s registration status.\n  Client asserting a device\u0026#39;s registration status   Request Message Format\nThe following table provides an overview of the properties a client needs to set on a message to assert a device\u0026rsquo;s registration status:\n   Name Mandatory Location AMQP Type Description     correlation-id no properties message-id MAY contain an ID used to correlate a response message to the original request. If set, it is used as the correlation-id property in the response, otherwise the value of the message-id property is used. Either this or the message-id property MUST be set.   device_id yes application-properties string MUST contain the ID of the device that is subject to the operation.   gateway_id no application-properties string The identifier of the gateway that wants to get an assertion on behalf of another device (given in the device_id property).\nAn implementation SHOULD verify that the gateway exists, is enabled and is authorized to get an assertion for, and thus send data on behalf of, the device.   message-id no properties string MAY contain an identifier that uniquely identifies the message at the sender side. Either this or the correlation-id property MUST be set.   reply-to yes properties string MUST contain the source address that the client wants to received response messages from. This address MUST be the same as the source address used for establishing the client\u0026rsquo;s receive link (see Preconditions).   subject yes properties string MUST be set to assert.    The body of the message SHOULD be empty and will be ignored if it is not.\nResponse Message Format\nThe following table provides an overview of the properties contained in a response message to an assert request:\n   Name Mandatory Location AMQP Type Description     correlation-id yes properties message-id Contains the message-id (or the correlation-id, if specified) of the request message that this message is the response to.   content-type no properties string MUST be set to application/json if the invocation of the operation was successful and the body of the response message contains payload as described below.   status yes application-properties int Contains the status code indicating the outcome of the operation. Concrete values and their semantics are defined below.   cache_control no application-properties string Contains an RFC 2616 compliant cache directive. The directive contained in the property MUST be obeyed by clients that are caching responses.    In case of a successful invocation of the operation, the body of the response message consists of a single Data section containing a UTF-8 encoded string representation of a single JSON object having the following properties:\n   Name Mandatory JSON Type Description     device-id yes string The ID of the device that is subject of the assertion.   via no array The IDs (JSON strings) of gateways which may act on behalf of the device. This property MUST be set if any gateways are registered for the device. If the assertion request contained a gateway_id property and the response\u0026rsquo;s status property has value 200 (indicating a successful assertion) then the array MUST at least contain the gateway ID from the request.   defaults no object Default values to be used by protocol adapters for augmenting messages from devices with missing information like a content type. It is up to the discretion of a protocol adapter if and how to use the given default values when processing messages published by the device.   mapper no string The name of a service that can be used to transform messages uploaded by the device before they are forwarded to downstream consumers. The client needs to map this name to the particular service to invoke.    Below is an example for a payload of a response to an assert request for device 4711 which also includes a default content-type and a mapper service:\n{ \u0026#34;device-id\u0026#34;: \u0026#34;4711\u0026#34;, \u0026#34;via\u0026#34;: [\u0026#34;4712\u0026#34;], \u0026#34;defaults\u0026#34;: { \u0026#34;content-type\u0026#34;: \u0026#34;application/vnd.acme+json\u0026#34; }, \u0026#34;mapper\u0026#34;: \u0026#34;my-payload-transformation\u0026#34; } The response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     200 OK, the device is registered for the given tenant and is enabled. The response message body contains the asserted device\u0026rsquo;s registration status.   400 Bad Request, the request message did not contain all mandatory properties.   403 Forbidden, the gateway with the given gateway id either does not exist, is not enabled or is not authorized to get an assertion for the device with the given device id.   404 Not Found, there is no device registered with the given device id within the given tenant id or the device is not enabled.    For status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred. In this case, the response message\u0026rsquo;s content-type property SHOULD be set accordingly.\nDelivery States The Device Registration service uses the following AMQP message delivery states when receiving request messages from clients:\n   Delivery State Description     ACCEPTED Indicates that the request message has been received and accepted for processing.   REJECTED Indicates that the request message has been received but cannot be processed. The disposition frame\u0026rsquo;s error field contains information regarding the reason why. Clients should not try to re-send the request using the same message properties in this case.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/credentials/",
	"title": "Credentials API Specification",
	"tags": [],
	"description": "",
	"content": "The Credentials API is used by Protocol Adapters to retrieve credentials used to authenticate Devices connecting to the adapter. In particular, the API supports to look up shared secrets which are often used by IoT devices by means of username/password based authentication schemes.\nCredentials are of a certain type which indicates which authentication mechanism the credentials can be used with. Each set of credentials also contains an authentication identity which is the identity claimed by the device during authentication. This authentication identity is usually different from the device-id the device has been registered under. A device may have multiple sets of credentials, using arbitrary authentication identities.\nThe Credentials API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to Hono using an AMQP 1.0 client in order to invoke operations of the API as described in the following sections.\n\nPreconditions for invoking the Credentials API  Client has established an AMQP connection with the Credentials service. Client has established an AMQP link in role sender on the connection using target address credentials/${tenant_id}. This link is used by the client to send commands to the Credentials service. Client has established an AMQP link in role receiver on the connection using source address credentials/${tenant_id}/${reply-to} where reply-to may be any arbitrary string chosen by the client. This link is used by the client to receive responses to the requests it has sent to the Credentials service. This link\u0026rsquo;s source address is also referred to as the reply-to address for the request messages.    Client connecting to Credentials service   Get Credentials Protocol adapters use this command to look up credentials of a particular type for a device identity.\nMessage Flow\n  Client looking up credentials for a device   Request Message Format\nThe following table provides an overview of the properties a client needs to set on an get credentials message.\n   Name Mandatory Location AMQP Type Description     correlation-id no properties message-id MAY contain an ID used to correlate a response message to the original request. If set, it is used as the correlation-id property in the response, otherwise the value of the message-id property is used. Either this or the message-id property MUST be set.   message-id no properties string MAY contain an identifier that uniquely identifies the message at the sender side. Either this or the correlation-id property MUST be set.   reply-to yes properties string MUST contain the source address that the client wants to receive response messages from. This address MUST be the same as the source address used for establishing the client\u0026rsquo;s receive link (see Preconditions).   subject yes properties string MUST contain the value get.    The body of the request MUST consist of a single Data section containing a UTF-8 encoded string representation of a single JSON object having the following members:\n   Name Mandatory JSON Type Description     type yes string The type of credentials to look up. Potential values include (but are not limited to) psk, x509-cert, hashed-password etc.   auth-id yes string The authentication identifier to look up credentials for.   client-certificate no string The client certificate the device authenticated with. If present, it MUST be the DER encoding of the (validated) X.509 client certificate as a Base64 encoded byte array and its subject DN MUST match the auth-id.    The client-certificate property MAY be used by the service implementation for auto-provisioning of devices. To do so, the device registry needs to create credentials (and registration data) for the device if they do not already exist.\nAdditionally, the body MAY contain arbitrary properties that service implementations can use to determine a device\u0026rsquo;s identity.\nThe following request payload may be used to look up the hashed password for a device with the authentication identifier sensor1:\n{ \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor1\u0026#34; } The following request payload may be used to look up or create x509-cert credentials for a device with the authentication identifier CN=device-1,O=ACME Corporation:\n{ \u0026#34;type\u0026#34;: \u0026#34;x509-cert\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;CN=device-1,O=ACME Corporation\u0026#34;, \u0026#34;client-certificate\u0026#34;: \u0026#34;DeviceCert==\u0026#34; } Response Message Format\nA response to a get credentials request contains the following properties:\n   Name Mandatory Location AMQP Type Description     correlation-id yes properties message-id Contains the message-id (or the correlation-id, if specified) of the request message that this message is the response to.   content-type no properties string MUST be set to application/json if the invocation of the operation was successful and the body of the response message contains payload as described below.   status yes application-properties int Contains the status code indicating the outcome of the operation. Concrete values and their semantics are defined below.   cache_control no application-properties string Contains an RFC 2616 compliant cache directive. The directive contained in the property MUST be obeyed by clients that are caching responses.    The response message payload MUST contain credential information as defined in Credentials Format if the status is 200 or 201.\nThe response message\u0026rsquo;s status property may contain the following codes:\n   Code Description     200 OK, the payload contains the credentials for the authentication identifier.   201 Created, the payload contains the newly created credentials for the authentication identifier.   400 Bad Request, the request message did not contain all mandatory properties or the subject DN of the certificate does not match the authentication identifier.   404 Not Found, there are no credentials registered matching the criteria.    For status codes indicating an error (codes in the 400 - 499 range) the message body MAY contain a detailed description of the error that occurred. In this case, the response message\u0026rsquo;s content-type property SHOULD be set accordingly.\nDelivery States The Credentials service uses the following AMQP message delivery states when receiving request messages from clients:\n   Delivery State Description     ACCEPTED Indicates that the request message has been received and accepted for processing.   REJECTED Indicates that the request message has been received but cannot be processed. The disposition frame\u0026rsquo;s error field contains information regarding the reason why. Clients should not try to re-send the request using the same message properties in this case.    Credentials Format Credential data is carried in the body of an AMQP message as part of a single Data section. The message\u0026rsquo;s content-type property must be set to application/json.\nThe credential data is contained in the Data section as a UTF-8 encoded string representation of a single JSON object. It is an error to include payload that is not of this type.\nThe table below provides an overview of the standard members defined for the JSON object:\n   Name Mandatory JSON Type Default Value Description     device-id yes string  The ID of the device to which the credentials belong.   type yes string  The credential type name. The value may be arbitrarily chosen by clients but SHOULD reflect the particular type of authentication mechanism the credentials are to be used with. Possible values include (but are not limited to) psk, x509-cert, hashed-password etc.   auth-id yes string  The identity that the device should be authenticated as.   enabled no boolean true If set to false the credentials are not supposed to be used to authenticate devices any longer. This may e.g. be used to disable a particular mechanism for authenticating the device. NB It is the responsibility of the protocol adapter to make use of this information.   secrets yes array  A list of secrets scoped to a particular time period. See Secrets Format for details. NB This array must contain at least one element - an empty array is considered an error.    For each set of credentials the combination of auth-id and type MUST be unique within a tenant.\nThe device registry may choose to not return information which is not suitable for authentication a device. This includes for example the enabled property. If set to false, then the device registry may choose to treat this request as if no credentials would be found. For secrets for example, this could mean that the device registry does not return secrets which are not valid at the current point in time.\nNB Care needs to be taken that the value for the authentication identifier is compliant with the authentication mechanism(s) it is supposed to be used with. For example, when using standard HTTP Basic authentication, the username part of the Basic Authorization header value (which corresponds to the auth-id) MUST not contain any colon (:) characters, because the colon character is used as the separator between username and password. Similar constraints may exist for other authentication mechanisms, so the authentication identifier needs to be chosen with the anticipated mechanism(s) being used in mind. Otherwise, devices may fail to authenticate with protocol adapters, even if the credentials provided by the device match the credentials registered for the device. In general, using only characters from the [a-zA-Z0-9_-] range for the authentication identifier should be compatible with most mechanisms.\nSecrets Format Each set of credentials may contain arbitrary secrets scoped to a particular validity period during which the secrets may be used for authenticating a device. The validity periods MAY overlap in order to support the process of changing a secret on a device that itself doesn\u0026rsquo;t support the definition of multiple secrets for gapless authentication across adjacent validity periods.\nThe table below contains the properties used to define the validity period of a single secret:\n   Name Mandatory JSON Type Default Value Description     not-before no string null The point in time from which on the secret may be used to authenticate devices. If not null, the value MUST be an ISO 8601 compliant combined date and time representation in extended format. NB It is up to the discretion of the protocol adapter to make use of this information.   not-after no string null The point in time until which the secret may be used to authenticate devices. If not null, the value MUST be an ISO 8601 compliant combined date and time representation in extended format. NB It is up to the discretion of the protocol adapter to make use of this information.    Examples Below is an example for a payload containing a hashed password for device 4711 with auth-id sensor1 using SHA512 as the hashing function with a 4 byte salt (Base64 encoding of 0x32AEF017). Note that the payload does not contain a not-before property, thus it may be used immediately up until X-mas eve 2017.\n{ \u0026#34;device-id\u0026#34;: \u0026#34;4711\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor1\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;secrets\u0026#34;: [{ \u0026#34;not-after\u0026#34;: \u0026#34;2017-12-24T19:00:00+0100\u0026#34;, \u0026#34;pwd-hash\u0026#34;: \u0026#34;AQIDBAUGBwg=\u0026#34;, \u0026#34;salt\u0026#34;: \u0026#34;Mq7wFw==\u0026#34;, \u0026#34;hash-function\u0026#34;: \u0026#34;sha-512\u0026#34; }] } The next example contains two pre-shared keys with overlapping validity periods for device myDevice with PSK identity little-sensor2.\n{ \u0026#34;device-id\u0026#34;: \u0026#34;myDevice\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;psk\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;little-sensor2\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;secrets\u0026#34;: [{ \u0026#34;not-after\u0026#34;: \u0026#34;2017-07-01T00:00:00+0100\u0026#34;, \u0026#34;key\u0026#34;: \u0026#34;cGFzc3dvcmRfb2xk\u0026#34; },{ \u0026#34;not-before\u0026#34;: \u0026#34;2017-06-29T00:00:00+0100\u0026#34;, \u0026#34;key\u0026#34;: \u0026#34;cGFzc3dvcmRfbmV3\u0026#34; }] } Credential Verification Protocol Adapters are responsible for authenticating devices when they connect. The Credentials API provides the Get Credentials operation to support Protocol Adapters in doing so as illustrated below:\nThe following sequence diagram illustrates the flow of messages involved in a Protocol Adapter authenticating a device. This is shown for the MQTT Protocol Adapter as example how a device authenticates with a username and a hashed-password. The mechanism can be transferred to other protocols in a similar manner.\n  MQTT Adapter authenticates device using the Credentials service   Protocol adapters MUST comply with the following rules when verifying credentials presented by a device:\n  Credentials that have their enabled property set to false MUST NOT be used for authentication.\n  Adapters MUST only consider secrets for authentication which\n have their not-before property set to either null or the current or a past point in time and have their not-after property set to either null or the current or a future point in time.    Standard Credential Types The following sections define some standard credential types and their properties. Applications are encouraged to make use of these types. However, the types are not enforced anywhere in Hono and clients may of course add application specific properties to the credential types.\nCommon Properties All credential types used with Hono MUST contain device-id, type, auth-id, enabled and secrets properties as defined in Credentials Format.\nHashed Password A credential type for storing a (hashed) password for a device.\nExample:\n{ \u0026#34;device-id\u0026#34;: \u0026#34;4711\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor1\u0026#34;, \u0026#34;secrets\u0026#34;: [{ \u0026#34;pwd-hash\u0026#34;: \u0026#34;AQIDBAUGBwg=\u0026#34;, \u0026#34;salt\u0026#34;: \u0026#34;Mq7wFw==\u0026#34;, \u0026#34;hash-function\u0026#34;: \u0026#34;sha-512\u0026#34; }] }    Name Mandatory JSON Type Default Description     type yes string  The credential type name, always hashed-password.   auth-id yes string  The identity that the device should be authenticated as.   pwd-hash yes string  The password hash (see table below for details).   salt no string  The Base64 encoding of the salt used in the password hash (see table below for details).   hash-function no string sha-256 The name of the hash function used to create the password hash. The hash functions supported by Hono are described in the table below.    NB It is strongly recommended to use salted password hashes only. Furthermore, the salt should be unique per user and password, so no lookup table or rainbow table attacks can be used to crack the salt-hashed password. Whenever a password is updated for a user, the salt should change as well.\nNB The example above does not contain any of the not-before, not-after and enabled properties, thus the credentials can be used at any time according to the rules defined in Credential Verification.\nThe table below describes the hash functions supported by Hono and how they map to the secret structure.\n   Name Salt Usage Salt Location Password Hash Format     sha-256 optional salt field The Base64 encoding of the bytes resulting from applying the sha-256 hash function to the byte array consisting of the salt bytes (if a salt is used) and the UTF-8 encoding of the clear text password.   sha-512 optional salt field The Base64 encoding of the bytes resulting from applying the sha-512 hash function to the byte array consisting of the salt bytes (if a salt is used) and the UTF-8 encoding of the clear text password.   bcrypt mandatory pwd-hash value The output of applying the Bcrypt hash function to the clear text password. The salt is contained in the password hash.\nNB Hono (currently) uses Spring Security for matching clear text passwords against Bcrypt hashes. However, this library only supports hashes containing the $2a$ prefix (see https://github.com/fpirsch/twin-bcrypt#about-prefixes) so Hono will fail to verify any passwords for which the corresponding Bcrypt hashes returned by the Credentials service contain e.g. the $2y$ prefix.    Pre-Shared Key A credential type for storing a Pre-shared Key as used in (D)TLS handshakes.\nExample:\n{ \u0026#34;device-id\u0026#34;: \u0026#34;4711\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;psk\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;little-sensor2\u0026#34;, \u0026#34;secrets\u0026#34;: [{ \u0026#34;key\u0026#34;: \u0026#34;AQIDBAUGBwg=\u0026#34; }] }    Name Mandatory JSON Type Description     type yes string The credential type name, always psk.   auth-id yes string The PSK identity.   key yes string The Base64 encoded bytes representing the shared (secret) key.    NB The example above does not contain any of the not-before, not-after and enabled properties, thus the credentials can be used at any time according to the rules defined in Credential Verification.\nX.509 Certificate A credential type for storing the RFC 2253 formatted subject DN of a client certificate that is used to authenticate the device as part of a (D)TLS handshake.\nExample:\n{ \u0026#34;device-id\u0026#34;: \u0026#34;4711\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;x509-cert\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;CN=device-1,O=ACME Corporation\u0026#34;, \u0026#34;secrets\u0026#34;: [{}] }    Name Mandatory JSON Type Description     type yes string The credential type name, always x509-cert.   auth-id yes string The subject DN of the client certificate in the format defined by RFC 2253.    NB The example above does not contain any of the not-before, not-after and enabled properties. The not-before and not-after properties should be omitted if the validity period is the same as the period indicated by the client certificate\u0026rsquo;s corresponding properties. It is still necessary to provide a (empty) JSON object in the secrets array, though.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/authentication/",
	"title": "Authentication API Specification",
	"tags": [],
	"description": "",
	"content": "The Authentication API is used to retrieve a token asserting a subject\u0026rsquo;s identity and granted authorities. Other service implementations use such a token to make authorization decisions on a client\u0026rsquo;s request to read or write from/to a resource or to invoke a certain operation.\nThe Authentication API is defined by means of AMQP 1.0 message exchanges, i.e. a client needs to connect to an Authentication service using an AMQP 1.0 client in order to invoke operations of the API as described in the following sections.\nNote that a component implementing this API will most likely need to also provide means to add, alter or remove identities and authorities as well. However, Hono itself does not require this kind of functionality, thus this kind of functionality is considered out of scope of this API.\nIn a real world environment there will often already be an identity management system in place. In such cases it can make sense to just implement a facade exposing the Authentication API operations and mapping them to the underlying existing system\u0026rsquo;s functionality.\nGet Token Clients use this operation to\n verify a set of credentials and retrieve a token asserting the authenticated subject\u0026rsquo;s identity and granted authorities.  Message Flow\nThe following sequence diagram illustrates the flow of messages involved in a Client retrieving a token.\n  Get Token message flow    The Client and Authentication service have agreed to use the SASL PLAIN mechanism for authenticating the client. The Client therefore sends the credentials of the identity it wants to retrieve a token for. The Authentication service successfully verifies the credentials and establishes the authorization ID.  The Authentication service completes the SASL exchange with a successful outcome (SASL OK).   The Client continues by opening an AMQP connection with the Authentication service. The Authentication service creates a token asserting the authorization ID and authorities established during the SASL exchange and associates it with the connection. The Client opens a receiving link using source address cbs.  The Authentication service opens the link and sends the token associated with the connection to the Client.   The Client closes the connection.  Token Message Format\nOn successful establishment of the receiving link with the client as described above, the server sends a message to the client containing a token asserting the identity and authorities of the client that has been authenticated as part of establishing the underlying AMQP connection.\nThe following table provides an overview of the properties of the message sent to the client.\n   Name Location Type Value     type application-properties string amqp:jwt    The message\u0026rsquo;s body consists of a single AMQP 1.0 AmqpValue section which contains the UTF-8 representation of a JSON Web Token as defined in Token Format.\nToken Format The token returned by the get Token operation is a cryptographically signed JSON Web Token as defined by RFC 7519.\nThe token contains the following mandatory claims:\n   Name Type Value     sub RFC 7519, Section 4.1.2 The authorization ID of the authenticated client. This represents the asserted identity.   exp RFC 7519, Section 4.1.4 The point in time after which the claims contained in this token must be considered no longer valid. Clients MUST NOT use any information from a token that has expired.    The subject\u0026rsquo;s authorities on resources and operations are represented by additional JWT claims with a name identifying the resource or operation and a value containing the activities the subject is allowed to perform. The following activities are supported:\n READ - The client is allowed to establish a receiving link using the resource\u0026rsquo;s node address as the link\u0026rsquo;s source address. WRITE - The client is allowed to establish a sending link using the resource\u0026rsquo;s node address as the link\u0026rsquo;s target address. EXECUTE - The client is allowed to invoke an operation on an endpoint, i.e. send a message over a link with a subject representing the operation name and the link\u0026rsquo;s target address representing the API endpoint\u0026rsquo;s node address.  The allowed activities are encoded in a claim\u0026rsquo;s value by means of simply concatenating the activities' initial characters (R, W, E).\nThe token may contain any number of additional claims which may be ignored by clients that do not understand their meaning.\nResource Authorities A client\u0026rsquo;s authority on a resource is represented by a JWT claim with a name containing the resource node address prefixed with r: and a value containing the activities the client is allowed to perform on the resource. The node address MAY contain one or more wildcard (*) characters to represent any string.\nExample:\nAssuming a client which is allowed to\n send and consume events for tenant my-tenant and consume telemetry data for all tenants  the corresponding claims (in the token\u0026rsquo;s JSON representation) would look like this:\n{ ... \u0026#34;r:event/my-tenant\u0026#34;: \u0026#34;RW\u0026#34;, \u0026#34;r:telemetry/*\u0026#34;: \u0026#34;R\u0026#34;, ... } Operation Authorities A client\u0026rsquo;s authority to invoke an endpoint\u0026rsquo;s operation(s) is represented by a JWT claim with a name containing the endpoint\u0026rsquo;s node address and operation identifier prefixed with o: and a value of E (for EXECUTE). The endpoint node address MAY contain one or more wildcard (*) characters to represent any string. The operation identifier is the subject value defined by the corresponding API for the operation. The operation identifier MAY be set to * to represent any operation of the endpoint.\nExample:\nAssuming a client which is allowed to\n invoke the Device Registration API\u0026rsquo;s assert Registration operation for any tenant and invoke all methods of the Credentials API for tenant my-tenant  the corresponding claims (in the token\u0026rsquo;s JSON representation) would look like this:\n{ ... \u0026#34;o:registration/*:assert\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;o:credentials/my-tenant:*\u0026#34;: \u0026#34;E\u0026#34;, ... } "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/management/",
	"title": "Device Registry Management API Specification",
	"tags": [],
	"description": "",
	"content": "  window.onload = function() { const TryItOutButtonWithHonoSandboxInfo = function() { return { wrapComponents: { TryItOutButton: (Original, { React }) = (props) = { return React.createElement(\"div\", {style: {\"font-size\": '14px'}}, React.createElement(Original, props), 'using the ', React.createElement('a', {href: 'https://www.eclipse.org/hono/sandbox/'}, \"Hono Sandbox\") ) } } } } const ui = SwaggerUIBundle({ url: \"device-registry-v1.yaml\", dom_id: '#swagger-ui', deepLinking: true, presets: [ SwaggerUIBundle.presets.apis, SwaggerUIStandalonePreset ], plugins: [ TryItOutButtonWithHonoSandboxInfo, SwaggerUIBundle.plugins.DownloadUrl ], supportedSubmitMethods: [], layout: \"StandaloneLayout\", docExpansion: \"none\", defaultModelRendering: \"model\", defaultModelExpandDepth: 0, defaultModelsExpandDepth: -1, validatorUrl: null }) window.ui = ui }  "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/api/metrics/",
	"title": "Metrics",
	"tags": [],
	"description": "",
	"content": "Eclipse Hono™\u0026rsquo;s components report several metrics which may be used to gain some insight into the running system. For instance, the HTTP adapter reports the number of successfully processed telemetry messages. Some of these metrics are considered part of Hono\u0026rsquo;s external interface. This section describes the semantics and format of the metrics, how they can be retrieved and how to interpret actual values.\nReported Metrics Hono uses Micrometer for collecting metrics. Those metrics can be exported to different back ends. Please refer to Configuring Metrics for details.\nThe container images published on Docker Hub have been compiled with support for Prometheus as the metrics back end.\nWhen deploying to Kubernetes/OpenShift, the metrics reported by Hono may contain environment specific tags (like the pod name) which are added by the Prometheus scraper. However, those tags are not part of the Hono metrics definition.\nHono applications may report other metrics in addition to the ones defined here. In particular, all components report metrics regarding the JVM\u0026rsquo;s internal state, e.g. memory consumption and garbage collection status. Those metrics are not considered part of Hono\u0026rsquo;s official metrics definition. However, all those metrics will still contain the common tags described below.\nCommon Metrics Tags for common metrics are:\n   Tag Value Description     host string The name of the host that the component reporting the metric is running on   component-type adapter, service The type of component reporting the metric   component-name string The name of the component reporting the metric.    The names of Hono\u0026rsquo;s standard components are as follows:\n   Component component-name     Auth Server hono-auth   Device Registry hono-registry   AMQP adapter hono-amqp   CoAP adapter hono-coap   HTTP adapter hono-http   Kura adapter hono-kura-mqtt   MQTT adapter hono-mqtt   Lora adapter hono-lora   Sigfox adapter hono-sigfox    Protocol Adapter Metrics Additional tags for protocol adapters are:\n   Name Value Description     direction one-way, request, response The direction in which a Command \u0026amp; Control message is being sent:\none-way indicates a command sent to a device for which the sending application doesn\u0026rsquo;t expect to receive a response.\nrequest indicates a command request message sent to a device.\nresponse indicates a command response received from a device.   qos 0, 1, unknown The quality of service used for a telemetry or event message.\n0 indicates at most once,\n1 indicates at least once and\nnone indicates unknown delivery semantics.   status forwarded, unprocessable, undeliverable The processing status of a message.\nforwarded indicates that the message has been forwarded to a downstream consumer\nunprocessable indicates that the message has not been processed not forwarded, e.g. because the message was malformed\nundeliverable indicates that the message could not be forwarded, e.g. because there is no downstream consumer or due to an infrastructure problem   tenant string The identifier of the tenant that the metric is being reported for   ttd command, expired, none A status indicating the outcome of processing a TTD value contained in a message received from a device.\ncommand indicates that a command for the device has been included in the response to the device\u0026rsquo;s request for uploading the message.\nexpired indicates that a response without a command has been sent to the device.\nnone indicates that either no TTD value has been specified by the device or that the protocol adapter does not support it.   type telemetry, event The type of (downstream) message that the metric is being reported for.    Additional tags for hono.connections.attempts:\n   Name Value Description     cipher-suite string The name of the cipher suite that is used for the device\u0026rsquo;s connection to the adapter. The specific value depends on the TLS implementation used by the protocol adapter.The value UNKNOWN is used if the connection does not use TLS or the cipher suite could not be determined, e.g. because the connection attempt failed before the cipher suite has been negotiated.   outcome adapter-disabled, connection-duration-exceeded,data-volume-exceeded, registration-assertion-failure,succeeded, tenant-connections-exceeded,unauthorized, unavailable, unknown The outcome of a device\u0026rsquo;s connection attempt.adapter-connections-exceeded indicates that the maximum number of connections that the adapter instance can handle are exceededadapter-disabled indicates that the protocol adapter is not enabled for the device\u0026rsquo;s tenantconnection-duration-exceeded indicates that the overall amount of time that a tenant\u0026rsquo;s devices may be connected to an adapter has exceededdata-volume-exceeded indicates that the overall amount of data that a tenant\u0026rsquo;s device may transfer per time period has exceededregistration-assertion-failure indicates that the device is either unknown or disabledsucceeded indicates a successfully established connectiontenant-connections-exceeded indicates that the maximum number of devices that may be connected simultaneously for a tenant has been exceededunauthorized indicates that the device failed to authenticateunavailable indicates that some of Hono\u0026rsquo;s (required) services are not availableunknown indicates an unknown reason.    Additional tags for hono.downstream.sent:\n   Name Value Description     outcome received, accepted, rejected, released, modified, declared, transactionalState, and aborted Any of the AMQP 1.0 disposition states, as well as aborted, in the case the connection/link was closed before the disposition could be read.    Metrics provided by the protocol adapters are:\n   Metric Type Tags Description     hono.commands.received Timer host, component-type, component-name, tenant, type, status, direction The time it took to process a message conveying a command or a response to a command.   hono.commands.payload DistributionSummary host, component-type, component-name, tenant, type, status, direction The number of bytes conveyed in the payload of a command message.   hono.connections.authenticated Gauge host, component-type, component-name, tenant Current number of connected, authenticated devices.  NB This metric is only supported by protocol adapters that maintain connection state with authenticated devices. In particular, the HTTP adapter does not support this metric.   hono.connections.unauthenticated Gauge host, component-type, component-name Current number of connected, unauthenticated devices.  NB This metric is only supported by protocol adapters that maintain connection state with authenticated devices. In particular, the HTTP adapter does not support this metric.   hono.connections.authenticated.duration Timer host, component-type, component-name, tenant The overall amount of time that authenticated devices have been connected to protocol adapters.  NB This metric is only supported by protocol adapters that maintain connection state with authenticated devices. In particular, the HTTP adapter does not support this metric.   hono.connections.attempts Counter host, component-type, component-name, tenant, outcome, cipher-suite The number of attempts made by devices to connect to a protocol adapter. The outcome tag\u0026rsquo;s value determines if the attempt was successful or not. In the latter case the outcome also indicates the reason for the failure to connect.NB This metric is only supported by protocol adapters that maintain connection state with authenticated devices. In particular, the HTTP adapter does not support this metric.   hono.downstream.full Counter host, component-type, component-name, tenant, type The number of times a message should be sent, but could not because the sender was out of credit.   hono.downstream.sent Timer host, component-type, component-name, tenant, type, outcome The time it took to send a message and receive the remote peers disposition.   hono.downstream.timeout Counter host, component-type, component-name, tenant, type The number of times a message timed out, meaning that no disposition was received in the appropriate amount of time.   hono.messages.received Timer host, component-type, component-name, tenant, type, status, qos, ttd The time it took to process a message conveying telemetry data or an event.   hono.messages.payload DistributionSummary host, component-type, component-name, tenant, type, status The number of bytes conveyed in the payload of a telemetry or event message.    Minimum Message Size If a minimum message size is configured for a tenant, then the payload size of the telemetry, event and command messages are calculated in accordance with the configured value and then reported to the metrics by the AMQP, HTTP and MQTT protocol adapters. If minimum message size is not configured for a tenant then the actual message payload size is reported.\nAssume that the minimum message size for a tenant is configured as 4096 bytes (4KB). The payload size of an incoming message with size 1KB is calculated as 4KB by the protocol adapters and reported to the metrics system. For an incoming message of size 10KB, it is reported as 12KB.\nService Metrics Hono\u0026rsquo;s service components do not report any metrics at the moment.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/deployment/",
	"title": "Deployment",
	"tags": [],
	"description": "",
	"content": "Deployment Learn how to deploy Eclipse Hono™ to various container orchestration platforms.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/deployment/helm-based-deployment/",
	"title": "Helm based Deployment",
	"tags": [],
	"description": "",
	"content": "Eclipse Hono™\u0026rsquo;s components are provided as container images which can be run on arbitrary container orchestration platforms. This page describes the steps necessary to deploy Hono to a Kubernetes cluster using the Helm package manager.\nInstalling Hono Hono\u0026rsquo;s Helm chart is available from the Eclipse IoT Packages chart repository. Please refer to the chart\u0026rsquo;s README for instructions regarding installation and configuration.\nDeploying custom Container Images The chart by default installs Hono\u0026rsquo;s pre-built container images. In some cases it might be desirable to build Hono from source, e.g. in order to use a different metrics back end or to use Jaeger tracing.\nThe container images created as part of the build process need to be made available to the Kubernetes cluster that Hono should be installed to. This usually requires the images to be pushed to a (private) container registry that the cluster can pull them from. Please refer to the documentation of the employed Kubernetes service provider for details regarding the setup and configuration of a private container registry.\nDeploying via a private Registry The first step is getting the source code of Hono. Please refer to Building from Source for details. Once the source code has been retrieved, the build process can be started using the following command:\n# in base directory of Hono working tree: mvn clean install -Pbuild-docker-image,metrics-prometheus,jaeger After the build process has finished, the custom container images need to be pushed to the registry so that the Kubernetes cluster can pull them from there during deployment. Assuming that the images should be tagged with 1.0.3-CUSTOM and the container registry name is my.registry.io, the following command can be used to tag the locally built images and push them to the registry:\n# in base directory of Hono working tree: ./push_hono_images.sh 1.0.3-CUSTOM my.registry.io  Note You may need to log in to the (private) container registry before pushing the images.  The image names that Hono should use for starting up containers can be configured in a YAML file:\ndeviceRegistryExample: imageName: \u0026#34;my.registry.io/eclipse/hono-service-device-registry-file:1.0.3-CUSTOM\u0026#34; authServer: imageName: \u0026#34;my.registry.io/eclipse/hono-service-auth:1.0.3-CUSTOM\u0026#34; deviceConnectionService: imageName: \u0026#34;my.registry.io/eclipse/hono-service-device-connection:1.0.3-CUSTOM\u0026#34; adapters: amqp: imageName: \u0026#34;my.registry.io/eclipse/hono-adapter-amqp-vertx:1.0.3-CUSTOM\u0026#34; mqtt: imageName: \u0026#34;my.registry.io/eclipse/hono-adapter-mqtt-vertx:1.0.3-CUSTOM\u0026#34; http: imageName: \u0026#34;my.registry.io/eclipse/hono-adapter-http-vertx:1.0.3-CUSTOM\u0026#34; Assuming that the YAML file is called imageNames.yaml, installation can then be done using:\nhelm install --dependency-update -n hono -f imageNames.yaml eclipse-hono eclipse-iot/hono Deploying to Minikube When using Minikube as the deployment target, things are a little easier. Minikube comes with an embedded Docker daemon which can be used to build the container images instead of using a local Docker daemon, thus eliminating the need to push the images to a registry altogether. In order to use Minikube\u0026rsquo;s Docker daemon, the following command needs to be run:\neval $(minikube docker-env) This will set the Docker environment variables to point to Minikube\u0026rsquo;s Docker daemon which can then be used for building the container images and storing them locally in the Minikube VM.\nIn any case the build process can be started using the following command:\n# in base directory of Hono working tree: mvn clean install -Pbuild-docker-image,metrics-prometheus,jaeger To obtain the used Hono version and write it in a variable, use:\n# in base directory of Hono working tree: HONO_VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout) The newly built images can then be deployed using Helm:\nhelm install --dependency-update -n hono --set honoImagesTag=$HONO_VERSION eclipse-hono eclipse-iot/hono Using Jaeger Tracing Hono\u0026rsquo;s components are instrumented using OpenTracing to allow tracking of the distributed processing of messages flowing through the system. The Hono chart can be configured to report tracing information to the Jaeger tracing system. The Spans reported by the components can then be viewed in a web browser.\nIn order for Hono\u0026rsquo;s components to use the Jaeger client for reporting tracing information, the container images need to be built with the jaeger Maven profile. Please refer to Monitoring \u0026amp; Tracing for details. The newly built images also need to be made available to the target Kubernetes cluster as described in the two previous sections.\nThe chart can be configured to deploy and use an example Jaeger back end by means of setting the jaegerBackendExample.enabled property to true when running Helm:\nhelm install --dependency-update -n hono --set jaegerBackendExample.enabled=true eclipse-hono eclipse-iot/hono This will create a Jaeger back end instance suitable for testing purposes and will configure all deployed Hono components to use the Jaeger back end.\nThe following command can then be used to return the IP address with which the Jaeger UI can be accessed in a browser (ensure minikube tunnel is running when using minikube):\nkubectl get service eclipse-hono-jaeger-query --output=\u0026#34;jsonpath={.status.loadBalancer.ingress[0][\u0026#39;hostname\u0026#39;,\u0026#39;ip\u0026#39;]}\u0026#34; -n hono If no example Jaeger back end should be deployed but instead an existing Jaeger installation should be used, the chart\u0026rsquo;s jaegerAgentConf property can be set to environment variables which are passed in to the Jaeger Agent that is deployed with each of Hono\u0026rsquo;s components.\nhelm install --dependency-update -n hono --set jaegerAgentConf.REPORTER_TYPE=tchannel --set jaegerAgentConf.REPORTER_TCHANNEL_HOST_PORT=my-jaeger-collector:14267 eclipse-hono eclipse-iot/hono Deploying to Azure Kubernetes Service (AKS) The following chapter describes how to use Azure Kubernetes Service (AKS) as a deployment target that has been set up as described in the Setting up a Kubernetes Cluster guide.\nFirst we build the docker images and push them into the ACR. Note that if you define a custom image tag you have to provide the helm with the image tags as described in the chapters above.\n# Resource group where the ACR is deployed. acr_resourcegroupname={YOUR_ACR_RG} # Name of your ACR. acr_registry_name={YOUR_ACR_NAME} # Full name of the ACR. acr_login_server=$acr_registry_name.azurecr.io # Authenticate your docker daemon with the ACR. az acr login --name $ACR_NAME # Build images. cd hono mvn install -Pbuild-docker-image -Ddocker.registry=$acr_login_server # Push images to ACR. ./push_hono_images.sh 1.0.0-SNAPSHOT $acr_login_server Now we can retrieve settings from the deployment for the following steps:\n# Resource group of the AKS deployment resourcegroup_name=hono aks_cluster_name=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.aksClusterName.value -o tsv` http_ip_address=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.httpPublicIPAddress.value -o tsv` amqp_ip_address=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.amqpPublicIPAddress.value -o tsv` mqtt_ip_address=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.mqttPublicIPAddress.value -o tsv` registry_ip_address=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.registryPublicIPAddress.value -o tsv` network_ip_address=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.networkPublicIPAddress.value -o tsv` Note: add the following lines in case you opted for the Azure Service Bus variant:\nservice_bus_namespace=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.serviceBusNamespaceName.value -o tsv` service_bus_key_name=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.serviceBusKeyName.value -o tsv` service_bus_key=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.serviceBusKey.value -o tsv` Next we prepare the k8s environment:\nk8s_namespace=honons kubectl create namespace $k8s_namespace Finally install Hono. Leveraging the managed-premium-retain storage in combination with deviceRegistry.resetFiles=false parameter is optional but ensures that Device registry storage will retain future update deployments.\n# in Hono working tree directory: hono/deploy helm install target/deploy/helm/eclipse-hono/ \\  --dep-up \\  --name hono \\  --namespace $k8s_namespace \\  --set adapters.mqtt.svc.annotations.\u0026#34;service\\.beta\\.kubernetes\\.io/azure-load-balancer-resource-group\u0026#34;=$resourcegroup_name \\  --set adapters.http.svc.annotations.\u0026#34;service\\.beta\\.kubernetes\\.io/azure-load-balancer-resource-group\u0026#34;=$resourcegroup_name \\  --set adapters.amqp.svc.annotations.\u0026#34;service\\.beta\\.kubernetes\\.io/azure-load-balancer-resource-group\u0026#34;=$resourcegroup_name \\  --set deviceRegistryExample.svc.annotations.\u0026#34;service\\.beta\\.kubernetes\\.io/azure-load-balancer-resource-group\u0026#34;=$resourcegroup_name \\  --set amqpMessagingNetworkExample.dispatchRouter.svc.annotations.\u0026#34;service\\.beta\\.kubernetes\\.io/azure-load-balancer-resource-group\u0026#34;=$resourcegroup_name \\  --set deviceRegistryExample.storageClass=managed-premium-retain \\  --set deviceRegistryExample.resetFiles=false \\  --set adapters.mqtt.svc.loadBalancerIP=$mqtt_ip_address \\  --set adapters.http.svc.loadBalancerIP=$http_ip_address \\  --set adapters.amqp.svc.loadBalancerIP=$amqp_ip_address \\  --set deviceRegistryExample.svc.loadBalancerIP=$registry_ip_address \\  --set amqpMessagingNetworkExample.dispatchRouter.svc.loadBalancerIP=$network_ip_address Note: add the following lines in case you opted for the Azure Service Bus variant:\n# Router update required to work together with Azure Service Bus --set amqpMessagingNetworkExample.dispatchRouter.imageName=quay.io/enmasse/qdrouterd-base:1.8.0 \\  --set amqpMessagingNetworkExample.broker.type=servicebus \\  --set amqpMessagingNetworkExample.broker.servicebus.saslUsername=$service_bus_key_name \\  --set amqpMessagingNetworkExample.broker.servicebus.saslPassword=$service_bus_key \\  --set amqpMessagingNetworkExample.broker.servicebus.host=$service_bus_namespace.servicebus.windows.net \\ Have fun with Hono on Microsoft Azure!\nNext steps:\nYou can follow the steps as described in the Getting Started guide with the following differences:\nCompared to a plain k8s deployment Azure provides us DNS names with static IPs for the Hono endpoints. To retrieve them:\nHTTP_ADAPTER_IP=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.httpPublicIPFQDN.value -o tsv` AMQP_ADAPTER_IP=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.amqpPublicIPFQDN.value -o tsv` MQTT_ADAPTER_IP=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.mqttPublicIPFQDN.value -o tsv` REGISTRY_IP=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.registryPublicIPFQDN.value -o tsv` AMQP_NETWORK_IP=`az group deployment show --name HonoBasicInfrastructure --resource-group $resourcegroup_name --query properties.outputs.networkPublicIPFQDN.value -o tsv` As Azure Service Bus does not support auto creation of queues you have to create a queue per tenant (ID), e.g. after you have created your tenant run:\naz servicebus queue create --resource-group $resourcegroup_name \\  --namespace-name $service_bus_namespace \\  --name $MY_TENANT "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/deployment/openshift/",
	"title": "OpenShift / OKD",
	"tags": [],
	"description": "",
	"content": "In Hono version 1.0 we dropped the OpenShift specific deployment using the source-to-image (S2I) model, in favor of the Helm charts and the Eclipse IoT Packages project.\nYou can still deploy to OpenShift and OKD, using the Helm charts. And you can also use routes to expose services. Deploying using S2I is also still possible, however the Hono project simply no longer provides out-of-the box scripts for doing so.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/deployment/create-kubernetes-cluster/",
	"title": "Setting up a Kubernetes Cluster",
	"tags": [],
	"description": "",
	"content": "This guide describes how to set up a Kubernetes cluster which can be used to run Eclipse Hono™.\nHono can be deployed to any Kubernetes cluster running version 1.11 or newer. This includes OpenShift (Origin) which is built on top of Kubernetes.\nThe Kubernetes web site provides instructions for setting up a (local) cluster on bare metal and/or virtual infrastructure from scratch or for provisioning a managed Kubernetes cluster from one of the popular cloud providers.\n\nSetting up a local Development Environment The easiest option is to set up a single-node cluster running on a local VM using the Minikube project. This kind of setup is sufficient for evaluation and development purposes. Please refer to Minikube\u0026rsquo;s getting started guide for instructions on how to set up a cluster locally.\nThe recommended settings for a Minikube VM used for running Hono\u0026rsquo;s example setup are as follows:\n cpus: 2 memory: 8192 (MB)  The command to start the VM will look something like this:\nminikube start --cpus 2 --memory 8192 After the Minikube VM has started successfully, the minikube tunnel command should be run in order to support Hono\u0026rsquo;s services being deployed using the LoadBalancer type. Please refer to the Minikube Loadbalancer docs for details.\n Setting Kubernetes Version Minikube will use the most recent Kubernetes version that was available when it has been compiled by default. Hono should run on any version of Kubernetes starting with 1.13.6. However, it has been tested with several specific versions only. The most recent version known to work is 1.15.4 so if you experience any issues with running Hono on another version, please try to deploy to 1.15.4 before raising an issue. You can use Minikube\u0026rsquo;s --kubernetes-version command line switch to set a particular version.  Setting up a Production Environment Setting up a multi-node Kubernetes cluster is a more advanced topic. Please follow the corresponding links provided in the Kubernetes documentation.\nSetting up an Environment on Microsoft Azure This chapter describes how Hono can be deployed on Microsoft Azure. It includes:\n Azure Resource Manager (ARM) templates for an automated infrastructure deployment. Helm based deployment of Hono to Azure Kubernetes Service (AKS). Push Hono docker images to an Azure Container Registry (ACR). Optional Azure Service Bus as broker for the Hono AMQP 1.0 Messaging Network instead of a self hosted ActiveMQ Artemis. Virtual Network (VNet) service endpoints ensure protected communication between AKS and Azure Service Bus.   Use for demos only This deployment model is not meant for productive use but rather for evaluation as well as demonstration purposes or as a baseline to evolve a production grade Application architecture out of it which includes Hono.  Prerequisites  An Azure subscription. Azure CLI installed to setup the infrastructure. kubectl and helm installed to deploy Hono into Azure Kubernetes Service (AKS)  Setup As described here we will create an explicit service principal. Later we add roles to this principal to access the Azure Container Registry (ACR).\n# Create service principal service_principal=`az ad sp create-for-rbac --name http://honoServicePrincipal --skip-assignment --output tsv` app_id_principal=`echo $service_principal | cut -f1 -d \u0026#39; \u0026#39;` password_principal=`echo $service_principal | cut -f4 -d \u0026#39; \u0026#39;` object_id_principal=`az ad sp show --id $app_id_principal --query objectId --output tsv` Note: it might take a few seconds until the principal is available for the next steps.\nNow we create the Azure Container Registry instance and provide read access to the service principal.\n# Resource group where the ACR is deployed. acr_resourcegroupname={YOUR_ACR_RG} # Name of your ACR. acr_registry_name={YOUR_ACR_NAME} # Full name of the ACR. acr_login_server=$acr_registry_name.azurecr.io az acr create --resource-group $acr_resourcegroupname --name $acr_registry-name --sku Basic acr_id_access_registry=`az acr show --resource-group $acr_resourcegroupname --name $acr_registry_name --query \u0026#34;id\u0026#34; --output tsv` az role assignment create --assignee $app_id_principal --scope $acr_id_access_registry --role Reader With the next command we will use the provided Azure Resource Manager (ARM) templates to setup the AKS cluster. This might take a while.\nresourcegroup_name=hono az group create --name $resourcegroup_name --location \u0026#34;westeurope\u0026#34; unique_solution_prefix=myprefix cd deploy/src/main/deploy/azure/ az group deployment create --name HonoBasicInfrastructure --resource-group $resourcegroup_name --template-file arm/honoInfrastructureDeployment.json --parameters uniqueSolutionPrefix=$unique_solution_prefix servicePrincipalObjectId=$object_id_principal servicePrincipalClientId=$app_id_principal servicePrincipalClientSecret=$password_principal Notes:\n add the following parameter in case you want to opt for the Azure Service Bus as broker in the Hono AMQP 1.0 Messaging Network instead of deploying a (self-hosted) ActiveMQ Artemis into AKS: serviceBus=true add the following parameter to define the k8s version of the AKS cluster. The default as defined in the template might not be supported in your target Azure region, e.g. kubernetesVersion=1.14.6  After the deployment is complete you can set your cluster in kubectl.\naz aks get-credentials --resource-group $resourcegroup_name --name $aks_cluster_name Next create retain storage for the device registry.\nkubectl apply -f managed-premium-retain.yaml Now Hono can be installed to the AKS cluster as describe in the Helm based installation guide.\nMonitoring You can monitor your cluster using Azure Monitor for containers.\nNavigate to https://portal.azure.com -\u0026gt; your resource group -\u0026gt; your kubernetes cluster\nOn an overview tab you fill find an information about your cluster (status, location, version, etc.). Also, here you will find a Monitor Containers link. Navigate to Monitor Containers and explore metrics and statuses of your Cluster, Nodes, Controllers and Containers.\nCleaning up Use the following command to delete all created resources once they are no longer needed:\naz group delete --name $resourcegroup_name --yes --no-wait "
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/deployment/resource-limitation/",
	"title": "Limiting Resource Usage",
	"tags": [],
	"description": "",
	"content": "Deploying Eclipse Hono™ to a container orchestration platform is easy thanks to the provided Docker images. This page provides some guidance for configuring the resource consumption of these containers in order to make sure that they get enough memory and CPU to run properly, but to also make sure that individual containers do not use up all the resources causing other containers to starve.\nDocker itself provides means to limit a container\u0026rsquo;s consumption of memory and CPU resources by means of command line options that can be set when starting up a container. Both Kubernetes and OpenShift leverage this mechanism when defining resource limits of a pod. Please refer to the corresponding documentation of Docker, Kubernetes and OpenShift for details regarding the particular syntax to be used.\nJava\u0026rsquo;s View of the World Hono\u0026rsquo;s service components are implemented in Java. When the corresponding Docker container for such a service is started, the only process being run inside the container is therefore a Java virtual machine (JVM). On startup, the JVM tries to determine the amount of memory and the number of CPU cores that it can use to execute workloads. By default the JVM queries the operating system for the corresponding parameters and adjusts its runtime parameters accordingly, e.g. it will by default limit the size of its heap memory to a quarter of the total memory available in order to leave enough memory for other processes running on the same system.\nThis is a reasonable approach when running on bare metal or a VM where other processes are expected to be running on the same machine, thus competing for the same computing resources. However, containers are usually configured to run a single process only so that it makes more sense to dedicate almost all of the available resources to running that process, leaving the (small) rest for the operating system itself.\nAs described above, a Docker container can easily be configured with a limit for memory and CPU resources that it may use during runtime. These limits are set and enforced using Linux CGroups.\nLimiting a Component\u0026rsquo;s Memory Consumption Starting with Java 9, the JVM will correctly determine the total memory and number of CPUs available when running inside of a container. All of the Docker images provided by Hono run with OpenJDK 11 by default, thus ensuring that the JVM considers any memory limits configured for the container when configuring its heap during startup. However, the default algorithm will still only allocate a quarter of the (limited) amount of memory, thus leaving a lot of memory available to the container unused.\nThe following JVM options can be used in Java 9 and later in order to change this behavior:\n -XX:MinRAMPercentage, -XX:MaxRAMPercentage and -XX:InitialRAMPercentage can be used to set the (minimum, maximum and initial) percentage of total memory that may be allocated for the heap. A value of 70-80% should work if no other processes are running in the same container.  Kubernetes In Kubernetes (and OpenShift) the resource limits for a pod, and thus the container(s) that are part of the pod, can be configured in the corresponding PodSpec. The following example from the HTTP adapter\u0026rsquo;s Kubernetes Deployment resource descriptor illustrates the mechanism:\napiVersion: apps/v1beta1 kind: Deployment metadata: name: hono-adapter-http-vertx spec: template: metadata: labels: app: hono-adapter-http-vertx version: \u0026#34;${project.version}\u0026#34; group: ${project.groupId} spec: containers: - image: eclipse/hono-adapter-http-vertx:${project.version} name: eclipse-hono-adapter-http-vertx resources: limits: memory: \u0026#34;256Mi\u0026#34; ports: - containerPort: 8080 protocol: TCP env: - name: SPRING_CONFIG_LOCATION value: file:///etc/hono/ - name: SPRING_PROFILES_ACTIVE value: dev - name: LOGGING_CONFIG value: classpath:logback-spring.xml - name: _JAVA_OPTIONS value: \u0026#34;-XX:MinRAMPercentage=80 -XX:MaxRAMPercentage=80\u0026#34; volumeMounts: - mountPath: /etc/hono name: conf readOnly: true volumes: - name: conf secret: secretName: hono-adapter-http-vertx-conf The resources property defines the overall limit of 256 MB of memory that the pod may use. The _JAVA_OPTIONS environment variable is again used to configure the JVM to use 80% of the total memory for its heap.\nLimiting the Number of Device Connections Hono supports limiting the overall number of simultaneously connected devices per tenant. Please refer to the connections limit concept for more information. The limit needs to be configured at the tenant level using the resource-limits configuration property. Please refer to the Tenant API for configuration details.\nLimiting the Overall Connection Time Hono supports configuring limits based on the overall amount of time that the devices have already been connected to protocol adapters for a tenant. Please refer to the connection duration limit for more information. Before accepting any connection requests from the devices, the protocol adapters verify that the configured connection duration limit is not exceeded. If the limit has been already reached, then the connection request is rejected. The limit needs to be configured at the tenant level using the resource-limits configuration property. Please refer to the Tenant API for configuration details.\nLimiting the Data Volume Hono supports limiting the amount of data that devices of a tenant can publish to Hono during a given time interval. Please refer to the messages limit concept for more information. The limit needs to be configured at the tenant level using the resource-limits configuration property. Please refer to the Tenant API for configuration details.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/architecture/",
	"title": "Architecture",
	"tags": [],
	"description": "",
	"content": "Architecture Get an overview of the architecture of Eclipse Hono™.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/architecture/component-view/",
	"title": "Component View",
	"tags": [],
	"description": "",
	"content": "This page describes the high level components constituting an Eclipse Hono™ instance and their relations to each other.\nTop Level The diagram below provides an overview of the top level logical components.\n  The MQTT and HTTP Adapters use the Device Registry to authenticate Devices connecting to the adapters and asserting their registration status. The adapters then forward the telemetry data and events received from the devices to the AMQP 1.0 Messaging Network for delivery to Business Applications. Business applications also use the messaging network to send commands to connected devices. Commands are first received by the Command Router and then forwarded to the protocol adapter that is connected to the respective devices.\nThe Device Registry and the Command Router use the Auth Server to authenticate the protocol adapters during connection establishment.\nAll interactions between the components are based on AMQP 1.0 message exchanges as defined by the\n Credentials API, Tenant API, Device Registration API, Command Router API, Command \u0026amp; Control API, Telemetry API and Event API.  Device Registry The diagram below provides an overview of the Device Registry component\u0026rsquo;s internal structure.\n  The Device Registry component implements the Credentials API, Tenant API and Device Registration API. Clients opening a connection to the DeviceRegistryServer are authenticated by means of an external service accessed via the Auth port.\nHono provides the following Device Registry implementations:\n MongoDB Based Device Registry JDBC Based Device Registry File Based Device Registry  Command Router The diagram below provides an overview of the Command Router component\u0026rsquo;s internal structure.\n  The Command Router component implements the Command Router API. Clients opening a connection to the CommandRouterServer are authenticated by means of an external service accessed via the Auth port.\nThe Command Router component uses the Device Registry via the Tenant API and the Device Registration API and is connected to the AMQP 1.0 Messaging Network to receive and forward Command \u0026amp; Control messages as defined by the Command \u0026amp; Control API.\nAMQP 1.0 Messaging Network The AMQP 1.0 Messaging Network is not per se a component being developed as part of Hono. Instead, Hono comes with a default implementation of the messaging network relying on artifacts provided by other open source projects. The default implementation currently consists of a single Apache Qpid Dispatch Router instance connected to a single Apache Artemis broker instance. Note that this setup is useful for development purposes but will probably not meet requirements regarding e.g. scalability of real world use cases.\nThe diagram below provides an overview of the default implementation of the Messaging Network component used with Hono.\n  Scaling out messaging infrastructure is a not a trivial task. Hono does not provide an out-of-the-box solution to this problem but instead integrates with the EnMasse project which aims at providing Messaging as a Service infrastructure.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/architecture/auth/",
	"title": "Authentication/Authorization",
	"tags": [],
	"description": "",
	"content": "This page describes how authentication and authorization of devices, consumers (back end applications) and system components works in Hono.\nRequirements  Devices are authenticated and authorized when they connect to a protocol adapter. Consumers are authenticated and authorized when they connect to a Dispatch Router instance. System components are authenticated and authorized when they connect to each other. Credentials and authorization rules can be managed centrally, i.e. credentials and rules do not need to be configured manually on each component.  How it works today The following diagram provides an overview of the components involved in use cases requiring authentication and authorization.\n  Device Auth Both the HTTP adapter as well as the MQTT adapter require devices to authenticate during connection establishment by default. Both rely on the Credentials API to help in verifying credentials provided by a device. Please refer to Device Authentication for a general overview of Hono\u0026rsquo;s approach to authenticating devices and to the protocol adapter user guides for specifics regarding how devices can authenticate to the corresponding protocol adapters.\nSystem Component Auth Client components opening an AMQP connection to a server component are authenticated using SASL PLAIN as specified in RFC 4422. The server component takes the authentication information provided by the client component and opens a connection to the Auth Server, using the credentials provided by the client in its SASL PLAIN exchange with the server component. On successful authentication the Auth Server issues a JSON Web Token (JWT) asserting the client\u0026rsquo;s identity and its granted authorities to the server component. The server component then attaches this token to its AMQP connection with the client and from then on uses it to make authorization decisions regarding the client\u0026rsquo;s requests. See Authentication API for details regarding the authentication process and the format of the tokens issued by the Auth Server.\nBased on the components shown above, the following sequence diagram shows how the MQTT Adapter connects to the Device Registry and gets authenticated transparently using the Auth Server.\n  Client components are authorized whenever they open a new AMQP link on an existing connection to the server. When a client tries to open a receiver link, the server checks if the client is authorized to read from the source address the client has specified in its AMQP attach frame. Analogously, when a client tries to open a sender link, the server checks if the client is authorized to write to the target address from the client\u0026rsquo;s attach frame.\nService implementations may additionally authorize individual (request) messages received from the client, e.g. based on the message\u0026rsquo;s subject property which is used by Hono\u0026rsquo;s AMQP 1.0 based APIs to indicate the operation to invoke. In such a case the server checks if the client is authorized to execute the operation indicated by the message subject on the link\u0026rsquo;s target address.\nApplication Auth Business Applications connect to the AMQP 1.0 Messaging Network in order to consume telemetry data and events and send commands to devices. It is therefore the responsibility of the AMQP Network to properly authenticate and authorize the application.\nThe Apache Qpid Dispatch Router which is used in Hono\u0026rsquo;s example deployment can be configured to authenticate consumers using arbitrary SASL mechanisms. Access to addresses for receiving messages can be restricted to certain identities. The Dispatch Router instance which is used in the example deployment is configured to delegate authentication of clients to the Auth Server by means of its Auth Service Plugin mechanism. This mechanism works in a very similar way as described above for the authentication of system components. The main difference is that the clients' authorities are not transferred by means of a JSON Web Token but instead are carried in a property of the Auth Server\u0026rsquo;s AMQP open frame.\nManagement of Identities and Authorities The identities and corresponding authorities that the Auth Server uses for verifying credentials and issuing tokens are defined in a configuration file (services/auth/src/main/resources/permissions.json) read in during start-up of the Auth Server. These authorities are used for authenticating and authorizing system components as well as Business Applications.\nPlease refer to the Dispatch Router documentation for details regarding configuration of Dispatch Router security.\nFuture Approach In the long run Hono will still use tokens for authenticating clients but will use a policy based approach for authorizing requests, i.e. authorization decisions will be made by a central policy enforcement component. Hono services will pass in the client\u0026rsquo;s token, the resource being accessed and the intended action along with potentially other attributes to the policy enforcement component which will then make the authorization decision based on the configured rules (policy) and return the outcome to the component.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/categories/",
	"title": "Categories",
	"tags": [],
	"description": "",
	"content": ""
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/user-guide/device-registry/",
	"title": "Device Registries",
	"tags": [],
	"description": "",
	"content": "Eclipse Hono™ provides these device registry implementations:\nFile Based Device Registry\nMongoDB Based Device Registry.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/admin-guide/device-registry-config/",
	"title": "Device Registry Configurations",
	"tags": [],
	"description": "",
	"content": "The configuration of Eclipse Hono™s Device Registry implementations for the File Based Device Registry and for the MongoDB Based Device Registry.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/dev/tags/",
	"title": "Tags",
	"tags": [],
	"description": "",
	"content": ""
}]