AquaFeedPro — Automatic Fish Feeder and Monitoring System

A mobile app and connected feeder prototype for managing two-nozzle fish feeding, monitoring dissolved oxygen and feed stock, and reviewing what happened during each feeding run.

AquaFeedPro connects a mobile interface, a cloud backend, and a feeder controller design in one system. From the app, an operator can pair a feeder, check its readings, request feeding, manage recurring schedules, and review results for each nozzle. The app uses Expo, React Native, and TypeScript. Supabase provides the database, access control, and APIs that connect the app with the feeder. A Python simulator acts as the device during development, with SQLite storing its schedules, feeding records, and remaining stock across restarts. The physical design uses a Raspberry Pi, two dispensing motors, a shared hopper weighed through an HX711 load-cell interface, a swing motor, and a blower. Dissolved oxygen is intended to come from a Bluetooth instrument connected to the Pi. The software and simulator provide the current implementation baseline; the physical controller, sensor integration, and operating limits still require integration and validation.

The central challenge is coordinating two dispensing nozzles that draw from one shared feed container. Each nozzle can need a different amount, but both affect the same stock measurement and must run in sequence. The system also needs to distinguish a request from a result. Saving a feeding request does not prove that a motor ran or that the requested amount was dispensed. A lost connection, repeated request, or controller restart must not silently cause another feeding cycle. AquaFeedPro addresses those constraints with separate request and outcome records, persistent device state, and clear handling of missing readings and uncertain results.

1. Pair an authorized phone. The operator scans a QR code or enters pairing details. A permanent QR identifies the feeder, while a fresh, temporary pairing challenge authorizes access. Recognizing the feeder does not grant control by itself.
2. Identify and select the feeder. Authorized phones can use the same shared feeder name and location. The app lets the operator select a paired device, and the backend checks that phone’s access before allowing protected actions.
3. Check the dashboard. The Home screen presents dissolved oxygen, remaining feed, device contact, and configuration status. Oxygen history can be viewed over different time windows. Missing, uncalibrated, or outdated readings are shown explicitly, so an unavailable sensor does not appear as a healthy zero.
4. Request immediate feeding. The operator selects Nozzle 1, Nozzle 2, or Both, enters a separate amount for each selected nozzle, and reviews the request before confirming. The app and backend check the feeder’s supported controls, dose limits, availability, and fresh stock reading. For gram-based doses, Both is checked against the combined amount required from the shared hopper.
5. Deliver the authorized request. Supabase stores the request and makes it available through the device API. The controller retrieves work through an outbound connection. Persistent request identifiers let repeated delivery refer to the same operation, helping prevent a network retry from creating another feed.
6. Run the nozzles in order. Both means Nozzle 1 followed by Nozzle 2. The simulator records progress and each nozzle’s result, including whether a measurement is available. A result that cannot be confirmed remains unknown rather than being automatically repeated. The physical controller must implement and validate the corresponding stop, weighing, and recovery behavior.
7. Set recurring schedules. The operator chooses the time, repeat days, nozzle targets, amounts, and feeder timezone. A saved change remains distinguishable from a configuration the device has actually applied. The simulator stores accepted schedules locally and can process them without a continuous cloud connection; occurrence records prevent the same scheduled event from running twice.
8. Keep records through interruptions. SQLite preserves the simulator’s inventory, applied configuration, pending reports, and execution state. After a restart, it checks unfinished work instead of assuming that feeding completed or resetting the hopper to full. Device reports retain their identities until acknowledged by the backend.
9. Review feeding history. The History screen brings manual and scheduled runs together, with date, source, and status filters. Detailed records show results per nozzle and keep requested amounts separate from measured dispensing. Completed, partial, failed, and unknown outcomes remain visible.
10. Surface conditions needing attention. Backend alert records cover configured oxygen limits, low feed, and feeding outcomes such as partial completion or an unknown result. The app includes notification history and an Android push implementation. Background push delivery still needs verification on a physical Android device with the required hosted configuration.

Authorized phone → confirmed feeding request → backend access, capability, and stock checks → device retrieval → Nozzle 1, then Nozzle 2 when selected → per-nozzle results → feeding history and relevant alerts. Recurring schedules follow a related path: save the configuration → device validates and applies it → local scheduler processes the due occurrence → results synchronize with the backend.

• React Native and Expo for the mobile app
• TypeScript for app and backend development
• Expo Router for screen navigation
• Supabase Auth for user authentication
• PostgreSQL for schedules, feeding records, device access, and monitoring data
• Supabase Edge Functions with Deno for app and device APIs
• Supabase Realtime for refreshing monitoring and feeding information
• Expo SecureStore for protected local session storage
• React Native Reanimated for interface motion
• React Native SVG for charts and visual elements
• Expo Notifications for notification integration
• Git and GitHub Actions for version control and automated checks