forked from wmbusmeters/wmbusmeters
-
Notifications
You must be signed in to change notification settings - Fork 0
/
wmbusmeters.1
278 lines (184 loc) · 10.3 KB
/
wmbusmeters.1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
.TH WMBUSMETERS 1
.SH NAME
wmbusmeters \- Acquire,query and decode wired and wireless mbus telegrams, then relay the telegrams to other software.
.SH SYNOPSIS
.B wmbusmeters {options} [device]+ { [name] [driver] [id] [key] }*
.B wmbusmeters {options} [hex] { [name] [driver] [id] [key] }*
.B wmbusmetersd {options} [pid_file>]
.SH DESCRIPTION
Wmbusmeters acquires wired or wireless mbus 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 (eg im871a,im170a,amb8465,
amb8335,cul,rc1180) or a software defined radio dongle (rtl_sdr) with an
RTL2832U (decoded using rtl_wmbus, rtl_433).
After the acquired telegram has been decrypted and parsed, it can then
be relayed using a shell command, or stored in a log file. The shell
commands can for example relay the telegram using MQTT (eg
mqtt_publish) sent to a REST API (eg curl) or store it in a database
(eg psql).
.SH OPTIONS
\fB\--alarmexpectedactivity=\fRmon-fri(08-17),sat-sun(09-12) Specify when the timeout is tested, default is mon-sun(00-23)
\fB\--alarmshell=\fR<cmdline> invokes cmdline when an alarm triggers
\fB\--alarmtimeout=\fR<time> Expect a telegram to arrive within <time> seconds, eg 60s, 60m, 24h during expected activity
\fB\--analyze\fR Analyze a telegram to find the best driver
\fB\--analyze=\fR<key> Analyze a telegram to find the best driver and use the provided decryption key.
\fB\--analyze=\fR<driver> Analyze a telegram but use only this driver.
\fB\--analyze=\fR<driver>:<key> Analyze a telegram and use only this driver with this key.
Add :verbose to any analyze to get more verbose analyze output.
\fB\--calculate_xxx_yyy=\fR... Add xxx_yyy to the json and calculate it using the formula. E.g.
\fB\--calculate_sumtemp_c=\fR'external_temperature_c+flow_temperature_c'
\fB\--calculate_flow_f\fR=flow_temperature_c Units are automatically translated if possible.
\fB\--debug\fR for a lot of information
\fB\--donotprobe=\fR<tty> do not auto-probe this tty. Use multiple times for several ttys or specify "all" for all ttys
\fB\--exitafter=\fR<time> exit program after time, eg 20h, 10m 5s
\fB\--format=\fR(hr|json|fields) for human readable, json or semicolon separated fields
\fB\--help\fR list all options
\fB\--identitymode\fR=(id,id-mfct,full,none) group meter state based on the identity mode. Default is id.
\fB\--ignoreduplicates\fR=<bool> ignore duplicate telegrams, remember the last 10 telegrams. Default is true.
\fB\--field_xxx=yyy\fR always add "xxx"="yyy" to the json output and add shell env METER_xxx=yyy The field xxx can also be selected or added using selectfields=. Equivalent older command is --json_xxx=yyy.
\fB\--license\fR print GPLv3+ license
\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
\fB\--listenvs=\fR<meter_type> list the env variables available for the given meter type
\fB\--listfields=\fR<meter_type> list the fields selectable for the given meter type
\fB\--listmeters\fR list all meter types
\fB\--listmeters=\fR<search> list all meter types containing the text <search>
\fB\--listunits=\fR list all unit suffixes that can be used for typing values
\fB\--logfile=\fR<dir> use this file for logging or --logfile=syslog
\fB\--logtelegrams\fR log the contents of the telegrams for easy replay
\fB\--logtimestamps=\fR<when> add timestamps to log entries: never/always/important
\fB\--meterfiles=\fR<dir> store meter readings in dir
\fB\--meterfilesaction=\fR(overwrite|append) overwrite or append to the meter readings file
\fB\--meterfilesnaming=\fR(name|id|name-id) the meter file is the meter's: name, id or name-id
\fB\--meterfilestimestamp=\fR(never|day|hour|minute|micros) the meter file is suffixed with a timestamp (localtime) with the given resolution.
\fB\--nodeviceexit\fR if no wmbus devices are found, then exit immediately
\fB\--normal\fR for normal logging
\fB\--oneshot\fR wait for an update from each meter, then quit
\fB\--overridedevice=\fR<device> override device in config files. Can only be used in combination with --useconfig= option
\fB\--pollinterval=\fR<interval> poll mbus meters every <interval>, default is 10m.
\fB\--ppjson\fR pretty print the json output
\fB\--resetafter=\fR<time> reset the wmbus dongle regularly, default is 23h
\fB\--selectfields=\fRid,timestamp,total_m3 select only these fields to be printed (--listfields=<meter> to list available fields)
\fB\--separator=\fR<c> change field separator to c
\fB\--shell=\fR<cmdline> invokes cmdline with env variables containing the latest reading
\fB\--silent\fR do not print informational messages nor warnings
\fB\--trace\fR for tons of information
\fB\--useconfig=\fR<dir> load config <dir>/wmbusmeters.conf and meters from <dir>/wmbusmeters.d
\fB\--usestderr\fR write notices/debug/verbose and other logging output to stderr (the default)
\fB\--usestdoutforlogging\fR write debug/verbose and logging output to stdout
\fB\--verbose\fR for more information
\fB\--version\fR print version
.SH DEVICES
.TP
\fBauto:c1\fR detect any serially connected wmbus dongles and rtl_sdr dongles and configure them for c1 mode.
Use auto to detect your dongle when testing, but then in production, state explicitly the dongle you are using.
This will significantly reduce the amount of probing done on the serial ports.
.TP
\fBim871a:t1\fR look for an im871a dongle attached to any of the serial ttys and configure it for t1 mode.
.TP
\fBim871a[12345678]:t1\fR look for the im871a dongle with this particular id.
.TP
\fB/dev/ttyUSB0:amb8465:c1,t1\fR expect an amb8465 on this tty.
.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.
.TP
\fBrtlwmbus[alfa]:433M:c1,t1 rtlwmbus[beta]:868.9M:c1,t1\fR Use two rtlsdr dongles, one has its id set to alfa (using rtl_eeprom)
and the other set to beta. Alfa has an antenna tuned for 433M, beta has an antenna suitable for 868.9M.
.TP
\fB/dev/ttyUSB0:9600\fR read serial data from tty at 9600 bps, expects raw wmbus frames with the DLL crcs removed.
.TP
\fBMAIN=/dev/ttyUSB0:mbus:2400\fR expect an serial to mbus master converter on ttyUSB0.
.TP
\fBstdin:rawtty\fR read binary telegrams (without dll crc:s) from stdin.
.TP
\fBfilename:rawtty\fR read binary telegrams from the file.
.TP
\fBstdin:hex\fR decode any hex found on stdin, non-hex characters are ignored.
.TP
\fBstdin:rtlwmbus\fR read rtlwmbus formatted data from stdin.
.TP
\fBmyfile.txt:rtlwmbus\fR read rtlwmbus formatted data from this file instead.
.TP
\fBsimulation_xxx.txt\fR read telegrams from file to replay telegram feed (use --logtelegrams to acquire feed for replay)
.TP
\fB2e441122334455667788\fR decode the given hex string the hex string must have only hex digits or underscores.
.SH METER QUADRUPLES
.TP
\fBmeter_name\fR a mnemonic for your utility meter
.TP
\fBmeter_type\fR for example multical21:t1 (suffix means that we expect this meter to transmit t1 telegrams) the driver auto can be used, but is not recommended for production.
.TP
\fBmeter_id\fR one or more addresses separated with commas, a single '*' wildcard, or a prefix '76543*' with wildcard. You can as a suffix fully or partially specify manufacturer, version and type: 12345678.M=KAM.V=1b.T=16 You can use p0 to p250 to specify an mbus primary address. You can filter out telegrams: 76543*,!76543210
.TP
\fBmeter_key\fR a unique key for the meter, if meter telegrams are not encrypted, you must supply an empty key: ""
.SH EXAMPLES
.TP
.TP
Wait for wmbus dongles to be inserted and then listen for c1 telegrams.
Print a summary of the telegram and whether wmbusmeters has a driver for decoding it.
% wmbusmeters auto:c1
Listen to C1 traffic using an im871a dongle attached to some tty.
% wmbusmeters im871a:c1
The im871a dongles have an id number that is printed when the dongle is started.
You can use this to specify which dongle to use for which linkmode.
% wmbusmeters im871a[12345678]:c1 im871a[22334455]:t1
.TP
Listen to both T1 and C1 traffic using rtl_sdr|rtl_wmbus and the standard frequency 868.95M, which
might need tweaking depending on the rtl_sdr dongle you are using.
% wmbusmeters rtlwmbus:868.95M
You can identify rtlsdr dongles this way as well. The id of the rtlsdr dongle is
set using rtl_eeprom. Assuming you want to listen to multiple frequencies, one dongle
has one type of antenna attached.
% wmbusmeters rtlwmbus[alfa]:433M:t1 rtlwmbus[beta]:868.9M:c1
You can query an mbus meter:
% wmbusmeters MAIN=/dev/ttyUSB0:mbus:2400 MyTempMeter piigth:MAIN:mbus 12001932 NOKEY
.TP
Execute using config file /home/me/etc/wmbusmeters.conf and meter config files in /home/me/etc/wmbusmeters.d
% wmbusmeters --useconfig=/home/me
.TP
Start a daemon using config file /etc/wmbusmeters.conf and meter config files in /etc/wmbusmeters.d
% wmbusmetersd --useconfig=/ /var/run/wmbusmeters/wmbusmeters.pid
.TP
An example wmbusmeters.conf:
.nf
loglevel=normal
device=im871a[12345678]:c1
device=rtlwmbus:433M:c1,t1
logtelegrams=false
format=json
# Remember to remove meterfiles to spare precious flash memory when only
# relaying data using for example mqtt.
meterfiles=/var/lib/wmbusmeters/meter_readings
meterfilesaction=overwrite
meterfilesnaming=name
meterfilestimestamp=day
logfile=/var/log/wmbusmeters/wmbusmeters.log
shell=/usr/bin/mosquitto_pub -h localhost -t "wmbusmeters/$METER_ID" -m "$METER_JSON"
alarmshell=/usr/bin/mosquitto_pub -h localhost -t wmbusmeters_alarm -m "$ALARM_TYPE $ALARM_MESSAGE"
alarmtimeout=1h
alarmexpectedactivity=mon-sun(00-23)
ignoreduplicates=false
field_address=MyStreet 5
.fi
.TP
An example wmbusmeters.d file:
.nf
name=MyTapWater
driver=multical21:c1
id=12345678
key=001122334455667788AABBCCDDEEFF
field_floor=4
.TP
You can use the driver auto, but it is not recommended for production.
The auto driver might change over time to better versions of the driver with new names,
whereas a fixed driver name should generate backwards compatible json.
.SH AUTHOR
Written by Fredrik Öhrström.
.SH COPYRIGHT
Copyright \(co 2017-2022 Fredrik Öhrström.
.br
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
.br
This is free software: you are free to change and redistribute it.
.br
There is NO WARRANTY, to the extent permitted by law.