Bergvärmepumpen stannar gång på gång, men startar nästan alltid igen efter en återställning. Larmet pekar på flöde eller temperatur, trots att ingenting egentligen verkar vara trasigt. Pumpen kan gå felfritt i flera dagar, tills samma sak händer igen. I det här inlägget går vi igenom hur ett sådant svårreproducerat fel utreddes genom att kombinera tidsseriedata från en Loopshore-mätare, AI-analys och mänskliga iakttagelser – och varför lösningen hittades först när man tittade på hur pumpen betedde sig över tid i stället för på enskilda larmkoder.
Problemet: larm utan tydlig orsak
Det gällde en äldre bergvärmepump (NIBE Fighter-serien) som gång på gång stannade med larm. Larmet gällde flödet och framledningstemperaturen, men de praktiska iakttagelserna tydde inte på något verkligt flödesproblem:
-
cirkulationspumpen gick
-
flödet hördes i rören
-
pumpen fungerade normalt efter en återställning
Ändå låste sig pumpen i larmläge om och om igen. Situationen är bekant för många: pumpen är inte uppenbart trasig, men inte heller pålitlig – den stängs av och det kommer kallt vatten ur duschen.
Varför tillverkarens egen diagnostik inte räckte
I äldre bergvärmepumpar bygger diagnostiken vanligtvis på:
-
enskilda givare
-
fasta gränsvärden
-
binära larm (ok / inte ok)
Sådan diagnostik visar bara att ett gränsvärde har överskridits – inte hur pumpen har betett sig över tid. Om en enskild givare ger en felaktig signal ser larmet likadant ut som vid ett verkligt fel, och orsaken går inte att utläsa enbart ur larmkoden.
Loopshores mätning: temperaturbeteendet avslöjar mer än larmet
På platsen hade en Loopshore-mätare installerats som kontinuerligt följde temperaturen i varmvattenberedaren. Datan gav en helt ny bild av situationen.
Tidsserien visade ett tydligt och återkommande mönster:
-
beredarens temperatur steg normalt
-
plötsligt kom ett brant temperaturfall
-
temperaturen återhämtade sig inte utan återställning
Det viktiga var det som inte syntes:
-
ingen gradvis avkylning
-
ingen profil som tydde på varmvattenförbrukning
-
inget belastningsberoende
Det handlade inte om brist på värme, utan om ett styrt stopp.
AI:ns roll: avvikande beteende, inte avvikande värde
AI-analysen inriktades just på formen på temperaturbeteendet:
-
förändringshastigheten
-
hur ofta det upprepades
-
den tidsmässiga strukturen
Analysen visade att temperaturrasen var:
-
för snabba för att vara normal avkylning
-
för regelbundna för att vara slumpmässiga
-
kopplade till att pumpen stannade, inte till förbrukningen
Det ringade in felets karaktär: det var inte ett problem med värmeproduktionen, utan en skyddsfunktion som löste ut på grund av en felaktig tolkning.
Mänskliga iakttagelser fullbordade diagnosen
Även om datan och analysen tog oss långt var det avgörande att också väga in iakttagelser gjorda av människor:
-
den första återställningen fick nästan alltid igång driften igen
-
flödet fanns i verkligheten
-
felet uppträdde slumpmässigt, ofta när temperaturen steg
När detta kombinerades med Loopshores data och AI:ns iakttagelser framträdde den mest sannolika orsaken tydligt: en felaktig signal från en åldrande flödesvakt (flödesgivare).
Det rörde sig inte om något verkligt flödesproblem – styrningen trodde bara att det fanns ett.
Vad lärde vi oss?
Fallet visar tre centrala saker:
-
Ett enskilt larm berättar inte hela sanningen
-
Data över tid avslöjar beteendemönster som styrningen inte ser
-
Bäst resultat får man när data, AI och människa samarbetar
Varken Loopshore eller AI ersätter service eller människan i beslutsfattandet – men de gör felsökningen mer exakt, snabbare och mer tillförlitlig.
Sammanfattning
När en bergvärmepump stannar gång på gång utan uppenbar orsak finns lösningen sällan i en enda larmkod. I det här fallet var det först extern mätning, AI-analys och praktiska iakttagelser tillsammans som avslöjade den verkliga orsaken.
Felet var inte komplicerat – problemet hade bara betraktats ur ett alltför snävt perspektiv.
Länk till felsökningssamtalet med ChatGPT: https://chatgpt.com/share/69563818-1dac-800d-b4b1-25fb0119786c