[
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/",
	"title": "Documentation",
	"tags": [],
	"description": "",
	"content": "Documentation Learn about Eclipse Hono™ and look up details.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/concepts/",
	"title": "Concepts",
	"tags": [],
	"description": "",
	"content": "Concepts Understand the concepts behind Eclipse Hono™.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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.\nFor demonstration purposes, Hono comes with a simple default implementation of both APIs which keeps all data in memory only. Therefore it is not supposed to be used in production scenarios. For the future, it is planned that a production-ready Device Registry will be released as part of Hono that implements both APIs.\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/1.2/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.\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 registration/TENANT  etc.\nThis 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/1.2/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 User Guide of the Device Registry.\nThe actual Device Provisioning is then performed as described under Register Device. This creates both a device identity and an (empty) credentials record. The last step is to add real credentials as described in Update Credentials for a Device.\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. The feature can be enabled per certificate authority (CA) at the tenant.\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.\nSequence of steps in Auto-Provisioning Auto-Provisioning consists of two steps.\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.\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 Optional: Provision device in external systems  The 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.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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.\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/1.2/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 it\u0026rsquo;s 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] (/hono/docs/1.2/user-guide/mqtt-adapter/) 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/1.2/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.\nCommands 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 \u0026ldquo;accepted\u0026rdquo; 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 \u0026ldquo;accepted\u0026rdquo; 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 \u0026ldquo;accepted\u0026rdquo; 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"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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/1.2/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/1.2/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/1.2/user-guide/device-registry/",
	"title": "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 in the local filesystem.\nIn addition, the Device Registry also exposes HTTP resources for managing the contents of the registry according to the Device Registry HTTP 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.\nThe resources have been designed to provide convenient access to the registry\u0026rsquo;s content using command line tools like curl or HTTPie.\n  Managing Tenants The following sections describe the resources representing the operations of the Tenant API and how they can be used to manage tenants. Please refer to the Device Registry HTTP API for the specific elements that are explained in detail there.\nAdd a Tenant  URI: /v1/tenants/${tenantId} Method: POST Request Headers:  (required) Content-Type: application/json (no other type supported)   Request Body:  (Optional) A JSON object as specified by Tenant schema of the HTTP API specification.   Status Codes:  201 (Created): Tenant has been added successfully under the resource indicated by Location header. 400 (Bad Request): The tenant has not been created because the request was malformed, e .g. because the payload was malformed. The response body may contain hints regarding the cause of the problem. 409 (Conflict): A tenant with the given tenantId already exists. The request has not been processed.   Response Headers:  Location: The URI under which the newly created resource can be accessed. ETag: Version of the resource    Example\nThe following commands add some tenants with different adapter configurations:\nAdd a tenant that has all adapters set to enabled:\ncurl -i -X POST http://localhost:28080/v1/tenants/tenantAllAdapters HTTP/1.1 201 Created ETag: becc93d7-ab0f-48ec-ad26-debdf339cbf4 Location: /v1/tenants/tenantAllAdapters Content-Type: application/json; charset=utf-8 {\u0026#34;id\u0026#34;: \u0026#34;tenantAllAdapters\u0026#34;} Add a tenant that can only use the MQTT adapter:\ncurl -i -X POST -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;{ \u0026#34;adapters\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;hono-mqtt\u0026#34;, \u0026#34;enabled\u0026#34;: true } ] }\u0026#39; http://localhost:28080/v1/tenants/tenantMqttAdapter HTTP/1.1 201 Created ETag: becc93d7-ab0f-48ec-ad26-debdf339cbf4 Location: /v1/tenants/tenantMqttAdapter Content-Type: application/json; charset=utf-8 {\u0026#34;id\u0026#34;: \u0026#34;tenantMqttAdapter\u0026#34;} Get configuration details of a Tenant  URI: /v1/tenants/${tenantId} Method: GET Status Codes:  200 (OK): A tenant with the given identifier has been found. The response body contains the tenant data as specified by Tenant schema of the HTTP API specification. 404 (Not Found): No tenant with the given identifier is registered.    Example\nThe following command retrieves the details for the tenant tenantMqttAdapter:\ncurl -i http://localhost:28080/v1/tenants/tenantMqttAdapter HTTP/1.1 200 OK ETag: becc93d7-ab0f-48ec-ad26-debdf339cbf4 Content-Type: application/json; charset=utf-8 { \u0026#34;enabled\u0026#34;: true, \u0026#34;adapters\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;hono-mqtt\u0026#34;, \u0026#34;enabled\u0026#34;: true } ] } NB A tenant can be created without specifying a tenant identifier. The device registry will generate a tenant ID:\ncurl -i -X POST http://localhost:28080/v1/tenants/ HTTP/1.1 201 Created Etag: edc93899-7838-4dd1-93c8-839748c2fa42 location: /v1/tenants/0b2df55f-1a02-43f7-a1c0-f3dbd25041e0 content-type: application/json; charset=utf-8 content-length: 45 {\u0026#34;id\u0026#34;:\u0026#34;0b2df55f-1a02-43f7-a1c0-f3dbd25041e0\u0026#34;} Update Tenant  URI: /v1/tenants/${tenantId} Method: PUT Request Headers:  (required) Content-Type: application/json (no other type supported)   Request Body:  (required) A JSON object as specified by Tenant schema of the HTTP API specification.   Status Codes:  204 (No Content): The tenant has been updated successfully. 400 (Bad Request): The tenant has not been updated because the request was malformed, e .g. because the payload was malformed. The response body may contain hints regarding the cause of the problem. 404 (Not Found): The request could not be processed because no tenant with the given identifier exists.    This resource can be used to change the configuration of a particular tenant.\nExample\nThe following command disables the MQTT adapter for devices that belong to the tenant tenantMqttAdapter:\ncurl -i -X PUT -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;{ \u0026#34;adapters\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;hono-mqtt\u0026#34;, \u0026#34;enabled\u0026#34;: true } ] }\u0026#39; http://localhost:28080/v1/tenants/tenantMqttAdapter HTTP/1.1 204 No Content ETag: 8919c736-30aa-40ce-a45a-830b90c4cd42 Content-Length: 0 Delete Tenant  URI: /v1/tenants/${tenantId} Method: DELETE Status Codes:  204 (No Content): The tenant with the given identifier has been deleted. 404 (Not Found): The request could not be processed because no tenant with the given identifier exists.    Example\ncurl -i -X DELETE http://localhost:28080/v1/tenants/tenantMqttAdapter HTTP/1.1 204 No Content Content-Length: 0 Managing Device Registration Information The following sections describe the resources representing the operations of the Device Registration API and how they can be used to manage device registration information. Please refer to the Device Registry HTTP API for the specific elements that are explained in detail there.\nRegister Device  URI: /v1/devices/${tenantId}/${deviceId} Method: POST Headers:  (required) Content-Type: application/json   Request Body:  (Optional) A JSON object as specified by Device schema of the HTTP API specification.   Status Codes:  201 (Created): Device has been registered successfully under resource indicated by Location header. 400 (Bad Request): Device has not been registered because the request was malformed, e .g. a required header is missing (the body may contain hints regarding the problem). 409 (Conflict): There already exists a device with the given ID. The request has not been processed.    Example\nThe following command registers a device with ID 4711 for tenant DEFAULT_TENANT\ncurl -i -X POST -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;{ \u0026#34;ext\u0026#34;: { \u0026#34;ep\u0026#34;: \u0026#34;IMEI4711\u0026#34; } }\u0026#39; http://localhost:28080/v1/devices/DEFAULT_TENANT/4711 The response will contain a Location header containing the resource path created for the device. In this example it will look like this:\nHTTP/1.1 201 Created Location: /v1/devices/DEFAULT_TENANT/4711 ETag: becc93d7-ab0f-48ec-ad26-debdf339cbf4 Content-Type: application/json; charset=utf-8 {\u0026#34;id\u0026#34;: \u0026#34;4711\u0026#34;} NB A device can be created without specifying a device identifier. The device registry will generate a device identifier:\ncurl -i -X POST http://localhost:28080/v1/devices/DEFAULT_TENANT HTTP/1.1 201 Created Etag: 0d615bcd-0825-44d9-9ef5-54a7b12165d8 location: /v1/devices/DEFAULT_TENANT/98d25103-d49d-44b0-bdd0-0de84743c522 content-type: application/json; charset=utf-8 content-length: 45 {\u0026#34;id\u0026#34;:\u0026#34;98d25103-d49d-44b0-bdd0-0de84743c522\u0026#34;} Read Device  URI: /v1/devices/${tenantId}/${deviceId} Method: GET Status Codes:  200 (OK): A device with the given identifier has been found. The response body contains the registration information as specified by Device schema of the HTTP API specification. 404 (Not Found): No device with the given identifier is registered for the given tenant.    Example\nThe following command retrieves registration data for device 4711:\ncurl -i http://localhost:28080/v1/devices/DEFAULT_TENANT/4711 HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 { \u0026#34;enabled\u0026#34;: true, \u0026#34;ext\u0026#34;: { \u0026#34;ep\u0026#34;: \u0026#34;IMEI4711\u0026#34; } } Update Device  URI: /devices/v1/${tenantId}/${deviceId} Method: PUT Headers:  (required) Content-Type: application/json   Parameters (encoded as a JSON object in the request body): Request Body:  (required) A JSON object as specified by Device schema of the HTTP API specification. All existing registration information will be replaced by the data provided in the object.   Status Codes:  204 (No Content): Device registration data has been updated. 400 (Bad Request): Device registration has not been updated because the request was malformed, e .g. a required header is missing (the body may contain hints regarding the problem). 404 (Not Found): No device with the given identifier is registered for the given tenant.    Example\ncurl -i -X PUT -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;{ \u0026#34;ext\u0026#34;: { \u0026#34;ep\u0026#34;: \u0026#34;IMEI4711\u0026#34;, \u0026#34;psk-id\u0026#34;: \u0026#34;psk4711\u0026#34; } }\u0026#39; http://localhost:28080/v1/devices/DEFAULT_TENANT/4711 HTTP/1.1 204 No Content Content-Length: 0 Delete Device  URI: /v1/devices/${tenantId}/${deviceId} Method: DELETE Status Codes:  204 (No Content): Device registration has been deleted. 404 (Not Found): No device with the given identifier is registered for the given tenant.    Example\ncurl -i -X DELETE http://localhost:28080/v1/devices/DEFAULT_TENANT/4711 HTTP/1.1 204 No Content Content-Length: 0 Managing Credentials The following sections describe the resources representing the operations of the Credentials API and how they can be used to manage credentials for devices. Please refer to the Device Registry HTTP API for the specific elements that are explained in detail there.\nUpdate Credentials for a Device  URI: /v1/credentials/${tenantId}/${deviceId} Method: PUT Request Headers:  (required) Content-Type: application/json (no other type supported)   Request Body:  (required) A JSON object as specified by Credentials schema of the HTTP API specification.   Status Codes:  204 (No Content): Credentials have been updated successfully. 400 (Bad Request): The credentials have not been added because the request was malformed, e .g. because the payload did not contain required values. The response body may contain hints regarding the cause of the problem.   Response Headers:  ETag: Version of the resource    Example\nThe following command adds some hashed-password credentials from a given plain text password for device 4710 using authentication identifier sensor10:\ncurl -i -X PUT -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;[{ \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor10\u0026#34;, \u0026#34;secrets\u0026#34;: [{ \u0026#34;pwd-plain\u0026#34;: \u0026#34;mylittlesecret\u0026#34; }] }]\u0026#39; http://localhost:28080/v1/credentials/DEFAULT_TENANT/4710 HTTP/1.1 204 No Content ETag: becc93d7-ab0f-48ec-ad26-debdf339cbf4x This uses a convenient option which lets the Device Registry do the hashing of the password. The following command retrieves the credentials that are stored by the Device Registry as a result of the command above:\ncurl -i http://localhost:28080/v1/credentials/DEFAULT_TENANT/4710 HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 ETag: becc93d7-ab0f-48ec-ad26-debdf339cbf4x [{ \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor10\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;secrets\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;349556ea-4902-47c7-beb0-1009ab693fb4\u0026#34; } ] }] The above result does not contain pwd_hash and hash_function of the secret, as these values are confidential.\nThe following commands set some hashed-password credentials for device 4720 using authentication identifier sensor20:\ncurl -i -X PUT -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;[{ \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor20\u0026#34;, \u0026#34;secrets\u0026#34;: [{ \u0026#34;pwd-plain\u0026#34;: \u0026#34;mylittlesecret\u0026#34; }] }]\u0026#39; http://localhost:28080/v1/credentials/DEFAULT_TENANT/4720 HTTP/1.1 204 No Content ETag: 02c99fb5-af8c-409f-8520-b405e224b27f The following command adds an expiration date to the hashed-password credentials for authentication identifier sensor20:\ncurl -i -X PUT -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;{ \u0026#34;device-id\u0026#34;: \u0026#34;4720\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor20\u0026#34;, \u0026#34;secrets\u0026#34;: [{ \u0026#34;pwd-plain\u0026#34;: \u0026#34;mylittlesecret\u0026#34;, \u0026#34;not-after\u0026#34;: \u0026#34;2018-01-01T00:00:00+01:00\u0026#34; }] }\u0026#39; http://localhost:28080/v1/credentials/DEFAULT_TENANT/4720 HTTP/1.1 204 No Content ETag: becc93d7-ab0f-48ec-ad26-debdf339cbf4x Multiple credentials of different type can be registered for the same authentication identifier. The following commands add psk credentials for the same device 4720 using authentication identifier sensor20:\nSHARED_KEY=$(echo -n \u0026#34;TheSharedKey\u0026#34; | base64 -w 0) curl -i -X PUT -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;[ { \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor20\u0026#34;, \u0026#34;secrets\u0026#34;: [{ \u0026#34;pwd-plain\u0026#34;: \u0026#34;mylittlesecret\u0026#34; }] }, { \u0026#34;device-id\u0026#34;: \u0026#34;4720\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;psk\u0026#34;, \u0026#34;auth-id\u0026#34;: \u0026#34;sensor20\u0026#34;, \u0026#34;secrets\u0026#34;: [{ \u0026#34;key\u0026#34;: \u0026#34;\u0026#39;$SHARED_KEY\u0026#39;\u0026#34; }] }]\u0026#39; http://localhost:28080/v1/credentials/DEFAULT_TENANT/4720 HTTP/1.1 204 No Content ETag: 122c971a-505a-4336-8f7d-640360e909bc The following command deletes all credentials for device 4710:\ncurl -i -X PUT -H \u0026#39;Content-Type: application/json\u0026#39; --data-binary \u0026#39;[]\u0026#39; http://localhost:28080/v1/credentials/DEFAULT_TENANT/4710 HTTP/1.1 204 No Content ETag: d383ba4d-1853-4d03-b322-b7ff5af05ae2 Get all Credentials for a Device  URI: /v1/credentials/${tenantId}/${deviceId} Method: GET Status Codes:  200 (OK): Credentials for the device have been found, body contains the credentials. The response body contains the registration information as specified by Credentials schema of the HTTP API specification. 404 (Not Found): No credentials for the device are registered.    Example\nThe following command retrieves credentials metadata for device 4720:\ncurl -i http://localhost:28080/v1/credentials/DEFAULT_TENANT/4720 HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 ETag: f3449b77-2c84-4b09-8d04-2b305876e0cb {[ { \u0026#34;auth-id\u0026#34;: \u0026#34;sensor20\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;secrets\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;d383ba4d-1853-4d03-b322-b7ff5af05ae2\u0026#34; \u0026#34;not-after\u0026#34;: \u0026#34;2020-02-1T00:00:00+01:00\u0026#34; }, { \u0026#34;id\u0026#34;: \u0026#34;46810d5c-133e-4c1c-994d-ed7745516b8e\u0026#34; \u0026#34;not-before\u0026#34;: \u0026#34;2020-01-01T00:00:00+01:00\u0026#34; } ], \u0026#34;type\u0026#34;: \u0026#34;hashed-password\u0026#34; }, { \u0026#34;auth-id\u0026#34;: \u0026#34;sensor20\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;secrets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;VGhlU2hhcmVkS2V5\u0026#34; } ], \u0026#34;type\u0026#34;: \u0026#34;psk\u0026#34; } ]} "
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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 Before accepting any telemetry or event or command messages, the HTTP adapter verifies that the configured [message limit] (/hono/docs/1.2/concepts/resource-limits/) is not exceeded. If the limit is exceeded then the incoming message is discarded with the status code 429 Too Many Requests.\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 because there is no consumer of telemetry data for the given tenant connected to Hono.    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 because there is no consumer of telemetry data for the given tenant connected to Hono.    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 because there is no consumer of telemetry data for the given tenant connected to Hono.    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.    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.    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.    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] (/hono/docs/1.2/api/tenant/#resource-limits-configuration-format).\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/1.2/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 Event The MQTT Adapter can send a Connection Event once the connection with a device has been successfully established or ended. Note that this requires the HONO_CONNECTION_EVENTS_PRODUCER configuration property to be explicitly set to events.\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] (/hono/docs/1.2/concepts/resource-limits/) before accepting any telemetry messages. If the message limit is exceeded or the incoming telemetry message cannot be processed, the connection to the client is closed.\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] (/hono/docs/1.2/concepts/resource-limits/) before accepting any event messages. If the message limit is exceeded or the incoming event message cannot be processed, the connection to the client is closed.\nThe devices can optionally indicate a time-to-live duration for event messages by setting the hono-ttl 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.\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 command topic filter indicating QoS 0 or 1 and will contain the Failure (0x80) value for all other filters. 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] (/hono/docs/1.2/concepts/resource-limits/) 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.  Receiving Commands (authenticated Device) An authenticated device MUST use the topic filter command///req/# to subscribe 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.  Example\nmosquitto_sub -v -u \u0026#39;sensor1@DEFAULT_TENANT\u0026#39; -P hono-secret -t command///req/# The adapter will then publish Request/Response commands for the device to topic command///req/${req-id}/${command} and one-way commands to topic command///req//${command}.\nFor example, a request/response command with name setBrightness from an application might look like this:\ncommand///q/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/setBrightness { \u0026#34;brightness\u0026#34;: 79 } A corresponding one-way command might look like this:\ncommand///q//setBrightness { \u0026#34;brightness\u0026#34;: 79 } Note that the topic in the latter case doesn\u0026rsquo;t contain a request identifier.\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/q/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/q//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 the topic filter command//+/req/# to subscribe to commands for all devices in whose behalf it acts.\nTo subscribe only to commands for a specific device, an authenticated gateway MUST use the topic filter command//${device-id}/req/#.\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.\nExample\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//+/req/# A 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 command//4711/req/# The adapter will then publish Request/Response commands for devices, that the gateway has acted on behalf of, to topic command//${device-id}/req/${req-id}/${command} and one-way commands to topic command//${device-id}/req//${command}.\nFor example, a request/response command for device 4711 with name setBrightness from an application might look like this:\ncommand//4711/q/1010f8ab0b53-bd96-4d99-9d9c-56b868474a6a/setBrightness { \u0026#34;brightness\u0026#34;: 79 } A corresponding one-way command might look like this:\ncommand//4711/q//setBrightness { \u0026#34;brightness\u0026#34;: 79 } Note that the topic in the latter case doesn\u0026rsquo;t contain a request identifier.\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; 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 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] (/hono/docs/1.2/api/tenant/#resource-limits-configuration-format).\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:\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/1.2/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 a client certificate.\nIn this guide, we will give examples for publishing telemetry data 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. If the adapter is configured for multi-tenancy (i.e HONO_AMQP_SINGLE_TENANT is set to false), then the username must match the pattern [auth-id@tenant], e.g. sensor1@DEFAULT_TENANT. Otherwise the DEFAULT_TENANT is assumed and the tenant-id can be omitted from the username.\nThe adapter verifies the credentials provided by the client against the credentials the configured Credentials service has on record for the client. If the credentials match, then authentication is successful and 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 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.\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 Adapter extracts the client certificate\u0026rsquo;s Issuer DN and uses it to us the Tenant service to look up the tenant that the client belongs to. 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 service returns the tenant, thus implicitly establishing the tenant that the device belongs to. Adapter validates the device’s client certificate using the registered trust anchor for the tenant. Finally, 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 fails the SASL handshake with a client\n if the maximum number of simultaneously connected devices for the client\u0026rsquo;s tenant is reached, or if the maximum number of connections per protocol adapter instance is reached.  Connection Duration Limits The adapter fails the SASL handshake with a client if the connection duration limit that has been configured for the client’s tenant is exceeded.\nMessage Limits The adapter\n fails the SASL handshake with a client 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’s tenant is exceeded.\nConnection Event The AMQP Adapter can send a Connection Event once the connection with a device has been successfully established or ended. Note that this requires the HONO_CONNECTION_EVENTS_PRODUCER configuration property to be explicitly set to events.\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:\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.\nAMQP 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) The AMQP adapter supports publishing of telemetry data to Hono\u0026rsquo;s Telemetry API. Telemetry messages can be published using either AT LEAST ONCE or AT MOST ONCE delivery semantics.\n Message Address: telemetry or t  This refers to the to property of the message.   Settlement Mode: presettled (AT MOST ONCE) or unsettled (AT LEAST ONCE) Authentication: SASL PLAIN or SASL EXTERNAL Message Body:  (optional) Arbitrary payload   Message properties:  (optional) Arbitrary properties (content-type, correlation-id, \u0026hellip;)   Disposition Frames:  Accepted: Message successfully processed by the adapter. Released: Message cannot be processed and should be redelivered. Rejected: Adapter rejects the message due to one of the following: * (hono:bad-request): Request rejected due to a bad client request. * (amqp:unauthorized-access): Request rejected because the adapter is disabled for tenant. * (amqp:precondition-failed): Request does not fulfill certain requirements e.g adapter cannot assert device registration etc. * (amqp:resource-limit-exceeded): Request rejected because the message limit for the given tenant is exceeded.    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.\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 --hono.client.username=sensor1@DEFAULT_TENANT --hono.client.password=hono-secret Notice that we only supplied a new value for the message address, leaving the other default values.\nPublish 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)  Message Address: telemetry/${tenant-id}/${device-id} or t/${tenant-id}/${device-id} Settlement Mode: presettled (AT MOST ONCE) or unsettled (AT LEAST ONCE) Authentication: none Message Body:  (optional) Arbitrary payload   Message properties:  (optional) Arbitrary properties (content-type, correlation-id, \u0026hellip;)   Disposition Frames:  Accepted: Message successfully processed by the adapter. Released: Message cannot be processed and should be redelivered. Rejected: Adapter rejects the message due to: * (hono:bad-request): A bad client request (e.g invalid content-type). * (amqp:unauthorized-access): The adapter is disabled for tenant. * (amqp:precondition-failed): Request not fulfilling certain requirements. * (amqp:resource-limit-exceeded): Request rejected because the message limit for the given tenant is exceeded.    Note how verbose the address is for unauthenticated devices. This address can be used by devices that have not authenticated to the protocol adapter. This requires the HONO_AMQP_AUTHENTICATION_REQUIRED configuration property to be explicitly set to false before starting the protocol adapter.\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)  Message Address: event or e Settlement Mode: unsettled (AT LEAST ONCE) Authentication: SASL PLAIN or SASL EXTERNAL Message Body:  (optional) Arbitrary payload   Message properties:  (optional) Arbitrary properties (content-type, correlation-id, \u0026hellip;)   Disposition Frames:  Accepted: Message successfully processed by the adapter. Released: Message cannot be processed and should be redelivered. Rejected: Adapter rejects the message due to: * (hono:bad-request): A bad client request (e.g invalid content-type). * (amqp:unauthorized-access): The adapter is disabled for tenant. * (amqp:precondition-failed): Request not fulfilling certain requirements. * (amqp:resource-limit-exceeded): Request rejected because the message limit for the given tenant is exceeded.    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)  Message Address: event/${tenant-id}/${device-id} or e/${tenant-id}/${device-id} Settlement Mode: unsettled (AT LEAST ONCE) Message Body:  (optional) Arbitrary payload   Message properties:  (optional) Arbitrary properties (content-type, correlation-id, \u0026hellip;)   Disposition Frames:  Accepted: Message successfully processed by the adapter. Released: Message cannot be processed and should be redelivered. Rejected: Adapter rejects the message due to: * (hono:bad-request): A bad client request (e.g invalid content-type). * (amqp:unauthorized-access): The adapter is disabled for tenant. * (amqp:precondition-failed): Request not fulfilling certain requirements. * (amqp:resource-limit-exceeded): Request rejected because the message limit for the given tenant is exceeded.    This address format is used by devices that have not authenticated to the protocol adapter. Note that this requires the 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=e/DEFAULT_TENANT/4711 --message.payload=\u0026#39;{\u0026#34;alarm\u0026#34;: 1}\u0026#39; Publish an Event (authenticated Gateway) Examples\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] (/hono/docs/1.2/concepts/resource-limits/) 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.\nSending 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 true 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.\nThe table below provides an overview of the properties that must be set on a command response message:\n   Name Mandatory Location Type Description     to yes properties string MUST contain the value of the reply-to property of the command request message.   correlation-id yes properties string MUST contain the value of the correlation-id property of the command request message.   status yes application-properties integer MUST contain a status code indicating the outcome of processing the command at the device (see Command \u0026amp; Control API for details).    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] (/hono/docs/1.2/api/tenant/#resource-limits-configuration-format).\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/1.2/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.\n Experimental The CoAP adapter has not yet reached the level of maturity of the other standard adapters. In particular, the resources implemented by the adapter might still be subject to change.  Device Authentication The CoAP adapter by default requires clients (devices or gateway components) to authenticate during connection establishment. The adapter (currently) only supports PSK as part of a DTLS handshake for that purpose. Additional variants mentioned in Securing CoAP might be added in the future.\nThe adapter tries to authenticate the device using these mechanisms in the following order\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 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.\nMessage Limits Before accepting any telemetry or event or command messages, the CoAP adapter verifies that the configured message limit is not exceeded. For CoAP currently only the messages limit is verified, the connections limit is not available. If the limit is exceeded then the incoming message is discarded with the status code 429 Too Many Requests.\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 because there is no consumer of telemetry data for the given tenant connected to Hono.    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 because there is no consumer of telemetry data for the given tenant connected to Hono.    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 because there is no consumer of telemetry data for the given tenant connected to Hono.    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 telemetry data for the given tenant connected to Hono.    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 telemetry data for the given tenant connected to Hono.    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 telemetry data for the given tenant connected to Hono.    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] (/hono/docs/1.2/admin-guide/common-config/#device-registration-service-connection-configuration).\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] (/hono/docs/1.2/api/tenant/#resource-limits-configuration-format).\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.   "
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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.  The Kura adapter by default requires devices (gateways) to authenticate during connection establishment. In order to do so, gateways need to provide a username and a password in the MQTT CONNECT packet. The username must have the form auth-id@tenant, e.g. sensor1@DEFAULT_TENANT. The adapter verifies the credentials provided by the gateway against the credentials the configured Credentials service has on record for the gateway. 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.\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.\nAfter verifying the credentials, the number of existing connections and the overall amount of time that the devices have already been connected are checked against the configured [resource-limits] (/hono/docs/1.2/concepts/resource-limits/) by the Kura adapter. If the limit is exceeded then a return code 0x05 indicating Connection Refused: not authorised is sent back.\nOnce 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] (/hono/docs/1.2/api/tenant/#resource-limits-configuration-format).\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/1.2/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/1.2/user-guide/jmeter_load_tests/",
	"title": "Load Tests with JMeter",
	"tags": [],
	"description": "",
	"content": "Eclipse Hono™ comes with an Apache JMeter plugin which provides samplers that can be used in JMeter test plans to send and receive telemetry/event data.\nThe plugin provides a Hono Receiver Sampler which can be used together with JMeter\u0026rsquo;s standard HTTP Sampler and XMeter\u0026rsquo;s JMeter plugin for MQTT to play the roles of a downstream application (consumer) and devices uploading data to the HTTP and MQTT protocol adapters. The diagram below illustrates how the components are related to each other.\n  JMeter with Hono   Installation  Install JMeter Copy the plugin jar file \u0026lt;hono-installation\u0026gt;/jmeter/target/plugin/hono-jmeter-\u0026lt;version\u0026gt;-jar-with-dependencies.jar to the \u0026lt;jmeter-installation\u0026gt;/lib/ext folder. Start JMeter  Example Test Plans The \u0026lt;hono-installation\u0026gt;/jmeter/src/jmeter folder contains several JMeter test plans which you can use as a basis for your own tests. All test plans can be run against Hono\u0026rsquo;s example deployment.\n http_messaging_throughput_test.jmx runs a set of HTTP clients and AMQP 1.0 consumers for a given period of time. The senders publish data to Hono' HTTP adapter while the consumers receive messages from the AMQP 1.0 Messaging Network (in case of the example installation this is the Qpid Dispatch Router). The test plan measures the number of messages that are sent/received during the test execution. mqtt_messaging_throughput_test.jmx runs a set of MQTT clients and AMQP 1.0 consumers for a given period of time. The clients publish data to Hono' MQTT adapter while the consumers receive messages from the AMQP 1.0 Messaging Network (in case of the example installation this is the Qpid Dispatch Router). The test plan measures the number of messages that are sent/received during the test execution. To use this plan you also need to add the JMeter plugin for MQTT to your JMeter plugin path. amqp_messaging_throughput_test.jmx runs a set of AMQP 1.0 senders and consumers for a given period of time. The senders publish data to the AMQP 1.0 Messaging Network directly while the consumers receive messages from the AMQP 1.0 Messaging Network (in case of the example installation this is the Qpid Dispatch Router). The test plan measures the number of messages that are sent/received during the test execution.\nThe sender can be configured to wait for n active receivers (from this test plan and JMeter instance) which can be used to make sure, that the receivers consuming from the corresponding address (e.g. telemetry/DEFAULT_TENANT) are up and running before the senders begin to publish messages.  It is recommended to run the test plans in non-gui mode as illustrated by the example shell scripts that are contained in the \u0026lt;hono-installation\u0026gt;/jmeter/src/jmeter folder. You may need to adapt some of the properties to reflect your concrete setup, e.g. the path to the trust store, host names, ports etc.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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/1.2/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_MILLIS\n--hono.vertx.maxEventLoopExecuteTimeMillis no 2000 The maximum number of milliseconds that a task on the event loop may run without being considered to block the event loop.   HONO_VERTX_PREFER_NATIVE\n--hono.vertx.preferNative no false Tries to enable epoll() support on Linux (if available). See the notes below for an explanation of the benefits of enabling epoll.    \nUsing epoll() on Linux Using epoll() on Linux 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 x86_64 based systems. Hono provides the a Maven build profile for enabling support for epoll during the build process.\nIn order to use epoll\n Hono needs to be built with the netty-native-linux-x86_64 Maven profile enabled and the HONO_VERTX_PREFER_NATIVE environment variable needs to be set to true on startup.  Protocol 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.\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.\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.\nDevice Connection Service Connection Configuration Protocol adapters require a connection 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 an 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.\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_CACHE_MIN_SIZE\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_CACHE_MAX_SIZE\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_CACHE_TIMEOUT\n--hono.resourceLimits.prometheusBased.cacheTimeout no 600 The number of seconds after which the cached metrics data should be considered invalid.    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 "
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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_SECURE_PROTOCOLS\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_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 no classpath:/\npermissions.json The Spring resource URI of the JSON file defining the identities and corresponding authorities on Hono\u0026rsquo;s endpoint resources. The default file bundled with the Auth Server defines authorities required by protocol adapters and downstream consumer. The default permissions file should only be used for evaluation purposes.   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 it\u0026rsquo;s 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 The server 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.\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/1.2/admin-guide/device-registry-config/",
	"title": "Device Registry Configuration",
	"tags": [],
	"description": "",
	"content": "The 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.\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 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_MAX_BCRYPT_ITERATIONS\n--hono.credentials.svc.maxBcryptIterations no 10 The maximum number of iterations that are 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 number of iterations.   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_SECURE_PROTOCOLS\n--hono.registry.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_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.   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.   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.   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.   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 AMQP port number (5672) if not set explicitly.\nSee Port Configuration below for details.   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.   HONO_REGISTRY_REST_KEY_STORE_PASSWORD\n--hono.registry.rest.keyStorePassword no - The password required to read the contents of the key store.   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.   HONO_REGISTRY_REST_PORT\n--hono.registry.rest.port no 5671 The secure port that the server should listen on for HTTP requests.\nSee Port Configuration below for details.   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 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)  The server will fail to start if none of the ports is configured properly.\nThe following sections apply to configuring both, the AMQP endpoint as well as the REST endpoint. The environment variables to use for configuring the REST endpoint are the same as the ones for the AMQP endpoint, substituting _AMQP_ with _REST_, e.g. HONO_REGISTRY_REST_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 AMQP port 5671. 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 AMQP port (5672) by simply setting HONO_REGISTRY_AMQP_INSECURE_PORT_ENABLED to true.  The server issues a warning on the console if HONO_REGISTRY_AMQP_INSECURE_PORT is set to the default secure AMQP port (5671).\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 it\u0026rsquo;s 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 The server 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.\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/1.2/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.\nThe 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.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_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_REGISTRY_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_SECURE_PROTOCOLS\n--hono.deviceConnection.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.    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 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)  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 it\u0026rsquo;s 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 The server 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.\nData Grid Connection Configuration The Device Connection component requires a connection to a remote data grid using the Infinispan Hotrod protocol to store device connection information in.\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_REMOTE_SERVER_LIST\n--hono.deviceConnection.remote.serverList yes - A list of remote servers in the form: host1[:port][;host2[:port]].....   HONO_DEVICECONNECTION_REMOTE_AUTH_SERVER_NAME\n--hono.deviceConnection.remote.authServerName yes - The server name to indicate in the SASL handshake when authenticating to the server.   HONO_DEVICECONNECTION_REMOTE_AUTH_USERNAME\n--hono.deviceConnection.remote.authUsername yes - The username to use for authenticating to the server.   HONO_DEVICECONNECTION_REMOTE_AUTH_PASSWORD\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.\nAuthentication 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/1.2/admin-guide/http-adapter-config/",
	"title": "HTTP Adapter Configuration",
	"tags": [],
	"description": "",
	"content": "The HTTP protocol adapter exposes a HTTP based API for Eclipse Hono™\u0026rsquo;s Telemetry and Event endpoints.\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_SECURE_PROTOCOLS\n--hono.http.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_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/1.2/admin-guide/amqp-adapter-config/",
	"title": "AMQP Adapter Configuration",
	"tags": [],
	"description": "",
	"content": "The AMQP protocol adapter allows clients (devices and gateway components) that speaks AMQP 1.0 to publish telemetry messages and events to Eclipse Hono™\u0026rsquo;s Telemetry and Event endpoints.\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_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 number of bytes that can be sent in an AMQP message delivery over the connection with a device. When a client sends an AMQP frame of larger size, the connection is 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.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_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/1.2/admin-guide/mqtt-adapter-config/",
	"title": "MQTT Adapter Configuration",
	"tags": [],
	"description": "",
	"content": "The MQTT protocol adapter exposes an MQTT topic hierarchy for publishing messages and events to Eclipse Hono™\u0026rsquo;s Telemetry and Event endpoints.\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 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_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_SECURE_PROTOCOLS\n--hono.mqtt.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_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.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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 publish control and data messages to Eclipse Hono™\u0026rsquo;s Telemetry and Event endpoints.\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_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_SECURE_PROTOCOLS\n--hono.kura.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_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.    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/1.2/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 adapter 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.   ${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}_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.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.   ${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 adapter uses for authenticating 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.   ${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 specified by the directive. 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.    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.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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/1.2/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.    Device Registry The Device Registry supports the use of TLS for connections to protocol adapters and the Auth Server. Please refer to the 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 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.    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/1.2/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 to the application.yml file.\nThe Hono build supports configuration of a specific metrics back end by means of Maven profiles. The following build profiles are currently supported:\n metrics-prometheus – Enables the Prometheus backend. metrics-graphite – Enables the Graphite backend. metrics-influxdb – Enables the InfluxDB backend.  Additionally to selecting a metrics back end, you may need to configure the back end using Spring configuration options. See the documentation mentioned above for more information.\nNote that none of the above profiles are active by default, i.e. you need to explicitly activate one of them when starting the build using Maven\u0026rsquo;s -p command line parameter.\nUsing 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.  Assuming that the HTTP adapter should be configured to use Jaeger tracing, the following steps are necessary:\n  Download Jaeger\u0026rsquo;s Java Tracer Resolver implementation and its dependencies (see the hint at the end).\n  Put the jars to a folder on the Docker host, e.g. /tmp/jaeger.\n  Start the HTTP adapter Docker image mounting the host folder:\ndocker run --name hono-adapter-http-vertx \\ --mount type=bind,src=/tmp/jaeger,dst=/opt/hono/extensions,ro \\ ... \\ eclipse/hono-adapter-http-vertx   Note: the command given above does not contain the environment variables and secrets that are required to configure the service properly. The environment variables for configuring the Jaeger client are also missing. Please refer to the Jaeger documentation for details.\nWhen the HTTP adapter starts up, it will look for a working implementation of the Tracer Resolver on its classpath and (if found) initialize and use it for publishing traces. The adapter\u0026rsquo;s log file will indicate the name of the Tracer implementation being 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.\nHint: to resolve all dependencies for jaeger-tracerresolver in order to provide them to /opt/hono/extensions, you may want to rely on Maven\u0026rsquo;s dependency plugin. To obtain all jar files you can invoke the following command in a simple Maven project that contains only the dependency to jaeger-tracerresolver:\nmvn dependency:copy-dependencies All jar files can then be found in the directory target/dependency.\nConfiguring 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.\nFor 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/1.2/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/1.2/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.\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:\n# in the \u0026#34;hono\u0026#34; folder containing the source code mvn clean install -Ddocker.host=tcp://${host}:${port} -Pbuild-docker-image,metrics-prometheus with ${host} and ${port} reflecting the name/IP address and port of the host where Docker is running on. This will build all libraries, Docker images and example code. If you are running on Linux and Docker is installed locally or you have set the DOCKER_HOST environment variable, you can omit the -Ddocker.host property definition.\nIf you plan to build the Docker images more frequently, e.g. because you want to extend or improve the Hono code, then you should define the docker.host property in your Maven settings.xml file containing the very same value as you would use on the command line as indicated above. The file is usually located in the .m2 folder in your user\u0026rsquo;s home directory. This way you can simply do a mvn clean install later on and the Docker images will be built automatically as well because the build-docker-image profile is activated automatically if the Maven property docker.host is set.\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.  Perform 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/1.2/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/1.2/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/example/ 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.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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/1.2/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/1.2/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/1.2/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; } } "
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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 because the device is (currently) not connected.   rejected The command has not been delivered to the device because it does not contain all required information.    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 because the device is (currently) not connected.   rejected The command has not been delivered to the device because it does not contain all required information.    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/1.2/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/1.2/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.\nThe Device Connection 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 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.\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.    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 adapter instance for the device has been updated.   400 Bad Request, the command-handling adapter instance 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 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.   404 Not Found, 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. In case the currently mapped adapter instance doesn\u0026rsquo;t match the given adapter instance id, a 412 status code may also be returned instead of 404.\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/1.2/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.    Below is an example for a payload of a response to an assert request for device 4711 which also includes a default content-type:\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; } } 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/1.2/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 it\u0026rsquo;s 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 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 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/1.2/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/1.2/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/1.2/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 in combination with Spring Boot to internally collect metrics. Those metrics can be exported to different back ends. Please refer to Configuring Metrics for details.\nThe example deployment by default uses 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 tags as 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.    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.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/1.2/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/1.2/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 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 The newly built images can then be deployed using Helm:\nhelm install --dependency-update -n hono 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] (/hono/docs/1.2/admin-guide/monitoring-tracing-config/) 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 hono-jaeger-query --output=\u0026#39;jsonpath={.status.loadBalancer.ingress[0].ip}\u0026#39; -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/1.2/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/1.2/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/1.2/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] (/hono/docs/1.2/concepts/resource-limits/) 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] (/hono/docs/1.2/concepts/resource-limits/) 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/1.2/architecture/",
	"title": "Architecture",
	"tags": [],
	"description": "",
	"content": "Architecture Get an overview of the architecture of Eclipse Hono™.\n"
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/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.\nThe Device Registry uses 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, Device Connection 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, Device Registration API and Device Connection API. Clients opening a connection to SimpleDeviceRegistryServer are authenticated by means of an external service accessed via the Auth port. The FileBasedCredentialsService, FileBasedTenantService and FileBasedRegistrationService store all data in the local file system. The MapBasedDeviceConnectionService keeps all data in memory. The Device Registry is therefore not recommended to be used in production environments because the component cannot easily scale out horizontally. It is mainly intended to be used for demonstration purposes and PoCs. In real world scenarios, a more sophisticated implementation should be used that is designed to scale out, e.g. using a persistent store for keeping device registration information that can be shared by multiple instances.\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/1.2/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/1.2/categories/",
	"title": "Categories",
	"tags": [],
	"description": "",
	"content": ""
},
{
	"uri": "https://www.eclipse.org/hono/docs/1.2/tags/",
	"title": "Tags",
	"tags": [],
	"description": "",
	"content": ""
}]