Lesing av AMS data (AMS/HAN -> IoT)

[ZoRaC]

6 timer siden, DIYglenn skrev:

Man er vel så vidt jeg også nødt til å gjøre endringer i MQTT-biblioteket for å kunne sende store nok pakker?

 

Nei, de har endret MQTT-biblioteket, sånn at den endringen kan gjøres med å definere en konstant i egen kode i stedet. 

[killi]

Hei.

Jeg har akkuratt fått aktivert HAN utgangen på min Aidon måler Den begynte å gi spenning lørdags kveld. Jeg har brukt en HAN til TTL converter og koblet den videre inn på en crestron programmerbar processor. Jeg har prøvd meg frem med baudrates og parity og det ser ut som at 2400 8,1,EVEN gir mest konsekvent og lik data. Jeg får små pakker hver 2,5 sekund og større hver 10 sekund slik jeg forstår det skal være. Men om dere ser på data som kommer inn. Er dette noe som kan stemme, dvs at jeg har koblet alt korrekt. Og hvordan kan jeg lese disse kodene, API osv?

Jeg vurderer å sette opp en raspberry piom det kan gjøre parsingen bedre og om den da har mulighet å sende videre på ethernet i formatert ascii format til crestron prossessoren som styrer resten av huset? Om en ser på syntax på kodene nedenfor så betyr \x at det som kommer etterpå er i hex verdi. 

 

Takker for hjelp.

 

[ArnieO]

@killi Jeg anbefaler deg å se på hvordan listene for Aidon er definert. Det ligger noe på @roarfred sin GitHub under «Dokumentasjon»: https://github.com/roarfred/AmsToMqttBridge

[Andreas]

Du burde sett 01,00,01,07,00,FF i den pakken som kommer hvert 2.5 sek

 

Første byte og siste byte skal være 7E.

 

Prøv å endre instillinger til det stemmer..

Endre stop bit, start bit og paritet.

Kan også teste 7 vs 8 bit

Endret 20. januar 2019 av Andreas

[Odd]

En ting jeg stusser på her er at grensesnittet holder seg ikke innenfor M-bus standarden da det ikke går an å sende meldinger fra det.

Eller tar jeg feil?

Hvis det er tilfellet kan jo ikke dette brukes på andre M-bus givere.

Det er faktisk mulig å kople flere m-bus givere på strøm-måleren som slaver for å lese av for eksempel vann forbruk.

Vi får imidlertid ikke lest disse uten å kunne sende en melding til de.

[ArnieO]

14 hours ago, Odd said:

En ting jeg stusser på her er at grensesnittet holder seg ikke innenfor M-bus standarden da det ikke går an å sende meldinger fra det.

Eller tar jeg feil?

Hvis det er tilfellet kan jo ikke dette brukes på andre M-bus givere.

Det er faktisk mulig å kople flere m-bus givere på strøm-måleren som slaver for å lese av for eksempel vann forbruk.

Vi får imidlertid ikke lest disse uten å kunne sende en melding til de.

Du kan ikke sende til AMSen, nei. Kun motta det som kommer på gitte tidsintervall. 

[MLL]

18 hours ago, Odd said:

En ting jeg stusser på her er at grensesnittet holder seg ikke innenfor M-bus standarden da det ikke går an å sende meldinger fra det.

Eller tar jeg feil?

Hvis det er tilfellet kan jo ikke dette brukes på andre M-bus givere.

Det er faktisk mulig å kople flere m-bus givere på strøm-måleren som slaver for å lese av for eksempel vann forbruk.

Vi får imidlertid ikke lest disse uten å kunne sende en melding til de.

Strømmålerne bruker kun det fysiske laget av M-Bus standarden.

[ronnyandre]

Håper ikke dette er gammelt nytt, i så fall så beklager jeg. Har mast på Hafslund for å få åpnet porten selv om standarden ikke er klar, og fikk til svar at de vil åpne HAN-porten denne uken.

[mk1 black limited]

Tro om det gjelder alle Hafslundkunder?

[ronnyandre]

11 minutter siden, mk1 black limited skrev:

Tro om det gjelder alle Hafslundkunder?

 

Fikk inntrykk av dette. Her er det de svarte meg:

 

Sitat

Det vil bli mulig å bestille åpning av HAN-porten i løpet av denne uken. Ettersom du nå har tatt kontakt vedrørende dette, så vil du motta en e-post fra oss når det er lagt tilrette for åpning av HAN-porten inne på Min side.

 

Det virker som enten holder det å gi beskjed nå, eller så kan det gjøres på Min side. Jeg har også sett at de har et nyhetsbrev angående HAN som man kan melde seg på, hvor det sikkert kommer informasjon om hvordan man aktiverer sin port.

[mk1 black limited]

Det nyhetsbrevet meldte jeg meg på for leeeenge siden, det har ikke kommet en eneste epost med info enda...:)

 

Men vi krysser fingrene!

[Odd]

23 timer siden, MLL skrev:

Strømmålerne bruker kun det fysiske laget av M-Bus standarden.

 

Det stemmer ikke helt.

Min har punkt for tilkopling av andre m-bus givere for eksempel forskjellige typer vann og effekt målere.

 

[xibriz]

@MLLrefererer nok til HAN-porten. Den ble vel avklart tidligere at den M-bus porten noen målere har et noe annet. 

[Odd]

7 minutter siden, xibriz skrev:

@MLLrefererer nok til HAN-porten. Den ble vel avklart tidligere at den M-bus porten noen målere har et noe annet. 

 

I følge dokumentasjonen er punktene under dekslet jeg tok bilde av, tilkoblingspunkt for andre M-bus slaver.

Disse kan leses av over den i utgangspunktet standard M-bus porten som måleren er utstyrt med.

Forutsetningen er imidlertid at en kan polle de andre giverne, det vil si sende en melding til de (TX).
Det går ikke med det designet det er lagt opp til her.

Hvis en har holdt seg til standarden, kunne en sannsynligvis ha lest og styrt ventilasjons systemer med M-bus og alle andre givere.

Jeg har både ventilasjon og to vannmålere som kan koples til.

Endret 22. januar 2019 av Odd

[Moskus]

45 minutter siden, Odd skrev:

I følge dokumentasjonen er punktene under dekslet jeg tok bilde av, tilkoblingspunkt for andre M-bus slaver.

Det kan jo stemme, men den er ikke et krav i hht. NVE.

Vår Aidon har ikke en slik port.

 

[Odd]

35 minutter siden, Moskus skrev:

Det kan jo stemme, men den er ikke et krav i hht. NVE.

Vår Aidon har ikke en slik port.

 

 

Neivel, skjønner.

Men er både RX og TX på HAN grensesnittet der?

 

Litt synd at designet ikke holder seg til M-Bus standarden allikevel da.

Med både RX og TX kunne det ha vært brukt på andre M-bus enheter som for eksempel ventilasjons systemer i tillegg.

Nå er det spesialtilpasset til en bestemt bruk og støtter ikke engang funksjoner på alle målerne i Norge.
Hvem vet om ikke det med tiden kan bli bruk for TX?

Endret 22. januar 2019 av Odd

[Moskus]

20 minutter siden, Odd skrev:

Men er både RX og TX på HAN grensesnittet der?

Kun sending.

Hva skal HAN-porten kunne motta...?

[Odd]

2 timer siden, Moskus skrev:

Hva skal HAN-porten kunne motta...?

 

På min måler kunne jeg muligens ha spurt to M-bus givere for varmtvanns forbruk som jeg har.

Disse var tilkoplet min forrige måler for fjernavlesning.

Det vil si givere eller andre M-bus enheter koplet opp mot måleren og som aksesseres via HAN porten.

 

Det som kanskje kan ødelegge den muligheten er hvordan NVE har valgt å sende informasjon ut på bussen uten at noen har spurt om den.

Den vanlige måten å innhente data på en M-bus er å spørre etter den når en trenger den, noe jeg vil si er my mere logisk.

 

Uansett hvis dere velger å ta med både rx og tx, vel en kunne benytte grensesnittet mot andre M-bus enheter enn en måler med HAN.

 

Vel, dette er ikke så viktig for meg, jeg bare stusser på at en velger å ta bort noe på et grensesnitt som har støtte i HW og i en standard.

Jeg velger bare en annen løsning som har støtte for både rx og tx.

Endret 22. januar 2019 av Odd

[ArnieO]

5 hours ago, Odd said:

Uansett hvis dere velger å ta med både rx og tx, vel en kunne benytte grensesnittet mot andre M-bus enheter enn en måler med HAN.

Dette er jo for så vidt et godt poeng, og det er kun en liten modifikasjon å legge inn Tx også på kortet jeg jobber med.

@roarfred hadde den med på kortet han la ut, jeg har tydeligvis ikke tenkt langt nok og generelt nok. ?

 

OK - point taken, jeg legger den inn når jeg får jobbet videre med kortet (er på jobbreise nærmeste par ukene).

Takk for god input!

[xibriz]

Trenger vi en egen tråd for AMS uten ekstern power? Uansett, jeg følte at denne hører hjemme her:

 

 

[Odd]

5 timer siden, xibriz skrev:

Trenger vi en egen tråd for AMS uten ekstern power? Uansett, jeg følte at denne hører hjemme her:

 

 

 

Du linker til riktig fyr
Han har vært med på grunn designen av flere løsninger som nå er i salg.
Jeg har et kort han har lagd som faktisk bruker en annen prosessor for å vekke opp hovedprosessoren når det er nødvendig.

 

Det som jeg stusser litt på er om vi faktisk oppnår noe med å "spare" strøm i mellom, 
når det er den nødvendige lesingen og videresendingen som faktisk er kritisk og trekker mest.
Det er hva vi bruker i øyeblikket vi leser, som er utfordringen slik jeg ser det. Vi får ikke uten videre mere tilgjengelig ved å "spare" mellom lese øktene.
Da må det i tilfelle inn et annet HW design.

Denne artikkelen er imidlertid veldig interessant for oss som bruker ESP32 til batteri drevet overvåkning av tilstander,

og som rota med assembler i forrige årtusen

 

Endret 23. januar 2019 av Odd

[bearer]

 

1 hour ago, Odd said:

Det er hva vi bruker i øyeblikket vi leser, som er utfordringen slik jeg ser det. Vi får ikke uten videre mere tilgjengelig ved å "spare" mellom lese øktene.
Da må det i tilfelle inn et annet HW design.
 

Derfor eg heller mot en buck konverter som er styrt av en microkontroller som også kan ta seg av jobben å være buffer for seriedata og vekke opp radio eller esp når det er nok data og energi tilgjengelig. Men stopper litt opp i påvente av bedre måleustyr.

[xibriz]

4 timer siden, Odd skrev:

 

Du linker til riktig fyr
Han har vært med på grunn designen av flere løsninger som nå er i salg.
Jeg har et kort han har lagd som faktisk bruker en annen prosessor for å vekke opp hovedprosessoren når det er nødvendig.

 

Det som jeg stusser litt på er om vi faktisk oppnår noe med å "spare" strøm i mellom, 
når det er den nødvendige lesingen og videresendingen som faktisk er kritisk og trekker mest.
Det er hva vi bruker i øyeblikket vi leser, som er utfordringen slik jeg ser det. Vi får ikke uten videre mere tilgjengelig ved å "spare" mellom lese øktene.
Da må det i tilfelle inn et annet HW design.

Denne artikkelen er imidlertid veldig interessant for oss som bruker ESP32 til batteri drevet overvåkning av tilstander,

og som rota med assembler i forrige årtusen

 

 

Jeg tenker at det kan være nødvendig å buffre opp ca. ett minutt med data før man sender.

 

Også kan man jo måle om det er nok data til å sende før man våkner

Endret 23. januar 2019 av xibriz

[Odd]

56 minutter siden, xibriz skrev:

Jeg tenker at det kan være nødvendig å buffre opp ca. ett minutt med data før man sender.

  

Også kan man jo måle om det er nok data til å sende før man våkner

 

Ja, kombinert med å bare sende videre hvis dataene endrer seg utover et visst nivå.

Det hjelper imidlertid ikke hvis en ikke har "lagret" litt effekt så en har litt mere enn hva HAN porten leverer på forhånd.
 

[killi]

Hei.

Jeg prøver meg igjen på logging av han. Denne gangen med en Raspberry og med han scriptet. Fikk ikke til å laste inn det ferdige imaget så jeg lastet ned standard rasperry OS og la inn han-port-1.15. Når jeg koblet til USB til HAN adapteret så fikk jeg inn dette. Aner ikke hva det betyr og ser ingen fornuft i dataen. Er min Aidon HAN data kryptert?

Takker for svar. Er første gang jeg tar i en Rasperry idag. Ønsker egentlig bare å ta imot data parce det til mer standardisert ascii kode og så multicaste det videre på nettverket til annen prossessor som jeg har mer kontrollen på. 

 

root@raspberrypi:/home/pi/han-port-1.15# ./test_rx -m -n -d /dev/ttyUSB0
{"Date_Time":"",
"Host_Time":1548361631.255,

{"Date_Time":"",
"Host_Time":1548361632.629,

{"Date_Time":"",
"Host_Time":1548361635.121,

{"Date_Time":"",
"Host_Time":1548361637.629,

{"Date_Time":"",
"Host_Time":1548361641.242,