I första versionen kommer det att finnas stöd för databaser, bevakning av andra programs loggfiler samt 1-Wire. Därefter kommer stöd för Telldus’ Tellstick för styrning av lampor osv. Det finns också planer på ett klientprogram för visualisering av det data som passerar genom systemet; så som temperaturer, status på brytare mm.

En del av er känner kanske igen namnet; ni minns inte fel! Jag arbetade med detta projekt redan i höstas, men pga diverse orsaker blev det lagt på is. Nu är det hursomhelst igång igen och snart dags för en första beta.

Projektets sida finner du här.

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.

Även TWatch bör fungera med Statlink’s nya format.

Mera ketchup effekt:
Jag har fått förfrågningar om både TWatch och FF2DB inom loppet av några dagar. Intresset för dessa program har ju varit svalt, men nu verkar det alltså som om det ökar. Det ska bli kul att se var det tar vägen….får peka på donationsknappen

Funderar på att skaffa ett konto hos site5.com igen. Var mycket nöjd med dem då jag sysslade med Dragonfly CMS. Måste ju ha någonstans att distribuera TWatch och FF2DB ifrån.

To run it you’ll need to extract the files to a folder of your choice an then edit the settings. The “settings.xml” that comes with the archive is setup to work with the files produced by Husdata.se’s Statlink software, as well as Lämpömittari (although I have yet to verify this).

The configuration should be pretty self explanatory. There are really only a few settings you’ll need to change; the FlatFileToDb/DatabaseConnection/* and the FlatFileToDb/DateSortedFiles/RootPath settings.

If you’re going to use this software with Statlink, you’re now all set. Users trying to get it to work with Lämpömittari need to edit the FlatFileToDb/DateSortedFiles/* settings as the filenames are likely not the same as Lämpömittari produces.

I don’t recommend changing the <../File/RegExp>-tags unless you really know how regular expressions works.

Once you have the settings sorted, you can now use the SQL script file that comes with the archive to create the required database on your MySQL server. If you’re not using the default configuration in the FlatFileToDb/DateSortedFiles/ section you’ll have to create your own database with associated tables.

There are two modes the application can run in; Auto parsing and manual. To enable the auto parsing mode you’ll have to start the application using the command switch “/auto”, ie. “c:\path\FlatFileToDatabase.exe /auto”. When in auto mode, most of the user interface is disabled.

Exiting the application can only be done using the exit-button, other ways (ALT-F4 etc.) will only hide the application window; it will then only be available through a double-click on the applications icon the notification area (or Systray, depending on who you ask) on your Start-bar.

Even though I doubt that by using this application you put you and yours in danger (or your files for that matter), you use this software at your own risk.

The main purpose of this application is to read the flat file database produced by Statlink, but it will also have a limited support for other flat files; as long as the values are in the form date-value, and one item per line, the application will be able to read it (with the appropiate configuration, of course).

I’ve decided to make this applications work in two modes:

1. First Use Conversion
2. Monitoring

The First Use Conversion mode will have a simple user interface allowing the user to make some choices before the flat-file-to-database conversion starts.

The Monitoring mode will work in the background, parsing the flat files in real-time. Naturally, this is the mode the application will run in once the initial data conversion is complete.

The application is configured using a XML file. Seeing as the configuration is very simple I’ve opted not to make a configuration dialog; this might be added at a later time if enough requests are voiced.

I’ve opted for a MySQL database since it is very easy to install and configure, and it also runs good on older computers with good performance. The fact that it also has very good support for .Net didn’t make the choice any harder

1. The development of the current TWatch will cease.
2. A new, multi part application will be created.
   It will include:
   1. A database to hold the data.
   2. A flat-file-to-db converter/monitor.
   3. A client to view and process the data.

I feel that continuing working from the flat files delivered by Statlink, puts quite a lot restrictions on what I can do without writing a database-like layer around the files. The current TWatch does its job nicely, but adding more features requires more work than it should due to the lack of a real, searchable database.

I’ve opted to use MySQL as the database since it is freely available and very easy to install, even for someone who’s never done it before.

That’s all for today, now it is time to do some sketching on the design. Cheers!

Another new feature that has been added are graphs for the temperature readings, also a nice thing to have. Depending on which features Peter intends to implement TWatch might become obsolete… I’ve had some thoughts to move from todays flat-file database to a SQL database to both increse the parsing speed and to ease the addition of new featers to TWatch.

Lastly, I’ve ordered a few samples of the 1-Wire temperature sensors from Maxim and I’m going to try their .NET API, should be an interesting experiment.

Update: Someone else also liked the 3D model I made: Click me