Hallo liebe Leute,
obigen Aktor habe ich u.a. auch bei mir in der Garage in der UV verbaut. Der schaltet dort die Beleuchtung. Funktionierte bis vor einigen Monaten auch problemlos...
Neuerdings aber, mit subjektiv steigender Tendenz, schmiert das Teil oft ab, so das per Funk keine Befehle mehr entgegen genommen werden resp. diese Befehle extrem Verzögert (1-3 Minuten) ausgeführt werden. Ab dem Punkt hilft dann nur noch ein Factory-Reset und neues Verheiraten.
Ich dachte zu erst, das hänge mit Störimpulsen anlaufender Maschinen zusammen (große Flex, MIG (Trafo) oder WIG (IGBT Inverter) Schweißgerät, ...), aber das passiert auch, wenn eine Woche niemand in der Garage war, allerdings nicht so häufig...
Ist da diesbezüglich irgend etwas bekannt, wie z.B. platte Elkos im Gerät, fehlende Bauteile zwecks Störsicherheit oder so?
wie sind die rssi? also Funkverbindung stabil und ausreichend?
Es könnte sein, dass sich im Laufe der Zeit die Warteschlange in Fhem füllt (wegen Nichterfolg) und nur sporadisch geleert werden kann.
Probier mal statt des fälligen Resets ein "clear msgEvents" auf Gerät und Kanäle. Das löscht die Warteschlange.
Bauteilprobleme sind bisher nicht bekannt, aber nicht ausgeschlossen.
... RSSI liegt umzu -70 bis -60dbi, das sollte also nicht das Problem sein; war es zumindest vorher nimmernicht ...
Dsa mit dem Löschen der MessageEvents ist ein guter Hinweis; versuche ich mal... Zum Verständnis nachgefragt: Die Events beziehen sich nur auf das Device, oder? Denn der Aktor bekommt ja nicht viel zu hören. In der Dunkelheit schaltet ein Kanal die Außenbeleuchtung der Garage (Radar- Bewegunbgsmelder), die anderen drei Kanäle sind für Vorraum und Garage (2 Kanäle) selbst. Diese Kanäle werden also nur beim Betreten der Garage angesteuert und nach oft mehreren Stunden erneut. In der Zwischenzeit werden die Kanäle nicht benutzt.
BTW: In der HV des Hauses (von der eine 5x10² zur Garage geht) sind auch zwei dieser Aktoren verbaut. Diese machen bis dato keinerlei Probleme und sind gleich alt...
EDIT: Das löschen der MessageEvents hilft nicht. Der Aktor verhält sich wie tot... Ich denke, ich werde den mal ausbauen und schauen, ob da was zu finden ist ...
Die rssi sind ausreichend und sollten kein Problem sein. Dann ist auch der Queue kein Problem und msgEvents zu leeren bringt nichts.
edit: sind beide rssi symmetrisch? (mit HM-IOs bekommt man Infos über beide Richtungen. Eine starke Unsymmetrie deutet dann auf einen Funkmodul-Defekt)
Der Radar-BM geht doch sicher über FHEM, d.h. die Schaltbefehle kommen vorn dort. Ist das dann verzögert? wie werden die anderen Kanäle angesteuert, sind die im Fehlerfall auch verzögert?
Gibt es dafür lokale HM-Peers (Wandtaster, Fernbedienung)? Wie reagiert der Aktor auf Befehle, die nicht von FHEM kommen?
Reagiert der Aktor im Fehlerfall flüssig auf lokale Bedienung an den internen Tasten?
Wie reagiert der Aktor beim Stromlosmachen?
Eine stromlose Phase lässt den Aktor einfach neu starten, der klassische Reboot, wenn nichts mehr tut.
Mir will einfach nicht in die Rübe, warum es wirklich einen Factory reset bräuchte.
Jeder Input zum Verhalten könnte helfen, einen fraglichen Hardwarefehler einzukreisen.
... die RSSI sind fast symetrisch und pendeln um den besagten Wert...
Alle Kanäle werden von FHEM aus angesteuert. Ein direktes Peering gibt es nicht. Die Radar (Sensor - ESP - WLAN - FHEM) reagieren promt. Die steuern via FHEM parallel auch zwei Kanäle der im Haus verbauten Sw4 Aktoren an (Downlights ums Haus) und die kommen fast ohne Verzögerung. Also die Sw4 im Haus reagieren sofort, der in der Garage meist nicht oder wenn, dann extrem verzögert.
Auf die Tasten am Aktor selber reagiert selbiger sofort und immer ohne Probleme. Die geänderten Zustände werden aber nicht an FHEM weiter gegeben, wenn der Aktor mal wieder seine "Tage" hat.
Ein auch längeres Stromlos- machen hilft nicht. Nach Anlegen der Netzspannung verhält er sich wie vorher, also wenn er vorher einwandfrei (nach einem F-Reset) funktioniert hat, tut er es auch nach Netztrennung wieder, wenn er vorher rumgezickt hat, zickt er auch nach Netztrennung wieder genau so.
Ich mache morgen Vormittag noch mal einen F-Reset und lerne den neu an. Dann werde ich mal explizit darauf achten, in welcher Situation er anfängt Zicken zu machen (Schweißgerät, Flex oder was auch immer). Ich glaube immer noch, das der irgendwie auf solche Netz- Spikes reagiert und gnadenlos abschmiert; ich hätte sonst keine andere Erklärung dafür...
ich hatte mal bei nem Fensterkontakt solche komischen Probleme - bei mir war es ein Register welches von mir falsch programmiert wurde - es funktionierte alles wunderbar bis ich die Batterie getauscht hatte.
Config zurückgespielt - nix gemerkt - und beim nächsten Battwechsel wieder :-(
Könnte evtl auch bei Dir sein
... wäre auch eine Möglichkeit ... Ich meine aber, das ich an den Aktoren nie was geändert habe; Out of the Box verbaut ...
Werden denn die Register bei einem F-Reset nicht auch auf F-Default gesetzt? Mir war so...
Zitat von: M_I_B am 19 September 2019, 23:36:41
Werden denn die Register bei einem F-Reset nicht auch auf F-Default gesetzt? Mir war so...
Yep.
Zitat von: M_I_B am 19 September 2019, 22:28:15
Ein auch längeres Stromlos- machen hilft nicht. Nach Anlegen der Netzspannung verhält er sich wie vorher, also wenn er vorher einwandfrei (nach einem F-Reset) funktioniert hat, tut er es auch nach Netztrennung wieder, wenn er vorher rumgezickt hat, zickt er auch nach Netztrennung wieder genau so.
Mystisch.
Also wenn er auch im bockigen Falle problemlos lokal reagiert, glaube ich in keinster Weise an irgendein Aufhängen durch Funk- oder Überspannungsspikes.
Eher an Probleme im Flash-Speicher, im Bereich der Register. Bei einem F-Reset wird alles re-initialisiert. RAM kann nicht sein, das wäre nach einem Reboot weg.
Boah, ich tappe echt im Dunkeln. Auch bezüglich der Hardware hätte ich gar keine Idee.
Komm.-probleme zwischen Prozessor und Funkmodul ließen sich mit einem F-Reset kaum lösen - es sei denn, der initialisiert das Funkmodul z.B. mit einer Firmware für dieses Teil, die sich im laufenden Betrieb wieder verabschiedet. Alles sehr gewagt orakelt.
Was für ein HM-Interface nutzt Du?
MIB
Du hast hoffentlich HMinfo mal definiert
defmod hm HMinfo
Zeige mal
get hm protoEvents
und
get hm rssi
sollte dann so ungefähr aussehen
protoEvents done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
AussenTemp : - | - | - | - # - | - | - | -
Aussen_Licht_Strasse : done | - | 991: | 63: # 8 | 7: | - | -
Bad_og_vd : done | - | 4: | - # - | - | - | -
CUL_HM_HM_LC_SW4_PCB_19BBA4 : - | - | - | - # - | - | - | -
HZsw : done | - | 120: | 53: # 2 | 1: | - | -
Treppe2 : done | - | 1002: | 9: # 3 | 3: | - | -
eg_Balkon : - | - | - | - # - | - | - | -
eg_Halle_Hz1 : done | - | 1011: | 11: # 8 | 2: | - | -
eg_Roll1 : done | - | 527: | 2: # - | - | - | -
eg_Roll2 : done | - | 891: | - # - | - | - | -
eg_Roll3 : done | - | 554: | 6: # - | - | - | -
eg_Roll4 : done | - | 526: | 20: # 3 | 3: | - | -
eg_Schlafzimmer : done | - | 896: | - # - | - | - | -
eg_eingang : done | - | 102: | - # - | - | - | -
eg_klo : done | - | 526: | - # - | - | - | -
eg_ku : done | - | 739: | 28: # 5 | 5: | - | -
og_Bad : done | - | 990: | - # - | - | - | -
og_Schlafzimmer : done | - | 1113: | - # - | - | - | -
og_Wohnzimmer : done | - | 1309: | 9: # 4 | 1: | - | -
wz_Roll1 : done | - | 527: | - # - | - | - | -
wz_Roll2 : done | - | 462: | 2: # 2 | - | - | 1:
wz_Roll3 : done | - | 542: | 16: # 4 | 4: | - | -
wz_schalter_1 : done | - | 396: | 2: # - | - | - | -
wz_schalter_2 : done | - | 12: | - # - | - | - | -
================================================================================================================
sum 0 |0 |13240 |221 #39 |26 |0 |1
rssi done:
Device receive from last avg min_max count
AussenTemp hmlan1 AussenTemp -69.0 -63.2 -99.0< -55.0 97408
AussenTemp hmlan2 AussenTemp -82.0 -81.6 -106.0< -75.0 97199
AussenTemp hmuart1 AussenTemp -53.0 -53.2 -81.0< -48.0 97588
Aussen_Licht_Strasse Aussen_Licht_Strasse hmuart1 -79.0 -82.3 -95.0< -79.0 999
Aussen_Licht_Strasse hmlan1 Aussen_Licht_Strasse -102.0 -102.5 -106.0< -98.0 23
Aussen_Licht_Strasse hmlan2 Aussen_Licht_Strasse -95.0 -98.4 -106.0< -92.0 960
Aussen_Licht_Strasse hmuart1 Aussen_Licht_Strasse -82.0 -85.6 -94.0< -81.0 982
og_Wohnzimmer hmlan1 og_Wohnzimmer -67.0 -73.9 -107.0< -40.0 96264
og_Wohnzimmer hmlan2 og_Wohnzimmer -82.0 -86.3 -110.0< -74.0 94011
og_Wohnzimmer hmuart1 og_Wohnzimmer -51.0 -57.3 -99.0< -46.0 96370
og_Wohnzimmer og_Wohnzimmer hmlan1 -65.0 -74.2 -97.0< -41.0 525
wz_Roll1 hmlan1 wz_Roll1 -80.0 -77.4 -103.0< -66.0 968
wz_Roll1 hmlan2 wz_Roll1 -100.0 -94.7 -106.0< -86.0 889
wz_Roll1 hmuart1 wz_Roll1 -61.0 -66.7 -87.0< -57.0 968
wz_Roll1 wz_Roll1 hmuart1 -68.0 -62.5 -76.0< -56.0 529
wz_Roll2 hmlan1 wz_Roll2 -71.0 -76.4 -95.0< -68.0 630
wz_Roll2 hmlan2 wz_Roll2 -94.0 -97.7 -107.0< -91.0 564
wz_Roll2 hmuart1 wz_Roll2 -65.0 -70.0 -94.0< -63.0 626
wz_Roll2 wz_Roll2 hmuart1 -68.0 -72.6 -96.0< -64.0 459
wz_Roll3 hmlan1 wz_Roll3 -68.0 -76.0 -98.0< -64.0 1055
wz_Roll3 hmlan2 wz_Roll3 -83.0 -82.9 -100.0< -78.0 1063
wz_Roll3 hmuart1 wz_Roll3 -56.0 -61.2 -82.0< -54.0 1068
wz_Roll3 wz_Roll3 hmlan1 -73.0 -81.2 -103.0< -70.0 542
Deine Prosa ;D
... ich benutze mehrere Gateways via VCCU, da ich mit einem GW bei weitem nicht auskomme. Da ist zum einen das alte UFO (HM-LAN dingens), ein SCC von Busware und inzwischen zwei MapleCUL. Eingebucht hat sich der Aktor am SCC3, da der am nächsten steht.
Und ich bin da mit Dir; es ist auch mir gerade ein Rätsel, was da Grütze ist.
@HM-Knecht:
Hatte ich schon mal gemacht, nachdem die Probleme das erste mal auftraten. Mache ich aber jetzt noch mal mit dem noch abgeschmierten Aktor. Die MapleCUN tauchen hier nicht auf, da die aktuell über eine ESP- Bridge angebunden sind (noch keine Lan- Kabel gelegt wegen Faulheit...). Der zickende Aktor ist als HM4SW2 benannt. (HM = Protokoll, 4 = Anzal Kanäle, SW = was es ist (Switch), 2 = Index welcher (1, 2, 3, ..., x))
protoEvents send to devices done:
name :State |CmdPend |Snd |SndB |Rcv |RcvB |Resnd #CmdDel |ResndFail |Nack |IOerr
HM1IR1 : done | - | 228 | - | 220 | - | - # - | - | - | -
HM1IR2 : done | - | 172 | - | 172 | - | - # - | - | - | -
HM1IR3 : done | - | 174 | - | 174 | - | - # - | - | - | -
HM1NV1 : done | - | 16 | 15 | 15 | - | - # - | - | - | -
HM1RM1 : done | - | 13 | 1 | 10 | - | - # - | - | - | -
HM1RM2 : done | - | 13 | 1 | 10 | - | - # - | - | - | -
HM1RM3 : done | - | 14 | 1 | 11 | - | - # - | - | - | -
HM2BB1 : done | - | 957 | - | 2304 | - | - # - | - | - | -
HM2BB2 : done | - | 797 | - | 2298 | - | - # - | - | - | -
HM2DI1 : done | - | 10768 | - | 10715 | - | 21 # - | - | - | -
HM2SD1 : done | - | 44 | - | 41 | - | - # - | - | - | -
HM2TA1 : - | - | - | - | - | - | - # - | - | - | -
HM2TH1 : - | - | - | - | 3789 | - | - # - | - | - | -
HM2TH2 : - | - | - | - | - | - | - # - | - | - | -
HM2TH3 : - | - | - | - | - | - | - # - | - | - | -
HM4NV1 : - | - | - | - | - | - | - # - | - | - | -
HM4SW1 : done | - | 1267 | - | 1267 | - | - # - | - | - | -
HM4SW2 : done_Errors:1 | - | 130 | - | 89 | - | 137 # 49 | 41 | - | -
HM4SW3 : - | - | - | - | - | - | - # - | - | - | -
HM4SW4 : - | - | - | - | - | - | - # - | - | - | -
HM4TB1 : - | - | - | - | - | - | - # - | - | - | -
HM5TH1 : done | - | 102 | 41 | 6676 | - | 7 # 6 | 1 | - | -
HM5TH2 : pending | 7 pending| 7 | 7 | - | - | - # - | - | - | -
HM6SP1 : - | - | - | - | - | - | - # - | - | - | -
HM6SP2 : done | - | 6003 | - | 9745 | - | - # - | - | - | -
HM6TA1 : done | - | 2 | - | 2 | - | - # - | - | - | -
HM6TA2 : done | - | 9 | - | 34 | - | - # - | - | - | -
HM6TH01 : done | - | 9 | - | 3722 | - | - # - | - | - | -
HM6TH02 : done | - | 9 | - | 3736 | - | - # - | - | - | -
HM6TH03 : pending | 29 pending| 58 | 27 | 1860 | - | 4 # 3 | 1 | - | -
HM6TH04 : pending | 54 pending| - | - | - | - | - # - | - | - | -
HM6TH05 : done | - | 106 | - | 3830 | - | 48 # 48 | 16 | - | -
HM6TH06 : done | - | 107 | - | 3764 | - | 47 # 45 | 15 | - | -
HM6TH07 : done | - | 99 | - | 3883 | - | 1 # - | - | - | -
HM6TH08 : done | - | 99 | - | 3882 | - | 9 # 6 | 2 | - | -
HM6TH09 : done | - | 103 | - | 3834 | - | 42 # 42 | 14 | - | -
HM6TH10 : done | - | 109 | - | 3820 | - | 48 # 48 | 16 | - | -
HM6TH11 : - | - | - | - | - | - | - # - | - | - | -
HM6TH12 : done | - | 13 | - | 3713 | - | - # - | - | - | -
HM6TH13 : done | - | 8 | - | 1752 | - | - # - | - | - | -
HM6TH14 : - | - | - | - | - | - | - # - | - | - | -
HM6TH15 : - | - | - | - | - | - | - # - | - | - | -
HM8SW1 : - | - | - | - | - | - | - # - | - | - | -
HM8SW2 : - | - | - | - | - | - | - # - | - | - | -
HM8TA1 : - | - | - | - | - | - | - # - | - | - | -
=======================================================================================================================================
sum 0 |90 |21436 |93 |75368 |0 |364 #247 |106 |0 |0
rssi done:
Device receive from last avg min_max count
HM1IR1 SCC3 HM1IR1 -82.0 -82.9 -99.5< -76.0 122
HM1IR1 UFO1 HM1IR1 -92.0 -84.7 -102.0< -78.0 205
HM1IR2 SCC3 HM1IR2 -72.5 -68.0 -72.5< -64.5 103
HM1IR2 UFO1 HM1IR2 -75.0 -75.7 -77.0< -74.0 172
HM1IR3 SCC3 HM1IR3 -64.0 -60.8 -73.0< -57.0 103
HM1IR3 UFO1 HM1IR3 -77.0 -79.1 -83.0< -76.0 171
HM1NV1 HM1NV1 UFO1 -45.0 -44.3 -45.0< -44.0 15
HM1NV1 SCC3 HM1NV1 -83.5 -81.9 -83.5< -80.0 9
HM1NV1 UFO1 HM1NV1 -45.0 -45.6 -46.0< -45.0 16
HM1RM1 HM1RM1 UFO1 -80.0 -80.0 -80.0< -80.0 1
HM1RM1 SCC3 HM1RM1 -50.5 -51.2 -51.5< -50.5 6
HM1RM1 UFO1 HM1RM1 -89.0 -88.5 -93.0< -81.0 13
HM1RM2 HM1RM2 UFO1 -57.0 -57.0 -57.0< -57.0 1
HM1RM2 SCC3 HM1RM2 -54.5 -54.8 -56.0< -54.0 6
HM1RM2 UFO1 HM1RM2 -62.0 -63.8 -67.0< -61.0 13
HM1RM3 HM1RM3 UFO1 -56.0 -56.0 -56.0< -56.0 1
HM1RM3 SCC3 HM1RM3 -57.5 -58.2 -59.5< -57.5 7
HM1RM3 UFO1 HM1RM3 -65.0 -65.4 -66.0< -65.0 14
HM2BB1 SCC3 HM2BB1 -74.5 -76.5 -105.0< -67.5 1866
HM2BB1 UFO1 HM2BB1 -81.0 -84.0 -106.0< -77.0 2782
HM2BB2 SCC3 HM2BB2 -91.0 -86.9 -106.5< -81.5 1691
HM2BB2 UFO1 HM2BB2 -94.0 -90.8 -106.0< -83.0 2571
HM2DI1 HM2DI1 SCC3 -61.0 -62.6 -74.0< -57.0 3363
HM2DI1 HM2DI1 UFO1 -80.0 -79.2 -83.0< -77.0 2085
HM2DI1 SCC3 HM2DI1 -64.0 -65.3 -74.5< -59.0 6624
HM2DI1 UFO1 HM2DI1 -83.0 -82.8 -88.0< -80.0 10757
HM2SD1 HM2SD1 SCC3 -56.0 -54.1 -56.0< -52.0 32
HM2SD1 HM2SD1 UFO1 -84.0 -83.2 -84.0< -82.0 4
HM2SD1 SCC3 HM2SD1 -49.5 -49.0 -51.5< -47.5 34
HM2SD1 UFO1 HM2SD1 -83.0 -82.2 -84.0< -81.0 44
HM2TH1 SCC3 HM2TH1 -54.0 -54.9 -57.0< -53.5 2288
HM2TH1 UFO1 HM2TH1 -89.0 -87.3 -96.0< -83.0 3782
HM4SW1 HM4SW1 UFO1 -59.0 -56.5 -80.0< -40.0 1230
HM4SW1 SCC3 HM4SW1 -78.0 -75.5 -94.0< -68.5 746
HM4SW1 UFO1 HM4SW1 -56.0 -58.0 -82.0< -42.0 1268
HM4SW2 HM4SW2 SCC3 -79.0 -76.6 -84.0< -72.0 741
HM4SW2 HM4SW2 UFO1 -100.0 -99.3 -111.0< -95.0 328
HM4SW2 SCC3 HM4SW2 -75.0 -75.4 -82.0< -70.5 700
HM4SW2 UFO1 HM4SW2 -101.0 -99.9 -112.0< -94.0 476
HM5TH1 HM5TH1 SCC3 -52.0 -52.7 -53.0< -52.0 20
HM5TH1 HM5TH1 UFO1 -83.0 -85.6 -89.0< -81.0 27
HM5TH1 SCC3 HM5TH1 -60.5 -60.9 -64.5< -59.0 4651
HM5TH1 UFO1 HM5TH1 -98.0 -94.7 -105.0< -88.0 6137
HM6SP2 SCC3 HM6SP2 -55.0 -55.1 -62.0< -53.5 5877
HM6SP2 UFO1 HM6SP2 -91.0 -93.4 -104.0< -88.0 9658
HM6TA1 SCC3 HM6TA1 -69.5 -69.8 -70.0< -69.5 2
HM6TA1 UFO1 HM6TA1 -73.0 -71.0 -73.0< -69.0 2
HM6TA2 SCC3 HM6TA2 -75.0 -72.0 -78.5< -64.5 31
HM6TA2 UFO1 HM6TA2 -94.0 -101.3 -109.0< -94.0 22
HM6TH01 SCC3 HM6TH01 -59.5 -58.6 -62.0< -57.5 2269
HM6TH01 UFO1 HM6TH01 -91.0 -90.9 -99.0< -86.0 3598
HM6TH02 SCC3 HM6TH02 -57.5 -58.8 -62.5< -56.0 2262
HM6TH02 UFO1 HM6TH02 -88.0 -94.7 -106.0< -86.0 3240
HM6TH03 HM6TH03 SCC3 -52.0 -55.3 -64.0< -52.0 23
HM6TH03 SCC3 HM6TH03 -59.5 -61.3 -77.5< -57.0 1851
HM6TH03 UFO1 HM6TH03 -88.0 -86.1 -104.0< -80.0 1836
HM6TH05 HM6TH05 UFO1 -64.0 -63.0 -64.0< -61.0 22
HM6TH05 SCC3 HM6TH05 -46.5 -45.4 -52.0< -41.5 2279
HM6TH05 UFO1 HM6TH05 -68.0 -68.5 -74.0< -64.0 3829
HM6TH06 HM6TH06 UFO1 -52.0 -56.2 -59.0< -52.0 24
HM6TH06 SCC3 HM6TH06 -56.0 -54.9 -64.5< -52.5 2277
HM6TH06 UFO1 HM6TH06 -59.0 -62.8 -68.0< -58.0 3661
HM6TH07 HM6TH07 UFO1 -49.0 -46.0 -54.0< -42.0 54
HM6TH07 SCC3 HM6TH07 -74.5 -66.2 -94.0< -61.5 2333
HM6TH07 UFO1 HM6TH07 -67.0 -56.1 -73.0< -50.0 3885
HM6TH08 HM6TH08 UFO1 -62.0 -63.6 -71.0< -59.0 50
HM6TH08 SCC3 HM6TH08 -93.5 -77.8 -107.5< -65.5 2311
HM6TH08 UFO1 HM6TH08 -71.0 -70.5 -83.0< -64.0 3888
HM6TH09 HM6TH09 UFO1 -81.0 -79.1 -81.0< -75.0 26
HM6TH09 SCC3 HM6TH09 -78.5 -79.4 -100.0< -72.0 2284
HM6TH09 UFO1 HM6TH09 -94.0 -85.2 -104.0< -78.0 3819
HM6TH10 HM6TH10 UFO1 -83.0 -75.5 -86.0< -69.0 24
HM6TH10 SCC3 HM6TH10 -69.5 -64.6 -73.0< -60.5 2277
HM6TH10 UFO1 HM6TH10 -84.0 -80.6 -106.0< -73.0 3805
HM6TH12 SCC3 HM6TH12 -81.0 -83.5 -99.0< -80.0 2270
HM6TH12 UFO1 HM6TH12 -70.0 -70.4 -72.0< -69.0 3623
HM6TH13 SCC3 HM6TH13 -75.5 -74.3 -84.0< -70.5 1732
HM6TH13 UFO1 HM6TH13 -48.0 -47.9 -49.0< -47.0 1744
name :State |CmdPend |Snd |SndB |Rcv |RcvB |Resnd #CmdDel |ResndFail |Nack |IOerr
HM4SW2 : done_Errors:1 | - | 130 | - | 89 | - | 137 # 49 | 41 | - | - Device receive from last avg min_max count
HM4SW2 HM4SW2 SCC3 -79.0 -76.6 -84.0< -72.0 741
HM4SW2 HM4SW2 UFO1 -100.0 -99.3 -111.0< -95.0 328
HM4SW2 SCC3 HM4SW2 -75.0 -75.4 -82.0< -70.5 700
HM4SW2 UFO1 HM4SW2 -101.0 -99.9 -112.0< -94.0 476Der Teil ist sehr interresannt
ZitatDevice receive from last avg min_max count
HM4SW2 HM4SW2 SCC3 -79.0 -76.6 -84.0< -72.0 741
HM4SW2 HM4SW2 UFO1 -100.0 -99.3 -111.0< -95.0 328
Da sendet dein Ufo 328 mal an dein HMSW2, und das kann so nicht funktionieren mit der RSSI Leistung.
Das spiegelt ja auch die Resend Zähler der ersten Auswertung, bis hin zu #CmdDel.
ZitatEingebucht hat sich der Aktor am SCC3
Vergiss das einbuchen! am I/O ganz schnell, gepairt wird mit Fhem nicht mit dem I/O, die SCC und CUL reichen die empfangene Nachrichten transparent durch nach fhem, und doppelte Nachrichten werden in der ersten halben sec verworfen.
Wie steht das attr IOgroup bei dem Aktor?
Ich wurde ja mal tippen, dass dein SCC ab und zu nicht erreichbar ist von Fhem, und deswegen die VCCU auf das Ufo zurückgreift, !
... ähhh stop, mal langsam bitte ...
Ich dachte bisher, das die VCCU die Kommunikation regelt und für die Übertragung der Daten jenes Gateway aussucht, welches die besten Sende-/Empfangseigenschaften bereits stellt. Und in dieser Annahme bin ich davon ausgegangen, das auch nur dieses Gateway dann sendet (Empfangen tun natürlich alle, aber es wird nur der Datenstrom des besten GW's genommen). Oder liege ich da falsch???
Die hohe Anzahl der wiederholten Sendungen könnte m.E. damit zusammen hängen, das entweder FHEM immer wieder versucht, einen positiven Response auf den gestern zuletzt gesendeten Befehl zu erhalten und/oder ja in der Nacht hier u.a. diverse größere Tiere (Dachs, Marder, Hunde, Rehe, Wildschweine, ab- und an ein Wolf) in den Erfassungsbereich des Sensors geraten und den auslösen (ja, is auf'm Land mit viel Wald und Tier umzu)
IODev = SCC3 / IOgrp = VCCU:SCC3
ZitatVCCU die Kommunikation regelt
ja, ABER nur das senden!
ZitatIOgrp = VCCU:SCC3
das besagt, bevorzuge zum senden den SCC3, und falls der nicht verfügbar, nimm den nächstbesten zum senden mit den "besten rssi" Werten.
bestätigt meine Meinung das dein SCC3 nicht immer "sendebereit "ist.
... öhhhdoch, der SCC3 ist eigentlich immer verfügbar. Der steuert hier auch reichlich andere Aktoren an, wie z.B. einiges im Wohn- und Esszimmer, die ständig benutzt werden und bis dato ohne Verzögerung reagieren. Daran kann's also m.E. nicht liegen.
Dein Prosa "andere Aktoren"
Wenn deine "andere Aktoren" auch in der Liste sind, könnte man ja sehen" ich sehe da einige, die wechselseitig mal über Ufo oder scc senden"
Habe es dir als Beispiel doch markiert. wie das zu lesen ist.
Ich weiß noch dass du einen Server Xenon hast, und deine SCC`s irgendwie über einen RPi angebunden hast, ....
Ich bleibe dabei, dein SCC ist nicht durchgängig verfügbar.
zeig doch mal "get vccu listDevice". am besten, wenn der aktor gerade zickt.
vielleicht dazu noch ein list vom hmlan.
ein list vom aktor wäre ja auch mal zeit.
hilft dann vielleicht ein "set vccu assignIO"?
... so, mal ein kleines Update:
Da ich heute den ganzen Nachmittag am Schweißen war, bot es sich an zu schauen, ob der damit ein Problem hat... Dazu musste ich ihn aber erst einmal zurücksetzen... Oder auch nicht! Dieses mal (im Gegensatz zu den vielen mal vorher) konnte ich den einfach nicht mehr Pairen...
Auf Grund Deines erneuten Hinweises und Deinem Beharren auf ein SCC- Problem bin ich dem jetzt noch mal explizit nachgegangen, da ich ja weis, das Du kein Dummer bist in dieser Hinsicht. Also habe ich mal die Kommunikation zwischen dem Server und dem SCC-PI beobachtet... Die war faktisch nicht mehr vorhanden. Extrem viele Abbrücke und Neuversuche mit wirren Daten... Konnte ich nicht wirklich nachvollziehen. Dann habe ich den Server mal komplett neu gestartet... und schwups... alles wieder ok (aktuell immer noch)!
Nun habe ich mal überlegt, was ich denn geändert habe, das hier nun auf einmal Probleme bestehen... Und dann viel mir ein, das ich den Server von Debian Jessie auf die aktuelle Buster geupdatet habe. Und das AUftreten dieses Problems fällt zeitlich mit mehr oder weniger 2 Wochen Unsicherheit in diesen Zeitraum... Verdammte Axt!!!!
Ich spreche den SCC-PI ja aus FHEM direkt via IP:Port an. Das hat bisher immer vollkommen schmerzfrei funktioniert. Nun scheint es aber so, das nach einer gewissen Zeit unter Buster genau diese Art der Kommunikation gegen die Wand läuft... Ich hatte es bisher ohne zu hinterfragen einfach hingenommen, das es so funktioniert, aber nun habe ich wohl ein Problem...
... noch ein Update:
Von Sonnabend Mittag bis gestern Abend (Sonntag) hatte ich alle HM- Gateways bis auf den SCC testweise stillgelegt.
Bis auf die nun ausser Reichweite befindlichen Geräte hat erst einmal alles weiterhin funktioniert. Alle Sensoren und Aktoren in Reichweite funktionierten bis Sonntag nachmittag ohne Einschränkungen und Verzögerungen. Dann ist der problematische Aktor in der Garage erneut abgeschmiert mit den berichteten Effekten. Aber: Alle anderen Geräte, die nun ja ausschließlich den SCC als Gateway nutzen, funktionierten weiterhin.
Mein Fazit:
Es kann nicht wirklich am SCC liegen, wenn es letztlich immer wieder das gleiche Gerät betrifft und alle anderen Geräte davon unbeeindruckt bleiben.
Ich werde jetzt schlicht und ergreifend den Aktor tauschen in der Hoffnung, das dann alles wie früher problemlos funktioniert. Irgendwann fliegen die HM- Aktoren eh raus, wenn ich denn irgendwann mal die Zeit finde, die auf ESP(easy) basierenden stapelbaren Hutschinen-Aktoren fertig zu entwickeln ...