roarfred

Disse dataene sier forøvrig: 02 1B - Byte (02): 27 elementer i listen som kommer (1B). Se altså OBIS koden i seg selv som et separat element fra verdien til den tilhørende OBIS koden. I enum vil du se at jeg på Kamstrup måleren har to verdier for hver OBIS, en for selve OBIS koden og en for den tilhørende verdien. Jeg trodde lenge at dette var en slags id på listen, men det er så enkelt at den bare angir hvor mange elementer som kommer. 0A 0E 4B616D73747275705F5630303031 - String/byte array (0A), lengde 14 (0E), tekst: Kamstrup_V0001 (som altså er den samme som Kamstrup sin 3-fas måler, og dermed gjør dette litt vanskelig) Det som hadde vært ønskelig hadde vært at vi fra arduino-kode (evt. portet til noe annet) kunne ut fra de mottatte dataene forstå hvilken måler som en fikk data fra. Hvis noen har gode ideer her, så la meg høre!

Dette med buffer overflow er litt tricky, men ESP har ikke noe problemer i seg selv med å operere på 2400 baud uten å bli svett... Sannsynligvis er problemet annen kode som trigges fra loop() koden som fører til forsinkelse i innlesingen, og som gjør at bufferet fylles. Så lenge en venter til pakken er fullført, så bør en ha ca. 10 sekunder på seg på en kamstrup måler til å gjøre unna rapportering av dataene... Edit: Det stemmer at lengden på pakken (0FD) er eksklusive start og stopp bytene. Hvis du bruker arduino-koden, så ligger her også kontroll av checksom i header (7BEB hos deg tror jeg) pluss kontroll av checksum for hele pakken (EB54 hos deg), slik at du aldri vil få ut verdier for målinger basert på ukomplette data.

Jeg vet ikke mer enn å komme med litt kvalifisert gjetting her... Sannsynligvis vil kraftleverandørene tilby dataene også via et API, men det er ikke noe krav fra NVE om dette, så det betyr at grunnene for å gjøre det er enten rent kommersielle (at de kan ta betalt for tjenesten) eller indirekte kommersielle (at de får konkurransefortrinn ved å gjøre det), eller også at de kan se potensiale for bedre utnyttelse av eksisterende kraftlinjer (dvs. de kan få betalt) Som Morten sier er det også noe med samtidigheten her som jeg tviler på blir like god som om du får data rett fra måleren. Da kommer det litt an på hva du ser for deg å bruke dataene til. Hvis du eks. vil en fin graf av historisk forbruk og gjerne analysere opp mot utendørs temperatursvinginger, så vil det fungere fint. Hvis du derimot ønsker å bygge automasjon som styrer nedprioritert utstyr (lading av el-bil, vvb, el.l.) når prioritert utstyr (kaffetrakter) startes, så vil du heller ønske data direkte fra kilden. Merk at NVE gikk ut med antydninger om progressiv prising av kraft. (dvs. at du betaler mer enn dobbelt for 2kW enn for 1kW, og at dette ikke alene styres av tid på døgnet) Om det skulle slå til er det ikke lenger nok med et tidsur for å kontrollere forbruket.

Vet ikke om du har sett denne, men den kan være litt nyttig: https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/OBIS List Information - KAMSTRUP.pdf Hos deg kommer verdiene 1-7 helt fint, deretter verdi 8 (strøm L1) og så 11 (spenning L1). Kanskje naturlig at du ikke får verdier for L2/L3 på en enfas måler, men skulle så inderlig ønsket at de hadde beskrevet dette et sted Hvis du kikker på data for pakke 2, så vil du helt sikkert se noe lignende. Om du vil bruke arduino koden kan du da enkelt lage nye enum'er som bare følger denne rekkefølgen. (Altså, justere Kamstrup.h og plukke vekk noen verdier herfra for de som mangler, bare pass på at rekkefølgen fortsatt stemmer) De første linjene kan du for øvrig knekke opp noe slik: FE => Start A0 B3 => Lengde på hele pakken 2B 21 13 => Adressering 8E53 => Checksum (CRC-16) for header data E6 E7 00 0F 00000000 => Usikker, men mulig noe LSAP? 09 0C 07 E1 0B 0F 03 00 1E 0A FF 80 00 00 => Dato/Tid: 2017-11-15 onsdag 00:30:10 02 11=> Den påfølgende strukturen består av 17 elementer 0A 0E 4B 61 6D 73 74 72 75 70 5F 56 30 30 30 31 => OBIS List ID: Kamstrup_V0001 Du finner mer forklaring og eksempler her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Samples/Kamstrup (se også obisdata.md)

Dette var litt annerledes ja Sa du noe om at dette var en måler som du fikk for lenge siden? (Eller var det noen andre) ID her sier Kamstrup_V0001 (0A 0E 4B616D73747275705F5630303031) og den burde de brukt som en måte å skille på ting... Uansett, I Kamstrup.h finner du definisjonen av listene. Du kan selv lage deg en variant her som stemmer med den utlistingen som du får. Alt ser ut til å følge samme mønster, men det er litt andre verdier kanskje i en annen rekkefølge. To spørsmål: 1) Du nevner liste2 stemmer ikke, betyr det at liste1 stemmer? 2) Var denne utlistingen komplett? (Ser litt "rar" ut på slutten og den burde vært avsluttet med 7E) PS: I HanReader::FindValuePosition finner du sjekk på de ulike data typene (09, 0A, 06 etc). Med dette kan det være litt enklere å splitte opp pakken din. https://github.com/roarfred/AmsToMqttBridge/blob/master/Code/Arduino/HanReader/src/HanReader.cpp#L79

Fant også denne, men utelukkende på develco sine sider...

Tror vi må satse på en ren SMD variant når vi har noe som fungerer stabilt. Da vil nok både assembly og tooling gå drastisk ned. Hva er noe slik verdt? 500 kroner inkl mva? Da må vel i tilfelle produksjonskostnaden ned i en hundrelapp om noen skal være interessert?

Antennen som monteres er nok for innrapportering av data til kraftleverandøren, og denne vil nok være på et eget kryptert nett som vi forhåpentligvis ikke får tilgang til. All tilgang fra forbruker sin side skal være tilrettelagt gjennom HAN. Det vi har sett så langt er at HAN er tilgjengeliggjort gjennom en fysisk RJ45 plugg med et M-bus elektrisk signal. Mener jeg også så noe om at HAN kunne bli tilgjengelig trådløst (over zigbee el.l.), men ble usikker nå på om det var ett av alternativene som ble vurdert, eller om det ble et krav fra NVE. Det jeg har funnet av dokumentasjon er lagt litt uorganisert i mappen documentation på github Github er for øvrig et fantastisk sted å samarbeide og samle slike prosjekter. Hver og en kan forke ut sin egen private kopi, hvor en kan jobbe fritt med redigering (legg til flere filer, oppdatere dokumentasjon, skrive kode etc) og så kan en enkelt be om å få oppdatere "master" med en pull request. En annen måte å bidra på er å opprette issues direkte mot prosjektet, så kan en diskutere der og vurdere evt. utvidelser og tillegg etter hvert. Sikkert mange som er på Github allerede, men jeg vil sterkt anbefale å bruke litt tid på å engasjere seg der for alle som har lyst å bidra på den ene eller andre måten: https://github.com/roarfred/AmsToMqttBridge Doner gjerne noen kroner til veldedige organisasjoner etter eget frie ønske! Noen hjelp i dette prosjektet er det neppe, men det blir en bedre verden til slutt

Fikk du forresten pris på ferdig montert? Hadde jo vært artig å vite, om vi har et design som funker på alle målere etterhvert

ESP8266 er litt tøff på strømforbruket i perioder, så jeg kjørte på med en mobillader (5V) for være på den sikre siden. Hvis en vil ha rapporter hvert 2. sekund, så tror jeg dette er eneste alternativet. Men, en kunne selvfølgelig slått av wifi, samlet data, og rapportert inn sjeldnere. Da kunne mulig et lipo batteri funket for å samlet nok energi mellom slagene. På den annen side har en jo som regel strøm i nærheten her, så kanskje ikke noen big deal...

Hvis du er interessert i en god deal kan du sende meg to i posten og få ett tilbake med komponenter, testet mot måleren min... Kan bestille selv også, men dumt hvis jeg oppdager feil på kretskortet og det må justeres

Tror du kan gjøre rom for flere der borte Burde kanskje løse seg med en ny motstand på 50-100k mellom HAN signalet og pin 2 da?

Tøft! Hvilken leverandør brukte du, og ble det noe ekstra fuzz eller gikk det direkte gjennom?

Hm, jeg fikk åpnet min neste dag etter å ha sendt en e-post. Jeg tror det er Valider som kraftselskapet bruker som leverandør av dette utstyret, og teknisk sett er det dem som åpner porten. Litt rart da at ulike kraftselskaper har ulik praksis, men det kan mulig være noen rutiner som tar tid å få på plass... Kanskje det hjelper å mase

Sikker 100de gang jeg spør, men hvilken måler har du? Kamstrup og Kaifa ser ut å la seg åpne, men med Aidon sitter det litt lenger inne...

hehe, tråden kan kanskje bli litt langstrakt etterhvert, men hyggelig å høre at flere finner veien hit! Andre har også målt ca. 25V stabilt over HAN porten, når denne ikke er aktivert. Aktivering er etter klar spec fra NVE sagt å skulle skje etter forespørsel fra kunde. Dette er også et krav, slik at du har rett til disse dataene. En liten hake er at e-lagene har frist fram til 1. jan 2019 med å imøtekomme dette kravet. Likevel, de som har fått Kamstrup og Kaifa målere har fått dette aktivert, mens Aidon (Hafslund i hvertfall, usikker på om det er flere) har vært tilbakeholdne. Ang. spørsmålene dine: 1) Kretskortet som ligger ute har nok ingen bestillt. Det viser seg at dette har etpar små svakheter, det er en motstand for mye her, og ubrukte innganger på opamp er ikke jordet. Jeg engasjerte en kar via freelancer.com som laget dette for meg, mest for å prøve ut det konseptet... I realiteten kjører vi på breadboard eller prototyping-kretskort. 2) For kommunikasjon med mqtt, så er det enkleste å bruke pubsubclient fra knolleary: https://github.com/knolleary/pubsubclient Dette har jeg brukt mye, også til helt andre ting, og det fungerer bra. Eneste obs er at det har en default buffer size som er litt liten, men som fint kan økes, se to-tre-fire meldinger tilbake i denne tråden. I mitt github prosjekt finner du komplett kode for MQTT/JSON/AMS 3) Arduino begrepet brukes her fordi en programmerer ESP8266 som en arduino (nettopp slik du antyder). Noen bruker ESP'en bare som en WiFi modul til en vanlig arduino, men det har jeg aldri skjønt meg på Jeg tror begrepet Arduino er like mye software-utvikling som den opprinnelige Arduino hardware. 4) Jeg skrev litt tidlig i denne tråden om M-Bus chippen. Har etpar slike liggende som du kan få... Første utfordring her er at disse ser mer ut til å være beregnet for om du selv skal lage en sensor med M-bus interface, og ikke en server (mottaker) for data. Andre utfordring er at den M-bus som nyttes på AMS målerne bruker en form for push teknologi. Det betyr at mens vanlig M-bus utstyr sitter stille og venter på at noen skal spørre etter data, så bare pøser disse ut på gitte tidsintervaller. (Mitt MBusMqttLogger prosjekt er forøvrig basert på kommunikasjon mer en mer tradisjonell M-bus device, også ved bruk av ESP8266: https://github.com/roarfred/MBusMqttLogger) I tilfellet med AMS målerne, så er det ikke så nøye at det er M-bus interface, så snart du klarer å konvertere det elektriske signalet fra å være 25V/15V til å være 3.3V/0V. Derfra handler det om plain serie-kommunikasjon (2400 baud, 8N1 hos Kamstrup og 2400 8E1 hos Kaifa, gud-vet-hva hos Aidon), og dekoding av DLMS protokollen. Håper dette var til hjelp! Hold oss oppdatert om du kommer noen vei!

De du vil ha er en versjon av ESP8266 som heter ESP-12E eller ESP-12F, eks: https://www.banggood.com/3Pcs-ESP8266-ESP-12F-Remote-Serial-Port-WIFI-Transceiver-Wireless-Module-p-1046653.html?rmmds=search&cur_warehouse=CN https://www.seeedstudio.com/ESP8266-based-WiFi-module-SPI-supported-p-2486.html https://www.ebay.com/itm/1-2-5-10PCS-ESP8266-ESP-12E-Wireless-Remote-Serial-WIFI-Transceiver-Board-Module/191981905297?hash=item2cb3036591:m:m32tG5UYU4U1RfD8dfjf8Uw Litt avhengig av hvordan du vil jobbe, så kan det være lurt med et breakout kort. Disse er i utgangspunktet kun for å få kortet til å passe i et s.k. breadboard, men noen av dem har også to-tre nyttige komponenter som hjelper deg under programmering: Uten reset/prog: https://www.ebay.com/itm/2017-ESP8266-breakout-board-adapter-plate-for-ESP-07-ESP-08-ESP-12E-WIFI-modules/182826533161?hash=item2a914f8129:g:ImoAAOSw~y9ZDS~K Med reset/prog: https://tronixlabs.com.au/news/new-product-esp8266-esp12e-wifi-breakout-board-australia/ Jeg kjøpte et lite lass av de siste, men ikke fra tronixlabs. De er veldig praktiske, da de har knapper for prog/reset pluss de nødvendige motstander for oppstart montert. Styr unna disse: (ikke noe vondt om dem, men for dette prosjektet er det blindspor) NodeMCU: https://www.kjell.com/no/produkter/elektro-og-verktoy/arduino/utviklingskort/nodemcu-utviklingskort-p87949?gclid=Cj0KCQiA84rQBRDCARIsAPO8RFxnh2v_cX_ASSAvQGu80MVcHyVLR1lFSJoJtEzZWMH3m_7cuwfTY2saAivFEALw_wcB ESP01: https://www.kjell.com/no/produkter/elektro-og-verktoy/arduino/moduler/wifi-modul-for-arduino-esp8266-p87947?gclid=Cj0KCQiA84rQBRDCARIsAPO8RFzKEB8vin2Alt6FAJ11Au5sCGwxeHQ7LK_CyT3Q2imz-BxVdjnZ_akaAlGrEALw_wcB Blynk: https://www.sparkfun.com/products/13794 EDIT: Du vil også trenge en FTDI for programmering, dette er en s.k. serie-port emulator for USB til PC. Viktig at denne kan kjøres med 3.3V inn/ut, eks en slik: https://www.ebay.com/itm/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-for-Arduino-Mini-Port/381374421597?epid=502148532&hash=item58cbafda5d:g:jk8AAOSwrklVMjIp

Jeg har bruk dette kortet: https://www.xnsense.no/product-page/xnsense-proto-mx-2-7-6-esp8266 Og denne boksen: https://www.xnsense.no/product-page/medium-boks (Egentlig fordi jeg var med xnsense og lage disse og hadde noen liggende. Mange gode alternativer)

Hei! Ikke noe dumt spørsmål... Du kan finne komplett liste, med unntak av ESP og kretskort nederst på denne siden: https://github.com/roarfred/AmsToMqttBridge/blob/master/Electrical/README.md Eksempelkoden sender data formatert som json til en mqtt server, men er du litt kjent med arduino kan du sende dem hvor du vil. (All kildekode ligger i samme prosjekt på github) Hvis du aldri har leflet med ESP8266 før, så er det en liten terskel å komme over. Da ville jeg evt anbefale å sjekke ut noen enklere eksempler, men de finnes i massevis på nett. Jeg er gjerne behjelpelig hvis du trenger noe assistanse underveis!

Lurt! Om du vil sikre deg litt bedre kan du også 1) initialisere msg med MQTT_MAX_PACKET_SIZE+1 // se her: https://github.com/bblanchon/ArduinoJson/issues/268 2) sjekk root.measureLength() for å finne ut om json vil overstige størrelse på buffer (ser at printTo returnerer antall bytes som ble skrevet, men det ser ut som om denne ikke gjør noen sjekk på buffer størrelse før den setter i gang)

Ja, rett i pubsubclient.h tror jeg... har gått så langt som til 512 eller 1024 Mange som vil ha en bedre måte å gjøre dette på: https://github.com/knolleary/pubsubclient/issues/110

Du kan finne og øke størrelsen på denne packet size konatanten. Det er et vanlig triks ☺

Takk! Fikset det på en kommentar her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Electrical/README.md

Godt ressonement og bra tips med nrrl! Hvis noen er villige til å hjelpe eller låne bort et oscilloscope så kunne vi kanskje løst dette...

Enig i at inngangene bør jordes. Har prøvd å tegne skjema ut fra bildene, og finner ikke noe feil. Et par uvissheter, men regner med du har kontroll på dem: 1) Er +3V3 koblet i den røde (+) linjen på det nederste bildet? 2) Har +3V3 kilden felles jord med denne kretsen? Gått litt tom for ideer nå. Hender jeg stopper opp slik hjemme også, da setter jeg ofte breadboard til sides og finner fram et nytt og nye komponenter og bygger fra scratch. @Einar, har du noen tro på at dette med 6mA kan være for lite til å drive kretsen? Ser vi bort fra lading av kondensatoren går det ca. 25V/50k=0.5mA i spenningsdeleren for referansen, typisk 0.7mA i LM358... Er det noe jeg ikke ser?