Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 17 15:19
    codecov[bot] commented #1707
  • Jan 17 14:02
    codecov[bot] commented #1713
  • Jan 17 13:41
    codecov[bot] commented #1683
  • Jan 17 13:41
    eriksven synchronize #1683
  • Jan 17 13:26
    sophokles73 commented #1676
  • Jan 17 13:24
    sophokles73 commented #1707
  • Jan 17 13:22
    codecov[bot] commented #1707
  • Jan 17 13:22
    sophokles73 synchronize #1707
  • Jan 17 13:18
    sophokles73 closed #1296
  • Jan 17 13:18
    sophokles73 commented #1296
  • Jan 17 13:09
    calohmn commented #1700
  • Jan 17 13:06
    sophokles73 commented #1700
  • Jan 17 13:04
    sophokles73 demilestoned #1693
  • Jan 17 12:27

    sophokles73 on master

    Use HTTP based readiness/livene… Use standard health check port … (compare)

  • Jan 17 12:26
    sophokles73 review_requested #1713
  • Jan 17 12:26
    sophokles73 labeled #1713
  • Jan 17 12:26
    sophokles73 milestoned #1713
  • Jan 17 12:26
    sophokles73 opened #1713
  • Jan 17 12:14
    alinaserg opened #1712
  • Jan 17 11:44

    sophokles73 on master

    [#1296] Improve documentation f… [#1296] Add support for Auto-Pr… [#1296] Support Auto-Provisioni… (compare)

Kai Hudalla
@sophokles73
I have successfully built 1.0.1. The web site should pick up the changes a part of the nightly web site build job. I will send out an announcement mail tomorrow ...
Steffen Schmid
@YoLieR

Hey guys,
we recently updated our Hono installation from v.0.8 to v.1.0.1. In this process we also wanted to switch from the deprecated AMQP control topics to the new command topic for our Command&Control workflow.

We adjusted the application on our device to receive commands on the command topic but we now don't get any commands from the AMQP adapter. The commands, in our case, get published to the Hono dispatch-router from Ditto via a connectivity-mapping. We adjusted that mapping to publish messages to command/TENANT_ID/DEVICE_ID as well.

Are there any additional adjustments that we need to make in order to receive on the command topic? The release-notes for Hono 1.0.M5 state that the topics have just been renamed..
I would appreciate any tips. Thx :).

Btw.: the old control topics still works...
Kai Hudalla
@sophokles73
Can you verify that you can send a (one-way) command to your device using just Hono and the CLI as described in the getting started guide?
Steffen Schmid
@YoLieR
java -jar target/hono-cli-*-exec.jar \
    --hono.client.host=hono-dispatch-router.OUR_DOMAIN \
    --hono.client.username=user-application@HONO \
    --hono.client.password=PASSWORD \
    --spring.profiles.active=command,ssl
I tried to publish a command to the dispatch router like so but only got SSL errors. Is there a way to see in the log that a command was received by hono? I don't see anything in the dispatch router or the AMQP adapter.
Kai Hudalla
@sophokles73
Does your Hono instance expose its north bound endpoints via TLS?
Carsten Lohmann
@calohmn
As far as I know there is an issue currently in Ditto that the AMQP to property of the command message is always tied to the AMQP link address. That means that the to property, as contained in the message reaching the AMQP adapter, doesn't contain the expected address (ending in a device id).
That issue is tracked here: eclipse/ditto#540
Steffen Schmid
@YoLieR
Ok. And that means that the AMQP adapter doesn't know to which device he has to deliver the message!?
Carsten Lohmann
@calohmn
Yes. In the AMQP adapter log there should be such an entry: "address of command message is invalid"
Steffen Schmid
@YoLieR
Ran into a failure when publishing signal: Failed to send message: Timed out waiting for credit to send Message - Message headers: [message-id=command-and-control, content-type=application/vnd.eclipse.ditto+json, reply-to=control/TENANT/replies, subject=startMeasurement, correlation-id=command-and-control]
If I enable the ditto connection logs I see the following error in the publish phase ... this then could occur because the message never was delivered!?
Hmm there is no message address of command message is invalid in our log. The message from ditto should be credited by the dispatch-router right?!
Carsten Lohmann
@calohmn
yes, there should be credit there, that's strange.
Steffen Schmid
@YoLieR
Ok thanks anyhow. We will look further into it at a later point and fallback to control for now.
Karthees Kalidass
@kaniyan
@sophokles73 @ctron Would you mind taking a look at this https://github.com/eclipse/hono/issues/1287#issuecomment-552511128 regarding the device connection time.
Kai Hudalla
@sophokles73
Hi community, do we want to do our community call today? Any pressing issues you would like to discuss? Otherwise we can cancel as Dejan is at KubeCon and will probably not participate and Jens seems to be offline for other reasons ...
Thomas Jaeckle
@thjaeckle
Hi Hono devs. I did not find a (documented) way in order to provide a "correlation-id" or "message-id" as header when sending telemetry or events from devices.
Is there no possibility to do this? I would like to use this for a test of a Hono-Ditto integration in order to ensure that messages can be correlated across systems.
Kai Hudalla
@sophokles73
@thjaeckle not sure what you are up to. Do you want a device to include a correlation-id in its telemetry message that it uploads to a protocol adapter and then want that id end up in the downstream AMQP message's correlation-id property?
Thomas Jaeckle
@thjaeckle
yes, or in the "message-id" property which currently also contains some sort of correlating id (but I guess set by an AMQP component)
Kai Hudalla
@sophokles73
what is the purpose of doing that?
Thomas Jaeckle
@thjaeckle
correlating requests sent via telemetry to responses sent back via one-way-commands ;)
even when not doing request-response (which I know is not yet supported): it would be helpful to use same correlation-ids in order to track down errors when using Hono + Ditto in combination
even better when the device can choose a correlation-id (e.g. always with a prefix) in order to e.g. find log entries related to such IDs
Kai Hudalla
@sophokles73
ok, not all protocols support the concept of headers vs body, e.g. in MQTT, such properties would need to be encoded in the topic name. Apart from that, Hono does not (yet) generically support the inclusion of "headers" provided by a device in downstream AMQP messages. A generic approach would most likely only support inclusion in AMQP application-properties. Setting the correlation-id would require the definition of a "special" header that we suppirt on all protocol adapters
It would probably be easier to implement this in the message payload, i.e. introduce a structure that distinguishes between meta info (headers) and payload ...
Thomas Jaeckle
@thjaeckle
ok, I get that - sending headers in the payload is of course possible, I just thought that we could influence the "message-id" which we receive for Hono telemetry messages
Kai Hudalla
@sophokles73
I also wonder if it feasible to define the forwarding of client provided headers in commands as a supported concept. Not sure if we could implement this for all protocols ...
BTW we currently use the presence of a correlation-id in a command message as an indicator that this is in fact a request/response command (instead of a one-way command) ...
Thomas Jaeckle
@thjaeckle
hm, for HTTP custom headers would be really cool as default headers like "content-type" or "ETag" or other caching headers might become really useful
ah, I thougt Hono uses the reply-to header as indication that this is a request/response command
Kai Hudalla
@sophokles73
you are right, of course, we use the reply-to header ... it's getting late
Thomas Jaeckle
@thjaeckle
ok, all good then :)
Kai Hudalla
@sophokles73
Can you open an issue for this in Hono? We can then track this better ...
Thomas Jaeckle
@thjaeckle
sure
Kai Hudalla
@sophokles73
@ctron Hi Jens, IIRC you wanted to set up a Doodle poll for finding a date/time for the IoT Packages call/meeting, right?
Jens Reimann
@ctron
Yes, I did that … everyone voted :D
it is today … 16:00 CET
Kai Hudalla
@sophokles73
Except for me, because I didn't follow the issue closely enough?
Jens Reimann
@ctron
sorry, that may be … I only know that Carsten can't join today, he is out of office IIRC
there is also a calendar with the invite
I did however forget to add this to the homepage.
Kai Hudalla
@sophokles73
no worries, found it ...
Kai Hudalla
@sophokles73
@dejanb Hi Dejan, have you been able to take a look at #1647 ?
Dejan Bosanac
@dejanb
@sophokles73 just briefly ... I plan to work on it tomorrow
Kai Hudalla
@sophokles73
cool
Kai Hudalla
@sophokles73
@ctron @dejanb @calohmn It looks like there is only a single place where we still use code from Google Guava: some toString() methods in the Device Registry helper classes. I wonder if we can remove that dependency altogether from Hono ... WDYT?
Jens Reimann
@ctron
hm … while I like the "ToStringHelper" stuff, guava's dependencies are sometimes tricky, so getting rid of it might be a good idea :+1:
that would be a change for 1.1?
Kai Hudalla
@sophokles73
I guess so. Guava is not part of any of our public APIs AFAIK
Dejan Bosanac
@dejanb
+1
Carsten Lohmann
@calohmn
I'm also for removing it then.