Efter ett par dagars experimenterande och lite mailväxlande med Göran Krook på techtrade har jag fått det som jag vill ha det…iaf för tillfället. Eftersom jag är på humör för att skriva nu ska jag berätta hela historien för er. Håll tillgodo.

Första steget var att bestämma vilken form av sensor jag skulle använda, eller rättare sagt vilken kompexitetsgrad den skulle ha; endast en sensor baserad på en fotodiod fungerar i mitt fall. Valet stod mellan en väldigt enkel bestående av tre komponenter och en andra variant med ett tiotal komponenter. Den senare inkluderade kompensation för bakgrundsljus och därmed var betydligt mindre känslig för störningar, men samtidigt betydligt jobbigare att löda ihop. Valet föll på den enklare varianten då jag ju alltid kan bygga den mer avancerade när grundfunktionaliteten är färdig. Sagt och gjort; en foto-diod, transistor och ett motstånd går fort att löda ihop så 15 minuter senare hade jag en sensor klar att koppla in.

Steg två var att ladda hem och installera EMC. Inte mycket att berätta om detta; installationen gick smärtfritt. Det ska bli intressant att se om några av de dll-filer installationsprogrammet uppdaterade på systemet kommer orsaka några kompabilitetsproblem i framtiden (jag är ingen fan av delade dll-filer). Bara att hoppas på det bästa. Lite kuriosa: Installationsprogrammet ger mig intrycket att det är skapat i Visual Studio 6, så gissningsvis är programmet skrivet antingen i VB6 eller Visual C++. Förmodligen det senare.

Steg tre; inkoppling. Tyvärr har jag bara en COM-port på min loggdator så jag var tvungen att koppla ur värmepumpens loggning. Därefter startade jag EMC, och det fungerade perfekt; sensorn registrerar all pulser från elmätaren, inte en enda verka missas. Att konfigurera COM-portens baud rate till en som funkar var busenkelt tack vare EMC’s hjälp (den analyserar pulslängderna och föreslår en baud rate).

Steg fyra; loggning till textfil. Nytt i version 1.3.37 var att den nu kunde kunde logga till en textfil, vilket var precis det jag behövde. Tyvärr hade denna funktion ett mindre bra beteenede; den skrev hela tiden ned det aktuella värdet av kWh och antal uppmätta pulser.

Varför är detta inte bra?

1. Det är nu omöjligt att få en hårddisk att inta viloläge då programmet hela tiden skriver till densamma, oavsett vilket loggningsintervall man angett i inställningarna.
2. Hårddisken får jobba betydligt mer än vad som är nödvändigt vilket förkortar livslängden samt ökar systemets effektförbrukning (om än marginellt)
3. Att köra EMC under XP Embedded från en CompactFlash i t.ex. en AEC-6810 (http://www.lillfab.se/systems/AEC-6810/aec6810.html) är inte längre att tänka på då dessa diskar redan har ett ganska begränsat antal skriv/läs cykler. (Går visserligen att förbättra med hjälp av XPE’s drivrutin för CF, men bara till en viss gräns)
4. Att automatisera bearbetningen av loggfilen försvåras eftersom man måste ignorera den sista raden i filen då denna hela tiden ändras.

Jag skickade dessa punkter, samt följande frågor till Göran Krook på Techtrade:

1) Kan man på något sätt få EMC att visa samma totala kWh-tal som den riktiga elmätaren?
2) Har ni en användarmanual att tillgå? Jag saknar information om bland annat:
- Loggningsformat (ser enkelt ut, men en specifikation vore fint)
- Syftet och formatet av pwrData.emc (man kan ju välja att stänga av den så den bör ju vara av intresse för användaren, eller?)
- Inställningar/Ring bell – vad är den till för?

Svaret kom redan 1½h senare, klocka två på natten! Det löd:

I emcLog.TXT lagras: tid, energi (Wh) och effekt (W).
Varje post är en rad med 39 tecken + CR + LF.
För att filen inte skall bli för stor så kan minsta tid mellan nya rader anges.
Vid nytt dygn blir det alltid en ny rad.
En rad med senaste mätarvärdet skrivs alltid i slutet av filen men skrivs över av nästa om den inte skall
sparas. Loggfilen kan delas och läsas från andra program som också får tömma den.

Det finns tre speciella posttyper:
-1W = manuellt inmatad mätarställning
-2W = programmet gick ON-line (startade)
-4W = programmet gick OFF-line (stoppades)

Med dubbelklick på ‘energy (kWh)’ i huvudfönstret kan man mata in verklig mätarställning som då skrivs till loggfilen.
När programmet startar läses senaste värdet på totalförbrukning in från emcLog.TXT och räkningen fortsätter därifrån.

Svaren på frågorna var som följer:

> 1) Kan man på något sätt få EMC att visa samma totala kWh-tal som den riktiga elmätaren?

* Ja, se ovan (dubbelklick på ‘energy (kWh)’), skrivs till loggfilen som -1W.>

2) Har ni en användarmanual att tillgå? Jag saknar information om bland annat:
* Nej, tyvärr inte, men det kommer nog.

 

> – Loggningsformat (ser enkelt ut, men en specifikation vore fint)
* Se ovan, de enda specialposterna som förekommer i nuvarande version är -1 -2 -4 (i W fältet).

> – Syftet och formatet av pwrData.emc (man kan ju välja att stänga av den så den bör ju vara av intresse för användaren, eller?)
* I denna fil sparas en post normalt för varje puls som kommer in. En post innehåller:
* datorns klocka,
* tidsstämpel med 16us upplösning för senaste pulsen,
* totalt antal pulser,
* och temperatur

* Varje gång programmet går on-line skrivs också en ‘header’ till filen som innehåller mätarkonstant, klockfrekvens mm.
* När man plottar en kurva är det data från pwrData.emc som visas. Denna fil är mycket kompaktare än text-loggfilen.

 

> – Inställningar/Ring bell – vad är den till för?
* Om du har en högtalare till datorn så plingar den för varje puls som kommer in, praktiskt vid montering av detektorn men annars mest irriterande.

Han fortsatte sedan med ytterligare lite användbar information:

Funktionen med loggning till textfil (emcLog.txt) är ny och kan säkert förbättras på olika sätt. Problemet är att hitta en modell som passar alla. EMC-programmet var från början mest avsett att mäta och lagra momentan effekt, inte energi. Flera användare har önskat att få tillgång till data viaen textfil som de kan läsa för att presentera data på annat sätt än med EMC programmets grafik. Problemet är att en del vill kunna läsa data med så kort intervall som möjligt medan andra nöjer sig med ackumulerad energi under ett dygn. Om man lagrar en ny post i textfilen för varje puls blir den snabbt väldigt stor. Sättet att skriva ett nytt aktuellt värde i slutet av filen för varje puls är ett sätt att tillgodose båda önskemålen utan att fylla disken. För att inte tappa bort den verkliga mätarställningen (vid strömavbrott) måste man skriva till disken ofta.

En möjlighet med loggfilen är att först kopiera den till en temporär fil innan bearbetning i ett annat program.

Detta kanske löser ditt problem:

I EMC.INI finns två parametrar som styr uppdateringsinterval;

minUpdateInterval=1
maxUpdateInterval=2

du kan ändra dessa (med en text editor) till:

minUpdateInterval=600
maxUpdateInterval=0

då behandlar programmet bara inkommande pulser var 600:e sekund (10min), och inge diskaccess sker dessemellan. Vi har inte gjort dessa parametrar tillgängliga i setupmenyn för att inte krångla till det mer än nödvändigt för ‘vanliga användare’. Ändringen gör också att inte heller huvudfönstret uppdateras med kortare intervall än 10min.

Tydligen gillade Göran mina kommentarer; han skickade detta mail till mig idag:

Hej igen,

Ny version av EMC-programmet finns nu att hämta på. http://www.techtrade.se/sv/download.asp
Dina synpunkter angående loggning till textfilen var inte helt tokiga, så jag har nu lagt till lite mer möjligheter till styrning av intervall mm.

Den lite väl “smarta” funktionen att alltid skriva senaste värdet till slutet av loggfilen är nu också valbar så att man inte sliter ut flash-disken i onödan – jag tänkte inte på det…
Man kan (som tidigare) välja minsta tid mellan posterna som skrivs till loggfilen, men måste välja om man även vill ha de temporära mellan värdena. Har även lagt till fasta intervall, som innebär att man synkroniserar loggningen till jämna tidsperioder.

mvh,

-gk

Jag har nu provat den nya versionen, 1.3.38, och så vitt jag kan se fungerar den precis som utlovat. Tack för det Göran!

Ytterligare utvärdering återstår, men snart är det dags för steg fem; bearbetning och presentation av informationen. Detta kommer troligen att ske med hjälp av TWatch och FF2DB.

Följande är det det jag minns från då jag undersökte IVT’s kommunikation. Om det stämmer för andra än den pump som jag har vet jag inte.

• Gränssnittet är normal RS232 kommunikation.
• Varje datapaket består av nio byte; stx, cmd, sex data bytes, samt kontrollsumman (XOR av datat)

Jag har inte sparat de anteckningar jag gjorde då jag först undersökte möjligheten att själv kommunicera med pumpen då det för min del inte är värt besväret. Statlink, programmet som Peter Hansson har skrivit kan ju redan kommunicera med de flesta av IVT:s pumpar och programmet kan dessutom exportera all nödvändig data till fil i drift så det känns som att uppfinna hjulet igen. Dessutom säljer han programmet så billigt att det inte är lönt att lägga ned tid på att göra det själv.

Jag lade istället min energi på att skriva ett grafprogram samt ett annat program som läser in det exporterade datat och för över det till en MySQL databas.

Så tyvärr min kära läsare, jag har inte tillgång till IVT:s protokoll.

I’ve completed the FileSystemMonitor replacement class. I’ve intentionally left out the part that would check for newly created files as this is not needed at this stage. The result is that when there is a change of dates, i.e at midnight, the monitor will no longer receive any updates since the values are now written to another file.

As I stated in an earlier post, I had the file monitoring working. Well, so I thought. After installing the computer that will be the one I’ll use to log all the data I discovered something that really ruined my day – networked drives does not support monitoring very well.

I am (read was) using a class named FileSystemMonitor that comes with the .NET platform. This class has the capability to monitor changes in the filesystem. Nothing in all the articles I’ve read about this class have suggested that it won’t work over a network – I’ve actually seen several examples that are supposed to work on a network drive.

After much testing I’ve come to the conclusion that this class won’t do what I need it to do. Sure, it works on the local file system just fine but networked drives is just a big black hole it seems. Very annoying.

So – I’m currently writing my own file monitor with support for networked drives.

Current features are:
- Regular expressions for parsing
- File system notifications for real time monitoring
- OOP, obviously

The piece of hardware I’ve been waiting for arrived today. As can be seen, it’s just a four-wire cable, with some circuitry for galvanic isolation in one end and a D-sub with an USB-plug for power supply.

The image shows how it looked like before I started working on it. Today the curcuit board is mounted inside the heat pump, and the D-sub is located at the computer in the other end of the house, connected with the cable I’ve previously mentioned.

The initial tests looks promising; now I’ve got to set up the logging properly and then write the applicationI’ve been thinking about that will parse the data and present it as diagrams. I know there’s an application that does this already, but I’ve got some additional things I want it to do.

So what’s there to write about such a thing then? Well, it’s not something that interests the general public, but I know that people with a system like, or similar, to this one likes to read about other people’s experiences.

I’m currently waiting on some hardware that will enable me to connect my PC to it and log temperatures and other interesting data over time. The hardware in question is actually just an RS232 cable, but with added galvanic isolation between the PC and the heat pump. I guess I could have built it on my own, but it was cheap enough, and it comes with a nice (at least it looks promising) program to log the data.

I’ve been trying to get hold of a specification of the communication protocol for my heatpump and today IVT, the manufacturer of my heatpump, gave me a call. I’ve not received the protocol yet, but what they did tell me sounds promising.

I’ve had quick a look at the communication protocol and to my suprice, it is a very simple protocol. As far as I can tell, all commands are nine bytes in total; stx, cmd, six bytes of data and the checksum, which is the xor:d value of the data.

It’s hardly worth the trouble to reverse engineer the protocol since there already is a program available to read the data I want, but it is fun none the less

I’m such a tech-freak

I pulled a cable across the entire house today so that I can hook up he PC with the heat pump. Thankfully I could pull the cable through the attic so it is hardly visible

Total length is about 25m so it should work allright