Bjørn Mork

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.

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

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 &l

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 over

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.