RFM69 Jeenode gateway output relay and processing
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Go to file
flabbergast 9014700f79
Bump version (0.0.15) - breaking changes in params and config.
5 years ago
src Encapsulate params into struct, print as info. 5 years ago
.gitignore wip, with clap. 6 years ago
Cargo.lock Bump version (0.0.15) - breaking changes in params and config. 5 years ago
Cargo.toml Bump version (0.0.15) - breaking changes in params and config. 5 years ago
LICENSE Add readme and license. 5 years ago
README.md Implement basic packed decoding checks. 5 years ago
jee_config.yml Read params also from config file. 5 years ago



The "usual" (well, mine anyway) small sensor network layout using jeenodes:

{{jeenode sensor(s)...}} <~~[radio]~~>

  <~~> {{jeenode gateway}} <--UART-->

      /--------------- computer ---------------\
  <-->|{ser2net}  <--TCP--> {jeethru} <-> .... |

The aim of this project is to provide a single binary daemon, which listens on a TCP port (with the expectation of incoming jeenode gateway messages), processes them (i.e. decodes the RF12demo-formatted messages into meaningful sensor data), and then pushes them further. The output options are:

  • Another TCP port. This works as a simple forwarder, i.e. no decoding is done and the incoming messages are just relayed further. This relaying actually works both ways (i.e. also towards the jeenode gateway). However this daemon accepts more than one simultaneous connection (so it can act as a multiplexer for ser2net, which is usually used to relay the UART/serial messages from the gateway to/from TCP).
  • Plain CSV files (one line per reading, one file per type).
  • Publish MQTT messages (this is also potentially two-way, but the "to gateway" direction is not implemented yet).
  • Insert into MongoDB database.

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, I compile on my laptop and just copy the resulting binary to my pocket beagle).

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.

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.

miscellaneous operational details

The program panics/errors out in some cases and does not in some others. In particular:

  • If binding to any of the ports (incoming, outgoing) fails on startup, the program ends.
  • The program ends "naturally" when the incoming port closes.
  • If MongoDB is enabled and the connection to the database and/or posting a record to it fails, the whole program panics.
  • If writing to csv is enabled and writing to a file fails, the whole program panics.
  • If MQTT is enabled and the initial connection to the server fails, the program fails; however a failure of an individual publish message is only logged and the program continues.
  • If decoding of an incoming message (from the gateway) fails at any point (e.g. "not-a-message", "not-enough-bytes", "corrupted-data"), it is simply logged and ignored further.


The project is licensed under MIT license.