Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Hono CLI proposal part 1 - consumer

Hi Karsten,


I do agree that development support for testing consumptions would be cool to have but I am not sure whether

implementing what you described as filtering is really worth it.


How about just defining a line format that’s easily greppable (device id, payload) and then use the typical

Unix tools (grep, uniq, etc.) on that? I assume performance is not a big issue when developing…


Best regards,



Mit freundlichen Grüßen / Best regards


Sebastian Schuster



Tel. +49 30 726112-485

Fax +49 30 726112-100


Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im Auftrag von Frank Karsten (INST/ECS4)
Gesendet: Montag, 20. März 2017 16:43
An: hono-dev@xxxxxxxxxxx
Betreff: [hono-dev] Hono CLI proposal part 1 - consumer



after Hono was very successfully used during a large hackathon, I would like to start a proposal for a commandline client.

Current situation is:
- we have the example clients in the maven submodule struture (as we all know)
- we have a tutorial how to embed HonoClient for a sender and for a consumer in arbitrary Java-Code (as described on the website)

Especially a consumer is essential for quickly checking if your payload (via MQTT, via REST, via LWM2M, via self-coded AMQP1.0, ...)
is reaching the receiving solution correctly.

I see a gap so far in the support of users that want to watch their devices, developers that want to watch the payloads to develop solutions on them
and DevOps engineers that need automated checks if their system is delivering the correct data.

This IMHO should at least be available in Hono via a commandline tool.

Since senders and consumers offer different ways of improvements, I like to separate the discussion into two points (consumers contained here):


Main target for now should (still) be the pure printing of the messages, BUT:

Missing is mostly the filtering possibilities to narrow the amount of data that is printed.


Following feature proposals:

a) regex filter for deviceIds: only devices which have a deviceId that matches the given regex are printed

b) regex filter for payloads: only payloads that match the given regex are printed

c) interactive mode:

- start and stop of listening collects all devices that sent data in that interval

- you then can decide which of the seen devices you want to watch (like you do with git when you squash commits e.g.):
-- usage of an editor that is called with the collected devices line by line
-- leave the lines with the desired devices active (like in git)
-- after write and quit this is stored to a NAMED configuration inside ~/.hono

- after doing that you get messages only for the selected devices

d) usage of previously selected devices of interactive mode:
- use the name that previously was stored via c)
- the content is taken from the file under ~/.hono

e) all should be contained in a submodule of Hono

What do you think?


Back to the top