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

roarfred

Medlemmer
 Vis profil  Se deres aktivitet

  • Innlegg

    336

  • Ble med

  • Besøkte siden sist

  • Dager vunnet

    7

 Innholdstype 

Alt skrevet av roarfred

  1. roarfred
    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...
  2. roarfred
    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: 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.
  3. roarfred
    @Ø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.
  4. roarfred
    Fikk kretskort i dag. De sendte 12 istedet for 10, mulig de vil kompensere for evt. feil... Kortene ble bestillt 2. mars, med 7 dagers prosessering. Viser seg å være 7 arbeidsdager, fra de får bestilling til de blir sendt, men 12 dager er ikke så ille. (PCB ble bestilt fra EuroCircuits, kan se ut som de holder til i Belgia) Loddet på komponenter. Så at ESP fikk strøm. Plugget i FTDI kabel og så AI Thinker ready... melding Patchet om HAN til labben og plugget denne i. Sjekket JP1 med oscilloscope, og så finfin 3.3V TTL komme rasende inn Satte jumper på JP1, lastet opp ESPDebugger sketch, og så på serial output... Her var det jo bare rabbel! Så kom jeg på, jeg har jo debug på Serial1, og det har jeg ikke tatt høyde for på kortet. Fant ut at Serial1 TX er Pin02, og at denne er lagt høy via R3. Kunne derfor koble til FTDI via en kabel, og voila! (Helt fantastisk at vi for to dager siden så at debug vil fungere helt fint via vanlig Serial også, om en kjører denne på samme config som HAN) En sjelden gang bare funker ting, "out of the box" PS: Er i gang med å lage en mer skikkelig software. AP boot, DNS, config i EEPROM, støtte for alle målere, osv.
  5. roarfred
    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.
  6. roarfred
    hehe, så ut som vi fant løsningen samtidig her godt jobbet!
  7. roarfred
    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...
  8. 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
  9. roarfred
    @xibriz, ligger den eksakte koden du kjører ute noe sted? Jeg kunne prøvd å simulere litt...
  10. roarfred
    @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.
  11. roarfred
    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
  12. roarfred
    Fikk svar fra Kamstrup på en forespørsel dit: 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
  13. roarfred
    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...
  14. roarfred
    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
  15. roarfred
    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...
  16. roarfred
    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
  17. roarfred
    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?
  18. roarfred
    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?
  19. roarfred
    @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
  20. roarfred
    Dataene er faktisk gyldige. Skal lese ut verdier og se om eks. list identifier har endret seg...
  21. roarfred
    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?
  22. roarfred
    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
  23. roarfred
    Wow! https://aisler.net/p/VPVMJEBF Hadde jo vært sykt bra om de kunne montert også da
  24. roarfred
    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...
  25. roarfred
    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.
×
×
  • 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.