Like many developers, I have a drawer full of retired electronics. Among the tangle of micro-USB cables and obsolete tablets sat a 2014 Samsung Galaxy Note 4. It still had its removable plastic back cover, a stylus, and an octa-core Exynos processor with 3GB of RAM.
Instead of sending it to an e-waste bin or paying $6 a month for a low-tier cloud VPS, I decided to see if it could handle real 24/7 edge duties.
Today, that decade-old phone sits quietly on my desk, drawing just 1.2 Watts from the wall, running Termux and headless Linux. It powers Maritime Watch, an open-source coastal safety engine that monitors marine weather, tracks live commercial vessels, and computes personalized departure windows for artisanal fishermen and small boats.
Here is why I built it, how I tamed Android's aggressive power management, and what it took to get the power draw down to barely a single watt.
The Problem with Generic Marine Forecasts
If you look at standard consumer weather apps, marine forecasts usually say something like:
"Wind 20 knots, wave height 1.4 meters."
If you are on a 200-meter commercial container vessel, 20 knots is just a breezy afternoon. But if you are a local fisherman in an 8-meter wooden skiff, 20 knots and a steep 1.4-meter chop means a very real risk of swamping or capsizing.
Raw numbers lack operational context. Small-boat skippers don't want to decipher raw meteorological datasets at 5:00 AM; they need clear answers:
- Is it safe to leave the harbor this morning?
- Exactly what time does the weather deteriorate?
- Where is the closest sheltered cove if conditions turn sour?
Maritime Watch ingests hourly marine forecasts from Open-Meteo (wave height, wave period, swell direction, wind gusts, and ocean current velocity) and pairs them with live AIS vessel traffic. Instead of a single blanket advisory, the engine evaluates conditions against three distinct hull classes:
- Small craft (under 8 meters): Very sensitive to wind chop over 12 knots and short-period waves over 0.8 meters.
- Medium boats (8 to 15 meters): Capable of handling up to 18-20 knots depending on wave period.
- Vessels over 15 meters: Commercial grade, higher seaworthiness limits.
Every morning at 6:00 AM, subscribers get a direct notification summarizing their departure window: for example, "Safe to head out between 07:00 and 14:00. At 15:00, gusts exceed 24 knots from the northeast; return to port by 14:30."
Why a Phone Instead of a Raspberry Pi?
Raspberry Pis are the default choice for homelab projects, but a retired flagship phone actually has several unfair advantages:
- Built-in UPS: If the power goes out, the internal battery keeps the server running for hours without dropping a single packet.
- Integrated Connectivity: It has functional Wi-Fi, Bluetooth, and cellular hardware built onto the board.
- Price: Exactly zero dollars. It was already sitting in my house doing nothing.
- Specs: 3GB of RAM and an octa-core processor are more than enough for pure Python scripts.
Getting a ten-year-old Android phone to behave like a stable server required solving a few quirks, however.
Setting Up Headless Linux via Termux
The base setup is straightforward:
- Install Termux from F-Droid (never use the abandoned Google Play Store release).
- Install the necessary packages:
pkg update && pkg upgrade
pkg install python git openssh tmux
- Set up SSH with public key authentication so the phone can be managed completely headless from a terminal on my main workstation.
- Disable Android's aggressive background sleep killers:
termux-wake-lock
I also added Termux to the OS battery optimization exemption list in Android settings. With tmux keeping sessions alive, the Python service runs quietly in the background without needing the phone display on.
Cutting Current Draw by 62%: The Long-Polling Refactor
When I first launched the Telegram bot listener on the phone, I noticed two problems: the device was warm to the touch, and battery current hovered around 118 mA.
The initial implementation used a naive HTTP polling loop with a short 1.5-second sleep interval.
Every single request triggered DNS resolution, a full TLS handshake, CPU wakeups out of deep sleep state, and Android radio chip power-state transitions. Doing that 2,400 times an hour kept the Cortex cores active almost continuously.
To fix this, I completely reworked the polling mechanism to use HTTP Keep-Alive Long Polling via Telegram's getUpdates endpoint with a 20-second timeout:
# Long-poll listener: holds connection open for up to 20s
url = f"https://api.telegram.org/bot{TOKEN}/getUpdates"
params = {
"offset": offset,
"timeout": 20,
"allowed_updates": ["message", "callback_query"]
}
response = session.get(url, params=params, timeout=25)
With this single change:
- If no commands come in, the connection sits idle on a single open socket.
- Hourly TLS handshakes dropped from ~2,400 to roughly 140.
- The CPU stays in low-power idle states 99% of the time.
- Current draw plummeted from 118 mA down to ~45 mA—a 62% reduction.
Measured at the wall outlet with a digital power meter, the entire setup consumes ~1.2 Watts. Running it 24/7 costs less than 15 cents a month in electricity.
Dealing with the 24/7 Battery Question
Whenever you talk about running a phone plugged in permanently, people rightly bring up battery swelling.
Right now, the phone stays cool to the touch because the screen is permanently blacked out and the CPU barely breaks 1% utilization. Heat is the main catalyst for lithium battery degradation.
However, leaving lithium cells pinned at 100% state-of-charge under continuous float voltage is still not ideal long-term. Because the Galaxy Note 4 has a removable back cover, my plan for the permanent deployment is one of two options:
- Use a smart plug with Home Assistant to cycle battery charge between 25% and 75%.
- Remove the lithium pouch entirely and wire a direct 4.2V 2A DC buck converter to the battery terminal pins with a dummy thermistor resistor.
For now, the phone has been running continuously for weeks without warming up or skipping a beat.
Architecture: Pure Python, Zero Runtime LLMs
One deliberate design choice was keeping the runtime completely free of heavy machine learning frameworks or paid LLM APIs:
- Data Ingestion: Asynchronous workers pull open-data marine forecasts and ITU-R M.1371 AIS radio streams.
- Deduplication: Raw AIS bursts are deduplicated by MMSI number and spatial bounding boxes to keep memory footprints minimal (the entire process uses under 75 MB of RAM).
- Collision Risk (CPA): Standard geometrical vectors compute Closest Point of Approach (CPA) and Time to CPA (TCPA) between converging vessels in tight waterways like the Bosphorus Strait.
- Web Frontend: A static single-page app built with vanilla HTML5, CSS, and Leaflet.js. It requires no Node.js runtime, no webpack build step, and is hosted completely free on GitHub Pages. It also includes an offline Service Worker (PWA) so emergency contact cards and VHF distress guides load even if connectivity drops offshore.
Final Thoughts
You don't always need an expensive multi-core home server or a cloud instance to build something useful. Older hardware that we routinely discard has plenty of computing power for automation, telemetry collectors, DNS filters, and monitoring nodes.
If you have an old Android phone sitting in a drawer, flash Termux on it, measure the wattage, and see what you can build.
If you want to check out the source code, inspect the AIS parser, or look through the deployment setup, the project is completely open source:
Feel free to share your thoughts, edge tips, or questions in the comments below!
