Hi,
ich habe festgestellt, dass mein HM-MOD-Em-8 wohl teilweise ausgelöste Signale nicht richtig an fhem übermittelt hat.
Habe an dem Modul 2 Eingänge in Benutzung. Einer als Sensor-Modus um die Betriebszeit eines Ölbrenners zu loggen, und einen als Trigger-Modus, welcher die Wasseruhr überprüft.
Zwischen meiner Wasseruhr und der Anzeige in FHEM gibt es nun eine Differenz (Wasseruhr hat mehr als FHEM). Dies kann kaum an nicht erkannten Signalen der Wasseruhr liegen, die sind sehr zuverlässig.
Das Modul hat auch guten Empfang und wird nicht bewegt.
Könnte es sein dass die Übermittlung manchmal nicht funktioniert weil vielleicht zufällig beide Kanäle übermitteln wollen?
Kann man das Modul dazu bringen zu prüfen ob die Übertragung fehlerhaft war und dann die Nachricht erneut senden lassen?
hier noch kurz ein List des entsprechenden Kanals:
Internals:
DEF 3D650608
NAME hk_hmSM_Wasseruhr
NOTIFYDEV global
NR 102
NTFY_ORDER 50-hk_hmSM_Wasseruhr
STATE 119.645 qm
TYPE CUL_HM
chanNo 08
device hk_hmSM
Readings:
2016-11-01 19:58:47 R-sign off
2016-11-04 17:09:56 RegL_01. 04:10 08:00 20:60 23:05 30:03 92:23 00:00
2016-11-13 15:29:15 state Short (to HMLAN1)
2016-11-13 15:29:15 trigDst_323CAD noConfig
2016-11-13 15:29:15 trigger Short_21
2016-11-13 15:29:15 trigger_cnt 21
2016-11-13 15:29:15 verbrauch 917
2016-11-13 15:29:15 wasseruhr 119.645
2016-11-13 15:29:15 wasseruhrLiterOffset 118728
Helper:
BNO 21
BNOCNT 1
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Attributes:
model HM-MOD-Em-8
peerIDs 00000000,
room Heizkeller
stateFormat {sprintf("%.3f"." qm",ReadingsVal('hk_hmSM_Wasseruhr','wasseruhr',0));}
userReadings verbrauch:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch", 0)+1;}, wasseruhrLiterOffset { 118728;}, wasseruhr:trigger_cnt.* {(ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch", 0)+ReadingsVal("hk_hmSM_Wasseruhr", "wasseruhrLiterOffset", 0))/1000;}
Viele Grüße
reen
das Device hat je Kanal ein "transmitTryMax" . Eine Kollision innerhalb des Devices sollte das Device selbst kontrollieren. Ein Kanal sendet nicht, senden wird immer das "Device". Das wäre ein böses FW-foul.
Allerdings kann es eine Kollision "in der Luft" geben. Dafür gibt es ein retransmit.
Da aber dein KAnal nicht gepeer ist könnte es sein, dass es kein ACK erwartet. Also wird es auch kein retransmit geben.
Peere das Device mit einem Kanal der VCCU. Suche dir einen aus deiner Wahl- das macht am meisten Sinn.
Danke Martin, da bin ich noch nicht ganz durchgestiegen.
Ich habe ein HM_Lan-Adapter, mit dem ich direkt paire, ohne eine VCCU.
Gepairt ist das HM-MOD-EM-8 also direkt über den Lanadapter.
list:
Internals:
DEF 3D6506
HMLAN1_MSGCNT 536
HMLAN1_RAWMSG E3D6506,0000,10BB7EB3,FF,FFD0,DFA2413D6506323CAD01BFC8
HMLAN1_RSSI -48
HMLAN1_TIME 2016-11-14 14:23:31
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 536
NAME hk_hmSM
NOTIFYDEV global
NR 99
NTFY_ORDER 50-hk_hmSM
STATE CMDs_done
TYPE CUL_HM
channel_01 hk_hmSM_Brenner
channel_02 hk_hmSM_Btn_02
channel_03 hk_hmSM_Btn_03
channel_04 hk_hmSM_Btn_04
channel_05 hk_hmSM_Btn_05
channel_06 hk_hmSM_Btn_06
channel_07 hk_hmSM_Btn_07
channel_08 hk_hmSM_Wasseruhr
lastMsg No:DF - t:41 s:3D6506 d:323CAD 01BFC8
protLastRcv 2016-11-14 14:23:31
protSnd 536 last_at:2016-11-14 14:23:31
protState CMDs_done
rssi_at_HMLAN1 avg:-48.3 min:-50 max:-47 lst:-48 cnt:536
Readings:
2016-11-04 17:14:51 CommandAccepted yes
2016-11-04 17:13:13 D-firmware 1.1
2016-11-04 17:13:13 D-serialNr MEQ0782171
2016-11-04 17:09:48 PairedTo 0x323CAD
2016-11-01 19:58:39 R-pairCentral 0x323CAD
2016-11-04 17:09:48 RegL_00. 02:01 05:00 0A:32 0B:3C 0C:AD 12:00 14:03 18:00 00:00
2016-11-08 19:02:27 alive yes
2016-11-14 14:23:31 battery ok
2016-11-08 19:02:27 powerOn 2016-11-08 19:02:27
2016-11-08 19:02:27 recentStateType info
2016-11-14 14:23:31 state CMDs_done
Helper:
HM_CMDNR 223
mId 00D9
rxType 16
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3D6506,00,00,00
nextSend 1479129811.69363
prefIO
rxt 2
vccu
p:
3D6506
00
00
00
Mrssi:
mNo DF
Io:
HMLAN1 -46
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rpt:
IO HMLAN1
flg A
ts 1479129811.6102
ack:
HASH(0x3392830)
DF8002323CAD3D650600
Rssi:
At_hmlan1:
avg -48.3059701492538
cnt 536
lst -48
max -47
min -50
Attributes:
IODev HMLAN1
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
model HM-MOD-Em-8
room CUL_HM
serialNr MEQ0782171
subType remote
webCmd getConfig:clear msgEvents
Mit dem peeren habe ich noch keine Erfahrungen, und daher gerade mal das wiki durchschaut.
Laut dem wiki Eintrag ist das peeren von Kanälen dazu da, dass die Kanäle auch ohne Zentrale kommunizieren können.
So ein peeren mit der "Zentrale" erscheint mir dann erstmal unlogisch?
Wenn du sagt, es sendet nur das device, welches ich ja eh schon gepairt habe, denke ich erstmal, das müsste reichen.
Aber ich glaub das natürlich und würde es gerne besser verstehen. :)
Geht das ohne VCCU dann hiermit: set <actChan> peerIODev <IO> <chan> [set|unset] ?
Muss der <chan> vorher noch definiert werden, und wie bekommt das HM-MOD-EM-8 dieses peering mit?
Hi,
ZitatSo ein peeren mit der "Zentrale" erscheint mir dann erstmal unlogisch?
Hier geht es um eine spezielle Eigenschaft:
Ein nicht gepeerter Kanal sendet einfach eine Nachricht, ihm ist egal ob es jemand hört oder nicht. Eine Telegramm und fertig.
Ein gepeerter Kanal erwartet eine Quittung vom Empfänger, kommt die nicht versucht er es erneut. Bis zu dreimal.
Wenn man einen Taster z.B. mit einem Virtuellen Aktor peert, erhält der Taster eine Quittung von der Zentrale und seine LED blinkt grün ansonsten nur gelb.
Würde ein Telegramm verloren gehen, würde der EM-08 einer Wiederholung machen.
Gruß Otto
Aha, das machts schon etwas klarer, danke Otto!
Dann würde ich wie folgt vorgwehen:
ausführen: set 1 peerIODev HMLAN1 hk_hmSM_Wasseruhr
HM-MOD-EM-8 aufwecken, damit es die config übermittelt bekommt.
Fertig!?
1 steht dann für den Kanal 1 der Zentrale wenn ich das richtig verstanden habe.
Muss man den erst anlegen oder prüfen ob da schon etwas gepeert ist?
Edit:
vielleicht könnte mir ja jemand kurz ein tipp geben, ob das geschilderte vorgehen und der Befehl so passen, oder ob ich auf dem Holzweg bin. Ein entsprechendes komplettes Beispiel habe ich nicht gefunden.
Hallo reen,
wie das mit dem IOdev geht, weiß ich nicht. betateilchen hat das glaube ich mal beschrieben.
Hier (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU#Virtuelle_Kan.C3.A4le_der_VCCU) ist beschrieben wie man virtuelle Kanäle erzeugt.
Ein virtueller Kanal ist von der Sache her wie ein universelles HM Gerät.
gepeert wird mit dem Kommando peerChan, das findest Du im set Befehl in der Oberfläche des Kanal Deines EM-8. Als Aktor wird ein virtueller Kanal angegeben, den Namen findest Du bei der VCCU. Hinter peerChan musst Du noch Parameter angeben:
0 <Name des Virtuellen Kanals> single set both.
Hier (http://heinz-otto.blogspot.de/2016/07/garagentor-mit-fhem-bedienen.html)habe ich das peering für meinen Garagenantrieb beschrieben. Falls Du noch ein paar praktische Ideen brauchst ;)
Gruß Otto
Hi Otto,
danke für die Hilfe!
Eine VCCU habe ich nicht, daher dachte ich, dass der peerIODev vielleicht passt.
Wäre es möglich eine VCCU anzulegen, und diese dann nur für das peeren zu verwenden, auch wenn diese eine andere hmid besitzt? - dann würde ich dafür eine anlegen. (ich würde nur ungern eine VCCU mit dem Lan-Adapter verwenden.)
Zitat0 <Name des Virtuellen Kanals> single set both.
Was bedeutet denn die "0" und das "both"?
...und gibt es eigentlich eine Möglichkeit die Channels der VCCU oder des IODevs anzuzeigen?
Zitat von: reen am 14 November 2016, 21:32:40
(ich würde nur ungern eine VCCU mit dem Lan-Adapter verwenden.)
Verstehe ich nicht, aber egal.
Du kannst auch nur einen virtuellen Aktor (https://forum.fhem.de/index.php/topic,57655.msg491040.html#msg491040)anlegen.
Alles wichtige dazu steht in der commandref, auch die Beschreibung der Befehle und Optionen zu peerChan.
Die 0 kann ich Dir nicht genau erklären, die ist so ::) both bedeutet, dass beide Seiten mit einem Kommando konfiguriert werden.
Siehe auch diesen Thread (https://forum.fhem.de/index.php/topic,50735.msg424503.html#msg424503).
Ein IODev hat keine Channel, zumindest nicht, dass ich wüsste. Die Channels der VCCU siehst Du einfach in der Definition. Wie bei jedem HM Gerät.
Gruß Otto
ja, bisher habe ich eine VCCU eben nicht benötigt, aber jetzt ist wohl der Zeitpunkt gekommen, dass ich sie brauche, also hab ich sie angelegt, danke soweit Otto.
ich denke, dass du zusätzlich auch den trigger überwachen könntest.
2016-11-13 15:29:15 trigger_cnt 21
bei jedem zählimpuls müsste der counter um 1 hochzählen. gehen messages verloren, kannst du sie sogar "rekonstruieren". der zähler sollte nach 255 wieder bei 0 beginnen.
Also ich habe jetzt den Kanal gepeert:
Sende-Modul kanal List:
Internals:
DEF 3D650608
NAME hk_hmSM_Wasseruhr
NOTIFYDEV global
NR 102
NTFY_ORDER 50-hk_hmSM_Wasseruhr
STATE V-Heute: 139 Liter - Wasseruhr: 120.106 qm
TYPE CUL_HM
chanNo 08
device hk_hmSM
Readings:
2016-11-15 22:08:09 R-VCCU_chan1_Wasseruhr-expectAES set_off
2016-11-15 22:08:09 R-VCCU_chan1_Wasseruhr-peerNeedsBurst set_off
2016-11-01 19:58:47 R-sign off
2016-11-04 17:09:56 RegL_01. 04:10 08:00 20:60 23:05 30:03 92:23 00:00
2016-11-15 22:13:02 state Short (to VCCU)
2016-11-14 22:38:21 trigDst_323CAD noConfig
2016-11-15 22:13:02 trigger Short_166
2016-11-15 22:13:02 trigger_cnt 166
2016-11-15 22:13:02 verbrauch_today 139
2016-11-15 22:13:02 verbrauch_total 1378
2016-11-15 22:13:02 wasseruhr 120.106
2016-11-15 22:13:02 wasseruhrLiterOffset 118728
2016-11-14 23:59:00 z_wasseruhr_delta_d 119.967
2016-11-14 23:59:00 z_wasseruhr_last_d 119.967
Helper:
BNO 166
BNOCNT 1
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shadowreg:
RegL_04.VCCU_chan1_Wasseruhr 01:00
Attributes:
model HM-MOD-Em-8
peerIDs 00000000,
room Heizkeller
stateFormat {sprintf("V-Heute: %.0f Liter - Wasseruhr: %.3f qm",
ReadingsVal('hk_hmSM_Wasseruhr','verbrauch_today',0),
ReadingsVal('hk_hmSM_Wasseruhr','wasseruhr',0));}
userReadings verbrauch_total:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_total", 0)+1;},
verbrauch_today:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_today", 0)+1;},
wasseruhrLiterOffset { 118728;},
wasseruhr:trigger_cnt.* {(ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_total", 0)+ReadingsVal("hk_hmSM_Wasseruhr", "wasseruhrLiterOffset", 0))/1000;}
VCCU-Kanal list:
Internals:
DEF 323CAD01
NAME VCCU_chan1_Wasseruhr
NOTIFYDEV global
NR 112
NTFY_ORDER 50-VCCU_Btn1
STATE ???
TYPE CUL_HM
chanNo 01
device VCCU
peerList hk_hmSM_Wasseruhr,
Readings:
2016-11-15 22:08:09 peerList hk_hmSM_Wasseruhr,
2016-11-15 22:14:23 state set_press short
Helper:
count 1
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
vrt 1
Attributes:
model CCU-FHEM
peerIDs 3D650608,
webCmd press short:press long
Woran erkenne ich nun, ob das peering in Ordnung ist?
Kann ich nun davon ausgehen, dass ich nach wie vor mit dem Sende-Modul Kanal hk_hmSM_Wasseruhr arbeiten kann und dass eventuelle Fehlübertragungen erneut gesendet werden? :)
Peering ist nicht in Ordnung beim Kanal vom EM-8 -> peerIDs 00000000,
Beim virtuellen Kanal steht er drin.
Du musst nach dem peerChan beim EM-8 die Übertragung triggern. Configtaste drücken oder Kanal triggern.
wie sah den peerChan Befehl aus?
Gruß Otto
Zitat von: reen am 15 November 2016, 22:27:29
Also ich habe jetzt den Kanal gepeert: ...
Woran erkenne ich nun, ob das peering in Ordnung ist?
Daran dass das Internal "peerList" beim fraglichen HM-MOD-EM-8-Kanal nicht gesetzt ist. Checke das mit getConfig. Wiederhole ggf. das Peering. Triggere das Modul per Taste oder Statusänderung, damit es das Peering übernimmt.
edit: Dam'nd, Otto war wieder schneller ...
der Befehl war:
set hk_hmSM_Wasseruhr 0 VCCU_chan1_Wasseruhr single set both
sorry, hatte die configtaste vor dem absenden gedrückt, nicht nochmal danach.
nun:
Internals:
DEF 3D650608
NAME hk_hmSM_Wasseruhr
NOTIFYDEV global
NR 102
NTFY_ORDER 50-hk_hmSM_Wasseruhr
STATE V-Heute: 140 Liter - Wasseruhr: 120.107 qm
TYPE CUL_HM
chanNo 08
device hk_hmSM
peerList VCCU_chan1_Wasseruhr,
Readings:
2016-11-15 22:44:03 R-VCCU_chan1_Wasseruhr-expectAES off
2016-11-15 22:44:03 R-VCCU_chan1_Wasseruhr-peerNeedsBurst off
2016-11-01 19:58:47 R-sign off
2016-11-15 22:44:02 RegL_01. 04:10 08:00 20:60 23:05 30:03 92:23 00:00
2016-11-15 22:44:03 RegL_04.VCCU_chan1_Wasseruhr 01:00 00:00
2016-11-15 22:44:03 peerList VCCU_chan1_Wasseruhr,
2016-11-15 22:31:28 state Short (to VCCU)
2016-11-14 22:38:21 trigDst_323CAD noConfig
2016-11-15 22:31:28 trigger Short_167
2016-11-15 22:31:28 trigger_cnt 167
2016-11-15 22:31:28 verbrauch_today 140
2016-11-15 22:31:28 verbrauch_total 1379
2016-11-15 22:31:28 wasseruhr 120.107
2016-11-15 22:44:03 wasseruhrLiterOffset 118728
2016-11-14 23:59:00 z_wasseruhr_delta_d 119.967
2016-11-14 23:59:00 z_wasseruhr_last_d 119.967
Helper:
BNO 167
BNOCNT 1
peerIDsRaw ,323CAD01,00000000
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shadowreg:
Attributes:
model HM-MOD-Em-8
peerIDs 00000000,323CAD01,
room Heizkeller
stateFormat {sprintf("V-Heute: %.0f Liter - Wasseruhr: %.3f qm",
ReadingsVal('hk_hmSM_Wasseruhr','verbrauch_today',0),
ReadingsVal('hk_hmSM_Wasseruhr','wasseruhr',0));}
userReadings verbrauch_total:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_total", 0)+1;},
verbrauch_today:trigger_cnt.* {ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_today", 0)+1;},
wasseruhrLiterOffset { 118728;},
wasseruhr:trigger_cnt.* {(ReadingsVal("hk_hmSM_Wasseruhr", "verbrauch_total", 0)+ReadingsVal("hk_hmSM_Wasseruhr", "wasseruhrLiterOffset", 0))/1000;}
So. Das Modul sollte jetzt die Sendungen quittiert bekommen (grüne Status-LED).
Das Register "transmDevTryMax" (im Gerät-Def) kann ggf. von 3 auf 10 erhöht werden - die maximale Sendeversuche bis zu einer erfolgreichen Quittung (dann rot)
Sieht gut aus!
Eventuelle Wiederholungen siehst Du im Hauptdevice nicht im Kanal.
@Pfriemler Ich dachte das Modul hat doch nur rote LEDs - aber Du hast Recht :-) Aber man muss sie einschalten!
Gruß Otto
super, Danke allen Helfern. ;)
p.s.: ...habe wegen dem register "transmDevTryMax" leider nicht gefunden im Hauptdevice?
Internals:
DEF 3D6506
HMLAN1_MSGCNT 48
HMLAN1_RAWMSG E3D6506,0000,17AC92AD,FF,FFC7,F084003D6506323CAD1100D94D45513037383231373140080000
HMLAN1_RSSI -57
HMLAN1_TIME 2016-11-15 22:44:13
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 48
NAME hk_hmSM
NOTIFYDEV global
NR 99
NTFY_ORDER 50-hk_hmSM
STATE CMDs_done
TYPE CUL_HM
channel_01 hk_hmSM_Brenner
channel_02 hk_hmSM_Btn_02
channel_03 hk_hmSM_Btn_03
channel_04 hk_hmSM_Btn_04
channel_05 hk_hmSM_Btn_05
channel_06 hk_hmSM_Btn_06
channel_07 hk_hmSM_Btn_07
channel_08 hk_hmSM_Wasseruhr
lastMsg No:F0 - t:00 s:3D6506 d:323CAD 1100D94D45513037383231373140080000
protLastRcv 2016-11-15 22:44:13
protSnd 45 last_at:2016-11-15 22:44:03
protState CMDs_done
rssi_at_HMLAN1 avg:-60.52 min:-73 max:-46 lst:-57 cnt:48
Readings:
2016-11-15 22:09:34 CommandAccepted yes
2016-11-15 22:44:13 D-firmware 1.1
2016-11-15 22:44:13 D-serialNr MEQ0782171
2016-11-04 17:09:48 PairedTo 0x323CAD
2016-11-01 19:58:39 R-pairCentral 0x323CAD
2016-11-04 17:09:48 RegL_00. 02:01 05:00 0A:32 0B:3C 0C:AD 12:00 14:03 18:00 00:00
2016-11-08 19:02:27 alive yes
2016-11-15 22:31:28 battery ok
2016-11-08 19:02:27 powerOn 2016-11-08 19:02:27
2016-11-08 19:02:27 recentStateType info
2016-11-15 22:44:03 state CMDs_done
Helper:
HM_CMDNR 260
cSnd 01323CAD3D65060803,01323CAD3D65060804323CAD0104
mId 00D9
rxType 16
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3D6506,00,00,00
nextSend 1479246254.03026
rxt 2
vccu VCCU
p:
3D6506
00
00
00
Mrssi:
mNo F0
Io:
HMLAN1 -55
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_hmlan1:
avg -60.5208333333333
cnt 48
lst -57
max -46
min -73
Attributes:
IODev HMLAN1
IOgrp VCCU
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
model HM-MOD-Em-8
room CUL_HM
serialNr MEQ0782171
subType remote
webCmd getConfig:clear msgEvents
Zitat von: reen am 15 November 2016, 23:00:49
super, Danke allen Helfern. ;)
p.s.: ...habe wegen dem register "transmDevTryMax" leider nicht gefunden im Hauptdevice?
Jep. Übertragung macht das Hauptdevice!
Gruß Otto
Zitat von: reen am 15 November 2016, 23:00:49
super, Danke allen Helfern. ;)
p.s.: ...habe wegen dem register "transmDevTryMax" leider nicht gefunden im Hauptdevice?
Jep. Übertragung macht das Hauptdevice! Auch die LED ist im Hauptdevice!
Gruß Otto
alles klar, habs jetzt auch gecheckt... mit regSet da IM device ;)
Gilt dasselbe eigentlich auch für das HM-MOD-RE-8 Modul?
Darüber schalte ich meine Rolladen und ich habe immer wieder mal das Problem, dass ein Rolladen nicht fährt.
Besonders dann, wenn sie zeitgleich angesteuert werden. Auch hier vermute ich Kollision "in der Luft".
@Otto: Ja, die LED muss man erst einschalten, hatte ich vergessen, mache ich aber bei allen netzversorgten Geräten immer, weil man sonst sprichwörtlich im Dunkeln tappt.
Und der Re-8 hat nur 8 rote LEDs. Verwechselt man ja leicht wegen der gleichen Größe ... 8)
@papaloewe: Andere Baustelle, andere Richtung. Ich nehme an, Du meinst eine Steuerung der Rolläden von FHEM aus. Hier fordert FHEM von sich aus immer ein ACK an** (ob man auch hier Sendeversuche erhöhen kann, weiß ich gar nicht mal). In jedem Fall checkt FHEM aber nicht selbst bzw. gibt keine Fehler aus, außer dem MISSING ACK im Status, was man aber abfangen oder zumindest melden kann. Zeitgleiche Ansteuerung sollte auch kein Problem sein, FHEM entzerrt die Sendungen selbst. Kollisionen mit anderen Sendern als FHEM können trotzdem auftreten.
Ist sicher, dass der Re-8 die Befehle nicht empfangen hat oder kann es auch ein Timing-Problem zwischen dem Re-8 und dem Rolladen geben?
Eigentlich wäre das aber was für einen neuen Fred, sonst findet das ja keiner mehr wieder.
**edit: ist das wirklich so? oder nur mit einem HMLAN?
Ok, danke. Ja das geht in die andere Richtung, also vom FHEM nach MOD-RE-8.
Ich habe auch das Attribut "msgrepeat" im Device gefunden und mal auf 3 gestellt (vorher 1).
Mal sehen, ob es jetzt nochmal auftaucht.
An der Rolladenverdrahtung kann es eigentlich nicht liegen.
Gruß
Thomas
dieses Attr legt fet, wie oft FHEM wiederholt. Es legt (natürlich) nicht fest, wie oft ein Device wiederholt.
Wenn es ein Problem zwischen 2 Devices ist wird sich hier nichts ändern. Zwischen FHEM und dem RE möglicherweise.
Hallo Martin,
danke für deine Erläuterungen. Der Befehl für die Rolläden geht direkt vom fhem zum MOD-RE-8.
Die Signalstärke liegt bei 45. Daran sollte es also nicht liegen.
Ich habe mir erst einmal geholfen die Zeiten ein wenig zu "entzerren", also die Rolläden nacheinander zu fahren.
Damit kann ich leben. Der Fehler trat auch nur sporadisch auf. Das ist sehr schwer zu lokalisieren.
Gruß
Thomas
Mit den zus. "msgrepeat = 3" bisher keine Probleme mehr. Ich beobachte weiter ;-).
prima.
msgRepeat ist 3 by Default. Ausser für burst devices, da nicht weil "gefährlich". Das muss der User schon selbst entscheiden.
Bei Rollos kannst du es also auch löschen, sollte identisch sein.