Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:40
    johnMinelli synchronize #1811
  • Apr 04 08:19
    sophokles73 commented #1848
  • Apr 04 08:19
    sophokles73 commented #1732
  • Apr 04 08:18
    sophokles73 commented #1665
  • Apr 04 07:31
    sathishreddynsr commented #1665
  • Apr 04 07:31
    sathishreddynsr commented #1732
  • Apr 04 07:31
    sathishreddynsr commented #1848
  • Apr 03 17:29

    sophokles73 on master

    [#1679] Update device informati… (compare)

  • Apr 03 17:29
    sophokles73 closed #1876
  • Apr 03 17:29
    sophokles73 milestoned #1876
  • Apr 03 17:28
    sophokles73 labeled #1876
  • Apr 03 17:28

    sophokles73 on master

    [#1679] Pull up a method to che… (compare)

  • Apr 03 17:28
    sophokles73 closed #1877
  • Apr 03 17:28
    sophokles73 milestoned #1877
  • Apr 03 17:28
    sophokles73 labeled #1877
  • Apr 03 16:16
    kaniyan edited #1877
  • Apr 03 16:16
    kaniyan review_requested #1877
  • Apr 03 16:16
    kaniyan opened #1877
  • Apr 03 15:49
    kaniyan opened #1876
  • Apr 03 15:49
    kaniyan review_requested #1876
Dejan Bosanac
@dejanb
@sophokles73 shouldn't we be doing 1.1.0-M1?
Kai Hudalla
@sophokles73
@dejanb 1.1.0-M1 is not a release by means of the Eclipse Foundation. The way to deliver bug fixes to users is by means of service releases, e.g. 1.0.1 or 1.0.2. These service releases then replace the original 1.0.0 release in terms of "this is the recommended version to use (and download)".
Dejan Bosanac
@dejanb
@sophokles73 sure ... just wanted to make sure you actually wanted to create a service release ... when should we schedule 1.1.0-M1 then?
Kai Hudalla
@sophokles73
@dejanb based on our discussion regarding branching strategy, I created the following release plan: https://projects.eclipse.org/projects/iot.hono/releases/1.1.0/plan
It is based on the assumption, that we want to do a milestone every four weeks ...
Dejan Bosanac
@dejanb
@sophokles73 great ... looks good
Kai Hudalla
@sophokles73
@dejanb so, what do you think about the service release?
Dejan Bosanac
@dejanb
@sophokles73 +1
Kai Hudalla
@sophokles73
@dejanb @ctron I would like to start the 1.0.1 service release build this afternoon. Anything else that should be in it from your point of view?
Dejan Bosanac
@dejanb
@sophokles73 nothing from me
Jens Reimann
@ctron
no … :+1:
Dejan Bosanac
@dejanb
anybody up for a community call?
@/all ^^
Kai Hudalla
@sophokles73
@dejanb sorry, I came back late from another meeting. Nothing special from me except for the 1.0.1 release ...
Dejan Bosanac
@dejanb
@sophokles73 cool ... no worries
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