Bekomme CUL mit WM-Bus_T nicht ans Laufen

[Tom S]

Hallo Community,
ich brauche da mal einen Tipp: ich habe einen CUL am Raspberry, der auch soweit einwandfrei läuft außer:

ich kann leider das attr RFMode WMBus_T nicht aktivieren, welches ich für das Auslesen von TechemHKV's brauche. Das Ergebnis: CUL868: Mode WMBus_T not supported

Der CUL selbst sieht wie folgt aus:

Internals:
   CMDS       ABCEeFfGhiKklMmRTtUVWXxYZz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400
   FD         10
   FHTID      0000
   NAME       CUL868
   NR         20
   PARTIAL
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL868
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s][A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
   Readings:
     2017-06-01 17:28:12   ccconf          freq:868.900MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2017-06-01 17:25:15   cmds             A B C E e F f G h i K k l M m R T t U V W X x Y Z z
     2017-05-27 13:44:06   fhtbuf          AE
     2017-06-01 16:39:54   raw             V 1.67 nanoCUL868
     2017-06-01 17:25:15   state           Initialized
     2017-06-01 16:48:27   uptime          0 00:32:25
     2017-06-01 17:27:32   version         V 1.67 nanoCUL868
Attributes:
   model      CUL
   room       Heizkostenverteiler
   verbose    5

Im Log steht:

2017.06.01 16:15:58 5: SW: V
2017.06.01 16:16:01 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0 disconnected, waiting to reappear (CUL868)
2017.06.01 16:16:01 3: Setting CUL868 serial parameters to 38400,8,N,1
2017.06.01 16:16:01 5: SW: V
2017.06.01 16:16:04 5: SW: V
2017.06.01 16:16:04 5: CUL/RAW (ReadAnswer): V 1.67 nanoCUL868

Ich habe bereits den Hersteller befragt; dieser meint, M-Bus T müsste laufen.
Hat jemand eine Idee, was hier nicht stimmen könnte.

Dank im Voraus!

[KölnSolar]

Hi Tom,
willkommen im Forum. Bitte "listings" zur besseren Lesbarkeit in Code-Tags(das # Zeichen) packen.

Ein Problem, welches vermutlich keins ist:

2017.06.01 16:16:01 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0 disconnected, waiting to reappear (CUL868)

Zu diesem Zeitpunkt war der CUL ja gar nicht aktiv 

2017-06-01 17:25:15   state           Initialized

Das sieht aber OK aus.

Nun zu Deinem eigentlichen Problem:

CMDS       ABCEeFfGhiKklMmRTtUVWXxYZz

Hier fehlt das "b" für WMBUS ! Das liegt an der geflashten firmware:

Code Auswählen Erweitern

2017-06-01 17:27:32   version         V 1.67 nanoCUL868
Aus "Platzgründen" ist das WMBUS-Protokoll beim nanoCUL nicht aktiv. Du müsstest Dir die culfw selber kompilieren. In der board.h HAS_MBUS aktivieren und andere Protokolle deaktivieren.

Grüße Markus

[Tom S]

Hallo zusammen,
nach viel Lesen und nanoCul neu flashen versteht er jetzt den WM-BUS_T. Soweit gut.

autocreate hat daraufhin einen WM-Bus Teilnehmer erkannt und wie folgt angelegt:

Code Auswählen Erweitern

DEF TCH 70816095 105 128
DeviceMedium unknown
DeviceType 128
IODev nanoCUL
IdentNumber 70816095
Manufacturer TCH
MessageEncoding CUL
NAME WMBUS_TCH_70816095_105_128
NR 21
STATE Unsupported CI Field a0, remaining payload is 019f210000b02c000081098c09000000000000000000000000000000000000000000000000000000
TYPE WMBUS
Version 105
addr TCH_70816095_105_128

Das Ergebnis im Logfile ist wie folgt:

Code Auswählen Erweitern

2017.06.15 22:41:12 5: WMBUS raw msg b7644210461014071550825B67261014071210455080800600516E682E56266667DDB0856C14A585B3F7616B6369A94AE892BDF2F77B4E55F2B77FD01815D9
2017.06.15 22:41:12 2: WMBUS Error during LinkLayer parse:message too short, expected 135, got 63 bytes
2017.06.15 22:41:12 3: nanoCUL: Unknown code b7644210461014071550825B67261014071210455080800600516E682E56266667DDB0856C14A585B3F7616B6369A94AE892BDF2F77B4E55F2B77FD01815D9

Und da weiß ich nicht mehr weiter. Warum erwartet der WMBUS 135 Byte und bekommt nur 63? Ist der device-Typ falsch? Es handelt sich um einen Heizkostenverteiler von Techem

Hat jemand einen Tipp? Danke im Voraus!

[herrmannj]

die techem module werden nicht per autocreate angelegt sondern werden manuell angelegt. Das was der cul da in Deinem Beispiel empfängt sieht aber nicht nach techem aus.

vg
joerg

[Tom S]

Danke Joerg, für die schnelle Reaktion.
Eine Idee, was das sein könnte? Es meldet sich laut log alle 5 Minuten.
Kannst du mir evtl. eine Konfiguration für einen HKV zukommen lassen?

[herrmannj]

Das ist irgendwas anderes. Auf dem Band ist ja viel los. Die Hkv sind in der commandref gut beschrieben

Vg
Jörg

[kaihs]

Und da weiß ich nicht mehr weiter. Warum erwartet der WMBUS 135 Byte und bekommt nur 63? Ist der device-Typ falsch? Es handelt sich um einen Heizkostenverteiler von Techem

Hat jemand einen Tipp? Danke im Voraus!

Das liegt wahrscheinlich an einem zu kleinen Empfangspuffer in der culfw.
Ist in der board.h definiert, ich weiß aus dem Kopf nicht das genaue define.
Der muss so groß sein, dass das komplette Telegramm reinpasst, sonst wird das einfach von der culfw abgeschnitten.
Das stellt dann erst das WMBUS Modul fest.
Es wird die Daten aber auch danach nicht dekodieren können, da die Daten ein nicht dokumentiertes CI Feld enthalten.



Gesendet von meinem SM-G935F mit Tapatalk

[Tom S]

Hallo kaihs,
Ich habe die FW umgeflasht und den Puffer vergrößert; der Fehler ist nun weg.
Sinnvolle Daten kommen tatsächlich immer noch nicht, selbst nicht von einem HKV der Fa. Innotas Elektronik, den ich mir jetzt extra zum Testen besorgt habe.
Ich bin langsam frustriert vom WMBUS-Modul.

Gibt es noch einen Ansatz, den man testen könnte?
Grüße, Tom S

[herrmannj]

Oben stand das es techem hkv sind. Wenn deren sendefunktion aktiviert ist dann solltest du die mit dem techem Modul empfangen können. Das wmbus Modul kann da nichts mit anfangen weil die techem Module sich nicht an den Standard halten sondern was ganz eigenes senden

Vg
Jörg