roarfred

Når jeg har fått tenkt meg litt om så er nok ikke dette helt ideell måte å gjøre det på. Utfordringen er at vi i praksis snakker om en annen måler her, selv om fabrikaten er Kamstrup. ListID er slett ikke noen ID, men faktisk et tall som angir antall elementer i listen. Om Kamstrup kommer med flere modeller etterhvert, så er det stor sjans for at vi kan få en annen modell som har samme antall elementer i listen, men andre felter/rekkefølge. Det bør dermed lages en spesifikk implementasjon per modell-nummer (evt. også per firmware, men det får vi se etterhvert)

Enn så lenge, så var det ingen like antall her, så det eksemplet jeg sendte funker sikkert godt nok til en test

27 minutes ago, xibriz said:

@roarfred : Jeg har nå testet HanReader mot en Kamstrup 1-fase måler (jeg har 3-fase), og det fungerte ikke av seg selv. Jeg har berensede debug-muligheter foreløpig, men jeg får ut ListSize 17 (desimal).

De to listene vi har definert i dag er hhv 0x19 (25) og 0x23 (35). Om vi fjerner spenning og strøm på L2 og L3 blir det fire elementer og fire til for OBIS kodene, dvs. 8 til sammen. 25-8 = 17. Føler vi er inne på gjetting-basert-programmering her nå, men det er kanskje verdt et forsøk å legge inn to nye lister på Kamstrup for disse og se om det funker?

Sånn røfflig noe slik:

enum class Kamstrup
{
    List1 = 0x19,
    List2 = 0x23,
    List3 = 0x11,
    List4 = 0x1B
};

enum class Kamstrup_List1
(...)

enum class Kamstrup_List2
(...)


enum class Kamstrup_List3
{
    ListSize,
    ListVersionIdentifier,
    MeterID_OBIS,
    MeterID,
    MeterType_OBIS,
    MeterType,
    ActiveImportPower_OBIS,
    ActiveImportPower,
    ActiveExportPower_OBIS,
    ActiveExportPower,
    ReactiveImportPower_OBIS,
    ReactiveImportPower,
    ReactiveExportPower_OBIS,
    ReactiveExportPower,
    CurrentL1_OBIS,
    CurrentL1,
    VoltageL1_OBIS,
    VoltageL1
};

enum class Kamstrup_List4
{
    ListSize,
    ListVersionIdentifier,
    MeterID_OBIS,
    MeterID,
    MeterType_OBIS,
    MeterType,
    ActiveImportPower_OBIS,
    ActiveImportPower,
    ActiveExportPower_OBIS,
    ActiveExportPower,
    ReactiveImportPower_OBIS,
    ReactiveImportPower,
    ReactiveExportPower_OBIS,
    ReactiveExportPower,
    CurrentL1_OBIS,
    CurrentL1,
    VoltageL1_OBIS,
    VoltageL1,
    MeterClock_OBIS,
    MeterClock,
    CumulativeActiveImportEnergy_OBIS,
    CumulativeActiveImportEnergy,
    CumulativeActiveExportEnergy_OBIS,
    CumulativeActiveExportEnergy,
    CumulativeReactiveImportEnergy_OBIS,
    CumulativeReactiveImportEnergy,
    CumulativeReactiveExportEnergy_OBIS,
    CumulativeReactiveExportEnergy
};

14 hours ago, emyr said:

men jeg får bare ut "Kamstrup v0001"

Syntes ikke dette så helt galt ut... Riktig at du mangler en E7 for avslutting, men ta en kikk på disse to sidene for å se om du ikke også har målerdata innimellom alt annet hos deg:

https://github.com/roarfred/AmsToMqttBridge/tree/master/Samples/Kamstrup

https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md

24 minutes ago, nilsanmy said:

Eg er veldig interessert i å lage ein maken modul som deg @roarfred. Eg ser for meg å få hjelp av kyndige personer.

Kva komponenter må eg handle inn?

Dette er nok riktig sted å begynne da: https://github.com/roarfred/AmsToMqttBridge/tree/master/Electrical/HAN_ESP_TSS721

Her finnes også komponentliste med direkte linker til digikey. ESP er mulig ikke tilgjengelig her, men kan finnes på eks. ebay, banggood, aliexpress, kjell&co el.l. til en billig penge

PS: Merk at det også finnes ferdige moduler å få kjøpt om du heller ønsker det, se evt. tråden "The easy way": 

Ser de forer en Raspberry Pi med denne. Hvis du vil ha kablet ethernet, så er det ikke noe dårlig alternativ å kjøre en sånn mbus konverter rett inn på en I/O pinne eller inn på USB på en Pi. Heller ikke prismessig... 

1 hour ago, Thomas said:

Dette kan jeg lite om, så du får beklage hvis det er et dumt spørsmål. Men det hadde vært fint med en som hadde 2 rj45. 1 for HAN og en for kablet nett og helst med poe. Er det mulig ?

Ingen dumme spørsmål!

Utfordringen i dette tilfellet er at kretsen baserer seg på en ESP8266 der en får en liten arduino med WiFi for 3-4 dollar. I de fleste tilfeller er det kanskje også mer tilgang på strøm enn fast ethernet i sikringsskapet, men her er jo det litt forskjeller på hvordan bygg er oppført. En tanke kan også være å patche HAN kontakten over til et sted der en kan plassere denne måleren innenfor trygge omgivelser og WiFi dekning (altså, ta HAN signalet ut av skapet heller enn å ta ethernet inn)

Hva tenkte du var største utfordring med WiFi framfor kablet nett? Stabilitet, dekning eller annet?

3 hours ago, Bullhill said:

Hvordan løste du det med å gi boksen strøm i sikringskapet @roarfred?

Jeg løste det ikke ? hos meg er det et svakstrømskap rett under, så der kan jeg borre meg gjennom. Men, beste tipset var kanskje ringetrafoen eller en din montert stikkontakt. Din montert usb uttak lette jeg litt etter, det hadde kanskje vært mest fancy, men jeg kunne ikke finne noe slik

Jeg har stort sett brukt ESP12E eller F. Bør koste rundt en tjuekroning: https://m.banggood.com/10Pcs-ESP8266-ESP-12F-Remote-Serial-Port-WIFI-Transceiver-Wireless-Module-p-1067471.html?rmmds=search

On 3/21/2018 at 23:44, roarfred said:

 

Som en artig kuriositet, AMS måleren min rapporterer tidvis 0V på L2.

Mitt lokale e-lag etterforsket dette litt og kom med følgende forklaring: (sannsynligvis er da spenningen alltid 0V på L2 hos meg)

Quote

I IT-nett blir energien henta ut mellom fasane L1-L2, L1-L3 og L2-L3. Og det er rett som kunden seier – det er 230V spenning mellom alle desse. Koplinga blir omtala som «trekant» eller «delta» (https://no.wikipedia.org/wiki/Trefase). Reint måleteknisk blir desse trefase installasjonane målt ved hjelp av «to wattmeter» metoden (https://etrical.blogspot.no/2016/05/measurement-three-phase-power-two-wattmeter-method.html). Det betyr at den eine fasen blir nytta som referanse (eller null-punkt om du vil). I våre målarar er dette fase L2. For spenning vil målaren altså gi måling på (L1-L2) for L1, (L2-L2) for L2 og (L3-L2) for L3. L2-L2 vil alltid vera 0, og difor får du dette talet ut. I eit TN distribusjonsnett finst det i tillegg ein nøytralleiar N. For måling er det denne som blir referanse, og spenningane blir såleis (L1-N), (L2-N) og (L3-N). Det er også rett som kunden observerer, at me måler straum på alle fasar.

4 minutes ago, skagmo said:

Hei. Ny her jeg også. Fint forum!

Fikk Aidon-måler fra Hafslund selv i går. Har fått koblet opp et interface og kikket litt på rådataene. Jeg får pakker på 79-82 byte, ca. hvert minutt. Samme baud-rate som deg. Jeg får derimot ikke serienummer. Mye tyder på at meldingene er SLIP-kodet, da de alltid slutter på 0xc0. Enda mer mistenksomt når en av de lengre meldingene inneholder en 0xdb etterfulgt av 0xdd (frame escape og transposed frame escape). Ved å anta little endian er det mange felt som gir mening som uint16. Fortsetter å undersøke.
 

Tre tilfeldige meldinger:

 

Tolkning av de siste 18 bytene i den siste meldingen:
ff08: 0x08ff = 2303. 230,3 V?
1509: 0x0915 = 2325. 232,5 V?
1309: 0x0913 = 2323. 232,3 V?
b6000000a300: ?
8713: 0x1387 = 4999. 49,99 Hz?
03: ?
8f4a: Varerier mye mellom hver melding. Sjekksum?
c0: Slutt på melding. SLIP frame end?

 

 

 

Spennende! 

Min umiddelbare reaksjon var at baud rate måtte være feil, men at dere leser ut spenning, frekvens og kanskje en sjekksum her sannsynliggjør at det likevel stemmer. Det som er sikkert er at dette ikke er DLMS data, da skulle alle pakker startet og sluttet med e7.

Så spørsmålet er om det er en helt annen firmware som var lagt inn initielt på disse målerne. Og, kan den reverse engineeres før det deployes ny firmware til Aidon?

Et lite tips ang checksum, det finnes en site her som kan hjelpe dekode, der det kjøres en lang rekke kjente checksum algoritmer på en valgfri datakilde. Se om du finner treff her: http://crccalc.com

3 hours ago, ArnieO said:

man kan jo se for seg at noen piggyback-kobler seg imellom og sender samme data til en annen mottaker

Eller hiver på en clamp rundt en av fasene, eller leser av IR måleren... Har du fysisk tilgang så klarer jeg ikke se hva du kan utrette av ekstra sikkerhet med kryptering på HAN (med de dataene som finnes der nå da). Fra avleseren må ting selvfølgelig være kryptert WiFi.

Flere som har Kaifa måler? Er de levert forseglet? Ser i brukermanualen at det skal være totalt 8 forseglinger, men hos meg er det kun forseglinger i skruene til venstre. Dvs. deksel til M-bus er åpent... og rekkeklemmer og moduldeksel har forsegling i en av to skruer.

14 minutes ago, Odd said:

 

Dette var fin lesing for meg med to M-Bus slaver i teknisk rom
Får følge med når montøren kommer og be han kople de på.

 

Denne er spennende! Her snakker vi direkte tilkobling til den ekte M-Bus (bak det lille dekselet på Kaifa måleren) og ikke data fra HAN porten?

15 minutes ago, Odd said:

@roarfred det er kritikk mot NVE på at de ikke har klart å alle leverandørene til å levere på en standard enda.
Det har gått 6-7 år, og enda klarer ikke alle leverandørene å få ut en streng som er lik.

Enig i at de burde kjørt hardt på en spesifikk output fra måleren. Litt usikker på om tidsgrensen de har satt for implementasjon er urimelig for noen...

5 minutes ago, Odd said:

Så vidt jeg vet er ikke dette på plass enda.

Tror vi kan skrive under på at det ikke er noe sentralt system eller en gang samme behandling av de som ønsker HAN porten åpnet. Merket meg at min henvendelse om åpning gikk fra Etne E-lag, til Valider, hvor de hadde en tekniker som fikset biffen. Valider var (er?) de som har/hadde kontroll på utrulling av Kaifa målere...

Virker på meg som at det er veldig liten samkjøring på både formater og prosedyrer, og når det kommer til "sikring" av dataene så begynner det hele å bli en vits.

Tror egentlig leverandørene har snakket sammen og samarbeidet, selv om det ikke er helt offisielt. Kanskje det mest spennende blir om Aidon deployer ut en løsning med 09-buggen

Jeg ser folk klager litt på AMS målere, noen pga. den enorme strålingen og noen fordi strømforbruket har gått opp. Hvis en skal mene noe om dette, så burde det kanskje være at det vil være en kostnad med installasjon, og at vi som forbrukere til slutt er de som betaler for gildet. Spørsmålet er så om dette med direkte tilgang til egne data kan go noen gevinst. Egentlig litt skeptisk til dette, men poster her en kurve av mitt eget forbruk. (Jeg fikk ny AMS måler montert i september 2017, tror det stemmer godt med starten på denne tråden) Nå skal det sies at jeg ikke har vært flink til å lese av, så det er mye stipulering, men innimellom har jeg rapportert inn. Det mystiske er at jeg har betydelig lavere forbruk sammenlagt nå. Litt obs er jeg jo, siden jeg har hatt "litt over gjennomsnittet fokus" på strøm siste halvåret, men har liksom ikke gått i dvale heller...

Som en artig kuriositet, AMS måleren min rapporterer tidvis 0V på L2. Den kan gjerne ha strøm på alle tre faser, men mangle spenning på L2. Dette så jeg da jeg dekodet sample data i fjor høst, og så det igjen nå. Kan jo være jeg har trukket vinnerloddet, men skal driste meg til å spørre mitt lokale e-lag om det kan ha noe å si...

40 minutes ago, Odd said:

Det som bekymrer meg er ordlyden i all dokumentasjonen,

Amen!

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...

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.

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, 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)

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.

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)

1 hour ago, Ravn said:

Angående han->esp interfacet. Har du sett på å drive hele kortet fra m-busen, istedenfor egen tilførsel via usb?

Ja, utfordringen ligger i svært ulik spec på hvilken belastning. Tror Kamstrup kommer dårligst ut med 144mW. Med ZWave eller Zigbee ville det vært enklere, men ESP8266 er nokså kravstor her. Vet du noe om ESP32 er noe bedre her?