Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:26
    calohmn review_requested #3274
  • 08:26
    calohmn review_requested #3274
  • 08:26
    calohmn review_requested #3274
  • 08:26
    calohmn review_requested #3274
  • 08:26
    calohmn labeled #3274
  • 08:26
    calohmn milestoned #3274
  • 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
  • May 20 12:01
    calohmn labeled #3272
Bob Claerhout
@BobClaerhout
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?
Kai Hudalla
@sophokles73

@/all I am currently struggling a little with configuring the Organize Imports functionality within the Eclipse IDE to be consistent with the Checkstyle configuration that we use. For type imports, we enforce the separation of import groups:

import java.lang.String;

import org.eclipse.hono.util.TenantObject;

However, for static imports we don't:

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static com.google.common.truth.Truth.assertThat;

It is not possible to configure the separation of import groups separately in Eclipse IDE. With the current Checkstyle configuration, whenever I hit Ctrl+O in order to automatically fix the imports in a class, I need to manually fix the static imports. This is quite annoying, so if it doesn't pose a problem to anybody, I would like to adapt our Checkstyle configuration to require separated static import groups as well and would adapt the code base accordingly.

Thoughts?

Kai Hudalla
@sophokles73
@calohmn @kaniyan ^^^
Carsten Lohmann
@calohmn
In Intellij IDEA, I also struggle with the static imports - but here the issue is that the Eclipse Code Formatter plugin doesn't apply the correct order, so that I manually have to move the "Truth" import. Can you post the envisioned changes to the checkstyle-config (and to the "hono.importorder" file, if any) ? Then I can test it (also using an updated Eclipse Code Formatter plugin).
Kai Hudalla
@sophokles73

hono.importorder:

#Organize Import Order
#Thu Dec 02 11:50:14 CET 2021
0=\#java
1=\#javax
2=\#org
3=\#com
4=java
5=javax
6=org
7=com

Updated ImportOrder check in Checkstyle config:

    <module name="ImportOrder">
      <property name="groups" value="/^java\./,javax,org,com"/>
      <property name="ordered" value="true"/>
      <property name="separated" value="true"/>
      <property name="option" value="top"/>
      <property name="staticGroups" value="/^java\./,javax,org,com"/>
      <property name="separatedStaticGroups" value="true"/>
      <property name="sortStaticImportsAlphabetically" value="true"/>
    </module>
Carsten Lohmann
@calohmn
@sophokles73 Yes, that works for me. The Eclipse Code Formatter plugin applied the intended order and separation (had to make sure the changes to the "hono.importorder" file got seen by selecting a different file first and then switching back).
@b-abel Could you test this as well?
Abel Büchner-Mihaljević
@b-abel
@sophokles73 @calohmn This solves the problem for me too in IntelliJ IDEA. This is a real improvement!
Kai Hudalla
@sophokles73
@kaniyan any opinion?
Karthees Kalidass
@kaniyan
@sophokles73 Thanks for brining it up and I also now and then faced this issue. +1 from my side for the proposed changes.
Kai Hudalla
@sophokles73
Ok, then I will push the corresponding changes ...
Mike
@klankster
Hi all together. I was playing around with the x.509 device authentication, and it worked great so far, but my use case is a little different from what I played around with yet, and I'm not sure if it's possible? Instead of creating device certificates and issuing them to the devices, I need to get certificates created independently on the devices and added to the device registration. They don't have a common CA, but I would need them under the same tenant ideally. Is that possible in the current version? If so, how? As I tried some things and couldn't get it to work. And if not, are there plans to add this feature in the future?
Kai Hudalla
@sophokles73

@klankster When you say

certificates created independently on the devices

do you mean certs that have been self-signed on/by the devices? My understanding is that you can not or do not want to register the trust anchors with the tenant. If so, what kind of authentication do you have in mind here? How could the protocol adapter authenticate the device if it does not have any knowledge about the issuer of the device certificates?

nehasewda
@nehasewda
Hi,
Kai Hudalla
@sophokles73
@/all I would like to do the 1.9.2 and 1.10.1 bug fix releases next week. Anything you need in there in addition to what we already have on the project boards? https://github.com/eclipse/hono/projects
Mike
@klankster
@sophokles73 yes, I mean self-signed on the device. my initial idea was, that the devices create the certificate on their side, then you just have to transfer the certificate to the server side and add it to the credentials of the device without any need of a common tenant CA for all devices. But I realized I had a misunderstanding and there aren't any certificate credentials stored on the device level, except the subject.
My new idea, I haven't had the chance to test yet, is that the devices create a tenant key and cert, matching the tenant planned to used for the devices. Then create the necessary key and cert for the device, signed by the tenant CA and used as credentials. After that, transfer the tenant cert to the server and add all the tenant CA certificates to the tenant. Would that be a possible solution?
Kai Hudalla
@sophokles73
@klankster I am afraid that I do not really understand why you do not simply create certificates for the devices using one or a few CAs which you register with the tenant. Why does every device need to create its own CA certificate? if you have that much control over the devices to implement your idea, then I do not quite see why you couldn't go the standard way as well. I seem to be missing something here ...
That said, there is no limit on the number of trust anchors that can be registered for a tenant. So, for a not too large number of devices, your approach of registering a CA per device should work, but I haven't tried it.
zhaoruijun201
@zhaoruijun201
How does Eclipse Hono implement a custom TCP/IP protocol
Kai Hudalla
@sophokles73
@zhaoruijun201 You can add support for custom protocols by means of implementing a Protocol Gateway. Hono's GitHub repository contains an example gateway implementation that might serve as a blueprint.
zhaoruijun201
@zhaoruijun201
@sophokles73 thank you
Mike
@klankster
@sophokles73 yeah thanks, I have tried this a little and everything worked like expected, which wasn't too bad. but as already expected, it is nowhere near practicable for the fact alone that there is no real option to add/remove tenant CAs without committing a full list of CAs as it was never intended for this use case.
and I know that this use case is somewhat special, but this is because everything happens after the device is already "out in the field". so several third parties install new firmware to the devices and provide the created device certificate to us, so no keys have to be transferred. if a device change its maintenance staff, they can easily create new certificates with the new firmware and provide us with the new certificate file to change it.
Kai Hudalla
@sophokles73
So, if I understand correctly, what you would rather do is compare the client certificate's public key with a public key that you have registered for the device and if they match you consider the device authenticated, right?
Mike
@klankster
@sophokles73 yes and use the tenants just as a collection of devices rather than a CA
Kai Hudalla
@sophokles73
I guess you could add this kind of functionality to the X509CertificateSecret and then create a new X509Authentication implementation that compares the public key from the device's client certificate to the public key registered for the device cert's subject DN. Note that in this case there is no validation of the device certificate's signature anymore because there is no trust anchor. But I guess that is acceptable in this use case.
Mike
@klankster
@sophokles73 thanks, I will take a look at this
LOorts-Aloxy
@LOorts-Aloxy
Hi! I'm adding some functionality to TheThingsStackProvider to include downlinks. However, the api needs the LoRaWAN port to also be included in the request. Our application doesn't really use any specific port so for me it's ok to assign this a constant but I can imagine others might want to change this in the downlink. Should this be configurable in the implementation or can I just add it as a constant? I've also noticed the loriotProvider-implementation doesn't include the port while the official api (https://docs.loriot.io/display/LNS/Downlink+Data+Message) does. Am I missing something here?
1 reply
Kai Hudalla
@sophokles73
@LOorts-Aloxy where could the port number come from? My understanding is that the port is supposed to give an indication of the context that the consumer should interpret the message payload in (kind of like a numerical method/subject name).
LOorts-Aloxy
@LOorts-Aloxy
@sophokles73 this is true but the same can be said for the sensor itself, a downlink to a certain port can result in a different result than the same downlink to a different port. So ideally, the port should be configurable somewhere but for our personal case, any port is sufficient. However, the API needs a port to be present or it will not accept the command.
Kai Hudalla
@sophokles73
@LOorts-Aloxy wouldn't it then make sense to be able to set the port number in the context of the command itself? Or would it be sufficient to set a fixed port number to be used for all commands at the adapter level?
LOorts-Aloxy
@LOorts-Aloxy
ideally, we would idd set the port number in the context of the command itself
Kai Hudalla
@sophokles73
Given that the downlink interface does not support a subject property, I can imagine that the port number could be provided in the command's subject. WDYT @LOorts-Aloxy ?
LOorts-Aloxy
@LOorts-Aloxy
@sophokles73 you mean in the payload? or where would this be provided in practice?
Kai Hudalla
@sophokles73
@LOorts-Aloxy No, we could use the command message's subject property (see https://www.eclipse.org/hono/docs/api/command-and-control-kafka/#send-a-one-way-command)
LOorts-Aloxy
@LOorts-Aloxy
@sophokles73 right, that idd sound like a good idea, thanks!
LOorts-Aloxy
@LOorts-Aloxy
@sophokles73 I updated eclipse/hono#3008 to use the subject's property for the port number. However, I'm not fully sold on the content of the subject as it's now just the port. Could you maybe take a look at it and perhaps propose and acceptable format?
Tomasz Leszczynski
@telemetrix
HI all, we are working on the architecture for smart metering platform where the application protocol workers stay on the server side connected to the message broker. It's the opposite model to the common one where the MQTT devices are sending telemetry data in the PUSH manner. Our app approach is to establish MQTT transparent channel to the end device and then run two-way communication in the app layer protocol based on it. The question if the HONO communication model allows to make it possible?
Kai Hudalla
@sophokles73
@telemetrix Hi, I am not sure if I understand what you are trying to achieve. In Hono, the devices (in your case I assume the smart meters) establish a connection to Hono's MQTT protocol adapter and can then use this connection to publish messages which can then be consumed by downstream applications. These applications can also send commands to the connected devices via the MQTT adapter.
Tomasz Leszczynski
@telemetrix
Hi @sophokles73 thank you for the replay ... so we have considered totally different scenario where MQTT client subscribes the topic and Application protocol worker is able to connect to devices behind of MQTT client natively. It's more like establish the tunnel between the smart meter and application protocol worker. Broker is only involved in auth and transport layer then. Btw as I see MQTT in HONO isn't based on independent broker but VERTX lib instead.
Kai Hudalla
@sophokles73
Yes, Hono does not use an MQTT broker but simply lets devices connect and exchange messages via the MQTT protocol. In your setup, will the Smart Meter use the MQTT protocol to connect to an endpoint/broker?
Tomasz Leszczynski
@telemetrix
Yes smart meter itself or the external terminal/gateway by serial interface connected to the meter. Terminal connect to the broker and subscribe the right topic. On another hand there is a worker subscribed to that topic which implements the native protocol on the meter side. The MQTT client on the terminal allows to tunel the app native protocol between the worker and the meter - MODBUS as an example.
Kai Hudalla
@sophokles73
@telemetrix Well, if both the terminal/gateway and the worker in the back end only subscribe to a topic, nothing will happen because no messages are being exchanged. Both sides will need to publish messages to the topics that the other side has subscribed to. That said, if you are flexible regarding the names of the topics to publish to and subscribe from, i.e. you can live with the topic names defined by Hono, then there shouldn't be an issue using Hono for this.