sms_forwarding is a 27.8 yuan ESP32C3 device that forwards received texts to eight push channels

The scope is a boundary, not a roadmap

The most useful paragraph in the README is the one refusing features. The project states it is for receiving SMS and for functions related to keeping a SIM alive, and that multi-SIM control, calls, dialling, open interfaces and automation will never be considered, with an explicit request not to file such requests.

That is unusual to find written down, and it changes how you evaluate the project. There is no API surface to wait for, no half-finished call handling to work around, and no ambiguity about whether a phone-like feature is coming. What exists is a device that reads SMS from one modem and hands them to notification services.

The stated goal is to use low cost hardware to forward SMS automatically, with the emphasis on supporting several push methods enabled at the same time rather than on any single integration. The repository is a hardware and firmware project: code/ holds the firmware sources, assets/ the images, dev_doc/ the developer documentation, and AGENTS.md sits at the root alongside the README and LICENSE.

There is also a branch distinction that matters before you start. The current branch is described as the new solution, and the 2022 approach lives on a separate branch named old-luatos. A reader arriving at the repository from an old link may end up on the Luatos based design instead of the ESP32C3 one described here.

Two boards, one UART link, and a 5 volt modem supply

The hardware is an ESP32C3 development board and an ML307R-DC modem board connected over a serial link, and the wiring is specific enough to reproduce.

The ESP32C3 Super Mini drives the modem's power enable line on GPIO5, labelled MODEM_EN, and crosses its own transmit and receive: GPIO3, labelled TX, goes to the modem's RX, and GPIO4, labelled RX, comes from the modem's TX. The two boards share ground, and the modem board is powered from the ESP32C3's 5V pin into its VCC. The modem board carries the SIM slot, which takes a Nano SIM, and an antenna connector for the 4G antenna.

That last detail deserves a second look. The modem is fed 5V while the ESP32C3 board is connected through the documented GPIO wiring, and the modem's enable line is driven by a microcontroller pin rather than pulled high passively. Anyone rebuilding this should treat the power and enable arrangement as part of the design rather than as wiring to improvise.

Programming and power come from the same USB connection to the ESP32C3. The README also notes that during normal operation the web page talks to the module over AT commands, which is a debugging convenience: the firmware can be inspected through the same interface it uses in production.

The ESP32C3 runs Arduino firmware, the modem runs stock AT firmware

The software is split unevenly, and that is what makes the project small. The ESP32C3 runs its own Arduino firmware, whose job is to join WiFi, receive the SMS data the ML307R-DC hands it, and forward that data to a configured HTTP endpoint or an email address. The ML307R-DC runs its default AT firmware and is not modified.

So the modem is treated as a peripheral that speaks AT, and everything interesting happens on the microcontroller. That is the reason a 27 yuan bill of materials is enough: no modem-side software, no custom baseband work, just AT command handling on one side and HTTP client code on the other.

The build environment is the Arduino IDE, and it needs this specific setup. Two libraries must be installed separately, ReadyMail by Mobizt for the email path and pdulib by David Henry, and ESP32 board support must be added following Espressif's own documentation, with the board type set to MakerGO ESP32 C3 SuperMini rather than a generic ESP32C3 entry.

That last setting is a small trap. The firmware is written against a specific development board, and the library list tells you the shape of the solution: one library for sending mail, one general purpose utility, and AT command handling the project supplies itself.

Eight push channels, and a count the README gets wrong

The push section claims support for seven methods that can be enabled together, then lists eight in the table. The gap is small and does not change anything, but it is the kind of detail that matters when you are configuring a device and counting checkboxes.

The channels are POST JSON, described as a generic HTTP POST, and a GET request with URL parameters, both of which need only a URL. Bark, described as an iOS push service, needs a Bark server URL. DingTalk is an enterprise group notification webhook; Feishu is a custom notification webhook. Both support signature verification with an optional secret. PushPlus pushes to a WeChat public account using a token, and Server酱 does the same job with a SendKey and Markdown support. The eighth is a custom template, which takes a URL and a request body template.

The payload formats are specified per channel, which is what makes them usable. POST JSON sends sender, message and timestamp fields. Bark maps them onto title and body, so the sender number becomes the notification title. The GET variant builds URL?sender=xxx&message=xxx&timestamp=xxx with automatic URL encoding. The custom template uses the placeholders {sender}, {message} and {timestamp}, so a channel with a different schema can be supported without code.

The up to five channels enabled simultaneously figure is the feature that makes the design more than a single webhook. With redundant channels, a missed push from one provider is covered by another, which is exactly the failure mode a device sitting unattended in a home or office will eventually hit.

The features are all about keeping a SIM working

Read the feature list as a whole and the intent becomes clear: this is a device for a SIM that sits in a drawer and needs to keep receiving.

Configuration and status go through a web interface, so parameters can be changed and the current state queried once the device is on the network. The forward target can be an email address. Beyond passive forwarding there is an active path: the web interface can send an SMS deliberately, described as a way to consume the remaining balance, and can also run a Ping test, described as a way to consume balance at very low cost.

The Ping test is the clever piece. A SIM sitting unused for months can have its service lapse, and a periodic low cost check keeps the line alive. That single feature reframes the whole device: it is a keep-alive mechanism with notification as the output.

Two more details matter in practice. Long SMS are merged automatically with a thirty second timeout, so a multi-part message arriving over a few seconds becomes one notification rather than three. And an administrator can send an SMS to the device to trigger a remote SMS send or a device restart, which is a recovery path when the web interface is unreachable.

The backend web page is demonstrated at the project's own site, and the README links a video tutorial on Bilibili, both of which are the fastest way to see the finished state before buying parts.

What it costs, and the carrier constraint that decides the hardware

The README gives two paths and they are not equivalent.

If you can buy a finished unit, the recommendation is a ready made kit, described as costing about the same as building it yourself. That path supports China Mobile, China Unicom and China Telecom SIMs. A 4G FPC antenna is bought together with the kit.

If you solder it yourself, the documented combination is cheaper and narrower. The parts listed are an ESP32C3 Super Mini development board at about 9.5 yuan, an ML307R-DC core board at about 16.3 yuan, and a 4G FPC antenna at about 2 yuan, for a total around 27.8 yuan with the caveat that prices float and parts can be substituted. The significant restriction is that this combination supports only China Mobile and China Unicom cards.

That asymmetry is the practical decision point. A China Telecom user cannot use the documented self-built combination and should take the finished kit, which also removes the soldering requirement entirely.

Two further notes. The FPC antenna is bought in the same listing as the board or core board, so it is not a separate purchase, and the total cost figure in the README is a component sum rather than a kit price, which excludes enclosure, power supply and the SIM.

Maintenance, licensing and what the documentation leaves open

The repository has no GitHub releases, so there is no tag to pin and no changelog to read. The README is the entire user documentation, with dev_doc/ and AGENTS.md at the root for the development side. The last push was on 2026-08-25 and the repository is not archived.

For a firmware project, that is a workable but thin arrangement. Pinning a build means pinning a commit, and reviewing a change means reading a diff, because there is no version history to consult. A user who flashed the firmware six months ago has no supported way to ask what changed, and the branch split with the 2022 Luatos design makes it easy to read documentation for the wrong firmware.

The licence is MIT, with a LICENSE file at the root. No legal advice is offered, but a permissive licence on hardware-adjacent firmware is worth having for anyone who wants to modify the board configuration or the AT command handling rather than only the push configuration.

The gaps are worth naming. The README does not state a minimum balance or advise how often the Ping test should run, which is the parameter that determines whether a SIM stays alive. It does not document the expected current draw, so battery or power supply sizing is left to the builder. It does not describe firmware update over the air, which for an unattended device is the operation you will eventually need.

Editorial conclusion

Build sms_forwarding if you need a cheap always-on device to forward the verification texts and balance notices a spare SIM receives, and you are comfortable soldering two boards and configuring WiFi credentials and push endpoints in a web interface. Do not build it expecting a phone replacement, since the README rules out calls, dialling, multi-SIM control, open interfaces and automation by design. Verify first which carrier your SIM is on, because the documented self-built hardware combination supports only China Mobile and China Unicom cards while the ready made kit is the option for China Telecom, and check the pin assignments GPIO5, GPIO3 and GPIO4 against your own board.

Frequently asked questions

Official sources

1. chenxuuu/sms_forwarding on GitHub
2. Issues
3. License: MIT
4. Project website
5. README