Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:24
    kaniyan synchronize #2985
  • 15:17
    kaniyan synchronize #2985
  • 14:04

    calohmn on master

    Fix handling of periodic commit… (compare)

  • 14:04
    calohmn closed #2978
  • 13:46
    calohmn milestoned #2983
  • 13:46
    calohmn labeled #2983
  • 13:46
    calohmn assigned #2983
  • 13:27
    kaniyan labeled #2985
  • 13:26
    kaniyan milestoned #2985
  • 13:26
    kaniyan review_requested #2985
  • 13:26
    kaniyan review_requested #2985
  • 13:26
    kaniyan opened #2985
  • 10:54
    calohmn edited #2837
  • 10:54
    calohmn milestoned #2984
  • 10:54
    calohmn labeled #2984
  • 10:54
    calohmn opened #2984
  • 09:42
    b-abel opened #2983
  • 09:14

    calohmn on master

    Add Command Router to 'Getting … (compare)

  • 09:14
    calohmn closed #2982
  • 07:02
    calohmn review_requested #2982
Kai Hudalla
@sophokles73
@BobClaerhout can you create an issue and a corresponding PR?
Bob Claerhout
@BobClaerhout
Kai Hudalla
@sophokles73
@/all I would like to start planning for Hono 2.0.0. Most imminent questions FMPOV are: 1) release time frame and 2) breaking changes.
Personally, I would like to see the 2.0.0 release by end of Q1 2022. At a minimum I would like to remove the already deprecated components/modules like the client module, the Device Connection service, the File based registry and the Spring Boot based variants of the components. However, we should also take the opportunity to introduce other breaking changes to existing external APIs that we consider helpful/necessary. Thoughts?
Oh, and I think we should remove support for Java 8 from the core module and upgrade to Java 17 code level.
Kai Hudalla
@sophokles73
@b-abel There are currently four PRs addressing #2837 and it is kind of hard to keep track. Are they all still relevant/required or can you maybe close some of them?
2 replies
Bob Claerhout
@BobClaerhout
Hi all, as you know we are installing our IoT solution on customers private clouds. This means we also would like to rely on the managed kafka cluster from the customer. However, this means we won't always have access to create topics (which used by the adapter for the internal topics). My understandig is that it is currently not possible to provide the used topics for internal commands. Is this correct? If so, might it be an idea to provide these topics somehow so the customer can manually create the topics and we do not need the permission to create them automatically? WDYT?
Kai Hudalla
@sophokles73
The problem is that the names of these topics are specific to the protocol adapter instance and are therefore determined dynamically during runtime, taking into account the name of the container that the adapter is running in. @calohmn any idea how to address this?
Carsten Lohmann
@calohmn
I think this is a valid point to bring up. I had thought about different alternatives to these dynamic topic names already, but all had their challenges. @BobClaerhout I think it would be best if you could create a Github issue for this. Then we can develop ideas there.
Bob Claerhout
@BobClaerhout
sure, I'll create one. A first step in the right direction might be to configure it but when you do, you can't have multiple adapters of the same type, since that would cause these both adapters to be reading the same topic. Anyway, I'll create an issue
Abel Büchner-Mihaljević
@b-abel
Wasn't it once discussed in a community call that we also want to offer (via configuration) the possibility that all protocol adapters receive commands via a single topic. Or do I remember that wrong?
Bob Claerhout
@BobClaerhout
Kai Hudalla
@sophokles73
@b-abel That was indeed one of the discussed options, in particular for use cases where you do not expect that many commands to be sent and therefore can afford to simply ignore the commands in adapter instances that the target device is not connected to. However, IIRC we decided to start with implementing the more general approach that we now have. Maybe you can add a pointer to the original issue in #2920 ?
Abel Büchner-Mihaljević
@b-abel
Kai Hudalla
@sophokles73
@b-abel exactly
Simon Mayer
@pragmayticer
Hi guys I'm a college of @JulianFeinauer . We use hono for device registration and other admin issues. I have a question about the topics. Can I subscribe to every topic e.g(myHouse or machine/4711) or just these three(command,telemetry and event) ?
Abel Büchner-Mihaljević
@b-abel
Hi @pragmayticer! Are you referring to MQTT topics or Kafka topics? And are you thinking about the device side or the northbound business application?
Simon Mayer
@pragmayticer
MQTT/ AMQP Topics. Well both sides. I want my own topics, first to subscribe on the northbound business application and the device should logically send to my custom topics......
Abel Büchner-Mihaljević
@b-abel
This is not supported. Hono uses the fixed topic names and AMQP addresses that are part of its API. If you want to use different MQTT topics, you could use a Protocol Gateway. You'll find a template for an MQTT Protocol Gateway in https://github.com/eclipse/hono-extras/tree/master/protocol-gateway/mqtt-protocol-gateway-template
Simon Mayer
@pragmayticer
ah okay, Thank you!
Julian
@JulianFeinauer
Thanks @b-abel! @pragmayticer we have to distinguish the messages by subject or on the payload level
Kai Hudalla
@sophokles73
With MQTT you can also use a property bag that you append to the topic name as outlined here. This way, you can for example include a content-type that you can then use for message routing in your downstream application. With AMQP 1.0 it is easier as it natively supports message properties (including content-type and other standard properties).
Kai Hudalla
@sophokles73
@JulianFeinauer Hi Julian, have you seen the new Eclipse Kanto project proposal? Given your interest in ioFog in the past, I wonder if this might be of interest to you as well? Let me know if you would like to know more about it. I can then get you in touch with the project lead ...
Bob Claerhout
@BobClaerhout
Goodmorning all, I'm running into an issue with the kerlink lora adapter. It looks like the implementation in hono doesn't comply with the kerlink version (anymore) used by our customers (a newer one, don't know exactly which one but content-type is different and payload has another structure as well). It was added in '19 and it doesn't like anyone has made any functional changes to this provider.
How do we cope with this? Do I create a new provider which includes a version somewhere or do I just update this provider according to the message I'm receiving now?
Besides this example with kerlink I'm expecting these issues to be popping up in the future for other providers as well so I think we should carefully think about this. For that, my preference goes to adding a version in the path somewhere. WDYT?
Kai Hudalla
@sophokles73
@BobClaerhout If the content-type is different then you could also handle/parse the incoming message differently based on the content-type only, i.e. without the need for introducing new endpoint URIs.
Bob Claerhout
@BobClaerhout
That's a good idea. It will, however, require some changes in the structure of the adapter as well since it currently only expectes 1 content type and add routes based on the path
Kai Hudalla
@sophokles73
I am not 100% sure but I guess you can also add routes for a combination of path and content-type and register different handlers for them.
Bob Claerhout
@BobClaerhout

I just tried running the lora quarkus adapter in combination with kafka and I ran into following misconfiguration exception:

MessagingClientProviders.MessagingClientProviders
        if (!telemetrySenderProvider.containsImplementations()) {
            throw new IllegalArgumentException("at least one TelemetrySender implementation must be set");
        }

Is the kafkaconfiguration different in the quarkus container compared to the spring one?

When I look at the secret, I'm seeing following configuration:

hono:
  kafka:
    defaultClientIdPrefix: adapter-lora-vertx
    commonClientConfig:
      bootstrap.servers: <bootstrap>:9092
      sasl.jaas.config: org.apache.kafka.common.security.scram.ScramLoginModule required
        username="<username>" password="<password>";
      sasl.mechanism: SCRAM-SHA-512
      security.protocol: SASL_PLAINTEXT

This configuration just works for the spring container but doesn't seem to work with the quarkus container. Anyone experiencing the same things?

Bob Claerhout
@BobClaerhout
Ah, it looks like other configuration changes are required aside from just using the quarkus image. Can somebody confirm this?
Abel Büchner-Mihaljević
@b-abel
@BobClaerhout I have not tried this lately but there has been some refactoring lately. It would be great if you could report any bugs or inconsistencies you encounter.
Which Hono version do you use?
Bob Claerhout
@BobClaerhout
Hi @b-abel , thanks for you response, I didn't have the time yet to fully convert from the spring images to the quarkus ones.
Following happened: I updated the kerlink adapter to support the new kerlink format (eclipse/hono#2937). I was building the image myself and thought: ah, why not try the quarkus one. I configured the lora adapter to use the quarkus image but this wasn't working (didn't do any change besides that one... I think that was my mistake).
I build the spring image and that image just works properly.
Both images are build from the latest master while the rest of the images are still using 1.10.0
Kai Hudalla
@sophokles73
Does the Lora provider actually start up using your custom built Quarkus based image? If so, I assume that it fails during start up with some error message(s) in the log? If so, can you post the output?
Bob Claerhout
@BobClaerhout
No, it doesn't startup. I'm getting following exception immediatly: 2021-11-15 08:26:04,529 ERROR [io.qua.run.Application] (main) Failed to start application (with profile prod): java.lang.IllegalArgumentException: at least one TelemetrySender implementation must be set. But I saw the quarkus images need slightly different configuration as well so I think the test doesn't tell us anything. I'll try running the quarkus images again later with all hono configuration (in the helm chart) set to quakus as well compared to only changing the image.
Kai Hudalla
@sophokles73
Actually, I am not aware of any additional config properties required when using the Quarkus images instead of the Spring Boot based images.
But we are not doing any integration tests with the Lora adapter. So I am not 1005 sure if this should indeed work.
Bob Claerhout
@BobClaerhout
ok, I'll test it once again and let you know if it succeeded
Carsten Lohmann
@calohmn
@BobClaerhout I couldn't reproduce the lora adapter issue, testing with current Hono master (I had to remove the "hono.kafka.defaultClientIdPrefix" property - see eclipse/hono#2960). The error you mentioned is raised when the "bootstrap.servers" property isn't defined or empty. I don't see an issue with your config above, but anyway, maybe you can try setting the value in quotes?
Bob Claerhout
@BobClaerhout
@calohmn , thanks for looking into this and your patience. I tried again just now and I encounter following exception when running the lora adapter:
io.smallrye.config.ConfigValidationException: Configuration validation failed:
        hono.kafka.defaultClientIdPrefix does not map to any root
        at io.smallrye.config.ConfigMappingProvider.mapConfiguration(ConfigMappingProvider.java:855)
        at io.smallrye.config.ConfigMappingProvider.mapConfiguration(ConfigMappingProvider.java:811)
        at io.smallrye.config.SmallRyeConfigBuilder.build(SmallRyeConfigBuilder.java:403)
        at io.quarkus.runtime.generated.Config.readConfig(Config.zig:1222)
        at io.quarkus.deployment.steps.RuntimeConfigSetup.deploy(RuntimeConfigSetup.zig:42)
        at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:326)
        at io.quarkus.runtime.Application.start(Application.java:101)
        at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:105)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:66)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:42)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:119)
        at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:48)
        at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:25)
All other services run just fine in quarkus
Bob Claerhout
@BobClaerhout
It's fair to say that the lora images is an image I build myself based on master. i'll try and cherry-pick my changes on the latest stable version and build it again now
Kai Hudalla
@sophokles73
@BobClaerhout the problem you are running into is already addressed in #2960
@calohmn How about reviewing/approving my PR ;-)
Bob Claerhout
@BobClaerhout
Thanks @sophokles73 , building from your branch now. 1.10.0 still had the required tenantConfig
Bob Claerhout
@BobClaerhout
FYI: the new container boots just fine
Bob Claerhout
@BobClaerhout
running on our dev cluster now. Thanks for the quick responses, enjoy your weekend
Kai Hudalla
@sophokles73
oyu too
you too
Sascha Seegebarth
@SSeegebarth_twitter
Hi, I am just starting with IoT platforms and would like to start with a capstone project with some students. The goal of the project is to have some sensors connected to hone / ditto and display the sensor data. The students shall present the project and therefore I would like to work with some concrete hardware. Do you have some suggestion regarding some IoT devices which are easy to use?
Another question: Starting with the topic and reading through the documentation / blogs / git docu from eclipse, bosch and pragmatic I wonder if there are more tutorials about how to start and setup the environment? Unfortunately I couldn't find a book about it. Do you have sometimes hand on workshops (like a installation party in earlier days)?
Kai Hudalla
@sophokles73
@SSeegebarth_twitter sorry for the late reply. Thanks for considering Hono for your curriculum :-) I guess when it comes to IoT devices that are easy to use it depends on what you (or your students) would consider easy to use, i.e. what level of experience can you build upon. I am not an expert when it comes to sensor HW but in general I would think that you get the most flexibility and community support for Arduino based devices. Regarding your second question: sadly but truly, Hono doesn't seem to have gained enough popularity so far for a book to have been written about it. However, are you aware of the Eclipse Packages project which hosts the Helm charts for the Eclipse IoT projects and which also contains a chart for the Cloud2Edge package which installs Eclipse Hono and Ditto in a ready to use, pre-configured setup. This might be a good starting point for your students to use?