Lokal lesing av HAN - The Easy Way (TM)

[Tore_Andersen]

1 time siden, funny0frank skrev:

Er det andre her som har hat problemer med at de får mange 0x00 verider når de leser av 120 byte meldingene? Jeg må ta +37 på lengden av 120 byte meldingen for å nå 0x7E slutt meldingen pga alle 0x00 bytene 

Det er egentlig det samme jeg ser, Jeg har enfase i huset og når en ser på starten av meldingene så angir tredje byte antall byte i meldingen. eks på mine 7e a0 27 liste 1, 7e a0 65 liste 9 og 7e a0 87 på timeslisten. Tredje byte 0X27 er 39 bytes melding + de 2 7E i begynnelsen og sluttenListe 1 hvert 2 sekund totalt 41 byte. Denne er alltid rett. 

0X65 er desimaltall 101 + de 2 start og stopp som skal være 7e gir 103 byte . Siden programmet i filen leser inn 103 byte så ser jeg når V og I er feil at de siste byte på skjermen er feil. De er egentlig begynnelsen på neste melding (10 sekunders melding).  det samme når jeg har timesmelding som er 0X87 desimalt 135 som betyr at meldingen med start og stopp 7e skal vær på totalt 137 byte. når jeg ser på en 10 sekunders melding som er ok så ser de 3 siste bytene ut slik XX XX7e der det bare finnes 1 byte med 7e som betyr slutt. Når jeg ser på de som er feil så slutte de enten med  7e 7e a0 eller 97 7e 7e. (tredje siste bit kan variere. ) jeg tolker dette slik at den har lest inn mistet en eller 2 byte under innlesning og lest inn starten på neste melding.  Jeg skal få testet dette med en pc ila av  en dag eller 2 med secure crt eller ett annet terminalprogram på en pc for å se om jeg klarer å finne noe forskjell. En korrekt melding skal ha 7e på begynnelsen og slutten og ingen 7e ellers. Jeg baserer dette på read.c filen fra hvordan jeg forstår programmeringen i funksjonen fra line 719 og utover. Fint hvis noen kunne verifisert dette da jeg ikke har programmert noe på en 15 års tid

Endret 18. april 2018 av Tore_Andersen

[funny0frank]

Tror ikke det er noen garanti for at det ikke er 7E ellers i meldingen. Bare at den skal starte og slutte med det. Der er jo mange av tallene vi får på strømmen som kan være 126...

[Helgemor]

Hei
Jeg har en Kaifa, som rapporterer måledata (lucky me!).
Jeg har forsøkt meg på en "enkel" løsning, med aliexpress MBUS-interface (dobbel type til 3-400,-) drevet av USB-kraft fra RPi, som igjen er drevet av et PoE-adapter.

MBUS-klumpen blinker riktig så fint, og alt ser bra ut. Men på min RPi med test_rx får jeg dette:

7e ff fb ff ff d3 6e fb 69 59 da 86 81 08 00 20 
00 00 04 00 00 00 00 00 00 00 00 00 00 20 10 00 
00 00 00 00 00 00 00 d8 62 c0 02 01 10 5a 87 e6 
etc.etc.
00 00 00 09 0c 07 e2 04 12 03 15 1b 10 ff 80 00 
00 02 01 06 00 00 14 58 1e 44 7e fb ff ff 7d ff 
ff 56 68 1c b0 02 d6 01 05 04 10 02 12 20 00 80
{"Date_Time":"",
"Host_Time":1524079635.859,

 

 

Tilsammen 993 bytes (i dette tilfellet). Tydeligvis med data som test_rx ikke skjønner stort av.
Det kan ta ganske lang tid mellom hver "rapport", 30-60 sekunder.
MEN: Hvis jeg tar en enkel cat /dev/ttyUSB0, så tikker det inn data annenhvert sekund med pakker av forskjellig lengde, noe som vel er i henhold til reglene.
Problemer er altså at etter start-taggen kommer det f.eks. "fb df" etc, som tilsier at her er det MYE data (hex bdf=3039 bytes) eller noe sånt.
Jeg har på forhånd gjort stty -F /dev/ttyUSB0 -cstopb cs8 -parenb 2400, for å sette 2400baud 8bits, 1 stopbit, ingen paritet, sånn som Kaifa sier det skal være.

 

Bildet viser innholdet fra cat /dev/ttyUSB0 >han.log

Det inneholder helt tydelig noe furnuftig som f.eks. serienummer og modellnummer. Men headerne ser ganske snåle ut.

Hjelp, please?

 

[funny0frank]

Ser ikke helt rett ut, første byte skal være 7E, men byte2 skal begynne med "A". Som regel så er den A0. Størrelsen på pakken er de 3 siste bit-ene i byte2 og alle bit-ene i byte3. Kan det være at du har feil parity?

Endret 18. april 2018 av funny0frank

[Helgemor]

Jeg mistenkte det, men i 7F er paritet odd, i FF even, DF odd, 80 odd, 00 even, DB even etc. Så jeg tror ikke det.

[petersv]

Kan det være jordingsproblem mellom M-bus-boksen og pi-en? Da kan man få artige verdier på serielinja.

[Tore_Andersen]

22 timer siden, Helgemor skrev:

Jeg har på forhånd gjort stty -F /dev/ttyUSB0 -cstopb cs8 -parenb 2400, for å sette 2400baud 8bits, 1 stopbit, ingen paritet, sånn som Kaifa sier det skal være".

 

22 timer siden, Helgemor skrev:

Hei
Du skriver "Jeg har på forhånd gjort stty -F /dev/ttyUSB0 -cstopb cs8 -parenb 2400, for å sette 2400baud 8bits, 1 stopbit, ingen paritet, sånn som Kaifa sier det skal være".

Når du kjører programmet  ~/src/han-port-1.14/test_rx -n -x -d /dev/ttyUSB0 så kjøres det oppsett av porten på nytt

fra read.c filen der står det i line 903 og utover.

char mode[] = {'8', /* bits in byte */
         'N', /* parity - E(ven), O(dd) or N(one) */
         '1', /* num stop bits */
         0}; /* end of string */
  int bdrate = 2400; /* 2400 baud */

Så skal du ha even paritet så må du gi kommandoen ~/src/han-port-1.14/test_rx -n -x -d /dev/ttyUSB0 -P E

prøv det og se om du får ut noe leselig.

 

 

[Helgemor]

Skjønner ikke hvor jord skal lage krøll her, siden mbusdingsen får kraft fra USB, og leverer data tilbake samme vei, men aldri godt å vite. Hvordan finner jeg ut det?


Sent from my iPad using Tapatalk

[Helgemor]

 

Har prøvd alle partiet, stopbits-kombinasjoner. Akkurat det samme som kommer inn.
Det underlige er at innholdet ser delvis fornuftig ut, ref modellnavn og serienummer som er med i noen meldinger. Det ser ut som det bare er kontrolltags etc. som er rotet til.


Sent from my iPad using Tapatalk

[daniel.h.iversen]

Har skrevet Python kode for å lese data fra Kaifa her https://github.com/Danielhiversen/AMSreader
Dataene lagres til disk og streames med mqtt.

Det er fortsatt wip, så kommer nok flere forbedringer etterhvert. Men har fungert fint her en ukes tid.

Endret 20. april 2018 av daniel.h.iversen

[petersv]

1 hour ago, daniel.h.iversen said:

Har skrevet Python kode for å lese data fra Kaifa her https://github.com/Danielhiversen/AMSreader
Dataene lagres til disk og streames med mqtt.

Det er fortsatt wip, så kommer nok flere forbedringer etterhvert. Men har fungert fint her en ukes tid.

Supert! Python vil jo gjøre det enklere å endre ting on the fly for ev. småfeil som leverandørene har i sin implementation. Hva kjører du programmet på?

[daniel.h.iversen]

Jeg har en kraftig regnemaskin i boden like ved sikringsskapet som jeg bruker. 
Men ser ikke noen grunn til at det ikke skal gå på en rpi.
Skriving til database og til mqtt skjer async

Endret 20. april 2018 av daniel.h.iversen

[petersv]

Veldig bra, kan jeg komme med noen forslag, enten her, eller via en pull request? Parametrisere litt av de hardkodede greiene (IP, tty, osv) og enable/disable databaseskriving?

Endret 20. april 2018 av petersv
formatering

[daniel.h.iversen]

Ja, bare å komme med pr.
Er nok behov for å rydde  litt opp i koden  også.
 

 

[Salvesen]

NICE! Python er mer opp min gate også!

[funny0frank]

Jeg kommer fortsatt til å lage go versjonen jeg holder på med, men er MYE enklere å lese 200+ linjer py en 1200 linjer rotete c.

 

@daniel.h.iversen  Støtter py filen din alle de forskjellige meldingene?

[daniel.h.iversen]

Støtter de tre meldingstypene jeg har sett på min Kaifa: https://github.com/Danielhiversen/AMSreader/blob/master/main.py#L147-L157

Men leser ikke ut alle verdiene i hver meldingstype. (Leser stort sett effekt, målerid og målerstand)

[Tore_Andersen]

Jeg har koblet til PC og leser ut rådata hexadesimalt og får samme utlesning der, melding som kommer hvert 10 sec "mangler" ofte 1 eller 2 byte, mens noen er normale. Det er alltid i slutten av meldingen slik at en av de 4 siste avlesningene blir feil og så har resten følgefeil pga det. Alt før dette er OK.

"React_Pow_P":240,

"React_Pow_M":-536870912,

"Curr_L1":21109,

"Volt_L1":2440

Jeg skal skaffe meg en ny MBUS leser av en annen type og se om jeg får andre resultat. Jeg konstaterer ihvertfall at det ikke skyldes pi,

tror jeg har testet alt av stoppbit og paritet som er mulig og hver gang det ser litt stabilt ut så faller det ut etter noen minutter eller bare noen sekunder så det er umulig å bli klok på

[Salvesen]

2 timer siden, Tore_Andersen skrev:

Jeg har koblet til PC og leser ut rådata hexadesimalt og får samme utlesning der, melding som kommer hvert 10 sec "mangler" ofte 1 eller 2 byte, mens noen er normale. Det er alltid i slutten av meldingen slik at en av de 4 siste avlesningene blir feil og så har resten følgefeil pga det. Alt før dette er OK.

"React_Pow_P":240,

"React_Pow_M":-536870912,

"Curr_L1":21109,

"Volt_L1":2440

Jeg skal skaffe meg en ny MBUS leser av en annen type og se om jeg får andre resultat. Jeg konstaterer ihvertfall at det ikke skyldes pi,

tror jeg har testet alt av stoppbit og paritet som er mulig og hver gang det ser litt stabilt ut så faller det ut etter noen minutter eller bare noen sekunder så det er umulig å bli klok på

 

Kjempe innsats! Da regner jeg med en av de 3 nye jeg har kjøpt fungerer, i og med at flere her inne har samme type som faktisk fungerer. 

[funny0frank]

Noen som har erfaringer med https://www.aliexpress.com/item/Industrial-Grade-USB-Transfer-to-MBUS-Host-USB-MBUS-Meter-Reading-Communication-USB-Power-Supply-10/32831725364.html ? Sliter med at 120 bytes meldingen er ustabil i lengde og innhold og tenkte jeg skulle prøve en annen en den som var linket til av OP.

[Helgemor]

Noen som har erfaringer med https://www.aliexpress.com/item/Industrial-Grade-USB-Transfer-to-MBUS-Host-USB-MBUS-Meter-Reading-Communication-USB-Power-Supply-10/32831725364.html ? Sliter med at 120 bytes meldingen er ustabil i lengde og innhold og tenkte jeg skulle prøve en annen en den som var linket til av OP.

Jeg har en slik, og anbefaler den IKKE. Se mine innlegg lenger oppe i tråden. Har henvendt meg til leverandøren og venter på svar.


Sent from my iPad using Tapatalk

[Lundig]

Er det noen som har erfaring med å lese ut data fra Aidon AMS måler?.

 

Jeg måler 24V på klemmene på MBUS converter.

Men får ikke noe svar når jeg kjører: ./test_rx -n -d /dev/ttyUSB0

Har forsøkt med både "-P O" og "-P E"

[Actibus]

Er også interessert i om noen har klart å tolke dataene de fikk ut av Aidon, var vel noen her som nevnte det tidligere.

[frodegill]

15 hours ago, Actibus said:

Er også interessert i om noen har klart å tolke dataene de fikk ut av Aidon, var vel noen her som nevnte det tidligere.

Cpu22 har en grei oppsummering her. Jeg holder på med litt Arduinokode på github (som nå har blitt såpass uoversiktlig at neste steg er refaktorering og opprydding). Koden min kjører på en NodeMCU og output kan løpende sjekkes på https://gill-roxrud.dyndns.org:8207/ (ikke bli overrasket hvis det plutselig dukker opp debug-meldinger relatert til checksum. Det skal være CRC16-XMODEM, men av en eller annen grunn sier koden konsekvent at checksum er feil)

[Actibus]

@frodegill

Prøvde såvidt å laste inn koden din, men fikk compiler feil

void write_persistent_string(const char* s, size_t max_length, int& adr)
{
  for (int i=0; i<min(strlen(s), max_length); i++)
  {
    EEPROM.write(adr++, s[i]);
  }
  EEPROM.write(adr++, 0);
}

'min' was not declared in this scope

 

Fjernet 'min' og da lastet den, men skjønner ikke helt hvordan den skal settes opp, fikk lagt inn ssid og passord ved å legge SETUP pin til jord, men finner den ikke på nettverket.

 

Blir et par hakk over mitt nivå på arduinokoding, spesielt uten kommentarer

 

Mitt endelige mål er å få laget det slik at jeg kan sende verdiene via arduino plugin til HomeSeer, men først må klokere hoder (les: deg :D) få en fungerende løsning jeg kan plukke fra hverandre

 

Fantastisk jobb dere gjør iallefall!

Endret 1. mai 2018 av Actibus