@/all I will start the 1.8.3 build now ...
So i thought it might be „special“ fixed properties but it seems thats just an issue of qpid and not of Hono
From my understanding, it should be a valid AMQP message if I pass a
properties dict with keys to and subject but it seems that qpid wants it as separate properties address and subject directly (see here: https://qpid.apache.org/releases/qpid-proton-0.32.0/proton/python/docs/proton.html#proton.Message)
Another question regarding the command and control API from HONO. If the application wants to send a command to a device… it needs to implement a strategy to basically „retry“ it until it gets an answer accepted (and even if that, in case of one-way it needs to hope that it worked). Or is there anything more „intelligent“ that works with all adapters (in case of HTTP it could simply react to a message received event with a
ttd set
The "ttd" mechanism works for all protocol adapters. See https://www.eclipse.org/hono/docs/1.8/concepts/device-notifications/ An application simply need to check the ttd application property in messages from devices in order to determine if the device can currently accept commands ...
But I just discovered the command router API which should be some kind of generalization of this idea, right?
it depends. If a device maintains a permanent subscription for commands, e.g. using MQTT or AMQP 1.0, then your application can send commands at any time after it has received a notification containing a ttd value of -1 and before receiving a message with ttd = 0. For devices using stateless protocols like HTTP or CoAP, the application can send commands after it has received a message containing a ttd > 0 and before the ttd has been reached ...
But generally speaking I should implement some kind of „mailbox“ mechanism in my app that „buffers“ the commands (if they are NOT ephemeral)
Slowly I start to see how we would need to modify our application to get it working on HONO
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 ...
Yes. For that purpose we have also defined kafka based versions of the north bound APIs (e.g. https://www.eclipse.org/hono/docs/1.9/api/kafka-api/ and https://www.eclipse.org/hono/docs/1.9/api/telemetry-kafka/ and https://www.eclipse.org/hono/docs/1.9/api/command-and-control-kafka/)
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
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"
@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 : )
@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
thank you!
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:
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?
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?
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.