Kamstrup Meter Protocol

Da vi sidst forlod emnet, havde jeg fået en Kamstrup 382J elmåler, men manglede protokollen for at kunne få andet en IEC1107 informationerne ud af den.

Det problem er løst nu: PyKamstrup er et lille python program der via en seriel-port og et optisk hovede (se tidligere blogindlæg for diagram) kan hente brugbare data ud af ihvertfald min elmåler.

Jeg har prøvet at spørge Kamstrup efter protokol dokumentationen et par gange, men det kommer der ikke noget ud af, selv ikke når man henviser til at Kamstrup selv i deres produktblade beskriver "KMP" protokollen som "the KMP (Kamstrup Meter. Protocol), which is [also] an open protocol."

Vink med Vognstang til Kamstrup:

Det er ikke en "åben protokol" når I ikke vil slippe dokumentationen.

Af hjemmestrikkede protokoller at være er det ikke den værste jeg har set, anvendelsen af CRC16 som checksum trækker opad, den klodsede frame- og escape-mekanisme tæller nedaf.

Jeg har ikke helt styr på hvordan/hvor godt Python virker under Windows, men i hvertfald alle nutidige UNIX dialekter burde kunne bruge ovenstående program.

At implementere protokollen på f.eks Arduino ligger lige til højrebenet.

Samme protokol anvendes tilsyneladende også af mange af Kamstrups andre måleindretninger, men der har man formodentlig andre variabel-numre med andre betydninger.

God Fornøjelse,

phk

PS: Output fra min elmåler:

Energy in (kWh) 6745 Energy out (kWh) 0 Energy in hi-res (kWh) 6745.4191 Energy out hi-res (kWh) 0.0 Voltage p1 (V) 229 Voltage p2 (V) 226 Voltage p3 (V) 232 Current p1 (A) 5.58 Current p2 (A) 1.69 Current p3 (A) 2.36 Power p1 (kW) 1.029 Power p2 (kW) 0.322 Power p3 (kW) 0.438

Poul-Henning Kamps billede
Poul-Henning Kamp
er selvstændig open source-softwareudvikler. Han skriver blandt andet om politik, hysteri, spin, monopoler, frihedskampe gør-det-selv-teknologi og humor.

Kommentarer (94)

Jeg har været igennem det samme for at kunne aflæse mine vand- og varmemålere fra Kamstrup. Har også forsøgt at få protokollen udleveret af Kamstrup, og fik at vide, at det kunne jeg måske godt, hvis mit forsyningsselskab ville tillade det. De svarede forsyningsselskabet aldrig på, så jeg begyndte at lave reverse engineering for at forstå protokollen.

Det letteste er register id'erne. De står i Kamstrup datablade for målerne - så intet problem dér.

Jeg har fundet et par ekstra detaljer, som du ikke har med i din implementation:

Byte 5 fra måleren er enhed jf. følgende:
units = {0: '', 1: 'Wh', 2: 'kWh', 3: 'MWh', 4: 'GWh', 5: 'j', 6: 'kj', 7: 'Mj', 8: 'Gj', 9: 'Cal', 10: 'kCal', 11: 'Mcal', 12: 'Gcal', 13: 'varh', 14: 'kvarh', 15: 'Mvarh', 16: 'Gvarh', 17: 'VAh', 18: 'kVAh', 19: 'MVAh', 20: 'GVAh', 21: 'kW', 22: 'kW', 23: 'MW', 24: 'GW', 25: 'kvar', 26: 'kvar', 27: 'Mvar', 28: 'Gvar', 29: 'VA', 30: 'kVA', 31: 'MVA', 32: 'GVA', 33: 'V', 34: 'A', 35: 'kV',36: 'kA', 37: 'C', 38: 'K', 39: 'l', 40: 'm3', 41: 'l/h', 42: 'm3/h', 43: 'm3xC', 44: 'ton', 45: 'ton/h', 46: 'h', 47: 'hh:mm:ss', 48: 'yy:mm:dd', 49: 'yyyy:mm:dd', 50: 'mm:dd', 51: '', 52: 'bar', 53: 'RTC', 54: 'ASCII', 55: 'm3 x 10', 56: 'ton x 10', 57: 'GJ x 10', 58: 'minutes', 59: 'Bitfield', 60: 's', 61: 'ms', 62: 'days', 63: 'RTC-Q', 64: 'Datetime'}

Byte 6: Antal bytes i data
Byte 7: Skaleringsfaktor:
exponent = b & 0x3F
if(b&0x40):
exponent = -exponent
factor = pow(10, exponent)
if (b&0x80==0x80):
factor=-factor

På Multical-målerne har jeg kørt med seriel parametre: 1200N82 - ved dog ikke om de kan køre hurtigere.

Til gengæld havde jeg ikke helt gennemskuet hvordan escape virkede. Men det kan jeg jo så få med nu :-)

  • 1
  • 0

Jeg er ligeledes igang med at interface til mine Kampstrup målere (min egen 382 bi-måler, mit forsyningsselskabs 601 varme og 61 vand -måler). Jeg har konstrueret et optisk læsehoved via en gammel 741 OpAmp og bortset fra noget echo/crosstalk (som jeg filtrerer i software, gør i også dét?) så fungerer det fint.

Ligeledes har jeg haft kontakt til Kamstrup, og udfordret dem på deres "open protocol" og "open source code" som de skriver i diverse materiale. Anyway, da jeg principielt nægter at acceptere nogen form for NDA, kom jeg ikke længere af den officielle vej. I skal dog næsten lige have denne skønne sætning med, omkring hvorfor protokollen er så hemmelig: "Årsagen hertil er, at vi løbende opdaterer KMP-protokollen og at vi derfor registrerer samtlige "brugere", sådan at vi senere kan rette henvendelse til disse firmaer om f.eks nye funktioner, implementering af nye målertyper osv.". Jeg tror hurtigt vi kan blive enige om at det er fis i en hornlygte, og at den sande grund nok er at Kamstrup forveksler sikkerhed med uigennemskuelighed (klassisk security though obscurity).

Og det giver måske også mening når man ser lidt nærmere på deres protokol, der er f.eks, kun 2^16 mulige passwords (til at kunne omprogrammere måleren) hvilket jeg har brugt til at finde passworded på min 382 måler med, via brute-force - det tager 1½ dag worst case at afprøve samtlige koder, med lidt under et forsøg pr. sekund.

Jeg havde også tænkt mig at dele information og kode med andre, der dog er i C# (Mono) da det er tilstrækkeligt lav-niveau (unsigned byte, serial support mv.) uden at være for besværligt. Grunden til jeg ikke har offentliggjort noget endnu, skyldes uklarhed over ricikoen ved at offentliggøre disse ting.

Det ville være suverent hvis vi kan stikke hovederne sammen og udveksle erfaringer. Et par issues. Hvorfor kalder i det CRC16, når der i virkeligheden er tale om en alm. 8-bit XOR/LRC?

            protected byte[] CalcChecksum(byte[] data)  
    {     
        byte checksum = (byte)0;  
        for (int i = 1; i < data.Length; i+=2)  
        {  
            checksum += (byte)FromKamstrupDouble(data, i);  
        }  
        checksum = (byte)((checksum ^ 0xFF) + 1);  
        return ToKamstrupDouble(checksum);  
    }

Og hvad er det for en mystisk ineffektiv protokol, hvor en Kamstrup byte bliver delt ud på 2 fysiske ASCII bytes der hver indeholder 0x30 - 0x46 og 0x40 hoppes over (speciel karakter)?

    private static byte ToKamstrupByte(int value)  
    {  
        if(value < 10)  
            return (byte)(0x30 + value);  
        return (byte)(0x40 + (value-9));  
    }  

    private static int FromKamstrupByte(byte value)  
    {  
        if(value < 0x3a)  
            return value - 0x30;  
        return value - 0x37;  
    }

Jeg skal lige have ryddet lidt op i koden, så smider jeg det på GitHub. Ser frem til hvad vi kan udrede sammen.

  • 1
  • 0

Så er Eriks information indarbejdet på github.

Casper, er vi sikre på at det er samme protokol den du roder med ?

Kamstrup angiver selv at de bruger CRC16 og derfra var det ret trivielt at finde hvilken CRC16 de brugte.

Mht til password: Har du prøvet default ? 12345

  • 1
  • 0

> Casper, er vi sikre på at det er samme protokol den du roder med ?

Nja jeg bliver da godt nok i tvivl. Jeg forbinder til min 382 med 1200N82, ingen handshake, og sender følgende som "Hello":

Talking through serial port /dev/ttyUSB1!
<- 0x40 0x46 0x45 0x30 0x30 0x30 0x32 @FE0002
-> 0x48 0x46 0x45 0x30 0x30 0x30 0x32 0x30 0x31 0x30 0x37 0x30 0x31 0x46 0x37 HFE0002010701F7

Første byte er reserveret til sign-on, resterende data bruger den lidt specielle encoding hvor Kamstrup deler en byte i en LSB og en MSB nibble, dvs. hvor 0x46 og 0x45 er lig 254 (16<<4 & 15), 0x30 og 0x30 er lig 0 (0<<4 & 0) og de to sidste bytes 0x30,0x32 er lig 2 (0<<4 & 2), som er en 8bit LRC af de underliggende data med første byte undtaget ((254 + 0)^0xff + 1). Måske er det min manglende forståelse af CRC16, jeg kan godt se at 2 bytes bliver brugt som checksum, men observerer kun 256 mutationer af disse hvilket der ikke er meget 16bit over.

  • 0
  • 0

>
Talking through serial port /dev/ttyUSB1!
<- 0x40 0x46 0x45 0x30 0x30 0x30 0x32 @FE0002
-> 0x48 0x46 0x45 0x30 0x30 0x30 0x32 0x30 0x31 0x30 0x37 0x30 0x31 0x46 0x37 HFE0002010701F7

Det ligner nærmest at nogen/noget hexdumper ting undervejs...

  • 0
  • 0

Det ligner nærmest at nogen/noget hexdumper ting undervejs...

Ja jeg tracer jo kommunikation, i et forsøg på at forstå og dokumentere hvad der sker. Anyway, eftersom kamstrup.py giver mig:

Energy in None None
Energy out None None
Energy in hi-res None None
Energy out hi-res None None
Voltage p1 None None
Voltage p2 None None
Voltage p3 None None
Current p1 None None
Current p2 None None
Current p3 None None
Power p1 None None
Power p2 None None
Power p3 None None

...må der næsten være tale om en anden (ældre) 382 måler.
Det KAN måske også skyldes echo/crosstalk? Måske jeg ikke kan få kamstrup.py til at funke, fordi mit optiske læsehoved læser hvad den selv skriver... dioderne på min 382 sidder begravet ca. 2 CM nede under et transparant stykke plastik, så jeg filtrerer denne echo/crosstalk fra i min software hvilket jo et nemt at gøre med en synkron protokol. Jeg må indrømme jeg er for nærig til at betale Kamstrup 1500kr for et læsehoved.

En IEC61107 forspørgsel afslører ikke hvilken generation jeg har:

KAM 685-382-OK-10
0.0(12345678)
1.20(0002308kWh)
1.20.1(0002307
kWh)
1.20.2(0000001kWh)
1.31(0050170
h)
1.26(0000000)
1.6(000000,5kW)
1.6
1(000000,5)!

...så det lader til at jeg måske har gang i en anden version af "KMP protokollen". Efter at have set de versioner af MeterTool Kamstrup har bikset sammen hardwired til én specifik måler, skulle det ikke undre mig.

  • 0
  • 0

Mange af de målere der er fjernaflæst bruger formaterne fra DS/EN 13757-3. Det meste af det stod tidligere i den 'gamle' DS/EN-1434-3 og kan sikker også findes i dokumenter fra M-bus User Group.

Dette er som i kan se europæiske standarder, som der er copyright på. Derfor kan jeg ikke udlevere det (og det Kamstrup nok heller ikke). Prøv evt. at se priserne på den slags dokumenter hos IEC eller ISO.

Det er helt rigtigt at meget af dette er "mindre struktureret". Der har ikke altid været en ordentlig systemarkitektur. Der har især tidligere været en masse mennesker der lavede 'smarte hack' når man skulle ha' plads til det i en 4-bit processor.

Koden for fabrikant navn er afledt af den tre bogstavs kode der bruges i IEC 1107 (som i øvrigt nu hedder IEC 62056-21). Teksten i standarden for dette er;
"The field "manufacturer" is coded unsigned binary with 2 bytes. This manufacturer ID is calculated from the ASCII code of EN 61107 manufacturer ID (three uppercase letters) with the following formula:
Man. ID = [ASCII(1st letter) – 64] • 32 • 32
+ [ASCII(2nd letter) – 64] • 32
+ [ASCII(3rd letter) – 64]

Forsyningsselskaber er generelt meget tilbageholdende med ændringer. Så længe den eksisterende standard virker, ønsker de ikke ændringer.

  • 0
  • 0

Jeg ved ikke om I har læst min lille intro på http://ing.dk/artikel/120890-hvilken-elmaa....

Et par kommentarer til ovenstående indlæg og Pyton-koden:
1. Man kan godt i hvert fald på nogle målere requeste flere end ét register i samme request
2. En liste over IEC fabrikant ID'er kan findes her:http://www.dlms.com/organization/flagmanuf...
3. Hvis man vil generalisere det hele lidt kan man med CID 0x01 (GetType) udlæse målermodellen. Ingen data ud over komandoen. 4 bytes svar:

[uint main hw type][uint8 sub hw type][uint16 sw revision]

53 00 Meter K382B / K382C
53 01 Meter K382Jx2, 3, 4, 5, 6, 7, 8, 9
55 00 Meter K382D / K382E
55 01 Meter K382JxB, C, D, F, G
56 00 Meter K162B / K162C
56 01 Meter K162Jx3, 6, 7
57 00 Meter K162D / K162E
57 01 Meter 162JxC, F, G
58 00 Meter K282B / K282C
58 01 Meter K282Jx2, 3, 4, 5, 6, 7, 8, 9
59 00 Meter K282D / K282E
59 01 Meter K282JxB, C, D, E, F, G

sw revision 0x0101 = A1, 0x0205 = B5 ...

  1. En lidt mere komplet register-liste for el-målere (per juli 2008):
    1 Active energy A14
    2 Active energy A23
    1031 Active energy A1234
    3 Reactive energy R12
    4 Reactive energy R34
    5 Reactive energy R1
    6 Reactive energy R4
    13 Active energy A14, test xxx.xxxx
    14 Active energy A23, test xxx.xxxx
    15 Reactive energy R12, test xxx.xxxx
    16 Reactive energy R34, test xxx.xxxx
    19 Active energy A14 Tariff 1
    23 Active energy A14 Tariff 2
    27 Active energy A14 Tariff 3
    31 Active energy A14 Tariff 4
    1059 Active energy A14 Tariff 5
    1060 Active energy A14 Tariff 6
    1061 Active energy A14 Tariff 7
    1062 Active energy A14 Tariff 8
    20 Active energy A23 Tariff 1
    24 Active energy A23 Tariff 2
    28 Active energy A23 Tariff 3
    32 Active energy A23 Tariff 4
    1063 Active energy A23 Tariff 5
    1064 Active energy A23 Tariff 6
    1065 Active energy A23 Tariff 7
    1066 Active energy A23 Tariff 8
    21 Reactive energy R12 Tariff 1
    25 Reactive energy R12 Tariff 2
    29 Reactive energy R12 Tariff 3
    33 Reactive energy R12 Tariff 4
    1067 Reactive energy R12 Tariff 5
    1068 Reactive energy R12 Tariff 6
    1069 Reactive energy R12 Tariff 7
    1070 Reactive energy R12 Tariff 8
    22 Reactive energy R34 Tariff 1
    26 Reactive energy R34 Tariff 2
    30 Reactive energy R34 Tariff 3
    34 Reactive energy R34 Tariff 4
    1071 Reactive energy R34 Tariff 5
    1072 Reactive energy R34 Tariff 6
    1073 Reactive energy R34 Tariff 7
    1074 Reactive energy R34 Tariff 8
    17 Resetable counter A14
    18 Resetable counter A23
    39 Max power P14
    40 Max power P23
    41 Max power Q12
    42 Max power Q34
    1023 Actual power P14
    1024 Actual power P23
    1025 Actual power Q12
    1026 Actual power Q34
    43 Accumulated max power P14
    44 Accumulated max power P23
    45 Accumulated max power Q12
    46 Accumulated max power Q34
    47 Number of debiting periods
    1049 Max power P14 RTC
    58 Pulse input
    1004 Hour counter
    1002 Clock
    1003 Date
    1047 RTC
    54 Configurations number 1
    55 Configurations number 2
    56 Configurations number 3
    1029 Configurations number 4
    1075 Configurations number 5
    57 Special Data 1
    1021 Special Data 2
    1010 Total meter number
    51 Meter number 1
    52 Meter number 2
    53 Meter number 3
    50 Meter status
    1001 Serial number
    1058 Type number
    2010 Active tariff
    1032 Operation mode
    1033 Max power P14 Tariff 1
    1050 Max power P14 Tariff 1 RTC
    1036 Max power P14 Tariff 2
    1051 Max power P14 Tariff 2 RTC
    1039 Power threshold value
    1040 Power threshold counter
    1045 RTC status
    1046 VCOPCO status
    1054 Voltage L1
    1055 Voltage L2
    1056 Voltage L3
    1076 Current L1
    1077 Current L2
    1078 Current L3
    1080 Actual power P14 L1
    1081 Actual power P14 L2
    1082 Actual power P14 L3
    1083 ROM checksum
    1005 Software revision
    1084 Voltage extremity
    1085 Voltage event
    1086 Logger status
    1087 Connection status
    1088 Connection feedback
    1102 Module port I/O configuration
  • 0
  • 0

Det lyder som om dit læsehoved er alt for følsomt.

Tak for tippet, jeg slap for crosstalk da jeg reducerede de ene modstand. Men jeg kan dog stadig ikke få kamstrup.py til at komme med noget konkret data, så jeg bliver nok nødt til at grave lidt mere i de forskellige måler typer/generationer... min er helt sikkert ikke en J generation (formeentligt en L eller en K).

  • 0
  • 0

Har du prøvet med andre seriel-parametre? phk's program kører 9600. Du skriver selv, at du bruger 1200N82.

Ja jeg har prøvet at gå ned til 1200, eftersom det ifølge Kamstrup's dokumentation kun er nyeste generation J der tillader 9600. De ældre generationer B, C, D, E, L og K, understøtter kun 1200.

  • 0
  • 0

Jeg synes mere det ligner en der samler pulser op fra gamle elmålere...

Hmm - der står da ellers:

"MGY skal først og
fremst være et alternativ der
man velger impulsbaserte
måleverdier fordi man ikke
ønsker å skifte ut (nye)
målere."

Men måske mine (manglende) norsk-kundskaber vindleder, så der menes "skifte ut [til] nye..." ?

Databladet er fra 2007.

  • 0
  • 0

Jeg har også selv overvejet at sætte en arduino på, men er ikke kommet længere end overvejelserne :-(.

Jeg snakkede med en installatør fra fjernvarmen, da jeg fik installeret ny måler med lækovervågning(Kamstrup 601, tror jeg ). Han påstod at det var problematisk at benytte sig af det optiske interface hvis man havde fjernaflæsning via f.eks GSM. De havde opgivet få til til at virke på en skole i området, der gerne selv ville følge med de deres forbrug. Jeg syntes nu det lyder lidt mystisk.

@Carsten: Kunne det måske være sådan noget der driller?

  • 0
  • 0

Da jeg spurgte Kamstrup om at få udleveret deres åbne protokol, sagde de, at forsyningsselskabet skulle give lov til at de udleverede protokollen, da kommunikationen kunne have indflydelse på opsætningen og driften af måleren. Jeg tolkede det som, at så længe jeg bare udlæser data, var der ikke noget problem (ud over at målerens batteri muligvis hurtigere bliver drænet). Men det er da ikke umuligt, at der er andre problemer.

  • 0
  • 0

Kunne det måske være sådan noget der driller?

Det tror jeg ikke, eftersom jeg p.t. kun arbejder med 382 målere (strømforbrug). Det optiske interface fører ifølge Kamstrup diagrammer, direkte ind i mikroprocessoren, og alt andet (MBus, wifi, GSM...) består så blot af konvertering til/fra KMP.

Jeg tolkede det som, at så længe jeg bare udlæser data, var der ikke noget problem (ud over at målerens batteri muligvis hurtigere bliver drænet).

For rent faktisk at ændre i måleren, skal du først autorisere dig. Tilsyneladende er mange målere aldrig blevet omprogrammeret fra default "12345", og det er måske derfor Kamstrup holder kortene tæt til kroppen.

  • 0
  • 0

Problemet er netop på mange målere (og måske også Kamstrups) at det er samme serielle kanal som det optiske øje og evt. indstiksmoduler til fjernaflæsningssystemer benytter - med det muligheder for sammenblanding af kommunikation som det kan medføre.

Mht. til sikkerhed tror jeg helt sikkert at Kamstrup og forsyningsselskaberne har røde øre. Mange default passwords, nem password brute force og ikke mindst ting man sjovt nok kan gøre uden brug af passwords (f.eks. at ændre målerens RTC - don't try this at home :-) )

  • 0
  • 0

Ingen af mine 382'ere (L og K modeller tror jeg det er) vil snakke på denne måde, men bruger åbentbart en ældre ASCII baseret protokol med simpel XOR checksum.

Er der andre der har held med at bruge PHK's Python kode på en ikke-J generation?

@PHK får du ikke et svar, hvis du sender 0x40 0x46 0x45 0x30 0x30 0x30 0x32 efterfulgt af 0x0D (LF) til din J-generations måler?

  • 0
  • 0

pywws burger jeg allerede til min Rosenberg måler, og dumper data til mit Synology NAS. Men der er ikke meget protokolværk der kan genbruges, hvilket jo er det svære... grafgenerering osv. kan man bare udlicitere til Google (http://code.google.com/apis/chart/).

Overvejer at prøve denne trådløse serielle enhed, så man bare kan knappe en lille dims på sine målere - men jeg ville skulle bruge 3, så søger p.t. efter en måde at multiplexe én på istedet:
http://77.162.55.232/usbscope/uart_index.html

  • 0
  • 0

Jeps, jeg tænkte heller ikke på protokollen, men mere på resten :O)

Den trådløse virker smart - det må du gerne holde mig opdateret med.

  • 0
  • 0

Hejsa

Jeg vil blot fortælle, at jeg med udgangspunkt i PyKamstrup har fået et par Arduino'er til at tale med både vores el- og fjernvarmemåler.

Den ene Arduino er koblet på vores elmåler (Kamstrup 382Jx3) vha. et hjemmebygget IR interface og afsender de opsamlede måledata via et ethernet-shield hvert minut til pachube.com.

Den anden Arduino har jeg bygget ind i en gammel Linksys WRT54GL router og koblet boardet til routerens interne serielport. Arduinoen trækker så - ligeledes ved hjælp af et IR interface - data ud af vor fjernvarmemåler (Kamstrup Multical 601), sender disse data serielt til Linksys'en, hvor et OpenWRT bash script derefter sender måledata til pachube.com.

Se evt. mere her: http://kildal.dk/?page_id=117

Begge målere "taler" KMP og mit lille projekt har kun kunnet lade sig gøre pga. det store forarbejde af Poul-Henning Kamp (PyKamstrup) samt den værdifulde information jeg har kunnet finde i denne tråd - så mange, mange tak for det!!

Jeg regner med at få renset lidt op i min Arduino kode, så den også kan havne på min webside herover.

Mvh Nicolai

  • 0
  • 0

Hejsa

Jeg er en af de få som er så heldig at have en kopi af protokollen (dækker multical 21, 402, 801, 62, 602, 601+ og 601 samt SVM S6

jeg er ikke den helt store nørd så fatter ikke ret meget andet end register id's

og jeg vil som så mange andre "bare" udlæse forbrug.... jeg har prøvet at følge nicolai kildals opskift på et ir interface her http://kildal.dk/wordpress/wp-content/uplo...

jeg har brugt disse her dioder/transistor

http://uk.rs-online.com/web/p/ir-leds/7269...
http://uk.rs-online.com/web/p/phototransis...

men eller samme værdier for modstandende....

jeg kan med multimeter fint komme ned på ca 1.6 volt hvis jeg holder hånden over modtageren og næsten 5V når jeg fjerner hånden... så jeg vil næsten sige ok selv for den del

men når jeg så beder arduinoen til at aflæse sker der intet....

koden er her (dog rettet til hvad angår register id's) http://kildal.dk/?page_id=432

kan det være at modstandene ikke passer og ir senderen er for svag? jeg har med en mobil set at den blinker, men ja ikke noget der blænder.

skal der magnet til for at aktivere interfacet? nogen skriver ja hvis man googler, andre siger det virke uden...

betyder det spor at den er fjernaflæst? ved ikke hvilket modul der bruges men ved blot den bliver aflæst hver 3 måned, alt for sløvt til mig og nogen måneder er af selskabet markeret med grå som betyder "cirka".

planen er som nicolai at logge data, dog vil jeg gøre det lokalt så jeg selv har kontrollen.

  • 0
  • 0

jeg prøvede så at fjerne formodstanden på tx dioden, bare for at se om det gjorde en forskel...

kun på mængden af udsendt ir lys.... mobilcam blev næsten overstyret...

men ingen data ud...

  • 0
  • 0

har så prøvet med og uden formodstand....

byttet rundt så tx dioden har været i både højre og venstre side af det lille optiske vindue

sågar prøvet med en magnet på

  • 0
  • 0

Ifølge databladet for din LED, bør din formodstand være på (5V - 1.3V) / 0.05A = 74 Ohm (rund op til 82 Ohm i E12 serien).

Der skal ikke magnet til interfacet, det er blot en fysisk standbard måde læsehovederne bruger til at "hænge" foran IR øjet.

Det betyder intet den er fjernaflæst, du vil altid kunne kommunikere via IR hovedet. Så vidt jeg kan observere, sender mine målere trådløst ca. hver 2 minut.

For at opnå fysisk adskillelse (ikke blot galvanisk adskillelse, undgå at dræne batteri og ej rage uklar med forsyningsselskab mv.) er jeg dog så småt begyndt at kigge på en SDR løsning istedet [http://sdr-radio.com/], her på ISM båndet er data dog krypteret.

  • 0
  • 0

hmm

nu er min måler forsynet fra 230V via en trafo i eltavlen, så dræn er ikke noget problem...

problemet er at der ikke kommer en "ski" ud... har prøvet næsten alt, med og uden formodstand, haft sender i både højre og venstre side...

hvor kan den være gal? kunne bølgelængden på ir strålerne være forkerte? ie forkert valgt diode?

eller kan koden i arduinoen være forkert? mr. kildal har det kørende så jeg undre mig meget, det er jo ikke ligefrem pc'en til rumfærgen jeg er ved at samle....

  • 0
  • 0

sig endelig til hvis du har success med SDR... måske jeg kunne bruge det

lige pt havde jeg dog mest kig på arduino da løsningen til at logge med er der hos openenergymonitor.org

  • 1
  • 0

Hej, er ved at lave logger til iphone, der via ir skal læse ovenstående måler, men det viser sig at det ikke er samme kode som phk's pykamstrup eller http://blog.bangbits.com/2013/08/talking-t...

her er hvad jeg kan sniffe når jeg sender nogle simple kommandoer via Kamstrup MeterTool:

https://github.com/st0ff3r/MeterLogger/blo...

jeg hentede data om målerens tid hvert minut - det ser ud til at det grundlæggende format der står på http://kamstrup.com/media/19757/file.pdf side 103 passer meget godt - starter med en start byte, destination address, cid (commando id?), så data'ene og to bits crc afsluttet med return (\r)

Nogen af jer der har erfaring med den?

  • 0
  • 0

Hejsa

rart at se der er nogen som gør lidt i det

jeg har samme måler som dig og sidst jeg forsøgte fik jeg ikke så meget som et komma ud af den

jeg brugte kredsløbet som er beskrevet her: http://kildal.dk/?page_id=117

men det kunne være jeg brugte forkerte ir dioder...

jeg fik endda dengang også protokollen udleveret fra kamstrup men det hjalp heller ikke noget...

min måler er fjernaflæst men med op til 3 mdr's forsinkelse eller lidt mere. noget jeg er lidt utilfreds med samt at man ikke kan få "read-only" adgang direkte på seriel udgangen.

Har jeg forstået rigtigt hvis IR altid er tilgængelig uanset hvad moduler fjernvarme selskabet har sat i?

mit næste forsøg på aflæsning er baseret på: http://www.thingiverse.com/thing:264268

har printet holderen, skal bare lige over den første så regner jeg med at bestille komponenter og lave en fuglerede og prøve at aflæse via min uno (som skal findes først)

  • 0
  • 0

Det er sjovt nok NÆSTEN den samme jeg fik

dog er der flere målere listet på forsiden, sidste rev. dato nederst er fra 2012, Rev er ikke M1 men T1, Der er lidt andre initialer

men ellers nok den samme... har ikke bladret din kopi igennem endnu

  • 0
  • 0

jo den er god nok, protokol mæssigt var der ikke noget nyt i den udgave jeg har.

Du skriver det er en iphone logger... vil det sige du har tlf hængende over måleren hele tiden?

hvad hardware bruger du til at sende kommandoer etc?

  • 0
  • 0

ok men det er jo en anden protokol end hvad jeg har set tidligere...

Dims jeg putter i minijack'et i iPhone og så kan den aflæse via IR

Bruger pic18 processor.

  • 0
  • 0

hejsa

nej har først lige bestilt stumper til at bygge ir hovedet med..

som sagt har jeg printet det her ud på min 3d printer, http://www.thingiverse.com/thing:264268

stumper bestilt... gutten der lavede 3d tingen har vist nogen print liggende men hvis ikke så har jeg noget klar i eagle som så tager ca 3-4 uger at lave ude i kina...

men har en Arduino uno og en mega liggende jeg kan bruge til at teste med... når først jeg får data ud så skal jeg have et modul fra openenergymonitor til at hive data ud og logge dem med ca 1-5 min interval

  • 1
  • 0

btw...

arduino kode jeg vil bruge:

include <SoftwareSerial.h>

// Kamstrup Multical 601
word const kregnums[] = { 0x003C,0x0050,0x0056,0x0057,0x0059,0x004a,0x0044,0x0045 };
char* kregstrings[] = { "Energy","Current Power","Temperature t1","Temperature t2","Temperature diff", "Flow", "Volumen 1", "Volumen 2" };

define NUMREGS 8

define KAMBAUD 1200

// Units
char* units[65] = {"","Wh","kWh","MWh","GWh","j","kj","Mj",
"Gj","Cal","kCal","Mcal","Gcal","varh","kvarh","Mvarh","Gvarh",
"VAh","kVAh","MVAh","GVAh","kW","kW","MW","GW","kvar","kvar","Mvar",
"Gvar","VA","kVA","MVA","GVA","V","A","kV","kA","C","K","l","m3",
"l/h","m3/h","m3xC","ton","ton/h","h","hh:mm:ss","yy:mm:dd","yyyy:mm:dd",
"mm:dd","","bar","RTC","ASCII","m3 x 10","ton x 10","GJ x 10","minutes","Bitfield",
"s","ms","days","RTC-Q","Datetime"};

// Pin definitions

define PIN_KAMSER_RX 5 // Kamstrup IR interface RX

define PIN_KAMSER_TX 7 // Kamstrup IR interface TX

define PIN_DIAG_LED 13 // Diag LED to blink with for fun

// Kamstrup optical IR serial

define KAMTIMEOUT 2000 // Kamstrup timeout after transmit

define POLLINTERVAL 300000 // Polling interval

SoftwareSerial kamSer(PIN_KAMSER_RX, PIN_KAMSER_TX, true); // Initialize serial

// last poll variable
long lastpoll;

void setup() {
// setup pins
pinMode(PIN_DIAG_LED,OUTPUT);
pinMode(PIN_KAMSER_RX,INPUT);
pinMode(PIN_KAMSER_TX,OUTPUT);

// initialize kamstrup serial interface
kamSer.begin(KAMBAUD);

// initialize serial interface
Serial.begin(9600);

// initialize lastpoll value
lastpoll = 0;
}

void loop() {

// check if it is time to do a poll
if(millis() - lastpoll > POLLINTERVAL or lastpoll == 0) {

// get Kamstrup data from meter  
for (int kreg = 0; kreg &lt; NUMREGS; kreg++) {  
  kamReadReg(kreg);  
  delay(100);  
}



// send a newline to have linksys process the data  
Serial.println(&quot;&quot;);    

// update lastpoll  
lastpoll = millis();  

}

// toggle LED to show we are alive
togglePin(PIN_DIAG_LED);

// loop delay
delay(500);

};

// Toggle pin
void togglePin(int pinNum) {
digitalWrite(pinNum, !digitalRead(pinNum));
}

// kamReadReg - read a Kamstrup register
void kamReadReg(unsigned short kreg) {

byte recvmsg[30]; // buffer of bytes to hold the received data
float rval; // this will hold the final value

// prepare message to send and send it
byte sendmsg[] = { 0x3f, 0x10, 0x01, (kregnums[kreg] >> 8), (kregnums[kreg] & 0xff) };
kamSend(sendmsg, 5);

// listen if we get an answer
unsigned short rxnum = kamReceive(recvmsg);

// check if number of received bytes > 0
if(rxnum != 0){

// decode the received message  
rval = kamDecode(kreg,recvmsg);  

// print out received value to terminal  
if (rval != false) {  
  Serial.print(rval);  
}  

}

Serial.print(",");

}

// kamSend - send data to Kamstrup meter
void kamSend(byte const *msg, int msgsize) {

// append checksum bytes to message
byte newmsg[msgsize+2];
for (int i = 0; i < msgsize; i++) { newmsg[i] = msg[i]; }
newmsg[msgsize++] = 0x00;
newmsg[msgsize++] = 0x00;
int c = crc_1021(newmsg, msgsize);
newmsg[msgsize-2] = (c >> 8);
newmsg[msgsize-1] = c & 0xff;

// build final transmit message - escape various bytes
byte txmsg[20] = { 0x80 }; // prefix
int txsize = 1;
for (int i = 0; i < msgsize; i++) {
if (newmsg[i] == 0x06 or newmsg[i] == 0x0d or newmsg[i] == 0x1b or newmsg[i] == 0x40 or newmsg[i] == 0x80) {
txmsg[txsize++] = 0x1b;
txmsg[txsize++] = newmsg[i] ^ 0xff;
} else {
txmsg[txsize++] = newmsg[i];
}
}
txmsg[txsize++] = 0x0d; // EOF

// send to serial interface
for (int x = 0; x < txsize; x++) {
kamSer.write(txmsg[x]);
}

}

// kamReceive - receive bytes from Kamstrup meter
unsigned short kamReceive(byte recvmsg[]) {

byte rxdata[50]; // buffer to hold received data
unsigned long rxindex = 0;
unsigned long starttime = millis();

kamSer.flush(); // flush serial buffer - might contain noise

byte r;

// loop until EOL received or timeout
while(r != 0x0d){

// handle rx timeout  
if(millis()-starttime &gt; KAMTIMEOUT) {  
  return 0;  
}

// handle incoming data  
if (kamSer.available()) {

  // receive byte  
  r = kamSer.read();  
  if(r != 0x40) {  // don&#039;t append if we see the start marker  
    // append data  
    rxdata[rxindex] = r;  
    rxindex++;   
  }

}  

}

// remove escape markers from received data
unsigned short j = 0;
for (unsigned short i = 0; i < rxindex -1; i++) {
if (rxdata[i] == 0x1b) {
byte v = rxdata[i+1] ^ 0xff;
if (v != 0x06 and v != 0x0d and v != 0x1b and v != 0x40 and v != 0x80){
Serial.print("Missing escape ");
Serial.println(v,HEX);
}
recvmsg[j] = v;
i++; // skip
} else {
recvmsg[j] = rxdata[i];
}
j++;
}

// check CRC
if (crc_1021(recvmsg,j)) {
Serial.println("CRC error: ");
return 0;
}

return j;

}

// kamDecode - decodes received data
float kamDecode(unsigned short const kreg, byte const *msg) {

// skip if message is not valid
if (msg[0] != 0x3f or msg[1] != 0x10) {
return false;
}
if (msg[2] != (kregnums[kreg] >> 8) or msg[3] != (kregnums[kreg] & 0xff)) {
return false;
}

// decode the mantissa
long x = 0;
for (int i = 0; i < msg[5]; i++) {
x <<= 8;
x |= msg[i + 7];
}

// decode the exponent
int i = msg[6] & 0x3f;
if (msg[6] & 0x40) {
i = -i;
};
float ifl = pow(10,i);
if (msg[6] & 0x80) {
ifl = -ifl;
}

// return final value
return (float )(x * ifl);

}

// crc_1021 - calculate crc16
long crc_1021(byte const *inmsg, unsigned int len){
long creg = 0x0000;
for(unsigned int i = 0; i < len; i++) {
int mask = 0x80;
while(mask > 0) {
creg <<= 1;
if (inmsg[i] & mask){
creg |= 1;
}
mask>>=1;
if (creg & 0x10000) {
creg &= 0xffff;
creg ^= 0x1021;
}
}
}
return creg;
}

  • 1
  • 0

Hej, så har vi kogt koden ned på en lille microprocessor der snakker med meteret og sender til iOS-device. Elektronikken er i produktion.

Er der nogen af der der har lyst til at teste i første omgang interfaceti app'en, så send en mail med dit UDID til meterlogger@skulp.net, så sender jeg app'en.

Dimsen - kan i første omgang læse Kamstrup Multical 601 og dem der bruger KMP > 2006.

Er ved at få den til at læse ældre multical også. Hvilken version af protokollen mener I denne her er? http://kamstrup.com/media/17009/mc-gb - det ligner ikke phk's eller søren bangs protokol?

  • 0
  • 0

jeg har planer om at gøre forsøget. har komponenter til et læsehoved jeg fandt på thingiverse: http://www.thingiverse.com/thing:264268

også mig der har lavet eagle filerne ud fra kidcad ver.

har såmænd også printet "kassen" men skal lige finde tiden til at samle osv.

vi har samme måler i radioamatør klubben så hvis jeg får success med det skal der også noget op der.

og jo skal nok give besked hvis det lykkedes.

  • 0
  • 0

Så du har slet ikke lavet en fuglerede og testet inden du laver den færdige?
Jeg forsøgte at lave den som Nicolai havde lavet men jeg kan ikke få det til at virke, når den sidder til arduinoen, kan jeg ikke via et kamera se ir lyset.

Så jeg er i tvivl om det er det optiske hoved, eller arduinoen der ikke virker.

/Allan

  • 0
  • 0

jo har lavet fuglereden sidst jeg forsøgte mig

men da vidste jeg ikke hvad IR dioder der skulle bruges, det har jeg via thingiverse nu fundet ud af

men også dengang kunne jeg med en mobil se ir lyset... tror jeg har været tæt på men bare ikke den rigtige bølgelængde

  • 0
  • 0

http://www.el-supply.dk/?Vnr=455.IRR
http://www.el-supply.dk/?Vnr=455.IRT

koden er kildal's uændret... vil imorgen se om jeg har nok til at lave en fugle rede

prøv evt også at kigge det her link: http://www.thingiverse.com/thing:264268

det er en gut ved mads som har lavet 3D tingen.. og han har fået det til at virke.

men vil se dyner... når jeg engang er i lodret plan vil jeg se om jeg fik stumper nok til at lave en fuglerede...

  • 0
  • 0

så fik jeg lavet opskrifen på fuglereden som kildal giver

og brugte også den ir ting som han linker til.

der kommer lys ud, jeg kan se det med en mobil..

men det jeg gjorde for at teste om der er lys er at bede arduino om at tænde den konstant... den blinker så af og til men ellers konstant tændt...

det er meget svagt.. og når man køre på normal vis vil man slet ikke nå at se det via en mobil...

tester lidt senere på dagen om der rent faktisk kommer data ud

  • 0
  • 0

æv ingen data...

om sender dioden så vender til højre eller venstre gør ikke nogen forskel...

og jeg lade den gå helt til målerens lille optiske vindue og 2 gennemløb med dioden til højre og så 2 gennemløb til venstre...

kun komma'er fik jeg ud som adskiller data...

æv bæv

  • 0
  • 0

jeg kan se ud af billedet at delen til venstre stammer fra eagle...

kan det passe du har været inde på thingiverse og taget eagle filerne jeg har lavet?

og har du prøvet at lave opstillingen præcis som jeg har lavet den?

  • 0
  • 0

Ja jeg har taget den ene del fra thingiverse og sat en transistor ind kildal's. jeg har lavet den komplette fra thingiverse og virker heller ikke, ir lyser men ikke kommuikere? Måske det er arduino koden?

Selve ir øjet burte ikke være så kunstværdig, så jeg forstår det ikke helt? Har du set kildals kode til hans fjv måler?

  • 0
  • 0

jeg vil nu sige gid der var nogen som vidste lidt mere..

der går jo også rygter om at hvis ens måler er fjernaflæst så kan man i nogen tilfælde ikke selv aflæse med optisk øje osv....

mit eget problem er at jeg kun har aflæsning 4 gange i året når skraldebilen kommer forbi, der sidder et lille modem modul i.... hvorfor f.... de ikke har brugt el nettet lige som elmåleren nu den sidder 50cm fra eltavlen osv.... så kunne man i det mindste se aflæsninger hver time eller sådan..

endelig burde der være en lov at om at forbrugs data ikke er selskabets ejendom men forbrugeren og at forbrugeren skal kunne trække data ud lokalt hvis man ønsker det.

  • 1
  • 0

Jubii.....

Så fik jeg data ud med det her øje:

http://wiki.hal9k.dk/projects/kamstrup

Sample data:

Energy: 102.47
Current Power: 0.00
Temperature t1: 35.45
Temperature t2: 30.84
Temperature diff: 4.61
Flow: 0.00
Volumen 1: 1208.96
Volumen 2: 0.00

Endelig sketch til arduino:

include <SoftwareSerial.h>

//Kamstrup setup
// Kamstrup Multical 601
word const kregnums[] = { 0x003C,0x0050,0x0056,0x0057,0x0059,0x004a,0x0044,0x0045 };
char* kregstrings[] = { "Energy","Current Power","Temperature t1","Temperature t2","Temperature diff", "Flow", "Volumen 1", "Volumen 2" };

define NUMREGS 8 // Number of registers above

define KAMBAUD 1200

// Units
char* units[65] = {"","Wh","kWh","MWh","GWh","j","kj","Mj",
"Gj","Cal","kCal","Mcal","Gcal","varh","kvarh","Mvarh","Gvarh",
"VAh","kVAh","MVAh","GVAh","kW","kW","MW","GW","kvar","kvar","Mvar",
"Gvar","VA","kVA","MVA","GVA","V","A","kV","kA","C","K","l","m3",
"l/h","m3/h","m3xC","ton","ton/h","h","hh:mm:ss","yy:mm:dd","yyyy:mm:dd",
"mm:dd","","bar","RTC","ASCII","m3 x 10","ton x 10","GJ x 10","minutes","Bitfield",
"s","ms","days","RTC-Q","Datetime"};

// Pin definitions

define PIN_KAMSER_RX 9 // Kamstrup IR interface RX

define PIN_KAMSER_TX 10 // Kamstrup IR interface TX

define PIN_LED 13 // Standard Arduino LED

// Kamstrup optical IR serial

define KAMTIMEOUT 2000 // Kamstrup timeout after transmit

define POLLINTERVAL 20000 // Polling interval

SoftwareSerial kamSer(PIN_KAMSER_RX, PIN_KAMSER_TX, false); // Initialize serial

// last poll variable
long lastpoll;

void setup() {
// initialize serial interface
Serial.begin(57600);

pinMode(PIN_LED,OUTPUT);
digitalWrite(PIN_LED, 0);

// setup kamstrup serial
pinMode(PIN_KAMSER_RX,INPUT);
pinMode(PIN_KAMSER_TX,OUTPUT);
kamSer.begin(KAMBAUD);

// initialize lastpoll value
lastpoll = 0;
}

void loop() {

// check if it is time to do a poll
if(millis() - lastpoll > POLLINTERVAL or lastpoll == 0) {

// poll the Kamstrup registers for data
for (int kreg = 0; kreg < NUMREGS; kreg++) {
kamReadReg(kreg);
delay(100);
}

  digitalWrite(PIN_LED, digitalRead(PIN_KAMSER_RX));    

delay(1000);

// update lastpoll    
lastpoll = millis();    

}
}

// kamReadReg - read a Kamstrup register
float kamReadReg(unsigned short kreg) {

byte recvmsg[30]; // buffer of bytes to hold the received data
float rval; // this will hold the final value

// prepare message to send and send it
byte sendmsg[] = { 0x3f, 0x10, 0x01, (kregnums[kreg] >> 8), (kregnums[kreg] & 0xff) };
kamSend(sendmsg, 5);

// listen if we get an answer
unsigned short rxnum = kamReceive(recvmsg);

// check if number of received bytes > 0
if(rxnum != 0){

// decode the received message    
rval = kamDecode(kreg,recvmsg);

// print out received value to terminal (debug)    
Serial.print(kregstrings[kreg]);    
Serial.print(&quot;: &quot;);    
Serial.print(rval);    
Serial.print(&quot; &quot;);    
Serial.println();  

return rval;    
}    

}

// kamSend - send data to Kamstrup meter
void kamSend(byte const *msg, int msgsize) {

// append checksum bytes to message
byte newmsg[msgsize+2];
for (int i = 0; i < msgsize; i++) { newmsg[i] = msg[i]; }
newmsg[msgsize++] = 0x00;
newmsg[msgsize++] = 0x00;
int c = crc_1021(newmsg, msgsize);
newmsg[msgsize-2] = (c >> 8);
newmsg[msgsize-1] = c & 0xff;

// build final transmit message - escape various bytes
byte txmsg[20] = { 0x80 }; // prefix
int txsize = 1;
for (int i = 0; i < msgsize; i++) {
if (newmsg[i] == 0x06 or newmsg[i] == 0x0d or newmsg[i] == 0x1b or newmsg[i] == 0x40 or newmsg[i] == 0x80) {
txmsg[txsize++] = 0x1b;
txmsg[txsize++] = newmsg[i] ^ 0xff;
} else {
txmsg[txsize++] = newmsg[i];
}
}
txmsg[txsize++] = 0x0d; // EOF

// send to serial interface
for (int x = 0; x < txsize; x++) {
kamSer.write(txmsg[x]);
}

}

// kamReceive - receive bytes from Kamstrup meter
unsigned short kamReceive(byte recvmsg[]) {

byte rxdata[50]; // buffer to hold received data
unsigned long rxindex = 0;
unsigned long starttime = millis();

kamSer.flush(); // flush serial buffer - might contain noise

byte r;

// loop until EOL received or timeout
while(r != 0x0d){

// handle rx timeout    
if(millis()-starttime &gt; KAMTIMEOUT) {    
  Serial.println(&quot;Timed out listening for data&quot;);    
  return 0;    
}

// handle incoming data    
if (kamSer.available()) {

  // receive byte    
  r = kamSer.read();    
  if(r != 0x40) {  // don&#039;t append if we see the start marker    
    // append data    
    rxdata[rxindex] = r;    
    rxindex++;     
  }

}    

}

// remove escape markers from received data
unsigned short j = 0;
for (unsigned short i = 0; i < rxindex -1; i++) {
if (rxdata[i] == 0x1b) {
byte v = rxdata[i+1] ^ 0xff;
if (v != 0x06 and v != 0x0d and v != 0x1b and v != 0x40 and v != 0x80){
Serial.print("Missing escape ");
Serial.println(v,HEX);
}
recvmsg[j] = v;
i++; // skip
} else {
recvmsg[j] = rxdata[i];
}
j++;
}

// check CRC
if (crc_1021(recvmsg,j)) {
Serial.println("CRC error: ");
return 0;
}

return j;

}

// kamDecode - decodes received data
float kamDecode(unsigned short const kreg, byte const *msg) {

// skip if message is not valid
if (msg[0] != 0x3f or msg[1] != 0x10) {
return false;
}
if (msg[2] != (kregnums[kreg] >> 8) or msg[3] != (kregnums[kreg] & 0xff)) {
return false;
}

// decode the mantissa
long x = 0;
for (int i = 0; i < msg[5]; i++) {
x <<= 8;
x |= msg[i + 7];
}

// decode the exponent
int i = msg[6] & 0x3f;
if (msg[6] & 0x40) {
i = -i;
};
float ifl = pow(10,i);
if (msg[6] & 0x80) {
ifl = -ifl;
}

// return final value
return (float )(x * ifl);

}

// crc_1021 - calculate crc16
long crc_1021(byte const *inmsg, unsigned int len){
long creg = 0x0000;
for(unsigned int i = 0; i < len; i++) {
int mask = 0x80;
while(mask > 0) {
creg <<= 1;
if (inmsg[i] & mask){
creg |= 1;
}
mask>>=1;
if (creg & 0x10000) {
creg &= 0xffff;
creg ^= 0x1021;
}
}
}
return creg;
}

  • 0
  • 0

Ja da jeg fik den var det direkte fra kamstrup, dog skulle jeg lige have varmeselskabets velsignelse, men den fik jeg nu meget nemt da de udemærket ved at man alligevel ikke kan ændre på måledata.

nogen selskaber siger nej da de ikke har en hat forstand på tingene.

  • 0
  • 0

hehe, har aldrig spurgt dem om lov... der er jo tale om ren aflæsning og det tror jeg næppe man skal have lov til... der bliver jo heller ikke lavet noget indgreb i måleren... så nej har ikke spurgt om lov, og vil heller ikke... og de fjernaflæser så kommer aldrig til at se det

og hvis de brokker sig får de bare lov at give mig mulighed for at aflæse hver 2. sek uden at stå ved måleren.... ellers kan de sku pille deres lort ned og plombere hanere i lukket tilstand

  • 0
  • 0

ikke at jeg ved af, men det kan da ikke udelukkes at kamstrup og værk har snakket sammen direkte...

men nu er der hvert fald en opskrift som kan følges....det eneste jeg glemte at sige er at jeg startede med at sætte øjet på med kabelhul nedad... det skal vende op... omvendt er det sku heller ikke til at se på måleren hvad diode der er hvad.

  • 0
  • 0

Det er super det der er lavet, jeg kan bare ikke få det til at virke... men det er ikke den rigtige måler, håbede bare på man bare kunne få et svar man måske ikke kunne tyde... ved du om det er den samme kommando man sender til alle målere, også skal man bare bruge protokollen til at tyde svaret? Eller det også start kommando?

  • 0
  • 0

kiggede lige på databladet for din vand måler:

http://www.kamstrup.dk/media/16717/file.pdf

side 44:

Måleren har et optisk kommunikationsinterface på fronten. Interfacet kommunikerer med 1200 baud,

For at begrænse strømforbruget, er det optiske øje normalt slukket. Målerens optiske kommunikation
tændes automatisk, 4 sek. efter et magnetisk optisk læsehoved er placeret på måleren.

det vil sige at det er slukket med mindre der kommer en magnet eller 2 til... så hvis du ikke bruger magnet på din måler sker der NADA :-D

det samme gælder for varme måleren:

http://www.kamstrup.dk/media/19756/file.pdf

side 105

min måler er forsynet med 24V fra en trafo i eltavlen, det er vist gældende på det meste af fyn...

hvis din ikke er det vil jeg tænke mig lidt om... batteriet kan hurtig tømmes... og man vil nok have et større forklaringsproblem. Værket kan jo sige at du er skyld i at der skal skiftes tidligt. at de så kunne have valgt at forsyne fra en 24V trafo er nok noget andet

men nok løftede pegefingre... i begge tilfælde taler de samme protokol... et par sider op i den sidste pdf kan du se nogen af de register id's der bruges....

hvad opstilling har du prøvet sidst?

  • 0
  • 0

ja på din går den ikke uden magnet... nok heller ikke i mit tilfælde men jeg behøver ikke tænke på batteri

men hvis du byggede den her: http://wiki.hal9k.dk/projects/kamstrup

ja så er du så tæt på du kan komme... jeg kiggede ikke lige i datablad om der stod noget med levetid på batteri hvis man aflæser optisk

det kommer jo også an på hvor tit man gør det, kamnstrup sagde til mig at man ikke skulle gå under 1 min af hensyn til batteri... men de vidste jo heller ikke min er direkte forsynet med 24V

  • 0
  • 0

hmm... din udsender også trådløst og batteri holder 12 år....

de fleste værker skifter måler efter bare 6 år.... så ja hvis du kan nøjes med at aflæse hver 5 min eller sådan vil jeg ikke mene der skulle ske noget

det er jo kun når du beder om at få data det koster noget.... magneten er bare en besked til måleren om at nu kan der ske noget (tror jeg)

men du bestemmer selv... jeg vil ikke selv have noget problem i det

det eneste der kan drille er at man skal finde register id man skal spørge om... og dem kender jeg ikke... jeg har bare brugt de programmer der er lagt på nettet... de er sådan set ens... den eneste forskel er de register id'er man spørger på

  • 0
  • 0

Hej

Er der nogen af Jer der har prøvet at aflæse Jeres målere trådløst?
Jeg har en Multical 402 med et wireless modul. Jeg har købt et wireless M-bus Radio modul som jeg har sat på et Beagleboard. Der er hul igennem og jeg modtager data fra måleren ca. hvert 4 minut. Men det ligner bare en header, som jeg dog ikke har afkodet endnu.
Så hvis der er én af Jer der har hul igennem trådløst vil jeg gerne høre lidt om det.

  • 0
  • 0

Lars,

Det er min erfaring, at M-bus telegrammer er krypterede. Jeg var begyndt at kigge lidt på det via SDR, men kom ikke rigtig længere end også at kunne se headers.

  • 0
  • 0

Så fik vi software til at køre i esp8266 + modul til at sætte det i kamstrup 601

https://github.com/nabovarme/kamstrup-wifi
https://oshpark.com/shared_projects/uZ377Gru

resultatet kan ses her:

http://isp.skulp.net/nabovarme/

Vi forsyner en del af christiania med varme fra pillefyr (nabovarme) og bruger bl.a. multical 601 som målere ude hos brugerne. Planen er at sætte modulet i og både fjernaflæse og give brugerne mulighed for at følge med i deres forbrug.

  • 0
  • 0

@Søren Juhl Andreasen , fik du nogensinde fat på Dongs Kamstrup 382Mx3 måler. Jeg har forsøgt men, hvis du har fundet en løsning, så kunne jeg godt tænke mig et par tips :-)

Mvh. Flemming

  • 0
  • 0