Bjørn Mork

Nei, har bare en Kamstrup-måler. Med Pow-K. Problemet forsvant, men dukket opp igjen i natt og så forsvant det igjen etter noen timer. Veldig rart. Men det har vært stabilt siden 02:00 i natt, så da håper jeg det forblir sånn

Pussig sammentreff på fredag 13.? Jeg oppdaget nettopp at jeg mangler data fra Kamstrup-måleren på hytta mellom Fri Aug 13 15:30:02 2021 og Fri Aug 13 19:49:27 2021 Og når jeg logget på min Pow-K nå for en liten stund siden så hadde den en oppetid på kun minutter. Merkelige greier. Den har vært dønn stabil siden jeg fikk den. Loggen fra DHCP-serveren forteller meg at den mest sannsynlig rebootet flere ganger helt umotivert nå rundt kl 20: Aug 13 19:49:27 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15 Aug 13 19:49:27 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 via eth0.15 Aug 13 19:49:27 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 via eth0.15 Aug 13 20:35:53 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15 Aug 13 20:35:53 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 (ams-4a15) via eth0.15 Aug 13 20:35:53 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 (ams-4a15) via eth0.15 Aug 13 20:35:53 idefix dhcpd[860] DHCPACK on 192.168.15.9 to 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15 Aug 13 20:36:06 idefix dhcpd[860] DHCPDISCOVER from 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15 Aug 13 20:36:06 idefix dhcpd[860] DHCPOFFER on 192.168.15.9 to 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15 Aug 13 20:36:06 idefix dhcpd[860] DHCPREQUEST for 192.168.15.9 (192.168.15.1) from 50:02:91:e0:4a:15 (ESP-E04A15) via eth0.15 Aug 13 20:36:06 idefix dhcpd[860] DHCPACK on 192.168.15.9 to 50:02:91:e0:4a:15 (ams-4a15) via eth0.15 Bug i firmware på Kamstrup? Eller samtidige firmware-oppgraderinger?

Uhm, ja, men da skal du helst ikke ha for strømkrevende USB-duppeditter. Evt få strøm fra et annet sted enn USB. 5V er ikke all verden når kabelen blir lang (og tynn, som USB kabler gjerne er). Kan anbefale å erstatte SD-kortet med en USB3 minnepinne på RPI4. Vanskelig å merke forskjell i opplevd IO-ytelse fra en PC med SSD. Dessuten mye enklere å flytte over til en laptop ved behov for å rette opp feilkonfigurasjon av bootloader eller tilsvarende.

Nå har jeg også meldt meg inn i klubben av strålende fornøyde kunder. Var heldig nok til å få kjøpe et ferdig kort, siden hverken evner eller utstyr tillater lodding på dette nivået. Det var plug-and-play for meg også. Svært enkelt å både installere og konfigurere. Som mange andre her så har jeg akkurat nok erfaring med hobby-prosjekter til å kjenne mine egne begresninger altfor godt. Det som imponerer meg stort med dette prosjektet er den utholdenheten som demonstreres gjennom finish både på hardware og software. Selv har jeg en lei tendens til å gå lei når noe virker på proof-of-concept stadiet. Dvs at hardware-utviklingen stopper på et breadboard med ledninger hit og dit og lodding som ikke ser ut i måneskinn. Og software får aldri noensinne et annet brukergrensesnitt enn et minimum for debugging. Dokumentasjon er noe som kan "gjøres senere". Derfor imponerer det stort når noen tar seg bryet med å designe og produsere hardware som ser så proff ut at det er bare er fraværet av feil som skiller det fra et komersielt produt, eller software som både ser veldig bra ut og som fungerer så bra at det åpenbart må være utviklet av noen som faktisk bruker produktet selv. Var forresten litt skeptisk til hvor bra WiFi kom til å virke inne i det gamle og svært solide stålskapet uten særlig mange hull, med rundt 10 meter, noen vegger og et etasjeskille til nærmeste AP. Men det funket også over all forventning. Ingen problemer å bruke modulen med lukket skap. Ser en RSSI på mellom -75 og -80 dBm et sted. Det synes jeg er helt innafor.

Interessant. Da forsvant resten av systemet. Ja, det er helt uforståelig. Jeg har Viken Fiber og har hatt det siden 2012. De første årene med en ZyXEL P2812 som hjemmesentral og en 100 Mbit mediakonverter fra Ping. Ca 2015(?) oppgraderte de til gigabit (vi snakker link-hastighet nå, ikke produkt) og vi fikk da en HET-3012 dual-rate 100/1000 media-konverter. Da benyttet jeg sjansen til å erstatte hjemmesentral og mediakonverter med et oppsett temmelig likt tegningen din. Det fungerte helt fint i 5 år, inkludert flytting av hele opplegget til en annen leilighet Men i januar i fjor fikk vi pushet på oss en VMG i stedet for HET+P2812 som en del av borettslagets fellesavtale. Jeg forsøkte meg på å bytte eske mot eske, siden jeg helst så at jeg slapp å demontere mitt fungerende nettverk. Montøren ble litt overrasket og måtte ta en telefon for å sjekke om det var OK, men det endte med at han måtte skru opp VMGen på veggen og koble den til. Bortkastet men greit nok, tenkte jeg. Overraskelsen var stor når jeg koblet tilbake til mitt utstyr, og TVen ikke lenger virket. Snooping avslørte at dekoderen ikke fikk noen ip-adresse. Koblet inn VMG og alt virket. Kjørte dhclient manuelt på VLAN 101 fra en Linux-PC med VMGens mac - og det fungerte. Prøvde dhclient med en annen mac - og det fungerte. Prøve dhclient med dekoderens mac - fungerte ikke. Jeg ser ingen annen forklaring enn at Viken har lagt på et filter for å blokkere direkte bruk av dekoder på VLAN 101. De har sikkert en grunn som gir mening for dem. Jeg endte opp med et betydelig mer komplisert oppsett for å oppnå det samme jeg hadde før: TV-dekoder isolert på sitt eget lille VLAN. Det krever nå en router med igmpproxy mellom dekoder-VLAN og (Vikens) VLAN 101. Routeren bruker en mac-adresse som ligner på VMG, men er slightly forskjellig (slik at jeg skal kjenne den igjen) Samboer skaffet seg nylig hytte med VIken fiber også, men der har vi ikke TV så jeg får ikke testet om det er samme opplegg. Men der fikk jeg ihvertfall testet gjenbruk av SFP fra VMGen. Den funket helt fint i en ZyXEL GS1900-10HP switch (med OpenWrt - har ikke prøvd med original firmware, men jeg vil tro det virker).

Jeg trakk en med dupleks LC fra huset til hageboden for noen år siden. Nå ligger det jo et 50mm rør i bakken der så akkurat den delen var ikke noe problem. Men inne i både hus og bod har jeg noen korte strekk med 20mm rør. Det holder, men jeg tror også det er minimum. Mulig du kan få gjennom mer enn ett par dersom du velger "staggered" terminering, slik at ikke alle LC-konnektorene ligger ved siden av hverandre? Har ikke prøvd. FWIW, å brukte jeg for sikkerhets skyld en vanvittig mekanisk overbeskyttet kabel av denne typen med ferdig trekkestrømpe: https://www.fs.com/de-en/products/70402.html Må innrømme at jeg falt for "Rodent Resistance" 🙂 Har nå ikke testet det siden den stort sett ligger i rør uansett. Kabelen var ihvertfall en drøm å trekke. Solid som faen, og likevel ekstremt myk og fleksibel. Og trekkestrømpa beskyttet konnektorene under trekkejobben. Kan anbefales om du har tid til å vente og vil ha en kabel som ikke går fløyten om rottene går help amok. Eller katta. Og hvis det er noe jeg angrer litt på så er det at jeg trakk multimode. Tanken var vel noe sånt som at det ikke spiller noen rolle - nok båndbredde uansett. Og jeg hadde både SX SFPer og SR/SX dual-rate SFP+ liggende - så det var fint å utnytte. Dessuten er multimode visstnok litt mer temperaturgunstig pga lavere effekt, og det så jeg for meg var en fordel siden jeg terminerte hus-enden av linken i et PCIe-kort i en PC. Problemet viste seg i fjor da jeg byttet ut medakonverteren i boden med en switch (ZyXEL GS1900-10HP) som jeg kjørte OpenWrt på. Det medførte litt fikling i oppstartsfasen, for å si det forsiktig. Da skulle jeg veldig gjerne hatt mer enn det ene fiberparet ut dit. Litt krøkkete når du river ned den eneste forbindelsen med omverden, og ikke vet om den kommer opp igjen etter reboot. Endte opp med å legge en laptop med et mobilmodem der ute til løsningne var stabilisert. Det hadde jo vært litt enklere om jeg hadde hatt single mode og kunne kjørt 2 BiDi-linker, eller evt hadde hatt flere multimode-par.

Vil anbefale fs.com. Null tull, rask leveranse og gode produkter. https://www.fs.com/de-en/products/39135.html Velg evt "customised" hvis du vil ha SC-konnektor (slik Altibox bruker) Har du en VMG hjemmesentral kan du jo også bare bruke den SFPen som står i der. Dette er dessverre ikke korrekt lenger for kunder som er oppgradert til nyere hjemmesentraler. Altibox aktiverer da et macadresse-filter, enten på DHCP-server eller et annet sted i nettet, som blokkerer direkte tilgang fra dekoderne. Hvis du har en slik løsning fra Altibox så må du ha en router mellom dekoder og VLAN 101. Denne routeren må nødvendigvis kjøre igmpproxy for at multicast/linjær-TV skal virke. Det er litt uklart hvilke mac-adresser som blir akseptert av filteret. Det eneste som er sikkert er at det blokkerer dekoderne. Det enkleste er å bare spoofe adressen som står på hjemmesentralen. Ja, jeg vet at dette virker rart og helt ubegripelig. Jeg var også lykkelig uvitende om det med en løsning som den du skisserer, inntil jeg fikk prakket på meg en VMG fra Altibox. Da sluttet TVen å virke når jeg koblet tilbake til min egen løsning, fordi dekoderen ikke lenger fikk noen ip-adresse fra Altibox. Så unngå for all del å oppgradere hjemmesentralen dersom du har en slik løsning med switching av VLAN 101. Da beholder du fleksibiliteten.

Er det noen som har oversikt over hvordan forskjellige kommuner ser på dette med nøkkel til vannmåleren? Det hadde vært nyttig med info om hvem som gir fra seg nøkkel, og i så fall riktig kontaktpunkt. Har nylig endt opp i en feriebolig i Asker (gamle Hurum kommune), og har da gleden av en slk fancy måler med w-mbus. Bruker et generisk rtl2832u adapter sammen med rtl-sdr, rtl_wmbus og wmbusmeters slik som mange andre her, og klarer fint å lese data fra måleren (samt fra en del naboers Kamstrup-målere). Vår måler er en Qualcosonic F1 som dette: https://www.axiomametering.com/en/products/water-metering-devices/ultrasonic/qalcosonic-f1-ultrasonic-water-meter Typisk output fra wmbusmeters er: (serial) received ascii "T1;1;1;2021-06-24 10:24:07.000;133;135;00129731;0x3e4409073197120008167a4f00300561f96352e74b19936f378dfe46b6132b13b789a6671dbea3bb83916af8143edea2412799fa1146528d72ec45f0c4c5b7<0A>T1;1;1;2021-06-24 10:24:07.000;153;156;00129731;0x3e4409073197120008167a4f00300561f96352e74b19936f378dfe46b6132b13b789a6671dbea3bb83916af8143edea2412799fa1146528d72ec45f0c4c5b7<0A>" (rtlwmbus) checkRTLWMBusFrame "T1;1;1;2021-06-24 10:24:07.000;133;135;00129731;0x3e4409073197120008167a4f00300561f96352e74b19936f378dfe46b6132b13b789a6671dbea3bb83916af8143edea2412799fa1146528d72ec45f0c4c5b7<0A>T1;1;1;2021-06-24 10:24:07.000;153;156;00129731;0x3e4409073197120008167a4f00300561f96352e74b19936f378dfe46b6132b13b789a6671dbea3bb83916af8143edea2412799fa1146528d72ec45f0c4c5b7<0A>" (rtlwmbus) received full frame (wmbus) parseDLL @0 63 (telegram) DLL L=3e C=44 (from meter SND_NR) M=0709 (AXI) A=00129731 VER=08 TYPE=16 (Cold water meter) (driver q400) DEV=rtlwmbus[00000001] RSSI=133 (wmbus) parseELL @10 53 (wmbus) parseAFL @10 53 (wmbus) parseTPL @10 53 (telegram) TPL CI=7a ACC=4f STS=00 CFG=0530 (AES_CBC_IV nb=3 cntn=0 ra=0 hc=0) Received telegram from: 00129731 manufacturer: (AXI) UAB Axis Industries, Lithuania (0x709) type: Cold water meter (0x16) ver: 0x08 device: rtlwmbus[00000001] rssi: 133 dBm driver: q400 (wmbus) 00: 3e length (62 bytes) (wmbus) 01: 44 dll-c (from meter SND_NR) (wmbus) 02: 0907 dll-mfct (AXI) (wmbus) 04: 31971200 dll-id (00129731) (wmbus) 08: 08 dll-version (wmbus) 09: 16 dll-type (Cold water meter) (wmbus) 0a: 7a tpl-ci-field (EN 13757-3 Application Layer (short tplh)) (wmbus) 0b: 4f tpl-acc-field (wmbus) 0c: 00 tpl-sts-field (OK) (wmbus) 0d: 3005 tpl-cfg 0530 (AES_CBC_IV nb=3 cntn=0 ra=0 hc=0 ) telegram=||3E4409073197120008167A4F00300561F96352E74B19936F378DFE46B6132B13B789A6671DBEA3BB83916AF8143EDEA2412799FA1146528D72EC45F0C4C5B7|+2242 (rtlwmbus) checkRTLWMBusFrame "T1;1;1;2021-06-24 10:24:07.000;153;156;00129731;0x3e4409073197120008167a4f00300561f96352e74b19936f378dfe46b6132b13b789a6671dbea3bb83916af8143edea2412799fa1146528d72ec45f0c4c5b7<0A>" (rtlwmbus) received full frame Men her kommer man jo ikke videre uten riktig AES-nøkkel. Vurderer å prøve kommunens kundeservice, men ser for meg at det er kan bli vanskelig nok å forklare problemstillingen. En tilleggsutfordring er jo at de tilbyr fjernavlesing av vannmåleren vha "Netti": https://hurumkraft.no/produkt/netti-iot-gateway-visning-vannmaler-effekt-utnytter-han-porten/ Slik sett har de jo sitt på det tørre(pun intended) om de påstår at jeg har tilgang på dataene. Jeg er bare ikke så interessert i en skybasert app-løsning. Som jeg vet det er stor forståelse for her i dette forumet, men ikke så mange andre steder i verden dessverre 🙂 EDIT: tenkte forresten tanken at jeg kunne prøve å koble opp nettien via en mitmproxy-løsning for å se om den får nøkkel via et eller annet API som kan misbrukes. Men så slo det meg at den mest sannsynlig bare forwarder w-mbus direkte uten å bry seg med dekryptering. Så den idéen er nok dødfødt

Har strukket nettverkskabel ut av skapet. Manglet forskriftsmessig tetning av eksisterende gjennomføringer når dette ble gjort, så det var en enkel ting å gjøre ? Tetning er på plass nå etter at tilsyn påpekte problemet. Og da ble det jo tettet med nettverks-kabelen installert. Gjorde det ikke slik primært pga ønske om å ha dingsen utenfor, men fordi det var noen meter fra skapet og bort til USB-porten den skulle kobles til. Valget mellom lang HAN-kabel eller lang USB-kabel er enkelt.5V er ikke mye og blir gjerne litt for lite om kabelen er lang.

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