Nabend,
Ich habe ein doif zur lichtsteuerung im Keller Flur.
Tastendruck macht 3 min an, langer Druck dauer an.
Ein identischer doif läuft tadellos. Der hat nur andere gpio, die Definition ist davon ab identisch.
Der vom Keller bleibt fast jedes Mal im cmd1.1 hängen.
Manchmal macht er aber auch ws er soll.
Wo liegt der Wurm begraben? Ich finde es nicht.
Internals:
DEF ([GPIO_IN_04:"^on$"] and [?OUT_1:PortA0] eq "off") (set OUT_1 PortA0 on) (set OUT_1 PortA0 off)
DOELSEIF ([GPIO_IN_04:"^on$"] and [?OUT_1:PortA0] eq "on") (set OUT_1 PortA0 off)
DOELSEIF ([GPIO_IN_04:"^Longpress:.on$"]) (set OUT_1 PortA0 on)
MODEL FHEM
NAME Licht_Flur_KG
NR 100
NTFY_ORDER 50-Licht_Flur_KG
STATE on
TYPE DOIF
READINGS:
2018-04-18 21:00:03 Device GPIO_IN_04
2018-04-18 20:30:05 cmd 1.1
2018-04-18 20:30:05 cmd_event GPIO_IN_04
2018-04-18 20:30:05 cmd_nr 1
2018-04-18 20:30:05 cmd_seqnr 1
2018-04-18 21:00:03 e_GPIO_IN_04_events Pinlevel: low,off,Longpress: off
2018-04-13 07:37:27 mode enabled
2018-04-18 20:30:05 state on
2018-04-18 20:30:05 wait_timer no timer
Regex:
condition:
0 EventDoIf('GPIO_IN_04',$hash,'^on$',1) and ReadingValDoIf($hash,'OUT_1','PortA0') eq "off"
1 EventDoIf('GPIO_IN_04',$hash,'^on$',1) and ReadingValDoIf($hash,'OUT_1','PortA0') eq "on"
2 EventDoIf('GPIO_IN_04',$hash,'^Longpress:.on$',1)
devices:
0 GPIO_IN_04
1 GPIO_IN_04
2 GPIO_IN_04
all GPIO_IN_04
do:
0:
0 set OUT_1 PortA0 on
1 set OUT_1 PortA0 off
1:
0 set OUT_1 PortA0 off
2:
0 set OUT_1 PortA0 on
3:
helper:
DOIF_Readings_events
DOIF_eventas
event Pinlevel: low,off,Longpress: off
globalinit 1
last_timer 0
sleepdevice GPIO_IN_04
sleepsubtimer 1
sleeptimer -1
timerdev GPIO_IN_04
timerevent on
triggerDev GPIO_IN_04
timerevents:
Pinlevel: high
on
timereventsState:
Pinlevel: high
state: on
triggerEvents:
Pinlevel: low
off
Longpress: off
triggerEventsState:
Pinlevel: low
state: off
Longpress: off
internals:
itimer:
perlblock:
readings:
trigger:
all GPIO_IN_04
uiState:
uiTable:
Attributes:
DbLogExclude .*
cmdState on,off|off|on
cmdpause 2:2:2
devStateIcon on:on:cmd_2 initialize|initialized|off:off:cmd_3
do always
group Licht_Flur_KG
room Licht,_Flur_KG
userattr room_map structexclude
verbose 0
wait 0,180:0:0
Habe einen Unterschied beim gpio (Schalter) gefunden.
Bei den "fehlerhaften" war event-on-change-reading nicht gesetzt.
attr GPIO_IN_04 event-on-change-reading state,Longpress
Habs jetzt gesetzt. Mal schaun ob der Fehler damit weg ist.
Gesendet von meinem S60 mit Tapatalk
Zitat von: Frank_Huber am 18 April 2018, 21:55:54
Habe einen Unterschied beim gpio (Schalter) gefunden.
Bei den "fehlerhaften" war event-on-change-reading nicht gesetzt.
attr GPIO_IN_04 event-on-change-reading state,Longpress
Habs jetzt gesetzt. Mal schaun ob der Fehler damit weg ist.
Gesendet von meinem S60 mit Tapatalk
Das hängt mit cmdpause zusammen.
Wenn nach cmd 1.1 innerhalb von zwei Sekunden ein Trigger für einen anderen Zweig kommt, z. B. cmd_2, dann wird der wait-Timer für cmd 1.2 unterbrochen, aber der Befehl für cmd_2 wird wegen Pause nicht ausgeführt -> das Modul verbleibt im letzten Zustand, also cmd 1.1
Zitat von: Damian am 18 April 2018, 22:04:17
Das hängt mit cmdpause zusammen.
Wenn nach cmd 1.1 innerhalb von zwei Sekunden ein Trigger für einen anderen Zweig kommt, z. B. cmd_2, dann wird der wait-Timer für cmd 1.2 unterbrochen, aber der Befehl für cmd_2 wird wegen Pause nicht ausgeführt -> das Modul verbleibt im letzten Zustand, also cmd 1.1
Danke Damian, wenn ich den list richt verstehe hat das Pinlevel reading das ausgeführt.
2018-04-18 21:00:03 e_GPIO_IN_04_events Pinlevel: low,off,Longpress: off
Das Setzen des event-on-change-reading sollte das dann lösen.
Der andere doif hat diesen fehler nochned gezeigt und läuft seit 1,5 Jahren ca.
Gesendet von meinem S60 mit Tapatalk