🆕 Funzionalità Auto-Discovery - Aggiunto metodo AutoDiscoverBufferSizes() per rilevamento automatico QPIGS/QPIRI/QMOD/QPIWS - Supporto variabili d'ambiente (INVERTER_DEVICE, MQTT_SERVER, etc.) - Caching persistente buffer sizes in /cache/inverter.conf.cache - Flag -a/--auto-discover per modalità auto-detection 🐛 Bug Fixes Critici - **Parsing interi**: Aggiunta attemptAddSettingInt() con stoi() invece di stof() - Fix: stof('98') = 98.0f → 97 (int), ora stoi('98') = 98 direttamente - Applicato a: qpiri, qpiws, qmod, qpigs - **Thread sync**: Aggiunto ups_qpiws_changed a main loop e condizione exit poll() - Fix: loop principale controllava solo 3 flag su 4, causava hang - Fix: thread poll() non usciva in runOnce perché mancava controllo QPIWS - **Config accuracy**: Corretti buffer sizes (qpiri: 98→103, qpiws: 36→40) - Rimosso sources/inverter-cli/inverter.conf che sovrascriveva config globale - Validato con test: inverter_poller -1 completa in 6s con JSON completo 📚 Documentazione Completa - Creato documentation/CODE_ARCHITECTURE.md (38KB) - Mappa logica variabili globali - Flusso esecuzione main() con diagrammi ASCII - Sequence diagram classe cInverter (poll, query, auto-discovery) - Thread synchronization diagrams - MQTT integration bash scripts flow - Mappa concettuale 5-layer system architecture - Error handling e performance optimizations - Organizzati file .md in documentation/ (AUTO_DISCOVERY, IMPLEMENTATION, QUICKSTART, DEBUG) - Aggiornato README.md con sezione v2.0 e indice documentazione - Aggiornato .github/copilot-instructions.md con novità v2.0 🔧 Miglioramenti Build & CI/CD - Gitea Actions per build multi-arch (arm/v6, arm/v7, arm64, amd64, 386) - Configurazione VS Code completa (tasks, launch, debug GDB) - Script test-autodiscovery.sh e test-device.sh ✅ Testing Validato - inverter_poller -1 completa in 6 secondi - Output JSON completo con tutte le metriche - Exit pulito senza timeout (exit code 0) - Tutte le 4 query QMOD/QPIGS/QPIRI/QPIWS funzionanti
3.5 KiB
Gitea Actions per Docker - Raspberry Pi
Questo progetto utilizza Gitea Actions per automatizzare la build e il deployment delle immagini Docker per architetture ARM (Raspberry Pi).
Workflows Disponibili
1. docker-build.yml
Build e push automatico delle immagini Docker multi-architettura per Raspberry Pi.
Trigger:
- Push su branch
main,master, odevelop - Creazione di tag con pattern
v*(es. v1.0.0) - Pull request su
mainomaster
Architetture supportate:
linux/arm/v6- Raspberry Pi Zero, Pi 1linux/arm/v7- Raspberry Pi 2, 3, 4 (32-bit)linux/arm64- Raspberry Pi 3, 4 (64-bit)
2. docker-test.yml
Test della build Docker senza pubblicazione.
Trigger:
- Pull request su branch principali
3. docker-cleanup.yml
Pulizia periodica delle immagini Docker vecchie.
Trigger:
- Schedulato: ogni domenica alle 2:00 AM
- Manuale: tramite workflow_dispatch
Configurazione
Secrets Richiesti
Per utilizzare questi workflows, devi configurare i seguenti secrets in Gitea:
- DOCKER_USERNAME: Il tuo username Docker Hub
- DOCKER_PASSWORD: Il tuo password/token Docker Hub
Come aggiungere i secrets in Gitea:
- Vai nelle impostazioni del repository
- Seleziona
Secrets→Actions - Aggiungi i seguenti secrets:
- Nome:
DOCKER_USERNAME, Valore:tuo-username-dockerhub - Nome:
DOCKER_PASSWORD, Valore:tuo-password-o-token-dockerhub
- Nome:
Configurazione Runner Gitea
Assicurati di avere un Gitea Actions runner configurato. Se stai usando un Raspberry Pi come runner:
# Installa il runner Gitea (act_runner)
wget https://dl.gitea.com/act_runner/latest/act_runner-latest-linux-arm64 -O act_runner
chmod +x act_runner
# Registra il runner
./act_runner register --instance https://tuo-gitea-server.com --token IL_TUO_TOKEN
# Avvia il runner
./act_runner daemon
Tag e Versioning
Le immagini Docker vengono taggate automaticamente:
latest- ultima versione del branch principalemain/master/develop- nome del branchv1.2.3- versioni semver dai tag Git1.2- major.minor dai tag semverpr-123- numero della pull request
Build Locale
Per testare la build localmente:
# Build per Raspberry Pi 4 (64-bit)
docker buildx build --platform linux/arm64 -f Dockerfile.multiarch -t ha-voltronic-mqtt:test .
# Build per Raspberry Pi 3 (32-bit)
docker buildx build --platform linux/arm/v7 -f Dockerfile.multiarch -t ha-voltronic-mqtt:test .
# Build multi-arch (richiede buildx con QEMU)
docker buildx build --platform linux/arm/v6,linux/arm/v7,linux/arm64 \
-f Dockerfile.multiarch -t ha-voltronic-mqtt:test .
Cache
I workflow utilizzano GitHub Actions cache (compatibile con Gitea) per velocizzare le build successive:
cache-from: type=gha- utilizza cache esistentecache-to: type=gha,mode=max- salva cache completa
Troubleshooting
Build fallisce con "platform not supported"
Verifica che il runner abbia QEMU installato e configurato per l'emulazione multi-arch.
Secrets non trovati
Assicurati di aver configurato correttamente i secrets nelle impostazioni del repository Gitea.
Runner non esegue i workflow
Verifica che il runner sia attivo e registrato correttamente con il comando:
./act_runner daemon --log-level debug
Note
- Le build multi-arch possono richiedere diversi minuti, specialmente su hardware limitato
- Per Raspberry Pi si consiglia di usare un server separato per le build, non il Pi stesso
- Il workflow utilizza Docker Buildx per supporto multi-architettura