Jo det blir lite tokigt ibland, det finns i fellistan men har inte högsta prio. (Sammanfogade din tråd med besläktad.)

24 timmar bakåt från vad klockan är nu? Blir inte det väldigt skrymmande? Var tänkte du att den skulle visas?

(Flyttade ditt inlägg från tråden "Rapport för Årsförbrukning / Månadsförbrukning" eftersom det inte stämde med rubriken.)

Det skulle kunna ordnas. Men jag antar att du menar kompressor skiljt från elpatron?

I så fall behöver vi kunna skilja på när kompressor respektive när elpatron går, detta diskuteras i ämnet Logga driftstid på värmepumpen. Och då skulle jag behöva hjälp med svar på frågorna jag ställer i inlägg #14 i den tråden för att komma vidare.

Jag har faktiskt börjat titta lite mer i detalj på hur "förbrukningsisopletter" kan läggas in i webbtjänsten och det är nog inte så hemskt många veckor bort. Tanken är att det skall hamna i det vanliga grafgränssnittet med fält för kanal för x respektive y, tidsperiod och varje punkts tidsomfång.

(Kallas detta verkligen isopletter? Är det inte snarare ett sambandsdiagram?)

Vad gäller mögelrisk får ni gärna utveckla mer i detalj hur ni önskar att en sån funktion skulle fungera. Gärna med skiss på hur det skulle se ut. Sannolikheten för att det skall bli av är mycket högre om ni hjälper till.

Tack för många bra synpunkter!

En produkt som inte har en lokal mjukvara är helt ointressant för mig

Frågan är om inte det börjar bli en gammaldags uppfattning i en värld som håller på att bli alltmer uppkopplad?

nu springer onekligen e-logger ifrån den lokala mjukvaran och produkten tappar ur min synvinkel sin styrka.

Fast somligt passar bättre att göra i en webbtjänst och somligt bättre i ett pc-program. Och som jag skrev i en annan tråd, LoggerSoft-användare är inte speciellt aktiva här i forumet. Hur mycket resurser ska vi då lägga på LoggerSoft? Något som diskuterats är att ta fram en mer utvecklad variant och då ta betalt för programmet, hade du varit intresserad att betala säg en femhundralapp för ett "LoggerSoft Plus"?

Ett alternativ skulle kunna vara en snyggt förpackad lösning med alla nödvändiga komponenter för köra webbtjänsterna på en egen server. Men det genererar ju oerhört mycket arbete och fler problem.

Exakt.

Varför utvecklingskostnaden skulle öka med lokal mjukvara förstår jag inte. Det är väl knappast varken dyrare eller mer tidskrävande att skriva ett exekverbart program, än att skapa ett webbgränssnitt

Som jag skrev, de flesta vill ha åtkomst via nätet, alltså måste ett webbgränssnitt alltid tas fram.

Att sen lägga exakt in samma funktonalitet i ett pc-program innebär dubblerad arbetstid. Och vilka fördelar får användaren rent användarmässigt i jämförelse med webbgränssnittet?

som måste skrivas om varje gång det släpps en ny webbläsare?

Det är sällan ändrigar behövs när det kommer en ny webbläsare. Skulle det vara något räcker det oftast med ändring på ett enda ställe om man sett till att jobba modulärt.

Är det trådlösa sändare direkt på kortet? Vad har de för räckvidd?

Sändare/mottagare direkt på kortet ja. 50 meter fri sikt, fungerar bra i ett trevåningshus med källare och en bit utanför om man monterar centralt.

Utgångar är trådlösa brytare av olika fabrikat, upp till 16A. För att styra trådbundet behövs en IO-modul ansluten till loggern.

Alla insignaler tas via loggern. För att få in digitala eller analoga signaler från larm, ljussensorer, tryckgivare osv. behövs en IO-modul. Det går även styra efter och logga signaler från trådlösa brytare, termometrar och väderstationer.

Styrfunktionen är bara utvecklad för webbtjänsten. Eftersom de flesta vill kunna styra via nätet varhelst man befinier sig är det naturligt. Visst skulle det gå att lägga till stöd för styrning i LoggerSoft/nytt pc-program också, men då stiger utvecklingskostnaden och du blir beroende av tillgång till pc. Hur ofta är det mer praktiskt att kunna göra inställningar i ett pc-program istället för i en webbläsare, och hur många hundra extra är folk beredda att betala för pc-stödet? Ytterligare en tänkbar variant hade varit att bygga in webbgränssnittet för styrning i Logger 2020 (dvs. man skriver in loggerns ip-adress i webbläsaren), men det faller då loggern inte klarar av att husera ett tillräckligt bra webbgränssnitt. Dessutom vore ett gränssnitt i loggern än mer arbetskrävande och kostsamt att lägga in än ett i ett pc-program.

Du har helt rätt i att det kan kännas osäkert att ha en styrfunktion som är beroende av gränssnitt i en nättjänst. Även fast den grundläggande styrningen är helt självgående i Logger 2020, och även om vi skulle garantera drift av nättjänsten 20 år framåt med gratis inloggning för styrning, går det inte att komma ifrån att det blir driftavbrott både på internet och på servrar. Detta är, näst efter ekonomin, det starkare skälet att tveka med att lansera detta.

Ja det finns en hel som skulle kunna förbättras i LoggerSoft...

Men jag är osäker på hur stor efterfrågan egentligen är, LoggerSoftanvändare är inte speciell aktiva här i forumet.

Nej det är inte alls otänkbart men det är svårt att få täckning för utvecklingskostnaderna för en styrfunktion bara för dem.

Med fler utgångar skulle man förutom att styra motorvärmare även kunna styre ytterbelysning med astronomiskt tidur/nattdämpning, slå av och på bastun, starta kaffebryggare, höja och sänka värmen i huset osv...

Ja precis det kan man göra med denna produkt. 10 utgångar. Styrs via timer och/eller utifrån loggerns givarvärden. Inställningar via E-logger.

Vad händer om jag kopplar in dom sensorerna som jag har raderat i Givarelistan?

Dom kommer tillbaka när du startar om loggern. Tar du bort dem igen kommer loggern att larma för att de saknas tills du raderat minnet. Larmet finns dokumenterat under rubriken "Givar- och modulfelslarm vid start" i manualen. http://www.e-logger.se/wiki/index.php/Manual_Logger_2020

Jag lyckas inte få fram något fel med decimals för elkanaler utskrivna med %s. Det finns heller ingen logik i att det skulle vara fel på bara el och inte till exempel temperatur via %s eftersom allt som skrivs ut med %s skrivs ut med precis samma kod.

Däremot påverkar inte decimals räknarna för dag/vecka.

För att förhoppningsvis förtydliga ytterligare:

Vad det gäller är alltså siffran i fältet "Hysteres" under inställningar/generellla inställningar/larminställningar. (Popuptexten "Grader i normalzonen innan larmkriterier rensas" är tokig, ska åtgärda.)

Vid nedre larm måste mätvärde gå upp över nedre larmgräns + hysteres för att larmet skall nollställas.

Vid övre larm måste mätvärde gå ner under övre larmgräns - hysteres för att larmet skall nollställas.

Exempel: Om övre larmgräns är 4 och hysteres är 1 måste mätvärdet ner till 4-1 dvs. 3 för att larmet skall nollställas.

Ajdå där hittade du något. Har tittat på detta, när jag provar spelar det ingen roll om ID är fel, men jag kan bekräfta att LoggerSoft inte startar om där ligger ett felaktigt IP. Det måste åtgärdas innan 1.0.0.8 görs mer allmänt tillgängligt. Tack!

Om pulsantal är rätt inställt och loggern ändå visar för mycket låter det som någon form av störning som orsakar skräppulser. Hur långa är kablarna mellan logger och elmätare? Vad för slags kabel använder du? Går mer än bara en elmätare genom samma kabel? Går kablarna möjligtvis i närheten av någon kabel eller elektrisk utrustning som kan tänkas störa?

Tack för det!

Error 84 betyder att nån inställning inte är korrekt, borde inte dyka upp om du nyss raderat minnet, men det kan förstås vara nåt som skriver fel.

Error 55 betyder att det kommit något otillåtet via nätverket.

När Logger 2020 är uppkopplad mot E-logger och LoggerSoft samtidigt kan pulsinställningar, offsetjustering samt inställning av vilket givarnamn som visas på loggerdisplayen bara göras via E-logger, det blir annars lätt snurrigt om saker kan ändras på flera ställen. (Det här kommer förstås att stå i manualen när den är klar.)

Kan du utveckla "tänka strömlöst" lite mer? Förstår inte riktigt hur du menar.