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

roarfred · 5. mars 2018

0x0A er nok riktig. Dette angir tekst, og neste byte skal angi lengde. Kan det være noe annet som har vært feil her siden flere ting plutselig falt på plass?

Endringen hos xibriz var utelukkende fjerning av denne 0x09 på datoen, og crc stemte både før og etter...

cpu22 · 5. mars 2018

50 minutes ago, roarfred said:

0x0A er nok riktig. Dette angir tekst, og neste byte skal angi lengde. Kan det være noe annet som har vært feil her siden flere ting plutselig falt på plass?

Endringen hos xibriz var utelukkende fjerning av denne 0x09 på datoen, og crc stemte både før og etter...

Ja, det ser ut som mange ting falt på plass nå. Fjerningen av 0x09 foran tidskoden og endringen av stringene fra 0xd til 0xa gjorde at boken (Kamstrup HAN-NVE interface description rev 3.0) stemmer bedre. De dubliserte 0xff ene ble borte og det er slutt på at det manglet en byte innimellom. Og når CRC-koden stemmer, er det mulig å verifisere at jeg får feilfrie data. Det er jo lettvint å skylde på firmware-oppgradering (spesielt siden jeg ikke har endret noe i mellomtiden), men jeg skal ikke utelukke at det kan ha vært noe feil her.

Nå er det faktisk CRC-feil innimellom, og det er egenlig litt rart med 2400 baud, og 3-4 meter kabel. Ofte i to påfølgende sendinger. Jeg er fristet til å skylde på Kamstrup igjen.

xibriz · 6. mars 2018

Prøvde noen skudd i blinde i går, men det ga ikke noen resultater. Det var alt for kaldt i garasjen til å stå å debugge

Thomas_ja27 · 6. mars 2018

Er det noen som har fått til å kjøre dette i OSX? Har Indigo Domo på denne og har koblet opp Kaifamåleren med en MBus til USB.

Så har et håp om å få dette inn i Indigo, men jeg er ikke noe god på programmering.

Får ut noe kryptisk om jeg kjører "screen /dev/tty.usbserial 2400" i terminal:

��~~�'Z��@ ��4~~�y��@ �
KFM_001 6970631403607026 MA304H3Ekp$. I P�w~~�'Z��@ ��e�~~�'KFM_001 6970631403607026��\R~~MA304H3EOt#�-��~~�y��@ G�� ND�~~�'Z��@ ��L@E~~�'Z�
��@ ��JKFM_001�6970631403607026��@ MA304H3EB{#A-<�@ ��
F N:�~~�'Z��@ ��D��~~�'Z��@

Det kommer hele tiden nye data inn her.

Har prøvd https://github.com/Apollon77/smartmeter-obis men denne gjenkjenner ikke dataene som kommer ut. Dette var skrevet for blant annet nederlandske Kaifa-målere, men de har ikke samme system som oss ser det ut for.

roarfred · 6. mars 2018

8 minutes ago, Thomas_ja27 said:

Får ut noe kryptisk

Dette ser ikke egentlig så kryptisk ut. Det du får er nok rådataene formatert som ASCII. Bare noen helt enkle elementer er virkelig ASCII, og disse ser du her som klar-tekst.

Hvis du får til noe kode som istedet får dette ut i et binærformat (type hex), så vil du kunne finne enkelt fram til effektforbruk, spenninger o.l.

Her er to sider hvordan dataene fra Kaifa måleren kan knekkes opp: (den første inkluderer start og slutt, den andre bare informasjons-delen)

- https://github.com/roarfred/AmsToMqttBridge/tree/master/Samples/Kaifa

- https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kaifa/obisdata.md

roarfred · 6. mars 2018

15 hours ago, xibriz said:

Prøvde noen skudd i blinde i går, men det ga ikke noen resultater. Det var alt for kaldt i garasjen til å stå å debugge

Jeg har prøvd å studere dette fenomenet litt. Dette er det jeg har funnet så langt:

Det finnes en software på GitHub som vi har såvidt vært innom tidligere, og denne kan kjøres opp i test-modus for push meldinger: https://github.com/Gurux/Gurux.DLMS.Net
Eksempel for test-kjøring er det som ligger under folderen Gurux.DLMS.Push.Listener.Example.Net
Per default er denne testen satt opp med InterfaceType.WRAPPER. Ved å endre dette til InterfaceType.HDLC kan en motta slike 7E ... 7E meldinger som måleren vår sender (må også fikse noe adressering, men det ser en av feilmeldinger)
Prøver en så å sende inn Kamstrup-data, så stopper den fordi E6 ikke er gjenkjent som en kommando. Problemet her er at kommandoen i pakken er 0F. Det ligger tre bytes i Kamstrup (og Kaifa) sine data som denne softwaren ikke kjenner igjen. Disse er E6 E7 00. Ved å debugge litt og manuelt overstyre er det mulig å skippe disse tre bytes. Gjør en det vil faktisk hele Kamstrup pakken leses fint inn.
Ser jeg nærmere etter hva som skjer etter at 0F kommandoen blir funnet, så forventes det å hoppe over 4 bytes (00 00 00 00) og så lese inn lengden på et informasjonsfelt (0C = 12 bytes). I koden fra Gurux leses disse tvert inn i et datoformat, uten noe mer sjekk. (Se funksjonen HandleDataNotification i GXDLMS.cs)
Så, prøver jeg å gjøre det samme med Kaifa dataene fra min måler, så feiler dette når denne timestamp blir forsøkt lest
Er jeg kreativ og endrer Kaifa data og fjerner 09 fra denne timestamp, så fungerer det også (må da oppdatere størrelse og rekalkulere checksum for header og pakke)
Så, dette er jo en viss indikasjon på at dette skal være slik (dvs. ingen 09 byte i timestamp), men det er også litt urovekkende at ikke Gurux klarer å lese pakken uten å hoppe over denne E6 E7 00.

Sekvensen jeg måtte ta bort er beskrevet som Destination LSAP, Source LSAP og LLC. Kapittel 8.3.2, Fig 19 i den grønne boken beskriver dette, men jeg blir ikke så veldig klok av det. Jeg har heller ikke den komplette boken, bare denne extract-versjonen, hvor det plutselig står "for more details see the complete Green Book".

Beklager alle detaljene her, jeg måtte bare få ting notert. Godt mulig løsningen er å ha noen ekstra settinger per målertype som kan hjelpe oss å navigere til riktig sted på riktig måte...

Odd · 7. mars 2018

@roarfred Jeg er litt bekymret fordi de forskjellige leverandørene kommer opp med forskjellig tolkning av standarden.
Når de ikke klarer å forenes om en standard, hvordan blir det hvis de i tillegg skal lage en kryptert løsning.

roarfred · 7. mars 2018

Fikk svar fra Kamstrup på en forespørsel dit:

Quote

Det er korrekt at der er foretaget en mindre ændring i protokollen mellem to måler FW revisioner. Se også vedhæftet revisionsdokument - Der er fjernet en byte i Headeren. Den ekstra byte var efter mine oplysninger ikke i henhold til DLMS specifikationen og derfor er den fjernet. Vi forventer at alle vores kunder i Norge på sigt vil opdatere deres målere til at understøtte det nye format for data-headeren.

Det er svært lige nu at sige hvordan vi kan håndtere dette bedst muligt i fremtiden. NVE har, hvad jeg har hørt, forslået en mulig løsning hvor de forskellige AMS-måler leverandører i Norge kan gøre deres opdaterede protokol-beskrivelse tilgængelige, men jeg kender ikke aktuel status på dette. Jeg forventer dog bestemt ikke flere ændringer i den nuværende data-protokol.

Dokumentet som refereres til er v3.1 av det vi tidligere hadde som v3.0. Dette er lastet opp på github

Har også sendt forespørsel til NVE og NTE om hvordan vi kan holde oss oppdatert på slike endringer, og om Kaifa nå kommer med samme endring.

Lurer litt på å kjøpe en utgave av NEK IEC 62056-7-5:2016, men er ikke 100% sikker på om den dekker alle detaljer. Noen som har tilgang til denne, evt. et abbonement hos standard.no?

Edit: fikset versjonsnummer på dok

Endret 7. mars 2018 av roarfred

roarfred · 7. mars 2018

NTE svarte kjapt og vil ta dette videre til Kaifa. De har ikke bekreftet at noe er feil, og viser til at Kaifa har et sterkt DSML miljø. Vi får da se...
I mellomtiden har jeg fikset litt på Arduino-koden og lagt ut på github.

Setter pris på om du har lyst til å teste fixen hos deg @xibriz

For å styre forskjellen på Kaifa og Kamstrup har jeg innført en property som kan settes til true: (da for Kaifa måler, hvor jeg anser dette for å være en bug)

hanReader.compensateFor09HeaderBug = true;

Begge eksemplene, KaifaTest og KamstrupTest er oppdatert. Gjenstår fortsatt å oppdatere ting under examples folder i biblioteket

Endret 7. mars 2018 av roarfred

xibriz · 8. mars 2018

Supert Får ikke testet det før i morgen kveld.

xibriz · 9. mars 2018

Da har jeg gode å dårlige nyheter @roarfred

Koden parser dataene fra måleren min riktig

Men det er kun en gang koden klarer å lese inn hele datastrømmen fra måleren rett etter oppstart.

Resten av tiden blir innlesingen avbrutt av feilmeldingen "Soft WDT reset".

Noen treff på google peker på at det kan være for dårlig strømforsyning, men jeg bruker den jeg har brukt hele tiden i dette prosjektet (12v 2A), men jeg prøvde en kraftigere på 12v 3A uten noen forskjell.

Lurer på hva det kan være....

xibriz · 9. mars 2018

Sitat

WDT resets are caused by a hang or too long loop in the software.

Jeg kan prøve å fjerne noen mqtt publish å se om det hjelper.

Endret 9. mars 2018 av xibriz

cpu22 · 9. mars 2018

Det kan være flere gunner til at watchdog timeren (WDT) trigger, men den aller vanligste er at programmet kræsjer av en eller annen grunn slik at ting stopper opp. "Long loops" kan selvfølgelig være en årsak. Det kan være verdt å sjekke om det brukes noen blokkerende kall for å vente på f.eks. serie-linjen eller annen input.

Det er ikke like sannsynlig at du har for lite power supply, spesielt hvis ting har virket fint lenge. 12V 2A høres allerede nok ut, men uansett om du bruker 2A eller 3A, er det regulatoren til 3.3V som evt. begrenser strømmen til ESP8266.

Men som sagt, sjekk SW feil først. Adressering utenfor gyldig område, null-pekere, overskrivninger og slikt.

roarfred · 9. mars 2018

@cpu22 er nok inne på noe her, @xibriz Jeg mener WDT er utelukkende for å hindre heng, og om en prøver seg på sammenhengende kode innenfor loop som tar mer enn 2(?) sekunder, så vil den slå ut. Husker jeg riktig er det fordi vi kun har en kjerne og selve wifi delen krever litt ressurser for å holde forbindelsen i live. Det skal finnes et kall, tror det heter yield() som man kan legge inn her og der for å frigi ressurser til andre ting. I arduino bibliotekene til ESP8266 skal dette også ligge innebygget i sleep().

Jeg ville prøvd å fjerne deler av loop, inntil ting kjører stabilt, og deretter legge tilbake. Tidkrevende, men som regel fører det frem.

xibriz · 10. mars 2018

Det er litt merkelig fordi jeg fikk problemer med "orginalkoden" min, som var den jeg allitd har kjørt. Den eneste forskjellen er oppdateringen i HAN-biblioteket.

roarfred · 11. mars 2018

@xibriz, ligger den eksakte koden du kjører ute noe sted? Jeg kunne prøvd å simulere litt...

xibriz · 11. mars 2018

Her er den eksakte kopien @roarfred

Den trenger en overhaling med tanke på gjentagende kode, men har kjørt problemfritt siden november

/*
* Simple sketch to simulate reading data from a Kamstrup
* AMS Meter.
*
* Created 10. November 2017 by Ruben Andreassen
*/

#include <ESP8266WiFi.h>
#include <PubSubClient.h>

#include <HanReader.h>
#include <Kamstrup.h>

// The HAN Port reader
HanReader hanReader;

const char* device_name = "espams";
// WiFi and MQTT endpoints
const char* ssid     = "";
const char* password = "";
const char* mqtt_server = "192.168.1.125";
const char* mqtt_topic = "esp/ams";
const char* mqtt_topic_PackageTime = "esp/ams/packagetime";
const char* mqtt_topic_ListSize = "esp/ams/listsize";
const char* mqtt_topic_ListVersionIdentifier = "esp/ams/listversionidentifier";
const char* mqtt_topic_MeterID = "esp/ams/meterid";
const char* mqtt_topic_MeterType = "esp/ams/metertype";
const char* mqtt_topic_ActiveImportPower = "esp/ams/activeimportpower";
const char* mqtt_topic_ActiveExportPower = "esp/ams/activeExportpower";
const char* mqtt_topic_ReactiveImportPower = "esp/ams/reactiveimportpower";
const char* mqtt_topic_ReactiveExportPower = "esp/ams/reactiveexportpower";
const char* mqtt_topic_CurrentL1 = "esp/ams/currentl1";
const char* mqtt_topic_CurrentL2 = "esp/ams/currentl2";
const char* mqtt_topic_CurrentL3 = "esp/ams/currentl3";
const char* mqtt_topic_VoltageL1 = "esp/ams/voltagel1";
const char* mqtt_topic_VoltageL2 = "esp/ams/voltagel2";
const char* mqtt_topic_VoltageL3 = "esp/ams/voltagel3";
const char* mqtt_topic_MeterClock = "esp/ams/meterclock";
const char* mqtt_topic_CumulativeActiveImportEnergy = "esp/ams/cumulativeactiveimportenergy";
const char* mqtt_topic_CumulativeActiveExportEnergy = "esp/ams/cumulativeactiveexportenergy";
const char* mqtt_topic_CumulativeReactiveImportEnergy = "esp/ams/cumulativereactiveimportenergy";
const char* mqtt_topic_CumulativeReactiveExportEnergy = "esp/ams/cumulativereactiveexportenergy";

String last_PackageTime = "";
String last_ListVersionIdentifier = "";
String last_MeterID = "";
String last_MeterType = "";
String last_ActiveImportPower = "";
String last_ActiveExportPower = "";
String last_ReactiveImportPower = "";
String last_ReactiveExportPower = "";
String last_CurrentL1 = "";
String last_CurrentL2 = "";
String last_CurrentL3 = "";
String last_VoltageL1 = "";
String last_VoltageL2 = "";
String last_VoltageL3 = "";

WiFiClient espClient;
PubSubClient client(espClient);

void setup() {
  setupWiFi();
  setupMqtt();

	// initialize the HanReader
	// (passing no han port, as we are feeding data manually, but provide Serial for debugging)
  hanReader.setup(&Serial, 2400, SERIAL_8N1, &Serial);  
}

void setupMqtt()
{
  client.setServer(mqtt_server, 1883);
}

void setupWiFi()
{
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
  }
}

void loop() {
  loopMqtt();

	// Read one byte from the port, and see if we got a full package
	if (hanReader.read())
	{
		// Get the list identifier
		int listSize = hanReader.getListSize();
    
		// Only care for the ACtive Power Imported, which is found in the first list
		if (listSize == (int)Kamstrup::List1 || listSize == (int)Kamstrup::List2)
		{
      //Publish uptime to let the world know i'm alive
      client.publish(mqtt_topic, ((String)millis()).c_str());

      String current_ListVersionIdentifier = hanReader.getString((int)Kamstrup_List1::ListVersionIdentifier);
      if (current_ListVersionIdentifier != last_ListVersionIdentifier || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_ListVersionIdentifier, current_ListVersionIdentifier.c_str());
        last_ListVersionIdentifier = current_ListVersionIdentifier;
      }

      String current_MeterID = hanReader.getString((int)Kamstrup_List1::MeterID);
      if (current_MeterID != last_MeterID || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_MeterID, current_MeterID.c_str());
        last_MeterID = current_MeterID;
      }

      String current_MeterType = hanReader.getString((int)Kamstrup_List1::MeterType);
      if (current_MeterType != last_MeterType || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_MeterType, current_MeterType.c_str());
        last_MeterType = current_MeterType;
      }

      String current_PackageTime = ((String)hanReader.getPackageTime());
      if (current_PackageTime != last_PackageTime || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_PackageTime, current_PackageTime.c_str());
        last_PackageTime = current_PackageTime;
      }

      String current_ActiveImportPower = (String)hanReader.getInt((int)Kamstrup_List1::ActiveImportPower);
      if (current_ActiveImportPower != last_ActiveImportPower || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_ActiveImportPower, current_ActiveImportPower.c_str());
        last_ActiveImportPower = current_ActiveImportPower;
      }   

      String current_ActiveExportPower = (String)hanReader.getInt((int)Kamstrup_List1::ActiveExportPower);
      if (current_ActiveExportPower != last_ActiveExportPower || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_ActiveExportPower, current_ActiveExportPower.c_str());
        last_ActiveExportPower = current_ActiveExportPower;
      }   

      String current_ReactiveImportPower = (String)hanReader.getInt((int)Kamstrup_List1::ReactiveImportPower);
      if (current_ReactiveImportPower != last_ReactiveImportPower || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_ReactiveImportPower, current_ReactiveImportPower.c_str());
        last_ReactiveImportPower = current_ReactiveImportPower;
      }    

      String current_ReactiveExportPower = (String)hanReader.getInt((int)Kamstrup_List1::ReactiveExportPower);
      if (current_ReactiveExportPower != last_ReactiveExportPower || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_ReactiveExportPower, current_ReactiveExportPower.c_str());
        last_ReactiveExportPower = current_ReactiveExportPower;
      }    

      String current_CurrentL1 = (String)((float)hanReader.getInt((int)Kamstrup_List1::CurrentL1) / 100.0);
      if (current_CurrentL1 != last_CurrentL1 || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_CurrentL1, current_CurrentL1.c_str());
        last_CurrentL1 = current_CurrentL1;
      }
      
      String current_CurrentL2 = (String)((float)hanReader.getInt((int)Kamstrup_List1::CurrentL1) / 100.0);
      if (current_CurrentL2 != last_CurrentL2 || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_CurrentL2, current_CurrentL2.c_str());
        last_CurrentL2 = current_CurrentL2;
      }
      
      String current_CurrentL3 = (String)((float)hanReader.getInt((int)Kamstrup_List1::CurrentL3) / 100.0);
      if (current_CurrentL3 != last_CurrentL3 || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_CurrentL3, current_CurrentL3.c_str());
        last_CurrentL3 = current_CurrentL3;
      }
      
      String current_VoltageL1 = (String)(hanReader.getInt((int)Kamstrup_List1::VoltageL1));
      if (current_VoltageL1 != last_VoltageL1 || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_VoltageL1, current_VoltageL1.c_str());
        last_VoltageL1 = current_VoltageL1;
      }
      
      String current_VoltageL2 = (String)(hanReader.getInt((int)Kamstrup_List1::VoltageL2));
      if (current_VoltageL2 != last_VoltageL2 || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_VoltageL2, current_VoltageL2.c_str());
        last_VoltageL2 = current_VoltageL2;
      }
      
      String current_VoltageL3 = (String)(hanReader.getInt((int)Kamstrup_List1::VoltageL3));
      if (current_VoltageL3 != last_VoltageL3 || listSize == (int)Kamstrup::List2) {
        client.publish(mqtt_topic_VoltageL3, current_VoltageL3.c_str());
        last_VoltageL3 = current_VoltageL3;
      }

			if (listSize == (int)Kamstrup::List2)
			{
        client.publish(mqtt_topic_MeterClock, ((String)hanReader.getTime((int)Kamstrup_List2::MeterClock)).c_str());

        client.publish(mqtt_topic_CumulativeActiveImportEnergy, ((String)hanReader.getInt((int)Kamstrup_List2::CumulativeActiveImportEnergy)).c_str());
        
        client.publish(mqtt_topic_CumulativeActiveExportEnergy, ((String)hanReader.getInt((int)Kamstrup_List2::CumulativeActiveExportEnergy)).c_str());

        client.publish(mqtt_topic_CumulativeReactiveImportEnergy, ((String)hanReader.getInt((int)Kamstrup_List2::CumulativeReactiveImportEnergy)).c_str());

        client.publish(mqtt_topic_CumulativeReactiveExportEnergy, ((String)hanReader.getInt((int)Kamstrup_List2::CumulativeReactiveExportEnergy)).c_str());
			}

		}
	}
}


// Ensure the MQTT lirary gets some attention too
void loopMqtt()
{
  if (!client.connected()) {
    reconnectMqtt();
  }
  client.loop();
}

void reconnectMqtt() {
  // Loop until we're reconnected
  while (!client.connected()) {
    // Attempt to connect
    if (client.connect("ESP8266Client")) {
      // Once connected, publish an announcement...
      // client.publish("sensors", "hello world");
      // ... and resubscribe
      // client.subscribe("inTopic");
    }
    else {
      // Wait 5 seconds before retrying
      delay(5000);
    }
  }
}

cpu22 · 11. mars 2018

5 hours ago, xibriz said:

Her er den eksakte kopien @roarfred

Den trenger en overhaling med tanke på gjentagende kode, men har kjørt problemfritt siden november

Jøss, kjører du hele dekodingen i ESP8266? Selv tenkte jeg å sende de mottatte dataene (alle 228 bytene inkludert 0x7e i begge ender) rått på MQTT, og la abonnenten gjøre jobben med dekodingen. Abonnenten blir etter hvert openHAB, men jeg har ikke kommet til det ennå.

Jeg tenkte at det da blir lettere å endre koden senere dersom det blir endringer i protokollen, og også lettere å debugge når det meste av koden ikke kjører på ESP8266.

Men siden du kjørerer alt dette i ESP8266, har du sjekket at det er nok plass til både program, stack og heap. Kanskje du er på grensen, og derfor får problemer. En "long shot", kanskje.

roarfred · 11. mars 2018

6 hours ago, xibriz said:

Her er den eksakte kopien @roarfred

Takker! Ble ikke så mye tid i kveld, men mulig i morgen...

Sjekket litt nærmere på WDT, ser ut som den har en begrensning på 1 sek. Dvs. at du bare har 1 sek på deg til å komme gjennom en runde i loop, eller evt. gjøre noen manuelle kall til yield(). En stor forskjell hos deg (fra meg) er at du rapporterer inn hver verdi som separate MQTT meldinger. Mulig et skudd i blinde, men her er 14 / 19 meldinger som skal sendes, og da er en kanskje ikke så helt unaturlig at det kan gå litt tid på en av dem. I tillegg kommer reconnectMqtt.

Jeg ville prøvd to ting:

1) yield(); etter hver client.publish(...)

2) kanskje bare kommentere bort alle verdier, slik at det kun er uptime som publiseres på MQTT

xibriz · 12. mars 2018

Jeg har prøvd å kommentere bort alt bortsett fra en publish uten hell.

Skal prøve å patche om litt i kveld så jeg kan sitte inne å holde på, blir litt lettere da men jeg holder fortatt en finger på at feilen ligger i hanreader.cpp

LenothX90 · 12. mars 2018

Endelig, etter uker med fomling og gjerde-sitting, har jeg fått montert avlesning hos meg. Største bøygen har vært å vri hodet fra "høyspent" kabling til elektronikk-spenninger.

SMD-lodding er noe dritt, brant gjennom en del kort/komponenter, før det ble en kombinasjon av Huzzah med breadboard ttl-level shifter - denne skal loddes når kretskort kommer, kan da slenge på en DHT sensor for tavla også, før det kommer en 3d printet "pocket" å sette suliamitten i.

Brukte "simple-han-reader-to-mqtt" ino'en fra github, men blir nok å endre denne, siden kun power ligger i mqtt stringen.

Egentlig godt gjort for lille ESP'en å snakke gjennom tavla, da den nesten kan betegnes som et faraday-bur?

(fra blidet kan man lese at samkjøring/nattsenk ikke er optimal, vi venter på nye termostater. ( gamle termostater er veldig, veldig dumme idag ?)

xibriz · 12. mars 2018

Nå kan jeg faktisk ikke fjerne mer kode... ?

/*
* Simple sketch to simulate reading data from a Kamstrup
* AMS Meter.
*
* Created 12. March 2018 by Ruben Andreassen
*/


#include <HanReader.h>
#include <Kamstrup.h>

// The HAN Port reader
HanReader hanReader;

void setup() {
	// initialize the HanReader
	// (passing no han port, as we are feeding data manually, but provide Serial for debugging)
  hanReader.setup(&Serial, 2400, SERIAL_8N1, &Serial);  
}

void loop() {
	// Read one byte from the port, and see if we got a full package
	if (hanReader.read())
	{
		// Get the list identifier
		int listSize = hanReader.getListSize();
    
		// Only care for the ACtive Power Imported, which is found in the first list
		if (listSize == (int)Kamstrup::List1 || listSize == (int)Kamstrup::List2)
		{
      Serial.println(hanReader.getInt((int)Kamstrup_List1::ActiveImportPower));
		}
	}
}

xibriz · 12. mars 2018

Noen ganger går det igjennom:

xibriz · 12. mars 2018

Koblet ut debugPrint-funksjonen og da ser det stabilt ut... jeg er sikker på at jeg prøvde å sette debugPort til NULL tidligere uten at det funket... får forske litt til.

Det er deilig å sitte inne i 24 grader kontra ute i 5 minus Kanskje derfor jeg finner ut av ting her

roarfred · 12. mars 2018

16 minutes ago, xibriz said:

hanReader.setup(&Serial, 2400, SERIAL_8N1, &Serial);

Her er noe muffens... Vi kan ikke bruke Serial både til HAN og til debugging... Kan du endre dette, eks til:

hanReader.setup(&Serial, 2400, SERIAL_8N1, NULL);

Dette gir deg da ingen debug output. Hvis du vil ha debug, så bruk Serial1 som siste parameter. En liten ting da er at du må koble over FTDI sin RX til GPIO2 (som er fast TX for Serial1). Når jeg har testet har jeg gjort dette, og jeg har også kjørt Serial1 på 115200 baud.

(Slo meg da jeg så at debug-meldingen var ganske stor, og ser jo nå at den kan ta nesten ett sekund alene å skrive ut, på 2400 baud)

PS: Kan være lurt å bytte bort Serial i din egen kode også. Teoretisk skulle det kanskje funke å bruke TX og RX til ulike ting, men litt sånn at en må holde tungen i riktig munn...

Logg inn

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

Anbefalte innlegg

Mest aktive i denne tråden

Populære dager

Mest aktive i denne tråden

Populære dager

Populære innlegg

roarfred

roarfred

xibriz

Postede bilder

Bli med i samtalen

Lignende innhold

Viktig informasjon