skagmo

22 hours ago, Singularity said:

Har forsøkt på timesvis å få lagt inn self-signed sertifikat i den sentrale sertifikatlageret, men jeg får ikke requests til å akseptere å får denne feilmeldingen tross utallige hacks:
Failed HASS: HTTPSConnectionPool(host='www', port=123): Max retries exceeded with url: /api/states/sensor.aidon_power (Caused by SSLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)'),))

Noen som har tips hvordan jeg enten kan bypasse det her, men aller helst få requests til å godta?

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

6 minutes ago, jerasm said:

 

Nydelig, hva skal til for å hente ut strøm på alle 3 fasene (har hafslund & aidon)?

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.

On 07/02/2019 at 08:33, Singularity said:

Nydelig!
Det holder lang vei for oss og med oppdatering hvert minutt.

Ser frem til at du legger ut

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

 

1 hour ago, roarfred said:

Spennende! 

 

Min umiddelbare reaksjon var at baud rate måtte være feil, men at dere leser ut spenning, frekvens og kanskje en sjekksum her sannsynliggjør at det likevel stemmer. Det som er sikkert er at dette ikke er DLMS data, da skulle alle pakker startet og sluttet med e7.

 

Så spørsmålet er om det er en helt annen firmware som var lagt inn initielt på disse målerne. Og, kan den reverse engineeres før det deployes ny firmware til Aidon?

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.

1 hour ago, roarfred said:

 

Et lite tips ang checksum, det finnes en site her som kan hjelpe dekode, der det kjøres en lang rekke kjente checksum algoritmer på en valgfri datakilde. Se om du finner treff her: http://crccalc.com

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:
 

#!/usr/bin/python

import serial, time, struct

# SLIP constants
FEND = '\xc0'

def parse(pkt):
	print "".join("{:02x}".format(ord(c)) for c in pkt)
	print len(pkt)
	if len(pkt) == 79:
		# Parse known fields; three phase voltages and frequency
		[v1, v2, v3] = struct.unpack("<HHH", pkt[62:68])
		[f] = struct.unpack("<H", pkt[74:76])
		print "v1=%.1f v2=%.1f v3=%.1f f=%.2f" % (v1/10.0, v2/10.0, v3/10.0, f/100.0)
	
		# Unknown fields
		[u1] = struct.unpack("<H", pkt[20:22])
		[u2] = struct.unpack("<H", pkt[28:30])
		[u3] = struct.unpack("<H", pkt[40:42])
		[u4] = struct.unpack("<H", pkt[44:46])
		[u5, u6] = struct.unpack("<HH", pkt[48:52])
		[u7] = struct.unpack("<H", pkt[58:60])
		print u1, u2, u3, u4, u5, u6, u7
	else:
		print "Length mismatch"

buf = ""
ser = serial.Serial("/dev/ttyUSB2", baudrate=9250, timeout=0, parity=serial.PARITY_NONE)

while(1):
	if ser.inWaiting():
		buf += ser.read(200)
		if FEND in buf:
			# Split message at the SLIP FEND character
			[pkt, buf] = buf.split(FEND)
			# Replace escape sequences in SLIP message
			pkt = pkt.replace("\xdb\xdc", "\xc0")
			pkt = pkt.replace("\xdb\xdd", "\xdb")
			parse(pkt)

On 1/14/2018 at 17:22, Kris said:

Hei, 

Er ny her. Har puslet litt med HAN-porten etter at jeg fikk Aidon-måler fra Hafslund. Kom over forumet helt tilfeldig, mye interessant arbeid dere har gjort!

Måleren min sender data ut på porten selv om dette ikke skal være slått på enda. Hvert minutt får jeg omkring 100 bytes på 9250 baud (!). De første 16 bytes er serienummeret til måleren, ellers kjenner jeg ikke igjen noe annet - ser ikke ut som OBIS.

Legger ved 4 samples i et regneark hvis noen er interessert. 

Mvh.

-Kristian

 

comparison.xlsx

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:

Quote

000000000000000000000000000000000000000000ba28000000000000bc20000000000000000000004a020000d38200008f0a95100000000000002410000006090109fc08dbdd000000cb0085130390a7c0
00000000000000000000000000000000000000009a27000000000000cc12000000000000000000001e020000078b0000bc850d11000000000000f9030000020910091209be000000150088130386d5c0
00000000000000000000000000000000000000005f27000000000000071e00000000000000000000d3020000198a0000a58a3f10000000000000cf0e0000ff0815091309b6000000a3008713038f4ac0

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?