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
    Jeg herjet mye fram og tilbake med dette før jeg gav opp... Du trenger bare den øverste delen da du skal bare motta data. Så kommer første utfordringen, inn-signalet ditt veksler mellom 20 og 15 volt, og du ønsker å oversette det til hhv 3.3 og 0V (litt slingring er lov, men si over 2.5 og under 0.5) Her er problemet i at transistoren må ha emitter rett i jord for å trekke deg ned så langt som mulig mot jord. Ved 15V skal denne altså ikke lede (dvs. minst mulig) mens ved 20V skal den lede mest mulig. Utfordringen er da at om du deler 15V ned til si 0.4V, så vil ikke 20V gi noe særlig mer enn 0.53V, så det blir litt hårfint... Ikke umulig, men sannsynligvis må du inn med et ekstra ledd for å forsterke. Husk også at denne kretsen vil invertere signalet, og det ønsker du ikke. Løsningen på det er å ha enda et transistortrinn for å snu tilbake, det hjelper deg også litt med problemet ovenfor. Jeg laget to løsninger, først en med en zener-diode som droppet bort ca. 12V fra inngangssignalet, og deretter brukte et slikt dobbelt transistortrinn. Neste bruker en enkel opamp (plukket tilfeldig LM358, fordi den lå lagelig til, og den tillot driftspenning rett fra HAN porten) Begge deler er tilgjengelig fra min github, for den første skissen må du bla tilbake på commits til nokså tidlig
  2. roarfred
    Dette var nettopp poenget mitt å ikke gjøre. Det kommer til å vrimle av slike dingser om en liten stund (men kanskje du må vente til 1. jan 2019), men utfordringen er at de kommer til å levere data til en skytjeneste utenfor huset ditt, hvorfra du kanskje via et API kan hente ut og bruke dataene igjen. Målet med mitt prosjekt var å gjøre dataene fritt tilgjengelige (dvs. bedre enn HAN), men uten å sperre dem inne i en proprietær løsning på nett. Fritt fram for hvem som helst å produsere og tjene penger på det jeg har gjort
  3. roarfred
    Dette burde kanskje være godt nok bevis på at det funker: http://etne.ro4r.no:4999/ui/ (Klokka nederst ligger 2t bak pga at den er UTM, og den tas fra pakken som kommer hver time)
  4. roarfred
    Det er for så vidt riktig at NVE har gitt e-lagene frist fram til 1. jan 2019 med å tilby kundene tilgang til HAN porten. At ikke Aidon er like klar som de to andre målerne finner jeg vanskelig å tro, men kanskje har de gode grunner til å holde tilbake... Jeg vil nok anta (håper!) at vi kommer å se endringer etter hvert, hos Kamstrup og Kaifa, og at kommunikasjon og innhold blir mer samstemt. Når dette skjer vil kretsen vi har laget her helt enkelt slutte å sende ut data, og vi må kode inn en evt. justering for det endelige HAN formatet.
  5. roarfred
    Takk, skal prøve å huske det denne gang
  6. roarfred
    Det er riktig at det ikke er 2 sek intervall på Kamstrup sin måler. De kjører med kun 2 ulike lister (data pakker), mens Kaifa og Aidon har 3. Hos Kamstrup kommer det data fra List1 hvert 10. sekund og fra List2 hver time. Se eksempel her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/HAN 20171019 xibriz4.txt Hvor lenge du måler lavt nivå med måleapparatet avhenger av mange faktorer. I teorien 229 bytes * 10 bit/byte / 2400baud = ca. 1 sek. Så kommer forsinkelse i måleapparatet og slikt inn. Med verdiene du skriver du får er jeg ganske sikker på at din HAN port er aktiv. Hadde for øvrig vært interessant å målt på en måler der vi vet at HAN porten ikke er aktivert. Noen som har lett tilgang til en? Fint om vi evt. også får med fabrikat...
  7. roarfred
    Det stemmer at det er samme serieporten som nyttes. Et alternativ kan være å bruke en SoftwareSerial, da kan du selv angi pinnene. En utfordring med dette er at denne ikke takler Even parity, men på Kamstrup måleren blir ikke det noe problem.
  8. roarfred
    1) viste seg å være jeg som hadde vært sparsommelig med størrelsen på et buffer. Var ikke plass til kjempe-pakkene fra Kamstrup Økt fra 256 til 512 bytes, og da kunne både list 1 og list 2 leses fint Var det noen som forstod begrepet OBIS? Er det slik at en gitt OBIS kode også burde angi størrelse (desimalplass) på verdiene? Kaifa sier strøm (L1) kommer på OBIS 1.0.31.7.0.255, at denne er i A(mpere) og at det er en long-signed Kamstrup sier strøm (L1) kommer på OBIS 1.1.31.7.0.255, at denne er i A(mpere) og at det er en unsigned Likevel ser det altså ut som verdien fra Kaifa skal deles på 1000 og den fra Kamstrup skal deles på 100 Jeg har funnet følgende koder for selve dataene: 09: byte array/string, brukt for dato, tekst og OBIS 06: 32 bit integer, brukt for støm, effekt 12: 16 bit integer, brukt for spenning hos Kamstrup 02: 8 bit integer (byte), brukt for antall elementer i listen 0A: String (bare hos Kamstrup, Kaifa nytter 09 for tekst) (Dette er ren reverse-engineering, veldig interessert i om det finnes dokumentasjon på dette) Edit: Står forresten noe som kan stemme med dette på side 34 i Blue Book: https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/Excerpt_GB8.pdf
  9. roarfred
    Nå begynner det å bli spennende her... Har laget to test-prosjekter, ett for Kaifa og et for Kamstrup. Legger så inn en sample av hver pakke-type i en konstant, for å simulere mottatte data. Finner ut: 1) Kamstrup sin List#2 klarer ikke å bli lest. Her må jeg debugge litt mer 2) Stømmen fra min måler kommer ut i A/1000 mens Kamstrup gir den i A/100 Festlig Aner at her kommer firmware update...
  10. roarfred
    Ja, det burde fungere. Merk at jeg har skrevet noe om at en bør bruke Serial (altså, hardware serial) for HAN port og noe annet (Serial1 eller software Serial) for debugging. Grunnen til dette er at det kun støttes å sette "even" parity på Serial. Siden du kjører med mer standard protokoll, så trenger du ikke dette, og står helt fritt til å bruke hvilken serieport du ønsker. (Ikke Serial1 da, tror den bare har TX og ingen RX). Merk deg at jeg i test-prosjektet ikke faktisk leser porten, men bare et fast byte-array. Regner med at du så det, men trikset er at hanReader.read() finnes i to varianter, en som tar et byte parameter og en som tar ingen parametre. Den sistnevnte vil bruke serieporten. Kunne godt tenke meg noen helt enkle ino filer som eksempler, så tar gjerne imot om du får til noe som fungerer i praksis Noe lignende dette: https://github.com/roarfred/AmsToMqttBridge/blob/master/Code/Arduino/HanReader/examples/read_han_simple/read_han_simple.ino
  11. roarfred
    Her finner en nå et prosjekt som verifiserer at data fra Kamstrup fungerer: https://github.com/roarfred/AmsToMqttBridge/tree/master/Code/Arduino Har skrevet om klassen HanReader, slik at den er helt fristillt fra KaifaHan. Jeg kom fram til at en kan bruke en egen .h fil for hver måler, bare med noen få enums som forteller hvilke lister som finnes og hva som finnes i hvilke lister. På denne måten kan jeg ha 3 implementasjoner for de tre målerne vi kjenner til i dag, mens en enkelt kan utvide om en senere får en annen måler med en helt annen rekkefølge på OBIS data. Forutsetninger jeg har tatt: 1) Data-pakken starter med 8 bytes som jeg ikke forstår helt hva er. Dette er likt for Kaifa og Kamstrup, så jeg håper det vil ligne for Aidon også. Hvis dette ikke stemmer, så må vi finne reglene for det og få satt variabelen dataHeader ut fra dette. 2) Uten at det er beskrevet i dokumentasjonen, har jeg funnet at dataene fra de to målerne starter med en timestamp, etterfulgt av en ID på datapakken. Det er en forutsetning for koden at dette skal stemme, så det blir spennende å se med Aidon måleren...
  12. roarfred
    Da er parsing av data fra List 1 dokumentert for Kamstrup: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md Ser jeg må omstrukturere koden litt, slik at vi skal klare å kjøre samme kode på alle målerne...
  13. roarfred
    Jeg skal prøve meg på det. Tror det skal være en grei sak å fore koden med data fra din måler. Det aller meste vil være likt, og i prinsippet tror jeg det vil fungere helt enkelt ved å justere enum-verdiene til å stemme med liste-verdiene fra Kamstrup (siden obis-kodene er med i dataene må disse variere i verdi, slik at de stemmer med indeks av oppføringen) Gir en lyd
  14. roarfred
    Dette er Kaifa måleren
  15. roarfred
    Ser at en forskjell er at Kaifa er oppgitt mtil å kunne levere 21mA ut på HAN porten, mens Kamstrup bare oppgir 6mA. Det burde holde, men mistenker litt at din boks kan føle seg overbelastet I oppstarten (kretsen vil da trekke 20V/330 ohm = 61mA, noe som også er i overkant for Kaifa!), og at den kanskje shutter ned som en slags fail-safe. Prøv å bytte ut R9 med en større verdi, 4.7k vil begrense strømtrekket til ca. 4.2mA ved tom kondensator. Merk at det da vil ta litt lenger tid for å lade opp, men ikke så veldig lenge 5RC = 2.2 sekunder, ca. men egentlig litt lenger pga. tapping gjennom R11/R13. Utfordringen kan være at kretsen da ikke klarer å holde oppe VDD når signalene kommer, I tilfelle bør R11/R13 byttes ut med noe større også. Så lenge forholdet mellom de to er ca. det samme, så er det greit.
  16. roarfred
    Har et lite håp om at api tjenesten til adax ikke er noe de tar betalt for og dermed heller ikke vil gjøre alt for å beskytte. Vi får se ☺
  17. roarfred
    Vet du hviken måler du får?
  18. roarfred
    Det funker!
  19. roarfred
    Fikk beskjed fra en i ADAX at henvendelsen ble videresendt til noen som hadde greie på det... så da ble den ikke avvist i det minste
  20. roarfred
    Devicen er den som er beskrevet her: https://github.com/roarfred/AmsToMqttBridge Kunne i teorien også vært laget for mobilnett (med en annen krets enn ESP8266 evt. en GSM modul), men burde da heller samle opp og rapportere i chunks. Dataene kommer fra måleren annet hvert sekund. Sannsynligvis enklere og billigere å få til et trådløst nett.
  21. roarfred
    Nettverkskabelen her trengs bare fra HAN porten og fram til denne device. Derfra er det WiFi. I tillegg må du ha strøm til kretsen, løsningen jeg laget bruker en std micro usb mobillader.
  22. roarfred
    Så dere denne: https://www.tu.no/artikler/nve-vil-gjore-det-dyrere-a-bruke-mye-strom-pa-en-gang/410203 Kan bli veldig nyttig å ha direkte tilgang til målerdata Tenker litt at VVB er den første og mest "bang for the buck" tingen som burde styres. Hos meg har denne ett 2kW element i tillegg til 3x5kW. Sistnevnte styres av en kontaktor. Er det kosher å hjemme-automatisere styring av kontaktorer i huset, eller er det autorisert el-installasjon?
  23. roarfred
    Da har jeg reorganisert litt under samples, og lagt til en forside for å kunne avdekke variasjoner: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/readme.md
  24. roarfred
    Flott! Stemmer det at du også måtte fjerne R8 for at det skulle virke? Kan du evt. prøve med denne igjen, for å bekrefte? (Jeg prøvde å regne på det, og klarte ikke se at det ikke skulle fungere, men samtidig er det ikke kritisk med denne hysteresen)
  25. roarfred
    Damn, det var jo litt sykt at ikke de kjører med samme settinger på serieporten... Det kommer jevnlig time-pakker ca. 7 sekunder over hel time. Disse er 303 bytes istedet for 229 Får jeg lov til å bruke denne filen på github prosjektet mitt? Så kan jeg dokumentere litt bedre der
×
×
  • 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.