Lesing av AMS data (AMS/HAN -> IoT)

[roarfred]

34 minutes ago, Tubez said:

 

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?

VDD holder ca. 27V. Ref tidligere post må opamp ha så høy driftspenning for å takle input direkte fra MBus

JUMPER er for å kunne frikoble opamp signal under programmering

470 ohms motstander kunne sikkert vært fjernet, ja.

Good catch med R på GPIO2, den skal selvfølgelig være koblet!

Headeren er tilpasset en ekstern FTDI. En kunne brukt USB til dette, men da med egen FTDI krets på kortet. Ser for meg at vi hovedsakelig oppdaterer over WiFi, så det er bare under initiell programmering dette er behov for.

[Tubez]

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

 

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? 

[roarfred]

2 minutes ago, Tubez said:

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

 

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? 

La oss krysse fingrene for at VDD på ESP bare er et navn på denne pinnen og at det ikke har noe med signal-navnet VDD å gjøre  

Poenget med å koble fra er at det kan være ukjent signal inn, så både transistoren og motstanden kan påvirke serie-signalet for programmering, noe som 115k baud signalet er litt ømfintlig for. Plass til en jumper koster ingen ting, og den kan evt. bare loddes over om en ser at det fungerer uten.

 

Header som en setter FTDIen oppå er også direkte på kretskortet, så en kan argumentere for at det er like enkelt å nappe ut en jumper som å koble ut RJ45 kabelen. Jeg bruker noe slik som dette: https://www.amazon.co.uk/XCSOURCE®-FT232RL-Adapter-Arduino-TE203/dp/B00HSX3CXE/ref=pd_lpo_sbs_147_img_1/257-9514725-8254220?_encoding=UTF8&psc=1&refRID=GTTP8PAVPYSN2E76DDR5

[Tubez]

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? 

[roarfred]

Følger deg ikke helt på dette med RX og TX direkte på micro usb. En ville her måtte ha en FTDI krets direkte på kortet (for å oversette USB til seriell) om en ønsket å koble eks en PC direkte til. Veldig mange protoboards for ESP8266 har nettopp dette, og det er kjekt når en skal komme fram til et design. Derimot litt fordyrende og unødvendig i denne sammenheng. Det en derimot kunne gjort var å ta ut VCC (5V) fra den eksterne FDTIen, da hadde en slippet å ha en ekstern strømforsyning koblet til under programmering og testing.

 

Stemmer helt at du kunne koblet deg på ved jumper (RXTTL3V3) og rett i PI'en. Om det heter TX eller RX kommer vel bare an på siden en ser det fra. Kanskje bedre navn kunne være HAN_TTL3V3.

 

Har mer enn nok med å kommunisere de elektriske endringene tilbake til ingeniøren, om jeg ikke også skulle henge meg opp i navngiving

 

 

[Tubez]

Ah ja det stemmer, ja det blir nok litt fordyrende på dette nivået man er på nå

 

Men for å snakke litt om kodingen, hvordan kom du fram til at det er RFC1662 standarden på dataoverføringen som er brukt?  

 

 

[roarfred]

5 minutes ago, Tubez said:

Ah ja det stemmer, ja det blir nok litt fordyrende på dette nivået man er på nå

 

Men for å snakke litt om kodingen, hvordan kom du fram til at det er RFC1662 standarden på dataoverføringen som er brukt?  

 

 

I seksjon 8.5.1/8.5.2 i Green Book finnes noen detaljer som satte meg på rett spor. Brant av en god lørdag for å komme derfra til ferdig implementert kode da  

https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/Excerpt_GB8.pdf 

[Einar]

3 timer siden, roarfred skrev:

La oss krysse fingrene for at VDD på ESP bare er et navn på denne pinnen og at det ikke har noe med signal-navnet VDD å gjøre  

 

Det trenger du ikke være redd for. Vdd i ESP8266 er en label i biblioteksmodulen. Den kan som du indikerer hete hvasomhelst. Det som bestemmer utlegget er hvor den er koblet i skjema. Alle som har (skjema)label VDD vil bli koblet sammen i utlegg uten hensyn til hva label i biblioteksmodulen er.

 

Du bør også tegne inn den andre komparatoren i LM358 og koble inngangene mot GND. Ellers kan du risikere at den blir en frittløpende oscillator og lage masse støy på kortet. Alt som ikke er tegnet inn med en kobling vil stå med pinnene uten tilkobling i utlegget.

[Tubez]

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

Endret 28. september 2017 av Tubez

[Tubez]

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`?

 

Endret 28. september 2017 av Tubez

[Tubez]

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?

Endret 29. september 2017 av Tubez

[roarfred]

11 minutes ago, Tubez said:

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?

Litt rart dette for det sies at det er mbus, men jeg får ikke protokollen til å stemme. Eks er det ulike start og stopp for pakkene. MBus dokumentasjonen stemmer med kommunikasjon jeg har gjort mot måleren på varmepumpen min, men ikke på AMS måleren. 2400baud, 8E1 og elektriske nivåer matcher. Kan det være at de har brukt deler av mbus bare?

[Tubez]

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? 

Endret 29. september 2017 av Tubez

[Tubez]

Har du lest de tabellene over variabel data strukturen for M-bus? http://www.m-bus.com/files/MBDOC48.PDF Side 76, side 75 inneholder informasjon om SI enhetene. 

[Tubez]

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

Endret 29. september 2017 av Tubez

[roarfred]

1 hour ago, Tubez said:

Har du lest de tabellene over variabel data strukturen for M-bus? http://www.m-bus.com/files/MBDOC48.PDF Side 76, side 75 inneholder informasjon om SI enhetene. 

Så bare at de definerer tre ulike typer pakker, hver med egen start byte som skal identifisere. Ingen av den er 7E. Men, så du skrev noe etterpå om at støtte for push har kommet etterpå. Skal se mer på det...

[roarfred]

1 hour ago, Tubez said:

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

 

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

Søkte litt på dlms push og kom over en tråd her:

https://www.gurux.fi/node/4821

 

Sjekk innlegg nr. 11. Her er flere detaljer om hva hver byte betyr. Ser også ut som om dlms kan kjøres i flere modes, der den ene gir en slik 7E pakke. HDLC nevnes som et begrep. Er det slik at det er en stack på dette viset:

Mbus for elektrisk

Hdlc for pakke-protokoll

Dlms/cosem for data-protokoll

[roarfred]

Fikk nettopp forslag til PCB (i 3D PDF). Tok en snap av det her:

 

[Tubez]

Ikke verst

 

Vet du om dette kortet vil fungere på Aidon sine målere? For jeg har ikke sett veldig mye dokumentasjon på utgangen på den måleren annet enn OBIS listen du har på Github.

[Tubez]

hvem produserer PCBen? Og hvor er minimumsbestilling av brettet?

Endret 29. september 2017 av Tubez

[roarfred]

10 minutes ago, Tubez said:

hvem produserer PCBen? Og hvor er minimumsbestilling av brettet?

Har brukt noe som heter gogopcb tidligere. Minstaantall på 5 kort, for ca. $20.

[roarfred]

6 hours ago, Tubez said:

Ikke verst

 

Vet du om dette kortet vil fungere på Aidon sine målere? For jeg har ikke sett veldig mye dokumentasjon på utgangen på den måleren annet enn OBIS listen du har på Github.

Umulig å si for meg... Håper noen får målt litt etterhvert, så kan jeg evt. justere om nødvendig

[Tubez]

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

 

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?

[roarfred]

9 minutes ago, Tubez said:

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

 

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?

Etter hver av 09 blokkene har du en 06. Det betyr også 6 påfølgende bytes, og her er det obis koden kommer. Det som er litt utfordrende er at min måler har omtrent tilsvarende data ut, men uten alle disse 09 06 verdiene. En kan tenke at en vha. OBIS identifier må slå opp i et register for å vite h a som kommer, og i hvilken rekkefølge. Hadde likevel vært kjekkere om de lignet litt mer på hverandre.

 

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

 

Det stemmer at 5BE5 er en checksum for hele framen. Det finnes også en egen checksum for header, ganske smart. Kalkulert på samme måte, men inkluderer da bare header data. Tror den er 239A i denne pakken.

 

Har ikke fått sjekket mer på class 40. Er på #rccodeathon2017 denne helgen...

[Tubez]

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

Endret 30. september 2017 av Tubez