Gå til innhold
  • Bli medlem
roarfred

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

Anbefalte innlegg

5 minutes ago, ToreOe said:

@aulvoy

 

Koden fra gskjold leser (sannsynligvis) 3-fase fint.  Må ta forbehold om at jeg ikke vet, og ikke har mulighet for å sjekke om Aidon sender ut forskjellige data for 3-fase IT/TT og 3-fase TN.

 

-Tore

@ToreOe Oppdaterer gjerne for 1-fase hvis du har input på endringer.

 

@aulvoy Hvis du allerede bruker min fork av koden og det ikke fungerer med Aidon 3-fas, så kan du flashe rdebugger branchen og bruke telnet mot den og se rådata som koden ikke klarer å tolke. Da kan vi implementere for disse også.

Del dette innlegget


Lenke til innlegg
Del på andre sider

Jeg jobber fortsatt litt med å få koden til gskjold til å fungere med annet en liste 1 på en 3 fas Aidon. 

 

Ser ut til at min måler sender ut liste 2 med en lengde på 12 og ikke 13 som koden forventer. Og dessverre så har rdebugger branchen problemer med å debugge da esp restarter når den får en melding type 2.

 

Jeg prøver når jeg har tid til å finne problemet, men har så langt ikke fått det til.

Del dette innlegget


Lenke til innlegg
Del på andre sider
Just now, rcastberg said:

Og dessverre så har rdebugger branchen problemer med å debugge da esp restarter når den får en melding type 2.

 

Dette kan være relatert til json packet size som jeg endret 27.april. Hadde glemt å merge den over i rdegugger. Dette  er gjort nå

Del dette innlegget


Lenke til innlegg
Del på andre sider

@gskjold og @rcastberg jeg har skrevet om en del på Aidon i koden jeg fant på fork til gskjold. Har lastet ned github desktop og skal prøve å sende dette inn igjen. Helt nytt for meg med Arduino og github så tilgi meg om dette ble helt feil :) 

 

Har lagt til kode for IT list 2 og 3 og beholdt TN list 2 og 3 slik at dette vil bli gjenkjent av kode. 

 

Fikk ikke med endringer i Aidon.h i commit greiene. Legger ved her

Aidon.h

Endret av aulvoy
Legger ved fil

Del dette innlegget


Lenke til innlegg
Del på andre sider

@aulvoy  ser at lengden kanskje stemmer mer med det min måler leverer, men renger med at du også endret funskjonen readHanPort_Aidon() for å få det til å fungere. Hadde du lastet det opp med git?

Del dette innlegget


Lenke til innlegg
Del på andre sider

@rcastberg prøvde å sende dette inn til gskjold i git, men det er ikke sikkert det ble gjort riktig fra min side. legger ut min .ino fil her. Aidon måler kontroller mot 230V 3-fase og lagt inn desimaler på kWh. Får online 400V 3-fase i løpet av kveld/helg så da får jeg kontrollert denne også, regner med det er feil på kWh her også. 1-fase måler tror jeg at jeg også skal klare å få online i løpet av helgen, da vil disse 3 variantene være verifisert på avlest og sendt til mqtt til mandag :)

 

AmsToMqttBridge.ino

Del dette innlegget


Lenke til innlegg
Del på andre sider
På 21.5.2019 den 19.05, deve87 skrev:

Fikk åpnet HAN porten på Aidon måler i går. Har benyttet koden til @Johove

https://github.com/johove/HAN-powermeter 

 

Benyttet MySensors plugins (gateway LAN/WiFi) mot Domoticz og en ESP8266. Koden trenkte en liten endring, men ellers lik.

 

Ting dukker opp i Domoticz, men av og til får jeg kommafeil på spenning og ampere dataen. Usikker på om det er noe med koden, Domoticz, eller måler. Noen som kan vite hva det eventuelt kommer av?

 

Slik en ser på loggen i bildene. Går plutselig spenningen fra 240,1V til 24010V og tilbake til 240,3V

 

Samme gjelder ampere, men kWh daglig og watt holder seg stabilt

 

 

AMS1.jpg

AMS2.jpg

AMS3.jpg

 

På amper og volt sendes det med  eksponent i OBIS meldinga fra målern, det er sannsynlig at feilen er i seriellgrensesnittet,  og at eksponenten ikke leses korrekt, du får da kommafeil.  Disse dataene kommer i en relativt lang melding hvert 10s i siste del av pakka. Dersom du har utfordringer med mbus til ttl kortet, strømforsyning til dette, eller timing i prosessoren kan det skje, avhengig av om du bruker software eller hardware seriell. 

 

Det enkleste er å liste verdiene som lese i debuggmodus for å sjekke, eller sette kommasetting fast som en quick fix.

 

Jeg har 2 slike måler stående med Arduino og 2.4Mhz mesh nettverk, jeg får ikke disse feilene.  Måelre jeg leser fra er  Aidon på Hafslund og  en i Ringsaker på Eidsiva.

Endret av Johove

Del dette innlegget


Lenke til innlegg
Del på andre sider
På 5.5.2019 den 10.56, rcastberg skrev:

Hei,

 

Jeg har 4 stk kretskort om noen er interessert, 70kr (porto inkludert), og har eventuelt en jeg kan sende som er ferdig loddet til 450kr (porto inkludert).

Disse er fra original designen til roarfred. Jeg har klart å lese meldinger fra min måler og kan bekrefte at de fungerer.

Send pm om noen er interessert.

 

Rene

20190505_105235.jpg

 

Jeg kjøpte et av disse. Det ser veldig bra ut, men jeg har innsett at jeg ikke kommer til få tid til å gå i gang med dette. Dessverre. Så jeg selger videre til kostpris, kr 70 inkl porto. Send pm om du er interessert. 

 

Endret av DeVille

Del dette innlegget


Lenke til innlegg
Del på andre sider
På 24.5.2019 den 10.13, Johove skrev:

 

På amper og volt sendes det med  eksponent i OBIS meldinga fra målern, det er sannsynlig at feilen er i seriellgrensesnittet,  og at eksponenten ikke leses korrekt, du får da kommafeil.  Disse dataene kommer i en relativt lang melding hvert 10s i siste del av pakka. Dersom du har utfordringer med mbus til ttl kortet, strømforsyning til dette, eller timing i prosessoren kan det skje, avhengig av om du bruker software eller hardware seriell. 

 

Det enkleste er å liste verdiene som lese i debuggmodus for å sjekke, eller sette kommasetting fast som en quick fix.

 

Jeg har 2 slike måler stående med Arduino og 2.4Mhz mesh nettverk, jeg får ikke disse feilene.  Måelre jeg leser fra er  Aidon på Hafslund og  en i Ringsaker på Eidsiva.

 

Har bestilt noe Arduino kort, for prøve å kjøre det via Mysensors Seriell (via USB TTL) for å se.

 

Prøve å kjøre M-bus TTL med 5V med 3.3V - 5V konvensjonen. Men ble igrunn mer feil av det.

 

Får av en eller annet grunn ikke ting til å fungere med en vanlig NodeMCU men bare via en Wemos Mini Pro. Koden kjører fint inn i NodeMCU men ingen data kommer inn i Mysensors.

 

Laget et enkelt LUA script som setter komma for verdier over 10000 for VA og 1000 for spenning. Deler bare tallene på 1000 for VA og 100 for spenning.

Endret av deve87

Del dette innlegget


Lenke til innlegg
Del på andre sider
12 minutes ago, deve87 said:

 

Har bestilt noe Arduino kort, for prøve å kjøre det via Mysensors Seriell (via USB TTL) for å se.

 

Prøve å kjøre M-bus TTL med 5V med 3.3V - 5V konvensjonen. Men ble igrunn mer feil av det.

 

Får av en eller annet grunn ikke ting til å fungere med en vanlig NodeMCU men bare via en Wemos Mini Pro. Koden kjører fint inn i NodeMCU men ingen data kommer inn i Mysensors.

 

Laget et enkelt LUA script som setter komma for verdier over 10000 for VA og 1000 for spenning. Deler bare tallene på 1000 for VA og 100 for spenning.

Hei,

tenkte bare å nevne at om du skal bruke NodeMCU så kan det være en god ide å swape-pins på serial, sånn at du ikke deler seriell-bus med USB-serial adapteren samt mbus-ttl adapteren.

Gjør det i koden jeg kjører på dette prosjektet. https://github.com/alekslt/HANToMQTT og det fungerer greit. Holder egentlig bare å kjøre swap på serial etter begin, samt koble mot GPIO13/RX2. Opplever dog ganske høy rate på CRC-errors med kabel mellom en NodeMCU og mbus-ttl kort, så greit å holde kabellengde kort eller alt på et PCB.

 

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
6 minutter siden, AleksanderLT skrev:

Hei,

tenkte bare å nevne at om du skal bruke NodeMCU så kan det være en god ide å swape-pins på serial, sånn at du ikke deler seriell-bus med USB-serial adapteren samt mbus-ttl adapteren.

Gjør det i koden jeg kjører på dette prosjektet. https://github.com/alekslt/HANToMQTT og det fungerer greit. Holder egentlig bare å kjøre swap på serial etter begin, samt koble mot GPIO13/RX2. Opplever dog ganske høy rate på CRC-errors med kabel mellom en NodeMCU og mbus-ttl kort, så greit å holde kabellengde kort eller alt på et PCB.

 

 

 

Alright. Skal prøve 🙂

Del dette innlegget


Lenke til innlegg
Del på andre sider

I går stoppet plutselig måler å sende ut data. TX lyset på M-Bus kortet lyste / blinket ikke.

 

Hjalp ikke å ta spenningen på ESPn, men derimot ta strømmen på måler (hovedsikring) gjorde susen. 

 

Nå kommer datan helt fint inn, ingen store peaker lenger. 

 

Mente og ha lest at flere hatt samme problemet med Aidon måler plutselig slutter å sende data

Del dette innlegget


Lenke til innlegg
Del på andre sider

Kan være strømbegrenseren som slår av utgangen. Er bare å koble fra kabelen en liten stund, så slår den seg på igjen.

Del dette innlegget


Lenke til innlegg
Del på andre sider
37 minutter siden, Hårek skrev:

Kan være strømbegrenseren som slår av utgangen. Er bare å koble fra kabelen en liten stund, så slår den seg på igjen.

Det var forsatt spenning på utgangen. Men ingen data bare

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 minute ago, deve87 said:

Det var forsatt spenning på utgangen. Men ingen data bare

Hvis du har koblet til RX inn mot M-Bus adapteren (altså sende data fra ESP(TX) til MBUS(RX)) så kan du prøve med bare mottak koblet opp, evt være sikker på at du ikke prøver å snakke med HAN-porten. Mener å ha sett at strømmålerne blir furten og stopper å sende data om du prøver å sende noe til dem (typ logmeldinger osv)

Del dette innlegget


Lenke til innlegg
Del på andre sider
54 minutter siden, AleksanderLT skrev:

Hvis du har koblet til RX inn mot M-Bus adapteren (altså sende data fra ESP(TX) til MBUS(RX)) så kan du prøve med bare mottak koblet opp, evt være sikker på at du ikke prøver å snakke med HAN-porten. Mener å ha sett at strømmålerne blir furten og stopper å sende data om du prøver å sende noe til dem (typ logmeldinger osv)

Neida, er bare TX fra M-Bus mot ESP som er tilkoblet 

Del dette innlegget


Lenke til innlegg
Del på andre sider
På 27.5.2019 den 19.06, deve87 skrev:

Det var forsatt spenning på utgangen. Men ingen data bare

Er det slik at man kan måle når porten er åpen eller ikke ? jeg får beskjed om at min aidon er åpnet måler 0.1 volt bare mellom pin 1 og 2. Trodde det skulle være 24v når den var åpen eller tuller kraftselskapet med meg ?

Del dette innlegget


Lenke til innlegg
Del på andre sider
13 minutes ago, Frode S said:

Er det slik at man kan måle når porten er åpen eller ikke ? jeg får beskjed om at min aidon er åpnet måler 0.1 volt bare mellom pin 1 og 2. Trodde det skulle være 24v når den var åpen eller tuller kraftselskapet med meg ?

 

Er veldig sikker på den er lukket. volt skal gå opp og ned relativt konstant

Del dette innlegget


Lenke til innlegg
Del på andre sider
2 minutter siden, aleks skrev:

 

Er veldig sikker på den er lukket. volt skal gå opp og ned relativt konstant

Bare er usikker på hvor mange volt jeg bør se når jeg måler ? for med godviljen til kan jeg kansje tyde 0.11-0.17v  (måler med vanlig multimeter). De påstår den er åpnet men gir ingen utslag når jeg kobler USB-mbus modulen til (den uten kabel fra aliexpress tilkoblet PI lyset er på konstant på modulen)

Del dette innlegget


Lenke til innlegg
Del på andre sider
1 minute ago, Frode S said:

Bare er usikker på hvor mange volt jeg bør se når jeg måler ? for med godviljen til kan jeg kansje tyde 0.11-0.17v  (måler med vanlig multimeter). De påstår den er åpnet men gir ingen utslag når jeg kobler USB-mbus modulen til (den uten kabel fra aliexpress tilkoblet PI lyset er på konstant på modulen)

 

Hva skjer hvis du dumper rådata? Tror det er 20+v så volt nede i dette tyder på lukket port

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

Når jeg kjører han port test programvaren eller aidon_test.py scriptet skjer det ingenting og jeg har satt rettigheter på /dev/ttyUSB0 porten så den skal være tilgjengelig.

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
7 timer siden, Frode S skrev:

Er det slik at man kan måle når porten er åpen eller ikke ? jeg får beskjed om at min aidon er åpnet måler 0.1 volt bare mellom pin 1 og 2. Trodde det skulle være 24v når den var åpen eller tuller kraftselskapet med meg ?

Skal være 24VDC på utgangen som statlig endres seg.

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider
12 timer siden, deve87 skrev:

Skal være 24VDC på utgangen som statlig endres seg.

Jepp, fikk bekreftet at de alikevel ikke hadde fått åpnet porten.... mistenker det ligger gammal firmware på måleren min, står 2017 på boksen

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
På 14.6.2019 den 19.14, Frode S skrev:

Jepp, fikk bekreftet at de alikevel ikke hadde fått åpnet porten.... mistenker det ligger gammal firmware på måleren min, står 2017 på boksen

 

Firmware skal oppdateres sentralt uten at du gjør noe. De sluttet jo å sende ut testdata også før ELhub ble startet opp. Vent og se hva som skjer nå som de har bekreftet at den ikke var åpen.

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Fjern formatering

  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.


  • Lignende innhold

    • Av Preben
      Hei,
       
      Har mekka litt for å få HAN-data fra Kamstrup-måleren min (1-fas) inn i Home Assistant.
       
      Bruker ESPHome med en ESP32 for å få inn data, forsøkte med en ESP8266, men den var ikke helt glad i software serieport, derfor måtte jeg ty til 32'en.
       
      Koden er ganske stygg foreløpig, men kanskje det kan hjelpe noen andre på vei:)
       
      Parser dataen ved å lese ut OBIS-koder og så hente tilknyttede data. Ingen CRC-sjekk e.l. da dingsen min ikke ser ut til å lese korrupte data i det hele tatt så langt.
       
      Har lånt en del inspirasjon fra RoarFreds HAN-leser, selv om jeg endte opp med noe ganske annerledes etterhvert:)
       
      ESPHome-konfigurasjonsfil:
      esphome: name: ams platform: ESP32 board: nodemcu-32s includes: mbus.h wifi: power_save_mode: light networks: - ssid: "LulzNettOppe" password: ##PASSORD## - ssid: "LulzNettEkstra" password: ##PASSORD## - ssid: "LulzNett" password: ##PASSORD## # Enable logging logger: level: DEBUG # Enable Home Assistant API api: ota: uart: id: uart_bus tx_pin: GPIO17 rx_pin: GPIO16 baud_rate: 2400 # Example configuration entry dallas: - pin: GPIO25 sensor: - platform: dallas address: 0xEA0214808622FF28 name: "Temperature Sikringsskap" - platform: custom lambda: |- auto mbus_reader = new MbusReader(id(uart_bus)); App.register_component(mbus_reader); return {mbus_reader->wattage_sensor, mbus_reader->reactive_power_sensor, mbus_reader->amperage_sensor, mbus_reader->voltage_sensor, mbus_reader->energy_sensor, mbus_reader->reactive_energy_sensor}; sensors: - name: "AMS Wattage" unit_of_measurement: kW accuracy_decimals: 3 filters: - multiply: 0.001 - name: "AMS Reactive Power" unit_of_measurement: VAr accuracy_decimals: 0 internal: true - name: "AMS Amperage" unit_of_measurement: A accuracy_decimals: 2 filters: - multiply: 0.01 - name: "AMS Voltage" unit_of_measurement: V accuracy_decimals: 0 - name: "AMS Hourly Energy" unit_of_measurement: kWh accuracy_decimals: 3 filters: - multiply: 0.01 - name: "AMS Hourly Reactive Energy" unit_of_measurement: kVArh accuracy_decimals: 3 internal: true filters: - multiply: 0.01 mbus.h:
      #include "esphome.h" class MbusReader : public Component, public uart::UARTDevice, public Sensor { public: MbusReader(uart::UARTComponent *parent) : uart::UARTDevice(parent) {} uint8_t temp_byte = 0; uint8_t *temp_byte_pointer = &temp_byte; uint8_t uart_buffer_[512]{0}; uint16_t uart_counter = 0; char uart_message[550]; char temp_string[10]; char obis_code[32]; char temp_obis[10]; uint32_t obis_value = 0; float wattage = 0; float amperage = 0; float voltage = 0; float energy = 0; Sensor *wattage_sensor = new Sensor(); Sensor *amperage_sensor = new Sensor(); Sensor *voltage_sensor = new Sensor(); Sensor *energy_sensor = new Sensor(); Sensor *reactive_power_sensor = new Sensor(); Sensor *reactive_energy_sensor = new Sensor(); void setup() override { } void loop() override { bool have_message = read_message(); } bool read_message() { while(available() >= 1) { read_byte(this->temp_byte_pointer); if(temp_byte == 126) { if(uart_counter > 2) { uart_buffer_[uart_counter] = temp_byte; uart_counter++; uart_message[0] = '\0'; strcpy(uart_message, ""); for (uint16_t i = 0; i < uart_counter && i < 256; i++) { //sprintf(temp_string, "%02X", uart_buffer_[i]); //strncat(uart_message, temp_string, 2); if(uart_buffer_[i-1] == 9 && uart_buffer_[i] == 6) { obis_code[0] = '\0'; strcpy(obis_code, ""); for (uint16_t y = 1; y < 6; y++) { sprintf(temp_obis, "%d.", uart_buffer_[i + y]); strcat(obis_code, temp_obis); } sprintf(temp_obis, "%d", uart_buffer_[i + 6]); strcat(obis_code, temp_obis); ESP_LOGV("uart", "OBIS code found: %s message length: %d", obis_code, uart_buffer_[i + 7]); obis_value = 0; if(uart_buffer_[i + 7] == 6) { for(uint8_t y = 0; y < 4; y++) { obis_value += (long)uart_buffer_[i + 8 + y] << ((3-y) * 8); } } else if(uart_buffer_[i + 7] == 18) { for(uint8_t y = 0; y < 2; y++) { obis_value += (long)uart_buffer_[i + 8 + y] << ((1-y) * 8); } } if(strcmp(obis_code, "1.1.1.7.0.255") == 0) { ESP_LOGV("uart", "Wattage: %d", obis_value); wattage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.31.7.0.255") == 0) { ESP_LOGV("uart", "Amperage: %d", obis_value); amperage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.32.7.0.255") == 0) { ESP_LOGV("uart", "Voltage: %d", obis_value); voltage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.1.8.0.255") == 0) { ESP_LOGV("uart", "Energy Usage Last Hour: %d", obis_value); energy_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.4.7.0.255") == 0) { ESP_LOGV("uart", "Reactive Power: %d", obis_value); reactive_power_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.4.8.0.255") == 0) { ESP_LOGV("uart", "Reactive Power Last Hour: %d", obis_value); reactive_energy_sensor->publish_state(obis_value); } else { ESP_LOGV("uart", "Unknown OBIS %s, value: %d", obis_code, obis_value); } } //strncat(uart_message, " ", 1); } ESP_LOGV("uart", "%d length received", uart_counter); //ESP_LOGI("uart", "%d length received: %s", uart_counter, uart_message); ESP_LOGV("uart", "Message length: %d", uart_message[3]); uart_counter = 0; uart_message[0] = '\0'; strcpy(uart_message, ""); } else { uart_counter = 0; } } uart_buffer_[uart_counter] = temp_byte; uart_counter++; } return false; } };  
    • Av Robin Smidsrød
      Hei alle sammen!
       
      Etter at jeg har lest gjennom en del poster på forumet her rundt lesing/dekoding av data fra AMS HAN-porten har jeg begynt å lure på hvor sensitiv målepunkt-ID-en er. Hvis man kobler den sammen med navn på abonnent og adresse er det sannsynligvis relativt sensitivt, men hvis den står alene i en binærdump, hvor mye skade kan en ondsinnet person gjøre hvis de har kjennskap til en målepunkt-ID?
       
      Grunnen til at jeg spør er fordi jeg har laget en dekoder[1], og jeg tenkte at det kunne være nyttig å legge ved eksempler på dump-filer fra forskjellige målere. Men hvis kjennskap til målepunkt-ID kan brukes til noe (f.eks. bestille eller avslutte tjenester som koster penger) uten å kjenne navnet på abonnenten tenker jeg at de ikke burde gjøres tilgjengelig på internett.
       
      Jeg leste et eller annet sted at NVE sammenligner målepunkt-ID med personnummer, og skatteetaten sier at personnummer ikke er sensitivt, men det er personopplysninger. Folk flest gir ikke fra seg personnummeret sitt til hvem som helst som spør om det, selv om skatteetaten sier som over.
       
      Jeg vet at målepunkt-ID består av landskode, kraftverk-ID, løpenummer og kontrollsiffer, som i seg selv ikke kan identifisere brukeren direkte.
       
      Så i bunn og grunn, hvis man har en målepunkt-ID, hva kan man gjøre med den?
       
      1: https://github.com/robinsmidsrod/ams-han-decoder
    • Av Torbjørn
      Da har jeg fått installert det meste på en litt eldre raspberry.
      Koblet til USB-MBUS slave modul, følgt guiden jeg fant her til å sette opp influxdb, grafana og node-red.
      Når jeg kjører test_rx fila i han-port mappa får jeg dette:
      root@raspberrypi:/home/pi/src/han-port# ./test_rx num args: 1 read serial: 1 read socket: 0 read file: 0 write file: 1 serial_device: /dev/ttyUSB0 fname: empty key: host: undefined port num: 10001 decrypt: 0 open_serial OK: 4 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 c8 02 02 0f 00 16 1b e8 a5 7e Date Time: , Items: 0 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 c8 02 02 0f 00 16 1b e8 a5 7e Date Time: , Items: 0 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 cc 02 02 0f 00 16 1b 9e ca 7e Date Time: , Items: 0 Leste i en annen trår her at på Aidon måler fungerer et python script til å gjøre samme jobb.
      Men her fikk jeg ikke helt rette verdier tror jeg:
      ./aidon_test.py /dev/ttyUSB0 {'p_act_in': 1046} {'p_act_in': 1036} {'p_act_in': 1032} {'p_act_in': 1032} {'p_act_in': 1052} {'p_act_in': 1040} {'p_act_in': 1040} {'p_act_in': 1050} {'p_act_in': 1050} {'p_act_in': 1066} {'p_act_in': 1076} {'p_act_in': 1052} {'p_act_in': 1052} {'p_act_in': 1062} I node-red står det bare å blinker "connecting" under alle AMS boksene.
       
       
      Noen som har fått til Aidon målerene som Lyse bruker, som kan hjelpe litt?
    • Av roy
      Jeg har en Kamstrup AMS fra Norgesnett med åpen HAN-port. For å lese disse DLMS OBIS datapush-meldingene har jeg en USB-til-MBUS-slave-modul koblet til en Raspberry Pi. Jeg skrev noen få linjer med Python for å skrive ut meldingene som kommer, og dette ser i utgangspunktet ut til å fungere stabilt og som forventet.
       
      Det jeg lurer på er om noen kan hjelpe meg å tyde/forklare meldingene til meg, fordi de later til å være mye kortere (145-160 bytes) enn det jeg har sett eksempler på her på forumene. Etter å ha lest hundrevis av meldinger og side opp og side ned her inne + lest kode og eksempeldata på spesielt https://github.com/roarfred/AmsToMqttBridge/ så skjønner jeg bare ikke hva det er med meldingene jeg får.
       
      Meldingene kommer hvert 10. sekund som forventet, og hver time kommer det en bittelitt lenger melding (den også mye kortere enn forventet). Det er som om OBIS-kodene ikke er med i meldingene.
       
      Start og slutt med byten E7 er alltid til stede og CRC for hvertfall header har stemt de gangene jeg har sjekket den.
       
      Her er eksempler på noen meldinger jeg får:
      2019-01-20T21:50:11.195980 - 155 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFBFE06C006E006F089C7FE74080600F80906F13AC60600FC4A6414DF100600FC89C7FE12C0BD4250B8FF3BE61200EB090601E1901200EB11CB7E 2019-01-20T21:50:21.194220 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126D18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFFFF06C006E006F00906F17408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FCFF12C02FC8505807FC1200EC090601F1D81200EE88D47E 2019-01-20T21:50:31.194745 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126F4800080FBB6FE682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017EF10A1236383431313331424E323433313031303430090681F9FF0680FF06C006E006F00906C1FF7408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FC12C02FC8505CFF07FC1200EC090601F1D81200EE13D47E 2019-01-20T21:50:41.189758 - 156 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A58000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FF96C828FF06C0FF06E006F089C7FE74080600F80906F13AC40600FC4A6414DF100600FCFF12C02FC85058FF3BE61200EC090601F1D81200EB3DC07E Hvis jeg tar f.eks. den siste meldingen over og bruker mye av kunnskapen fra https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/readme.md og https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md så tolker jeg det som noe slikt som under. Jeg har brukt linjeskift ved de typiske separatorene bare for å prøve å finne mønster, men det vil nok ofte være helt feil ettersom jeg ofte ikke får ting til å stemme med "02 - one byte following 06 - long (4 bytes / 32 bits) 12 - int (2 bytes / 16 bit) 09 - string, first byte is length (could it be a byte array?) 0A - string, first byte is length" uansett.
       
      7E <-- Frame Start flag A <-- 4 bits, A = Frame Format Type 3 0E2 <-- 12 bits, Frame size: 0xE2 (226 bytes!?, excluding start/end flags) 2B <-- Destination Address 21 <-- Source Address 13 <-- Control Field 239A <-- Gyldig CRC-16/X-25 E6 <-- Destination LSAP E7 <-- Source LSAP 00 <-- LLC Quality 0F <-- Information, n*8 bits? 0000F8BF60D95 <-- Hva er dette? Ofte(?) likt 09 12 6A58000F0FF682A566B1797AE17AE650582828A4A641428FE 0A 1135372036353627323132343834373536 <-- Gyldig målernummer i ASCII (NB: jeg endret noen sifre her, så evt påfølgende checksum vil feile) 09 06 01017CF1 <-- Hva er dette? Alltid likt 0A 12 36383431313331424E323433313031303430 <-- Alltid likt = ASCII 6841131BN243101040 <-- 684113 = måler-type 09 06 81F9FF 06 80FF96C828FF 06 C0FF 06 E0 06 F089C7FE7408 06 00F897C8287E 09 06 F13AC4 06 00FC4A6414DF10 06 00FCFF 12 C02FC85058FF3BE6 12 00EC <-- 236 (Volt? (L2?)) 09 06 01F1D8 <-- Hva er dette? 12 00EB <-- 235 (Volt? (L3?)) 3DC0 <-- Checksum? 7E <-- Frame End flag  
      Oppsettet for avlesingen er slik jeg hadde forventet det å være:
      ser = serial.Serial( port='/dev/ttyUSB0', baudrate=2400, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, bytesize=serial.EIGHTBITS, timeout=10)  
      Håper noen har noen tips eller innspill til meldingene. 🙂
       
    • Av aleks
      Usikker på hvor overrasket jeg er? Til Hafslund:
       
       
×
×
  • Opprett ny...