Good morning everyone,
I seek your advice. We have a project in which we communicate devices with Eclipse Ditto via websocket. We liked this approach because of the speed of sending telemetry updates (every few milliseconds) from devices on an already established connection.
Now we wanted to add Hono eclipse, but Hono apparently doesn't have a WebSocket adapter. How would you deal with this situation? Would you do messages go over HTTP? Would you use MQTT instead? Or is there a faster alternative for constant telemetry updates every few milliseconds? Would it be worth creating your own WebSocket adapter?
You can use any of Hono's supported device protocols. That includes the ones you already mentioned (HTTP, MQTT) but also AMQP 1.0 and CoAP. For a device that needs to transmit telemetry at that rate, I would suggest to use a protocol with a stateful connection like MQTT or AMQP 1.0. If you are only sending telemetry and do not care if once in a while a message gets dropped/lost, then MQTT with QoS 0 should work well for you. If you need more sophisticated message exchange handling with acknowledgments then AMQP 1.0 might be the better choice. CoAP could also be a good alternative. It runs via UDP (instead of TCP) and has been designed in particular for constrained devices. However, if your device sends at that rate then it is most likely not constrained, is it? Or at least it is not constrained regarding power supply ...
Thanks for your quick response. It has been useful to us; After reading you, we believe that the MQTT approach is the most appropriate in this case, thanks ^. ^
Yes! One of the devices that we have connected is not an embedded constrained by regarding power supply. It's "more like" an AMRs (Autonomous Mobile Robot). This device will not have problems in terms of connection or computing power, so it is feasible to use MQTT.
Thank you very much!
Hello, I am new to Eclipse Hono. I am able to connect my raspberry Pi 4 with eclipse hono installed on my Ubuntu machine on minikube using nginx reverse port forwarding. I can communicate in between using amqp. But I am facing trouble while connecting it to Eclipse Kura. It shows connected status for 2-3 second then disconnect. Could you tell me how to connect eclipse hono with Kura on local network?
@calohmn , considering your remarks on eclipse/packages#279, I've updated the PR accodring to what I understood from your remarks. Can you have a look and verify whether this is what you were aiming for?
A device cannot subscribe to any other topic than the command topic which it uses to receive command messages from back end applications. The MQTT adapter is not an MQTT broker but simply supports the MQTT 3.1.1 protocol to exchange messages with devices. Please also refer to the MQTT adapter user guide (https://www.eclipse.org/hono/docs/user-guide/mqtt-adapter/) for information regarding subscribing to the command topic.
I observed a strange behavior when using eclipse hono via eclipse ditto (through the cloud2edge kubernetes package). I subscribed with a „device“ to receive commands via MQTT but the topic I got the command at was missing a „/„, so it was ${request-id}replies… instead of ${request-id}/replies (so the slash was missing)
I was following the guide from here https://www.eclipse.org/packages/packages/cloud2edge/tour/ ("Sending a command to the device via its digital twin“)
I was subscribing
command///req/#
And the command was sent via ditto
curl -i -X POST -u ditto:ditto -H 'Content-Type: application/json' -w '\n' --data '{
"water-amount": "3liters"
}' http://xxx:8080/api/2/things/org.acme:my-device-1/inbox/messages/start-watering?timeout=60
(you could also try it out yourself as my test cluster is public…)
I am not 100% sure but it looks like
....replies is actually the reply-id being used by Ditto. It may look strange but the Hono MQTT adapter user guide does not specify a separate replies segment in the command topic. Are you able to actually PUBLISH a response to the command using the reply-id ending in ...replies?
let me check
The Helm Chart is
0.2.1
9 replies
I am able to write code that works with the sandbox (where the credentials are known) but with my cloud2edge setup I am missing that
This has to be configured in the dispatch router (qpid?), or?
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 ...