roarfred

Litt vrient å gi en garanti for dette... Er obs på følgende feil: GND/VCC på LM358 viser ikke på skjema. Her skal Pin 8 til VCC og Pin 4 til GND På ESP skal GPIO 0 til +3V3 via en 10k motstand På ESP skal GPIO 2 til +3V3 via en 10k motstand Jeg kan prøve å fikse dette i eagle skjema og evt. lage et forslag til en enkel PCB i løpet av kvelden Vær obs på at denne fungerer på min Kaifa måler, men er ikke testet på hverken Kamstrup eller Aidon. Jeg har dog ikke sett noe som beviser at dette ikke skal fungere ennå

Logger svært lite, men ser at jeg må begynne med det nå. Kom hjem og da stod måleren på 7500W... (Har laget et lite oled display som viser data)

Hehe, tror kanskje du er mer interessert enn menig mann ☺ Interessant om 2 sek verdien er en øyeblikksverdi eller et gjennomsnitt/integrert verdi...

Prøver å bli litt klok på OBIS koder... Ser ikke ut som det er fantastisk god "semje" mellom de ulike leverandørene: Kamstrup: Kaifa: Aidon: Antall lister varierer, og tidsrommet mellom listene, hvilke data som er med i listene og til slutt også selve OBIS kodene som brukes. Blir mest spennende å se om det nå stemmer at Kamstrup også sender ut hver eneste OBIS kode i forkant av selve dataene (mens Kaifa da er bevist å ikke gjøre dette). Håper det evt. lar seg gjøre å detektere på sikkert vis hva en får ut av hver måler... Selve OBIS inndelingen er beskrevet i den såkalte Blue Book, kapittel 7.2:

Stilig! Mye spennende en kan få til med litt eksterne APIer... PS: Hvis du refererte til det jeg beskrev tidligere som komplekst, så handlet det ikke om å finne pris, men å finne fram til at det var 627W du hadde i øyeblikksforbruk. Eks. kan dataene se slik ut fra måleren: 04 34 16 FF 80 00 00 02 01 06 00 00 02 73 55 0B 7E 7E A0 27 01 02 01 10 5A 87 E6 E7 00 0F 40 00 00 00 09 0C 07 E1 09 0F 05 04 34 18 FF 80 00 00 02 01 06 00 00 02 72 FD 17 7E 7E A0 27 01 02 01 10 5A 87 E6 E7 00 0F 40 00 00 00 09 0C 07 E1 09 Fra dette er det 627W det ene sekundet og 628W det neste. Prosjektet her handler om å få gjort om dataene fra elektriske bits til tall og tekst i json format, som igjen kan ligge til grunn for nettopp slike løsninger som du skisserer. (no offence, bare ment som en liten oppklaring)

Regner med at spørsmålet ditt er veldig hypotetisk, men ja, hvis jeg selv kunne programmere meg fram til tallet jeg ble fakturert for så hadde det vært interessant Uten verken hasjplantasje eller HB apparat, så ser jeg ikke noen stor grunn til å holde dataene skjult, men etter å ha sett motstanden mot disse målerne, så tror jeg ikke det er "gjengs oppfatning" PS: Hold oss oppdatert på det du får ut av måleren da! (Alt fra første test med voltmeter AC/DC er interessant)

Jeg tviler egentlig på at du slipper noe billigere unna med TI-kretsen. Når jeg kikket gjennom databladet nå, så kommer jeg på grunnen til at jeg lot den ligge i skuffen var at denne var beregnet på når du skal lage din egen sensor og så koble den til en M-bus. (Litt motsatt av det som er tilfellet her) Så, enkleste veien til målet tror jeg er å benytte en Arduino eller en ESP8266, og en enkel level-converter som den jeg tegnet. Da kan du bruke elektronikk og kode direkte fra meg. Videre installerer du Mosquitto MQTT server på PI'en din, så kan du konsentrere deg om ferdige verdier i Watt, Volt og Ampere, i stedet for å fikle med bits, bytes og manuell sjekking av CRC. De aller fleste programmeringsspråk og automasjonssystemer har gode eksempler på å koble seg til MQTT og å lese JSON. (Nå er det klart at jeg er litt "biased" her, så andre må gjerne skrike ut om de mener det er enklere veier til Rom)

Jeg har også et par slike TI-chipper liggende, kjøpt før jeg forstod hvor enkelt dette kan gjøres :) Den lille kretsen med en op-amp gjør ikke annet enn å omvandle en puls som skifter mellom 27V og 15V til en lik puls som skifter mellom 3.3V og 0V. Derfra kan du behandle signalet som helt "standard" seriell data. Standard i anførselstegn fordi det er helt spesifikt 2400 baud, 8 data bit, even parity og 1 stop bit. Jeg har ikke gjort dette selv, men det ser ut som RPi har en fysisk serieport og at det skal gå fint å programmere mot denne. Det du vil trenge er i prinsippet den logikken som du finner i prosjektet mitt. Fordelen med ESP (evt. annen microcontroller) er at de er super-billige, og du får en dedikert device til å gjøre en dedikert oppgave. I mitt eksempel handler det utelukkende om å dekode HAN signalet til en lesbar JSON og levere denne via MQTT. En annen fordel er stabilitet. Hos meg fungerer dette omtrent slik: En RPi kjører MQTT og fungerer som en HUB for alle devices Mange ulike ESP devices leser og sender MQTT meldinger En node.js app og en zwave-usb stick oversetter zwave til og fra MQTT Node Red kjører på samme RPi. Herfra kan en programmere hvilke meldinger som skal føre til hvilke andre meldinger Ingen devices vet om at noen andre eksisterer Eks. vises forbruk fra strømmåleren på en annen ESP-koblet device med en OLED skjerm. Denne OLED'en vet ikke om strøm-måleren, men har kun i oppgave å ta i mot meldinger på et bestemt format fra en MQTT. Strøm-måleren vet heller ikke om displayet, den bare sender meldiner om strømforbruk. Node Red er kjernen her som sørger for at en innkommende melding om strømforbruk fører til en ny utgående melding om at en tekst ønskes vist på et display. MQTT er for øvrig linket til IoT Hub i Azure, men det er en helt annen historie. Mesteparten av det vi har gjort på Arduino/ESP ligger ute på github.com/xnsense

Tøft! Ser det er Kamstrup måler du får. Er veldig spent på hvor mye hex kodene hos dem ligner på de som jeg fikk ut. (I følge Kamstrup dokument jeg har, så skulle de være noe annerledes...) PS: Ser i en annen tråd at du hadde en C# utfordring med å lese json... Har litt erfaring med C#/json om du står fast, så gi meg en lyd...

Har nå lagt til kode for WiFi tilkobling, og rapportering av JSON til MQTT. (Bruker ArduinoJson og PubSubClient for dette) I prinsippet er en dermed i mål med prosjektet, men vil gjøre to forbedringer: 1) Pakke sammen DlmsReader og KaifaHan til et mer generelt Arduino bibliotek 2) Forsøke å få til en mer generell løsning for KaifaHan, slik at vi kan støtte en generisk måler (men minstekrav at Aidon og Kamstrup funker)

Da har jeg lagt ut en komplett oppdeling av de tre listene fra Kaifa måleren, koblet sammen med forklaring fra OBIS-dokumentet. Reagerer litt på at de enhetene i dokumentet fra Kaifa åpenbart må være feil, evt. også har jeg litt problemer med å skjønne hva en double-long-unsigned skal være. Kan mao se ut som verdiene som kommer ut skal multipliseres eller divideres med 10, 100 eller 1000 før de stemmer med den oppgitte enheten. Eks har jeg 2424V og 2182A på den ene linjen min Det hele finnes her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kaifa OBIS breakdown.md

Du kan jo bare kombinere forbruk * pris, og gå i rødt når ting koster mer enn eks. to kroner per time... Jeg ville da gjerne ventet med å sette på klesvasken og gjerne trykket på knwppen som kobler ut varmtvannstanken i 30 min. (Som egentlig skulle vært autmatisert)

Skulle fått til en skjerm på kjøkkenet med en slik rullende over Media1.mp4

To av de tre dokumentene jeg fikk lå allerede ute på gihub hos meg. Det tredje fikk jegspørsmål om å ikke dele, fordi det var laget uten tanke på det. Det som lå i det siste var en hex-utlisting av data fra han porten, samme som mine filer under samples viser. I tilleg hadde deres fil en liten forklaring til hvert av data-elementene. Jeg skal lage en slik selv, men kan desverre ikke legge ut det dokumentet de sendte meg...

Diodeblink vil fungere greit, men vær obs på at denne er fryktelig enkel og fungere omtrent slik at du får en puls hver gang det har blitt forbrukt en Wh. Slike blink har vært tilgjengelige i mange år på ulike typer målere, så det finnes mange eksempler på å sette det opp. Hvis du lagrer historikk, og ikke er interessert i kuriositeter som fasedreiing og enkelbelastning på linjene, så vil denne kunne gi omtrent samme info som han kontakten. Jeg har en arduino-klasse som teller opp og ser på litt sum og gjennomsnitt i et av mine github prosjekter, men sannsynligvis finnes det langt bedre tilnærminger til dette. Artig at de skriver at du ikke kan koble til PC. Tror jeg har motbevist det. De burde kanskje heller si at selv om kontakten er en RJ45, så har det ikke noe med nettverk (ethernet) å gjøre, og at du med stor sannsynliget kan skade evt nettverksutstyr du kobler til.

Da har jeg fått god hjelp av NVE og NTE Nett. Her bekreftes at datastrømmen som jeg mottar er riktig og at denne ikke skal inneholde selve OBIS kodene. De virker litt overrasket over at Kamstrup har disse med, men antar standarden gir frihet til det. Løsningen er dermed at en må implementere tabellene med OBIS koder i software. Basert på OBIS ID (eks. KFM_001 for Kaifa) kan en finne rett tabell, ut fra OBIS List ID finner en så hvilke data som er forventet, hvilken rekkefølge de skal komme i og selve datatypen. Jeg skal forsøke meg på en slik implementasjon. På sikt skulle være mulig å legge en slik definisjon ut på en HTTP-adresse, slik at en har mulighet for å støtte flere målinger, evt. justeringer i data-strømmen uten å måtte uploade ny firmware. NTE Nett var også hyggelige nok til å sende meg en utlisting av HEX koder og deres egen forklaring / dekoding. Hyggelig å se at den lignet veldig på min egen tolkning

Ser forresten ut som disse finnes i både fast spenning og i variable:

Er det forresten noen som har kilder på hva som er safe å belaste han-porten med? Mener jeg leste 700mA et sted, og det ville i tilfelle være nok til å drive en ESP8266...

Ble litt usikker nå... stjal denne fra et adsfruit design med esp12 på, så håpet det skulle funke... kretsen har riktignok 5 ben, men det er ingen motstander. EN ligger nok til Vin og lurer på om adj ligger rett til out (evt flytende?). 150mA høres lite ut. Kanskje her også skulle vært en liten el-lytt... kjører fint fortsatt her, men jeg bruker foreløbig ikke wifi. Enkleste billige løsning som en noenlunde stabil hadde vært å foretrekke

ok, skal få det inn Regulatoren jeg har brukt her er en MIC5225-3.3YM5. Det er en smd, så litt "klure" for hjemmelodding. Hva som helst vil jo duge, så lenge den takler strømkrav fra ESP...

Det stemmer at opamp er forsynt fra VCC. Prøvde først med en forenklet variant der jeg forsynte den med 3.3V, men den var ikke spesielt happy med referansespenning på nesten 20V da Kondensatorer er alltid lurt, men jeg er desverre litt for grønn for å beregne... Har du noe konkrete tips tar jeg gjerne i mot en pull request, eller evt. bare en kommentar om hvordan det skal se ut. Snakker vi størrelse rundt 100nF eller noe annet? Edit: VCC er den likerettede spenningen fra HAN bussen. Kommer fram av kretesen. Ligger på ca 27V hos meg, men har tenkt at det skal fungere godt over varierende spenning, så lenge pulsene dropper minst 1/6 av denne. Edit2: Kanskje viktigere, VCC er ikke noe tilført. Det er bare et navn på dette punktet. Gjorde det slik for å forenkle skjemaet litt, tror jeg... Sa jeg at jeg er litt grønn?

Ok, krysser fingrene da. (Min erfaring er at denne protokollen er hel annerledes enn min måler på varmepumpen. Den er en zenner med m-bus. Der må jeg forspenne med 34V og så må jeg selv sende adresserte pakker for å spørre etter data. På AMS'en ligger det allerede en forspenning, og data pøses ut uten at noen har spurt etter dem. Forhåpentligvis er m-bus mer komplisert enn jeg trodde, og kanskje gatewayen detekterer dette selv) Kunne forresten vært kjekt med en link til denne gateway, hvis du har det...

Takk for info! Vet du at m-bus gateway vil fungere på HAN? Hva oversetter evt denne til?

Da har jeg tegnet en mer robust krets og lagt ut. Tilgjengelig i PDF og Eagle format. (Denne bruker ikke lenger zener-dioder, men istedet en LM358 op-amp. Kretsen er også komplettert med power supply og ESP8266): https://github.com/roarfred/AmsToMqttBridge/blob/master/Electrical/Schematics.PNG

Har mottatt litt mer detaljerte dokumenter fra NVE, men OBIS koder for de tre ulike målerne. Dokumentene ligger her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Documentation