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.

[Jan S. (john85)]

Hallo Carsten,

bist du dir sicher, dass die von 2.2 auf 3.0s geänderte Aufwachsequenz 
so wirklich richtig ist für deinen Zähler?

Also ich bin jetzt absolut begeistert, denn mit Nicks V3 und eurer 
restlichen Arbeit hier (Tasmota "support" etc.) hab ich es jetzt recht 
einfach mit Tasmota ans laufen bekommen.

Die unterschiedlichen Paritäten 8N1 / 8E1 hab ich damals glaub überhaupt 
nicht beachtet, oder kann mich nicht mehr erinnern.

Läuft jetzt so:

>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,0C78bcd8@1,ModuSeriennummer,,serialnum,0
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,°K,t_diff,2
1,046Dbcd8@1,Time,,time,0
1,0227uuUU@1,Meter days,d,OpDays,0
1,09FD0Euu@1,Firmware Version,,FW_Version,0
1,09FD0Fuu@1,Software Version,,SW_Version,0
1,684d4d68080072x4uuUU@1,Manufacturer,,manufacturer,0
1,684d4d68080072x4x2uu@1,Generation,,generation,0
1,684d4d68080072x4x2x1uu@1,Medium,,media,0
1,684d4d68080072x4x2x1x1uu@1,Zaehler Auslesungen,,cnt_read,0
1,684d4d68080072x4x2x1x1x1uu@1,Fehlerbyte,,Error_State,0
#

Müsste / könnte man die Kopfdatenabfrage noch vereinfachen in einer 
Zeile?

Vielen Dank für alles!

Muss nur noch das verschicken der Daten an FHEM per MQTT optimieren, da 
anfangs immer noch 0-Werte verschickt werden. (z. B. nach jeder Script 
Bearbeitung).
Hab ich zwar in FHEM per readingsChange für den Zählerstand umgangen, 
aber das ist ja trotzdem igendwie Mist.

Kann MQTT ab boot deaktivieren:

;disable publishing at MQTT teleperiod, on boot
smlj=0

 aber mir fehlt noch ne tollere Alternative anstatt es nach bestimmter 
Zeit wieder zu aktivieren:

;re-enable publishing at MQTT teleperiod, after 10 seconds of uptime
if upsecs>10
then
smlj|=1
endif

Besser als es dauernd zu deaktivieren, wäre es ja die Nachricht
abzuschicken, sobald gültige Daten empfangen wurden.

Geht das mit

Publish

auch in dem SMI Script >S Bereich?

https://tasmota.github.io/docs/Commands/#mqtt

Gruß,
Jan

[Carsten (carsten12)]

Hallo Jan,

ja ich orientiere mich bei der Anpassung meines Scripts an mbus-test und 
da ist das so und funktionierte ja auch.

Ich bin noch einmal auf Schritt Null zurück gegangen, damit ich 
ausschließen kann, dass ich zwischendurch mal irgendwas kaputt gespielt 
habe. Obwohl ich in ganz extremen Kopfpositionen die Reflexionen meiner 
Kommandos "sehen" konnte. Aber dennoch:

1. Kopf wieder an den Stromzähler. Da empfängt er passiv mit Tasmota 
alles, was der Zähler freiwillig herum plärrt. Ich weiß jetzt auch, dass 
der Kopf nicht kritisch auf Mikrometer positioniert werden muss, einfach 
in den runden Anschlag reinsetzen, Kabel nach untern.

2. Im Kopf esp01s abgezogen und via USB-Serial ans Armbian und mit 
mbus-test -d /dev/ttyUSB0 -v -v -vv -r alles komplett ausgelesen. 
Funktioniert einwandfrei. Und ja, ich weiß nicht ob -v -v oder -vv aber 
so ist es egal, denn es protokolliert alles schön mit.

  a) Port 8N1
  b) Aufwachsequenz (722 x 0x55)
  c) Warte 350ms
  d) Port 8E1
  e) wir senden SND_UD 0 0x6804046853FE5000A116
  f) wir empfangen ein 0xE5 ACK
  g) wir senden REQ_UD2 0x105BFE5916
  h) und der Zähler quasselt los.

3. Bei Tasmota sehe ich trotz sensor53 d1 kein ACK! Das führte soweit, 
dass ich dachte der Kopf funktioniert nicht mehr, deshalb bin ich zu 
Schritt Null zurück.

4. Also doch ein generelles Problem mit der seriellen Kommunikation? 
Also Tasmota V3 von Nick erneut geflasht. Dann (sorry Nick) Tasmota 
selber mit SML und vergrößertem seriellen Buffer übersetzt. Nix, nix 
nix.

Meine Schlussfolgerung daraus ist, dass der Zähler durch Tasmota nicht 
aufgeweckt wird. Ich bin schon kurz davon einfach einen Sketch in der 
Arduino IDE zu basteln und auf das Ding zu flashen.

Also, falls noch jemand eine Idee hat, wie man die 0x55 sonst noch in 
dieser merkwürdigen Schriftsprache rauszuhauen: gerne.

Ansonsten wünsche ich allen hier ein frohes Fest, bastelt nicht so viel 
;o).

Carsten.

[Stefan B. (stefan_b278)]

Freut mich, daß wenigstens mein Programm funktioniert. Mit dem Tasmota 
kann ich nicht helfen..

[Carsten (carsten12)]

Ich konnte es nicht lassen und habe weiter probiert. Folgende 
Merkwürdigkeit ist mir aufgefallen. Nicks Log zeigt:

19:26:08.372 read meter
19:26:08.374 wakeup start
19:26:10.552 wakeup end

Man sieht, dass das Senden des Wakeup 2,2 Sekunden dauert. Bei mir:

17:55:28.413 read meter
17:55:28.415 wakeup start
17:55:28.420 wakeup end

Ist ein wenig schnell...obwohl die LED auch 2,2 bzw 3 Sekunden lange im 
Handytest leuchtet. Trotzdem merkwürdig...

Carsten.

[Carsten (carsten12)]

Hallo,

ich bin weinen Schritt weiter, witzig, dass alles so wie bei Nick läuft. 
Die gute Seele auf GitHub (siehe obiger Thread) hat mir ein wenig 
geholfen und nun bekomme ich:

22:00:16.959 read meter
22:00:16.961 wakeup start
22:00:20.255 wakeup end
22:00:20.257 wait for the meter
22:00:20.609 request data
22:00:20.769 : 68 94 94 68 08 
22:00:20.814 : 00 72 02 13 49 44 93 15 2f 
22:00:20.858 : 04 73 00 00 00 0c 06 04 02 04 
22:00:20.901 : 00 8c 10 06 00 00 00 00 8c 
22:00:20.944 : 20 13 03 00 00 00 0c 13 24 05 
22:00:20.988 : 13 01 0c 2b 52 16 00 00 0b 
22:00:21.030 : 3b 36 00 00 0a 5a 99 06 0a 5e 
22:00:21.075 : 03 03 0a 62 97 03 0a 27 01 
22:00:21.118 : 17 04 6d 25 17 d7 2c 4c 06 43 
22:00:21.162 : 80 03 00 4c 13 22 09 07 01 
22:00:21.204 : cc 10 06 00 00 00 00 cc 20 13 
22:00:21.249 : 03 00 00 00 42 6c df 25 42 
22:00:21.292 : ec 7e ff 25 cc 01 06 44 33 03 
22:00:21.337 : 00 cc 01 13 76 06 93 00 cc 11 
22:00:21.381 : 06 00 00 00 00 cc 21 13 02 
22:00:21.424 : 00 00 00 c2 01 6c bf 2c c2 01 
22:00:21.473 : ec 7e df 2c 54 16

Des Rätsels Lösung war, dass er das SND_UD 0 doch nicht mag. Und ich 
hatte noch eine Option Beinm selber kompilieren vergessen, nun ja, Wald 
vor lauter Bäumen und so...

Die Antwort mit Tasmota deckt sich mit mbus-test und ich erkenne die 
Sequenzen:

22:00:20.858 0c 06 dem BCD8@1 04 02 04 00 = 00040204 kWh total Energy 
folgt, was richtig ist, aber irgendwie nicht in Tasmota ankommt.

Ist die Zeile

1,0C06bcd8@1,Total Energy,kWh,w_total,0

nicht richtig?

Analog 22:00:21.030 0a 5a gefolgt von BCD4@10 99 06 = 60.9°C

Das ist das gleiche wie bei Nick:

1,0A5Abcd4@10,Flow temp,°C,t_flow,1

Wer macht mein persönliches Weihnachtswunder wahr? Ich sehe nichts, ich 
rufe das alle 60 Sekunden auf, telemetry period steht auch auf 60, er 
liest es einfach nicht...

Trotzdem danke an alle, vor allem Steffen B für diese wunderbare 
Software!

Gruß,
Carsten.

[Carsten (carsten12)]

Halt, alles zurück, Tasmota brauchte nur ein wenig Zeit, es läuft!!!

Anbei also ein Laufens Script für den Elster 96 Plus baugleich Sharky 
775.

Nun kann es Weihnachten werden :-)

[Nick K. (nick-tech)]

Hallo Carsten,
Sorry, komme erst heute zum antworten:

Befehle die man per sml(1 1 „xxx“) sendet, sieht man bei tasmota nicht 
mit „Sensor53 d1“ (warum auch immer)

Bei mir hat es sich nicht geklappt 700x x55 zu senden, deswegen 70x 
„55555555555555555555“. Warum das so ist weiß ich allerdings auch nicht

[Matthias (Gast)]

Hallo,
ich möchte das ganze mit Tasmota für meinen Allmess Integral-V UltraMess 
Pro nachbauen. Welchen Lesekopf brauche ich? Sollte ich einen mit 
Seriellen Ausgang verwenden oder was habt ihr verwedet. Das wird mir aus 
dem Thread nicht klar, da ja weit oben auch über verschiedene 
Wellenlängen gesprochen wird.
Schonmal Danke für eure tolle Arbeit. Wenn ich einen Tastkopf habe muss 
ich es nur noch hinbekommen Tasmota über mqtt zu Triggern da der 
Zählerstand bei mir nur erfasst werden soll bevor die Heizung anspringt.

[Carsten (carsten12)]

Also ich habe einen Kopf von Hichi verwendet. Er bietet welche mit 
aufgestecktem esp01s in der Bucht an, das ist ganz praktisch. Dann hast 
Du den Mikrocontroller gleich mit im 3D Druck Gehäuse.

Alternativ hat er auch TTL Versionen, die Du an einen Microcontroller 
Deiner Wahl anschließen kannst. Mit USB gibt es auch welche, TTL und USB 
könnten dann auch an einen Raspberry Pi oder was auch immer.

Ist letzlich ne Geschmacksfrage. Gibt auch andere Anbietet aber Hichi 
hat einen fairen Preis und liefert sehr schnell.

Gruß,
Carsten.

[Christoph (pidelta)]

Hallo,
echt super Arbeit. Mit den Infos konnte ich nun endlich auch meinen 
Sensus PolluCom mit Hichi Wifi Lesekopf auslesen. Ich hatte es schon mit 
einem Python Script 
(https://forum.iobroker.net/topic/32722/smart-meter-sensus-pollucom-e/5) 
und USB-Lesekopf am Raspi geschafft.

Ich habe das Script für Tasmota SMI mal angehängt, vielleicht hilft es 
ja auch anderen.

Einzig die Decodierung der Temperaturdifferenz ist mir nicht gelungen. 
Ich habe hier 
https://wiki.volkszaehler.org/hardware/channels/meters/warming/sensus_pollucom 
einen Mitschnitt gefunden und anhand dessen die Codes angepasst aber bei
03       DIB INT-24
 60       VIB Temperaturdifferenz (K)
komme ich nicht weiter. Es handelt sich ja weder um ein "word" noch um 
ein "long word". Hat da jemand eine Idee?
1,0360uuUU@10,Temp diff,°C,t_diff,2  -> geht nicht
1,0360uuUUuuUU@10,Temp diff,°C,t_diff,2 -> geht nicht


VG
Christoph

[Martin R. (rogi1)]

Hallo,

habe ich eine Chance, einen Diehl Metering RAY (Jahr 2016) über die IR 
Schnittstelle auszulesen? Ich habe im Internet nur wirklich sehr wenig 
dazu gefunden. Laut Hersteller handelt es sich um folgende 
Schnittstelle:

"VEI Schnittstelle zur Kommunikation, M-Bus Protokoll"

Danke für eure Hilfe

Martin

[Carsten (carsten12)]

Ich denke, du könntest es versuchen. Denn VEI klingt verdächtig nach 
ZVEI und dann wäre es genau wie der Elster.

GrC

[Urs P. (naseweiss)]

Nur als Kreuzreferenz.
Ich habe einen Sensostar U mit drahtgebundenem MBus an Tasmota 
erfolgreich angeschlossen und dekodiert. Siehe 
https://github.com/arendst/Tasmota/discussions/17228

Me. Muss für ein mit Infrarot verbundenes Tasmota "nur" die 
Aufwachsequence auf vielen 55 hex gesendet werden.
Das brauchte ich aber nicht zu machen, auch wenn ich das erst glaubte.
Hier eine kleine Doku meiner Tests - auch mit dem unnötigen 55 hex 
vornweg.


https://forum.creationx.de/forum/index.php?thread/1095-d0-z%C3%A4hler-sml-auslesen-mit-tasmota/&pageNo=91

[Thomas (Gast)]

Christoph schrieb:
> Hallo,
> echt super Arbeit. Mit den Infos konnte ich nun endlich auch meinen
> Sensus PolluCom mit Hichi Wifi Lesekopf auslesen. Ich hatte es schon mit
> einem Python Script
> (https://forum.iobroker.net/topic/32722/smart-meter-sensus-pollucom-e/5)
> und USB-Lesekopf am Raspi geschafft.
>
> Ich habe das Script für Tasmota SMI mal angehängt, vielleicht hilft es
> ja auch anderen.
>
> [...]
>
> VG
> Christoph

Hallo zusammen,

ich möchte schon seit einiger Zeit meinen WMZ Sensus Pollucom C/S-RA in 
ioBroker integrieren. Mit Freude habe ich den Post hier gesehen. Leider 
funktioniert dieses Skript bei mir nicht:

13:10:02.523 read meter
13:10:02.525 wakeup start
13:10:02.108 wakeup end
13:10:02.110 wait for the meter
13:10:03.349 request data
13:10:12.402 read meter
13:10:12.405 wakeup start
13:10:12.988 wakeup end
13:10:12.990 wait for the meter

Als Lesekopf habe ich den IR Lesekopf mit ESP01s von Hichi. FW habe ich 
die Tasmota v3 von Nick drauf.

Wenn ich den Lesekopf an den PC mit minicom3 anschließe, wird alles 
problemlos ausgelesen. Also liegt es nicht am Lesekopf oder Position 
dessen Position.
In der Software sind der Pollucom E und C zusammengefasst.

@Christoph: Ist bei deinem Skript noch etwas anzupassen?

Viele Grüße
Thomas

[Carsten (carsten12)]

Ich bin unterwegs, deshalb nur kurz… Der Zeitraum zwischen start und end 
wake up ist zu kurz. Firmware selber übersetzt? Vlt eine Option 
vergessen?
GrC

[Thomas (Gast)]

Stimmt, das sind keine 3s. Ich habe die wakeup Sequenz aus deinem 
Beitrag 
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen" 
übernommen.
Sonst ist das Skript weiter wie von Christoph: 
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"

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
cnt=1

Ausgabe jetzt:

14:14:32.658 read meter
14:14:32.660 wakeup start
14:14:35.625 wakeup end
14:14:35.627 wait for the meter
14:14:35.981 request data

Es passen zwar jetzt die 3s, aber es ist immer noch die Dauerschleife.

Als Firmware habe ich Tasmota bin aus dem Beitrag 
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"

[Christoph (pidelta)]

Bevor der Sensus überhaupt irgendwas von sich gibt muss er erstmal durch 
drücken der Taste am Gerät "aktiviert" werden. Wenn ich mich richtig 
entsinne muss dann innerhalb 30 min oder 1h eine Auslesung per IR 
erfolgen, ansonsten legt er sich wieder schlafen und reagiert nicht auf 
Anforderungen per IR. Zur wakeup sequenz: meiner Erfahrung nach braucht 
der Sensus 132x die Aufwachsequenz "55"
("55555555555555555555" geht auch aber nur dann wenn ich das auch 132x 
sende, keine Ahnung warum, habe ich auch nur durch probieren 
herausgefunden. 72x "55555555555555555555" geht bei mir auf jeden Fall 
nicht)

[Thomas (Gast)]

Genau, nach Betätigung der Taste wartet der WMZ eine Stunde auf Signale. 
Bei jedem Befehl über IR beginnt die Stunde erneut. Das habe ich 
berücksichtigt.

bei 132x "55" ist die WakeUp Sequenz nur knapp 0,6 sek lang:

15:34:57.123 read meter
15:34:57.125 wakeup start
15:34:57.708 wakeup end
15:34:57.710 wait for the meter
15:34:58.063 request data

bei 132x"55555555555555555555" (20x5) sind es etwa 5 sek. Aber es bleibt 
dabei, dass keine Werte angezeigt werden.

Kann ich mir durch das Skript in der Console anzeigen lassen, ob 
überhaupt eine Antwort kommt und was der WMZ sendet?

[Thomas (Gast)]

@christoph, welche version von Tasmota hast du drauf? Hast du die v3 von 
Nick oder selbst kompiliert?

[Christoph (pidelta)]

Ich habe die v3 von Nick

[Carsten (carsten12)]

Anzeige der empfangenen Daten durch Eingabe von

sensor53 d1

in der Console.

GrC

[Thomas (Gast)]

Nach der Eingabe von "sensor53 d1" kommt zwar die Ausgabe, dass es 
angenommen wurde, aber es wird nichts vom WMZ ausgegeben.

Ich verstehe es nicht. Hab die gleiche Tasmota Version und Skript wie 
Christoph, der Lesekopf an sich funktioniert (kann den WMZ mit dem PC 
und minicom3 auslesen), entsprechend ist auch die Position des Kopfes 
richtig.

Habt ihr ne Idee, wie ich der Lösung näher kommen kann?

[Christoph (pidelta)]

Hm, der Hichwi Wifi Kopf ist um 180° gedreht. Bei der Hichi USB-Variante 
geht das Kabel nach unten bei der Wifi Variante muss der USB-Anschluss 
nach oben Richtung Display. Hat mich auch ein wenig Nerven gekostet. 
Schon mal 180° gedreht probiert?

[Nick K. (nick-tech)]

Hallo Zusammen,

bisher habe ich meinen Wärmezähler einfach periodisch alle X Sekunden 
ausgelesen. Je nachdem wann man das Skript initial gestartet hat, waren 
die Zeitpunkte also mehr oder weniger "ungerade". z.B. eine Auslesung um 
18:37, eine um 19:37, je nach dem wann man das Script gestartet hat.

Mit dem Code unten wird das auslesen immer zur vollen Stunde gestartet. 
Mit `period=120` dann eben um 02:00, 04:00 und so weiter.

Hat schon jemand erfolgreich mit der Tasmota Scriptsprache den 
Zeitstempel dekodiert?

>D
;start, define variables
wkup=1
period=60
;read meter every n minutes after midnight (60 --> 01:00, 02:00...)
blk=0


>B
;setup sensor
->sensor53 r

>S
if time%period==0 
and blk==0
;minutes since midnight divided by period have a remainder of "0"
then
=#readmeter
blk=1
;set a flag to execute the readout only once every period
endif

if time%period-1==0 
and blk==1
;one minute after we entered the first loop
then
blk=0
; reset the flag
endif

#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,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,0227uuUU@1,Meter days,d,OpDays,0

1,046Dxxuu@1-1,Hour,h,time_h,0
1,046Duu@1,Minute,min,time_m,0
1,046Dxxxxuu@1,Day,dd,time_d,0
1,046Dxxxxxxuu@1,Month,mm,time_m,0
#

[EGS (Gast)]

Hat der WMZ eine Pufferzelle oder die an eine Mono (D-) Zelle erinnernde 
Batterie?

Wenn die Pufferzelle leer ist oder kurz davor, verweigern die Sensus 
Pollu WMZ die Kommunikation. Soll sicherstellen, dass der Zähler 
weiterzählt. Mesitens sind die WMZ dann aber schon älter (5-8 Jahre).

Habe bei einem Kunden 25 Sensus WMZ, drahtgebundener M-Bus, nur 
Pufferzelle (sieht aus wie nen Supercap). Nach anfänglich stündlichen 
Abfragemöglichkeit nur noch 1-mal täglich. Nach 1 Jahr keine Daten mehr 
auf dem M-Bus. Einzige Lösung neue Batterie (3-4 Jahre Haltbarkeit) oder 
Netzteil. M-Bus Speisung (wie es eigentlich sein sollte) versorgt nur 
die M-Bus Module…😩

[Thomas (Gast)]

Christoph schrieb:
> Hm, der Hichwi Wifi Kopf ist um 180° gedreht. Bei der Hichi USB-Variante
> geht das Kabel nach unten bei der Wifi Variante muss der USB-Anschluss
> nach oben Richtung Display. Hat mich auch ein wenig Nerven gekostet.
> Schon mal 180° gedreht probiert?

Der Hichi Wifi ist mit dem USB Anschluss nach oben angebracht. In genau 
dieser Position konnte ich mit einem FTDI mit der offiziellen Software 
am PC auslesen. Habe aber trotzdem mal mit 180° gedreht versucht. Aber 
kein Unterschied.

Aber bei mir ist "nach oben" nicht Richtung Display. Hast du einen 
anderen WMZ als den Pollucom E oder C?


EGS schrieb:
> Hat der WMZ eine Pufferzelle oder die an eine Mono (D-) Zelle erinnernde
> Batterie?

Ich sehe keine Batterie oder ähnliches. Aber auch keine externe 
Stromversorgung. Das Gerät sitzt auf dem Heizungsrohr und die Leitungen 
gehen nur an Warmwasser Zu- und Ablauf (siehe Foto im Anhang). Die 
Zähler wurden Mitte 2020 gewechselt. Sind also keine 3 Jahre alt.

[Christoph (pidelta)]

PolluCom F, im Sommer 2022 installiert, vielleicht benötigt deiner eine 
andere Sequenz.

[Dodi (herr_grabowski)]

Hi, ich habe einen Sharky 775 und das Auslesen mittels HichiTTL (Kabel 
nach oben) klappt mittels Tasmota.

Die Seuquenz 0c 06 und meinen Wäremewert 36 15 02 (21537 kwh) finde ich 
auch. Allerdings läufts das jetzt schon über einen Tag und Tasmota zeigt 
immer noch nichts an.

Wie lange dauert es, bis hier was kommt?

Decoder Tasmota
>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
#

Sensor Dump
18:47:23.438 wakeup end
18:47:23.440 wait for the meter
18:47:23.793 request data
18:47:23.923 : 68 95 95 68 08 01
18:47:23.926 WIF: Sending Gratuitous ARP
18:47:23.970 : 72 28 96 04 10 a5 11 40 04 46 00
18:47:24.011 : 00 00 0c 06 36 15 02 00 8c
18:47:24.053 : 10 06 00 00 00 00 8c 20 13 17
18:47:24.100 : 00 00 00 0c 13 91 24 33 00 0c
18:47:24.143 : 2b 17 22 00 00 0b 3b 36 00
18:47:24.185 : 00 0a 5a 26 09 0a 5e 76 03
18:47:24.232 : 0a 62 50 05 0b 26 26 40 01 04 6d
18:47:24.277 : 1e 13 e9 21 4c 06 87 09 02 00
18:47:24.323 : 4c 13 24 34 32 00 cc 10 06 00
18:47:24.367 : 00 00 00 cc 20 13 17 00 00
18:47:24.410 : 00 42 6c df 2c 42 ec 7e ff 2c
18:47:24.455 : cc 01 06 87 09 02 00 cc 01
18:47:24.498 : 13 24 34 32 00 cc 11 06 00 00
18:47:24.543 : 00 00 cc 21 13 17 00 00 00 c2
18:47:24.588 : 01 6c df 2c f2 01 ec 7e df
18:47:24.631 : 21 85 16

[Carsten (carsten12)]

Hallo,

hier ein paar Gedanken zu Deinem Problem, obwohl es schon mal super ist, 
dass er mit Dir spricht.

  - welche Firmwareversion verwendest Du?
  - hast Du selber übersetzt und alle Options gesetzt?
  - verwendest Du die Version 3 von Nick, dann solltest Du safe sein
  - ist der Haken Script enable gesetzt?
  - wie ist configuration/logging/telemetry period gesetzt?

Poste mal das ganze Script und meine Firmware. Erst oben per Web auf 
-minimal upgraden, dann unten per angehängter Datei (nicht auspacken).

Anbei meine letzte Version, die einmal um Mitternacht ausliest und das 
Delta per MQTT und Webinterface postet:

>D
;start, define variables
cnt=1
timer=1
w_new=0
w_delta=0
p:w_last=40350

>B
;setup sensor
->sensor53 r

>T
w_new=WAERME#w_total

>S
timer=int(time)
if chg[timer]>0 
then
switch timer
case 0
print It is midnight
print wakeup start
sml(-1 1 "2400:8N1")
for cnt 1 72 1
sml(1 1 "55555555555555555555")
next
print wakeup end
print wait for the meter
delay(350)
sml(-1 1 "2400:8E1")
print request data
sml(1 1 "105BFE5916")
case 1
print It is a minute after midnight
print calculating daily value
print w_last %0w_last%
w_delta=w_new-w_last
w_last=w_new
svars
print w_new %0w_new%
print w_delta %0w_delta%
ends
endif

>J  
,"w_delta":%w_delta% 

>W
===============
Vortagsverbrauch:    {m} %3w_delta% KWh 

>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
#

Übersetzt gitpod mit folgenden Options in der der 
user_config_override.h:

#ifndef USE_SCRIPT
#define USE_SCRIPT
#endif
#ifndef USE_SML_M
#define USE_SML_M
#endif
#ifdef USE_RULES
#undef USE_RULES
#endif
#ifndef SML_BSIZ
#define SML_BSIZ 200
#endif
#ifndef USE_SML_SCRIPT_CMD
#define USE_SML_SCRIPT_CMD
#endif
#ifndef USE_SCRIPT_JSON_EXPORT
#define USE_SCRIPT_JSON_EXPORT
#endif
#ifndef USE_SCRIPT_WEB_DISPLAY
#define USE_SCRIPT_WEB_DISPLAY
#endif

[Dodi (herr_grabowski)]

Zurück. Es klappt jetzt.

Der Debugdump Sensor53 d1 musste raus, danach lief es.

Vielen Dank

[Carsten (carsten12)]

Cool, das erklärt dann auch mein damaliges Problem und das hin und her 
meiner Beiträge…

GrC

[Christoph (pidelta)]

Thomas schrieb:
> Nach der Eingabe von "sensor53 d1" kommt zwar die Ausgabe, dass es
> angenommen wurde, aber es wird nichts vom WMZ ausgegeben.
>
> Ich verstehe es nicht. Hab die gleiche Tasmota Version und Skript wie
> Christoph, der Lesekopf an sich funktioniert (kann den WMZ mit dem PC
> und minicom3 auslesen), entsprechend ist auch die Position des Kopfes
> richtig.
>
> Habt ihr ne Idee, wie ich der Lösung näher kommen kann?

Mann könnte z.B. mit der Software "Serial Port Monitor" den Datenverkehr 
der minicom3 Software mit deinem Zähler "sniffen" und anhand dessen die 
"richtige" Syntax für deinen Zähler finden, als Bsp. hier mal von meinem 
Zähler:

[11/01/2023 23:20:53] - Open port COM5 (C:\Program Files (x86)\MiniCom 
3\minicom3.exe)

[11/01/2023 23:20:54] Written data (COM5)
    2f                                                /
[11/01/2023 23:21:01] Written data (COM5)
    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
    55 55 55 55                                       UUUU
[11/01/2023 23:21:02] Written data (COM5)
    10 40 00 40 16                                    .@.@.
[11/01/2023 23:21:02] Read data (COM5)
    e5                                                å
[11/01/2023 23:21:02] Written data (COM5)
    10 5b 00 5b 16                                    .[.[.
[11/01/2023 23:21:02] Read data (COM5)
    68 42 42 68 08 00 72 27 63 37 11 ae 4c 1d 04 f4   hBBh..r'c7.®L..ô
    00 00 00 0c 06 53 31 00 00 0c 13 81 10 98 00 0c   .....S1.....˜..
    3b 00 00 00 00 0c 2b 00 00 00 00 02 5a 23 01 02   ;.....+.....Z#..
    5e f7 00 03 60 4a 11 00 0c 78 27 63 37 11 0c fd   ^÷..`J...x'c7..ý
    10 27 63 37 11 1f ac 16                           .'c7..¬.
[11/01/2023 23:21:03] Written data (COM5)
    10 7b 00 7b 16                                    .{.{.
[11/01/2023 23:21:03] Read data (COM5)
    68 49 49 68 08 00 72 27 63 37 11 ae 4c 1d 04 f5   hIIh..r'c7.®L..õ
    00 00 00 02 71 10 00 04 6d 28 37 eb 21 00 fd 3a   ....q...m(7ë!.ý:
    00 fd 3a 8c 10 06 00 00 00 00 82 20 fb 76 fa 00   .ý:Œ......‚ ûvú.
    83 20 e0 48 96 00 00 8c 20 06 00 00 00 00 32 22   ƒ àH–..Œ .....2"
    00 00 32 fd 75 00 00 02 fd 17 00 00 1f 18 16      ..2ýu...ý......

[Dodi (herr_grabowski)]

Nachdem ich etwas umkonfiguriert (MQTT) und neu gestartet habe, fängt er 
nur noch an sporadisch auszulesen.

Also entweder ein Timingproblem des ESP, oder (meine Vermutung) der 
Sharky lässt sich nicht mehr so oft auslesen und blockiert die 
Schnittstelle für mehrere Stunden.

Könnte es sein, dass der Sharky zum Batterie sparen, die Schnittstelle 
sperrt?

Im Handbuch habe ich nichts dazu gefunden.

LGD

[Thomas (Gast)]

Christoph schrieb:
> Mann könnte z.B. mit der Software "Serial Port Monitor" den Datenverkehr
> der minicom3 Software mit deinem Zähler "sniffen" und anhand dessen die
> "richtige" Syntax für deinen Zähler finden, als Bsp. hier mal von meinem
> Zähler:

Ach cool, an sowas hatte ich auch gedacht. Wusste aber nicht wie...

Also bei mir kommt die gleiche Ausgabe. Bei dir ist der IR Kopf auch 
Standard an GPIO 1 und 3 (TX/RX)? Hast du bei Module bzw den GPIOs was 
eingestellt? Bei mir ist "Generic(0)" und bei allen GPIOs "none" (hab 
ich beim D1 am Stromzähler auch; da funktioniert es).

Könnte ich sonst was auf dem Weg vergessen haben? Tasmota von Nick 
flashen, WLAN verbinden, Skript kopieren, enable skript. Sonst sollte 
doch nichts zu tun sein oder?

[14/01/2023 13:02:03] Written data (COM7)
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU
55 55 55 55                                       UUUU            
[14/01/2023 13:02:04] Written data (COM7)
10 40 00 40 16                                    .@.@.           
[14/01/2023 13:02:04] Read data (COM7)
e5                                                Â               
[14/01/2023 13:02:04] Written data (COM7)
10 5b 00 5b 16                                    .[.[.           
[14/01/2023 13:02:04] Read data (COM7)
68 42 42 68 08 00 72 17 11 14 81 ae 4c 19 04 a7   hBBh..r...ÅÆL..ß
00 00 00 0c 06 48 85 00 00 0c 13 17 06 90 00 0c   .....HÖ......ê..
3b 18 01 00 00 0c 2b 66 06 00 00 02 5a 67 01 02   ;.....+f....Zg..
5e 38 01 03 60 86 12 00 0c 78 17 11 14 81 0c fd   ^8..`Ü...x...Å.˝
10 17 11 14 81 1f 31 16                           ....Å.1.        
[14/01/2023 13:02:05] Written data (COM7)
10 7b 00 7b 16                                    .{.{.           
[14/01/2023 13:02:05] Read data (COM7)
68 44 44 68 08 00 72 17 11 14 81 ae 4c 19 04 a8   hDDh..r...ÅÆL..®
00 00 00 02 71 0f 00 04 6d 03 0b ee 21 00 fd 3a   ....q...m..Ó!.˝:
00 fd 3a 8c 10 06 00 00 00 00 82 20 fb 76 fa 00   .˝:å......Ç ˚v˙.
83 20 e0 48 67 ff ff 8c 20 06 00 00 00 00 32 22   É ‡Hgˇˇå .....2"
00 00 32 fd 75 00 00 1f 1c 16                     ..2˝u.....      
[14/01/2023 13:02:06] Written data (COM7)
10 5b 00 5b 16                                    .[.[.

[Thomas (Gast)]

Ich habe gerade nochmal in der Konsole ausgeben lassen, ob und was der 
WMZ sendet. Ich erhalte zumindest ein "e5" zurück.

Dann habe ich es mal mit einem Delay(100) vor REQ_UD2 versucht. Dann 
erhalte ich auch die gleichen Daten, welche bei minicom3 empfangen 
wurden.

Wie kann ich nun daraus lesen, wie die Daten nach "M1" angepasst werden? 
Also welche Daten aus dem Telegram in Tasmota ausgegeben werden.

14:16:19.073 read meter
14:16:19.075 wakeup start
14:16:19.658 wakeup end
14:16:19.659 wait for the meter
14:16:20.018 request data
14:16:20.172 : e5 68 42 
14:16:20.219 : 42 68 08 00 72 17 11 14 81 ae 4c 
14:16:20.264 : 19 04 be 00 00 00 0c 06 50 
14:16:20.307 : 85 00 00 0c 13 65 07 90 00 0c 
14:16:20.351 : 3b 20 01 00 00 0c 2b 75 10 
14:16:20.394 : 00 00 02 5a 84 01 02 5e 36 01 
14:16:20.439 : 03 60 63 1e 00 0c 78 17 11 14 
14:16:20.483 : 81 0c fd 10 17 11 14 81 1f 
14:16:20.526 : c4 16

[Thomas (Gast)]

Schade, dass man als Gast keine Beiträge löschen oder bearbeiten kann.

Tasmota hat wohl eine Zeit gebraucht, um die Daten richtig zu 
verarbeiten. Kurz und knapp: Es funktioniert alles.

Der pollucom c/s-ri mochte es wohl nicht, dass zwei Befehle direkt 
hintereinander reinkommen. Mit dem Delay(100) funktioniert jetzt alles.

@christop und @carsten
Vielen Dank euch für die Hilfe!

[Christoph (pidelta)]

Schön das es jetzt geht.
Vielleicht versuchst du folgende Zeilen aus "meinem" script:

print request data
;reset application code
sml(1 1 "6804046853FE5000A116")

;set string to send to "105BFE5916" (REQ_UD2)
sml(1 1 "105BFE5916")

durch folgende zu ersetzen, dann sollte tasmota auch schneller die Werte 
anzeigen. Die anderen Werte aus meinem script entsprechen nicht der 
Kommunikation der minicom software, damit kommt scheinbar nur "zufällig" 
was brauchbares vom Zähler zurück. Was gesendet wird kannst du auch an 
deinem Mitschnitt nachvollziehen -> [14/01/2023 13:02:04] Written data 
(COM7)
10 40 00 40 16                                    .@.@.
[14/01/2023 13:02:04] Read data (COM7)
e5                                                Â
[14/01/2023 13:02:04] Written data (COM7)
10 5b 00 5b 16                                    .[.[.

hier die "neuen" Werte für das script:

print request data
;reset application code
sml(1 1 "1040004016")
-> dein delay(100)
;set string to send to "105b005b16" (REQ_UD2)
sml(1 1 "105b005b16")

[Frank (xmp1)]

Ich habe einen Allmess Echo II WMZ und einen Hitchi IR wifi.
Nutze die tasmota_V3 und das Script von Nick. Im Script musste ich
die Zeile für Total energy wesentlich ändern. Vielleicht ist der Hinweis 
ja für den ein oder anderen Allmess-Besitzer von Interesse. Script im 
Anhang.

; uuUUuuUU = extract an unsigned long word (low order byte first)
;on long word values, if a trailing “s” is added at the end of the mask, 
word order is reversed
1,0406uuUUuuUUs@1000,Total energy,MWh,Energie_total,3

Ein Problem habe ich noch.
Wenn die Wärmepumpe läuft wird diese Zeile korrekt abgearbeitet:
1,0B2Dbcd6@10,Current power,KW,Leistung_akt,2

Wenn sie stillsteht bleibt der Wert "Current power" eingefroren stehen. 
Die Ursache habe ich gefunden. Eine Abfrage mit sensor53d1 findet keine 
#0B2D sonder an der Stelle gibt es dann die #3B2D mit #999999

Für eine Auswertung über MQTT -> FHEM -> SVG-Plot ist das "doof". Es 
zeigt ein Diagramm bei der die WP dauerhaft "powert". Im Tasmota.gitub 
habe leider auch keine Lösung gefunden (oder nicht verstanden).

Hat jemand von euch Profis vielleicht einen Lösungsvorschlag?

[Urs P. (naseweiss)]

Frank schrieb:
> Wenn sie stillsteht bleibt der Wert "Current power" eingefroren stehen.
> Die Ursache habe ich gefunden. Eine Abfrage mit sensor53d1 findet keine
> #0B2D sonder an der Stelle gibt es dann die #3B2D mit #999999

genau eine Frage in dieser Richtung habe ich Carsten12 im Tasmota Forum 
gestellt, es geht um fehlerhafte Readings, wo im Datenstrom die 
Schlüssel per Zufall an anderer Stelle auftauchen und dann falsche Werte 
zurückgegeben werden. War bei mir der Fall.
Ich zähle deshalb die Bytes ab einem eindeutigen Schlüssel und verwende 
sie dann.

Meine ursprünglicher Code ist dieser:
+1,3,rE1,0,2400,Waerme,1,10,1040FD3D16,105B005B16
1,68b3b368x23uuUUUUUU@1,Energy total,,total,0 ; Total Wärmemenge
1,68b3b368x47uuUUUUUU@60,Flow F_akt,,F_akt,0 ; aktueller Flow in m^3

...
Dabei stehen die 23 für für das 23. Byte nach dem Schlüssel, bzw. die 47 
für das 47. Byte danach.

Dafür muss man leider Tasmota neu kompilieren mit den entsprechenden 
Einstellungen.
Siehe auch https://github.com/arendst/Tasmota/discussions/17228

Damit ist es auch egal sein was vor den Datenwerten steht. Aber Du wirst 
dann auch die 99999 auslesen, wenn ich das richtig sehe. Wobei ich bei 
mir solch ein Verhalten nicht sehe (Sensostar U mit drahtgebundenem 
MBus).



Cheerio

[Frank (xmp1)]

Urs P. schrieb:
> Ich zähle deshalb die Bytes ab einem eindeutigen Schlüssel und verwende
> sie dann.

das ist der entscheidende Hinweis gewesen! Den Rest konnte ich mit einem 
userReadings in FHEM lösen. Jetzt läuft die Sache perfekt!

An dieser Stelle ein großes Lob und meinen Dank an die sach- und 
fachkundigen Teilnehmer in diesem Thread!!

[Marcus (Gast)]

Mein WMZ ist ein Sensus Wärmemengenzähler PolluCom E 
(DE-07-M1004-PTB004) und auch ich versuche mit dem Hichi Wifi Lesekopf 
mit integriertem Tasmota die Daten auszulesen.

Aufgrund der Beiträge hier im Forum (Dank an Alle!) habe ich folgendes 
gemacht:
- Firmware "tasmota_V3.bin.gz" von 'Nick' geflashed
- Script eingefügt (script_Sensus_PolluCom_Tasmota_SMI.txt) von 
Christoph (pidelta)
- Taste am WMZ betätigt (für Aktivierung der optischen Schnittstelle für 
1h
- Montage am WMZ mit Kabel "nach oben"

Der Sensus reagiert leider überhaupt nicht...

- Mit dem Script von Christoph (132 x "55") hatte ich das Problem, daß 
die Wakeup-time nur 0,5 sec. war. Also habe ich etwas rumprobiert und 
mich für 132 x "55555555" entschieden. Ergibt eine Wakeup-Time von 2,19 
sec. Sollte eigentlich passen.
- Montage um 180° gedreht (Kabel nach unten Richtung Display) brachte 
kein Ergebnis.
- Hab auch mit "sensor53 d1/sensor53 d0" die Console überwacht.
- Auch hab ich mit verschiedenen hier verwendeten Application Codes 
gespielt (wie Christoph in seinem letzten post vorgeschlagen hatte)

Hat alles nix geholfen. Ich hänge hier mal das Scrip an, das aus meiner 
Sicht eigentlich laufen sollte.

Mittlerweile denke ich, ist die Batterie am WMZ (3,25 Jahre alt) zu 
schwach (?) und die optische Schnittstelle lässt sich nicht mehr 
aktivieren.

Kann man das testen? Wenn ich die Taste am WMZ drücke kann ich über das 
Handy keine IR Aktivität erkennen, aber ich denke da müsste auch erst 
die Aufweck-Sequenz ankommen, bevor der WMZ sich meldet?

Hat noch jemand andere Ideen an was es liegen könnte?

[Daniel (Gast)]

Hallo zusammen,

ich habe den Beitrag jetzt endlich komplett durchgelesen und kann soweit 
meinen Engelmann SensoStar mit einem Hichi USB-IR auslesen.

./mbus-test -d /dev/ttyUSB0
dann "2" und ich bekomme zumindest eine Antwort:

Port Modus 8N1
wakeup(): Sende Aufwachsequenz
Pause 350 ms
Port Modus 8E1
req_ud2(): Sende Anfrage Daten Klasse 2
5 bytes sent
185 byte(s) received
Length:         179
Checksum OK
C-Field:                0x08
Primary Adress:         0x00
Ci-Field:               0x72
variable Antwort, fixed header 12 Bytes
-------------------------------------------------
primary_address:        0x00
customer_number:        20152109
manufacturer:           EFE
generation:             0
medium:                 4        = Wärme
reading_counter:        124
error_code:             0
signature:              0
fabrication_number:     20152109
energy:                 0 kWh
volume:                 0 l
power:                  12487 W
flow:                   3595 l/h
supply_temp:            29.0 °C
return_temp:            25.0 °C
temp_difference:        3.36 K
date:                   31.12.2022
time:                   00:00:00
operating_time:         386 d
firmware_version:       0
software_version:       0
alarm_code:             0
-------------------------------------------------

Allerdings verändern sich nur "reading counter, supply temp, return temp 
und temp_difference".

Werte wie "energy" bzw. "date" bzw. "time" sind immer gleich.

Mir würde 4x am Tag die erzeugte Wärmemenge (energy) völlig reichen, 
soll dann im iobroker ausgelesen werden.

Woran kann das liegen?

[Matthew F. (matthew_f)]

Ich vermute mit 3 statt 2 kriegst du mehr Infos.

Ich habe meine Erfahrungen hier aufgeschrieben:
https://github.com/mattfullerton/volkszaehler_scripts/blob/main/readHeat/

Der Teil mit Befehl 3:
https://github.com/mattfullerton/volkszaehler_scripts/blob/main/readHeat/run.sh#L17

Mein Gerüst um mbus-test herum ist  sehr unschön, funktioniert aber 
ziemlich zuverlässig mit 4 Ablesung am Tag und ist während dieser 
Jahreszeit sehr informativ.

VG,
Matt

[Daniel (Gast)]

Hallo Matt,

hat leider nicht funktioniert:

COMMAND 0: ACK received / 1 byte received
COMMAND 1: 0 byte received
COMMAND 2: siehe oben (heute haben sich nur "operating_time" und 
"reading_counter" geändert)
COMMAND 3: 0 byte received

Eigentlich hatte ich das Auslesen schon aufgegeben, aber dank Euch hier 
bin ich zumindest weitergekommen. Schaue mir Deine Links an, vielleicht 
finde ich da die Lösung.

Sonst niemand mit einen ähnlichen Problem hier?

VG Daniel

[Daniel (Gast)]

@matthew_f Hab mir Deine Infos bei Github durchgelesen, weicht die 
verlinkte mbus-test Variante immer noch vom Original ab? D.h. "init-size 
536" ist im Original ein anderer?

Bei Dir funktioniert es mit dem SensoStar E, dann muss es eigentlich 
auch mit meinem SensoStar U gehen.

Läuft der run.sh Skript auch mit einem USB-IR Lesekopf?

VG Daniel

[Matthew F. (matthew_f)]

Hallo Daniel,

irgendwie habe ich dein Post vorher nicht richtig gelesen, und sehe erst 
jetzt, dass du Einträge für Energy und Volume hast aber sie sitzen auf 
0. Ich hatte am Anfang das gleiche Problem 
(Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen") und die 
Lösung war einfach zurück in der Ausgabe zu schauen, weil mehrere 
Ausgaben/MBus Dekodierungen stattgefunden haben. Das Eintragen-finden 
macht bei mir das Python Skript automatisch.

Ansonsten, wenn das immer noch nicht funktioniert könntest du mein 
Version von damals as-is ausprobieren. Das habe ich scheinbar angefangen 
aber nicht zu Ende gemacht 
(https://github.com/mattfullerton/mbus-test-fork/) - aber ich kann das 
ergänzen und dann könntest du das run.sh usw. ausprobieren. Aber 
eigentlich wenn du schon Daten rausbekommst, denke ich nicht, dass du 
irgendetwas an mbus-test ändern müsstest. Eigentlich sollte ich eher 
schauen, dass mein Setup noch mit der aktuellster Version läuft. Aber... 
"never touch a running system", und keine Zeit, usw.

Ich bin auch der Meinung, dass es funktionieren musste, solang bei dir 
im Display die Daten in MW/kW ausgegeben werden (und auch wenn nicht, 
habe ich keine Ahnung, ob die Daten nicht dann doch noch vollständig 
über MBus zu erwarten wären). Ich bin zuversichtlich... weil wie gesagt, 
das gleiche Problem hatte ich auch am Anfang.

VG,
Matt

[Daniel (Gast)]

Wenn ich den SenoStar mit "verbose level 2" und "COMMANDS 2" abfrage, 
erhalte ich tatsächlich u.a. die erzeugte Wärmemenge angezeigt:

DIF 04
VIF 06
        function_field: 00
        data_length:    4
        data_field:     04
        unit:           06
        data bytes: 3C 11 00 00
        Instantaneous value
        Energy (kWh)
        mbus_parse_data_field: DIF 0x04 was decoded using 4 byte integer
        result: 4412    factor 1.000000 n: 3    neg 0

In diesem Fall sind es tatsächlich 4412 kWh.

Weiter unten erscheint es dann 4x hintereinander mit Null Werten:

DIF 84
DIFE 20
VIF 06
        function_field: 00
        data_length:    4
        data_field:     04
        unit:           06
        data bytes: 00 00 00 00
        Instantaneous value
        Energy (kWh)
        mbus_parse_data_field: DIF 0x84 was decoded using 4 byte integer
        result: 0       factor 1.000000 n: 3    neg 0



Wie komme ich jetzt an den ersten Output mit der tatsächlichen 
Wärmemenge?

[Matthew F. (matthew_f)]

Super, das freut mich!

Das aussuchen der Werte mache ich mit Python. Das sind die Zeile hier:
https://github.com/mattfullerton/volkszaehler_scripts/blob/main/readHeat/readHeat.py#L10-L28

Das Output von `mbus-test` wird in eine Datei geschickt (redirected 
von stdout). `run.sh` schaut, dass es genüg Zeit gibt für die Ausgabe 
gibt. Python geht die Datei durch. Nach einem Zeil mit Energy gefunden 
wird, wird geprüft ob die Wert > 0 ist. Ich habe da auch Werte für Power 
genommen, inzwischen habe ich aber festgestellt, dass die Werte nicht so 
nützlich sind (was gerade passiert nur einmal alle 4 Stunden ist 
uninteressant). Volkszähler ermittelt den Durchschnittsverbrauch aus den 
Gesamtverbrauchswerte.

[Daniel (Gast)]

Danke Dir Matt!

Kannst Du mir bitte noch verraten, was ich eingeben muss, damit es auf 
meinem Raspberry mit mbus-test funktioniert? Bin froh, dass ich 
mbus-test zum laufen bekommen habe, bin leider kein Experte. Von Python 
hab ich null Ahnung.
Gibt es eine Möglichkeit die Daten per MQTT weiterzugeben?

VG Daniel

[Daniel (Gast)]

Matt und @all, ich benötige bitte Eure Unterstützung.

Meinen SensoStar U konnte ich optisch (USB IR Lesekopf von Hichi) mit 
LORUSFREE direkt und fehlerfrei auslesen. Sämtliche Daten werden richtig 
angezeigt.

Für mich als Laien stellt sich jetzt die Frage, wie ich diese Infos 
nutzen kann, um meinen WMZ 4x am Tag ohne Programmierkenntnisse 
auszulesen.

Ich nutze iobroker und habe hier mehrere Raspberry´s.

Gibt es einen Adapter für iobroker, der im Grunde wie Lorusfree ohne 
besondere Einstellungen funktioniert?

Danke Euch!

[Matthew F. (matthew_f)]

Ich kann dir gerne helfen, die Daten automatisch 4x am Tag auszulesen. 
Steht eigentlich alles hier: 
https://github.com/mattfullerton/volkszaehler_scripts/blob/main/readHeat/README.md
Aber wir können gern über Zoom oder so reden.
Nur ich schicke meine Daten an Volkszähler, was sehr einfach ist (ein 
URL mit der Wert drin). Mit ioBroker würde ich mich schlau lesen müssen.

[Matthias (Gast)]

Hey ho,

erstmal vielen Dank für diesen Thread - das ist super hilfreich. Ich 
habe auch einen Engelmann Sensor hier - konkret eigentlich einen Metrona 
Heat C - allerdings scheinbar (?) baugleich zum Engelmann.

Mit der Firmware von naseweis bekomme ich auch eine wunderbare Antwort. 
Nur jetzt habe ich das gleiche Problem, das Thomas auch hatte - wie 
komme ich von der Binär-Antwort zur Tasmota Definition?

sml(1 1 "105BFE5916")

>M 1
+1,3,rE1,0,2400,Waerme,1

liefert mir den Binär-Blob.

Als Definition habe ich aktuell folgendes eingetragen (alles geklaut):

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 Rücklauftemperatur
1,68b3b368x67uuUU@1,Temp Diff,,Diff,0 ; aktuelle Differenz Vorlauf/Rücklauftemperatur

Damit tut Tasmota leider überhaupt nichts, es werden keine Werte 
ausgewertet. Mit sensor53 d1 sehe ich aber eine Antwort:

10:01:21.893 : 68 04 04 68 53 fe 50 00 a1 16 10 5b 3e 04 20 05 00 68 08 00 72
10:01:21.937 : 37 41 25 10 c5 14 00 04 a0 00
10:01:21.979 : 00 00 04 78 39 77 9c 00 04
10:01:22.021 : 6d 01 2a e4 22 04 13 25 0d 08
10:01:22.066 : 00 44 13 25 e7 06 00 84 01
10:01:22.107 : 13 bf ef 07 00 04 06 d8 0e
10:01:22.149 : 00 00 44 06 a3 0c 00 00 84 01
10:01:22.195 : 06 9d 0e 00 00 84 10 06 00 00
10:01:22.240 : 00 00 c4 10 06 00 00 00 00
10:01:22.281 : 84 11 06 00 00 00 00 42 6c
10:01:22.324 : df 2c 02 6c ff 2c 84 20 06 00
10:01:22.367 : 00 00 00 84 30 06 00 00 00
10:01:22.408 : 00 04 3b 00 00 00 00 14 3b
10:01:22.451 : 9e 03 00 00 04 2b 00 00 00 00
10:01:22.495 : 14 2b a8 39 00 00 02 5b 1b
10:01:22.537 : 00 02 5f 1b 00 04 61 0d 00
10:01:22.578 : 00 00 02 23 f4 02 01 fd 17
10:01:22.620 : 10 04 90 28 18 00 00 00 f1
10:01:22.662 : 16

Nur was mache ich jetzt mit der Antwort? Ich habe schon versucht im 
Hex-Editor die aktuellen Zähler-Werte zu finden - nur diese Zahlen finde 
ich nirgends.

Hat jemand eine Idee?

Vielen Dank
Matthias

[Dodi (herr_grabowski)]

Hi Matthias,

Bei deinem dump kommen die Daten d8 0e 00 00 nach dem Register 04 06.

Dann müsste dein Zählerstand 3800 kWh zeigen.

Falls ja, solltest du

1,0406uuUUuuUu@1,

Ausprobieren. Mit dem tasmota Decoder bin ich aber nicht so vertraut.

LGD

[Matthias (Gast)]

Hi,

erstmal vielen Dank!

Ich habe die Definition einfach mal ausprobiert - damit bekomme ich aber 
leider auch nur eine 0 zurück :-(

Wie bist du denn auf die 3800 gekommen? Der Wert würde exakt stimmen.

Wenn ich in der Doku lese, dann bedeutet uuUUuuUu ein unsigned long 
word. Ich hätte jetzt little-endian vermutet, aber irgendwie sehe ich 
nur fürs Ende "uu" oder "UU", nie den Mix aus "Uu".

d8 0e 00 00 würden 4 Byte entsprechen, also 32 Bit. Im Hex Editor 
bekomme ich für 32 Bit an dieser Stelle aber 807417956 (big endian 
1681399856) angezeigt - das passt auch nicht.

Und zur 0 in Tasmota passt es auch nicht.

Ich bin verwirrt, irgendwo habe ich einen Denkfehler -.-

Ich habe es jetzt auch ein paar Minuten laufen lassen, es hat sich nicht 
eingefangen, irgendwie bleibt die 0 -.-

Viele Grüße
Matthias

[Dodi (herr_grabowski)]

Hi,

Hex 0e d8 = dec 3800

06 04 low high low high

LGD

[Urs P. (naseweiss)]

Matthias schrieb:
> 10:01:21.893 : "68 04 04 68" 53 fe 50 00 a1 16 10 5b 3e 04 20 05 00 68 08
> 00 72
> 10:01:21.937 : 37 41 25 10 c5 14 00 04 a0 00
> 10:01:21.979 : 00 00 04 78 39 77 9c 00 04


Hallo wenn Du Dir mal die ersten 4 Bytes anschaust, wirst du sehen, daß 
die anders sind als bei dem in meinem Skript verwendeten Sensostar U.

Schau Dir mal dieses Dokument an, darin ist - wenn auch für einen 
anderen Zähler - die Struktur der Daten erklärt.

https://docs.google.com/viewer?url=http%3A%2F%2Fwww.mikrocontroller.net%2Fattachment%2F577509%2FCF_Serie.pdf

Nimm mal
1,68040468x23uuUUUUUU@1,Energy total,,total,0 ; Total Wärmemenge

Das mit den abgezählten Bytes usw. musst du u.U. anpassen.

Cheerio

[Urs P. (naseweiss)]

Man sieht die Startsequenz (gelb) und danach die 23 zu überspringenden 
Bytes (blau). Dann kommen die relevanten Daten (rot)

Das muss dann mit dem eigenen Dump in Übereinstimmung gebracht werden.

[Matthias (Gast)]

Vielen Dank für die vielen Infos :-). Dann probiere ich mal weiter!

Matthias

[Willy L. (sabberlotte)]

Marcus schrieb:

>
> Mittlerweile denke ich, ist die Batterie am WMZ (3,25 Jahre alt) zu
> schwach (?) und die optische Schnittstelle lässt sich nicht mehr
> aktivieren.
>
> Kann man das testen? Wenn ich die Taste am WMZ drücke kann ich über das
> Handy keine IR Aktivität erkennen, aber ich denke da müsste auch erst
> die Aufweck-Sequenz ankommen, bevor der WMZ sich meldet?
>
> Hat noch jemand andere Ideen an was es liegen könnte?

Ich habe einen Allmess Integral-MK UltraMaXX mit dem ich mich wochenlang 
beschäftigt habe (leider lange ohne Erfolg).
Der Volkszähler- ähnliche Lesekopf (UART-Ausgang) hat auf Anhieb an 
einem Stromzähler funktioniert. Am WMZ leider keine Antwort.

Die batteriebetriebenen WMZ müssen mit Energie sparsam umgehen.
Das brachte mich auf die Idee die Sendeleistung des Lesekopfes zu 
reduzieren und den Empfang empfindlicher zu machen.
Also den Serienwiderstand der Sendediode von 180 auf 680 Ohm verändert,
den Serienwiderstand des Fototransistors von 12k auf 39k.

Und nun kann ich mich endlich mit der Antwort beschäftigen...

LG

[Tony L. (tonyl)]

Marcus schrieb:
> Der Sensus reagiert leider überhaupt nicht...

Hallo in die Runde.

Selbes Problem hier. Ich habe einen PolluCom E mit Hichi TTL Kopf an 
einem NodeMCU mit Nicks tasmota_v3 und dem PolluCom Script von 
Christoph. Auch andere hier gepostete Scripts habe ich getestet - keine 
Chance.

Eventuell habe ich es überlesen: Kann jemand sagen, welche Linse am 
PolluCom E RX und welche TX ist? Ich habe es natürlich in beide 
Richtungen versucht, es wäre aber hilfreich hier schonmal Sicherheit zu 
haben. Anschluss am NodeMCU passt, der Handy-Test funktioniert.

Vielen dank für die super Arbeit, die hier bisher geleistet wurde!

[Tony L. (tonyl)]

Hmm,

ganz schön fix:

08:20:51.435 read meter
08:20:51.437 wakeup start
08:20:51.467 wakeup end
08:20:51.469 wait for the meter
08:20:51.821 request data

Das bisher erwähnte Auskommentieren von SND_UD 0 (Carsten)

sml(1 1 "6804046853FE5000A116")

hat hier keine Besserung gebracht.

[Carsten (carsten12)]

Ich denke, die Wakeup Seequenz wird nicht gesendet. Das siehst Du am 
Timecode. Probier mal meine Firmware. GrC

[Tony L. (tonyl)]

Mit deiner Firmware vom 09.01. sehe ich keine Aktivität des Kopfes mehr 
in der Kamera des Handys. Das Script läuft weiterhin zu flott:

09:17:33.394 wakeup start
09:17:33.430 wakeup end

VG
-T

[Christoph (pidelta)]

Wegen der Nachfragen zu den PolluCom Zählern hier eine kurze 
Zusammenfassung meiner Erfahrungen.
Auch wenn das nichts neues ist, aber die optische Schnittstelle ist bei 
den Geräten fürs dauerhafte Auslesen ungeeignet. Der Zähler, mit dem ich 
viel getestet habe, antwortet beim zyklischen Abfragen nur noch 1-4x 
dann fällt er wieder in den Tiefschlaf, er lässt sich dann auch nicht 
mehr mit der MiniCom Software oder Python script auslesen. Nach ca. 24h 
kann er durch Drücken der Taste wieder für weitere 1-4 Auslesungen 
aktiviert werden. Ein anderer Zähler dessen Batterie noch „frischer“ ist 
lässt sich nach wie vor ohne Probleme zyklisch abfragen. (Ist nur die 
Frage wie lange noch)
Es ist nicht unwahrscheinlich, dass wegen geringer Spannung der Batterie 
das Auslesen irgendwann überhaupt nicht mehr geht.
Ein Servomotor oder ähnliches der immer wieder die Taste drückt könnte 
zumindest beim Auslesen 1x pro Tag helfen den Zähler immer wieder zu 
aktivieren. Damit würde man bei funktionieren Zählern die Anzahl der 
Auslesungen geringhalten.
Das in der Zwischenzeit etwas abgewandelte scrip für den Sensus Pollucom 
F, welches bei Zählern mit voller Batterie sehr gut funktioniert habe 
ich nochmal angehangen.

[Tony L. (tonyl)]

Vielen Dank dafür. Auch mit diesem Script ist die Wake Up Sequence, so 
sie denn gesendet wird, enorm kurz.

10:49:02.753 ===== ctr: 10.00 wakeup start ===== 
10:49:02.793 ===== wakeup end, wait for the meter =====

Ich beobachte das hier mal weiter, vielleicht hat ja doch noch jemand 
eine Idee.

[Christoph (pidelta)]

Sie mag kurz sein aber sie funktioniert hier bei mir, wenn ich den Teil 
aus dem Script lösche geht nix mehr.

[Tony L. (tonyl)]

Kopf und PolluCom funktionieren, hiermit konnte ich dem Zähler gerade 
Daten entlocken: 
https://forum-raspberrypi.de/forum/thread/57389-sensus-pollucom-e-ueber-pymeterbus-auslesen/?postID=543096#post543096

RX am PolluCom E ist die linke Linse, falls sich das nach mir nochmal 
jemand fragt.

[Tony L. (tonyl)]

Ich habe jetzt eine Lösung, die für mich funktioniert.

Im Heizkreisverteiler hängt ein NodeMCU mit esp-link. Auf einem Linux, 
das anderswo ohnehin ganztägig läuft, baue ich mit socat eine virtuelle 
serielle Schnittstelle mit esp-link als Gegenseite. Oben genanntes 
Python-Script nutzt dann den virtuellen Port um über esp-link mit dem 
PolluCom E zu kommunizieren. Die Weitergabe der Daten erfolgt dann per 
MQTT.

[Toptobias (toptobias)]

Hallo zusammen, ich finde den Forom echt toll und habe viel gelernt 
daraus.
Ich kann nun mein WMZ Ultramess C3 von Molline die Verbrauchte 
Märmemenge mit dem Script abfragen.

Doch was überhaupt nicht klappt ist die Auslesung nach einer Periode.
Ich habe das Script angepasst das er den WMZ aller drei Stunden mal 
abfragen soll, doch es passiert einfach nichts. Ich erhalte nur noch im 
der Console diese Zeichenketten:

16:49:41.548 MQT: tele/tasmota_E3757E/STATE = 
{"Time":"2023-04-03T16:49:41","Uptime":"0T18:20:25","UptimeSec":66025,"H 
eap":19,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POW 
ER":"OFF","Wifi":{"AP":1,"SSId":"FRITZ!Box  6490 
2-4","BSSId":"3C:37:12:C7:8A:77","Channel":6,"Mode":"11n","RSSI":56,"Sig 
nal":-72,"LinkCount":1,"Downtime":"0T00:00:05"}}
16:49:41.554 MQT: tele/tasmota_E3757E/SENSOR = 
{"Time":"2023-04-03T16:49:41","WAERME":{"w_total":4711}}

Nun meine Frage wie kann ich das Script so einstellen das es, sagen wir 
mal aller 4 Stunden den Zähler ausliesst? Es muss auch nicht ab 
Mitternacht passieren. In der Scriptsprache bin ich nicht so vertrraut.

Vielen Dank

aktuelles Script:

>D
;start, define variables
wkup=1
period=180
;read meter every n minutes after midnight (60 --> 01:00, 02:00...)
blk=0


>B
;setup sensor
->sensor53 r

>S
if time%period==0
and blk==0
;minutes since midnight divided by period have a remainder of "0"
then
=#readmeter
blk=1
;set a flag to execute the readout only once every period
endif

if time%period-1==0
and blk==1
;one minute after we entered the first loop
then
blk=0
; reset the flag
endif


#readmeter

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

;send 0x55 for 3 seconds with 8N1 (72x), 2400 baud (wakeup sequence)
for wkup 1 72 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 "6804046853FE5000A116"
sml(1 1 "105BFE5916")

>M 1
+1,3,rE1,0,2400,WAERME,1
1,0406uuUUUUUU@1,Total energy,kWh,w_total,0

#

[Leo (leo89)]

Hi,

ich versuche auch gerade einen Techem Ultra S3 (sollte auch ein Sharky 
775 sein) auszulesen - jedoch ohne Erfolg.

1. Hab direkt mit Tasmota gestartet, der Lesekopf funktioniert an einem 
Stromzähler.
2. Hab die V3 von Nick installiert -> 
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"
3. Und es direkt mit dem Script von Carsten probiert. 
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"

Wird mir nichts angezeigt in Tasmota ;-(

Hat noch jemand einen Tipp für mich? Wird doch nicht etwa bei dem Techem 
Zähler anders sein?

[Leo (leo89)]

Kann meinen Post leider nicht mehr bearbeiten - nutzt der Sharky 775 
einen kombinierte IR Diode für Send / Receive? Die Leseköpfe (die ich 
habe) haben zwei getrennte Dioden - da wird das alignment schon 
schwierig?

[Carsten (carsten12)]

Ich verwende den Kopf von Hichi, der hat zwei getrennte Dioden. Das 
Gehäuse positioniere ich mit dem Kabel nach unten und dann muss ich es 
bündig an die beiden Erhebungen drücken damit es funktioniert. Dann 
liegen die beiden Dioden des Lesekopfes links und rechts neben der einen 
im Zähler.

Weil es mir und anderen passiert ist: schaue im Log ob die 
Aufwachsequenz wirklich so lang ist, wie sie sein sollte (je nach Script 
im Bereich einiger Sekunden).

GrC

[Leo (leo89)]

Hi Carsten und danke für die Tipps!

Ist in der Tat ein Problem mit der Positionierung des Lesekopfes!

Habe jetzt eine Position leicht versetzt zu einer Seite gefunden, die 
funktioniert. (Lesekopf ist ein ein Bausatz gewesen, 2 getrennte Dioden, 
Gehäuse selbst gedruckt, ähnlich wie Hichi)
Habe auch nur mal das Plastikgehäuse des Lesekopfes aufgesetzt um mir 
durch die Löcher der LEDs eine gute Position auszuloten. Gar nicht so 
einfach! :-/

[Rubinho S. (che_guevara)]

Frank schrieb:
> Ich habe einen Allmess Echo II WMZ und einen Hitchi IR wifi.
> Nutze die tasmota_V3 und das Script von Nick. Im Script musste ich
> die Zeile für Total energy wesentlich ändern. Vielleicht ist der Hinweis
> ja für den ein oder anderen Allmess-Besitzer von Interesse. Script im
> Anhang.

Hallo Zusammen, ich habe mir als Vorbereitung für einen 
Wärmepumpeneinbau einen Wärmezähler (gebrauchter Allmess Integral-V 
Ultralite) zugelegt.
Momentan liegt er noch auf meinem Schreibtisch zum testen. Ich möchte 
zukünftig die Daten mittels Optischer Schnittstelle und einem Hichi Wifi 
Lesekopf an HomeAssistant senden.

Wenn ich das Script von Frank (vielen Dank dafür) benutze, bekomme ich 
nach dem Speichern einmal Werte geschickt, allerdings passiert dann nix 
mehr. Ich sehe kein Weakeup oder sonstiges mehr. Lediglich die 
Statuslogs, die alle 5min gesendet werden.

Sollte ich nicht alle x Minuten (abhängig von der Periodenzahl) 
normalerweise ein Wakeup im Konsolelog sehen?

Viele Grüße
Che

[Rubinho S. (che_guevara)]

Ok, ich war wohl zu ungeduldig.
Das Teil fing erst ab Mitternacht an loszulegen.

Danke an die Community für die tolle Arbeit, auch wenn es in diesem 
Thread recht unübersichtlich wurde. Was der Anzahl an Posts geschuldet 
ist.
Ein Wiki wäre kein Luxus :)

Viele Grüße
Che

[Thomas C. (thomas_c31)]

Hallo,
ich habe auch einen Sensus PolluCom E/S und wollte die Wärme-Menge 
optisch auslesen. Jetzt lese ich hier aber öfter, dass es bei zu 
schwachen Batterien oder bei längerer Laufzeit zu Problemen kommt. Wie 
sind eure Lnagzeit-Erfahrungen?

[Tony L. (tonyl)]

Ich habe mein Konstrukt aus ESP-Link und Docker Container mit Python 
Script jetzt seit März laufen, Abfrage alle 55 Minuten. Bisher keine 
Probleme. So richtig langzeit ist das aber natürlich noch nicht.

[Thomas C. (thomas_c31)]

D.h.
- WMZ: PolluCom E (batteriebetrieben)
- IR-Lesekopf mit TTL (Wie befestigt?)
- NodeMCU (ESP-Link)
- Python-Script zur Kommunikation 
(https://forum-raspberrypi.de/forum/thread/57389-sensus-pollucom-e-ueber-pymeterbus-auslesen/?postID=543096#post543096)
- Wakeup-Time 55 Minuten

[Christoph (pidelta)]

Bei mir war nach ca. einem Jahr Ende, kein zyklischen auslesen mehr. 
(konnte ich bei 2 Zählern feststellen) Vermutlich habe ich am Anfang 
beim Testen auch wirklich sehr oft ausgelesen.
Liegt auch nicht am ESP, gleiches ist auch per USB-IR-Kopf und Python 
Script festzustellen.
Ungefähr 1x am Tag geht es nach vorherigen drücken der Taste noch. Ich 
habe schon von anderen gehört, dass sie das dann per SwitchBot/FingerBot 
machen, auch von einem Servo am ESP habe ich schon gelesen, war mir aber 
bisher zu aufwändig. Die tatsächlichen Zeiten können sich natürlich 
unterscheiden aber eine wirkliche dauerhafte Lösung scheint mir das 
Auslesen per IR-Schnittstelle bei diesen Zählern nicht zu sein.

[Thomas C. (thomas_c31)]

Vielen Dank, da der Austausch des WMZ bei leerer Batterie auch ein 
Kostenfaktor ist, werde ich mich mal nach Alternativen erkundigen und 
dann vielleicht gleich mit M-BUS on Board.

[Tony L. (tonyl)]

Thomas C. schrieb:
> D.h.
> - WMZ: PolluCom E (batteriebetrieben)
> - IR-Lesekopf mit TTL (Wie befestigt?)
> - NodeMCU (ESP-Link)
> - Python-Script zur Kommunikation
> 
(https://forum-raspberrypi.de/forum/thread/57389-sensus-pollucom-e-ueber-pymeterbus-auslesen/?postID=543096#post543096)
> - Wakeup-Time 55 Minuten

Was das Script angeht: https://github.com/ostpol/PolluComE, dort stehen 
die Anpassungen bzgl. Kommunikation zwischen Python und ESP-Link drin. 
Docker Container ist auch fertig. Disclaimer: Ich bin kein besonders 
guter Programmierer und auch zu Docker kenne ich nur Basics. Aber 
irgendwo muss man ja mal anfangen. ;)

Befestigung sieht so aus: 
https://twitter.com/ostpol/status/1634896280202907648?s=12&t=xc7l-nC4po-ngRWAnWqoPw

[Klaus R. (klara)]

Thomas C. schrieb:
> Vielen Dank, da der Austausch des WMZ bei leerer Batterie auch ein
> Kostenfaktor ist, werde ich mich mal nach Alternativen erkundigen und
> dann vielleicht gleich mit M-BUS on Board.

Hallo,
ein PolluCom E war mein erster Wärmemengenzähler. Er lief über M-Bus und 
wurde von mir zunächst zu oft abgefragt. Ich erfuhr das die 
Auslesehäufigkeit begrenzt wird, so dass die Mindestlaufzeit erreicht 
werden kann.

Seit über 10 Jahren habe ich zwei Sontex Supercal 539 im Einsatz. Er 
wird von mir über M-Bus gespeist und somit wird die interne Batterie 
nicht belastet. Beim Kauf mußte ich extra angeben, das ich über M-Bus 
speisen möchte.

Den 539 gibt es wohl nicht mehr. Heute ist es wohl der Sontex Supercal 
739.
mfg Klaus

[Toptobias (toptobias)]

Hallo nochmal zusammen. Kann mir jemand bitte helfen zwecks der 
Dateninterpretation. Ich habe ein WMZ vom Typ Ultramess C3 von Molline.
Ich bekomme folgende Daten heraus.

12:59:25.030 : 00 00 00 04 78 3c 9e 36 01 04 06
12:59:25.075 : 85 14 00 00 04 13 1c d6 24
12:59:25.118 : 00 04 2b 00 00 00 00 14 2b 18
12:59:25.161 : 3e 00 00 04 3b 00 00 00 00
12:59:25.203 : 14 3b 39 f3 f6 cf 02 5b 19
12:59:25.246 : 00 02 5f 19 00 02 61 fe ff 02
12:59:25.290 : 23 1f 02 04 6d 2d 2a f3 27
12:59:25.332 : 44 06 e5 07 00 00 44 13 0f 82
12:59:25.378 : 0d 00 42 6c df 2c 01 fd 17
12:59:25.420 : 40 03 fd 0c 05 00 00 84 20 06
12:59:25.463 : 00 00 00 00 c4 20 06 00 00
12:59:25.505 : 00 00 84 30 06 00 00 00 00
12:59:25.553 : c4 30 06 00 00 00 00 7d 16

Leider kann ich nur nur Total energy auslesen mit "04 06".
Wie kann ich die anderen Werte wie m³, power, flow und Temp auslesen.

Ich habe diese Werte probiert, aber da kommt nichts raus :-(

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


Vielen Dank
toptobias

[Toptobias (toptobias)]

Hallo zusammen, so nach längerem Probieren habe ich es nun rausgefunden 
um die Daten aus einem Molline Ultramess C3 auszulesen.

Hier die Konfiguration:

1,0406uuUUUUUU@1,Total energy,kWh,w_total,0
1,0413bcd8@100,Total volume,m³,v_total,2
1,042Bbcd6@1,Current power,W,p_act,0
1,043Bbcd6@1000,Current flow,l/h,F_akt,3
1,025BuuUU@1,Flow temp,°C,t_flow,2
1,025FuuUU@1,Return temp,°C,t_return,2
1,0261bcd4@10,Temp diff,°K,t_diff,2

1,142Bbcd6@1,Maximum power,W,p_max,0
1,143Bbcd6@1000,Maximum flow,l/h,F_max,3

1,0478bcd8@1,Seriennummer,,serialnum,0
1,0223uuUU@1,Meter days,d,OpDays,0
1,03FD0Cuu@1,Firmware Version,,FW_Version,0

[Martin (klostopfer)]

Hallo zusammen in diesem wunderbar motivierenden Thread. Ich habe mich 
so n bisschen drangehängt und das ganze mit einem Sensonic II von ISTA 
probiert und es hat eigentlich auch ganz gut geklappt.

Ich habe das Script von Corny (https://github.com/corny/mbus-esp32) auf 
einen ESP32 (+Volkszähler-IR-Interface) gespielt, etwas angepasst 
(hauptsächlich musste die Länge des Antworttelegrams angepasst werden) 
und die Antwort als JSON per MQTT an Iobroker übermittelt und da mit 
einem entsprechenden Skript aufgearbeitet. Hat auch alles sehr gut 
funktioniert, konnte alle 15-16 Minuten auslesen, bei kürzeren Intervall 
kam einfach keine Antwort.

Hatte mir zum Testen eine originalverpackte Sensonic II mbus gekauft, 
weil ich zu faul war zum Testen immer vor meinem FBH-Verteiler zu sitzen 
und hab eine mit mbus-Anschluss genommen umd das auch direkt mal zu 
testen - und auch das hat genauso gut und mit dem gleichen Script 
funktioniert, lediglich die Aufwecksequenz braucht man nicht senden, auf 
(Kabel)-Mbus lauscht der Wärmemengenzähler wohl dauerhaft mit.

Weiterhin war es extrem wichtig, die Dioden gut vor dem optischen 
Interface zu platzieren. Davorhalten hat nichts gebracht, da war die 
Fehlerquote sehr hoch. Mit einem gedruckten Tool hat das dann aber ganz 
gut funktioniert und hat auch noch gleichzeitig die beiden Dioden 
gegeneinander abgeschirmt.

Das Ganze hat hervorragend funktioniert... SO LANGE ich an meinem 
Schreibtisch saß. Als ich das Projekt dann an den Zähler meiner 
Fußbodenheizung anschließend wollte, musste ich leider feststellen, dass 
scheinbar das optische Interface von meinem Zähler deaktiviert ist. Bei 
ISTa habe ich aber leider keinen Support ans Telefon bekommen, der davon 
Ahnung hatte. Angeblich ist der Port bei Mietgeräten immer deaktiviert, 
wenn man die Fernauslesung von ISTA nicht dazu kauft.

Und jetzt die große Frage: Hat irgendjemand eine Idee, wie ich meinen 
Wärmemengenzähler zum reden bekomme? Die optische Schnittstelle kann ja 
nichts verstellen, ist ja wirklich nur zum Auslesen und auch genau dafür 
vorgesehen. Hat jemand zufällig zugriff auf die Montagehandbücher von 
dem Ding, so dass man mal nachsehen kann, wie die Monteure die optische 
Schnittstelle freischalten? Hat jemand zufällig shcon mal zugesehen, wie 
die dinger programmiert werden? Oder kennt jemanden, der sachdienlich 
weiterhelfen kann?

Wäre klasse, wenn der Aufwand jetzt nicht umsonst war. Würde 
grundsätzlich ja auch das Fernauslesesystem der ISTA kaufen, aber man 
kann es halt nirgends einbinden und somit ist es nutzlos für mich.

Viele Grüße
Martin

[Sven K. (satirebird)]

Hallo Martin,

ich habe auch ein sensonic II und konnte die erfolgreich auslesen. Auf 
der optischen Schnittstelle der sensonic II eine spezielle 
Aufwachsequenz. Ich habe das damals mit Messung der Batteriespannung 
herausgefunden. Siehe hier:
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"

[Walter (wavoigt)]

@carsten12
Hallo,
Ich hab letzte Woche den Fernwärmeanschluss bekommen mit dem Sharky 775.
Jetzt hab ich versucht, den auszulesen mit dem Hichi Wlan Lesekopf.
Das Script ist von Carsten waermezaehler.txt (896 Bytes) vom 23.12.2022.
Ich bekomme zwar eine Antwort vom WMZ, aber die ist viel zu kurz, und 
ergibt auch keine Messwerte.
Das Drehen des Kopfes brachte nix.
Ich habs mit 2 verschiedenen Firmwares versucht, mit folgendem Ergebnis:

tasmota_V3.bin.gz:  von Nick v. 18.12.22
--------------------
19:38:53.640 wakeup start
19:38:56.935 wakeup end
19:38:56.937 wait for the meter
19:38:57.291 request data
19:38:57.406 : 10 5b fe 59 16

tasmota.bin.gz von Carsten v. 09.01.23
------------------------
19:51:04.585 wakeup start
19:51:07.879 wakeup end
19:51:07.880 wait for the meter
19:51:08.234 request data
19:51:08.441 : 68 16 16 68 08 01 72 01 30 
19:51:08.482 : 01 76 a5 11 40 04 b7 00 00 
19:51:08.527 : 00 0f 04 03 c1 04 fe df 8c 16

Ich wäre dankbar, wenn jemand eine Idee dazu hätte.

[Walter (wavoigt)]

Also, ich habs geschafft, hier eine kurze Zusammenfassung:
(Ich hab noch die offizielle Kommunikationsbeschreibung des Sharky 775 
angehängt)

Firmware: tasmota.bin.gz von Carsten v. 09.01.23
          (= tasmota12.3.1.bin.gz  mit w_delta)
          (tasmota_V3.bin.gz von Nick 18.12.22 geht bei mir nicht)

Script: waermezaehler.txt (889 Bytes) vom 23.12.22
        (liest alle 1 bzw 5 min ab und sendet MQTT)
oder:   das "Mitternachtsscript" von Carsten v. 09.01.2023
        (liest nach Mitternacht ab und berechnet Delta zum Vortag = 
w_delta)

Bei 1. Inbetriebnahme muss vermutlich im Script "waermezaehler.txt":
sml(1 1 "6804046853FE5000A116"
aktiviert werden, um die Datenübertragung zu initieren
-> Zähler sendet E5 (Ack)
Dann nur noch sml(1 1 "105BFE5916")

Befehlszeile:
mit "sensor53 d1" kommt folgende Response:
danach "sensor53 d0"

10:07:45.752 : 68 95 95 68 08 01 72 01 30 01 76 a5 11 40 
10:07:45.794 : 04 29 00 00 00 0c 06 83 00 
10:07:45.836 : 00 00 8c 10 06 00 00 00 00 
10:07:45.880 : 8c 20 13 03 01 00 00 0c 13 79 
10:07:45.923 : 75 00 00 0c 2b 00 00 00 00 
10:07:45.964 : 0b 3b 00 00 00 0a 5a 37 05 
10:07:45.006 : 0a 5e 89 03 0a 62 47 01 0b 26 
10:07:46.044 : 71 01 00 04 6d 11 0a f8 28 
10:07:46.086 : 4c 06 00 00 00 00 4c 13 00 00 
10:07:46.131 : 00 00 cc 10 06 00 00 00 00 
10:07:46.174 : cc 20 13 00 00 00 00 42 6c ff 
10:07:46.218 : 25 42 ec 7e 1f 35 fc 01 06 
10:07:46.260 : 00 00 00 00 fc 01 13 00 00 00 
10:07:46.305 : 00 fc 11 06 00 00 00 00 fc 
10:07:46.347 : 21 06 00 00 00 00 f2 01 6c 00 
10:07:46.391 : 00 c2 01 ec 7e ff 2c c5 16

[Phill (philip_mario)]

Sehr lehrreiche Beiträge. Als interresierter Laie will ich einfach nur 
danke sagen !!

Kann ebenfalls berichten, Sharky 775 kann man mittels HichiTTL und 
tasmota auslesen.

Ein Aspekt den ich trotzdem gerne fokussieren würde, da mich das etwas 
Zeit gekostet hat ..
Die initiale Sequenz welche den Sharky Daten entlockt wird getriggert 
durch ein  sml(1 1 "6804046853FE5000A116") .
Dieses muss wohl einmalig nach der Inbetriebnahme passieren ..

Bei mir hat das aber nicht auf anhieb funktioniert.

Nach vielen hin-und-her und etlichen Fehlversuchen habe ich die Anregung 
von Thomas probiert und ins waermezaehler.txt -Script von Carsten ein 
Delay(100) eingehekelt.

..

;reset application code
sml(1 1 "6804046853FE5000A116")
delay(100)
;set string to send to "105BFE5916" (REQ_UD2)
sml(1 1 "105BFE5916")

..

Anschließend wurde Sharky ziemlich gesprächig... ha .. ein Glücksmoment 
nach vielen Stunden :-) !!
Offensichtlich wollte er es etwas gemächlicher angehen und hat eine 
Pause gebraucht.
Die initiale Sequenz kann dann wieder auskommentiert werden.

Verwende ein Hichi TTL (Kabel nach unten) mit Wemos D1 mini .. TX-TX 
RX-RX, firmware tasmota.bin.gz von Carsten v. 09.01.23.

[Thorsten N. (thorsten_n)]

Hallo ich habe den CF Echo 2 von Itron und durch die tolle Anleitung 
hier im Forum habe  ich es geschafft und kann den WMZ auslesen und die 
Daten im HomeAssisstent anzeigen lassen. Nur leider werden ab und zu 
falsche Daten gesendet, dann werden auf einmal z.B. 50.000 mWh Total 
Energy gesendet. Hat hier jemand eine Idee woran es liegen könnte bzw 
ich das Problem beheben kann ?

Ich weiß nicht wie ich das Script ändern kann das unschlüssige Werte gar 
nicht gesendet werden.

Ich nutze das Script Waermemengenzaehler_Allmess.txt und habe Tasmota_V3 
geflasht.

[Wro (wro77)]

Hallo allerseits,

ich versuche vergeblich einen allmess Integral-V Ultralite Ha mit einem 
Hichi Lesekopf auszulesen. Ich nutze das Skript von Frank 
(Script_Waermemengenzaehler_Allmess.txt), welches bei Rubinho S. 
erfolgreich bei dem fast baugleichen WMZ (lediglich ohne HA) läuft.

Ich habe mich mit Rubinho auch bereits direkt ausgetauscht und wertvolle 
Tipps sowie seine funktionierende Tasmota Version zugesendet bekommen.

Ich kriege aber absolut keine Daten rein.
Der Lesekopf wurde schon in allen erdenklichen, sinnvollen Positionen 
gedreht. Ich habe auch schon mal etwas Klebeband zwischen Lesekopf und 
den Dioden platziert, um den Abstand zu vergrößern.
Der Lesekopf ist in Ordnung. Das Testskript mit Spiegel empfängt die 
eigenen Daten.

Ich habe inzwischen die Befürchtung, dass die Dioden bei dem WMZ nicht 
in Ordnung sind, die Batterie zu schwach ist oder die optische 
Schnittstelle evt. sogar gar nicht aktiviert ist (wenn das überhaupt vom 
Hersteller vorgesehen ist).

Vielleicht hat das Schwarmwissen hier aber auch noch einen 
entscheidenden Tipp in petto.

Hier noch ein paar Zeilen Code aus der Tasmota Konsole nach dem 
Aufwecken.

22:00:00.315 wakeup start
22:00:03.328 wakeup end
22:00:03.330 wait for the meter
22:00:03.632 request data
22:02:30.849 RSL: STATE = 
{"Time":"2023-11-30T22:02:30","Uptime":"0T09:10:29","UptimeSec":33029,"H 
eap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POW 
ER":"ON","Wifi":{"AP":1,"SSId":"xxx","BSSId":"xxx","Channel":6,"Mode":"1 
1n","RSSI":72,"Signal":-64,"LinkCount":1,"Downtime":"0T00:00:03"}}
22:02:30.855 RSL: SENSOR = 
{"Time":"2023-11-30T22:02:30","WP_WMZ":{"Energie_total":0.000,"Durchflus 
s_total":0.00,"Leistung_akt":0.00,"Durchfluss_akt":0.000,"temp_Vorlauf": 
0.0,"temp_Ruecklauf":0.0,"temp_diff":0.00,"Betriebstage":0}}

[Willy L. (sabberlotte)]

Schon probiert?:
[[Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"]]

[Wro (wro77)]

Danke für den Tipp.
Habe ich bisher noch nicht gemacht und ich bin mir auch nicht sicher, ob 
das meine elektrotechnischen Kompetenzen hergeben, da ich mal stark 
davon ausgehe, dass ich das löten muss?

Hast du das bei einem Hichi Lesekopf gemacht oder ist dein Lesekopf ein 
Eigenbau?

[Willy L. (sabberlotte)]

Sicher musst du löten (oder jemand der das kann).

Wro schrieb:
> Hast du das bei einem Hichi Lesekopf gemacht oder ist dein Lesekopf ein
> Eigenbau?

Kein Eigenbau.
Hichi kompatibel würde ich sagen.
Bei meiner Anwendung war ausschlaggebend die IR Sendeleistung zu 
reduzieren und den Empfänger empfindlicher zu machen.

LG

[Walter (wavoigt)]

@thorsten_n
Hi, ich hab das gleiche Problem, dass sporadisch unplausible Werte 
kommen, im Extremfall "0" oder irgendein Zufallswert.
Das liegt vermutlich an dem optischen Interface, bei dem ab und zu 
Lesefehler auftreten.
Wie ich das im Tasmota script beheben kann, hab ich noch nicht 
herausgefunden, aber ich hab "Hilfssensoren" ins configuration.yaml 
eingefügt, und mache die Plausibilitätsprüfung dort.

# Test des Eingangswertes auf Grenzen relativ zum vorigen Wert, 
# falls der Sprung zu gross ist, wird der vorige Wert übernommen 
template:
  - sensor:
      name: "Tasmota 3 Waerme W Total Korr"
      unique_id: "tasmota_3_waerme_w_total_korr"
      icon: mdi:chart-bar
      state: >-
        {% if (is_number(states("sensor.tasmota_3_waerme_w_total")) and is_number(states("sensor.tasmota_3_waerme_w_last"))) %}
          {% set W = states("sensor.tasmota_3_waerme_w_total")| float %}
          {% set L = states("sensor.tasmota_3_waerme_w_last") | float %}
          {% if ((W - L) > 400) %} {{ L }}
          {% elif ((W - L) < 10) %} {{ L }}
          {% else %} {{ W }}
          {% endif %} 
        {% else %} {{ states("sensor.tasmota_3_waerme_w_total") }}
        {% endif %} 

# Speichern des letzten (hoffentlich guten) Eingangswertes
  - sensor:
      name: "Tasmota 3 Waerme W last"
      unique_id: "tasmota_3_waerme_w_last"
      state: >-
        {% if is_number(states("sensor.tasmota_3_waerme_w_total_korr")) %}
          {{ states("sensor.tasmota_3_waerme_w_total_korr") }}
        {% else %} {{ states("sensor.tasmota_3_waerme_w_total") }}
        {% endif %}

Ist vielleicht nicht besonders elegant programmiert, aber bei mir 
funktioniert es bisher.
Für feedback bin ich dankbar :-)

[Thorsten N. (thorsten_n)]

Hallo irgendwie funktioniert es bei mir noch nicht,

Habe deinen Code auf meine Namen geändert, weiß nicht ob ich noch was 
falsch gemacht habe. Aber die Werte von den korrigierten sind gleich dem 
nicht korrigierten Werten.

template:
  - sensor:
      - name: "WärmeMengenZähler"
        unique_id: "WMZ"
        unit_of_measurement: 'kWh'
        device_class: "Gas"
        state_class: "total_increasing"
        state: >
          {{ float(states('sensor.tasmota_wp_wmz_energie_total')) | round(3) }}
  - sensor:
      name: "WärmeMengenZähler Korr"
      unique_id: "WärmeMengenZähler Korr"
      icon: mdi:chart-bar
      unit_of_measurement: 'kWh'
      device_class: "Gas"
      state_class: "total_increasing"
      state: >-
        {% if (is_number(states("sensor.tasmota_wp_wmz_energie_total")) and is_number(states("sensor.tasmota_3_waerme_w_last"))) %}
          {% set W = states("sensor.tasmota_wp_wmz_energie_total")| float %}
          {% set L = states("sensor.tasmota_3_waerme_w_last") | float %}
          {% if ((W - L) > 400) %} {{ L }}
          {% elif ((W - L) < 10) %} {{ L }}
          {% else %} {{ W }}
          {% endif %} 
        {% else %} {{ states("sensor.tasmota_wp_wmz_energie_total") }}
        {% endif %} 
# Speichern des letzten (hoffentlich guten) Eingangswertes
  - sensor:
      name: "Tasmota 3 Waerme W last"
      unique_id: "tasmota_3_waerme_w_last"
      state: >-
        {% if is_number(states("sensor.tasmota_3_waerme_w_total_korr")) %}
          {{ states("sensor.tasmota_3_waerme_w_total_korr") }}
        {% else %} {{ states("sensor.tasmota_wp_wmz_energie_total") }}
        {% endif %}

[Walter (wavoigt)]

Hi, ich hab das ganze nochmal simuliert, bei mir funktioniert es:
anstatt "sensor.tasmota_wp_wmz_energie_total" hab ich ein Numerisches 
Eingabefeld zum Testen "input_number.nummer".
Der Code:

template:

# Test des Eingangswertes auf Grenzen relativ zum vorigen Wert 
# falls der Sprung zu gross ist, wird der vorige Wert übernommen 
  - sensor:
      name: "Tasmota 3 Waerme W Total korr_test"
      unique_id: "tasmota_3_waerme_w_total_korr_test"
      device_class: energy
      # state_class: "total_increasing"      
      icon: mdi:chart-bar
      state: >-
        {% if (is_number(states("input_number.nummer")) and is_number(states("sensor.tasmota_3_waerme_w_last_test"))) %}
          {% set W = states("input_number.nummer")| int %}
          {% set L = states("sensor.tasmota_3_waerme_w_last_test") | int %}
          {% if ((W - L) > 400) %} {{ L }}
          {% elif ((W - L) < 10) %} {{ L }}
          {% else %} {{ W }}
          {% endif %} 
        {% else %} {{ states("input_number.nummer") }}
        {% endif %} 

# Speichern des letzten Eingangswertes
  - sensor:
      name: "Tasmota 3 Waerme W last_test"
      unique_id: "tasmota_3_waerme_w_last_test"
      device_class: energy
      # state_class: "total_increasing"      
      state: >-
        {% if is_number(states("sensor.tasmota_3_waerme_w_total_korr_test")) %}
          {{ states("sensor.tasmota_3_waerme_w_total_korr_test") }}
        {% else %} {{ states("input_number.nummer") }}
        {% endif %}

[Walter (wavoigt)]

Ich hab die Plausibilitätsprüfung jetzt auch im Tasmota script 
realisiert:
(Ausschnitt)
(die Grenze 400 muss eventuell angepasst werden, da Tasmota nach einem 
Reset eventuell 0 liefert und erst nach der nächsten Ablesung den 
richtigen Wert, was zu einem grösseren Sprung führen kann)

>D
w_new=0
w_corr=0
w_delta=0
p:w_last=0
>B
;setup sensor
->sensor53 r
>T
w_new=WAERME#w_total

; Wert auslesen...

w_delta=w_new-w_last
w_corr=w_new
; Plausibilitaetstest
if w_delta>400 
or w_delta<10 
then
if w_last>10
then 
w_corr=w_last
endif
w_delta=0
endif
w_last=w_corr
svars
print w_new %0w_new%
print w_delta %0w_delta%
print w_corr %0w_corr%

>J  
,"w_delta":%w_delta%,"w_corr":%w_corr%

[Thorsten N. (thorsten_n)]

Oh super das wäre natürlich super wenn ich es direkt im Tasmota Script 
änder könnte. Allerdings vestehe ich noch nicht genau wo ich dies genau 
in meinem Script einfügen muss.

Hier mein Script

>D

;start, define variables

wkup=1

period=60

;read meter every n minutes after midnight (60--> 01:00, 02:00...)

blk=0

>B

;setup sensor

->sensor53 r

>S

if time%period==0 

and blk==0

;minutes since midnight divided by period have a remainder of "0"

then

=#readmeter

blk=1

;set a flag to execute the readout only once every period

endif

if time%period-1==0 

and blk==1

;one minute after we entered the first loop

then

blk=0

; reset the flag

endif

#readmeter

print wakeup start

;set serial protocol

sml(-1 1 "2400:8N1")

;send 0x55 for 2,2 seconds with 8N1 (73x), 2400 baud (wakeup sequence)

for wkup 1 73 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 "105B005B16" (request data)

sml(1 1 "105BFE5916")

>M 1

+1,3,rE1,0,2400,WP_WMZ,1

1,0406uuUUuuUUs@1000,Total energy,MWh,Energie_total,3

1,0C14bcd8@100,Total volume,m³,Durchfluss_total,2

1,0B2Dbcd6@10,Current power,KW,Leistung_akt,2

1,0B3Bbcd6@1000,Current flow,m³/h,Durchfluss_akt,3

1,0A5Abcd4@10,Flow temp,°C,temp_Vorlauf,1

1,0A5Ebcd4@10,Return temp,°C,temp_Ruecklauf,1

1,0B61bcd6@100,Temp diff,°C,temp_diff,2

1,0227uuUU@1,Meter days,d,Betriebstage,0

;1,046Dxxuu@1-1,Hour,h,time_h,0

;1,046Duu@1,Minute,min,time_m,0

;1,046Dxxxxuu@1,Day,dd,time_d,0

;1,046Dxxxxxxuu@1,Month,mm,time_m,0

#

Könntest du mir hier eventuell helfen ?

[Felix H. (flas)]

Hallo zusammen,

ich möchte einen Zenner Zelsius C5 Wärmemengenzähler (mit optischer 
Schnitstelle IRDA/ZVEI) auslesen. Ich nutze einen Wifi 
Volkszähler/IR-Lesekopf. Ich habe die Firmware tasmota_V3.bin.gz von 
Nick v. 18.12.22 und das folgende script von carsten vom 23.12.2022.
Ich habe alles mögliche versucht (Lesekopf gedreht, Taste am Zähler 
gedrückt, Lesekopf verschoben). Ich habe nichts selbst kompiliert, 
lediglich die o.g.Firmware und das skript unverändert genutzt. Hier das 
script:

>D
;start, define variables
wkup=1


>B
;setup sensor
->sensor53 r


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

#readmeter

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

;send 0x55 for 3 seconds with 8N1 (72x), 2400 baud (wakeup sequence)
for wkup 1 72 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 "6804046853FE5000A116"
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
#

Ich bekomme keine Daten. In der console sehe ich folgendes:
13:28:54.152 read meter
13:28:54.153 wakeup start
13:28:57.448 wakeup end
13:28:57.449 wait for the meter
13:28:57.802 request data
13:29:57.046 read meter
13:29:57.047 wakeup start
13:30:00.341 wakeup end
13:30:00.342 wait for the meter
13:30:00.695 request data

Was mache ich falsch? Igendein Tipp?
Danke schonmal.

[Thorsten N. (thorsten_n)]

Felix H. schrieb:
> Was mache ich falsch? Igendein Tipp?
> Danke schonmal.

Hast du einfach mal einen Tag gewarte ? EWs kann manchmal etwas dauern 
bis Daten gesendet werden.

[Thorsten N. (thorsten_n)]

Walter schrieb:
> Ich hab die Plausibilitätsprüfung jetzt auch im Tasmota script
> realisiert:
> (Ausschnitt)
> (die Grenze 400 muss eventuell angepasst werden, da Tasmota nach einem
> Reset eventuell 0 liefert und erst nach der nächsten Ablesung den
> richtigen Wert, was zu einem grösseren Sprung führen kann)

Habe es doch zum größten Teil hin bekommen und es werden die Werte in 
der Console angezeigt allerdings jede Sekunde ist dies so gewollt ?

Jetzt bekomme ich die Daten nur nicht an HomeAssistent gesendet. Kann es 
sein das hierfür noch  die user_config_override.h verändert werden muss 
? Siehe angehängtes PDF Seite 34

[Walter (wavoigt)]

Bin grade im Urlaub, melde mich an Wochenende.

[Morris (morris12)]

Hallo zusammen
Aufgrund dieses Beitrages und der zur Verfügung gestellten Infos zum 
Auslesen der optischen m-bus Schnittstelle habe ich mir einen Allmess 
Integral-V UltraLite PRO Wärmemengenzähler (aktuell noch im 
Batteriebetrieb (neue Batterie)) sowie den Lesekopf von Hichi gekauft.

An dieser Stelle, vielen Dank für die ganze Vorarbeit und das Teilen der 
Arbeit.

Ich habe darauf die tasmota_V3.bin.gz Firmware aufgespielt und das 
angehängte Skript aufgespielt und Sensor53 d1 ausgeführt.
Leider erhalte ich kaum eine Ausgabe und hoffe, dass jemand eventuell 
eine Idee hat, woran dies liegen könnte. Die Ausgaben im Anhang habe ich 
sehr unterschiedlich erhalten, ich erkenne da kein Muster.

Für die Unterstützung danke ich im Voraus.
Beste Grüsse
Morris

[Walter (wavoigt)]

@thorsten_n
Thorsten N. schrieb:
> Habe es doch zum größten Teil hin bekommen und es werden die Werte in
> der Console angezeigt allerdings jede Sekunde ist dies so gewollt ?
>
Im Anhang mein aktuelles Script.
Es handelt sich um das modifizierte "Mitternachtsscript" von Carsten v. 
09.01.2023 (liest nach Mitternacht ab und berechnet Delta zum Vortag =
w_delta)

Als Firmware verwende ich tasmota.bin.gz von Carsten v. 09.01.23
Das Sendeintervall stellst du ein bei Tasmota Main Menu - Configuration 
- Configure Logging - Telemetry Period (in Sekunden)

Ich hab dir noch meine Testdatei angehängt (in C), dann kannst du die 
Korrektur mit einem Online C Compiler Testen.

[Felix H. (flas)]

Thorsten N. schrieb:
> Felix H. schrieb:
>> Was mache ich falsch? Igendein Tipp?
>> Danke schonmal.
>
> Hast du einfach mal einen Tag gewarte ? EWs kann manchmal etwas dauern
> bis Daten gesendet werden.

Also ich habe jetzt 2 Tage gewartet. Aber noch keine Rückmeldung vom 
Wärmemengenzaehler. Ich bin ratlos.

[Walter (wavoigt)]

@morris12
Hast du denn schon die Datenübertragung initialisiert mit sml(1 1 
"6804046853FE5000A116" ?
Die tasmota_V3.bin.gz von Nick hat bei mir auch nicht funktioniert.
siehe:
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"
und:
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"

[Thorsten N. (thorsten_n)]

Noch einmal eine grunsätzliche Frage, weiß jemand wie der Lesekopf 
optimal platziert werden sollte ?Es gibt ja eine helle und dunkle Diode.

Beim Wärmemengenzähler scheinen die Dioden übereinander zu liegen. Dann 
ist ja eigentlich nur die Frageob das Kabel nach rechts gucken sollte 
oder anders herum.

[Frank (xmp1)]

Beim Echo muss das Kabel bei Verwendung des Hichi nach links zeigen.

[Thorsten N. (thorsten_n)]

Danke super, und hält der bei euch gut ? Bei mir ist dieser sehr locker, 
scheint nicht sher magnetisch zu sein.

Beim Stromzähler habe ich einen Hichi USB und dieser ist viel fester, 
wird richtig an den Stromzähler heran gezogen und man muss schon feste 
ziehen damit dieser wieder ab geht.

Frage weil ich mir vorstellen kann das ich deshalb immer mal wieder 
merkwürdige Werte ausgelesen bekommen.

[Morris (morris12)]

@Walter

Danke für die Hinweise, habe ich mittlerweile auch probiert, jedoch 
erhalte ich dann keine Rückmeldung vom Zähler:

11:39:16.940 read meter
11:39:16.941 wakeup start
11:39:20.232 wakeup end
11:39:20.233 wait for the meter
11:39:20.585 request data

Habe dies mit verschiedenen Versionen von Nick und Carsten probiert, 
auch mit und ohne dem delay(100).

Mit der Version von Nick und seinem skript habe ich wenigstens ein paar 
wenige Ausgaben vom Zähler (gemäss meinem letzten Post) erhalten, 
zumindest denke ich, dass dies Ausgaben von Zähler sind. Aber auch bei 
seiner Version/Skript hat sml(1 1 "6804046853FE5000A116" (mit delay(100) 
nicht gewirkt...

Beste Grüsse
Morris

[Walter (wavoigt)]

Also ich hatte mit der Firmware von Nick zuerst auch einen Einzeiler als 
Antwort:
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"
Dann bin ich folgendermassen vorgegangen:
Firmware tasmota.bin.gz von Carsten v. 09.01.23,
Script waermezaehler.txt (889 Bytes) vom 23.12.22
Die Initialisierungssequenz sml(1 1 "6804046853FE5000A116") aktiviert 
und erst mal die den Readoutbefehl sml(1 1 "105BFE5916") auskommentiert
-> Zähler sendet E5 (Ack)
Die Initialisierungssequenz sml(1 1 "6804046853FE5000A116") 
auskommentiert und den Readoutbefehl sml(1 1 "105BFE5916") aktiviert
Danach hat es funktioniert.
Ich hab den Sharky 775, der ist angeblich Baugleich mit deinem UltraLite 
PRO,
vielleicht gibt es da doch Unterschiede ?

[Phill (philip_mario)]

@Morris

So wie ich die Ausgaben oben interpretiere, fragt das Script jede Minute 
beim Zähler ein Readout an -> sml(1 1 "105BFE5916").
Es kommt auch was zurück.
Vermutung .. Die Antwort vom Zähler ist unvollständig, deswegen kann es 
auch nicht korrekt ausgewertet werden.
Weiter oben war die Rede von schwächelnder Batterie. Auch nicht ganz 
abwägig, die Positionierung des Lesekopfes.

Ich würde meinen, die Sequenz sml(1 1 "6804046853FE5000A116") hat den 
Zähler grundsätzlich initialisiert und kann deswegen auskommentiert 
werden.

.. weitere Erfahrungen ..
Bei meinem Sharky gehe ich ähnlich vor, Readout zyklisch alle 5 min, 
allerdings antwortet der Zähler viel seltener.
Nach einem erfolgreichem Auslesen (Werte plausibel) dauert es eben ca. 
110 Min. bis das nächste mal ein erfolgreicher Readout stattfindet. 
Dazwischen kommt einfach nix.
Hier legt sich wohl die optische Schnittstelle definiert schlafen (ggf. 
wg. Batterieverbrauch).
Das erschwert die Fehlersuche am Anfang. Vielleicht Optokopf 
verschieben, Änderung notieren, dann 3-4 Stunden warten usw. bis
ein plausibler wert kommt ..
Durchhalten!!

[Willy L. (sabberlotte)]

...und nochmal:


Schon probiert?:

[[Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"]]

[Thomas C. (thomas_c31)]

Hallo,
nun habe ich es auch endlich geschafft meinen Pollucom E/S auszulesen. 
Ich habe dafür folgendes Setup:
- Hichi TTL Lesekopf mit Druckgehäuse und etwas Heisskleber am WMZ 
befestigt
- Rasperry Pi Zero mit aktivierter serieller Schnittstelle und WLAN 
(https://howtoraspberrypi.com/enable-port-serial-raspberry-pi/) an 
GPIO14 und 15

enable_uart=1
dtoverlay=miniuart-bt

-> /dev/serial0 ( Test mit minicom und weisser Oberfläche ist hilfreich)
- Python-Script 
https://forum-raspberrypi.de/forum/thread/57389-sensus-pollucom-e-ueber-pymeterbus-auslesen/?postID=543096#post543096
- Python Script sendet die Json-Daten dann an meinen MQTT-Server (habe 
ich um diese Funktion erweitert)
- Python-Script läuft alle 55 Minuten per cronJob
- Einbettung in Homeassistant über Sensoren:

mqtt:    
 sensor:
    - unique_id: WMZ_Pollucom_ENERGY_WH
      name: "WMZ Pollucom ENERGY_WH"
      state_topic: "wmz"
      unit_of_measurement: "Wh"
      value_template: "{{ value_json.body.records[0].value}}"

[Christoph J. (christoph_j462)]

Hallo zusammen,

habe hier auch einen Sensus Pollucom E den ich gerne auslesen würde.
Habe schon mehrfach versucht mit dem Script von 
"https://forum-raspberrypi.de/forum/thread/57389-sensus-pollucom-e-ueber-pymeterbus-auslesen/?postID=543096#post543096"; 
diesen auszulesen.
Leider klappt dies nicht.

An der Positionierung kann es nicht liegen, da ich über Minicom 3 meinen 
Zähler einwandfrei auslesen kann.

Ich verwende momentan einen Raspberry Pi3 an diesem UNIProg: 
https://github.com/PricelessToolkit/UNIProg_Programmer

Habe mit eben diesem genauso wie er auch am Raspi hängt mit Minicom 3 an 
meinem Windows Laptop den Zähler auslesen können.

Mir ist nun aufgefallen das es in Minicom 3 einmal den Sensus Pollucom 
E/C gibt und dann auch noch den Sensus Pollucom E/C (Neue Version)

Ich kann bei mir nur die Neue Version auslesen.
Könnte es sein das dieses Skript für die "ältere Version" ist?

Und könnte mir jemand helfen das Skript an die neue Version anzupassen?

[Uwe (mymikro)]

Toptobias schrieb:
> Hallo zusammen, so nach längerem Probieren habe ich es nun rausgefunden
> um die Daten aus einem Molline Ultramess C3 auszulesen

Hallo Tobias,

ich versuche meinen Molline Ultramess C3 auszulesen. Ich sehe zwar, das 
er manchmal Daten liefert. Alles in allem aber nicht reproduzierbar. 
Könntest du bitte einmal dein Skript für den Zähler komplett posten. 
Welche Firmware verwendest du ? V3 von Nick oder die von Carsten ?

Danke dir,
Uwe

[Toptobias (toptobias)]

Hallo Uwe

Ich habe den Hichi Wifi Lesekopf von ebay gekauft, und habe keine neue 
Firmware installiert. Mir mir läuft die Tasmota 12.3.1 
(https://github.com/arendst/Tasmota) das script was bei mir läuft ist 
dieses. Es ist nicht perfekt aber ich bekomme ein paar richtige Daten 
aus dem WMZ.


>D
;start, define variables
wkup=1
period=60
;read meter every n minutes after midnight (60 --> 01:00, 02:00...)
blk=0


>B
;setup sensor
->sensor53 r

>S
if time%period==0
and blk==0
;minutes since midnight divided by period have a remainder of "0"
then
=#readmeter
blk=1
;set a flag to execute the readout only once every period
endif

if time%period-1==0
and blk==1
;one minute after we entered the first loop
then
blk=0
; reset the flag
endif


#readmeter

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

;send 0x55 for 3 seconds with 8N1 (72x), 2400 baud (wakeup sequence)
for wkup 1 72 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 "6804046853FE5000A116"
sml(1 1 "105BFE5916")

>M 1
+1,3,rE1,0,2400,WAERME,1
1,0406uuUUUUUU@1,Total energy,kWh,w_total,0
1,0413bcd8@100,Total volume,m³,v_total,2
1,042BuuUUUU@1,Current power,W,p_act,0
1,043BuuUU@1,Current flow,l/h,F_akt,3
1,025BuuUU@1,Flow temp,°C,t_flow,0
1,025FuuUU@1,Return temp,°C,t_return,0
1,0261uuUU@0.01,Temp diff,°K,t_diff,2

1,142BuuUUUU@1,Maximum power,W,p_max,0
1,143Bbcd6@1000,Maximum flow,l/h,F_max,3

1,01FD17uu@1,Fehlerbyte,,Error_State,0
1,0223uuUU@1,Meter days,d,OpDays,0
1,03FD0Cuu@1,Firmware Version,,FW_Version,0

#


Wasnicht so richtig funktioniert, aber ich denke das liegt an der 
Berechung innerhalb von Tasmota, ist Temp diff und auch Error. Aber naja 
Hauptsache Total energy stimmt.

Gruß
Tobias

[Uwe (mymikro)]

Hallo Thomas,

danke dir für deine Rückmeldung. Ich habe das mal als Startpunkt 
genommen. Etliche Stunden später gelingt es mir nun "manchmal" den 
Wärmezähler auszulesen. Und wenn es klappt werden auch sinnvolle Werte 
angezeigt. Mal abgesehen von der Firmware Version. Die stimmt noch nicht 
mit der überein die im Display des Zählers angezeigt wird. Auf meinem 
Zähler wird die Firmware "1.03 0.14" im Menü 2-09 angezeigt. Um die 
anderen Werte korrekt (In Übereinstimmung mit den im Displaye 
angezeigten Werten) darzustellen habe ich einige der Metrics Decoder 
angepasst. Ich habe lange mit der Hichi (Habe ich auch bei eBay gekauft) 
Firmware 12.3.1 gearbeitet bis die Werte die gelesen und angezeigt 
wurden, wenn sie denn gelesen wurden plausibel waren. Dann habe ich mich 
mal dran gemacht die aktuelle Version der Tasmota Firmware (13.4) für 
den SmartMeter zu bauen um zu versuchen ob ich damit den Zähler 
reproduzierbarer auslesen kann.

Die angehängte Version habe ich jetzt bei mir mit folgendem Script im 
Einsatz:

>D
;start, define variables
wkup=1
period=60
;read meter every n minutes after midnight (60 --> 01:00, 02:00...)
blk=0


>B
;setup sensor
->sensor53 r

>S
if time%period==0
and blk==0
;minutes since midnight divided by period have a remainder of "0"
then
=#readmeter
blk=1
;set a flag to execute the readout only once every period
endif

if time%period-1==0
and blk==1
;one minute after we entered the first loop
then
blk=0
; reset the flag
endif


#readmeter

print wakeup start
;set serial protocol
ret=sml(-1 1 "2400:8N1")
print do it
;send 0x55 for 3 seconds with 8N1 (72x), 2400 baud (wakeup sequence)
for wkup 1 72 1
sml(1 1 "55555555555555555555")
next
print wakeup end
wkup=1

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

print switch serial protocol
sml(-1 1 "2400:8E1")

print initialize
sml(1 1 "1040004016")
delay(100)

print set data frame mode "Standard"
sml(1 1 "6804046853FE5000A116")
delay(100)

print request data
sml(1 1 "105BFE5916")

>M 1
+1,3,rE1,0,2400,WAERME,1
1,0406uuUUuuUUs@1000,Total energy,MWh,w_total,3
1,0413bcd8@100,Total volume,m³,v_total,2
1,042BuuUUuuUUs@1,Current power,W,p_act,0
1,043BuuUUuuUUs@1,Current flow,l/h,F_akt,0
1,025BuuUU@1,Flow temp,°C,t_flow,0
1,025FuuUU@1,Return temp,°C,t_return,0
1,0261uuUU@100,Temp diff,°C,t_diff,2

1,142BuuUUuuUUs@1000,Maximum power,kW,p_max,3
1,143BuuUUuuUUs@1,Maximum flow,l/h,F_max,0

1,0478uuUUuuUUs@1,Seriennummer,,serialnum,0
1,0223uuUU@1,Meter days,d,OpDays,0
1,03FD0Cuu@1,Firmware Version,,FW_Version,0
#

Ein Datensatz sieht damit bei mir so aus:

22:38:00.772 wakeup start
22:38:00.774 do it
22:38:04.072 wakeup end
22:38:04.074 wait for the meter to wake up
22:38:04.427 switch serial protocol
22:38:04.430 initialize
22:38:04.537 set data frame mode "Standard"
22:38:04.645 request data
22:38:04.974 : 10 40 00 40 16 e5 68 04 04 68 53 fe 50 00 a1 16 e5 10 5b fe 59 16 68 85 85 68 08 00 72 28 55 15 
22:38:04.979 : 85 c5 14 00 04 e3 00 00 00 04 78 c8 5e 13 05 04 06 5a 1b 01 00 04 13 d7 d7 28 00 04 2b 00 00 00 
22:38:05.023 : 00 14 2b 90 7a 00 00 04 3b 00 00 00 00 14 3b 75 03 00 00 02 5b 2f 00 02 5f 1e 00 02 61 a1 06 02 
22:38:05.169 : 23 60 07 04 6d 25 36 05 33 44 06 41 0b 01 00 44 13 cc 88 26 00 42 6c ff 2c 01 fd 17 00 03 fd 0c 
22:38:05.316 : 05 00 00 84 20 06 00 00 00 00 c4 20 06 00 00 00 00 84 30 06 00 00 00 00 c4 30 06 00 00 00 00 4a 
22:38:05.360 : 16

Die gesendeten Befehle werden mit dem ACK sauber quittiert und dann der 
Datensatz gesendet.

Mein Problem ist aber weiterhin, unabhängig davon ob ich die Tasmota 
12.3.1 verwende oder die 13.4, das ich den Zähler nur sporadisch mal 
auslesen kann. Im Fehlerfall, wenn keine Daten gelesen werden scheint es 
so zu sein das es nicht gelingt den Zähler aufzuwecken. Die CMDs an den 
Zähler gehen raus. Es kommt aber kein ACK.

22:40:00.373 wakeup start
22:40:00.375 do it
22:40:03.672 wakeup end
22:40:03.674 wait for the meter to wake up
22:40:04.026 switch serial protocol
22:40:04.030 initialize
22:40:04.138 set data frame mode "Standard"
22:40:04.246 request data
22:40:04.614 : 10 40 00 40 16 68 04 04 68 53 fe 50 00 a1 16 10 5b fe 59 16

Ich habe es bereits damit versucht delays einzubauen, die WakeUp Sequenz 
länger oder kürzer zu machen und auch mit oder ohne "Initialize" und 
"set data frame mode standard" CMDs.

Wenn jemand noch eine Idee hat was ich bzgl des aufwecken des Zählers 
noch probieren könnte, gerne.

Grüße,
Uwe

[Toptobias (toptobias)]

Hallo Uwe

Das mit den sporadisch auslesen habe ich auch. Ich habe sogar ein nicht 
Original Netzteil eingebaut, aber dieses hat auch nicht viel gebracht.
Bei werden je nach Lust und Laune des WMZ am Tag 3 bis 7 Messungen 
auslesen.
Hallt aber sehr willkürlich nicht zur selben Zeit.
Wie du im script gesehen hast habe ich den Ausleseintervall auf eine 
Stunde gesetzt. Ich hatte ihn auch mal aller 8 Stunden auslesen lassen. 
Dann hast du 3-mal am Tag eine Ablesung.

Wenn du eine genaue Auslesung des WMZ haben willst kommst du um ein BUS 
Modul nicht drum herum. Da kannst du sofort auf die Daten zugreifen.

Beste grüße
Tobias

[Uwe (mymikro)]

Hallo Tobias,

dann belasse ich es jetzt mal dabei und schaue mal wie ich bei mir das 
Intervall einstelle damit ich mindestens 1 mal am Tag eine 
Aktualisierung bekomme. Zu oft mag ich auch nicht auslesen damit mir die 
Batterie nicht vorzeitig aussteigt.

Nur der Vollständigkeit halber falls das hier noch jemand liest und auch 
diesen Zähler hat. Bei mir muss das "Total Volumen" auch als Hex 
decodiert werden und nicht als BCD8.

Uwe schrieb:
> 1,0413bcd8@100,Total volume,m³,v_total,2

Muss bei meinem Zähler damit auch ersetzt werden durch

1,0413uuUUuuUUs@1000,Total volume,m³,v_total,3

um mit dem auf dem Display angezeigten Wert überein zu stimmen.
Damit sind in meinem Datensatz alle Werte Hex codiert.

Viele Grüße,
Uwe

[Toptobias (toptobias)]

Hallo Uwe

Vielen Dank für die Konvertierung. Diese habe ich nun auch übernommen, 
und nun stimmen die Werte. Zur Vollständigkeit lade ich dir mal die Docu 
über den M-Bus hoch. Vielleicht hillft es dir weiter.

Beste Grüße
Tobias

[Toptobias (toptobias)]

Hallo Uwe

Vielleicht hast du ein Tip was das ist:
Mit deiner Kodierung kann ich nun die Werte richtig darstellen.
Nur ein Wert macht mir Probleme und ich weiss nicht warum.
Es geht um 1,143BuuUUuuUUs@1,Maximum flow,l/h,F_max,0
da bekomme ich ein risigen Wert von 3489067833 l/h angezeigt, am WMZ 
lese ich aber 890067,67- m³/h ab.
Hast du eine Idee warum die Kodierung nicht stimmen kann?

Vielen Dank
Tobias

[Uwe (mymikro)]

Hallo Tobias,

danke zunächst mal für die Protokollbeschreibung. Und dann.....

Hut ab vor deinem Wärmezähler. Der Zeigt ernsthaft 890067,67- m³/h für 
das Register 4-02-1 als maximalen Durchfluss an ? Der mittlere 
Wasserbedarf der Stadt München sind 300-350.000 m³ pro Tag. Über den 
Daumen also 12.500 m³/h. Da hoffe ich mal, du musstest die Wärme nicht 
zahlen die das Wasser transportiert hat das dein WMZ als Durchfluss im 
Peak denkt gemessen zu haben scheint.

Aber nun mal zu den 3489067833 l/h die Tasmota anzeigt. Das wäre in Hex 
0xCFF6F339 bzw. im Byte Strom 0x39 0xF3 0xF6 0xCF. Gemäß 
Protokollbeschreibung ist der Wert wie die meisten anderen die der 
Zähler liefert vorzeichenbehaftet. Der Dekoder ist aber aktuell auf 
unsigned eingestellt. Als signed wird aus dem Hex Wert im 2er Komplement 
eine -805899463. Entsprechend -805899,463 m³/h. Der Wert ist schon mal 
näher dran an dem im Display. Und der hat ja an der dritten 
Nachkommastelle auch ein Minus :-)

Ich würde mir noch ansehen ob die Daten korrekt empfangen werden und 
wenn ja, dann is es so das der Zähler den Wert ausgibt. Dafür brauchst 
du von der Konsole mal einen kompletten Datentransfer. Nur für die Doku. 
Aktivieren mit "sensor53 d1" warten bis ein kompletter Datensatz 
empfangen wurde und dann mit "sensor53 d0" wieder abstellen.

Bei mir wäre das:

22:38:04.645 request data
22:38:04.974:10 40 00 40 16 e5 68 04 04 68 53 fe 50 00 a1 16 e5 10 5b fe 59 16 68 85 85 68 08 00 72 28 55 15 
22:38:04.979:85 c5 14 00 04 e3 00 00 00 04 78 c8 5e 13 05 04 06 5a 1b 01 00 04 13 d7 d7 28 00 04 2b 00 00 00 
22:38:05.023:00 14 2b 90 7a 00 00 04 3b 00 00 00 00 14 3b 75 03 00 00 02 5b 2f 00 02 5f 1e 00 02 61 a1 06 02 
22:38:05.169:23 60 07 04 6d 25 36 05 33 44 06 41 0b 01 00 44 13 cc 88 26 00 42 6c ff 2c 01 fd 17 00 03 fd 0c 
22:38:05.316:05 00 00 84 20 06 00 00 00 00 c4 20 06 00 00 00 00 84 30 06 00 00 00 00 c4 30 06 00 00 00 00 4a 
22:38:05.360:16

Da suchst du in der ersten Zeile mal nach dem 68xxxx68. Die beiden xx 
Bytes zwischen der 68 geben die Länge des Datenblocks an. Bei mir 0x85 
== 133 Bytes. Los geht es mit dem ersten Byte nach dem 68xxxx68 Header. 
Bei mir die 0x08. Nicht Bestandteil des Datenblocks ist der CRC (Bei mir 
im Beispiel 0x4a) und das Stoppbyte 0x16.

Also:

08 00 72 28 55 15 
85 c5 14 00 04 e3 00 00 00 04 78 c8 5e 13 05 04 06 5a 1b 01 00 04 13 d7 d7 28 00 04 2b 00 00 00 
00 14 2b 90 7a 00 00 04 3b 00 00 00 00 14 3b 75 03 00 00 02 5b 2f 00 02 5f 1e 00 02 61 a1 06 02 
23 60 07 04 6d 25 36 05 33 44 06 41 0b 01 00 44 13 cc 88 26 00 42 6c ff 2c 01 fd 17 00 03 fd 0c 
05 00 00 84 20 06 00 00 00 00 c4 20 06 00 00 00 00 84 30 06 00 00 00 00 c4 30 06 00 00 00 00

Die Checksumme gemäß Protokollbeschreibung ist das niederwertige Byte 
der Summe aller einzelnen Bytes. Du kannst diesen Datenblock in eines 
der Online Checksum tools kippen. Ich habe verwendet:
https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/
Die benötigte Checksum ist die "CheckSum8 Modulo 256". Bei mir wird 
korrekt die 0x4a berechnet und damit ist mein Datenblock schon mal 
fehlerfrei empfangen worden.

Dann suchst du dir das entsprechende Datenpacket für den "Durchfluss 
(Höchstwert)". Also 0x14 0x3b gefolgt von 4 Byte Nutzdaten. Bei mit die 
0x75 0x03 0x00 0x00. In die richtige Reihenfolge gebracht 0x00000375 was 
den 885 l/h entspricht die bei mir angezeigt werden. Wobei du bei dieser 
Online Seite:
https://www.rapidtables.com/convert/number/hex-to-decimal.html
dir sowohl das Ergebnis ohne Vorzeichen als auch das 2er Komplement 
entsprechend mit Vorzeichen anzeigen lassen kannst.

Entsprechend der Protokollbeschreibung habe ich bei mir das Decode 
vorzeichenrichtige Werte umgeschrieben. Ändert zwar bei mir nix da ich 
nur positive habe. Aber die Minus Zahl bei dir wäre mal ein Test.

1,0406ssSSssSSs@1000,Wärmenergie gesamt,MWh,W_total,3
1,0413ssSSssSSs@1000,Volumen gesamt,m³,V_total,3
1,042BssSSssSSs@1000,Strom aktuell,kW,P_curr,3
1,043BssSSssSSs@1,Durchfluss aktuell,l/h,F_curr,0
1,025BssSS@1,Temperatur Vorlauf,°C,T_flow,0
1,025FssSS@1,Temperatur Rücklauf,°C,T_return,0
1,0261ssSS@100,Temperatur Differenz,°C,T_diff,2

1,142BssSSssSSs@1000,Strom Maximum,kW,P_max,3
1,143BssSSssSSs@1,Durchfluss Maximum,l/h,F_max,0

1,4406ssSSssSSs@1000,Wärmenergie Stichtag,MWh,W_total,3
1,4413ssSSssSSs@1000,Volumen Stichtag,m³,V_total,3
1,426CuuUU@1,Stichtag,Coded,Time_EOP,0

1,0478uuUUuuUUs@1,Seriennummer,,SN,0
1,0223uuUU@1,Tage in Betrieb,d,Op_Days,0
1,01FD17uu@1,Fehlercode,Coded,Err_Code,0 
1,03FD0CuuUUuus@1,FW Version,,FW_Version,0
1,046DuuUUuuUUs@1,Datum und Zeit,Coded,Time_curr,0

Aber Achtung, ich habe bei mir auch die Variablen umbenannt falls du die 
nutzt.

Die als "Coded" ausgegebenen Werte habe ich überprüft aber noch nicht 
dekodiert. Prinzipiell stimmen sie aber.

Grüße,
Uwe

[Toptobias (toptobias)]

Hallo Uwe

Du bist Klasse, nun stimmen bei mir die Werte im Tasmota mit denen im 
WMZ überein. Vielen vielen Dank dafür.

Ja mit dem negativen Wert beim Durchfluss Maximum verstehe ich auch 
nicht so richtig, da war wohl der Zähler sich sehr verzählt oder er hat 
einfach gesponnen. Interessant ist aber das ich nun negative Werte 
anzeigen lassen kann. Ich habe dieses bei mir im Sommer bei der 
Temperatur Differenz.
Da ist der Rückfluss des Wassers wärmer als der Zufluss. Da hatte ich 
immer eine kuriose Anzeige in Tasmota.

Ich will demnächst noch mal genau verstehen wie man auf diese Werte 
kommt. Dank deiner super Anleitung werde ich mich da mal reinlesen und 
testen.

Beste Grüße
Tobias

[Kirill K. (kirill45)]

Hallo zusammen,


ich versuche nun seit Tagen meinem Wärmezähler die daten mittels python 
Skript zu entlocken, leider bisher ohne erfolg.

wmz-skript.py

Es handelt sich um die Pollucom E (neuere version).

Ich verwende den Hichi Lesekopf mit einem ftdi Adapter, das auslesen mit 
der MiniCom3 Software klappt bei beiden Zähler problemlos, daher kann 
ich die Batterie, Serielle kommunikation, Lesekopf positionierung etc. 
ausschließen.

Ich bekomme nach dem senden des SND_NKE befehl, einfach kein E5 zurück.


Hier ein Mittschnitt der seriellen Kommunikation, zuerst mit der 
MiniCom3

minicom3.txt

darauf plaudert der zähler los.


Hier das von dem python Skript.

python_skript.txt



Hatte vielleicht jemand ähnliche Problemme, ich weiß einfach nich in 
welche richtung ich graben soll.

[Thomas C. (thomas_c31)]

Probier doch erstmal mal, mit minicom oder einem anderen Terminal 
Programm an Port Com8? dich zu verbinden. Wenn da etwas kommt, ist 
vielleicht das Programm nicht ganz richtig.

[Kirill K. (kirill45)]

Problem gelöst!

ser.dsrDtr = True

musste ersetzt werden durch

ser.setDTR(True)

[Toptobias (toptobias)]

Hallo Uwe

Ich wollte mal nachfragen ob du rausbekommen hast wie man das Datum im 
Tasmota richtig codiert und eine Anzeige außer als "0" rausbringt.
Habe zwar auch ein wenig gespielt, aber es hat nicht funktioniert.

Gruß
Tobias

[Uwe (mymikro)]

Hallo Tobias,

ja. Dekodieren der Zeiten habe ich eingebaut. Wird im Tasmota Web 
Interface angezeigt. Jeweils auf einer eigenen Zeile am Ende der 
Readings.


Was ich noch nicht gelöst habe ist (i) die Zeiten Inline zu dekodieren 
und anzuzeigen. Also nicht auf einer eigenen Zeile sondern an der stelle 
an der die Kodierte Zahl steht. (ii) die beiden dekodierten Zeiten 
anstelle der kodierten im MQTT record zu übertragen.

Das hier ist mein aktueller Stand.

>D
;start, define variables
wkup=1
period=180
;read meter every n minutes after midnight (60 --> 01:00, 02:00...)
blk=0
myDate_EOP=0
sDate_EOP="yyyy-mm-dd"
myDate_Read=0
sDate_Read="yyyy-mm-ddThh:mm"

>B
;setup sensor
->sensor53 r

>T
myDate_EOP=MoUlC3#Date_EOP
myDate_Read=MoUlC3#Date_Read

>S
if time%period==0
and blk==0
;minutes since midnight divided by period have a remainder of "0"
then
=#readmeter
blk=1
;set a flag to execute the readout only once every period
endif

if time%period-1==0
and blk==1
;one minute after we entered the first loop
then
blk=0
; reset the flag
sDate_EOP=s(4.0(2000+((myDate_EOP>>9&0x0078)|(myDate_EOP>>5&0x0007))))+"-"+s(2.0(myDate_EOP>>8&0x000f))+"-"+s(2.0(myDate_EOP&0x001f))
print Abrechnungsdatum %sDate_EOP%
sDate_Read=s(4.0(2000+((myDate_Read>>25&0x78)|(myDate_Read>>21&0x07))))+"-"+s(2.0(myDate_Read>>24&0x0f))+"-"+s(2.0(myDate_Read>>16&0x1f))+"T"+s(2.0(myDate_Read>>8&0x1f))+":"+s(2.0(myDate_Read&0x3f))
print Datensatz %0myDate_Read% vom %sDate_Read%
; convert coded dates
endif

#readmeter

print wakeup start
;set serial protocol
ret=sml(-1 1 "2400:8N1")
print do it
;send 0x55 for 504 times with 8N1, 2400 baud (wakeup sequence)
for wkup 1 50 1
sml(1 1 "55555555555555555555")
next
sml(1 1 "55555555")
print wakeup end
wkup=1

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

print switch serial protocol
sml(-1 1 "2400:8E1")

print initialize
sml(1 1 "1040004016")
delay(100)

print set data frame mode "Standard"
sml(1 1 "6804046853FE5000A116")
delay(100)

print request data
sml(1 1 "105BFE5916")

>W
Datensatz vom:       {m} %sDate_Read%
Abrechnungsdatum:    {m} %sDate_EOP%

>M 1
+1,3,rE1,0,2400,MoUlC3,1
1,0406ssSSssSSs@1000,Wärmenergie gesamt,MWh,W_total,3
1,0413ssSSssSSs@1000,Volumen gesamt,m³,V_total,3
1,042BssSSssSSs@1000,Strom aktuell,kW,P_curr,3
1,043BssSSssSSs@1000,Durchfluss aktuell,m³/h,F_curr,3
1,025BssSS@1,Temperatur Vorlauf,°C,T_flow,0
1,025FssSS@1,Temperatur Rücklauf,°C,T_return,0
1,0261ssSS@100,Temperatur Differenz,K,T_diff,2

1,142BssSSssSSs@1000,Strom Maximum,kW,P_max,3
1,143BssSSssSSs@1000,Durchfluss Maximum,m³/h,F_max,3

1,426CuuUU@1,Abrechnungsdatum,Coded,Date_EOP,0
1,4406ssSSssSSs@1000,Wärmenergie,MWh,W_due,3
1,4413ssSSssSSs@1000,Volumen,m³,V_due,3

1,0478uuUUuuUUs@1,Seriennummer,,SN,0
1,0223uuUU@1,Tage in Betrieb,d,Op_Days,0
1,01FD17uu@1,Fehlercode,Coded,Err_Code,0 
1,03FD0CuuUU@1,Gerätetyp,,Dev_Version,0
1,046DuuUUuuUUs@1,Date and Time,Coded,Date_Read,0
#

Grüße,
Uwe

[Toptobias (toptobias)]

Hallo Uwe

Vielen Dank für das Skript, ich habe das bei mir auch mal probiert.
Daten sehen nun viel besser aus. :-)
Gibt es noch eine besondere Einstellung wegen der letzten beiden Zeilen 
mit der Umwandlung des Datums? Bei mir werden diese trotz des Skriptes 
nicht angezeigt.
Also wie ich dich verstanden habe werden die letzten beiden Zeilen also 
nicht via MQTT übertragen.
Ist es möglich im Homeassistant das codierte Datum dort umzuwandeln?


Beste Grüße
Tobias

[Uwe (mymikro)]

Hallo Tobias,

hast du diesen Block übernommen ?

>W
Datensatz vom:       {m} %sDate_Read%
Abrechnungsdatum:    {m} %sDate_EOP%

Wenn dann im WebGui die Zeilen nicht angezeigt werden ist deine Firmware 
nicht mit:

USE_SCRIPT_WEB_DISPLAY

Ich hatte hier Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen" die 
config mit der ich meine Firmware übersetzt habe und auch das binary 
angehängt. Die Beschreibung der verwendeten defines findest du hier: 
https://tasmota.github.io/docs/Scripting-Language/


In HomeAssistant kannst du die Konvertierung auch machen. Ich bin nur 
noch nicht dazu gekommen. Wenn ich es habe, poste ich es.

Grüße,
Uwe

[Ralf (rl_rl)]

Hallo zusammen.
Dieser Thread war für mich mehrmals sehr aufschlussreich.
Meine ersten Erfahrungen mit Optolesern lagen schon 14 Jahre zurück,
da musste man die noch selber bauen und viel ausprobieren.

Mein WMZ : Itron allmess UltraMaXX
Es gab jetzt für einen meiner Wärmemengenzähler diverse Hürden zu 
nehmen.

Magnet hält hier nicht, also hab ich mir was selbst gedruckt.

Es gab aber keine Daten, nicht mit Tasmota, nicht mit Python, nicht mit 
LorusFree, nicht mit M-tool
oder anderen Experimenten mit mehreren Optoplatinen.

Irgendwann war ich genervt und besann mich auf diesen
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"


Dank an Willy L. (sabberlotte) vom 14.02.2023 17:36

Alle Platinen die ich habe (5 Varianten,einschließlich Tasmota-Lesekopf) 
basieren auf dem
Beispiel:

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

Hier gibts im Empfangszweig den Widerstand R1 13k.
Den habe ich letztendlich auf 68k geändert.
Und siehe da, es ging sofort.

Am Sendezweig hab ich nichts geändert, das führt aber eventuell zum 
Übersprechen.
Der Empfänger liest dann die Daten die man selbst ausgibt.
Dieser Effekt liegt auch am Gehäuse, was natürlich beim experimentieren 
oft fehlt.
Ich verhinderte das Übersprechen erfolgreich mit schwarzen
Schrumpfschlauchstummeln um Sender und Empfänger.
Weiße Gehäuse (Selbstdruck) sind diesbezüglich schlechter als schwarze 
Gehäuse.
Ein trennender Steg zwischen Sender und Empfänger ist hilfreich.

Weitere Erkenntnisse:

Der WMZ liefert seine Daten nach jeder Anforderung ab,
er stellt die Mitarbeit also nicht ein,
wie irgendwo weiter oben vermutet wurde.

Die Positionierung muss natürlich stimmen bezüglich der Ausrichtung 
Sender/Empfänger,
ist aber ansonsten ziemlich unkritisch.

Wenn man eine TTL-Optoplatine an eine 8266-Platine anschliesst, wird 
diese dort mit 3,3V betrieben, möglicherweise noch abzüglich einer 
Schutzdiode.
Aus einem FTDI-USB-Kabel (TTL-232R-3V3) kommen zwar 3,3V Signalleitungen 
aber die Versorgung liefert 5V!
Abweichende Ergebnisse sind so absehbar :-)
Die genannten 68k funktionieren bei mir mit beiden Konstellationen.

Mein Zähler liefert einen ein Byte Zähler,
der im Tasmota-Script im >M Bereich

1,92261704uu@1,cnt, ,readcnt,0

ausgewertet werden kann, so hat man schnell ein Überblick ob das 
Auslesen
so abläuft wie zeitlich gewünscht, bei meinen Experimenten alle zehn 
Sekunden.

Mein LorusFree sendet gar keine Aufwecksequenz,
was mit einer Kamera mit Blick auf die Sendediode sofort auffällt.

M-tool lässt sich vom Übersprechen gelegentlich verwirren,
hat mir aber ansonsten geholfen.

Nach dem alles lief war auch der Zweifel weg,
ob die selbstkompilierte Version von Tasmota alles Nötige beinhaltete.

[Toptobias (toptobias)]

Hallo Uwe

Ja, ich dachte es mir das es an der Firmware liegt, ich habe aktuell 
nicht die neuste installiert. Aber irgendwie traue ich mich nicht deine 
Firmware aufzuspielen, da ich ja den Tasmota erst mal mit eine mini 
Firmware bespielen muss und dann mit deiner hinterher.
Kann da was schiefgehen?

Gruß
Tobias

[Uwe (mymikro)]

Hallo Tobias,

ich kann nur sagen das bei mir der Update der Firmware bisher immer ohne 
Probleme funktioniert hat. Ich lade auch erst die minimal Version und 
dann die neue. Da die Programmierung incl. Wifi erhalten bleibt ist das 
ganze in 2-3 Minuten erledigt. Und für den Notfall habe ich einen 
Programmieradapter in der Schublade.

Grüße,
Uwe

[Jo G. (lcnjo)]

Hallo Zusammen,
spannender Tread. Hat jemand das von euch ggf. schon mal mit node Red 
probiert umzusetzten?
Also in Node red gibt es diverse Serielle Nodes für z.B. Stromzähler. 
Auch einige die Mbus sprechen. Aber leider habe ich bisher keine Node 
gefunden, welche die Parität wechselt und die 0x55 sendet.

Wer hat da einen Tip? Danke!

Gruß
Jo

[Toptobias (toptobias)]

Hallo Uwe

Ich bins nochmal, ich habe gestern die Firmware
tasmota_13.4_V1.bin.gz auf den Kopf hochgeladen, dieses hat auch 
funktioniert, ich konnte ihn wieder erreichen per WLAN.
Doch was nicht mehr geht ist die Auslesung.
Habe nun 18 Stunden gewartet aber er zeigt nur noch 0 Werte an.
Nun meine Frage muß ich was mit der "user_config_override.h" irgendwas 
machen?

Vielen Dank
Tobias

[Toptobias (toptobias)]

Toptobias schrieb:
> Hallo Uwe
>
> Ich bins nochmal, ich habe gestern die Firmware
> tasmota_13.4_V1.bin.gz auf den Kopf hochgeladen, dieses hat auch
> funktioniert, ich konnte ihn wieder erreichen per WLAN.
> Doch was nicht mehr geht ist die Auslesung.
> Habe nun 18 Stunden gewartet aber er zeigt nur noch 0 Werte an.
> Nun meine Frage muß ich was mit der "user_config_override.h" irgendwas
> machen?
>
> Vielen Dank
> Tobias

Sorry geht wieder, Der Kopf hat sich um 3 mm verdreht.

[Uwe (mymikro)]

Hallo Tobias,

schön das die Lösung so einfach war. Die Datei "user_config_override.h" 
benötigst du auch nur wenn du dir das Binary selbst compilierst.

Ich habe mir gestern mal das Thema dekodieren des ausgelesenen Datums 
angesehen. Du kannst dazu mal folgenden Code in Homeassistant in den 
Template Editor eingeben:

{% set dt = int(states('sensor.warmezahler_moulc3_date_read')) %}
{% set DatasetDate= as_datetime(
               (2000 + int(dt/2**25) | bitwise_and(0x78) | bitwise_or(int(dt/2**21) | bitwise_and(0x07)))~"-"~
               (int(dt/2**24) | bitwise_and(0x0f))~"-"~
               (int(dt/2**16) | bitwise_and(0x1f))~"T"~
               (int(dt/2**8) | bitwise_and(0x1f))~":"~
               (int(dt/2**0) | bitwise_and(0x3f))
               ) %}
{{ DatasetDate }}

{% set dt = int(states('sensor.warmezahler_moulc3_date_eop')) %}
{% set SettlementDate= as_datetime(
               (2000 + int(dt/2**9) | bitwise_and(0x78) | bitwise_or(int(dt/2**5) | bitwise_and(0x07)))~"-"~
               (int(dt/2**8) | bitwise_and(0x0f))~"-"~
               (int(dt/2**0) | bitwise_and(0x1f))
               ) %}
{{ SettlementDate }}

Und dir auf dieser Basis jeweils einen Template Sensor anlegen. Den 
Namen des jeweiligen Sensors musst du durch deinen ersetzen.

Nach allem was ich bisher gefunden/gelesen habe scheint es aber keine 
Möglichkeit zu geben das Datum selbst als Zeitstempel zu verwenden mit 
dem Homeassistant die Readings in die Datenbank schreibt. Da wird wohl 
immer der Zeitstempel verwendet an dem HA die Sensor Daten empfängt.

Wenn dazu jemand eine Lösung hat, sehr gerne-

Grüße,
Uwe

[Jonas (jonas_g644)]

Hallo zusammen,

ich habe einige Zeit mitgelesen und auch für meinen WMZ das Skript 
angepasst zum Auslesen. Ich habe einen VoluMess VI Komfort, das scheint 
ein gebrand-labelter Engelmann zu sein der auch ein wenig andere 
Register hat. Es ist noch nicht perfekt, möchte es aber dennoch mal hier 
anhängen für die welchen es so genügt.

Mein Problem ist aber ein anderes, nämlich dass die Auslesung sehr 
unzuverlässig ist. Im Debuglog sieht man, dass oftmals anfängliche Teile 
des Telegrams fehlen und daher die dekodierung in ca 40% der Fälle nicht 
funktioniert.

Ein mitternächtliches Auslesen funktioniert daher für mich nicht, wenn 
ich zuverlässig 1x am Tag werte haben möchte. Aktuell habe ich das so 
umgangen, dass ich um 0, 1, 2 und 3 Uhr auslese. Meistens ist dann ein 
erfolgreicher Auslesevorgang dabei.

Ist es möglich anstelle dieser festen stündlichen Auslesezeitpunkte in 
der >S Sektion, dass Auslesen auf Befehl, z.B. per MQTT anzustoßen? Dann 
würde ich es in einer Home Assistant Automatisierung so oft anstoßen, 
bis es einmal geklappt hat.

Viele Grüße,
Jonas

[Ralf (rl_rl)]

Hallo,

[[https://github.com/arendst/Tasmota/discussions/20029]]

hier ist etwas ähnliches beschrieben.

rl

[Uwe (mymikro)]

Hallo Tobias,

ich hab das gerade bei mir ins HomeAssistant eingebaut. Hier die beiden 
Templates.

- sensor:
  - name: Wärmezähler MoUlC3 Auslesedatum
    unique_id: "HeatMeterDatasetReadDate"
    state: >- 
      {% set dt = int(states('sensor.warmezahler_moulc3_date_read')) %}
      {% set DatasetDate= (
        (2000 + int(dt/2**25) | bitwise_and(0x78) | bitwise_or(int(dt/2**21) | bitwise_and(0x07)))~"-"~
        (int(dt/2**24) | bitwise_and(0x0f))~"-"~
        (int(dt/2**16) | bitwise_and(0x1f))~"T"~
        (int(dt/2**8) | bitwise_and(0x1f))~":"~
        (int(dt/2**0) | bitwise_and(0x3f))
        ) | as_timestamp | int %}
      {{ DatasetDate | timestamp_custom("%d.%m.%Y %H:%M") }}
      
- sensor:
  - name: Wärmezähler MoUlC3 Abrechnungsdatum
    unique_id: "HeatMeterSettlementDate"
    state: >- 
      {% set dt = int(states('sensor.warmezahler_moulc3_date_eop')) %}
      {% set SettlementDate= (
        (2000 + int(dt/2**9) | bitwise_and(0x78) | bitwise_or(int(dt/2**5) | bitwise_and(0x07)))~"-"~
        (int(dt/2**8) | bitwise_and(0x0f))~"-"~
        (int(dt/2**0) | bitwise_and(0x1f))
        ) | as_timestamp | int %}
      {{ SettlementDate | timestamp_custom("%d.%m.%Y") }}

Und die aktuelle Version meines Tasmota Templates.

>D 30
;start, define variables
wkup=1
period=180
;read meter every n minutes after midnight
blk=0
myDate_EOP=0
sDate_EOP="yyyy-mm-dd"
myDate_Read=0
myTime_Read=0
sDate_Read="yyyy-mm-ddThh:mm"

>B
;setup sensor
->sensor53 r

>T
myDate_EOP=MoUlC3#Date_EOP
myDate_Read=MoUlC3#Date_Read
myTime_Read=MoUlC3#Time_Read

>S
if time%period==0
and blk==0
;minutes since midnight divided by period have a remainder of "0"
then
=#readmeter
blk=1
;set a flag to execute the readout only once every period
endif

if time%period-1==0
and blk==1
;one minute after we entered the first loop
then
blk=0
; reset the flag
sDate_EOP=s(4.0(2000+((myDate_EOP>>9&0x0078)|(myDate_EOP>>5&0x0007))))+"-"+s(2.0(myDate_EOP>>8&0x000f))+"-"+s(2.0(myDate_EOP&0x001f))
print Abrechnungsdatum %sDate_EOP%
sDate_Read=s(4.0(2000+((myDate_Read>>25&0x78)|(myDate_Read>>21&0x07))))+"-"+s(2.0(myDate_Read>>24&0x0f))+"-"+s(2.0(myDate_Read>>16&0x1f))+"T"+s(2.0(myTime_Read>>8&0x1f))+":"+s(2.0(myTime_Read&0x3f))
print Datensatz vom %sDate_Read%
; convert coded dates
endif

#readmeter

print wakeup start
;set serial protocol
ret=sml(-1 1 "2400:8N1")
print do it
;send 0x55 for 504 times with 8N1, 2400 baud (wakeup sequence)
for wkup 1 50 1
sml(1 1 "55555555555555555555")
next
sml(1 1 "55555555")
print wakeup end
wkup=1

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

print switch serial protocol
sml(-1 1 "2400:8E1")

print initialize
sml(1 1 "1040004016")
delay(100)

print set data frame mode "Standard"
sml(1 1 "6804046853FE5000A116")
delay(100)

print request data
sml(1 1 "105BFE5916")

>W
Datensatz vom:       {m} %sDate_Read%
Abrechnungsdatum:    {m} %sDate_EOP%

>J
;,"sDate_EOP":"%sDate_EOP%"
;,"sDate_Read":"%sDate_Read%"

>M 1
+1,3,rE1,0,2400,MoUlC3,1
1,=so3,165
1,0406ssSSssSSs@1000,Wärmenergie gesamt,MWh,W_total,3
1,0413ssSSssSSs@1000,Volumen gesamt,m³,V_total,3
1,042BssSSssSSs@1000,Strom aktuell,kW,P_curr,3
1,043BssSSssSSs@1000,Durchfluss aktuell,m³/h,F_curr,3
1,025BssSS@1,Temperatur Vorlauf,°C,T_flow,0
1,025FssSS@1,Temperatur Rücklauf,°C,T_return,0
1,0261ssSS@100,Temperatur Differenz,K,T_diff,2
1,142BssSSssSSs@1000,Strom Maximum,kW,P_max,3
1,143BssSSssSSs@1000,Durchfluss Maximum,m³/h,F_max,3
1,426CuuUU@1,*,Coded,Date_EOP,0
1,4406ssSSssSSs@1000,Abger. Wärmenergie,MWh,W_due,3
1,4413ssSSssSSs@1000,Abger. Volumen,m³,V_due,3
1,0478uuUUuuUUs@1,Seriennummer,,SN,0
1,0223uuUU@1,Tage in Betrieb,d,Op_Days,0
1,01FD17uu@1,Fehlercode,Coded,Err_Code,0
1,03FD0CuuUU@1,Gerätetyp,,Dev_Version,0
1,046DuuUUuuUUs@1,*,Coded,Date_Read,0
1,046DuuUU@1,*,Coded,Time_Read,0
#

(i) Ich zeige im Web jetzt nur noch das dekodierte Datum an. (Label im 
Dekoder auf "*" setzen.) (ii) Variablen in Tasmota sind "float". Bei 
großen Zahlen wie der Zeit als unsigned double geht das aber zu lasten 
der Minuten. Will sagen bei der Berechnung des Datum Strings habe ich 
mich am Anfang darüber gewundert warum wenn ich alle paar Minuten 
auslese die Minuten immer als "00" angezeigt werden. Das habe ich gelöst 
indem ich mit der letzten Decoder Zeile die Minuten noch mal als 
unsigned word lese und damit rechne. (iii) Die Puffergröße setze ich 
jetzt über die zweite Decoder Zeile.

Viele Grüße,
Uwe

[Toptobias (toptobias)]

Hallo Uwe

Vielen Dank für die Infos und die konfiguration.
Ich konnte diese in meiner Konfiguration anpassen, nun sehe ich die 
Daten, werde nun sehen wie lange die Aktualisierung benötigt.

Ja bei dem WMZ ist das leider echt ein Problem mit dem periodischen 
Auslesen bei einem Infrarot Kopf. Da gibt es wohl wirklich noch keine 
gute Lösung. Bei mir wird etwa 5 mal am Tag ausgelesen, obwohl dieser 
jede Stunde versucht.

Ich bin nun auf diese Seite gestoßen 
(https://github.com/Zeppelin500/MBusino), da wird der WMZ mittels MBUS 
ausgelsen, ja leider wird wieder neue Hardware benötigt, aber naja was 
zum Basteln.
Da Konzept ist ganz gut, da wird der WMZ via Modbus ausgelesen und via 
WIFI an Homeassistant per MQTT die Daten übermittelt.
Mal sehen ob das Funktioniert.

Beste Grüße
Tobias

[Toptobias (toptobias)]

Hallo Uwe

Mir ist bei meinem WMZ aufgefallen das die Uhrzeit nicht korrekt ist.
Kann man mit deinem Script in Tasmota und/oder Homeassistant die Uhrzeit 
korriegieren?
Oder noch besser gibt es ein Möglichkeit in dem WMZ die Urzeit zu 
ändern?

Beste Grüße
Tobias

[Uwe (mymikro)]

Hallo Tobias,

stimmt. Ist bei meinem WMZ auch so. Sind bei mir ein paar Minuten. Habe 
ich bisher ignoriert.

In HomeAssistant kannst du das am einfachsten machen. Die Variable 
"DatasetDate" aus meinem Template ist eine Unix Timestamp (Sekunden seit 
01.01.1970) die in der letzten Zeile in einen String umgewandelt wird. 
Schau dir an wie viele Sekunden dein WMZ daneben liegt und addiere oder 
subtrahiere das als offset.

Wenn die Uhr am Beispiel 5 Minuten nach geht ersetze:

{{ DatasetDate | timestamp_custom("%d.%m.%Y %H:%M") }}

durch

{{ (DatasetDate + 300) | timestamp_custom("%d.%m.%Y %H:%M") }}

Zu einem einfachen Fix im Tasmota Script habe ich keine Idee. Man müsste 
ja den Übertrag auf die Stunden,Tage,...berücksichtigen. Mein erster 
Ansatz damals war die ausgelesene Zeit erst in ein Unix Timestamp zu 
konvertieren. Dazu habe ich aber in Tasmota nicht die passenden 
Funktionen gefunden und das manuell zu machen habe ich aufgrund der 
unterschiedlichen Anzahl von Tagen im Monat und der Schaltjahre als 
Lösung wieder verworfen.

Viele Grüße,
Uwe

[Philipp (phrxmd)]

Hallo ihr,

ich möchte meinen Wärmemengenzähler Engelmann Sensostar I per IR 
auslesen, verwende dazu einen Hichi-IR-Lesekopf mit Tasmota und bin, 
nicht zuletzt dank der Informationen aus diesem Thread, so weit, daß ich 
vom Zähler eine Rückmeldung bekomme. Allerdings mag Tasmota diese bisher 
noch nicht parsen.

In der Tasmota-Console sehe ich folgendes:

09:42:38.214 read meter
09:42:38.216 wakeup start
09:42:40.636 wakeup end
09:42:40.638 wait for the meter
09:42:40.991 init MBus (1040004016); scan for device 00
09:42:41.349 request current data (107BFE7916)
09:42:41.357 request current data finished
09:42:41.466 : 00 72 32 12 55 00 c5 14 00 04 05 
09:42:41.511 : 00 00 00 04 78 40 69 08 00 
09:42:41.553 : 04 06 c5 3c 00 00 04 13 3f 44 
09:42:41.597 : 19 00 04 2b 00 00 00 00 14 
09:42:41.639 : 2b 18 90 00 00 04 3b 00 00 
09:42:41.681 : 00 00 14 3b 6b 05 00 00 02 5b 
09:42:41.727 : 1c 00 02 5f 1c 00 02 61 03 00 
09:42:41.772 : 02 23 85 06 04 6d 2d 29 18 
09:42:41.813 : 38 44 06 bd 36 00 00 44 13 
09:42:41.854 : 98 ff 16 00 42 6c ff 2c 01 
09:42:41.896 : fd 17 40 03 fd 0c 05 00 00 84 
09:42:41.940 : 20 06 00 00 00 00 c4 20 06 
09:42:41.983 : 00 00 00 00 84 30 06 00 00 00 
09:42:42.019 : 00 c4 30 06 00 00 00 00 df 
09:42:42.061 : 16

Der Zähler ist batteriebetrieben, er spuckt also nur alle paar Stunden 
Werte aus, damit kann ich aber leben.

Als Skript verwende ich das aus der Tasmota-Dokumentation für den 
Sensostar E 
(https://tasmota.github.io/docs/Smart-Meter-Interface/#engelmann-sensostar-e-heat-meter-used-with-hichi-ir-interface), 
da ist der Parser wie folgt definiert:

>M 1
+1,3,rE1,0,2400,WAERME,1
1,=so3,32
1,0478u32s@1,Zählernummer,,Zählernummer,0
1,0406u32s@1000,Energie,MWh,Energie,3
1,0413u32s@1000,Volumen,m³,Volumen,3
1,042bu32s@1,Leistung,W,Leistung,0
1,142bu32s@1,Max. Leistung,W,Max. Leistung,0
1,043bu32s@1000,Volumenstrom,m³/h,Volumenstrom,3
1,143bu32s@1000,Max. Volumenstrom,m³/h,Max. Volumenstrom,3
1,025buuUU@1,Vorlauftemperatur,°C,Vorlauftemperatur,0
1,025fuuUU@1,Rücklauftemperatur,°C,Rücklauftemperatur,0
1,0261ssSS@100,Temperaturdifferenz,°C,Temperaturdifferenz,2
1,0223uuUU@1,Betriebsdauer,Tage,Betriebsdauer,0
1,4406u32s@1000,Stichtag Energie,MWh,Letzter Stichtag Energie,3
1,4413u32s@1000,Stichtag Volumen,m³,Letzter Stichtag Volumen,3
#

Wie man sieht, sind die Schlüsselwerte, also 04 78, 04 06, 04 13 usw., 
in den Daten vom Zählers alle vorhanden und sollten vom Raw-Parser 
eigentlich gefunden werden, in Tasmota sehe ich jedoch nur Nullen.

Ich habe die Parserdefinition auch mal probeweise gegen die aus Uwes 
Template (Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen") 
ausgetauscht, das Problem ist das Gleiche. Als Tasmota-Version war 
12.3.1 drauf, ich habe auf 13.2 von Hichi upgedated, ohne Veränderung.

Ich stehe wahrscheinlich auf dem Schlauch, aber wie kann ich Tasmota 
dazu bekommen, die Werte auch tatsächlich zu parsen?

[Philipp (phrxmd)]

> Ich stehe wahrscheinlich auf dem Schlauch, aber wie kann ich Tasmota
> dazu bekommen, die Werte auch tatsächlich zu parsen?

Hat sich erledigt, einen Neustart und einen Tag später parst er 
einwandfrei.

[Mario T. (mario_t)]

Hallo in die Runde,
ich habe einen neuen Wärmezähler von Zenner bekommen ,der nennt sich 
Zenner Zelsius C5-IUF,das ist die Lora Version.Den würde ich gerne 
optisch auslesen wollen und habe aber bis jetzt nichts gefunden wie ich 
das machen kann.Ich habe mir einen BitShake lesekopf für meinen 
Stromzähler gekauft und den habe ich erstmal am Wärmezähler probiert 
aber nichts ist passiert.Beim Stromzähler funktioniert der Lesekopf.Die 
Bedienungsanleitung von dem Wärmezähler ist nicht wirklich 
aufschlussreich.Vielleicht kennt sich jemand hier damit aus und kann mir 
weiterhelfen.
Vielen Dank schonmal und Grüße Mario

[Klaus R. (klara)]

Hallo Mario,
ich lese auch den MBus aus, aber per Draht und speise damit auch gleich 
Strom ein. Ich habe zuvor SuperCal 539 Wärmezähler gehabt und hoffe das 
die neuen sofort laufen wenn ich die Herstellerkennung in meiner 
Software anpasse. Das war zuvor bei den ganzen alten PolluCom auf 
SuperCal 539 so problemlos gelaufen.

Um das zu Unterstützen habe ich mir eine Parameterliste der C5 
Wärmezähler schicken lassen. Sie liegt anbei.

Die optische Schnittstelle (ZVEI, IrDA) ist tatsächlich in der Montage- 
und Bedienungsanleitung nicht erklärt worden, sondern nur als Standard 
deklariert worden. Dann müßte man nach "ZVEI IrDA" googlen. Vielleicht 
gibt es auch spezielle Leseköpfe.

Hier ein Thread.
Beitrag "Wärmezähler über optische M-Bus-Schnittstelle auslesen"

Zenner war eigentlich ziemlich zuvorkommend. Ich hatte per Kontakt - 
Seite an die Firma gewandt.

Habe noch einen interessanten Link gefunden.
https://forum.iobroker.net/topic/60309/fernw%C3%A4rmez%C3%A4hler-optischen-zvei-schnittstelle

mfg Klaus

[Mario T. (mario_t)]

Hallo Klaus,danke für deine Antwort.Soweit ich weiß ist bei der Lora 
Version des C5-IUF kein MBus Modul verbaut da in der Anleitung nur 
optional drin steht somit wird es wegfallen und ich denke das es 
nachträglich nicht verbaut werden darf da es nicht mein Eigentum 
ist.Danke für die Parameterliste.Nach IrDA und ZVEI habe ich auch schon 
gegoogelt und bin auch auf die Foren gekommen,das hat mir leider nicht 
geholfen mit welchem lesekopf die Daten ausgelesen werden könnten.
MfG Mario

[Klaus R. (klara)]

Mario T. schrieb:
> Hallo Klaus,danke für deine Antwort.Soweit ich weiß ist bei der Lora
> Version des C5-IUF kein MBus Modul verbaut

Das MBus Modul ist wohl eher Hardware für die Drahtverbindung. Ich 
könnte mir vorstellen das über Lora die Daten per MBus - Protokoll 
gesendet werden.
mfg Klaus

[Mario T. (mario_t)]

Hallo nochmal,ist es möglich mit einem Hichi Lesekopf und V3 von Nick 
meinen Zenner Zelsius C5-IUF optisch auszulesen?Der Zenner sendet nur 
ZVEI und IrDA.Danke.Grüße Mario

[Klaus R. (klara)]

Mario T. schrieb:
> Hallo nochmal,ist es möglich mit einem Hichi Lesekopf und V3 von Nick
> meinen Zenner Zelsius C5-IUF optisch auszulesen?Der Zenner sendet nur
> ZVEI und IrDA.Danke.Grüße Mario

Ich habe zufällig beide Teile da. Meine beiden Zenner Zelsius C5-IUF 
werden am Montag eingebaut und ersetzen Sontex SuperCal 539. Die hatte 
ich ürbigens schon über 10 Jahre in Betrieb und nie Probleme gehabt. Der 
Zenner Zelsius C5-IUF wird noch besser sein. Ich habe seit ein paar 
Wochen schon drei Hichi Leseköpfe im Einsatz. Einer war leider 
tatsächlich nicht ganz in Ordnung. Er lieferte innerhalb von einer 
Minute bei einem Lesevorgang in 1 s bis 2 s bis zu 3 erkannte 
Fehlversuche und teilweise Datenmüll. Der neue Lesekopf ist aber 
fehlerfrei.

Der Hichi Lesekopf passt zumindest. IR-Fotodiode und IR-LED haben exakt 
den passenden Abstand und der Lesekopf wird magnetisch verankert. 
Welches Protokoll da geliefert wird ist mir unklar. Beim MBus muß man ja 
auch zunächst ein Datenpaket anfordern. Das wird bei der optischen 
Übertragung ähnlich sein.

Aber, Du sagtest auch, daß der Zähler nicht Dein Eigentum ist. Insofern 
wird der Betreiber des Wärmemengenzählers den Zugriff auf den Zähler 
zumindest beschränkt haben. Meine MBus - Version wird auch über dem MBus 
mit Strom gespeist. Die vorhandene Batterie wird in der Regel gar nicht 
belastet. Bei mir ist auch die Lesehäufigkeit nicht beschränkt. Meine 
ganz alten PolluCom Wärmemengenzähler wurden nicht fremdgespeist und ich 
hatte  damals so alle 5 Minuten ausgelesen. Das ging einige Wochen gut 
und dann liessen sie das häufige Auslesen nicht mehr zu und bremsten 
mich. Denn, die Batterie sollte ja 5 + 1 Jahr durchstehen können.

OK, das war nur ein Tipp von mir.

Ich denke, die Daten werden im Prinzip so wie beim MBus geliefert. Der 
Vorspann kann etwas anders sein.
mfg Klaus

[Thorsten N. (thorsten_n)]

Hallo da mein alter Hichi Lesekopf defekt war und dieser ab und zu 
falsche Werte geliefert hat habe ich mir einen neuen gekauft. Diesmal 
ist es ein Lesekopf "Pro3" auf dem ich aber ganz normale die minimale 
Tasmota Bin geflasht habe und danach die tasmota_v3.bin hier aus dem 
Forum. Habe dann das Backup vom alten Hichi eingespielt bekomme nun aber 
keine Daten.

Liegt dies wohl jetzt an dem Lesekopf ? Ich dachte sollte gleich sein 
und dennoch funktionieren ?

Zur Zeit vermute ich das es an der Positionierung liegt die eventuell 
nicht optimal ist. Das Script sollte ja passen da es vorher funktioniert 
hat

[Thorsten N. (thorsten_n)]

Noch eine Frage kann ich irgendwo sehen das ich die richtige Firmware 
geflasht habe ? Nicht das hier noch eine Fehler ist. Alsoi das ich die 
V3 von Nick verwende. Ich glaube zwar nicht das hier der Fehler ist aber 
man weiß ja  nie.

Also mein Script sieht so aus:

>D

;start, define variables

wkup=1

period=2

;read meter every n minutes after midnight (60 --> 01:00, 02:00...)

blk=0

>B

;setup sensor

->sensor53 r

>S



if time%period==0 

and blk==0

;minutes since midnight divided by period have a remainder of "0"

then

=#readmeter

blk=1

;set a flag to execute the readout only once every period

endif

if time%period-1==0 

and blk==1

;one minute after we entered the first loop

then

blk=0

; reset the flag

endif

#readmeter

print wakeup start

;set serial protocol

sml(-1 1 "2400:8N1")

send 0x55 for 2,2 seconds with 8N1 (73x), 2400 baud (wakeup sequence)

for wkup 1 73 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 "105B005B16" (request data)

sml(1 1 "105BFE5916")

>M 1

+1,3,rE1,0,2400,WP_WMZ,1

1,0406uuUUuuUUs@1000,Total energy,MWh,Energie_total,3

1,0C14bcd8@100,Total volume,m³,Durchfluss_total,2

1,0B2Dbcd6@10,Current power,KW,Leistung_akt,2

1,0B3Bbcd6@1000,Current flow,m³/h,Durchfluss_akt,3

1,0A5Abcd4@10,Flow temp,°C,temp_Vorlauf,1

1,0A5Ebcd4@10,Return temp,°C,temp_Ruecklauf,1

1,0B61bcd6@100,Temp diff,°C,temp_diff,2

1,0227uuUU@1,Meter days,d,Betriebstage,0

;1,046Dxxuu@1-1,Hour,h,time_h,0

;1,046Duu@1,Minute,min,time_m,0

;1,046Dxxxxuu@1,Day,dd,time_d,0

;1,046Dxxxxxxuu@1,Month,mm,time_m,0

#

[Mario T. (mario_t)]

Was ist es denn für ein Stromzähler Model?
Das Script sieht mit eher so aus als wenn es für einen Wärmezähler 
geschrieben wurde.
Vielleicht wirst du bei dem Link fündig den ich dir anhänge:
https://www.docs.bitshake.de/script/
Grüße Mario

[Thorsten N. (thorsten_n)]

Mario T. schrieb:
> Was ist es denn für ein Stromzähler Model?
> Das Script sieht mit eher so aus als wenn es für einen Wärmezähler
> geschrieben wurde.
> Vielleicht wirst du bei dem Link fündig den ich dir anhänge:
> https://www.docs.bitshake.de/script/
> Grüße Mario

Hallo es geht nicht um einen Stromzähler sondern um einen 
Wärmemengenzähler und zwar dem CF Echo 2 von Allmess bzw. Itron

Gruß Thorsten

[Andreas (apreick)]

Hallo und Gruß an die Gemeischaft :-)

ich suche schon lange eine Möglichkeit meinen Wärmemengenzähler Sharky 
775 auszulesen und war vor ca. 1 Jahr schon mal hier im Forum zum 
stöbern.

Letzte Woche nochmals gesucht und diesen Beitrag von Thomas gefunden:
https://thomasheinz.net/warmezahler-techem-ultra-s3-baugleich-sharky-775-uber-optische-schnittstelle-auslesen-tasmota/

Da ich an meinem Stromzähler bereits einen bitShake im einsatz habe 
bestellte ich einen weiteren für den Sharky 775

Mein bitShake befindet sich momentan noch auf der Tasmota:
Tasmota 14.1.0 (tasmota32) von Theo Arends

Das Script habe ich von der verlinkten Https verwendet mit einer kleinen 
änderung, da der Support von bitShake mir das extra geschrieben hat:
"Die eine Zeile aus dem Script von der Webseite musst du wie folgt 
anpassen: +1,5,rE1,0,2400,WAERME,4"

leider scheint er nicht zu kumunizieren mit dem Sharky 775

Habe den Lesekopf jetzt mal um 180° gedreht, bisher aber keine 
Veränderung

Was mir nicht klar ist: wie mache ich die "Die initiale Sequenz welche 
den Sharky Daten entlockt wird getriggert
durch ein sml(1 1 “6804046853FE5000A116”)" ???

Könnt ihr mir Helfen? Gruß Andreas

[Leo (leo89)]

Hey Andreas - bin der Autor vom Blogpost - alle Infos stammen aber von 
hier aus dem Mikrocontroller Forum, habe die nur für mich / andere 
gebündelt zusammengeschrieben.

Habe da lange rumgebastelt, hauptsächlich ist / war es bei mir die 
Aurichtung des Lesekopfes auf dem Zähler. Vllt. sollte ich mir da mal 
was ausm 3D Drucker rauslassen, war wirklich ein "Pain".

Die initiale Sequenz kannst du einfach in das Script mit aufnehmen


Vor der Zeile

sml(1 1 "105BFE5916")

das aufnehmen

sml(1 1 "6804046853FE5000A116")
delay(100)

Sobald es einmal gelaufen ist kann man dies auch wieder entfernen.

[Andreas (apreick)]

Hallo Leo,
Danke für die schnelle Erklärung :-)

Habe jetzt das orginal Script verwendet mit der initiale Sequenz

Jetzt werde ich mich mal an das Ausrichten machen

wenn er gesprächig wird sehe ich das doch in Konsole?
(Screenshot von mir im ersten Beitrag
also hier:
{"w_total":0,"v_total":0.00,"p_act":0,"F_akt":0.000,"t_flow":0.0,"t_retu 
rn":0.0}

Habe ja Zeit, bisherige vorgehensweise seit über einem Jahr ist ein Bild 
am Tag vom Zähler und dann Excel

[Andreas (apreick)]

Hallo Leo,
bisher wird der Sharky nicht gesprächig :-)
gefühlt viele Positionen versucht.

Hast Du mal ein Bild von deiner Position des Lesekopfes

Leo schrieb:
> war es bei mir die
> Aurichtung des Lesekopfes auf dem Zähler

[Leo (leo89)]

Evtl hilft es auch die "Innereien" aus dem Lesekopf kurz zu entnehmen, 
dann kann man durch die Aussparungen vom Lesekopf durchsehen und die 
Position dann mit Klebeband / Edding auf dem Sharky markieren. Hänge dir 
mal ein Foto an, aber denke das hilft dir nicht soo viel weiter.

[Andreas (apreick)]

Hallo, danke für dein Bild

Leo schrieb:
> Evtl hilft es auch die "Innereien" aus dem Lesekopf kurz zu entnehmen,
> dann kann man durch die Aussparungen vom Lesekopf durchsehen und die
> Position dann mit Klebeband / Edding auf dem Sharky markieren. Hänge dir
> mal ein Foto an, aber denke das hilft dir nicht soo viel weiter.

Ok, das ist natürlich eine Möglichkeit :-) habe jetzt aber Tape zum 
ausrichten verwendet

Das Script habe ich von hier verwendet (mit Start Sequenz) und beite 
varianten mit der veränderten Zeile "+1,5,rE1,0,2400,WAERME,4"

>D
;start, define variables
cnt=1
timer=1
w_new=0
w_delta=0
p:w_last=40350

>B
;setup sensor
->sensor53 r

>T
w_new=WAERME#w_total

>S
timer=int(time)
if chg[timer]>0 
then
switch timer
case 0
print It is midnight
print wakeup start
sml(-1 1 "2400:8N1")
for cnt 1 72 1
sml(1 1 "55555555555555555555")
next
print wakeup end
print wait for the meter
delay(350)
sml(-1 1 "2400:8E1")
print request data
sml(1 1 "6804046853FE5000A116")
delay(100)
sml(1 1 "105BFE5916")
case 1
print It is a minute after midnight
print calculating daily value
print w_last %0w_last%
w_delta=w_new-w_last
w_last=w_new
svars
print w_new %0w_new%
print w_delta %0w_delta%
ends
endif

>J  
,"w_delta":%w_delta% 

>W
===============
Vortagsverbrauch:    {m} %3w_delta% KWh 

>M 1
+1,5,rE1,0,2400,WAERME,4
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
#

Er kumuniziert halt überhaut nicht in der Konsole :-(

Da ich hier alles gelesen habe in diesem Thread, tippe ich eher auf die 
FW vom Lesekopf.
Ich verwende die orginale FW vom neu gekauften bitShake, also die
Tasmota 14.1.0 (tasmota32) von Theo Arends
Aber ich habe noch nie eine andere Tasmota FW auf einen ESP geflasht, 
daher bräuchte ich so zusagen ein kleines ToDo um auch wieder auf die 
originale zurück komme (um diesen an Bekannte an für einen Stromzähler 
zu verschenken)
Habt ihr da etwas für mich, und welche FW mit einstellungen für den 
Lesekopf

Gruß Andreas

[Ralf (rl_rl)]

Andreas schrieb:

> Gruß Andreas

Das im Post gezeigte Script versucht genau um Mitternacht ein einziges 
mal den Zähler auszulesen.
Da ist Geduld gefragt.
Wenn die Ausrichtung dann nicht stimmt hast Du den nächsten Versuch 
einen Tag später.

Zur Erprobung würde ich ein Script nehmen, dass alle 10 Sekunden was im 
Terminal ausgibt.

rl

[Andreas (apreick)]

Ralf schrieb:
> Script nehmen, dass alle 10 Sekunden

Hallo Ralf
Ja danke für den Tip, dann suche ich mal rückwärts

Gruß Andreas

[Andreas (apreick)]

Hallo, kleines Update passend zu Weihnachten
am 24.12.24 kam ein anderen Lesekopf, der
"Wlan Hichi, IR Lesekopf für Stromzähler optisch auslesen - SmartMeter - 
Volkszähler - Optokopf - Wifi"

Mittags dann grob ausgerichtet und mit einem Script aus diesem Forum 
gefüttert (ohne weitere Einstellungen)

>D
;start, define variables
wkup=1

>B
;setup sensor
->sensor53 r

>S
if upsecs%60==0 {
print read meter
=#readmeter
}
#
#readmeter
print wakeup start
;set serial protocol
ret=sml(-1 1 "2400:8N1")
;send 0x55 for 3 seconds with 8N1 (72x), 2400 baud (wakeup sequence)
for wkup 1 72 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 "6804046853FE5000A116"
sml(1 1 "6804046853FE5000A116")
delay(100)
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
#

Am späten Abend schaute ich dann in die WebUI vom Lesekopf => Bescherung 
=> Daten wurden angezeigt :-)

Also aus dem Script die Startsequenz entfernt und natürlich noch die 
MQTT einrichtung abgeschlossen => daher startete der Lesekopf natürlich 
neu und hatte keine Daten mehr in der WEBUI (also alles 0)

leider redet er seither nicht mehr mit dem Wärmezähler, auch nicht mehr 
mit der Startsequenz im Script

Habt Ihr eine Idee
Gruß Andreas

[Phill (philip_mario)]

Hallo Andreas,
das ist doch ein schönes Weihnachtsgeschenk .. das Feintunning kriegst 
auch noch hin ..
Vielleicht liegts am Wärmezähler selbst.
Bei mir ist der Sharky 775 nach einem erfolgreichem Auslesen erst wieder 
nach ca. 2 Stunden ansprechbar und liefert wieder Daten.
Da die initiale Startsequenz wohl erfolgreich war, nimm diese wieder 
raus und schaue periodisch mal nach, ob Daten kommen (und ja, Geduld ist 
gefragt).
Bei mir fragt das Script alle 5 Minuten nach, erfolgreiches Auslesen 
eben alle 110 Minuten.
Das deaktivieren der optischen Schnittstelle scheint definierts 
Verhalten. Ob sich das von Gerät zu Gerät unterscheidet, weiß ich nicht.
Nach etwas mehr als einem Jahr stelle ich jedoch vermehrt 
Fehlauslesungen fest, diese waren die erste Zeit nicht zu beobachten.
Im Home Assistant werden die Charts unplausibel :-(
Grüße

[Andreas (apreick)]

Phill schrieb:
> Bei mir fragt das Script alle 5 Minuten nach, erfolgreiches Auslesen
> eben alle 110 Minuten

Hallo Phill
kannst Du mal deinen Script hier Teilen?

Gruß Andreas

[Phill (philip_mario)]

> kannst Du mal deinen Script hier Teilen?

na klar, ist auch CopyPaste hier aus dem Thread mit kleinen Anpassungen, 
ähnelt aber deinem .. damit kann ich mit meinem Sharky seit ner Weile 
gut kommunizieren, alle ca. 110 min. gibt's ein Echo.
Weiter oben habe ich meine Erfahrungen beschrieben.
Viel Erfolg !

>D
;start, define variables
cnt=0

>B

;setup sensor
->sensor53 r

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

#
#readmeter
print wakeup start
;set serial protocol
sml(-1 1 "2400:8N1")
;send 520 times 0x55 with 8N1, 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)
delay(100)
sml(1 1 "105BFE5916")
print ----- END CYCLE -----
;delay(10000)

>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
#

[Andreas (apreick)]

Phill schrieb:
> meinem Sharky seit ner Weile
> gut kommunizieren

super :-)
habe jetzt deinen Script verwendet und => Antwortet sofort

Vielen Dank
Gruß Andreas

[Andreas (apreick)]

Phill schrieb:
> alle ca. 110 min. gibt's ein Echo

Ich freue mich total das er jetzt Werte übergibt :-)

Nur der Intervall der Daten ist bei mir etwas "willkürlich"
siehe Spalte Minuten

Uhrzeit  Verbrauch  Diff  Minuten
09:18:00  0 kWh  00:11:00  11
09:07:00  2 kWh  01:15:00  75
07:52:00  5 kWh  03:07:00  187
04:45:00  1 kWh  00:40:00  40
04:05:00  3 kWh  02:27:00  147
01:38:00  1 kWh  00:05:00  5
01:33:00  8 kWh  01:30:00  90
00:03:00  2 kWh  01:51:00  111
22:12:00  5 kWh  03:17:00  197
18:55:00  1 kWh  01:26:00  86
17:29:00  1 kWh  01:10:00  70
16:19:00  1 kW

gibt es dafür eine Erklärung?
bzw. eine Lösung?

Gruß Andreas

[Ralf (rl_rl)]

Andreas schrieb:

> gibt es dafür eine Erklärung?
> bzw. eine Lösung?
>
> Gruß Andreas

Hallo,
schön, dass es Ergebnisse gibt.

Ich würde erstmal (vorsichtig) an der Ausrichtung spielen.
Vorher markieren, Foto machen.

Dann kann man versuchen im Script nach der Abfrage

sml(1 1 "105BFE5916")

delay(xxx)

print ----- END CYCLE -----

noch ein delay(xxx) einzufügen. (z.B. delay(50) )
Dieses Delay in 100er Schritten erhöhen, testen.

Mal sehen was passiert.
[auskommentiert steht da: delay(10000), ist auf jedenfall viel zu hoch]


Ich habe mal was über meine Erfahrungen geschrieben:

Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"

[Andreas (apreick)]

Ralf schrieb:
> Ich würde erstmal (vorsichtig)

Vielen Dank, vorsichtig möchte ich aus sein :-)
bin ja erst einmal froh das etwas kommt und möchte das auch nicht kaput 
machen.

wenn ich deinen Vorschlag richtig verstanden habe dann würde das so 
aussehen, siehe Screenshot?

[Ralf (rl_rl)]

Andreas schrieb:

> ...dann würde das so aussehen...


ja, stimmt so.

Wenn aber die Ausrichtung nicht stimmt, werden die delays möglicherweise 
nichts ändern.

Einfach experimentieren.
Die Varianten des Scripts würde ich genügend gut dokumentieren.
In einigen Tagen, oder Monaten, oder Jahren, weiß man nicht, was gut 
ging.

[Thorsten N. (thorsten_n)]

Hallo nochmal eine Frage funktioniert das ganze auch mit einem Hichi IR 
USB Lesekopf also ohne Wlan ? Allerdings finde ich keinen Weg diesen zu 
flashen. Kann mir hier jemand behilflich sein ? Oder funktioniert es gar 
nicht.

Mein Plan wäre diesen per USB mit Home Assient zu verbinden.

Gruß Thorsten Niemann

[Klaus (feelfree)]

Thorsten N. schrieb:
> Hichi IR
> USB Lesekopf

Der wird an einen Rechner angeschlossen, am sinnvollsten an den, auf dem

> Home Assistent

läuft. Auslesen tue ich den per vzlogger und gebe die Daten per MQTT an 
HA weiter.

Thorsten N. schrieb:
> Allerdings finde ich keinen Weg diesen zu
> flashen

Logisch, da ist ja auch nix drin was selbständig arbeitet. Das macht in 
dem Fall der Rechner, an den der Lesekopf angeschlossen ist.

[Philipp (phrxmd)]

Klaus schrieb:
> Thorsten N. schrieb:
>> Hichi IR USB Lesekopf
>
> Der wird an einen Rechner angeschlossen […]

Nicht notwendigerweise, denn…

>> Allerdings finde ich keinen Weg diesen zu flashen
>
> Logisch, da ist ja auch nix drin was selbständig arbeitet. Das macht in dem Fall 
der Rechner, an den der Lesekopf angeschlossen ist.

…die gibt‘s auch mit eingebautem ESP8266 mit Tasmota, dann braucht man 
keinen Rechner (ist ja auch nicht immer in Zählernähe vorhanden), dafür 
muß man ihn dann flashen.

[Klaus (feelfree)]

Philipp schrieb:
> Hichi IR USB Lesekopf

Philipp schrieb:
> die gibt‘s auch mit eingebautem ESP8266 mit Tasmota,

Finde den Unterschied.

[Thorsten N. (thorsten_n)]

Vielen Dank für die Hilfe. Daran habe ich gar nicht gedacht das hier Esp 
moder ähnliches verbaut ist. Habe nur daran gedacht das der Hichi mit 
Wlan dies hat und ist klar dieser braucht es ja auch um das Wlan 
bereitzustellen.

Jetzt muss ich nur gucken wie ich das ganze unter Home Assient am laufen 
bekomme. Ich habe den Hichi IR USB bis jetzt für meine Smartmeter 
genutzt und die Daten wurden dann in der EDL21 integrität 
bereitgestellt, somit konnte ich die den Verbrauch dann auslesen. Aber 
dies wird mit dem WMZ wohl nicht so einfach sein. Ich denke muss ja auch 
wie bei dem Tasmota Skript eine spezielle Konfiguration erstellen damit 
die Daten ausgelesen werden kann. Aufwecksequenz etc.

Habe gelesenm das es wohl den VZ Logger als Addon gibt, ich hoffe 
bekommen es hin.

[Thorsten N. (thorsten_n)]

So konnte jetzt den VZ logger als addon installieren, jetzt muss ich nur 
noch eine VZlogger.conf erstellen. Hat jemand schon einmal eine für 
einen wmz erstellt uns könnte ein Beispiel dafür zeigen?

[Andreas (apreick)]

Leo schrieb:
> Aurichtung des Lesekopfes

Ralf schrieb:
> Ausrichtung nicht stimmt

Erst einmal wünsche ich allen hier ein "gesundes Jahr 2025"

Ich spiele noch ein wenig mit der Ausrichtung meines Lesekopfes am 
Sharky 775 da ich momentan nur alle 4h Daten bekomme. Den Lesekopf habe 
ich jetzt Außen gut gekennzeichnet und jetzt noch mal zu der position am 
Sharky:

Viele Bilder im internet gesucht und hier mal eine Vermutung von mir im 
angehangenen Bild: kann es sein das der Lesekopf etwas nach rechts 
korrigiert werden muss?

Gruß Andreas

[Thorsten N. (thorsten_n)]

Hallo,
kannst du mir sagen wie du die vzlogger.conf konfiguriert hast ? Ich 
klomme da einfach nicht weitrer. Da ich keine Ahnung habe wie diese für 
dem WMz aufgebaut werden soll.

Klaus schrieb:
> läuft. Auslesen tue ich den per vzlogger und gebe die Daten per MQTT an
> HA weiter.

Hier einmal das Log File vom VZLogger. Ich weiß nicht ob es was zu 
beudetn hat aber zumindest zeigt er bei last byte verschieden Werte an 
0x16, 0x0, 0x10 0x 5b

[Klaus (feelfree)]

Thorsten N. schrieb:
> kannst du mir sagen wie du die vzlogger.conf konfiguriert hast ?

Kann ich, auch wenn es dir nicht viel nützen wird, weil:

- Ich nutze eine uuuralte vzlogger Version, 0.6.1 oder so
- Ein Wärmezähler wird üblicherweise über das OMS Protokoll ausgelesen. 
Du hast D0 konfiguriert - ob es damit auch geht, keine Ahnung
- Mein vzlogger benutzt für das OMS-Protokoll die libmbus. Die hat nur 
so semi gut mit meinem Wärmezähler funktioniert, deshalb habe ich die 
noch im Sourcecode gepatcht.
- Außerdem wird mein Wärmezähler von der Heizung abgefragt, deshalb 
brauche ich keine externe Pullsequenz.

Thorsten N. schrieb:
> aber zumindest zeigt er bei last byte verschieden Werte an
> 0x16, 0x0, 0x10 0x 5b

Davor steht aber, dass gar keine Daten empfangen wurden (0 bytes), 
deshalb sind die "last bytes" vermutlich nur Datenmüll. der zufällig 
irgendwo im Speicher steht.

[Phill (philip_mario)]

Andreas schrieb:
...
>> Aurichtung des Lesekopfes

...
> Ich spiele noch ein wenig mit der Ausrichtung meines Lesekopfes am
> Sharky 775 da ich momentan nur alle 4h Daten bekomme.
..

Hallo Andreas,
in der tat war mein Lesekopf ein Tick nach rechts ausgerichtet. Die 
erste Einkerbung/Markierung neben dem Fixierungsstreifen war komplett 
vom Lesekopf überdeckt, zur linken ist Einkerbung dagegen sichtbar 
gewesen.

Nachdem du es genauer wissen wolltest, hat mich das dann auch 
interessiert.
Den Lesekopf nun "symmetrisch" nach links verschoben (.. erste 
Einkerbung  neben Fixierung komplett vom Lesekopf überdeckt)..

dann nach einem Tag -> keine Änderung zu beobachten.
Zähler liefert weiterhin zuverlässig in bekannten Zyklus plausible Werte 
(bei meinem Sharky sind das die ca. 110 Min).

Ich würde meinen, wenn der Lesekopf einigermaßen zentriert ist und auch 
plausible Werte ausgelesen werden, wars das zum Thema Ausrichtung (etwas 
Spiel scheint es auch zu geben).  Der Rest ist eher in der Software zu 
suchen.
Die Auslesezyklen scheinen mir vom Zähler abhängig. Ob man das im Rahmen 
der Initialisierung mit dem Lesekopf beeinflußen kann ? ..

Weiterer Gedanke .. Im Sharky selbst können weitere Module verbaut sein. 
Bei mir ist ein Funkmodul integriert.  Mit diesem kann die 
Fernwärmegesellschaft die Zählerstände drahtlos empfangen. ggf. 
beeinflusst die Hardwarekonfiguration des Zählers die Auslesezyklen an 
der optischen Schnittstelle. Dazu konnte ich in den Dokus nix finden.
Grüße

[Thorsten N. (thorsten_n)]

Okay scheint ja doch ziemlich kompliziert sein, zumindest für einen 
Laien wie mich.

Ich hatte gedacht du könnste mir helfen, weil du folgendes geschrieben 
hattest.

Klaus schrieb:
> Auslesen tue ich den per vzlogger und gebe die Daten per MQTT an
> HA weiter.

Beim Protokoll habe ich auch keine Ahnung welches ich verwenden muss, 
habe d0 gewählt weil ich dachte dies könnte richtig sein. Also meinst du 
hier müsste ich OMS verwenden ? Kann man es irgendwie heraus finden 
welches Protokoll verwendet werden muss auf der Webseite zum CF Echo 2 
habe ich nichts gefunden.

Mit dem Tasmota Skript konnte ich den WMZ ja auslesen nur ist der Hichi 
Wlan leider defekt und den Hichi USB hatte ich übrig und ich dachte 
müsste hiermit auch funktionieren. Welches Protokoll wird den mit dem 
Tasmota Skript verwendet oder ist dieses wieder was anderes. In dem 
Skript gibt es ja einen SML Befehl bedeutet dies das dass SML Protokoll 
verwendet werdne muss ?

[Klaus (feelfree)]

SML und OMS sind zumindest ähnlich.
Bei deinem Wissensstand würde ich empfehlen, auf eine Lösung zu setzen, 
die schon Mal irgendwo in den Weiten des Internets funktioniert hat.

Thorsten N. schrieb:
> Mit dem Tasmota Skript konnte ich den WMZ ja auslesen

Dann mach das so. Die Kosten für den Lesekopf sind im Verhältnis zum 
Aufwand alles selbst und neu zu machen minimal.

[Thorsten N. (thorsten_n)]

Naja macht ja auch Spaß was neues auszuprobieren dadurch lernt man auch 
sehr viel. Deswegen habe ich schon etwas Ehrgeiz es hinzubekommen wenn 
es theoretisch möglich ist.

Ich will jetzt erstmal ausprobieren ob ich das mbus Test Programm hier 
aus dem Beitrag ans laufen bekomme, dann weiß ich hoffentlich ob es 
überhaupt funktioniert und ich Daten vom wmz bekomme.

Habe auch schon nach der Software lorusfree gesucht aber die gibt es zur 
Zeit wohl nicht als Download.

Wenn das funktioniert würde ich mich weiter damit beschäftigt wie ich 
die Daten dann in Home Assistent bekomme. Ich habe auch gelesen das 
manche ein pyton Script erstellt haben und den wmz auszulesen, 
vielleicht bekomme ich dies ja hin. Ich glaube in Home Assistent kann 
man auch pyton Scripte ausführen.

[Thorsten N. (thorsten_n)]

Ich habe jetzt ein Python Skript gefunden das eigentlich für einen 
anderen WMZ gedacht ist dies würde ich gerne versuchen anzupassen.

import serial
import time
import binascii
 
 
# === mbus_checksum ===============================================================================
def mbus_checksum(data, skip):
    sum = 0
    for i in range(0, len(data)):
        if i >= skip:
            sum = sum + int(data[i])
    return bytearray([sum & 255])
 
 
# === check_result ================================================================================
def check_result(where, ser):
    result = ser.read(1)
    if result == b'\xe5':
        return True
    else:
        if result is None:
            return True
        else:
            print(f'{where}: bad answer: {binascii.hexlify(bytearray(result), " ")}')
            return False
 
 
# === get_data ====================================================================================
def get_data(ser):
    # 2.5: at 2400, 8N1 to send 2.2s of alternating bits
    ser.write(b'\x55' * 528)
 
    # time.sleep(2.0) # 2.0s sleep -> 0.8s break -> 1.2s until the buffer is empty ...
    time.sleep(1.2 + 170.0 / 2400.0)
 
    # 2.3: change parity
    ser.parity=serial.PARITY_EVEN
 
    # 2.7.1: do selection, use jokers for serial, manufacturer, ID, medium
    # 17 chars, 0.08s outgoing
    selection = b'\x68\x0B\x0B\x68\x53\xFD\x52\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF'
    ser.write(selection)
    ser.write(mbus_checksum(selection, 4))
    ser.write(b'\x16')
    # result arrives after 0.19s - 0.30s
    check_result('Selection', ser)
 
    # 3.1: do application reset 0x50 (to read instant values)
    # 10 chars, 0.05s outgoing
    app_reset = b'\x68\x04\x04\x68\x53\xFD\x50\x50'
    ser.write(app_reset)
    ser.write(mbus_checksum(app_reset, 4))
    ser.write(b'\x16')
    # result arrives after 0.08s
    check_result('Application reset', ser)
 
    # 3.2: do read data
    # 5 chars, 0.02s
    read_data = b'\x10\x7B\xFD'
    ser.write(read_data)
    ser.write(mbus_checksum(read_data, 1))
    ser.write(b'\x16')
    # result arrives after 0.07s, is 0.71s long (ca. 173 bytes)
    result = ser.read(200)  # 173 bytes plus some reserves
    if result is None:
        print('No data received')
    else:
        # debug output (hex dump) of received data
        print(f'user data bytes: {binascii.hexlify(bytearray(result), " ")}')
 
        # 2.7.2: do deselection
        # 5 chars, 0.02s
        deselection = b'\x10\x40\xfd'
        ser.write(deselection)
        ser.write(mbus_checksum(deselection, 0))
        ser.write(b'\x16')
        check_result('Deselection', ser)
 
        # return bytes received
    return result
 
 
# === main ========================================================================================
print('Starting up ...\n')
# 2.5: 2400, 8N1 to send 2.2s of alternating bits, long timeout due to slow response by Ultramess
ser = serial.Serial("/dev/ttyUSB0", baudrate=2400, bytesize=8, parity=serial.PARITY_NONE, stopbits=1, timeout=0.5)
 
while True:
    print('Reading #0')
    result = get_data(ser)
 
    time.sleep(5.0)

Was ich aber noch nicht verstehe sind die Hexadezimalen Zeichen bedeuten 
sollen. Mir ist klar das diese was mit dem anfordern der Daten zu tun 
haben aber ich habe das System noch nicht verstanden. Ich habe nur "xe5" 
verstande, dies ist ja wohl die Rückmeldung vom WMZ das die 
intitilaisierung erfolgreich ist. Habe versucht es irgendwie zu 
verstehen, auch mit Hilfe der Anleitung vom Allmess und verschiedenen 
WEbseiten aber ich verstehe es nicht.

Vor allem weil es unter Tasmota wieder ganz anders aussieht,  hier gibt 
es sml(1 1 "55555555555555555555") als Aufwecksequenz. Warum sieht es so 
aus wenn 0x55 gesendet werden soll.

Bzw. warum es danach so aussieht sml(1 1 "105BFE5916"). Ich die 1 hinter 
der KLammer ist die Nummer des Meters der ausgelesen werden soll. Aber 
woher kommt die Nummer in den Anführungszeichen.

Ich würde es wirklich gerne verstehen.

[Andreas (apreick)]

Ich bin gerade etwas Ratlos

Phill schrieb:
> alle ca. 110 min. gibt's ein Echo

Disen Script von Phill (27.12.24) verwende ich

ging ja auch relativ gut, nur halt nicht im sauberen Abstand von 110 min
selbst mit den unregelmäßigen hätte ich leben können.
Seit Neujahr allerdings nicht mehr (ziemlich böse böse Böller hier)

- dann gabs das erste mal einen FALSCHEN Wert vom Lesekopf und ab da nur 
noch sehr sporadisch

- dann mal den Tip mit dem delay=50 (und aufsteigend) => das half auch 
nicht mehr

- also mal den Skript gelöscht, ging nicht! erst nach stromlos machen 
des Lesekopfes. Dann Skript vom 27.12.24 wieder rein und ca. 5min später 
kam wieder ein Datensatz. Aber neu auslesen kam ganz ganz selten bis gar 
nicht.

Ich habe das jetzt heute 2x mit Stromlos (ca. 30min) gemacht und dann 
kamen inerhalb 5min neue Daten
siehe Anhang

Mein Sharky 775 hat auch das Zusatzmodul (Funk) vom 
Fernwärmelieferanten.
Kann natürlich auch sein das der Sharky ab 2025 nicht mehr mitspielen 
möchte

Habt ihr noch eine Möglichkeit zur Fehlerbeseitigung
Gruß Andreas

[Andreas (apreick)]

Hier noch mal gebastelte Verläufe 2x Spannungslos des Lesekopf machen

[Andreas (apreick)]

ich habe gestern noch eine Automation in HA eingebaut:
wenn um 23:00 Uhr die letzte übermittlung älter ist als 120 min dann 
Lesekopf (ESP01S) 10min stromlos

Das ist natürlich nicht das Ziel :-(

Aber jedes mal danach kamen sofort innerhalb von 5min (Standart 
TelePeriod 300) ein aktueller Wert vom Sharky => also ist das 
Reproduzierbar

Siehe Screenshot (jeweils der erste Datenpunkt war natürlich eine "0")

[Thorsten N. (thorsten_n)]

Ich glaube ich habe endlich die Daten empfangen.. Habe einmal dieses 
zurück bekommen und ich find viele Zeichen wieder.

Daten erhalten: b'4d 4d 68 08 00 72 26 54 83 22 77 04 09 04 3b 00 00 00 
0c 78 26 54 83 22 04 06 21 34 00 00 0c 14 89 93 07 00 0b 2d 24 00 00 0b 
3b 56 00 00 0a 5a 49 06 0a 5e 76 02 0b 61 30 37 00 04 6d 20 05 28 31 02 
27 c3 03 09 fd 0e 22 09 fd 0f 47 0f 00 00 7e 16' [0

Das hier ist aus meinem tasmota Skript gewesen:
1,0406uuUUuuUUs@1000,Total energy,MWh,Energie_total,3
1,0C14bcd8@100,Total volume,m³,Durchfluss_total,2
1,0B2Dbcd6@10,Current power,KW,Leistung_akt,2
1,0B3Bbcd6@1000,Current flow,m³/h,Durchfluss_akt,3
1,0A5Abcd4@10,Flow temp,°C,temp_Vorlauf,1
1,0A5Ebcd4@10,Return temp,°C,temp_Ruecklauf,1
1,0B61bcd6@100,Temp diff,°C,temp_diff,2
1,0227uuUU@1,Meter days,d,Betriebstage,0
;1,046Dxxuu@1-1,Hour,h,time_h,0
;1,046Duu@1,Minute,min,time_m,0
;1,046Dxxxxuu@1,Day,dd,time_d,0

Ich finde 0406 wieder, 0c 14 usw.

Kann jemand bestätigen dass es nach den richtigen Daten aussieht?

[Ralf (rl_rl)]

Thorsten N. schrieb:
> Ich glaube ich habe endlich die Daten empfangen.. Habe einmal dieses
> zurück bekommen und ich find viele Zeichen wieder.
>
> Kann jemand bestätigen dass es nach den richtigen Daten aussieht?

Deine Daten habe ich hier
https://dev-lab.github.io/tmbus/tmbus.htm
reingesteckt.
Aber an der 1.Stelle ein 68 eingefügt.

68 4d 4d 68 08 00 72 26 54 83 22 77 04 09 04 3b 00 00 00
0c 78 26 54 83 22 04 06 21 34 00 00 0c 14 89 93 07 00 0b 2d 24 00 00 0b
3b 56 00 00 0a 5a 49 06 0a 5e 76 02 0b 61 30 37 00 04 6d 20 05 28 31 02
27 c3 03 09 fd 0e 22 09 fd 0f 47 0f 00 00 7e 16

ergibt:
[c]
  LEN  83
  Type  Data
  L  77
  C  8
  A  0
  CI  114
  Errors
  Fixed  false
  ID  22835426
  ManId  ACW
  Version  9
  DeviceCode  4
  DeviceType  Heat meter (Volume measured at return temperature: outlet)
  AccessN  59
  Status  0
data
  data[0]
  id  0
  dif  12
  vif  120
  type  Fabrication No
  value  22835426
  rawValue  38,84,131,34
  func  Instantaneous
  storage  0
  data[1]
  id  1
  dif  4
  vif  6
  type  Energy
  unit  Wh
  value  13345000
  rawValue  33,52,0,0
  func  Instantaneous
  storage  0
  data[2]
  id  2
  dif  12
  vif  20
  type  Volume
  unit  m³
  value  793.89
  rawValue  137,147,7,0
  func  Instantaneous
  storage  0
  data[3]
  id  3
  dif  11
  vif  45
  type  Power
  unit  W
  value  2400
  rawValue  36,0,0
  func  Instantaneous
  storage  0
  data[4]
  id  4
  dif  11
  vif  59
  type  Volume Flow
  unit  m³/h
  value  0.056
  rawValue  86,0,0
  func  Instantaneous
  storage  0
  data[5]
  id  5
  dif  10
  vif  90
  type  Flow Temperature
  unit  °C
  value  64.9
  rawValue  73,6
  func  Instantaneous
  storage  0
  data[6]
  id  6
  dif  10
  vif  94
  type  Return Temperature
  unit  °C
  value  27.6
  rawValue  118,2
  func  Instantaneous
  storage  0
  data[7]
  id  7
  dif  11
  vif  97
  type  Temperature Difference
  unit  K
  value  37.3
  rawValue  48,55,0
  func  Instantaneous
  storage  0
  data[8]
  id  8
  dif  4
  vif  109
  type  Time Point (time & date)
  value  08.01.2025 05:32
  rawValue  32,5,40,49
  func  Instantaneous
  storage  0
  data[9]
  id  9
  dif  2
  vif  39
  type  Operating Time
  unit  days
  value  963
  rawValue  195,3
  func  Instantaneous
  storage  0
  data[10]
  id  10
  dif  9
  vif  253,14
  type  Firmware version #
  value  22
  rawValue  34
  func  Instantaneous
  storage  0
  data[11]
  id  11
  dif  9
  vif  253,15
  type  Software version #
  value  47
  rawValue  71
  func  Instantaneous
  storage  0
  data[12]
  id  12
  type  Manufacturer specific
  value  0,0
[c]

sieht schlüssig aus.
Du bist kurz vorm Ziel.

[Ralf (rl_rl)]

Andreas schrieb:
> Hier noch mal gebastelte Verläufe 2x Spannungslos des Lesekopf machen

Hallo Andreas,

mal nur so eine Idee,
nimm doch mal ein besseres Netzteil.

rl

[Thorsten N. (thorsten_n)]

Super das freut mich, hätte nicht gedacht das es noch klappt. Jetzt muss 
ich nur noch einmal die richtige Position des Lesekopf finden. Den ich 
habe heute morgen die Position immer wieder verschoben und dann geguckt 
ob etwas gesendet wurde. Habe aber übersehen das wohl heute Nacht als 
das Skript lief die Werte empfangen wurde, ich weiß abe nicht mehr in 
welcher Position ich ihn gestern abend gesetzt habe. Muss jetzt einfach 
ausprobieren und ihn dann länger an einer Position lassen. Zumindest 
weiß ich jetzt das es funktioniert und nur an der richtigen Position 
gesetzt werden muss.

Kennt sich hier jemand mit Python aus und kann mir sagen wie ich die 
Daten parsen kann und zu Home Assient senden kann, z.B. über MQTT. 
Vielleicht hat hier schon jemand einb fertiges Beispiel ansonsten muss 
ich wieder ausprobieren.

[Ralf (rl_rl)]

Thorsten N. schrieb:
> Kennt sich hier jemand mit Python aus und kann mir sagen wie ich die
> Daten parsen kann und zu Home Assient senden kann, z.B. über MQTT.
> Vielleicht hat hier schon jemand einb fertiges Beispiel ansonsten muss
> ich wieder ausprobieren.

Hast Du die gezeigten Daten mit dem Pascal Script von weiter oben

[[Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"]]

empfangen?
Dann sollten Daten viel häufiger kommen und Du kannst besser ausrichten.

Welchen Lesekopf hast Du?
Welchen Zähler hast Du eigentlich?

Ich weiss ja selbst auch, dass es nicht einfach ist, sich in das 
Protokoll einzuarbeiten.

[[https://m-bus.com/assets/downloads/MBDOC48.PDF]]

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

Es hält sich aber im Rahmen.
Du bekommst Deine Rohdaten ja mit drei Aufrufen(Telegrammen) aus dem 
Zähler.
Da hackst Du dir die interressanten Teile raus und bereitest sie auf.
So macht es Tasmota ja auch, wie Du selbst oben gesehen hast.

Aber auch in dieses Format muss man sich einarbeiten.

[Thorsten N. (thorsten_n)]

Ralf schrieb:
> Hast Du die gezeigten Daten mit dem Pascal Script von weiter oben
>
> [[Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"]]
>
> empfangen?

Ja ist aber ein Python Skript, keine Ahnung warum nur einmal Daten 
empfangen wurden. Von 1 Uhr bis ca 6 Uhr hat er jede Minute den Request 
gesendet aber ist nichts zurück gekommen.

Ich habe ein CF Echo 2  und nutze ein Hitchi USB Lesekopf. Ich habe von 
dem alten kaputten Hichi Wlan Leskopf den Boden abgesägt und diesen 
zwischen WMZ und dem neuen Hitchi USB Lesekopf geklemmt. Da ich vorher 
anscheinend Reflexionen hatte und mir aufgefallen ist das bei  alten 
kaputten Hichi Wlan die Dioden weniger weit raus gucken. Scheint 
funktioniert zu haben da ich seitdem weniger Reflexionen habe.

Alles klar dann muss ich weiter ausprobieren

[Ralf (rl_rl)]

Thorsten N. schrieb:
> Alles klar dann muss ich weiter ausprobieren

Ja, ohne zuverlässige Leseergebnisse brauchst Du nichts an der SW zu 
ändern.

Und Du weisst jetzt, das es prinzipiell geht.

Ich finde den Hichi WLAN Lesekopf eine gute Wahl, ohne spezifisch 
Werbung zu machen.

Die Tasmota Anpassungen sind auch überschaubar.

[Carsten S. (carsten_s185)]

Hi zusammen!

Ich verzweifle gerade ein bisschen, weil ich entweder dümmer bin als 
erhofft oder alles komplizierter ist als erwartet.

Ich versuche einen Zenner Zelsius C5-IUF optisch mittels eines Bitshake 
SMR air (also mit Wifi) auszulesen.

Der Lesekopf funktioniert soweit (Testskript mit Spiegel), aber dann 
geht nicht mehr viel.

Ich hab versucht die optische Schnittstelle einmal zu initialisieren, 
dann entsprechende Wakeup-Skripte plus sml(1 1 "105BFE5916") 
ausprobiert.

Mein Hauptproblem ist, dass ich NICHTS sehe, da ich nicht weiss, ob das 
Gerät überhaupt antwortet, wie häufig es sendet, etc.

Kann mir da jemand weiterhelfen und sagen, welche Wakeup-Sequenz auf 
jeden Fall stimmt?

Viele Grüsse aus Hamburg

Carsten

[Ralf (rl_rl)]

Carsten S. schrieb:
> Zenner Zelsius C5-IUF

Hi, frag doch mal bei bitshake nach, die haben eine sehr lange Liste mit 
Scripts.
Ansonsten stell mal Dein Script hier ein.

rl

[Carsten S. (carsten_s185)]

Ralf schrieb:
> Hi, frag doch mal bei bitshake nach, die haben eine sehr lange Liste mit
> Scripts.
> Ansonsten stell mal Dein Script hier ein.

Hi Ralf, hab schon nachgefragt und auch geschaut, aber die haben nur für 
3 WMZ die Skripte (Engelmann und Kamstrup).

"Mein" Skript hab ich rangehängt. Es kommt überhaupt kein Ergebnis, 
vermutlich liefert der WMZ nicht mal irgendwas zurück.

[Ralf (rl_rl)]

Carsten S. schrieb:
> Es kommt überhaupt kein Ergebnis


;set serial protocol

ret=sml(-1 1 "2400:8E1")

gehört hier nicht 8N1 hin?



mit

"Sensor53 d1"

kann man in der Tasmotakonsole die Ausgabe der empfangenen bytes sehen.
Da sollte nach dem data request mindestens \xE5 zurückkommen, oder mehr.

Wichtig! nach Gebrauch unbedingt wieder auf

"Sensor53 d0"

zurücksetzen, sonst sieht man keine Daten mehr auf der Hauptseite.



bei meinen Zählern gehts nicht ohne:

"\x10\x40\xFE\x3E\x16"  # SND_NKE mbus_init

"\x68\x05\x05\x68\x53\xFE\x51\x0F\x0F\xC0\x16" # statusrequest

vor der Abfrage.

[Carsten S. (carsten_s185)]

Ralf schrieb:
> Carsten S. schrieb:

> ;set serial protocol
>
> ret=sml(-1 1 "2400:8E1")
>
> gehört hier nicht 8N1 hin?

Ja, stimmt, ich habs in einer meiner Versuche, das mal umzudrehen 
(N1->E1) nicht wieder korrigiert, danke!


> "Sensor53 d1"
>
> kann man in der Tasmotakonsole die Ausgabe der empfangenen bytes sehen.
> Da sollte nach dem data request mindestens \xE5 zurückkommen, oder mehr.
>
> Wichtig! nach Gebrauch unbedingt wieder auf
>
> "Sensor53 d0"
>
> zurücksetzen, sonst sieht man keine Daten mehr auf der Hauptseite.

Ja, das kenne ich, aber wie gesagt, man sieht überhaupt nichts, weil das 
Ding evtl. nur einmal am Tag Daten rauslässt.
Wenn ich das dann nicht zufällig zur richtigen Zeit eingebe (dass er 
dumpen soll), dann sehe ich nix.
Das Log ist dann ja ratzfatz weg.
Debugging ist da irgendwie schwierig, oder komme ich noch an alte Logs 
ran?

> bei meinen Zählern gehts nicht ohne:
>
> "\x10\x40\xFE\x3E\x16"  # SND_NKE mbus_init
>
> "\x68\x05\x05\x68\x53\xFE\x51\x0F\x0F\xC0\x16" # statusrequest
>
> vor der Abfrage.

Das ist ja das Schlimme, es gibt so viele Varianten und ich hab keine 
Ahnung, welche wirklich funktioniert, weil alle hier unterschiedliche 
Zähler haben, die etwas unterschiedlich funktionieren.

Ich nehme das auch noch mit auf, dann mache ich halt alle Abfrage 
hintereinander, die ich finden konnte :-)

Geht das eigentlich, dass man sich das result rausprinten kann mittels
print result='%ret%' ?

Siehe angehängtes Script

[Ralf (rl_rl)]

Carsten S. schrieb:

> Geht das eigentlich,
>
Die print Ausgabe geht in die Konsole.
Die Hochkommas brauchst Du nicht.

>W
The lines in this section are displayed in the web UI main page. 
Requires compiling with #define USE_SCRIPT_WEB_DISPLAY.

Also dort wo auch die Werte stehen sollen.
Das musst Du ausprobieren, ob die Tasmota Firmware bei Dir so kompiliert 
ist, sonst musst Du selbst kompilieren.

Diese beiden Dokus muss man aufmerksam lesen ...
und dann doch noch vieles ausprobieren.
Die Scripts, vor allem die aufwändigen, von anderen Leuten studieren, 
hilft enorm weiter.
Manche Sachen stossen an Grenzen, die man sonst nicht kennt.
Anderes fühlt sich an, wie durch die Brust ins Auge.
Ich hab mal was angehängt. (für einen meiner Zähler)

[[https://tasmota.github.io/docs/Smart-Meter-Interface/]]

[[https://tasmota.github.io/docs/Scripting-Language/]]

[Carsten S. (carsten_s185)]

Ralf schrieb:
> Die print Ausgabe geht in die Konsole.
> Die Hochkommas brauchst Du nicht.

Ist eher ein alter Programmierer"trick": wenn Du quotes ausgibst, dann 
siehst Du, ob z.B. non printable characters in dem String sind, also 
z.B. ein Leerzeichen oder ein Zeilenumbruch.
Ich hab auch klar zu viele prints drin, aber wollte erstmal gucken ob 
überhaupt was zurück kommt ;-)


>>W
> The lines in this section are displayed in the web UI main page.
> Requires compiling with #define USE_SCRIPT_WEB_DISPLAY.
>
> Also dort wo auch die Werte stehen sollen.
> Das musst Du ausprobieren, ob die Tasmota Firmware bei Dir so kompiliert
> ist, sonst musst Du selbst kompilieren.

Okay, das muss ich mir noch mal durchlesen, damit kann ich dann infos 
direkt auf die Hauptseite rausloggen/anzeigen?


> Diese beiden Dokus muss man aufmerksam lesen ...
> und dann doch noch vieles ausprobieren.
> Die Scripts, vor allem die aufwändigen, von anderen Leuten studieren,
> hilft enorm weiter.

Ja, ich denke da hab ich noch so einiges an Arbeit vor mir ;-)

Aktuell sieht das log übrigens so aus:
22:17:43.960 set 2400 baud:8N1
22:17:43.961 result='???'
22:17:43.962 send 0x55 for 3 seconds with 8E1 (72x), 2400 baud (wakeup 
sequence)
22:17:43.965 result='???'
22:17:43.966 wait for the meter
22:17:44.367 switch to 2400 baud 8E1
22:17:44.368 result='???'
22:17:44.369 initialize 6804046853FE5000A116
22:17:44.370 result='???'
22:17:44.771 initialize 1040004016
22:17:44.772 result='???'
22:17:45.173 SND_NKE mbus_init
22:17:45.175 result='???'
22:17:45.176 send "105BFE5916" (request data)
22:17:45.177 result='???'

Ist das normal, dass auch die Kommandos zum Setzen der Baudrate und 
Anzahl Bits keine Rückgabewerte liefern?
Ich hab ja wirklich überhaupt keine Ahnung, ob überhaupt was 
funktioniert.
Oder tappt man so lange im Dunkeln, bis man dann einmal per Zufall die 
richtige Wakeup Sequenz erwischt hat?


LG Carsten

[Ralf (rl_rl)]

Carsten S. schrieb:
> per Zufall die
> richtige Wakeup Sequenz erwischt hat?

Nach der Wakeup Sequenz kommt erstmal nix zurück, die schickst Du so ins 
Blaue.
Wenn Du ein für den Zähler gültiges Telegramm geschickt hast, kommt
E5 zurück. Oder nach Aufforderung die Messwerte.

Erstmal also das Script so simpel wie möglich halten und in der Konsole 
gucken, ob was zurückkommt.

Der Haken dabei ist, man weis nicht, ob nix kommt, weil die Ausrichtung 
nicht stimmt, oder ob die Ansteuerung nicht stimmt.
Ich habe meine Sensoren umgebaut, die Ausrichtung ist jetzt sehr 
unkritisch. Man kann sie sogar deutlich vom Zähler abheben.
Bei meinen Zählern sind Kunststofflinsen Teil des Gehäuses. Da sollte 
die Sendediode so im Sensor stehen, das der Focuspunkt auch getroffen 
wird.

Am Anfang kann man gut mit einem USB-Kopf und einem Programm in einer 
Programmiersprache deiner Wahl die Kommunikation prüfen.

Es gibt auch Analyseprogramme, die man dann mit diesem Kopf auf den 
Zähler loslassen kann.

[Thorsten N. (thorsten_n)]

Ach mich der WMZ noch verrückt. Zweimal habe ich ja Daten erhalten aber 
ish kann es nicht reproduzieren damit ich diese immer wieder erhalte.

Ich habe auch starke Probleme mit Reflexionen da ich immer die 
Aufwachsequenz mit den 55 zurück bekommen. Wobei es auch komisch ist 
manchmal wenn ich den Lesekopf wieder ein Stück drehe bekomme ich andere 
merkwürdige Zeichen zurück.
95 95 usw. oder FF oder 55 55 00 55 61. Aber leider keine Daten die ich 
im Mbus Protokoll wiederfinden kann.

Das was mich dann noch besonders stutzig macht als ich den Lesekopf auf 
eine dunkle Oberfläche komplett bündig gelegt habe habe ich noch Daten 
erhalten. Da können doch keine Reflexionen entstehen ? Die Dioden waren 
dann kompllett bedeckt.

Dachte  könnet etwas an dem Python Skript sein, aber was soll hier der 
Grund sein. Es werden ja die Daten nur serial ausgelesen. Das macht es 
einfach kompliziert.

Ich denke wenn so viel Daten durch die Reflexion zurück kommen, kommen 
die richtigen Daten gar nicht an. So wie ich das Script verstehe werden 
nur 200 Zeichen ausgegeben und dann werden die richtigen Daten 
vielleicht gar nicht ausgegeben weil durch die Reflexion schon 200 
Zeichen ausgegeben wurden.

[Carsten S. (carsten_s185)]

Ralf schrieb:

> Nach der Wakeup Sequenz kommt erstmal nix zurück, die schickst Du so ins
> Blaue.

Habs schon befürchtet. Wäre ja ein netter Zug vom Zähler wenn er ein 
paar mal blinkt und damit sagt: "bin jetzt wach"

> Wenn Du ein für den Zähler gültiges Telegramm geschickt hast, kommt
> E5 zurück. Oder nach Aufforderung die Messwerte.
>
> Erstmal also das Script so simpel wie möglich halten und in der Konsole
> gucken, ob was zurückkommt.

Mein Problem ist, dass nach Meinung Anderer hier im Forum der Zähler nur 
1-4 mal pro Tag überhaupt antwortet.
D.h. ich kann einmal am Tag eine Änderung machen und dann 24h warten.
Wäre alles etwas einfacher, wenn der Zähler sofort irgendwas machen 
würde, an dem ich ablesen kann, ob es funktioniert oder nicht


> Der Haken dabei ist, man weis nicht, ob nix kommt, weil die Ausrichtung
> nicht stimmt, oder ob die Ansteuerung nicht stimmt.

Und das kommt noch dazu! :-/

> Am Anfang kann man gut mit einem USB-Kopf und einem Programm in einer
> Programmiersprache deiner Wahl die Kommunikation prüfen.
>
> Es gibt auch Analyseprogramme, die man dann mit diesem Kopf auf den
> Zähler loslassen kann.

Da muss ich mir echt noch mal überlegen, ob es mir die Zeit wert ist, so 
einen Aufwand zu betreiben. Klar, wäre super, zumindest tagesgenaue 
Werte zu haben, damit ich die Heizungsregelung anpassen kann.


Dank Dir für Deine Hilfe!

Carsten

[Klaus (feelfree)]

Carsten S. schrieb:
> Klar, wäre super, zumindest tagesgenaue Werte zu haben, damit ich die
> Heizungsregelung anpassen kann.

Verstehe ich nicht. Die Heizungsregelung regelt ja die Heizleistung in 
Abhängigkeit von Außentemperatur, Zimmertemperatur oder was auch immer.
Der WMZ misst quasi das Ergebnis dieser Regelung. Wie sollte man 
aufgrund des Verbrauchs in die Regelung eingreifen?

[Thorsten N. (thorsten_n)]

Klaus schrieb:
> Carsten S. schrieb:
>> Klar, wäre super, zumindest tagesgenaue Werte zu haben, damit ich die
>> Heizungsregelung anpassen kann.
>
> Verstehe ich nicht. Die Heizungsregelung regelt ja die Heizleistung in
> Abhängigkeit von Außentemperatur, Zimmertemperatur oder was auch immer.
> Der WMZ misst quasi das Ergebnis dieser Regelung. Wie sollte man
> aufgrund des Verbrauchs in die Regelung eingreifen?

Doch kann ich nachvollziehen. Man verstellt etwas an der Heizung und 
kann kann sehr einfach sehen wie sich der Verbrauch ändert. Natürlich 
sollten dann die Bedingungen Außentemperatur etc an beiden Tagen an 
ziemlich gleich sein

[Klaus (feelfree)]

Thorsten N. schrieb:
> Man verstellt etwas an der Heizung und
> kann kann sehr einfach sehen wie sich der Verbrauch ändert.

Ok, das verstehe ich.

> Natürlich
> sollten dann die Bedingungen Außentemperatur etc an beiden Tagen an
> ziemlich gleich sein

Aber das kann man vergessen. Das wird man nie hinbekommen, und damit 
sind solche Vergleiche von vornherein sinnlos.

Ich mache das Auslesen eigentlich nur, weil ich es kann ;-)
Und natürlich ist es schön, später mal Tages/Monats/Jahresvergleiche zu 
haben.

[Carsten S. (carsten_s185)]

Thorsten N. schrieb:

> Doch kann ich nachvollziehen. Man verstellt etwas an der Heizung und
> kann kann sehr einfach sehen wie sich der Verbrauch ändert. Natürlich
> sollten dann die Bedingungen Außentemperatur etc an beiden Tagen an
> ziemlich gleich sein

Genau.
Es kann auch motivieren, die Heizung doch etwas kühler zu stellen, wenn 
man direkt sieht, wie sich das auf den Wärmeverbrauch und damit die 
Kosten auswirkt.

Das ist ja auch der Hintergedanke beim Stromverbrauch.
Wenn jeder seinen Stromverbrauch misst, kann er/sie gut nachvollziehen, 
wo man sparen kann.

Bei uns (Fernwärme, gut isolierter Neubau) ist die Heizkostenrechnung 
z.T. doppelt so hoch wie bei Nachbarn mit ähnlichem Heizverhalten, dem 
will ich auf den Grund gehen.
Da über den Wärmetauscher auch Warmwasser geht, könnte das die Ursache 
sein, muss aber nicht.

LG Carsten

[Thorsten N. (thorsten_n)]

Carsten S. schrieb:
> Bei uns (Fernwärme, gut isolierter Neubau) ist die Heizkostenrechnung
> z.T. doppelt so hoch wie bei Nachbarn mit ähnlichem Heizverhalten, dem
> will ich auf den Grund gehen.
> Da über den Wärmetauscher auch Warmwasser geht, könnte das die Ursache
> sein, muss aber nicht.

Hallo, kleine Info. Ich hatte auch einen Neubau einen hohen Verbrauch 
und bei mir lag es daran das die Zirkulationspumpe für Warmwasser rund 
um die Uhr lief, habe eine Zeitschaltuhr dazwischen geschaltet und nun 
ist der Verbrauch deutlich herunter gegangen.

Klaus schrieb:
> Aber das kann man vergessen. Das wird man nie hinbekommen, und damit
> sind solche Vergleiche von vornherein sinnlos.

Also bei mir hat es geholfen heraus zu finden das der Verbrauch so hoch 
istweil die Zirkulationspumpe durchlief. Weil ich selbst in den 
Sommermonaten einen hohen Verbrauch hatte und dies durch die 
Aufzeichnungen gut nachvollziehen können. Ich könnte natürlich auch 
jeden Monat hingehen und es ablesen aber so ist ja noch einfacher.

So habe nun sehr wahrscheinlich heraus gefunden woran es liegtdas ich 
die richtigen Daten nicht bekommen habe. Lag wirklich daran das nur 200 
Zeichen ausgewertet wurden. Habe es auf 800 erhöht und jetzt habe ich 
dreimal die Daten erhalten, halt mittendrin zwischen vielen 55

2025-01-10 08:30:48.391 INFO (SyncWorker_6) [custom_components.python_script] Lesen
2025-01-10 08:30:49.243 INFO (SyncWorker_6) [custom_components.python_script] diese Daten erhalten: b'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 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 10 5b fe 59 16 68 4d 4d 68 08 00 72 26 54 83 22 77 04 09 04 54 00 00 00 0c 78 26 54 83 22 04 06 b9 34 00 00 0c 14 00 00 08 00 0b 2d 16 00 00 0b 3b 35 03 00 0a 5a 24 06 0a 5e 82 05 0b 61 19 04 00 04 6d 08 09 2a 31 02 27 c5 03 09 fd 0e 22 09 fd 0f 47 0f 00 00 78 16 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'

Verstehe nur noch nicht warum überhaupt Reflexionen enstehen werden die 
Daten auch beim senden gelesen. Ich dachte die Sequenz wird gesendet und 
dann wird 0,35 Sekunden gewartet und der Req_UD 2 gesendet und dann 
kommen doch erst die Daten vom WMZ zurück. Wie könenn da dann die Daten 
von der Aufwachsequenz wieder dabei sein ?

[Carsten S. (carsten_s185)]

Thorsten N. schrieb:

> Hallo, kleine Info. Ich hatte auch einen Neubau einen hohen Verbrauch
> und bei mir lag es daran das die Zirkulationspumpe für Warmwasser rund
> um die Uhr lief, habe eine Zeitschaltuhr dazwischen geschaltet und nun
> ist der Verbrauch deutlich herunter gegangen.

Ja, die Zirkulationspumpe ist mittlerweile sogar komplett abgeschaltet. 
Hat auch etwas gebracht, aber Verbrauch ist aus meiner Sicht immer noch 
zu hoch im Vergleich zu den Nachbarn.
Aber stimmt, das ist nen ziemlicher Faktor, das konnte man schon 
beobachten. (bis sich das finanziell auszahlt, dauert es ja, da die 
Abrechnung ja immer nen Jahr verzögert kommt, d.h. die für 2024 kommt 
erst Mitte 2025).


> Verstehe nur noch nicht warum überhaupt Reflexionen enstehen werden die
> Daten auch beim senden gelesen. Ich dachte die Sequenz wird gesendet und
> dann wird 0,35 Sekunden gewartet und der Req_UD 2 gesendet und dann
> kommen doch erst die Daten vom WMZ zurück. Wie könenn da dann die Daten
> von der Aufwachsequenz wieder dabei sein ?

Aus Laiensicht: Macht eigentlich nur Sinn, wenn das Senden der 
Aufwachsequenz asynchron passiert und dann schon vor Ende der 
Aufwachsequenz die Datenabfrage passiert.
Keine Ahnung, ob der ESP/Tasmota so funktioniert, aber halte ich auch 
für unwahrscheinlich.

LG Carsten

[Ralf (rl_rl)]

Thorsten N. schrieb:
> Verstehe nur noch nicht warum überhaupt Reflexionen enstehen

Hallo,
mach mal bitte ein Foto vom Aufbau:
Sensorfront, Zählerfront und montiert.

rl

[Thorsten N. (thorsten_n)]

Ralf schrieb:
> Thorsten N. schrieb:
>> Verstehe nur noch nicht warum überhaupt Reflexionen enstehen
>
> Hallo,
> mach mal bitte ein Foto vom Aufbau:
> Sensorfront, Zählerfront und montiert.
>
> rl

Mache ich wenn später zuhause bin aber ich glaube es liegt doch nicht an 
Reflexionen. Ich hatte zwischendurch die Aufwachsequenz aus meinem 
Python Script entfernt und immer doch die Daten aus der Aufwachsequenz 
erhalten.

Hat dies vielleicht etwas mit dem Timeout Befehl zu tun ? Ich bin da 
noch nicht ganz durch gestiegen, bei der Serial Funktion stand auch 
etwas von Buffer und löschen. Wird vielleicht etwas zwischengespeichert 
und wird dann mit ausgelesen. Hier scheint man noch vieles einstellen zu 
können.

Hier einmal das Script, ich hoffe ist verständlich sind noch ein paar 
Sachen drin wo ich nicht genau weiß was diese bedeuten und teilweise 
auskommentiert.

import serial
import time
import binascii
import datetime
import meterbus

##logger.debug(data)
# === mbus_checksum ===============================================================================
def mbus_checksum(data, skip):
    sum = 0
    for i in range(0, len(data)):
        if i >= skip:
            sum = sum + int(data[i])
    return bytearray([sum & 255])
 
 
# === check_result ================================================================================
def check_result(where, ser):
    result = ser.read(1)
    if result == b'\xe5':
        return True
    else:
        if result is None:
            return True
        else:
            logger.info(f'{where}: falsche Antwort: {binascii.hexlify(bytearray(result), " ")}')
            return False
 
 
# === get_data ====================================================================================
def get_data(ser):
    # Definiere die Aufwachsequenz
    # 2.5: at 2400, 8N1 to send 2.2s of alternating bits
    ser.write(b'\x55' * 528)
    #Wartezeit(war vorher 0.350 hat hiermit funktioniert)
    # time.sleep(2.0) # 2.0s sleep -> 0.8s break -> 1.2s until the buffer is empty ...
    time.sleep(0.350)
    
    # Wechsel der Parität zum auslesen der Daten
    # 2.3: change parity
    ser.parity=serial.PARITY_EVEN
 
    # 2.7.1: do selection, use jokers for serial, manufacturer, ID, medium
    # 17 chars, 0.08s outgoing
    ## selection = b'\x68\x04\x04\x68\x53\xFE\x50\x00\xA1\x16'  SND UD 0
    ## selection = b'\x68\x0B\x0B\x68\x53\xFD\x52\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF' # aus dem Sharky Skript
    ##ser.write(selection)
    ##ser.write(mbus_checksum(selection, 4))
    ##ser.write(b'\x16')
    # result arrives after 0.19s - 0.30s
    ##check_result('Selection', ser)
 
    # 3.1: do application reset 0x50 (to read instant values)
    # 10 chars, 0.05s outgoing    app_reset = b'\x68\x04\x04\x68\x53\xFD\x50\x50'
    ##ser.write(app_reset)
    ##ser.write(mbus_checksum(app_reset, 4))
    ##ser.write(b'\x16')
    # result arrives after 0.08s
    ##check_result('Application reset', ser)
 
    # Daten lesen müssen 5 Bytes sein, beim Sharky wird Cheksum und Stopp Bit extra gesendet
    # 3.2: do read data
    # 5 chars, 0.02s
    read_data = b'\x10\x5B\xFE\x59\x16'
    ## read_data = b'\x10\x7B\xFD' aus dem sharky Skript
    ser.write(read_data)
    ##ser.write(mbus_checksum(read_data, 1)) #extra berehcnet und gesendet
    ##ser.write(b'\x16') # stopp Bit
    # result arrives after 0.07s, is 0.71s long (ca. 173 bytes)
    result = ser.read(800)  # 173 bytes plus some reserve erhöht weil Reflexionen dabei sind, war vorher 200
    if result is None:
        logger.info('Keine Daten empfangen')
    else:
        # debug output (hex dump) of received data
        logger.info("Daten nicht umgewandelt")
        logger.info(result)
        logger.info(f'diese Daten erhalten: {binascii.hexlify(bytearray(result), " ")}')
        ##telegram = meterbus.load(result)
        ##logger.info telegram.records[3].parsed_value
        #weiß nicht ob notwendig steht in der Sharky WMZ Anleitung
        # 2.7.2: do deselection
        # 5 chars, 0.02s
        ##deselection = b'\x10\x40\xfd'
        ##ser.write(deselection)
        ## ser.write(mbus_checksum(deselection, 0))
        ##ser.write(b'\x16')
        ##check_result('Deselection', ser)
 
        # return bytes received
    return result
 
 
# === main ========================================================================================
logger.info('Starting up ...\n')
# 2.5: 2400, 8N1 to send 2.2s of alternating bits, long timeout due to slow response by Ultramess
ser = serial.Serial("/dev/ttyUSB1", baudrate=2400, bytesize=8, parity=serial.PARITY_NONE, stopbits=1, timeout=2)
 
while True:
   logger.info('Lesen')
   result = get_data(ser)
 
   time.sleep(60.0)

[Ralf (rl_rl)]

Thorsten N. schrieb:
> warum überhaupt Reflexionen enstehen

Die Aufwachsequenz heißt so, weil sie gar kein Telegramm ist.
In der MBUS Doku steht da garnichts von.
Das ist eine Vereinbarung mit der man batteriebetriebene Geräte darauf 
aufmerksam machen kann, dass außen jemand was will.

Es handelt sich einfach um ein Signal mit wechselndem Pegel.

Der Trick mit \x55 ist folgender:
hex 55 entspricht binär 01010101. Es gibt also auf der Sendeleitung 
einen gleichförmigen Wechsel von 1 und 0. Damit das Muster nicht gestört 
wird muss das im Format 8N1 gesendet werden.
Startbit, 8Bit s.o., keine Parität, 1Stoppbit.
Die Baudrate 2400 Bit pro Sekunde führt dann zum richtigen Timing.

Mit der Anzahl der \x55 stellt sich dann die gewünschte zeitliche Länge 
der Aufwecksequenz ein, weil sich nahtlos 0 und 1 aneinanderreihen.

Danach ist der Zähler bereit Daten zu empfangen.

Vom Zähler gibts darauf keine Antwort ( und auch kein Echo ).

Langer Rede kurzer Sinn, Deine \x55 sind Reflektionen,
die von der Sendediode direkt in den Fototransistor einkoppeln.

Ich habe bei meinen Sensoren kurze schwarze Schrumpfschlauchstücke auf 
Sender und Empfänger gesteckt. Das kommt aber auf die Gehäuse an, wie 
das geht. Normalerweise kann man die Platine verlustfrei aus dem Gehäuse 
nehmen.

Ich finde die Reflektionen auch unschön, aber auf die Dekodierung wirken 
sie sich nicht aus. Im Pascal Script könnte man sie auch weglöschen.

[Thorsten N. (thorsten_n)]

Ralf schrieb:
> Ich habe bei meinen Sensoren kurze schwarze Schrumpfschlauchstücke auf
> Sender und Empfänger gesteckt. Das kommt aber auf die Gehäuse an, wie
> das geht. Normalerweise kann man die Platine verlustfrei aus dem Gehäuse
> nehmen.
> Ich finde die Reflektionen auch unschön, aber auf die Dekodierung wirken
> sie sich nicht aus. Im Pascal Script könnte man sie auch weglöschen.

Hallo ich habe jetzt um beide Dioden Klebeband gemacht aber immer noch 
das gleiche Problem. Im Gehäuse ist auch schon ein langer Steg, ich 
glaube der ist die dick das er komplett die beiden Dioden trennt. Hier 
auf den Foto ist das Klebeband nur bei einer Diode habe s aber jetzt an 
beiden Dioden gemacht.

Bezüglich den löschen im Pascal Skript ist Pascal das gleiche wie 
Python. Weißt du wie man dies machen kann, ich habe hier noch nichts 
passendes gefunden

[Andreas (apreick)]

Ralf schrieb:
> nimm doch mal ein besseres Netzteil

Hallo Ralf
und natürlich auch auch alle die mir geholfen haben :-)

Lösung war nicht ein anderes Netzteil
=> habe seit gestern den "Hichi IR Wifi v2" verbaut und der sendet alle 
ca. 110 min die Daten

Danke schön an alle
Gruß Andreas

[Ralf (rl_rl)]

Andreas schrieb:
> Danke schön an alle

;-)

[Thorsten N. (thorsten_n)]

Hallo, wollte noch Rückmeldung geben. Ich habe es wirklich ans laufen 
bekommen. Habe jetzt ein Python Script in Home Assistent welches die 
Daten ausliest umwandelt und per MQTT an Home Assistent schickt und wird 
dort als Gerät Wärmenmengenzähler mit den verschiedenen Sensoren 
angezeigt.

Sind noch ein paar Kleinigkeiten die ich anpassen muss. Da nicht immer 
Daten zurück kommen, muss ich noch schauen woran es liegen kann. Weiß 
jemand wie oft dieser WMZ daten zurück gibt ? Ob man ihn stündlich 
auslesen kann oder doch nur täglich ?

Muss auch sagen habe es nur durch die Hilfe von Google Gemini geschaft. 
Bin wirklich überrascht und auch ein bisschen erschreckt was Gemini 
leisten kann. Im Prinzip wurde der Code zu 90% von Gemini geschrieben 
und er funktionert.

Ich habe den Anfang erstellt das die Daten serial ausgelesen werden aber 
dann kam ich mit dem umwandeln nicht weiter. Habe dann Gemini gesagt 
erstelle mir bitte einen  code zum umwandeln der daten und senden diese 
per Mqtt zu Home Assistent. Dann hat er mir den kompletten Code 
erstellt.  Dann habe ich noch nach den code für die Sensoren in Home 
Assistent gefragt, diese hat er mir dann auch noch erstellt.

Die Reflexionen konnte ich nicht beseitigen deswegen habe ich gemini 
auch um einen Code zum entfernen dieser Zeichen gebeten, diesen hat er 
mir dann auch erstellt.

Was mir noch aufgefallen ist, dass der Timeout Befehl (0.5) zu kurz 
eingestellt gewesen ist, und somit die Daten nicht emfangen wurden da 
vorzeitig schon das Timeout erreicht wurde, habe diesen auf 10s erhöht.
Ich denke liegt daran das ja auch die Reflexionen gelesenb werden, und 
somit die 0.5 nicht ausreichen.

Wenn jemand interesse an dem Code hat kann ers sich gernen melden.

[Ralf (rl_rl)]

Thorsten N. schrieb:
> Weiß jemand wie oft dieser WMZ daten zurück gibt ?

Das weis ich leider nicht, aber wenn der Zähler batteriebetrieben ist, 
muß man mit dem Auslesen im Dauerbetrieb sparsam umgehen.

Wenn er zuverlässig ausliest, reicht eigentlich einmal um Mitternacht.
Das Script kannst du ja anhängen, hilft vielleicht weiter.

[Thorsten N. (thorsten_n)]

Hallo hier einmal das Script, bei fragen gerne melden

import serial
import time
import binascii
import logging
import meterbus
import paho.mqtt.client as mqtt
import json

# Logger konfigurieren
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
logger = logging.getLogger(__name__)

# MQTT Konfiguration (Anpassen!)
MQTT_BROKER = "xxx"  # z.B. 192.168.178.20
MQTT_PORT = xxx
MQTT_USER = "xxx"
MQTT_PASSWORD = "xxx"
MQTT_TOPIC = "mbus/data"

# MQTT Callbacks
def on_connect(client, userdata, flags, rc):
    if rc == 0:
        logger.info("Erfolgreich mit MQTT Broker verbunden!")
    else:
        logger.error(f"Verbindung mit MQTT Broker fehlgeschlagen, Fehlercode: {rc}")

def on_publish(client, userdata, mid):
    logger.info(f"Daten erfolgreich an MQTT gesendet (MID: {mid})")

def on_disconnect(client, userdata, rc):
    if rc != 0:
        logger.warning(f"Verbindung zum MQTT Broker getrennt, Fehlercode: {rc}. Versuche erneut zu verbinden...")
        client.reconnect()  # Automatische Wiederverbindung
    else:
        logger.info("Erfolgreich vom MQTT Broker getrennt.")

# === get_data ==================================================================================
def get_data(ser=None, test_data=None):
    if test_data:
        logger.info("Verwende Testdaten...")
        return test_data
    else:
        try:
            ser.write(b'\x55' * 528)
            time.sleep(0.350)
            ser.parity = serial.PARITY_EVEN

            logger.info("Daten lesen")
            read_data = b'\x10\x5B\xFE\x59\x16'
            ser.write(read_data)

            result = ser.read(620)
            if not result:
                logger.warning("Keine Daten vom seriellen Port empfangen.")
                return None

            byte_array_hex = binascii.hexlify(result)
            logger.info(f"gelesene Daten (hex): {byte_array_hex.decode()}")
            return result

        except serial.SerialException as e:
            logger.error(f"Fehler bei der seriellen Kommunikation in get_data: {e}")
            return None

# === daten_filtern ==============================================================================
def daten_filtern(daten):
    if daten is None:
        return None

    start_byte = b'\x68'
    end_byte = b'\x16'

    start_index = 0
    while True:
        try:
            start_index = daten.index(start_byte, start_index)
            end_index = daten.find(end_byte, start_index + 1)
            if end_index != -1:
                gefilterte_daten = daten[start_index: end_index + 1]
                logger.info(f"Gefilterte Daten (hex): {binascii.hexlify(gefilterte_daten).decode()}")
                return gefilterte_daten
            else:
                logger.warning("Kein Endbyte nach dem Startbyte gefunden.")
                return None
        except ValueError:
            logger.warning("Kein Startbyte mehr gefunden.")
            return None
        start_index += 1

def transform_json(json_string):
    """
    Transformiert einen JSON-String, indem der Inhalt von "body" nach oben verschoben wird.
    """
    try:
        data = json.loads(json_string)
    except json.JSONDecodeError:
        try:
            # Füge geschweifte Klammern hinzu und parse den String
            json_string = "{" + json_string + "}"
            data = json.loads(json_string)
        except json.JSONDecodeError:
            logger.error("Fehler: Ungültiger JSON-String.")
            return None

    if "body" in data:
        body_content = data.pop("body")

        # Fließkommazahlen runden
        for record in body_content.get("records", []):
            if isinstance(record.get("value"), float):
                record["value"] = round(record["value"], 2)

        data.update(body_content)
    else:
        logger.info("Hinweis: Kein 'body'-Schlüssel gefunden. Keine Transformation notwendig.")

    return json.dumps(data, indent=4)

# === main ========================================================================================
logger.info('Starte Hauptprogramm')
try:
    # Testdaten definieren
    #test_daten_hex = "684d4d680800722654832277040904360000000c78265483220406493500000c14490508000b2d0000000b3b0000000a5a18060a5e89020b61883200046d0d0c2c310227c80309fd0e2209fd0f470f00008d16"
    #test_daten = bytes.fromhex(test_daten_hex)

    # Entweder mit Testdaten testen...
    #roh_daten = get_data(test_data=test_daten)

    #...oder mit der seriellen Schnittstelle (auskommentieren für Tests!)
    ser = serial.Serial("/dev/ttyUSB1", baudrate=2400, bytesize=8, parity=serial.PARITY_NONE, stopbits=1, timeout=10)
    roh_daten = get_data(ser)
    ser.close()

    if roh_daten:
        gefilterte_daten = daten_filtern(roh_daten)

        if gefilterte_daten:
            try:
                frame = meterbus.load(gefilterte_daten)
                json_data = frame.to_JSON()
                logger.info(f"M-Bus Daten (JSON): {json_data}")

                # JSON transformieren
                transformed_json = transform_json(json_data)
                if transformed_json:
                    logger.info(f"Transformierte M-Bus Daten (JSON): {transformed_json}")
                    json_data_to_mqtt = transformed_json # Verwende die transformierte JSON für MQTT
                else:
                    logger.error("Fehler bei der JSON Transformation. Sende untransformierte Daten.")
                    json_data_to_mqtt = json_data # Bei Fehler die ursprünglichen Daten senden

                # MQTT Client erstellen und konfigurieren
                client = mqtt.Client()
                if MQTT_USER and MQTT_PASSWORD:
                    client.username_pw_set(MQTT_USER, MQTT_PASSWORD)

                # Callbacks setzen
                client.on_connect = on_connect
                client.on_publish = on_publish
                client.on_disconnect = on_disconnect

                try:
                    client.connect(MQTT_BROKER, MQTT_PORT, 60)
                    client.loop_start()
                    client.publish(MQTT_TOPIC, json_data_to_mqtt) # Sende die (transformierten) JSON Daten
                    time.sleep(1)
                    client.loop_stop()
                    client.disconnect()
                    logger.info("MQTT Operationen abgeschlossen.")

                except Exception as e:
                    logger.error(f"Fehler bei der MQTT Verbindung oder beim Senden: {e}")

            except meterbus.exceptions.MBusFrameDecodeError as e:
                logger.error(f"Fehler beim Decodieren des M-Bus Frames: {e}")
            except Exception as e:
                logger.error(f"Unerwarteter Fehler beim Parsen des M-Bus Frames: {e}")
        else:
            logger.info("Keine gültigen Daten zum Filtern gefunden.")
    else:
        logger.info("Keine Daten empfangen (weder seriell noch Testdaten).")

except serial.SerialException as e:
    logger.error(f"Fehler bei der seriellen Kommunikation im Hauptprogramm: {e}")
except Exception as e:
    logger.error(f"Unerwarteter Fehler im Hauptprogramm: {e}")

logger.info('Programm beendet')

[Ralf (rl_rl)]

@ Stefan (biscaya)

Das macht es anschaulicher.

[Stefan (biscaya)]

@ Ralf (rl_rl)

Danke für das Bild. Ich habe das ganze nochmal auseinandergenommen und 
durchgemessen, das passt alles. Wenn ich den Zähler in die Hand nehme 
und verdunkle, empfängt das Gerät die eigenen gesendeten Daten. Scheint 
also bezüglich Sensibilität zu funktionieren. Ich habe mittlerweile auch 
eine Ausgabe vom WMZ.

Es handelt sich um einen Allmess Integral-MK UltraMaXX. Problem ist 
tatsächlich wohl der Abstand. Ich verwende einen Hichi Wifi (v1) Kopf. 
Wenn ich den einfach so aufsetze, kommt halt nichts. Keine Ahnung obs am 
Senden oder Lesen liegt. Der Abstand zwischen den Dioden passt. Wenn ich 
den Abstand vom gesamten Kopf zum Sensor leicht vergrößere, kommt etwas 
zurück. Aber leider sehr unregelmäßig. Manchmal ist die Antwort lang, 
meistens zu kurz. Ich bekomme das nicht in eine verlässliche Position 
:-( scheint im unter 1mm Bereich zu liegen, was da genau getroffen 
werden muss. Ich verstehe das nicht richtig, da ich hier von solchen 
Problemen eigentlich nicht wirklich was gelesen habe. Mir gehen da 
irgendwie so langsam die Ideen aus.

[Ralf (rl_rl)]

Stefan schrieb:
> Wenn ich
> den Abstand vom gesamten Kopf zum Sensor leicht vergrößere

Man muß drauf achten ob das reflektierte Signal zurückkommt, oder ob 
auch Daten des Zählers zurückkommen. Wenn tatsächlich was zurückkommt 
UND Reflektion gelesen wird, ist das ein sequentieller Haufen, lässt 
sich aber erkennen.
rl

[Stefan (biscaya)]

Danke nochmal für die Hilfe. Ich hab es jetzt hinbekommen. Nach 
zahllosen Experimenten mit dem Abständen und der Positionierung 
funktioniert das Auslesen jetzt sehr zuverlässig.
Ich habe trotzdem leider noch ein Problem, was ich nicht gelöst bekomme. 
Die Werte die zurückkommen stimmen eigentlich alle zu 100% bis auf den 
Wert total energy. Hier kommt fast jedes mal an dritter stelle ein 
falscher Wert zurück. Da alle anderen Werte immer passen und das 
Auslesen jedes mal klappt, schließe ich jetzt mal ein Fehler beim 
Empfang aus. Hat jemand eine Idee woran das liegen könnte?

Beispiel: Wert liegt bei 47.283, es wird ausglesen und der Wert  47.201 
zurückgegeben, obwohl 47.301 richtig wäre. Der Fehler tritt immer an der 
selben Stelle auf. Nach X Auslesezyklen passt es dann plötzlich.


Mein aktueller Quellcode:

>D
cnt=1

>B
->sensor53 r

>E
ReadWMZ:
print wakeup start
sml(-1 1 "2400:8N1")
for cnt 1 72 1
sml(1 1 "55555555555555555555")
next
print wakeup end
print wait for the meter
delay(350)
sml(-1 1 "2400:8E1")
print request data
sml(1 1 "105BFE5916")
ends

>M 1
+1,3,rE1,0,2400,WMZ,1
1,=so3,128

1,0406uuUU@1,Total energy,kWh,w_total,0

1,0C14bcd8@100,Total volume,m³,v_total,2

1,0B2Dbcd6@10,Current power,KW,p_akt,2

1,0B3Bbcd6@1000,Current flow,m³/h,v_akt,2

1,0A5Abcd4@10,Flow temp,°C,t_flow,1

1,0A5Ebcd4@10,Return temp,°C,t_return,2

1,0B61bcd6@100,Temp diff,°C,t_diff,2

1,0227uuUU@1,Meter days,d,days_op,0

1,92261704uu@1,Readings, ,readcnt,0

#

[Ralf (rl_rl)]

Stefan schrieb:

> sml(1 1 "105BFE5916")
> ends

wofür steht da ein 'ends'?
(switch - case - ends)


> 1,=so3,128

Versuch mal den Puffer größer zu machen. (verdoppeln?)


Vertausche mal zwei Zeilen.
1,0406uuUU@1,Total energy,kWh,w_total,0

1,0C14bcd8@100,Total volume,m³,v_total,2

Ist danach "Total volume" falsch?

[Stefan (biscaya)]

Hups, das ends ist wohl übrig geblieben. Ich habe den Code relativ hart 
beschnitten, da ich das Auslesen simpel halten wollte und per MQTT den 
Befehl aus Homeassistant sende. Hintergrund war, dass ich darüber das 
Delta errechnen wollte, da ich das für mich als einfacher erachtet habe. 
Zusätzlich habe ich in NodeRed dann noch eingebaut, dass nach dem 
Auslesen kontrolliert wird, ob die Anzahl der Auslesungen um +1 erhöht 
wurden, da ich zwischenzeitlich mal das Problem hatte, dass das nicht 
jedes mal geklappt hat. Das ist mittlerweile allerdings kein Problem 
mehr. Ich bin in Tasmota überhaupt nicht firm. Ends habe ich jetzt 
rausgelöscht.

Wenn ich die zwei Zeilen vertausche ändert sich nur die Reihenfolge in 
der Übersicht der Auswertungen, der Wert ist trotzdem fehlerhaft. 
Mittlerwiele ist es auch nicht nur die dritte Stelle die nicht stimmt, 
sondern mir ist aufgefallen, dass der ganze Wert bis auf die ersten zwei 
Zahlen an verschiedenen Stellen daneben ist.

Beispiel jetzt gerade: Ich habe die zwei Zeilen getauscht, ausgelesen - 
Ergebnis 47534

Zeilen zurückgestellt, Puffer verdoppelt - Ergebnis 47606

Der echte Zählerstand verglichen zu diesem Zeitpunkt war dann 47636 (am 
Zähler abgelesen)

Beim dritten mal Auslesen mit dem selben Skript dann plötzlich korrekt 
:-/

So richtig schlau werde ich daraus nicht. Die anderen Werte scheinen 
immer korrekt zu sein, auch Total volume, obwohl das ja eebenfalls eine 
"lange" Zahl ist. Sollte ich doch nochmal an der Positionierung 
arbeiten?

[Ralf (rl_rl)]

Stefan schrieb:
> nochmal an der Positionierung
> arbeiten?

Du kannst in der Tasmota-Konsole mal
in der Eingabezeile

sensor53 d1

eingeben.
Daraufhin werden die Rohdaten im Terminal ausgegeben.

Etliche Ausgaben abwarten, dann markieren, kopieren und als txt-File 
abspeichern.

Oder direkt hier:

https://tasmota-sml-parser.azurewebsites.net/

reinkopieren und dekodieren.
Die Zählerstandszeile kannst Du von dort in dein Script übernehmen.
(Falls was mit der Decodierung nicht stimmt)

Anschließend nicht vergessen:

sensor53 d0

sonst kommt nix auf der Webseite

[Stefan (biscaya)]

Danke für die Tipps! Ich habe jetzt mehrfach ausgelesen und 
abgespeichert, siehe Anhang. Sieht für mich so aus, als ob Lesefehler 
auftreten, die Antworten sind immer unterschiedlich lang und die Werte 
ändern sich / fehlen teilweise.

Bei https://dev-lab.github.io/tmbus/tmbus.htm bekomme ich Parsing Error: 
Check sum failed, pos 1

Bei https://tasmota-sml-parser.azurewebsites.net/decode kommt direkt gar 
nichts, weil wahrscheinlich die Checksum auch dort als falsch erkannt 
wird?

Uff, das ist echt übel. So langsam verzweifel ich daran. Ich dachte echt 
das Ding wäre jetzt gut ausgerichtet, da jedes mal eine ähnliche Antwort 
kam und er auch wirklich immer antwortet. Das war tatsächlich ja auch 
erst so, nachdem ich einen kleinen Abstandshalter eingebaut habe und 
einen Steg dazwischengebaut habe, damit die Dioden sich nicht stören.

[Stefan (biscaya)]

@Ralf (rl_rl)
Leider zu spät für ein Bearbeiten des letzten Beitrags. Was hast du für 
einen ungefähren Abstand der Dioden zum "Glas" vor den Dioden des WMZ? 
Wenn ich den Lesekopf absolut akkurat gerade aufsetze, sendet der WMZ 
Daten aber der Lesekopf registriert nichts. Widerstand habe ich ja schon 
erhöht. Wenn ich ihn leicht drehe kommen die Daten wie vorher immer 
beschrieben, sind aber fehlerhaft (Spiegelung der Sendediode durch das 
Glas?). Ich habe das Gefühl, dass das an der Wölbung des Glases liegt, 
was vor den Dioden des WMZ ist. Komme da absolut nicht weiter. Egal ob 
ich komplett ran gehe oder Abstand habe, ich empfange dann nichts.

[Ralf (rl_rl)]

Stefan schrieb:
> Wölbung des Glases
Ja, die 'Linsen' machen es zusätzlich schwer.
Erstens muss man den Focus einigermassen treffen.
Und wenn man schräg reinleuchtet weicht die 'Focusscheibe' zur Seite 
aus.
Kann man gut mit Lupe und Taschenlampe probieren.
Ich kann das mal probieren am echten Objekt, geht aber nicht spontan, 
ich hab aber noch Teile hier rumliegen.

Ich hab mir damals Gehäuse gedruckt, die vorne auf den Nippeln klemmen 
und einen Kabelbinder zur Sicherung benutzen. Bild.

Ich kanns jetzt nicht sehen, aber ich denke Diode und Transistor sind 
bündig mit der Gehäuseoberfläche.

[Andreas (apreick)]

Andreas schrieb:
> Lösung war nicht ein anderes Netzteil
> => habe seit gestern den "Hichi IR Wifi v2" verbaut und der sendet alle
> ca. 110 min die Daten

Hallo :-)

ich habe leider "wieder" ein Problem und finde keine Lösung

der "Hichi IR Wifi v2" verabschiedet sich alle 2/3 Tage
- also die WebUI ist dann nicht mehr erreichbar und sendet natürlich 
dann auch keine Daten mehr an Mqtt

Stromlos machen => dann geht es wieder für 2/3 Tage

Bisher habe ich:
- mehrere Netzteile versucht
- andere USB Kabel
- neuen Lesekopf "Hichi IR Wifi v2" mit Tasmota 14.4.1
- (Position Lesekopf dann natürlich auch, kenne sie jetzt sehr gut)

Habt ihr eine Lösung für mein Problem woran das liegen kann?

Verwendeter Script:

>D
;start, define variables
cnt=0

>B
;setup sensor
->sensor53 r

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

#
#readmeter
print wakeup start
;set serial protocol
sml(-1 1 "2400:8N1")
;send 520 times 0x55 with 8N1, 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)
delay(100)
sml(1 1 "105BFE5916")
delay(50)
print ----- END CYCLE -----
;delay(10000)

>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
#

Habe in Homeassistant jetzt eigene Sensoren angelegt damit die ersten 
Werte "0" nach einem Neustart ignoriert werden und dann natürlich auch 
in InfluxDB alles passt ohne das ich noch etwas korrigieren muss

[Klaus (feelfree)]

Andreas schrieb:
> Habt ihr eine Lösung für mein Problem

Keine Lösung, aber ein Workaround:
Über eine Zeitschaltuhr den Lesekopf einmal täglich stromlos machen. 
Oder vielleicht gibt's ja sogar in Tasmota eine passende 
Reboot-Funktion, die man mit einem Timer auslösen kann?

[Andreas (apreick)]

Ja 👍
Momentan habe ich einen Shelly Plug am Lesekopf und dieser macht den 
Lesekopf stromlos wenn 10min nicht erreichbar.

Dein Vorschlag ist auch schon vorbereitet:
über HTTP request oder
über MQTT topic

Hätte aber gerne gewusst warum?

Der MQTT Connect Count Sensor zählt natürlich auch hoch bevor das ganze 
passiert

[Stefan (biscaya)]

@Ralf (rl_rl)

Ich bin tatsächlich einen Schritt weiter aber stehe wieder vor einem 
anderen Problem. Ich habe die Lese-Diode ausgetauscht sowie den 
Abstandhalter ausgebaut und den Lesekopf gerade fixiert. Jetzt haben 
sich die Daten so verändert, dass ich konstant jedes mal eine 68 am 
anfang habe. Ich habe zig mal ausgelesen und die Seite 
https://dev-lab.github.io/tmbus/tmbus.htm zeigt mir die Daten auch 
entsprechend immer richtig an.

Hier mal eine Beispielausgabe:

68 4d 4d 68 08 00 72 52 14 38 21 92 26 17 04 12 00 00 00 0c 78 52 14 38 
21 04 06 20 bb 00 00 0c 14 03 99 36 01 0b 2d 26 00 00 0b 3b 22 10 00 0a 
5a 83 02 0a 5e 60 02 0b 61 25 02 00 04 6d 16 11 22 33 02 27 a8 04 09 fd 
0e 08 09 fd 0f 11 0f 00 00 68 16

Zum Problem: Mit meinem oben geposteten Quellcode in Tasmota bekomme ich 
zum Teil trotzdem andere (falsche) Werte zurück - bspw. bei total 
Energy.
Die andere Seite (https://tasmota-sml-parser.azurewebsites.net/decode) 
funktioniert leider nicht mit den Eingaben und liefert keine Ausgabe. 
Wie komme ich an die richtigen Decoder-Strings, wenn ich sie dort nicht 
bekomme? Die Daten müssten ja trotzdem jetzt korrekt sein nehme ich an? 
Ich habe mir einen Wolf gegoogelt, aber finde nichts.

[Ralf (rl_rl)]

Stefan schrieb:
> wie komme ich an die richtigen Decoder-Strings

https://itrona.ch/stuff/F2-2_PJM_5_Beschreibung%20SML%20Datenprotokoll%20V1.0_28.02.2011.pdf

Hänge nochmal Daten an, von denen Du glaubst, dass sie richtig sind.

Die Filterstrings in deinem Script findest Du in deinen Hexwerten 
wieder,

Bei mir zB:

1,0C78bcd8@1,SerNo, ,serNo,0
1,0406uuUU@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,2
1,0B3bbcd6@1,Current flow,l/h,F_akt,1
1,0A5abcd4@10,Flow temp,°C,t_flow,1
1,0a5ebcd4@10,Return temp,°C,t_return,1
1,0b61bcd6@100,Temp diff,K,t_diff,2

und Bild.

Die Doku:
https://tasmota.github.io/docs/Smart-Meter-Interface/

[Ralf (rl_rl)]

Andreas schrieb:

Hallo,
mal den Puffer vergrößern, falls Du das nicht mitkompiliert hast.

;delay(10000)
>M 1
+1,3,rE1,0,2400,WAERME,1
1,0C06bcd8@1,Total Energy,kWh,w_total,0

ändern bei 1,=so3,512

>M 1
+1,3,rE1,0,2400,WAERME,1
1,=so3,512
1,0C06bcd8@1,Total Energy,kWh,w_total,0

[Andreas (apreick)]

Ralf schrieb:
> falls Du das nicht mitkompiliert hast.

Hallo Ralf,
Bei dem ersten v2 (Baugleich zum neuen) trat der gleiche Fehler auf.
Daher mein Versuch mit dem anderen die neue Tasmota Version zu 
verwenden.
Selber kompiliert habe ich ihn nicht, habe eine fertige verwendet:
https://ottelo.jimdofree.com/stromz%C3%A4hler-auslesen-tasmota/#4

Aber versuche ich gerne :-)

[Andreas (apreick)]

Ralf schrieb:

> 1,=so3,512

mit dieser Zeile kamen in 7 Stunden keine Werte vom Lesekopf.
Zeile wieder raus, dann kam innerhalb 1/2 h wieder ein Wert

[Thomas (linuzer)]

Hallo :-)

erstmal vielen Dank für all die Informationen in diesem Thread und die 
ganze Arbeit, die hier schon geleistet wurde!

Seit einiger Zeit versuche ich (bisher erfolglos) meinen Minol C5-M60 
Wärmezähler über die optische ZVEI-Schnittstelle auszulesen. Entweder 
habe ich hier noch ein grundlegendes Verständnisproblem, auf jeden Fall 
gibt der Zähler bisher keinen Mucks von sich. Ich gehe davon aus, dass 
er tatsächlich mbus über die optische Schnittstelle spricht, obwohl ich 
auch hierbei nicht 100%ig sicher bin. Da meine Versuche mit der 
Tasmota-Firmware bisher keine Ergebnisse hatten, bin ich auf das 
mbus-test Tool von Stefan B. umgestiegen.

Aber auch nach zahlreichen Versuchen mit den unterschiedlichsten 
Parametern (Länge der Aufwachsequenz 0 - 3300 ms, Pause 300 - 400 ms) 
habe ich es nicht geschafft, dem Zähler auch nur eine einzige Antwort zu 
entlocken.

Als Hardware nutze ich zum testen einen Raspi 5, an dem ein 
Volkszähler-kompatibler IR-Lesekopf von Ueding an den Ports 14 + 15 
hängt.

Mit mbus-test -t leuchtet die LED schwach rot, d.h. ich denke die 
Hardware sollte soweit funktionieren. Auch die Positionierung über der 
Schnittstelle habe ich nach bestem Wissen und Gewissen perfektioniert 
(Blick durch das leere Gehäuse, Markierung der Position). Eine 
Restunsicherheit gibt es bei der Ausrichtung, also welche die sendende 
und welche die empfangende LED des Zählers ist (die dunkler aussehende 
ist Rx, oder?).

Hat irgend jemand noch einen guten Tipp für mich, wie ich die Sache 
weiter eingrenzen kann? Am besten, wenn irgend jemand schon direkte 
Erfahrungen mit Minol-Wärmezählern hätte...
Mit welchen Parametern von mbus-test zu spielen ist am 
aussichtsreichsten? Was kann ich noch tun? Bin für jede Hilfe dankbar!

[Erwin G. (holzheizer)]

Ich kann mich nur meinem Vorredner anschließen --> großer Respekt, was 
hier schon geschrieben wurde.
Aber genau darin besteht für mich als Laien auch das Problem; soviele 
Skripte
(oder was auch immer), soviele Seiten - das schaffe ich nicht zu lesen 
und noch weniger zu verstehen.
Deshalb bitte ich die Gemeinschaft hier um Hilfe, damit ich meinen
Wärmezähler Metrona Ultraheat XS2 auslesen und die Daten speichern kann.
Folgende Konfiguration habe ich:
an dem WZ ist ein optische Lesekopf von "Wattwächter" mit Tasmota, der 
eigentlich für Strommessung ist. Der Verkäufer sagte mir aber, dass das 
Auslesen schon einmal bei einem Engelmann WZ funktioniert hat - bei 
meinem funktioniert das mitgeschickte Skript leider nicht.
Der IR-Kopf ist ins Netzwerk eingebunden und ich erreiche den auch über 
den Browser nach Eingabe der IP.
Soweit bin ich schon mal.
Aaaaber ich kann ihn nicht ansprechen, weil ich keine Ahnung, was ich da 
eingeben müsste.
Ihr würdet mich megaglücklich machen, wenn ihr mir helfen könntet, weil 
ich verzweifle. Für mich ist das deshalb wichtig, weil ich die Daten 
dringend brauche, um meine tatsächliche Heizlast zu kennen, weil ich 
meine Heizung ändern will.
....und der Winter ist fast vorbei.
Falls das gar nicht geht, wäre ich auch froh, wenn man mir einen WZ 
empfehlen oder verschaffen könnte, der einfacher zu handhaben ist. Kann 
was Gebrauchtes sein, Batteriepaket oder Netzteil würde ich dranbasteln.
Alle 15 Minuten abrufen zu können wäre optimal.

Vielen, vielen Dank schon mal im voraus.

[Walter (wavoigt)]

Hi Erwin,
Der Wattwächter funktioniert sicher ähnlich oder gleich wie der Hitchi 
Lesekopf, zumal beide Tasmota verwenden.
Du brauchst auf jeden Fall ein Tasmota Script, das auf deinen 
Wärmezähler angepasst ist.
Ich hab mal auf https://tasmota.github.io/docs/Smart-Meter-Interface/
geschaut, da ist dein Wärmezähler leider nicht zu finden.
Vielleicht findet sich hier jemand, der/die weiterhelfen kann...

[Erwin G. (holzheizer)]

Walter schrieb:
> Vielleicht findet sich hier jemand, der/die weiterhelfen kann...

Ja, das hoffe ich auch.
Ich glaube auch fast, dass es die identischen Zähler unter verschiedenen 
Namen gibt.
Auf meinem steht Metrona Ultraheat XS2 drauf, gibt es aber auch mit der 
Aufschrift ISTA, Landis+Gyr, Qundis etc.
Ich habe leider überhaupt keine Ahnung, wie die anzusprechen sind.
Habe mich bei Landis+Gyr gemeldet - sehr unkooperetiv...  der 
Mitarbeiter hatte entweder keine Ahnung oder wollte nicht helfen. 
Angeblich könnte man über die optische Schnittstelle nichts auslesen.... 
naja, frage mich dann natürlich, wozu die da ist.
Vielleicht hatte von euch ja jemand schon mal so ein Teil geöffnet und 
könnte mir sagen, ob die eingekreisten Stellen im Bild irgendwelche 
Schnittstellen sein könnten?

VG