tty228/luci-app-wechatpush for OpenWrt Notifications and Firewall Control

What luci-app-wechatpush Changes on an OpenWrt Router

luci-app-wechatpush turns an OpenWrt router into a monitored and remotely informed endpoint. The project targets router operators who want alerts when a WAN IP or IPv6 address changes, when a device appears online or goes offline, and when a router login occurs through the Web or SSH interfaces. It also documents scheduled router status reports, unattended tasks, CPU load, temperature, PVE host temperature monitoring, device lists and traffic usage.

The notification targets are broader than the project name suggests. The README lists WeChat through Server酱, 推送加, WPUSH and WxPusher, 企业微信 through application messages, Telegram through a bot, and email through msmtp. The implementation language is primarily Shell, while the repository contains LuCI files under `htdocs/`, package metadata in `Makefile/`, translations under `po/` and runtime files under `root/`. That layout places the package at the OpenWrt package layer, with LuCI as the configuration surface and shell components handling collection and notification work.

Automatic blocking is a separate operational feature rather than merely an alert channel. The README says blacklisted addresses are blocked by default from traffic that accesses the router. An additional option can block forwarding traffic from a blacklisted IP, including port-mapped devices and LAN clients accessing the internet. This distinction matters for anyone comparing the plugin with a simple notification script.

How Detection, Notifications and Blocking Are Connected

The documented flow starts with OpenWrt system information and local network probes. Device availability is checked actively with `ping` and `arping`, according to the README. This approach is used to counter Wi-Fi sleep behavior, at the cost of additional probing work. Device names can come from device notes, an advanced lookup setting, a MAC address database, or NetBIOS support supplied by `samba*-server` or `samba*-client`.

The package can collect more than presence data. CPU load and temperature are documented monitoring targets. Optional local disk inspection uses `lsblk` for capacity information and `smartctl` for temperature, power-on time and health information. Remote PVE host information is also mentioned, so a deployment should distinguish data collected from the OpenWrt router itself from data collected from a remote host.

Traffic statistics depend on `wrtbwmon`. The README and `Makefile` both identify this package as an optional dependency for the traffic monitoring build option. The documentation warns of conflicts with Routing/NAT, Flow Offloading and proxy internet access plugins, which can make traffic data unavailable. This is a direct integration boundary. The notification path can still be useful, but the traffic feature should not be assumed to work independently of the router's packet accounting arrangement.

When automatic blocking is enabled, the plugin adds firewall rules for router access. The optional forwarding mode extends the restriction to routed traffic. If `conntrack` is installed, the README says the plugin attempts to clear existing connection tracking records for the blocked address. Without `conntrack`, that cleanup step is skipped, while new connections should still encounter the blocking rules. Rules are removed in the next detection loop when automatic blocking or forwarding blocking is disabled. Stopping the service does not immediately remove already active rules. They remain until a firewall reload or restart, then can be restored during the next loop while the plugin runs.

Installing the OpenWrt Package and Preparing Dependencies

The project documents installation through OpenWrt releases rather than providing a standalone command that can be copied for every device. Before installing, run the documented package index update command. The README names `iputils-arping`, `curl`, `jq` and `bash` as core dependencies. It also warns that these packages consume storage and memory on routers with limited resources.

For supported releases from `openwrt-19.07.0` through the latest version listed in the README, use the project's release page. The repository Makefile identifies the package as `luci-app-wechatpush`, with `luci-lua-runtime` and the named command-line dependencies. Traffic monitoring, local disk information detection and host information detection are conditional package options, each with its own dependencies.

The README specifically says that LuCI 18.06 is no longer supported after v2.06.2. For that release line, the documented source branch is `openwrt-18.06`:

git clone -b openwrt-18.06 https://github.com/tty228/luci-app-wechatpush.git

This command obtains the compatibility branch. It does not install the package by itself. The reader should confirm that the selected branch matches the OpenWrt version before compiling or installing the resulting package. For the main branch, the download section directs users to the latest release badge for supported OpenWrt versions.

The repository is not archived. The last push was on 2026-10-09, and recent release entries include v3.6.12 from 2026-03-03, v3.6.10 from 2025-08-15 and v3.6.9 from 2025-05-12. Those facts describe release and repository activity, but the README does not define a support window or an upgrade compatibility guarantee.

A First WeChat or Telegram Alert

The README does not provide a complete, copy-and-paste first-use sequence for creating a bot, submitting a WeChat service key, or saving SMTP credentials. It does identify the intended service interfaces and the browser-facing LuCI package. A first deployment should therefore begin by installing the package and its core dependencies, then configure one notification channel in the LuCI interface.

For Telegram, the documentation points to BotFather. The generated bot token and chat destination are configuration values that must be entered through the package's interface. For WeChat delivery, the documented options require an account or endpoint with one of the listed services. Email uses `msmtp`, which is a separate mail transport dependency rather than a built-in SMTP client.

A practical first check is to select an event that can occur locally, such as a device status transition, and send it to one channel before enabling every provider. The documented event set includes device online and offline alerts, IP changes and router login notices. Once one alert path is configured, its delivery result can be checked against the router's logs and the temporary runtime directory. The README identifies `/tmp/wechatpush/` for diagnostic files.

For firewall alerts or login notifications, automatic blocking introduces a second verification step. Confirm that the plugin's detection loop has run and that the intended address is blocked before relying on the rule to disconnect an active session. The documented `conntrack` behavior means an existing session may persist unless that package and the cleanup path are available.

Firewall Blocking Trade-offs and Failure Cases

The forwarding option is the feature most likely to change network behavior beyond notifications. Blocking a router address is relatively bounded because it concerns access to the router itself. Blocking forwarding traffic can affect port-mapped services, LAN clients and internet access routed through the OpenWrt device. A rule intended to stop one abusive address may therefore have broader consequences than the alert itself suggests.

The README makes the timing behavior explicit. Disabling the relevant setting does not necessarily produce an immediate cleanup. The plugin removes the rules during its next detection loop. Stopping the service is different. Rules already in effect remain until a firewall reload or restart, and they can return on a later loop when the service is running again. `fw4` scheduled blocking can restore a block according to the remaining duration recorded for the address. A blacklist duration of `0` means permanent blocking until the entry is manually cleared.

The plugin is therefore a poor choice if the operator requires immediate, transaction-free firewall rollback or needs to prove that every existing connection is terminated on every router. `conntrack` is required for the documented attempt to clear existing tracked flows. If it is absent, the plugin skips that step. Other package interactions create further uncertainty. The README says temperature values and interface displays may require adaptation because the package was made on x86 OpenWrt v23.05.0, and it identifies possible conflicts with routing and offloading features.

luci-app-wechatpush Compared with a Lightweight Notification Script

The real alternative is a small Shell script that reads a limited set of OpenWrt events and sends them through one provider. Such a script can have a smaller installation footprint and a simpler control path because it would not need to manage LuCI pages, translations, optional disk checks, host inspection or persistent firewall behavior.

luci-app-wechatpush offers a broader operational surface instead. Its documented capabilities cover multiple notification providers, scheduled status delivery, device probing, traffic information, disk and PVE information, unattended tasks, login prompts, automatic blacklisting and optional forwarding blocking. It is aimed at operators who want one package to combine monitoring and enforcement rather than a narrowly scoped alert sender.

That breadth also creates more platform dependencies. Core operation requires `iputils-arping`, `curl`, `jq` and `bash`. Traffic data requires `wrtbwmon`, disk details require `lsblk` and `smartctl`, and remote host information requires `openssh-client` and `openssh-keygen` when that build option is selected. The Makefile exposes these features as package configuration choices. A lightweight script is easier to tailor when all that functionality is unnecessary, while this package is the more specific choice for an OpenWrt installation with matching monitoring and blocking requirements.

Maintenance, License and Upgrade Considerations

The repository is licensed under GPL-2.0. That identifier is recorded in the project information and should be reviewed with the repository's `LICENSE` file when distribution, modification or integration matters. The README does not add licensing exceptions or alternative terms.

The current Makefile declares `PKG_VERSION:=3.6.13`, while the release list supplied for the repository identifies v3.6.12 as the most recent listed release. That difference means a source build and a release download should not be assumed to contain identical package metadata. The README also separates compatibility for OpenWrt `19.07.0` through the latest supported line from the older `18.06` branch. Upgrading should therefore account for both the OpenWrt release and the plugin branch or package version.

The last push was on 2026-10-09. The repository is not archived, and its release history includes entries in 2025 and 2026. The documentation does not promise automatic migration of notification credentials, firewall rules or configuration files between versions. It also does not document a rollback procedure for package upgrades or for changes to active blacklist rules.

Editorial conclusion

Adopt luci-app-wechatpush if you run OpenWrt and need router notifications or automatic blocking through a LuCI-managed package. Do not expect reliable traffic figures where wrtbwmon conflicts with other networking features, and do not use the current branch for LuCI 18.06. Verify your OpenWrt release, selected notification service, optional packages and firewall behavior before relying on automatic blocking.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. tty228/luci-app-wechatpush on GitHub