Wireless M-Bus für CUL

[Ich79]

Hallo zusammen,

ich habe auch ein paar Meldungen, die scheinbar zu kurz sind. Wobei die schon recht ähnlich sind.
Vielleicht hilft das irgendwie bei der Modul Entwicklung

VG
Boris

Code Auswählen Erweitern


2015.02.26 17:37:19 3: cul: Unknown code b4BC465B2B7413006F015505AA083030065707C0139446532955570099D25D8077ACE000000046D0D0BFA120C13584DEF1306004C1308640500426CDF1C326, help me!
2015.02.26 17:47:18 3: cul: Unknown code b4BC465B2B7414006F016A272A083030097703C0039446532025670098F2FD8077ACF000000046D3010FA120C139995447303004C1348370300426CDF1C326, help me!
2015.02.26 20:27:10 3: cul: Unknown code b4BC465B2B7414006F01A81ABA08303007C70F400394465329657700923D2D8077ACF000000046D1410FA120C1314F1CB6202004C1315220200426CDF1C326, help me!
2015.02.26 20:47:14 3: cul: Unknown code b4BC465B2B7416006F01CDACEA08303008C701B0039446532965870099041D8077AD0000000046D1414FA120C1336094B2404004C1399030400426CDF1C326, help me!


[kaihs]

ich habe auch ein paar Meldungen, die scheinbar zu kurz sind.

Es könnte dieses Problem sein.
Was benutzt ihr als Empfänger, einen CUL von busware? Falls ja, welche Hardware Version und welcher Version der culfw?
Habt ihr eine eigene Version compiliert und mglw. die TTY_BUFSIZE geändert?

[Ich79]

Guter Punkt. Ich nutze keinen CUL von Busware, sondern was selbst gebasteltes. Habe die nanoCUL FW geflashed

Code Auswählen Erweitern

version => V 1.63 nanoCUL868
bei mir ist es so definiert:

Code Auswählen Erweitern

#define TTY_BUFSIZE             128

Werde mal eine neue Firmware flashen. Die Bufsize setze ich dann mal auf 800. Bei der Gelegenheit kann ich dann auch mal ein paar ungenutze Protokolle rauswerfen. Danke für den Hinweis! Ich melde mich sobald das mal ein paar Stunden gelaufen ist. Wohl erst am WE.

VG,
Boris

[kaihs]

Die Bufsize setze ich dann mal auf 800.

Damit könnte es schon eng werden, der ATMega328 hat nur 2048 Bytes RAM.
WMBUS braucht selbst schon ziemlich große Puffer, so dass selbst wenn der Compiler nicht meckert es während der Programmausführung zu einem Stackoverflow kommen könnte.

Deine Pakete sollten mit einer TTY_BUFSIZE von 256 auskommen.

[Ich79]

Mhm hab es gerade gemerkt. Nach dem flashen mit Größe von 512 kommt quasi gar nichts mehr an. Morgen teste ich mal mit etwas weniger Puffer. Danke!

[Ich79]

Deine Pakete sollten mit einer TTY_BUFSIZE von 256 auskommen.

So, nach etwas rumprobieren bin ich jetzt bei der TTY_BUFSIZE von 200 angekommen. Damit kommt jetzt die gesamte Nachricht an. Die Geräte haben sich mittlerweile nochmal gemeldet und wurden korrekt angelegt.
Vielen Dank für den Tipp!

Viele Grüße
Boris

[kossmann]

Zur Info: Meine Qundis-Zähler funken seit dem 25. Februar, 19:00 Uhr, keine interpretierbaren Nachrichten mehr. Schade

[Mario67]

Hallo,

ich hoffe ich bin im passenden Thema.

Hat jemand Anstrengungen unternommen und ggf. sogar Resultate bei der Anbindung des Wasserzählers MULTICAL 21 der Fa. Kamstrup erzielt (https://www.kamstrup.com/de-de/products-and-solutions/water-meters/residential-water-meter), welcher über Wireless M-Bus kommuniziert?
Hintergrund der Frage ist die geplante Umstellung hier durch den städtischen Versorger, so dass ich Ersatz für meine bisher praktizierte Verbrauchserfassung (Abtastung mit Reflex-Optokoppler, Zählung mit 1-Wire-Counter) benötige.

Grüße,
Mario

[kaihs]

Hat jemand Anstrengungen unternommen und ggf. sogar Resultate bei der Anbindung des Wasserzählers MULTICAL 21 der Fa. Kamstrup erzielt (https://www.kamstrup.com/de-de/products-and-solutions/water-meters/residential-water-meter), welcher über Wireless M-Bus kommuniziert?

Laut Datenblatt sendet der Zähler im C-Mode welcher aktuell von der culfw nicht unterstützt wird.
Die bisherige Implementation von WMBus in der culfw basiert auf einer Application Note des Chipherstellers TI, und da ist der C-Mode nicht enthalten.

Ich habe in dem Datenblatt des Zählers keine Information dazu gefunden, ob er evtl. auf T-Mode umgestellt werden kann.
Falls das doch der Fall ist stehen die Chancen ganz gut, dass die Daten dekodiert werden können, da die Telegramme in der Spezifikation beschrieben sind.

[Mario67]

Vielen Dank für die schnelle Antwort. Hmmh, da werde ich wohl beim Hersteller etwas graben müssen. Es gibt möglicherweise auch noch die Option einen S0-Ausgang nachzurüsten, allerdings recht umständlich. Wenn ich mehr weiss, würde ich an dieser Stelle nochmal nachfragen.

Bis dann & Danke,
Mario

[tostmann]

culfw rev500+ beherrscht ab sofort auch das SENDEN von WMBus Telegrammen im T oder auch S Mode. Somit kann man nun auch bidirektionale Quellen ansprechen.

Syntax:

bss<data>  für S-mode
bst<data>  für T-mode

<data> entspricht dem was b<...> bisher zurück gab.

Der Speicher eines CUL V3 ist arg am Ende, sodass man nicht benötigte andere Protokolle abschalten sollte.

[Wuschi6]

Ich habe soweit meinen autocreate erhalten, allerdings mit Fehler?

Auszug aus der Log während des autocreate:

2015.04.09 18:48:34 3: WMBUS Unknown device b1044791681003210040243AF70F002FD170100AA00A0DA, please define it
2015.04.09 18:48:34 2: autocreate: define WMBUS_ESY_10320081_4_2 WMBUS b1044791681003210040243AF70F002FD170100AA00A0DA
2015.04.09 18:48:34 3: WMBUS_ESY_10320081_4_2: I/O device is nanoCUL
2015.04.09 18:48:34 2: autocreate: define FileLog_WMBUS_ESY_10320081_4_2 FileLog /opt/fhem/log/WMBUS_ESY_10320081_4_2-%Y.log WMBUS_ESY_10320081_4_2
2015.04.09 18:48:49 2: WMBUS WMBUS_ESY_10320081_4_2 Error during ApplicationLayer parse:Unsupported CI Field 70

Was kann das sein?

[kaihs]

In der OMS Spezifikation steht zum CI-Field 70:

CI-field	Direction	Header length	Application protocol
70h	Error from device	None	Generic (for wired M-Bus only!)

D.h. dieser Wert ist eigentlich nur für die kabelgebundene Protokollvariante M-Bus spezifiziert.
Daher ist unklar, was der Hersteller deines Zählers damit eigentlich überträgt, wahrscheinlich hat er das Protokoll missbraucht und überträgt da irgendwelche herstellerspezifischen Daten.
Das ist leider weit verbreitet, siehe auch die entsprechenden Anmerkungen im Wiki.

Du könntest beim Hersteller anfragen, ob der die Protokollbeschreibung zur Verfügung stellt, dann könnte ich das implementieren.
Die Hersteller sind aber i.A. sehr zugeknöpft.

Kai

[Wuschi6]

vielen Dank erstmal für die Info. Sehr schade. Soviel gebastelt und nun Sackgasse.
Na mal schauen, ob ich das etwas besorgen kann. Bin ja schliesslich im Energieversorgungsunternehmen tätig.
Hier schonmal die pdf des Easymeter M-Bus Modul:
http://www.easymeter.com/fileadmin/bilder/downloads/Wireless_M-Bus_Betriebsanleitung.pdf

[kaihs]

Dieser Abschnitt aus der Betriebsanleitung macht doch Hoffnung:

5.3.2 Datenausgabe
Zu den gesendeten Datensätzen ist ein separates Dokument erhältlich.

Wenn du das besorgen kannst können wir schauen, ob sich die Daten damit dekodieren lassen.