Update README.

master
flabbergast 4 years ago
parent c938813938
commit d75eb8e569
  1. 23
      README.md

@ -22,14 +22,31 @@ The aim of this project is to provide a single binary daemon, which listens on a
This program is written in [rust], which is excellent in producing single static binaries which can be just copied around; and it is also very simple to cross-compile (e.g. using [this docker setup](https://github.com/messense/rust-musl-cross), I compile on my laptop and just copy the resulting binary to [my pocket beagle](https://flabbergast.drak.xyz/posts/pb-rfmcape/)).
One drawback is that the "decoding the gateway messages" bit is hardcoded into the program (see `sensordata.rs` and `decode_jee.rs` source files), so if anyone wants to use this, they will need to have a look at the code and modify for their own sensor types/
devices.
One drawback is that the "decoding the gateway messages" bit is semi-hardcoded into the program (see `sensordata.rs` and `decode_jee.rs` source files), so if anyone wants to use this, they will need to have a look at the code and modify for their own sensor types/devices.
I wrote this program primarily for myself and my own small sensor network (and as a thing for learning [rust]), and I have no illusions about anyone else using this ;) So hardcoding the sensors was good enough for me. Also, because of the brutal ease of cross-compiling and having a single binary daemon with no dependencies, I do not feel compelled to implement some complicated sensordata configuration system.
However, once the appropriate _device types_ are hardcoded, the actual list of devices is configurable at runtime via the configuration file.
I wrote this program primarily for myself and my own small sensor network (and as a thing for learning [rust]), and I have no illusions about anyone else using this ;) So hardcoding the sensor types was good enough for me. Also, because of the brutal ease of cross-compiling and having a single binary daemon with no dependencies, I do not feel compelled to implement some complicated sensordata configuration system.
## configuration
Various parameters can be configured when the program is run, in one of the three-and-a-half ways, listed here in decreasing order of priority (i.e. the top ones override the bottom ones):
* _Command line parameters_: run `jeethru -h` to get the full list with short descriptions and defaults.
* _Environment variables_: the possibilities and the format are the same as above, the variable names have the format `JEETHRU_[OPT]`, where `[OPT]` is capitalised full name of a command line parameter. For example `JEETHRU_HOST_MQTT=10.0.0.1`.
* _Configuration file_: the default name is `jee_config.yml` (this is possible to override with a command line parameter). It is in YAML format, and the possibilities and format are the same as above.
* _Defaults_: hardcoded into the binary.
There are a few exceptions to this scheme:
* _Logging verbosity_: only settable as a command line parameter (the more `-v`'s appear, the more verbose the program is).
* _Configuration file path/name_: only settable as a command line parameter.
* __Device list__: only settable in the configuration file. See the supplied `jee_config.yml` for the expected format. This also means that if the configuration file is missing, no devices will be configured, and so effectively no message decoding will happen (however the rest of the features will work, so e.g. one-to-many port multiplexing, or publishing raw messages to MQTT).
* And one quirk: The `toggle_*` switches toggle some feature (e.g. publishing to MQTT broker); all of these features are disabled by default. These are evaluated as follows: `cmdline_switch XOR (env_var OVERRIDES cfg_file)`. (An example: If `cmdline_switch` is _set_, `env_var` is not present and it is _set_ in `cfg_file`, the feature ends up disabled.)
## miscellaneous operational details

Loading…
Cancel
Save