[TerkinTelemetry] Renovations to improve the library interface, and to make things work #80
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
About
In order to do the right thing, this patch renovates the TerkinTelemetry library a bit. It also adds a README, and runnable example programs, aiming to make it a first citizen of the library code provided by this repository, alongside the BERadio C++ and TerkinData C++ libraries.
Synopsis
Transmit sensor measurement readings from Arduino and libc environments, for humans. 1
telemetry->transmit(measurement);
Details
The library is still in its infancy, being very much work in progress, but at least this patch is another iteration which actually makes a few things work, where they did not work beforehand. While working on this iteration, I've adjusted a few class names, and removed one layer of indirection.
Now, there are three classes you will use to configure a telemetry client instance, each with a specific subset of connectivity parameters. This design aims to make the library as modular as intended, without overcomplicating it.
ChannelAddress
: You will use it to define the data acquisition channel your device will submit data to. It reflects the venerable quadruple hierarchic addressing scheme we are using for connecting, addressing, and mapping individual sensor node devices in a wide-area scenario.XyzTransmitter
: You can select one of the available transmitter components, in order to define which kind of outbound transport you are intending to use. There are different kinds of transmitter components included into TerkinTelemetry, but it is possible to bring your own.TelemetryClient
: The telemetry client instance your code will interact with, in order to actually submit measurement/metric values, after reading your sensors.I am not sure this will turn out well, but it is worth to explore. More details are available on our discussion forum at 2.
Usage
Setup
Collect and transmit
/cc @msweef, @einsiedlerkrebs, @wetterfrosch, @Tonkenfo, @thiasB, @ClemensGruber, @marcelgasser, @rohlan
Footnotes
The idea of TerkinTelemetry is to bring the flexibility of the telemetry subsystem of the Terkin MicroPython Datalogger on behalf of the
self.device.telemetry.transmit(dataframe)
within itstransmit_readings()
method, to the Arduino ecosystem. ↩https://community.hiveeyes.org/t/telemetriesubsystem-fur-arduino-firmwares-generalisieren/181/14 ↩