@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
@BobClaerhout the problem you are running into is already addressed in #2960
@calohmn How about reviewing/approving my PR ;-)
@calohmn How about reviewing/approving my PR ;-)
you too
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)?
@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?
@/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?
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).
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=comUpdated 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>
@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?
@b-abel Could you test this as well?
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?
@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?
@/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
@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?
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?
@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.
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 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.
@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.
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.
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.
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
@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.
@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)
@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?
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?
@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.
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.
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.