mirror
/
wmbusmeters
kopia lustrzana https://github.com/weetmuts/wmbusmeters
1
0
Forkuj 0
Kod Zgłoszenia Projekty Wydania Wiki Aktywność

Updated README

pull/42/head
weetmuts 2019-10-24 21:06:33 +02:00
rodzic 6e9a6e33e2
commit bfc3ba14af
4 zmienionych plików z 42 dodań i 99 usunięć
Pokaż statystyki Ściągnij plik aktualizacji Ściągnij plik porównania Expand all files Collapse all files

13
Makefile
Wyświetl plik

@ -82,7 +82,7 @@ $(info Building $(VERSION))
CXXFLAGS := $(DEBUG_FLAGS) -fPIC -fmessage-length=0 -std=c++11 -Wall -Wno-unused-function -I$(BUILD)
$(BUILD)/%.o: src/%.cc $(wildcard src/%.h)
$(CXX) $(CXXFLAGS) $< -c -E > $@.src
@#$(CXX) $(CXXFLAGS) $< -c -E > $@.src
$(CXX) $(CXXFLAGS) $< -MMD -c -o $@
METER_OBJS:=\
@ -144,9 +144,18 @@ wmbusmeters_$(DEBVERSION)_$(DEBARCH).deb:
@echo Built package $@
@echo But the deb package is not yet working correctly! Work in progress.
$(BUILD)/wmbusmeters: $(METER_OBJS) $(BUILD)/main.o
$(BUILD)/main.o: $(BUILD)/short_manual.h
$(BUILD)/wmbusmeters: $(METER_OBJS) $(BUILD)/main.o $(BUILD)/short_manual.h
$(CXX) -o $(BUILD)/wmbusmeters $(METER_OBJS) $(BUILD)/main.o $(DEBUG_LDFLAGS) -lpthread
$(BUILD)/short_manual.h: README.md
echo 'R"MANUAL(' > $(BUILD)/short_manual.h
sed -n '/wmbusmeters version/,/```/p' README.md \
| grep -v 'wmbusmeters version' \
| grep -v '```' >> $(BUILD)/short_manual.h
echo ')MANUAL";' >> $(BUILD)/short_manual.h
$(BUILD)/testinternals: $(METER_OBJS) $(BUILD)/testinternals.o
$(CXX) -o $(BUILD)/testinternals $(METER_OBJS) $(BUILD)/testinternals.o $(DEBUG_LDFLAGS) -lpthread

21
README.md
Wyświetl plik

@ -95,7 +95,6 @@ using `sudo killall -HUP wmbusmetersd` or `killall -HUP wmbusmeters`
depending on if you are running as a daemon or not.
# Running without config files, good for experimentation and test.
```
wmbusmeters version: 0.9.15
Usage: wmbusmeters {options} <device>{:suffix} ( [meter_name] [meter_type]{:<modes>} [meter_id] [meter_key] )*
@ -127,16 +126,15 @@ As <options> you can use:
For the <device> you can add a suffix: /dev/ttyUSB0:amb8465 to
specify which wmbus dongle is connected to that device.
Supported wmbus dongles are: IMST 871a (i, Amber 8465, RFM-RX2 and
Supported wmbus dongles are: IMST 871a, Amber 8465, BMeters RFM-RX2.
If you specify a baudrate as a suffix: /dev/ttyUSB0:38400 then wmbusmeters will
simple listen to that serial port with that baudrate and expect raw
wmbus telegrams.
As a <device> you can also use: auto which will look for the
links /dev/im87a,/dev/amb8475,/dev/rfmrx2 and /dev/rtlsdr (the links are
automatically generated by udev if you have run the install scripts.)
and start wmbusmeters with the proper tty device or rtlwmbus background process.
links /dev/im871a, /dev/amb8465, /dev/rfmrx2 and /dev/rtlsdr (the links are
automatically generated by udev if you have run the install scripts)
As a <device> you can also use: rtlwmbus
to spawn the background process: "rtl_sdr -f 868.95M -s 1600000 - | rtl_wmbus"
@ -178,10 +176,16 @@ Heat meter Kamstrup Multical 302 (multical302)
Electricity meter Kamstrup Omnipower (omnipower)
```
The wmbus dongles imst871a can only listen on one type of wmbus telegrams at a time.
Thus you can listen to multiple meters as long as they all require the same radio mode C1 or T1.
The wmbus dongles imst871a can listen to one type of wmbus telegrams
at a time, ie either C1 or T1 telegrams. Thus you can listen to
multiple meters as long as they all require the same radio mode C1 or
T1.
However if you use amb8465 or rtlwmbus, then you can listen to both C1 and T1 telegrams at the same time. Alas rtl_wmbus does have problems receiving C1 telegrams, T1 telegrams work ok though.
However if you use amb8465 or rtlwmbus, then you can listen to both C1
and T1 telegrams at the same time. Unfortunately the original version
of rtl_wmbus (`https://github.com/xaelsouth/rtl-wmbus.git`) cannot
reliably listen to C1 telegrams, but the fork
`https://github.com/afflux/rtl-wmbus.git` can!
# Usage examples
@ -273,7 +277,6 @@ will listen and print the header information of any telegram it hears.
You must specify the listening mode.
With an rtlwmbus or amb8465 dongle: `wmbusmeters --listento=c1,t1 auto`
(Alas rtl_wmbus does have problems receiving C1 telegrams, T1 telegrams work ok though.)
With an imst871a dongle: `wmbusmeters --listento=c1 auto`

84
src/main.cc
Wyświetl plik

@ -79,87 +79,9 @@ provided you with this binary. Read the full license for all details.
}
if (cmdline->need_help) {
printf("wmbusmeters version: " VERSION "\n");
const char *msg = R"MANUAL(
Usage: wmbusmeters {options} <device>{:suffix} ( [meter_name] [meter_type]{:<modes>} [meter_id] [meter_key] )*
As <options> you can use:
--addconversions=<unit>+ add conversion to these units to json and meter env variables (GJ)
--debug for a lot of information
--exitafter=<time> exit program after time, eg 20h, 10m 5s
--format=<hr/json/fields> for human readable, json or semicolon separated fields
--json_xxx=yyy always add "xxx"="yyy" to the json output and add shell env METER_xxx=yyy
--listento=<mode> tell the wmbus dongle to listen to this single link mode where mode can be
c1,t1,s1,s1m,n1a,n1b,n1c,n1d,n1e,n1f
--listento=c1,t1,s1 tell the wmbus dongle to listen to these link modes
different dongles support different combinations of modes
--c1 --t1 --s1 --s1m ... another way to set the link mode for the dongle
--logfile=<file> use this file instead of stdout
--logtelegrams log the contents of the telegrams for easy replay
--meterfiles=<dir> store meter readings in dir
--meterfilesaction=(overwrite|append) overwrite or append to the meter readings file
--meterfilesnaming=(name|id|name-id) the meter file is the meter's: name, id or name-id
--oneshot wait for an update from each meter, then quit
--reopenafter=<time> close/reopen dongle connection repeatedly every <time> seconds, eg 60s, 60m, 24h
--separator=<c> change field separator to c
--shell=<cmdline> invokes cmdline with env variables containing the latest reading
--shellenvs list the env variables available for the meter
--useconfig=<dir> load config files from dir/etc
--verbose for more information
For the <device> you can add a suffix: /dev/ttyUSB0:amb8465 to
specify which wmbus dongle is connected to that device.
Supported wmbus dongles are: IMST 871a (i, Amber 8465, RFM-RX2 and
If you specify a baudrate as a suffix: /dev/ttyUSB0:38400 then wmbusmeters will
simple listen to that serial port with that baudrate and expect raw
wmbus telegrams.
As a <device> you can also use: auto which will look for the
links /dev/im87a,/dev/amb8475,/dev/rfmrx2 and /dev/rtlsdr (the links are
automatically generated by udev if you have run the install scripts.)
and start wmbusmeters with the proper tty device or rtlwmbus background process.
As a <device> you can also use: rtlwmbus
to spawn the background process: "rtl_sdr -f 868.95M -s 1600000 - | rtl_wmbus"
You can also use: rtlwmbus:868.9M to use this fq instead. Fq tuning can sometimes
be necessary. Or you can specify the entire background process command line: "rtlwmbus:<commandline>"
As meter quadruples you specify:
<meter_name> a mnemonic for this particular meter
<meter_type> one of the supported meters
(can be suffixed with :<mode> to specify which mode you expect the meter to use when transmitting)
<meter_id> an 8 digit mbus id, usually printed on the meter
<meter_key> an encryption key unique for the meter
if the meter uses no encryption, then supply ""
Supported water meters:
Kamstrup Multical 21 (multical21)
Kamstrup flowIQ 3100 (flowiq3100)
Sontex Supercom 587 (supercom587)
Sensus iPERL (iperl)
Apator at-wmbus-16-2 (apator162) (non-standard protocol)
Water meter Techem MK Radio 3 (mkradio3) (non-standard protocol)
Supported heat cost allocators:
Qundis Q caloric (qcaloric)
Innotas EurisII (eurisii)
Supported heat meter:
Heat meter Techem Vario 4 (vario451) (non-standard protocol)
Supported room sensors:
Lansen Thermometer/Hygrometer (lansenth)
Bmeters RFM-AMB Thermometer/Hygrometer (rfmamb)
Supported electricity meters:
Tauron Amiplus (amiplus) (includes vendor apator and echelon)
Work in progress:
Heat meter Kamstrup Multical 302 (multical302)
Electricity meter Kamstrup Omnipower (omnipower)
)MANUAL";
puts(msg);
const char *short_manual =
#include"short_manual.h"
puts(short_manual);
}
else
if (cmdline->daemon) {

23
wmbusmeters.1
Wyświetl plik

@ -3,7 +3,7 @@
wmbusmeters \- listen to wireless mbus radio traffic and relay the decoded telegrams to other software
.SH SYNOPSIS
.B wmbusmeters [options] <device> (<meter_name> <meter_type>[:<mode>] <meter_id> meter_key>)*
.B wmbusmeters [options] <device>{:suffix} (<meter_name> <meter_type>[:<mode>] <meter_id> meter_key>)*
.B wmbusmetersd <pid_file>
@ -11,7 +11,7 @@ wmbusmeters \- listen to wireless mbus radio traffic and relay the decoded teleg
Wmbusmeters acquires wmbus telegrams, decodes them and relays them to
some other software for further processing. It can for example listen
to radio traffic using dedicated wmbus dongles like (im871a/amb8465)
to radio traffic using dedicated wmbus dongles like (im871a/amb8465/rfmrx2)
or a generic software defined radio dongle (rtl_sdr).
After the received telegram has been decrypted and parsed, it can then
@ -29,6 +29,8 @@ mqtt_publish) sent to a REST API (eg curl) or store it in a database
\fB\--format=\fR(hr|json|fields) for human readable, json or semicolon separated fields
\fB\--json_xxx=yyy\fR always add "xxx"="yyy" to the json output and add shell env METER_xxx=yyy
\fB\--listento=\fR<mode> listen to one of the c1,t1,s1,s1m,n1a-n1f link modes.
\fB\--listento=\fR<mode>,<mode> listen to more than one link mode at the same time, assuming the dongle supports it.
@ -47,6 +49,8 @@ mqtt_publish) sent to a REST API (eg curl) or store it in a database
\fB\--oneshot\fR wait for an update from each meter, then quit
\fB\--reopenafter=\fR<time> close/reopen dongle connection repeatedly every <time> seconds, eg 60s, 60m, 24h
\fB\--separator=\fR<c> change field separator to c
\fB\--shell=\fR<cmdline> invokes cmdline with env variables containing the latest reading
@ -59,10 +63,13 @@ mqtt_publish) sent to a REST API (eg curl) or store it in a database
.SH DEVICES
.TP
\fB/dev/ttyUSB0\fR to which an im871a or amb8456 dongle is attached
\fB/dev/ttyUSB0\fR to which an im871a or amb8456 dongle is attached and let wmbusmeters detect the type.
.TP
\fBauto\fR look for /dev/im871a or /dev/amb8465 or /dev/rtlsdr (these will only show up automatically if the appropriate udev rules have been installed)
\fB/dev/ttyACM0:rfmrx2\fR when an rfmrx2 dongle is attached to this tty.
.TP
\fBauto\fR look for /dev/im871a, /dev/amb8465, /dev/rfmrx2 or /dev/rtlsdr (these will only show up automatically if the appropriate udev rules have been installed)
.TP
\fBrtlwmbus\fR use software defined radio rtl_sdr|rtl_wmbus to receive wmbus telegrams.This defaults to 868.95MHz, use for example \fBrtlwmbus:868.9M\fR to tune the rtl_sdr dongle to slightly lower frequency.
@ -85,12 +92,12 @@ This is necessary since an apator162 can be configured to send either c1 or t1 t
.SH EXAMPLES
.TP
Listen to T1 traffic using a wmbus dongle attached to ttyUSB0.
Listen to C1 and T1 traffic using a wmbus dongle attached to ttyUSB0.
% wmbusmeters --t1 /dev/ttyUSB0
% wmbusmeters --listento=c1,t1 /dev/ttyUSB0:amd8465
.TP
Listen to C1 traffic and assume that a wmbus dongle is either /dev/im871a or /dev/amb8465 or /dev/rtlsdr
Listen to C1 traffic and assume that a wmbus dongle is either /dev/im871a, /dev/amb8465, /dev/rfmrx2 or /dev/rtlsdr
% wmbusmeters --c1 auto
@ -121,6 +128,7 @@ meterfiles=/var/log/wmbusmeters/meter_readings
meterfilesaction=overwrite
logfile=/var/log/wmbusmeters/wmbusmeters.log
shell=/usr/bin/mosquitto_pub -h localhost -t "wmbusmeters/$METER_ID" -m "$METER_JSON"
json_address=MyStreet 5
.fi
.TP
@ -131,6 +139,7 @@ name=MyTapWater
type=multical21
id=12345678
key=001122334455667788AABBCCDDEEFF
json_floor=4
.SH AUTHOR
Written by Fredrik Öhrström.