Hello,
as part 2 of my proposals for a cli for Hono here are the feature ideas for a sender, that I would like to have.
*****************
Sender:
A sender IMHO should have some (limited) capabilities of simulating a (not too big) swarm of devices inside one tenant.
To keep things simple and flexible for the user (developer or DevOps engineer mainly) this is my proposal:
a) use application.yml of SpringBoot for configuration of the swarm (easy to implement)
Example see below.
b) define the payload with Apache velocity (alternative if this dependency is not desired: simple own substitution implementation)
- have variables inside the payload at arbitrary places
c) a small set of supported values that can be used for the substitution variables
- COUNTER: just counts the nr of messages sent so far
- TIMESTAMP: system time in millis
- RANDOM(lower,upper): a random number inside [lower,upper]
- CONSTANT: a constant string
d) simple time based repetition for each device:
- repetition interval defined in milliseconds
- max number of repetitions (infinite also possible)
e) should be contained as a submodule in Hono
Lineout of configurations:
*************************
1) Example device swarm definition (part of application.yml):
honoSenderConfig :
name: myDevSwarm
devices:
- device:
- name: espDevice1
- deviceId: "espDevice1.9786F4EA4711"
- payload:
- path: /home/user/.hono/sender/payloads/espPayload.vm
- substitutes:
- key: lightSensorValue
value: COUNTER
- key: temperatureSensorValue
value: RANDOM(15,26)
- key: humiditySensorValue
value: RANDOM(10,65)
- device:
- name: xdkDevice
- instances: 20
- deviceId: "xdkDevice1.9786F4EA4712"
- payload:
- path: /home/user/.hono/sender/payloads/xdkPayload.vm
- substitutes:
- key: substKey
value: CURRMILLISECS
- device:
- name: raspiDevice1
- deviceId: "raspiDevice1.9786F4EA4713"
- payload:
- path: /home/user/.hono/sender/payloads/raspiPayload.vm
- substitutes:
- key: substKey
value: RANDOM(1,1000)
2) Example payloads:
/home/user/.hono/sender/payloads/espPayload.vm:
{
light: ${lightSensorValue},
temperature: ${temperatureSensorValue},
humidity: ${humiditySensorValue}
}
The template engine (or own implementation) would substitute the values for each device before sending them out.
***********************
Intentionally not included in this proposal:
- multiple senders simulating a load
- parallel groups of senders
- metrics and reporting of fully equipped loadtest tools like JMeter, Gatling, etc.
Main goal is to have a sender cli that is not too complicated but can do much more than the simple examples available so far.
What do you think?
Thanks
Karsten