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,
Sebastian
Mit freundlichen Grüßen / Best regards
Sebastian Schuster
INST/ESY1
Tel. +49 30 726112-485
Fax +49 30 726112-100
www.blog.bosch-si.com
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
Hello,
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):
Consumers:
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?
Thanks
Karsten
