Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

Tubez

Medlemmer
  • Innlegg

    83
  • Ble med

  • Besøkte siden sist

Innlegg skrevet av Tubez

  1. 3 timer siden, roarfred skrev:

    Jeg tror det er slik at den første byte forklarer dataformatet. Dvs 07=dato, 09=string, 06=int (32 bit)

     

    Hver av disse har så sin egen definisjon av de påfølgende bytes. Eks trenger ikke 06 si hvor mange bytes som følger. 07 er nok et definert datoformat der det settes av 2 bytes (16 bit) til årstall. 07 D0 må dermed sees i sammenheng og gir 2000. Se mine data, så stemmer det godt

     

    Ja, jeg er enig i at første byten forteller noe om dataformatet, og så ser ut som at byte 2 skal fortelle om antall bytes dataen består av eller ikke. Dette ser man i for eksempel når man får avleste verdier, så står denne til 0600000524. Så kanskje skal alle avleste verdier være oppført som 0600 000524? I dette tilfellet er allerede 06 definert til å Unsigned 32, og man trenger da ikke å gi noe ytterlige informasjon om antall bytes, derfor er byte 2 satt til "00"? Eller så har de bare droppet å gi ytterlige informasjon om denne og denne skal være oppført som 06 00000524?

     

    Etter å hatt lest litt så ser jeg at du har nok rett i det med datoen, for i henhold til Bluebook: 

    "OCTET STRING (SIZE(12))

    {

    year highbyte,

    year lowbyte,

    month,

    day of month,

    day of week,

    hour,

    minute,

    second,

    hundredths of second,

    deviation highbyte,

    deviation lowbyte,

    clock status

    }

    The elements of date and time are encoded as defined above. Some may be set to “not specified” as defined above. In addition: deviation: interpreted as long"

    • Like 1
  2. Ja jeg ser den, men jeg får det fortsatt ikke til å stemme. Hvis du ser på Kamstrup så starter denne med 0C07. Den tar heller ikke med FF800000 i samme streng.

     

    Det som jeg også har sett, er at i de tilfellene en sekvens starter med 09 (An orderes sequence of octets (8 bit bytes)), så tar han for seg byte for byte. Det vil si at 07D0 skal sees på som 07 = 7 og D0 = 320... Eller hvis man ser hele samlet så blir dette "07E1090C02171232FF800000" = "1760411030010270444000000000000". Dette ser du stemmer med følgende:

    0907 4B464D5F303031 = KFM_001

    0908 4D41333034483345 = MA304H3E

  3. Kan 0F 40000000 være "SND_NKE 0100 0000 40 Short Frame Initialization of Slave"? http://www.m-bus.com/files/MBDOC48.PDF side 24.

     

    Jeg ser også at de 12 første bytes i serien er definert som header (som du også sa). Så da tenker jeg at 0F 40000000 sier noe om formatet (i dette tilfelle "Short Frame")?

     

    Edit: jeg leste nylig på m-bus.com at "0F" kan bety: "Start of manufacturer specific data structures to end of user data", om det har noen betydning. 

  4. Hei igjen

     

    Jeg har sett over de dataene du har mottatt, og jeg kom da fram til følgende (se under).

     

    Det jeg ser er at E7 og E6E700 i rad 1 er identisk hele veien og med Kamstrup sitt eksempel. 0F er også lik for alle, inklusiv Kamstrup. Det jeg ikke er helt enig i er Dato og tid. For denne strengen er ikke lik for Kamstrup. Videre så har dato og tid en egen kode i BB12 (tabell 2 side 34). Denne avsluttes også med FF800001 på Kamstrup sitt eksempel. 

    [2017-09-12 23.18.43.731 - Received 41 (0x29) bytes]
    7E A027 01 02 01 10 5A87 E6E700

    0F 40000000

    090C 07E1090C0217122AFF800000 Kommentar: Dato og tid (2017-09-12, 02 = tirsdag, kl 23:18:42). FF800000 ukjent.

    0201 Kommentar: Struktur med 1 objekt. http://dlms.com/documents/Excerpt_BB12.pdf Tabell 2 side 34.

    0600000528 Verdi: “1320” W

    B80C 7E


    [2017-09-12 23.18.45.739 - Received 41 (0x29) bytes]
    7E A027 01 02 01 10 5A87 E6E700

    0F 40000000

    090C 07E1090C0217122CFF800000 Kommentar: Dato og tid

    0201 Kommentar: Struktur med 1 objekt.

    0600000524 Verdi: “1316” W

    19C1 7E


    [2017-09-12 23.18.47.732 - Received 41 (0x29) bytes]
    7E A027 01 02 01 10 5A87 E6E700

    0F 40000000

    090C 07E1090C0217122EFF800000 Kommentar: Dato og tid

    0201 Kommentar: Struktur med 1 objekt.

    0600000535 Verdi: “1333” W

    AAC2 7E


    [2017-09-12 23.18.49.724 - Received 41 (0x29) bytes]
    7E A027 01 02 01 10 5A87 E6E700

    0F 40000000

    090C 07E1090C02171230FF800000 Kommentar: Dato og tid

    0201 Kommentar: Struktur med 1 objekt.

    0600000527 Verdi: “1319” W

    C0E9 7E


     

    [2017-09-12 23.18.51.733 - Received 123 (0x7B) bytes]
    7E A079 01 02 01 10 8093 E6E700

    0F 40000000

    090C 07E1090C02171232FF800000 Kommentar: Dato og tid

    020D Kommentar: Struktur med 13 objekter.

    Objekt 1: 0907 4B464D5F303031 Output: “KFM_001”, OBIS liste

    Objekt 2: 0910 36393730363331343031373533393835 Output: “6970631401753985”, Måler-ID.

    Objekt 3: 0908 4D41333034483345 Output: “MA304H3E”, Type måler.

    Objekt 4: 0600000524 Verdi: “1316” Active power [W] (+)

    Objekt 5: 0600000000 Verdi: “0” Active power [W] (-)

    Objekt 6: 0600000000 Verdi: “0” Reactive power [VAr] (+)

    Objekt 7: 0600000081 Verdi: “129” Reactive power [VAr] (-)

    Objekt 8: 06000006D2 Verdi: “1746” Strøm fase 1 [mA]

    Objekt 9: 06000011D5 Verdi: “4565” Strøm fase 2 [mA]

    Objekt 10: 0600001268 Verdi: “4712” Strøm fase 3 [mA]

    Objekt 11: 0600000960 Verdi: “2400” Spenning U1-N [V]  (xxx.x V)

    Objekt 12: 0600000000 Verdi: “0” Spenning U2-N [V] (xxx.x V)

    Objekt 13: 0600000962 Verdi: “2402” Spenning U3-N [V] (xxx.x V)
    4BDB 7E

    • Like 1
  5. 10 timer siden, roarfred skrev:

    Jeg er usikker på hva som ligger i 0A dataene. Mulig interessant.

     

    Tenker du på 0A i rad 5 og 6? Det er måler ID og type måler. 

     

    Det som jeg lurer på i A0 i rad 1 kan være en tekststreng med E2 bytes? Edit: nei,  tviler på at der skal være 226 bytes i den strengen xD... 

     

    Det jeg ikke klarer å finne ut av er hva som foregår på rad 2... 

  6. Ja, hvis netteieren her hadde aktivert utgangen så kunne jeg fått målt. 

     

    Jeg har prøvd å se om jeg finner ut om de kodene i det eksempelet til Kamstrup, men har bare klart å komme så langt til nå: image.thumb.png.59d9eed2e757b533e74dec617114d9c5.png 

     

    Det jeg vet er at alle de blanke tekstene i midten, er som du sier, henviser til OBIS koden. 

     

    Det jeg også har sett er at "7E" (antar start flag), "2B", "21", "13", "E6E700" i første rekke er like i alle 3 eksemplene, samme gjelder for "0F" og "00000000" i rekke 2. 

    De siste "5BE5" må være frame check og "E7" er da end flag eller noe i den duren.

     

    Fant du ut noe mer angående Class 40?

  7. Jeg har lest litt mer i det dokumentet med eksempelkodene fra Kamstrup, og der nevner de DLMS klassen de benytter seg av, class 40. PPP er class 44 så det kan vell være en av årsakene til at ting ikke stemmer?

     

    Har prøvd å finne ut litt mer om Class 40 men fant kun dette: https://www.kalkitech.com/news_releases/January15_Newsletter/page5.html

    Sitat

    We have also released a new Interface class (IC: 40) for push setup. This "Push setup” interface class contains a list of references to COSEM object attributes to be pushed. It also contains the push destination and method as well as the communication time windows and the handling of retries.

     

    Fant også denne siden her: http://www.gurux.fi/gurux.dlms Her ser det ut som at de har laget koder i Java for å avlese målere, men usikker på hvordan DLMS klasse de har skrevet den til.

     

    Edit:

    Fant også Github siden deres: https://github.com/Gurux/Gurux.DLMS.Net

  8. Ja for jeg får det heller ikke til å stemme, men det er veldig rart hvis de mikser sammen 2 ulike protokoller? 

     

    Det som er rart er at start/stop framen som du mottar en konstant (7E), mens i henhold til M-bus skal startframen være 68 og endframe 16 (hex)... 

     

    Edit: Ahh ofc. M-bus standarden tar kun for seg kommunikasjonen mellom Master-Slave og Slave-Master. Den tar jo ikke høyde for at Slave skal sende signal til en "avleser"... Kan det ha noe med saken å gjøre at de bruker PPP sammen med M-bus? 

  9. Jeg har lest litt i det dokumentet på m-bus.com, og de sier at "data link layer" er basert på ICE870-5. Ikke at jeg klarte å finne ut hva standarden sier, men jeg fant denne fra abb: https://library.e.abb.com/public/b4ee801d21d685b5c1257b1300569705/rec523_IECprotENd.pdf

     

    Og jeg fant denne også: http://www.geocities.jp/ps_dictionary/standard/cpaper/IEC-R20_1.pdf

     

    Er det noe du kan bruke der?

  10. Jeg prøvde å legge inn denne kretsen i Multisim for å se hva man fikk ut ved utgangen før jumperen, må si at den funket bra :)

     

    Når V1 var 27 V, så hadde den en utgangspenning på 3,3 V, men hvis V1 var 15 V, så var utgangspenningen på 24,7 mV :)

     

    Linken til hele finner dere her:

    https://www.multisim.com/content/iSJDMGe7kyn5H4gC5s79kh/ams-reader/open

     

    Edit:

    Som man ser så har jeg lagt inn V2 og V4 her som konstant spenningskilde på 27 V, men denne spenningen er vell egentlig hentet ut fra utgangen fra HAN? Og den vil jo variere sammen med V1 her`?

     

    image.thumb.png.3aa49c4bb91a458ebc217f9f354e8244.png

    • Like 1
  11. Kan sikkert være lurt å skille på digital jord og "sann" jord, for i tegningen er det tegnet som "sann" jord, noe som, i dette tilfellet, er i sikringsskapet, mens i denne kretsen så er man interessert i digital jord? 

     

    Ikke at det har så veldig stor betydning for det blir nok skilt på det i praksis.  Bare dumt hvis den digitale jorden sammenkobles med "sann" jord ettersom at det ligger en del støy på jordingsanlegget i huset/e-verket som man ikke ønsker skal gå inn i denne kretsen :P

  12. Det er nok det ser du, tenkte at istedet for å kalle 27 V for VDD, kunne man bare skrevet 27V0 eller noe for å unngå forvirringer. 

     

    Ah ja da skjønner jeg hvorfor du vil ha en header, for ut fra schematicen så kunne man direktekoblet USB? Det man kan gjøre er å sette RX og TX på MicroUSB kontakten din opp mot header med en XOR enhet mellom? For da kan man velge om man bruker Header eller USBen som gir strøm :)

     

    Det som er litt morsomt å se er at signalet som heter RXTTL3V3 kan faktisk kobles direkte til GPIO-grensesnittet på RPien? Selv om den skulle vell egentlig het TXTTL3V3 da denne transmitter signalet fra måleren til microkontrolleren? 

  13. Hvis VDD har ca. 27 V, så blir det litt feil på ESP8266 da der 3,3 V og VDD er tilkoblet sammen :P 

     

    Jumper, så du ønsker å kunne frakoblet signalet under programmering? Men er det da ikke bare å koble ut kabelen fra selve måleren? Litt lettere å håndtere kabelen derfra enn en liten jumper på et kretskort, Evt så setter du en RJ45 kontakt på kortet for å kunne koble fra kabelen der? 

  14. 39 minutter siden, roarfred skrev:

    Da er neste revisjon av schematics klar. Neste steg er komplett parts list

     

    image.thumb.png.df32e6fadc24736a9e110f585c2dbbbf.png

     

    Ikke verst dette. Eneste jeg lurte litt på om hvorfor det blir skilt på VDD og 3,3 V på tegningen når dette ser ut til å være akkurat det samme.

     

    Hvor skal "JUMPER" være plassert inn mot ESP8266? 

     

    Er det noe poeng med å ha en 470  ohms resistor mellom RST og GND hvis du setter switchen etter motstanden på 10k ohm? 

     

    Jeg ser også at GPIO2 har en 10k ohm resistor, men den er tilsynelatende ikke koblet opp mot noe? 

     

    Kunne man ikke erstattet "ProgramHeader" med å benytte RX og TX i "MicroUSB Connectoren"? Eller er det et poeng at du skal ha den for seg selv? For den "ProgramHeader" kan i praksis likså greit være USB?

  15. 3 timer siden, roarfred skrev:

    Godt mulig du har rett i dette. Hadde vært spennende å prøvd! Den breakouten fra aliexpress kan en jo sikkert bruke for å koble direkte til både PC og RPi.

     

    Tror jeg kjøpte noen løse chipper fra digikey til 40 kr stk. Utfordringen var nok at jeg den gangen trengte å lage en master, og ikke en slave. Samtidig fikk jeg den bare i SMD (16-SOIC) som er litt krevende å hånd-lodde. Dette er nok (om det fungerer) et mer solid design. Min tilnærming er nok en rimeligere løsning som kan lages med komponenter en gjerne likevel har liggende.

     

     

    Tror jeg skal prøve å bestille et par av disse brikkene å teste, men ser at jeg trenger litt hjelp med å bestemme størrelser på motstander og kondensatorer... Har prøvd å tegne litt i *host*paint*host* på hvordan dette blir direkte mot RPi:

    image.thumb.png.495e94d4f0fab3f830bf875bbb0855e7.png

     

    Selve loddingen av SMD har jeg ingen bekymringer for, har loddet en del av dette tidligere så det er ingen problem så lenge man har nok fluxmiddel :)

  16. En ting jeg ikke klarer å legge fra meg, er hvorfor man ikke kan bruke TSS721A for dette? I følge http://www.m-bus.com/mbusdoc/md4.php så ser det ut som at man kan bruke denne brikken direkte mot måleren og koble denne mot en microcontroller/RPi? Ser ut som at man må inn med noen kondensatorer for å glatte signalet og noen motstander for aktivering eneste? Det er nok som du sier, at denne er mer ment for selve målerenheten, men hvis man hadde kunne brukt denne så hadde man sluppet noen av de komponentene dere har over (som igjen tar bort litt av gleden)?

     

    Her er også noen som har lagt ferdige board, men det jeg tenkte var å kun bestille selve brikken fra e-bay (kostet 20 kr) og dermed har man vell det man trenger?: https://www.aliexpress.com/store/product/TSS721-Module-Board-M-BUS-To-TTL-with-RX-TX-Indicator-STM32-Development-Board-Free-Shipping/722716_32751482255.html 

  17. Må si at dette ser spennende ut :)

     

    Men i ditt originale schematics, inverterer du signalet? Kan det være en årsak til at mengdene ikke stemmer helt? For de kodene du mottar, er ikke identisk med det eksempelet som kamstrup har her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/Kamstrup HAN-NVE interface description_rev_3_0.pdf

     

    Jeg spør sikkert dumt, men det er en stund siden jeg hadde elektroteknikk og digitalteknikk :P 

  18. Tja, det kan hende. I dokumentasjonen for Aidon måleren så står det at formatet skal være 4.3 (xxxx.xxx kW) og har en oppløsning på 1 W. Da tviler jeg på at verdien du får oppgitt i effekt er i mW.

     

    Formatet på de ulike skal være: 

    Spenning: format 3.1 (xxx.x V)

    Strøm: format 3.2 (xxx.xx A)

    Effekt: format 4.3 (xxxx.xxx kW). Legg merke til at her er den oppgitt i kW, men oppløsningen er i 1 W. 

     

    Så ut fra hva jeg kan se, så får man oppgitt effekt i W med oppløsning på 1 W, strøm i mA med en oppløsning på 10 mA og spenning V med oppløsning 100 mV. 

    Dette stemmer jo bra med effekten og spenninge, men for strømmen så skulle man fått 1,75 A og ikke 1,755 A ettersom oppløsningen er på 10 mA. 

    Effekt: 06 00 00 02 5C = 000604 W, 

    Strøm: 06 00 00 06 BD = 1755 mA = 1,755 A

    Spenning: 06 00 00 09 60 = 2400 = 240 V

     

    Men jeg stusser litt på at avlesningen din bare var på 0,6 kW ved dette tidspunktet, for hvis man ser på hvordan verdi strømmen skulle hatt (altså 17,5 A ettersom oppløsningen er 10 mA), så skulle effekten også vært høyere. Vet du med sikkerhet at lasten din på dette punktet var kun 604 W? eller var den 6,04 kW? 

  19. Jeg ser at spenningen er oppgitt med en oppløsning på 0,1 V med format xxx.x V på Aidon sine målere og nesten det samme for Kaifa, bare der oppgir de ikke oppløsningen, men ettersom de består av akkurat samme OBIS kode så antar jeg at det er en oppløsning på 0,1 V og at den gir ut heltall. Det samme gjelder for strømmen (0,1 A) forutenom Kamstrup som oppgir oppløsning på 0,01 A. Her skal det nevnes at Kamstrup har objektkode 1.1.31/51/71.7.0.255, mens Aidon og Kaifa har objektkode: 1.0.31/51/71.7.0.255.

     

    Når det kommer til inndelingen av OBIS kodene, så har jeg klart å finne fram til dette: 

    "Value group B identifies the measuring channels. Value group C identifies the physical quantity measured, while value group D identifies the processing methods and country specific codes. Value group E is used for identifying rates or can be used for further classification. Value group F is used for identifying historical values or can be used for further classification. "

     

    Gruppe A=1 angir om det er elektriske komponenter som skal måles.

     

    Dermed ser det ut til at Aidon og Kaifa gir ut strømverdien på en annen kanal enn Kamstrup, og det er sikkert det som angir oppløsningen på 0,1 A og 0,01 A.

     

    Edit: Ser på de dataene du har så stemmer det ikke helt med hva som er oppgitt på de skjemaene fra NVE. For tviler for at du har en belastning på over 200 A.

  20. På 24.9.2017 den 18.50, roarfred skrev:

    Da har jeg lagt ut en komplett oppdeling av de tre listene fra Kaifa måleren, koblet sammen med forklaring fra OBIS-dokumentet. Reagerer litt på at de enhetene i dokumentet fra Kaifa åpenbart må være feil, evt. også har jeg litt problemer med å skjønne hva en double-long-unsigned skal være.

     

    Kan mao se ut som verdiene som kommer ut skal multipliseres eller divideres med 10, 100 eller 1000 før de stemmer med den oppgitte enheten. Eks har jeg 2424V og 2182A på den ene linjen min :)

     

    Det hele finnes her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kaifa OBIS breakdown.md

    Jeg tittet litt på disse verdiene nå, og det er nok som du sier en feil med at verdien er 1000x for høy ja, men så lenge nettselskapet korrigerer det så er det nok ikke så farlig... 

     

    Videre så ser jeg, hvis disse tallene stemmer, at du,  eller noen på samme trafokrets,  har jordfeil på fase 2 :P

×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.