Hey,
ich habe hier an einem HM_CUL über eine VCCU unter anderem einen HM-LC-SW1PBU-FM Unterputzschalter.
Das Problem ist: er schaltet manchmal über FHEM sehr langsam.
Genauer gesagt schalte ich ihn dann ein oder aus und es dauert oft zwischen 3-8 Sekunden! Fhem hängt aber in der Zeit nicht.
Andere Homematic Autoren schalten sehr sehr schnell. Ich habe z.B. noch einen Hutschienenaktor an dem eine elektrische Fußbodenheizung hängt, der schaltet quasi SOFORT.
Ebenfalls schaltet der Unterputzschalter sehr zügig und zuverlässig, wenn ich ihn direkt von Hand bediene, also ist er scheinbar auch nicht defekt? Dachte erst an dieses Kondensatorproblem mit den Dingern.
Reichweite kann es auch nicht sein, denn der Schalter ist ca. 1m neben dem FHEM-Rechner in der Wand. Die RSSI ist auch sehr gut!
Habt ihr einen Tipp, was das sein kann? :(
Liegt das vielleicht daran, dass er mehrere "PeerIDs" hat?
Vielleicht sollte ich das Ding mal komplett resetten und neu pairen? (Wie geht das eigentlich? In Fhem "unpair" und das Ding dann über den Reset-Taster resetten?)
Hier das List:
Internals:
DEF 48C5E9
FUUID 5cd0935c-f33f-0d46-df7e-935795a8568cc82a
HMCUL_MSGCNT 52
HMCUL_RAWMSG A0E49800248C5E94669000101000020::-29.5:HMCUL
HMCUL_RSSI -29.5
HMCUL_TIME 2022-03-07 23:38:40
IODev HMCUL
LASTInputDev HMCUL
MSGCNT 52
NAME GartenHausLampe
NR 355
NTFY_ORDER 48-GartenHausLampe
STATE off
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
lastMsg No:49 - t:02 s:48C5E9 d:466900 0101000020
peerList self01,self02
protCmdDel 4
protLastRcv 2022-03-07 23:38:40
protRcv 48 last_at:2022-03-07 23:38:40
protResnd 44 last_at:2022-03-07 23:38:40
protResndFail 3 last_at:2022-03-05 22:21:28
protSnd 60 last_at:2022-03-07 23:38:30
protState CMDs_done
rssi_HMCUL cnt:32 min:-33 max:-31 avg:-32 lst:-32
rssi_at_HMCUL cnt:52 min:-31.5 max:-29 avg:-29.75 lst:-29.5
READINGS:
2022-03-07 23:38:40 CommandAccepted yes
2022-03-07 23:36:43 D-firmware 2.8
2022-03-07 23:36:43 D-serialNr NEQ0133328
2022-03-07 23:38:30 IODev HMCUL
2022-03-07 23:37:09 PairedTo 0x466900
2019-09-30 22:05:12 R-intKeyVisib visib
2019-09-10 21:40:15 R-localResDis off
2019-09-10 21:40:15 R-pairCentral 0x466900
2019-09-10 21:40:16 R-powerUpAction off
2019-09-30 22:05:14 R-self01-lgActionType jmpToTarget
2019-09-30 22:05:14 R-self01-lgCtDlyOff geLo
2019-09-30 22:05:14 R-self01-lgCtDlyOn geLo
2019-09-30 22:05:14 R-self01-lgCtOff geLo
2019-09-30 22:05:14 R-self01-lgCtOn geLo
2019-09-30 22:05:14 R-self01-lgCtValHi 100
2019-09-30 22:05:14 R-self01-lgCtValLo 50
2019-09-30 22:05:14 R-self01-lgMultiExec on
2019-09-30 22:05:14 R-self01-lgOffDly 0 s
2019-09-30 22:05:14 R-self01-lgOffTime unused
2019-09-30 22:05:14 R-self01-lgOffTimeMode absolut
2019-09-30 22:05:14 R-self01-lgOnDly 0 s
2019-09-30 22:05:14 R-self01-lgOnTime unused
2019-09-30 22:05:14 R-self01-lgOnTimeMode absolut
2019-09-30 22:05:14 R-self01-lgSwJtDlyOff off
2019-09-30 22:05:14 R-self01-lgSwJtDlyOn off
2019-09-30 22:05:14 R-self01-lgSwJtOff off
2019-09-30 22:05:14 R-self01-lgSwJtOn dlyOff
2019-09-30 22:05:14 R-self01-shActionType jmpToTarget
2019-09-30 22:05:14 R-self01-shCtDlyOff geLo
2019-09-30 22:05:14 R-self01-shCtDlyOn geLo
2019-09-30 22:05:14 R-self01-shCtOff geLo
2019-09-30 22:05:14 R-self01-shCtOn geLo
2019-09-30 22:05:14 R-self01-shCtValHi 100
2019-09-30 22:05:14 R-self01-shCtValLo 50
2019-09-30 22:05:14 R-self01-shMultiExec off
2019-09-30 22:05:14 R-self01-shOffDly 0 s
2019-09-30 22:05:14 R-self01-shOffTime unused
2019-09-30 22:05:14 R-self01-shOffTimeMode absolut
2019-09-30 22:05:14 R-self01-shOnDly 0 s
2019-09-30 22:05:14 R-self01-shOnTime unused
2019-09-30 22:05:14 R-self01-shOnTimeMode absolut
2019-09-30 22:05:14 R-self01-shSwJtDlyOff off
2019-09-30 22:05:14 R-self01-shSwJtDlyOn off
2019-09-30 22:05:14 R-self01-shSwJtOff off
2019-09-30 22:05:14 R-self01-shSwJtOn dlyOff
2019-09-30 22:05:15 R-self02-lgActionType jmpToTarget
2019-09-30 22:05:15 R-self02-lgCtDlyOff geLo
2019-09-30 22:05:15 R-self02-lgCtDlyOn geLo
2019-09-30 22:05:15 R-self02-lgCtOff geLo
2019-09-30 22:05:15 R-self02-lgCtOn geLo
2019-09-30 22:05:15 R-self02-lgCtValHi 100
2019-09-30 22:05:15 R-self02-lgCtValLo 50
2019-09-30 22:05:15 R-self02-lgMultiExec on
2019-09-30 22:05:15 R-self02-lgOffDly 0 s
2019-09-30 22:05:15 R-self02-lgOffTime unused
2019-09-30 22:05:15 R-self02-lgOffTimeMode absolut
2019-09-30 22:05:15 R-self02-lgOnDly 0 s
2019-09-30 22:05:15 R-self02-lgOnTime unused
2019-09-30 22:05:15 R-self02-lgOnTimeMode absolut
2019-09-30 22:05:15 R-self02-lgSwJtDlyOff on
2019-09-30 22:05:15 R-self02-lgSwJtDlyOn on
2019-09-30 22:05:15 R-self02-lgSwJtOff dlyOn
2019-09-30 22:05:15 R-self02-lgSwJtOn on
2019-09-30 22:05:15 R-self02-shActionType jmpToTarget
2019-09-30 22:05:15 R-self02-shCtDlyOff geLo
2019-09-30 22:05:15 R-self02-shCtDlyOn geLo
2019-09-30 22:05:15 R-self02-shCtOff geLo
2019-09-30 22:05:15 R-self02-shCtOn geLo
2019-09-30 22:05:15 R-self02-shCtValHi 100
2019-09-30 22:05:15 R-self02-shCtValLo 50
2019-09-30 22:05:15 R-self02-shMultiExec off
2019-09-30 22:05:15 R-self02-shOffDly 0 s
2019-09-30 22:05:15 R-self02-shOffTime unused
2019-09-30 22:05:15 R-self02-shOffTimeMode absolut
2019-09-30 22:05:15 R-self02-shOnDly 0 s
2019-09-30 22:05:15 R-self02-shOnTime unused
2019-09-30 22:05:15 R-self02-shOnTimeMode absolut
2019-09-30 22:05:15 R-self02-shSwJtDlyOff on
2019-09-30 22:05:15 R-self02-shSwJtDlyOn on
2019-09-30 22:05:15 R-self02-shSwJtOff dlyOn
2019-09-30 22:05:15 R-self02-shSwJtOn on
2019-09-10 21:40:16 R-sign off
2019-09-10 21:40:16 R-statusInfoMinDly 2 s
2019-09-10 21:40:16 R-statusInfoRandom 1 s
2019-09-10 21:40:16 R-transmitTryMax 6
2022-03-07 23:37:08 cfgState updating
2022-03-07 23:38:40 commState CMDs_done
2022-03-07 23:38:40 deviceMsg off (to vccu)
2022-03-07 23:38:40 level 0
2022-01-24 21:33:34 levelMissed desired:0
2022-03-07 23:38:40 pct 0
2022-03-07 23:37:16 peerList self01,self02
2022-03-07 23:38:40 recentStateType ack
2022-03-07 23:38:40 state off
2022-03-07 23:38:40 timedOn off
2022-03-07 23:38:30 trigLast fhem:02
helper:
HM_CMDNR 73
cSnd 1146690048C5E90201C80000,1146690048C5E90201000000
cfgStateUpdt 0
dlvlCmd ++A01146690048C5E90201000000
lastMsgTm 1646692720.61217
mId 0069
peerFriend peerSens,peerVirt
peerIDsRaw ,48C5E901,48C5E902,00000000
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey self01,self02:no:1646340203.2613
TmplTs 1646340203.2613
cmdKey 1:1:0::GartenHausLampe:0069:01:self01,self02
cmdLst:
assignHmKey noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
deviceRename -newName-
eventL -peer- -cond-
eventS -peer- -cond-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{self01})]
pressS [(-peer-|{self01})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
unpair noArg
lst:
condition slider,0,1,255
peer self01,self02
peerOpt HM_561CD2,HM_5CD4D0_SenF,HM_5CD4D0_SenI,HM_5CD4D0_SenPwr,HM_5CD4D0_SenU,HM_68B4DF_SenF,HM_68B4DF_SenI,HM_68B4DF_SenPwr,HM_68B4DF_SenU,HM_68D8CF,HM_69B0FF_SenF,HM_69B0FF_SenI,HM_69B0FF_SenPwr,HM_69B0FF_SenU,HM_6B2042_Btn_01,HM_6B2042_Btn_02,vccu
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 1
raw 0
tpl 0
io:
flgs 0
newChn +48C5E9,00,00,00
nextSend 1646692720.71166
rxt 0
vccu vccu
p:
48C5E9
00
00
00
prefIO:
mRssi:
mNo 49
io:
HMCUL:
-21.5
-21.5
peerIDsH:
00000000 broadcast
48C5E901 self01
48C5E902 self02
prt:
bErr 0
sProc 0
tryMsg:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rssi:
HMCUL:
avg -32
cnt 32
lst -32
max -31
min -33
at_HMCUL:
avg -29.75
cnt 52
lst -29.5
max -29
min -31.5
shadowReg:
tmpl:
Attributes:
IOgrp vccu
alias Licht am Haus
autoReadReg 4_reqStatus
expert defReg,allReg
firmware 2.8
genericDeviceType light
group Licht
model HM-LC-SW1PBU-FM
peerIDs 00000000,48C5E901,48C5E902
room HomeKit02,Garten,Alexa
serialNr NEQ0133328
sortby 5
subType switchDanke und Grüße
EDIT: Das Wiki sagt das hier:
ZitatBeim Pairen ist, wie im normalen Betrieb auch, ein Mindestabstand (etwa 1-2 Meter) zwischen dem Sender der Zentrale (CUL, HMLAN etc.) einzuhalten, da die Funkempfänger sonst mit Übersteuerung reagieren und keine Kommunikation zustande kommt.
Könnte das mein Problem sein?
genau, vergrössere mal den abstand zum cul.
wenn schon reset, dann am besten, wie in der bedienunggsanleitung beschrieben. danach wieder pairen.
aber in der regel völlig überflüssig.
Wozu Reset? Welche peerIDs?
Internals:
DEF 48C5E9 ...
peerList self01,self02 ...
READINGS:...
2019-09-30 22:05:12 R-intKeyVisib visib ...
Attributes: ...
peerIDs 00000000,48C5E901,48C5E902
Das sind die per intKeyVisib sichtbar gemachten internen Tasten.
Zitat von: Pati_Alpha am 07 März 2022, 23:50:33
Reichweite kann es auch nicht sein, denn der Schalter ist ca. 1m neben dem FHEM-Rechner in der Wand. Die RSSI ist auch sehr gut!
Internals:
rssi_HMCUL cnt:32 min:-33 max:-31 avg:-32 lst:-32
rssi_at_HMCUL cnt:52 min:-31.5 max:-29 avg:-29.75 lst:-29.5
Zu gut. Obgleich die Probleme mehr bei komplexen Konfigurationsvorgängen auftreten. Schalten kann ich hier auch bei geringem Abstand sehr problemlos, aber es sind auch immer mehr als 1 Meter.
Ursache für die Probleme könnte sein, dass die Empfänger beim Empfang des ersten Datentelegramms übersteuern und sie daher nicht verstehen können. Die später wiederholten Telegramme treffen treffen dann auch heruntergeregelte Empfänger.
Wenn es ein weiteres HM-Interface (IO) gäbe (wofür ich aber im List keinen Anhaltspunkt sehe), würde ich dem Schalter als bevorzuges Gerät ein weiter entferntes zuweisen, damit vccu nicht das "optimale" lauteste nimmt.
Zitat von: Pati_Alpha am 07 März 2022, 23:50:33
Das Problem ist: er schaltet manchmal über FHEM sehr langsam.
Genauer gesagt schalte ich ihn dann ein oder aus und es dauert oft zwischen 3-8 Sekunden! Fhem hängt aber in der Zeit nicht.
Nur zur Sicherheit nachgefragt: Du meinst Du machst in FHEM ein set GartenHausLampe und es dauert? Oder Du drückst den Taster an der GartenHausLampe und es dauert 3-8 sec bis Du es in FHEM siehst?
44 resends und die existenz des readings levelMissed zeigen doch deutlich kommunikationsprobleme, oder?
da has Du sicher Recht :) sorry für die Nachfrage ...
Erstmal vielen Dank für eure Hilfe/Tipps!! :)
Zitat von: Otto123 am 08 März 2022, 21:04:54
Nur zur Sicherheit nachgefragt: Du meinst Du machst in FHEM ein set GartenHausLampe und es dauert? Oder Du drückst den Taster an der GartenHausLampe und es dauert 3-8 sec bis Du es in FHEM siehst?
Das erste: Ich schalte in FHEM und es dauert teils 3-8 Sekunden bis das Licht dann wirklich an geht.
Schalte ich am Schalter selbst, geht das Licht sofort an/aus also scheinbar kein physischer Defekt im Aktor.
Ich werde nachher nochmal testen, ob, wenn ich am Schalter schalte, es auch 3-8 Sekunden dauert bis FHEM das sieht.
Zitat von: Pfriemler am 08 März 2022, 20:54:03
Wenn es ein weiteres HM-Interface (IO) gäbe (wofür ich aber im List keinen Anhaltspunkt sehe), würde ich dem Schalter als bevorzuges Gerät ein weiter entferntes zuweisen, damit vccu nicht das "optimale" lauteste nimmt.
Das ist natürlich auch eine gute Idee, aber leider habe ich nur den einen Stick und eigentlich auch nur den einen Rechner an dem ich ihn anbringen kann. :(
Zitat von: frank am 08 März 2022, 22:00:19
44 resends und die existenz des readings levelMissed zeigen doch deutlich kommunikationsprobleme, oder?
=> Ah, wird das internal tatsächlich jedes mal geupdated? Was ist denn hier ein "guter" Wert? 0? :D Ich kann ja mal einen meiner anderen Aktoren schalten und schauen, was dort der "protResnd" sagt?
protokol fehler werden bei fhem restart oder mit "set clear msgevents/msgerrors" zurückgesetzt.
ZitatIch werde nachher nochmal testen, ob, wenn ich am Schalter schalte, es auch 3-8 Sekunden dauert bis FHEM das sieht.
Nur zur Aufklärung meiner Frage: es ist normal, dass es dauert bis der Status des Aktors an FHEM gesendet wird. Hat aber offenbar nichts mit deinem Fall zu tun. War ein Missverständnis von mir ;)
ZitatWas ist denn hier ein "guter" Wert? 0?
Die Einträge protResnd und das Reading levelmissed existieren dann gar nicht. :)
Zitat von: Pati_Alpha am 09 März 2022, 11:10:29
Ich werde nachher nochmal testen, ob, wenn ich am Schalter schalte, es auch 3-8 Sekunden dauert bis FHEM das sieht.
Wie Otto schon sagte: das sollte
2019-09-10 21:40:16 R-statusInfoMinDly 2 s
2019-09-10 21:40:16 R-statusInfoRandom 1 s
also 2-3 Sekuden dauern und wäre völlig normal damit.
Ein zweites IO für Homematic ist immer gut, und etwas besseres als ein CUL sowieso. Dafür reicht im einfachsten Fall ein passendes HM-IO-Modul, ein WEMOS D1 und ein paar kurze Klingeldrähte. Angebunden wird das Ding dann per WLAN und braucht sich dann nur in Reichweite des WLAN zu befinden. Das ist nicht optimal, aber als Zweitgerät immer gut.
Aktuell könntest Du Dir schlicht behelfen (auch zum Testen), indem Du den CUL über eine USB-Verlängerung (so sich sowas profanes in Deinem Haushalt befindet) anschließt und damit die Abstände variierst. In Alufolie einwickeln würde auch gehen, ist aber mit anderen Effekten verbunden.
Grade stand das Device auch einmal auf MISSING ACK.
Das Einschalten per FHEM ging dann Instant, das Ausschalten direkt danach locker 8 Sekunden. :/
ProtRsnd 59!
Also meint ihr resetten, neu pairen etc wird nichts bringen, da von der Config sonst alles ok scheint?
Sind denn alle "Verdächtigen" auf einem guten Stand?
Firmware des CUL
Modul für den CUL
10_CUL_HM.pm
HMConfig.pm
Frank hat doch da einen guten Überblick über die aktuellen Stände?
Oder ist das ein C26 Problem (https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Unterputz-Schaltaktor_1-fach#M.C3.B6gliche_Hardwaredefekte)?
ZitatProtRsnd 59!
wie hast du die funkstrecke verändert?
setze mal verbose=5 beim cul.
anschliessend mehrmals von fhem aus schalten.
dann den log ausschnitt posten.
Zitat von: Otto123 am 10 März 2022, 09:10:43
Sind denn alle "Verdächtigen" auf einem guten Stand?
Firmware des CUL
Modul für den CUL
10_CUL_HM.pm
HMConfig.pm
Frank hat doch da einen guten Überblick über die aktuellen Stände?
Oder ist das ein C26 Problem (https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Unterputz-Schaltaktor_1-fach#M.C3.B6gliche_Hardwaredefekte)?
Ja, das mit dem C26 hatte ich auch überlegt... so "Funktioniert, aber ist langsam etc." klingt ja immer erstmal elektronisch nach Kondensator.
Aber dann würde er glaube ich nicht so sauber schalten, wenn ich selbst den Taster drücke?
Modul für den CUL, 10_CUL_HM.pm und HMConfig.pm werden glaube ich per "update" in FHEM geupdated, oder? Dann wären die aktuell.
CUL-Firmware ist aber ein guter Punkt. Die ist 100% nicht aktuell. Ich nutze den seit etwas über 5 Jahren (Januar 2017) und habe nie die Firmware geupdated. :O
Zitat von: frank am 10 März 2022, 09:38:08
setze mal verbose=5 beim cul.
anschliessend mehrmals von fhem aus schalten.
dann den log ausschnitt posten.
Gute Idee, das teste ich mal und melde mich nochmal! :)
Wichtig:
Zitat von: frank am 10 März 2022, 09:38:08
wie hast du die funkstrecke verändert?
Ohne Änderung lesen wir hier weiter im Kaffeesatz.
C26 halte ich für unwahrscheinlich. Die damit verbundenen Effekte sorgen eigentlich immer für ein unerwartetes Ausschalten, wenngleich es nicht völlig ausgeschlossen ist. Problematisch wird es unter hoher Last, also aktivem Relais und sendendem Funkmodul. Das passiert unmittelbar nach dem Einschalten während der Statusmeldung an die Zentrale, allerdings auch nach dem Empfang des Ausschaltbefehls beim Senden der Quittung an die Zentrale (erst dann wird m.W. ausgeschaltet und der aktive Status erneut gesendet). Nur: Spannungseinbrüche sorgen für einen Reboot, bei dem die Relais auf jeden Fall umgehend abfallen - das Licht würde ausgehen und aus bleiben.
Ich finde kein powerOn-Reading hier (bei mir übrigens auch nicht mehr, seltsam, nur bei einigen Aktoren und dann auch definitiv veraltet - wurde das wegrationalisiert?). Das war eigentlich auch immer ein gutes Indiz für C26-Fehler.
edit: Ich habe tatsächlich mal einen Sw1PBU hier auf den Tisch bekommen, der beschriebenermaßen langsam einschaltete. Da war wirklich der C26, der so knapp geworden war, dass das Relais beim Einstromen im Schleichgang schloss: Bei dem kam die Rückmeldung an die Zentrale sofort und vermutlich erst nach dem Abschalten des Senders war genug Saft da, um das Relais endgültig zu ziehen. Es schaltete auch hörbar leiser als normal.
Also bitte: "verschlechtete" mal gezielt die Funkstrecke und schaue, ob sich die Probleme dadurch auflösen oder bestehen bleiben. Ein Konfigurationsproblem ist eigentlich so unwahrscheinlich, dass ich einen Reset nicht in Betracht ziehen würde. Wenn sich das unwillige Schalten auch bei schlechter Verbindung hält, müsste man neu überlegen. "Schlecht" sollten die rssi unter -50, besser unter -60 liegen. Eine große Blechkiste über dem RPi samt CUL in Richtung Schalter sollte da schon eine deutliche Veränderung zeigen.
Erstes Ergebnis:
Ich habe mal die Antenne wie einen Zauberstab GENAU auf den Aktor gerichtet (:D), denn Stabantennen senden ja im Prinzip donutfömig um ihre Achse herum das meiste Signal aus.
Daher habe ich den Aktor quasi in den Blind-Spot der Antenne gebracht und zumindest die ersten Tests waren deutlich besser!
LogLevel 5 folgt aber noch!
Zitat von: Pfriemler am 10 März 2022, 16:01:57
C26 halte ich für unwahrscheinlich.
Ja, ich tatsächlich von der Charakteristik des Fehlerbilds auch. Manuell/lokal schaltet der Aktor ja perfekt.
Frustrierend ist halt auch einfach, dass all meine anderen HomeMatic Aktoren SO SCHNELL und sauber schalten...! :D
Ich werde mit Abschirmung zumindest temporär nochmal experimentieren. Wenn es dann sicher das ist, denke ich wirklich über ein weiteres Funkmodul nach. Schon verrückt - extra einen Sender kaufen, damit man ihn "schlechter" platzieren kann. :D
Zitat von: Pati_Alpha am 11 März 2022, 10:17:23
Ja, ich tatsächlich von der Charakteristik des Fehlerbilds auch. Manuell/lokal schaltet der Aktor ja perfekt.
Ohne das "elektronisch" erklären zu können - meine ich: jedes Fehlerbild ist denkbar. Das ist wie mit einem kaputten Dateisystem... ;D
Zumal ich Taster und Aktor im Abstand von 2 cm verbaut habe (rssi um die 20) und noch nie eine Funkstörung hatte. Aber offenbar ist bei der Zentrale - Aktor anders?
Zitat von: Pati_Alpha am 11 März 2022, 10:17:23
... Antenne wie einen Zauberstab GENAU auf den Aktor gerichtet ... Donut ... Blind-Spot ...
Ja klar! Und die Ergebnisse deuten schon mal auf eine Verbesserung hin.
Ja, es ist schon ein wenig verrückt, zumal andere Hardwarefamilien das offenbar besser hinbekommen. Im konkreten Fall könntest Du noch überlegen, den Aktor gezielt "tauber" zu machen, bspw. die Antenne intern drastisch zu kürzen (aufwickeln sollte nicht reichen nach meinen bescheidenen HF-Kenntnissen). Der sendet dann zwar auch schlechter, aber das ist bei der Nähe dann auch kein Problem. Einen Schaden sollte die Sendestufe bei den Leistungen aufgrund einer Fehlanpassung eigentlich nicht nehmen, zumindest habe ich davon noch nie gehört. Beherzter Einsatz von Alufolie in der Unterputzdose wurde auch hin und wieder versucht etwa bei direktverknüpften Sendern und Aktoren in benachbarten Unterputzdosen - da isses eigentlich noch übler. Ein Wunder, dass Otto keine Probleme damit hat.
Zitat von: Pfriemler am 11 März 2022, 12:00:59
Im konkreten Fall könntest Du noch überlegen, den Aktor gezielt "tauber" zu machen, bspw. die Antenne intern drastisch zu kürzen (aufwickeln sollte nicht reichen nach meinen bescheidenen HF-Kenntnissen).
Da hab ich tatsächlich auch schon drüber nachgedacht! :D
Und ja, mein etwas zurückliegendes Physikstudium sagt glaube ich auch, dass Wickeln nicht hilft - nur Kürzen. :) Aber gute Idee!