Pico-Home-Hub

System Architecture 📊

               ┌────────────────────────┐
               │      Home Server       │
               │  (Domoticz or Spring)  │
               └────────┬──────┬────────┘
                        ▲      ▲
                        │      │
                        │      │
                        │  ┌──────────────────────┐
                        │  │     User Devices     │
                        │  │   (Phone, Browser)   │
                        │  └──────────────────────┘
                        │
                        ▼
 ┌────────────────────────────────────────────────┐
 │      Communication via Middleware (PUSH)       │
 │         or Direct Fetch by Server (PULL)       │
 │               using HTTP protocol              │
 └────────────────────────┬───────────────────────┘
                          │
                          ▼
     ┌────────────────────────────────────────┐
     │         Pico-Home-Hub Devices          │
     │  (Raspberry Pi Pico + Sensors/Relays,  │
     │     running MicroPython over LAN)      │
     └────────────────────────────────────────┘

🔄 Communication Flow Summary:

• PUSH: Middleware script running on the Home Server fetches data from the Pico and sends it to Domoticz or a Spring Boot app via HTTP.
• PULL: Domoticz or Spring Boot can directly fetch data from the Pico devices’ REST API.
• User Devices: Users interact solely with Domoticz or Spring through a web browser or mobile app — never directly with Pico devices.

📡 Communication Details:

• Pico-Home-Hub Devices (Raspberry Pi Pico + sensors/actuators) communicate with the Home Server (Domoticz or Spring Boot) using HTTP requests (GET/POST) over the local Wi-Fi network.
• The Home Server handles all incoming requests, device management, and optional data storage. It also serves as the central interface for user interaction.
• No data leaves your local network, ensuring full privacy and offline functionality for all connected devices.

📄 Project Data Sheet

Property	Details
Project Name	Pico-Home-Hub
Platform	Raspberry Pi Pico (MicroPython)
Communication	HTTP (Local Network Only)
Privacy	100% Local Data – No external/cloud communication
Compatible Server	Domoticz on Raspberry Pi 4B or custom Spring Boot + MongoDB (planned)
Target Users	DIY Enthusiasts, Makers, Smart Home Developers
License	MIT (or your choice)
Status	Active Development

🚀 Roadmap

Feature/Component	Status
HTTP communication between Pico and server	✅ Implemented
Support for basic sensors (e.g., DHT22, PIR)	✅ Implemented
Domoticz integration on Raspberry Pi 4B	✅ Supported
Server application using Spring Boot + MongoDB	🔄 In development
Web UI for device control and monitoring	🔄 Planned
MQTT protocol support (optional) with Apache Kafka	🔄 Planned
OTA updates for Pico devices	🔄 Planned
Secure communication (e.g., HTTPS/Token auth)	🔄 Planned

Example config.py

WIFI_SSID = 'Your-network-name'
WIFI_PASSWORD = 'secretpass'
IP_ADDRESS = '192.168.0.12'
SUBNET_MASK = '255.255.255.0'
GATEWAY = '192.168.0.1'
DNS = '8.8.8.8'

Execution

1. Add config.py described above.
2. Change pico3.py to main.py.
3. Copy whole files structure to Raspeberry Pi Pico (W). .uf2 file must be added to pico for micropython support

How does it work

WiFi library

In the main file, the program will attempt to connect to the WiFi network using the data provided in config.py. This operation is handled in a loop. Once a network connection is established, the library will attempt to open a socket on port 80.

If the operation is unsuccessful, the machine will be restarted to release resources and prevent errors related to improper socket closure.

After successfully opening the socket, the program will wait for client connections (API requests).

The opened socket will throw timeout error after 5 seconds if no client connections are received. This behavior is intentional, allowing the program to perform other tasks, such as checking the WiFi connection.

If the WiFi connection is lost, the library will continuously attempt to reconnect in an infinite loop. Once the WiFi connection is successfully restored, the program will check if the socket is still open. If the socket is not open, the program will attempt to reopen it, which may trigger the machine restart described above.

Request library

The request library is designed to handle received HTTP requests. When the socket receives a message from a client, it is a byte object. The main program converts this byte object into a string, which may look like this:

b'GET /switch-one/off HTTP/1.1\r\nX-RESPONSE-TYPE: 1[...]\r\n\r\n'

The role of the request library is to decode provided string in the following way:

1. Based on the start of the string, the library sets requestMethod field to one of the following:

• GET
• POST
• PUT
• DELETE

The request method is an enum type implemented as a singleton with str values.

2. From the next part of the string, the library extracts the requested endpoint and assigns it to the endpoint variable.
3. The library also checks if X-RESPONSE-TYPE header is provided. This header is used to manage Content-Type header and can take the following values:

• 1 - For the JSON type.
• 2 - For the TEXT/HTML type (default).

The response type is stored in a variable named responseType. This variable is represented by an enum, also implemented as a singleton with str values.

Technologies and Protocols

Bit-Banging

Bit-banging SPI communication was introduced in clockDS1302