Gå til innhold
  • Bli medlem

Anbefalte innlegg

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?

Del dette innlegget


Lenke til innlegg
Del på andre sider

Jeg har akkurat satt opp Aidon fra Hafslund, antar det er samme som Lyse bruker, jeg bruker Python scriptet og sitter å skriver en guide. Én klar fordel er at du slipper å bruke node-red helt og kan bruke det ene Python-scriptet og skrive direkte til basen. Det var en del prøving og feiling, men det har kjørt noen uker nå og virker veldig bra.

 

Edit: Kanskje du vil være "prøvekanin" for guiden min?

Endret av larsi70
  • Thanks 1

Del dette innlegget


Lenke til innlegg
Del på andre sider
11 timer siden, Torbjørn skrev:

Ja jeg er gjerne prøvekanin :)

 

Da har jeg sendt PM med utkast til Guide. Når den er gjennomgått, evt fikset og funnet i orden lager jeg ny post med denne guiden som flere kan ha nytte av. 

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

Da er systemet oppe å kjører., sånn delvis vert fall.

Får bare hente ut effekt verdien. Eneste som blir sendt til influxdb.

 

Noen som har et python script som fungerer på Aidon 6515 modellen. Koblet til hos Lyse dersom det har noe å si?

Del dette innlegget


Lenke til innlegg
Del på andre sider

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå

  • Lignende innhold

    • 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 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:
       
       
    • Av 1v4r
      Jeg har hatt litt mailkorespondanse med med Eidsiva Nett om å få åpnet HAN-porten på min AMS-måler. Nå er det tydeligvis bare å smøre seg med tålmodighet.
       
       

       
       

       

       
       
    • Av Vegard S
      Jeg har kikket litt på denne disse trådene for lesing av HAN.
       
      Jeg har endt opp med å bruke en ferdig M-Bus til TTL modul fra aliexpress koblet til en ESP-8266 ESP-01 versjonen med RoarFred sin Arduino kode:
      https://www.aliexpress.com/item/TSS721-Module-Board-M-BUS-To-TTL-with-RX-TX-Indicator-STM32-Development-Board-Free-Shipping/32751482255.html
       
      Dette fungerer feldig fint på det korte meldingene med kun Power(W) sendingene fra HAN koblingen, men når de lengre meldingene med strøm/spenning så feiler 1/3 av meldingene av å bli lest av ESP modulen. Jeg har aldri fått lest kWh meldingene fra HAN koblingen.
       
      Etter å ha sjekket litt med oscilloscope så fikk jeg se dette som er på bildet:
      Her ser vi øverst signalet direkte på HAN koblingen (M-Bus).
      Nederst TTL singalet ut fra M-bus til TTL konverteren.
       
      Her ser det ut som at konverteren ikke klarer å lage TTL signalet mot slutten av meldingen.
      Mot slutten så halveres spenningen på signalet fra 5V til ca 2.2v. Dette er litt for lavt for at ESP modulen detekterer signalet.
       
      Er det noen der ute som kan gi meg noen tips på hva jeg kan sjekke for å få konverteren til å fungere ordentlig? 
       
       
       

×