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!
Hi Tom,
willkommen im Forum. Bitte "listings" zur besseren Lesbarkeit in Code-Tags(das # Zeichen) packen.
Ein Problem, welches vermutlich keins ist:
Zitat2017.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 :o
Zitat2017-06-01 17:25:15 state Initialized
Das sieht aber OK aus.
Nun zu Deinem eigentlichen Problem:
ZitatCMDS ABCEeFfGhiKklMmRTtUVWXxYZz
Hier fehlt das "b" für WMBUS ! Das liegt an der geflashten firmware:
2017-06-01 17:27:32 version V 1.67 nanoCUL868Aus "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
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:
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:
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!
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
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?
Das ist irgendwas anderes. Auf dem Band ist ja viel los. Die Hkv sind in der commandref gut beschrieben
Vg
Jörg
Zitat von: Tom S am 21 Juni 2017, 22:46:45
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
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
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