Vinnerliste

Fullført layout og bestillt PCB og komponenter til min lille baby Universal energimåler basert på ESP32 som kan bestykkes med enten SSR for 2 kanals dimming (eller trinnløs styring av varmekabler), 2 rele a 5A eller 1stk 16A rele. Felles inngang for laststyring er uavhengig av tilførsel til modul og har egen strømmåler hvor en også kan sette en øvre grense som slår av utgang(er) og trigger alarm. Hovedmåler i modul kan måle opp til 27.5A direkte eller 100A via strømtrafo. Temperraturgiver på PCB for alarm og eventuelt kutt av rele. Det beste av alt er at den ikke måler mer en 41x33x25mm. hehe.

Jeg innser at verden neppe har behov for enda et slikt program, men jeg er protokoll-nerd og klarte ikke helt å være fornøyd med en strategi der du bare finner verdier basert på relativ posisjon eller evt et søk etter OBIS-koden som en byte-sekvens. Måtte bare tygge tilstrekkelig på disse DLMS/COSEM pakkene til å forstå hele strukturen ? Resultatet finner dere her: https://github.com/bmork/obinsect Jeg kjører denne på et Ubiquity UniFi AP AC Pro aksesspunkt med OpenWrt, ettersom det allerede stod ganske nær sikringsskapet og hadde en ledig USB-port, med en slik dings til selve HAN-tilkoblingen: https://www.ebay.com/itm/173715712894 Dette er altså en HAN til MQTT proxy som antageligvis er noe mer fleksibel enn de fleste andre alternativene, ettersom jeg først parser hele pakken og bygger opp en slags kopi som et JSON object. Deretter bruker jeg en konfigurerbar del av dette objektet i en eller flere MQTT-meldinger. Dvs at det er mulig å publisere et variabelt sett med variable til flere MQTT emner, basert på den samme input-pakken fra måleren. For "effektivitetens" skyld postes selvsagt ingenting til emner som ikke inneholder oppdaterte variable. F.eks. poster jeg akkurat nå alle målerverdiene med to forskjellige nøkkelsett: OBIS kode og et alias for OBIS-koden (dette er selvsagt ikke så nyttig, men illustrerer mulighetene): { "1-1:0.2.129.255": "AIDON_V0001", "0-0:96.1.0.255": "7359992895319515", "0-0:96.1.7.255": "6525", "1-0:1.7.0.255": 0.9470000000000001, "1-0:2.7.0.255": 0, "1-0:3.7.0.255": 0, "1-0:4.7.0.255": 0.047, "1-0:31.7.0.255": 3.7, "1-0:71.7.0.255": 3.9000000000000004, "1-0:32.7.0.255": 247.70000000000002, "1-0:52.7.0.255": 246.60000000000002, "1-0:72.7.0.255": 247.20000000000002, "timestamp": 1559131080 } { "ListId": "AIDON_V0001", "SerialNumber": "7359992895319515", "Model": "6525", "Power": 0.9470000000000001, "PowerExport": 0, "ReactivePower": 0, "ReactivePowerExport": 0.047, "CurrentL1": 3.7, "CurrentL3": 3.9000000000000004, "VoltageL1": 247.70000000000002, "VoltageL2": 246.60000000000002, "VoltageL3": 247.20000000000002, "timestamp": 1559131080 } Samtidig poster jeg også litt andre data-sett fra de samme pakkene til litt andre MQTT emner. F.eks. sender jeg øyeblikkseffekten alene til et emne som er eksportert via en websocket lister, slik at jeg kan bruke det direkte fra paho mqtt klienten i en browser. Siden dette bare er en verdi, så blir denne ikke wrappet i JSON (selv om det jo forsåvidt fremdeles er gyldig JSON): $ mosquitto_sub -v -h 192.168.0.1 -t /obinsect/websocket/\# /obinsect/websocket/power 0.95100000000000007 /obinsect/websocket/power 0.94900000000000007 /obinsect/websocket/power 0.94600000000000006 Som dere sikkert også legger merke til, så skalerer jeg verdiene. Og som vanlig gir flyttallsdivisjon litt stygge tall ettersom det blir litt feil. Dette er basert på OBIS liste-dokumentasjonen fra NVE, der alle ser ut til å sende effekt som W men oppgir at det er kW skalert til et 4.3 format. Dette spiller jo selvsagt liten rolle, men jeg har nå valgt å gjøre det slik. Det kan slås av med en kommanolinje-option om du foretrekker uskalerte verdier. Helst skulle jo selsagt de skalerte verdiene vært vist med korrekt oppløsning, slik at effektene ovenfor var 0.951, 0.949 og 0.946. Men dette er JSON double verdier, og ikke tekst. Dermed blir den slags avrunding/korting opp til JSON parseren. Jeg har forsåvidt også en modus som publiserer verdiene som tekst med enhet, men det er normalt ikke spesielt nyttig siden du da må parse i den andre enden. Men da formatteringen blir penere da. Håper dette kan være nyttig for andre enn meg. Det hjalp ihvertfall meg mye å se COSEM-pakkene som et JSON-object. Spesielt for å skjønne forskjellenen på strukturen de tre leverandørene har valgt. Tar helt til slutt med et ekspempel på hvordan det objektet ser ut for hver av de tre. Dette er ment for debugging og er ikke veldig nyttig som output til vanlig Kamstrup: { "metadata": { "timestamp": 1559132486, "framelength": 226, "framenumber": 1, "srcprog": "./obinsectd", "srchost": "miraculix", "version": "0.01", "serialport": "stdin", "parsetime": 1431 }, "hdlc": { "format": 10, "segmentation": false, "length": 226, "src": 43, "dst": 33, "control": 19, "hcs": 39459, "fcs": 58715 }, "llc": { "lsap": 230, "dsap": 231, "quality": 0 }, "data-notification": { "long-invoke-id-and-priority": 0, "date-time": 946762380, "notification-body": { "visible-string-0": "Kamstrup_V0001", "obis-1": "1-1:0.0.5.255", "visible-string-2": "5706567000000000", "obis-3": "1-1:96.1.1.255", "visible-string-4": "000000000000000000", "obis-5": "1-1:1.7.0.255", "double-long-unsigned-6": 0, "obis-7": "1-1:2.7.0.255", "double-long-unsigned-8": 0, "obis-9": "1-1:3.7.0.255", "double-long-unsigned-10": 0, "obis-11": "1-1:4.7.0.255", "double-long-unsigned-12": 0, "obis-13": "1-1:31.7.0.255", "double-long-unsigned-14": 0, "obis-15": "1-1:51.7.0.255", "double-long-unsigned-16": 0, "obis-17": "1-1:71.7.0.255", "double-long-unsigned-18": 0, "obis-19": "1-1:32.7.0.255", "long-unsigned-20": 0, "obis-21": "1-1:52.7.0.255", "long-unsigned-22": 0, "obis-23": "1-1:72.7.0.255", "long-unsigned-24": 0 } } } Kaifa: { "metadata": { "timestamp": 1559132574, "framelength": 121, "framenumber": 2156, "srcprog": "./obinsectd", "srchost": "miraculix", "version": "0.01", "serialport": "stdin", "parsetime": 33 }, "hdlc": { "format": 10, "segmentation": false, "length": 121, "src": 1, "dst": 513, "control": 16, "hcs": 37760, "fcs": 49191 }, "llc": { "lsap": 230, "dsap": 231, "quality": 0 }, "data-notification": { "long-invoke-id-and-priority": 1073741824, "date-time-bug": true, "date-time": 1505416990, "notification-body": { "octet-string-0": "KFM_001", "octet-string-1": "6970631401753985", "octet-string-2": "MA304H3E", "double-long-unsigned-3": 1176, "double-long-unsigned-4": 0, "double-long-unsigned-5": 131, "double-long-unsigned-6": 0, "double-long-unsigned-7": 2208, "double-long-unsigned-8": 3841, "double-long-unsigned-9": 3794, "double-long-unsigned-10": 2389, "double-long-unsigned-11": 0, "double-long-unsigned-12": 2397 } } } Aidon: { "metadata": { "timestamp": 1559132627, "framelength": 210, "framenumber": 1, "srcprog": "./obinsectd", "srchost": "miraculix", "version": "0.01", "serialport": "stdin", "parsetime": 192 }, "hdlc": { "format": 10, "segmentation": false, "length": 210, "src": 65, "dst": 2179, "control": 19, "hcs": 54914, "fcs": 50400 }, "llc": { "lsap": 230, "dsap": 231, "quality": 0 }, "data-notification": { "long-invoke-id-and-priority": 1073741824, "notification-body": [ { "obis-0": "1-1:0.2.129.255", "visible-string-1": "AIDON_V0001" }, { "obis-0": "0-0:96.1.0.255", "visible-string-1": "7359992890941742" }, { "obis-0": "0-0:96.1.7.255", "visible-string-1": "6515" }, { "obis-0": "1-0:1.7.0.255", "double-long-unsigned-1": 1362, "structure-2": { "integer-0": 0, "enum-1": 27 } }, { "obis-0": "1-0:2.7.0.255", "double-long-unsigned-1": 0, "structure-2": { "integer-0": 0, "enum-1": 27 } }, { "obis-0": "1-0:3.7.0.255", "double-long-unsigned-1": 996, "structure-2": { "integer-0": 0, "enum-1": 29 } }, { "obis-0": "1-0:4.7.0.255", "double-long-unsigned-1": 0, "structure-2": { "integer-0": 0, "enum-1": 29 } }, { "obis-0": "1-0:31.7.0.255", "long-1": 93, "structure-2": { "integer-0": 255, "enum-1": 33 } }, { "obis-0": "1-0:32.7.0.255", "long-unsigned-1": 2500, "structure-2": { "integer-0": 255, "enum-1": 35 } } ] } } Så mens Kaifa bare sender en straight liste med verdier, så sender altså Aidon en liste med objekter, der hvert objekt består av en OBIS kode og en verdi. I tilegg har alle numeriske objekter et objekt med en integer og en enum. Det siste jeg har ikke klart å finne dokumentert hva det betyr. Jeg gjetter på at det er en slags beskrivelse av tallverdien, der enumen kanskje representerer enhet, men det hadde jo vært fint å finne noe dokumentasjon. Nie, jeg kommer nok ikke til å kjøpe noen IEC-standarder. Det er jo noe av de mer ubrukelige dokumenter som finnes. Bare se på det ovenfor og forklar hvordan tre leverandører kunne komme opp med en så totalt forskjellig tolk ning av hvordan pakkene skulle se ut ?

Takk for tilbakemelding og info. Kortet ser for øvrig riktig bra ut, tydelig at dette ikke er ditt første kort!

Takk for tibakemelding. Den kan i grunnen måle 30A men skruklemmer begrenser lasten til 27,5A og hemmeligheten ligger i ACS71020 fra Allegro som har denne muligheten. Angående dimming med Solide State Rele må disse ikke ha Zero Cross fuksjon og jeg har valgt å bruke G3MB-202PL fra Omron som er ganske rimelig og kan belastes med opp til 2A. Skal vurdere å dele skjema men avventer litt før jeg bestemmer meg. Ha en ellers flott dag

Bare sett statisk IP i ruteren så endrer den seg jo aldri?

Her var det mye interessant! Kan/vil du dele skjema? Jeg var ikke klar over at SSR (Solid-state relé, antar jeg) egner seg som dimmer? Er ellers nysgjerrig på hvordan du måler 27,5A direkte. Ble i det hele tatt veldig nysgjerrig! ?

Den kan ikke brytes så vidt jeg vet, men jeg har løst på ved hjelp av parameter. Parameter 25 kan snu om slik at IN1 går til OUT2 (i tilfelle feilkobling). På den måten kan jeg sku av dingdong, men samtidig få varsel om noen ringer på. Parameter 25 til 1 (IN1 går til OUT2) = Lyd av. Setter jeg parameter 25 tilbake til 0, er lyden på igjen (IN1 går til OUT1 igjen).

Det er det vel DHCP-serveren din som bestemmer? Varmepumpa spør etter IP, og det er det jo DHCP som er ansvarlig for... du kan vel også muligens låse IPen som er gitt av DHCP-serveren din (routeren din?), det gjør jeg hvis "dingsen" ikke har oppsett for fast IP.

Tror jeg kan svare på det. Jeg har et dokument som heter BS EN 62056-6-2:2013. Det var en vennlig sjel som la det ut på forumet her for en god stund siden. BSI Standards Publication Electricity metering data exchange — The DLMS/COSEM suite Part 6-2: COSEM interface classes På side 30 finner man "Table 3 – Enumerated values for physical units". F.eks 27 = W, 28 = VA, 29 = VAR, 33 = A, 35 = V Godt jobba!

Kommer i løpet av helgen nå. Har begynt.

Laget en effekt og daglig kWh skjerm som henter data fra AMS måler Data hentes via en M-Bus -> TTL mot en ESP8266. Skjermen er tilkoblet en Raspberry Zero som kjører Domoticz. Har bestilt en boks laget for skjermen, som den skal stå i. Film her Edit: Fått en boks å ha den i. Også endret scriptet slik at den switcher mellom temperature og effekt hvert 3 sek

@Evelen Du er jammen meg glad i tacosaus...