rtlamr-collect provides data aggregation for rtlamr. This tool in tandem with rtlamr provides easy and accurate data collection.
- GoLang >=1.9.2 (Go build environment setup guide: http://golang.org/doc/code.html)
- rtlamr
- InfluxDB >=1.4.2
Downloading and building rtlamr-collect is as easy as:
go get github.com/bemasher/rtlamr-collect
This will produce the binary $GOPATH/bin/rtlamr-collect. For convenience it's common to add $GOPATH/bin to the path.
Provisioning influxdb can be done using the included initial schema and Chronograf's explore tab and the queries given in init.iql.
init.iql contains schema for creating the database rtlamr and three retention policies:
- 1 week for initial data (default).
- 30 days for 1 hour intervals.
- 5 years for 1 day intervals.
All data written by rtlamr-collect occurs in the rtlamr measurement.
rtlamr-collect is entirely configured through environment variables:
COLLECT_INFLUXDB_HOSTNAME=https://localhost:8086/InfluxDB hostname to write data to.COLLECT_INFLUXDB_DATABASE=rtlamrInfluxDB database to connect to.COLLECT_INFLUXDB_USER=usernameInfluxDB username to authenticate with.COLLECT_INFLUXDB_PASS=passwordInfluxDB password to authenticate with.COLLECT_STRICTIDM=1Ignores IDM with type 8 and NetIDM with type 7. This should probably always be enabled if you are simultaneously listening to IDM and NetIDM.
At a minimum rtlamr must have the following environment variables defined:
RTLAMR_FORMAT=jsonrtlamr-collect input must be json.RTLAMR_FILTERID=000000000List your meter id's here separated by commas. This is not strictly necessary, but it is highly recommended. Promiscuously listening to all the meters in a given area is likely to have high series cardinality and will negatively impact InfluxDB's performance.
rtlamr-collect should take its input directly from the output of an rtlamr instance through a pipe.
$ rtlamr | rtlamr-collectrtlamr-collect reads messages serialized as json from stdin. All new data points are written to the rtlamr measurement in InfluxDB with 1s resolution.
All messages include the following tags:
protocol: One of SCM, SCM+, IDM, NetIDM, R900, R900BCD.msg_type: Either differential or cumulative.endpoint_type: The meter's commodity type.endpoint_id: The meter's serial number.
Meters transmitting cumulative messages such as SCM, SCM+, R900, and R900BCD will insert only a single new point per message. These messages include only a single field consumption.
Meters transmitting differential messages such as IDM and NetIDM will insert a point for each differential interval the message contains, timestamped based on the interval. Fields included are consumption and interval. State for each meter is maintained so that only data for new intervals is sent to the database. On startup, rtlamr-collect will gather this state for all of the previously seen differential meters to avoid duplicating data between runs.
Scaling received data so that it represents real units depends on the meter being monitored and is left as an exercise to the user.
Data visualization is left as an exercise for the user. I have had a good experience with grafana, however Chronograf and others should work equally well.
If you have any general questions or feedback leave a comment below. For bugs, feature suggestions and anything directly relating to the program itself, submit an issue in github.