mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wärmezähler über optische M-Bus-Schnittstelle auslesen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: A.. P. (arnonym)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
Autor: A.. P. (arnonym)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander S. (alexanders)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oroettger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Klaus R. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Alexander S. (alexanders)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus R. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander S. (alexanders)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus R. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander S. (alexanders)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Herbert K. (avr-herbi)
Datum:

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

Autor: Klaus R. (klara)
Datum:

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

Autor: geronet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander S. (alexanders)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alexander S. (alexanders)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: tnzs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: tnzs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.