Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 05:42
    calohmn review_requested #3363
  • 05:42
    calohmn synchronize #3363
  • Aug 08 12:08
    avgustinmm synchronize #3370
  • Aug 08 05:39
    calohmn review_requested #3368
  • Aug 08 05:39
    calohmn review_requested #3368
  • Aug 08 05:39
    calohmn ready_for_review #3368
  • Aug 08 05:26
    calohmn review_requested #3371
  • Aug 08 05:26
    calohmn ready_for_review #3371
  • Aug 08 05:26
    calohmn opened #3371
  • Aug 08 05:26
    calohmn labeled #3371
  • Aug 08 05:26
    calohmn labeled #3371
  • Aug 08 05:17
    calohmn edited #3369
  • Aug 08 04:20

    calohmn on quarkus_2.11.1

    (compare)

  • Aug 08 04:19

    calohmn on quarkus_2.11.2

    [#3367] Upgrade to Quarkus 2.11… (compare)

  • Aug 08 04:16
    calohmn edited #3368
  • Aug 08 04:15
    calohmn synchronize #3368
  • Aug 08 04:11
    calohmn synchronize #3368
  • Aug 05 16:34

    calohmn on master

    Fix layout issues in device reg… (compare)

  • Aug 05 10:13
    avgustinmm opened #3370
  • Aug 05 05:41
    calohmn labeled #3369
Julian
@JulianFeinauer
The message does neither get rejected, released nor accepted (amqp side) nor does the client receive it (answer is 202) and I dont see errors in the logs
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 ...
Kai Hudalla
@sophokles73
Have you tried following the steps described in Hono's Getting Started guide (section Advanced: Sending Commands to a Device)?
Once you have successfully run it using the MQTT adapter, it should be only a small change to use the HTTP adapter instead ...
Julian
@JulianFeinauer
Yes i followed the guide the main difference is that I do the „north side“ myself and not via the java client
Kai Hudalla
@sophokles73
Does it work with the java client using the HTTP adapter?
Julian
@JulianFeinauer
Yes it works if I use the Java Client as stated in the documentation… thus I wanted to ensure that I do the things right in my python impl : )
(and a quick glance on the client didnt help me to exactly see the program flow)
Julian
@JulianFeinauer
I think I do everything similar but my message gets rejected and I have no idea why
Julian
@JulianFeinauer
From the log of the command router I see: command message has no valid address but the to property of my message seems to be correct and the sender link also...
Kai Hudalla
@sophokles73
Maybe you want to share your Python code?
Julian
@JulianFeinauer
Sure
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)
Kai Hudalla
@sophokles73
it should probably be "to:" f"command/{self.tenantId}/{self.deviceId}", shouldn't it?
Kai Hudalla
@sophokles73
ah no, I see, tenant is initialized to the value of tenantId ...
Kai Hudalla
@sophokles73
@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"?
Julian
@JulianFeinauer
Yeah, thanks @sophokles73 , I got it working with your example
Indeed I guess it was me using the lib incorrectly. with your handling of properties it works with mine it doesnt
Kai Hudalla
@sophokles73
Nice :-)
@/all I will start the 1.8.3 build now ...
Julian
@JulianFeinauer
I never used AMQP before so please excuse my noob questions : )
Kai Hudalla
@sophokles73
no sweat, it is not that popular anyway so you are part of the majority ;-)
Julian
@JulianFeinauer
But I think the documentation could be improved a bit then… from my understanding the address is a fixed AMQP attribute of a message, right?
Kai Hudalla
@sophokles73
fixed?
Julian
@JulianFeinauer
I got a bit confused since I passed the „to“ and „subject“ as Message Properties to QPid (as read from the Hono docs) but it seems that qpid at least likes to have the explicit attributes „address“ and „subject“ to work
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)
Julian
@JulianFeinauer
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
Kai Hudalla
@sophokles73
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 ...
Julian
@JulianFeinauer
okay.. so in most cases I would „piggybag“ my commands to send them after I received telemetry data
But I just discovered the command router API which should be some kind of generalization of this idea, right?
Kai Hudalla
@sophokles73
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 ...
Julian
@JulianFeinauer
I see
But generally speaking I should implement some kind of „mailbox“ mechanism in my app that „buffers“ the commands (if they are NOT ephemeral)
Kai Hudalla
@sophokles73
yes, Hono does not provide such an outbox for each device.
Julian
@JulianFeinauer
got it, thanks
Slowly I start to see how we would need to modify our application to get it working on HONO
Julian
@JulianFeinauer
And regarding the relation of Hono and EnMasse… in a scalable setup we would use an EnMasse „controlled“ infrastructure as Broker and Dispatcher and not the single containers provided with the Helm Chart?
Kai Hudalla
@sophokles73
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 ...
Julian
@JulianFeinauer
Ah, so all communication woudl then be done via Kafka Topics basically?
Kai Hudalla
@sophokles73
Julian
@JulianFeinauer
yes, I saw it in the docu but did not have a deeper look. What about the internal APIs? Would these still be AMQP?
Kai Hudalla
@sophokles73
If by "internal" you mean between protocol adapters and device registry, then the answer is yes. However, these components talk to each other directly, i.e. they do not need the Dispatch Router ...
9 replies
Kai Hudalla
@sophokles73
@/all I am now starting the 1.9.1 release build ...
Kai Hudalla
@sophokles73
@/all 1.8.3 and 1.9.1 have been released successfully ... The Hono helm chart has also already been updated accordingly
Anoop Kumar
@anoopk30
Hello, I want to know whether we can connect Eclipse Hono with Eclipse Kapua along with Eclipse Kura?