Gå til innhold
  • Bli medlem

Anbefalte innlegg

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

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

For sånne ting tenker jeg at det er bedre å være "føre var". Å endre et målepunkt-ID før opplasting er jo en smal sak...

Del dette innlegget


Lenke til innlegg
Del på andre sider
3 timer siden, Moskus skrev:

For sånne ting tenker jeg at det er bedre å være "føre var". Å endre et målepunkt-ID før opplasting er jo en smal sak...

 

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

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

Det er ikke målepunkt-ID som ligger i data fra måleren. Målepunkt-ID (18 siffer) finner du på strømregningen. På HAN porten får du ut Meter ID (16 siffer).

  • Like 2

Del dette innlegget


Lenke til innlegg
Del på andre sider
4 timer siden, Hårek skrev:

Det er ikke målepunkt-ID som ligger i data fra måleren. Målepunkt-ID (18 siffer) finner du på strømregningen. På HAN porten får du ut Meter ID (16 siffer).

 

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

Del dette innlegget


Lenke til innlegg
Del på andre sider

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

Del dette innlegget


Lenke til innlegg
Del på andre sider

Det er godt å høre at det er flere som tenker på disse tingene. :) Jeg har sensurert målernummeret mitt i de dataene jeg har lastet opp, men det er kanskje ikke nødvendig.

 

Det som jeg har stusset over derimot, er hvordan man på diverse tjenester på nettet kan skrive inn et mobilnummer og få ut fullt navn, full adresse, fødselsdato, målepunkt-ID, målernummer og netteier. Om man ikke finner en persons mobilnummer i telefonkatalogen finner man det stort sett alltid i en eller annen kontaktliste for et idrettslag, et Facebook-innlegg, en Finn-annonse, eller lignende. Så sånn sett er det litt enklere å få tak i målepunkt-ID enn et fødselsnummer..

Del dette innlegget


Lenke til innlegg
Del på andre sider
På 8.7.2019 den 17.48, roy skrev:

Det er godt å høre at det er flere som tenker på disse tingene. :) Jeg har sensurert målernummeret mitt i de dataene jeg har lastet opp, men det er kanskje ikke nødvendig.

 

Og som nevnt tidligere, hvis du beholder resten av melding uendret (med sjekksum) kan man (relativt) enkelt regne seg frem til det.

 

På 8.7.2019 den 17.48, roy skrev:

Det som jeg har stusset over derimot, er hvordan man på diverse tjenester på nettet kan skrive inn et mobilnummer og få ut fullt navn, full adresse, fødselsdato, målepunkt-ID, målernummer og netteier. Om man ikke finner en persons mobilnummer i telefonkatalogen finner man det stort sett alltid i en eller annen kontaktliste for et idrettslag, et Facebook-innlegg, en Finn-annonse, eller lignende. Så sånn sett er det litt enklere å få tak i målepunkt-ID enn et fødselsnummer..

 

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:

 

Sitat

Det er kun netteier og din strømleverandør (via Elhub) som har tilgang til ditt målernummer og kan koble det mot ditt navn/målepunkt-ID/adresse. 

 

Alle målere fra Aidon har unike målernummer. Hva slags målernummer/serienummer andre produsenter av målere verden over benytter kjenner vi ikke til.

 

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

Del dette innlegget


Lenke til innlegg
Del på andre sider
7 timer siden, Robin Smidsrød skrev:

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.

 

Jeg tror det er Enoro som i sitt produkt Elwin Elprosess som tilbyr dette her. Uten at jeg vet det så virker det som om de har det meste av opplysninger om de fleste på tvers av selskaper.

 

 

7 timer siden, Robin Smidsrød skrev:

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

 

Poll er nok bra. Virker som om du relativt trygt kan dele det. Selv om jeg fort heller mot å fortsette å modifisere målernummer og sjekksum. Det er jo kjapt å søke og erstatte både målernummer og sjekksummer i både små store mengder data. (Skulle man finne på å scripte det er det jo ikke umulig å få regnet ut ny gyldig sjekksum om ønskelig.)

 

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 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. 🙂
       
×
×
  • Opprett ny...