Bjørn Mork

Nei, det der ser ut som bare støy. Det er ingen 7e som markerer start/slutt på rammene eller noe annet ligner på gyldige data. Ingen vits i å fortsette med software-debugging.

Det er jo et godt tegn. Prøv å kjøre hexdump -C /dev/ttyUSB0 elns. Da får du det litt mindre krytpisk slik at det går an å verifisere at pakkene er OK.

Jeg tror " invoke-id-and-priority" er nokså meningsløst ifm denne type meldinger som kringkastes fra måleren. Det gir bare mening når du begynner å sende requests du vil ha svar på. Ser at de forskjellige leverandørene varierer mellom 40 00 00 00 og 00 00 00 00. Hvis man skal tro på koden i https://github.com/Gurux/Gurux.DLMS.Net/blob/master/Development/GXDLMS.cs#L80 (og det er jeg tilbøyelig til...) så er forskjellen service class confirmed eller non-confirmed. Jeg ser ikke at hvordan det gir noen som helst mening i denne konteksten.... Like greit å ignorere hele feltet. Og strengt tatt er vel 00 lengden på "DateTime" feltet. Dvs at det ikke er noe tidsstempel her. Alternativer er 0C. En av leverandørende hadde vel også en feil der det dukket opp en ekstra type-kode (09) i denne posisjonen. Den skulle ikkke vært der.

I følge http://www.m-bus.com/mbusdoc/md4.php er minimumskravet "the bus voltage in the Space state must at no point in a segment fall below 12 V, because of the remote powering of the slaves" når du tar høyde for tap i kabling, forbruk i slaver osv. Jeg er usikker på hvilke krav NVE egentlig stiller til bussen, men dette er jo åpenbart designet for en enkelt slave og relativet kort kabel. Så det er godt mulig at det er innafor med 12V der du måler. Slavene må uansett være forberedt på det.

Kikket kjapt på https://github.com/ossno/mbusparser/blob/master/parser.js og den vil jo si det der nesten uansett. Eneste unntak er hvis alt tilfeldigvis skulle virke ? Men du kan jo utvide kode-eksempelet med litt mer debug info. Alternativt så ser det ut for meg som om de bare leverer deg de rå pakkene fra måleren via USB-porten, men base64-kodet. Gjetter på at det er slik de sender dem over nettet også for å unngå å sløese bort elektroner på parsing/prosessering. Så du kan jo bare plugge base64-dekoding inn foran en hvilken som helst av de andre ams-applikasjonene fra dette forumet.

Så lenge USB-tilkobling er et alternativ så er jo ikke strøm noe problem uansett? Da virker jo de billige aliexpress-greiene helt fint og du har "just works" med eller uten Oss. Hva slags nett-tilobling har Oss-brikken når du ikke kobler den via USB? LoRa? NB-IoT? LTE-M? Den funker fra inne i skapet uten annen strøm enn fra HAN-porten?

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

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

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

Ser flott ut. Ville nok også valgt perl eller python om det ikke var for at jeg planla å kjøre dette på et aksespunkt der ingen av disse var installert fra før. Det blir veldig mye bloat av et lite script hvis du må installere et helt script-rammeverk for å kjøre det ? Jeg er forsåvidt med på tankegangen om å gjøre det enkelt ved å bare pipe videre, men når du piper til mosquitto_pub så må du jo etablere en ny sesjon til brokeren for hver eneste melding. Det spiller kanskje ikke så stor rolle hvis du bare skal håndtere én måler. Men det føles likevel som litt unødvendig mye overhead... Har du vurdert AnyEvent::MQTT eller tilsvarende? Bruker det for en del jobbting og det funker jo rimelig greit.

Tja, kommer vel litt an på hvor du kommer fra tror jeg. WiFi er enkelt fordi du kan det og allerede har aksesspunktet. Men BLE er jo egentlig kjempeenkelt i forhold. Ihvertfall så lenge du kan forholde deg til GATT og ikke må implementere hele stacken under selv. Uansett var ikkepoenget at softwaren skulle bli enklere, men at BLE kan gjøres med vesentlig mindre effektbehov enn WiFi. Dermed blir hardwaren muligens en del enklere. Kanskje. Det er ren synsing fra min side. Jeg har ikke tenkt å bygge dette selv. ?

Bare for å blande meg inn i noe jeg ikke har peiling på, men.... Dere har ikke vurdert å bruke Bluetooth Low Energy ut av skapet? Det synes en smule enklere - på papiret iaffal. Energi-budsjettet med WiFi blir vel noget stramt? Jeg innbiller meg at 3.3V forsyningen fra en TSS721A kan være nok til å drive en TI CC2541 (f.eks en HM-11 modul) direkte, gitt en tilstrekkelig stor kondensator til at du får sendt en hel pakke.

FWIW så har jeg et adapter som ligner det fungerende, kjøpt på eBay: https://www.ebay.com/itm/173715712894 Nå har jeg bare testet dette på Aidon, men det virker utmerket der ihvertfall. OBS: Forsendelsen tok litt lang tid. Ca 1 måned. Mulig det var tilfeldig, men bare så jeg ikke lurer noen til å kaste seg over dette som en quickfix....

Det ser helt riktig ut. Verdiene må skaleres. Dette leser du litt mellom linjene i liste-definisjonen i "Kamstrup_V0001 181022" . På side 3 oppgir de enhet, oppløsning og "format". Både oppløsning og format ser ut til å egentlig angi skalering. Så når det står: så mener de egentlig at tallverdien må deles på 100 for å få verdien i A, med en oppløsing på 0.01A.

Takk for bekreftelsen. Da var det som jeg trodde. Makes sense Ser at jeg burde vært her før og plukket opp standardene. Jaja, de dukker vel opp igjen en gang. Jeg vet jo heller ikke akkurat hva vi skal benytte denne infoen til. Aidon sender altså fullstendig selv-definerende pakker med OBIS-koder, enhet og ekpsonent. Så vi kan parse dem uten å kjenne til noen pre-definert OBIS-liste. Men den finnes, og dermed er både enheter og skalering låst så vidt jeg kan skjønne. Og vi må jo fremdeles forholde oss til disse listene for å støtte de andre leverandørene, selv om vi i teorien kunne droppet den for Aidon EDIT: nå var jo dette godt for noe da: Det gjorde det åpenbart at jeg parset "integer" feil. Håndteringen av fortegn for integer på 8 eller 16 bit var lbak mål. En 8bit signed int kan jo aldri bli "255"... Og -1 gir litt mer mening som eksponent. Trenger jo å renske litt opp i koden, men har ihvertfalll pushet en quickfix EDIT2: og siden dette fremdeles kan mappes tilbake, så tok jeg like gjerne med info i "parserdata" objektet. Gjetter samtidig rått og brutalt at 30 = Wh og 32 =VArh. Så nå ser den delen av en "liste 3" pakke fra Aidon slik ut (korrigering av type for MeterTime skjer senere, så derfor ser den litt uggen ut): { "obis-0":"1-0:1.7.0.255", "double-long-unsigned-1":674, "structure-2":{ "integer-0":0, "enum-1":"W" } }, { "obis-0":"1-0:2.7.0.255", "double-long-unsigned-1":0, "structure-2":{ "integer-0":0, "enum-1":"W" } }, { "obis-0":"1-0:3.7.0.255", "double-long-unsigned-1":0, "structure-2":{ "integer-0":0, "enum-1":"VAr" } }, { "obis-0":"1-0:4.7.0.255", "double-long-unsigned-1":109, "structure-2":{ "integer-0":0, "enum-1":"VAr" } }, { "obis-0":"1-0:31.7.0.255", "long-1":27, "structure-2":{ "integer-0":-1, "enum-1":"A" } }, { "obis-0":"1-0:71.7.0.255", "long-1":28, "structure-2":{ "integer-0":-1, "enum-1":"A" } }, { "obis-0":"1-0:32.7.0.255", "long-unsigned-1":2462, "structure-2":{ "integer-0":-1, "enum-1":"V" } }, { "obis-0":"1-0:52.7.0.255", "long-unsigned-1":2445, "structure-2":{ "integer-0":-1, "enum-1":"V" } }, { "obis-0":"1-0:72.7.0.255", "long-unsigned-1":2463, "structure-2":{ "integer-0":-1, "enum-1":"V" } }, { "obis-0":"0-0:1.0.0.255", "octet-string-1":"\u0007�\u0005\u001d\u0003\n\u0000\u0000�\u0000\u0000\u0000" }, { "obis-0":"1-0:1.8.0.255", "double-long-unsigned-1":3867449, "structure-2":{ "integer-0":1, "enum-1":"Wh" } }, { "obis-0":"1-0:2.8.0.255", "double-long-unsigned-1":0, "structure-2":{ "integer-0":1, "enum-1":"Wh" } }, { "obis-0":"1-0:3.8.0.255", "double-long-unsigned-1":4929, "structure-2":{ "integer-0":1, "enum-1":"VArh" } }, { "obis-0":"1-0:4.8.0.255", "double-long-unsigned-1":139370, "structure-2":{ "integer-0":1, "enum-1":"VArh" } } Eksponent, typer og verdier stemmer overens her, men jeg registrerer at de ikke stemmer helt med det Aidon har dokumentert til NVE, der W, VAr, Wh og VArh alle har et k prefiks og tilsvarende juster eksponent. Jada, det er pirk ?

Er en stund siden du psotet dette, så du har kanskje allerede løst problemet? Men i tilfelle ikke: Her har det skjedd noe galt med avlesningen din. Starter veldig bra med frame marker, HDLC header, LLC header, og en god del av data-notfication payload: 7e a0e2 2b 21 13 239a e6e700 0f 00 00 00 00 0c 07e304040410381eff800000 02 19 0a 0e 4b616d73747275705f5630303031 09 06 0101000005ff 0a 10 35373036353637323035353936323835 09 06 0101600101ff 0a 12 36383431313231424e323433313031303430 09 06 0101010700ff 06 00002173 09 06 0101020700ff 06 0000c006 De to første bytene etter date-time feltet (linjen som starter med 0c) angir at resten av pakken skal bestå av en struct med 25 felt. Oddetall er forventet ettersom listenavnet kommer alene først, etterfulgt av par med en OBIS-kode og en verdi. Du skulle altså hatt 12 verdier i denne pakken. Men det kommer altså bare 4 før det brekker fullstendig: f006fcfe0680ff06c0db89c7feff1280ff0906c1ffff1280fe Det der gir jo ingen mening i det hele tatt, og det mangler åpenbart mye. Bare 8 OBIS-koder med type og lenge blir jo 64 byte, mens du her bare har 25 byte. I følge lengde-feltet i HDLC-headeren så skulle jo hele pakken også vært på 226 byte. kan tenkes at avslutingen er en korrekt sjekksum, men det er jo ikke så lett å verifiser når vi ikke kjenner hele pakken: f21d 7e

Jeg innser at verden neppe har behov for enda et slikt program, men jeg er protokoll-nerd og klarte ikke helt å være fornøyd med en strategi der du bare finner verdier basert på relativ posisjon eller evt et søk etter OBIS-koden som en byte-sekvens. Måtte bare tygge tilstrekkelig på disse DLMS/COSEM pakkene til å forstå hele strukturen ? Resultatet finner dere her: https://github.com/bmork/obinsect Jeg kjører denne på et Ubiquity UniFi AP AC Pro aksesspunkt med OpenWrt, ettersom det allerede stod ganske nær sikringsskapet og hadde en ledig USB-port, med en slik dings til selve HAN-tilkoblingen: https://www.ebay.com/itm/173715712894 Dette er altså en HAN til MQTT proxy som antageligvis er noe mer fleksibel enn de fleste andre alternativene, ettersom jeg først parser hele pakken og bygger opp en slags kopi som et JSON object. Deretter bruker jeg en konfigurerbar del av dette objektet i en eller flere MQTT-meldinger. Dvs at det er mulig å publisere et variabelt sett med variable til flere MQTT emner, basert på den samme input-pakken fra måleren. For "effektivitetens" skyld postes selvsagt ingenting til emner som ikke inneholder oppdaterte variable. F.eks. poster jeg akkurat nå alle målerverdiene med to forskjellige nøkkelsett: OBIS kode og et alias for OBIS-koden (dette er selvsagt ikke så nyttig, men illustrerer mulighetene): { "1-1:0.2.129.255": "AIDON_V0001", "0-0:96.1.0.255": "7359992895319515", "0-0:96.1.7.255": "6525", "1-0:1.7.0.255": 0.9470000000000001, "1-0:2.7.0.255": 0, "1-0:3.7.0.255": 0, "1-0:4.7.0.255": 0.047, "1-0:31.7.0.255": 3.7, "1-0:71.7.0.255": 3.9000000000000004, "1-0:32.7.0.255": 247.70000000000002, "1-0:52.7.0.255": 246.60000000000002, "1-0:72.7.0.255": 247.20000000000002, "timestamp": 1559131080 } { "ListId": "AIDON_V0001", "SerialNumber": "7359992895319515", "Model": "6525", "Power": 0.9470000000000001, "PowerExport": 0, "ReactivePower": 0, "ReactivePowerExport": 0.047, "CurrentL1": 3.7, "CurrentL3": 3.9000000000000004, "VoltageL1": 247.70000000000002, "VoltageL2": 246.60000000000002, "VoltageL3": 247.20000000000002, "timestamp": 1559131080 } Samtidig poster jeg også litt andre data-sett fra de samme pakkene til litt andre MQTT emner. F.eks. sender jeg øyeblikkseffekten alene til et emne som er eksportert via en websocket lister, slik at jeg kan bruke det direkte fra paho mqtt klienten i en browser. Siden dette bare er en verdi, så blir denne ikke wrappet i JSON (selv om det jo forsåvidt fremdeles er gyldig JSON): $ mosquitto_sub -v -h 192.168.0.1 -t /obinsect/websocket/\# /obinsect/websocket/power 0.95100000000000007 /obinsect/websocket/power 0.94900000000000007 /obinsect/websocket/power 0.94600000000000006 Som dere sikkert også legger merke til, så skalerer jeg verdiene. Og som vanlig gir flyttallsdivisjon litt stygge tall ettersom det blir litt feil. Dette er basert på OBIS liste-dokumentasjonen fra NVE, der alle ser ut til å sende effekt som W men oppgir at det er kW skalert til et 4.3 format. Dette spiller jo selvsagt liten rolle, men jeg har nå valgt å gjøre det slik. Det kan slås av med en kommanolinje-option om du foretrekker uskalerte verdier. Helst skulle jo selsagt de skalerte verdiene vært vist med korrekt oppløsning, slik at effektene ovenfor var 0.951, 0.949 og 0.946. Men dette er JSON double verdier, og ikke tekst. Dermed blir den slags avrunding/korting opp til JSON parseren. Jeg har forsåvidt også en modus som publiserer verdiene som tekst med enhet, men det er normalt ikke spesielt nyttig siden du da må parse i den andre enden. Men da formatteringen blir penere da. Håper dette kan være nyttig for andre enn meg. Det hjalp ihvertfall meg mye å se COSEM-pakkene som et JSON-object. Spesielt for å skjønne forskjellenen på strukturen de tre leverandørene har valgt. Tar helt til slutt med et ekspempel på hvordan det objektet ser ut for hver av de tre. Dette er ment for debugging og er ikke veldig nyttig som output til vanlig Kamstrup: { "metadata": { "timestamp": 1559132486, "framelength": 226, "framenumber": 1, "srcprog": "./obinsectd", "srchost": "miraculix", "version": "0.01", "serialport": "stdin", "parsetime": 1431 }, "hdlc": { "format": 10, "segmentation": false, "length": 226, "src": 43, "dst": 33, "control": 19, "hcs": 39459, "fcs": 58715 }, "llc": { "lsap": 230, "dsap": 231, "quality": 0 }, "data-notification": { "long-invoke-id-and-priority": 0, "date-time": 946762380, "notification-body": { "visible-string-0": "Kamstrup_V0001", "obis-1": "1-1:0.0.5.255", "visible-string-2": "5706567000000000", "obis-3": "1-1:96.1.1.255", "visible-string-4": "000000000000000000", "obis-5": "1-1:1.7.0.255", "double-long-unsigned-6": 0, "obis-7": "1-1:2.7.0.255", "double-long-unsigned-8": 0, "obis-9": "1-1:3.7.0.255", "double-long-unsigned-10": 0, "obis-11": "1-1:4.7.0.255", "double-long-unsigned-12": 0, "obis-13": "1-1:31.7.0.255", "double-long-unsigned-14": 0, "obis-15": "1-1:51.7.0.255", "double-long-unsigned-16": 0, "obis-17": "1-1:71.7.0.255", "double-long-unsigned-18": 0, "obis-19": "1-1:32.7.0.255", "long-unsigned-20": 0, "obis-21": "1-1:52.7.0.255", "long-unsigned-22": 0, "obis-23": "1-1:72.7.0.255", "long-unsigned-24": 0 } } } Kaifa: { "metadata": { "timestamp": 1559132574, "framelength": 121, "framenumber": 2156, "srcprog": "./obinsectd", "srchost": "miraculix", "version": "0.01", "serialport": "stdin", "parsetime": 33 }, "hdlc": { "format": 10, "segmentation": false, "length": 121, "src": 1, "dst": 513, "control": 16, "hcs": 37760, "fcs": 49191 }, "llc": { "lsap": 230, "dsap": 231, "quality": 0 }, "data-notification": { "long-invoke-id-and-priority": 1073741824, "date-time-bug": true, "date-time": 1505416990, "notification-body": { "octet-string-0": "KFM_001", "octet-string-1": "6970631401753985", "octet-string-2": "MA304H3E", "double-long-unsigned-3": 1176, "double-long-unsigned-4": 0, "double-long-unsigned-5": 131, "double-long-unsigned-6": 0, "double-long-unsigned-7": 2208, "double-long-unsigned-8": 3841, "double-long-unsigned-9": 3794, "double-long-unsigned-10": 2389, "double-long-unsigned-11": 0, "double-long-unsigned-12": 2397 } } } Aidon: { "metadata": { "timestamp": 1559132627, "framelength": 210, "framenumber": 1, "srcprog": "./obinsectd", "srchost": "miraculix", "version": "0.01", "serialport": "stdin", "parsetime": 192 }, "hdlc": { "format": 10, "segmentation": false, "length": 210, "src": 65, "dst": 2179, "control": 19, "hcs": 54914, "fcs": 50400 }, "llc": { "lsap": 230, "dsap": 231, "quality": 0 }, "data-notification": { "long-invoke-id-and-priority": 1073741824, "notification-body": [ { "obis-0": "1-1:0.2.129.255", "visible-string-1": "AIDON_V0001" }, { "obis-0": "0-0:96.1.0.255", "visible-string-1": "7359992890941742" }, { "obis-0": "0-0:96.1.7.255", "visible-string-1": "6515" }, { "obis-0": "1-0:1.7.0.255", "double-long-unsigned-1": 1362, "structure-2": { "integer-0": 0, "enum-1": 27 } }, { "obis-0": "1-0:2.7.0.255", "double-long-unsigned-1": 0, "structure-2": { "integer-0": 0, "enum-1": 27 } }, { "obis-0": "1-0:3.7.0.255", "double-long-unsigned-1": 996, "structure-2": { "integer-0": 0, "enum-1": 29 } }, { "obis-0": "1-0:4.7.0.255", "double-long-unsigned-1": 0, "structure-2": { "integer-0": 0, "enum-1": 29 } }, { "obis-0": "1-0:31.7.0.255", "long-1": 93, "structure-2": { "integer-0": 255, "enum-1": 33 } }, { "obis-0": "1-0:32.7.0.255", "long-unsigned-1": 2500, "structure-2": { "integer-0": 255, "enum-1": 35 } } ] } } Så mens Kaifa bare sender en straight liste med verdier, så sender altså Aidon en liste med objekter, der hvert objekt består av en OBIS kode og en verdi. I tilegg har alle numeriske objekter et objekt med en integer og en enum. Det siste jeg har ikke klart å finne dokumentert hva det betyr. Jeg gjetter på at det er en slags beskrivelse av tallverdien, der enumen kanskje representerer enhet, men det hadde jo vært fint å finne noe dokumentasjon. Nie, jeg kommer nok ikke til å kjøpe noen IEC-standarder. Det er jo noe av de mer ubrukelige dokumenter som finnes. Bare se på det ovenfor og forklar hvordan tre leverandører kunne komme opp med en så totalt forskjellig tolk ning av hvordan pakkene skulle se ut ?