I only have another question (regarding 1.8.0): I am now able to get the „north“ side running via AMQP but I do not yet get a command message sent to a client (client via HTTP adapter). I try to do the whole thing without ditto, so HONO only. Just to ensure that I got everything right:
- Application creates a connection and a sender link to target
command/{self.tenant}/{self.deviceId} - Application creates a receiver link to target
telemetry/{self.tenant} - Client sends a telemetry with header
hono-ttdand wait time in seconds - When my application receives the message it can send the command as message witth properties
properties={"to": f"command/{self.tenant}/{self.deviceId}", "subject": "work“}via above sender link
08:18:03.873 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - sent request [target address: registration/d7338cdc-6c72-4e3c-a329-54ab939221d7, subject: assert, correlation ID: registration-client-d813ceee-4adc-4fe7-9dea-c9843f37b0e1, device ID: 7a3f6a37-db90-4671-9a29-ac0f69e717cf] to service
08:18:03.880 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - received response [reply-to: registration/d7338cdc-6c72-4e3c-a329-54ab939221d7/a750eeca-997c-4e4d-957d-b0491f3c3772, subject: null, correlation ID: registration-client-d813ceee-4adc-4fe7-9dea-c9843f37b0e1, status: 200, cache-directive: max-age = 300]
08:18:03.880 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.impl.CachingClientFactory - creating new client for [cmd_router-d7338cdc-6c72-4e3c-a329-54ab939221d7]
08:18:03.881 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - client provided response handler did not settle message, auto-accepting ...
08:18:03.882 [vert.x-eventloop-thread-0] DEBUG o.e.h.client.impl.HonoConnectionImpl - receiver open [source: cmd_router/d7338cdc-6c72-4e3c-a329-54ab939221d7/fd10a6dc-c3fb-4d07-9c60-4ec794282c33]
08:18:03.882 [vert.x-eventloop-thread-0] DEBUG o.e.h.client.impl.HonoConnectionImpl - sender open [target: cmd_router/d7338cdc-6c72-4e3c-a329-54ab939221d7, sendQueueFull: false, remote max-message-size: null]
08:18:03.882 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - request-response client for peer [c2e-test-service-command-router] created
08:18:03.882 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.impl.CachingClientFactory - successfully created new client for [cmd_router-d7338cdc-6c72-4e3c-a329-54ab939221d7]
08:18:03.883 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - sent request [target address: cmd_router/d7338cdc-6c72-4e3c-a329-54ab939221d7, subject: register-command-consumer, correlation ID: cmd_router-client-d87de6e0-fdad-4f6b-9d80-f6f565524de6, device ID: 7a3f6a37-db90-4671-9a29-ac0f69e717cf] to service
08:18:03.893 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - received response [reply-to: cmd_router/d7338cdc-6c72-4e3c-a329-54ab939221d7/fd10a6dc-c3fb-4d07-9c60-4ec794282c33, subject: null, correlation ID: cmd_router-client-d87de6e0-fdad-4f6b-9d80-f6f565524de6, status: 204, cache-directive: null]
08:18:03.893 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.impl.CachingClientFactory - creating new client for [telemetry/d7338cdc-6c72-4e3c-a329-54ab939221d7]
08:18:03.893 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - client provided response handler did not settle message, auto-accepting ...
08:18:03.895 [vert.x-eventloop-thread-0] DEBUG o.e.h.client.impl.HonoConnectionImpl - sender open [target: telemetry/d7338cdc-6c72-4e3c-a329-54ab939221d7, sendQueueFull: false, remote max-message-size: 131072]
08:18:03.895 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.impl.CachingClientFactory - successfully created new client for [telemetry/d7338cdc-6c72-4e3c-a329-54ab939221d7]
08:18:08.894 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.impl.CachingClientFactory - reusing cached client [cmd_router-d7338cdc-6c72-4e3c-a329-54ab939221d7]
08:18:08.894 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - sent request [target address: cmd_router/d7338cdc-6c72-4e3c-a329-54ab939221d7, subject: unregister-command-consumer, correlation ID: cmd_router-client-c0cd1a7e-dd8b-40d0-ab8b-08f7de9ca5a8, device ID: 7a3f6a37-db90-4671-9a29-ac0f69e717cf] to service
08:18:08.897 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - received response [reply-to: cmd_router/d7338cdc-6c72-4e3c-a329-54ab939221d7/fd10a6dc-c3fb-4d07-9c60-4ec794282c33, subject: null, correlation ID: cmd_router-client-c0cd1a7e-dd8b-40d0-ab8b-08f7de9ca5a8, status: 412, cache-directive: null]
08:18:08.898 [vert.x-eventloop-thread-0] DEBUG o.e.h.c.amqp.RequestResponseClient - client provided response handler did not settle message, auto-accepting ...
Once you have successfully run it using the MQTT adapter, it should be only a small change to use the HTTP adapter instead ...
(and a quick glance on the client didnt help me to exactly see the program flow)
This is my testing script (attention, its rather „Holzhacker“-Programming)
But its based on the python code I did for the hono quickstart Demo I did back then
I guess the crucial part is here
def on_start(self, event):
event.container: Container
conn = event.container.connect(url=self.server, user="consumer@HONO", password="verysecret")
event.container.create_receiver(conn, f"telemetry/{self.tenant}")
self.sender = event.container.create_sender(conn, target=f"command/{self.tenant}", options=[HelloWorld.SessionEnd()])
def on_message(self, event):
print(f"I got a telemetry message, sending command...")
self.accept(event.delivery)
message = Message(properties={
"to": f"command/{self.tenant}/{self.deviceId}",
"subject": "work",
# "content-type": "application/json",
# "messageId": "0",
# "userId": "null",
# "replyTo": "null",
# "correlationId": "0",
# "contentEncoding": "null",
# "absoluteExpiryTime": "null",
# "creationTime": "null",
# "groupId": 'null',
# "groupSequence": "null",
# "replyToGroupId": 'null',
})
print(f"Sending Command: {message}")
self.sender.send(message)
@JulianFeinauer I am using this code to (successfully) send a command to a device via the HTTP adapter. Maybe you can adapt your code accordingly?
from __future__ import print_function, unicode_literals
from proton import Message
from proton.handlers import MessagingHandler
from proton.reactor import Container
class HelloWorld(MessagingHandler):
def __init__(self, server, address):
super(HelloWorld, self).__init__()
self.server = server
self.address = address
def on_start(self, event):
print("connecting ...")
conn = event.container.connect(self.server, sasl_enabled=True, allowed_mechs="PLAIN", allow_insecure_mechs=True, user="consumer@HONO", password="verysecret")
event.container.create_sender(conn, self.address)
def on_sendable(self, event):
print("sending command")
event.sender.send(Message(body="Hello World!", address="command/DEFAULT_TENANT/4711", content_type="text/plain", subject="call"))
event.sender.close()
event.connection.close()
Container(HelloWorld("amqp://hono.eclipseprojects.io:15672", "command/DEFAULT_TENANT")).run()
maybe you need to use "address" instead of "to"?
Indeed I guess it was me using the lib incorrectly. with your handling of properties it works with mine it doesnt
So i thought it might be „special“ fixed properties but it seems thats just an issue of qpid and not of Hono
From my understanding, it should be a valid AMQP message if I pass a
properties dict with keys to and subject but it seems that qpid wants it as separate properties address and subject directly (see here: https://qpid.apache.org/releases/qpid-proton-0.32.0/proton/python/docs/proton.html#proton.Message)
Another question regarding the command and control API from HONO. If the application wants to send a command to a device… it needs to implement a strategy to basically „retry“ it until it gets an answer accepted (and even if that, in case of one-way it needs to hope that it worked). Or is there anything more „intelligent“ that works with all adapters (in case of HTTP it could simply react to a message received event with a
ttd set
The "ttd" mechanism works for all protocol adapters. See https://www.eclipse.org/hono/docs/1.8/concepts/device-notifications/ An application simply need to check the ttd application property in messages from devices in order to determine if the device can currently accept commands ...
But I just discovered the command router API which should be some kind of generalization of this idea, right?
it depends. If a device maintains a permanent subscription for commands, e.g. using MQTT or AMQP 1.0, then your application can send commands at any time after it has received a notification containing a ttd value of -1 and before receiving a message with ttd = 0. For devices using stateless protocols like HTTP or CoAP, the application can send commands after it has received a message containing a ttd > 0 and before the ttd has been reached ...
But generally speaking I should implement some kind of „mailbox“ mechanism in my app that „buffers“ the commands (if they are NOT ephemeral)
Slowly I start to see how we would need to modify our application to get it working on HONO
That's the idea, yes. However, we are currently implementing support for using Apache Kafka as an alternative messaging infrastructure (i.e. replacing Dispatch Router and Artemis). This is already available in Hono 1.9 as a tech preview and I guess in the upcoming 1.10.0 version we will declare this fully supported ...
Yes. For that purpose we have also defined kafka based versions of the north bound APIs (e.g. https://www.eclipse.org/hono/docs/1.9/api/kafka-api/ and https://www.eclipse.org/hono/docs/1.9/api/telemetry-kafka/ and https://www.eclipse.org/hono/docs/1.9/api/command-and-control-kafka/)
9 replies