🏗️ How I Built MyZubster: A Decentralized Green Ecosystem with AI, IoT and Blockchain
A technical journey into building a system that combines AI, robotics, Monero, Tor, IoT and open-source hardware to explore smarter and more sustainable gardens.
MyZubster started as an experiment around plants and technology.
It gradually evolved into something much larger:
- 🤖 AI assistants
- 🌱 smart gardening
- 📡 IoT sensors
- 🤏 embedded devices
- 🤖 robotics
- 🧅 Tor services
- 💰 Monero integration
- 🔓 open-source infrastructure
- ⚡ industrial automation
This article explains how the different pieces fit together.
📋 Architecture at a Glance
The system is divided into several layers:
text
┌──────────────────────────────────────────────┐
│ FRONTEND LAYER │
│ Portal / Marketplace / CLI │
└──────────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ BACKEND LAYER │
│ Gateway API / Pytho / AI-CAD │
└───────────────┬───────────────┬──────────────┘
│ │
┌───────▼──────┐ ┌────▼────────────┐
│ PRIVACY │ │ BLOCKCHAIN │
│ Tor / PGP │ │ Monero / MYZ │
└───────┬──────┘ └────┬────────────┘
│ │
└──────┬───────┘
│
▼
┌──────────────────────────────────────────────┐
│ IoT / HARDWARE LAYER │
│ ESP32 / Pinch / NFC / VFD / Robotics │
└──────────────────────────────────────────────┘
The important design principle is modularity.
Each component should be replaceable without rebuilding the entire ecosystem.
🧱 Technology Stack
The current architecture is based around several technologies.
Backend
Runtime:
- Node.js
- Express.js
Communication:
- REST APIs
- WebSockets
- Serial communication
Storage:
- SQLite
- JSON files
AI
AI:
- DeepSeek API
- Ollama fallback
Knowledge:
- Hardware knowledge base
- Design patterns
- Project context
Vector Search:
- Embeddings
- ChromaDB
Privacy
Privacy:
- Tor
- Onion Services
- SOCKS5
- PGP
Authentication:
- JWT
IoT
IoT:
- ESP32
- Moddo Pinch
- MQTT
- CoAP
- SerialPort
- NFC
Blockchain
Blockchain:
- Monero
- JSON-RPC
- monero-wallet-rpc
Ecosystem:
- MYZ
DevOps
Infrastructure:
- Docker
- Docker Compose
- PM2
- GitHub Actions
🤖 Pytho AI
One of the most interesting components is Pytho, the AI assistant inside the MyZubster ecosystem.
The idea wasn't to build another generic chatbot.
Instead, Pytho is designed around the project's hardware and software.
It can work with:
component information
hardware specifications
design patterns
project context
troubleshooting information
gardening data
system APIs
The simplified architecture looks like this:
User
│
▼
Pytho AI
│
├── Intent Analysis
│
├── Knowledge Retrieval
│
├── Project Context
│
└── Response Generation
│
▼
User
A simplified implementation looks like:
class PythoAI {
constructor() {
this.knowledgeBase = {
components: this.loadComponents(),
patterns: this.loadDesignPatterns(),
solutions: this.loadSolutions()
};
this.models = {
remote: new DeepSeekClient(),
local: new OllamaClient(),
fallback: new LocalKnowledgeBase()
};
this.context = {
history: [],
project: "MyZubster",
preferences: {}
};
}
async processQuery(query) {
const intent = await this.analyzeIntent(query);
const context =
await this.retrieveContext(intent);
const response =
await this.generateResponse(query, context);
return this.formatResponse(response);
}
}
The important part is the separation between:
query → intent → retrieval → generation
rather than simply sending every question directly to an LLM.
🧠 Hardware Knowledge Base
Pytho can use structured hardware information.
For example:
components:
ESP32:
type: microcontroller
specs:
cpu: "Dual-core Xtensa"
wifi: true
bluetooth: true
alternatives:
- ESP8266
- RP2040
- STM32
CubeMars_RI30:
type: motor
specs:
kv: 260
torque: "project-dependent"
application:
- robotics
- joints
- actuators
This allows the AI to reason about components in the context of the project.
For example:
"Which controller should I use for this sensor?"
Instead of giving a generic answer, Pytho can consider the project's existing hardware and interfaces.
🏗️ AI-CAD: From Conversation to Hardware Design
Another experimental direction is AI-assisted CAD.
The idea is to let an AI system help transform a high-level engineering problem into possible mechanical solutions.
For example:
User:
"I need to connect two tubes but the NFC reader
cannot fit in the original position."
│
▼
Pytho AI
│
┌───────┼────────┐
▼ ▼ ▼
45° Offset Flexible
joint mount adapter
│
▼
Cost / complexity /
compatibility analysis
The AI doesn't replace engineering validation.
Instead, it can reduce the amount of time required to explore possible designs.
That distinction is important.
AI-generated hardware designs still need to be reviewed, simulated and physically tested.
🧅 Tor Integration
Privacy is another architectural layer.
MyZubster experiments with Tor onion services to provide an alternative way to access ecosystem services.
The architecture is:
Tor Browser
│
▼
Tor Network
│
▼
Onion Service
│
▼
MyZubster Gateway
│
┌───┼─────────┐
▼ ▼ ▼
AI Portal APIs
Tor can provide network-level privacy properties, but it should not be confused with complete application anonymity.
For example, applications still need to consider:
authentication
application logs
metadata
browser configuration
account identifiers
operational security
Privacy therefore needs to be designed at multiple layers.
💰 Monero Integration
Financial privacy is another part of the ecosystem.
MyZubster experiments with Monero (XMR) as a privacy-oriented payment layer.
The architecture can be represented as:
MyZubster
│
┌────────┴────────┐
│ │
Services Users
│ │
└────────┬────────┘
│
▼
Monero
│
▼
Private payments
The goal is not to add blockchain technology simply for marketing.
The question is:
Where can privacy-preserving digital money provide real value inside a physical ecosystem?
Potential applications include:
community rewards
marketplace transactions
donations
device operators
ecosystem services
Any financial implementation still needs proper wallet security, transaction validation and operational controls.
🌱 IoT: Connecting Plants to Software
A smart garden needs reliable data.
MyZubster experiments with small embedded devices and environmental sensors.
Typical measurements include:
temperature
soil moisture
light
device status
plant identifiers
A simplified payload:
{
"deviceId": "PINCH-001",
"plantId": "tomato-san-marzano",
"temperature": 24.5,
"soilMoisture": 68,
"lightLevel": 780
}
The gateway can then process the data.
Sensor
│
▼
Embedded Device
│
▼
MQTT / Serial / API
│
▼
MyZubster Gateway
│
├── Database
├── AI
├── Dashboard
└── Automation
📡 NFC Integration
Physical plants can also be connected to digital records using NFC.
The concept is straightforward:
Physical Plant
│
▼
NFC Tag
│
▼
NFC Reader
│
▼
MyZubster API
│
▼
Plant Record
This creates a bridge between physical objects and digital information.
A visitor could scan a tag and retrieve information about:
plant species
planting date
garden location
historical information
maintenance data
🤖 Robot Gardener
The physical automation layer is where MyZubster becomes particularly interesting.
The robot can combine:
motors
encoders
sensors
controllers
AI
navigation
garden data
A simplified system:
MyZubster
│
▼
Robot Gateway
│
┌───────────┼───────────┐
▼ ▼ ▼
Sensors Controller AI
│ │ │
└───────────┼───────────┘
▼
Motors
│
▼
Garden Robot
Potential applications include:
autonomous navigation
plant inspection
irrigation assistance
harvesting assistance
selective maintenance
environmental monitoring
The objective is to create useful automation while keeping humans in control of the system.
⚡ Industrial Automation
The same architecture can scale from a tiny sensor to industrial automation.
Components such as VFD controllers, MQTT and Modbus can connect physical infrastructure to the software layer.
Sensors
│
▼
Edge Gateway
│
├── MQTT
├── Modbus
└── REST API
│
▼
Industrial Controller
│
▼
VFD
│
▼
Motor / Pump
This could be useful for applications such as automated irrigation.
For example:
Soil Moisture < Threshold
│
▼
Automation
│
▼
VFD Start
│
▼
Irrigation Pump
Safety limits and hardware interlocks should always remain independent of AI decisions.
🐳 Docker Deployment
Containerization makes development and deployment easier.
A simplified deployment might look like:
services:
gateway:
build: ./gateway
ports:
- "3001:3001"
pytho:
build: ./pytho
ports:
- "3005:3005"
database:
image: sqlite
tor:
image: tor
mqtt:
image: eclipse-mosquitto
The advantage is reproducibility.
A developer can bring up multiple components without manually configuring every dependency.
🔌 API-First Architecture
The different components communicate through APIs.
Examples include:
/api/auth/*
/api/wallet/*
/api/nfc/*
/api/pinch/*
/api/vfd/*
/api/robot/*
/api/pytho/*
This makes it possible to replace individual components.
For example:
Gateway API
│
┌──────────┼──────────┐
▼ ▼ ▼
ESP32 Robot AI
│ │ │
▼ ▼ ▼
Hardware Hardware Software
The API becomes the integration layer.
📊 Observability and Testing
A distributed system needs visibility.
Important metrics include:
API response time
device connectivity
sensor data freshness
motor status
gateway health
AI response time
error rates
transaction state
A simple health endpoint can provide:
{
"gateway": "online",
"iot": "online",
"robot": "standby",
"ai": "online",
"tor": "connected"
}
For real deployments, this should be extended with proper monitoring, structured logs and alerting.
🧩 Challenges
Building an ecosystem like this creates several engineering challenges.
1. Hardware Compatibility
Different devices use different protocols.
Solution:
Use adapters and standardized interfaces wherever possible.
2. AI Reliability
An LLM can generate incorrect information.
Solution:
Use structured knowledge bases, validation and deterministic safety rules.
3. Privacy
Tor alone does not solve every privacy problem.
Solution:
Treat privacy as a system-wide property involving networking, authentication, storage and operational practices.
4. Hardware Safety
AI should never have unrestricted control over physical machinery.
Solution:
Use hardware-level safety limits and independent control layers.
AI
│
▼
High-Level Command
│
▼
Safety Controller
│
├── Limits
├── Interlocks
└── Emergency Stop
│
▼
Motor
5. Complexity
Combining AI, IoT, robotics and blockchain creates a large system.
Solution:
Keep components modular.
Each service should have a clear responsibility.
🔮 What's Next?
The next stage of development is about moving from individual components toward a more integrated ecosystem.
Possible directions include:
🔗 P2P communication
📱 Mobile applications
🌱 More environmental sensors
🤖 Autonomous robotics
🧅 Additional privacy services
💰 Deeper Monero integration
🏪 Decentralized marketplace experiments
👥 Community governance
📊 Better observability
🧪 Hardware-in-the-loop testing
🔓 Why Open Source?
The most important part of the project isn't a specific component.
It is the ability for other people to experiment with it.
Developers can improve the APIs.
Hardware enthusiasts can build new devices.
Robotics developers can improve motion systems.
Privacy researchers can audit the architecture.
Gardeners can propose real-world applications.
That is why MyZubster is being developed as an open-source experiment.
🤝 Contributing
There are many areas where contributors can help:
🤖 AI
Improve Pytho and hardware reasoning.
📡 IoT
Add sensors and embedded platforms.
🌱 Botany
Expand plant and garden databases.
🤖 Robotics
Improve navigation and manipulation.
🔐 Security
Audit authentication, APIs and infrastructure.
🧅 Privacy
Review Tor integration and privacy architecture.
📚 Documentation
Write tutorials and integration guides.
🌿 Final Thoughts
MyZubster started with a simple question:
Can technology help us build more sustainable physical communities without giving up openness and privacy?
There isn't a final answer yet.
Instead, we're building an experiment.
AI provides intelligence.
IoT provides data.
Robotics provides physical action.
Monero provides a privacy-oriented financial layer.
Tor provides an alternative privacy layer for network access.
Open source provides collaboration.
And the garden provides the real-world environment where everything comes together.
🌱 SUSTAINABILITY
│
┌──────┼──────┐
│ │ │
IoT AI Robotics
│ │ │
└──────┼──────┘
│
MyZubster
│
┌──────┼──────┐
│ │ │
Tor Monero Open Source
│ │ │
└──────┼──────┘
│
🌍 DECENTRALIZATION
The interesting part isn't any single technology.
It's what happens when they work together.
🌿 Build openly.
🔐 Respect privacy.
🤖 Automate responsibly.
🌍 Keep experimenting.
🔗 Project
GitHub:
https://github.com/DanielIoni-creator/I-ECO-01
👽 Pytho:
"The future doesn't have to be centralized. Sometimes it starts with a seed, a sensor and a line of code."
🌿🤖🧅💰🔓
#Monero #XMR #OpenSource #IoT #Robotics #AI #Tor #Blockchain #Sustainability #MyZubster
Top comments (0)