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

Anbefalte innlegg

Skrevet (endret)
12 minutter siden, roarfred skrev:

Wow!

https://aisler.net/p/VPVMJEBF

 

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

 

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

https://www.elecrow.com/pcb-manufacturing.html

 

 

Endret av Odd
Skrevet
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

 

 

 

Skrevet
15 minutter siden, roarfred skrev:

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

 

 

 

 

Veeeel ... jeg også har syslet litt med diverse prosjekter, blant annet moddet Xbox 1 :)

Men ser helst at jeg slipper .. hvis jeg må er nok varmluft å foretrekke, ikke så stø på hånda som for 25 år siden :)

 

Skrevet
21 minutter siden, Odd skrev:

 .. hvis jeg må er nok varmluft å foretrekke, ikke så stø på hånda som for 25 år siden :)

 

 

Samme her. Og det er hovedgrunnen til at jeg har gått helt over til overflatemontering der det er mulig.

Det eneste "spesialverktøy" du trenger er en fin pinsett, helst av Titan. Loddebolten du har er fint brukbar om det ikke er av typen loddeøks for takrenner og beslag.

Varmluft er jeg ikke så glad i. Plutselig har du blåst printet fritt for komponenter. :-(

Ja, også trenger du flytende fluss. Det som er i tinnet er ikke nok eller bra nok.

 

Skrevet (endret)

Nå tror jeg Firmwaren min er klar snart.

 

Booter opp som AP, så browser man til en nettside for å skrive inn SSID, passord og MQTT-server.

Deretter kobler den seg opp på nettverket og betjenes via MQTT.

Mulighet for reset og FOTA oppgradering.

 

Kom akkurat på at jeg nok må legge inn mulighet for å velge måler da det er noen små forskjeller i oppsettet..

Endret av xibriz
  • Like 5
Skrevet
3 hours ago, xibriz said:

Nå tror jeg Firmwaren min er klar snart.

 

ooohh, noe du er åpen for å dele? :)

Har Kaifa måler.

 

Loddet meg omsider en logger idag, etter design fra roarfred. Bestilte delene for en god stund siden. Styrte resten av dagen med å få FDTI drivere inn på macén..

Gav opp tilslutt og gikk over til guttungen sin windows edb. gav opp der også,  fant ut at driverene følger med i ubuntu, . Har tilfeldig en Linux mint maskin stående å tikker, lastet den Arduino IDE på den.. virket med en gang.  Fatter ikke hvorfor det skulle være kul umulig å få noe så enkelt som drivere på macén

 

men uansett... nå står loggeren å blinker etter en suksessfull opplasting av blink. 

Så da er det å finne veien videre :)

 

 

 

Skrevet (endret)
6 timer siden, kanutten skrev:

 

ooohh, noe du er åpen for å dele? :)

Har Kaifa måler.

 

 

Ja, den kommer på Github når jeg er ferdig :)

 

Kom på støtte for flere målere når jeg trodde jeg var ferdig :P men det er nok ordnet i kveld eller i morgen. 

Endret av xibriz
  • Like 4
Skrevet

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?

Skrevet
1 hour ago, xibriz said:

Jeg la ved en sample-fil 1f607.png

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

Skrevet (endret)

@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

Endret av roarfred
  • Like 1
Skrevet
8 timer siden, roarfred skrev:

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.

 

Det var det jeg mistenkte. Da må vi (du) håndtere begge deler :) Jeg skal se mer på det i kveld, så kan jeg kjøre en PR hvis jeg får det til å fungere.

Skrevet (endret)
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?

Endret av roarfred
Skrevet

Man kan jo merke seg at i det jeg får ut nå ligner mer på eksemplene her:

https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/Kamstrup HAN-NVE interface description_rev_3_0.pdf

 

Sitat

3.1 Example 1: /* 10s list, 3 phases, 4 quadrants */
7E A0E2 2B 21 13 239A E6E700
0F 00000000 0C07D0010106162100FF800001
0219
0A0E 4B616D73747275705F5630303031
0906 0101000005FF 0A10 35373036353637303030303030303030
0906 0101600101FF 0A12 303030303030303030303030303030303030
0906 0101010700FF 0600000000
0906 0101020700FF 0600000000
0906 0101030700FF 0600000000
0906 0101040700FF 0600000000
0906 01011F0700FF 0600000000
0906 0101330700FF 0600000000
0906 0101470700FF 0600000000
0906 0101200700FF 120000
0906 0101340700FF 120000
0906 0101480700FF 120000
5BE57E


3.2 Example 2: /* 1 hour list, 3 phases, 4 quadrants */
7E A12C 2B 21 13 FC04 E6E700
0F 00000000 0C07E1081003100005FF800000
0223
0A0E 4B616D73747275705F5630303031
0906 0101000005FF 0A10 35373036353637303030303030303030
0906 0101600101FF 0A12 303030303030303030303030303030303030
0906 0101010700FF 0600000000
0906 0101020700FF 0600000000
0906 0101030700FF 0600000000
0906 0101040700FF 0600000000
0906 01011F0700FF 0600000000
0906 0101330700FF 0600000000
0906 0101470700FF 0600000000
0906 0101200700FF 120000
0906 0101340700FF 120000
0906 0101480700FF 120000
0906 0001010000FF 090C 07E1081003100005FF800000
0906 0101010800FF 0600000000
0906 0101020800FF 0600000000
0906 0101030800FF 0600000000
0906 0101040800FF 0600000000
C8867E


3.3 Example 3: /* 1 hour list, 1 phase, 1 quadrant */

7E A0AE 2B 21 13 A01B E6E700
0F 00000000 0C07E1081003100005FF800000
020F
0A0E 4B616D73747275705F5630303031
0906 0101000005FF 0A10 35373036353637303030303030303030
0906 0101600101FF 0A12 303030303030303030303030303030303030
0906 0101010700FF 0600000000
0906 01011F0700FF 0600000000
0906 0101200700FF 120000
0906 0001010000FF 090C 07E1081003100005FF800000
0906 0101010800FF 0600000000
05217E

 

Skrevet
Akkurat nå, Marius-H skrev:

Har dere fortsatt samme utspenning? Jeg har plutselig 3V ut :o

 

Jeg målte i går når jeg oppdaget problemer på min, og det er fortsatt 18/24v

Skrevet
1 hour ago, Marius-H said:

Har dere fortsatt samme utspenning? Jeg har plutselig 3V ut :o

 

Jeg sjekket min nå i ettermiddag. Fortsatt 24V / 18V ut.

Skrevet
2 hours ago, xibriz said:

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

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

 

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?

Skrevet
5 minutes ago, roarfred said:

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

 

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?

 

Det ser ut til å være flere endringer enn headeren til tidskoden.

Headeren til teksten "Kamstrup ..." osv. er endret fra 0x0a 0x0e til 0x0d 0x0e, det 0x0e er lengden i begge tilfellene.

To positive ting er:

1) CRC koden stemmer nå, så den kan brukes til feilsjekk.

2) De dupliserte 0xff'ene som jeg trodde var "min skyld" er borte.

 

Jeg har ikke gått gjennom hele meldingen ennå, så det kan være flere endringer.

 

Skrevet
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

Skrevet
11 minutes ago, roarfred said:

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

 

228 bytes read, 0 skipped
  0: 0x7e 0xa0 0xe2 0x2b 0x21 0x13 0x23 0x9a 0xe6 0xe7 0x00 0x0f 0x00 0x00 0x00 0x00
 16: 0x0c 0x07 0xe2 0x03 0x05 0x01 0x12 0x06 0x14 0xff 0x80 0x00 0x00 0x02 0x19 0x0a
 32: 0x0e 0x4b 0x61 0x6d 0x73 0x74 0x72 0x75 0x70 0x5f 0x56 0x30 0x30 0x30 0x31 0x09
 48: 0x06 0x01 0x01 0x00 0x00 0x05 0xff 0x0a 0x10 0x35 0x37 0x30 0x36 0x35 0x36 0x37
 64: 0x32 0x37 0x30 0x30 0x38 0x33 0x35 0x35 0x30 0x09 0x06 0x01 0x01 0x60 0x01 0x01
 80: 0xff 0x0a 0x12 0x36 0x38 0x34 0x31 0x31 0x32 0x31 0x42 0x4e 0x32 0x34 0x33 0x31
 96: 0x30 0x31 0x30 0x34 0x30 0x09 0x06 0x01 0x01 0x01 0x07 0x00 0xff 0x06 0x00 0x00
112: 0x18 0x4a 0x09 0x06 0x01 0x01 0x02 0x07 0x00 0xff 0x06 0x00 0x00 0x00 0x00 0x09
128: 0x06 0x01 0x01 0x03 0x07 0x00 0xff 0x06 0x00 0x00 0x00 0x00 0x09 0x06 0x01 0x01
144: 0x04 0x07 0x00 0xff 0x06 0x00 0x00 0x00 0xdb 0x09 0x06 0x01 0x01 0x1f 0x07 0x00
160: 0xff 0x06 0x00 0x00 0x05 0xea 0x09 0x06 0x01 0x01 0x33 0x07 0x00 0xff 0x06 0x00
176: 0x00 0x06 0x76 0x09 0x06 0x01 0x01 0x47 0x07 0x00 0xff 0x06 0x00 0x00 0x05 0xb4
192: 0x09 0x06 0x01 0x01 0x20 0x07 0x00 0xff 0x12 0x00 0xe9 0x09 0x06 0x01 0x01 0x34
208: 0x07 0x00 0xff 0x12 0x00 0xe9 0x09 0x06 0x01 0x01 0x48 0x07 0x00 0xff 0x12 0x00
224: 0xe9 0x71 0xb8 0x7e

Ja, det er første etter 0x02 0x19. Se listen over.  Men alle text strengene har nå kode 0xa i stedet for 0xd som før oppdateringen.

Jeg hadde tenkt å spørre hvordan dere fikk crc-koden til å stemme, men nå trenger jeg ikke det lenger.

 

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

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