ConfigWatch

Yamaha RTX is not verified on real hardware

The profile was built from Yamaha’s own documentation and the vendor list says it is unverified. Paging is stepped through with spaces rather than by sending console lines infinity — that command shows up in show config even unsaved, so sending it would put our line into your backup. If you run RTX hardware and it works, we would like to hear.

Rollback

ConfigWatch never pushes configuration to a device. It generates rollback commands for you to read and run yourself. If you saved rollback commands from a version before 0.4.1, regenerate them — a bug affecting every vendor made those commands re-apply a change before removing it.

Free and Pro

Free browses history for 3 devices. Every device you register is backed up, on every tier — the limit is on browsing history, not on collection. Devices beyond the limit are deliberately still listed so you can remove them.

SSH host keys

Since 0.4.4 ConfigWatch pins each device’s SSH host key. The first connection records the key the device presents; every later connection must present the same key, and one that presents a different key is refused before the login is sent — the collection fails rather than hand the read-only credentials to whatever answered at that address. The recorded keys are kept in known-hosts.json in the data folder:

• macOS — ~/Library/Application Support/ConfigWatch/known-hosts.json
• Windows — %APPDATA%\ConfigWatch\known-hosts.json
• Linux — ~/.config/ConfigWatch/known-hosts.json

It is one JSON object with an entry per device, keyed by the host and port as you entered them, with the SHA-256 hash of the device’s key as the value — for example {"192.168.1.10:22":"3f9a…"}. When you legitimately replace a device or regenerate its host key, remove that device’s entry, or delete the whole file to re-learn every device. The next collection records the new key. The file is read afresh at the start of every backup run, so ConfigWatch does not need restarting; edit it while no backup is running.

Language

Settings → Language. English and Japanese. Device configuration text is never translated.

Where your data lives

Everything ConfigWatch stores stays on the computer it runs on. None of it is sent to us, to an analytics company or to an advertising network.

Licence keys

The key arrives by email after purchase. It is checked on this computer, so ConfigWatch never contacts a licensing server. When the 30-day trial ends, or a subscription lapses, ConfigWatch drops to the Free limits above: scheduled backups, rollback commands and audit export stop, and history already stored is kept.

Nothing is arriving

The firewall is the usual reason — see section 4. After that, check that the device is pointed at this computer’s current local IP address; a DHCP lease can move it.

Test connection to Central fails

bad-token means the token is wrong or was revoked — issue a new one. unreachable means the address is wrong or a firewall is in the way; port 8443 must be open on the Central server. Note it is http://, not https://, unless you put a reverse proxy in front of Central. wrong-product means the token was issued for a different product; the message names which one. Issue a token for ConfigWatch instead and revoke the other. If the address looks right but Central is still unreachable, check it for a typo: most mistyped addresses are still valid addresses — 127.0.0.01 is read as 127.0.0.1 and 192.168.001.5 as 192.168.1.5 — so the connection quietly goes somewhere else. In the current releases these results are shown as sentences — a token Central refuses is explained as possibly revoked or issued by a different Central — and the code itself appears when you hover over the message.

Central shows this agent as “connected”, but nothing arrives

That is not a failure. connected means the test succeeded and nothing has been sent yet; the row switches to reporting on the first real report, because a product sends only when something happens. ConfigWatch switches to reporting after one backup run, even when nothing changed. A row still reading waiting has never reached Central.

A backup fails with “Host denied (verification failed)”

The device presented a different SSH host key from the one recorded on the first connection, so ConfigWatch refused to log in. The status line after the run names the device by host and port, for example 1 failed — 192.168.1.10:22: Host denied (verification failed). If you replaced the device or regenerated its key, remove its entry from known-hosts.json — see SSH host keys. If you did not, find out why the key changed before you do: something else may be answering at that address.

A collection failed instead of saving a short config

That is deliberate. If the device’s paged output stops before its prompt comes back, ConfigWatch discards the capture and reports The configuration did not finish printing (stopped after N of M pages), so nothing was stored rather than storing a truncated copy. A truncated copy would otherwise be saved as that day’s configuration and show up as a large, false change. Run the backup again; if it keeps failing on the same device, write to support with the vendor and model.

Problems that affect every product

A blank window after upgrading, Ubuntu 24.04 refusing to start the app, credentials stored as plain text on Linux without a keyring, alert email not being delivered — these are the same on every product and are collected on the support page.

Still stuck

Write to support@meshwatch.app with the version number and what you expected to happen. First reply within two business days, Monday to Friday.