Hallo,
ich habe mit einem Homematic 4 fach Aktor "Aktor=01_Garten" ein Problem und zwar nur im Kanal 3 "Rudi.Li"
Einschalten des channel_03 Rudi.Li über die Kommadozeile mit set Rudi.Li on funktioniert prima. Rückmeldung, alles ok.
Ausschalten des channel_03 Rudi.Li über die Kommandozeile mit set Rudi Li off funktioniert nicht, Rückmeldung zeigt das rote Ausrufzeichen auf dem "Lichtsymbol" im Deviceoverview, der Aktor reagiert auch nicht. Das device "Aktor=01_Garten" zeigt Cmds done_Errors 1 und missing Ack im state.
Der Aktor ist etwas weit vom Raspberry entfernt, die übrigen 3 Kanäle funktionieren aber. Auch der channel_03 hat bereits längere Zeit zuverlässig funktioniert, ich meine nichts geändert zu haben.
Internals:
DEF 43D9AB03
FUUID 5c481922-f33f-64ff-317d-d1e03f93fd0e0167
NAME Rudi.Li
NOTIFYDEV global
NR 92
NTFY_ORDER 50-Rudi.Li
STATE set_off
TYPE CUL_HM
chanNo 03
device AKTOR01_GARTEN
READINGS:
2019-03-09 15:03:53 CommandAccepted yes
2019-02-02 16:13:25 R-H.Str_Btn_02-lgActionType jmpToTarget
2019-02-02 16:13:25 R-H.Str_Btn_02-shActionType jmpToTarget
2019-02-02 16:13:23 R-powerUpAction off
2019-02-02 16:13:23 R-sign off
2019-03-09 15:03:53 deviceMsg on (to VCCU)
2019-03-09 15:03:53 level 100
2019-02-03 10:42:53 levelMissed desired:0
2019-03-09 15:03:53 pct 100
2019-03-09 15:03:53 recentStateType ack
2019-03-09 15:04:29 state set_off
2019-03-09 15:03:53 timedOn off
2019-03-09 15:04:29 trigLast fhem:02
2019-02-03 20:39:43 trig_H.Str_Btn_02 Short_44
helper:
dlvl 00
dlvlCmd ++A01107065743D9AB0203000000
getCfgList all
getCfgListNo ,3
regLst ,1,3p
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
tmpl:
Attributes:
DbLogExclude .*
genericDeviceType switch
model HM-LC-SW4-DR
peerIDs 00000000,
room Alarm,GARTENHAUS
webCmd statusRequest:toggle:on:off
Internals:
DEF 43D9AB
FUUID 5c481922-f33f-64ff-3c5c-6781476d57d6b599
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 22
NAME AKTOR01_GARTEN
NOTIFYDEV global
NR 89
NTFY_ORDER 50-AKTOR01_GARTEN
STATE MISSING ACK
TYPE CUL_HM
channel_01 G.Pan.Li
channel_02 G.Weg.Li
channel_03 Rudi.Li
channel_04 AKTOR01_GARTEN_Sw_04
lastMsg No:47 - t:02 s:43D9AB d:070657 0103C80064
myHmUART_MSGCNT 22
myHmUART_RAWMSG 0403005347800243D9AB0706570103C80064
myHmUART_RSSI -83
myHmUART_TIME 2019-03-09 15:03:53
protCmdDel 29
protLastRcv 2019-03-09 15:03:53
protRcv 20 last_at:2019-03-09 15:03:53
protResnd 45 last_at:2019-03-09 15:04:45
protResndFail 11 last_at:2019-03-09 15:04:51
protSnd 39 last_at:2019-03-09 15:04:29
protState CMDs_done_Errors:1
rssi_at_myHmUART cnt:22 min:-86 max:-80 avg:-84.27 lst:-83
rssi_myHmUART cnt:18 min:-101 max:-94 avg:-97.38 lst:-100
READINGS:
2019-02-07 21:41:12 CommandAccepted yes
2019-01-06 10:41:33 D-firmware 2.8
2019-01-06 10:41:33 D-serialNr MEQ1810146
2019-03-09 14:54:28 PairedTo 0x070657
2019-01-06 10:41:38 R-pairCentral 0x070657
2019-03-09 14:54:28 RegL_00. 00:00 02:01 0A:07 0B:06 0C:57 15:FF 18:00
2019-02-02 17:49:45 powerOn 2019-02-02 17:49:45
2019-03-09 15:04:51 state MISSING ACK
helper:
HM_CMDNR 72
cSnd 1107065743D9AB0203C80000,1107065743D9AB0203000000
mId 0061
regLst ,0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +43D9AB,00,00,00
nextSend 1552140233.66987
rxt 0
vccu VCCU
p:
43D9AB
00
00
00
prefIO:
myHmUART
mRssi:
mNo 47
io:
myHmUART:
-81
-81
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rssi:
at_myHmUART:
avg -84.2727272727273
cnt 22
lst -83
max -80
min -86
myHmUART:
avg -97.3888888888889
cnt 18
lst -100
max -94
min -101
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
IODev myHmUART
IOgrp VCCU:myHmUART
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
genericDeviceType switch
icon light_fairy_lights
model HM-LC-SW4-DR
room GARTENHAUS,CUL_HM
serialNr MEQ1810146
subType switch
webCmd getConfig:clear msgEvents
Uwe: ab rssi -80 kann alles gehen, muss aber nicht. Der hat
min:-101 max:-94 avg:-97.38
das ist im Mittel ein 25stel von dem Pegel der die Grenze wäre.
Durch Einschalten verschlechtert sich offenbar der Funk, der Verbraucher stört.
Ich denke alles verhält sich richtig. Du musst einen IO in die Nähe bringen oder den Empfang verbessern.
Hallo Otto,
Danke für die wie immer schnelle Antwort,
leider habe ich gerade das erwartet und stehe jetzt vor einem grösseren Problem. Bisher war alles ok, wahrscheinlich grenzwertig mit dem Funk, jetzt aber wahrscheinlich Temperatur, Feuchte, etc..
Und die Verbindung muss sicher sein.
Leider habe ich jetzt Zeitnot, da ich in wenigen Tagen auch von hier weg bin, bin gerade in den letzten Zügen, alle Fehler raus zu machen etc. und das transportable System für die langen Stunden einzurichten (Stichwort Vagabundi).
Ich hab in der Nähe des Aktors nicht direkt Lan aber sicherlich ok. Hardware sollte auch nicht das Thema sein, einen Raspberry 2 und ein Funkmodul habe ich auch noch, auch einen CUL.
Aber die entsprechende Softwareinstallation für ein weiteres I/O hab ich noch nie gemacht. Ist FHEM2FHEM ein Stichwort dazu?
Kannst du mir einen Link zu einem Einstig schicken, an dem ich mich heranhangeln kann.
Danke
Hab ich da überhaupt ne Chance?
Warum Kain wifi hm gateway auf wemos Basis?
Gesendet von meinem Doogee S60 mit Tapatalk
Hin Frank_Huber,
ich habe in dieser Richtung noch gar nicht gemacht und kann deshalb Schwieigkeit und Aufwand nicht einschätzen. Hast du dazu noch ne Antwort?
Uwe
Naja wenn DU den Raspberry irgendwie in die Nähe bekommst (LAN oder WLAN), dann als Remote IO so wie hier beschrieben. ser2net würde ich machen.
Das Ganze unter einer VCCU, ist relativ easy.
Hallo,
wenn Du es so eingibst:
über die Kommandozeile mit set Rudi Li off funktioniert nicht
wird es vermutlich nicht funktionieren. Vielleicht hast Du dich aber hier auch nur verschrieben.
set Rudi.Li off
Gruß Rolf
Hallo Rolf,
war nur ein Schreibfehler. Hab jetzt mal ne mechanische Lösung versucht.
Raspberry umgesetzt!
Hier sind die Werte jetzt, besser ab immer noch grenzwertig.
Zitatrssi_at_myHmUART cnt:16 min:-81 max:-78 avg:-79.75 lst:-79
rssi_myHmUART cnt:16 min:-93 max:-87 avg:-90.87 lst:-89
Dies sind doch die wichtigen Werte?
Die Funktion ist gegeben. Zumindest jetzt gerade. Werde testen. Kann man beim HM-Funkmodul die Antenne verlängern, modifizieren. Bringt das was?
Verlängern ist nicht das Richtige. Heraus aus dem Gehäuse damit, das bringt was. Auf beiden Seiten!
Achtung Netzspannung, also am Aktor vielleicht keine gute Idee.
Blech in der Nähe vermeiden.
Kabelführung aussen am Aktor ev. modifizieren.
Den Ringkern (der beim HMUART Modul dabei ist) wie vorgeschrieben um die Spannungsversorgung des Pi bauen.
Manchmal bringen ein paar cm links rechts oben unten was.
Hallo Otto,
vielen Dank, werde alles so richten und hoffen, dass es stabil läuft. Die Idee mit dem StromPi3 als Notstromversorgung war leider ein Flop.
Danke nochmals
Zitat von: UweUwe am 09 März 2019, 18:40:17
Hin Frank_Huber,
ich habe in dieser Richtung noch gar nicht gemacht und kann deshalb Schwieigkeit und Aufwand nicht einschätzen. Hast du dazu noch ne Antwort?
Uwe
Hi,
Nichts einfacher als das.
Module werden immer wieder im Marktplatz angeboten.
Strom dran, mit dem wemos WLAN verbinden, deine WLAN Daten eingeben und dann nur noch über IP Adresse in fhem einbinden.
Gesendet von meinem Telekom Puls mit Tapatalk
Das ist ja toll, muss ich gleich mal anschauen
Hi, die Lösung mit dem wemos WLAN verbinden war ja leider schon vergriffen.
Was haltet ihr von folgender Lösung?
https://technikkram.net/2017/10/raspberrymatic-raspberry-pi3-als-wlan-gateway-verwenden?
Nö bevor Du von hinten durch die Brust: nimmst Du einfach den Pi und das Modul und machst es mit ser2net.
Rasbperrymatic braucht es nicht.
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Du kannst aber auch einen Wemos und das RPI-PCB Modul mit Strippen zusammenstecken. An welchen Fähigkeiten klemmt es denn?
Gruß Otto
Uwe,
ich könnte Dir eines von meinen Wemos HM Gateways abtreten.
hab dann paar Tage schlechte RSSI Werte an einem Gerät, aber das macht nix. bis zu nächsten WE hab ich mein LAN Gateway fertig. :-)
Grüße
Frank
Hallo Frank , hab dir ne PM geschickt.
Hab mit meinem Wemos ein Thema. Der angeschlossene 4 fach Aktor schält nicht mehr und zeigt unbestimmte Zustände. Ich glaube , dass er keine Rückmeldung bekommt.
[Internals:
AssignedPeerCnt 1
CNT 125
Clients :CUL_HM:
DEF uart://192.168.10.74:23
DEVCNT 125
DevState 99
DevType UART
DeviceName 192.168.10.74:23
FD 39
FUUID 5c892cba-f33f-64ff-f9ff-c5c529ae97f3014b
LastOpen 1553191539.53255
NAME Wemos_HM_GW
NR 285
PARTIAL
RAWMSG 040200
RSSI -62
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 0
msgLoadHistory 0/0/0/0/0/-1/0/0/0/0/0/0
msgLoadHistoryAbs 0/0/0/0/0/0/1/1/1/1/1/1/1
owner 070657
owner_CCU VCCU
Helper:
CreditTimer 364
FW 66561
Initialized 1
AckPending:
LastSendLen:
3
3
Log:
IDs:
PeerQueue:
RoundTrip:
Delay 0.0886640548706055
loadLvl:
lastHistory 1553196942.17653
MatchList:
1:CUL_HM ^A......................
Peers:
68DB70 +68DB70,00,00,00
READINGS:
2019-03-21 19:05:42 D-HMIdAssigned 070657
2019-03-21 19:05:42 D-HMIdOriginal 59DB4E
2019-03-21 19:05:42 D-firmware 1.4.1
2019-03-21 19:05:42 D-serialNr OEQ0607792
2019-03-13 17:33:43 D-type HM-MOD-UART
2019-03-21 19:05:42 cond ok
2019-03-21 20:10:29 load 0
2019-03-21 19:05:42 loadLvl low
2019-03-21 19:05:39 state opened
helper:
Attributes:
DbLogExclude .*
hmId 070657
room HomeMatic
Der betroffene 4 fach Aktor sieht so aus , eine Wand und 4 Meter vom WEMOS entfernt . Hier ist nur ein Kanal dargestellt, alle Kanäle sind undefiniert
Internals:
DEF 43D9AB
FUUID 5c481922-f33f-64ff-3c5c-6781476d57d6b599
IODev myHmUART
LASTInputDev Wemos_HM_GW
MSGCNT 43
NAME AKTOR01_GARTEN
NOTIFYDEV global
NR 88
NTFY_ORDER 50-AKTOR01_GARTEN
STATE MISSING ACK
TYPE CUL_HM
Wemos_HM_GW_MSGCNT 22
Wemos_HM_GW_RAWMSG 05000045AA800243D9AB0706570102C84059
Wemos_HM_GW_RSSI -69
Wemos_HM_GW_TIME 2019-03-20 20:19:06
channel_01 G.Pan.Li
channel_02 G.Weg.Li
channel_03 Rudi.Li
channel_04 AKTOR01_GARTEN_Sw_04
lastMsg No:AA - t:02 s:43D9AB d:070657 0102C84059
myHmUART_MSGCNT 21
myHmUART_RAWMSG 0403004FAA800243D9AB0706570102C84059
myHmUART_RSSI -79
myHmUART_TIME 2019-03-20 20:19:06
protCmdDel 23
protLastRcv 2019-03-20 20:19:06
protRcv 22 last_at:2019-03-20 20:19:06
protResnd 38 last_at:2019-03-21 19:43:53
protResndFail 12 last_at:2019-03-21 19:43:58
protSnd 39 last_at:2019-03-21 19:43:40
protState CMDs_done_Errors:1
rssi_at_Wemos_HM_GW cnt:22 min:-77 max:-67 avg:-73.45 lst:-69
rssi_at_myHmUART cnt:21 min:-87 max:-79 avg:-83.09 lst:-79
rssi_myHmUART cnt:21 min:-98 max:-89 avg:-94.28 lst:-89
READINGS:
2019-02-07 21:41:12 CommandAccepted yes
2019-01-06 10:41:33 D-firmware 2.8
2019-01-06 10:41:33 D-serialNr MEQ1810146
2019-03-09 14:54:28 PairedTo 0x070657
2019-01-06 10:41:38 R-pairCentral 0x070657
2019-03-09 14:54:28 RegL_00. 00:00 02:01 0A:07 0B:06 0C:57 15:FF 18:00
2019-02-02 17:49:45 powerOn 2019-02-02 17:49:45
2019-03-21 19:43:58 state MISSING ACK
helper:
HM_CMDNR 182
cSnd 1107065743D9AB0203000000,1107065743D9AB0202000000
mId 0061
regLst ,0
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +43D9AB,00,00,00
nextSend 1553109546.41898
rxt 0
vccu VCCU
p:
43D9AB
00
00
00
prefIO:
myHmUART
mRssi:
mNo AA
io:
Wemos_HM_GW:
-69
-69
myHmUART:
-77
-77
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_Wemos_HM_GW:
avg -73.4545454545455
cnt 22
lst -69
max -67
min -77
at_myHmUART:
avg -83.0952380952381
cnt 21
lst -79
max -79
min -87
myHmUART:
avg -94.2857142857143
cnt 21
lst -89
max -89
min -98
tmpl:
Attributes:
DbLogExclude .*
IODev myHmUART
IOgrp VCCU:myHmUART
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
genericDeviceType switch
icon light_fairy_lights
model HM-LC-SW4-DR
room GARTENHAUS,CUL_HM
serialNr MEQ1810146
subType switch
webCmd getConfig:clear msgEvents
Wo liegt mein Fehler
Hi,
naja der hat IOgrp VCCU:myHmUART
eingetragen. Und Der ist nicht der Beste:
rssi_myHmUART cnt:21 min:-98 max:-89 avg:-94.28 lst:-89
Mach doch daraus einfach VCCU dann regelt die das?
Gruß Otto
Hallo Otto, schön von dir zu hören. Da ich physikalisch darauf die nächsten Wochen keinen Zugriff habe , nochmals eine Nachfrage. Hab hier schlechte Erfahrung gemacht. Dazu melde ich mich noch.
Aktuell steht
IOgrp VCCU:myUART
und ich soll es verändern auf
IOgrp VCCU
korrekt ?
ja. damit steht kein preffered IO mehr, der offenbar nicht der Beste ist.
Hi, hab ich gemacht, WEMOS ist weiterhin an dem Aktor aktiv. Ich hab ihn auch installiert genau für diesen Zweck, den WEMOS und er hat auch seine Dienste getan, wenige Tage. Eigentlich war nur nur der Kanal 1 schwach, die übrigen Kanäle des Aktors taten ihren Dienst, jetzt ist das Phänomen auf allen Kanälen.
Wie gut ist das wlan?
Hat evtl der Aktor ein Antennen Problem?
Ich hab hier 3 IO Module über VCCU.
Lief über WLAN 2 Jahre stabil, jetzt seit der Umstellung über LAN.
Gesendet von meinem Doogee S60 mit Tapatalk
Hi, kann ich den wemos einfach mal inaktiv setzten ?
Dann sollte ja der ursprüngliche I/o wieder dran gehen.
Wlan ist an der Stelle top
dann einfach ein set Wemos_HM_GW close absetzen.
Hast die IOgrp umgestellt wie Otto es vorgeschlagen hat?
und falls es das Attribut IOdev gibt, das kannst löschen.
Hier ein Beispielaktor der über die VCCU läuft:
defmod HM_Bewegung_Garten CUL_HM 69F568
attr HM_Bewegung_Garten IOgrp VCCU
attr HM_Bewegung_Garten actCycle 000:30
attr HM_Bewegung_Garten actStatus alive
attr HM_Bewegung_Garten autoReadReg 4_reqStatus
attr HM_Bewegung_Garten expert 2_raw
attr HM_Bewegung_Garten firmware 1.7
attr HM_Bewegung_Garten model HM-Sen-MDIR-O-3
attr HM_Bewegung_Garten peerIDs 00000000,
attr HM_Bewegung_Garten serialNr PEQ00000000
attr HM_Bewegung_Garten subType motionDetector
wie sieht deine VCCU aus? sind die Gateways da sauber drin?
Hallo, ich habe die IOgrp Umstellung gemäss Otto gemacht. Es hat sich nichts geändert, da da sich WEMOS wieder eingebracht ist. Er sitzt ja auch am nächsten zu dem 4 fach Aktor. Und ich habe den Wemos dort örtlich installiert, da der direkte Draht vom RPI zu dem 4 fach Aktor nicht gut war, ab er komischerweise besser als jetzt. Eigentlich ging bisher nur ein Kanal des 4 fach Aktors nicht zuverlässig, jetzt geht kein Kanal mehr.
Mit dem Wemos gingen jedoch die Kanäle alle schon mal. Zuverlässig, das weiss ich nicht, zu wenig Testzeit stand leider zur Verfügung.
Ich kann mir auch vorstellen, dass der Aktor ein Thema hat, gibt es da eine Möglichkeit, diesen 4 fach Aktor neu zu starten, falls ich da drauf komme?
Ich hatte jetzt den Wemos die Nacht über aus und heute Vormittag geöffnet. Das ist das list der VCCU
Internals:
DEF 070657
FUUID 5c481922-f33f-64ff-6e3c-da736185b158c4c7
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 7048
NAME VCCU
NOTIFYDEV global
NR 57
NTFY_ORDER 50-VCCU
STATE myHmUART:ok,Wemos_HM_GW:ok
TYPE CUL_HM
Wemos_HM_GW_MSGCNT 5828
Wemos_HM_GW_RAWMSG 0500004223800207065769791200
Wemos_HM_GW_RSSI -66
Wemos_HM_GW_TIME 2019-03-22 09:44:47
assignedIOs Wemos_HM_GW,myHmUART
channel_01 RAUCHMELDER_Team
channel_02 VCCU_Btn2
channel_03 VCCU_Btn3
channel_04 VCCU_Btn4
channel_05 VCCU_Btn5
channel_06 VCCU_Btn6
channel_07 VCCU_Btn7
channel_08 VCCU_Btn8
channel_09 VCCU_Btn9
channel_0A VCCU_Btn10
channel_0B VCCU_Btn11
channel_0C VCCU_Btn12
channel_0D VCCU_Btn13
channel_0E VCCU_Btn14
channel_0F VCCU_Btn15
channel_10 VCCU_Btn16
channel_11 VCCU_Btn17
channel_12 VCCU_Btn18
channel_13 VCCU_Btn19
channel_14 VCCU_Btn20
channel_15 VCCU_Btn21
channel_16 VCCU_Btn22
channel_17 VCCU_Btn23
channel_18 VCCU_Btn24
channel_19 VCCU_Btn25
channel_1A VCCU_Btn26
channel_1B VCCU_Btn27
channel_1C VCCU_Btn28
channel_1D VCCU_Btn29
channel_1E VCCU_Btn30
lastMsg No:C2 - t:11 s:070657 d:43D9AB 0201000000
myHmUART_MSGCNT 1220
myHmUART_RAWMSG 0500003CC2A01107065743D9AB0201000000
myHmUART_RSSI -60
myHmUART_TIME 2019-03-22 09:54:54
protLastRcv 2019-03-22 09:54:39
protRcv 3440 last_at:2019-03-22 09:54:39
protRcvB 115 last_at:2019-03-22 08:07:23
rssi_at_Wemos_HM_GW cnt:4596 min:-81 max:-65 avg:-69.76 lst:-66
rssi_at_myHmUART cnt:255 min:-68 max:-59 avg:-62.15 lst:-60
READINGS:
2019-03-22 09:44:47 CommandAccepted yes
2019-03-22 08:02:26 IOopen 2
2019-03-22 08:02:26 state myHmUART:ok,Wemos_HM_GW:ok
2019-03-17 07:45:29 unknown_121059 received
2019-03-02 17:55:35 unknown_325B86 received
2019-01-06 09:12:24 unknown_36569B received
helper:
HM_CMDNR 194
PONtest 1
mId FFF0
regLst ,0
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
nextSend 1553244894.44479
prefIO
vccu VCCU
ioList:
myHmUART
Wemos_HM_GW
mRssi:
mNo C2
io:
Wemos_HM_GW:
-66
myHmUART:
-56
-56
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_Wemos_HM_GW:
avg -69.7615317667539
cnt 4596
lst -66
max -65
min -81
at_myHmUART:
avg -62.1529411764705
cnt 255
lst -60
max -59
min -68
tmpl:
Attributes:
DbLogExclude .*
IODev myHmUART
IOList myHmUART,Wemos_HM_GW
IOgrp VCCU
expert 2_raw
model CCU-FHEM
room HomeMatic
subType virtual
webCmd virtual:update
Die unknowns rühren von einer 2. Raspberry Installation her.
Ich tippe auch auf den 4 fach Aktor. Aber komisch ist es schon.
Aktor neu starten bedeutet Strom weg und wieder dran ...
Die vier Kanäle des Aktors können eigentlich nicht unterschiedlich sein. Es wird ja alles über ein Devices empfangen und gesendet.
Es könnte sein, dass das was die Kanäle schalten separat zu Störungen führt und damit zu einem unterschiedlichem Verhalten.
Du kannst den Wemos ja als preferred IO eintragen.
IOgrp VCCU:Wemos_HM_GW
1. der aktor hat eventuell auch einen leichten "hörschaden". im letzten list gab es rssi unterschiede von etwa 10 punkten.
2. ist der aktor in einen metallschrank eingebaut?
3. der wemos uart zeigt im list ein roundtrip delay von ca 90ms. ich würde mal kontrollieren, ob dieser wert konstant bleibt. dazu würde ich vorübergehend (eventuell 30 min) das attribut logIDs=sys beim uart setzen, und anschliessend die roundtrip delay in fhem log begutachten.
Eine weitere Möglichkeit:
Die Last am channel 3 stört den Funk. daher hier kein Ausschakten.
Den Aktor ohne Lasten an den Kanälen testen wäre gut.
man kann auch mit on-for-timer ausschalten - so als workaround wenn es funktioniert
Hi Wuooi68, danke für den gutgemeinten Tip, aktuell geht aber an dem Aktor weder Ein- noch Ausschalten.
Kannst du einmal sniffen wenn nicht geanrwortet wird? Alle ios sniffen lassen, parallel. Und einmal wenn etwas klappt