unknown argument on/off (gelöst)

[uron]

Hallo,
ich weiß nicht, ob es Sinn macht ein Thema neu zu starten, was ich in ähnlicher Form schon einmal hatte https://forum.fhem.de/index.php/topic,89538.0.html (ftp://forum.fhem.de/index.php/topic,89538.0.html) und es auch gelöst bekam, nun aber bei einem anderen Device diese Lösung (erneutes Pairen) nicht greift - egal ich mache ein neues Thema auf:
Heute morgen wollte ich einen Funk-Schaltaktor (HM-LC-Sw1-FM) in mein System einbinden. Das klappte soweit beim Pairen auch gut (fast, da PairedTo = 0xF10000), mit getConfig habe einige Readings bekommen, stelle aber fest, wenn ich 'on', 'off' oder z.B. 'StatusRequest' im WebUI mit 'set' aufrufe, dass diese oder ähnliche Feldermeldungen kommen:

Code Auswählen Erweitern

Unknown argument on, choose one of clear:readings,rssi,msgEvents,unknownDev clear:readings,trigger,register,oldRegs,rssi,msgEvents,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet virtual:slider,1,1,50. Diese Fehlermeldung findet man häufig im Forum, aber nichts passt zum meinem Problem, bzw. löst selbiges.
Zunächst einmal das list des Device:

Code Auswählen Erweitern

Internals:
   CUL_HM_MSGCNT 18
   CUL_HM_RAWMSG A0C7FA010612B10F10000030000::-58.5:CUL_HM
   CUL_HM_RSSI -58.5
   CUL_HM_TIME 2018-09-29 16:30:57
   DEF        612B10
   IODev      CUL_HM
   LASTInputDev CUL_HM
   MSGCNT     18
   NAME       Einfahrt_Licht
   NOTIFYDEV  global
   NR         189
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:7F - t:10 s:612B10 d:F10000 030000
   protLastRcv 2018-09-29 16:30:57
   protRcv    18 last_at:2018-09-29 16:30:57
   protSnd    27 last_at:2018-09-29 16:30:57
   protState  CMDs_done
   rssi_at_CUL_HM cnt:18 min:-58.5 max:-57 avg:-57.3 lst:-58.5
   READINGS:
     2018-09-29 16:30:57   PairedTo        0xF10000
     2018-09-29 16:23:47   R-pairCentral   0xF10000
     2018-09-29 16:30:57   RegL_00.          02:01 0A:F1 0B:00 0C:00 15:FF 18:00 00:00
   helper:
     HM_CMDNR   127
     cSnd       01F10000612B1000040000000000,01F10000612B1000040000000000
     mId       
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +612B10,00,00,00
       nextSend   1538231457.32668
       prefIO     
       rxt        0
       vccu       
       p:
         612B10
         00
         00
         00
     mRssi:
       mNo        7F
       io:
         CUL_HM:
           -52.5
           -52.5
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL_HM
       flg        A
       ts         1538231457.22791
       ack:
         HASH(0x32af898)
         7F8002F10000612B1000
     rssi:
       at_CUL_HM:
         avg        -57.3055555555556
         cnt        18
         lst        -58.5
         max        -57
         min        -58.5
     shadowReg:
     tmpl:
Attributes:
   IODev      CUL_HM
   autoReadReg 4_reqStatus
   expert     2_raw
   icon       on
   room       HM-Devices,Favourites,Einfahrt
   serialNr   LPNHE25860
   webCmd     statusRequest:on:off
Dann das define aus der fhem.cfg:

Code Auswählen Erweitern

define Einfahrt_Licht CUL_HM 612B10
attr Einfahrt_Licht IODev CUL_HM
attr Einfahrt_Licht icon on
attr Einfahrt_Licht room HM-Devices,Favourites,Einfahrt
attr Einfahrt_Licht webCmd statusRequest:on:off
Interessanterweise bekam ich über getConfig keine SN oder das Modell.
Mit

Code Auswählen Erweitern

get Einfahrt_Licht model bekomme ich die Fehlermeldung

Code Auswählen Erweitern

Unknown argument model, choose one of cmdList param reg regList regTable regVal saveConfig
Im Nachgang habe ich die Angabe auf dem Karton als Attribute gesetzt. Die dort angegebene SN (LPNHE25860) ist über die originale SN geklebt und entspricht nicht den üblichen Konventionen.
Ich verstehe einfach nicht, warum ich Readings vom Devie bekommen aber z.B. keine StatusRequest-Info!
Ich vermute mal, dass es ein Rückläufer war, dessen SN geändert wurde (war als 'gebraucht' bei Amazon gekennzeichnet).
Noch ein paar Hinweise, die in anderen Posts bereits besprochen wurden, aber noch nicht beseitigt sind:
Ja, mein CUL für Homematic heißt immer noch CUL_HM und ist mit 'Timestamp Firmware' auch noch nicht geflasht - ich tue mich mit der Umsetzung noch schwer.

So, aber nun nochmals zu meinem Problem was ich direkt am Device vermute, da er die als Attribut gesetzten WebCmd nicht erkennt:
Habt ihr eine neue Idee für mich?

[frank]

es fehlen wichtige attribute: model, subType, ...
ist autocreate aktiv?
einfach nochmal drüber pairen.

[LuckyDay]

er scheint gepairt zu sein, aber ohne attr <> model und subtyp weiß ja cul_hm nicht was das Device sein soll.

du kannst mal

Code Auswählen Erweitern

attr Einfahrt_Licht subType switch
attr Einfahrt_Licht model HM-LC-SW1-FM
von Hand setzen
dann sollte auch on off funktioniern.

sniffe mal die Anlernmessage von deinem Actor, die fängt so ähnlich an A1A028400..... die wäre interresant !
um dem Thema deines Problems auf die Spur zu kommen

wie man snifft findest im Wiki

[uron]

Das Setzen der Attribute war ein Volltreffer!!! 
Das mit dem Sniffen mach ich spätestens in den nächsten Tagen - jetzt erst einmal durchatmen - sitze bestimmt schon mind. 4 Stunden an diesem "blöden" Thema.
Ich melde mich, wenn Ergebnisse vorliegen.

Danke erst einmal!

[uron]

Habe den Pairvorgang nach manuellem Setzen der SN und des Modell wie folgt vorgenommen:

Code Auswählen Erweitern

set CUL_HM hmPairSerial LPNHE25860
Beim Sniffen  kam dann  folgendes heraus:

Code Auswählen Erweitern

2018.09.29 23:26:32.865 4: CUL_Parse: CUL_HM A 16 14 A010 612B10 F10000 0202010AF10B000C0015FF180014 -64
2018.09.29 23:26:33.176 4: CUL_Parse: CUL_HM A 0C 15 A010 612B10 F10000 03000014 -64
2018.09.29 23:26:33.473 4: CUL_Parse: CUL_HM A 0C 16 A010 612B10 F10000 03080014 -64
2018.09.29 23:26:33.749 4: CUL_Parse: CUL_HM A 10 17 A010 612B10 F10000 0230065724560017 -62.5
2018.09.29 23:26:34.020 4: CUL_Parse: CUL_HM A 0C 18 A010 612B10 F10000 03000014 -64
2018.09.29 23:26:34.320 4: CUL_Parse: CUL_HM A 0E 19 A010 612B10 F10000 010000000014 -64
Das sagt mir natürlich gar nichts!

[martinp876]

Bei pairserial sollte die cul eine pairing aufforderung schicken. Die sehe ich nicht. Hast du etwas abgeschnitten?
Model setzt man nicht selbst. Einmal config am device auslösen und fhem trägt alles ein.

[uron]

Habe nichts abgeschnitten.
Das erstmalige Auslösen des Pairingvorgangs für ein mittlerweile verdeckt verbautes Device geht m.W. nur mit SN.
Diese SN, sowie das Modell hat mir das Device aber nicht zurückgegeben als ich (auch mehrfach)

Code Auswählen Erweitern

set Einfahrt_Licht getConfig ausgelöst habe. Da blieb mir nur das manuelle Setzen von Modell und SN - oder siehst du einen anderen Weg?

Hab aber trotzdem gerade nochmals das Pairing mit der gegebenen SN ausgelöst und erhalte folgendes Sniffingergebnis:

Code Auswählen Erweitern

2018.09.30 11:55:11.323 4: CUL_Parse: CUL_HM A 0D 50 8441 5B4EE7 000000 014DF880F4 -80
2018.09.30 11:56:32.934 4: CUL_Parse: CUL_HM A 0D 39 A641 5B5158 F10000 015CFE80DD -91.5
2018.09.30 11:56:35.828 4: CUL_Parse: CUL_HM A 0D B5 A641 5B4EEC F10000 01B3FE80E8 -86
2018.09.30 11:59:46.435 4: CUL_Parse: CUL_HM A 0D 51 8441 5B4EE7 000000 014EFE80F6 -79
2018.09.30 12:00:08.538 4: CUL_Parse: CUL_HM A 16 2A A010 612B10 F10000 0202010AF10B000C0015FF18001F -58.5
2018.09.30 12:00:08.809 4: CUL_Parse: CUL_HM A 0C 2B A010 612B10 F10000 0300001F -58.5
2018.09.30 12:00:09.106 4: CUL_Parse: CUL_HM A 0C 2C A010 612B10 F10000 0308001F -58.5
2018.09.30 12:00:09.382 4: CUL_Parse: CUL_HM A 10 2D A010 612B10 F10000 023006572456001F -58.5
2018.09.30 12:00:09.653 4: CUL_Parse: CUL_HM A 0C 2E A010 612B10 F10000 0300001E -59
2018.09.30 12:00:09.953 4: CUL_Parse: CUL_HM A 0E 2F A010 612B10 F10000 01000000001E -59
2018.09.30 12:02:22.719 4: CUL_Parse: CUL_HM A 0D 3A A641 5B5158 F10000 015DFE80DD -91.5
2018.09.30 12:02:29.563 4: CUL_Parse: CUL_HM A 0D B6 A641 5B4EEC F10000 01B4FE80E7 -86.5

[frank]

SN, model und fw gibt es nie über getConfig, sondern nur über die anlernmessage vom device.
die anlernmessage ist aber weiterhin nicht im sniff zu sehen.

pairen über hmPairForSec funktioniert grundsätzlich bei allen devices. allerdings muss immer irgend ein knöpfchen gedrückt werden. beim sw1-fm ist es der externe taster, der am "s"- eingang angeschlossen wird. aber nur für eine gewisse zeit nach einschalten der versorgungsspannung, siehe anleitung.

[uron]

Das Pairen habe ich ursprünglich natürlich gem. Anleitung gemacht, in dem ich kurz über den Taster S1 Spannung verbunden habe.
Nachdem das Blinken erloschen ist, ging ich von einem vollständigen Anlernprozess aus.
Ich kann es ja nochmals wiederholen, muss dazu den Schaltaktor allerdings wieder freilegen, da er im Moment hinter einem Lichtschalter verbaut ist.
Ich berichte zu gegebener Zeit.

[uron]

So, am heutigen Feiertag habe ich mich nochmals daran gemacht, den Funkschalter erneut zu Pairen - er war wie beschrieben hinter einem Lichtschalter verbaut.
Den Pairingprozess habe ich nun mit

Code Auswählen Erweitern

set CUL_HM hmPairForSec 120 eingeleitet und am Device über den Taster kurzzeitig Spannung auf S1 gegeben.
Nach zweimaligem Blinken erlosch die LED und ich bekomme nun folgendes List:

Code Auswählen Erweitern

Internals:
   CUL_HM_MSGCNT 10
   CUL_HM_RAWMSG A0E53A010612B10F100000100000000::-66:CUL_HM
   CUL_HM_RSSI -66
   CUL_HM_TIME 2018-10-03 12:20:26
   DEF        612B10
   IODev      CUL_HM
   LASTInputDev CUL_HM
   MSGCNT     10
   NAME       Einfahrt_Licht
   NOTIFYDEV  global
   NR         194
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:53 - t:10 s:612B10 d:F10000 0100000000
   protLastRcv 2018-10-03 12:20:26
   protRcv    10 last_at:2018-10-03 12:20:26
   protSnd    12 last_at:2018-10-03 12:20:26
   protState  CMDs_done
   rssi_at_CUL_HM cnt:10 min:-69 max:-65.5 avg:-67.25 lst:-66
   READINGS:
     2018-10-03 12:15:57   CommandAccepted yes
     2018-10-03 12:15:56   D-firmware      2.8
     2018-10-03 12:15:56   D-serialNr      OEQ1548857
     2018-10-03 12:20:25   PairedTo        0xF10000
     2018-10-03 12:20:25   R-pairCentral   0xF10000
     2018-09-29 23:26:34   R-powerUpAction off
     2018-09-29 23:26:34   R-sign          off
     2018-10-03 12:20:25   RegL_00.          02:01 0A:F1 0B:00 0C:00 15:FF 18:00 00:00
     2018-10-03 12:20:25   RegL_01.         08:00  30:06 57:24 56:00 00:00
     2018-10-03 06:57:09   deviceMsg       off (to CUL_HM)
     2018-10-03 06:57:09   level           0
     2018-10-03 06:57:09   pct             0
     2018-10-03 06:57:09   recentStateType ack
     2018-10-03 06:57:09   state           off
     2018-10-03 06:57:09   timedOn         off
   helper:
     HM_CMDNR   83
     cSnd       01F10000612B1001040000000001,01F10000612B100103
     mId        0004
     peerIDsRaw ,00000000
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +612B10,00,00,00
       nextSend   1538562026.35735
       prefIO     
       rxt        0
       vccu       
       p:
         612B10
         00
         00
         00
     mRssi:
       mNo        53
       io:
         CUL_HM:
           -62
           -62
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   00
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL_HM
       flg        A
       ts         1538562026.25855
       ack:
         HASH(0x25f5660)
         538002F10000612B1000
     rssi:
       at_CUL_HM:
         avg        -67.25
         cnt        10
         lst        -66
         max        -65.5
         min        -69
     shadowReg:
     tmpl:
Attributes:
   IODev      CUL_HM
   alias      Licht Einfahrt
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.8
   icon       on
   model      HM-LC-SW1-FM
   peerIDs    00000000,
   room       HM-Devices,Favourites,Einfahrt
   serialNr   OEQ1548857
   subType    switch
   webCmd     statusRequest:on:off
Interessanterweise wurde nun das Modell und die alte SN eingetragen, die auf der Verpackung überklebt war!?! Die alten Attribute hatte ich vor dem Pairen aus dem Device gelöscht.
Ist der Pairingvorgang nun abgeschlossen? Mir wurde in einem vorherigen Thrad mitgeteilt, dass das '0x' im Reading

Code Auswählen Erweitern

PairedTo        0xF10000 auf einen nicht abgeschlossenen Vorgang hinweist.

Durch das Sniffen habe ich im Logfile nun folgende Einträge:

Code Auswählen Erweitern

2018.10.03 12:14:25.909 4: CUL_Parse: CUL_HM A 0D D5 A641 5B5158 F10000 01F8FE80F0 -82
2018.10.03 12:15:56.884 4: CUL_Parse: CUL_HM A 1A 23 8400 612B10 000000 2800044F455131353438383537100101000A -69
2018.10.03 12:15:57.157 4: CUL_Parse: CUL_HM A 0A 4B 8002 612B10 F10000 000A -69
2018.10.03 12:15:57.430 4: CUL_Parse: CUL_HM A 0A 4C 8002 612B10 F10000 000A -69
2018.10.03 12:15:57.700 4: CUL_Parse: CUL_HM A 0A 4D 8002 612B10 F10000 000B -68.5
2018.10.03 12:20:24.841 4: CUL_Parse: CUL_HM A 16 4E A010 612B10 F10000 0202010AF10B000C0015FF180010 -66
2018.10.03 12:20:25.112 4: CUL_Parse: CUL_HM A 0C 4F A010 612B10 F10000 03000011 -65.5
2018.10.03 12:20:25.409 4: CUL_Parse: CUL_HM A 0C 50 A010 612B10 F10000 0308000F -66.5
2018.10.03 12:20:25.686 4: CUL_Parse: CUL_HM A 10 51 A010 612B10 F10000 023006572456000F -66.5
2018.10.03 12:20:25.957 4: CUL_Parse: CUL_HM A 0C 52 A010 612B10 F10000 0300000F -66.5
2018.10.03 12:20:26.256 4: CUL_Parse: CUL_HM A 0E 53 A010 612B10 F10000 010000000010 -66
2018.10.03 12:33:52.367 4: CUL_Parse: CUL_HM A 0D 58 8441 5B4EE7 000000 0155EF80EE -83

[frank]

alles gut.
"0x" bedeutet hexwert. ein vorangestelltes "set_" wäre schlecht/ungenügend.

jetzt kam auch die anlernmessage (#2) mit fw, model und sn. mit dieser sn funktioniert dann wahrscheinlich auch anlernen über sn. kannst ja mal drüberpairen und die timestamps vergleichen oder in den sniff schauen.

im sniff fehlen allerdings alle messages von fhem an das device. schlechter grep?

[uron]

schlechter grep?

Das Drüberpairen ergab im sniff nur

Code Auswählen Erweitern

2018.10.03 13:28:05.338 4: CUL_Parse: CUL_HM A 1A 56 8400 612B10 000000 2800044F4551313534383835371001010013 -64.5.
Ich denke, ich belasse es dabei und danke für eure Unterstützung!

@frank - p.s.: Mit dem "0x" hatte ich mich geirrt, es war das von dir angesprochene "set_", was auf einen nicht abgeschlossenen Pairvorgang hinweist.

[martinp876]

Es ist auch nichts weiter zu tun. Device ist gepairt. Sn ist natürlich die von der Verpackung. Diese solltest du auch nicht löschen. Geht dich nichts an.
Das sniffen musst du beim nächsten mal aber besser machen!

[uron]

@martin876
Ich würde gerne dazu lernen, um das Sniffen besser zu machen.
In der fhem.cfg habe ich die empfohlenen

Code Auswählen Erweitern

attr global verbose 1
attr global mseclog 1
attr CUL_HM verbose 4 eingetragen.
Fehlt da etwas?

[frank]

das passt.
hast du die messages aus fhem.log, oder vom eventmonitor? hast du einzelne rausgesucht, oder "am stück" kopiert?

wie gesagt, fehlen alle messages von fhem an das device.