Hej!

Efter ett (eller flera) strömavbrott fick jag två larm från E-logger på givare där jag ställt larm om temperaturen är under 5 grader i 30 minuter. Det udda är att larmloggen visar att den larmar för att 655.3<5 !!

Handlar det om något slags spökvärde iochmed strömavbrottet som orsakar att någon datatyp slår runt, eller är det bara knas?

Det känns som två fel: Både att det mystiska värdet 655.3 dyker upp på två olika givare, samt att E-logger kommer med nya matematiska rön och hävdar att 655.3 är mindre än 5 ;-)

Några framsteg med att åtminstone kunna visa värden från flera loggrar i systembilden?

En variant skulle ju kunna vara att kludge:a lite så att man för det man vill visa i systembilden från en annan logger skapar en kanalgrupp för flera loggrar med bara en kanal i och sedan använder man den i systembildsdefinitionen.

Idealt skulle jag ju vilja ha något som vi diskuterat tidigare i tråden, men för att få iallafall något på en samlad systembild skulle ovanstående funka om det innebär mindre arbete för er att implementera.

Tack för synpunkterna, sammanfogat de bägge trådarna nu!

Ja valbart mellan sammankopplade/icke sammankopplade är en variant. Det bästa vore om man på något sätt helt fritt kunde välja vilka vilka som ska kopplas och inte. Kom gärna med förslag på hur det i så fall skulle kunna ske i praktiken.

Öhm, det beror ju lite på vad du menar med frågan :-)

Svaret kan ju vara allt ifrån bocka för kryssrutan för hantera-flera-loggers-som-ett-system till mer detaljerat hur man ska implementera det...

Rent spontant så känns det inte som att det är så mycket man behöver för att en sammankopplad variant ska funka med nuvarande elogger-webgränssnitt. En till kolumn där man definerar givare som visar vilken logger givaren finns på, och sen om det blir nått special med larmen (de ligger väl i loggern och triggas därifrån?). Resten borde bara fungera om det ligger i samma hink så att säga.

Ska man fixa nått så att loggrarna är hopkopplade lokalt så att bara en rapporterar tlll elogger måste man fixa den konfigurationen på något sätt, inte helt trivialt att få det enkelt för den som inte har pejl på nätverk/IP. Givet DHCP och att loggrarna får olika IP:s hela tiden måste man nog ha nån slags hitta-min-kompis-funktion.

Vilket som skulle ju lösa problemet för oss, så välj den variant som är enklast att implementera.

Rent spontant så tror jag dock att följande variant borde kunna vara hyffsat rättfram:
- Plocka bort den hårda kopplingen till logger, låt istället givare/kanaler vara kopplade till kontot. Det krävs lite tabellroddande och att alla givare har loggerid:t med men borde vara hyffsat enkelt att automatkonvertera med lite scriptande sen man väl har designen klar för sig.
- Låt varje logger berättiga skapandet av en systembild, dvs. om du har 2 loggrar får du skapa upp till 2 systembilder.

Ett problem här är iofs att kanaler måste ha unika namn inom kontot, vet inte hur stort det problemet är.

Att länka loggrar "lokalt" så att bara en rapporterar flyttar väl mest bara utvecklingsbehovet. Det känns som att det är enklare att rodda runt och utveckla på serversidan än att rodda i mjukvaran i loggern, men det vet ni ju mycket bättre än mig hur ni implementerat det.

Hej!

Vi har nyligen shoppat en till logger för att hantera antalet kanaler och elmätare vi har på vårt lantställe.

Dock så verkar jag ha läst på lite dåligt, för det verkar inte som om det går att använda mätvärden från flera loggrar i samma systembild/grafer etc? Det enda jag hittar är Kanalgrupper flera loggrar, men det är ju bara en bråkdel av funktionaliteten... Eller är jag bara dålig på att lista ut hur man ska göra?

Rent spontant så hade jag förväntat mig att flera loggrar på samma konto skulle vara lite mer integrerat, att sedan man definerat upp givare skulle man kunna skapa kanaler utan att bry sig om den fysiska layouten med loggers och hur saker var kopplade.

Rent specifikt så skulle vi vilja:
- Visa mätvärden från båda loggrarna i samma systembild.
- Visa beräknad kanal med elmätare från två loggrar (Total-hus2-hus3 == hus1)

Är detta möjligt? Kommer det att bli möjligt? Det _borde_ inte vara så mycket jobb för att kunna visa i systembilden iallafall...

Definitionen är ju idag (enligt manualen):

gl=kanalnamn; x; y; diagrambredd; diagramhöjd [;minområde]

Skulle ju funka att bara haka på en
;tidsintervall (minuter)
där, förvisso måste man ju då ange minområde men det känns inte som något större problem?

Eller så är man lite mer strikt och kräver att man alltid måste ange minområde och tidsintervall, så är det ingen tvekan om vad som gäller.

Kan man ange 0 som både minområde och tidsintervall för att avse defaultvärde (dvs. som idag) så blir det inte såå jobbigt att uppdatera från nuvarande syntax.

Skulle ju vara snyggt att kunna ange 12h för 12 timmar, men det är inte så hightech att räkna ut 12*60=720 minuter och mata in 720 som tidsintervall...

Det är väl en smaksak hur man vill ha det, jag blir glad bara man kan ange det tidsintervall/tidsområde som grafen ska visa!

Bra fråga. Men en kludge kan ju vara att om den går kortare än fördröjningen innan första avläsning så läser man bara av värdet när den slår av och är nöjd med det? Det blir ju inte perfekt, men har man så kort körtid så är det nog det bästa man kan göra...

Många kompressorer går iofs inte på fast effekt utan jobbar inom ett effektområde.

Mjo, även de med bara på/av drar ju olika mycket effekt beroende på temperaturer.

Men en av poängerna med att bara titta på effektsteg är att inte behöver bry sig så mycket om de bitarna. Ponera t.ex. en kompressor som drar 1.7kW vid tillslag och sen smyger uppåt när temperaturen ökar och drar 2.2kW vid frånslag. Om man bara tittar på de stora effektkliven kan man ignorera att effekten varierar lite under driftsperioden, oavsett om det är kompressor eller cirkpumpar som varierar. Visst, det blir lite meck med att få ihop det hela vid frånslagen, speciellt om den slår ifrån alla effektsteg samtidigt, men det borde gå att få det hyffsat robust.

I teorin borde det även gå att klara av en inverterpump, men det är nog inte målsättningen man ska börja med

Angående pseudokod så beror det lite på vad för rådata som finns att utgå ifrån. En variant är ju t.ex. att jämföra nuvarande effekt med den för 30 sekunder sedan och titta på om det effektklivet är signifikant, etc.

Om det gick lösa så att den loggar från 5 minuter efter start fram till att kompressorn stoppar och sedan sparar ett medelvärde för den perioden, det tror jag skulle ge rätt värde.
Huruvida man vill spara dessa värden till ett dygnsmedelvärde eller ej är upp till Andreas, temperaturen lär inte ändra särskilt mycket över ett dygn i alla fall.

Instämmer.

Denna temp är ju mest relevant att studera över längre tider, att se förändringar under kortare perioder som timvis tycker jag inte är relevant. Därför borde det räcka med att ta det lägst uppmätta värdet varje dygn att presentera.

Då spelar det ingen roll om det är mitt i vintern där pumpen går näst intill för jämnan, eller om det är endast VV-körningar mitt i sommaren. En graf med var dygns bottentemp blir på så sätt signifikativ för köldbärarens förändring över tid.

Hmm. Att bara ta det lägst uppmätta värdet kan kanske ge problem i följande situationer, lite beroende på hur man vill att det ska fungera:

- Felavläsningar/störningar av olika orsaker. En viss medelvärdesbildning brukar vara att föredra om man ska representera en längre tidsperiod.

- Om du har borrhål/markslinga som är något underdimensionerad för värmepumpens effekt så kommer du att få lägre mintemperatur ju längre gångtid du har. Mintemperaturen är av intresse för att upptäcka detta, men för en uppskattning på köldbärarens "energinivå" är nog medeltemperaturen mer intressant.

Och det går tyvärr inte att göra annorlunda. Om patronerna överlappar med kompressorns effektområde är det omöjligt särskilja dem med en elmätare som mäter effekt för hela värmepumpen. Det går alltså inte att göra en sådan här funktion där det minsta elsteget är mindre än kompressorns tillslagseffekt.

Kom att tänka på att det faktiskt går alldeles utmärkt, men man får tänka lite annorlunda...

Grejen är att istället för att bara titta på totaleffekten och dra slutsatser av den så måste man bygga en liten tillståndsmaskin som tittar på effektstegen och drar slutsatser av dem istället.

T.ex, ser man ett effektsteg på över 1.5kW räknar man upp kompressor, ser man ett effektsteg på 900-1500W räknar man upp tillsatssteg, etc. Det kan bli lite bökigt beroende på vad man har för slags data att arbeta med, och man måste hantera fallen att man kan råka räkna fel när effekten sjunker etc, men det går om man verkligen vill...

Dvs. lite samma tänk som gör att man kan lista ut vad som händer om man tittar på effektgrafen för värmepumpen...

Hej!

Jag tycker att 10 minuter som maxperiod för minilinjediagram i systembild v2 är alldeles för kort tid.

Skulle helst se att man kunde visa upp till 12-24 timmar bakåt i ett linjediagram, det blir ju ingen större precision men då skulle jag på systembilden direkt kunna se t.ex. trend för utetemperatur, värmesystemstemperatur etc.

Som det är nu med 10 minuter som maxperiod så blir linjediagrammen nästan alltid ett rakt streck, inte så spännande ;-)

Antar att man i så fall bör vänta ett tag efter pumptillslag innan man mäter, hur länge?

Snabb koll nu när jag fått dit givare på köldbärarslingan (monterade med värmepasta+folietejp mot kopparrör) ger att efter 3-4 minuter så verkar det vara hyffsat korrekta temperaturer för vår anläggning. Det lär ju variera, så säg 5 minuter efter tillslag som startpunkt?

Ah, borde vara fungerande workaround. Får testa lite...

Hej!

Vi har en Nibe F1145-10, inkopplad via en egen elmätare ansluten till loggern.

När värmepumpen bara arbetar på kompressor så verkar specialräknaren fungera perfekt.

Dock, när tillsatsen slår till så verkar specialräknaren ibland få fnatt och tro att kompressorn inte arbetar, och att värmepumpen arbetar med endast eltillsats. Så är inte fallet.

Den här värmepumpen stegar eltillsatsen i små steg (1kW verkar det som), och inte i större 3kW-steg som specialräknaren förväntar sig om jag förstått manualen rätt.

Efter att ha tvärsurfat runt lite och kollat så verkar det som att de flesta moderna pumpar har små effektsteg för tillsatsen, så jag skulle därför vilja föreslå att specialräknaren anpassas för detta (eller att det går att konfigurera).

Mitt förslag är att göra antagandet att kompressorn alltid arbetar, det borde bli mer rätt i de vanligaste fallen. Man tappar möjligheten att kunna se när VP:n arbetar med endast eltillsats, men den detektionslogiken lär inte fungera på någon modern värmepump.

Det bästa vore dock om man kunde konfigurera specialräknaren (eller ha olika specialräknare) för om man har värmepump med små eller stora steg i eltillsatsen, då skulle saker fortsätta fungera för de vars VP:s stämmer med nuvarande beteende och vi med nya VP:s skulle också bli glada.

Det skulle nog kunna gå att bygga detektionslogiken för att fungera med alla olika driftsfall genom att titta/detektera effektstegen i sig och inte titta på gränsvärden i totaleffekten, men jag gissar att det är mer arbete än vad det är värt.