Hallo, nun suche ich seit Stunden den Fehler in meine fhem.cfg und habe ähnlich Fehleraussagen, kann mit den Antworten aber nicht wirklich etwas anfangen - liegt sicher an meiner geringen Wissenstiefe!
Ist-Zustand
- Ich habe einen neuen Homematic Schaltaktor HM-LC-Sw1-Pl-2 und möchte ihn in meine fhem.cfg einbinden und über den vorhandenen CUL_HM ansteuern
Beim Pairen habe ich folgende Einträge erhalten:
define HM_357982 CUL_HM 357982
attr HM_357982 room CUL_HMattr HM_357982 webCmd on:off
attr HM_357982 model HM-LC-SW1-PL2
definiere ich danach die möglichen Schaltbefehle und setze das Aktormodell
ProblemKlicke ich nun im Webfrontend
on oder
off, erhalte ich folgende Fehlermeldung:
Unknown argument on, choose one of assignHmKey:noArg clear:readings,rssi,msgEvents,unknownDev clear:readings,trigger,register,oldRegs,rssi,msgEvents,attack,all deviceRename fwUpdate getConfig:noArg getRegRaw peerBulk raw regBulk regSet reset:noArg sign:on,off unpair:noArg virtual:slider,1,1,50Schaue ich in der cmdList finde ich dort kein on oder off.
Ich vermute irgedwo einen Gedankenfehler, finde ihn aber nicht.
Könnt ihr helfen?
1. Du bist Urheber dieses Threads und nur Du (oder ein Mod) kannst daher durch Ändern des ersten Beitrages diesen und die Antworten in einen anderen Bereich, hier konkret "Homematic" (in den Haus-Automatisierungs-Systemen) verschieben. Bitte tue das, denn die Frage gehört dorthin.
2. Das Hinzukonfigurieren von model kann sehr tricky sein, denn schon auf die 100% korrekte Schreibweise kommt es an. Die übliche Nomenklatur lässt hier schon mal einen Fehler vermuten. Aus diesem Grund wird hier von FHEM auch keine richtige Vorbelegung der devicetypischen Eigenschaften vorgenommen, weswegen die Befehle dann auch nicht zur Verfügung stehen.
3. Für gewöhnlich wird bei einem Pairen all dies automatisch eingetragen. Du solltest das Pairen richtig wiederholen.
4. Irgendwie scheint sich gerade flächendeckend durchzusetzen, dass fhem.cfg-Auszüge (oder RAW definitions) gepostet werden statt der Ausgabe eines "list <device>" im Browser. Nur hier sehen die Helfenden aber wichtige Infos zu aktuellen Registerwerten.
- Danke für den Hinweis, ist hiermit geschehen
- Hab nun einmal unter "attr model" beide ähnlich lautende modelle ausgewählt und getestet: Das Ergebnis ist gleich: "unknown argument"
- Was soll ich beim Pairen anderes tun?
- hier das Ergebnis zu list HM_357982
Internals:
DEF 357982
IODev CUL_HM
NAME HM_357982
NOTIFYDEV global
NR 242
STATE ???
TYPE CUL_HM
READINGS:
2018-07-21 10:29:49 CommandAccepted yes
2018-07-21 10:29:48 D-firmware 2.4
2018-07-21 10:29:48 D-serialNr LTK0126321
2018-07-21 15:12:54 PairedTo 0xF10000
2018-07-21 10:34:49 R-pairCentral 0xF10000
2018-07-21 15:12:55 R-sign off
2018-07-21 15:12:54 RegL_00. 02:01 0A:F1 0B:00 0C:00 15:FF 18:00 00:00
2018-07-21 15:12:55 RegL_01. 08:00 30:06 57:24 56:00 00:00
helper:
HM_CMDNR 111
mId 0011
rxType 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +357982,00,00,00
prefIO
rxt 0
vccu
p:
357982
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
Attributes:
IODev CUL_HM
autoReadReg 4_reqStatus
expert 2_raw
model HM-LC-SW1-PL2
room CUL_HM
webCmd on:off Freue mich auf weitere Antworten!
was ist das für eine seriennummer: LTK0126321 ?
wo sind die attribute subtype, firmware, serialnbr, ... ?
nutzt du kein autocreate?
1. Die Nr. LTK0126321 steht auf der Verpackung!
2. Ich habe autocreate eingeschaltet
define autocreate autocreate
attr autocreate autosave
Das Pairen habe ich wie folgt vollzogen:
set CUL_HM hmPairForSec 60
Danach den Taster am Schaltaktor so lange gedrückt, bis LED anfing zu blinken. Nach 1x Blinken leuchtete die LED wieder dauernd, der generierte Eintrag in der fhem.cfg: siehe im 1. Post!
außer den 2 genannten Zeilen war nichts zu sehen!
Jetzt habe ich den Aktor wieder gelöscht, FHEM neu gestartet, neu wie oben beschrieben gepairt ..... und ...
.... nun kommt der Fehler nicht mehr! Auch das lamp-icon ist nun gesetzt - weiß der Geier warum!
Das list HM_357982 sieht nun aber auch ganz anders aus!
Trotzdem Danke für eure Hilfe, leider ohne Erkenntnisgewinn außer der, dass mit auch noch so unmöglichen Problemen im Forum Hilfe angeboten wird.
mit der seriennummer kann das eigentlich kein original homematic sein. zeig doch noch mal ein aktuelles list.
Also, so ganz scheint mich das Thema doch nicht loszulassen, da das Device immer wieder gelöscht wird.
Ein erneutes Pairen gibt wieder Fehler, dann wieder nicht. Reproduzieren kann ich das aber noch nicht.
Hier nun das aktuelle list und dort findest du auch die genannte SN. Der toggle-Befehl muss noch händisch raus:
Internals:
CFGFN
CUL_HM_MSGCNT 6
CUL_HM_RAWMSG A0E6C8002357982F100000101C80038::-78.5:CUL_HM
CUL_HM_RSSI -78.5
CUL_HM_TIME 2018-07-21 19:46:23
DEF 357982
IODev CUL_HM
LASTInputDev CUL_HM
MSGCNT 6
NAME HM_357982
NOTIFYDEV global
NR 528
STATE on
TYPE CUL_HM
lastMsg No:6C - t:02 s:357982 d:F10000 0101C80038
protLastRcv 2018-07-21 19:46:23
protSnd 5 last_at:2018-07-21 19:46:22
protState CMDs_done
rssi_CUL_HM avg:-55 min:-56 max:-54 lst:-56 cnt:2
rssi_at_CUL_HM avg:-84.5 min:-88.5 max:-77 lst:-78.5 cnt:6
READINGS:
2018-07-21 19:46:23 CommandAccepted yes
2018-07-21 19:45:53 D-firmware 2.4
2018-07-21 19:45:53 D-serialNr LTK0126321
2018-07-21 19:45:53 R-pairCentral set_0xF10000
2018-07-21 19:46:23 deviceMsg on (to CUL_HM)
2018-07-21 19:46:23 level 100
2018-07-21 19:46:23 pct 100
2018-07-21 19:46:23 recentStateType ack
2018-07-21 19:46:23 state on
2018-07-21 19:46:23 timedOn off
helper:
HM_CMDNR 108
cSnd 11F100003579820201000000,11F100003579820201C80000
dlvlCmd ++A011F100003579820201C80000
mId 00A1
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +357982,00,00,00
nextSend 1532195183.08712
prefIO
rxt 0
vccu
p:
357982
00
00
00
mRssi:
mNo 6C
io:
CUL_HM -76.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
CUL_HM:
avg -55
cnt 2
lst -56
max -54
min -56
at_CUL_HM:
avg -84.5
cnt 6
lst -78.5
max -77
min -88.5
shadowReg:
RegL_00. 02:01 0A:F1 0B:00 0C:00
Attributes:
IODev CUL_HM
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.4
model HM-LC-SW1-PL2
room CUL_HM
serialNr LTK0126321
subType switch
webCmd statusRequest:toggle:on:off
du musst nicht immer wieder pairen. das device ist bereits gepairt und kann die daten nicht verlieren.
fhem fehlen aber noch daten, die du über getconfig bekommst.
mit get hminfo configCheck kannst du kontrollieren.
es gibt anscheinend ein funkproblem vom device zum cul. siehe rssi. die werte sind eher schlecht, aber vor allem deutlich schlechter, als die andere richtung.
ist der cul defekt, oder gebrauchtes device?
ich kenne nur SN mit "EQ" an 2ter und 3ter stelle. seltsam.
OK, nicht erneut pairen!
Wo sind Daten mit getconfig auszulesen? Gebe ich "get hminfo configCheck" in die Befehlszeile ein erhalte ich "Please define hminfo first"!
Das Funkproblem wundert mich, da ich mit dem CUL (EG) quer durch das Haus Rolladenschalter im OG steuere.
In der untersuchten Phase des Pairings war Device (gebrauchter Schaltaktor über ebay erworben) und CUL_HM etwa 2,5 m voneinander platziert. Der CUL ist ca. 2 Jahre alt.
So, ich habe das heute Morgen mal erkundet, was es mit hminfo auf sich hat und poste nun das Ergebnis:
rssi done:
Device receive from last avg min_max count
HM_357982 CUL_HM HM_357982 -86.5 -82.4 -89.0< -76.5 4
HM_357982 HM_357982 CUL_HM -80.0 -63.3 -80.0< -54.0 3
RolloBuero CUL_HM RolloBuero -66.5 -69.2 -72.0< -66.5 2
RolloBuero RolloBuero CUL_HM -43.0 -43.0 -43.0< -43.0 1
RolloPatrickzimmerGaube CUL_HM RolloPatrickzimmerGaube -92.5 -93.7 -94.5< -92.5 3
RolloPatrickzimmerGaube RolloPatrickzimmerGaube 59CB50 -56.0 -57.0 -58.0< -56.0 2 Dabei ist wichtig zu wissen, dass der diskutierte Aktor HM_357982 mittlerweile in meinem Gartenhaus, also weiter weg als gestern, untergebracht ist. RolloBuero ist ca. 1.20 m vom CUL_HM entfernt.
Wie lautet eure Diagnose zum CUL?
unauffällige rssi sehen sicherlich anders aus:
1. beide funkrichtungen nahezu gleich, +/- 5
2. -20 < avg < -80
entweder empfängt der cul schlecht, oder alle devices senden schlecht.
auch -63 vom cul zum aktor bei 1,2m ist extrem schlecht.
die wahrscheinlichkeit eines "defekten" culs ist sicherlich ziehmlich hoch. selbstbau? antenne ok? mach ein "get cul ccconf" und poste ein list vom cul.
Kein Selbstbau, habe ich bei ebay erworben. Habe zur "Qualität" des Herstellers allerdings keine Infos.
Ergebnis get cul ccconf:
CUL_HM ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
Krieg das mit dem list vom CUL nicht hin. Deshalb ein Screenshot vom Device. Ist das OK?
ccconf passt.
antenne mal durchgemessen (widerstand vom letzten bauteil bis antennenspitze)?
ein nanocul gehört für mich in die gruppe der selbstbau culs, egal wer ihn jetzt wirklich gebaut hat.
letztens hatte jemand einen haufen rolloaktoren mit dem selben fehlerbild. vermutlich wurden seine rolloaktoren durch rückwirkung der motoren in sehr kurzer zeit reihenweise geschrottet. da war allerdings die andere funkrichtung betroffen.
hm, ... in sofern sind mir deine hm geräte komplett suspekt im hinblick auf aussagen zum rssi.
mein bauch tippt auf den cul.
ich würde mir an deiner stelle zusätzlich den hmuart für den pi für 20 euro besorgen. als gateway sowieso besser für hm als die cul familie. dann hättest du vergleichswerte für die rssi.
Antenne durchgemessen: 0,5/0,6 Ohm.
Habe den (privaten) Verkäufer kontaktiert und erhoffe hier Infos.
Habe gleichzeitig recherchiert und das hier gefunden: https://groups.google.com/forum/?hl=en&fromgroups=#!searchin/fhem-users/predictor/fhem-users/HAaBri3eQgk/h1rvpn0tSV4J
Da aber mein CUL schon auf 8 dB eingestellt ist, ist das auch keine Lösung.
Ich überdenke das mit dem hmuart.
Nur mal so zwischenrein: die mid(modelid) welche fhem beim pairen (und jedem configButtonPress) empfängt ist der Key. Aus diesem wird das model abgeleitet. Es stand auf 11 und isr nun A1. Also ein anderes device.
Daher sollte man an diesen Attributen nicht spielen. Bekommt der anfänger nicht mehr unter Kontrolle.
... bleibt die Frage, warum sich die mid geändert hat?
Lag es an meinen händischen Umbenennung oder liegt ein Gerätedefekt nahe?
Wie gesagt,das kommt mit der config msg vom device. Wenn du es manuell aendertst hast du es geändert.
Dass ein Device eine falsche id sendet hatte ich noch nie. Ausschliessen kann ich das auch nicht.
Allerdings würde ich erst mal in deine Richtung blicken. War wohl eine retorische Frage.
dass ein fehler exakt die id's erzeugt, die du probiert hast, ist ja nahe zu unwahrscheinlich.
@martin
vielleicht könntest du die liste von "get hminfo models" mal sortieren. das würde den spass mit der liste sicherlich deutlich erhöhen. ;)
Ich hatte oben eine möglicherweise falsche Schreibweise des model moniert, die ist aber zu meiner Überraschung richtig und fällt damit bei der sonst üblichen Nomenklatur aus dem Rahmen: Diverse andere Geräte sind richtig mit "Pl-x" (also l klein und die Versionsnummer mit Bindestrich) statt wie hier "PL2". Lässt sich das vereinheitlichen?
Nun, zumindest get das in hminfo fast immer implementierte find wie dokumentiert:
Get hm help
Get hm models -f burst
Get hm models -f sw
Das solte fürs erste reichen
Nachdem mir mein "CUL-Hersteller" nun kostenfrei einen neuen CUL zugesandt hat, sehen die Ergebnisse m.E. schon besser aus. Offenbar war die Lötstelle der Antenne doch nicht ganz so fest, wie sie sein sollte:
rssi done:
Device receive from last avg min_max count
RolloBuero CUL_HM RolloBuero -57.0 -57.3 -58.0< -56.0 5
RolloBuero RolloBuero CUL_HM -53.0 -55.2 -57.0< -53.0 4
RolloPatrickzimmerGaube CUL_HM RolloPatrickzimmerGaube -72.5 -72.5 -72.5< -72.5 1
RolloPatrickzimmerGaube RolloPatrickzimmerGaube CUL_HM -71.0 -71.0 -71.0< -71.0 1
RolloPatrickzimmerLang CUL_HM RolloPatrickzimmerLang -78.5 -78.5 -78.5< -78.5 1
RolloPatrickzimmerLang RolloPatrickzimmerLang CUL_HM -77.0 -77.0 -77.0< -77.0 1
es sind zwar noch nicht sehr viele messungen, aber bisher sieht die symmetrie der rssi top aus. auch alle werte besser -80. die reichweite musst du beurteilen.
bei dem erfolg solltest du das "cul tuning" gleich fortsetzen und die für homematic optimalste fw flashen.
https://forum.fhem.de/index.php/topic,24436.0.html (https://forum.fhem.de/index.php/topic,24436.0.html)
OK, ich schau mir das mit dem Tuning gleich mal an.
Ich möchte an dieser Stelle (ohne Eigennutz) meinen CUL-Lieferanten Sascha Sturn loben. Der Austausch-Service, 9 Monate nach dem Kauf klappte absolut problemlos!
Das ist ja auch nicht selbstverständlich!