Robin Smidsrød

Og som nevnt tidligere, hvis du beholder resten av melding uendret (med sjekksum) kan man (relativt) enkelt regne seg frem til det. Det tror jeg strengt tatt er et brudd på personvernsforordringen (GDPR) og burde således rapporteres til Datatilsynet. Hvis vi alle er flinke til å rapportere det når vi legger merke til det så kanskje vi over tid blir kvitt, i det minste, de verste synderne. Folk som selv deler telefonnummer og andre personopplysninger på sosiale medier er det vanskelig å gjøre noe med. Forøvrig: Jeg fikk dette svaret fra Skagerak Nett her om dagen på spørsmålet mitt rundt målernummer og personvern: Det betyr i det minste at det er et fåtall personer og institusjoner som har mulighet til å koble målernummeret til person/installasjonsadresse. Så da er spørsmålet. Skal eller skal jeg ikke dele målernummer uten å anonymisere det...? Kanskje se om jeg finner ut om det er mulig å lage en poll her for å se hva andre hadde gjort... -- Robin

Har sendt inn en forespørsel til nettselskapet mitt nå, og håper på et svar tilbake fra de rundt kobling av målernummer til målepunkt-ID og person/adresse. -- Robin

Tusen takk for opplysningen! Det var jo interessant informasjon. Da endrer jo spørsmålet seg litt siden det IKKE dreier seg om målepunkt-ID, men målernummer. Er det noen andre enn nettselskapet som har levert måleren som kan koble målernummer til målepunkt-ID? Når jeg tenket over det, er det kanskje et godt spørsmål å stille til kundeservice hos nettselskapet... -- Robin

Vel, å endre målepunkt-id før opplasting er ikke alltid enkelt hvis man har en større binærfil. I tillegg vil da sjekksum på fila ikke stemme, og hvis man bruker en dekoder som faktisk sjekker sjekksum så skal den da forkaste meldingen. I min dekoder (nevnt over) verifiserer jeg faktisk sjekksum, så den vil forkaste en melding hvor målepunkt-id er endret. Derfor har jeg lagt inn et parameter for å ignorere sjekksum (-i) hvis man har slike dump-filer man ønsker å kikke på. Mens jeg jobbet med dekoderen min la jeg merke til at man kan faktisk brute-force målepunkt-id hvis sjekksum (FCS) for meldingen ikke er endret. Og med tanke på at det kun er 17 siffer (0-9) og man kan verifisere offline burde det det ikke ta veldig lang tid å finne en målepunkt-id hvis man ellers har hele meldingen. Så jeg er fremdeles nysgjerrig på hva slags ting man faktisk kan gjøre med en målepunkt-id... -- Robin

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

Den skjønner jeg også. Hvis det var en del av kravet mitt hadde jeg nok prøvd å skrive det i Go, Rust eller et eller annet kompilerbart språk. Vel, etter at jeg hadde implementert den funksjonaliteten så slo det meg at hvis man ikke ønsker å starte et program for hver ny melding kan man jo pipe hele strømmen (som er JSON-meldinger, en per linje med newline på slutten hvis man bruker flagget for kompakte JSON-meldinger) direkte til et annet program som detekterer hvert enkelt JSON-objekt og sender det av gårde når det er ferdig mottatt. Tror muligens jq eller mosquitto_pub allerede har støtte for dette... Grunnen til at jeg ikke brukte en MQTT-modul fra CPAN var at jeg ønsket å holde avhengigheter minimale, for å gjøre det enkelt å installere. Derfor jeg også ikke har brukt Moo, Moose eller strukturert det objektorientert. -- Robin

Vel, jeg er vel kanskje litt mer old-school Unix, at man skal lage et verktøy som gjør _en_ oppgave, og gjør den bra, mens du tydligvis foretrekker den andre tankegangen (all-in-one tools). Forøvrig så ser jeg på koden til meter_reading at den tar litt snarveier som gjør at den _kun_ fungerer med Aidon-målere. Jeg har fokusert (i min kode) på å dekode korrekt, og det krever nødvendigvis mer kode og fler oppslagstabeller. Programmet mitt har mulighet til å sende meldinger til både Home Assistant (som jeg bruker) eller InfluxDB ved å bruke -p-argumentet (send dekodet melding via standard input til et annet program). Jeg bruker den opsjonen til å sende over MQTT vha. mosquitto_pub, men du kan like gjerne bruke ditt eget program der, som f.eks. konverterer JSON til noe HA skjønner og sende en API-forespørsel til HA om å oppdatere en sensor).

Heisann! Jeg har laget en dekoder til disse smartmålerne også. Min dekoder tar seg _KUN_ av dekoding av seriell-strømmen til JSON, men fungerer med både Aidon, Kamstrup og Kaifa-målere. I tillegg har den en opsjon for å kjøre et program for hver melding, så det er enkelt å lage en systemd unit som bruker f.eks. mosquitto_pub for å sende meldingen til et MQTT-endepunkt. Programmet er skrevet i Perl og skal fungere helt greit på en Raspberry Pi eller andre Linux-baserte operativsystemer. Her er linken, hvis det skulle være av interesse: https://github.com/robinsmidsrod/ams-han-decoder Personlig bruker jeg det til å sende JSON-meldingene over MQTT (bruker mosquitto) til Node-Red, som igjen kverner litt på meldingene og sender de videre til InfluxDB. Deretter bruker jeg Grafana til å visualisere informasjonen lagret i InfluxDB. Jeg så det var postet noen logger fra en Kamstrup-måler i tråden, og kjørte de gjennom dekoderen min. La umiddelbart merke til at de hadde bl.a. checksum-feil og masse andre feil (hvis jeg ignorerte checksum-feilen). Når jeg så det scrollet jeg litt lenger opp og så lenka til hvilket MBUS-til-USB-adapter som ble benyttet. Da skjønte jeg hvorfor ting ikke virket. Jeg hadde den samme modulen først og hadde samme problemet med min. Kjøp en ny adapter (link i programkoden i mitt git repo til adapter som virker) så skal alt virke. Når jeg nå ser størrelsen på programkoden min (i Perl) for å få til riktig dekoding skjønner jeg at det er omfattende å skrive en (korrekt) dekoder i Node-Red. Det kan hende dere finner noe nyttig info i programkoden som kan hjelpe dere med å skrive en bedre node-red contrib-modul. Uansett synes jeg dette er spennende og det er artig å endelig få god oversikt over strømforbruket i heimen. -- Robin

Heisann! Som deg fant jeg heller ikke noe godt nok og bestemte meg for å prøve selv. Min dekoder tar seg _KUN_ av dekoding av seriell-strømmen til JSON, men fungerer med både Aidon, Kamstrup og Kaifa-målere. I tillegg har den en opsjon for å kjøre et program for hver melding, så det er enkelt å lage en systemd unit som bruker f.eks. mosquitto_pub for å sende meldingen til et MQTT-endepunkt. Programmet er skrevet i Perl og skal fungere helt greit på en Raspberry Pi eller andre Linux-baserte operativsystemer. Her er linken, hvis det skulle være av interesse: https://github.com/robinsmidsrod/ams-han-decoder Personlig bruker jeg det til å sende JSON-meldingene over MQTT (bruker mosquitto) til Node-Red, som igjen kverner litt på meldingene og sender de videre til InfluxDB. Deretter bruker jeg Grafana til å visualisere informasjonen lagret i InfluxDB. Har lagt ved et eksempel på List 3 (den største meldingen) fra Aidon 6525-måler, og som du ser har jeg både HDLC info (header), selve COSEM datastrukturen (payload) og en forenklet versjon av COSEM-dataene (data) som er mer egnet for å sende videre til andre applikasjoner. Feltet "payload" skal alltid være riktig, men "data" kan være feil hvis du har en Kaifa-måler som ikke sender ut registerne i riktig OBIS-rekkefølge (f.eks. forskjell på 1-fas og 3-fas). I så fall må scriptet endres litt i funksjonen "decode_cosem_structure" for å sette opp riktig rekkefølge på OBIS-kodene. Hvis du fremdeles sliter med dekoding av COSEM-registerne er Perl-koden ganske godt dokumentert på hvor opplysningene finnes. Det kan hende du finner noe du kan bruke der selv. -- Robin AIDON_V0001_list_3_example.json

Heisann! Jeg har laget en dekoder som fungerer med den samme MBUS/USB-adapteren du nevner over. Den tar seg _KUN_ av dekoding av seriell-strømmen til JSON, men fungerer med både Aidon, Kamstrup og Kaifa-målere. I tillegg har den en opsjon for å kjøre et program for hver melding, så det er enkelt å lage en systemd unit som bruker f.eks. mosquitto_pub for å sende meldingen til et MQTT-endepunkt. Programmet er skrevet i Perl og skal fungere helt greit på en Raspberry Pi. Her er linken, hvis det skulle være av interesse: https://github.com/robinsmidsrod/ams-han-decoder Personlig bruker jeg det til å sende JSON-meldingene over MQTT (bruker mosquitto) til Node-Red, som igjen kverner litt på meldingene og sender de videre til InfluxDB. Deretter bruker jeg Grafana til å visualisere informasjonen lagret i InfluxDB. -- Robin

Førstegansposter her. :) Tenkte jeg bare skulle informere om at jeg har laget min egen dekoder for Aidon 6525. Har prøvd å skrive den på en måte som skal gjøre det enkelt å bruke programmet mot Kamstrup og Kaifa også, men har ikke informasjon om hvordan disse målerne fungerer, så litt mer hjelp trengs før disse er funksjonelle. Her er linken du trenger for å finne programmet: https://github.com/robinsmidsrod/ams-han-decoder -- Robin