Gå til innhold
  • Bli medlem
roy

Hjelp til tyding av DLMS OBIS datapush-meldinger

Anbefalte innlegg

3 minutter siden, ole88 skrev:

Prøvde å korte ned ledningen, men ingen forandring. Har vært inne på tanken selv, om at kanskje adapteret er problemet i og med at det er ustabilt i meldingene.

Uansett, takk for hjelp :)

Jeg har benyttet denne et par mnd nå uten problemer:

https://www.aliexpress.com/item/USB-to-MBUS-Slave-Module-Discrete-Component-Non-TSS721-Circuit-M-BUS-Bus-Monitor/32917153031.html?spm=a2g0s.9042311.0.0.65084c4dHuLwpT

Del dette innlegget


Lenke til innlegg
Del på andre sider

Del dette innlegget


Lenke til innlegg
Del på andre sider
12 timer siden, ole88 skrev:

Takk for hjelpen. Jeg trodde at å skrive kun msg i debug noden ville "printe" alle verdier, men når jeg fylte inn "payload.act_pow_pos" i feltet, fikk jeg ut forbruk av watt. Tusen takk for hjelp!!

Til andre som kanskje kommer til å slite med det samme, disse innstillingene fungerer for meg: 

 

Oppsett.png

Til info så jobber jeg med en ny versjon av decoderene der man får opp alle data i msg.payload uavhengig av man setter inn komplett objektnavn slik som msg.payload.act_pow_pos. I tillegg kommer jeg til å implementere "msg.payload = msg.payload.toUpperCase();" slik at man kan slippe å medta denne i funsksjonsnoden. 

Del dette innlegget


Lenke til innlegg
Del på andre sider

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

Del dette innlegget


Lenke til innlegg
Del på andre sider

Takk for alle svar! 🙂

 

Jeg kjøpte meg en ny USB-til-MBUS-slave-modul fra eBay siden jeg - tilsynelatende i likhet med mange - ikke fikk noen fornuftige data ut av den forrige fra AliExpress. Og da ble det en annen verden. Nå er pakkene stabile på 228 bytes hvert tiende sekund. Innholdet er akkurat som forventet. 🙂

 

Spoiler


Når jeg nå tolker dataene ut i 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å blir alt så fint:


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
23 9A                                                           <-- Valid CRC-16/X-25
E6                                                              <-- Destination LSAP
E7                                                              <-- Source LSAP
00                                                              <-- LLC Quality
0F                                                              <-- Information, n*8 bits?

00 00 00 00                                                     <-- INVOKE_ID_AND_PRIORITY

0C                                                              <-- 12 bytes (length of the string)
07 E3                                                           <-- 2019 (year)
06                                                              <-- 06 (month, june)
12                                                              <-- 18 (day of month)
02                                                              <-- Tuesday (day of week)
14                                                              <-- 20 (hour of day)
2F                                                              <-- 47 (minute of hour)
32                                                              <-- 50 (seconds of minute)
FF                                                              <-- (fff not specified?)
80                                                              <-- (deviation not specified?)
00 80                                                           <-- (what's this?)
02 19                                                           <-- List ID

0A                                                              <-- (what's this, a separator?)
   0E                                                           <-- 14 (length of meter type in ASCII?)
      4B 61 6D 73 74 72 75 70 5F 56 30 30 30 31                 <-- Kamstrup_V0001 (OBIS List Version Identifier)
09 06                                                           
      01 01 00 00 05 FF                                         <-- 1.1.0.0.5.255 (OBIS for Meter ID)
0A                                                              
      34 32 30 30 35 36 37 32 32 33 31 39 37 37 31 34           <-- 4200567223197714 (meter id, has changed some numbers so the checksum is broken)
09 06                                                           
      01 01 60 01 01 FF                                         <-- 1.1.96.1.1.255 (OBIS for meter type)
0A                                                              
   12                                                           <-- 18 (length of meter type in ASCII?)
       36 38 34 31 31 33 31 42 4E 32 34 33 31 30 31 30 34 30    <-- 6841131BN243101040 (meter type)
09 06                                                           
       01 01 01 07 00 FF                                        <-- 1.1.1.7.0.255 (OBIS for Active Power +)
       06 00 00                                                 <-- (what's this?)
       06 A7                                                    <-- 1703 W
09 06                                                           
       01 01 02 07 00 FF                                        <-- 1.1.2.7.0.255 (OBIS for Active Power -)
       06 00 00                                                 
       00 00                                                    <-- 0 W (Active Power -)
09 06                                                           
       01 01 03 07 00 FF                                        <-- 1.1.3.7.0.255 (OBIS for Reactive Power +)
       06 00 00                                                 
       00 00                                                    <-- 0 W
09 06                                                           
       01 01 04 07 00 FF                                        <-- 1.1.4.7.0.255 (OBIS for Reactive Power -)
       06 00 00                                                 
       01 E0                                                    <-- 480 W
09 06                                                           
       01 01 1F 07 00 FF                                        <-- 1.1.31.7.0.255 (OBIS for L1 Current)
       06 00 00                                                 
       00 88                                                    <-- 1,36 A (L1 Current)
09 06                                                           
       01 01 33 07 00 FF                                        <-- 1.1.51.7.0.255 (OBIS for L2 Current)
       06 00 00                                                 
       02 36                                                    <-- 5,66 A (L2 Current)
09 06                                                           
       01 01 47 07 00 FF                                        <-- 1.1.71.7.0.255 (OBIS for L3 Current)
       06 00 00                                                 
       00 6D                                                    <-- 1,09 A (L3 Current)
09 06                                                           
       01 01 20 07 00 FF                                        <-- 1.1.32.7.0.255 (OBIS for L1 Voltage)
       12 00                                                    <-- (what's this, yet another separator?)
       EB                                                       <-- 235 V (L1 Voltage)
09 06                                                           
       01 01 34 07 00 FF                                        <-- 1.1.52.7.0.255 (OBIS for L2 Voltage)
       12 00                                                    
       EB                                                       <-- 235 V (L2 Voltage)
09 06                                                           
       01 01 48 07 00 FF                                        <-- 1.1.72.7.0.255 (OBIS for L3 Voltage)
       12 00                                                    
       EB                                                       <-- 235 V (L3 Voltage)
83 77                                                           <-- Checksum? (will not validate since meter id has been altered)
7E                                                              <-- Frame End flag


 


 

Del dette innlegget


Lenke til innlegg
Del på andre sider
02 19                                                           <-- List ID


bmork: nei. 02 er struct.  19 er antall felt (25 desimalt).  Merk at dette er en flat struktur.
OBIS-koder og etterfølgende verdier er alle på samme nivå.  Antallet må derfor alltid være et
oddetall ettersom liste-navnet kommer først, uten noen OBIS-kode

0A                                                              <-- (what's this, a separator?)

bmork: 0a er "visible-string"


09 06                                                           
       01 01 01 07 00 FF                                        <-- 1.1.1.7.0.255 (OBIS for Active Power +)
       06 00 00                                                 <-- (what's this?)
       06 A7                                                    <-- 1703 W

bmork:  06 er "double-long-unsigned", dvs et 32bit unsigned heltall.  De to 00 bytene er altså en del av
verdien din: 0x000006a7


       12 00                                                    <-- (what's this, yet another separator?)
       EB                                                       <-- 235 V (L1 Voltage)
 
 bmork: 12 er "long-unsigned", dvs et 16bit heltall (ja, de har noen merkelige ideer om "long").  00 er
 alså en del av spenningsverdien din: 0x00eb

Ble litt slitsomt å quote dette, men prøver meg med noen inline-kommentarer ovenfor.  Håper det kan tydes...

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

Ah, tusen takk, @Bjørn Mork!

 

Nå googlet jeg litt på det du skrev. Fant denne gode oppsummeringen av det hele:

structure        02 LL                  (LL elements)
octet-string     09 LL   XX ..          (LL bytes)
visible-string   0A LL   XX ..          (LL bytes)
unsigned32       06      XX XX XX XX    (04 bytes)
unsigned16       12      XX XX          (02 bytes)

 

Da kan jo man gjøre parsingen av dataene skikkelig. :) 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Hei.

 

har prøvd på dette en stund nå, men får bare feilmelding:

 

TypeError: Object  ()  has no method 'includes'

 

har den ustabile modulen, men lengden på pakkene ser veldig stabile ut for et utrent øye, det ser også ut som de er bygget opp som instruksjonen fra Aidon.

 

Noen som vet hva jeg har røra med?

 

 

Spoiler

 

7E A10B 41 0883 13 FA7C E6E700
0F 40000000 00
010C
0202 0906 0101000281FF 0A0B 4149444F4E5F5630303031
0202 0906 0000600100FF 0A10 37333539393932383938373331313437
0202 0906 0000600107FF 0A04 36353235
0203 0906 0100010700FF 06 000009DE 0202 0F00 161B
0203 0906 0100020700FF 06 00000000 0202 0F00 161B
0203 0906 0100030700FF 06 00000000 0202 0F00 161D
0203 0906 0100040700FF 06 00000237 0202 0F00 161D
0203 0906 01001F0700FF 10 0013     0202 0FFF 1621
0203 0906 0100470700FF 10 0061     0202 0FFF 1621
0203 0906 0100200700FF 12 08CD     0202 0FFF 1623
0203 0906 0100340700FF 12 08DA     0202 0FFF 1623
0203 0906 0100480700FF 12 08C2     0202 0FFF 1623
2E2E 7E 


7E A10B 41 0883 13 FA7C E6E700

0F 40000000 00
010C
0202 0906 0101000281FF 0A0B 4149444F4E5F5630303031
0202 0906 0000600100FF 0A10 37333539393932383938373331313437
0202 0906 0000600107FF 0A04 36353235
0203 0906 0100010700FF 06 00000ABE 0202 0F00 161B
0203 0906 0100020700FF 06 00000000 0202 0F00 161B
0203 0906 0100030700FF 06 00000000 0202 0F00 161D
0203 0906 0100040700FF 06 00000234 0202 0F00 161D
0203 0906 01001F0700FF 10 001C     0202 0FFF 1621
0203 0906 0100470700FF 10 0061     0202 0FFF 1621
0203 0906 0100200700FF 12 08C9     0202 0FFF 1623
0203 0906 0100340700FF 12 08D7     0202 0FFF 1623
0203 0906 0100480700FF 12 08C0     0202 0FFF 1623
3877 7E 

 

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
7 hours ago, hmmm said:

har den ustabile modulen, men lengden på pakkene ser veldig stabile ut for et utrent øye, det ser også ut som de er bygget opp som instruksjonen fra Aidon.

Vet ikke hva som er galt, men kan ihvertfall bekrefte at de to pakkene du postet er korrekte og fullstendige.

Del dette innlegget


Lenke til innlegg
Del på andre sider

Da virker det!

 

oppdater, oppdater, oppdater!! 

kjørte gamle versjoner av det meste. 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Hva betyr egentlig den OBIS-meldingen 0.1.1.0.0.255 - RTC w/Quality? Hvordan skal man tyde innholdet?

 

09                                        <-- octet-string
  06                                      <-- string length, 0x06 = 6 bytes
    00 01 01 00 00 FF                     <-- 0.1.1.0.0.255 (OBIS for RTC w/Quality)
09                                        <-- octet-string
  0C                                      <-- string length, 0x0C = 12 bytes
    07 E3 07 09 02 14 00 05 FF 80 00 80   <-- What's this?

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
4 hours ago, roy said:

07 E3 07 09 02 14 00 05 FF 80 00 80 <-- What's this?

 

Dette er dato og klokke fra måleren.  Formatet er beskrevet f.eks. i kapittel 4.1.6 i dette åpne dokumentet: https://www.dlms.com/files/Blue-Book-Ed-122-Excerpt.pdf

Du har:

07e3  => år: 2019

07 => måned: juli

09 => dag: 9.

02 => ukedag: tirsdag

14 00 05 => time, min, sek: 20:00:05

ff => hundredeler: ikke oppgitt

80 00 => offset fra UTC er ikke oppgitt

80  => status: sommertid(?)

 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Ah, Real Time Clock selvfølgelig. La ikke merke til at tallene ga den meningen eller at den stringen også er til stede i headeren. Takk for hjelpen. :)

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 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 aleks
      Usikker på hvor overrasket jeg er? Til Hafslund:
       
       
×