Hjelp til tyding av DLMS OBIS datapush-meldinger

[Christopher Stenersen]

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

[ole88]

37 minutes ago, Christopher Stenersen said:

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

Merkelig, har den samme såvidt jeg kan se. Mulig det er noe feil med den. Kjøpte denne tidligere i år: 

https://www.aliexpress.com/item/Freeshipping-USB-to-MBUS-slave-module-discrete-component-non-TSS721-circuit-M-BUS-bus-data-monitor/32814808312.html?spm=a2g0s.9042311.0.0.27424c4dDQSLM9

 

[Christopher Stenersen]

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: 

 

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. 

[Christopher Stenersen]

Ny versjon 1.1.0 av HAN decoderen er nå publisert.

 

[Robin Smidsrød]

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

[roy]

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

 

 

[Bjørn Mork]

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

[roy]

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.  

[hmmm]

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 

 

 

 

[Bjørn Mork]

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.

[hmmm]

Da virker det!

 

oppdater, oppdater, oppdater!! 

kjørte gamle versjoner av det meste. 

[roy]

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?

 

[Bjørn Mork]

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(?)

 

[roy]

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.