Wireless M-Bus für CUL

kaihs · 22 Januar 2019, 20:58:52

Bitte ein list von dem Device und ein paar rawmsg aus dem Log posten.

Dann kann ich die Fragen vielleicht beantworten.

kaihs · 24 Januar 2019, 20:09:32

Zitat von: fh168 am 22 Januar 2019, 18:57:09
Hallo,

ich habe die gleichen Wasseruhren.
bei mir dekodiert er aber nicht den Verbrauch.
2_value
3500821f8035865418f6df99fb2ac9a810e76ca7f5980c6ed3f16c3fc9e3cd5dadfee0255ef587847d0f5697ee8d99cc7e5607de4c360c7809464959

Was muss man tun?
Und was bedeutet die 81 im define?

LG
/robin

81 ist die Version des Zählers so wie dieser die mitteilt.

Code Auswählen


2019-01-22 18:31:11   2_storage_no    0
2019-01-22 18:31:11   2_type          MANUFACTURER SPECIFIC
2019-01-22 18:31:11   2_unit         
2019-01-22 18:31:11   2_value         3500829f8035ea7d26c9eff69517be6b54a60aee569778f0b9ea33d4c0b7d9f9b6dbfc9ea0376a4791b741732b892409eb3888786bfb0c7891521759

Das Reading 2_value enthält Daten die herstellerspezifisch sind und nicht dekodiert werden können (siehe Reading 2_type).
Um die zu dekodieren würde ich eine Dokumentation des Datenformats benötigen.

Evtl. hast du Glück und der Zähler sendet auch Daten in einem dekodierbaren Format.
Dann solltest du das Attribut ignoreUnknownDataBlocks setzen, damit diese nicht wieder von den nicht dekodierbaren überschrieben werden.

killah78 · 01 März 2019, 18:36:19

Hallo zusammen,
langsam wir es spannend hier.
Also zum Thema Letrika SM260 Modulwechselrichter.
Wie schon irgendwo beschrieben, antwortet der Wechselrichter nur auf "Anfrage".
Diese Anfrage ist aber wohl immer gleich und sollte sich doch auch durch den CUL senden lassen. Hat bei mir aber nicht funktioniert.
Im Anhang mal ein Log. Hier ist gut durch die RSSI zu erkennen, was was ist.
Ein RSSI um die 30 ist der Laptop mit dem Sun-Stick. Ein RSSI um die 55 ist der Wechselrichter.
Man erkennt, dass der Stick etwas sendet, dann sendet der Wechelrichter was, dann der Stick wieder und letztendlich der Wechelrichter wieder.
Das wiederholt sich dann alle 20 Sekunden (einstellbar).
Ab 17:35:48 habe ich den Wechelrichter ausgeschaltet, das ist dann wieder eine besondere Nachricht.
Vielleicht kann man daraus was machen, was die Anfrage über den CUL sendet. Wäre cool.
Weitere Tests sind kein Problem.
Gruss

kaihs · 03 März 2019, 14:40:07

Zitat
2019.03.01 17:09:37 2: WMBUS Error during LinkLayer parse:message too short, expected 107, got 63 bytes
2019.03.01 17:09:37 2: Please make sure that TTY_BUFSIZE in culfw is at least two times the message length + 1

Erhöhe mal wie in der Meldung angegeben die BUFSIZE damit die Antwort des Wechselrichters vollständig empfangen werden kann.

Zitat
2019.03.01 17:29:48 2: WMBUS WMBUS_LET_00006398_1_2 Error during ApplicationLayer parse:Unsupported CI Field 51, remaining payload is 0c7900000000

CI Field 51 bedeutet
51h CMD to device None M-Bus (for wired M-Bus only!)

Scheint also eigentlich nur für drahtgebundene Kommunikation vorgesehen zu sein.

Was passiert denn wenn du mit

Code Auswählen


set nanoCUL_WM raw bs135BB4B098630000010291C7510C790000000000FFA73CBF80

das selbe sendest wie der Sun-STICK?

killah78 · 05 März 2019, 13:33:01

Hmmh, habe einen nanoCUL mit a-cul.
Habe das set raw mal versucht, hat aber keine Reaktion gegeben.

Dann habe ich die Firmware aus Beitrag 664 geflashed, eben auch wegen der Buffersize.
Seit dem empfange ich garnichts mehr. Sprich Wasseruhr kommt auch nicht mehr an.
Auf ein get cconf oder ähnliches wird normal reagiert.
Wo liegt mein Fehler? Die normale CUL sollte doch genauso wie die a-cul den WMBUS empfange, oder nicht?
get version sagt: "V 1.67 nanoCUL433". Was das das File in #664 für einen 433?
Gruss

kaihs · 05 März 2019, 21:35:34

In der a-culfw auf github ist WMBUS für den nanoCUL komplett ausgeschaltet. Hast du eine selbst compilierte culfw?

WMBUS braucht sehr viel Speicher, insbesondere wenn auch gesendet werden soll. Daher macht es Sinn dafür einen dedizierten CUL zu haben in dem alle anderen Protokolle außer WMBUS ausgeschaltet sind.

Ich habe gerade nochmal eine culfw mit diesen Eigenschaften erstellt, probiere die mal.

killah78 · 06 März 2019, 11:14:55

Hi,
die angehangene hex empfängt leider nichts. Ich habe mir die a-cul jetzt mal neu kompiliert, habe alle Optionen ausser wmbus deaktiviert. Und den Buffer auf 220 gesetzt. Jetzt wird der 2. Teil des Letrika empfangen, allerdings mit der Meldung:

Code Auswählen

2019.03.06 11:05:10.397 2: WMBUS WMBUS_LET_00006398_1_2 Error during ApplicationLayer parse:in datablock 3: unexpected DIF_READOUT

Hier nochmal die gesamten zusammenhängenden Daten:

Code Auswählen

2019.03.06 11:05:10.103 5: CUL/RAW: /b105BB4B09
2019.03.06 11:05:10.119 5: CUL/RAW: b105BB4B09/86300000102DD72510C79000000007680801E
2019.03.06 11:05:10.120 4: CUL_Parse: nanoCUL868_WM b105BB4B0986300000102DD72510C79000000007680801E -59
2019.03.06 11:05:10.122 5: nanoCUL868_WM: dispatch b105BB4B0986300000102DD72510C7900000000768080::-59
2019.03.06 11:05:10.122 5: WMBUS raw msg b105BB4B0986300000102DD72510C7900000000768080::-59
2019.03.06 11:05:10.125 2: WMBUS WMBUS_LET_00006398_1_2 Error during ApplicationLayer parse:Unsupported CI Field 51, remaining payload is 0c7900000000

2019.03.06 11:05:10.151 5: CUL/RAW: /b2008B4B098630000010256847A
2019.03.06 11:05:10.167 5: CUL/RAW: b2008B4B098630000010256847A/00000000040319410900022B30000631F46D0C50448320288192800B
2019.03.06 11:05:10.167 4: CUL_Parse: nanoCUL868_WM b2008B4B098630000010256847A00000000040319410900022B30000631F46D0C50448320288192800B -68.5
2019.03.06 11:05:10.168 5: nanoCUL868_WM: dispatch b2008B4B098630000010256847A00000000040319410900022B30000631F46D0C5044832028819280::-68.5
2019.03.06 11:05:10.168 5: WMBUS raw msg b2008B4B098630000010256847A00000000040319410900022B30000631F46D0C5044832028819280::-68.5

2019.03.06 11:05:10.247 5: CUL/RAW: /b135BB4B098630000010291C7510C790000000000
2019.03.06 11:05:10.263 5: CUL/RAW: b135BB4B098630000010291C7510C790000000000/FFA73CBF801E
2019.03.06 11:05:10.263 4: CUL_Parse: nanoCUL868_WM b135BB4B098630000010291C7510C790000000000FFA73CBF801E -59
2019.03.06 11:05:10.264 5: nanoCUL868_WM: dispatch b135BB4B098630000010291C7510C790000000000FFA73CBF80::-59
2019.03.06 11:05:10.264 5: WMBUS raw msg b135BB4B098630000010291C7510C790000000000FFA73CBF80::-59
2019.03.06 11:05:10.266 2: WMBUS WMBUS_LET_00006398_1_2 Error during ApplicationLayer parse:Unsupported CI Field 51, remaining payload is 0c790000000000ffa7

2019.03.06 11:05:10.343 5: CUL/RAW: /b5C08B4B0986300000102DA227A00000000022B3200027C0
2019.03.06 11:05:10.359 5: CUL/RAW: b5C08B4B0986300000102DA227A00000000022B3200027C0/76968705FC83E736F63E80301FD6601027C0471657266246D8713017C0870
2019.03.06 11:05:10.390 5: CUL/RAW: b5C08B4B0986300000102DA227A00000000022B3200027C076968705FC83E736F63E80301FD6601027C0471657266246D8713017C0870/6D745F636463640F017CEFDF08706D745F636163640F027C0B746C6FE822765F63645F636573A40106FD670000006205000000FFFF800
2019.03.06 11:05:10.391 4: CUL_Parse: nanoCUL868_WM b5C08B4B0986300000102DA227A00000000022B3200027C076968705FC83E736F63E80301FD6601027C0471657266246D8713017C08706D745F636463640F017CEFDF08706D745F636163640F027C0B746C6FE822765F63645F636573A40106FD670000006205000000FFFF800
2019.03.06 11:05:10.392 5: nanoCUL868_WM: dispatch b5C08B4B0986300000102DA227A00000000022B3200027C076968705FC83E736F63E80301FD6601027C0471657266246D8713017C08706D745F636463640F017CEFDF08706D745F636163640F027C0B746C6FE822765F63645F636573A40106FD670000006205000000FFFF800
2019.03.06 11:05:10.393 5: WMBUS raw msg b5C08B4B0986300000102DA227A00000000022B3200027C076968705FC83E736F63E80301FD6601027C0471657266246D8713017C08706D745F636463640F017CEFDF08706D745F636163640F027C0B746C6FE822765F63645F636573A40106FD670000006205000000FFFF800
2019.03.06 11:05:10.397 2: WMBUS WMBUS_LET_00006398_1_2 Error during ApplicationLayer parse:in datablock 3: unexpected DIF_READOUT

Edit: So, jetzt habe ich die normale culfw mal kompiliert und läuft. Aber auch damit kommt auf das senden der Rawmessage leider keine Reaktion.

PeMue · 06 März 2019, 13:54:31

Hallo,

Zitat von: killah78 am 06 März 2019, 11:14:55
Edit: So, jetzt habe ich die normale culfw mal kompiliert und läuft. Aber auch damit kommt auf das senden der Rawmessage leider keine Reaktion.

könntest Du die hex noch anhängen? Vielleicht bringt sie dem einen oder anderen was.

Danke + Gruß

PeMue

killah78 · 06 März 2019, 14:33:41

Zitat von: PeMue am 06 März 2019, 13:54:31
könntest Du die hex noch anhängen?

Hi, klar. Hier die culfw 1.67 für 868Mhz mit aktiviertem WMBUS, sonstiges deaktiviert, Buffer 220

Gruss

kaihs · 06 März 2019, 19:58:15

Zitat von: killah78 am 06 März 2019, 11:14:55
2019.03.06 11:05:10.397 2: WMBUS WMBUS_LET_00006398_1_2 Error during ApplicationLayer parse:in datablock 3: unexpected DIF_READOUT

Probiere es mal mit der angehängten Version.

Da kommen bei mir damit jetzt diese Werte raus:

Code Auswählen


Manufacturer b0b4 LET
IdentNumber 00006398
Version 1
Type 2 Electricity
IsEncrypted 0
Status: 0 no errors
1. StorageNo 0 Instantaneous value VIF_ELECTRIC_POWER 50 W
2. StorageNo 0 Instantaneous value see unit 1000 ihp_soc
3. StorageNo 0 Instantaneous value VIF_STATE_PARAMETER_ACTIVATION 1 
4. StorageNo 0 Instantaneous value see unit 4999 qerf
5. StorageNo 0 Instantaneous value see unit 15 pmt_cdcd
6. StorageNo 0 Instantaneous value see unit 15 pmt_cacd
7. StorageNo 0 Instantaneous value see unit 420 tlov_cd_ces
8. StorageNo 0 Instantaneous value VIF_SPECIAL_SUPPLIER_INFORMATION 0

Kannst du verifizieren, dass die Werte plausibel sind?

killah78 · 06 März 2019, 21:23:09

Hi, sieht gut aus. Werte kommen an und werden interpretiert:

Code Auswählen

2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 RSSI: -54
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 LQI: 128
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 Unsupported CI Field 51, remaining payload is 0c7900000000
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 RSSI: -61.5
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 LQI: 128
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 1_storage_no: 0
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 1_type: VIF_ENERGY_WATT
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 1_value: 606753
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 1_unit: Wh
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 1_value_type: Instantaneous value
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 2_storage_no: 0
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 2_type: VIF_ELECTRIC_POWER
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 2_value: 0
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 2_unit: W
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 2_value_type: Instantaneous value
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 3_storage_no: 0
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 3_type: VIF_TIME_POINT_DATE_TIME
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 3_value: 2000-00-00 00:00 
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 3_unit: 
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 3_value_type: Instantaneous value
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 batteryState: ok
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 is_encrypted: 0
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 decryption_ok: 1
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 no errors
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 rawmsg: 2008b4b098630000010256847a00000000040321420900022b000006fa516d0c504483202881928019
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 RSSI: -54
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 LQI: 128
2019-03-06_21:12:13 WMBUS_LET_00006398_1_2 Unsupported CI Field 51, remaining payload is 0c790000000000ffa7
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 RSSI: -66
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 LQI: 128
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 1_storage_no: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 1_type: VIF_ELECTRIC_POWER
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 1_value: 50
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 1_unit: W
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 1_value_type: Instantaneous value
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 2_storage_no: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 2_type: see unit
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 2_value: 1000
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 2_unit: ihp_soc
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 2_value_type: Instantaneous value
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 3_storage_no: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 3_type: VIF_STATE_PARAMETER_ACTIVATION
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 3_value: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 3_unit: 
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 3_value_type: Instantaneous value
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 4_storage_no: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 4_type: see unit
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 4_value: 4998
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 4_unit: qerf
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 4_value_type: Instantaneous value
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 5_storage_no: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 5_type: see unit
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 5_value: 11
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 5_unit: pmt_cdcd
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 5_value_type: Instantaneous value
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 6_storage_no: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 6_type: see unit
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 6_value: 12
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 6_unit: pmt_cacd
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 6_value_type: Instantaneous value
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 7_storage_no: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 7_type: see unit
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 7_value: 14
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 7_unit: tlov_cd_ces
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 7_value_type: Instantaneous value
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 8_storage_no: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 8_type: VIF_SPECIAL_SUPPLIER_INFORMATION
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 8_value: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 8_unit: 
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 8_value_type: Instantaneous value
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 batteryState: ok
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 is_encrypted: 0
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 decryption_ok: 1
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 no errors
2019-03-06_21:12:14 WMBUS_LET_00006398_1_2 rawmsg: 5c08b4b0986300000102da227a00000000022b3200027c076968705fc83e736f63e80301fd6600027c0471657266a9998613017c08706d745f636463640b017c0e3408706d745f636163640c027c0b746c6fc306765f63645f6365730e0006fd6700000076f1000000ffff8010

Allerdings gibt es folgendes Problem: Es gibt ja zwei Datentelegramme. Das erste beinhaltet die aktuelle Leistung in Watt und die bisher abgegebene Strommenge in Wh. Das zweite Datentelegramm enthält dann die einstellbare abzugebende Leistung in W und ein ein/aus Schalter. Die anderen Daten müssten eine Art Fehlerlog/Alarm beinhalten, der bei mir aber leer bzw Null ist. Leider ist das Problem, dass die zweite Nachricht, die erste überschreibt. Unglücklicherweise heissen die typen sogar gleich (VIF_ELECTRIC_POWER).
KAnn man das irgendwie separieren?
Hier noch ein Listing:

Code Auswählen

Internals:
   DEF        LET 00006398 1 2
   DeviceMedium Electricity
   DeviceType 2
   FUUID      5c7a87c0-f33f-86d0-2a8f-1477677272313525
   IODev      nanoCUL868_WM
   IdentNumber 00006398
   LASTInputDev nanoCUL868_WM
   MSGCNT     660
   Manufacturer LET
   MessageEncoding CUL
   NAME       WMBUS_LET_00006398_1_2
   NR         740
   STATE      no errors
   TYPE       WMBUS
   Version    1
   addr       LET_00006398_1_2
   model      LET_2_1
   nanoCUL868_WM_MSGCNT 660
   nanoCUL868_WM_RAWMSG b5C08B4B0986300000102DA227A00000000022B3200027C076968705FC83E736F63E80301FD6600027C0471657266A9998513017C08706D745F636463640B017C5F0008706D745F636163640C027C0B746C6FC306765F63645F6365730E0006FD6700000076F1000000FFFF801
   nanoCUL868_WM_RSSI -52
   nanoCUL868_WM_TIME 2019-03-06 21:20:22
   READINGS:
     2019-03-06 21:20:22   1_storage_no    0
     2019-03-06 21:20:22   1_type          VIF_ELECTRIC_POWER
     2019-03-06 21:20:22   1_unit          W
     2019-03-06 21:20:22   1_value         50
     2019-03-06 21:20:22   1_value_type    Instantaneous value
     2019-03-06 21:20:22   2_storage_no    0
     2019-03-06 21:20:22   2_type          see unit
     2019-03-06 21:20:22   2_unit          ihp_soc
     2019-03-06 21:20:22   2_value         1000
     2019-03-06 21:20:22   2_value_type    Instantaneous value
     2019-03-06 21:20:22   3_storage_no    0
     2019-03-06 21:20:22   3_type          VIF_STATE_PARAMETER_ACTIVATION
     2019-03-06 21:20:22   3_unit          
     2019-03-06 21:20:22   3_value         0
     2019-03-06 21:20:22   3_value_type    Instantaneous value
     2019-03-06 21:20:22   4_storage_no    0
     2019-03-06 21:20:22   4_type          see unit
     2019-03-06 21:20:22   4_unit          qerf
     2019-03-06 21:20:22   4_value         4997
     2019-03-06 21:20:22   4_value_type    Instantaneous value
     2019-03-06 21:20:22   5_storage_no    0
     2019-03-06 21:20:22   5_type          see unit
     2019-03-06 21:20:22   5_unit          pmt_cdcd
     2019-03-06 21:20:22   5_value         11
     2019-03-06 21:20:22   5_value_type    Instantaneous value
     2019-03-06 21:20:22   6_storage_no    0
     2019-03-06 21:20:22   6_type          see unit
     2019-03-06 21:20:22   6_unit          pmt_cacd
     2019-03-06 21:20:22   6_value         12
     2019-03-06 21:20:22   6_value_type    Instantaneous value
     2019-03-06 21:20:22   7_storage_no    0
     2019-03-06 21:20:22   7_type          see unit
     2019-03-06 21:20:22   7_unit          tlov_cd_ces
     2019-03-06 21:20:22   7_value         14
     2019-03-06 21:20:22   7_value_type    Instantaneous value
     2019-03-06 21:20:22   8_storage_no    0
     2019-03-06 21:20:22   8_type          VIF_SPECIAL_SUPPLIER_INFORMATION
     2019-03-06 21:20:22   8_unit          
     2019-03-06 21:20:22   8_value         0
     2019-03-06 21:20:22   8_value_type    Instantaneous value
     2019-03-06 21:20:22   LQI             128
     2019-03-06 21:20:22   RSSI            -66
     2019-03-06 21:20:22   batteryState    ok
     2019-03-06 21:20:22   decryption_ok   1
     2019-03-06 21:20:22   is_encrypted    0
     2019-03-06 21:20:22   rawmsg          5c08b4b0986300000102da227a00000000022b3200027c076968705fc83e736f63e80301fd6600027c0471657266a9998513017c08706d745f636463640b017c5f0008706d745f636163640c027c0b746c6fc306765f63645f6365730e0006fd6700000076f1000000ffff8010
     2019-03-06 21:20:22   state           no errors
Attributes:
   IODev      nanoCUL868_WM
   rawmsg_as_reading 1
   room       WMBUS

Siehst du auch irgendwie die Möglichkeit, diesen "Starting Payload" über den CUL zu senden um das Senden des Wechselrichters "anzustossen"?

Danke und Gruss

kaihs · 06 März 2019, 21:59:00

Aktuell finde ich keine Möglichkeit die unterschiedlichen Telegrammarten zu unterscheiden.
Es gibt zwar so etwas im Standard (access no) aber die ist immer 0.

Es müsste wohl zusätzlich das gesendete Telegramm ausgewertet werden um die Antwort zuordnen zu können.

Da muss ich mich noch tiefer mit auseinandersetzen um mglw. eine Lösung zu finden.

Senden habe ich selbst noch nie ausprobiert, ich weiß daher nicht, ob das in der culfw überhaupt richtig funktioniert. Dazu müsste ich erst mal einen separaten Sender und Empfänger haben.

kaihs · 10 März 2019, 13:53:35

Ich habe den aktuellen Stand gerade eingecheckt.

Es werden jetzt auch die Nachrichten die von dem Stick an den Wechselrichter gesendet werden ohne Fehler verarbeitet. Diese Nachrichten werden aber normalerweise vom Modul ignoriert es sei denn das Attribute ignoreMasterMessages wird explizit auf 0 gesetzt.

Der Inhalt dieser Nachrichten ist aktuell nicht sonderlich hilfreich:

Code Auswählen


Manufacturer b0b4 LET
IdentNumber 00006398
Version 1
Type 2 Electricity
IsEncrypted 0
Status: 0 no errors
1. StorageNo 0 Instantaneous value VIF_OWNER_NO 0 
2. StorageNo 0 Instantaneous value MANUFACTURER SPECIFIC

Bei der einen Nachricht fehlt der MANUFACTURER SPECIFIC Teil.

kaihs · 10 März 2019, 15:44:18

Zitat von: killah78 am 06 März 2019, 21:23:09
Siehst du auch irgendwie die Möglichkeit, diesen "Starting Payload" über den CUL zu senden um das Senden des Wechselrichters "anzustossen"?

Ich habe gerade mal Senden und Empfangen getestet.
Es geht, wenn man es richtig macht

1. In der culfw muss HAS_MBUS definiert sein und MBUS_NO_TX darf nicht defriniert sein.
2. Das korrekte Kommando zum senden lautet bss oder bst zum Senden per S-Mode/T-Mode

Also z. B.

Code Auswählen


set nanoCUL868_WM raw bss105BB4B0986300000102DD72510C7900000000768080

für's Senden im S-Mode.

Auf welchen rfmode ist dein nanoCUL868_WM eingestellt?

killah78 · 10 März 2019, 16:26:34

Danke kaihs, das ist super!!!! Funktioniert!!
Ich hatte das Senden immer mit bs gestartet, aber mit bss funktioniert es.
So kann jetzt nach Bedarf der Zustand des Wechselrichters abgefragt werden.
Ich werde mal noch weitere Tests machen, ob das Einstellen der abzugebenden Leistung und Ein/Aus auch funktioniert. Aber da gehe ich von aus.
Jetzt bleibt noch das Problem der überschreibenden Readings, dann ist es Pefekt.
Danke für deine Mühe und deinen Support.