Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:38
    boaks synchronize #1762
  • 13:37
    b-abel commented #1765
  • 13:35
    b-abel synchronize #1765
  • 09:14
    jbtrystram edited #1776
  • 09:11
    jbtrystram review_requested #1776
  • 09:11
    jbtrystram review_requested #1776
  • 09:11
    jbtrystram opened #1776
  • Feb 18 20:12
  • Feb 18 16:07
    ctron opened #1775
  • Feb 18 15:29
    b-abel synchronize #1765
  • Feb 18 15:10
    jbtrystram synchronize #1769
  • Feb 18 12:05
    BobClaerhout synchronize #1773
  • Feb 18 12:04
    BobClaerhout synchronize #1773
  • Feb 18 10:54
    b-abel commented #1773
  • Feb 18 10:22
    dejanb commented #1727
  • Feb 18 10:14
    BobClaerhout commented #1773
  • Feb 18 10:01
    dejanb labeled #1774
  • Feb 18 10:00
    dejanb edited #1774
  • Feb 18 09:59
    dejanb opened #1774
  • Feb 18 09:58
    BobClaerhout review_requested #1773
Carsten Lohmann
@calohmn
+1
victormartinezjurado
@victormartinezjurado
Dear all,
First of all, apologies in advance if this is not the right channel to ask this question, but here we go . We are evaluating hono as an iot as a service platform , but one of the doubt I still haven't figure it out is how could we integrate one of our devices to hono http Adapters. The device in question, is an electronic lock tracker (JT701) with internet connectivity using Jt600 protocol. Unfortunately for us, we can not change the device in order to use hono API (neither http or mqtt) Could you let me know how would be the approach to connect the device to eclipse hono using the Adapter mechanism ?
Thanks in advance!
Dejan Bosanac
@dejanb
@victormartinezjurado one option would be to implement adapter for this particular protocol
Kai Hudalla
@sophokles73
@victormartinezjurado Hi Victor, welcome to the Hono community :-) Asking here is totally appropriate. However, I can also image that the answer to your question would be of interest to other people having a similar problem, i.e. connecting devices that do not speak HTTP or MQTT or AMQP. For those, it would be best if you could post the question on stackoverflow because then it would be easily found by a Google search. So it is up to you, would you mind spending the time posting to stackoverflow?
victormartinezjurado
@victormartinezjurado
Kai Hudalla
@sophokles73
@victormartinezjurado great :-)
victormartinezjurado
@victormartinezjurado
@dejanb Hi dejan, thanks for your answer! I'm redirecting the convesation as suggested by Kai to stack overflow.
Dejan Bosanac
@dejanb
@victormartinezjurado cheers ... that's great ... welcome to the community :)
Kai Hudalla
@sophokles73
@ctron would you mind taking a look at #1604 ?
Kai Hudalla
@sophokles73
@dejanb @calohmn @ctron I would like to do a 1.0.1 release this week including the fixes from the 1.0.1 project board. WDYT?
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 ...