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
    Einar mente det kunne være feil motstandsverdi på R12. Evt. kunne du sikkert også økt denne til 100k ohm
  2. roarfred
    Blir den da også hengende stabilt på ca 25V?
  3. roarfred
    Jeg mener det må være en feil her et sted! Du kan evt. prøve å koble ut LM358 og se om du da får en stabil spenning over kondensatoren. Gjør du ikke det, så prøv videre å koble ut R10. Da er det ikke lenger noe som helst som skulle belaste og tappe ut kondensatoren. Hvis du evt. har noen nærbilder så kan jeg hjelpe å lete etter feil...
  4. roarfred
    Det er noe som ikke stemmer her... Med 330 ohm og 470uF skal kondensatoren kunne lade seg opp på ca. 5*RC = 0,15 sek Med 25V vil det i start-øyeblikket bli trukket U/R = 75mA Dette er "litt" i overkant for kamstrup måleren, de sier maks 6mA. For å oppnå det må vi opp i U/I = 4166 -> 4.7 kohm Med 4k7, og 470uF blir oppladingstiden 5*RC = 11 sek (dette er fra helt tom og opp til full) Du kan godt prøve med større R9, gjerne 4.7k ohm, men prøv gjerne også å finne en mindre kondensator. Jeg tror noe i størrelsen 10-50uF kunne passet bedre... Tiden vi trenger å holde tilbake spenningen med kondensatoren er bare i det øyeblikket som HAN porten går lav. Hvis den skulle gå lav på en hel byte, så er det ca 1/2400 sekund = 0.41ms. Selv 10uF skal klare ca. et halvt sekund... (utlading gjennom 50k)
  5. roarfred
    Hvor mange volt var denne kondensatoren merket med? Klarer du å finne noe annet å bytte den ut med?
  6. roarfred
    Høres riktig ut det. Den negative verdien er fordi inngangen synker, men kondensatoren holder tilbake spenningen. Dioden sørger for at det ikke "lekker" tilbake. Da ville jeg sjekket R9. Hvis denne virkelig er 330 ohm, så prøv med en mindre verdi, f.eks. 100 ohm. Håper den er av feil verdi eller blåst eller noe...
  7. roarfred
    Altså en 1N4148? (Hadde i tidlige lister noen zener-dioder, men det skal ikke brukes lenger) Kan du måle med multimeter over denne? det bør vise ca. 0.6V med mest positive pinne er den uten strek (anoden)
  8. roarfred
    Tror ikke egentlig det... Tror heller det må ha noe med dioden å gjøre. Hvilken type er det? Kan den stå feil vei?
  9. roarfred
    NICE!!! Good catch dette med buffer size, dette var jeg ikke klar over Ser jeg du også allerede er på MQTT bakom der?
  10. roarfred
    Ser de sier at hardware buffer er 128 bytes. Med 2400 baud vil det ta 53ms å fylle bufferet. I sample-koden min (KamstrupTest.ino) hadde jeg noen delay linjer nederst i loop-funksjonen, for at samples skulle skrives ut litt støtvis. Har du noen delay inne i loop? I tilfelle burde disse fjernes...
  11. roarfred
    Kan være en god teori, men også enkel å få bekreftet. Et sted i koden gjøres en if (hanPort.available()) ... Kunne du lest denne inn i en egen variabel og sjekket for verdi 128? Noe slik (ikke testet): byte available = hanPort.available(); if (available == 128) debug.PrintLn("Serial port overflow!"); else if (available) { ... // eksisterende kode her }
  12. roarfred
    Jeg tror det holder om du prøver med halvering og dobling av begge to. (Sånn ca, bare ta den nærmeste du kommer halv og dobbel verdi, men prøv systematisk alle 9 kombinasjoner)
  13. roarfred
    Mistenker at dette da ikke er problemet, men det kan godt være at FTDI kretsen er mindre nøye på verdiene for "0" og "1" enn ESP kretsen. I følge databladet på ESP8266 så skal lav være 0.82V og høy min 2.48V (ved 3.3V driftspenning). R10 og R12 vil kunne spille inn her. Jeg har prøvd å regne på det, men klarer ikke å se at du skal kunne få feil verdier. Likevel, du kunne prøvd å minke og øke begge disse for å se om du får noen forandring. Den mye bedre metoden ville selvfølgelig være å måle med et oscilloscope, men det forstod jeg du ikke hadde tilgang på? En annen test som du kan gjøre er å koble fra HAN porten mens du måler spenningen rett på RX. Sett så en ekstern strømforsyning på HAN-porten og se hvilke spenningsverdier som skal til for at du får skifte på RX porten, og hva spenningen da blir på RX porten (for høy og lav verdi).
  14. roarfred
    Ja, prøv med batterier. Koble gjerne fra motstanden eller dioden da
  15. roarfred
    Høyst merksnodig! Har sammenlignet litt, og det ser ut som det er helt på slutten at det feiler... Er det mulig at opamp ikke har nok spenning mot slutten? Men da burde også dette vært et problem med FTDI... Se sammenligning i vedlegg. Se uten word wrap. Første linje er fra din måler med FTDI, andre er linje to fra tekstfilen du sendte sist sammenlingning.txt
  16. roarfred
    De to første bytes, dvs (A)0 E3 angir lengden, 0 E3 => 227 bytes. Dette er total lengde eksklusive 7E i start og stopp. Her er bare 221 bytes....
  17. roarfred
    Start og slutt på 126 (0x7E) er helt riktig. I DlmsReader::Read finner du logikken i innlesing av pakken. I prinsippet følger denne følgende mønster: Pakken må starte med 7E Frame-format valideres (må ha A som første del av byte nr 2) Lengden på pakken leses fra byte 2/3 Headeren sin checksum kontrolleres Den totale pakken sin checksum kontrolleres Siste byte er 0x7E Når alt dette slår til, så vil read() returnere true, for da vet vi at vi har en pakke hvor alt stemmer i hht. DLMS. HanReader klassen handler så om å bruke denne pakken for å slå opp spesifikke verdier. Jeg har testet med dine data (se KamstrupTest prosjektet), så vi vet at koden skal fungere. Forresten, hviken kode bruker du? I Code/ESPDebugger ligger en litt eldre versjon som nå kjører på min måler (tror ikke denne vil virke uten endringer hos deg) I Code/Arduino/HanReader/src finner du nyeste versjon (denne har noen endringer, eks. er buffer øket til 512 bytes) Det er absolutt å anbefale å bruke den sistnevnte. Denne er også lagt opp til å kunne bli et Arduino bibliotek. Du kan evt. kopiere inn alle filer fra Code/Arduino/HanReader/src og inn i Code/ESPDebugger. Etter det får du litt små justeringer, men du kan kikke i KamstrupTest.ino for hvordan det skal gjøres med List-enums fra Kamstrup.h filen
  18. roarfred
    Noe slik som dette: if (debug) debug->println(data, HEX); Kan da gjerne ha mellomrom og, så noe slik:
  19. roarfred
    Kan du fjerne alt som skriver utenom data, og legge inn et parameter HEX på denne? Fint med et mellomrom og sånn at utlistingen blir omtrent slik: 01 22 33 44 11 22 33
  20. roarfred
    Hvis du kjører KNX over IP allerede, så ser det ut som en god mulighet å kombinere mitt prosjekt med dette: https://github.com/envy/esp-knx-ip Dvs. samme hardware som jeg har, men en software som da broadcaster KNX telegrammer over IP. Kanskje noen plukker opp den? (Desverre litt begrenset fra min side hvilke prosjekter en kan gå løs på :))
  21. roarfred
    Tror kanskje jeg foreløbig har det eneste huset hvor en slik dings er i drift, så helt ferdig er det jo ikke Siden det rulles ut 3 ulike målere i norge nå, så ønsker jeg å få bygget inn støtte for disse, derfor har jeg litt assistanse fra andre for å samle inn feil og erfaringer. De fleste systemer for hjemmeautomasjon vil nok ha mulighet til å snakke med en MQTT server. For oversetting til KNX finnes en rekke prosjekter på github (krever sannsynligvis en hjemmesentral el.l. hvor denne koden kan kjøres), eller også ferdige devices som eks. http://cdinnovation.com/maestro-supports-iot-mqtt/ M-bus er jo signalet i seg selv, så her trenger du ingen ekstra device. (Utstyret du har må dog støtte M-Bus push) Modbus baserer seg på polling (så langt jeg kan se, liten erfaring med det). Du kunne dermed tenkt deg en device som cachet opp dataene som strømmes fra AMS måleren, og som kunne servere ut spesifikke verdier på forespørsel over Modbus. Høres intiutivt ikke ut til å være helt mainstream. Selve MQTT serveren kan du kjøre på en offentlig server (ser en kar som vedlikeholder en liste over ulike tilbydere her: https://github.com/mqtt/mqtt.github.io/wiki/public_brokers), eller du kan også kjøre dette på en Raspberry PI lokalt i ditt eget nett. (Oppsett er gjort på en halvtime, men ikke sikkert du har lyst til enda en dings å vedlikeholde, om du ikke ser andre fordeler med å ha en liten linux server i hjemmet)
  22. roarfred
    Ja, bare legg inn en linje som skriver ut den byte som mottas, og gjerne et mellomrom... Da skal det være relativt lett å kjenne igjen resulatet, og du kan evt. justere litt på kretsen mens den er live for å se om det dukker opp noe fornuftig... Er forresten kretsen helt lik den som nå ligger ute på min github, med unntak av R8 som er fjernet?
  23. roarfred
    No hard feelings Ville bare vise at det fungerer fra ende til annen, og understreke at poenget med MQTT er en åpen protokoll som ikke gjør deg avhengig av et abbonement og en konto noe sted. Er litt nysgjerrig på hva du mener med en mer lesbar protokoll. Hva ville stått øverst på lista?
  24. roarfred
    Usikker her... kan se ut som ingen data inn. Kan du måle rett på rx og se hva den sier? (Bør ligge på ca 3.3 og synke til ca 0.5) Forresten, sikkert lurt at vi tar dette i den andre tråden, siden denne var ment å ikke kuppe min
  25. roarfred
    Dette er forøvrig det nærmeste jeg har kommet noe ferdig: https://www.develcoproducts.com/products/meter-interfaces/emi-norwegian-han/ Framstår som proft og fint, men forteller egentlig veldig lite...
×
×
  • 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.