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

[Andreas]

Jeg leste jo ut målertype, det er altså min 1-fas Kamstrup-måler.. 

 

Dette leste jeg ut : 6861111BN242101040 

,Og dette leser vi i manualen : 

 

Så da kan du jo lese ut den stringen, og vite at det er en 1-fas eller 3-fas måler...

 

 

Har forøvrig det seende slik ut i Homeseer nå :

 

Alt ser ut til å være stabilt...

 

Andreas

[KVS]

Hei alle,

 

jeg har lest denne tråden over flere dager og er mektig imponert over innsatsen og hva dere har fått til.

 

Jeg har nettopp startet smarthusreisen og bestemt meg for Home Assistant på RPi3, med kombinasjon av WiFi, z-wave og zigbee utstyr. Har i tillegg gått til innkjøp av en Google Home Assistant, fikk den i hus i går og har mye gøy med den for øyeblikket, før den vil bli satt på større prøver med å styre diverse ting i huset.

 

I sommer fikk jeg installert ny måler, type Kaifa, og tenkte ikke mer på det før jeg kom over denne tråden. Sendte derfor sporenstreks en mail til BKK, som er min leverandør her  i Bergen, om å få åpnet HAN-porten på måleren.

I dag kom svaret;

"For øyeblikket har vi dessverre ikke muligheter for å åpnet Han-porten, det jobbes med å finne en løsning på dette og vi vil gi en tilbakemelding så snart vi kan"

 

Er det noen andre som har BKK som leverandør og har fått samme svar? Husker ikke å ha lest om BKK i tråden.

 

Kenneth

[roarfred]

9 hours ago, KVS said:

Hei alle,

 

jeg har lest denne tråden over flere dager og er mektig imponert over innsatsen og hva dere har fått til.

 

Jeg har nettopp startet smarthusreisen og bestemt meg for Home Assistant på RPi3, med kombinasjon av WiFi, z-wave og zigbee utstyr. Har i tillegg gått til innkjøp av en Google Home Assistant, fikk den i hus i går og har mye gøy med den for øyeblikket, før den vil bli satt på større prøver med å styre diverse ting i huset.

 

I sommer fikk jeg installert ny måler, type Kaifa, og tenkte ikke mer på det før jeg kom over denne tråden. Sendte derfor sporenstreks en mail til BKK, som er min leverandør her  i Bergen, om å få åpnet HAN-porten på måleren.

I dag kom svaret;

"For øyeblikket har vi dessverre ikke muligheter for å åpnet Han-porten, det jobbes med å finne en løsning på dette og vi vil gi en tilbakemelding så snart vi kan"

 

Er det noen andre som har BKK som leverandør og har fått samme svar? Husker ikke å ha lest om BKK i tråden.

 

Kenneth

Dette var litt rart. BKK bruker Valider (kanskje de også er Valider, eller eier Valider?), som er det samme selskapet som nyttes av Etne E-lag som jeg har. Hos meg åpnet de mandag etter at jeg sendte dem en e-post søndag. Har det fra veldig uoffisielle kilder at selve åpningen er det Valider som gjør, og at det foreløbig er en liten manuell jobb...

 

Hvis en går inn på www.valider.no og ser på eiere, så ligger BKK øverst og Etne nederst

[KVS]

10 timer siden, roarfred skrev:

Dette var litt rart. BKK bruker Valider (kanskje de også er Valider, eller eier Valider?), som er det samme selskapet som nyttes av Etne E-lag som jeg har. Hos meg åpnet de mandag etter at jeg sendte dem en e-post søndag. Har det fra veldig uoffisielle kilder at selve åpningen er det Valider som gjør, og at det foreløbig er en liten manuell jobb...

 

Hvis en går inn på www.valider.no og ser på eiere, så ligger BKK øverst og Etne nederst

 

Hm, kanskje jeg skal ringe BKK å høre med de. Har tid ennå, venter på ting og tang fra Ebay for å lage og teste hardwaren først. 

[Trillebar]

Jeg fikk følgende svar fra BKK 13.11.2017:

Hei
Vi bekrefter at Han porten er åpnet

Med vennlig hilsen
BKK Nett AS

[cpu22]

Hei

Jeg trenger litt assistanse her. Jeg har en Kamstrup-måler og kraftselskapet har nylig aktivert utlesing av data på HAN-porten. Problemet er at jeg ser ingen signaler med oscilloscopet. Det ser ut som en konstant 24.2V DC, akkurat som før de aktiverte den.

 

Hvordan ser signalet ut fra Kamstrup-måleren for dere som har fått det til å virke? Jeg har lest at det skal svinge mellom 24V og 36V. Noen som kan bekrefte dette? Evt. bilde.

[Einar]

Nei, det skal svinge ned. Til rundt 18V om jeg husker rett.

Så om du skifter trigger på skopet ned under 24V bør det dukke opp noe om det er noe der. Sett den også til fallende flanke.

For å verifisere rett instilling av trigger kan du ta av måleklypa. Da skal du se fallet fra 24V og ned.

 

[cpu22]

5 minutes ago, Einar said:

Nei, det skal svinge ned. Til rundt 18V om jeg husker rett.

Så om du skifter trigger på skopet ned under 24V bør det dukke opp noe om det er noe der. Sett den også til fallende flanke.

For å verifisere rett instilling av trigger kan du ta av måleklypa. Da skal du se fallet fra 24V og ned.

 

Takk for tips. Jeg har egentlig prøvd trigger både over og under 24V, men det virker helt dødt. Burde skje noe hvert 10. sekund ifølge manualen. Og, ja jeg får trigger på fallet fra 24V til 0 når jeg tar av proben. Mulig måleren eller HAN-modulen er gåen? Uflaks.

[Andreas]

Tipper at den ikke er aktivert..

Har du noe last på utgangen?

[cpu22]

4 hours ago, Andreas said:

Tipper at den ikke er aktivert..

Har du noe last på utgangen?

Nei, ingen belastning. Bare en høy-impedans probe til oscilloscopet.

[Andreas]

Dra ut modulen av måleren og sett den inn igjen.. Så sender du en sinnamail til netteier..

[cpu22]

5 minutes ago, Andreas said:

Dra ut modulen av måleren og sett den inn igjen.. Så sender du en sinnamail til netteier..

 

He-he, ja jeg har tenkt å gå videre med saken. Jeg hadde lyst å være sånn ca. 100% sikker først. Litt pinlig å klage hvis det er min feil, liksom. Jeg har prøvd å ta ut modulen og sette den inn igjen. Det hjalp heller ikke.

 

Jeg prøvde å belaste utgangen med 47k for å se om det hadde noen effekt, men det gjorde ingen forskjell.

 

Jeg leste forresten i M-BUS spec'en at "1" tilsvarer +36V og "0" tilsvarer +24V. Er det noen her som har målt på dette?

[Einar]

Mulig det er fordi min ikke er aktivert. Men den ligger på 24V. Og hvilestilling skal jo være den høyeste spenningen.

Men det er vel flere her som har målt på et aktivert interface. Uansett er en stabil spenning ikke mye tess for å lese ut data.

Jeg ville vel forsøke med å sjekke med kraftselskapet uten å ta i bruk pekefinger eller utestemme.

 

[xibriz]

24v som detter ned til ca 18v hvert 10. sekund er fasiten på Kamstrup.

[arneolav]

Finnes noe info her:

https://www.nek.no/wp-content/uploads/2017/10/AMS-HAN-personvernnotat-høringsversjon.pdf

For ordens skyld gjentas data som skal strømmes på HAN-porten så snart den er åpnet.

Dette er beskrevet i detalj i brev fra NVE, datert 27.09.2016, ref 2016603500-6.

 

 

Det foreslås at alle de tre målerleverandørene (Aidon, Kaifa og Kamstrup) skal kunne tilby kundene følgende informasjon og frekvens:

 

Frekvens = 2,5 sekund(*)

• Aktiv effekt (kW) x 2 (= import og eksport) Frekvens = 10 sekunder

• Reaktiv effekt (kVAr) x 2

• Strøm (A) x 3 (L1, L2 og L3)

• Spenning (V) x 3 (alle faser) Frekvens = 1 time

• Aktiv energi (kWh) x 2 (= import og eksport)

• Reaktiv energi (kVArh) x 2

• Klokke og dato

(*)Kamstrups målere tilfredsstiller ikke dette kravet. Gruppen mener imidlertid at dette er håndterlig for tjenesteleverandørene.

 

Kan være greitt å ta en titt her:

https://en.wikipedia.org/wiki/Meter-Bus

 

Og her:

https://www.nve.no/Media/4307/201603186-1-informasjon-til-kundene-via-han-grensesnittet-i-ams-måleren-obis-koder-1772408_1124902_0.pdf

 

Og her:

http://www.m-bus.com/info/mbuse.php

Og her:

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

Endret 22. november 2017 av arneolav
Wikipedia- m-bus

[arneolav]

M-bus

3.3. Variable Data Structure

The variable data structure is the part of an M-Bus frame that contains the measurement data. Its format is defined as part of the M-Bus application layer in EN 13757-3.

 

A variable data structure consists of the following components:

 

1. Data Header (optional) – Depending on the value of the CI field the variable data structure contains a long data header (CI=0x72), short data header (CI=0x7a), or no data header (CI=0x78). The header contains mainly information about the metering device. A short header contains the following fields:

   • Access number (1 byte) – is a counter of how many times a meter has been read (wired M-Bus) or a meter has sent data (wireless M-Bus). For detailed information on when the access number is incremented see EN 13757-3.

   • Status (1 byte) – Codes the status of the metering device. For example a device can signal that it is running out of power or is in an error state.

   • Configuration (2 bytes) – the configuration field contains information about the encryption mode and the number of encrypted bytes. Wired M-Bus usually uses no encryption while wireless M-Bus meters often do. Only data after the data header may be encrypted.

   A long data header contains the secondary address of the meter in addition to all the fields of the short header.

    

    

    

2. Data records – Data records (sometimes called variable data blocks) contain the measured data. Each data record is made up of a data information block (DIB), a value information block (VIB) and a value. Similar to OBIS codes DIBs and VIBs code information such as the meaning of a value.

   The DIB codes:

    

   • Storage number – a meter can have several storages e.g. to store historical time series data. The storage number 0 signals an actual value.

   • Function – Data can have the following four function types: instantaneous value, max value, min value, value during error state

   • Data value type – The length and coding of the data value field following the DIB and VIB. Possible value types are 8/16/24/32/48/64 bit integer, 32 bit real, 2/4/6/8/12 digit binary coded decimals (BCD), date and string. In addition the value type “none” exists to label data records that have no data value field.

   • Tariff – Indicates the tariff number of this data field. The data of tariff 0 is usually the sum of all other tariffs.

   • Subunit – Can be used by a slave to distinguish several subunits of the metering device.

   The VIB codes:

    

   • Description – The meaning of the data value (e.g. “Energy”, “Volume” etc.)

   • Unit – The unit of the data value.

   • Multiplier – A factor by which the data value coded in the data field has to be multiplied with

    

    

3. Manufacturer specific data (optional) – Manufacturer specific data may optionally be appended at the end of the frame. This is essentially an array of bytes that is not standardized by the M-Bus standard.

[arneolav]

Hva skal strømmålerne måle?

I utgangspunktet er det selve strømforbruket (kWh) per time som skal lagres, men strømmålerne måler mer enn som så:

Avlesingsfrekvens = 2,5 sekund(*)

• Aktiv effekt (kW) x 2 (= import og eksport)

Avlesingsfrekvens = 10 sekunder

• Reaktiv effekt (kVAr) x 2
• Strøm (A) x 3 (L1, L2 og L3)
• Spenning (V) x 3 (alle faser)

Avlesingsfrekvens = 1 time

• Aktiv energi (kWh) x 2 (= import og eksport)
• Reaktiv energi (kVArh) x 2
• Klokke og dato

I utgangspunktet er det bare de siste tre elementene som skal lagres, mens resten er ting som du kan hente ut fra strømmåleren i sanntid gjennom for eksempel en app på mobilen.

 

 

Endret 22. november 2017 av arneolav

[roarfred]

@arneolav, du finner mye av dette samlet under documentation mappen i github prosjektet: https://github.com/roarfred/AmsToMqttBridge/

 

Ang. frekvens ser vi at data kommer hvert annet sekund (ikke hvert 2.5), fra Kaifa. Kamstrup sender hvert 10. sekund og Aidon har vi ikke fått kontakt med ennå, men siste dokumentasjon fra dem sier at det vil ligne veldig på data fra Kaifa.

 

M-Bus tror jeg bare er brukt for det elektriske laget, og ikke for logisk protokoll. Dessuten brukes her push, slik at en ikke trenger å spørre etter data. I prinsippet kan du level-konvertere (ca 25V/12V til 3.3V/0V og koble til med en terminal som da vil motta strømmende data) 

Jeg har et annet prosjekt som implementerer med mer fullstendig M-Bus protokoll, der arduino må spørre etter data. Se evt. https://github.com/roarfred/MBusMqttLogger

[arneolav]

T

23 minutter siden, roarfred skrev:

@arneolav, du finner mye av dette samlet under documentation mappen i github prosjektet: https://github.com/roarfred/AmsToMqttBridge/

 

Ok,

Tenkte det var greitt å legge inn noe her siden det er svar på endel aktuelle spørsmål.

 

Flott at dere arbeider så grundig med dette!

 

 

[xibriz]

Jeg lagde meg nytt produksjonskort i går. Jeg kaller det "frankenboard" med referanse til Frankenstein.

 

 

[Odd]

På ‎22‎.‎11‎.‎2017 den 23.43, roarfred skrev:

Jeg har et annet prosjekt som implementerer med mer fullstendig M-Bus protokoll, der arduino må spørre etter data. Se evt. https://github.com/roarfred/MBusMqttLogger

 

Jeg har en leilighet i et sameie som har m-bus målere på vaskevann (mengde) og oppvarmingsvann (effekt).
Disse er kablet mot et M-bus grensesnitt på vår strømmåler.
Tanken var at det lokale e-verket skulle lese av vann forbruket.

Dessverre fikk de aldri til dette på en skikkelig måte, det vil si de klarte ikke å lese av alle målerne i hver enkelt leilighet riktig.

 

Nå skal Trønderenergi installere nye målere i hele sameiet i første del av 2018, og vi kommer til å bli pilot på avlesing av vann og strøm via HAN og via strømleverandør.

 

Jeg følger med denne tråden fordi den jo omhandler nettopp dette og kommer til å informere hva som skjer i piloten.

 

Så et lite hjertesukk  Det er 20 år siden jeg la loddebolten på hylla, jeg savner en step by step artikkel om hvordan en lager et HAN grensesnitt mot HS3.

Det vil si med programvare og komponenter.

Ja det ligger på GIT hub, men sant å si så er det litt uklart hvordan en kommer i mål selv om en har elektronikk og programmering i bunn for mange år siden

Mulig jeg til og med tar ned loddebolten

Endret 24. november 2017 av Odd

[xibriz]

I går annonserte TK både på nett og SMS at folk måtte begrense forbruket mellom klokken 1500 og 1900. Jeg gjorde min del helt til ungene ville bade:)

 

Skrudde av alle varmekilder, ventet med og lade elbilen osv.

 

http://www.itromso.no/nyheter/2017/11/24/Folk-fulgte-oppfordringen-fra-Troms-Kraft-–-Markant-nedgang-i-strømforbruket-15650867.ece

 

 

[roarfred]

3 hours ago, Odd said:

Så et lite hjertesukk  Det er 20 år siden jeg la loddebolten på hylla, jeg savner en step by step artikkel om hvordan en lager et HAN grensesnitt mot HS3.

Det vil si med programvare og komponenter

Det stemmer at en her har tatt utgangspunkt i en "basis" kunnskap om arduino, ESP8266 og lodding. Siden det finnes en lang rekke artikler og forum som dekker "getting-started" med disse teknologiene, så har jeg ikke brydd meg så mye med dette. Spesielt i denne fasen har det vært litt prøving og feiling, og da tror jeg det ville blitt litt mye basic support, om en skulle lagt opp til noe enklere, i stedet for å bruke kreftene på å løse de faktiske problemene.

 

Så er kanskje spørsmålet, har du interesse av å lære disse tingene, for å kunne bygge forskjellige typer sensorer, eller vil du bare ha tilgang på data fra strømmåleren? Hvis det siste er tilfellet, så blir det etter all sannsynlighet mulig å kjøpe slike dingser fra ulike leverandører, med abbonement mot et dertil egnet API. Litt å ha i bakhodet her at den løsningen som github-prosjektet dekker ikke gir deg direkte tilgang på dataene heller, uten at du enten har en MQTT server eller om du koder noe helt eget i Arduino koden.

 

For ESP8266 vil jeg gjerne anbefale videoene til Andreas Spiess: https://www.youtube.com/channel/UCu7_D0o48KbfhpEohoP7YSQ

Disse er spesielt bra om en har litt Arduino-erfaring. 

 

[roarfred]

On ‎23‎.‎11‎.‎2017 at 00:12, arneolav said:

T

Ok,

Tenkte det var greitt å legge inn noe her siden det er svar på endel aktuelle spørsmål.

 

Flott at dere arbeider så grundig med dette!

 

 

Takk for det og takk for bidrag  Ville bare tipse om at det var samlet litt allerede om du ikke hadde sett det

[Moskus]

6 timer siden, Odd skrev:

Så et lite hjertesukk  Det er 20 år siden jeg la loddebolten på hylla, jeg savner en step by step artikkel om hvordan en lager et HAN grensesnitt mot HS3.

Det vil si med programvare og komponenter.

Jeg venter på at noen kan selge meg en ferdig boks...