Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon! 🥇🥈🥉

Anbefalte innlegg

Skrevet
  ole88 skrev (På 2.5.2019 den 19.20):

Prøvde å korte ned ledningen, men ingen forandring. Har vært inne på tanken selv, om at kanskje adapteret er problemet i og med at det er ustabilt i meldingene.

Uansett, takk for hjelp :)

Ekspander  

Jeg har benyttet denne et par mnd nå uten problemer:

https://www.aliexpress.com/item/USB-to-MBUS-Slave-Module-Discrete-Component-Non-TSS721-Circuit-M-BUS-Bus-Monitor/32917153031.html?spm=a2g0s.9042311.0.0.65084c4dHuLwpT

Skrevet
  ole88 skrev (På 2.5.2019 den 8.42):

Takk for hjelpen. Jeg trodde at å skrive kun msg i debug noden ville "printe" alle verdier, men når jeg fylte inn "payload.act_pow_pos" i feltet, fikk jeg ut forbruk av watt. Tusen takk for hjelp!!

Til andre som kanskje kommer til å slite med det samme, disse innstillingene fungerer for meg: 

 

Oppsett.png

Ekspander  

Til info så jobber jeg med en ny versjon av decoderene der man får opp alle data i msg.payload uavhengig av man setter inn komplett objektnavn slik som msg.payload.act_pow_pos. I tillegg kommer jeg til å implementere "msg.payload = msg.payload.toUpperCase();" slik at man kan slippe å medta denne i funsksjonsnoden. 

  • 1 måned senere...
Skrevet

Heisann!

 

Jeg har laget en dekoder til disse smartmålerne også. Min dekoder tar seg _KUN_ av dekoding av seriell-strømmen til JSON, men fungerer med både Aidon, Kamstrup og Kaifa-målere. I tillegg har den en opsjon for å kjøre et program for hver melding, så det er enkelt å lage en systemd unit som bruker f.eks. mosquitto_pub for å sende meldingen til et MQTT-endepunkt. Programmet er skrevet i Perl og skal fungere helt greit på en Raspberry Pi eller andre Linux-baserte operativsystemer.

 

Her er linken, hvis det skulle være av interesse: https://github.com/robinsmidsrod/ams-han-decoder

 

Personlig bruker jeg det til å sende JSON-meldingene over MQTT (bruker mosquitto) til Node-Red, som igjen kverner litt på meldingene og sender de videre til InfluxDB. Deretter bruker jeg Grafana til å visualisere informasjonen lagret i InfluxDB.

 

Jeg så det var postet noen logger fra en Kamstrup-måler i tråden, og kjørte de gjennom dekoderen min. La umiddelbart merke til at de hadde bl.a. checksum-feil og masse andre feil (hvis jeg ignorerte checksum-feilen). Når jeg så det scrollet jeg litt lenger opp og så lenka til hvilket MBUS-til-USB-adapter som ble benyttet. Da skjønte jeg hvorfor ting ikke virket. Jeg hadde den samme modulen først og hadde samme problemet med min. Kjøp en ny adapter (link i programkoden i mitt git repo til adapter som virker) så skal alt virke.

 

Når jeg nå ser størrelsen på programkoden min (i Perl) for å få til riktig dekoding skjønner jeg at det er omfattende å skrive en (korrekt) dekoder i Node-Red. Det kan hende dere finner noe nyttig info i programkoden som kan hjelpe dere med å skrive en bedre node-red contrib-modul. Uansett synes jeg dette er spennende og det er artig å endelig få god oversikt over strømforbruket i heimen. :)

 

-- Robin

Skrevet

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. ?

 

  Vis skjult innhold


 

Skrevet
02 19                                                           <-- List ID


bmork: nei. 02 er struct.  19 er antall felt (25 desimalt).  Merk at dette er en flat struktur.
OBIS-koder og etterfølgende verdier er alle på samme nivå.  Antallet må derfor alltid være et
oddetall ettersom liste-navnet kommer først, uten noen OBIS-kode

0A                                                              <-- (what's this, a separator?)

bmork: 0a er "visible-string"


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

bmork:  06 er "double-long-unsigned", dvs et 32bit unsigned heltall.  De to 00 bytene er altså en del av
verdien din: 0x000006a7


       12 00                                                    <-- (what's this, yet another separator?)
       EB                                                       <-- 235 V (L1 Voltage)
 
 bmork: 12 er "long-unsigned", dvs et 16bit heltall (ja, de har noen merkelige ideer om "long").  00 er
 alså en del av spenningsverdien din: 0x00eb

Ble litt slitsomt å quote dette, men prøver meg med noen inline-kommentarer ovenfor.  Håper det kan tydes...

  • Like 1
Skrevet

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. :) 

  • roy endret tittelen til Hjelp til tyding av DLMS OBIS datapush-meldinger
Skrevet

Hei.

 

har prøvd på dette en stund nå, men får bare feilmelding:

 

TypeError: Object  ()  has no method 'includes'

 

har den ustabile modulen, men lengden på pakkene ser veldig stabile ut for et utrent øye, det ser også ut som de er bygget opp som instruksjonen fra Aidon.

 

Noen som vet hva jeg har røra med?

 

 

  Vis skjult innhold

 

 

Skrevet
  hmmm skrev (På 26.6.2019 den 23.01):

har den ustabile modulen, men lengden på pakkene ser veldig stabile ut for et utrent øye, det ser også ut som de er bygget opp som instruksjonen fra Aidon.

Ekspander  

Vet ikke hva som er galt, men kan ihvertfall bekrefte at de to pakkene du postet er korrekte og fullstendige.

  • 2 uker senere...
Skrevet

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?

 

Skrevet
  roy skrev (På 11.7.2019 den 6.00):

07 E3 07 09 02 14 00 05 FF 80 00 80 <-- What's this?

Ekspander  

 

Dette er dato og klokke fra måleren.  Formatet er beskrevet f.eks. i kapittel 4.1.6 i dette åpne dokumentet: https://www.dlms.com/files/Blue-Book-Ed-122-Excerpt.pdf

Du har:

07e3  => år: 2019

07 => måned: juli

09 => dag: 9.

02 => ukedag: tirsdag

14 00 05 => time, min, sek: 20:00:05

ff => hundredeler: ikke oppgitt

80 00 => offset fra UTC er ikke oppgitt

80  => status: sommertid(?)

 

Skrevet

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. :)

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.