Hack my Daikin HPSU Compact: terza parte

finishing_the_puzzle_by_picxilete-d6usw6v

Se avete letto (e realizzato) le due puntate precedenti:

Hack my Daikin HPSU Compact: prima parte

Hack my Daikin HPSU Compact: seconda parte

Siamo pronti per completare un sistema di monitoraggio avanzato della vostra Daikin HPSU Compact.

L’obiettivo e’ quello di poter pubblicare su un servizio in cloud i dati rilevati dai contatori interni della pompa di calore onde farne analisi in tempo reale e su base storica.

Successivamente, ma vi rimando al prossimo inverno, saremo anche in grado di controllare in modo automatico la pompa di calore.

Libreria di raccolta e pubblicazione dati

Questo e’ il fulcro software del sistema e ringrazio ancora una volta zanac per la sua realizzazione ho solamente supportato in minima parte.

Al momento non c’e’ ancora un procedura di installazione consolidata, per cui occorre andare sul progetto in GitHub e scaricare ed installare il tutto:

https://github.com/zanac/pyHPSU

Nella versione corrente la sintassi di utilizzo e’ la seguente:

pyHPSU.py -d DRIVER -c COMMAND
-d --driver driver name: [ELM327, PYCAN, EMU, HPSUD]
-p --port port (eg COM or /dev/tty*, only for ELM327 driver)
-o --output_type output type: [JSON, CSV, CLOUD] default JSON
-c --cmd command: [see commands domain]
-v --verbose verbosity: [1, 2] default 1
-u --upload upload on cloud: [_PLUGIN_]
-l --language set the language to use [EN IT DE]
-g --log set the log to file [_filename]

Con un esempio di utilizzo pratico si vede che e’ alquanto semplice:

python3 /home/pi/pyHPSU-master/pyHPSU.py -d PYCAN -c t_hc_set -c t_dhw_set -c t_ext -c t_outdoor_ot1 -c ta2 -o CLOUD -u EMONCMS -g /home/pi/hpsu.medium.log -v 1
[Notate la sintassi estesa che ho utilizzato includendolo in uno script]

  • -d PYCAN: specifica il driver per la librieria Python CAN (quella utilizzata con la scheda PiCAN2)
  • -c t_hc_set -c t_dhw_set -c t_ext -c t_outdoor_ot1 -c ta2: e’ l’elenco di variabili prelevate dalla HPSU con l’invocazione del comando (utilizzando i nomi definiti nel vocabolario applicativo)
  • -o CLOUD -u EMONCMS: specifica di pubblicare contestualmente in cloud spendendo verso emoncms.org
  • -g /home/pi/hpsu.medium.log -v 1: specifica un file di log con verbosità alta

Il tutto e’ basato su un file di configurazione di sintassi alquanto chiara ed auto-esplicativa:

[config]
apikey=YOUR-API-KEY-HERE
[node]
node_30=t_hs,t_hc,flow_rate,t_return,mode,t_ext,t_hc_set,bpv,posmix,t_dhw,t_dhw_set,t_v1,t_dhw1,t_vbh,t_r1,tliq2,tdhw2,ehs,qboh,qchhp,qch,qwp,qdhw,pump,ta2,t_outdoor_ot1,t_dhw_setpoint1,hyst_hp

Al fine di non perturbare troppo il sistema e dati i limiti di frequenza di pubblicazione su emoncms, ho creato tre timer + servizi schedulati che catturano e pubblicano i dati con frequenza differenti.

Selezione delle metriche HPSU

Direi che questa parte, superate le complessità tecniche, e’ stata quella più lunga in termini di tempo soprattutto perché la documentazione Daikin non e’ spesso chiara/completa.

L’esito e’ stata la selezione di un set di parametri che si sono rivelati affidabili ed associabili facilmente allo schema di funzionamento della HPSU:

hpsu

hpsu_1

DISPLAYVOCABOLARIOSCHEMADESCRIZIONEUnita’
Flusso Volumetricoflow_rateV1Portata flusso circolazione acqual/h
Pos Mixposmix3UV DHWPosizione valvola 3 vie 3UV DHW%
BPVbpv3UBV1Posizione valvola 3 vie 3UV B1%
T-GDCt_v1tV1Temperatura di mandata scambiatore a piastre°C
T-ACSt_dhw1tDHW1Temperatura bollitore acqua calda°C
T.Circ.Risc.t_vbhtV,BHTemperatura mandata pavimento o uscita bollitore°C
T-ritornot_r1tR1Temperatura di ritorno°C
PumppumppumpVelocità pompa di circolazione acqua%
EHSehsehsPotenza backup-heaterkW

Oppure la visualizzazione della modalità di funzionamento / set-point impostati correntemente sul sistema:

DISPLAYVOCABOLARIODESCRIZIONEUnita’
ModemodeModalità attuale pompa di caloreRiscaldamento, Raffrescamento,
Produzione ACS, Sbrinamento
T.Circ.Risc.Nom.t_hc_setTemperatura nominale mandata riscaldamento°C
T-ACS Nom.t_dhw_setTemperatura nominale bollitore acqua calda°C

Calibrazione sensori di temperatura

Al fine di garantire misure il più possibile affidabili, in particolare quelle di potenza ed energia, e’ necessario effettuare una taratura delle misure dei sensori “fisici” di temperatura. Questo serve a garantire che calcolando delle differenze di temperatura si siano rimossi/minimizzati gli errori di misura dei sensori veri e propri.

Il software garantisce infatti di collezionare i dati digitali presenti sul bus della HPSU, ma l’esperienza pratica di tutti i possessori di questa pompa di calore ci dice che le misure di temperatura presenti non si “parlano” mai (in particolare i famigerati T-GDCT.Circ.Risc.).

La procedura di calibrazione che ho seguito e’ alquanto semplice:

  • ho messo la pompa di calore in condizioni di riscaldamento ma con una temperatura di mandata nominale estremamente bassa: il risultato e’ che la pompa di circolazione gira (al massimo valore possibile) mentre il compressore esterno rimane spento
  • in questa condizione, osservando lo schema interno di funzionamento, dopo un certo numero di ore in cui il sistema stabilizza qualsiasi transitorio deve essere necessariamente tV1 = tV,BH = tR1 (o in altri termini T-GDC = T.Circ.Risc. = T-Ritorno)
  • Scegliendo come valore corretto quello mediano, otteniamo gli off-set da applicare alle singole misure per “normalizzare” il valore a quello più corretto (statisticamente parlando)
  • Questo ci assicura che nel calcolo delle potenze abbiamo rimosso totalmente l’errore dovuto alla tolleranza dei sensori di temperatura
  • Non siamo ovviamente “protetti” dagli errori associati a non linearità dei sensori (differenze che variano al variare della temperatura) e dalla risoluzione della misura stessa

Nella pratica del mio esemplare di HPSU posso dire che:

  • la calibrazione e’ perfettamente affidabile per le temperatura tipiche del riscaldamento (intorno ai 30 °C)
  • si evidenziano delle non linearità (quindi differenze) per le temperature tipiche della produzione di ACS (intorno ai 50 °C)
  • ho preferito la perfetta calibrazione in riscaldamento poiché e’ di gran lunga la condizione di funzionamento in cui viene prodotta più energia termica nel corso dell’anno

Calcolo di potenza/energia termica e COP

Oltre ad apprezzare il funzionamento in tempo reale, siamo ora in grado di calcolare le metriche più interessanti per verificare l’efficienza del funzionamento della nostra HPSU.

La formula di base per poter calcolare la potenza termica scambiata da un circuito qualsiasi in cui circola acqua e’ la seguente:

P termica ( W) = 1,163 * Portata (l/h) * ΔT ( °C)

Questa formula può essere applicata ai vari elementi del nostro impianto, ma occorre porre attenzione alla presenza delle valvole a 3 vie che cambiano la configurazione idraulica, in particolare durante le fasi transitorie. In questo senso lo sbrinamento e’ la fase più complessa in termini di “attribuzione” dei vari flussi termici.

La misura della potenza/ energia termica netta che transita sullo scambiatore a piastre e’ quella più precisa in assoluto perché non soffre dei vari stati delle valvole a tre vie:

Exchanger Power = 1.163 * V1 * (tV1 – tR1)

L’unico difetto che ha e’ che non consente di distingue i contributi termici dovuti a fasi tra di loro molto diverse come riscaldamento, sbrinamento ed ACS. Questo diventa particolare importante col comportamento della HPSU Compact che, per basse temperatura di mandata, preleva tutto il calore necessario agli sbrinamenti dall’accumulo.

Per questo motivo, data la limitatezza di emoncms.org per fare calcoli avanzati sui valori di input, ho adottato le formule seguenti per valutare la potenza termica netta inviata al pavimento ed all’accumulo:

Floor Power = 1.163 * V1 * (tV,BH – tR1) ; Heating Mode only

Tank Power = 1.163 * V1 * (tV1 – tV,BH) + EHS ; DHW Mode or Defrost Mode only

Queste 2 formule sono affette da un errore marginale durante le fasi transitorie (valvole a 3 vie in movimento da uno stato stabile all’altro).

Con queste definizioni la perdita per gli sbrinamenti si sposta sulla potenza termica inviata all’accumulo che viene decurtata dell’energia sottratta a causa degli sbrinamenti. Nella pratica si vede bene che con sbrinamenti frequenti il Tank COP si riduce drasticamente, per quanto una frazione di calore vada anche verso il pavimento.

Vediamo l’andamento delle tre misure di potenza termica in fase di riscaldamento ed ACS:

floor tank

Si vede benissimo:

  • la perfetta aderenza di Floor Power e Exchanger Power
  • la sovra-stima di Tank Power rispetto ad Exchanger Power (dovuta alla differenza non lineare dei sensori di temperatura al crescere della temperatura stessa)

I COP in tempo reale vengono calcolati dividendo la potenze/energia termica per la corrispondente potenza/energia elettrica.

L’energia viene calcolata dalla potenza utilizzando il processor Power to kWh di emoncms.

Utilizzando le dashboard di emoncms e’ possibile creare viste davvero gradevoli e potenti che potenti che potete apprezzare qui’ in Tempo Reale.

Il sistema cosi’ realizzato e’ in grado di misurare il COP effettivo della pompa di calore avulso da qualsiasi influenza dell’impianto idraulico:

  • la potenza termica e’ misurata ai morsetti (scambiatore di calore a piastre)
  • la potenza elettrica e’ misurata ai morsetti (alimentazione di unita’ esterna RRLQ006CAV3 + unita’ interna HPSU Compact 508 (H/C) DB + backup-heater BUH1)

Queste misure sono quindi perfettamente confrontabili con i dati nominali presenti sulla documentazione di prodotto.

Limitazioni & Next Steps

Quando ho creato il sistema, oltre alla sorpresa iniziale, ho scatenato un po’ di mal di pancia e critiche sulla sua attendibilità. Mi duole dirlo ma la maggior parte non in buona fede.

Il punto di partenza e’ che la precisione del sistema e’ quella assicurata dalla Daikin HPSU Compact stessa: non abbiamo aggiunto errori a quelli eventualmente esistenti. Detto in altre parole abbiamo realizzato delle viste facilitate e storicizzate ai dati interni Daikin (Hack my Daikin HPSU Compact).

Aggiungerei che grazie alla calibrazione delle misure di temperatura la precisione della misura della potenza/energia termica del sistema e’ di gran lunga maggiore della HPSU grezza.

Dopo un mesetto abbondante di osservazioni dei dati ci sono comunque una serie di considerazioni da fare che vanno indirizzate

  1. qualche singola estrazione dati dalla HPSU fallisce (campione mancante) – statisticamente irrilevante e sostanzialmente invisibile sui dashboard
  2. qualche singola estrazione dati dalla HPSU fornisce dati palesemente errati (sicuramente errore interno alla HPSU, ad esempio una temperatura che crolla da 30 °C ad 1 °C per risalire immediatamente dopo a 30 °C) – statisticamente irrilevante ma visibile sui dashboard
  3. la frequenza di campionamento delle grandezze termiche (estratte dalla HPSU) e’ differente da quelle elettriche (misurate direttamente da OEM)
  4. per le grandezze calcolate (in particolare ΔT e potenze termiche) tutti i punti precedenti determinano valori “rumorosi” e/o con singoli campioni visibilmente spuri – statisticamente irrilevante ma visivamente molto fastidioso
  5. alcuni sensori sembrano lievemente rumorosi (ad esempio la temperatura di ritorno)

La mia idea di soluzione è che nel layer intermedio tra quello fisico (CAN-Bus) e quello applicativo, la libreria di acquisizione e pubblicazione dei dati, ci dovrebbero stare delle logiche (opzionali) di:

  • data filtering (per attenuare/rimuovere il rumore)
  • data cleansing (per rimuovere dati palesemente fuori scala)
  • calcolo on the fly (calcolare al volo una grandezza derivata da grandezze elementari ma tra campioni tra di loro sincroni)

Questo potrebbe essere del tutto trasparente al layer applicativo che non farebbe altro che invocare normalmente la lettura di una grandezza (nativa o derivata) ottenendo dati estremamente puliti.

Ovviamente le grandezze derivate sarebbero scolpite in un vocabolario per il loro uso con il codice implementativo.

Anche la pubblicazione in cloud dovrebbe fare uso di questo servizio intermedio per poter visualizzare/storicizzare dati puliti.

Esempi di calcoli on-the-fly di grandezze derivate:

  • applicazione di off-set (costanti) di correzione (vedi calibrazione sensori di temperatura)
  • calcolo di differenze (come i ΔT acqua)
  • calcolo potenze termiche
  • derivazione di grandezze binarie (esempio Modo Defrost) da grandezze multivalore (Modo corrente)

Direi che zanac ha ancora un sacco di lavoro da fare !

13 risposte a “Hack my Daikin HPSU Compact: terza parte”

  1. Ciao Emiliano, come al solito sei una fonte inesauribile di dati che fanno pensare molto
    Condivido con te che la difficoltà maggiore per utenti non forniti di un sistema di lettura dati come il tuo, di determinare in modo serio le potenze termiche utilizzate nelle varie fasi di funzionamento, riscaldamento, acs e defrost.
    Nel mio specifico caso mi sono sempre limitato a leggere le potenze elettriche assorbite, ma noto con interesse che ora le grandezze per determinare gli effettivi cop della hpsu compact con i tuoi strumenti sono facilmente calcolabili.
    Detto questo, sono rimasto sbalordito dai cop risultati dai defrost precoci, che mi hanno subito portato a cronfontare i dati pubblicati nelle tabelle Daikin.
    Che dire ? Rimasto senza parole.
    Dico solo che mi sorge il dubbio che qualcuno attribuisca l’energia termica per i defrost conteggiandoli separatamente come acs ?
    Seguo l’evolversi degli eventi

  2. Ciao Emiliano,

    ti leggo da poco ma ti faccio davvero i complimenti per tutto il lavoro svolto!

    Ho da poco acquistato un appartamento climatizzato con una HPSU 308 + 3 convettori Rotex.
    Io viaggio molto per cui verificare l’efficienza del sistema è piuttosto improbabile.
    Avrei però forte necessità di comandare da remoto l’impianto nel suo complesso.

    Quindi sia la pdc per poter impostare temperature ed eventuale stato antigelo per i periodi di lunga assenza.
    I convettori per poter riscaldare l’ambiente prima del mio arrivo.

    L’assistenza mi ha proposto per il generatore l’interfaccia Rocon g1.
    Trovo il costo di 500 € inavvicinabile ed ingiustificato e limitato alla pdc.

    Ti volevo chiedere se il tuo sistema di monitoraggio potesse anche impartire comandi alla macchina?

    Per i convettori, secondo Daikin, assolutamente isolati dal resto del mondo, potrei ipotizzare svariate soluzioni più o meno semplici.
    Mi rimane lo scoglio duro del generatore in cui vedo un barlume nel tuo sistema di monitoraggio.
    Grazie per una risposta e ciao

    Luca

    1. Ciao Luca, il RoCon G1 e’ una soluzione valida e pronta per remotizzare il display a bordo macchina.

      Io lo avevo comprato qui’:

      http://www.heizungdirekt24.de/Rotex/Oel-Brennwertkessel/ROTEX-Gateway-RoCon-G1.html

      Il mio sistema sta già comandando la macchina (temperatura di mandata) ma il software e’ in uno stato primordiale per consentire l’uso ad altri.

      Sicuramente nella roadmap di zanac e’ previsto il controllo della macchina.

      Dipende quanto tempo vuoi aspettare. ciao.

      1. Emiliano grazie per la risposta.

        avevo trovato anche io su quel sito l’interfaccia, mi sembra che ci siano altri 80 euro di spedizione.
        Confesso che da una macchina del genere mi sarei aspettato fosse integrata e avrei tanto voluto spendere meno.
        Anche perché dovrei comunque acquistare i ripetitori infrarosso wi-fi ed un termostato wi-fi.
        A me basterebbe poter impostare la temperatura dell’acqua e antigelo nel prossimo inverno.
        Ipotizzo, nel frattempo, una diminuzione di prezzo (italiano) del RoCon G1, che a mio avviso è davvero una esagerazione.
        Comunque grazie, vedrò per una soluzione più artigianale.

  3. Me lo ha proposto l’assistenza Rotex.
    Non so da dove lo prendano loro. Ho immaginato fosse di fornitura ufficiale dato che esiste anche il manuale di installazione in italiano.

  4. No, l’avrebbero montato loro.
    Faticano a proporlo per via del costo davvero alto e funzionalità limitata al generatore.
    Chi è interessato, rimane stupito che non possa comandare tutto l’impianto della stessa marca.
    Sentito il prezzo, ho cercato io alternative per acquistarlo.
    Personalmente, date le funzionalità e per quanto ben fatto, potrei valutare una spesa max di 100€ per quella interfaccia.
    Al giorno d’oggi, dovrebbe essere una funzione standard.

    Io penso di risolvere con un termostato wi-fi che gestisca l’alimentazione generale dell’impianto.
    Per cui da alimentazione a tutto o stacca tutto.
    PDC, elettrovalvole e convettori.

    Perdona le divagazioni ma dall’inizio dell’inverno sto cercando una soluzione che non mi costi come una settimana bianca.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *