Integrarea unei pompe de căldură cu KNX și Modbus: ce poți monitoriza și ce merită controlat

Integrarea unei pompe de căldură cu KNX poate transforma informațiile tehnice ale instalației în date utile pentru administrare, confort și mentenanță. Poți vedea temperaturi, stări, alarme, moduri de funcționare și, atunci când producătorul permite, poți transmite comenzi externe controlate.

O integrare corectă nu înseamnă să înlocuiești regulatorul intern al pompei. Controlerul producătorului trebuie să păstreze funcțiile frigorifice și de siguranță: protecție anti-îngheț, degivrare, limite de temperatură, protecție compresor, post-circulare și logici specifice echipamentului.

1. De ce integrezi pompa de căldură în KNX

Integrarea este utilă atunci când ai mai multe zone de încălzire sau răcire, când vrei o vizualizare centrală, când administrezi o pensiune ori când instalația are nevoie de alarme și istoric de funcționare.

În KNX poți centraliza, de exemplu:

• Temperatura exterioară și temperaturile de tur/retur
• Temperatura boilerului de apă caldă
• Modul de funcționare: încălzire, răcire, ACM, standby sau alarmă
• Starea compresorului și a pompelor de circulație
• Alarme și coduri de eroare, dacă interfața le publică
• Consumuri electrice și contoare de energie
• Cererea globală rezultată din termostatele de cameră
• Poziții de vane, stări de actuatoare și temperaturi pe zone

2. Ce este Modbus în acest context

Modbus este un protocol folosit frecvent pentru schimb de date între echipamente tehnice. Pompa de căldură poate avea Modbus RTU pe RS-485 sau Modbus TCP prin rețea IP. KNX nu vorbește nativ Modbus, de aceea ai nevoie de un gateway sau de un controller care face conversia între obiecte KNX și registre sau coil-uri Modbus.

Gateway-ul nu inventează funcții pentru pompă. El expune în KNX doar ceea ce interfața și harta de registre a producătorului permit: valori citibile, comenzi scriibile și formate de date specifice.

3. Ce merită citit din pompă

Înainte de orice comandă, începe cu monitorizarea. Citește și afișează datele care te ajută să înțelegi funcționarea:

• Temperatură exterioară
• Tur și retur încălzire
• Temperatură ACM
• Setpoint tur sau curbă climatică, când este disponibilă
• Stare compresor
• Mod activ: încălzire, răcire, ACM sau degivrare
• Stări pompe, vane și rezistențe auxiliare
• Presiuni sau debite, numai dacă producătorul le expune
• Alarme și coduri de eroare
• Energie electrică și energie termică, când există contoare sau valori disponibile

4. Cererea globală de încălzire din zonele KNX

Într-o instalație pe zone, fiecare termostat poate genera o cerere locală de încălzire. Pentru pompă este util să existe o singură cerere globală:

Această cerere se obține cu o logică OR. Fiecare zonă sau fiecare modul de actuatoare trebuie să intre pe o intrare separată a logicii. Nu lega toate cererile direct pe aceeași adresă de grup și nu presupune că bus-ul KNX va face OR automat.

Dacă mai multe surse scriu direct pe aceeași GA, ultima telegramă poate deveni starea văzută de gateway. O zonă care transmite 0 poate opri cererea, chiar dacă alta este încă 1. Poarta OR păstrează starea fiecărei intrări și trimite 0 numai după ce toate intrările sunt 0.

5. Heating enable, external demand și setpoint

În harta Modbus a pompei caută numai obiecte oficiale, documentate ca scriibile (R/W):

• Heating enable sau CH enable
• External heating enable
• External demand sau Thermostat request
• Remote enable
• External setpoint
• Heating curve offset

Semnificația valorilor este stabilită de producător. Un obiect poate fi binar (0 = disable, 1 = enable), iar altul poate avea valori enumerate (0 = no demand, 1 = heating, 2 = cooling).

Nu scrie în registre marcate doar R, Read only, Input Register sau în valori de stare precum Compressor status, Heat demand actual ori Heating mode actual. Acestea sunt feedback-uri.

6. Ce nu trebuie comandat direct

Nu comanda direct compresorul printr-o logică KNX simplă, nu anula degivrarea și nu forța rezistențele electrice fără funcția oficială permisă de producător.

KNX poate transmite o cerere sau o permisiune, dar pompa trebuie să decidă compresorul, turația, degivrarea, post-circularea și protecțiile. Această separare reduce riscul de alarme, cicluri dese și funcționare incorectă.

7. Control zonal și debit minim

Controlul zonal aduce confort, dar poate crea o problemă hidraulică dacă multe actuatoare se închid simultan. Pompa de căldură are nevoie de debit minim și de volum de apă potrivit pentru funcționare stabilă și pentru anumite regimuri, inclusiv degivrare la echipamente aer-apă.

În funcție de proiect, soluția poate include:

• Circuit permanent deschis
• Buffer sau separator hidraulic
• Bypass proiectat și reglat corect
• Distribuitoare echilibrate
• Limitarea închiderii simultane a zonelor
• Temporizări anti-ciclare
• Cerere globală transmisă numai prin funcția permisă de producător

8. Cum arată o arhitectură simplă

Termostate KNX pe zone
        ↓
Actuatoare pentru distribuitoare / ventiloconvectoare
        ↓
Cereri locale de încălzire
        ↓
Logică OR pentru cerere globală
        ↓
Gateway KNX–Modbus
        ↓
Obiect oficial al pompei: Heating Enable sau External Demand
        ↓
Controlerul intern al pompei de căldură

În paralel, gateway-ul citește temperaturi, stări și alarme din pompă și le transmite către vizualizare, BMS sau sistemul de monitorizare.

9. Alarme, istorice și monitorizare

Pentru exploatare, mai utile decât o simplă comandă ON/OFF pot fi alarmele și istoricele. Configurează praguri relevante și alerte care pot fi interpretate:

• Alarmă generală a pompei
• Temperatură anormală tur/retur
• Lipsă comunicare Modbus
• Temperatură ACM sub nivelul necesar
• Funcționare neobișnuit de lungă
• Contor de energie sau consum peste un prag
• Pierdere de debit, dacă există semnal disponibil
• Pană de tensiune sau revenire după reset

O alarmă trebuie să aibă un destinatar și o procedură: cine primește notificarea, ce verifică de la distanță și când este necesară intervenția în teren.

10. Checklist înainte de punerea în funcțiune

• Confirmă modelul exact al pompei, controllerul și interfața de comunicație.
• Folosește harta oficială de registre a producătorului.
• Verifică dacă obiectul este R/W și dacă necesită activare din meniul de service.
• Confirmă adresa Modbus, unit ID, baud rate/paritate sau IP/port.
• Verifică offsetul de adresare: 0-based, 1-based sau notația 4xxxx.
• Confirmă tipul de date, semnul, numărul de registre și factorul de scalare.
• Mapează separat în ETS comenzile și feedback-urile.
• Testează cu ETS Group Monitor înainte de activarea logicii automate.
• Verifică debitul minim și schema hidraulică.
• Aplică temporizări pentru cererea globală numai după teste funcționale.
• Testează comportamentul după revenirea alimentării și a bus-ului KNX.

Concluzie

Integrarea KNX–Modbus poate face instalația mai ușor de administrat și mai ușor de diagnosticat, însă trebuie să păstreze rolurile corecte: KNX generează cereri, vizualizează stări și coordonează zonele; controlerul pompei păstrează funcțiile frigorifice și de protecție.

O integrare bună începe cu monitorizarea, apoi adaugă numai comenzile oficiale necesare pentru proiect.