Neues Modul zur Abfragen eines MBus Netzwerks

[daubsi]

Servus,

wenn du nicht an das Kabel selber hinkommst, könnte es wohl schwer werden. Um MBus zu "sprechen", brauchst Du wie oben beschrieben einen Pegelwandler, der die Befehle auf den Bus setzt. Wenn das Kabel bei Dir nur in dieses Auslesemodul geht, dann sieht es wohl eher schlecht aus... BT Schnittstelle kann jetzt auch alles und nichts sein. Meine Heizung kann auch über ein IR Modul ausgelesen werden, dass man vorne hinklippst - das hatte der Techniker auch mal dabei -, aber solange Du nicht Zugangscodes etc. hast, wirst Du damit wohl auch nicht weit kommen.
Einfach schon mal freundlich beim Versorger angefragt? Manchmal hat man ja Glück und man gelangt an einen hilfsbereiten Menschen, der einem u.U. sogar die PIN für den Auslese-Zugang rausgibt (so geschehen bei einem Kollegen von mir...)

VG
daubsi

[Andreasgs]

Hallo Zusammen,

Ich hab ein Problem beim Testen der seriellen Schnittstelle: Ich habe einen Wärmemengenzähler der eine RS232 Schnittstelle besitzt, über diese er das MBUS - Protokoll spricht.

Auf dem Rpi3 hab ich das Serial Modul von https://www.abelectronics.co.uk/p/51/Serial-Pi-Plus gesteckt und nach deren Anleitung konfiguriert. Nachdem ich auch den RPI3 Bluetooth hack durchgeführt hatte, bekam ich auch keine Probleme mehr beim connecten der rSCADA Lib zum Port. Nur jetzt kommt gar nichts mehr. Das Script läuft, und beendet sich ohne Rückmeldung. Ich hab das Gefühl, dass ich den falschen Serial Port im RPI3 erwischt habe.

dmesg liefert folgenden output:

Code Auswählen Erweitern


andreas@FHEM:~ $ dmesg | grep tty
[    0.000000] Kernel command line: 8250.nr_uarts=1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa02082 bcm2709.serial=0x5dfdc392 smsc95xx.macaddr=B8:27:EB:FD:C3:92 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[    0.001290] console [tty1] enabled
[    0.268311] 3f215040.uart: ttyS0 at MMIO 0x3f215040 (irq = 29, base_baud = 50000000) is a 16550
[    0.908209] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 83, base_baud = 0) is a PL011 rev2
[    2.491519] systemd[1]: Starting system-getty.slice.
[    2.495059] systemd[1]: Created slice system-getty.slice.


ttyS0 und ttyAMA0 habe ich probiert. die Bautraten hatte ich nochmal angepasst auf 2400Baud. immer mit dem gleichen ergebnis.

Weiß jemand Rat?

[daubsi]

Hi,

hm, was meinst Du mit "RS232 über die er MBus spricht"?
MBus ist ja ein Protocol mit 2 Drähten und bis zu 36V Spannung? Da kannst Du doch keine normale RS232 anschliessen?
Oder ist das Ding sowas wie der Pegelwandler, den ich oben erwähnt habe?

VG
daubsi

[alen]

Servus,

wenn du nicht an das Kabel selber hinkommst, könnte es wohl schwer werden. Um MBus zu "sprechen", brauchst Du wie oben beschrieben einen Pegelwandler, der die Befehle auf den Bus setzt. Wenn das Kabel bei Dir nur in dieses Auslesemodul geht, dann sieht es wohl eher schlecht aus...

also an das Kabel würde ich schon raunkommen. Siehe Bild. Das blaue Ding ist das Auslesemodu. Der Vorsorger hat so ein Auslesegerät (induktiv). Das hält er dort hin und kann die Daten via Bluetooth an an ein Tablet/Notebook übertragen. Das ist das Auslesegerät: http://www.gwf.ch/fileadmin/download/Versorgung/Prospekte/Automatisierte_Auslesung/NEU_CAB-05.pdf

Die Frage ist ob ich etwas nachbauen könnte, damit ich die Daten auch von diesem Ding (induktiv) ablesen kann und dann ins FHEM einbinden könnte?

Oder ich hänge etwas im Kabel dazwischen (M-Bus Master) natürlich in Rücksprache mit dem Vesorger.
Was denkt ihr?

Den Versorger/Hersteller habe isch schon angefragt, aber leider keine Antwort.

Gruss
A.

[daubsi]

Servus,

hm so ein Busmaster könnte vlt funktionieren, aber dass Du Duch in die BT Schnittstelle "reinhacken" kannst, kann ich mir eher nicht vorstellen ...

Aber unbedingt mit dem Betreiber vorher abklären...

VG daubsi

[micomat]

Pegelwandler (PW3) da
HRI-Modul fuer Sensus Zaehler da
libmbus test funktioniert

Jetzt wird dein Modul getestet

[micomat]

Hier mein Script zum Auslesen eines HRI-B1 Moduls das an einem SENSUS Wasserzaehler haengt. Als Pegelwandler wird ein Relay PW3 genutzt.

Code Auswählen Erweitern


#!/bin/bash
/home/pi/libmbus-0.8.0/bin/mbus-serial-request-data -b 300 /dev/usbteil3 0 > /opt/fhem/log/zaehler
volume=$(xmllint --xpath '//DataRecord[@id=1]/Value/text()' /opt/fhem/log/zaehler)
echo VOLUME:$volume/V
echo $(date) VOLUME:$volume >> /opt/fhem/log/zaehlerlog.txt


300 baud weil die Entfernung schon ein paar Meter sind und ich bei 2400 baud eher zufaellig gueltige Readings hatte.
Das Zaehlerlog schreibe ich nur aktuell zu Testzwecken mit. Da ich nur ein einziges Reading brauche habe ich alle anderen Werte entsprechend geloescht.

[Prof. Dr. Peter Henning]

Bestärkt mich in der Ansicht, dass der MBus viel zu viel Overhead für die Hausautomatisierung bietet.

LG

pah

[micomat]

mangels alternativen und bei nur 45eur für nen PW3 kann ich damit leben.

[Prof. Dr. Peter Henning]

Klar, muss ja - zeigt aber m.E., dass MBus keine so richtige Zukunft hat.

LG

pah

[daubsi]

Hier mein Script zum Auslesen eines HRI-B1 Moduls das an einem SENSUS Wasserzaehler haengt. Als Pegelwandler wird ein Relay PW3 genutzt.

Code Auswählen Erweitern


#!/bin/bash
/home/pi/libmbus-0.8.0/bin/mbus-serial-request-data -b 300 /dev/usbteil3 0 > /opt/fhem/log/zaehler
volume=$(xmllint --xpath '//DataRecord[@id=1]/Value/text()' /opt/fhem/log/zaehler)
echo VOLUME:$volume/V
echo $(date) VOLUME:$volume >> /opt/fhem/log/zaehlerlog.txt


300 baud weil die Entfernung schon ein paar Meter sind und ich bei 2400 baud eher zufaellig gueltige Readings hatte.
Das Zaehlerlog schreibe ich nur aktuell zu Testzwecken mit. Da ich nur ein einziges Reading brauche habe ich alle anderen Werte entsprechend geloescht.

Moin!
Interessant, ich bin momentan auch auf 300 Baud runter, weil ich andauernd Abbrüche hatte. Das Kabel ist bei mir aber nur etwa 10m lang.
Ich habe mein Script zum Auslesen GetHRIDataUnit.sh noch ein bisschen erweitert zur Fehlerbehandlung. Ein Problem ist z.B. dass ich ja 2 MBus Devices habe und FHEM die unter Umständen so scheduled dass zeitgleich versucht wird beide Devices auszulesen, was natürlich nicht klappt. Daher habe ich eine Warteschleife eingebaut. Ausserdem wird das richtige USB2Serial Kabel dynamisch ermittelt, da ich auch noch einen JeeLink habe, und nicht jedesmal 100% exakt dem gleichen ttyUSB-Device das gleiche HW-Device zugeordnet wird. Alternativ könnt ihr es über udev rules statisch zuweisen, siehe das letzte Script.

GetHRIDataUnit.sh

Code Auswählen Erweitern


#!/bin/bash
DEVICE=`/home/pi/listUSB.sh | grep Prolific | cut -d " " -f 1`

/usr/local/bin/mbus-serial-request-data -b 300 $DEVICE 10 > /tmp/hridataunit

if [ $? -ne 0 ]; then
        sleep 10
        /usr/local/bin/mbus-serial-request-data -b 300 $DEVICE 10 > /tmp/hridataunit
fi

serial=$(xmllint --xpath '//DataRecord[@id=0]/Value/text()' /tmp/hridataunit)
water=$(xmllint --xpath '//DataRecord[@id=1]/Value/text()' /tmp/hridataunit)
vendor=$(xmllint --xpath '//SlaveInformation/Manufacturer/text()' /tmp/hridataunit)
requests=$(xmllint --xpath '//SlaveInformation/AccessNumber/text()' /tmp/hridataunit)
echo VENDOR:$vendor,SERIAL:$serial,REQUESTS:$requests,LITERS:$water/V
rm /tmp/hridataunit



listusb.sh:

Code Auswählen Erweitern


#!/bin/bash

for sysdevpath in $(find /sys/bus/usb/devices/usb*/ -name dev); do
    (
        syspath="${sysdevpath%/dev}"
        devname="$(udevadm info -q name -p $syspath)"
        [[ "$devname" == "bus/"* ]] && continue
        eval "$(udevadm info -q property --export -p $syspath)"
        [[ -z "$ID_SERIAL" ]] && continue
        echo "/dev/$devname - $ID_SERIAL"
    )
done


/etc/udev/rules.d/80-serials.rules:

Code Auswählen Erweitern


# Ensure the myJeelink (the one with the serial number) is called ttyUSB0 and the Prolific USB2Serial cable for the MBus interface is called ttyUSB1 (identified via manufacturer tag)
KERNEL=="ttyUSB*", ATTRS{serial}=="AJ02Wxxx", NAME="ttyUSB0"
KERNEL=="ttyUSB*", ATTRS{manufacturer}=="Prolific Technology Inc.", NAME="ttyUSB1"



[micomat]

Ich habe auch in Etwa 10m Laenge. Dachte erst es liegt irgendwie an EMV da im Heizungs-/Hausanschlussraum ja doch noch einiges anderes steht. Seit ich aber auf 300baud bin flutscht das.

Ich hab auch eine udev-Rule, da am gleichen Pi noch IR-Lesekoepfe fuer Stromzaehler haengen.

Ich hoffe ich finde noch irgendwo eine weitere MBus Verwendungsmoeglichkeit. Sonst liegen 2 der 3 Anschluesse am PW3 brach.

@pah, wenn ich jedoch hausverwalter bin und habe einen PW60 um die einzelnen Wohnungen zu messen, dann macht das sicher mehr Spass als alle einzeln abzufragen

[micomat]

@daubsi, du hast nicht zufaellig ne ahnung, wie ich den zaehlerwert in das HRI modul schreiben kann? ich haette gern den wert auf der uhr synchron mit dem in FHEM

[daubsi]

Hm... na ja, nachdem der Zähler ja für viele nicht nur als "Spielerei" für FHEM gedacht ist, sondern die Basis für die Abrechnung an die Wasserwerke (das ist ja der Witz, dass da nicht zwingend jemand vorbei kommen muss um die Uhr abzulesen), kann ich mir nur schwer vorstellen, dass man den einfach so auf einen anderen Wert setzen kann...
Hast Du denn das Anleitungsblatt von dem HRI B1 mitbekommen? Ich habe da 2,3 Datenblätter, bzw. auch Anleitungen für die Anbindung an einen Pegelwandler o.ä. Evtl steht da was dazu, aber ich glaube es, wie gesagt, eher nicht.

[micomat]

eigentlich auch ne bloede frage hast recht. wenns so einfach waer wuerds jeder machen.
ich werd mir einfach nen dummy/doif bauen und die differenz addieren.

danke