Lesing av AMS data (AMS/HAN -> IoT)

[Helgemor]

15 timer siden, kanor skrev:

 

Jeg kjøpte ett slikt:   https://www.aliexpress.com/item/Industrial-Grade-USB-Transfer-to-MBUS-Host-USB-MBUS-Meter-Reading-Communication-USB-Power-Supply-10/32831725364.html?spm=a2g0s.9042311.0.0.V57FUI  og det fungere ok, så ser ikke bort fra at denne billigere varianten også vil virke. Men mener å ha lest advarsler om at man skal være obs på at slike billige M-BUS adaptere som er bygd opp av diskre komponenter ikke har galvanisk skille og man kan risikere å skade USB-porten man kobler seg inn på.

 

Jeg også bruker en Raspberry Pi 3 som kjører domoticz. Har skrevet python-script som leser serie-dataene som kommer inn på USB-porten også henter ut/konverterer de hex-bytene som inneholder de verdiene jeg vil ha tak i. Har gitt blanke i å forsøke å forstå 'obis-språket' siden dataene som strømmer ut på hanporten har ett kjent fast og forutsigbart mønster, og det holder å telle seg fram til riktig byte for aktuell verdi i hver frame.

 

Men hadde jeg vist om den sw som du linker til over, hadde jeg nok spart meg noen timer med å lære meg python....

 

Har i tillegg laget ett python-script som laster ned xls-arket med spot-prisene fra nordpool  så jeg kan kalkulere strømkost time for time. Skal bli spennende å se når strømregningen kommer neste mnd om man med timebasert avregning som kommer i nær fremtid vil måtte betale mer eller mindre, og om det vil være noe å spare på å flytte de 'trege forbrukerne' til timer med lav pris:

 

 

 

Interessant løsning (selv om jeg ikke kjører Domoticz). Og du har ingen problemer med strømforsyning fra Raspberryen til HAN-dingsen? Den kan jo ikke levere allverden av effekt. Hvilken strømforsyning har du til Raspberry?

[roarfred]

On 3/16/2018 at 21:01, Odd said:

Noen som husker at M-bus i utgangspunktet er toveis?

Jeg ønsker å kople på andre M-bus enheter på samme grensesnitt.

Det er jo ikke mye som skal til når kretsene i utgangspunktet støtter dette-

M-Bus på AMS målerne er litt spesiell. Her er det kun en-veis kommunikasjon, og det skrives i dokumentasjon at det kun skal være en device tilkoblet. Jeg kan ikke se at det skulle gjøre noen skade om flere "lyttet på linjen", men en ville uansett bare få lese ut de samme data. Å koble noe annet M-Bus utstyr på samme linjen som andre sensorer tror jeg er en dårlig ide, uten at jeg kan si at det er helt umulig. (Vil tippe at AMS måleren fullstendig igjorerer om det er annen kommunikasjon på bussen, og bare pøser på data som vil forstyrre)

[kanor]

2 timer siden, Helgemor skrev:

Interessant løsning (selv om jeg ikke kjører Domoticz). Og du har ingen problemer med strømforsyning fra Raspberryen til HAN-dingsen? Den kan jo ikke levere allverden av effekt. Hvilken strømforsyning har du til Raspberry?

 

God strømforsyning er viktig ja. Brukte først en 2A usb-lader som fulgte med min gamle Samsung note 4, men Pi'en hang seg sånn ca. en gang i døgnet med den.

 

Også kjøpte jeg denne:  https://www.aliexpress.com/item/Raspberry-Pi-3-Power-Supply-5V-3A-Switch-Button-Micro-USB-Interface-Power-Charger-Adapter-EU/32805797998.html?spm=a2g0s.9042311.0.0.IaC7wV, men den var enda dårligere...   

 

Så jeg bruker nå denne som jeg egentlig hadde tiltenkt lading av nytelefonen via en USB-C HUB:  https://www.aliexpress.com/item/L-I-45W-USB-Type-C-Wall-Charger-Power-Adapter-with-Power-Delivery-for-iPhone-X/32839304892.html?spm=a2g0s.9042311.0.0.W3aMME

 

Er nok en hvis sammenheng mellom pris og kvalitet på varene fra kina ja ?

 

[xibriz]

Jeg kjører orginale stømforsyninger på alle mine Rpi. For flere år siden oppdaget vi på jobb at Rpi gikk i en slags "power saving mode" hvis den ikke hadde kraftig nok strømforsyning. De offesielle specs er:

 

Sitat

Output Volt: 5,1 V
Output Ampere: 2.5A

 

Endret 19. mars 2018 av xibriz

[Odd]

15 timer siden, roarfred skrev:

M-Bus på AMS målerne er litt spesiell. Her er det kun en-veis kommunikasjon, og det skrives i dokumentasjon at det kun skal være en device tilkoblet. Jeg kan ikke se at det skulle gjøre noen skade om flere "lyttet på linjen", men en ville uansett bare få lese ut de samme data. Å koble noe annet M-Bus utstyr på samme linjen som andre sensorer tror jeg er en dårlig ide, uten at jeg kan si at det er helt umulig. (Vil tippe at AMS måleren fullstendig igjorerer om det er annen kommunikasjon på bussen, og bare pøser på data som vil forstyrre)

 

Så det er ikke M-Bus med andre ord.
Jeg har to andre M-Bus givere i tekniskrom for fjernvarme og tappevann.
Det betyr at jeg faktisk må ha to grensesnitt fordi de ikke følger standarden.

 

[Morten B]

1 minutt siden, Odd skrev:

 

Så det er ikke M-Bus med andre ord.
Jeg har to andre M-Bus givere i tekniskrom for fjernvarme og tappevann.
Det betyr at jeg faktisk må ha to grensesnitt fordi de ikke følger standarden.

 

Hva for en måler bruker du på vann? Hadde vært kjekt å hatt egentlig.. Så slipper jeg å gå helt ut på teknisk rom for å lese av måleren en gang i året

 

[roarfred]

38 minutes ago, Odd said:

Så det er ikke M-Bus med andre ord

Jeg tror nok de med rette kan kalle det M-Bus fortsatt, men lurer på om dette kan være et tillegg (Push) som er kommet inn i senere tid.

 

Jeg har også implementert en mer tradisjonell M-Bus løsning der min ESP8266 må spørre et kalorimeter om å få ut data. Når jeg har sammenlignet disse, så ser jeg ikke noe mer enn den elektriske protokollen (spenningsnivåer for 1 og 0, og baud-rate) som er felles. Eks. er kalkulasjon av checksum forskjellig.

 

Er på fryktelig tynn is her, men godt mulig andre vil korrigere? Uansett er nok konklusjonen at en må ha en separat leser for HAN og evt. en annen for mer tradisjonelt M-Bus utstyr.

[ArnieO]

On 2/27/2018 at 20:42, cpu22 said:

 

Håper du har rett, med du ser at du har PWR_FLAG to steder?

Sjekk side 10 i databladet. Hvis man bruker "eksternt" power, så må pin 9 og 11 splittes, og pin 9 skal evt. koples til power. Pin 11 kommer fra den interne spenningsregulatoren. Håper jeg ikke blir for pirkete, jeg vil jo ikke påvirke designet ditt i feil retning heller.

Sammenlignet med datablad ser pi 9 og 11 rart ut. Layouten på github har disse koblet mot jord via C5 og R10, ikke mot noe power, mens @roarfred sitt svar tydet på at intensjonen var at pin 9/11 skulle være koblet til power? Databladet indikerer vel at de skulle vært splittet, med pin 11 til C5/R10, og pin 9 til power?

Men der fungerer visst slik, ser jeg lengre nede i tråden?

[roarfred]

@ArnieO, Pin 9 og 11 er koblet sammen. Dette er vist i Figur 7 i TI sitt datablad. Disse vil holde en slags "power" tatt fra HAN porten, men den brukes ikke til noe, og dette punktet skal dermed heller ikke være koblet til noe annet enn R10 og C5. (Hadde vi hatt en mindre stømkrevende krets enn ESP8266, så kunne dette punktet forsynet kretsen med strøm fra HAN porten)

 

og merk at lablene merket med PWR_FLAG ikke har noe med hverandre å gjøre. De er utelukkende der for å bekrefte at dette er et "Power" punkt, slik at elektrisk sjekk diagram fungerer.

 

Jeg har loddet sammen to slike kort og testet dem litt uten problem. Et lite minus er at der ikke er lagt til rette for debug-port på Serial1, men litt tidligere i tråden ble det antydet at vi kanskje kan kjøre debugging på samme port som programmeringen. (og da samme port som HAN porten er koblet til, men vi bruker bare RX på HAN og bare TX på debug. Det som kan gjøre dette litt klønete er at HAN port er satt opp med 2400 baud og 8E1 på Kaifa, og dermed må også debug skje på samme setup)

[ArnieO]

3 minutes ago, roarfred said:

@ArnieO, Pin 9 og 11 er koblet sammen. Dette er vist i Figur 7 i TI sitt datablad. Disse vil holde en slags "power" tatt fra HAN porten, men den brukes ikke til noe, og dette punktet skal dermed heller ikke være koblet til noe annet enn R10 og C5. (Hadde vi hatt en mindre stømkrevende krets enn ESP8266, så kunne dette punktet forsynet kretsen med strøm fra HAN porten)

 

@roarfred Figur 7 viser den case du beskriver, hvor ESP8266 (tilsvarer "Sensor system" i Fig 7) forsynes fra TSS721, og det brukes en stor C på pinne 3 (C_STC) for å lagre energi mens bussen ikke har spenning. I ditt design spenningsforsyner du imidlertid ESP separat, og slik jeg leser databladet er det da Fig 8 som skal brukes. Som du ser i Table 2, så beskrives pin 9 (BAT) som "Logic level adjust". Slik jeg leser det er dette en input til TSS721 som angir hvilket logisk nivå du vil ha på utgangene. Altså er det her du må gi inn 3,3V for å si at du vil ha 3,3V signal ut av RX/RXI og gi det inn på TX/TXI. Designet ditt fungerer i dette tilfellet fordi VDD er en 3,3V spenningsregulatorutgang. Men strengt tatt skulle du gitt inn ESP8266 sin spenningsforsyning her. Hadde du f.eks. brukt en 5V mikrokontroller ville dette neppe fungert, fordi du ville fått 0 til 3,3V ut. Ved å gi 5V inn på pin 9 ville RX/TX vært 0 til 5V.

[roarfred]

Oi, @ArnieO, tror jeg er med på hva du sier, da at vi får ut en TTL på 3.3V fordi TSS sin VDD pinne er 3.3V og ikke fordi vi styrer dette fra ESP sin tilførselspenning. Er med på at det måtte vært annerledes om vi skulle ha ut en 5V TTL, men jeg kan godt leve med denne kuriositeten  Takk for innsikt!

[ArnieO]

11 hours ago, roarfred said:

Oi, @ArnieO, tror jeg er med på hva du sier, da at vi får ut en TTL på 3.3V fordi TSS sin VDD pinne er 3.3V og ikke fordi vi styrer dette fra ESP sin tilførselspenning. Er med på at det måtte vært annerledes om vi skulle ha ut en 5V TTL, men jeg kan godt leve med denne kuriositeten  Takk for innsikt!

Just precis! ☺️ Ja, kortet fungerer nok slik det er, men greit å gjøre oppmerksom på dette i fall noen f.eks. vil bruke designet mot en 5V Arduino.

Endret 20. mars 2018 av ArnieO
Tydeliggjøre at kortet fungerer *slik det er*.

[daniel.h.iversen]

På 17.3.2018 den 22.39, kanor skrev:

 

Jeg kjøpte ett slikt:   https://www.aliexpress.com/item/Industrial-Grade-USB-Transfer-to-MBUS-Host-USB-MBUS-Meter-Reading-Communication-USB-Power-Supply-10/32831725364.html?spm=a2g0s.9042311.0.0.V57FUI  og det fungere ok, så ser ikke bort fra at denne billigere varianten også vil virke. Men mener å ha lest advarsler om at man skal være obs på at slike billige M-BUS adaptere som er bygd opp av diskre komponenter ikke har galvanisk skille og man kan risikere å skade USB-porten man kobler seg inn på.

 

Jeg også bruker en Raspberry Pi 3 som kjører domoticz. Har skrevet python-script som leser serie-dataene som kommer inn på USB-porten også henter ut/konverterer de hex-bytene som inneholder de verdiene jeg vil ha tak i. Har gitt blanke i å forsøke å forstå 'obis-språket' siden dataene som strømmer ut på hanporten har ett kjent fast og forutsigbart mønster, og det holder å telle seg fram til riktig byte for aktuell verdi i hver frame.

 

Men hadde jeg vist om den sw som du linker til over, hadde jeg nok spart meg noen timer med å lære meg python....

 

Har i tillegg laget ett python-script som laster ned xls-arket med spot-prisene fra nordpool  så jeg kan kalkulere strømkost time for time. Skal bli spennende å se når strømregningen kommer neste mnd om man med timebasert avregning som kommer i nær fremtid vil måtte betale mer eller mindre, og om det vil være noe å spare på å flytte de 'trege forbrukerne' til timer med lav pris:

 

 

 

Kult, kunne du delt python koden? 

[roarfred]

Noen oppdateringer fra den siste uken...

 

1) Laget meg en boks selv og 3D printet.

Ble helt greitt til å gjemmes bort i sikringskapet (bilder nedenfor)

Om interesse ligger STL filer på github: https://github.com/roarfred/AmsToMqttBridge/tree/master/Electrical/HAN_ESP_TSS721/enclosure

(Brukt Fusion 360 her, er det noe annet enn STL format som er fornuftig å dele?)

 

2) Har laget en mer fullverdig Arduino "sketch", med følgende features:

• Boot som Access Point om ikke config finnes, eller om Prog-knappen trykkes ned innen 5 sek etter oppstart
• Webside for å konfigurere (bruker innebygget DNS, så hvilken som helst http-url funker, eks. http://config)
  • SSID / Passord
  • Meter Type (Kaifa / Kamstrup / Aidon)
  • MQTT server, port, brukernavn og passord
• Lagrer config i EEPROM (første byte er en "identifying byte" som kan endres om en endrer på strukturen)
• Støtter Kaifa og Kamstrup måler, og tilrettelagt for Aidon (sendt forespørsel om å få test-data fra dem for å fullføre. Får se om det kommer noe, ellers får jeg ta en best guess)
• Temperatursensor leses av og rapporteres sammen med hver sending på MQTT
• Mottak av MQTT meldinger (klargjort, med egen metode, men ikke kodet noe spesiellt her) - kan enkelt brukes for OTA update
• Debugging via samme connector (litt klønete, må koble til/fra TX på FTDI når evt. HAN port skal brukes, og en må ha en terminal som støtter 2400 baud 8E1 for Kaifa)
• Utnytter blå LED på ESP, for litt status:
  • Lyser i 5 sek etter oppstart, for å vise at du kan trykke Prog-knappen for å boote som AP
  • Blinker hvert sekund (50% syklus) hvis startet som AP
  • Under normal drift, tennes hver gang en pakke på HAN porten er dekodet, og lyser til den er levert på MQTT. (På Kaifa, flash hvert 2. sekund)
• WiFi/MQTT reconnect

Da tror jeg det er på tide å gjøre en solid oppdatering på all dokumentasjon på github...

Som de sier i politikken om dagen, lik og del!

 

Config

 

Kretskort i boksen

 

"Montert" vha friksjon i sikringsskapet

 

 

 

 

[xibriz]

Meget godt jobbet @roarfred

[ArnieO]

1 hour ago, xibriz said:

Meget godt jobbet @roarfred

Jeg henger meg på den. Jeg har lest hele tråden (og et par grener) siste dagene, og er virkelig imponert over jobben @roarfred har gjort her. Høy klasse!

Bildet ovenfor viser fordelen med den lange, smale PCBen. Noen produsenter leverer 50x50 mm kort til 15-16 USD for en pakke på 10 levert i postkassa etter et par uker. Men jeg ser nå fordelen med det smale kortet.

 

Status for min egen del er at AE Nett har svart meg på epost at de ikke er klar til å aktivere HAN, men det kommer "innen 2019". Så jeg har tid til å bestille print og komponentene jeg ikke har i skuffen allerede.

[ArnieO]

On 3/17/2018 at 22:39, kanor said:

Har i tillegg laget ett python-script som laster ned xls-arket med spot-prisene fra nordpool  så jeg kan kalkulere strømkost time for time. Skal bli spennende å se når strømregningen kommer neste mnd om man med timebasert avregning som kommer i nær fremtid vil måtte betale mer eller mindre, og om det vil være noe å spare på å flytte de 'trege forbrukerne' til timer med lav pris:

 

Alternativ kilde for spotpriser er https://transparency.entsoe.eu/

Det står instruks på API-siden deres om hvordan du får API-nøkkel for automatisert nedlesing.

Prisene her er i EUR/MWh, men Norges Bank har åpen API for å hente valutakursene, så omregningen EUR->NOK kan enkelt automatiseres.

Jeg har implementert dette i min Domoticz. Et LUA-script trigges litt før midnatt, leser neste døgns priser fra Entsoe, og stiller timere på VVberederen slik at den kobles inn i de lavest prisede timeintervallene. Det er noen pitfalls i algoritmen ennå, merket vi i helgen - da laveste prisene ikke lengre var på natta men på ettermiddagen. Så jobber videre med den så vi unngår (bokstavelig talt) kalddusj... :-) Kommer nok til å legge en temp sensor på VVberederen også som kan trigge umiddelbar innkobling dersom temp kommer under et visst nivå.

 

Spørsmål:

Hvordan gjør du for å lagre strømprisene i Domoticz time for time? Har du en timer som en gang i timen leser rett timeintervall fra det Nordpool Excel-arket og oppdaterer "devicen" din? Jeg har ikke funnet noen metode for å lagre flere målinger i slengen med spesifisert "datostempel" (kanskje ikke mulig) - som jo hadde vært alternativet.

[Bullhill]

Kan ikke si annet enn fantastisk jobb her, og da spesielt roarfred, men er også flere som har gjort en god jobb.

 

Var selv i kontakt med NTE nå for å få åpnet mine HAN porter.

Har selv 2 strømmålere der en er på en driftsbyggning med vesentlig større hovedsikringer, derfor har jeg en trafomålt strømmåler. Disse måtte man gange enkelte verdier med 60 for å få korrekte data ut siden de målte bare en liten del av strømmen. Vet ikke om dette bør inn i matematikken til ESP'en eller bør mottakeren regne om det?

 

Videre har jeg ikke wifi dekning der jeg har den strømmåleren. Tror dere det går bra med ca 50M cat6 kabel før den går inn i boksen ESP'en står i?

[ArnieO]

20 minutes ago, Bullhill said:

Tror dere det går bra med ca 50M cat6 kabel før den går inn i boksen ESP'en står i?

 

50 meter bør gå helt greit.

http://www.m-bus.com/mbusdoc/md4.php

(Tror det er en tegnsettingsfeil der det står 29 W nedenfor; skal nok være 29 ohm.)

[roarfred]

49 minutes ago, Bullhill said:

Vet ikke om dette bør inn i matematikken til ESP'en

 

Takk for gode tilbakemeldinger, alle!!

 

Når det gjelder justering av verdier, så har jeg valgt å ikke gjøre noe med disse, dvs. at de leveres i json slik de ligger i DLMS formatet. Eks. ligger spenning som et 32 bit heltall, som skal divideres med 10 for å gi rett spenning i volt. Det er ingen informasjon i data-strømmen som sier noe om dette, men godt mulig at OBIS koden har dette spesifisert i et register. Vet vi var inne på noen detaljer omkring OBIS her tidligere, men tar ikke helt igjen om dette kan deduseres med logikk eller om det må slås opp i en tabell. (og evt. om det i det hele tatt er spesifisert)

 

Sannsynligvis vil hver enkelt målertype ha sitt eget oppsett på hvilke data som kommer, og i hvilken rekkefølge. Arduino-biblioteket HanReader er generell nok til å kunne tolke enhver slik "liste", men må siden spørres om å få ut eks. "heltall fra element nr. 8" i listen. Her er det implementert separate klasser for å systematisere oppsettet til hver målertype (Kaifa.h/Kamstrup.h), og her er også noen justeringer jeg vet om med eks. enfas-målere som vil ha et ulikt antall elementer. Trafomålte varianter har jeg bare såvidt hørt om, så det hadde vært veldig spennende å få kikke på output fra dem også.

 

Litt avhengig av hvor mange ulike målere vi ender opp med til slutt, så må det vurderes om det kanskje er mer hensiktsmessing å ignorere målertype fullstendig på Arduino-siden, og heller rapportere inn et array i json, der alle elementer fra listen er inkludert. Eks. vil Kamstrup da ha annet hvert element som en string, der selve OBIS koden viser. For den som skal konsumere dataene, så betyr det kanskje ikke så mye å måtte gå til data[8] istedet for til data["UL1"] for å finne spenningen på L1?

 

PS: Fikk svar fra NTE i dag at de ikke har eksempel-data for Aidon, men de sender med en definisjon tilsvarende den PDF som vi har sett tidligere. Det vises til at de har valgt å avvente implementering av HAN dataprofil inntil endelig avklaring omkring kryptering/fysisk sikring av HAN port foreligger fra NVE/Datatilsynet.

[Bullhill]

Har sjekket litt mer i sikringskapet når jeg kom hjem nå og er nok ikke trafomålt, men er nok "Split-core current transformer" som brukes. Jeg må ha hørt feil når jeg snakket med NTE idag.

 

Ønsker du å teste kan jeg informere deg når de åpner porten min @roarfred? Skal være greit å vite hvor mye strøm som faktisk går siden det kun er 2 stk 7.5kW og 1 stk 5.5kW motor som står på måleren. Antar du ikke er så langt unna meg siden vi begge er i kontakt med NTE. Jeg bor i Steinkjer

[Odd]

5 timer siden, roarfred skrev:

avklaring omkring kryptering/fysisk sikring av HAN port foreligger fra NVE/Datatilsynet

 

Håper vi som bruker får anledning til å bestemme om dataene skal være på eller av, og om de skal være krypterte eller ikke.
Jeg ser for meg at å utvikle løsninger med krypterte data ut fra HAN vil gjøre det temmelig vanskelig for oss på den HW vi baserer oss på..
Hvem skal ha ansvaret for nøkler, hvilken standard?
Så langt har de holdt på siden 2011 og har ikke klart å bli enige om den åpne standarden engang.

[ZoRaC]

3 minutter siden, Odd skrev:

Håper vi som bruker får anledning til å bestemme om dataene skal være på eller av, og om de skal være krypterte eller ikke.
Jeg ser for meg at å utvikle løsninger med krypterte data ut fra HAN vil gjøre det temmelig vanskelig for oss på den HW vi baserer oss på..
Hvem skal ha ansvaret for nøkler, hvilken standard?
Så langt har de holdt på siden 2011 og har ikke klart å bli enige om den åpne standarden engang.

 

Epost fra NVE 16.02.18:

Sitat

På side 2 i brevet du viser til er det et kapittel om kryptering. Der står det at NVE vil vurdere behovet for dette når aktørene har fått mer erfaring med krypteringsløsninger. NEK sendte et forslag til sikkerhetsløsning for HAN ut på høring i fjor høst https://www.nek.no/aktuelt/horinger/, og de er nå i ferd med å ferdigstille denne anbefalingen. Både NVE, Datatilsynet og noen relevante virksomheter fra bransjen har vært involvert i arbeidet. NVE presiserer at nettselskapene må påse at de oppfyller krav i sikkerhetsregelverk, som eksempelvis avregningsforskriftens § 4-2 g) og personopplysningsloven m/forskrift, før de tilbyr å åpne HAN-porten for kundene sine.

 

Dette er brevet det henvises til:

https://hafslundnett.blob.core.windows.net/files/NY_MALER/infobrev/NVE_Info_kunder_HANgrensesnitt.pdf

[Odd]

57 minutter siden, ZoRaC skrev:

 

Epost fra NVE 16.02.18:

 

Dette er brevet det henvises til:

https://hafslundnett.blob.core.windows.net/files/NY_MALER/infobrev/NVE_Info_kunder_HANgrensesnitt.pdf

 

Det som bekymrer meg er ordlyden i all dokumentasjonen,
Det brukes "bør" isteden for "skal", ting skal fremdeles utredes etter 6 år.
Jeg har lang er faring som prosjektleder, her synes jeg prosjektledelsen og kravstiller er for sene.
Vi snakker om en modernisering anslåes til 12 milliarder som vi brukere skal betale og spesifikasjonen for dette er fremdeles ikke klar.
Prosjektet, eller moderniseringen skal være ferdig 31.12.2018 det er et krav.

Endret 21. mars 2018 av Odd

[roarfred]

3 hours ago, Bullhill said:

Antar du ikke er så langt unna meg

Nåvel, jeg sitter i Etne, en times kjøring øst fra Haugesund. Grunnen til at jeg var i kontakt med NTE var at jeg ble henvist dit fra NVE, for spørsmål ang. Aidon målere. Har bare Kaifa selv, både hjemme og (snart) på hytta, men prøver å få ting til å fungere for alle...