roy
-
Innlegg
14 -
Ble med
-
Besøkte siden sist
-
Dager vunnet
1
Innholdstype
Profiler
Forum
Blogger
Nedlastninger
Artikler
Regler
Hendelser
Galleri
Store
Innlegg skrevet av roy
-
-
9 timer siden, Alvin skrev:
Hvilke nett-tjenester er det som oppgir målepunkt-id?
Gudbrandsdal Energi har i hvertfall gjort det veldig lenge: https://www.ge.no/stromavtale/produkt/markedskraft/bestill
Bare skriv inn mobilnummer og trykk "neste" så har du det.
-
På 14.8.2019 den 9.05, ZoRaC skrev:
Kult!
Med Tibber kan du vel få enda mer nøyaktig estimering av strømregningen? Mener du kan hente ut «beløp hittil denne mnd» via API deres og så er det bare å estimere forbruket for resten av mnd og plusse på.
Man kan også kjøpe Tibber Pulse (koster bare 100 kr om man benytter vervelenke og blir kunde hos dem samtidig), da slipper man å bygge sin egen hardware.
koden må da endres litt for å hente fra deres API i stedet, men det er nok overkommelig.
Takk!
Her også får jeg hentet ut beløp hittil denne måneden ved å spørre om det. Nå har jeg ikke hatt så mye datagrunnlag hittil, men akkurat nå bruker den bare snittet av det til å estimere resten av måneden. (Det er jo klart at det riktige er å ha mer data og la ukedager, måned, temperatur, osv være en del av regnestykket. (Er jo perfekt for litt maskinlæring rett og slett.))
Ja, her er det bare å bygge inn støtte for Tibber sitt API i midten så får man akkurat samme funksjonalitet mot dem. Det kan fort være at jeg ender opp med å bli kunde hos dem. Hvis de har riktig autentiseringsløsning så går det an å lage dette til en generell tjeneste hvor enhver kunde kunne benyttet seg av dette.
-
Tenkte jeg skulle poste denne ettersom jeg tror den kan være interessant for flere her.
Ved hjelp av folk på forumet her fikk jeg lest av strømforbruket via HAN-porten. Som presentasjon av forbruket valgte jeg å gå for plattformen Google Assistant som vist i videoen under.
Mer om prosjektet kan leses på kode24. Siste del med Google Home kan leses på https://www.kode24.no/guider/smart-meter-part-3-hey-google-how-much-electricity-am-i-using/71463193. Jeg håper jo og tror at aktører som Tibber og Fjordkraft som allerede henter sanntidsdata kan tilby et tilsvarende produkt snart.
Her er alle de ulike delene:
- https://www.kode24.no/guider/smart-meter-part-1-getting-the-meter-data/71287300
- https://www.kode24.no/guider/smart-meter-part-2-data-storage-and-price-info/71439621
- https://www.kode24.no/guider/smart-meter-part-3-hey-google-how-much-electricity-am-i-using/71463193
-
3
-
2
-
-
Ah, Real Time Clock selvfølgelig. La ikke merke til at tallene ga den meningen eller at den stringen også er til stede i headeren. Takk for hjelpen.
-
Hva betyr egentlig den OBIS-meldingen 0.1.1.0.0.255 - RTC w/Quality? Hvordan skal man tyde innholdet?
09 <-- octet-string 06 <-- string length, 0x06 = 6 bytes 00 01 01 00 00 FF <-- 0.1.1.0.0.255 (OBIS for RTC w/Quality) 09 <-- octet-string 0C <-- string length, 0x0C = 12 bytes 07 E3 07 09 02 14 00 05 FF 80 00 80 <-- What's this? -
7 timer siden, Robin Smidsrød skrev:
Det tror jeg strengt tatt er et brudd på personvernsforordringen (GDPR) og burde således rapporteres til Datatilsynet. Hvis vi alle er flinke til å rapportere det når vi legger merke til det så kanskje vi over tid blir kvitt, i det minste, de verste synderne. Folk som selv deler telefonnummer og andre personopplysninger på sosiale medier er det vanskelig å gjøre noe med.
Jeg tror det er Enoro som i sitt produkt Elwin Elprosess som tilbyr dette her. Uten at jeg vet det så virker det som om de har det meste av opplysninger om de fleste på tvers av selskaper.
7 timer siden, Robin Smidsrød skrev:Så da er spørsmålet. Skal eller skal jeg ikke dele målernummer uten å anonymisere det...? Kanskje se om jeg finner ut om det er mulig å lage en poll her for å se hva andre hadde gjort...
Poll er nok bra. Virker som om du relativt trygt kan dele det. Selv om jeg fort heller mot å fortsette å modifisere målernummer og sjekksum. Det er jo kjapt å søke og erstatte både målernummer og sjekksummer i både små store mengder data. (Skulle man finne på å scripte det er det jo ikke umulig å få regnet ut ny gyldig sjekksum om ønskelig.)
-
Det er godt å høre at det er flere som tenker på disse tingene.
Jeg har sensurert målernummeret mitt i de dataene jeg har lastet opp, men det er kanskje ikke nødvendig.
Det som jeg har stusset over derimot, er hvordan man på diverse tjenester på nettet kan skrive inn et mobilnummer og få ut fullt navn, full adresse, fødselsdato, målepunkt-ID, målernummer og netteier. Om man ikke finner en persons mobilnummer i telefonkatalogen finner man det stort sett alltid i en eller annen kontaktliste for et idrettslag, et Facebook-innlegg, en Finn-annonse, eller lignende. Så sånn sett er det litt enklere å få tak i målepunkt-ID enn et fødselsnummer..
-
Ah, nice. Takk for en god og enkel forklaring!
-
Ah, tusen takk, @Bjørn Mork!
Nå googlet jeg litt på det du skrev. Fant denne gode oppsummeringen av det hele:
structure 02 LL (LL elements) octet-string 09 LL XX .. (LL bytes) visible-string 0A LL XX .. (LL bytes) unsigned32 06 XX XX XX XX (04 bytes) unsigned16 12 XX XX (02 bytes)Da kan jo man gjøre parsingen av dataene skikkelig.
-
Nå som jeg endelig får ut fornuftige data fra strømmåleren min vurderer jeg hvordan jeg skal bruke disse videre. For oss som ikke har noe bakgrunn i elektronikk: Kan noen fortelle (evt. linke til en kilde) hva i disse meldingene som kommer hvert 10. sekund fra måleren med øyeblikksdata om gir nåværende strømforbruk? Jeg er ikke så interessert i hele forklaringen om vekselstrøm jeg kan lese om på Wikipedia, men mer konkret hvilke(t) tall av active/reactive power +/- som (sammen?) gir det faktiske strømforbruket.
Helt konkret så jeg f.eks. dette rapportert:
Active Power +: 1703 Watt
Active Power -: 0 WattReactive Power +: 0 Watt
Reactive Power -: 480 WattHva er egentlig da strømforbruket? Hva tar liksom strømselskapet betalt for da?
Beklager hvis jeg spør om ting som er selvfølgelig for "alle". ?
-
Takk for alle svar! ?
Jeg kjøpte meg en ny USB-til-MBUS-slave-modul fra eBay siden jeg - tilsynelatende i likhet med mange - ikke fikk noen fornuftige data ut av den forrige fra AliExpress. Og da ble det en annen verden. Nå er pakkene stabile på 228 bytes hvert tiende sekund. Innholdet er akkurat som forventet. ?
SpoilerNår jeg nå tolker dataene ut i fra https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/readme.md og https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md så blir alt så fint:
7E <-- Frame Start flag A <-- 4 bits, A = Frame Format Type 3 0E2 <-- 12 bits, frame size: 0xE2 (226 bytes, excluding start/end flags) 2B <-- Destination Address 21 <-- Source Address 13 <-- Control Field 23 9A <-- Valid CRC-16/X-25 E6 <-- Destination LSAP E7 <-- Source LSAP 00 <-- LLC Quality 0F <-- Information, n*8 bits? 00 00 00 00 <-- INVOKE_ID_AND_PRIORITY 0C <-- 12 bytes (length of the string) 07 E3 <-- 2019 (year) 06 <-- 06 (month, june) 12 <-- 18 (day of month) 02 <-- Tuesday (day of week) 14 <-- 20 (hour of day) 2F <-- 47 (minute of hour) 32 <-- 50 (seconds of minute) FF <-- (fff not specified?) 80 <-- (deviation not specified?) 00 80 <-- (what's this?) 02 19 <-- List ID 0A <-- (what's this, a separator?) 0E <-- 14 (length of meter type in ASCII?) 4B 61 6D 73 74 72 75 70 5F 56 30 30 30 31 <-- Kamstrup_V0001 (OBIS List Version Identifier) 09 06 01 01 00 00 05 FF <-- 1.1.0.0.5.255 (OBIS for Meter ID) 0A 34 32 30 30 35 36 37 32 32 33 31 39 37 37 31 34 <-- 4200567223197714 (meter id, has changed some numbers so the checksum is broken) 09 06 01 01 60 01 01 FF <-- 1.1.96.1.1.255 (OBIS for meter type) 0A 12 <-- 18 (length of meter type in ASCII?) 36 38 34 31 31 33 31 42 4E 32 34 33 31 30 31 30 34 30 <-- 6841131BN243101040 (meter type) 09 06 01 01 01 07 00 FF <-- 1.1.1.7.0.255 (OBIS for Active Power +) 06 00 00 <-- (what's this?) 06 A7 <-- 1703 W 09 06 01 01 02 07 00 FF <-- 1.1.2.7.0.255 (OBIS for Active Power -) 06 00 00 00 00 <-- 0 W (Active Power -) 09 06 01 01 03 07 00 FF <-- 1.1.3.7.0.255 (OBIS for Reactive Power +) 06 00 00 00 00 <-- 0 W 09 06 01 01 04 07 00 FF <-- 1.1.4.7.0.255 (OBIS for Reactive Power -) 06 00 00 01 E0 <-- 480 W 09 06 01 01 1F 07 00 FF <-- 1.1.31.7.0.255 (OBIS for L1 Current) 06 00 00 00 88 <-- 1,36 A (L1 Current) 09 06 01 01 33 07 00 FF <-- 1.1.51.7.0.255 (OBIS for L2 Current) 06 00 00 02 36 <-- 5,66 A (L2 Current) 09 06 01 01 47 07 00 FF <-- 1.1.71.7.0.255 (OBIS for L3 Current) 06 00 00 00 6D <-- 1,09 A (L3 Current) 09 06 01 01 20 07 00 FF <-- 1.1.32.7.0.255 (OBIS for L1 Voltage) 12 00 <-- (what's this, yet another separator?) EB <-- 235 V (L1 Voltage) 09 06 01 01 34 07 00 FF <-- 1.1.52.7.0.255 (OBIS for L2 Voltage) 12 00 EB <-- 235 V (L2 Voltage) 09 06 01 01 48 07 00 FF <-- 1.1.72.7.0.255 (OBIS for L3 Voltage) 12 00 EB <-- 235 V (L3 Voltage) 83 77 <-- Checksum? (will not validate since meter id has been altered) 7E <-- Frame End flag
-
Takk for svar, @Andreas!
Her er meldingene re-formatert. 0 var allerede paddet. Men ja, de fremstår som unaturlig korte i forhold til andre jeg har sett. Men det interessante er at f.eks. CRC for header er gyldig. (Usikker på hvordan korrekt beregne CRC av totalen.) Og meldingene holder seg stabile, starter og slutter alltid med 7E og inneholder målernummer, målertype og litt diverse ting som kommentert i første post.
2019-01-20T21:50:11.195980 - 155 bytes: 7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 F8 BF 60 D9 50 91 26 A1 80 00 F0 FF 68 2A 56 6B 17 97 AE 17 AE 65 05 82 82 8A 4A 64 14 28 FE 0A 11 35 37 20 36 35 36 27 32 31 32 34 38 34 37 35 36 09 06 01 01 7C F1 0A 12 36 38 34 31 31 33 31 42 4E 32 34 33 31 30 31 30 34 30 09 06 81 F9 FF 06 80 FF FB FE 06 C0 06 E0 06 F0 89 C7 FE 74 08 06 00 F8 09 06 F1 3A C6 06 00 FC 4A 64 14 DF 10 06 00 FC 89 C7 FE 12 C0 BD 42 50 B8 FF 3B E6 12 00 EB 09 06 01 E1 90 12 00 EB 11 CB 7E 2019-01-20T21:50:21.194220 - 154 bytes: 7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 F8 BF 60 D9 50 91 26 D1 80 00 F0 FF 68 2A 56 6B 17 97 AE 17 AE 65 05 82 82 8A 4A 64 14 28 FE 0A 11 35 37 20 36 35 36 27 32 31 32 34 38 34 37 35 36 09 06 01 01 7C F1 0A 12 36 38 34 31 31 33 31 42 4E 32 34 33 31 30 31 30 34 30 09 06 81 F9 FF 06 80 FF FF FF 06 C0 06 E0 06 F0 09 06 F1 74 08 FF 06 00 F8 5F 21 50 FE 3A C4 06 00 FC 4B 7F DF 07 FC 06 00 FC FF 12 C0 2F C8 50 58 07 FC 12 00 EC 09 06 01 F1 D8 12 00 EE 88 D4 7E 2019-01-20T21:50:31.194745 - 154 bytes: 7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 F8 BF 60 D9 50 91 26 F4 80 00 80 FB B6 FE 68 2A 56 6B 17 97 AE 17 AE 65 05 82 82 8A 4A 64 14 28 FE 0A 11 35 37 20 36 35 36 27 32 31 32 34 38 34 37 35 36 09 06 01 01 7E F1 0A 12 36 38 34 31 31 33 31 42 4E 32 34 33 31 30 31 30 34 30 09 06 81 F9 FF 06 80 FF 06 C0 06 E0 06 F0 09 06 C1 FF 74 08 FF 06 00 F8 5F 21 50 FE 3A C4 06 00 FC 4B 7F DF 07 FC 06 00 FC 12 C0 2F C8 50 5C FF 07 FC 12 00 EC 09 06 01 F1 D8 12 00 EE 13 D4 7E 2019-01-20T21:50:41.189758 - 156 bytes: 7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 F8 BF 60 D9 50 91 26 A5 80 00 F0 FF 68 2A 56 6B 17 97 AE 17 AE 65 05 82 82 8A 4A 64 14 28 FE 0A 11 35 37 20 36 35 36 27 32 31 32 34 38 34 37 35 36 09 06 01 01 7C F1 0A 12 36 38 34 31 31 33 31 42 4E 32 34 33 31 30 31 30 34 30 09 06 81 F9 FF 06 80 FF 96 C8 28 FF 06 C0 FF 06 E0 06 F0 89 C7 FE 74 08 06 00 F8 09 06 F1 3A C4 06 00 FC 4A 64 14 DF 10 06 00 FC FF 12 C0 2F C8 50 58 FF 3B E6 12 00 EC 09 06 01 F1 D8 12 00 EB 3D C0 7E
-
Jeg har en Kamstrup AMS fra Norgesnett med åpen HAN-port. For å lese disse DLMS OBIS datapush-meldingene har jeg en USB-til-MBUS-slave-modul koblet til en Raspberry Pi. Jeg skrev noen få linjer med Python for å skrive ut meldingene som kommer, og dette ser i utgangspunktet ut til å fungere stabilt og som forventet.
Det jeg lurer på er om noen kan hjelpe meg å tyde/forklare meldingene til meg, fordi de later til å være mye kortere (145-160 bytes) enn det jeg har sett eksempler på her på forumene. Etter å ha lest hundrevis av meldinger og side opp og side ned her inne + lest kode og eksempeldata på spesielt https://github.com/roarfred/AmsToMqttBridge/ så skjønner jeg bare ikke hva det er med meldingene jeg får.
Meldingene kommer hvert 10. sekund som forventet, og hver time kommer det en bittelitt lenger melding (den også mye kortere enn forventet). Det er som om OBIS-kodene ikke er med i meldingene.
Start og slutt med byten E7 er alltid til stede og CRC for hvertfall header har stemt de gangene jeg har sjekket den.
Her er eksempler på noen meldinger jeg får:
2019-01-20T21:50:11.195980 - 155 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFBFE06C006E006F089C7FE74080600F80906F13AC60600FC4A6414DF100600FC89C7FE12C0BD4250B8FF3BE61200EB090601E1901200EB11CB7E 2019-01-20T21:50:21.194220 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126D18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFFFF06C006E006F00906F17408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FCFF12C02FC8505807FC1200EC090601F1D81200EE88D47E 2019-01-20T21:50:31.194745 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126F4800080FBB6FE682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017EF10A1236383431313331424E323433313031303430090681F9FF0680FF06C006E006F00906C1FF7408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FC12C02FC8505CFF07FC1200EC090601F1D81200EE13D47E 2019-01-20T21:50:41.189758 - 156 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A58000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FF96C828FF06C0FF06E006F089C7FE74080600F80906F13AC40600FC4A6414DF100600FCFF12C02FC85058FF3BE61200EC090601F1D81200EB3DC07E
Hvis jeg tar f.eks. den siste meldingen over og bruker mye av kunnskapen fra https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/readme.md og https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md så tolker jeg det som noe slikt som under. Jeg har brukt linjeskift ved de typiske separatorene bare for å prøve å finne mønster, men det vil nok ofte være helt feil ettersom jeg ofte ikke får ting til å stemme med "02 - one byte following 06 - long (4 bytes / 32 bits) 12 - int (2 bytes / 16 bit) 09 - string, first byte is length (could it be a byte array?) 0A - string, first byte is length" uansett.
7E <-- Frame Start flag A <-- 4 bits, A = Frame Format Type 3 0E2 <-- 12 bits, Frame size: 0xE2 (226 bytes!?, excluding start/end flags) 2B <-- Destination Address 21 <-- Source Address 13 <-- Control Field 239A <-- Gyldig CRC-16/X-25 E6 <-- Destination LSAP E7 <-- Source LSAP 00 <-- LLC Quality 0F <-- Information, n*8 bits? 0000F8BF60D95 <-- Hva er dette? Ofte(?) likt 09 12 6A58000F0FF682A566B1797AE17AE650582828A4A641428FE 0A 1135372036353627323132343834373536 <-- Gyldig målernummer i ASCII (NB: jeg endret noen sifre her, så evt påfølgende checksum vil feile) 09 06 01017CF1 <-- Hva er dette? Alltid likt 0A 12 36383431313331424E323433313031303430 <-- Alltid likt = ASCII 6841131BN243101040 <-- 684113 = måler-type 09 06 81F9FF 06 80FF96C828FF 06 C0FF 06 E0 06 F089C7FE7408 06 00F897C8287E 09 06 F13AC4 06 00FC4A6414DF10 06 00FCFF 12 C02FC85058FF3BE6 12 00EC <-- 236 (Volt? (L2?)) 09 06 01F1D8 <-- Hva er dette? 12 00EB <-- 235 (Volt? (L3?)) 3DC0 <-- Checksum? 7E <-- Frame End flagOppsettet for avlesingen er slik jeg hadde forventet det å være:
ser = serial.Serial( port='/dev/ttyUSB0', baudrate=2400, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, bytesize=serial.EIGHTBITS, timeout=10)
Håper noen har noen tips eller innspill til meldingene. ?
Er målernummer fra AMS-målere sensitivt?
i Strømsparing og strøm-overvåkning
Skrevet
Jeg har 100% treffprosent. Ikke at datasettet er så stort.
Men er jo bare å ta tlf.nr. til en nabo du tror strømmen står på. Eller ta navnet til en av oss på forumet her og søk opp nummeret. (Men nå fikk du vel uansett svar på det egentlig lurte på i forhold til målepunkt-id. 🙂)