Wärmezähler über optische M-Bus-Schnittstelle auslesen

[A.. P. (arnonym)]

Hallo zusammen,

ich habe in meiner Wohnung folgenden Wärmezähler der Firma Allmess GmbH 
(s. Bild). Dieser verfügt über eine optische Schnittstelle (M-Bus), die 
ich gerne verwenden würde, um darüber Daten über Verbrauch etc. 
auszulesen und weiterzuverarbeiten.

Ich habe mich im Netz und auch hier im Forum etwas schlau gemacht über 
diesen M-Bus und was ich bis jetzt verstanden habe, ist, dass die Geräte 
i.d.R. (immer?) über einen M-Bus-Master angesprochen werden. Der 
Standard EN60870-5 spezifiziert offensichtlich den Frame-Aufbau, das 
Format der Datenpakete und grundlegende Anwendungsfunktionen 
(Wikipedia).

Nun würde ich gerne zum einen wissen, ob ich meinem Wärmezähler einen 
M-Bus-Master vorgaukeln muss, um an seine Daten zu kommen und welche 
Spezifikationen für mich dabei relevant sind. Müsste ich mich also durch 
alle Teile des Standards durchwühlen oder baue ich über die optische 
Schnittstelle einfach eine serielle Kommunikation auf und tausche 
einfache Pakete mit dem Zähler aus und muss mich nur auf bestimmte Teile 
des Standards konzentrieren?

Ich habe hier im Forum bereits etwas von Pegelwandlung etc. gelesen, 
aber ich denke mal, dass ich damit nichts am Hut habe, da dies nur bei 
einer drahtgebundenen Kommunikation mit einem Master interessant ist.

Ich möchte also im einfachsten Fall eine IR-Diode an die Schnittstelle 
des Zählers hängen, seriell mit ihm kommunizieren und die Daten dann 
weiterverarbeiten.

Achja, interessieren würde mich natürlich noch, ob ich dabei auch etwas 
im Gerät zerstören könnte? Ich möchte keinesfalls irgendwas an dem Teil 
verändern, lediglich die Werte möchte ich gerne auslesen.

In die Standards kann ich leider im Moment nicht reinschauen, aber ich 
könnte nächste Woche in meiner Uni mal sehen, ob wir spezielle diesen 
Standard dort auch rumliegen haben.

Über Hilfe und sachdienliche Infos darüber bin ich sehr dankbar :)

Gurß

[Rufus Τ. F. (rufus)]

A.. P. schrieb:
> Nun würde ich gerne zum einen wissen, ob ich meinem Wärmezähler einen
> M-Bus-Master vorgaukeln muss, um an seine Daten zu kommen und welche
> Spezifikationen für mich dabei relevant sind. Müsste ich mich also durch
> alle Teile des Standards durchwühlen oder baue ich über die optische
> Schnittstelle einfach eine serielle Kommunikation auf und tausche
> einfache Pakete mit dem Zähler aus und muss mich nur auf bestimmte Teile
> des Standards konzentrieren?

Ein Gerät, das mit einem M-Bus-Gerät kommuniziert, ist ein M-Bus-Master. 
Das ergibt sich aus dem Prinzip, ist aber nicht weiter kompliziert.

Du musst nur über die serielle Schnittstelle dem Gerät mitteilen, daß es 
seine Daten senden soll. Dazu musst Du neben den eigentlichen 
Kommunikationsparametern (Baudrate, Parität, Stopbits) noch die 
Geräteadresse herausfinden.

Das geht, indem Du das Gerät mit der Adresse 254 (0xfe) ansprichst, es 
antwortet daraufhin mit seiner konfigurierten Adresse. Da Du keinen Bus 
im eigentlichen Sinne hast, sondern nur zwei Teilnehmer, kann es dabei 
auch nicht zu Kollisionen kommen.

Was der Master zu senden hat, ist recht einfach, die Geräteadresse und 
der Funktionscode für "liefere Deine Daten". Das Gerät (der Slave) 
antwortet dann mit einem Datentelegramm; passen nicht alle Daten in das 
Telegramm, wird im Telegramm signalisiert, daß noch weitere Telegramme 
verfügbar sind, die der Master separat anzufordern hat.

Aufwendiger wird es, das Telegramm zu decodieren, das der Slave sendet.

Aber dafür gibt es Sourcecode:

http://www.rscada.se/libmbus/

> In die Standards kann ich leider im Moment nicht reinschauen

Die findet man im Internet:

http://www.m-bus.com/

Das Dokument hier
http://www.m-bus.com/files/MBDOC48.PDF

genügt eigentlich schon, interessant sind für Dich die Informationen ab 
Seite 22. Die vorhergehenden Seiten beschreiben das elektrische 
Interface (das Du nicht nutzt) und nicht die optische Übertragung.

Wie die hardwaremäßig umzusetzen ist, entzieht sich meiner Kenntnis, da 
bist Du auf Dich selbst gestellt.

[A.. P. (arnonym)]

Super, danke dir schon mal für die Quellen! Werde diese mal durchlesen 
und hoffe, dass ich daraus bereits alles entnehmen kann, was ich 
benötige. Den Hardwareteil kriege ich schon auf die Reihe :)

Besten Gruß

[Markus (Gast)]

Keine Ahnung, ob das jetzt noch relevant ist, aber bei dem Thema MBus 
muss man immer ein wenig aufpassen:
Der eigentliche MBus, so wie er mal gedacht war, ist eine drahtgebundene 
Schnittstelle mit einer Mischung aus strom- und spannungsdefierter 
Übertragung. Das System ist sehr robust und wird so seit Jahrzehnten 
verwendet.
Aus diesem Standard hat sich dann auch der Wireless MBus entwickelt.
Die optische Schnittstelle der Wärmezähler gehört nicht zu dem 
MBus-Standard, verwendet aber gerne dessen Telegrammaufbau. Im Kern sind 
diese optischen Schnittstellen also lediglich UARTs über IR Dioden.
Wenn man also Baudrate, Byteformat und die Telegrammliste hat, ist der 
Rest wirklich einfache serielle Übertragung und erfordert keine tiefere 
Kenntnis den MBus.

Viel Erfolg und Grüße,
Markus

[Alexander S. (alexanders)]

Hallo,

ich würde gerne auch den gleichen Wärmemengenzähler auslesen. Habe mir 
dazu eine IR Schnittstelle mit 860nm gebaut. Bei den diversen 
Stromzählern (SML) funktioniert diese auch ohne Probleme.

Leider kann ich keine Kommunikation mit dem Wärmemengenzähler aufbauen.



Zum Übermitteln des 0xFE Bytes nutze ich Lorus in der Freeware Version.

Vielleicht ist ja schon jemand weiter und kann mir einen Tipp geben.

[oroettger (Gast)]

Hallo,

ich würde gerne einen ähnlichen Zähler mit gleicher Schnittstelle 
auslesen.

Es ist der Integral-V UltraLite Art.Nr.: 561423000706 mit Optische 
Schnittstelle EN 60870-5 / M-BUS Protokoll.
Wie bekomme ich über die optische Schnittstelle ein Signal auf M-Bus 
Zweidraht?

Ich finde dazu keine Hardware. Oder gibt es andere Möglichkeiten?

[Klaus R. (klara)]

oroettger schrieb:
> Ich finde dazu keine Hardware. Oder gibt es andere Möglichkeiten?

Eventuell hilft Dir unter wiki.volkszaehler.org ein IR-Schreib-Lesekopf 
mit dem ich eHZ Stromzähler auslese. Ich konnte seinerzeit den fertigen 
Kopf kaufen und mußte nicht selber basteln. Eigentlich müßte der 
M-Buszähler damit auch klar kommen.

https://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-rs232-ausgang

Du mußt jedoch auch die Software für das Ansteuern und Auslesen des 
M-Buszähler haben.

Alexander S. schrieb:
> Zum Übermitteln des 0xFE Bytes nutze ich Lorus in der Freeware Version.

https://www.m-bus.de/lorusfree.html

Diese Software hatte mir anfangs sehr geholfen.
mfg Klaus

[Alexander S. (alexanders)]

Klaus R. schrieb:
> Eventuell hilft Dir unter wiki.volkszaehler.org ein IR-Schreib-Lesekopf
> mit dem ich eHZ Stromzähler auslese. Ich konnte seinerzeit den fertigen
> Kopf kaufen und mußte nicht selber basteln. Eigentlich müßte der
> M-Buszähler damit auch klar kommen.

Kann ich so direkt nicht bestätigen. Ich habe mir einen Kopf selbst 
gebaut, mit SFH4554 als Sendediode (850nm statt 880nm) und SFH 309 als 
Empfänger. Dieser funktioniert einwandfrei mit jedem bisher getesteten 
Stromzähler aber leider nicht mit oben genanntem Wärmemengenzähler. Ich 
habe es mit verschiedener Software und auch Ansteuersequenzen getestet 
und kann mir folgende Dinge vorstellen:

Spezielle Ansteuerungssequenz
Reedkontakt der die optische Schnittstelle aktiviert

Der Sendekopf wurde selbst entwickelt um den Haltenasen am WMZ zu 
entsprechen. Das Layout / Schaltpläne veröffentliche ich gerne.

[Klaus R. (klara)]

Alexander S. schrieb:
> Der Sendekopf wurde selbst entwickelt um den Haltenasen am WMZ zu
> entsprechen. Das Layout / Schaltpläne veröffentliche ich gerne.

Würde mich interessieren.


Alexander S. schrieb:
> aber leider nicht mit oben genanntem Wärmemengenzähler. Ich
> habe es mit verschiedener Software und auch Ansteuersequenzen getestet
> und kann mir folgende Dinge vorstellen:
>
> Spezielle Ansteuerungssequenz
> Reedkontakt der die optische Schnittstelle aktiviert

Manche Hersteller sind da auskunftsfreudig.

mfg Klaus

[Alexander S. (alexanders)]

Hallo,

anbei die Dateien zum Lesekopf. Erstellt in KiCAD 5.0.

Bei dem Hersteller habe ich einmal angefragt, alternativ werde ich es 
noch mal mit der Initialisierungssequenz nach EN 62056-21 probieren.

[Klaus R. (klara)]

Alexander S. schrieb:
> Initialisierungssequenz nach EN 62056-21

Die Schaltung sieht wirklich gut aus. Den FT-Baustein kannte ich noch 
nicht. Ich habe immer den FT232RL verwendet.

Hast Du einen Link zur "Initialisierungssequenz nach EN 62056-21"?
Mal schauen was dahintersteckt. Die ganze M-Bus Programmierung war 
damals ziemlich aufwändig.
mfg klaus

[Alexander S. (alexanders)]

Klaus R. schrieb:
> Die Schaltung sieht wirklich gut aus. Den FT-Baustein kannte ich noch
> nicht. Ich habe immer den FT232RL verwendet.

Günstiger da z.B. ohne komplettes Handshakeinterface - außerdem war 
dieser gerade besser lieferbar.


Ich hätte die Norm, denke aber nicht das ich diese hier veröffentlichen 
darf.

Ich gebe es mal mit meinen eigenen Worten wieder:

Es gibt zwei Verfahren, die sich in der Dauer der Aufwachsequenz 
unterscheiden.

Bei dem langsameren Verfahren muss man einen String von Nullzeichen 
senden (0x00) mit einer Gesamtlänge zwischen 2,1 und 2.3 Sekunden. Es 
dürfen maximal 5 ms zwischen den Zeichen vergehen. Die Baudrate sollte 
bei 300 Baud liegen und es wird mit einem Startbit, sieben Datenbits 
einer geraden Parität und einem Stopbit gearbeitet. Nach dieser Sequenz 
soll das Auslesegerät 1,5 bis 1.7 Sekunden warten und dann die Request 
Message senden.

Eine solche Nachricht besteht auf folgernder Zeichenkombination 
"/?!CRLF"
Hier wurde eine Geräteadresse weggelassen (ansonsten zwischen ? und !), 
es sollte jedes Gerät antworten. CR/LF stehen für Carriage Return (0x0A) 
und Line Feed (0x0D).

Danach sollte das Gerät mit seinem Identifier antworten und eine 
Kommunikation kann beginnen.

Alternativ gibt es die schnellere Wakeupsequenz

Hier werden Blöcke mit Aufwachsequenzen verschickt und nach jedem Block 
auf eine Reaktion vom Gerät gewartet.
Eine Sequenz besteht aus dem Übermitteln von Nullzeichen (0x00) für 0,5 
- 0,6 Sekunden. Danach muss die Übertragungszeit von zwei Zeichen + 20 - 
40 ms auf ein ACK (0x06) gewartet werden. Dieser Block einer 
Aufwachsequenz soll mindestens für 4,5 Sekunden gesendet werden. Falls 
das Gerät mit einem ACK antwortet, soll die Übertragung abgebrochen 
werden, dies kann auch schon während der Nullsequenz sein.

Nach dem ACK soll der Master 200 ms warten, um danach oben beschriebene 
Request Message zu senden. Nach 1500ms nach dem ACK legt sich das Gerät 
wieder schlafen.

In beiden Fällen soll die Wartezeit zwischen zwei erfolglosen Versuchen 
1,5 Sekunden betragen. Erfolglos ist meiner Meinung nach, wenn ein NACK 
(0x15) statt einem ACK geantwortet wird. In der Norm wird das als 
Übertragungsfehler beschrieben.

[Herbert K. (avr-herbi)]

Danke an Alexander !
Einfach mal google befragen mit "Aufwachsequenz mbus"
Manchmal reicht ja so ein Wink mit dem Zaunpfahl  :-)

[Klaus R. (klara)]

Danke an Alexander und Herbert,
ich muß mal gelegentlich meinen Source überprüfen. Vielleicht läßt sich 
noch etwas verbessern.
mfg Klaus

[geronet (Gast)]

Interessiere mich auch für die Auslesemöglichkeit des o.g. Wärmezählers 
(4 Stück).
Bei der Recherche bin ich auf das hier gestoßen, vielleicht hilfts:

http://www.sedelmaier.at/node/112

[Alexander S. (alexanders)]

Hallo,

ich bin etwas weiter gekommen. Die Kommunikation muss nach folgendem 
Muster erfolgen:

1. Übertragung von Muster 0/1 für 3 Sekunden (2400Baud, 8N1 ohne 
Parität) - realisiert durch das Senden von 0x55
2. Wartezeit von 234ms (10 Zeichen Wartezeit? - Eigentlich schreibt 
EN1434-3 330 Bitperioden + 50ms vor)
3. Umstellen der Übertragung auf 8N1 mit gerader Parität
4. Übertragen eines Mbus Telegramms (SND_UD) mit CI von 0xA6 (unbekannt) 
an die Geräteadresse 0xFE (Broadcast) (0x68 (Start) 
0x03(Nachrichtenlänge - L Field) 0x03(Nachrichtenlänge - L Field, 
erneut) 0x68 (Start) 0x53 (SND_UD) 0xFE (Broadcast Addr. mit Antwort) 
0xA6 (unbekannt) 0xF7 (Prüfsumme, richtig) 0x16 (End)
5. Prüfen auf Antwort (0xE5), falls keine Antwort 3s Wartezeit - dann 
erneut bei 1 beginnen - maximal drei Wiederholungen
6. Falls drei Wiederholungen ohne Antwort => Umstellen der Baudrate auf 
9600 Baud und erneut drei Versuche.


Leider funktioniert die Kommunikation nach obigem Schema bei mir nicht. 
Vielleicht kann jemand anders es einmal mit einem anderen Kopf 
probieren.

[Rufus Τ. F. (rufus)]

Alexander S. schrieb:
> Umstellen der Übertragung auf 8N1 mit gerader Parität

Ich würde das 8E1 nennen. Das "N" in 8N1 steht für kein Parity-Bit.

[Alexander S. (alexanders)]

Rufus Τ. F. schrieb:
> Ich würde das 8E1 nennen. Das "N" in 8N1 steht für kein Parity-Bit.

Wie gedankenlos von mir. Vielleicht kann ein Moderator den Beitrag 
#5872420 anpassen - mir ist das leider nicht mehr möglich.

[tnzs (Gast)]

M-Bus (also Zweidraht) und optische Schnittstelle sind zweierlei...
Die optische Schnittstelle arbeitet nach ZVIE und kommt aus dem 
Stromzählerbereich. Bei den Wärmezähler läuft darauf fast immer das 
M-Bus Protokoll.
Bei dem batteriebetriebenen Wärmezählern muss man die Schnittstelle 
erstmal aufwecken, weil die aus Energiespargründen immer aus ist. 1-2 
Sekunden 0x55 hinschicken. Dann mit 2400 8E1 ein SND_NKE oder ein 
REQ_UD2 Telegramm an Testadresse 254. Dann sollte was zurückommen (68 LL 
LL 68 usw).

Beim 62056/1107 Protokoll wird mit 300baud 7e1 angefragt und dann die 
Baudrate auf 2400/9600 gestell. Ja nachdem was der Zähler kann. Aber das 
ist eher notwenig bei den Stromzählern.

[tnzs (Gast)]

Nachtrag:
Manche Wärmezähler lassen sich nicht beliebig oft an der optischen 
Schnittstelle auslesen. Manchen lassen nur eine gewisse Anzahl an 
Kommunikatioen pro Tag zu, manche haben lustige Creditsystem und einige 
schalten ihre Schnittstelle zu bestimmten Zeiten (Nachts) komplett ab.

[geronet (Gast)]

Hab mir jetzt eine Prototyp-Schnittstelle zusammengebastelt nach dem 
Schema von falk hier:
Beitrag "Re: Smartmeter - MT681 - Fehler beim IR-Lesen"

Ist über einen Max232 und rs232-usb Wandler an den Rechner angeschlossen 
(Hackintosh).

Senden und Empfangen geht einwandfrei, wenn ich z.B. einen Spiegel 
davorhalte.
Auf dem Wärmezähler montiert (gleicher Typ wie im ersten Bild ganz oben) 
schicke ich per Terminal (2400 baud, 8E1) ca. 2 sek. 0x55 rein, danach 
mehrere 0xFF und gleich die Sequenz 10 40 FE 3E 16 hinterher (SND_NKE).

Ab und zu bekomme ich darauf tatsächlich die Antwort 0xE5 :-)
Schreib mir nun ein C-Programm, um das weiter auszutesten.

Gute Informationen gibt es hier auf Seite 4/5:

https://docuthek.kromschroeder.com/documents/download.php?lang=de&doc=29514

[Alexander S. (alexanders)]

Ich weiß nicht, ob es gewünscht ist, aber ich habe für meine Versuche 
folgenden Code zusammengebastelt, vielleicht hilft es ja.

#include <stdint.h>
#include <stdio.h>
#include <sys/types.h>
#include <errno.h>
#include <termios.h>
#include <unistd.h>
#include <string.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sys/select.h>
#include <unistd.h>
#include <signal.h>
#include <time.h>

static void sig_handler(int signo) {
  printf("Signal %d\r\n", signo);
}

int set_interface_attribs(int fd, int speed, int parity, int bits) {
  struct termios tty;
  memset(&tty, 0, sizeof tty);
  if (tcgetattr(fd, &tty) != 0) {
    printf("error %d from tcgetattr", errno);
    return -1;
  }

  cfsetospeed(&tty, speed);
  cfsetispeed(&tty, speed);

  tty.c_cflag &= ~CSIZE;
  tty.c_cflag &= ~CSTOPB;
  tty.c_cflag &= ~(PARENB | PARODD);
  tty.c_cflag |= (CLOCAL | CREAD);
  tty.c_cflag |= bits;
  tty.c_cflag |= parity;

  tty.c_iflag &= ~(IXON | IXOFF | IXANY);
  tty.c_iflag &= ~(ICANON | ECHO | ECHOE | ISIG);

  tty.c_oflag = 0;
  tty.c_lflag = 0;

  tty.c_cc[VMIN] = 0;
  tty.c_cc[VTIME] = 5;            // 0.5 seconds read timeout

  if (tcsetattr(fd, TCSANOW, &tty) != 0) {
    printf("error %d from tcsetattr", errno);
    return -1;
  }
  return 0;
}

void set_blocking(int fd, int should_block) {
  struct termios tty;
  memset(&tty, 0, sizeof tty);
  if (tcgetattr(fd, &tty) != 0) {
    printf("error %d from tggetattr", errno);
    return;
  }

  tty.c_cc[VMIN] = should_block ? 1 : 0;
  tty.c_cc[VTIME] = 5;            // 0.5 seconds read timeout

  if (tcsetattr(fd, TCSANOW, &tty) != 0)
    printf("error %d setting term attributes", errno);
}

char* read_data(int fd) {
  char* data = malloc(255);
  int maxfd = fd + 1;
  struct timeval timeout = { 1, 0 };
  fd_set readSet;
  FD_ZERO(&readSet);
  FD_SET(fd, &readSet);
  if (select(maxfd, &readSet, NULL, NULL, &timeout) > 0) {
    if (FD_ISSET(fd, &readSet)) {
      int n = read(fd, data, 255);
      if (n < 0) {
        printf("error %d on reading data from serial device", errno);
        return NULL;
      }
    }
  }
  return data;
}

int init_en_62056_slow(int fd) {
  // Anforderung:
  // 300 Baud 7N1 even parity
  size_t ret_out;
  char init_seq[614];
  char *buf;
  set_interface_attribs(fd, B300, PARENB, CS7);
  set_blocking(fd, 1);    // set blocking
  memset(init_seq, 0x00, sizeof(init_seq));
  struct timespec sleep_1_7s = { .tv_sec = 1, .tv_nsec = 700000000 };

  uint32_t transmission_len = 0;

  transmission_len = 69;

  ret_out = write(fd, init_seq, transmission_len);  // sent wakeup
  if (ret_out != transmission_len)
    return -1;
  tcdrain(fd);
  //Warten von 1,7s

  if (nanosleep(&sleep_1_7s, NULL) != 0)  // sleep enough to transmit plus
    printf("Error in nanosleep: %d\r\n", errno);

  sprintf(init_seq, "/?!\r\n");
  ret_out = write(fd, init_seq, strlen(init_seq));
  tcdrain(fd);
  buf = read_data(fd);
  if (buf == NULL) {
    return -1;
  } else if (buf[0] == '/') {
    printf("Recieved '/'");
  }
  return -1;
}

int init_en_62056_fast(int fd) {
  // Anforderung:
  // 2400 Baud 7N1 even parity
  size_t ret_out;
  char init_seq[147];
  char *buf;
  struct timespec sleep_48_3ms = { .tv_sec = 0, .tv_nsec = 48300000 };

  set_interface_attribs(fd, B2400, PARENB, CS7);
  set_blocking(fd, 1);    // set blocking
  for (uint8_t i = 0; i < 10; i++) {
    memset(init_seq, 0x00, sizeof(init_seq));
    uint32_t transmission_len = 0;
    transmission_len = 140;
    ret_out = write(fd, init_seq, transmission_len);  // sent wakeup
    if (ret_out != transmission_len)
      return -1;
    tcdrain(fd);
    //Warten von zwei Zeichen + 40 ms
    if (nanosleep(&sleep_48_3ms, NULL) != 0)  // sleep enough to transmit plus
      printf("Error in nanosleep: %d\r\n", errno);
    buf = read_data(fd);
    if (buf == NULL) {
      return -1;
    } else if (buf[0] == 0x06) {
      printf("Recieved ACK");
      return 0;
    }
  }
  return -1;
}

int init_en_13757(int fd, int speed) {
  // Anforderung:
  // 300 oder 2400 Baud 8N1
  size_t ret_out;
  char init_seq[614];
  char *buf;
  set_interface_attribs(fd, speed, 0, CS8);
  set_blocking(fd, 1);    // set blocking
  memset(init_seq, 0x00, sizeof(init_seq));
  uint32_t transmission_len = 0;
  if (speed == B2400) {
    transmission_len = 552;
  } else if (speed == B300) {
    transmission_len = 69;
  } else {
    return -1;
  }
  ret_out = write(fd, init_seq, transmission_len);  // sent wakeup
  if (ret_out != transmission_len)
    return -1;
  tcdrain(fd);
  //Warten von 330 Bitzeiten
  struct timespec sleep_138ms = { .tv_sec = 0, .tv_nsec = 138000000 };
  struct timespec sleep_1_1s = { .tv_sec = 1, .tv_nsec =  100000000 };
  if (speed == B2400) {
    if (nanosleep(&sleep_138ms, NULL) != 0)  // sleep enough to transmit plus
      printf("Error in nanosleep: %d\r\n", errno);
  } else if (speed == B300) {
    if (nanosleep(&sleep_1_1s, NULL) != 0)  // sleep enough to transmit plus
      printf("Error in nanosleep: %d\r\n", errno);
  } else {
    return -1;
  }

  char snd_nke = 0x40;
  ret_out = write(fd, &snd_nke, 1);  // sent snd_nke
  tcdrain(fd);
  buf = read_data(fd);
  if (buf == NULL) {
    return -1;
  } else if (buf[0] == 0xE5) {
    printf("Recieved ACKN");
  }
  return -1;
}
int main(int argc, char *argv[]) {
  const char *filename = "/dev/ttyUSB1";
  struct sigaction sa;
  sa.sa_handler = sig_handler;
  int i;
  for (i = 1; i <= 64; i++) {
    sigaction(i, &sa, NULL);
  }
  int fd = open(filename, O_RDWR| O_SYNC);
  tcflush(fd, TCIFLUSH); /* Discards old data in the rx buffer            */
  int ret = init_en_13757(fd, B2400);
  struct timespec sleep_2s = { .tv_sec = 2, .tv_nsec = 0 };
  if (ret == 0) {
    printf("Kommunikation erfolgreich, 13757 mit 2400 Baud");
    return 0;
  }
  nanosleep(&sleep_2s, NULL);
  ret = init_en_13757(fd, B300);
  if (ret == 0) {
    printf("Kommunikation erfolgreich, 13757 mit 300 Baud");
    return 0;
  }
  nanosleep(&sleep_2s, NULL);
  ret = init_en_62056_slow(fd);
  if (ret == 0) {
    printf("Kommunikation erfolgreich, 62056_slow mit 300 Baud");
    return 0;
  }
  nanosleep(&sleep_2s, NULL);
  ret = init_en_62056_fast(fd);
  if (ret == 0) {
    printf("Kommunikation erfolgreich, 62056_fast mit 2400 Baud");
    return 0;
  }
  printf("Keine erfolgreiche Kommunikation\r\n");

  return 0;
}

[F. F. (foldi)]

A.. P. schrieb:
> lediglich die Werte möchte ich gerne auslesen.

Wieso machst du dir das so kompliziert?
Meistens kann man direkt einen Zugang zu "den eigenen Werten" bekommen.
Schreibe doch die Firma an, die die Auswertung macht.

[Alexander S. (alexanders)]

F. F. schrieb:
> A.. P. schrieb:
>> lediglich die Werte möchte ich gerne auslesen.
>
> Wieso machst du dir das so kompliziert?
> Meistens kann man direkt einen Zugang zu "den eigenen Werten" bekommen.
> Schreibe doch die Firma an, die die Auswertung macht.

Zum Beispiel zur Integration in eine Visualisierung/Hausautomatisierung. 
Der dargestellte WMZ kann die Werte der letzten x Monate per Display 
anzeigen - zeitlich feiner aufgelöste Werte wird die auswertende Firma 
wohl auch nicht anbieten. In meinem Fall erfolgt die Ablesung privat, 
per Display. Eine Einbindung per Bussystem des Herstellers ist sehr 
kostenintensiv, teilweise für Privatpersonen auch nicht möglich.

[geronet (Gast)]

Die Wärmezähler mit MBus-Ausgang sind um einiges teurer. Für die 
größeren Wärmezähler gibt es Einsteckplatinen, aber die sind auch teuer 
und braucht man nur bei größeren Anlagen.

Ich hab durch Zufall und langes rumprobieren jetzt eine Antwort auf die 
Zeichenfolge
10 5B FE 59 16 bekommen:

684D4D68 08007217 42521192 2617040B 1400000C 78174252 11040618 A700000C 
14614728 003B2D99 99993B3B 9999990A 5A14020A 5E16020B 61250000 046D2600 
7C290227 330B09FD 0E0609FD

Das lässt mich hoffen, daß es also irgendwie zu gehen scheint, nur das 
genaue Timing ist warscheinlich wichtig. Auf meinem gebraucht gekauftem 
Zähler zum Testen steht:
(Baujahr 2011)
opt. Schnittstelle: M-Bus/EN60870-5 2. 2
Auf den anderen vier wo ich das dann einbauen will steht:
(Baujahr 2017)
opt. Schnittstelle: M-Bus/EN60870-5 4.2
und
(Baujahr 2016)
opt. Schnittstelle: M-Bus/EN60870-5 6.2

[geronet (Gast)]

Alexander S. schrieb:
> Ich weiß nicht, ob es gewünscht ist, aber ich habe für meine Versuche
> folgenden Code zusammengebastelt, vielleicht hilft es ja.

Da ist ein Fehler drin:

warning: comparison of constant 229 with expression of type 'char' is 
always false
      [-Wtautological-constant-out-of-range-compare]
    } else if (buf[0] == 0xE5) {

buf[] muss ein unsigned sein, damit das geht.

[Alexander S. (alexanders)]

geronet schrieb:
> Das lässt mich hoffen, daß es also irgendwie zu gehen scheint, nur das
> genaue Timing ist warscheinlich wichtig. Auf meinem gebraucht gekauftem
> Zähler zum Testen steht:
> (Baujahr 2011)
> opt. Schnittstelle: M-Bus/EN60870-5 2. 2
> Auf den anderen vier wo ich das dann einbauen will steht:
> (Baujahr 2017)
> opt. Schnittstelle: M-Bus/EN60870-5 4.2
> und
> (Baujahr 2016)
> opt. Schnittstelle: M-Bus/EN60870-5 6.2

Sind das alles kaloUltramax MK Zähler? Ich habe hier einen Integral-V 
UltraLite Pro und konnte ihn mit der von dir geschilderten Abfolge nicht 
zu einer Antwort bewegen. Ich habe mir die Norm mal angeschaut, konnte 
aber keine Zuordnung der 2.2, 4.2 oder 6.2 Nummerierung erkennen.

Vielleicht kannst du hier deinen Code veröffentlichen, damit es andere 
auch probieren können.

Ansonsten scheinst du ja die richtige Antwort zu bekommen, 684D4D68 
sieht doch sehr gut aus.

> warning: comparison of constant 229 with expression of type 'char' is
> always false

Uhh, manchmal sollte man -Wextra anmachen.

[geronet (Gast)]

Im Moment ist es noch gar kein Code, sondern nur 0x55 und die 
entsprechende Zeichenfolge im Terminal (CoolTerm).
Es klappt aber recht selten daß eine Antwort kommt, aber immerhin.
Der Zähler ist gebraucht, ist ein Integral MK-UltraMaXX. Die neueren 
(sind Integral-V UltraLite) kann ich nicht testen, die sind ca. 5 km 
weg.

[geronet (Gast)]

@Alexander S.: Hast du mal geprüft, was du wirklich sendest?
Zum Beispiel Spiegel hinhalten und schauen was zurückkommt. Ich hab dein 
Programm übernommen und abgeändert: Thread eingebaut zum Empfangen. Im 
Moment kommt aber nicht das zurück, was ich senden will.
Warum probierst du es eigentlich nicht mit 0x55 als Initialisierung?

[geronet (Gast)]

Noch was: Im Datenblatt steht:

2.2 ZVEI
Die optische ZVEI Schnittstelle arbeitet mit folgenden Parametern:
• Physical Layer: ZVEI mit MUX LED; reduzierten optische Kenndaten
• Kontaktaufnahme: nach EN601107
*• Scan-Frequenz 0,5Hz*
• 2400 Baud
• 8 Datenbits
• even Parity
• 1 Stopbit
• Link-Layer: M-Bus EN1434-3
• Application Layer: M-Bus EN1434-3

Hast du Zugriff auf die EN601107?
Die Scan-Frequenz ist wohl ein Hinweis darauf, daß der WMZ nur alle 2 
Sekunden nach der Schnittstelle schaut, deshalb soll man mind. 2.2 
Sekunden 0x55 senden.

[Alexander S. (alexanders)]

Ich habe mir das Ganze mit dem LA (Abgriff Sendediode) angeschaut und 
dort passt alles.

Warum ich genau 0x00 sende weiß ich nicht mehr - habe das aber auch mal 
probeweise in 0x55 abgeändert. Ich habe mir damals die Standards (also 
z.B. DIN-EN 62056-21 in Version 2003-01, Anhang B) angeschaut und dort 
ist das Protokoll so beschrieben.

[Alexander S. (alexanders)]

geronet schrieb:
> 2.2 ZVEI
> Die optische ZVEI Schnittstelle arbeitet mit folgenden Parametern:
> • Physical Layer: ZVEI mit MUX LED; reduzierten optische Kenndaten
> • Kontaktaufnahme: nach EN601107

Ich denke das ist ein Schreibfehler. Ich kann keine Norm unter diesem 
Namen finden. EN60107 ist "Meßverfahren für Empfänger von 
Fernseh-Rundfunksendungen" und EN60110 hat kein Kapitel 7 bzw. ist über 
"Leistungskondensatoren für induktive Erwärmungsanlagen. Beuth kennt 
diese Norm auch nicht.
"
> *• Scan-Frequenz 0,5Hz*
> • 2400 Baud
> • 8 Datenbits
> • even Parity
> • 1 Stopbit
> • Link-Layer: M-Bus EN1434-3
> • Application Layer: M-Bus EN1434-3
>
Dieser Ablauf entspricht IMHO dem von EN 13757-2. Nur das diese Norm 
eigentlich die kabelgebundene Schnittstelle beschreibt und somit nicht 
auf eine Aufwachsequenz eingeht.
In der EN 1434-3 im Anhang B findet man ein Ablaufbeispiel zur EN 
13757-2 mit Aufwachsequenz:
2,2 +-0,1s 0x55 senden oder auch > 330 Bitzeiten wobei danach zwischen 
33 und 330 Bitzeiten gewartet werden muss (bis zu nächsten 
Kommunikation)

[geronet (Gast)]

Man könnte sich auch einfach so ein Teil besorgen:
https://www.allmess.de/fileadmin/multimedia/alle_Dateien/DB/DB_P0409_EquaScan%20hMIU%20RF_TS0817.pdf
und dort die Sendediode untersuchen bzw. was "dazwischenschalten".. Hab 
ich irgendwo für 60 € gesehn.
Oder bei Itron direkt anfragen?

[geronet (Gast)]

Andere Frage: Könnte das auch eine IrDA Schnittstelle sein? Woran 
erkennt man das?

[Alexander S. (alexanders)]

geronet schrieb:
> Man könnte sich auch einfach so ein Teil besorgen:
> 
https://www.allmess.de/fileadmin/multimedia/alle_Dateien/DB/DB_P0409_EquaScan%20hMIU%20RF_TS0817.pdf
> und dort die Sendediode untersuchen bzw. was "dazwischenschalten".. Hab
> ich irgendwo für 60 € gesehn.
> Oder bei Itron direkt anfragen?

Ich habe mal Allmess angefragt und dort hat man mir eine Software zum 
Auslesen der Zähler gegeben. Wenn du mir per PM deine E-Mail zukommen 
lässt schicke ich dir den Link. Damit hat es aber auch nicht 
funktioniert, so langsam zweifle ich an meinen Dioden (die aber mit den 
Schnittstellen in Stromzählern gehen...).

Andere Frage: Könnte das auch eine IrDA Schnittstelle sein? Woran
erkennt man das?
Ich kenne die IrDA Schnittstellen immer nur mit 9600Baud.

[minifloat (Gast)]

Alexander S. schrieb:
> malloc(255);

geronet schrieb:
> Da ist ein Fehler drin [...]

Da ist ein klassisches Speicherleck drin! Malloc() ohne Free(), jedesmal 
wenn read_data bemüht wird.

mfg mf

[Johannes R. (jomone)]

Hallo zusammen,
ich dachte ich lasse das Thema wieder aufleben.
Ich versuche meinen Zenner Zelsius Wärmezähler mithilfe eines 
IR-Lesekopfs und einem Raspberry Pi auszulesen. Leider klappt es noch 
nicht. Bisher bin ich wie folgt vorgegangen.
Zunächst habe ich mir von Zenner die MSS Software runtergeladen und eine 
Demolizenz eingerichtet.
Für meinen IR-Lesekopf (CP2104) habe ich hier den Treiber für Win10 
gefunden 
https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
Dann habe ich die von Zenner angegebenen Einstellungen im Geräte-Manager 
eingegeben: 2400 8E1
In der Zenner Software (MSS) die Gruppe "Computer ports", Ableseart "USB 
port" mit entsprechendem Treiber, Gerätetyp
"C5 Standard", Profiltyp "IR ZVEI" ausgewählt und siehe da, der Zähler 
wurde ausgelesen.
WICHTIG: vorher muss man die Taste auf dem Zähler drücken, vermutlich um 
die Schnittstelle zu aktivieren.

Nun habe ich mit einem zweiten IR-Lesekopf den "output" der Zenner 
Software mitgeschnitten... das kam dabei raus

0000250: fe51 0f00 0000 06b7 1655 5555 5555 5555  .Q.......UUUUUUU
0000260: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000270: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000280: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000290: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002a0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002b0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002c0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002d0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002e0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002f0: 5568 0808 6853 fe51 0f00 0000 06b7 1655  Uh..hS.Q.......U
0000300: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000310: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000320: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000330: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000340: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000350: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000360: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000370: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000380: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000390: 5555 5555 5555 5568 0808 6853 fe51 0f00  UUUUUUUh..hS.Q..
00003a0: 0000 06b7 1655 5555 5555 5555 5555 5555  .....UUUUUUUUUUU
00003b0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00003c0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00003d0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00003e0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00003f0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000400: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000410: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000420: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000430: 5555 5555 5555 5555 5555 5555 5568 0808  UUUUUUUUUUUUUh..


...und weiter bin ich nicht.
wenn ich die entsprechenden parameter auf dem Raspberry Pi in minicom 
eingebe (2400 8E1) und den oberen Code eingebe passiert nichts.
Wenn ich mit der TV-Fernbedienung auf den IR-Kopf "schieße" bekomme ich 
in minicom einen Output. Von meinem Zähler jedoch nicht.

Kann mir jemand weiterhelfen?
Vielen Dank für eure Antworten!

[Alexander S. (alexanders)]

Johannes R. schrieb:
> Hallo zusammen,
Hallo,

>
> ...und weiter bin ich nicht.
> wenn ich die entsprechenden parameter auf dem Raspberry Pi in minicom
> eingebe (2400 8E1) und den oberen Code eingebe passiert nichts.

Welchen Code gibst du ein? Den Mitschnitt den du gepostet hast?

> Kann mir jemand weiterhelfen?

Das ist eine Anfrage:

5555 5555 5555  .Q.......UUUUUUU
0000260: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000270: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000280: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
0000290: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002a0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002b0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002c0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002d0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002e0: 5555 5555 5555 5555 5555 5555 5555 5555  UUUUUUUUUUUUUUUU
00002f0: 5568 0808 6853 fe51 0f00 0000 06b7 16

Beginnt mit der Aufwachsequenz 0x55 und dann folgt eine MBus Abfrage 
(Long Frame). Meistens wird die Aufwachsequenz mit 2400 8N1 gesendet, 
wichtig ist eine wechselnde 1/0 Folge mit einer Dauer von 2,1-2,2 
Sekunden.

Was bei der einfachen Wiedergabe der Aufzeichnung vermutlich verloren 
geht ist das Timing. Bei dem von mir genutzten Zähler ist z.B. nach der 
Aufwachsequenz eine Pause von 100ms und nach der ersten Anfrage muss der 
Zähler zwischen 11 und (330 + 50ms) Bitzeiten warten (ich glaube 
EN1434-3) bis er antwortet.

=> Mache eine erneute Aufnahme wo das Timing berücksichtigt wird 
(Achtung, oft sind Buffer, wie bei deinem silabs 576 Byte, im 
Übertragungsweg die jenes verfälschen) - oder probiere es mal mit den 
genannten Zeiten

[Johannes R. (jomone)]

Hallo Alexander,
vielen Dank für deine Antwort!
Ich hab die "Aufzeichnung" mit dem Programm minicom gemacht... leider 
weiß ich nicht, ob man dabei das Timing aufzeichnen kann.
Kennst du ein Programm, mit dem das geht?
Leider übersteigt die Thematik etwas meine Fähigkeiten.
Ist die Nachricht, die ich oben gepostet habe in HEX ??
Wie kann man das von dir beschriebene timting programmieren?

Danke für jeden Hinweis!

[Alexander S. (alexanders)]

Bei CuteCom wird ein Zeitstempel angezeigt, es gibt aber auch die 
Einschränkung mit den Buffern.

Ich nutze dafür einen Logikanalyser.

Die Nachricht die du geposted hast ist folgendermaßen aufgebaut:
Offset von Beginn, Datenzeile in Hex, Datenzeile in ASCII.

Ich kann dir keine Antwort auf die Frage wie du das Programmieren kannst 
geben. Dazu wäre erst einmal Interessant welche Programmiersprachen du 
kannst.

Du kannst dir ja mal das C Beispiel weiter oben anschauen. Dort wird 
probiert mit verschiedenen Protokollen den Zähler anzusprechen.
(Achtung!: Das Beispiel ist nicht für den produktiven Einsatz gedacht, 
siehe z.B. memory leak)

[Alexander S. (alexanders)]

Ich glaube du wirfst hier ein paar Zahlendarstellungen durcheinander. 
Minicom erwartet normalerweise ASCII Zeichen, das 55 ist aber wie schon 
genannte die HEX Spalte. Das 0x ist eine gängige Kennzeichnung das es 
sich um Hex handelt und nicht um z.B. Zahlen oder ASCII. Somit 
entspricht 0x55 dem ASCII Wert 'U' und dem Dezimalwert 85. Wenn du in 
Minicom nun eine 5 eingibst wird das nach ASCII Tabelle in 0x35 
gewandelt und dann als ein Byte übertragen. Somit findet hier schon eine 
komplett andere Übertragung statt.

Ich kann dir nur raten dich erst einmal mit den verschiedenen 
Zeichendarstellungen zu beschäftigen.

Ich kann mir nicht vorstellen das es möglich ist das Timing in Minicom 
zu erreichen. Wenn du Erfahrung in Python hast probiere doch mal darüber 
die erfassten Daten erneut über die serielle Schnittstelle auszusenden 
und lasse eine kurze Pause (ca.100ms) zwischen der Aufwachsequenz und 
der ersten Anfrage. Dann sollten du im Anschluss zumindest eine 
Bestätigung vom WMZ empfangen.

[Johannes R. (jomone)]

>Bei CuteCom wird ein Zeitstempel angezeigt, es gibt aber auch die >Einschränkung 
mit den Buffern.

Danke für den Tipp!
ich lade mir Linux Mint, damit ich CuteCom ausprobieren kann.

>Ich nutze dafür einen Logikanalyser

Das habe ich leider nicht.
Habe ich ohne einen Logikanalyser überhaupt eine Chance?

>Ich kann dir keine Antwort auf die Frage wie du das Programmieren kannst
>geben. Dazu wäre erst einmal Interessant welche Programmiersprachen du
>kannst.

Ich kann etwas python. Bisher habe ich kleine Programme zum Mitloggen 
von Temperaturdaten geschrieben.
Diese Maschinenkommunikation sind für mich aber böhmische Dörfer...

[Johannes R. (jomone)]

Jetzt habe ich die "Zenner Anfrage" nochmal mit CuteCom mitgeloggt.
Das Ergebnis in ASCII:

UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU 
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU 
UUUUUUUUh\0x08\0x08hS\0xfeQ\0x0f\0x00\0x00\0x00\0x06\0xb7\0x16UUUUUUUUUU 
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU 
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUh\ 
0x08\0x08hS\0xfeQ\0x0f\0x00\0x00\0x00\0x06\0xb7\0x16UUUUUUUUUUUUUUUUUUUU 
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU 
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUh\0x08\0x08h 
S\0xfeQ\0x0f\0x00\0x00\0x00\0x06\0xb7\0x16

über das timing weiß ich leider auch nicht mehr.

Ist es richtig, wenn ich jetzt die UUUUUUUUUU... Folge in cutecom zeile 
einfüge und mit enter abschicke??? Oder muss ich das auf jeden Fall mit 
einem Programm machen?

[Reinhard N. (Gast)]

Hallo,
da ich mich auch mit dem Thema beschäftige, wollte ich hier mal meine 
Erfahrungen berichten.
Ich versuche einen Engelmann SensoStar2 Wärmemengenzähler zu lesen. Dazu 
benutze ich den Optokopf aus dem Volkszähler Projekt. Nach vielen 
Versuchen habe ich einsehen müssen, dass sich dieser Zähler nicht mit 
einer optischen Sequenz aufwecken ließ. Nach vielen erfolglosen 
Versuchen habe ich die SW LorusFree (Link in einem der vorherige Posts) 
genutzt und die Sequenz mit einem Logikanalyser mitgelesen. Die SW hat 
auch die Funktion des optischen Aufwachens, das funktioniert mit diesem 
Typ Zähler aber nicht.
Man muss die Taste am Zähler drücken und dann den Auslesevorgang 
starten. Das Ergebnis häng ich als Screenshot an.
Nach dem Logikanalyser läuft folgende MBus Sequenz
Lorus sendet: 10 40 fe 3e 16     (das ist ein Broadcast=Adresse FE)
Zähler antwortet nach ca. 50ms mit 5E   (das ist ein ACK)
nach 50ms Lorus sendet: 10 7b fe 79 16  (das ist ein Request for Class2 
Data)
Zähler antwortet nach 50ms (hier mitgelesen mit CuteCom):
00000000    68 93 93 68 08 00 72   75 40 48 10 c5 14 00 04   .h..h␈
00000016 24 27 00 00 04 78 6b f9   9f 00 04 6d 11 0e 63 2b   $'
00000032 04 15 e0 20 00 00 44 15   e0 20 00 00 84 01 15 e0   ␄␕.
00000048 20 00 00 04 06 a0 21 00   00 44 06 a0 21 00 00 84
00000064 01 06 a0 21 00 00 84 10   06 00 00 00 00 c4 10 06   ␁␆.!
00000080 00 00 00 00 84 11 06 00   00 00 00 42 6c 5f 2c 02
00000096 6c 7f 2c 04 3b 00 00 00   00 14 3b 08 01 00 00 04   l.,␄;
00000112 2b 00 00 00 00 14 2b 39   24 00 00 02 5b 17 00 02   +
00000128 5f 17 00 04 61 24 00 00   00 02 23 81 0c 01 fd 17   _␗
00000144 00 04 90 28 0b 00 00 00   40 16
Die gesamte Übertragung läuft mit 2400 8E1

Nachdem ich das soweit im Griff hatte, habe ich es dann mit libmbus 
versucht und nach einigen Versuchen auch den korrekten Aufruf gefunden, 
hier mit Adresse 0, da auf einen Scan hier eine Antwort kam:
mbus-serial-scan -d -b 2400 /dev/ttyUSB0
Scanning primary addresses:
0 [2019-11-03 14:50:29] SEND (005): 10 40 00 40 16
[2019-11-03 14:50:29] RECV (001): E5

Found a M-Bus device at address 0
Die gesamte Ausgabe auf den Request häng ich als txt File an

Mein Plan ist, die Antwort soweit zu kürzen, dass ich den Zählerstand 
per LoRaWAN über TTN senden kann. Jetzt werd ich mich wohl mit dem 
Payloadformat auseinandersetzen müssen.

[Alexander S. (alexanders)]

Reinhard N. schrieb:

Das Funkmodul FAW (https://www.engelmann.de/de/funkaufsatzmodul-faw/) 
ist somit nicht mit deinem Zähler kompatibel? Zumindest scheint es 
diesem ja möglich zu sein unabhängig vom Knopfdruck auszulesen.

> Nachdem ich das soweit im Griff hatte, habe ich es dann mit libmbus
> versucht und nach einigen Versuchen auch den korrekten Aufruf gefunden,
> hier mit Adresse 0, da auf einen Scan hier eine Antwort kam:

Ich hatte mal wo gelesen, das viele WMZ mit Adresse 0 ausgeliefert 
werden.

> Mein Plan ist, die Antwort soweit zu kürzen, dass ich den Zählerstand
> per LoRaWAN über TTN senden kann. Jetzt werd ich mich wohl mit dem
> Payloadformat auseinandersetzen müssen.
Ich prüfe das XML gegen ein XSD File und versende die Daten dann per 
MQTT an eine Hausautomatisierung.

[Reinhard N. (Gast)]

Alexander S. schrieb:
> Das Funkmodul FAW (https://www.engelmann.de/de/funkaufsatzmodul-faw/)
> ist somit nicht mit deinem Zähler kompatibel? Zumindest scheint es
> diesem ja möglich zu sein unabhängig vom Knopfdruck auszulesen.

Das nicht, es gäbe aber ein anderes passendes Modul. Bin mir nur nicht 
sicher, ob das nachrüstbar ist. Da der Zähler aber beim Vermieter hängt 
und der den wenn überhaupt dann vom Fachmann einbauen lassen will, wird 
das teuer.

Alexander S. schrieb:
> Ich prüfe das XML gegen ein XSD File und versende die Daten dann per
> MQTT an eine Hausautomatisierung.

würde ich auch so machen, aber ich habe am Zähler kein WLAN, dehalb 
LoRaWAN. Gateway ist vorhanden. Aber erst muss ich das Thema mit dem 
Drücken des Tasters lösen. Vielleicht mit einem Servo.

[Reinhard N. (rn-cologne)]

Reinhard N. schrieb:
Aber erst muss ich das Thema mit dem
> Drücken des Tasters lösen. Vielleicht mit einem Servo.

check: drücken des Tasters gelöst

[Klaus R. (klara)]

Reinhard N. schrieb:
> check: drücken des Tasters gelöst

Woher hast Du denn die Schale für den Servo und das Meßgerät? 3-D 
Drucker?
mfg klaus

[Reinhard N. (rn-cologne)]

Klaus R. schrieb:
> Woher hast Du denn die Schale für den Servo und das Meßgerät? 3-D

Den Zähler hab ich gebraucht von eBay. Die Halterung des Servos kommt 
aus dem  3D-Drucker. Bei Interesse kann ich die STL zur Verfügung 
stellen. Ich konnte leider noch nicht testen, ob das auch bei dem Zähler 
passt, den ich eigentlich messen will.
Hier zusätzlich als Info: ich habe diese SW gefunden, davon werde ich 
einiges übernehmen können.
https://github.com/btm/emonMbus

[Stefan B. (stefan_b278)]

Ich hab mir optische Module zusammengebaut und erfolgreich getestet, die 
per RS-485 Bus mit 2 8P8C (RJ45) Steckern und normalen Netzwerkkabeln 
vernetzt werden können und auch die Stromversorgung darüber erhalten.

Die Module haben selbst keine Intelligenz sondern setzen den RS485 Bus 
direkt in Infrarotsignale zum WMZ um bzw. senden auf den Bus wenn sie 
etwas vom WMZ empfangen. Das funktioniert auch ohne Kollisionen wenn man 
die Zähler per primärer (vorher per Einzelanschluss zu vergeben) oder 
sekundärer Adressierung anspricht. Der MAX13487 macht das per 
AutoDirection möglich. Im Prinzip ist das wie ein drahtgebundener MBus, 
nur mit RS485 und vor der Zählerkommunikation muss man den/die Zähler 
mit 2400 Baud 8N1 2.2 Sekunden lang mit 0x55 aufwecken.

Die Gehäuse sitzen fest auf dem Wärmezähler nur mit den zwei Noppen, die 
genau in die Bohrungen im Gehäuse greifen.

Im Moment sind 4 Module und ein Zusatzmodul am Bus, das mir die 
TTL-UART-Signale mit einem MAX232 umwandelt und ein RS232-USB Stecker 
den Bus vom Rechner aus zugänglich macht. Ich baue mir aber noch ein 
Master-Gerät im Hutschienenformat das dann direkt die Daten täglich oder 
monatlich einsammelt und noch ein paar andere Funktionen hat (Gaszähler- 
und Wasserzählerimpulse, Stromzähler etc.)

[Stefan B. (stefan_b278)]

Jetzt hab ich die 4 Module installiert und per Bus verbunden. 
Funktioniert einwandfrei ;)
Muss noch das Ausleseprogramm ein bisschen erweitern damit das 
Mbus-Protokoll richtig interpretiert wird.

Beispiel für Ausgabe:

-------------------------------------------------
primary_address:  0x01
customer_number:  17540027
manufacturer:    ITR
generation:    23
medium:      4   = Wärme
reading_counter:  115
error_code:    0
signature:    0
fabrication_number:  17540027
energy:      5889 kWh
volume:      1187229 l
power:      0 W
flow:      0 l/h
supply_temp:    29.8 °C
return_temp:    22.0 °C
temp_difference:  7.85 K
date:      04.01.2020
time:      18:10:00
operating_time:    1031
firmware_version:  7
software_version:  17
alarm_code:    0
-------------------------------------------------

[LoxWinner (Gast)]

Hallo zusammen,

habe heute mal meinen Itron WMZ UltraMax aufgeschraubt und an der 
rechten Seite gibt es ein Steckmodul hinter der runden Plastikabdeckung 
mit 4 Leitern / Polen.
Hat jemand eine Ahnung, ob das auch die M-Bus-Schnittstelle ist, welches 
werkseitig dann in der M-Bus-Variante mit dem 1,2m langem Kabel 
ausgeliefert wird?
Und welcher Pol / Anschluss wie zu verdrahten ist?
Dann würde man sich den Umweg über die optische Schnittstelle sparen.
Gruß

[Jan S. (john85)]

Hallo,

ich hab den folgenden Wärmezähler:
allmess Integral-MK UltraMaXX

Wenn die optische Schnittstelle funktioniert wäre es mir ja egal ob 
darüber oder per Kabel.

@ LoxWinner:
Kann man das Teil ungeschadet öffnen und wieder zusammenbekommen, oder 
ist eine Öffnung nachher nachvollziehbar? Könntest du vlt. mal ein Foto 
im geöffneten Zustand hochladen?


Leider hab ich es bisher nicht geschafft dem Gerät eine Antwort zu 
entlocken.

Setup
- Infrarotdiode(unbekannt) und -transistor(SFH309FA-4) bisher auf 
Lochrasterplatine (Dioden je an einem Transistor) (Daten werden durch 
Spiegel korrekt ins Terminal zurückgegeben)
- Anordnung wo Sende-Diode und Empfangs-Transistor auf dem Integral-MK 
hin müssen hab ich mal aus Stefan seinen Bildern entnommen:
links (näher am roten Taster) ist laut deiner Platine die D1, also der 
Sender vom Interface)
rechts ist T1, also die Empfängertransistor
Oder?
Das sieht so schon echt top aus in dem Gehäuse mit LAN-Kabel!

Probiert hab ich
- per hterm (Win) oder moserial (Ubuntu)  Kommunikation herzustellen 
(wie hier mal angegeben 2.400 baud, 8N1)
- jmbus v 3.2.1 auf Ubuntu 18.04.3

./jmbus-app.sh scan -cp /dev/ttyUSB0  -bd 2400 -t 1000  -v

- libmbus http://www.rscada.se/libmbus/ auf Ubuntu Laptop per

mbus-serial-scan -d -b 2400 /dev/ttyUSB0

- LorusFree Version 2018 auf dem Win10 Laptop
(- Tasmota mit SML Bibliothek gebaut und auf Wemos D1 Mini
https://tasmota.github.io/docs/#/peripherals/Smart-Meter-Interface
da ist aber das „Smart Meter Interface Descriptor“ Script noch nicht so 
ganz fertig.
Zumal ich mir auch nicht ganz sicher bin, ob ich das Counterflag mit 
oder ohne Pullup eingestellt sein muss.

>D

>B
=>sensor53 r

>M 1
+1,3,m,1,2400,MODBUS,1,1
1,xxxx0503xxxxxxxxxxxxxxuu@1,Heizung,kWh,Warmwater,3     #--->  to do ...
#

)
- Hab mir jetzt ein Python Script geschrieben um genau die 2.2+-0.1 s 
lang  0x55 zu schicken. Laut Oszi passt das jetzt auch perfekt.
Werde mich wohl als nächstes doch mal mit dem M-BUS Telegrammen 
auseinandersetzten und diese in mein Script implementieren.
https://m-bus.de/telegramme.html bzw. das zur Unterstützung nehmen:
https://github.com/openenergymonitor/HeatpumpMonitor/blob/master/Firmware/Arduino/MBUS_Reader/mbus.ino

@ Stefan B. (stefan_b278)
Ich wäre wirklich froh, wenn Stefan uns seinen Code für die 
Kommunikation mit dem allmess Gerät zur Verfügung stellen würde, dann 
kann ich vlt. zumindest mal wissen ob es generell mit meinem Zähler und 
dem  provisorischen Interface funktioniert.
Komm mir langsam zu blöd vor!

Vielen Dank im Voraus!

Gruß,
Jan

[Stefan B. (stefan_b278)]

LoxWinner schrieb:
> Hallo zusammen,
>
> habe heute mal meinen Itron WMZ UltraMax aufgeschraubt und an der
> rechten Seite gibt es ein Steckmodul hinter der runden Plastikabdeckung
> mit 4 Leitern / Polen.
> Hat jemand eine Ahnung, ob das auch die M-Bus-Schnittstelle ist, welches
> werkseitig dann in der M-Bus-Variante mit dem 1,2m langem Kabel
> ausgeliefert wird?
> Und welcher Pol / Anschluss wie zu verdrahten ist?
> Dann würde man sich den Umweg über die optische Schnittstelle sparen.
> Gruß

Du meinst sicher den Stecker auf dem Foto links. Mit MBus hat das nichts 
zu tun, ich denke das wird der Programmierstecker sein um z.B. die 
Software draufzuladen und Kalibrierinformationen für die 2 Fühler zu 
übertragen.

Der Mbus-Chip wird wohl unten rechts aufgelötet, der Kabelanschluß ist 
jedenfalls schon vorhanden.

[Stefan B. (stefan_b278)]

Jan S. schrieb:
> Kann man das Teil ungeschadet öffnen und wieder zusammenbekommen, oder
> ist eine Öffnung nachher nachvollziehbar? Könntest du vlt. mal ein Foto
> im geöffneten Zustand hochladen?

Hinten sind nur zwei Schrauben durch rote Kappen (Plomben) verdeckt, 
eine Öffnung sieht man nur wenn man die Plomben rauspult.

Links muss deine Diode senden, rechts sitzt der Phototransistor.
Sieht man auch gut auf dem Bild, rechts ist die weiße Infrarotled vom 
WMZ.

Jan S. schrieb:
> Ich wäre wirklich froh, wenn Stefan uns seinen Code für die
> Kommunikation mit dem allmess Gerät zur Verfügung stellen würde, dann
> kann ich vlt. zumindest mal wissen ob es generell mit meinem Zähler und
> dem  provisorischen Interface funktioniert.
> Komm mir langsam zu blöd vor!

Kam ich mir auch vor, von 4 WMZ konnte ich einen nie auslesen, alle 
anderen funktionierten. Dann hab ich die 4 Module gebaut, und mit einem 
Modul funktionierte auch dieser. Den Grund hab ich bis jetzt noch nicht 
herausfinden können, es liegt aber nicht an der Positionierung der Leds. 
Vielleicht eine leicht andere Wellenlänge?

Meine Software hab ich mal drangehängt.
Ist ein C-Programm und kompiliert mit OSX und Linux.
Bei 1) muss ein E5 zurückkommen.
Bei 3) die kompletten Informationen vom WMZ.

[Jan S. (john85)]

Es funktioniert :-)
Vielen Dank dir!!

Da warst du ja mal richtig fleißig was die SW angeht!

Hab deine SW in Code::Blocks "gebuildet" und es lief direkt auf Ubuntu. 
Ich musste nur das vorzeitige Ende (return 0;) in der Zeile 579 
auskommentieren, damit ich bis zur While-Schleife mit den 
Abfragemöglichkeiten kam.

Hat dann auch direkt mit der ersten Aufwachsequenz funktioniert und mit 
3) kamen alle Daten:

-------------------------------------------------
primary_address:  0x00
customer_number:  18797981
manufacturer:    ITR
generation:    23
medium:      4   = Wärme
reading_counter:  14
error_code:    0
signature:    0
fabrication_number:  18797981
energy:      1985 kWh
volume:      194180 l
power:      7200 W
flow:      416 l/h
supply_temp:    51.7 °C
return_temp:    36.9 °C
temp_difference:  14.78 K
date:      12.01.2020
time:      08:56:00
operating_time:    436
firmware_version:  7
software_version:  17
alarm_code:    0
-------------------------------------------------

Ich bin begeistert!

Ich hatte erwartet, dass das Display durch die Aufwachsequenz angeht, 
aber das bleibt aus.

Meine HW war also definitiv okay, es lag an der SW.

Verblüffend ist, dass trotz aufwecken mit deiner SW direkt danach 
dennoch mit den anderen Programmen immer noch keine Kommunikation 
möglich ist.
Weder mit jmbus, libmbus oder Lorus erhalte ich irgend eine Antwort.
Dass die Programme irgendetwas senden sehe ich an der TX-LED meines 
IR-Interfaces, aber es kommt laut Terminal und RX-LED einfach überhaupt 
keine Reaktion vom Wärmemengenzähler.

Was auch immer du da gezaubert hast funktioniert auf jeden Fall mit 
meinem Zähler. :-)

[Stefan B. (stefan_b278)]

Jan S. schrieb:
> Ich musste nur das vorzeitige Ende (return 0;) in der Zeile 579
> auskommentieren, damit ich bis zur While-Schleife mit den
> Abfragemöglichkeiten kam.

Ja stimmt ich hatte da noch einen Testlauf drin, am besten alle Zeilen 
von 575-579 löschen.

Jan S. schrieb:
> Verblüffend ist, dass trotz aufwecken mit deiner SW direkt danach
> dennoch mit den anderen Programmen immer noch keine Kommunikation
> möglich ist.

Der Zähler bleibt meines Wissens nach nur ca. 3 Sek. aufgeweckt. Da wird 
dir die Zeit nicht reichen zum umschalten.

Die Software ist in Zusammenarbeit mit Alexander S. entstanden. Habe 
aber teilweise bei libmbus abgeschaut für die Auswertung.

[Sven K. (satirebird)]

Hat jemand Erfahrung mit den Wärmemengenzählern von Ista. Bei mir ist 
ein sensonic II verbaut. Die haben auch alle eine optische 
Schnittstelle.

https://www.ista.com/de/technik/waerme-und-kaeltezaehler/

Verwenden die das gleiche Protokoll?

[Stefan B. (stefan_b278)]

Warscheinlich schon. Ausprobieren!

[Sven K. (satirebird)]

Ich hatte mal wieder Zeit und habe mir einen gebrauchten Zähler besorgt. 
Leider habe ich es bis jetzt nicht geschafft dem Zähler auch nur 
ansatzweise eine Antwort zu entlocken. Ich habe das Tool vom Stefan 
verwendet und am Timing noch etwas modifiziert, da es bei mir noch nicht 
ganz gepasst hatte.

Ich habe alles mit einem Logic-Analyzer mitgeschnitten. Neben der TXD 
und der RXD Leitung habe ich auch die Batteriespannung mitgeschnitten. 
Man kann daran erkennen, wenn der Controller im Zähler aufwacht. Den 
Messzyklus alle 60s kann man schön erkennen.

Unterschiedliche längen der Aufwachsequenz, andere M-Bus Adressen und 
Timing-Varianten habe ich schon durchprobiert. Der Zähler bleibt einfach 
stumm.

Im Internet sind die Zulassungsdokumente zugänglich:

http://legnet.metas.ch/legnet2/Eichstellen/Eichstellen_Waerme/Zulassungen/thermische_energie/t2_waermezaehler_und_komponenten_nach_en_1434/741-750/T2-750/Pub-CH-T2-13750-00.PDF

Darin wird unter 2.3.1 geschrieben, dass die optische Schnittstelle auf 
der Norm EN 1434 basiert. Ich denke es sollte doch möglich sein, mit dem 
Zähler zu kommunizieren. Anscheinend gibt es auch Schnittstellen dafür: 
https://www.youtube.com/watch?v=rXap-SOFJmQ

Hat noch jemand eine Idee, wie man die optische Schnittstelle aktiviert 
bekommt? Hat jemand so einen Adapter zur Hand und könnte mal messen, was 
da gesendet wird?

[Stefan B. (stefan_b278)]

Werden die 0x55 mit 8N1 gesendet und die Init-Sequenz mit 8E1?
Schonmal mit 300 baud versucht?

https://www.ista.com/fileadmin/twt_customer/countries/content/Germany/Documents/Loesungen/Funk/M-Bus_System/Protokollbeschreibung_modul_mbus.pdf

Und probier mal die Init-Sequenz etwas später zu schicken, so nach ca. 
0,5s.

[Stefan B. (stefan_b278)]

Warum sind die Daten auf der TXD UND RXD Leitung sichtbar?

Eventuell kann auch die Positionierung der Leds wichtig sein. Hat der 
Deckel eine optische Linse eingebaut?
Ich hatte mir zum Testen eine Halterung gebaut, wo die Sendeled und 
Empfangsdiode direkt über denen vom WMZ liegt, um den Faktor 
auszuschließen.

[Sven K. (satirebird)]

Der Tipp mit den 300 Baud war gut. Ich habe die Init-Sequenz mit 300 
Baud gesendet und parallel die Batteriespannung aufgezeichnet. Im Bild 
kann man schön erkennen wie der Controller aus dem Schlaf aufwacht. Bei 
einigen Versuchen brauchte der Controller max. ca. 400ms um aufzuwachen.

Allerdings ließ hat der Controller nicht mit 300Baud auslesen. Anhand 
der Spannungseinbrüche hat man aber schön gesehen, dass der Controller 
alle 4.4ms etwas macht. Das ist genau eine Byte bei 2400Baud.

Die Aufwachsequenz muss also mit 300Baud für 0.5s gesendet werden. 
Danach kann praktisch ohne Verzögerung auf 2400Baud umgeschaltet werden 
und man kann die Daten senden. Im Bild sieht man wie die Antwort 
gesendet wird: 0xE5

Meine Fotodiode ist für die LED allerdings sehr unempfindlich. Ich nehme 
an, dass die Wellenlänge nicht passt. Das Digitalisieren geht so noch 
nicht. Ich muss man noch andere Fotodioden probieren.

> Warum sind die Daten auf der TXD UND RXD Leitung sichtbar?

Das liegt an den Reflexionen. Das ist praktisch nur das Echo. Die 
Reflexionen sind praktisch stärker als das Nutzsignal. Ich werde jetzt 
schauen, dass ich den Adapter optimieren kann.

[Stefan B. (stefan_b278)]

Cool, probiers mal mit 950 nm.

[Heinz R. (heijz)]

Alexander S. schrieb:
> Ich habe mal Allmess angefragt und dort hat man mir eine Software zum
> Auslesen der Zähler gegeben. Wenn du mir per PM deine E-Mail zukommen
> lässt schicke ich dir den Link. Damit hat es aber auch nicht
> funktioniert, so langsam zweifle ich an meinen Dioden (die aber mit den
> Schnittstellen in Stromzählern gehen...).

Hat zufällig jemand diese Software und könnte sie mir zur Verfügung 
stellen?

Die ALlmess-Seite ist wohl komplett nicht erreichbar?

Spiele auch gerade aus Langeweile mit WMZ herum - meine eigenen sind 
über M-Bus, das funktioniert

Würde es jetzt gerne über Opto-M-Bus hinbekommen, bislang spricht nur 
ein Sensus Pollucom mit der Original-Software mit mir
Lorusfree geht bei diesem von 10 Versuchen 1 x

Kocht da echt jeder Hersteller seine eigene Suppe?

Viele Grüße

Heinz

[Sven K. (satirebird)]

Ich habe in der Zwischenzeit den Opto-Adapter mechanisch fixiert und die 
LED mit etwas Schrumpfschlauch optisch abgeschirmt. Damit funktioniert 
die Kommunikation sehr gut. Ich nutze ein normales FTDI-Kabel (3.3V) für 
die Verbindung zum Rechner. Meine Schaltung habe ich angehängt. Die ist 
sehr einfach und schnell auf einer Lochrasterplatine aufgebaut.

Auf der Softwareseite habe ich mich an der libmbus probiert:
https://github.com/rscada/libmbus
Das ganze dekodieren übernimmt die Bibliothek. Das macht die Software 
schön einfach. Ich habe ein kleines Beispiel zusammengestellt um mit der 
libmbus die Ista-Zähler auszulesen. Dafür muss die libmbus vorher 
installiert sein.

git clone https://github.com/rscada/libmbus.git
cd libmbus
./build.sh
sudo make install

Dann einfach

unzip ista.zip
make
./ista

Der Beispielcode gibt die Messdaten in XML-Form wieder aus. Das ganze 
sollte auch mit anderen Zählern funktionieren, wenn man die 
Wakeup-Funktion entsprechend anpasst.

[Sven K. (satirebird)]

Heinz R. schrieb:
> Kocht da echt jeder Hersteller seine eigene Suppe?

Ich würde sagen jain. Ich habe zwar nur den einen Zähler von Ista hier 
aber den Berichten zufolge würde ich denken, das Problem sind die 
unterschiedlichen Aufwach-Sequenzen. Beim Ista-MWZ sind es 0x55 mit 
300Baud 8N1 für 0.5s. Wenn man auch nur ein bisschen davon abweicht geht 
es nicht mehr. Ich hatte mal mit 300Baud 8E1 getestet, was im Signal nur 
einen minimalen unterschied ausmacht. Aber es hat schon nicht mehr 100% 
funktioniert.
Bei den Allmess-MWZ muss wieder eine andere Aufwach-Sequenz verwendet 
werden. Das eigentlichen MBus-Protokoll ist dann standardisiert und 
sollte für jeden Zähler gleich sein.

[Heinz R. (heijz)]

Hallo Sven,

welcher Transistortyp ist Q1?

Ich habe zwar einen IR-Lesekopf hier, aber würde mal Deine Schaltung 
zusammen mit LEDs aus einem alten WMZ ausprobieren - vielleicht passt ja 
auch die Wellenlänge nicht

Du schreibst, Du hast die LED optisch abgeschirmt?  bei mir ist es bei 
allen WMZ so, das ich grundsätzlich das gesendete auch wieder empfange, 
wird wohl im Zählerinneren reflektiert
Ist das bei Dir auch so?

[Sven K. (satirebird)]

Heinz R. schrieb:
> Hallo Sven,
>
> welcher Transistortyp ist Q1?

Da sollte nahezu jeder beliebige NPN-Transistor funktionieren. Ich habe 
aus meiner Fundkisten einen BC237 genommen. Auch für den 2N7000 sollte 
eigentlich fast jeder NChannel-FET als Ersatz funktionieren. Diese hatte 
ich nur gerade da.

>
> Ich habe zwar einen IR-Lesekopf hier, aber würde mal Deine Schaltung
> zusammen mit LEDs aus einem alten WMZ ausprobieren - vielleicht passt ja
> auch die Wellenlänge nicht
>
> Du schreibst, Du hast die LED optisch abgeschirmt?  bei mir ist es bei
> allen WMZ so, das ich grundsätzlich das gesendete auch wieder empfange,
> wird wohl im Zählerinneren reflektiert
> Ist das bei Dir auch so?

Nein. Die Reflexionen solltest du irgendwie unterdrücken. Sonst bringt 
das zumindest die Software durcheinander. Ich habe die Sendediode mit 
einem Stück Schrumpfschlauch "optimiert". Siehe Bilder. Damit waren das 
Echo komplett verschwunden. Im Gehäuse sind dann Lichtleiter die bis 
direkt zur Empfangs-/Sendediode gehen.

[Stefan B. (stefan_b278)]

Hier gibt es den Schaltplan und Layout für die oben genannten 
"Busmodule":

Die Stecker sind 8p8c:
https://www.tme.eu/de/details/rjjs881401ejh136/rj-steckverbinder/encitech/rjjs-88-1401-ejh-136/

Gehäuse:
https://www.tme.eu/de/details/hm-1551gtbu/universal-gehause/hammond/1551gtbu/

Das Gehäuse muss man ziemlich ausfräsen, die Stege wegzwicken und die 
Löcher nach Plan durch den Boden bohren. Am besten erstmal kleiner damit 
das Gehäuse recht streng auf die Nippel vom WMZ passt, dann hält es von 
alleine.
Damit die Platine reinpasst und ganz am Boden aufliegt muss man auf der 
Lötseite die THT Überstände abschleifen.
Das könnte man bei der nächsten Version sicher verbessern, aber ich 
wollte kein größeres Gehäuse nehmen da man sonst entweder den WMZ nicht 
mehr ablesen kann oder das Teil übersteht.

[Matthias (Gast)]

Ich habe hier nen Engelmann Sensostar U, bei dem funktioniert das 
"mbus-test" Programm auch super. Das ista-tool geht auch, wenn ich 
vorher mit mbus-test die Init-Sequenz schicke und dann schnell bin :-)

Eine Sache ist mir aufgefallen:
Die Temperaturen im Display aber auch auf der Schnittstelle werden nur 
alle paar Minuten aktualisiert. Das ist schade :-( Laut Datenblatt 
wertet der Sensor sie aber alle 2 Sekunden aus - und ich habe das am 
Stromverbrauch auch nachvollzogen. Alle 2 Sekunden spiked er 2x kurz 
hintereinander (vermutlich 1x pro Temperatursensor).

Ich habe dem Wärmemengenzähler auch den "Netzteilbetrieb" vorgegaukelt, 
den erkennt er auch. Das macht allerdings keinen Unterschied :-(

Test mit der echten Mbus-Schnittstelle steht aus, allerdings erwarte ich 
da keinen Unterschied.

Das heißt ja im Endeffekt, dass der WMZ für die Schnittstelle extra 
"Register" haben muss, die er nicht ständig aktualisiert. Gibts da ein 
Kommando, um das zu erzwingen?

Aktualisieren eure häufiger die Temperatur?

[Sven K. (satirebird)]

Matthias schrieb:
> Das heißt ja im Endeffekt, dass der WMZ für die Schnittstelle extra
> "Register" haben muss, die er nicht ständig aktualisiert. Gibts da ein
> Kommando, um das zu erzwingen?

So etwas habe ich noch nicht gesehen.

>
> Aktualisieren eure häufiger die Temperatur?

Wenn ich mich richtig erinnere misst mein Ista-Zähler alle 30s. Das 
hatte ich damals an der Batteriespannung gesehen. Wie oft der aber die 
Werte intern aktualisiert kann ich dir gar nicht sagen. Aktuell lasse 
ich den Zähler einmal am Tag auslesen. (Verbrauchswerte)
Ich hatte anfangs mal 20 Minuten eingestellt. Irgendwann hat der Zähler 
aber die Kommunikation gänzlich verweigert. Ich nehme die haben einen 
Beschränkung implementiert, um die Batterie zu schonen.

Eine hochauflösende Temperaturmessung habe ich mit einem anderen Sensor 
realisiert und nicht über den Zähler.

[Klaus R. (klara)]

Matthias schrieb:
> Eine Sache ist mir aufgefallen:
> Die Temperaturen im Display aber auch auf der Schnittstelle werden nur
> alle paar Minuten aktualisiert. Das ist schade :-( Laut Datenblatt
> wertet der Sensor sie aber alle 2 Sekunden aus - und ich habe das am
> Stromverbrauch auch nachvollzogen. Alle 2 Sekunden spiked er 2x kurz
> hintereinander (vermutlich 1x pro Temperatursensor).

Wird Dein Wärmemengenzähler per Batterie gespeist oder und/auch 
fremdgespeist?

Mein erster Wärmemengenzähler wurde per Langzeitbatterie gespeist. Damit 
die Batterie auch mindestens (5 + 1) Jahr durchhält war die Häufigkeit 
der Auslese begrenzt worden. So habe ich nur alle 20 Minuten einen Wert 
ausgelesen. Gemessen wurde wesentlich häufiger. Das konnte man an 
Display ablesen.

Ich habe 2011 dann einen Wärmemengenzähler mit Fremdeinspeisung gesucht 
und den Sontex Supercal 539 gefunden. Der speist sich über den M-Bus 
ein. Diese Option mußte man extra angeben. Er läuft immer noch. Bei 
Auslesen des M-Bus bin ich bei 20 Minuten geblieben.

Die Temperaturen lese ich über Wärmesensoren ab. Damals was es ein 
DS1631. Heute nehme ich ein MCP9808 mit Breakout.

https://www.reichelt.de/temperatursensor-msop-8-mcp-9808-ems-p137341.html
Der kostet als IC nur ein drittel des DS1631, ist besser zu kaufen und 
ist noch genauer.

Es war für mich auch ein Problem meine I2C Schnittstelle an den MCP9808 
anzupassen. Viel einfacher war da ein ESP32 oder D1Mini zunehmen und ein 
Breakout des MCP9808 einzusetzen. Kein feinteiliges Löten und Software 
gibt es genügend.
http://www.esp32learning.com/code/esp32-and-mcp9808-digital-temperature-sensor-example.php

Du installierst die kostenlose Ardurino IDE und schon geht es los. 
Anleitungen gibt es zu hauf. Und die Welt der Sensoren steht Dir zur 
Verfügung.
mfg Klaus

[Matthias (Gast)]

Danke für die Antworten, natürlich könnte ich die Temperaturen extern 
lesen, aber wenn der WMZ das kann möchte ich das gern.

Und wie beschrieben hat meiner eine Netzteilerkennung, welche ich nutze 
(Stromverbrauch dann etwa 100µA dauerhaft + 60 µA/100ms alle 2 Sekunden 
- sonst, also auf Batterie, nur so 3-4µA + 60µa für knapp 100ms alle 2 
s);
Auslesen über Optik (mbus-test) "kostet" 1,2 mA für 750ms

[Hans M. (funzel1607)]

Hallo zusammen,

ich würde das Thema gern noch mal "aufwärmen" und nachfragen ob schon 
wer einen CF55 von itron erfolgreich auslesen konnte. Es gibt wohl eine 
Menge an aufsteckbaren Modulkarten, für die man jedoch die Plombe 
entfernen müsste.

Auf der Front scheint ebenfalls eine optische Schnittstelle vorhanden zu 
sein, welche ich gern mittels Volkszähler auslesen möchte. Im Idealfall 
via "Smartmeter" Adapter im ioBroker. Ansonsten wäre mqtt natürlich auch 
schön :)

Hat jemand schon Erfahrung mit dem Hersteller/Modell?

Danke!

[Stefan B. (stefan_b278)]

Darfst du die Plombe nicht entfernen? Evtl. Fernwärme?
Die optische Schnittstelle wird wohl die gleiche sein wie bei den 
kleineren. Also Adapter bauen mit Magnetring und testen..

[Hans M. (funzel1607)]

Stefan B. schrieb:
> Darfst du die Plombe nicht entfernen? Evtl. Fernwärme?

Korrekt.


> Die optische Schnittstelle wird wohl die gleiche sein wie bei den
> kleineren. Also Adapter bauen mit Magnetring und testen..

Habe einen neuen Volkszähler heute bekommen. Werde mal nen iobroker 
dranhängen und mal schauen was da rauskommt.

Oder gibt es einen einfacheren/besseren Weg das zu analysieren und zu 
testen?

Danke!

[Flo (Gast)]

Hi,
hast du geschafft ihn auszulesen?
Ich würde zu gern den Sharky 775 auslesen, aber aktuell bekomme ich da 
leider nichts hin und wäre dankbar über Ansätze...

[Hans M. (funzel1607)]

Flo schrieb:
> Hi,
> hast du geschafft ihn auszulesen?
> Ich würde zu gern den Sharky 775 auslesen, aber aktuell bekomme ich da
> leider nichts hin und wäre dankbar über Ansätze...

Leider nein. Bin auch nur selten vor Ort, weshalb ich nicht so viel Zeit 
zum testen habe. Falls sonst wer noch eine Idee hat, wie man vorgehen 
könnte, wäre ich auch dankbar.

[Matthew F. (matthew_f)]

Hat jemand hier Erfahrung mit dem Engelmann Sensostar E? Laut Anleitung 
musste das auch genauso gehen wie oben beschrieben. Ich kriege aber nur 
eine Reihe von 0x55 zurück:

mbus_bytes_received: 8: [55] [55] [55] [55] [55] [55] [55] [55] 
mbus_bytes: 1
Data:
{0x55, }
Error: -2

[Stefan B. (stefan_b278)]

Dann stimmt etwas mit dem Empfang nicht. Eventuell hast du Reflektionen 
und du liest deine eigenen gesendeten Bytes.

[Matthew F. (matthew_f)]

Der Kopf war falsch rum...

[Matthew F. (matthew_f)]

Jetzt versuche ich die Daten zu verstehen. Wir haben bisher wenig 
geheizt und unser Zählerstand war 48 kWh (per Knopfdruck am Gerät). 
Jetzt habe ich die Heizung für einen großen Zimmer (Bodenheizung) 
angemacht und schon ist der Stand auf 49 kWh.

Aus den Daten sehe ich den Unterschied aber nur sehr indirekt.

Vorher:
-------------------------------------------------
primary_address:  0x00
...
energy:      0 kWh
volume:      0 l
power:      6637 W
flow:      520 l/h
supply_temp:    21.0 °C
return_temp:    21.0 °C
temp_difference:  0.14 K
...
-------------------------------------------------

Nachher:
-------------------------------------------------
primary_address:  0x00
...
energy:      0 kWh
volume:      0 l
power:      11647 W
flow:      520 l/h
supply_temp:    37.0 °C
return_temp:    26.0 °C
temp_difference:  10.81 K
...
-------------------------------------------------

Man sieht schon, das plötzlich viel mehr Power im Spiel ist, und 
Vor/Rücklauf Temperatur anders sind. Aber wie zeichne ich laufend (mit 
z.B. 4 Ablesungen am Tag - laut Anleitung geht das) unser Verbrauch auf 
ohne den eigentlichen Zählerstand? Der eigentliche Zählerstand ist nicht 
zu sehen. Und warum ist Power schon auf 6637W obwohl kein Durchlauf 
stattfindet? Ist das eine Art Basis Power für die 21° (ich bin in einer 
Wohnung und habe keine Kontrolle über die Zentralheizung oder 
Vorlauftemperatur).

[Stefan B. (stefan_b278)]

Dann stimmt was mit der Berechnung nicht und die Ausgegebenen Werte 
werden nicht richtig interpretiert. Da musst du selbst ein bisschen Hand 
anlegen.

[Klaus R. (klara)]

Matthew F. schrieb:
> Ist das eine Art Basis Power für die 21° (ich bin in einer
> Wohnung und habe keine Kontrolle über die Zentralheizung oder
> Vorlauftemperatur).

Schon mal nach Infos zum Wärmemengenzähler gesucht? Mein Hersteller war 
da sehr auskunftsfreudig.

Eingesetzt wird der Wärmemengenzähler von der Allmess GmbH in Oldenburg. 
Vielleicht rücken die mit Informationen zum Auslesen heraus.
mfg Klaus

[Matthew F. (matthew_f)]

Ich glaube das Problem war nur, dass bestimmte Werte mehrmals kommen, 
und in der Übersicht am Ende stehen die letzte Werte pro Werttyp. Mein 
Zählerstand war durchaus da, aber man musste zurück im Decoding-Teil 
schauen statt in der Übersicht am Ende.

Zur Info für andere, was bei mir funktioniert hat mit dem SensostarE:
- Eine USB Buchse hat was zurück bekommen, die andere nicht (das 
Test-Laptop ist ziemlich alt...)
- Serial zurücksetzen mit

stty -F /dev/ttyUSB0 sane

 (wahrscheinlich unwichtig)
- Pause auf 240ms
- Init auf 536 Bytes gesetzt
- Schreib/Lese-Kopf "falsch rum"/von oben dran setzen
- Der Zähler muss nicht händisch aufgeweckt werden
- Zuerst aufwecken mit dem Befehl 1
- Dann Auslesen mit dem Befehl 3

Ob Pause Zeit und Init-Länge unbedingt so anders von den Defaults sein 
müssen, bin ich nicht sicher.

Vielen Dank @stefan_b278 für diesen tollen Stück C Code!

[Hans M. (funzel1607)]

So, ich habe nun auch mal bei der Fa. Alles angerufen und einen sehr 
netten MA drangehabt. Dieser hat mir per Mail direkt die Doku des CF55 
sowie eine Config-Software für Windows zugesandt.

Habe dann mal versucht mit dem Volkszähler und der Software Zugriff zu 
bekommen, was leider auch nicht klappte. Selbst mit deren Anleitung 
nicht. Allerdings habe ich auch eine Preisliste von denen erhalten, wo 
sie den IR-Kopf für 750€ anbieten!?! Meint ihr, der kann was 
"besonderes" oder warum klappt es mit einem normalen Kopf nicht? Hatte 
Baud und Fifo beachtet...

Da es sich um M-Bus handelt, habe ich unter iobroker noch mal den Mbus 
Adapter installiert, finde unter Discovery aber keine Geräte am 
Lesekopf... Habe ihn auch schon mal gedreht, leider ohne Erfolg.

Muss man hier noch was weiteres beachten? Danke!

[Matthew F. (matthew_f)]

Wie man oben liest, bin ich kein Expert, aber mein Verständnis bisher, 
ist das mit MBUS über einen Kabel kann man sofort kommunizieren, aber 
mit MBUS über die optische Schnittstelle muss das Gerät erst aufgeweckt 
werden, entweder per Hand oder wie in meinem Fall mit einem langen 
Sequenz von Bytes.

Ich würde, vor man mit Volkszähler oder ioBroker oder was Kompliziertes 
anfängt versuchen überhaupt einen Datenaustausch hinzukriegen. Das 
C-Code mbus-test oben ist sehr hilfreich dafür. Das Programm Lorus 
(https://www.m-bus.de/software.html) scheint auch Einige geholfen zu 
haben.

Hinterher hat man dann evtl. das Problem, dass Volkszähler oder andere 
MBUS tools (auch libmbus) dieses Aufwecken nicht machen. Ich habe in 
diesem Thread von keine Automatisierung gelesen die ohne ein Bisschen 
Programmieren/Zusammenkleben von Tools ging.

Vom Bild im Benutzerhandbuch sieht es so aus, dass der Lesekopf 
seitwärts zu montieren ist. Ich hätte gedacht mit dem Kabel dann nach 
rechts, aber in meinem Fall war es andersrum als was man erwartet hatte. 
Aber die Dioden sind oben und unten und nicht links und rechts, soweit 
ich sehen kann.

Ich habe mich gefreut, dass dieser Lesekopf, was eigentlich eher immer 
wieder mit Stromzähler in Verbindung gebracht wird, auch hier 
funktioniert hat. Ich würde denken, dass das bei Ihnen auch gehen muss, 
und das man kein 750€ ausgeben muss... aber wie gesagt, mein Halbwissen 
besteht erst seit gestern.

[Klaus R. (klara)]

Matthew F. schrieb:
> Ich würde, vor man mit Volkszähler oder ioBroker oder was Kompliziertes
> anfängt versuchen überhaupt einen Datenaustausch hinzukriegen. Das
> C-Code mbus-test oben ist sehr hilfreich dafür. Das Programm Lorus
> (https://www.m-bus.de/software.html) scheint auch Einige geholfen zu
> haben.

C-Code mbus-test erläutert doch alle MBus Codes die man braucht.
Ich habe vor über 12 Jahren selber mit dem Programm Lorus Free meine 
ersten Erfolge gehabt. Heute kann das sicher noch mehr.
mfg Klaus

[Stefan B. (stefan_b278)]

Ich habe das Programm mal in github reingeschoben, da ich noch ein paar 
Verbesserungen eingebaut hab:

https://github.com/geronet1/mbus-test

[Hans M. (funzel1607)]

Kannst du in zwei Zeilen beschreiben wo ich den /dev/ttyUSB0 definiere?

Aktuelle bekomme ich auf einem Pi nur folgenden Fehler:

root@iobroker-cloud:~/mbus-test# sudo python3 readout-test.py 
Start:21.11 12:05:25
21.11 12:05:25  Traceback (most recent call last):
  File "/root/mbus-test/readout-test.py", line 38, in <module>
    mbus_readout()
  File "/root/mbus-test/readout-test.py", line 23, in mbus_readout
    proc = subprocess.run(path + args, capture_output=True, text=True, timeout=10)
  File "/usr/lib/python3.10/subprocess.py", line 501, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/usr/lib/python3.10/subprocess.py", line 969, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.10/subprocess.py", line 1845, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'Release/mbus-test'

[Stefan B. (stefan_b278)]

Das readout-test.py war eigentlich nur ein Test für mehrere Wärmezähler.

Du musst das Programm mbus-test in Release/ starten bzw. vorher mit make 
compilieren.
Hatte ganz vergessen das Makefile mitzusenden, hab ich jetzt 
hochgeladen.

[Hans M. (funzel1607)]

root@iobroker-cloud:~/mbus-test/Release# sudo make
Building target: mbus-test
Invoking: MacOS X C Linker
gcc  -o "mbus-test"   
gcc: fatal error: no input files
compilation terminated.
make: *** [makefile:31: mbus-test] Error 1

Was mache ich falsch?
Danke!

[Stefan B. (stefan_b278)]

Sorry zuviel Dateien gelöscht, jetzt gehts. Nochmal neu laden und dann 
klappts ;)

[Hans M. (funzel1607)]

Jetzt klappt's, wo wir wieder bei meiner Einstiegsfrage sind:
Wo definiere ich /dev/ttyUSB0?

root@iobroker-cloud:~/mbus-test/Release# ./mbus-test 
error opening serial device /dev/ttyAMA0: No such file or directory)

Danke für die schnelle Reaktion :)


EDIT:
Mein USB Lesekopf war plötzlich bei /dev/ttyS0, daher hatte er ihn mit 
dem Argutment "-d" nicht gefunden.

Danke!

[Hans M. (funzel1607)]

Ich korrigiere mich erneut, ich war auf der falschen Maschine :)
Hatte mich mit der IP vertippt und bin (danke Zerotier) unbemerkt auf 
einem völlig falschen Host unterwegs gewesen....

Wenn ich die Config auf dem Display richtig interpretiere müsste ich mit 
der Primäradresse 0x00 auf Baud 2400 kommunizieren, oder? Habe mal die 
Bilder angehängt.

So, nun endlich auf dem richtigen System folgende Meldungen:

mal Error: -2
mal Error: -1
mal Error: wring length


mit einem "sudo ./mbus-test -d /dev/ttyUSB0 -a 0x00 -t" kommt nur 
"sending test data 0x55..." und dann nichts mehr.

An welchen Schrauben sollte man dann nun noch drehen, damit ich mit dem 
Teil sprechen kann? Welche Parameter kann man am besten zum testen 
nutzen? Danke!

[Matthew F. (matthew_f)]

Von meinen Erfahrungen vor ein paar Tagen:

- Das Program ohne -t laufen lassen, da musste einen Menu erscheinen - 
Option 1 ist dann Aufwecken (viele 0x55, danach sollte ein 0xE5 zurück 
kommen)
- Nicht aufgeben, wenn ein Fehler Meldung kommt, sondern weiter machen 
mit Option 2 oder 3
- Bei mir kommt allerdings schon eine Antwort (0xE5) nach dem Aufwecken
- Langsam die Paket-Länge verlängern (+/-) und/oder die Pause (a/y) 
verlängern

Ich bin allerdings mit dem Code von dem Thread hier unterwegs und nicht 
mit der GitHub Version - ich hatte noch nicht Zeit das im Detail 
anzuschauen.

[Hans M. (funzel1607)]

Danke für die Infos.

Muss ich bzgl. der Herstellerkennung noch was anpassen? Habe einen CF55.

[Stefan B. (stefan_b278)]

Matthew F. schrieb:
> Ich bin allerdings mit dem Code von dem Thread hier unterwegs und nicht
> mit der GitHub Version - ich hatte noch nicht Zeit das im Detail
> anzuschauen.

Ist eigentlich der gleiche nur weiterentwickelt um auch mit 
nicht-optischen Zählern über MBUS (2-Draht) kommunizieren zu können.

[Stefan B. (stefan_b278)]

Die Option -t brauchst du gar nicht, da sendet er 0x55 dauerhaft (zum 
testen des Optokopfes und schauen mit der Handy-Kamera)

sudo brauchst du eigentlich auch nicht, gib deinem /dev/ttyUSB0-Gerät 
die passenden Rechte oder dir als User die richtige Gruppe die dort 
lesen und schreiben kann.

./mbus-test -v -d /dev/ttyUSB0 -a 0x00
und dann mit 0-3 alles durchprobieren.

-a ist auch unnötig außer es hängen mehrere WMZ an dem Optokopf was 
unwarscheinlich ist. Mit Adresse 0x254 (default) antwortet jeder.

[Hans M. (funzel1607)]

So, ich habe nun alles durch. vor Ort den Kopf auch mal um 180° gedreht, 
habe die Lords Software getestet, habe die Software von iltron versucht 
und zuletzt den mbus Adapter innerhalb von ioBroker. Keiner ist in der 
Lage eine Verbindung aufzubauen.

Ich habe den CF55 auch vor Ort durch die rote taste manuell geweckt, was 
auch nichts brachte.

Das Einzige was mal eine Art von Lebenszeichen war, ist die 
Fehlermeldung, dass ich mal eine Meldung mit "wrong length" hatte.
Das war es aber leider auch.

Der Kopf selbst muss ok sein, da ich damit im selben Aufbau (Raspi, 
iobroker) problemlos einen Smartmeter auslesen kann.

Demnach bin ich kurz davor das Thema zu begraben, sofern niemand eine 
weitere Idee hat.

Danke im Voraus!

[Klaus R. (klara)]

Hans M. schrieb:
> Das Einzige was mal eine Art von Lebenszeichen war, ist die
> Fehlermeldung, dass ich mal eine Meldung mit "wrong length" hatte.
> Das war es aber leider auch.

Das ist ha schon etwas. Läßt sich das reproduzieren?
mfg Klaus

[Hans M. (funzel1607)]

Jap, muss noch mal genau aufzeichnen, was ich dazu tun muss, aber es 
geht.

[Stefan B. (stefan_b278)]

Wichtig ist der Parameter "-v", dann siehst du auch die Empfangenen 
Daten. Falls diese die gleichen wie deine gesendeten sind, hast du 
Reflektionen.

Bei meinen WMZ von Allmess (auch Itron) hab ich welche gehabt die sich 
nur ganz selten oder gar nicht aufwecken ließen. Verschiedene IR-Leds 
probiert (mit verschiedenen Wellenlängen), andere Ausrichtung etc.
Mit einem anderem Lesekopf ging es dann (siehe oben, die blauen). Keine 
Ahnung warum.

Die Software in deinem größerem WMZ dürfte sogar die gleiche bzw. 
ähnlich sein, somit liegt es warscheinlich nur an deinem Lesekopf. Hast 
du ein Oszilloskop?

[Hans M. (funzel1607)]

Oszilloskop leider noch nicht, wäre aber mal heute eine gute Gelegenheit 
nach einem kleinen zu schauen :) Was müsste ich dann beim Messen prüfen?

[Stefan B. (stefan_b278)]

Naja wenn du keins hast brauchst du es nicht extra kaufen.
Du kannst auch mit der Handy-Kamera schauen ob was vom Zähler 
zurückkommt wenn du nur die Sende-Led hinhältst und die Sequenz sendest. 
Dann weisst du ob es an deinem Kopf liegt ;)

[Alexander D. (d_alexander)]

Hi

Ich habe mich mehrfach durch diesen Thread durchgearbeitet und auch die 
ganzen Software Programme ausprobiert, ohne dass ich bei meinem 
Verbauten WMZ (Allmess Integral-V UltraLite PRO) irgendeine Art 
Lebenszeichen oder Meldung bekommen hätte. Andere haben ja aber 
erfolgreich diesen WMZ hier abfragen können, also suche ich gerade nach 
dem Problem.

Da ich bereits bei meinen Stromzählern gute Erfahrungen mit einem 
fertigen Opto-Kopf (https://weidmann-elektronik.de/Produkt_IR-Kopf.html) 
gemacht hatte, hatte ich mir diesen auch für den WMZ gekauft. Jetzt gibt 
es aber auch einige Beiträge hier die mit dem Ansatz gescheitert sind 
den Kopf für den Stromzähler am WMZ zu verwenden.

Kann jemand mal einen Blick auf die Beschreibung des Opto-Kopfs werfen 
und mir sagen ob das vielleicht komplett das falsche ist für den WMZ?

Oder kann jemand einen kaufbaren Kopf empfehlen, der erschwinglich ist? 
Der Allmess M-BUS Optokopf USB für 675,96 Euro ist mir definitiv zu 
teuer, selber basteln aber halt nicht meine Kompetenz.

[Hans M. (funzel1607)]

Ich habe nun drei mal Option "1" gesendet und dann folgendes 
zurückbekommen:

verbose: 2
Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
728 bytes sent
0 byte(s) received
Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
728 bytes sent
0 byte(s) received
Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
728 bytes sent
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[7B] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[7B] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[4D] 
mbus_bytes_received: 1
[68] 
mbus_bytes_received: 1
[72] 
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[04] 
mbus_bytes_received: 1
[42] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[23] 
mbus_bytes_received: 1
[20] 
mbus_bytes_received: 1
[07] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[03] 
mbus_bytes_received: 1
[2D] 
mbus_bytes_received: 1
[59] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[0B] 
mbus_bytes_received: 1
[76] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[0A] 
mbus_bytes_received: 1
[5A] 
mbus_bytes_received: 1
[05] 
mbus_bytes_received: 1
[0A] 
mbus_bytes_received: 1
[50] 
mbus_bytes_received: 1
[04] 
mbus_bytes_received: 1
[61] 
mbus_bytes_received: 1
[44] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[04] 
mbus_bytes_received: 1
[1A] 
mbus_bytes_received: 1
[0D] 
mbus_bytes_received: 1
[2B] 
mbus_bytes_received: 1
[02] 
mbus_bytes_received: 1
[DC] 
mbus_bytes_received: 1
[03] 
mbus_bytes_received: 1
[FD] 
mbus_bytes_received: 1
[0E] 
mbus_bytes_received: 1
[09] 
mbus_bytes_received: 1
[FD] 
mbus_bytes_received: 1
[24] 
mbus_bytes_received: 1
[0F] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[E0] 
48 byte(s) received
Data:
{0x10, 0x7B, 0x00, 0x7B, 0x16, 0x4D, 0x68, 0x72, 0x10, 0x04, 0x42, 0x00, 0x23, 0x20, 0x07, 0x00, 0x16, 0x03, 0x2D, 0x59, 0x00, 0x0B, 0x76, 0x16, 0x0A, 0x5A, 0x05, 0x0A, 0x50, 0x04, 0x61, 0x44, 0x00, 0x04, 0x1A, 0x0D, 0x2B, 0x02, 0xDC, 0x03, 0xFD, 0x0E, 0x09, 0xFD, 0x24, 0x0F, 0x00, 0xE0, }
Error: -2

[Stefan B. (stefan_b278)]

Sieht doch gut aus, kannst du mal die ganze Ausgabe reinkopieren wenn du 
"2" drückst?
Und kommt ein "E5" zurück wenn du "0" probierst?

[Nick K. (nick-tech)]

Hallo Zusammen,

ich habe auch einen Wärmezähler (Ditech Integral-V UltraLite PRO) der ja 
mit dem Kalo Ultramax identisch zu sein scheint.

Ich würde den Zähler gerne auslesen und habe mir dazu einen Schreib- 
Lesekopf besorgt der an einen ESP angeschlossen ist:
https://www.ebay.de/itm/314152997777

Zum Auslesen würde ich gerne das Tasmota Smart Meter Interface nutzen. 
Das sollte eigentlich alles können was man braucht.

https://tasmota.github.io/docs/Smart-Meter-Interface/
https://tasmota.github.io/docs/Scripting-Language/

Falls zwischendrin die Baudrate gewechselt werden muss geht das auch, 
Beispiele dazu gibt es 
(https://tasmota.github.io/docs/Smart-Meter-Interface/#landis-gyr-zmr120ares2r2sfcs-obis)

Bevor ich nun los bastel, möchte ich zunächst einmal sammeln was man tun 
muss um den Zähler Aufzuwecken. Trotz intensiver Recherche ist mir das 
nicht ganz klar.

Kann jemand bestätigen dass folgendes korrekt ist:
Aufwachsequenz:
2400 baud, 8E1
2,2 Sekunden lang
eine Aufwachsequenz senden? Welche?

Danach sollte der Zähler irgendwas antworten..?

[Hans M. (funzel1607)]

Hier zwei Mal die "0"

verbose: 2
Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
snd_nke(): Sende Initialisierung
[10][40][00][40][16]
5 bytes sent
mbus_bytes_received: 255
[55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] [55] 
1 byte(s) received
Data:
{0x55, }
Error: -2
Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
snd_nke(): Sende Initialisierung
[10][40][00][40][16]
5 bytes sent
mbus_bytes_received: 1
[00] 
1 byte(s) received
Data:
{0x00, }
Error: -2

Hier zwei Mal die "2"

Port Modus 8E1
req_ud2(): Sende Anfrage Daten Klasse 2
[10][5B][00][5B][16]
5 bytes sent
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[16] 
5 byte(s) received
Data:
{0x10, 0x5B, 0x00, 0x5B, 0x16, }
Error: -2
Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
req_ud2(): Sende Anfrage Daten Klasse 2
[10][5B][00][5B][16]
5 bytes sent
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[16] 
5 byte(s) received
Data:
{0x10, 0x5B, 0x00, 0x5B, 0x16, }
Error: -2
Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
req_ud2(): Sende Anfrage Daten Klasse 2
[10][5B][00][5B][16]
5 bytes sent
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[55] 
mbus_bytes_received: 1
[55] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[72] 
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[04] 
mbus_bytes_received: 1
[0B] 
mbus_bytes_received: 1
[6A] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[0C] 
mbus_bytes_received: 1
[23] 
mbus_bytes_received: 1
[19] 
mbus_bytes_received: 1
[13] 
mbus_bytes_received: 1
[C2] 
mbus_bytes_received: 1
[6C] 
mbus_bytes_received: 1
[DF] 
mbus_bytes_received: 1
[C4] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[AD] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[CC] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[19] 
mbus_bytes_received: 1
[03] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[AE] 
mbus_bytes_received: 1
[28] 
mbus_bytes_received: 1
[06] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[D5] 
mbus_bytes_received: 1
[2E] 
mbus_bytes_received: 1
[F3] 
mbus_bytes_received: 1
[8B] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[BE] 
mbus_bytes_received: 1
[06] 
mbus_bytes_received: 1
[D5] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[70] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[DB] 
mbus_bytes_received: 1
[28] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[66] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[7B] 
mbus_bytes_received: 1
[FE] 
mbus_bytes_received: 1
[79] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[55] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[58] 
mbus_bytes_received: 1
[77] 
mbus_bytes_received: 1
[04] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[78] 
mbus_bytes_received: 1
[20] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[C4] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[03] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[28] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[D5] 
mbus_bytes_received: 1
[F3] 
mbus_bytes_received: 1
[3E] 
mbus_bytes_received: 1
[D4] 
mbus_bytes_received: 1
[4F] 
mbus_bytes_received: 1
[CD] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[D4] 
mbus_bytes_received: 1
[4F] 
mbus_bytes_received: 1
[C1] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[66] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[7B] 
mbus_bytes_received: 1
[FE] 
mbus_bytes_received: 1
[79] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[68] 
mbus_bytes_received: 1
[68] 
mbus_bytes_received: 1
[72] 
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[04] 
mbus_bytes_received: 1
[6C] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[23] 
mbus_bytes_received: 1
[13] 
mbus_bytes_received: 1
[6C] 
mbus_bytes_received: 1
[C4] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[03] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[28] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[2E] 
mbus_bytes_received: 1
[8B] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[28] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[3E] 
mbus_bytes_received: 1
[70] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[28] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[66] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[7B] 
mbus_bytes_received: 1
[FE] 
mbus_bytes_received: 1
[79] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[55] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[58] 
mbus_bytes_received: 1
[10] 
mbus_bytes_received: 1
[04] 
mbus_bytes_received: 1
[0B] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[0C] 
mbus_bytes_received: 1
[19] 
mbus_bytes_received: 1
[20] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[07] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[16] 
mbus_bytes_received: 1
[03] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[AE] 
mbus_bytes_received: 1
[4F] 
mbus_bytes_received: 1
[CC] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[2E] 
mbus_bytes_received: 1
[F3] 
mbus_bytes_received: 1
[42] 
mbus_bytes_received: 1
[D4] 
mbus_bytes_received: 1
[4F] 
mbus_bytes_received: 1
[28] 
mbus_bytes_received: 1
[2A] 
mbus_bytes_received: 1
[3E] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[40] 
mbus_bytes_received: 1
[DB] 
mbus_bytes_received: 1
[4F] 
mbus_bytes_received: 1
[C1] 
mbus_bytes_received: 1
[00] 
mbus_bytes_received: 1
[5B] 
mbus_bytes_received: 1
[66] 
mbus_bytes_received: 1
[42] 
172 byte(s) received
Data:
{0x00, 0x5B, 0x55, 0x55, 0x00, 0x72, 0x10, 0x00, 0x04, 0x0B, 0x6A, 0x00, 0x00, 0x0C, 0x23, 0x19, 0x13, 0xC2, 0x6C, 0xDF, 0xC4, 0x00, 0x2A, 0xAD, 0x00, 0xCC, 0x16, 0x19, 0x03, 0x00, 0x00, 0xAE, 0x28, 0x06, 0x2A, 0xD5, 0x2E, 0xF3, 0x8B, 0x00, 0xBE, 0x06, 0xD5, 0x00, 0x00, 0x70, 0x00, 0xDB, 0x28, 0x2A, 0x5B, 0x66, 0x16, 0x10, 0x7B, 0xFE, 0x79, 0x16, 0x55, 0x00, 0x58, 0x77, 0x04, 0x00, 0x00, 0x78, 0x20, 0x00, 0x2A, 0xC4, 0x2A, 0x00, 0x16, 0x03, 0x00, 0x28, 0x2A, 0xD5, 0xF3, 0x3E, 0xD4, 0x4F, 0xCD, 0x00, 0x00, 0xD4, 0x4F, 0xC1, 0x2A, 0x5B, 0x66, 0x16, 0x10, 0x7B, 0xFE, 0x79, 0x16, 0x68, 0x68, 0x72, 0x10, 0x04, 0x6C, 0x00, 0x23, 0x13, 0x6C, 0xC4, 0x2A, 0x00, 0x16, 0x03, 0x00, 0x28, 0x2A, 0x2E, 0x8B, 0x00, 0x28, 0x2A, 0x3E, 0x70, 0x00, 0x28, 0x2A, 0x5B, 0x66, 0x16, 0x10, 0x7B, 0xFE, 0x79, 0x16, 0x55, 0x00, 0x58, 0x10, 0x04, 0x0B, 0x00, 0x0C, 0x19, 0x20, 0x00, 0x2A, 0x07, 0x00, 0x00, 0x16, 0x03, 0x00, 0xAE, 0x4F, 0xCC, 0x2A, 0x2E, 0xF3, 0x42, 0xD4, 0x4F, 0x28, 0x2A, 0x3E, 0x00, 0x40, 0xDB, 0x4F, 0xC1, 0x00, 0x5B, 0x66, 0x42, }
Error: -2

[Matthew F. (matthew_f)]

Falls es hilft: ich hatte neulich das Problem mit einem Lesekopf, dass 
die Dioden zu weit raus nach vorne geschaut haben. So hat mann immer die 
gleiche Daten zurückbekommen, die man gesendet hat. Ein vorsichtiges 
präzises drücken zurück ins Gehäuse hat geholfen.

[Stefan B. (stefan_b278)]

Nick K. schrieb:
> Kann jemand bestätigen dass folgendes korrekt ist:
> Aufwachsequenz:
> 2400 baud, 8E1
> 2,2 Sekunden lang
> eine Aufwachsequenz senden? Welche?
Als Byte die "5"
ergibt mit 8E1 nämlich ein genaues Rechtecksignal..

> Danach sollte der Zähler irgendwas antworten..?
Nein, kurze Pause machen (ca. 350 ms) und dann [10][5B][FE][59][16] 
senden.
Muss ein "E5" zurückkommen (einzelnes Byte).

[Stefan B. (stefan_b278)]

Hans M. schrieb:
> Error: -2

Man sieht deutlich daß du Reflektionen hast und deine gesendeten Daten 
wieder zurückbekommst. Kannst du den Lesekopf besser positionieren?

Beim 2. mal hats ja funktioniert, ich schau grad nach warum er die Daten 
nicht dekodieren kann.

[Nick K. (nick-tech)]

Mein Zwischenstand bisher, leider noch nicht erfolgreich.

>D
;start, define variables
res=0
scnt=0


>B
;setup sensor
->sensor53 r

>F
;this section is executed every 100ms
scnt+=1
;increment counter

switch scnt
;jump to x according to scnt

case 6
;after 600ms (done so in example, why?)
res=sml(1 1 "05")
;set string to send to "05" on meter 1 (wake up sequence)

case 28
;2,2s later (28-6), wake up time is over
res=sml(1 1 "")
;send nothing, can this be done like this?

case 31
;0,3s later (31-28), waiting period is over
res=sml(1 1 "105BFE5916")
;set string to send to "105BFE5916" on meter 1 (request data)

case 50
;5000ms later \>restart sequence
scnt=0
ends

>M 1
;declare sensors  
+1,3,M,0,2400,WAERME,1
;Meter number=1,rxPIN=3,M=Modbus8E1,No Pullup=0,baud=2400,jsonPrefix=WAERME
;txPIN=1,message and timing defined in >F section
#

Um den Zähler aufzuwecken, zu warten, zum Senden aufzufordern und die 
Daten dann zu lesen, wird alle 5 Sekunden folgende Schleife ausgeführt:

- 0,6s warten (weil das hier auch so gemacht wird: 
https://tasmota.github.io/docs/Smart-Meter-Interface/#landis-gyr-zmb120-t213cs-obis)
- 2200ms lang 0x05 senden
- 300ms lang "nichts" senden (350ms gehen leider nicht, 400 wäre 
möglich, ich hoffe es funktioniert als zu sendenden String einfach "" 
anzugeben)
- "105BFE5916" senden um Daten anzufordern

Damit sollte zumindest mal irgendwas zurückkommen. Bisher erhalte ich 
aber nur folgendes:

01:05:35.012 > 05 00 02 e0 00 
01:05:37.252 > 00 02 80 71 
01:05:37.553 > 10 5b fe 59 16 00 02 5c a7

.

Fragen:
- Das ist ja das was ich Sende (incl. Parity + Stopbit?). Sowohl die 
Sendediode wie auch der Empfangstransistor stecken in einem schwarzen 
Gehäuse mit eigenen "Kanälen", die können sich eigentlich nicht sehen.

Ich meine folgendes zu erkennen:

01:05:35.012 > 05 00 02 e0 00

- das ist wohl der "Aufwachblock", aber wohl nicht das was hier 
rauskommen soll

01:05:37.252 > 00 02 80 71

- mit "" nichts zu senden klappt scheinbar nicht. Wie dann?

01:05:37.553 > 10 5b fe 59 16 00 02 5c a7

- ist das wenigstens korrekt? [10][5B][FE][59][16] + Parity + Stopbit?


@Stefan B.:
- Was meinst du genau mit "Als Byte die "5""? 0x05?
- 350ms warten kann ich wohl nicht, nur 300 oder 400. Was ist besser?

[Stefan B. (stefan_b278)]

Ich hoffe dir ist klar daß die optische Schnittstelle nicht dafür 
gemacht ist die Daten regelmäßig zu lesen. Je nach Zähler maximal 4x am 
Tag bei Batteriebetrieb, sonst antwortet er einfach nicht (kommt halt 
auf den Zähler an). Für eine Visualisierung brauchst du die 
Drahtgebundene MBUS Schnittstelle.

> Was meinst du genau mit "Als Byte die "5""? 0x05?
Sorry, hätte gleich 0x55 schreiben sollen

> 350ms warten kann ich wohl nicht, nur 300 oder 400. Was ist besser?
mach 400, die Zähler sind meist noch 1-4 Sekunden wach. Einfach 
probieren.

[Klaus R. (klara)]

Stefan B. schrieb:
> Ich hoffe dir ist klar daß die optische Schnittstelle nicht dafür
> gemacht ist die Daten regelmäßig zu lesen. Je nach Zähler maximal 4x am
> Tag bei Batteriebetrieb, sonst antwortet er einfach nicht (kommt halt
> auf den Zähler an). Für eine Visualisierung brauchst du die
> Drahtgebundene MBUS Schnittstelle.

Mein erster Wärmemengenzähler durfte nur alle 15 Minuten angesprochen 
werden. Ich habe ihn daraufhin alle 20 Minuten ausgelesen.

Beim nächsten hatte ich ganz bewusst auf die zusätzliche 
Fremdeinspeisung geachtet.
mfg Klaus

[Nick K. (nick-tech)]

im ersten Schritt wäre ich schon mal froh, wenn ich 1x am Tag den 
Zählerstand auslesen könnte. Bisher ist es mir leider immer noch nicht 
gelungen irgend eine Antwort vom Zähler zu bekommen.

Noch mal zur Aufwecken: Ich muss nicht nur 1x 0x55 senden, sondern 2,2s 
lang immer wieder 0x55. Richtig?

Bzgl. Drahtgebundener MBUS Schnittstelle: Gibt es da anschlüsse auf der 
Platine? Stefan B., du hattest das Gerät doch mal offen?

Hat irgendjemand ein vernünftiges Manual zu dem "Integral V Ultra lite 
Pro"? irgendwo muss das doch dokumentiert sein..

[Stefan B. (stefan_b278)]

Ich denke bei dir wäre es sinnvoller wenn du das vorher ohne den ESP 
probierst und irgendwie einen Lesekopf an einen Rechner oder Raspberry 
bastelst, damit du auch später prüfen kannst was der ESP sendet.
Somit kannst du auch mein Programm verwenden und herumtesten, das ist 
nämlich genau für die Itron Zähler (deiner) gemacht.

Du musst 2,2 sek. 0x55 senden mit 8E1, dann 400 ms warten, dann 
umschalten auf 8N1 und die Sequenz senden.

>Bzgl. Drahtgebundener MBUS Schnittstelle: Gibt es da anschlüsse auf der
>Platine? Stefan B., du hattest das Gerät doch mal offen?
Bei den Geräten ohne serienmäßigen MBus-Anschluss gibt es keine Bauteile 
dafür auf der Platine, logischerweise.

[Hans M. (funzel1607)]

Stefan B. schrieb:
> Hans M. schrieb:
>> Error: -2
>
> Man sieht deutlich daß du Reflektionen hast und deine gesendeten Daten
> wieder zurückbekommst. Kannst du den Lesekopf besser positionieren?

muss ich mal schauen, bin nicht immer vor Ort

> Beim 2. mal hats ja funktioniert, ich schau grad nach warum er die Daten
> nicht dekodieren kann.

hattest du schon was in Erfahrung bringen können? Hatte die komplette 
Doku mal hier hochgeladen.

Danke!

[Nick K. (nick-tech)]

Ich habe das Programm von Stefan B auf einem RaspberryPI installiert und 
führe es dort aus. Der Lesekopf hängt an GPIO14/15 (/dev/serial0). Mit 
der Handykamera sieht man es auch blinken, ich würde mal sagen das 
funktioniert.

Allerdings bekomme ich immer noch keine Rückmelung vom Wärmezähler.

Ich rufe Stefan B.`s Programm auf:

./mbus-test -v -d /dev/serial0

Nachdem ich nie eine Antwort bekomme, hier mal die Meldung wenn ich 
versuche nur die Aufwachswquenz sende (q: wakeup sequence)

Ausgabe ist dann:

Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
error 22 from tcsetattr

Was bedeutet dieser Error 22?

[Matthew F. (matthew_f)]

Ich habe das gleiche Setup auf einem alten Raspi Model B. Falls nicht 
schon geschehen, es ist wichtig den Serial Port als Serial Port 
einzurichten:
https://learn.adafruit.com/adafruit-nfc-rfid-on-raspberry-pi/pi-serial-port

Ich glaube ansonsten funktioniert den UART als Terminal, und man hat den 
Eindruck das es etwas tut aber nicht richtig funktioniert. Nach der 
Umstellung (was bei mir leider zuerst auch eine Umstellung auf den 
echten Raspberry PI OS erforderte) ging es.

Ich hatte zuerst mit einem USB-Schreib-Lesekopf gearbeitet, ein Variable 
weniger im Mix, und bin dann, nach alles funktioniert hat auf die GPIO 
Pins umgestiegen. So ist die USB Version frei für weitere Experimente 
wie unsere Warmwasserzähler (gleiche Firma, gleiche (laut Anleitung) 
Schnittstelle, aber andere Dioden-Abstand und kein schönen magnetischen 
Platz für den Lesekopf) womit ich bisher kein Erfolg hatte.

[Stefan B. (stefan_b278)]

Nick K. schrieb:
> Was bedeutet dieser Error 22?

Siehe https://github.com/pyserial/pyserial/issues/196

/dev/ttyS0 of Raspberry Pi 3 Model B does not support EVEN and ODD.
So, you need to use /dev/ttyAMA0.
However /dev/ttyAMA0 of Raspberry Pi 3 Model B is bound to Bluetooth 
module.
In order to use /dev/ttyAMA0, you need to add the followings line into 
/boot/config.txt.

dtoverlay=pi3-miniuart-bt
After reboot, you can use /dev/ttyAMA0 as physical serial port.

[Nick K. (nick-tech)]

Danke Stefan B. !

Damit funktioniert es und ich bekomme eine Antwort von dem Zähler, wird 
auch gleich richtig dekodiert!

Die Harware scheint also zu funktionieren, jetzt muss ich das "nur" noch 
auf Tasmota hin bekommen.

Ich vermute auch hier liegt es an der 8N1/8E1 umschaltung beim 
aufwecken..

[Carsten (carsten12)]

Nick, bist Du mittlerweile mit Deinem Tasmota-Script weiter? Ich möchte 
zwar einen Wärmezähler Elster F96 Plus (baugleich Sharky 775) auslesen, 
aber die Spec ist sehr ähnlich: M-BUS über ZVEI, Baudratenwechsel, 
Parität umschalten, etc.

Bin vom ganzen Suchen schon tüddelig und weiß nicht mehr, wo ich das 
gefunden habe, aber so ist es wohl. Das könnte man natürlich auch mit 
nem TTL Kopf machen und selber einen ESP programmieren, aber ich fand 
das mit Tasmota via WLAN ganz schick und habe den gleichen Kopf wie Du 
gekauft. Ziel soll dan FHEM werden.

Falls jemand anders da schon weiter ist, gerne auch Tipps.

Gruß,
Carsten.

[Nick K. (nick-tech)]

Hallo Carsten,

ich mühe mich immer noch ab. Einen durchbruch habe ich noch nicht, aber 
vielleicht kommen wir gemeinsam weiter.
Hier der aktuelle Stand:

- Ich habe im Tasmota Projekt angefragt ob es eine Möglichkeit gibt die 
Parität umzuschalten. 
(https://github.com/arendst/Tasmota/discussions/17283) Bisher gab es die 
nicht, ein netter Mensch hat aber etwas eingebaut womit das 
funktioniert. Damit kann man nun wohl folgendes:
to restart hardware serial port. e.g.
sml(-1 1 "9600:8E1")
currently supports only baud rate and parity N,E,O
ignores number of bits and stop bits

- ich hab die Tasmota Firmware damit und mit den Optionen die man für 
SmartMeter und Scripting braucht gebaut (hier angehängt)

- Man muss zum flashen dieser Firmware, zunächst die minimal firmware 
installieren als Zwischenschritt sonst reicht der Speicher nicht 
(https://github.com/arendst/Tasmota-firmware/tree/main/release-firmware/tasmota)

- ich habe eine zweite Anfrage gestartet, weil mir nach wie vor nicht 
klar ist wie ich diese Abfrage z.B. alle 4h starte. Mir ist das 
verhalten der einzelnen Script-teile nicht klar: der Teil nach >S wir 
jede Sekunde, der Teil nach >F alle 100ms ausgeführt. Damit kann man 
hochzählen und je nach Stand des Zählers irgend welche Dinge ausführen 
(State Machine). Da wir aber ein 2,2s langes Aufwachsignal senden 
müssen, scheidet das nach meinem Verständnis aus (das würde ja nach 
spätestens 1s abbrechen)

- dazu habe ich bei Tasmota ein zweites Topic gestartet: 
(https://github.com/arendst/Tasmota/discussions/17388). Die Lösung ist 
wohl eine Subroutine zu schreiben die den Zähler aufweckt, wartet, daten 
anfordert und liest. Diese wird dann alle 4h aufgerufen. (Allerdings ist 
mir noch nicht klar wie man diesen Aufruf z.b. alle x Stunden anstellt.

Mein aktueller Code ist dieser, der ruft nach dem speichern 1x die 
Subroutine auf. Leider bekomme ich damit auf der Konsole im "Dump mode" 
(sensor53 d1) überhaupt keine Ausgabe und verstehe nicht warum. Ich 
sollte doch zumindest sehen was ich sende..
Für heute geb' ich auf.

>D
;start, define variables
wkup=1


>B
;setup sensor
->sensor53 r

>BS
print start
delay(5000)
print waited 5s, call subroutine

=#readmeter

#readmeter
print wake up meter
;set serial protocol
sml(1 1 "2400:8E1")
;send 0x55 for 2,2 seconds with 8E1, 2400 baud (wakeup sequence)
for wkup 1 532 1
sml(1 1 "55")
next
wkup=1
print wait for the meter
;wait for the meter to wake up
delay(400)
;switch serial protocol
sml(-1 1 "2400:8N1")
print request data
;set string to send to "1040FE3E16" (request data)
sml(-1 1 "1040FE3E16")
#


>M 1
+1,3,M,0,2400,WAERME,1
;Sensor 1: 8E1
#

[Hans M. (funzel1607)]

Stefan B. schrieb:
> Hans M. schrieb:
>> Error: -2
> Beim 2. mal hats ja funktioniert, ich schau grad nach warum er die Daten
> nicht dekodieren kann.

Hi Stefan, ich wollte noch mal vorsichtig nachfragen ob du bzgl. der 
Dekodierung was herausgefunden hast.

Vielen Dank!

[Hans M. (funzel1607)]

Ich bin soeben selbst durch Zufall einen Schritt weiter. Ich habe 
gesehen, dass der Adapter mbus in ioBroker plötzlich Objekte drin hatte. 
Anhand des Timestamps konnte ich sehen, dass sie von dem Tag waren, als 
ich hier meine letzten Erfolge mit dem senden des Befehls "2 - REQ_UD2" 
hatte.

Habe es gerade verifiziert und kann sagen, dass es nun manuell klappt!
Wenn der Adapter in ioBroker läuft und ich parallel per Console sudo 
./mbus-test -d /dev/ttyUSB0 aufrufe und den Befehl "2 - REQ_UD2" oder 
einfach mit "q" ein wakeup sende, bekomme ich immer ein Update in 
ioBroker.


Das müsste nun nur noch der Adapter selbst in regelmäßigen Abständen 
können, dann wäre es perfekt :)

EDIT: Sehe auch grad, dass ich nun auch im mbus-test Tool endlich eine 
richtige Antwort bekomme :)

[Carsten (carsten12)]

Moin,

leider kann ich noch nichts ausprobieren, ich muss jetzt erstmal auf den 
Tastkopf warten. Aber danke schon mal für die vorkompilierte Firmware, 
das erleichtert es ja um einiges.

Falls es Dir noch nicht klar ist, wie das mit den alle-4-Stunden 
funktionieren kann, der nette Kollege hat auf Github geantwortet.

Außerdem steht das M für Modus und nicht für M-Bus, also müssen wir das 
ganze mit r auslesen.

Ich bin schon so gespannt...

Gruß,
Carsten.

[Hans M. (funzel1607)]

Ich habe es jetzt erst mal mit nem Cronjob gelöst, der einfach stündlich 
das Tool startet, sodass die Daten regelmäßig abgeholt werden.

Dazu einfach

0 * * * *       ~/mbus-test/Release/mbus-test -d /dev/ttyUSB0 -n

eingetragen. Reicht als User pi.

[Hans M. (funzel1607)]

Hans M. schrieb:

> Dazu einfach
>

0 * * * *       ~/mbus-test/Release/mbus-test -d /dev/ttyUSB0 -n

>
> eingetragen.

"-n" reicht dauerhaft leider doch nicht. Kam ein paar Stunden mit 
Aussetzern und dann gar nicht mehr. Muss dann doch wieder manuell drauf 
und mit "2" aufwecken und abfragen. Gibts leider nur nicht als Parameter 
zum aufrufen.

@Stefan B. wäre es möglich, dass dein Tool auch Parameter mit wakeup 
sequence sendet?

Danke!

[Stefan B. (stefan_b278)]

Wieso verwendest du -n? Braucht das dein WMZ? Sonst nimm doch einfach -r

[Hans M. (funzel1607)]

Hatte es getestet und er antwortete eine Zeit lang darauf. Nun möchte er 
immer vorher geweckt werden, was er mit -r leider nicht wird.

[Stefan B. (stefan_b278)]

Aufwecken tut er bei beiden Parametern. Aber vielleicht braucht dein WMZ 
das hier vor dem auslesen:

SND_NKE → Single control character

This procedure serves to start up after the interruption or beginning of 
communication. The value of the frame count bit FCB is adjusted in 
master and slave, i.e. the first master telegram with FCV=1 after 
SND_NKE contains a FCB=1. The slave responds to a correctly received 
SND_NKE with an acknowledgment consisting of a single character (E5h).

Kannst du mal die Ausgabe hier reinkopieren wenn es funktioniert und 
wenn nicht? Was für ein WMZ ist das?

[Hans M. (funzel1607)]

Es handelt sich um den oben beschriebenen itron CF55. Ich habe es nun 
mal in den sudo crontab geschrieben, damit das logging einfacher ist. 
Wenn er nun mit -r aufruft und keine Daten gelesen werden können, 
schreibt er

error: no ACK, frame 0

Ich habe dann manuell mit dem Tool eine "2" und somit REQ_UD2 mit wakeup 
gesendet, woraufhin ich das hier erhalte

Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
req_ud2(): Sende Anfrage Daten Klasse 2
5 bytes sent
0 byte(s) received

Eine Minute später lief der Cron dann noch mal. Erhalte dann wieder

error: no ACK, frame 0

 im Log und keine neuen Daten in der DB

Habe dann noch mal manuell "2" gesendet und erhielt dann

Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
req_ud2(): Sende Anfrage Daten Klasse 2
5 bytes sent
198 byte(s) received
Error: -2

inkl. neuer Daten

Habe gesehen, dass er heute Nacht gegen 03:00 Uhr auch mit -r mal Daten 
bekommen hat. Aber das ist absolut unzuverlässig wenn er nur alle x 
Stunden mal mit Glück was erhält.

Ich hoffe das hilft

[Stefan B. (stefan_b278)]

Ist der im Batteriebetrieb? Dann ist wohl die Auslesehäufigkeit 
begrenzt. Wie genau weiß nur der Hersteller aber dann kannst du senden 
was du magst der Antwortet nicht. Möglich ist z.B. ein Wert von 4x am 
Tag oder so.

[Hans M. (funzel1607)]

Ja genau, ist im Batteriebetrieb. Wenn ich ihn manuell triggere, dann 
geht definitiv jede Stunde. Dass der Abruf limitiert ist, hatte ich 
schon geahnt, daher auch nur stündlicher Versuch meinerseits.

[Nick K. (nick-tech)]

hier mal die angepasste Tasmota Firmware mit:
- Möglichkeit den hardware serial port. neu zu starten ("-" vor der 
nummer des Ports), z.B. sml(-1 1 "9600:8E1")

- größerer Serial Buffer (#define SML_BSIZ 200)

wie hier besprochen https://github.com/arendst/Tasmota/discussions/17388

[Matthew F. (matthew_f)]

Entschuldige wenn ich das Thema von Tasmota wechsele. Weißt jemand was 
für einen Lesekopf/Dioden man braucht um mit den Engelmann Wasserzähler 
(nicht Wärmezähler) kommunizieren zu können? Laut Anleitung läuft der 
Datenaustausch gleich ab (mit unserem Wärmezähler erfasse ich 
erfolgreich automatisch Daten). Am Zähler sieht man die Dioden, der 
Abstand ist aber kleiner, und obwohl die kreisförmige Linie den Eindruck 
gibt, dass irgendeiner Lesekopf drauf kommen könnte/sollte, ist dieser 
Platz scheinbar nicht magnetisch wie bei den anderen Geräten.

Ein Bild ist anbei.

[Stefan B. (stefan_b278)]

Wahrscheinlich muss man den Engelmann Lesekopf hinhalten um mit der 
Engelmann Software den Zähler zu konfigurieren bzw. auszulesen. Ist aber 
wohl nicht dafür gedacht dauerhaft Daten rauszulesen.

[Matthew F. (matthew_f)]

Danke. Lustig ist aber, das in der Anleitung genau das gleiche steht mit 
4x Auslesen pro Tag. Aber ja, was das Elektronische kann widerspiegelt 
sich nicht ins Physikalische.

[Nick K. (nick-tech)]

Nick K. schrieb:
> hier mal die angepasste Tasmota Firmware mit:
> - Möglichkeit den hardware serial port. neu zu starten ("-" vor der
> nummer des Ports), z.B. sml(-1 1 "9600:8E1")
>
> - größerer Serial Buffer (#define SML_BSIZ 200)
>
> wie hier besprochen https://github.com/arendst/Tasmota/discussions/17388

Ich habe in "Version 2" vergessen die Option "USE_SML_SCRIPT_CMD" mit zu 
aktivieren. Kann also nicht funktionieren

Mit der angehängten Firmware und dem Skript unten leuchtet die IR-Led 
2,2s lang und sendet danach die Aufwachsequenz. Eine Antwort bekomme ich 
trotzdem nicht :-(

Ich sende nicht 532* "55", da das aus irgend einem Grund das Script zum 
Absturz bringt, sondern 53* "55555555555555555555" )=10x55. Ich hoffe 
das ist das gleiche..


Kann irgenjemand einen Hinweis geben wie man die Rückmeldung vom Zähler 
(so er sich denn irgendwann meldet) richtig dekodiert?
Die Tasmota Dokumentation ist hier: 
https://tasmota.github.io/docs/Smart-Meter-Interface/#meter-metrics

So soll das beispielsweise aussehen 
(https://github.com/arendst/Tasmota/discussions/17388#discussioncomment-4407236)

1,68b3b368x23uuUUUUUU@1,Energie total,,total,0 ; Total Wärmemenge
1,68b3b368x47uuUUUUUU@60,Flow F_akt,,F_akt,0 ; aktueller Flow in m^3
1,68b3b368x35uuUUUU@1,Power P_akt,,P_akt,0 ; aktuelle Wärme-Leistung
1,68b3b368x59uuUU@1,Temp Vorlauf,,Vorlauf,0 ; aktuelle Vorlauftemperatur
1,68b3b368x63uuUU@1,Temp Rückl,,Rückl,0 ; aktuelle Vorlauftemperatur
1,68b3b368x67uuUU@1,Temp Diff,,Diff,0 ; aktuelle Differenz Vorlauf/Rücklauftemperatur

>D
;start, define variables
wkup=1

>B
;setup sensor
->sensor53 r

;>BS
;print start
;delay(5000)
;print waited 5s, call subroutine

>F
if upsecs%60==0 {
print read meter
=#readmeter
}
#

#readmeter

print wakeup start
;set serial protocol
sml(-1 1 "2400:8E1")

;send 0x55 for 2,2 seconds with 8E1 (53x), 2400 baud (wakeup sequence)
for wkup 1 53 1
sml(1 1 "55555555555555555555")
next
print wakeup end
wkup=1

print wait for the meter
;wait for the meter to wake up
delay(350)

;switch serial protocol
sml(-1 1 "2400:8N1")
print request data
;set string to send to "105BFE5916" (request data)
sml(1 1 "105BFE5916")



>M 1
+1,3,rE1,0,2400,WAERME,1
;Sensor 1: 8E1
;1,68b3b368x23uuUUUUUU@1,Energie total,,total,0 ; Total Wärmemenge
#

[Hans M. (funzel1607)]

Scheint jetzt doch relativ stabil zu laufen, wenn man ihn allein machen 
lässt und zwischendrin nicht noch manuell triggert. Habe fast jede 
Stunde einen Wert.

Habe nun folgendes im sudo crontab:

0 * * * *       /home/pi/mbus-test/Release/mbus-test -d /dev/ttyUSB0 -r >> /var/log/cronlog.log 2>&1

[Carsten (carsten12)]

Moin Nick, danke für die V3. Ich hatte am Wochenende leider :-D viel 
Besuch und konnte den Kopf bislang erst nur mit meinem Stromzähler 
ausprobieren. Nun wollte ich die V3 gerade mal flashen, aber da war ja 
noch das Problem mit dem Speicher...wenn ich zuerst aber die -minimal 
Version flashe kommt die gleiche Fehlermeldung. Du machst das doch via 
Upgrade der Webseite des Device, oder? Also Upload aus Datei? Oder?

Ich werde mich dann gleich daran setzen, das für den Elster 96 Plus 
baugleich Sharks 775 zu implementieren, Aufwecken und auslesen ist sehr 
ähnlich zu Deinem Zähler. Mein Vorteil: ich habe eine Beschreibung des 
Protokolls vom Hersteller geschickt bekommen. Aber daraus lässt sich 
vielleicht auch für Dich was lernen.

Allerdings wirft mich das jetzt zurück, wenn ich den ESP01s jetzt erst 
noch per Kabel flashen muss...ich finde meinen USB nach Seriell Wandler 
grad net.

Schönen Abend noch,
Carsten.

[Nick K. (nick-tech)]

Ich bekomme eine Antwort (mit "Firmware V3")!
Ich hatte die Parität verkehrt herum gesetzt :-(

Jetzt muss ich das "nur" noch dekodieren

So sehen die Antworten aus:

19:26:08.372 read meter
19:26:08.374 wakeup start
19:26:10.552 wakeup end
19:26:10.554 wait for the meter
19:26:10.907 request data
19:26:11.178 : 68 4d 4d 68 08 00 72 84 03 36 20 92 26 17 04 09 00 00 00 0c 78 84 03 36 20 04 06 aa 63 00 00 0c 14 69 75 08 00 0b 2d 00 
19:26:11.224 : 00 00 0b 3b 00 00 00 0a 5a 09 
19:26:11.268 : 05 0a 5e 95 02 0b 61 41 21 00 
19:26:11.313 : 04 6d 11 14 d2 2c 02 27 2c 
19:26:11.356 : 04 09 fd 0e 07 09 fd 0f 11 0f 
19:26:11.400 : 00 00 ab 16 

19:35:10.436 read meter
19:35:10.437 wakeup start
19:35:12.618 wakeup end
19:35:12.620 wait for the meter
19:35:12.973 request data
19:35:13.147 : 68 4d 4d 68 08 00 72 84 03 36 20 92 26 17 04 0b 00 00 00 
19:35:13.276 : 0c 78 84 03 36 20 04 06 aa 63 00 00 0c 14 69 75 08 00 0b 2d 00 00 00 0b 3b 00 00 00 
19:35:13.320 : 0a 5a 80 04 0a 5e 02 03 0b 61 
19:35:13.365 : 72 17 00 04 6d 1a 14 d2 2c 
19:35:13.410 : 02 27 2c 04 09 fd 0e 07 09 fd 
19:35:13.453 : 0f 11 0f 00 00 c1 16

Das ist der Code:

>D
;start, define variables
wkup=1


>B
;setup sensor
->sensor53 r

>S
; read meter every 60 seconds
if upsecs%60==0 {
print read meter
=#readmeter
}
#

#readmeter

print wakeup start
;set serial protocol
sml(-1 1 "2400:8N1")

;send 0x55 for 2,2 seconds with 8N1 (53x), 2400 baud (wakeup sequence)
for wkup 1 53 1
sml(1 1 "55555555555555555555")
next
print wakeup end
wkup=1

print wait for the meter
;wait for the meter to wake up
delay(350)

;switch serial protocol
sml(-1 1 "2400:8E1")
print request data
;set string to send to "105BFE5916" (request data)
sml(1 1 "105BFE5916")



>M 1
+1,3,rE1,0,2400,WAERME,1
;Sensor 1: 8E1
;1,68b3b368x23uuUUUUUU@1,Energie total,,total,0 ; Total Wärmemenge
#

[Carsten (carsten12)]

Also in meiner Spec vom Elster steht im Wesentlichen was von Aufwecken, 
was man ihn fragen kann und was er antwortet. Ich denke wie er 
antwortet steht hier irgendwo: https://m-bus.com/documentation aber
das habe ich noch nicht gelesen.

GrC.

[Nick K. (nick-tech)]

@Carsten: du musst erst die minimal version flashen, das geht über das 
Webinterface. Ich hatte in der Vergangenheit das Problem dass das 
fehlschlug wenn ich hier direkt die URL angegeben habe. Upload von Lokal 
hat immer geklappt.

Zum Thema:
Ich bekomme nun zuverlässig Antworten vom Zähler und kann diese auch 
dekodieren bis auf ein paar Ausnahmen (siehe Script unten).

so sieht das Ergebnis aus:

WAERME Total energy   25523 kWh
WAERME Total volume   875.99 m³
WAERME Current power   0 W
WAERME Current flow   0.000 m³/h
WAERME Flow temp   58.1 °C
WAERME Return temp   47.1 °C
WAERME Temp diff   11.27 °C
WAERME Time           33330001
WAERME Meter days   1068 d

Erkenntnisse:
- mir hat es geholfen die Nachricht manuell zu "zerlegen" (siehe Anhang)
- Tasmota kann auch BCD (https://de.wikipedia.org/wiki/BCD-Code) 
dekodieren, das ist aber (noch) nicht dokumentiert
- mir ist noch nicht klar wie der Zeitstempel dekodiert werden muss. Was 
bedeutet "36 07 C5 2C"?

Aus Stefan B.'s Programm ist mir klar, dass die einzelnen bytes 
irgendwie für Minuten, Stunden, Tage, Monate und Jahre stehen:

else if (t_data_size == 4)           // Type F = Compound CP32: Date and Time
    {
      if ((t_data[0] & 0x80) == 0)     // Time valid ?
      {
        t->tm_min = t_data[0] & 0x3F;
        t->tm_hour = t_data[1] & 0x1F;
        t->tm_mday = t_data[2] & 0x1F;
        t->tm_mon = (t_data[3] & 0x0F) - 1;
        t->tm_year = 100 + (((t_data[2] & 0xE0) >> 5) | ((t_data[3] & 0xF0) >> 1));
        t->tm_isdst = (t_data[1] & 0x80) ? 1 : 0;  // day saving time
      }
    }

>D
;start, define variables
wkup=1


>B
;setup sensor
->sensor53 r

>S
if upsecs%3600==0 {
print read meter
=#readmeter
}
#

#readmeter

print wakeup start
;set serial protocol
sml(-1 1 "2400:8N1")

;send 0x55 for 2,2 seconds with 8N1 (53x), 2400 baud (wakeup sequence)
for wkup 1 53 1
sml(1 1 "55555555555555555555")
next
print wakeup end
wkup=1

print wait for the meter
;wait for the meter to wake up
delay(350)

;switch serial protocol
sml(-1 1 "2400:8E1")
print request data
;set string to send to "105BFE5916" (request data)
sml(1 1 "105BFE5916")



>M 1
+1,3,rE1,0,2400,WAERME,1
;Sensor 1: 8E1

;Meter,%DataField%Unit%Value@%factor,%Screenname,%Unit,%MQTTname,%decimals
;%DataField describes lenght and encoding (UUuu, uuUU, bcd4/6/8)
1,0406uuUUUUUU@1,Total energy,kWh,w_total,0
1,0C14bcd8@100,Total volume,m³,v_total,2

1,0B2Dbcd6@0.01,Current power,W,p_act,0
1,0B3Bbcd6@1000,Current flow,m³/h,F_akt,3

1,0A5Abcd4@10,Flow temp,°C,t_flow,1
1,0A5Ebcd4@10,Return temp,°C,t_return,1
1,0B61bcd6@100,Temp diff,°C,t_diff,2

1,046Dbcd8@1,Time,,time,0
1,0227uuUU@1,Meter days,d,OpDays,0 
#

[Nick K. (nick-tech)]

Nachdem das auslesen des Zählers nun klappt, habe ich noch zwei Fragen:

1. Wie wird der Zeitstempel dekodiert? In der Mbus-DOkumentation steht 
das im Anhang, aber ich kriege das nicht mit dem Telegramm zusammen.
So weit ich das verstehe müsste der "Burgunderrote Block" ab Zeile 7 ab 
"x04 x6D" für den Zeitstempel stehen. x36 müssten die Minuten sein und 
x07 die Stunden. --> 07h 54min ist das korrekt? Die dekodierte Zeit ist 
immer eine Stunde früher und ca. 10 Minuten später als es tatsächlich 
ist. Könnte auch eine falsche Zeitzone und eine falsch eingestellte 
Uhrzeit sein..
So sieht der Teil des Scripts dazu aus:

1,046Dxxuu@1,Hour,h,time_h,0
1,046Duu@1,Minute,min,time_m,0

Für das Datum habe ich noch überhaupt keine Idee.

2. Kann jemand ein Setup empfehlen für eine 
Datenbank(influxdb?)/MQTT-Broker(mosquitto?)/Anzeige(grafana?) mit der 
man die nun gewonnenen Daten schön aufbereiten kann? Am wichtigsten wäre 
dass gut dokumentiert ist was man da machen muss um das einzurichten.

[Stefan B. (stefan_b278)]

Naja steht doch genau beschrieben. Ein Byte nehmen, mit der Maske 
verodern und evtl. noch schieben.

Mosquitto ist super, dann per Script oder NodeRED oder telegraf in 
influxdb reinschreiben.
Grafana zeigts dann hübsch an.

[Klaus (feelfree)]

Nick K. schrieb:
> Wie wird der Zeitstempel dekodiert?

Einen Beitrag weiter oben hast du einen Schnipsel C-code gepostet, der 
das perfekt erklärt.
Welches Konstrukt davon verstehst du nicht?

[Stefan B. (stefan_b278)]

Komischerweise funktioniert der Code so, ist auch aus dem libmbus 
Projekt geklaut. Aber die Spezifikation sieht anders aus z.B. bei den 
Minuten ist bit 0 nicht dabei..

[Klaus (feelfree)]

Die Spec die oben als Bild eingefügt ist zählt die bits 1..32 statt 
0..31.
Dann passt es doch perfekt zum code.

[Carsten (carsten12)]

Moin, jetzt ein Update von meiner Seite:

ich habe den Hichi WIFI Schreib/Lesekopf, der aus einem TTL-Lesekopf und 
einem ESP01s besteht. Software nun (via tasmota-minimal per Web-URL) die 
tasmota V3 von Nick, welche SML Scripting eingeschaltet und einen 
vergrößerten Serial Buffer hat. Das neue Feature "Parity Umschalten" ist 
seit 12.2 mit drin. Der Zähler ist ein Elster 96 Plus baugleich Sharky 
775.

Natürlich passierte gar nichts. Dass der Kopf was tut konnte ich mit dem 
Messer-Test sehen, aber der Zähler tat so, als wenn er nichts davon 
mitbekommt.

Also folgte ich Nicks Weg und schloss den TTL-Teil des Kopfes via eines 
TTL-USB Adapters an ein hier rumliegendes Armbian System an und nutzte 
die M-BUS Software von Stefan B. Siehe da, es flutscht:

C-Field:    0x08
Primary Adress:    0x00
Ci-Field:    0x72
variable Antwort, fixed header 12 Bytes

DIF 0C
VIF 06
  function_field:  00
  data_length:  4
  data_field:  0C
  unit:    06
  data bytes: 62 00 04 00 
  Instantaneous value
  Energy (kWh)
  mbus_parse_data_field: DIF 0x0C was decoded using 8 digit BCD
  result: 40062  factor 1.000000  n: 3  neg 0

Hier nur mal das Beispiel des ersten VIF. Da mein Zähler auf 40.062 MW/h 
steht bin ich erstmal glücklich.

Dann folgte ich Nicks Weg der Decodierung im Datenstrom, da wir das in 
Tasmota über so eine Art Pattern-Matching machen müssen. Das hat auch 
ganz gut geklappt, ohne dass ich die gesamte M-Bus Spec lesen musste, 
man kann es gut aus dem Output von Stefan B.s Software herauslesen.

Im nächsten Schritte gedenke ich den ESP01s wieder einzusetzen. Ich habe 
mbus-test ohne Änderung mit -r aufgerufen, um an die Ergebnisse zu 
kommen. Nun werde ich mal in die Software schauen, was genau da so 
abgeht. Ich denke:

  - Aufwachsequenz [55]..[55] 2400 8N1
  - [68][04][04][68][53][FE][50][00][A1][16] 2400 8E1 -> ACK
  - [10][5B][FE][59][16] -> Daten
  - zB Suchen nach [00][0C] -> Akkumulierte Energie 8 digit BCD

Merkwürdig ist nur, dass das vorhin geklappt hat und nun wieder nicht. 
Wahrscheinlich macht der sehr selten mit um seine Batterie zu sparen.

Ich habe ja die Datenspec des Zähler von einem Mitarbeiter der Firma 
bekommen, der gleich sagte, ich sollte das bitte nicht so oft machen 
:-).

Hier notiert um andern Leidensgenossen zu helfen.

Gruß,
Carsten.

[Carsten (carsten12)]

Hallo, ich brauche noch mal Hilfe.

Ich habe den Lesekopf wieder an den ESP01s angeschlossen, auf dem die V3 
von Nick läuft. Nachdem ich die Messages dekodieren konnte, verwende ich 
nun folgendes Script:

>D
;start, define variables
cnt=0

>B
;setup sensor
->sensor53 r

>S
if upsecs%10==0 {
print read meter
=#readmeter
}
#

#readmeter

print wakeup start
;set serial protocol
sml(-1 1 "2400:8N1")

;send 0x55 for 3,0 seconds with 8N1 (72x), 2400 baud (wakeup sequence)
for cnt 1 72 1
sml(1 1 "55555555555555555555")
next
print wakeup end

print wait for the meter
;wait for the meter to wake up
delay(350)

;switch serial protocol
sml(-1 1 "2400:8E1")
print request data
;reset application code
;sml(1 1 "6804046853FE5000A116"
;set string to send to "105BFE5916" (REQ_UD2)
sml(1 1 "105BFE5916")

>M 1
+1,3,rE1,0,2400,WAERME,1
1,0C06bcd8@1,Total Energy,kWh,w_total,0
1,0C13bcd8@1000,Total volume,m³,v_total,2

1,0C2Bbcd8@1,Current power,W,p_act,0
1,0B3Bbcd6@1000,Current flow,m³/h,F_akt,3

1,0A5Abcd4@10,Flow temp,°C,t_flow,1
1,0A5Ebcd4@10,Return temp,°C,t_return,1
1,0A62bcd4@10,Temp diff,°C,t_diff,2
#

Mit einem weniger aggressiven Timing (alle 10 Sekunden) habe ich das am 
Wärmezähler probiert, aber es kam nichts. Weil nach Eingabe von sensor53 
d1 keine Daten empfangen wurden, habe ich das Teil in meine Bastelbude 
geholt und lasse das nun alle 10 Sekunden laufen, um es zu testen.

Ich sehe mit dem Handy, dass er etwas sendet. Allerdings kann ich auch 
mit einem glänzendem Messer nicht provozieren, dass ich wenigstens die 
gesendeten Daten empfange...habe ich da irgendwo versehentlich was 
verstellt, einen GPIO Pin für Empfang oder so? Ist es doch nicht die 
richtige Firmware?

Ich bin verwirrt, hat jemand eine Idee zum Debuggen? Wenn ich ein Budget 
für die Anzahl der Auslosungen habe und das beim Testen heute morgen mit 
mbus-test zufällig gerade aufgebraucht war, würde der Zähler dann so 
reagieren? Aber ich meine, er reagiert ja gar nicht. Hmmm.

Gruß,
Carsten.

P.S.: den Code 6804046853FE5000A116 habe mal drin und mal draußen 
gehabt, bei meinen Tests heute morgen mit mbus-test wurde das beim 
Aufruf mit -r auch nicht mehr gesendet, ein einfaches REQ_UD2 
Kurztelegramm scheint auszureichen.

[Carsten (carsten12)]

Also, ich habe den Kopf jetzt noch einmal mit einem Stromzähler 
überprüft und der antwortet brav, ein Defekt des Kopfes bzw. der Tasmota 
Software können also ausgeschlossen werden. Ich habe dann 24 Stunden 
gewartet bevor ich es erneut ausprobiert habe, wieder keinen Erfolg 
gehabt. Ich bin ratlos. Es scheint an der "Übersetzung" von mbus-test 
zum Tasmota-Script der Aufwecksequenz zu liegen.

Gruß,
Carsten.