skagmo

Hvordan få requests til å ignorere sertifikat (selv om det strengt tatt er mye bedre med et fungerende sertifikat): https://stackoverflow.com/questions/15445981/how-do-i-disable-the-security-certificate-check-in-python-requests Har lagt ved Grafana-dashbord som et utgangspunkt. Strøm-1549799520846.json

Strøm på to av fasene hentes ut per i dag. Den tredje fasen måles ikke, da summen av de tre fasestrømmene vil være null. Du kan eventuelt regne ut den siste fasestrømmen om du er interessert i det. Edit: Vel å merke om du har IT-nett, noe jeg regner med at du har siden denne parseren hadde feilet om måleren spyttet ut tre fasestrømmer.

Fikk fortsatt litt på det i går. Inkluderer nå videresending til Home Assistant og energi/kWh som kommer en gang i timen.

Har laget et dashboard for Grafana ja. Se bilde. Kan legge det på Github f.eks. i morgen kveld hvis du vil ha det som utgangspunkt. Skal også legge til videresending til HA. Gjenstår å lese ut meldinga med akkumulert forbruk (kWh) som kommer en gang i timen, så foreløpig populeres ikke dashbordet fullt ut. Hadde ikke tid til å inkludere den meldinga i går. Må innrømme at jeg faktisk likte det forrige testformatet bedre, hvor man hadde høyere oppløsning på strøm, forbruk/kWh hvert minutt og nettfrekvens også. For meg var 1 minutt oppdateringsrate plenty...

Fikk åpnet porten på min Aidon-måler i dag, så har en fungerende parser i Python nå. HDLC-dekodingen er fullverdig (med sjekksum), men det gjøres mange antakelser/forenklinger rundt OBIS-feltene som antas å være som på en Hafslund-måler. https://github.com/skagmo/meter_reading

Ser ut som det kun er starten på meldingene som er forskjellig hos dere. Har ikke sjekket M-bus-en med skop enda, men mistenker at kina-adapteren jeg bruker ikke nødvendigvis er helt tipp-topp siden meldingene mine varierer i lengde utover det SLIP-enkodingen tilfører. Hvis noen av dere har tangamperemeter og mulighet til å belaste måleren med en ca. konstant last vil det nok være greit å finne ut av hvilke felt som er strøm. La Python-koden ut på Github og la til trunkering av meldinger lengre enn 79 byte, så regner med det burde fungere for dere også: https://github.com/skagmo/meter_reading

Hehe, ja det kan diskuteres hvor mye vits det er å reverse engineere når dette er en midlertidig protokoll som byttes senest til nyttår. Takk for tips, bruker den der regelmessig ja

Siste fra meg ang. Hafslund/Aidon: Har skrevet en snutt i Python for dekoding av SLIP og parsing av det som er kjent så langt. Jeg prøvde å måle fasene med tangamperemeter for å sammenlikne, men det var ikke noe som umiddelbart stemte veldig bra (altså tilsynelatende ikke skalert med en tierpotens el.). Det var også for mye endringer i målingene med tangamperemeter og for lav rate på meldingene på HAN-bussen. Skulle fått ut litt mer informasjon på skjermen på måleren, så hadde det vært lettere å korrelere målingene... Noen som vet om det finnes en mer omfattende manual til måleren enn denne PDF-en på to sider? (https://hafslundnett.blob.core.windows.net/files/NY_MALER/veiledning/AIDON_veiledning_des2015.pdf) Kode:

Hei. Ny her jeg også. Fint forum! Fikk Aidon-måler fra Hafslund selv i går. Har fått koblet opp et interface og kikket litt på rådataene. Jeg får pakker på 79-82 byte, ca. hvert minutt. Samme baud-rate som deg. Jeg får derimot ikke serienummer. Mye tyder på at meldingene er SLIP-kodet, da de alltid slutter på 0xc0. Enda mer mistenksomt når en av de lengre meldingene inneholder en 0xdb etterfulgt av 0xdd (frame escape og transposed frame escape). Ved å anta little endian er det mange felt som gir mening som uint16. Fortsetter å undersøke. Tre tilfeldige meldinger: Tolkning av de siste 18 bytene i den siste meldingen: ff08: 0x08ff = 2303. 230,3 V? 1509: 0x0915 = 2325. 232,5 V? 1309: 0x0913 = 2323. 232,3 V? b6000000a300: ? 8713: 0x1387 = 4999. 49,99 Hz? 03: ? 8f4a: Varerier mye mellom hver melding. Sjekksum? c0: Slutt på melding. SLIP frame end?