Vinnerliste

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 ?

Hei Har fått ny varmepumpe fra Daikin nå med WiFi modul og har da laget et script for å kontrollere den. DEVICER: Oppsett av devicer, navnet er over bildet er referansen til variabelen i scriptet Denne må være huket av på alle devicene! Device nummer finnes under advanced tabben på den respektive devicen. vp_set_point_dev vp_status_dev vp_fan_point_dev vp_mode_dev vp_vane_dev vp_temp_outdoor_dev vp_temp_indoor_temp vp_compressor_dev EVENTER: Denne eventen kjører jevnlig for å sjekke etter oppdateringer fra varmepumpen. Jeg kjører 30 sekunder uten problemer Denne eventen blir kjørt hver gang en av devicene som er oppført til å kontrollere noe blir kjørt. Her må devicene for variabel vp_set_point_dev, vp_status_dev, vp_fan_point_dev, vp_mode_dev, vp_vane_dev legges inn. FUNKSJONER: Send_values(): Oppdaterer varmepumpen med alle verdiene satt i HS3 SetTempMan(temperatur): Tar et argument som temperatur for å sette temperatur direkte via eventer IncTemp(): øker settpunktet for temperatur med 1 grad celsius DecTemp(): senker settpunktet med 1 grad celsius Check(): sender forespørsel om data og oppdaterer devicer. Dene blir kjørt hver gang en av de overstående blir kjørt så det er ikke nødvendig å kjøre denne manuelt for å oppdatere etter en kommando ANNET: For å se direkte om verdiene stemmer med det i varmepumpen kan man logge inn med <ip adresse>/aircon/get_control_info og <ip adresse>/aircon/get_sensor_info For å aktivere/deaktivere debug info settes variabelen "debug" til 1 (standard) og 0. Det vil da komme litt ekstra info i loggen til HS3 under "VP Status" CR_daikin_vp_check_v1.0.vb

Interessant script! Fungerer det for deg etter den siste fw-oppdateringen? Når jeg kaller API-et direkte, får jeg denne i retur: ret=PARAM NG,msg=404 Not Found Har kontakt, og får data i retur når jeg bruker disse API-definisjonen: https://github.com/ael-code/daikin-control/wiki/API-System Har Moskus R32.

Legger nå ut en prøveversjon av mqtt2miirobo(for windows og python 3.5+) har tatt screenshots av cfg fila mm. Man behøver en mqtt broker for å få dette til å spille. La inn Find() funksjonen i prøveversjonen. Kan være fint å ha en kvinnestemme som roper "Hey! I'm here!" både som selskap og til å skremme vekk uvedkommende! Lykke til! ? p.s. Den kommer til å bli lagt ut i min nettbutikk når den er helt ferdig. Det er nesten 750 linjer kode, så jeg håper dere tilgir meg for at jeg må ta meg betalt en symbolsk sum for arbeidet. roborock_screenshots.zip mqtt2miiorobo.zip roborock-doc.txt

Hei, Da har jeg fått data fra AMS til min rpi som kjører HomeAssistant, via Rpi med Node Red flow fra Thomas_ja27 med mindre endringer, og koden til Per Erik. Stor takk til begge to! Bruker "alibaba" Mbus-USB dongle med parity Even. Foreløpig bruker jeg HomeAssistant sin innebygde MQQT. Fra før av regner jeg ut effekt som går til varme fra heatit/multireg termostatene, ved å trekke dette fra totaleffekt fra AMS gir det en fin visning med "effekt varme" "effekt forbruk" og "totalforbruk" der varmtvann foreløpig kommer inn under "forbruk" Neste skritt er å trekke ut KWh/d og få satt opp regnestykke på "totalkostnad" per dag, osv.