roarfred

2 hours ago, Ravn said:

Jeg har ikke lært meg kicad enda dessverre

Kan skrive under på at det var en befrielse å gå over til KiCad. MYE enklere, og bedre kontroll over kapsling osv. Og bonusen med 3D modell da. Drog den nettopp inn i Fusion 360 for å printe meg en boks...

Ang, den mystiske byten vi så i DLMS headeren, som Kamstrup fjernet, men som vi fremdeles ser hos Kaifa. DLMS.com har bekreftet at dataene vi får fra Kaifa er feil, så her må vi nok regne med at det kommer en korreksjon:

Quote

 

Dear Roar,

I can confirm now that the KAIFA APDU is wrong.

This is the APDU carried by the HDLC frame:

0F 40 00 00 00 09 0C 07 E1 09 0C 02 17 12 2A FF 80 00 00 02 01 06 00 00 05 28

This translates to:

<DataNotification>
  <LongInvokeIdAndPriority Value="40000000" />
  <DateTime Value="0C07E1090C0217122A" /> // 09 is interpreted as the length 
  <NotificationBody>
    <DataValue>
      <DontCare /> // This is because the bte FF, the remaining bytes 80 00 00 02 01 06 00 00 05 28 are ignored.
    </DataValue>
  </NotificationBody>
</DataNotification>

The correct APDU would be:

0F 40 00 00 00 0C 07 E1 09 0C 02 17 12 2A FF 80 00 00 02 01 06 00 00 05 28 (the tag 09 is for octet-string is not present)
 

<DataNotification>
  <LongInvokeIdAndPriority Value="40000000" />
  <DateTime Value="07E1090C0217122AFF800000" /> the lengh of the octet-string is 12
  <NotificationBody>
    <DataValue>
      <Structure Qty="0001" > // structure of 1
        <DoubleLongUnsigned Value="00000528" />
      </Structure>
    </DataValue>
  </NotificationBody>
</DataNotification>

The KAMSTRUP APDU is correct.

Please advise KAIFA, I will ask advise them.

best regards

DLMS Support

 

Jeg har meldt dette inn til NTE Nett som tar det videre til Kaifa og lover å holde oss oppdatert på når evt. ny firmware kommer.

@Øyvind, @Moskus og @sajje, jeg har desverre ikke kapasitet til å lodde kretskort for salg... Det jeg imidlertid kan bruke litt tid på er å få omformet kortet til en SMD variant, slik @Ravn foreslår, og få det lagt inn hos en PCB service hvor en kan kjøpe ferdige kors. Hvis noen har kompetansen og slik på dette, setter jeg også stor pris på en Pull Request  Oppgaven vil egentlig bare bestå i å kjøre KiCad og bytte ut innkapslingen til through hole komponentene med SMD ekvivalenter.

24 minutes ago, xibriz said:

 

Joda.. RX fra HAN og TX inn på PCen

Du har helt rett, jeg som ikke helt tenkte på denne muligheten...

En endring jeg bør få inn er da selvfølgelig noen yields() inni kode som skriver ut hele mottatte pakke som hex. Denne blir fort nesten 4 x antall mottatte bytes, og over 2400 baud er det fort å nærme seg 1 sekund.

3 minutes ago, xibriz said:

Koblet ut debugPrint-funksjonen og da ser det stabilt ut... jeg er sikker på at jeg prøvde å sette debugPort til NULL tidligere uten at det funket... får forske litt til.

 

Det er deilig å sitte inne i 24 grader kontra ute i 5 minus Kanskje derfor jeg finner ut av ting her

hehe, så ut som vi fant løsningen samtidig her  godt jobbet!

16 minutes ago, xibriz said:

hanReader.setup(&Serial, 2400, SERIAL_8N1, &Serial);

Her er noe muffens... Vi kan ikke bruke Serial både til HAN og til debugging... Kan du endre dette, eks til:

hanReader.setup(&Serial, 2400, SERIAL_8N1, NULL);

Dette gir deg da ingen debug output. Hvis du vil ha debug, så bruk Serial1 som siste parameter. En liten ting da er at du må koble over FTDI sin RX til GPIO2 (som er fast TX for Serial1). Når jeg har testet har jeg gjort dette, og jeg har også kjørt Serial1 på 115200 baud.

(Slo meg da jeg så at debug-meldingen var ganske stor, og ser jo nå at den kan ta nesten ett sekund alene å skrive ut, på 2400 baud)

PS: Kan være lurt å bytte bort Serial i din egen kode også. Teoretisk skulle det kanskje funke å bruke TX og RX til ulike ting, men litt sånn at en må holde tungen i riktig munn...

6 hours ago, xibriz said:

Her er den eksakte kopien @roarfred

 

Takker! Ble ikke så mye tid i kveld, men mulig i morgen...

Sjekket litt nærmere på WDT, ser ut som den har en begrensning på 1 sek. Dvs. at du bare har 1 sek på deg til å komme gjennom en runde i loop, eller evt. gjøre noen manuelle kall til yield(). En stor forskjell hos deg (fra meg) er at du rapporterer inn hver verdi som separate MQTT meldinger. Mulig et skudd i blinde, men her er 14 / 19 meldinger som skal sendes, og da er en kanskje ikke så helt unaturlig at det kan gå litt tid på en av dem. I tillegg kommer reconnectMqtt.

Jeg ville prøvd to ting:

1) yield(); etter hver client.publish(...)

2) kanskje bare kommentere bort alle verdier, slik at det kun er uptime som publiseres på MQTT

@xibriz, ligger den eksakte koden du kjører ute noe sted? Jeg kunne prøvd å simulere litt... 

@cpu22 er nok inne på noe her, @xibriz Jeg mener WDT er utelukkende for å hindre heng, og om en prøver seg på sammenhengende kode innenfor loop som tar mer enn 2(?) sekunder, så vil den slå ut. Husker jeg riktig er det fordi vi kun har en kjerne og selve wifi delen krever litt ressurser for å holde forbindelsen i live. Det skal finnes et kall, tror det heter yield() som man kan legge inn her og der for å frigi ressurser til andre ting. I arduino bibliotekene til ESP8266 skal dette også ligge innebygget i sleep().

Jeg ville prøvd å fjerne deler av loop, inntil ting kjører stabilt, og deretter legge tilbake. Tidkrevende, men som regel fører det frem.

NTE svarte kjapt og vil ta dette videre til Kaifa. De har ikke bekreftet at noe er feil, og viser til at Kaifa har et sterkt DSML miljø. Vi får da se... 
I mellomtiden har jeg fikset litt på Arduino-koden og lagt ut på github.

Setter pris på om du har lyst til å teste fixen hos deg @xibriz

For å styre forskjellen på Kaifa og Kamstrup har jeg innført en property som kan settes til true: (da for Kaifa måler, hvor jeg anser dette for å være en bug)

hanReader.compensateFor09HeaderBug = true;

Begge eksemplene, KaifaTest og KamstrupTest er oppdatert. Gjenstår fortsatt å oppdatere ting under examples folder i biblioteket

Fikk svar fra Kamstrup på en forespørsel dit:

Quote

Det er korrekt at der er foretaget en mindre ændring i protokollen mellem to måler FW revisioner. Se også vedhæftet revisionsdokument - Der er fjernet en byte i Headeren. Den ekstra byte var efter mine oplysninger ikke i henhold til DLMS specifikationen og derfor er den fjernet. Vi forventer at alle vores kunder i Norge på sigt vil opdatere deres målere til at understøtte det nye format for data-headeren.

 

Det er svært lige nu at sige hvordan vi kan håndtere dette bedst muligt i fremtiden. NVE har, hvad jeg har hørt, forslået en mulig løsning hvor de forskellige AMS-måler leverandører i Norge kan gøre deres opdaterede protokol-beskrivelse tilgængelige, men jeg kender ikke aktuel status på dette. Jeg forventer dog bestemt ikke flere ændringer i den nuværende data-protokol.

Dokumentet som refereres til er v3.1 av det vi tidligere hadde som v3.0. Dette er lastet opp på github

Har også sendt forespørsel til NVE og NTE om hvordan vi kan holde oss oppdatert på slike endringer, og om Kaifa nå kommer med samme endring.

Lurer litt på å kjøpe en utgave av NEK IEC 62056-7-5:2016, men er ikke 100% sikker på om den dekker alle detaljer. Noen som har tilgang til denne, evt. et abbonement hos standard.no?

Edit: fikset versjonsnummer på dok

15 hours ago, xibriz said:

Prøvde noen skudd i blinde i går, men det ga ikke noen resultater. Det var alt for kaldt i garasjen til å stå å debugge  

Jeg har prøvd å studere dette fenomenet litt. Dette er det jeg har funnet så langt:

• Det finnes en software på GitHub som vi har såvidt vært innom tidligere, og denne kan kjøres opp i test-modus for push meldinger: https://github.com/Gurux/Gurux.DLMS.Net
• Eksempel for test-kjøring er det som ligger under folderen Gurux.DLMS.Push.Listener.Example.Net
• Per default er denne testen satt opp med InterfaceType.WRAPPER. Ved å endre dette til InterfaceType.HDLC kan en motta slike 7E ... 7E meldinger som måleren vår sender (må også fikse noe adressering, men det ser en av feilmeldinger)
• Prøver en så å sende inn Kamstrup-data, så stopper den fordi E6 ikke er gjenkjent som en kommando. Problemet her er at kommandoen i pakken er 0F. Det ligger tre bytes i Kamstrup (og Kaifa) sine data som denne softwaren ikke kjenner igjen. Disse er E6 E7 00. Ved å debugge litt og manuelt overstyre er det mulig å skippe disse tre bytes. Gjør en det vil faktisk hele Kamstrup pakken leses fint inn.
• Ser jeg nærmere etter hva som skjer etter at 0F kommandoen blir funnet, så forventes det å hoppe over 4 bytes (00 00 00 00) og så lese inn lengden på et informasjonsfelt (0C = 12 bytes). I koden fra Gurux leses disse tvert inn i et datoformat, uten noe mer sjekk. (Se funksjonen HandleDataNotification i GXDLMS.cs)
• Så, prøver jeg å gjøre det samme med Kaifa dataene fra min måler, så feiler dette når denne timestamp blir forsøkt lest
• Er jeg kreativ og endrer Kaifa data og fjerner 09 fra denne timestamp, så fungerer det også (må da oppdatere størrelse og rekalkulere checksum for header og pakke)
• Så, dette er jo en viss indikasjon på at dette skal være slik (dvs. ingen 09 byte i timestamp), men det er også litt urovekkende at ikke Gurux klarer å lese pakken uten å hoppe over denne E6 E7 00.

Sekvensen jeg måtte ta bort er beskrevet som Destination LSAP, Source LSAP og LLC. Kapittel 8.3.2, Fig 19 i den grønne boken beskriver dette, men jeg blir ikke så veldig klok av det. Jeg har heller ikke den komplette boken, bare denne extract-versjonen, hvor det plutselig står "for more details see the complete Green Book".

Beklager alle detaljene her, jeg måtte bare få ting notert. Godt mulig løsningen er å ha noen ekstra settinger per målertype som kan hjelpe oss å navigere til riktig sted på riktig måte...

8 minutes ago, Thomas_ja27 said:

Får ut noe kryptisk

Dette ser ikke egentlig så kryptisk ut. Det du får er nok rådataene formatert som ASCII. Bare noen helt enkle elementer er virkelig ASCII, og disse ser du her som klar-tekst.

Hvis du får til noe kode som istedet får dette ut i et binærformat (type hex), så vil du kunne finne enkelt fram til effektforbruk, spenninger o.l.

Her er to sider hvordan dataene fra Kaifa måleren kan knekkes opp: (den første inkluderer start og slutt, den andre bare informasjons-delen)

- https://github.com/roarfred/AmsToMqttBridge/tree/master/Samples/Kaifa

- https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kaifa/obisdata.md

0x0A er nok riktig. Dette angir tekst, og neste byte skal angi lengde. Kan det være noe annet som har vært feil her siden flere ting plutselig falt på plass?

Endringen hos xibriz var utelukkende fjerning av denne 0x09 på datoen, og crc stemte både før og etter...

15 minutes ago, cpu22 said:

endret fra 0x0a 0x0e

Jeg så ikke dette i dataene fra @xibriz... Var dette første elementet etter List Size infoen (02 19)?

Her er første pakken fra xibriz dissekert:

[2018-03-04 20.47.22.568 - Received 228 (0xE4) bytes]
7E    // Start
A  
0 E2  // Antall bytes i pakken, stemmer
2B 
21 
13 
23 9A // Checksum for header, verifisert
E6 
E7 
00 
0F    // Denne refereres til som n*8 bits of "information"
00 00 00 00 
0C 07 E2 03 04 07 14 34  // Ny dato-tid
00 FF 80 00 00 

02 19                    // Start av vanlige data
0A 0E 4B 61 6D 73 74 72 75 70 5F 56 30 30 30 31 09
06 01 01 00 00 05 FF 
0A 10 35 37 30 36 35 36 37 32 37 34 33 38 39 37 30 32 
09 06 01 01 60 01 01 FF 
0A 12 36 38 34 31 31 32 31 42 4E 32 34 33 31 30 31 30 34 30 
09 06 01 01 01 07 00 FF 
06 00 00 0E E7 
09 06 01 01 02 07 00 FF 
06 00 00 00 00 
09 06 01 01 03 07 00 FF 
06 00 00 00 00 
09 06 01 01 04 07 00 FF 
06 00 00 00 BF 
09 06 01 01 1F 07 00 FF 
06 00 00 05 59 
09 06 01 01 33 07 00 FF 
06 00 00 01 EC 
09 06 01 01 47 07 00 FF 
06 00 00 05 14 
09 06 01 01 20 07 00 FF 
12 00 E1 
09 06 01 01 34 07 00 FF 
12 00 DD 
09 06 01 01 48 07 00 FF 
12 00 DE 
46 0F // Checksum for hele pakken, verifisert
7E

2 hours ago, xibriz said:

Oj, det står tilogmed i "Revision history" på samme dokument  

Uffda, da er det grunn til å tro at dette ikke er en feil som er skjedd

Jeg har brukt litt tid på å lete etter hvordan denne header skal tolkes. Står litt i green book, ingen detaljer om denne date-time verdien vi ser. De beskriver destination address og source address, samt LLC quality som vi ser rett før, og så er det noe om et n*8 bit information field.

Jeg klarer ikke helt å se hvordan man skal klare å detektere innholdet/størrelsen på denne header. Noen som ser noe jeg ikke ser?

4 hours ago, xibriz said:

Jeg skal se mer på det i kveld

Hadde vært fantastisk å finne ut om dette fortsatt er innenfor DLMS standard. I HanReader.cpp gjøres litt håndtering av ulike datatyper, og 0C er ikke håndtert her. Mulig den skulle vært lagt til, og at det vil fungere. (Selv om jeg før har sett på 09 som "string" og deretter 0C som lengden - 13 bytes - på denne string)

Edit:

På side 34-37 i Blue Book står det beskrevet format på data-typer. "Tag" i listen på side 34 er den første byte vi mottar for hver verd. For date/time er det 25, 26 og 27 som er dedikert, men det står også på side 35 at date-time kan være representert med en octet-string, og at da skal både tag (0x0A) og lengde på string være med.

Når verdien vi ser her starter med 0x0C (12 desimal), så antyder det data-type UTF8 string. Står ikke noe om at det skal være et alternativ for en date/time, og det gir heller ikke noen mening å se på disse bytes som UTF8. Tror det skulle være et blindspor.

Samtidig er ikke dette data-elementet innenfor den fleksible DSLM delen, det kommer faktisk før det egentlig første elementet som angir hvor mange elementer det er i listen. Mulig det finnes noe som sier at dette elementet har en fast data-type og at det skal alltid skal være octet-string og at tag for datatype da skulle være overflødig?

Noen som har sett noe skrevet om hvordan firmware updates på AMS målere skal skje, og evt. hvordan dette er tenkt å kommuniseres ut til forbrukeren?

@xibriz, det ser på meg ut som du har fått en firmware update der eneste forskjell jeg kan se fra tidligere er at det mangler en 0x09 foran timestamp i starten på blokken. Hvis du ser på denne, pkt nr 0 i listen: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md

Merk at alt av checksummer (både header og data) stemmer, så dette er ikke en lese-feil i kretsen, det er måleren som har begynt å sende data på en ny måte.

I dataene fra deg er inndeling slik:

(...) 
E6 E7 00 0F 00 00 00 00 
0C 07 E2 03 04 07 14 34 00 FF 80 00 00     **** HER MANGLER "09" I START ****
02 19 
0A 0E 4B 61 6D 73 74 72 75 70 5F 56 30 30 30 31 **** LIST IDENTIFIER ER UENDRET: Kamstrup_V0001 ****
09 06 01 01 00 00 05 FF 
0A 10 35 37 30 36 35 36 37 32 37 34 33 38 39 37 30 32 
09 06 01 01 60 01 01 FF 
0A 12 36 38 34 31 31 32 31 42 4E 32 34 33 31 30 31 30 34 30 
09 06 01 01 01 07 00 FF 06 00 00 0E E7 
09 06 01 01 02 07 00 FF 06 00 00 00 00 
09 06 01 01 03 07 00 FF 06 00 00 00 00 
09 06 01 01 04 07 00 FF 06 00 00 00 BF 
09 06 01 01 1F 07 00 FF 06 00 00 05 59 
09 06 01 01 33 07 00 FF 06 00 00 01 EC 
09 06 01 01 47 07 00 FF 06 00 00 05 14 
09 06 01 01 20 07 00 FF 12 00 E1 
09 06 01 01 34 07 00 FF 12 00 DD 
09 06 01 01 48 07 00 FF 12 00 DE 
46 0F 
7E

1 hour ago, xibriz said:

Jeg la ved en sample-fil 

Dataene er faktisk gyldige. Skal lese ut verdier og se om eks. list identifier har endret seg...

Spennende! Hos meg kommer fortsatt List1 og List2 fint ut til MQTT, og List3 kom sist for ca 10 min siden.

Stemmer checksum, slik at det faktisk har vært en firmware update på måleren din?

1 minute ago, Odd said:

 

Jeg har ikke utstyr til overflate montering, så om det er mulig så er det flott å få kjøpt en komplett løsning.
Jeg tror at disse gjør det:
https://www.elecrow.com/wiki/index.php?title=Main_Page

 

Jeg har heller ikke noe utstyr utover en loddebolt med fin spiss. EEVBlog hadde en sak om at montering av SMD egentlig ikke bør være noen terskel for noen

Her snakker vi da også bare om noen veldig få komponenter

5 hours ago, xibriz said:

Aisler.net

Wow!

https://aisler.net/p/VPVMJEBF

Hadde jo vært sykt bra om de kunne montert også da

Finnes det en public PCB-design plass, hvor en kan laste opp en spec på et design, inkl. montering av komponenter og hvor deretter hvem som helst kan gå inn og bestille? (Produsert per bestilling, mulig med et lite antall i buffer)

Mente jeg så en kommentar en dag fra en som sa noe slik som "poster du designet på make-it-for-me.com"? Men, kan ikke helt finne det igjen...

4 minutes ago, cpu22 said:

 

Jeg kjøper gjerne ett av deg. Eller to hvis du ikke blir kvitt dem.

Jeg har en hel skuff av slike prototype kort du kan få kjøpe, jeg har ingen aning av hva noen av dem skal brukes til

Registrert at du vil ha, så send meg en PM, evt. med postadresse så klarer jeg holde orden på det.