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_PLAINTEXTThis configuration just works for the spring container but doesn't seem to work with the quarkus container. Anyone experiencing the same things?
Which Hono version do you use?
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
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
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.
But we are not doing any integration tests with the Lora adapter. So I am not 1005 sure if this should indeed work.
@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?
@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.