Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 26 09:54
  • May 25 08:26
    calohmn review_requested #3274
  • May 25 08:26
    calohmn review_requested #3274
  • May 25 08:26
    calohmn review_requested #3274
  • May 25 08:26
    calohmn review_requested #3274
  • May 25 08:26
    calohmn labeled #3274
  • May 25 08:26
    calohmn milestoned #3274
  • May 25 08:26
    calohmn opened #3274
  • May 24 11:21

    calohmn on master

    Let properties URL input stream… (compare)

  • May 24 11:08

    calohmn on master

    Remove superfluous logger. Sig… (compare)

  • May 23 14:19
  • May 23 09:26

    calohmn on master

    Update DEPENDENCIES concerning … (compare)

  • May 20 14:12
    sophokles73 review_requested #3273
  • May 20 14:12
    sophokles73 review_requested #3273
  • May 20 14:12
    sophokles73 review_requested #3273
  • May 20 14:12
    sophokles73 review_requested #3273
  • May 20 14:12
    sophokles73 labeled #3273
  • May 20 14:12
    sophokles73 milestoned #3273
  • May 20 14:12
    sophokles73 opened #3273
  • May 20 12:01
    calohmn opened #3272
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?
Bob Claerhout
@BobClaerhout
Hi all, I've question concerning the quarkus images. Some time ago I noticed the quarkus images didn't do what I expected. Yesterday I installed the latest hono version on our test cluster and the quarkus images were used automatically. However, it seems some configuration is not passed to the container. I can't seem to find where the configuration (in code) is coming from. I found QuarkusMqttProtocolAdapterProperties but couldn't find where this was populated. Do I have to provide the configuration in a different way for these quarkus containers?
17 replies
Julian
@JulianFeinauer
Short feedback after all my struggle with the initial setup and getting everything right in my tooling we finally start to use Hono and really like it. Very well done guys (special thanks to @sophokles73 for all the help). I try to prepare a little PR with some minor updates in the documentation (things that confused me) to help others to ease their „onboarding"
Kai Hudalla
@sophokles73
@JulianFeinauer thanks for the feedback :-) A PR would be more than welcome ... Would you also mind sharing some details about your use case/scenario where you are deploying Hono?
Julian
@JulianFeinauer
@sophokles73 Of course. We have a SaaS Offering for Machine Builders (not Factories) where we give them their own whitelabeled „Portal“ to communicate with their machines as well as their clients. So one part of the system is a little bit like the Azure IoTHUB / Boschs IoT Suite but more focused on Metadata and their relation with the Machine and so on. Another crucial part for us is the data history so we rely heavily on Apache IoTDB (there were / are also discussions in the #eclipse/ditto channel about some possibilities to integrate timeseries storage with Ditto in some way)
But simply put.. we have gateways that read data from machinery (a bit like Kura) and sends them via Messaging (currently MQTT only) to our backend where we then do several things with it
And we now decided to migrate to Hono for simple scaling reasons. Not about the infrastructure but the device management as our customer base (luckily) grows : )
Kai Hudalla
@sophokles73
Awesome. Thanks @JulianFeinauer :-)
Dejan Bosanac
@dejanb
@calohmn @sophokles73 Just got the confirmation that Quarkus 2.2.x is ready and productized and will be supported long term ... Next productized version will be 2.2.3
Kai Hudalla
@sophokles73
@dejanb thanks for checking, I am already in the process of updating my PR to use 2.2.2.Final instead of 2.0.3.Final ...
Dejan Bosanac
@dejanb
@sophokles73 sounds good
Kai Hudalla
@sophokles73
@/all I would like to do the 1.10.0 release this week. Anything else you need to go into it in addition to what we already have on the project board?
2 replies
samrose
@samrose
Is it feasible to use hono outside of kubernetes? It seems so, but I wondered what knowledgeable people here think
Abel Büchner-Mihaljević
@b-abel
@samrose It is possible. There used to be deployment scripts for Docker Swarm, but they were removed a long time ago. The deployment of the sandbox VM was still running on Docker Swarm until recently. That can still be found in the Git history for inspiration: https://github.com/eclipse/hono/tree/5505c3c6f6d4cb2ba70828188c9e38af2d02f1de/deploy/src/main/sandbox
samrose
@samrose
@b-abel I was considering running this with nomad, consul cluster
thank you!
Kai Hudalla
@sophokles73
@/all I will now start the 1.10.0 release build ...
Kai Hudalla
@sophokles73
@/all Our PGP key used for creating signatures of our release artifacts has expired. I have created an issue with Eclipse webmasters to extend the key's validity. Until then we cannot publish the artifacts to Maven Central ...
Kai Hudalla
@sophokles73
@/all The 1.10.0 release build has succeeded and I have pushed the container images to Docker Hub. However, the artifacts still cannot be published to Maven Central but that shouldn't be a big issue as most people install using the container images anyway ...
Bob Claerhout
@BobClaerhout
Hi, I was trying to run the quarkus images just now (version 1.10.0) and I stumbled upon a change in the lora adapter. In the spring lora adapter I'm not obliged to confugre following property: hono.lora.commandEnabledTenants. I was wondering why this is required in the quarkus version?
As you might imagin, I would not like to change my deploy because I'm adding a new tenant. Why can't the lora adpater look at the gateways with a commandEndpoint and add those dynamically to the used tenants?
Kai Hudalla
@sophokles73
This is probably a bug in the LoraProtocolAdapterOptions configuration class where the corresponding property is not optional. Anyway, it looks like LoraProtocolAdapterProperties.getCommandEnabledTenants() is never used anywhere in the Lora adapter so I guess we can simply remove the configuration property altogether.
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).