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:
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:
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:
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 get Einfahrt_Licht model bekomme ich die Fehlermeldung 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?
es fehlen wichtige attribute: model, subType, ...
ist autocreate aktiv?
einfach nochmal drüber pairen.
er scheint gepairt zu sein, aber ohne attr <> model und subtyp weiß ja cul_hm nicht was das Device sein soll.
du kannst mal
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
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!
Habe den Pairvorgang nach manuellem Setzen der SN und des Modell wie folgt vorgenommen:
set CUL_HM hmPairSerial LPNHE25860
Beim Sniffen kam dann folgendes heraus:
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!
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.
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) 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:
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
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.
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.
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 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: 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 PairedTo 0xF10000 auf einen nicht abgeschlossenen Vorgang hinweist.
Durch das Sniffen habe ich im Logfile nun folgende Einträge: 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
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?
Zitatschlechter grep?
???
Das Drüberpairen ergab im sniff nur
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.
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!
@martin876
Ich würde gerne dazu lernen, um das Sniffen besser zu machen.
In der fhem.cfg habe ich die empfohlenen attr global verbose 1
attr global mseclog 1
attr CUL_HM verbose 4 eingetragen.
Fehlt da etwas?
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.
Ich hatte die messages aus der fhem.log; der Eventmonitor wäre demnach sicher besser gewesen.
Ich baue meinen Funkschalter aber jetzt nicht wieder aus um die messages zu testen und beachte das beim nächsten Mal.
Danke für den Hinweis.
die datei fhem.log ist genau richtig.
im eventmonitor mit opt fhem.log theoretisch auch möglich. allerdings werden manche einträge aus fhem.log nicht im eventmonitor angezeigt. zb einträge, die durch geforkte prozesse entstehen.
dann bleibt das fehlen der messages bei dir weiterhin ein rätsel. gesendet wurden sie ja. aber anscheinend gelangen sie bei dir nicht ins log. sehr seltsam.
sniffen funktioniert ja immer. du musst also nichts wieder ausbauen.
Den erneuten Ausbau hatte ich erwogen, da ich ja den Anlernprozess am Device über den Tastaer an S1 anstoßen müsste.
Sniffen
https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen
Also ok. Allerdings fehlen die gesendeten mesages. Du hast sicher schon die cul ts version. Wenn nicht empfehle ich es dringend. Leider sind meine beiden cul und cuno verstorben....
Ich muss einmal den loglevel der cul prüfen. Hierzu ist wichtig, welche version du nutzt. Ich betrachte nur tscul. Alles andere ( also die default cul) ist nicht hm geeignet.
Beim ersten anlernen nutze ich immer die config taste. Erst wenn es verbaut ist mache ich eine ausnahme.
Was auch immer ich für einen CUL habe, ich weiß es nicht, den hatte ich bei ebay gekauft und bisher hat er geklappt (ich weiß, ich wurschtele mich da so durch).
Das List des CUL zeigt Internals:
CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400
FD 12
FHTID 0000
NAME CUL_HM
NR 40
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL868
initString X21
Ar
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-07-24 08:47:19 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2018-10-05 06:35:30 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
2018-10-05 06:35:30 state Initialized
helper:
Attributes:
hmId F10000
rfmode HomeMatic
Ich bin seit einiger Zeit schon auf dem Weg zu TSCUL. Das Aufspielen der aktuelle CUL Timestamp Variante erfordert m.W. aber den Zugriff auf meinen Raspi, um die Datei "CUL_Util.pm" aufzuspielen, was mir wegen des fehlenden Raspi-PW nicht gelingen will.
Das Zurücksetzen gem. https://praxistipps.chip.de/raspberry-pi-zuruecksetzen-so-klappts_45154 (https://praxistipps.chip.de/raspberry-pi-zuruecksetzen-so-klappts_45154) klappt auch nicht.
Ich muss mich jetzt erst einmal meinem Raspi-Problem widmen.
Dazu brauche ich m.E. eine FHEM-Sicherung, um dann den Raspi auf Werkseinstellungen setzen zu können und die Sicherung wieder aufzuspielen. So jedenfalls stelle ich mir das vor.