Moin,
ich weiss nicht so recht, wo hin mit meiner Frage, also mal in den Anfängerbereich.
Ich habe da gerade einen Knoten im Kopf und hoffe, dass mein Problem recht einfach zu lösen ist.
Ich habe ein Sonoff S20 mit EasyESP. Funktioniert an sich gut. ich kann mit "set ESPtest on" einschalten.
Ich habe auch einen selbstgebauten Fensterdrehgriffkontakt auf HM basis. Funktioniert alleine genommen auch gut. Sendet open/closed/tilted.
Jetzt habe ich mir ein DOIF erstellt:
([HM_3E8178] =~ "open|tilted")
{fhem "set ESPtest on";;}
DOELSEIF
([HM_3E8178] =~ "closed")
{fhem "set ESPtest off";;}
Funktioniert nicht. Die Namen stimmen alle. Wenn ich im DOIF set CMD_1 oder CMD_2 manuell auslöse, schaltet der S20 ein oder aus. Wenn ich den Fensterkontakt ändere, sehe ich im Reading des DOIF auch dass er auslöst. ABER: über den DOIF wird der S20 NICHT geschaltet.
Mein 2. Versuch: Ich habe ein dummy erstellt, welches per notify den S20 schaltet. Wenn ich den Dummy direkt schalte, schaltet auch der S20.
schalte ich den dummy über mein DOIF, sehe ich dass der dummy ein und aus schaltet, aber der S20 bleibt ohne Reaktion.
Das sieht so aus, als ob ich über ein DOIF kein ESP schalten kann.
Ich werd verrückt. Im log finde ich auch keinen Hinweis.
Wer kann mir da auf die Sprünge helfen?
Gruss
killah78
Poste ein List von deinem HM_3E8178.
Hier das List vom Fenstersensor. Der Fenstersensor funktioniert schon länger. Auch in anderen DOIFs zum Senden von pushmessages.
Und auch im besagten DOIF sehe ich, dass ein cmd ausgeführt wird, aber es passiert halt nix am ESPEasy.
Internals:
DEF 3E8178
FUUID 5c62d29a-f33f-86d0-36c4-e7fdd2fdd587b22c
IODev hmusb
NAME HM_3E8178
NR 631
NTFY_ORDER 48-HM_3E8178
STATE closed
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
READINGS:
2021-11-12 11:59:44 Activity alive
2019-02-13 18:51:15 D-firmware 2.2
2019-02-13 18:51:15 D-serialNr ZAURFCT7JW
2021-11-12 11:49:45 IODev hmusb
2020-02-22 17:37:46 PairedTo 0xF11234
2020-02-22 09:10:47 R-cyclicInfoMsg on
2020-02-22 10:42:08 R-eventDlyTime 0 s
2020-02-22 09:10:47 R-pairCentral 0xF11234
2020-02-22 10:42:08 R-sign off
2020-02-22 17:37:46 RegL_00. 00:00 02:01 09:01 0A:F1 0B:12 0C:34 10:01 14:06
2020-02-22 17:37:46 RegL_01. 00:00 08:00 20:6C 21:00 22:64 30:06
2021-11-12 11:19:35 alive yes
2021-11-12 11:19:35 battery ok
2020-09-27 21:47:57 cfgState ok
2021-11-12 11:19:35 commState CMDs_done
2021-11-12 11:19:35 contact closed (to hmusb)
2019-09-13 13:30:09 cover closed
2021-10-15 10:07:12 powerOn 2021-10-15 10:07:12
2021-11-12 11:19:35 recentStateType info
2021-11-12 11:19:35 sabotageError off
2021-11-12 11:19:35 state closed
2021-10-19 23:11:32 trigDst_ noConfig
2021-11-12 09:09:20 trigDst_F11234 noConfig
2021-11-12 09:09:20 trigger_cnt 139
helper:
HM_CMDNR 155
mId 0030
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 20
cmds:
TmplKey :no:1636714186.26702
TmplTs 1636714186.26702
cmdKey 1:1:0::HM_3E8178:0030:01:
cmdLst:
assignHmKey noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
unpair noArg
lst:
condition closed,open,tilted
peer
peerOpt HM_07004A,HM_3B0261_WindowRec,HM_3B0261_remote,HM_3B02FE_WindowRec,HM_3B02FE_remote,HM_3B0305_WindowRec,HM_3B0305_remote
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
flgs 0
newChn +3E8178,00,01,00
rxt 2
vccu
p:
3E8178
00
01
00
prefIO:
mRssi:
mNo
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
tmpl:
Attributes:
IODev hmusb
actCycle 028:00
actStatus alive
alias Fenster Küche
autoReadReg 4_reqStatus
expert defReg,rawReg
firmware 2.2
model HM-SEC-RHS-2
peerIDs 00000000
room CUL_HM
serialNr ZAURFCT7JW
subType threeStateSensor
Für mich nicht erklärbar.
Was ist mit:
([HM_3E8178:state] =~ "open|tilted")
(set ESPtest on)
DOELSEIF
([HM_3E8178:state] =~ "closed")
(set ESPtest off)
Hatte ich auch schon probiert. Geht auch nicht.
ABER! Bin einen Schritt weiter und habe einen funktionierenden Workaround gefunden:
([HM_3E8178] =~ "open|tilted")
{fhem( 'sleep 1 ; set ESPtest on' );}
DOELSEIF
([HM_3E8178] =~ "closed")
{fhem( 'sleep 1 ; set ESPtest off' );}
Habe trotzdem keine Erklärung. Habe schon an eine "Funkstörung" gedacht. Weil ja beide geräte quasi gleichzeitig senden. aber das eine ist 868 MHz, das andere 2,4GHz. Wohl eher nicht wahrscheinlich.
Habe aber trotzdem keine Idee keine Idee.
Mit state, wie in meinem, Vorschlag schon probiert?
Ansonsten statt Sleep würde ich das Attribut wait nehmen.
mit state hatte ich auch probiert. Klappt auch nicht.
Das wait Attribut anstelle Sleep klappt aber.
Gut, zumindest ein Workaround gefunden. Erklärbar ist es mir trotzdem nicht.
Wenn ich einen anderen Aktor verwende (ZB. Firmata) klappt das.
Naja. Vielen Dank für deine Hilfe. :-D
Möglicherweise hast du dir irgendwo indirekt ein Loop eingebaut: device1->device2->device1
Vermutlich wird es dann auch funktionieren wenn du statt wait selftrigger-Attribut im DOIF setzt.
nein, mit selftrigger klappts auch nicht.
Ich hatte den ESP auch bereits neu angelegt mit anderem Namen. Aber gleiches Ergebnis.
Aber mit wait kann ich leben. Obwohl mich die offene Frage wurmt....
Zitat von: killah78 am 12 November 2021, 08:40:45
([HM_3E8178] =~ "open|tilted")
{fhem "set ESPtest on";;}
DOELSEIF
([HM_3E8178] =~ "closed")
{fhem "set ESPtest off";;}
würde das set on mit fhem weg lassen und einfach nur "set ESPtest on" bzw off.
Habe so meine Heizung gesteuert, mit espeasy. Klappt seit ca. 2 Jahren ohne Probleme.
nein, ob perl modus oder direkt. beides klappt so nicht. Bei mir klappt es nur mit einer eingebauten Verzögerung.
Hallo killah78.
Testweise habe ich einen Wemos mit EspEasy zum Nachvollziehen bestückt.
Hardware: Wemos mit einer LED an D4 u. GND (ja, mit Vorwiderstand)
EspEasy: "ESP_Easy_mega_20211105_normal_ESP8266_4M1M Nov 5 2021"
Einstellungen geändert:
- Controllers: FHEM IP:8383
- Devices: "LED" GPIO-2 (D4), Switch, Normal Switch, "Enabled" und "Send to Controller" angehakt
In FHEM die Bridge, ein Dummy und ein DOIF angelegt. Das ESP-Easy-Device kam per autocreate - EventMap angepasst. Verbose auf 4 hochgedreht. Ein "list -r my.*|ESP.*" sagt:
define ESPEasy_ESP_Easy_LED ESPEasy FHEM-IP 80 myespbridge ESP_Easy_LED
attr ESPEasy_ESP_Easy_LED IODev myespbridge
attr ESPEasy_ESP_Easy_LED Interval 300
attr ESPEasy_ESP_Easy_LED eventMap /gpio 2 1:on/gpio 2 0:off/
attr ESPEasy_ESP_Easy_LED group ESPEasy Device
attr ESPEasy_ESP_Easy_LED presenceCheck 1
attr ESPEasy_ESP_Easy_LED readingSwitchText 1
attr ESPEasy_ESP_Easy_LED room ESPEasy
attr ESPEasy_ESP_Easy_LED setState 3
attr ESPEasy_ESP_Easy_LED verbose 4
define mydoif DOIF ([mydummy] =~ "open|tilted")\
{fhem("set ESPEasy_ESP_Easy_LED on")}\
DOELSEIF\
([mydummy] =~ "closed")\
{fhem("set ESPEasy_ESP_Easy_LED off")}
attr mydoif verbose 4
define mydummy dummy
attr mydummy setList open tilted closed
attr mydummy verbose 4
define myespbridge ESPEasy bridge 8383
attr myespbridge authentication 0
attr myespbridge combineDevices 0
attr myespbridge group ESPEasy Bridge
attr myespbridge room ESPEasy
setstate ESPEasy_ESP_Easy_LED Sta: off
setstate ESPEasy_ESP_Easy_LED 2021-11-15 08:30:25 State off
setstate ESPEasy_ESP_Easy_LED 2021-11-15 08:30:13 presence present
setstate ESPEasy_ESP_Easy_LED 2021-11-15 08:30:25 state Sta: off
setstate mydoif cmd_2
setstate mydoif 2021-11-15 08:30:24 Device mydummy
setstate mydoif 2021-11-15 08:30:24 cmd 2
setstate mydoif 2021-11-15 08:30:24 cmd_event mydummy
setstate mydoif 2021-11-15 08:30:24 cmd_nr 2
setstate mydoif 2021-11-15 08:30:24 e_mydummy_STATE closed
setstate mydoif 2021-11-15 07:57:30 mode enabled
setstate mydoif 2021-11-15 08:30:24 state cmd_2
setstate mydummy closed
setstate mydummy 2021-11-15 08:30:24 state closed
setstate myespbridge 2021-11-15 07:27:17 state Initialized
LOG sagt:
2021.11.15 08:30:13.542 4: dummy set mydummy open
2021.11.15 08:30:13.543 3: ESPEasy ESPEasy_ESP_Easy_LED: set ESPEasy_ESP_Easy_LED gpio 2 1
2021.11.15 08:30:13.742 4: ESPEasy ESPEasy_ESP_Easy_LED: State: on
2021.11.15 08:30:13.743 4: ESPEasy ESPEasy_ESP_Easy_LED: presence: present
2021.11.15 08:30:17.442 4: dummy set mydummy closed
2021.11.15 08:30:17.443 3: ESPEasy ESPEasy_ESP_Easy_LED: set ESPEasy_ESP_Easy_LED gpio 2 0
2021.11.15 08:30:17.550 4: ESPEasy ESPEasy_ESP_Easy_LED: State: off
2021.11.15 08:30:21.403 4: dummy set mydummy tilted
2021.11.15 08:30:21.404 3: ESPEasy ESPEasy_ESP_Easy_LED: set ESPEasy_ESP_Easy_LED gpio 2 1
2021.11.15 08:30:21.544 4: ESPEasy ESPEasy_ESP_Easy_LED: State: on
2021.11.15 08:30:24.847 4: dummy set mydummy closed
2021.11.15 08:30:24.848 3: ESPEasy ESPEasy_ESP_Easy_LED: set ESPEasy_ESP_Easy_LED gpio 2 0
2021.11.15 08:30:25.043 4: ESPEasy ESPEasy_ESP_Easy_LED: State: off
Beobachtung:
Bei "set mydummy open" und bei "tilted" schaltet es die LED an. Bei "set my dummy closed" wieder aus.
Das DOIF geändert auf
([mydummy] =~ "open|tilted")
(set ESPEasy_ESP_Easy_LED on)
DOELSEIF
([mydummy] =~ "closed")
(set ESPEasy_ESP_Easy_LED off)
klappt analog.
Grundsätzlich im Standardfall also OK. Hilft Dir natürlich noch nix. Irgendwo muss doch der Unterschied zu finden sein :)
Meine Erfahrung: FHEM --> DOIF --> ESPEASY --> ESP8266 schaltet/ reagiert sehr schnell.
Habe div. Schalter usw., welche prellen und andere die schlicht Funktelegramme mehrfach senden. Reagieren ließ ich quasi per toggle. Ergebnis: Das schaltete mehrmals an/ aus, ohne dass ich es merkte. Mal war der ESP an, mal aus. "Aus" nahm ich als "tut nix" wahr.
Als schnelle Lösung hatte ich auch ein wait drin. Später in Hardware entprellt und nicht mehr getoggelt. Gerade mein Funktaster ist problematisch: einmal drücken und er sendet mind. 2-3x ON. Ich wollte aber so reagieren lassen: 1x on --> Lampe1 an, 2x on --> Lampe2 an, 3x on beide an; off --> beide off. Ist mit solchen Funktastern wie meinem eher problematisch ::)
Ich kenne den HM_3E8178 leider nicht. Aber könnte der prellen oder Telegramme mehrfach senden o.ä.?
Welche ESP-Easy Version hast Du drauf?
Welche Rules hast Du ggf. in ESP-Easy aktiv?
Was passiert im EventMonitor, wenn der HM_3E8178 auslöst?
Ich kann gerne die Einstellungen/ Rules in ESP-Easy übernehmen und damit testen. Vielleicht ließe sich ja doch noch etwas erkennen.
Viele Grüße
rob
Hi, vielen Dank für deine Mühe. Also mit dem Wait funktioniert es zuverlässig. Ohne nicht.
Du brauchst aber nicht Aufwand zu betreiben. Mit dem wait 1 Sekunde funktioniert für mich zuverlässig. Bleibt halt nur die Frage in meinem Kopf.
Vielleicht muss ich mal eine Testinstanz mit nur den zwei Geräten erstellen um Wechselwirkungen auszuschließen.
Meine easyESP version:
Es ist ein Sonoff S20
v2.0-20180228
Event monitor ohne wait. ESP schaltet NICHT.
2021-11-15 10:22:31.994 ESPEasy ESPEasy_ESP1_Power on
2021-11-15 10:22:32.010 DOIF di_fenster2 cmd_nr: 1
2021-11-15 10:22:32.010 DOIF di_fenster2 cmd: 1
2021-11-15 10:22:32.010 DOIF di_fenster2 cmd_event: HM_3E8178
2021-11-15 10:22:32.010 DOIF di_fenster2 cmd_1
2021-11-15 10:22:33.243 CUL_HM HM_3E8178 battery: ok
2021-11-15 10:22:33.243 CUL_HM HM_3E8178 commState: CMDs_done
2021-11-15 10:22:33.243 CUL_HM HM_3E8178 contact: open (to myRemoteHmUART)
2021-11-15 10:22:33.243 CUL_HM HM_3E8178 open
2021-11-15 10:22:33.243 CUL_HM HM_3E8178 trigDst_F11234: noConfig
2021-11-15 10:22:33.243 CUL_HM HM_3E8178 trigger_cnt: 198
2021-11-15 10:22:33.279 CUL_HM HM_3E8178 commState: CMDs_done
2021-11-15 10:22:33.331 ESPEasy ESPEasy_ESP1_Power RSS: -56.00 Rel: off
2021-11-15 10:22:34.106 CUL_HM HM_3E8178 commState: CMDs_done
2021-11-15 10:22:34.870 CUL_HM HM_3E8178 commState: CMDs_done
2021-11-15 10:22:35.199 CUL_HM HM_3E8178 commState: CMDs_done
Event monitor mit wait. ESP schaltet ein.
2021-11-15 10:26:24.540 DOIF di_fenster2 wait_timer: 15.11.2021 10:26:25 cmd_1 HM_3E8178
2021-11-15 10:26:25.945 CUL_HM HM_3E8178 battery: ok
2021-11-15 10:26:25.945 CUL_HM HM_3E8178 commState: CMDs_done
2021-11-15 10:26:25.945 CUL_HM HM_3E8178 contact: open (to myRemoteHmUART)
2021-11-15 10:26:25.945 CUL_HM HM_3E8178 open
2021-11-15 10:26:25.945 CUL_HM HM_3E8178 trigDst_F11234: noConfig
2021-11-15 10:26:25.945 CUL_HM HM_3E8178 trigger_cnt: 200
2021-11-15 10:26:25.963 DOIF di_fenster2 wait_timer: no timer
2021-11-15 10:26:25.980 ESPEasy ESPEasy_ESP1_Power on
2021-11-15 10:26:25.993 DOIF di_fenster2 cmd_nr: 1
2021-11-15 10:26:25.993 DOIF di_fenster2 cmd: 1
2021-11-15 10:26:25.993 DOIF di_fenster2 cmd_event: HM_3E8178
2021-11-15 10:26:25.993 DOIF di_fenster2 cmd_1
2021-11-15 10:26:26.043 CUL_HM HM_3E8178 commState: CMDs_done
2021-11-15 10:26:26.211 ESPEasy ESPEasy_ESP1_Power Relay: on
2021-11-15 10:26:26.228 ESPEasy ESPEasy_ESP1_Power RSS: -56.00 Rel: on
2021-11-15 10:26:26.446 CUL_HM HM_3E8178 commState: CMDs_done
2021-11-15 10:26:27.123 CUL_HM HM_3E8178 commState: CMDs_done
2021-11-15 10:26:27.752 CUL_HM HM_3E8178 commState: CMDs_done
Hier Rules aus dem ESP:
on Power#Key do
if [Power#Relay]=1
gpio,12,0
else
gpio,12,1
endif
endon
on Power#Relay do
if [Power#Relay]=1
// gpio,13,0
else
// gpio,13,1
endif
endon
// Init
on System#Boot do
// Switch on
gpio,12,1
endon
Gerne. Danke Dir für die Rückmeldung. Falls ich doch was unterstützen kann bzgl. weiter forschen gerne melden :)
VG
rob
Hast Du mal anstelle von DOIF es mit notify getestet? Nur um Modulprobleme auszuschlie0en ...
Killah78s Versuch 2 oben hatte ich so verstanden, dass das mit notify klappt, aber mit DOIF in selber Konstellation nicht:
Zitat von: killah78 am 12 November 2021, 08:40:45
Mein 2. Versuch: Ich habe ein dummy erstellt, welches per notify den S20 schaltet. Wenn ich den Dummy direkt schalte, schaltet auch der S20.
schalte ich den dummy über mein DOIF, sehe ich dass der dummy ein und aus schaltet, aber der S20 bleibt ohne Reaktion.
Das Event scheint ja in beiden Fällen zu kommen, mit und ohne wait:
ohne wait
2021-11-15 10:22:32.010 DOIF di_fenster2 cmd_event: HM_3E8178
...
mit wait
2021-11-15 10:26:25.993 DOIF di_fenster2 cmd_event: HM_3E8178
Irgendwie scheint der wait_timer u.s. um 10:26:24.540 schon gesetzt zu sein, obwohl das Event erst um 10:26:25.993 kommt. Gibt es ggf. mehrere Events, die in dem ggf. Ausschnitt nicht zu sehen sind?
Nee .. er geht über einen Dummy, den er per DOIF schaltet. Ich wollte, das mal komplett ohne DOIF arbeitet. Da er mit Perl-Ebene {} arbeitet, sollte er das eigentlich hinkriegen ...
Der Versuch über den Dummy funktioniert. Also ich hatte anstelle des Fensterkontakts einen dummy erstellt und entsprechend ein DOIF. Die Kombination Dummy und ESP funktioniert ohne Probleme.
Mein Problem ist nur die Kombination von dem Fenstersensor und ESP.
Ich hatte das auch mit einem Notify probiert. Ging aber auch nicht. Und eben auch Direkt oder Perl-Ebene.
Das komische ist auch, wenn ich über den DOIF zB das cmd_1 direkt ausführe, schaltet der ESP, wenn der trigger vom Fenstersensor kommt, sehe ich im DOIF dass ausgelöst wird, aber der ESP schaltet nicht.
Achso, dieser "2. Versuch", den ich gemaht hatte war Folgendes:
Ein Dummy schaltet per notify den ESP. Klappt.
Dann habe ich den DOIF erstellt, welches auf den Fenstersensor reagiert und den dummy schaltet. (der dummy schaltet dann wieder den ESP per notify). Ergebnis war, das der Fenstersensor den DOIF triggert, ich sehe auch, dass der dummy schaltet (zustandsänderung), aber der ESP bleibt unverändert. So wollte ich prüfen, dass das DOIF funktioniert, denn der dummy wurde ja geschaltet. Aber eben er nachrangige ESP dann nicht.
PS: Ich hatte aber auch ein notify getestet, der auf den FEnstersensor reagiert und den ESP schaltet. Hat nicht funktioniert. Nur eben mit dem Wait.
Danke Euch für die Klarstellung. Der Teufel steckt im Detail ;)
Zitat von: killah78 am 15 November 2021, 15:57:44
...auch mit einem Notify probiert. Ging aber auch nicht...
...wenn ich über den DOIF zB das cmd_1 direkt ausführe, schaltet der ESP, ...
Ich kann es nicht beweisen, aber für mich klingt es danach, als wenn einfach die Teile des DOIF oder Notify alle sehr schnell nacheinander wahr werden würden. So als würde ohne wait mittendrin auf das closed=off getriggert werden und mit wait auf das letzte open/tilted=on.
Auf Kraft möchte ich da aber auch nicht weiterbohren. Bin halt neugierig, ich gebs ja zu :)
Man kann beim wait-Attribut auch Angaben kleiner eins machen.
Du könntest es auch mit wait 0.1 testen.
Ja, "wait 0.1:0.1" funktioniert auch. Ich merke aber keinen Unterschied in der Verzögerung. Also 0.1 und 1 ist gefühlt gleich.
Trickert denn der notify?
Kannst Du (per verbose) sehen, ob überhaupt der Schalt-Befehl zum esp abgesendet wird?
Im Moment ist es wieder ein DOIF. Das Notify war ein Test, hat aber das gleiche Ergebnis geliefert.
Hier siehst du den Event-Monitor mit und ohne wait.
https://forum.fhem.de/index.php/topic,124084.msg1187135.html#msg1187135
In beiden Fällen wird der ESP getriggert. (In dem Fall ohne wait passiert halt nur nix)
Komisch ist, dass der ESP erst getriggert wird und dann erst der DOIF cmd erscheint. Aber wahrscheinlich loggt das Modul erst nach der Ausführung.
Wenn wirklich der befehl von FHEM gesendet wird, müste er auf dem Weg zum ESP "verlohren" gehen.
Was mir mal spontan einfällt .. ist Dein WLAN überlastet? häufiger von Stöhrungen betroffen? Das würde eventuell erklähren, warum eine Verzögerung eine Besserung bringt ...