Our Journey So Far
From a single ESP32 handshake to a company with a mission, every step documented.
Preliminary Pairing Protocol
Established the preliminary pairing protocol for the system. The workflow is set: (1) Put the Main ESP into pairing mode to listen, (2) Plug in the Sensor ESP to broadcast its name and state, (3) Select the sensor on the Main ESP to send the Main MAC address, and (4) Establish the connection. Need to focus on using receiver/broadcaster code and setting up "packages" using structs for each module.
Main Code Debugging
Working on the Main Code, using Claude to help explain and fix issues. The setup currently works, but hit a wall where only "smartfarm setup" is visible and WiFi/password inputs aren't working. Decided to scrap the current setup implementation and move forward by writing core code that takes input from the Serial monitor first, then implementing HTML later.
Core Setup Functionality
Successfully debugged the setup code by putting UI elements aside and focusing on core functionality. Developed a rough plan for using Preferences and ESP-NOW. To-Do: Develop a plan for data management and create "packages" to define when and how data is sent and stored.
Version 1
Completed a "bare bones" UI. The server now includes a pairing mode, a pending devices section, and an "Added Devices" section with a popup for adding new modules. The sensor side is programmed to enter pairing automatically, sending out index 255 messages until it receives an index 254 from the server. Code for v1 shows the initial setup using AsyncWebServer and basic ESP-NOW broadcast logic using a Packet1 struct containing MAC, device type, and name.
Version 2 & 3
Completed the Packet 2 infrastructure and established the data communication for the SD card. Added a feature allowing users to edit device names and time intervals, giving control over how frequently sensor readings are sent. Code analysis of v3 shows the addition of Packet2 for sensor data (value, unit, sequence) and the transition to WIFI_AP_STA mode.
Hardware Bottleneck
Encountered a hardware bottleneck. Learned that an issue with the dev kit is interfering with the SD card. Decision: Use SPI mode instead of 1-bit mode for now. When eventually printing custom circuit boards, 1-bit mode will be set up properly.
Version 4, 5, & 6
Focusing on data reliability. Successfully implemented a system to have the server filter triple-broadcasts from sensors. Decision: Considered swapping arrays for lists but decided to keep arrays for speed. While standalone SPI code works, the integrated code is failing to initialize the SD card; this is a priority to troubleshoot. v6 code shows the integration of the SD.h library and chipSelect on pin 5.
Version 7 & 8
Developing the client base and trying to get the server to connect to the internet for timestamps. Architecture Change: Decided to separate the server code into two parts for ease and size management. v8 now has WiFi connection logic via the UI and the ability to clear lists after a network is selected.
Version 9 & 10
Integrated NTP server connections and a dropdown for timezones. v10 is "complete" but buggy; WiFi is crashing the chip and sensor CSVs are reporting date/time incorrectly. v10 code reveals the implementation of ezTime and NTP sync attempts, though the system remains unstable during WiFi connection attempts.
Version 11 & 12
Focusing on fixing v10’s bugs. Incorporated fixes into v12, specifically addressing the inability to add devices after WiFi connection and ensuring the CSV writes the correct time. Moved to VS Code to help manage the growing complexity of the project. However, v12 is currently untested and proving difficult to stabilize.
Version 13 - Architecture Pivot
Architecture Change: v12 was broken, necessitating a significant shift. Decided that the best way forward is to add another ESP32 into the equation. This new architecture will offload internet tasks to a secondary chip.
Ping-Pong Inter-ESP Communications
Experimented with inter-ESP UART communications and got it to work. Successfully powered the second ESP through the first and achieved a "blink" response when specific data was sent. Structure for WiFi connecting and NTP sync can now be set up on the secondary chip.
Ping-Pong v1–v4
UART functionality is now working for WiFi and timezone functions. Decision: Taking v4 in a new direction. In v3, ESP1 requested NTP time and kept an internal timer. In v4, ESP2 (Pong) will keep the time, and ESP1 (Ping) will request the time every single time it needs to use it.
Telegram Alerts Sketch
Set up a sketch for Telegram alerts. Testing with "Liz" suggested adding features to disconnect/reconnect from the server and adding a redirect link for usability. Decision: Use v4 as a proof of concept and worry about user-friendliness later.
Ping-Pong v5 & Integration
Finalized Ping+Pong v5, which combines the Telegram demo with the timing functions. Added "Token:" and "Alert:" commands. Now integrating this with v7 of the server. Brainstormed project names and landed on "Physis" (Greek for nature and growth).
Ping-Pong v6
Standardizing the response structure from Pong to Ping: 0: Ack, 1: Progress, 2: Data, 3: Error, 4: Success. Created Pong v1, which is essentially v7 with WiFi functions stripped off to run on the secondary chip. Improvements for Ping include using a fixed array for clients instead of realloc for stability.
VS Code Transition
Officially moved development into VS Code and making real progress on v12. Redoing Ping-v6 to work better with Pong should solve the current integration issues.
Version 11, 12, 13, & 14
A massive push to finalize integration. v13 fully integrates Pong to v7! Then created v14, which cleaned up the entire code base and resolved all minor issues, resulting in a very polished system. Code for v14 confirms the offloading of tasks to "Pong" via SerialPort(2) at pins 16 and 17.
Version 15
v15 is complete! The system is ready to develop sensors immediately. Code for v15 represents the template sensor firmware, featuring deep sleep logic and automatic pairing with the Master ESP.
Version 16, 17, & 18
Moved into the final refinement stages. Added features for viewing and downloading data directly in the app. v16 added a maximum log size (~600KB) to prevent crashes. v17 introduced metadata for sensor health and calibration, specifically for pH, DO, and EC sensors. v18 added a dedicated system_log.csv to track system events like WiFi connections and pairing.
Housing Refinements
Spent this month resolving issues with the 3D printed housing, including heat dissipation, snapping notches, relief for sliding lids, grips, and general fit/finish. The system is stable and logging successfully.
Circuits & Cloud Roadmap
Developed and finalized the circuits as well as the prototype housings for each sensor module. So far, all data management has been local, but planning development for a cloud database approach and started drafting code for a cloud architecture.
Productization & Infrastructure
The project began shifting from a working technical prototype into a more formal company and product. We decided on the Alitus domain name, purchased the domain, and connected it to Firebase. We also created the early company roadmap, set up professional email addresses and forwarding, and launched the first template version of the website using Firebase hosting. Anand was added to the Firebase project as an administrator so both founders could work within the same production environment. During this same period, we created a Google Sheets task tracker to organize weekly product, software, website, and business development work. This was an important operational step because the project had grown beyond isolated firmware development and now required clearer coordination between hardware, web, cloud, branding, and outreach tasks.
GitHub & Cloud Architecture
We set up the private GitHub repository and structured automated deployments for both the development and production environments. This created a cleaner workflow between active development and the live website. We also began formalizing the written content for the website and product by drafting markdown summaries for the website, web app fields, product messaging, and frontend content structure. On the technical side, we started researching Firebase and Firestore as the likely foundation for cloud data management. Up to this point, most system data had been handled locally through the ESP32/SD card architecture. The research and early implementation work during this period marked the beginning of a major architectural expansion: moving from an isolated local system toward a cloud-connected product with accounts, dashboards, and long-term data access.
Web App & Database Connection
We established the first rough connection between the web app and the database. This was an important proof-of-concept because it connected the website/web app layer to the cloud data layer for the first time. The web app planning also became more concrete, with required fields and dashboard concepts documented in markdown. Anand developed multiple frontend variations for the main website, which gave us options for the visual direction of the company brand. We also worked through website updates, early logo concepts, and graphic ideas for the about page. Some logo and content-review tasks were later de-prioritized or cancelled as we chose to focus on higher-value work, including the YC application, website readiness, and the web app foundation.
Website & YC Application
We began preparing the company for more public-facing conversations. The website content was reviewed and refined, and we started aligning the public message around AI-enabled hydroponic technology for sustainable farming. This period also included initial work on the Y Combinator application, including creating accounts, completing founder profiles, and drafting rough points for the founder video. The website continued to improve visually and structurally. Anand updated the hero page and incorporated final comments and minor detail fixes. At this stage, the website became less of a placeholder and more of an actual front door for Alitus.
Finalizing YC Application
We finalized the Y Combinator application and recorded the founder video. This forced us to clarify several core points: what Alitus makes, why hydroponics needs a lower-barrier and more automated solution, how our hardware/software architecture is different from existing hydroponic offerings, and why the company can have a global impact. This was also a strong forcing function for the company narrative. We clarified that Alitus is building modular, ready-to-deploy hardware and software that automates the hydroponic growing process. We also sharpened the long-term vision: using automation, sensor data, and AI optimization to make food production more reliable, accessible, and sustainable.
Public Devlogs & Partnerships
We began turning the development history into public-facing dev log content for the website. This included compiling previous dev log entries, collecting related images, and creating a working Google Doc for continued dev log updates. The goal is to document the process more consistently going forward and make the company’s progress easier to understand for partners, supporters, investors, and future users. We also researched ways to support donations through the website and drafted a partnership-oriented email for organizations such as Convoy of Hope and Compassion. This marked a meaningful expansion of the company’s direction from simply building a product to intentionally pursuing nonprofit and globalimpact partnerships.
Current Priorities & Active Work
We are actively developing dedicated dev log pages for the website so that the project history can be presented in a cleaner and more organized way. We are also continuing website optimization, including visual improvements and animation, to make the site feel more polished and credible. On the product side, the web app is moving toward a basic account-management and dashboard structure. The current goal is to create a login page, account system, and blank dashboard that can later connect to live system data. This is a key step toward turning the hydroponic controller from a local prototype into a user-facing connected product. We have also initiated the Google Grant process and are continuing work on local AI for development and automation support. The local AI work is intended to support internal development workflows and eventually help inform how Alitus can use AI to manage and optimize hydroponic systems more effectively. The main direction now is clear: maintain the stable local hardware foundation, continue developing the cloud/web application layer, polish the public website and documentation, and begin building relationships with farms, charities, universities, restaurants, and global-impact organizations that could help test, deploy, or support the system.
Be Part Of The Journey.
Every prototype, experiment, and breakthrough brings us one step closer to our vision. If you’d like to help accelerate the development of Alitus, we’d be grateful for your support.
Support Our Mission →