HM-PB-6-WM55 (6-Tasten-Sender): FHEM blockiert während andauerendem Tastendruck

Begonnen von CQuadrat, 18 November 2020, 10:12:34

Vorheriges Thema - Nächstes Thema

CQuadrat

Hallo Zusammen,

ist es eigentlich normal, dass FHEM blockiert, solange ich eine Taste gedrückt halte?


Viele Grüße

Christoph
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Otto123

Wenn Du allerdings etwas definiert hast, das beim Taste drücken langwierige, blockierende Aktionen auslöst - wäre es zu erwarten.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

CQuadrat

Zitat von: Otto123 am 18 November 2020, 10:39:57
Wenn Du allerdings etwas definiert hast, das beim Taste drücken langwierige, blockierende Aktionen auslöst - wäre es zu erwarten.
Das ist mir auch klar. Aber genau so etwa kann ichtrotz intensiver Suche nicht finden. Zumindest noch nicht.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

frank

starte mal apptime.
dann taster 10s drücken.
dann "apptime max" aufrufen und posten.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CQuadrat

Das hatte ich auch schon ausprobiert. Da hatte ich immer meine HM-IO-Devices, die in meiner vCCU definiert sind.
Deshalb auch mein Bauchgefühl, dass hier etwas prinzipiell falsch läuft.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

CQuadrat


name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
HMLAN1                                   HMLAN_Read                            1688        9    5179.88   575.54     0.00     0.00 18.11. 11:38:04 HASH(HMLAN1)
HMUART3                                  HMUARTLGW_Read                        1523       11    3780.50   343.68     0.00     0.00 18.11. 11:38:17 HASH(HMUART3)
HMUSB1                                   HMLAN_Read                            1225        7    2851.46   407.35     0.00     0.00 18.11. 11:37:59 HASH(HMUSB1)
HMUART2                                  HMUARTLGW_Read                        1014       22    2570.25   116.83     0.00     0.00 18.11. 11:38:00 HASH(HMUART2)
HMUART4                                  HMUARTLGW_Read                         921       16    3705.14   231.57     0.00     0.00 18.11. 11:37:58 HASH(HMUART4)

FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

frank

hattest du genau 10s gedrückt?

zeige die komplette liste.
die io-read-funktionen sind zwar immer auch in der liste zu sehen, aber eigentlich nie die ursache.

vor einem neuen versuch, aber zunächst "apptime clear" aufrufen.

ein list der vccu vielleicht noch.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CQuadrat

Habe etwas mit event-on-change-reading herumprobiert -> es ist besser geworden.

Ich muss wohl doch irgendwo etwas triggern. :-\
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

CQuadrat

Der Übeltäter war ein DOIF.
Zitat Commandref:
Zitat
(...)Das Modul wird getriggert, sobald das angegebene Device hier "remotecontrol" ein Event erzeugt. Das geschieht, wenn irgendein Reading oder der Status von "remotecontrol" aktualisiert wird.(...)
Da bei einem anhaltenden Longpress des 6-Tasten-Senders der entsprechende Button im state ständig Events erzeugt, wird auch permanent das DOIF getriggert; auch wenn dort nur auf ein short-Press reagiert wird.

Mit einem notify wäre das nicht passiert...
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

Damian

Zitat von: CQuadrat am 18 November 2020, 12:46:50
Zitat Commandref:Da bei einem anhaltenden Longpress des 6-Tasten-Senders der entsprechende Button im state ständig Events erzeugt, wird auch permanent das DOIF getriggert; auch wenn dort nur auf ein short-Press reagiert wird.

Das hängt von der Definition des Triggers im DOIF ab.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF