[Smart Beekeeping Dev Log Part 2] Designing the "ID Card" for Our Hives

 Hello everyone, and welcome back.

Last week, in Part 1, we explained why we chose NFC tags over handwritten notes or QR codes to withstand the harsh environment of the apiary (sticky gloves, dirt, and rain).

Now that we have the hardware (NFC tags and a smartphone), the next question is software: "What exactly should we write on these tags?"

Today, we dive into the Data Architecture. As a developer-turned-farmer, this is where I had to balance "Technical Perfection" with "Field Flexibility."

---

1. The Dilemma: "Storage" vs. "Key"

When using NFC, there are two main ways to handle data. This was my first technical hurdle.

• Option A: Store Everything on the Tag (The USB Approach)

  • We write the entire inspection history (dates, disease status, queen condition) directly into the NFC tag's memory.

  • Pros: No internet connection needed.

  • Cons: Data Loss Risk. If a tag gets damaged or the hive cover blows away in a typhoon, the history is gone forever. Also, NFC tags have very limited storage space.

• Option B: Store Only the ID (The Credit Card Approach)

  • The tag only holds a unique number (UID). The actual data lives safely in our database (Server/Local PC). The phone scans the ID and asks the database, "Who is this?"

  • Pros: Safe data backup, unlimited storage, easy to analyze later.

Our Decision: Option B (UID Mapping) We decided to use the NFC tag strictly as a "Physical Key". In the rough environment of a farm, hardware can always be damaged or lost. By storing only a unique ID on the tag, even if a tag is destroyed, our precious data remains safe in the system. We just need to attach a new tag and map it to the existing data.

For this series, our primary focus is strictly on "Data Collection"—building a robust pipeline to get data from the field into the system.

---

2. The Philosophy: "This is Not Medical Data"

When designing a database, developers often fall into the trap of trying to build a "Perfect Castle" from the start. We worry about every possible future scenario and over-engineer the structure.

But as we planned this system, we reminded ourselves: "This is beekeeping, not medical surgery."

We don't need a rigid, flawless system right from day one. In farming, variables change constantly.

• Today, we might care about "Varroa mites."

• Next year, we might need to track a new type of "Feed efficiency."

Therefore, we adopted an Agile/Iterative approach. We will build the basic structure now, and as we use it in the field, we will add columns and modify the schema flexibly. We are building this castle one brick at a time, based on real-world feedback.

---

3. The Blueprint: What Are We Tracking?

Even though we are staying flexible, we need a baseline. Here is the initial Data Structure (Schema) we designed for our hives.

• Hive UID (Primary Key): The link to the NFC tag.

• Queen Status:

  • Presence (Yes/No)

  • Type (Virgin Queen / Mated Queen)

  • Age (New Queen / Old Queen)

• Colony Strength:

  • Frame Count (Total frames vs. Brood frames)

  • Grade (Strong / Medium / Weak)

• Health & Disease:

  • Symptoms (e.g., Chalkbrood, Mites)

  • Treatment History (Medication used, Dosage)

• Installation Info:

  • Date of setup

  • Origin (Swarm capture, Artificial division, etc.)

• Multimedia Notes:

  • Voice Memos: "Frame 3 looks a bit empty." (To be analyzed by AI later)

  • Photos: Visual records of the brood pattern.

This structure allows us to capture the "Health Vitals" of a hive in seconds.

---

4. What's Next?

We have defined the hardware (NFC) and the blueprint (Data Structure). Now, it is time to bring it to life with code.

In Part 3, we will open Visual Studio and start building the Android app using .NET MAUI. I will share how we write the code to actually read the NFC tags and connect them to this data structure.

See you next Wednesday!