Gå til innhold
  • Bli medlem
roy

Hjelp til tyding av DLMS OBIS datapush-meldinger

Anbefalte innlegg

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

 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Tips: skill bytene med et komma eller 0x så blir lesbarheten myyyyye bedre.

 

Også la 0 vises som 0x00 eller 00.

 

Ser ikke ut som noen kamstrup-meldinger jeg har sett før.

Men det er siden formateringen er dårlig.

-Andreas 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Takk for svar, @Andreas!

 

Her er meldingene re-formatert. 0 var allerede paddet. Men ja, de fremstår som unaturlig korte i forhold til andre jeg har sett. Men det interessante er at f.eks. CRC for header er gyldig. (Usikker på hvordan korrekt beregne CRC av totalen.) Og meldingene holder seg stabile, starter og slutter alltid med 7E og inneholder målernummer, målertype og litt diverse ting som kommentert i første post.

 

2019-01-20T21:50:11.195980 - 155 bytes:
7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 F8 BF 60 
D9 50 91 26 A1 80 00 F0 FF 68 2A 56 6B 17 97 AE 17 
AE 65 05 82 82 8A 4A 64 14 28 FE 0A 11 35 37 20 36 
35 36 27 32 31 32 34 38 34 37 35 36 09 06 01 01 7C 
F1 0A 12 36 38 34 31 31 33 31 42 4E 32 34 33 31 30 
31 30 34 30 09 06 81 F9 FF 06 80 FF FB FE 06 C0 06 
E0 06 F0 89 C7 FE 74 08 06 00 F8 09 06 F1 3A C6 06 
00 FC 4A 64 14 DF 10 06 00 FC 89 C7 FE 12 C0 BD 42 
50 B8 FF 3B E6 12 00 EB 09 06 01 E1 90 12 00 EB 11 
CB 7E

2019-01-20T21:50:21.194220 - 154 bytes:
7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 F8 BF 60 
D9 50 91 26 D1 80 00 F0 FF 68 2A 56 6B 17 97 AE 17 
AE 65 05 82 82 8A 4A 64 14 28 FE 0A 11 35 37 20 36 
35 36 27 32 31 32 34 38 34 37 35 36 09 06 01 01 7C 
F1 0A 12 36 38 34 31 31 33 31 42 4E 32 34 33 31 30 
31 30 34 30 09 06 81 F9 FF 06 80 FF FF FF 06 C0 06 
E0 06 F0 09 06 F1 74 08 FF 06 00 F8 5F 21 50 FE 3A 
C4 06 00 FC 4B 7F DF 07 FC 06 00 FC FF 12 C0 2F C8 
50 58 07 FC 12 00 EC 09 06 01 F1 D8 12 00 EE 88 D4 
7E

2019-01-20T21:50:31.194745 - 154 bytes:
7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 F8 BF 60 
D9 50 91 26 F4 80 00 80 FB B6 FE 68 2A 56 6B 17 97 
AE 17 AE 65 05 82 82 8A 4A 64 14 28 FE 0A 11 35 37 
20 36 35 36 27 32 31 32 34 38 34 37 35 36 09 06 01 
01 7E F1 0A 12 36 38 34 31 31 33 31 42 4E 32 34 33 
31 30 31 30 34 30 09 06 81 F9 FF 06 80 FF 06 C0 06 
E0 06 F0 09 06 C1 FF 74 08 FF 06 00 F8 5F 21 50 FE 
3A C4 06 00 FC 4B 7F DF 07 FC 06 00 FC 12 C0 2F C8 
50 5C FF 07 FC 12 00 EC 09 06 01 F1 D8 12 00 EE 13 
D4 7E

2019-01-20T21:50:41.189758 - 156 bytes:
7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 F8 BF 60 
D9 50 91 26 A5 80 00 F0 FF 68 2A 56 6B 17 97 AE 17 
AE 65 05 82 82 8A 4A 64 14 28 FE 0A 11 35 37 20 36 
35 36 27 32 31 32 34 38 34 37 35 36 09 06 01 01 7C 
F1 0A 12 36 38 34 31 31 33 31 42 4E 32 34 33 31 30 
31 30 34 30 09 06 81 F9 FF 06 80 FF 96 C8 28 FF 06 
C0 FF 06 E0 06 F0 89 C7 FE 74 08 06 00 F8 09 06 F1 
3A C4 06 00 FC 4A 64 14 DF 10 06 00 FC FF 12 C0 2F 
C8 50 58 FF 3B E6 12 00 EC 09 06 01 F1 D8 12 00 EB 
3D C0 7E

 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Tipper det er den kretsen din som ikke sender hele medlingen. Prøv med en opamp slik som beskrevet på en av de siste sidene i den andre ams-tråden ca side 54?image.png

Endret av Andreas

Del dette innlegget


Lenke til innlegg
Del på andre sider

@roy Jeg har utviklet 2 noder for Node-Red til decoding av Aidon og Kamstrup. Har ikke testet denne på Kaifa enda da jeg ikke har fått tilgang på rådata fra den.

Du kan jo se om du får noe fornuftig ut av den? Jeg tror meldingene dine er komplette ved første øyekast.

 

https://www.npmjs.com/package/node-red-contrib-ams-decoder

 

har forsøkt å lagge en fornuftig README på hvordan den bør benyttes i Node Red.

Del dette innlegget


Lenke til innlegg
Del på andre sider

@Christopher Stenersen noden din til Kamstrup ser ikke ut til å fungere med min kamstrup måler. Her er det jeg fåt rett fra seriel-noden og hva jeg får ut fra Kamstrup-noden:

 

{"payload":[126,160,178,43,33,19,53,79,230,231,0,15,0,0,0,0,12,7,227,4,28,7,11,28,20,255,128,0,128,2,17,10,14,75,97,109,115,116,114,117,112,95,86,48,48,48,49,9,6,1,1,0,0,5,255,10,16,53,55,48,54,53,54,55,50,56,55,51,50,49,53,53,51,9,6,1,1,96,1,1,255,10,18,54,56,54,49,49,49,49,66,78,50,52,50,49,48,49,48,52,48,9,6,1,1,1,7,0,255,6,0,0,5,45,9,6,1,1,2,7,0,255,6,0,0,0,0,9,6,1,1,3,7,0,255,6,0,0,0,0,9,6,1,1,4,7,0,255,6,0,0,0,164,9,6,1,1,31,7,0,255,6,0,0,2,52,9,6,1,1,32,7,0,255,18,0,239,16,193,126],"port":"/dev/ttyUSB0","_msgid":"b4a51ca3.01e2d"}

{"port":"/dev/ttyUSB0","_msgid":"b4a51ca3.01e2d"}


{"payload":[126,160,178,43,33,19,53,79,230,231,0,15,0,0,0,0,12,7,227,4,28,7,11,28,30,255,128,0,128,2,17,10,14,75,97,109,115,116,114,117,112,95,86,48,48,48,49,9,6,1,1,0,0,5,255,10,16,53,55,48,54,53,54,55,50,56,55,51,50,49,53,53,51,9,6,1,1,96,1,1,255,10,18,54,56,54,49,49,49,49,66,78,50,52,50,49,48,49,48,52,48,9,6,1,1,1,7,0,255,6,0,0,4,203,9,6,1,1,2,7,0,255,6,0,0,0,0,9,6,1,1,3,7,0,255,6,0,0,0,0,9,6,1,1,4,7,0,255,6,0,0,0,68,9,6,1,1,31,7,0,255,6,0,0,2,4,9,6,1,1,32,7,0,255,18,0,240,195,105,126],"port":"/dev/ttyUSB0","_msgid":"eb53e4cf.daf528"}

{"port":"/dev/ttyUSB0","_msgid":"eb53e4cf.daf528"}

image.thumb.png.049d22bc7a05419fffa008ea709b1f05.png

Del dette innlegget


Lenke til innlegg
Del på andre sider

image.png.1e0578082ed9d6e087e899e9fda945f2.png

 

For meg er det parity "none" som er riktig, du ser av datastrømmen at stop-bittet 0x7e er der. Den klarte visst ikke å kopiere/paste i hex ser jeg nå, men det er 126 ja. Jeg får ikke riktig stop-bit med parity even.

Del dette innlegget


Lenke til innlegg
Del på andre sider

@eriler har du mulighet til å sende meg rådata  fra serialporten med riktig HEX format så kan jeg ta en titt?

Jeg tror nok den fungerer men debug-noden greier ikke å lese ut data uten å gjøre noen innstillinger.

du kan også forsøke å henge på en debug node med slik instilling for å se om du får ut aktiv effekt:

image.png.c514a6645113157a7797ab8edf47cfe9.png

Del dette innlegget


Lenke til innlegg
Del på andre sider
7 minutes ago, Christopher Stenersen said:

@eriler har du mulighet til å sende meg rådata  fra serialporten med riktig HEX format så kan jeg ta en titt?

Jeg tror nok den fungerer men debug-noden greier ikke å lese ut data uten å gjøre noen innstillinger.

du kan også forsøke å henge på en debug node med slik instilling for å se om du får ut aktiv effekt:

image.png.c514a6645113157a7797ab8edf47cfe9.png

 

Jeg ser at jeg har gjort feil i å anta at å velge "complete msg object" i debug noden ville vise meg alt den får fra kamstrup noden din!

Jeg får en fornuftig verdi når jeg skriver det du skriver i debug noden min også. Da funker det altså. Hjertelig takk for arbeidet du har lagt ned i dette og support til meg på toppen av det hele!

Del dette innlegget


Lenke til innlegg
Del på andre sider
5 timer siden, eriler skrev:

@Christopher Stenersen Har du en god måte å sende disse verdiene til mqtt? Jeg ser det som kamstrup noden gir ut må splittes på et vis.

Det fungerer fint med f.eks en function node som tilpasser "msg.payload" til å være lik "msg.payload.act_pow_pos" som sender videre til en MQTT broker:

 

image.png.333b64541fc67f88b679f4ef1d08988b.png

 

Skript i function noden:

msg.payload = msg.payload.act_pow_pos
return msg;

 

Skal du publisere til samme topic i MQTT eller en topic pr. data som kommer fra noden?

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 time siden, eriler skrev:

Planen var et mqtt topic per verdi, slik at det lettest kan brukes videre i et GUI.

ok.

Da kan du legge noe slikt i function node så lar du topic stå blank i mqtt noden:

node.send({payload:msg.payload.act_pow_pos, topic:"aktiv_effekt_positiv"})
node.send({payload:msg.payload.act_pow_neg, topic:"aktiv_effekt_negativ"})
return;

 

Del dette innlegget


Lenke til innlegg
Del på andre sider

Hei alle.

 

Jeg skriver her på grunn av at jeg ikke kommer helt i mål. Får ut melding i Node-red som starter på 7E og slutter på 7E. Har en Kamstrup måler med en mbus til usb, samme som trådstarter. Har laget en skisse, se vedlegget. Ved bruk av Kamstrup noden får jeg ikke ut noe annet enn payload: function. Er det noen åpenbar enkel feil eller noe jeg har oversett?

 

Takk for all hjelp.

problem.png

Del dette innlegget


Lenke til innlegg
Del på andre sider

En annen ting som kanskje er greit å vite er at input til Kamstrup-noden får jeg ved hjelp av funksjonen for ordens skyld dette:

bilde1.png

Del dette innlegget


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

Hei alle.

 

Jeg skriver her på grunn av at jeg ikke kommer helt i mål. Får ut melding i Node-red som starter på 7E og slutter på 7E. Har en Kamstrup måler med en mbus til usb, samme som trådstarter. Har laget en skisse, se vedlegget. Ved bruk av Kamstrup noden får jeg ikke ut noe annet enn payload: function. Er det noen åpenbar enkel feil eller noe jeg har oversett?

 

Takk for all hjelp.

problem.png

 

Alt 1:

huk av at debuger node skal vises i console. Da burde meldinger vises i terminal som kjører node red med noe mer informasjon

 

alt 2:

du må skrive komplett objektnavn i debugger. 

F.eks msg.payload.act_pow_pos. Se readme for noden for å få oversikt over alle objektene. 

 

Du finner readme her:

https://flows.nodered.org/node/node-red-contrib-ams-decoder

 

 

Endret av Christopher Stenersen

Del dette innlegget


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

 

Alt 1:

huk av at debuger node skal vises i console. Da burde meldinger vises i terminal som kjører node red med noe mer informasjon

 

alt 2:

du må skrive komplett objektnavn i debugger. 

F.eks msg.payload.act_pow_pos. Se readme for noden for å få oversikt over alle objektene. 

 

Du finner readme her:

https://flows.nodered.org/node/node-red-contrib-ams-decoder

 

 

4 hours ago, Christopher Stenersen said:

 

Alt 1:

huk av at debuger node skal vises i console. Da burde meldinger vises i terminal som kjører node red med noe mer informasjon

 

alt 2:

du må skrive komplett objektnavn i debugger. 

F.eks msg.payload.act_pow_pos. Se readme for noden for å få oversikt over alle objektene. 

 

Du finner readme her:

https://flows.nodered.org/node/node-red-contrib-ams-decoder

 

 

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

Del dette innlegget


Lenke til innlegg
Del på andre sider

Har fått kamstrup måleren til å gi ut data på disse hvert 10 sek:

msg.payload.obis_list_version "Kamstrup_V0001"

msg.payload.meter_ID "5706567205596285"

msg.payload.meter_model "6841121BN243101040"

payload.act_pow_pos " x watt" Gir riktig watt i øyeblikket

 

Denne kommer ca. hvert 30 sekund:

msg.payload.act_pow_neg, 50694,50201, 49953, varierer opp og ned. Hva er dette?

 

De andre får jeg ingen data fra. Jeg har satt opp overvåkning, så venter å ser om det kommer inn noe på dem iløpet av noen timer.

Noen som har noen tips? Ville gjerne sett volt og ampere målingene.

Del dette innlegget


Lenke til innlegg
Del på andre sider
2 hours ago, Christopher Stenersen said:

Kan du sende meg rådata fra ca en times logging så kan jeg ta en kikk. Act_pow_neg skal være strøm ut av huset ved for eksempel solcelleanlegg etc.

Her har du 2 filer. Lagde en logfil med timestamp,  og en med bare data fra kl 14.38 til ca 15.45 i dag. 

 

 

ams_raa_1438.log

ams2_medtid1438.log

Del dette innlegget


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

Her har du 2 filer. Lagde en logfil med timestamp,  og en med bare data fra kl 14.38 til ca 15.45 i dag. 

 

 

ams_raa_1438.log

ams2_medtid1438.log

Oi her var det veldig varierende lengder på linjene, disse burde hvert eksakt like lange hvert 10.sek  og noe lengre hver time. 

Ser ut som dataene er riktige frem til act_pow_pos men deretter er det veldig varierende struktur. 

Kanskje du kan forsøke en annen USB-Seriell overgang?

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
12 minutes ago, Christopher Stenersen said:

Oi her var det veldig varierende lengder på linjene, disse burde hvert eksakt like lange hvert 10.sek  og noe lengre hver time. 

Ser ut som dataene er riktige frem til act_pow_pos men deretter er det veldig varierende struktur. 

Kanskje du kan forsøke en annen USB-Seriell overgang?

 

 

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 :)

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