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

[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.