Gå til innhold
  • Bli medlem
roarfred

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

Anbefalte innlegg

Ja, du har rett i at det blir litt fikling for å treffe rette spenninger. Og det man kommer frem til vil ikke nødvendigvis funke for et annet FTDI interface.

Men den kretsen du peker til vil jo ha omtrent samme problemet. Ialfall om man bruker de komponentverdiene som er angitt.

 

Akkurat nå har jeg ikke tid til å mekke interface, men når jeg får aktivisert interfacet vil nok prioriteten heves.

Komparatorer har jeg i skuffen, og resten bør da være enkelt.

Del dette innlegget


Lenke til innlegg
Del på andre sider
4 minutes ago, Einar said:

Ja, du har rett i at det blir litt fikling for å treffe rette spenninger. Og det man kommer frem til vil ikke nødvendigvis funke for et annet FTDI interface.

Men den kretsen du peker til vil jo ha omtrent samme problemet. Ialfall om man bruker de komponentverdiene som er angitt.

 

Akkurat nå har jeg ikke tid til å mekke interface, men når jeg får aktivisert interfacet vil nok prioriteten heves.

Komparatorer har jeg i skuffen, og resten bør da være enkelt.

Forskjellen blir transistoren. Trikset blir da å få delt ned spenningen slik at 25V/15V havner på hver sin side av 0.6V, slik at en får utnyttet at transistoren kan sperre/lede. Ser jo nå at den kretsen jeg linket til også inverterer slik min aller første skisse gjorde. Er ikke 100% sikker på om det skulle ha noe å bety eller ikke. (Denne er lagt ut som et forslag til en RS232 <> TTL shifter)

 

Men, aller best hvis noen har tilgang til litt komponenter, et oscilloscope el.l. og får koblet opp noe som fungerer for en spesifikk måler. Da kan vi dokumentere litt etter hvert, og forhåpentligvis komme fram til en krets som fungerer for alle.

Del dette innlegget


Lenke til innlegg
Del på andre sider
On 15.9.2017 at 10:01, roarfred said:

Hvis noen har Aidon eller Kamstrup måler, så er jeg svært interessert i å få ut test-data fra disse. Kan gjerne assistere med måling, elektronikk etc...

Har Aidon fra Hafslund.

 

Har også div nodeMCU, Arduino og et lass med div komponenter. 

Del dette innlegget


Lenke til innlegg
Del på andre sider
4 minutes ago, Gjelsvik said:

Har Aidon fra Hafslund.

 

Har også div nodeMCU, Arduino og et lass med div komponenter. 

Supert!

 

Se også litt mer info i diskusjonen her:

 

Først må du få åpnet HAN porten hos deg. Det skal din nettleverandør kunne gjøre på forespørsel.

Det kunne vært interessant å målt litt på porten før den åpnes. Etter all sannsynlighet har du ca. 25V likespenning mellom pinne 1 og 2 (2 = GND, 1=signal). Etter åpning bør det strømme ut data, hvert 2. sekund. Disse dataene er modulert slik at de gir ca. 12V lavere spenning for en "0" og ca 25V for en "1". Jeg har lagt ut en skisse som fungerer (hos meg) for konvertering til 3.3V TTL nivå her: https://github.com/roarfred/AmsToMqttBridge

 

Kommer du så langt at du får lest ut data, så ligger det noen detaljer om hva som skal være med i de tre ulike data-pakkene fra Aidon her:

https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/NVE_Info_kunder_HANgrensesnitt.pdf

 

Gi en lyd hvordan det går!

Del dette innlegget


Lenke til innlegg
Del på andre sider

Ikke sikker på om jeg skjønner alle tegnene på tegningen din.

Kunne du satt opp en liste, så skal jeg se om jeg har det jeg trenger?

Basicly slik?  HAN#2 til GND og HAN#1 pin RX, (etter at spenningen er dratt ned) 

Er det da vanlig Serial.Read() man kan bruke mot en pinne på f.eks arduino?

 

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
17 minutes ago, Gjelsvik said:

Ikke sikker på om jeg skjønner alle tegnene på tegningen din.

Kunne du satt opp en liste, så skal jeg se om jeg har det jeg trenger?

Basicly slik?  HAN#2 til GND og HAN#1 pin RX, (etter at spenningen er dratt ned) 

Er det da vanlig Serial.Read() man kan bruke mot en pinne på f.eks arduino?

 

 

 

Mulig det kan hjelpe å se på koblingen på bread-board?

Serial.Read() vil lese en byte fra serie-porten på Arduino. Merk at porten må settes opp med 2400 baud, 8 data-bit, Even parity og 1 stop bit. (8E1)

Du kan finne eksempler på kode til windows og til arduino (ESP8266) her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Code

Her viser også et annet bilde av breadboard, som mulig viser bedre koblingene.

 

Edit: Skal se om jeg får laget en skisse vha. Fritzing senere: http://fritzing.org/

Endret av roarfred

Del dette innlegget


Lenke til innlegg
Del på andre sider

Jo har sett på de tegningene, koblingene går hetl fint, det er noen av komponentene jeg ikke er helt med på.. F.eks de diodene du har merket med 12V og 3.9V som har en "vinkel" på den rette streken, det er nytt for meg.

 

Jeg har noen npn transistorer fra tidligere prosjekter, men de er ikke nøyaktig samme (bc337)

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
2 hours ago, Moskus said:

Det er slik det skal være, de er pålagt det av NVE.

 

Som du sier er problemet å få snakket med noe som faktisk forstår hva du spør etter. Jeg gruer meg til jeg skal ta denne debatten med Lyse... :( 

Du får ikke hjelp av Lyse.

Du må snakke med Lyse Elnett på 51908079

Del dette innlegget


Lenke til innlegg
Del på andre sider
16 minutes ago, Gjelsvik said:

Jo har sett på de tegningene, koblingene går hetl fint, det er noen av komponentene jeg ikke er helt med på.. F.eks de diodene du har merket med 12V og 3.9V som har en "vinkel" på den rette streken, det er nytt for meg.

 

Jeg har noen npn transistorer fra tidligere prosjekter, men de er ikke nøyaktig samme (bc337)

 

ok :) Diodene med en vinkel på er zener-dioder. Disse fungerer likt som en diode i ene retningen, men så har de en karakteristikk som gjør at de begynner å lede på en gitt spenning i motsatt retning. Effekten er at en får et spenningsfall over, og du kan se på det som at du subtraherer en gitt spenning. Som du kanskje forstår har hver slik diode en gitt oppgitt verdi i antall volt som skal til før den leder. Mer her: https://en.wikipedia.org/wiki/Zener_diode

 

Hvis du har betegnelsen på din transistor(er) kan jeg godt sjekke om den kan være egnet.

 

Et alternativ kan også være den forenklede kretsen som ble postet tidligere i denne tråden. Se her: https://www.dd-wrt.com/wiki/index.php/Image:LaFonera_Hardware_Serial-Cable-Port_11_simple_schematic.jpg

 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skal se om jeg finner ut hva som står på de.

 

Den forenkla kretsen så jo en del enklere ut ja.

Det er vel bare den øverste der vi trenger? Kjører ikke toveis.kom mot HAN?

 

Så, dette er alt man trenger?

 

2x 1k ohm motstand

1x 2k2 ohm motstand.

1x NPN 2n2222

 

Ikke noen kondensatorer eller zenerdioder?

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 hour ago, Gjelsvik said:

Skal se om jeg finner ut hva som står på de.

 

Den forenkla kretsen så jo en del enklere ut ja.

Det er vel bare den øverste der vi trenger? Kjører ikke toveis.kom mot HAN?

 

Så, dette er alt man trenger?

 

2x 1k ohm motstand

1x 2k2 ohm motstand.

1x NPN 2n2222

 

Ikke noen kondensatorer eller zenerdioder?

 

 

Det skal stemme, men merk at motstandsverdier på inngangen sannsynligvis må justeres litt. Forholdet mellom de to bør være ca. 1:20, så jeg ville prøvd med 22k og 1k (dvs. bytt den på 2k2 med 22k). Du kan fint prøve deg frem etterpå, ved å sette 25V og 15V på inngangen. Disse skal da gi ut 0V og 5V.

 

PS: Merk at dette ikke er helt bulletproof ettersom kretsen vil invertere signalet. Hvis så er tilfellet så kan en inn med en ekstra motstand på emitter og så ta ut spenningen over denne.

 

Edit:

I følge disse postene, så

1) Er det viktig å ha rett "Polaritet" på signalet, dvs. at det betyr noe om det er invertert eller ikke. For HAN må det derfor ikke inverteres: http://forum.arduino.cc/index.php?topic=11955.0

2) En "Idle" state på TTL er 5V. Denne er også en logisk "1": https://www.sparkfun.com/tutorials/215

 

Dette betyr således at en må lage en krets som er ikke-inverterende. Den helt enkleste måten er nok å legge på et ekstra inverterende trinn bakom... 

Endret av roarfred

Del dette innlegget


Lenke til innlegg
Del på andre sider

Fikk svar fra Hafslund nå, om at de ikke vil aktivere HAN før senest tredje kvartal 2018, dette fordi myndighetene ikke har bestemt seg for protokoll(?)

 

Quote

Hei!

HAN-kontakten (RJ45-kontakt) inneholder foreløpig ikke noen forbruksdata, men vil bli forsynt med forbruksdata så snart myndigheten har bestemt seg for en standard protokoll, anslått til 3. kvartal 2018. Kunder som ønsker data strømmet over målerens HAN-kontakt (RJ45-kontakt) må ta kontakt med oss for å få dette slått på, men først etter 3.kvartal 2018.   
Utstyr som skal installeres via HAN-kontakten, leveres av tredjepartleverandører, og ikke direkte fra Hafslund Nett, men ikke før i 3. kvartal 2018.

Ta gjerne kontakt dersom du har flere spørsmål.


Ha en fin dag!

Med vennlig hilsen
Hafslund Nett AS

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
20 minutter siden, Gjelsvik skrev:

Fikk svar fra Hafslund nå, om at de ikke vil aktivere HAN før senest tredje kvartal 2018, dette fordi myndighetene ikke har bestemt seg for protokoll(?)

 

 

 

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

 

Står klart M-Bus som protokoll.

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 hour ago, Gjelsvik said:

Fikk svar fra Hafslund nå, om at de ikke vil aktivere HAN før senest tredje kvartal 2018, dette fordi myndighetene ikke har bestemt seg for protokoll(?)

 

 

Hm, jeg prøver å spore litt opp i dette. Har en forespørsel inne til mitt lokale e-lag, ang formatet/protokollen fra Kaifa måleren. Den ble videresendt til Valider...

Hadde vært interessant å visst hvordan disse har laget utstyret sitt:

https://www.develcoproducts.com/products/meter-interfaces/emi-norwegian-han/

Del dette innlegget


Lenke til innlegg
Del på andre sider

Da har jeg fått kode for tolking av DLSM (tror jeg er riktig å si, men er usikker på om det egentlig er HDLC) til å fungere fra windows og fra ESP8266. Kildekode er oppdatert i de to prosjektene her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Code

 

Arduino koden er modifisert til å kun logge ut data-innholdet (hver gang en pakke er korrekt detektert med start/stop flag og riktig crc). La inn en logg-fil fra noen minutters kjøring nå: 

https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/ESP 20170918 Raw.txt

 

Da er det bare å krysse fingrene for at ikke også Etne E-lag finner på at HAN porten ikke er klar for bruk og stenger den ned igjen hos meg :) 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Om det ikke er HDLC så er det tvillingbroren. HDLC må ikke være synkron selv om den ofte er det.

Hvis grunnen til at du spekulerer på det er om du kan gjenbruke HDLC kode du finner på nettet så kan du nok det. Async/sync forskjellen ligger i L1, mens det vi er interessert i er L2. UART dekoder L1 for oss helt automagisk så protokolldekodingen ikke ser forskjell.

 

Om interfacet er åpent hos deg så skal du bare la bjørnen sove. Som tidligere nevnt skal den ikke være åpen før du spør om det. Og iflg. netteier her så skal det skje skriftlig.

Del dette innlegget


Lenke til innlegg
Del på andre sider

Hei alle!

Disclaimer. Jeg jobber i Hafslund marked, som nå er en del av Fortum! (Strømselskapet, IKKE nettselskapet Hafslund nett)

 

Vi er nå i undersøkelsesporet i forbindelse med et potensielt testprosjekt som går på bruk av akkurat disse dataene. Som personlig hjemmeautomasjonsnerd, er jeg superinteressert i få dette til å fungere, og la folk fritt få bruke dataene til hva man ønsker selv. For å kunne på en enkel og effektiv måte bistå, er jeg veldig nyskjerrig å vite hva slags ambisjoner folk har i forbindelse med dataene.  Som eksempelvis:

1. Hvorfor ønsker man dataene?

2. Hva slags fordeler eller problemer ville man løst dersom man hadde hatt tilgang til de?

3. Hva slags oppløsning bør dataene være i? Type timesverdier, sekundverdier osv.

4. Hvilke muligheter ville kunne det åpnet seg dersom man har tilgang til dataene?

5. Hvis du skulle hatt tilgang til dataene, ville man hatt det via API som man leker med selv, API til favoritt hjemmeautomasjonssystem (eks Telldus), eller som en IOT device? Osv osv.

 

Under følger et par lenker (som kanskje også har vært lenket til i den tidligere tråden).

 

https://www.hafslundnett.no/kunde/veiledning/15554

https://www.aidon.com/nb/aktuelt/beyond-metering-nyhetsbrev/nyhetsbrev-februar-2015/spesifisering-av-ams-maleres-han-port-grensesnitt-a3-foreligger-na-i-form-av-nek-rapport/

 

Dersom vi får noe interesse rundt dette prosjektet vil det være noe vi vil forsøke å få gjennomført så raskt som mulig. En mulig løsning vil være gjennom HAN interfacet. En annen løsning vil være typisk NILM måling med etterjustering etter faktiske målerdata. Målerene sender allerede timesmålinger til nettselskapene, men etter meg bekjent så deles ikke disse med kundene.

 

Til slutt så bare svarer jeg personlig på spørsmålene over.

 

1. Jeg vil ha dataene fordi jeg vil gjøre hva jeg vil med de. Først og fremst er det noe jeg mangler en god løsning på i min eksisterende løsning. Bruker openenergymeeter inntil videre.

2. Jeg er nyskjerrig på om jeg greier å spare penger dersom jeg hadde blitt fakturert etter timesforbruk. Som ved å kun varme opp varmtvannstanken på natta når strømmen er billig.

3. Jo høyere jo bedre, alltid.

4. Samme som nr 2. Men i tillegg kunne jeg justert kanskje andre type enheter/løsninger etter strømpris og evt forbruk.

5. Kunne tenke meg tilgang til dataene direkte via et API, og kanskje noe ferdigløsninger som er enkle og bruke for basic funksjonalitet.

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Dette tror jeg er verd en ny tråd. Men jeg sluker den her med søkke og snøre.

1. Hvorfor ønsker man dataene?

Hvis jeg ser bort fra nerdefaktoren så er det fordi jeg regner med at effektledd er like rundt hjørnet også for oss som ikke har det allerede.

2. Hva slags fordeler eller problemer ville man løst dersom man hadde hatt tilgang til de?

Øker muligheten til å tilpasse forbruket for i størst mulig grad jevne ut forbrukstoppene. Det er vel det de håper på, de som innfører dette? Selv om det bare er et "kjøkkenwattmeter" så vil man kunne bruke det som feedback på om de brytere man skrur på og tidspunktene man gjør det, er fornuftige.

3. Hva slags oppløsning bør dataene være i? Type timesverdier, sekundverdier osv.

En dekade bedre enn oppløsningen i effektledd beregningen.

4. Hvilke muligheter ville kunne det åpnet seg dersom man har tilgang til dataene?

Tilpasse forbruk som jeg like gjerne kan flytte i tid. Elbilen lader jeg om natta, og romtemperatur kan jeg senke om natta. VVB kan jeg styre med en dings. Men i en styringssløyfe er dette bare pådrag. Først når man har en feedback kan man få til en reell styring. Styring basert på antagelser blir aldri bedre enn man er til å gjette.

5. Hvis du skulle hatt tilgang til dataene, ville man hatt det via API som man leker med selv, API til favoritt hjemmeautomasjonssystem (eks Telldus), eller som en IOT device? Osv osv.

Et åpent API. Jeg liker å ha muligheten til å putte fingern i sausen og smake. Uansett vil det bli laget plugin e.l. til systemene om API og hardware er åpent. Men nettselskapene bør gjeninnføre kjøkkenwattmeteret i en eller annen form om dere skal nå flere brukere. Husautomatisering er i dag et nisjemarked.

 

Ehh... Er min input veldig lik din kanskje?

Del dette innlegget


Lenke til innlegg
Del på andre sider

Hei @Marius-H!

 

Jeg håper starten på tråden beskriver litt hva en ønsker å gjøre. Dvs. lage en generell hardware/software som en bridge mot eks. MQTT. Enkel elektronikk og ardiono kode som kan nyttes av hvem som helst. For dette prosjektet sin del er det nok mer at en ønsker å lage en løsning som tilgjengeliggjør dataene, enn at en ønsker dataene selv. (Som du kanskje har sett, så har jeg forsåvidt data fra HAN porten allerede, men vil gjerne lage en mer generell løsning)

 

Kan forsåvidt svare på spørsmålene i rekkefølge også, som "forbruker":

 

1. Ønsker data for å se og analysere eget strømforbruk.

2. Svar på spørsmål som hva koster en klesvask, en dusj etc. Alarm på overforbruk grunnet en ovn som ikke var avskrudd etc. Evt. justering koblet til døgn-diffrensiert prising, men det ser jeg egentlig ikke at denne AMS måleren skal kunne hjelpe så mye med

3. Oppløsning trodde jeg nesten var bestemt, men mer og hyppigere data er bedre. Helt klart at en med høy oppløsning kunne drevet litt mønster-gjenkjenning, og detektert ulike apparater (i det minste de mest strømkrevende)

4. Se 2) og 3)

5. I prinsippet ikke viktig, men ser ikke noen fordeler med at dataene skal forlate huset for så å hentes inn igjen. Et API er fint, MQTT er bra det også, og arduino-bibliotek er helt greit. Poenget mitt er at det er viktigere med en åpen og veldokumentert standard, enn selve standarden i seg selv. (Dette prosjektet har til nå vært basert på kvalifisert gjetning, men jeg begynner etterhvert å forstå hvorfor)

 

Har du ellers noen formening eller info om hvilke steg det egenglig er som gjenstår før det er enighet om HAN portens protokoll? Slik jeg forstår det har NEK gitt sin anbefaling til NVE sin velsignelse, tilbake i 2015... Men så sies det fra Hafslund at det ikke er enighet...

 

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
6 timer siden, roarfred skrev:

Hmm, kom over denne nå: https://www.nve.no/stromkunde/smarte-strommalere-ams/

 

 

Sier NVE (skrevet i 2015, men oppdatert i august i år) uten så mye mer forklaring...

 

Jeg vil anta at det er fordi firmwaren på enkelte målere ikke støtter dette enda og det tar lang til å få dette på plass.

Del dette innlegget


Lenke til innlegg
Del på andre sider
10 timer siden, Marius-H skrev:

1. Hvorfor ønsker man dataene?

Dette er vel kanskje det mest innlysende. For å følge med på sitt eget forbruk, og å styre huset etter.

Jo mer data, jo smartere hus kan man ha.

 

10 timer siden, Marius-H skrev:

2. Hva slags fordeler eller problemer ville man løst dersom man hadde hatt tilgang til de?

Ikke skriv "dersom", skriv" når". ;)

Jeg ville sluppet en ekstern avleser (siden jeg leser av forbruket allerede), og den nye måleren vil sannsynligvis ha mindre feilkilder (forhåpentligvis), samt avlesing av effektledd (som nevnt av andre).

 

10 timer siden, Marius-H skrev:

3. Hva slags oppløsning bør dataene være i? Type timesverdier, sekundverdier osv.

Hvor mange kan vi få? Hvis kun én, så er det lavest mulig oppløsning som gjelder, så kan det eksterne systemet ta seg av matematikken.

 

10 timer siden, Marius-H skrev:

4. Hvilke muligheter ville kunne det åpnet seg dersom man har tilgang til dataene?

Alene er det ikke så spennende. Men når man vet hvordan forbruket sitt er, kan man bruke historiske forbruksdata og den sannsynlige strømprisen de neste 5, 12 eller 24 timer til å vurdere når det er billigst å gjøre enkelte ting.

 

Klesvask er nevnt, men å vaske klær eller kjøre tørketrommel om natta anbefales selvfølgelig ikke på grunn av brannfaren.

 

 

10 timer siden, Marius-H skrev:

5. Hvis du skulle hatt tilgang til dataene, ville man hatt det via API som man leker med selv, API til favoritt hjemmeautomasjonssystem (eks Telldus), eller som en IOT device? Osv osv.

Det er avhengig av hvor enkelt du kan gjøre det. Personlig ønsker jeg meg en dings som du kobler i M-BUS-porten og som spyr ut ferdig tygde data enten via f.eks Z-wave (som stort sett alle seriøse hjemmeautomasjonssystemer støtter) eller via HTTP eller MQTT. Det er allerede nok av APIer som må settes opp for å få jobben gjort. Jeg vil ha det enklest mulig.

 

Vi vil tross alt gjøre dette tilgjengelig for folk flest, det er jo det hele AMS-innføringen går på: Fordele strømforbruket.

Man får jo egentlig ingen gevinst med AMS hvis folk ikke bruker systemet, og det kommer ikke folk til å gjøre automatisk.

 

Altså trenger de så smått litt hjemmeautomasjon. Og da handler det ikke om å skrive en halv kilometer kode for å få det inn i systemet, da skal det helst være plug'n'play.

 

 

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

1: For å ha best mulig oversikt på strømforbruket over tid. Jeg har allerede logget mitt forbruk siden 2008, via puls utgangen.
Vokste opp med kjøkkenwattmeter. Det savner jeg, har derfor laget mitt eget. 

2: Jeg vil ha god oversikt over hva som bruker strøm og når. Kan f.eks sjekke at termostatene fungerer, noe de ikke alltid gjør.

3: Har nå display av effekt for hver puls, og lagrer snitt hvert minutt. 2-sekunder intervall som foreslått er helt OK.

4: Forbedring av eksisterende system, telling av pulser er ikke er helt nøyaktig.

5: Vil ha direkte tilgang til data og leke med de selv.

 

Eksempel på mitt forbruk sist Lørdag: Blå er strøm, oransje er utetemperatur, grønn er atmosfærisk lufttrykk. Brukte ca 38 kWh denne dagen.

  • Grunnforbruk ligger på ca 1 kW. Noen PCer, lys, etc.
  • De små toppene, mest synlig på natten, er luft-luft varmepumpen.
  • De noe større toppene er varmekabel på badet.
  • Enda større topper 4-5 ganger om dagen er varmtvann.
  • 10:00 er det vaskemaskin, 15:30 tørketrommel.

59c0cff158f42_PowerMonitor2017A.thumb.PNG.162d9de48d976919f157860d19fef584.PNG

  • Like 3

Del dette innlegget


Lenke til innlegg
Del på andre sider

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Fjern formatering

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.


  • Lignende innhold

    • Av Preben
      Hei,
       
      Har mekka litt for å få HAN-data fra Kamstrup-måleren min (1-fas) inn i Home Assistant.
       
      Bruker ESPHome med en ESP32 for å få inn data, forsøkte med en ESP8266, men den var ikke helt glad i software serieport, derfor måtte jeg ty til 32'en.
       
      Koden er ganske stygg foreløpig, men kanskje det kan hjelpe noen andre på vei:)
       
      Parser dataen ved å lese ut OBIS-koder og så hente tilknyttede data. Ingen CRC-sjekk e.l. da dingsen min ikke ser ut til å lese korrupte data i det hele tatt så langt.
       
      Har lånt en del inspirasjon fra RoarFreds HAN-leser, selv om jeg endte opp med noe ganske annerledes etterhvert:)
       
      ESPHome-konfigurasjonsfil:
      esphome: name: ams platform: ESP32 board: nodemcu-32s includes: mbus.h wifi: power_save_mode: light networks: - ssid: "LulzNettOppe" password: ##PASSORD## - ssid: "LulzNettEkstra" password: ##PASSORD## - ssid: "LulzNett" password: ##PASSORD## # Enable logging logger: level: DEBUG # Enable Home Assistant API api: ota: uart: id: uart_bus tx_pin: GPIO17 rx_pin: GPIO16 baud_rate: 2400 # Example configuration entry dallas: - pin: GPIO25 sensor: - platform: dallas address: 0xEA0214808622FF28 name: "Temperature Sikringsskap" - platform: custom lambda: |- auto mbus_reader = new MbusReader(id(uart_bus)); App.register_component(mbus_reader); return {mbus_reader->wattage_sensor, mbus_reader->reactive_power_sensor, mbus_reader->amperage_sensor, mbus_reader->voltage_sensor, mbus_reader->energy_sensor, mbus_reader->reactive_energy_sensor}; sensors: - name: "AMS Wattage" unit_of_measurement: kW accuracy_decimals: 3 filters: - multiply: 0.001 - name: "AMS Reactive Power" unit_of_measurement: VAr accuracy_decimals: 0 internal: true - name: "AMS Amperage" unit_of_measurement: A accuracy_decimals: 2 filters: - multiply: 0.01 - name: "AMS Voltage" unit_of_measurement: V accuracy_decimals: 0 - name: "AMS Hourly Energy" unit_of_measurement: kWh accuracy_decimals: 3 filters: - multiply: 0.01 - name: "AMS Hourly Reactive Energy" unit_of_measurement: kVArh accuracy_decimals: 3 internal: true filters: - multiply: 0.01 mbus.h:
      #include "esphome.h" class MbusReader : public Component, public uart::UARTDevice, public Sensor { public: MbusReader(uart::UARTComponent *parent) : uart::UARTDevice(parent) {} uint8_t temp_byte = 0; uint8_t *temp_byte_pointer = &temp_byte; uint8_t uart_buffer_[512]{0}; uint16_t uart_counter = 0; char uart_message[550]; char temp_string[10]; char obis_code[32]; char temp_obis[10]; uint32_t obis_value = 0; float wattage = 0; float amperage = 0; float voltage = 0; float energy = 0; Sensor *wattage_sensor = new Sensor(); Sensor *amperage_sensor = new Sensor(); Sensor *voltage_sensor = new Sensor(); Sensor *energy_sensor = new Sensor(); Sensor *reactive_power_sensor = new Sensor(); Sensor *reactive_energy_sensor = new Sensor(); void setup() override { } void loop() override { bool have_message = read_message(); } bool read_message() { while(available() >= 1) { read_byte(this->temp_byte_pointer); if(temp_byte == 126) { if(uart_counter > 2) { uart_buffer_[uart_counter] = temp_byte; uart_counter++; uart_message[0] = '\0'; strcpy(uart_message, ""); for (uint16_t i = 0; i < uart_counter && i < 256; i++) { //sprintf(temp_string, "%02X", uart_buffer_[i]); //strncat(uart_message, temp_string, 2); if(uart_buffer_[i-1] == 9 && uart_buffer_[i] == 6) { obis_code[0] = '\0'; strcpy(obis_code, ""); for (uint16_t y = 1; y < 6; y++) { sprintf(temp_obis, "%d.", uart_buffer_[i + y]); strcat(obis_code, temp_obis); } sprintf(temp_obis, "%d", uart_buffer_[i + 6]); strcat(obis_code, temp_obis); ESP_LOGV("uart", "OBIS code found: %s message length: %d", obis_code, uart_buffer_[i + 7]); obis_value = 0; if(uart_buffer_[i + 7] == 6) { for(uint8_t y = 0; y < 4; y++) { obis_value += (long)uart_buffer_[i + 8 + y] << ((3-y) * 8); } } else if(uart_buffer_[i + 7] == 18) { for(uint8_t y = 0; y < 2; y++) { obis_value += (long)uart_buffer_[i + 8 + y] << ((1-y) * 8); } } if(strcmp(obis_code, "1.1.1.7.0.255") == 0) { ESP_LOGV("uart", "Wattage: %d", obis_value); wattage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.31.7.0.255") == 0) { ESP_LOGV("uart", "Amperage: %d", obis_value); amperage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.32.7.0.255") == 0) { ESP_LOGV("uart", "Voltage: %d", obis_value); voltage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.1.8.0.255") == 0) { ESP_LOGV("uart", "Energy Usage Last Hour: %d", obis_value); energy_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.4.7.0.255") == 0) { ESP_LOGV("uart", "Reactive Power: %d", obis_value); reactive_power_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.4.8.0.255") == 0) { ESP_LOGV("uart", "Reactive Power Last Hour: %d", obis_value); reactive_energy_sensor->publish_state(obis_value); } else { ESP_LOGV("uart", "Unknown OBIS %s, value: %d", obis_code, obis_value); } } //strncat(uart_message, " ", 1); } ESP_LOGV("uart", "%d length received", uart_counter); //ESP_LOGI("uart", "%d length received: %s", uart_counter, uart_message); ESP_LOGV("uart", "Message length: %d", uart_message[3]); uart_counter = 0; uart_message[0] = '\0'; strcpy(uart_message, ""); } else { uart_counter = 0; } } uart_buffer_[uart_counter] = temp_byte; uart_counter++; } return false; } };  
    • Av Robin Smidsrød
      Hei alle sammen!
       
      Etter at jeg har lest gjennom en del poster på forumet her rundt lesing/dekoding av data fra AMS HAN-porten har jeg begynt å lure på hvor sensitiv målepunkt-ID-en er. Hvis man kobler den sammen med navn på abonnent og adresse er det sannsynligvis relativt sensitivt, men hvis den står alene i en binærdump, hvor mye skade kan en ondsinnet person gjøre hvis de har kjennskap til en målepunkt-ID?
       
      Grunnen til at jeg spør er fordi jeg har laget en dekoder[1], og jeg tenkte at det kunne være nyttig å legge ved eksempler på dump-filer fra forskjellige målere. Men hvis kjennskap til målepunkt-ID kan brukes til noe (f.eks. bestille eller avslutte tjenester som koster penger) uten å kjenne navnet på abonnenten tenker jeg at de ikke burde gjøres tilgjengelig på internett.
       
      Jeg leste et eller annet sted at NVE sammenligner målepunkt-ID med personnummer, og skatteetaten sier at personnummer ikke er sensitivt, men det er personopplysninger. Folk flest gir ikke fra seg personnummeret sitt til hvem som helst som spør om det, selv om skatteetaten sier som over.
       
      Jeg vet at målepunkt-ID består av landskode, kraftverk-ID, løpenummer og kontrollsiffer, som i seg selv ikke kan identifisere brukeren direkte.
       
      Så i bunn og grunn, hvis man har en målepunkt-ID, hva kan man gjøre med den?
       
      1: https://github.com/robinsmidsrod/ams-han-decoder
    • Av Torbjørn
      Da har jeg fått installert det meste på en litt eldre raspberry.
      Koblet til USB-MBUS slave modul, følgt guiden jeg fant her til å sette opp influxdb, grafana og node-red.
      Når jeg kjører test_rx fila i han-port mappa får jeg dette:
      root@raspberrypi:/home/pi/src/han-port# ./test_rx num args: 1 read serial: 1 read socket: 0 read file: 0 write file: 1 serial_device: /dev/ttyUSB0 fname: empty key: host: undefined port num: 10001 decrypt: 0 open_serial OK: 4 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 c8 02 02 0f 00 16 1b e8 a5 7e Date Time: , Items: 0 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 c8 02 02 0f 00 16 1b e8 a5 7e Date Time: , Items: 0 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 cc 02 02 0f 00 16 1b 9e ca 7e Date Time: , Items: 0 Leste i en annen trår her at på Aidon måler fungerer et python script til å gjøre samme jobb.
      Men her fikk jeg ikke helt rette verdier tror jeg:
      ./aidon_test.py /dev/ttyUSB0 {'p_act_in': 1046} {'p_act_in': 1036} {'p_act_in': 1032} {'p_act_in': 1032} {'p_act_in': 1052} {'p_act_in': 1040} {'p_act_in': 1040} {'p_act_in': 1050} {'p_act_in': 1050} {'p_act_in': 1066} {'p_act_in': 1076} {'p_act_in': 1052} {'p_act_in': 1052} {'p_act_in': 1062} I node-red står det bare å blinker "connecting" under alle AMS boksene.
       
       
      Noen som har fått til Aidon målerene som Lyse bruker, som kan hjelpe litt?
    • Av roy
      Jeg har en Kamstrup AMS fra Norgesnett med åpen HAN-port. For å lese disse DLMS OBIS datapush-meldingene har jeg en USB-til-MBUS-slave-modul koblet til en Raspberry Pi. Jeg skrev noen få linjer med Python for å skrive ut meldingene som kommer, og dette ser i utgangspunktet ut til å fungere stabilt og som forventet.
       
      Det jeg lurer på er om noen kan hjelpe meg å tyde/forklare meldingene til meg, fordi de later til å være mye kortere (145-160 bytes) enn det jeg har sett eksempler på her på forumene. Etter å ha lest hundrevis av meldinger og side opp og side ned her inne + lest kode og eksempeldata på spesielt https://github.com/roarfred/AmsToMqttBridge/ så skjønner jeg bare ikke hva det er med meldingene jeg får.
       
      Meldingene kommer hvert 10. sekund som forventet, og hver time kommer det en bittelitt lenger melding (den også mye kortere enn forventet). Det er som om OBIS-kodene ikke er med i meldingene.
       
      Start og slutt med byten E7 er alltid til stede og CRC for hvertfall header har stemt de gangene jeg har sjekket den.
       
      Her er eksempler på noen meldinger jeg får:
      2019-01-20T21:50:11.195980 - 155 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFBFE06C006E006F089C7FE74080600F80906F13AC60600FC4A6414DF100600FC89C7FE12C0BD4250B8FF3BE61200EB090601E1901200EB11CB7E 2019-01-20T21:50:21.194220 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126D18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFFFF06C006E006F00906F17408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FCFF12C02FC8505807FC1200EC090601F1D81200EE88D47E 2019-01-20T21:50:31.194745 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126F4800080FBB6FE682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017EF10A1236383431313331424E323433313031303430090681F9FF0680FF06C006E006F00906C1FF7408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FC12C02FC8505CFF07FC1200EC090601F1D81200EE13D47E 2019-01-20T21:50:41.189758 - 156 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A58000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FF96C828FF06C0FF06E006F089C7FE74080600F80906F13AC40600FC4A6414DF100600FCFF12C02FC85058FF3BE61200EC090601F1D81200EB3DC07E Hvis jeg tar f.eks. den siste meldingen over og bruker mye av kunnskapen fra https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/readme.md og https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md så tolker jeg det som noe slikt som under. Jeg har brukt linjeskift ved de typiske separatorene bare for å prøve å finne mønster, men det vil nok ofte være helt feil ettersom jeg ofte ikke får ting til å stemme med "02 - one byte following 06 - long (4 bytes / 32 bits) 12 - int (2 bytes / 16 bit) 09 - string, first byte is length (could it be a byte array?) 0A - string, first byte is length" uansett.
       
      7E <-- Frame Start flag A <-- 4 bits, A = Frame Format Type 3 0E2 <-- 12 bits, Frame size: 0xE2 (226 bytes!?, excluding start/end flags) 2B <-- Destination Address 21 <-- Source Address 13 <-- Control Field 239A <-- Gyldig CRC-16/X-25 E6 <-- Destination LSAP E7 <-- Source LSAP 00 <-- LLC Quality 0F <-- Information, n*8 bits? 0000F8BF60D95 <-- Hva er dette? Ofte(?) likt 09 12 6A58000F0FF682A566B1797AE17AE650582828A4A641428FE 0A 1135372036353627323132343834373536 <-- Gyldig målernummer i ASCII (NB: jeg endret noen sifre her, så evt påfølgende checksum vil feile) 09 06 01017CF1 <-- Hva er dette? Alltid likt 0A 12 36383431313331424E323433313031303430 <-- Alltid likt = ASCII 6841131BN243101040 <-- 684113 = måler-type 09 06 81F9FF 06 80FF96C828FF 06 C0FF 06 E0 06 F089C7FE7408 06 00F897C8287E 09 06 F13AC4 06 00FC4A6414DF10 06 00FCFF 12 C02FC85058FF3BE6 12 00EC <-- 236 (Volt? (L2?)) 09 06 01F1D8 <-- Hva er dette? 12 00EB <-- 235 (Volt? (L3?)) 3DC0 <-- Checksum? 7E <-- Frame End flag  
      Oppsettet for avlesingen er slik jeg hadde forventet det å være:
      ser = serial.Serial( port='/dev/ttyUSB0', baudrate=2400, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, bytesize=serial.EIGHTBITS, timeout=10)  
      Håper noen har noen tips eller innspill til meldingene. 🙂
       
    • Av aleks
      Usikker på hvor overrasket jeg er? Til Hafslund:
       
       
×
×
  • Opprett ny...