eclipse/hono

Connect. Command. Control.

Kai Hudalla

@sophokles73

Keep us posted ...

Bob Claerhout

@BobClaerhout

is currently using 269Mi while the limit is 300Mi so pretty certain that's the issue. Changed now, will see if this helps

Bob Claerhout

@BobClaerhout

small update on this: the device registry was restarting roughly every 8 hours and didn't restart in the last 19h so looks promissing. Will give another update after the weekend

Kai Hudalla

@sophokles73

thanks @BobClaerhout

Bob Claerhout

@BobClaerhout

no restarts over the weekend, so that seemed to be the problem. I raised the memory limit to 500Mi

Kai Hudalla

@sophokles73

500Mi should be (much) more than sufficient, but if you can spend the memory ...

Bob Claerhout

@BobClaerhout

The request is still at 300Mi but the limit is now set to 500Mi. Are you running with 300Mi limit?

Karthees Kalidass

@kaniyan

Hi, Unfortunately, I won't be able to attend our today's community call.

Amable Valdés

@amable_alisys_gitlab

Good morning everyone,

I seek your advice. We have a project in which we communicate devices with Eclipse Ditto via websocket. We liked this approach because of the speed of sending telemetry updates (every few milliseconds) from devices on an already established connection.

Now we wanted to add Hono eclipse, but Hono apparently doesn't have a WebSocket adapter. How would you deal with this situation? Would you do messages go over HTTP? Would you use MQTT instead? Or is there a faster alternative for constant telemetry updates every few milliseconds? Would it be worth creating your own WebSocket adapter?

Kai Hudalla

@sophokles73

You can use any of Hono's supported device protocols. That includes the ones you already mentioned (HTTP, MQTT) but also AMQP 1.0 and CoAP. For a device that needs to transmit telemetry at that rate, I would suggest to use a protocol with a stateful connection like MQTT or AMQP 1.0. If you are only sending telemetry and do not care if once in a while a message gets dropped/lost, then MQTT with QoS 0 should work well for you. If you need more sophisticated message exchange handling with acknowledgments then AMQP 1.0 might be the better choice. CoAP could also be a good alternative. It runs via UDP (instead of TCP) and has been designed in particular for constrained devices. However, if your device sends at that rate then it is most likely not constrained, is it? Or at least it is not constrained regarding power supply ...

Amable Valdés

@amable_alisys_gitlab

Thanks for your quick response. It has been useful to us; After reading you, we believe that the MQTT approach is the most appropriate in this case, thanks ^. ^

Yes! One of the devices that we have connected is not an embedded constrained by regarding power supply. It's "more like" an AMRs (Autonomous Mobile Robot). This device will not have problems in terms of connection or computing power, so it is feasible to use MQTT.

Thank you very much!

Kai Hudalla

@sophokles73

You're welcome. Let us know if Hono works for your use case ....

Anoop Kumar

@anoopk30

Hello, I am new to Eclipse Hono. I am able to connect my raspberry Pi 4 with eclipse hono installed on my Ubuntu machine on minikube using nginx reverse port forwarding. I can communicate in between using amqp. But I am facing trouble while connecting it to Eclipse Kura. It shows connected status for 2-3 second then disconnect. Could you tell me how to connect eclipse hono with Kura on local network?

Kai Hudalla

@sophokles73

What version of Kura are you using?

Anoop Kumar

@anoopk30

4.1.2

Kai Hudalla

@sophokles73

Then you should be able to connect to Hono's MQTT adapter using Kura's Eclipse Cloud Connection type

Anoop Kumar

@anoopk30

Could you provide me steps for doing it?

Kai Hudalla

@sophokles73

http://eclipse.github.io/kura/cloud-stacks/kura-hono.html

Anoop Kumar

@anoopk30

Thanks, I am able to make connection between them.

Kai Hudalla

@sophokles73

That's good to hear :-)

Bob Claerhout

@BobClaerhout

@calohmn , considering your remarks on eclipse/packages#279, I've updated the PR accodring to what I understood from your remarks. Can you have a look and verify whether this is what you were aiming for?

Anoop Kumar

@anoopk30

I am not receiving any log in Eclipse Hono Example Client 1.9.0 when I tried to publish data using mosquitto_pub command. It is working fine when I use curl command.

Anoop Kumar

@anoopk30

I have solved this problem.

Anoop Kumar

@anoopk30

How can I subscribe to topic other than telemetry?? When I tried mosquitto_sub command, it's showing "All Subscription Access Were Denied".

Kai Hudalla

@sophokles73

A device cannot subscribe to any other topic than the command topic which it uses to receive command messages from back end applications. The MQTT adapter is not an MQTT broker but simply supports the MQTT 3.1.1 protocol to exchange messages with devices. Please also refer to the MQTT adapter user guide (https://www.eclipse.org/hono/docs/user-guide/mqtt-adapter/) for information regarding subscribing to the command topic.

Anoop Kumar

@anoopk30

Ok, thanks.

Julian

@JulianFeinauer

Good Morning people : )

Julian

@JulianFeinauer

I observed a strange behavior when using eclipse hono via eclipse ditto (through the cloud2edge kubernetes package). I subscribed with a „device“ to receive commands via MQTT but the topic I got the command at was missing a „/„, so it was ${request-id}replies… instead of ${request-id}/replies (so the slash was missing)

Kai Hudalla

@sophokles73

@JulianFeinauer Hi Julian, hope you're doing well :-) Can you post the topic that you used to subscribe to commands? Where did the commands originate from? Is there a north bound application which sends the command or is that a command that originates from Ditto?

Julian

@JulianFeinauer

@sophokles73 thanks, I’m well, yes, I hope you are too!

I was following the guide from here https://www.eclipse.org/packages/packages/cloud2edge/tour/ ("Sending a command to the device via its digital twin“)

I was subscribing command///req/#

And the command was sent via ditto

curl -i -X POST -u ditto:ditto -H 'Content-Type: application/json' -w '\n' --data '{
  "water-amount": "3liters"
}' http://xxx:8080/api/2/things/org.acme:my-device-1/inbox/messages/start-watering?timeout=60

Julian

@JulianFeinauer

Here is the response I get

(you could also try it out yourself as my test cluster is public…)

Kai Hudalla

@sophokles73

I see. Which version of the chart are you using? In particular, which version of Hono and Ditto is being installed?

Kai Hudalla

@sophokles73

I am not 100% sure but it looks like ....replies is actually the reply-id being used by Ditto. It may look strange but the Hono MQTT adapter user guide does not specify a separate replies segment in the command topic. Are you able to actually PUBLISH a response to the command using the reply-id ending in ...replies?

Julian

@JulianFeinauer

no.. I am unable to reply no matter what kind of topic I sue

let me check

The Helm Chart is 0.2.1

Kai Hudalla

@sophokles73

The response would need to be published to command///res/${req-id}/${status} with ${req-id} being the string ending in ...replies and ${status} being an HTTP status code ...

9 replies

Julian

@JulianFeinauer

Ditto is 2.0.1 and Hono is 1.8.0

Julian

@JulianFeinauer

Slightly related question… If I want to try out command & control without Ditto but with „plain hono“, how can I create credentials for an „application“ (the north bound site)? Did I miss that in the documentation?

I am able to write code that works with the sandbox (where the credentials are known) but with my cloud2edge setup I am missing that

This has to be configured in the dispatch router (qpid?), or?

Julian

@JulianFeinauer

ah, nvm… found it

Kai Hudalla

@sophokles73

@/all I would like to do 1.9.1 and 1.8.3 service releases today. Anything else you need to have in there?

Julian

@JulianFeinauer

I only have another question (regarding 1.8.0): I am now able to get the „north“ side running via AMQP but I do not yet get a command message sent to a client (client via HTTP adapter). I try to do the whole thing without ditto, so HONO only. Just to ensure that I got everything right:

Application creates a connection and a sender link to target command/{self.tenant}/{self.deviceId}
Application creates a receiver link to target telemetry/{self.tenant}
Client sends a telemetry with header hono-ttd and wait time in seconds
When my application receives the message it can send the command as message witth properties properties={"to": f"command/{self.tenant}/{self.deviceId}", "subject": "work“} via above sender link

Julian

@JulianFeinauer

The message does neither get rejected, released nor accepted (amqp side) nor does the client receive it (answer is 202) and I dont see errors in the logs

Where communities thrive

People

Repo info

Activity