Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[hono-dev] Hono CLI proposal part 2 - sender

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



Back to the top