First Scan and Tap Test

First scan and water-use check

Use a scan to find nearby transmitters, then a water-use check to help confirm which one is yours. Check the transmitter label where possible; signal strength alone does not establish ownership. The check uses your household tap: leave the meter and transmitter untouched.

Tip

What you'll need

• ha-taggle 0.3.0 installed (add-on, Docker or Python)
• The antenna connected and positioned (placement tips)
• 65 minutes for the scan
• A 10 L bucket and nobody else using water during the water-use check

Part 1: The scan

Why 65 minutes?

Transmitters typically send about once an hour. Scan for 65 minutes to cover an expected hourly transmission opportunity. Messages can still be missed, and other channels or transmitter types may not be supported.

Start a scan

Stop normal reception first. Only one program can use the USB receiver.

• Add-on: on Configuration, set scan_minutes: 65 and use meter_ids: [] if you do not know your ID. Keep other options. Click Save, then Restart (or Start if stopped) on Info. Watch Log.

• Docker: run the following from the cloned ha-taggle directory:

  docker compose stop taggle
  docker compose run --rm taggle --config /config/options.json --scan 65

• Python: stop the existing receiver process or service, then run:

  taggle-rx --config config.json --scan 65

Ctrl+C stops a foreground scan early. Scan mode makes no MQTT connection, creates no entities and writes no state or log files. It stops when the time is up; it does not switch to normal reception automatically.

Read the output

Each valid message prints one line. This is a fictional 0.3.0 example:

{"time":"2026-11-02T08:15:00+00:00","meter_id":123456,"snr_median_db":12.4,"signal_level_dbfs":-43.2}

Field	Meaning
time	Sample-derived UTC frame time, not decoding completion time
meter_id	The transmitter ID heard
snr_median_db	SNR, signal-to-noise ratio in decibels. Higher is better for comparing positions.
signal_level_dbfs	Signal level in dBFS. Closer to 0 means stronger.
counts	Raw counters. Shown only for IDs already in meter_ids, and only for clear (unencrypted) messages.

Release 0.3.0 includes UTC timestamps and one-decimal signal measurements, but no byte-length field. Missing counts for an unconfigured ID does not establish encryption. Counts for your configured ID establish a supported clear format, but not whether it is 18 or 21 bytes. See supported formats and field-test limits and Protocol.

Note

Is my SNR good enough? There is no proven threshold. This is an estimate measured after decoding, not straight off the antenna. Generated tests use 5 dB as a test setting, not a reception rule. Judge whether your own transmitter is received consistently over several hourly opportunities.

Important

Scan output can contain other people's IDs. Keep it private. Hearing an ID does not make it yours; configure only your own transmitter.

Nothing heard?

1. Check startup now: the receiver should be detected and the log should show Reading samples in async mode.... A V4 can also show RTL-SDR Blog V4 Detected. A USB light is not a reliable detection check. Fix errors before waiting.
2. Check the antenna connection. Move it to a window facing the meter or higher up.
3. Use the USB extension to move the receiver away from the computer.
4. Try gain 49; reduce it if reception gets worse. Add-on: Save → Restart. Docker: edit gain in config.json; the next scan command reads it. Python: stop and rerun the scan after editing.
5. Once startup is healthy, compare reception over a full 65 minutes after each change. Scan mode can remain silent between decoded frames; it has no normal listening heartbeat.
6. Still nothing? Check Troubleshooting for USB, channel and mobile-network-meter checks.

Normal-mode startup and heartbeat

After returning to normal reception, 0.3.0 logs startup, broker connection and configured-meter updates. Fictional example (order can vary):

INFO Listening on 922.2 MHz for meter(s): 1 configured; first reading can take up to an hour
INFO MQTT connected to 192.168.1.50:1883
INFO Meter 123456: +10 pulses last hour, SNR 30.1 dB
INFO still listening: 0 frames from 0 other meters heard in the last 15 min

The 15-minute heartbeat counts frames and distinct other meters without listing neighbour IDs. It shows that the receiver runs; it does not prove your own meter was heard or that USB acquisition is healthy. Check SDR detection and Reading samples in async mode... first. Scan mode has no MQTT, startup listening announcement or normal heartbeat. A no-SDR warning needs USB troubleshooting, not another hour of waiting.

Part 2: The water-use check

This provides evidence about ownership and usable pulses. It is not proof of ownership or litre calibration. If the label is unreadable, ask your utility to confirm the transmitter ID when the result is uncertain.

1. Put only your own ID (or the candidate you are checking) in meter_ids, replacing fictional 123456. Return to normal mode using Part 3 below.
2. Open Settings → Devices & services → MQTT → Devices → Taggle 123456 (your ID). Wait for Last seen, under Diagnostics, to update. Note its time and Last hour pulses.
3. Stop other water use: washing machine, irrigation and toilet refills included.
4. Fill a 10 L bucket twice (20 L total) from a household tap. Note the time and reuse the water.
5. Look for corresponding usage at the next update; check the following update too if the draw straddled two intervals. It need not exceed the previous hour's usage.

Note

Do not expect “20”. Until calibration, these are pulses, not litres. A 20 L draw may be too small for a clear result at an unknown pulse size. No visible change is inconclusive. Repeat during normal water use; do not keep running water to force a result.

Repeat uncertain identification at another time. A coincident neighbour's water use can resemble your test. Remove an unconfirmed candidate from meter_ids, apply the change, and use the old-device cleanup guidance. Never keep a neighbour's ID configured.

Diagnostics update but usage is unavailable? Encryption is one possible cause; a counter/sequence discontinuity can also temporarily hide usage. Check the encrypted attribute on Last hour where available, or report uncertainty. Confirmed encrypted messages provide ID and signal information only, so this check cannot use their pulses.

Part 3: Back to normal

Keep only your own confirmed ID in meter_ids, then use your installation's action:

Install	Return to normal reception
Add-on	Set scan_minutes: 0, Save, then Start/Restart Taggle water meter.
Docker	Let the one-off scan finish or stop it with Ctrl+C. Save config.json, then run docker compose up -d taggle from the receiver repository.
Python	Stop the scan, save config.json, then run taggle-rx --config config.json without --scan.

Do not add scan_minutes to Docker/Python JSON; it is add-on-only. Devices should appear as soon as normal mode connects to MQTT, before radio values arrive. If none appear, check MQTT discovery. Next: optionally add the dashboard card, then follow guided calibration.

Further reading

• Wikipedia: signal-to-noise ratio
• Wikipedia: dBFS