Hi zusammen - habe mir o.g. Schalter geholt. Gepaired mit meinem CUL und fhem - Gerät taucht wie folgt per autocreate in der fhem.cfg auf:
2018.04.02 09:01:21 5: CUL/RAW: /A1A04840057E0D90000002400D04F4551303631353538351004010015
2018.04.02 09:01:21 4: CUL_Parse: CUL1 A 1A 04 8400 57E0D9 000000 2400D04F4551303631353538351004010015 -63.5
2018.04.02 09:01:21 5: CUL1: dispatch A1A04840057E0D90000002400D04F45513036313535383510040100::-63.5:CUL1
2018.04.02 09:01:21 2: CUL_HM Unknown device HM_57E0D9 is now defined
2018.04.02 09:01:21 2: autocreate: define HM_57E0D9 CUL_HM 57E0D9
2018.04.02 09:01:21 2: autocreate: define FileLog_HM_57E0D9 FileLog ./log/HM_57E0D9-%Y.log HM_57E0D9
Schalten von z.B. Kanal 1 geht dann wie folgt nicht:
2018.04.02 09:02:48 3: CUL_HM set HM_57E0D9_Sw_01 on
2018.04.02 09:02:48 0: CUL_HM_assignIO HM_57E0D9 AssignIoPort used
2018.04.02 09:02:48 5: CUL1 sending As0E2CA01107056757E0D90201C80000
2018.04.02 09:02:48 5: SW: As0E2CA01107056757E0D90201C80000
2018.04.02 09:02:52 5: CUL1 sending As0E2CA01107056757E0D90201C80000
2018.04.02 09:02:52 5: SW: As0E2CA01107056757E0D90201C80000
2018.04.02 09:02:57 5: CUL1 sending As0E2CA01107056757E0D90201C80000
2018.04.02 09:02:57 5: SW: As0E2CA01107056757E0D90201C80000
2018.04.02 09:03:03 5: CUL1 sending As0E2CA01107056757E0D90201C80000
2018.04.02 09:03:03 5: SW: As0E2CA01107056757E0D90201C80000
2018.04.02 09:03:05 5: CUL/RAW: /A0CFE8670585D6800000000D62329
Es kommt so wie ich das sehe keine Quittung. Ist das Teil defekt?
EDIT: Was ich noch sehe - in den Readings habe ich kein PairedTo...
hält er den schaltzustand bei manuellem schalten?
Gesendet von meinem SM-J510FN mit Tapatalk
Ja - manuell geht
Moin,
mach mal einlist HM_57E0D9 und poste die Ausgabe.
Ich vermute er ist zwar angelegt aber nicht angelernt (gepairt)
Gruß Otto
CFGFN
CUL1_MSGCNT 9
CUL1_RAWMSG A1A14840057E0D90000002400D04F45513036313535383510040400::-75:CUL1
CUL1_RSSI -75
CUL1_TIME 2018-04-02 09:39:38
DEF 57E0D9
IODev CUL1
LASTInputDev CUL1
MSGCNT 9
NAME HM_57E0D9
NOTIFYDEV global
NR 314
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 HM_57E0D9_Sw_01
channel_02 HM_57E0D9_Sw_02
channel_03 HM_57E0D9_Sw_03
channel_04 HM_57E0D9_Sw_04
lastMsg No:14 - t:00 s:57E0D9 d:000000 2400D04F45513036313535383510040400
protCmdDel 10
protLastRcv 2018-04-02 09:39:38
protResnd 6 last_at:2018-04-02 09:40:29
protResndFail 2 last_at:2018-04-02 09:40:34
protSnd 2 last_at:2018-04-02 09:40:13
protState CMDs_done_Errors:1
rssi_at_CUL1 min:-82 lst:-75 max:-59.5 avg:-69 cnt:9
Helper:
DBLOG:
D-firmware:
logdb:
TIME 1522654778.67089
VALUE 2.4
D-serialNr:
logdb:
TIME 1522654778.67089
VALUE OEQ0615585
state:
logdb:
TIME 1522654834.8169
VALUE RESPONSE TIMEOUT:RegisterRead
READINGS:
2018-04-02 09:39:38 D-firmware 2.4
2018-04-02 09:39:38 D-serialNr OEQ0615585
2018-04-02 09:40:34 state RESPONSE TIMEOUT:RegisterRead
RegL_00.:
VAL
helper:
HM_CMDNR 60
cSnd 1107056757E0D90202C80000,0107056757E0D900040000000000
mId 00D0
regLst ,0,1,3p
rxType 1
supp_Pair_Rep 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +57E0D9,00,00,00
nextSend 1522654778.76042
prefIO
rxt 0
vccu VCCU
p:
57E0D9
00
00
00
mRssi:
mNo 14
io:
CUL1:
-73
-73
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_CUL1:
avg -69
cnt 9
lst -75
max -59.5
min -82
Attributes:
IODev CUL1
IOgrp VCCU
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.4
model HM-LC-Sw4-DR-2
room Garage
serialNr OEQ0615585
subType switch
webCmd getConfig:clear msgEvents
Zitat von: Otto123 am 02 April 2018, 10:14:42
Ich vermute er ist zwar angelegt aber nicht angelernt (gepairt)
Da lag ich richtig :)
also pairen :)
https://wiki.fhem.de/wiki/HomeMatic#Pairen
Ich steh aufm Schlauch - bisher hat fhem immer automagisch gepaired... Tase drücken am Gerät - und gut ists...
Du mußt dein gateway dazu in den pairing modus versetzen
Gesendet von meinem SM-J510FN mit Tapatalk
Geht/ging bei mir bisher automatisch.
Habe ich jetzt nochmal manuell gemacht (set CUL1 hmPairforSeconds 600) - gleiches Ergebnis.
pairen geht/ging noch nie automatisch.
musst Du notfalls mehrfach machen, eventuell auch mal einen clear msgEvents
Keine Hektik,
Ruhe bewahren, pairing dauert Zeit.
Und jetzt noch mein Lieblingsspruch: Der CUL ist ein besch... Homematic IO
Man braucht auf alle Fälle die richtige Firmware -> https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Was hminfo configcheck hilft auch immer bei der Analyse.
Viel Erfolg
otto
das ist das erste Gerät, dass sich so verhält - ich lese mal in Ruhe noch deine Links.
Frage:
kann es sein, dass dieses Gerät ein "gebrauchtes" ist, dass schonmal an Original-Homematic gepaired war?
wenn es auf dein pairing "sauer" reagieren würde, gäbe es attack Meldungen.
Was hast Du sonst für Geräte? Sensoren oder Schalter?
Gib mal ein list von einem anderen Gerät
Zitat von: LT@Home am 02 April 2018, 19:07:10
das ist das erste Gerät, dass sich so verhält - ich lese mal in Ruhe noch deine Links.
Was sind denn die anderen Geräte für Geräte?
Denn wie bereits geschrieben: automatisch (also ohne set CUL hmPairForSec) wird das Gerät zwar von autocreate angelegt (ist dann in fhem "vorhanden") aber ist NICHT gepaired. D.h. es kann nicht geschalten werden.
Ein Sensor kann natürlich "mitgelesen" werden, da gibt es ja nichts zu steuern und die per Funk gesendeten Telegramme werden empfangen und fhem "ordnet" die Daten dann entsprechend zu...
Und: irgendwann ist immer das erste Mal, dass es mit einem CUL nicht (sofort) geht.
Hatte auch lange nur einen nanoCUL und alles hat geklappt...
...bis dann eben auch irgendwann mal ein Gerät um die Ecke kam wo es nicht mehr ging...
...bzw. nur mit der im von Otto verlinkten Wiki verlinkten "Spezial-FW".
Viel Erfolg, Joachim
hmm - ich hab z.B. den hier - sauber gepaired würde ich meinen:
Internals:
CUL1_MSGCNT 2
CUL1_RAWMSG A0EC880024E3DF20705670104000046::-69:CUL1
CUL1_RSSI -69
CUL1_TIME 2018-04-01 07:36:13
DEF 4E3DF2
IODev CUL1
LASTInputDev CUL1
MSGCNT 2
NAME GV.BE.SC.Licht
NOTIFYDEV global
NR 43
NTFY_ORDER 50-GV.BE.SC.Licht
STATE CMDs_done
TYPE CUL_HM
channel_01 GV.BE.SC.Licht_Sw_01
channel_02 GV.BE.SC.Licht_Sw_02
channel_03 GV.BE.SC.Licht_Sw_03
channel_04 GV.BE.SC.Licht_Sw_04
lastMsg No:C8 - t:02 s:4E3DF2 d:070567 0104000046
protLastRcv 2018-04-01 07:36:13
protSnd 2 last_at:2018-04-01 07:36:12
protState CMDs_done
rssi_CUL1 avg:-70 cnt:2 lst:-70 max:-70 min:-70
rssi_at_CUL1 lst:-69 max:-69 avg:-69 cnt:2 min:-69
Helper:
DBLOG:
state:
logdb:
TIME 1522560973.01774
VALUE CMDs_done
READINGS:
2018-01-27 07:07:57 CommandAccepted yes
2017-05-20 14:43:53 D-firmware 1.12
2017-05-20 14:43:53 D-serialNr NEQ0999661
2018-01-27 07:11:29 PairedTo 0x070567
2017-05-20 14:43:58 R-pairCentral 0x070567
2018-01-27 07:11:29 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:07 0B:05 0C:67 00:00
2018-01-14 16:56:44 level 0
2018-01-14 16:56:44 pct 0
2018-01-14 16:56:44 powerOn 2018-01-14 16:56:44
2018-01-14 16:56:44 recentStateType info
2018-04-01 07:36:13 state CMDs_done
2018-01-14 16:56:44 timedOn off
helper:
HM_CMDNR 200
cSnd 110705674E3DF20204C80000,110705674E3DF20204000000
mId 0003
regLst ,0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +4E3DF2,00,00,00
nextSend 1522560973.10673
prefIO
rxt 0
vccu VCCU
p:
4E3DF2
00
00
00
mRssi:
mNo C8
io:
CUL1:
-65
-65
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 04
qReqStat 01,02,03
role:
dev 1
prs 1
rssi:
CUL1:
avg -70
cnt 2
lst -70
max -70
min -70
at_CUL1:
avg -69
cnt 2
lst -69
max -69
min -69
tmpl:
Attributes:
IODev CUL1
IOgrp VCCU
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.12
model HM-LC-SW4-SM
room CUL_HM
serialNr NEQ0999661
subType switch
webCmd getConfig:clear msgEvents
oder die hier:
Internals:
CUL1_MSGCNT 94
CUL1_RAWMSG A0D53A4105114580705670604C800::-55.5:CUL1
CUL1_RSSI -55.5
CUL1_TIME 2018-04-03 07:30:51
DEF 511458
IODev CUL1
LASTInputDev CUL1
MSGCNT 94
NAME Sirene
NOTIFYDEV global
NR 57
NTFY_ORDER 50-Sirene
STATE CMDs_done
TYPE CUL_HM
channel_01 Sirene_Sen_01
channel_02 Sirene_Sen_02
channel_03 Sirene_Panic
channel_04 Sirene_Arm
lastMsg No:53 - t:10 s:511458 d:070567 0604C800
protLastRcv 2018-04-03 07:30:51
protSnd 94 last_at:2018-04-03 07:30:51
protState CMDs_done
rssi_at_CUL1 min:-57.5 avg:-54.86 cnt:94 lst:-55.5 max:-53
Helper:
DBLOG:
battery:
logdb:
TIME 1522733451.53475
VALUE ok
sabotageError:
logdb:
TIME 1522733451.53475
VALUE off
state:
logdb:
TIME 1522733451.53475
VALUE CMDs_done
READINGS:
2018-01-27 06:18:51 CommandAccepted yes
2018-01-09 19:09:38 D-firmware 1.0
2018-01-09 19:09:38 D-serialNr NEQ1416382
2018-01-27 07:11:55 PairedTo 0x070567
2018-01-27 07:11:55 R-cyclicInfoMsg on
2018-01-27 07:11:55 R-pairCentral 0x070567
2018-01-27 07:11:55 R-sabotageMsg on
2018-01-27 07:11:55 RegL_00. 02:01 03:48 09:01 0A:07 0B:05 0C:67 12:17 18:00 10:01 22:83 00:00
2018-04-03 07:30:51 battery ok
2018-04-03 07:30:51 sabotageError off
2018-04-03 07:30:51 state CMDs_done
helper:
HM_CMDNR 83
mId 00F9
regLst ,0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +511458,00,00,00
nextSend 1522733451.52555
prefIO
rxt 0
vccu VCCU
p:
511458
00
00
00
mRssi:
mNo 53
io:
CUL1:
-49.5
-49.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 01,02,03
qReqStat
role:
dev 1
prs 1
rpt:
IO CUL1
flg A
ts 1522733451.42725
ack:
HASH(0x23482f0)
53800207056751145800
rssi:
at_CUL1:
avg -54.8670212765958
cnt 94
lst -55.5
max -53
min -57.5
tmpl:
Attributes:
IODev CUL1
IOgrp VCCU
autoReadReg 4_reqStatus
batterytype 2 x 1,5 V LR14/Baby/C
expert 2_raw
firmware 1.0
model HM-Sec-Sir-WM
msgRepeat 1
room CUL_HM
serialNr NEQ1416382
subType siren
userattr batterytype
webCmd getConfig:clear msgEvents
Da ich im Moment nicht vor dem teil sitze, kann ich den Vorgang im Moment nicht anstoßen - versuche ich heute Abend nochmal.
Ich will nicht "schwören", dass ich nie hmPairfor gemacht habe....
Wie wichtig ist die Version vom CUL - ich hab im Moment die 1.66 drauf - verfügbar ist die 1.67 so wie ich das sehe. Oder brauche ich die "Timestamp-Version"? Was in dem Zusammenhang vllt. noch erwähnenswert wäre: Ich habe am WE auch den Raspberry getauscht - von nem alten 1er Modell auf nen 3er - fhem ist jetzt schön "flitzeschnell" - ich kann auch nochmal zurück auf die alte HW und schauen, ob es dann geht.
beide sauber gepairt,
poste mal je ein list von vccu und cul1.
edit: das beste für hm ist die ts_culfw.
Moin,
wenn Du nie hmPairForSec oder hmPairSerial gemacht hast - hast Du die ganzen Geräte vorher schon mal mit Homematicsoftware oder CCU gepairt?
Bei der Firmware wie Frank schon sagt: Die Nummer spielt keine Rolle sondern die TimeStamp Firmware muss es sein.
Oder Du leistest Dir für 20 € das RPI Modul für deinen neuen Pi.
Gruß Otto
Internals:
DEF 070567
IODev CUL1
NAME VCCU
NOTIFYDEV global
NR 83
NTFY_ORDER 50-VCCU
STATE CUL1:ok,
TYPE CUL_HM
assignedIOs CUL1
channel_01 VCCU_Btn1
READINGS:
2018-03-30 15:39:26 state CUL1:ok,
2018-03-03 07:15:29 unknown_31A231 received
2018-03-20 17:34:30 unknown_54047D received
2018-03-29 18:10:11 unknown_5490B6 received
2018-03-30 09:37:05 unknown_57E0D9 received
2018-03-20 17:58:17 unknown_585D68 received
2018-03-20 18:09:09 unknown_585FC8 received
helper:
HM_CMDNR 203
mId FFF0
regLst ,0
rxType 1
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU
ioList:
CUL1
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
Attributes:
IODev CUL1
IOList CUL1
IOgrp VCCU
expert 2_raw
icon cul_cul
model CCU-FHEM
room Dongles
subType virtual
webCmd virtual:update
und
Internals:
CMDS BbCFiAZNkGMKUYRTVWXefmLltux
CUL1_MSGCNT 6557
CUL1_TIME 2018-04-03 10:13:13
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 0000
DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00@9600
FD 14
FHTID 0000
HM_CMDNR 1
NAME CUL1
NR 33
NR_CMD_LAST_H 2
PARTIAL
RAWMSG A0CA2867054584D0000000059471E
RSSI -59
STATE Initialized
TYPE CUL
VERSION V 1.66 CUL868
hmPairSerial OEQ0615585
initString X21
Ar
owner_CCU VCCU
Helper:
DBLOG:
state:
logdb:
TIME 1522688079.39751
VALUE hmPairForSec 600
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-03-30 15:39:23 cmds B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
2017-03-02 18:16:23 raw isFF00FF000FF0
2018-04-03 10:13:13 state Initialized
2017-01-06 08:52:22 uptime 0 00:40:28
2017-12-09 14:38:14 version V 1.66 CUL868
XMIT_TIME:
1522736791.10099
1522740192.34913
helper:
000000:
QUEUE:
4E3DF2:
QUEUE:
511458:
QUEUE:
54047D:
QUEUE:
54584D:
QUEUE:
55B060:
QUEUE:
57E0D9:
QUEUE:
585D68:
QUEUE:
585FC8:
QUEUE:
Attributes:
hmId 070567
icon cul_868
rfmode HomeMatic
room Dongles
verbose 5
[/code]
ich will nicht behaupten ich hätte NIE hmPairfor.... gemacht - aber die letzten Dinger, die ich hinzugefügt habe waren Sensoren
Hä RPI - Modul?
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Danke - da ich zur Reichweitenerhöhung ne größere externe Antenne dran hab, scheidet das Teil dann aus.
Wie ist jetzt der schnellste Weg zu ner korrekten FW? Ich habe die Threads gefunden - aber 48 Seiten lesen ist harter Tobak...
im prinzip sieht alles ok aus.
allerdings sind die letzten protokoldaten des sw4-dr während dem pairen alles andere als gut:
protCmdDel 10
protLastRcv 2018-04-02 09:39:38
protResnd 6 last_at:2018-04-02 09:40:29
protResndFail 2 last_at:2018-04-02 09:40:34
protSnd 2 last_at:2018-04-02 09:40:13
protState CMDs_done_Errors:1
rssi_at_CUL1 min:-82 lst:-75 max:-59.5 avg:-69 cnt:9 vielleicht störungen und abschirmung im schaltschrank, der rssi (funk) schwankt auch heftig.
zum pairen würde ich den cul mal näher bringen, vielleicht auch die schaltschranktür offen lassen, zumal die fw vom cul ja nicht ideal ist.
ansonnsten drüber pairen bis es funktioniert hat, ohne device löschen oder resetten.
Zitatda ich zur Reichweitenerhöhung ne größere externe Antenne dran hab, scheidet das Teil dann aus.
die antenne könntest du auch an den hmuart bauen.
den fw-thread würde ich mal "rückwärts" lesen.
Zitat von: frank am 03 April 2018, 11:03:03
im prinzip sieht alles ok aus.
allerdings sind die letzten protokoldaten des sw4-dr während dem pairen alles andere als gut:
protCmdDel 10
protLastRcv 2018-04-02 09:39:38
protResnd 6 last_at:2018-04-02 09:40:29
protResndFail 2 last_at:2018-04-02 09:40:34
protSnd 2 last_at:2018-04-02 09:40:13
protState CMDs_done_Errors:1
rssi_at_CUL1 min:-82 lst:-75 max:-59.5 avg:-69 cnt:9
vielleicht störungen und abschirmung im schaltschrank, der rssi (funk) schwankt auch heftig.
zum pairen würde ich den cul mal näher bringen, vielleicht auch die schaltschranktür offen lassen, zumal die fw vom cul ja nicht ideal ist.
ansonnsten drüber pairen bis es funktioniert hat, ohne device löschen oder resetten.
die antenne könntest du auch an den hmuart bauen.
den fw-thread würde ich mal "rückwärts" lesen.
Das Teil liegt im Moment ausgebaut in sehr guter Reichweite des CUL - ich hatte zunächst auch Reichweitenproblem / Abschirmung durch sehr viel Stahl im beton vermutet - und den Schalter dann mal "inHouse" geholt - aber keine Verbesserung des Verhaltens.
Ich fang dann mal an rückwärts zu lesen.
Wie so oft steht das wichtige auf Seite 1 und dann dieser Link
https://forum.fhem.de/index.php/topic,24436.msg773255.html#msg773255
Ich will Dir nicht Deinen geliebten CUL ausreden und ich verkaufe auch keine Module bei elv.
Aber mit dem kleinen Modul und einem ESP kannst Du das Ding zum WLAN HM-IO machen. Davon kannst Du auch mehrere einsetzen und so vielleicht elegant Funkprobleme beheben.
heiß geliebt ist der CUL nicht...
ich hab vor einigen Jahren mal experimentell mit fhem einem razberry angefangen - die ZWave-Teile haben mir aber nicht gefallen und dann habe ich mal experimentell mit nem CUL und Homematic weitergemacht - und das war für mich in Ordnung. Das ganze soll jetzt sukzessive "in die Fläche" - mein Wissen und meine Hardware ist also entsprechend angestaubt. Ich hatte auch schon mal überlegt ob ich mir ne CCU2 hole, weil die Schaltereinsätze (da gehts dann finanziell ans eingemachte) perspektivisch IP sind und das ist ja scheinbar "closed" - jedenfalls nur per CCU an fhem zu betreiben. Die Schalterei in der Garage ist noch "Zwischenexperiment" mit Herausforderung bei Reichweite (und im Moment Pairing).
Zitat von: Otto123 am 03 April 2018, 12:08:43
Ich will Dir nicht Deinen geliebten CUL ausreden und ich verkaufe auch keine Module bei elv.
Aber mit dem kleinen Modul und einem ESP kannst Du das Ding zum WLAN HM-IO machen. Davon kannst Du auch mehrere einsetzen und so vielleicht elegant Funkprobleme beheben.
Leider wohl nicht mehr:
https://forum.fhem.de/index.php/topic,86575.msg789955.html#msg789955
Gruß, Joachim
Ich denke doch, es gab vielleicht bloß Umbau an der Webseite?
https://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html
Gruß Otto
Hallo Otto,
puh, dann ist's ja gut! :)
Danke, Joachim
Soderle - jetzedle.....
Ich habe den PI (zurück-)getauscht - das erschien mir als erstes eine gute Idee, bevor ich mich mit dem Thema "nach vorne" beschäftige und am CUL rumfrickel - einen Versuch war es mir wert.
Und siehe da, das Teil paired - auf Anhieb!
Wenn am Wochenende mal Zeit ist, dann beschäftige ich mich mit dem CUL und einer passenden FW - auf dem neuen Pi.
EDIT: Interessanterweise ließen sich mit dem neuen/schnelleren PI die schon gepairten Devices schalten
Moin,
ich habe keine Erfahrung mit dem CUL (ich habe mal einen in "Lohnarbeit" geflashed :D ) und erst Recht nicht von dessen Firmware und was da eigentlich genau passiert.
Aber wenn der langsame und der schnelle Pi einen Unterschied bringt riecht das irgendwie nach Timing. Und genau damit beschäftigt sich die andere Firmware.
Gruß Otto
Das war ja meine Vermutung auch, nachdem mir das Thema Firmware ans Herz gelegt wurde und ich bisher keine Schwierigkeiten hatte.