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
    Når jeg har fått tenkt meg litt om så er nok ikke dette helt ideell måte å gjøre det på. Utfordringen er at vi i praksis snakker om en annen måler her, selv om fabrikaten er Kamstrup. ListID er slett ikke noen ID, men faktisk et tall som angir antall elementer i listen. Om Kamstrup kommer med flere modeller etterhvert, så er det stor sjans for at vi kan få en annen modell som har samme antall elementer i listen, men andre felter/rekkefølge. Det bør dermed lages en spesifikk implementasjon per modell-nummer (evt. også per firmware, men det får vi se etterhvert) Enn så lenge, så var det ingen like antall her, så det eksemplet jeg sendte funker sikkert godt nok til en test
  2. roarfred
    De to listene vi har definert i dag er hhv 0x19 (25) og 0x23 (35). Om vi fjerner spenning og strøm på L2 og L3 blir det fire elementer og fire til for OBIS kodene, dvs. 8 til sammen. 25-8 = 17. Føler vi er inne på gjetting-basert-programmering her nå, men det er kanskje verdt et forsøk å legge inn to nye lister på Kamstrup for disse og se om det funker? Sånn røfflig noe slik: enum class Kamstrup { List1 = 0x19, List2 = 0x23, List3 = 0x11, List4 = 0x1B }; enum class Kamstrup_List1 (...) enum class Kamstrup_List2 (...) enum class Kamstrup_List3 { ListSize, ListVersionIdentifier, MeterID_OBIS, MeterID, MeterType_OBIS, MeterType, ActiveImportPower_OBIS, ActiveImportPower, ActiveExportPower_OBIS, ActiveExportPower, ReactiveImportPower_OBIS, ReactiveImportPower, ReactiveExportPower_OBIS, ReactiveExportPower, CurrentL1_OBIS, CurrentL1, VoltageL1_OBIS, VoltageL1 }; enum class Kamstrup_List4 { ListSize, ListVersionIdentifier, MeterID_OBIS, MeterID, MeterType_OBIS, MeterType, ActiveImportPower_OBIS, ActiveImportPower, ActiveExportPower_OBIS, ActiveExportPower, ReactiveImportPower_OBIS, ReactiveImportPower, ReactiveExportPower_OBIS, ReactiveExportPower, CurrentL1_OBIS, CurrentL1, VoltageL1_OBIS, VoltageL1, MeterClock_OBIS, MeterClock, CumulativeActiveImportEnergy_OBIS, CumulativeActiveImportEnergy, CumulativeActiveExportEnergy_OBIS, CumulativeActiveExportEnergy, CumulativeReactiveImportEnergy_OBIS, CumulativeReactiveImportEnergy, CumulativeReactiveExportEnergy_OBIS, CumulativeReactiveExportEnergy };
  3. roarfred
    Syntes ikke dette så helt galt ut... Riktig at du mangler en E7 for avslutting, men ta en kikk på disse to sidene for å se om du ikke også har målerdata innimellom alt annet hos deg: https://github.com/roarfred/AmsToMqttBridge/tree/master/Samples/Kamstrup https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md
  4. roarfred
    Dette er nok riktig sted å begynne da: https://github.com/roarfred/AmsToMqttBridge/tree/master/Electrical/HAN_ESP_TSS721 Her finnes også komponentliste med direkte linker til digikey. ESP er mulig ikke tilgjengelig her, men kan finnes på eks. ebay, banggood, aliexpress, kjell&co el.l. til en billig penge PS: Merk at det også finnes ferdige moduler å få kjøpt om du heller ønsker det, se evt. tråden "The easy way":
  5. roarfred
    Ser de forer en Raspberry Pi med denne. Hvis du vil ha kablet ethernet, så er det ikke noe dårlig alternativ å kjøre en sånn mbus konverter rett inn på en I/O pinne eller inn på USB på en Pi. Heller ikke prismessig...
  6. roarfred
    Ingen dumme spørsmål! Utfordringen i dette tilfellet er at kretsen baserer seg på en ESP8266 der en får en liten arduino med WiFi for 3-4 dollar. I de fleste tilfeller er det kanskje også mer tilgang på strøm enn fast ethernet i sikringsskapet, men her er jo det litt forskjeller på hvordan bygg er oppført. En tanke kan også være å patche HAN kontakten over til et sted der en kan plassere denne måleren innenfor trygge omgivelser og WiFi dekning (altså, ta HAN signalet ut av skapet heller enn å ta ethernet inn) Hva tenkte du var største utfordring med WiFi framfor kablet nett? Stabilitet, dekning eller annet?
  7. roarfred
    Jeg løste det ikke ? hos meg er det et svakstrømskap rett under, så der kan jeg borre meg gjennom. Men, beste tipset var kanskje ringetrafoen eller en din montert stikkontakt. Din montert usb uttak lette jeg litt etter, det hadde kanskje vært mest fancy, men jeg kunne ikke finne noe slik
  8. roarfred
    Jeg har stort sett brukt ESP12E eller F. Bør koste rundt en tjuekroning: https://m.banggood.com/10Pcs-ESP8266-ESP-12F-Remote-Serial-Port-WIFI-Transceiver-Wireless-Module-p-1067471.html?rmmds=search
  9. roarfred
    Mitt lokale e-lag etterforsket dette litt og kom med følgende forklaring: (sannsynligvis er da spenningen alltid 0V på L2 hos meg)
  10. roarfred
    Spennende! Min umiddelbare reaksjon var at baud rate måtte være feil, men at dere leser ut spenning, frekvens og kanskje en sjekksum her sannsynliggjør at det likevel stemmer. Det som er sikkert er at dette ikke er DLMS data, da skulle alle pakker startet og sluttet med e7. Så spørsmålet er om det er en helt annen firmware som var lagt inn initielt på disse målerne. Og, kan den reverse engineeres før det deployes ny firmware til Aidon? Et lite tips ang checksum, det finnes en site her som kan hjelpe dekode, der det kjøres en lang rekke kjente checksum algoritmer på en valgfri datakilde. Se om du finner treff her: http://crccalc.com
  11. roarfred
    Eller hiver på en clamp rundt en av fasene, eller leser av IR måleren... Har du fysisk tilgang så klarer jeg ikke se hva du kan utrette av ekstra sikkerhet med kryptering på HAN (med de dataene som finnes der nå da). Fra avleseren må ting selvfølgelig være kryptert WiFi.
  12. roarfred
    Flere som har Kaifa måler? Er de levert forseglet? Ser i brukermanualen at det skal være totalt 8 forseglinger, men hos meg er det kun forseglinger i skruene til venstre. Dvs. deksel til M-bus er åpent... og rekkeklemmer og moduldeksel har forsegling i en av to skruer.
  13. roarfred
    Denne er spennende! Her snakker vi direkte tilkobling til den ekte M-Bus (bak det lille dekselet på Kaifa måleren) og ikke data fra HAN porten?
  14. roarfred
    Enig i at de burde kjørt hardt på en spesifikk output fra måleren. Litt usikker på om tidsgrensen de har satt for implementasjon er urimelig for noen...
  15. roarfred
    Tror vi kan skrive under på at det ikke er noe sentralt system eller en gang samme behandling av de som ønsker HAN porten åpnet. Merket meg at min henvendelse om åpning gikk fra Etne E-lag, til Valider, hvor de hadde en tekniker som fikset biffen. Valider var (er?) de som har/hadde kontroll på utrulling av Kaifa målere... Virker på meg som at det er veldig liten samkjøring på både formater og prosedyrer, og når det kommer til "sikring" av dataene så begynner det hele å bli en vits. Tror egentlig leverandørene har snakket sammen og samarbeidet, selv om det ikke er helt offisielt. Kanskje det mest spennende blir om Aidon deployer ut en løsning med 09-buggen
  16. roarfred
    Jeg ser folk klager litt på AMS målere, noen pga. den enorme strålingen og noen fordi strømforbruket har gått opp. Hvis en skal mene noe om dette, så burde det kanskje være at det vil være en kostnad med installasjon, og at vi som forbrukere til slutt er de som betaler for gildet. Spørsmålet er så om dette med direkte tilgang til egne data kan go noen gevinst. Egentlig litt skeptisk til dette, men poster her en kurve av mitt eget forbruk. (Jeg fikk ny AMS måler montert i september 2017, tror det stemmer godt med starten på denne tråden) Nå skal det sies at jeg ikke har vært flink til å lese av, så det er mye stipulering, men innimellom har jeg rapportert inn. Det mystiske er at jeg har betydelig lavere forbruk sammenlagt nå. Litt obs er jeg jo, siden jeg har hatt "litt over gjennomsnittet fokus" på strøm siste halvåret, men har liksom ikke gått i dvale heller... Som en artig kuriositet, AMS måleren min rapporterer tidvis 0V på L2. Den kan gjerne ha strøm på alle tre faser, men mangle spenning på L2. Dette så jeg da jeg dekodet sample data i fjor høst, og så det igjen nå. Kan jo være jeg har trukket vinnerloddet, men skal driste meg til å spørre mitt lokale e-lag om det kan ha noe å si...
  17. roarfred
    Amen!
  18. roarfred
    Nåvel, jeg sitter i Etne, en times kjøring øst fra Haugesund. Grunnen til at jeg var i kontakt med NTE var at jeg ble henvist dit fra NVE, for spørsmål ang. Aidon målere. Har bare Kaifa selv, både hjemme og (snart) på hytta, men prøver å få ting til å fungere for alle...
  19. roarfred
    Takk for gode tilbakemeldinger, alle!! Når det gjelder justering av verdier, så har jeg valgt å ikke gjøre noe med disse, dvs. at de leveres i json slik de ligger i DLMS formatet. Eks. ligger spenning som et 32 bit heltall, som skal divideres med 10 for å gi rett spenning i volt. Det er ingen informasjon i data-strømmen som sier noe om dette, men godt mulig at OBIS koden har dette spesifisert i et register. Vet vi var inne på noen detaljer omkring OBIS her tidligere, men tar ikke helt igjen om dette kan deduseres med logikk eller om det må slås opp i en tabell. (og evt. om det i det hele tatt er spesifisert) Sannsynligvis vil hver enkelt målertype ha sitt eget oppsett på hvilke data som kommer, og i hvilken rekkefølge. Arduino-biblioteket HanReader er generell nok til å kunne tolke enhver slik "liste", men må siden spørres om å få ut eks. "heltall fra element nr. 8" i listen. Her er det implementert separate klasser for å systematisere oppsettet til hver målertype (Kaifa.h/Kamstrup.h), og her er også noen justeringer jeg vet om med eks. enfas-målere som vil ha et ulikt antall elementer. Trafomålte varianter har jeg bare såvidt hørt om, så det hadde vært veldig spennende å få kikke på output fra dem også. Litt avhengig av hvor mange ulike målere vi ender opp med til slutt, så må det vurderes om det kanskje er mer hensiktsmessing å ignorere målertype fullstendig på Arduino-siden, og heller rapportere inn et array i json, der alle elementer fra listen er inkludert. Eks. vil Kamstrup da ha annet hvert element som en string, der selve OBIS koden viser. For den som skal konsumere dataene, så betyr det kanskje ikke så mye å måtte gå til data[8] istedet for til data["UL1"] for å finne spenningen på L1? PS: Fikk svar fra NTE i dag at de ikke har eksempel-data for Aidon, men de sender med en definisjon tilsvarende den PDF som vi har sett tidligere. Det vises til at de har valgt å avvente implementering av HAN dataprofil inntil endelig avklaring omkring kryptering/fysisk sikring av HAN port foreligger fra NVE/Datatilsynet.
  20. roarfred
    Noen oppdateringer fra den siste uken... 1) Laget meg en boks selv og 3D printet. Ble helt greitt til å gjemmes bort i sikringskapet (bilder nedenfor) Om interesse ligger STL filer på github: https://github.com/roarfred/AmsToMqttBridge/tree/master/Electrical/HAN_ESP_TSS721/enclosure (Brukt Fusion 360 her, er det noe annet enn STL format som er fornuftig å dele?) 2) Har laget en mer fullverdig Arduino "sketch", med følgende features: Boot som Access Point om ikke config finnes, eller om Prog-knappen trykkes ned innen 5 sek etter oppstart Webside for å konfigurere (bruker innebygget DNS, så hvilken som helst http-url funker, eks. http://config) SSID / Passord Meter Type (Kaifa / Kamstrup / Aidon) MQTT server, port, brukernavn og passord Lagrer config i EEPROM (første byte er en "identifying byte" som kan endres om en endrer på strukturen) Støtter Kaifa og Kamstrup måler, og tilrettelagt for Aidon (sendt forespørsel om å få test-data fra dem for å fullføre. Får se om det kommer noe, ellers får jeg ta en best guess) Temperatursensor leses av og rapporteres sammen med hver sending på MQTT Mottak av MQTT meldinger (klargjort, med egen metode, men ikke kodet noe spesiellt her) - kan enkelt brukes for OTA update Debugging via samme connector (litt klønete, må koble til/fra TX på FTDI når evt. HAN port skal brukes, og en må ha en terminal som støtter 2400 baud 8E1 for Kaifa) Utnytter blå LED på ESP, for litt status: Lyser i 5 sek etter oppstart, for å vise at du kan trykke Prog-knappen for å boote som AP Blinker hvert sekund (50% syklus) hvis startet som AP Under normal drift, tennes hver gang en pakke på HAN porten er dekodet, og lyser til den er levert på MQTT. (På Kaifa, flash hvert 2. sekund) WiFi/MQTT reconnect Da tror jeg det er på tide å gjøre en solid oppdatering på all dokumentasjon på github... Som de sier i politikken om dagen, lik og del! Config Kretskort i boksen "Montert" vha friksjon i sikringsskapet
  21. roarfred
    Oi, @ArnieO, tror jeg er med på hva du sier, da at vi får ut en TTL på 3.3V fordi TSS sin VDD pinne er 3.3V og ikke fordi vi styrer dette fra ESP sin tilførselspenning. Er med på at det måtte vært annerledes om vi skulle ha ut en 5V TTL, men jeg kan godt leve med denne kuriositeten Takk for innsikt!
  22. roarfred
    @ArnieO, Pin 9 og 11 er koblet sammen. Dette er vist i Figur 7 i TI sitt datablad. Disse vil holde en slags "power" tatt fra HAN porten, men den brukes ikke til noe, og dette punktet skal dermed heller ikke være koblet til noe annet enn R10 og C5. (Hadde vi hatt en mindre stømkrevende krets enn ESP8266, så kunne dette punktet forsynet kretsen med strøm fra HAN porten) og merk at lablene merket med PWR_FLAG ikke har noe med hverandre å gjøre. De er utelukkende der for å bekrefte at dette er et "Power" punkt, slik at elektrisk sjekk diagram fungerer. Jeg har loddet sammen to slike kort og testet dem litt uten problem. Et lite minus er at der ikke er lagt til rette for debug-port på Serial1, men litt tidligere i tråden ble det antydet at vi kanskje kan kjøre debugging på samme port som programmeringen. (og da samme port som HAN porten er koblet til, men vi bruker bare RX på HAN og bare TX på debug. Det som kan gjøre dette litt klønete er at HAN port er satt opp med 2400 baud og 8E1 på Kaifa, og dermed må også debug skje på samme setup)
  23. roarfred
    Jeg tror nok de med rette kan kalle det M-Bus fortsatt, men lurer på om dette kan være et tillegg (Push) som er kommet inn i senere tid. Jeg har også implementert en mer tradisjonell M-Bus løsning der min ESP8266 må spørre et kalorimeter om å få ut data. Når jeg har sammenlignet disse, så ser jeg ikke noe mer enn den elektriske protokollen (spenningsnivåer for 1 og 0, og baud-rate) som er felles. Eks. er kalkulasjon av checksum forskjellig. Er på fryktelig tynn is her, men godt mulig andre vil korrigere? Uansett er nok konklusjonen at en må ha en separat leser for HAN og evt. en annen for mer tradisjonelt M-Bus utstyr.
  24. roarfred
    M-Bus på AMS målerne er litt spesiell. Her er det kun en-veis kommunikasjon, og det skrives i dokumentasjon at det kun skal være en device tilkoblet. Jeg kan ikke se at det skulle gjøre noen skade om flere "lyttet på linjen", men en ville uansett bare få lese ut de samme data. Å koble noe annet M-Bus utstyr på samme linjen som andre sensorer tror jeg er en dårlig ide, uten at jeg kan si at det er helt umulig. (Vil tippe at AMS måleren fullstendig igjorerer om det er annen kommunikasjon på bussen, og bare pøser på data som vil forstyrre)
  25. roarfred
    Ja, utfordringen ligger i svært ulik spec på hvilken belastning. Tror Kamstrup kommer dårligst ut med 144mW. Med ZWave eller Zigbee ville det vært enklere, men ESP8266 er nokså kravstor her. Vet du noe om ESP32 er noe bedre her?
×
×
  • 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.