Guten Tag,
ich möchte gerne meine Dunstabzugshaube in Abhängigkeit des Küchenfensters ein und auschalten.
Ich habe dazu einen HM-SEC-SCO und HM-LC-SW1-PL-DN-R1 im Einsatz.
Nun versuche ich einen Notify anzulegen, welcher prüft, ob das Fenster geöffnet ist oder nicht:
Fenster.Kueche.Auf {
if (Value ("TFK.Kueche") eq "open")
{fhem ("set Dunstabzugshaube.Kueche on")}
else {fhem ("set Dunstabzugshaube.Kueche off")}
if (Value ("Dunstabzugshaube.Kueche") eq "on" and Value ("TFK.Kueche") eq "closed" )
{fhem ("set Dunstabzugshaube.Kueche off")}
}
Kann man zwei if schleifen in einer Notify Definition schreiben? Es funktioniert leider so noch nicht.
Kann man eigentlich Notifys weglassen und nur den Programmcode in die 99_myUtils zum Beispiel schreiben? Macht das Sinn?
Sorry für die Anfängerfragen...
Moin,
ich würde bei dieser einfachen Anwendung die beiden Geräte direkt peeren. Siehe dazu Bedinungsanleitung HM-LC-SW1-PL-DN-R1 Seite 8 ff. Vermutlich funktioniert dann schon alles wie gewünscht und es wird kein notify etc gebraucht. Ich habe so etwas für "Tür auf - Licht an" im Einsatz, funktioniert absolut störungsfrei.
Alternativ (ich finde einfacher) kannst Du das Peering auch über fhem command machen.
set TFK.Kueche peerChan 0 Dunstabzugshaube.Kueche single set (anschließend Anlerntaste am HM-SEC-SCO kurz drücken)
...versuch doch mal und viel Erfolg
Bernd
Wie hast du denn das notify "definiert"!?
Einfach mal so oder (besser und VIEL einfacher) mittels Eventmonitor:
https://wiki.fhem.de/wiki/Event_monitor
Diesen öffnen (Filter auf z.B. dein Fenster setzen), warten bis der gewünschte Event auftaucht und dann: create/modify -> fertig
Du kannst, wenn richtig gemacht, soviel if/elsif/else einbauen wie du willst/brauchst.
Wichtig: ab der geschweiften Klammer { ist es Perl, da dann eben if/elsif/else usw. bis dann wieder die "Perl geschweifte Klammer" zugeht }:
define my_notify notify Regex {hier dann Perl Code. Besser ausgelagert in eine Sub in myUtils.}
Wenn du mehr "programmieren" willst (bzw. mache ich das praktisch "immer"), dann würde ich eben in eine Sub auslagern:
https://wiki.fhem.de/wiki/99_myUtils_anlegen
Aufruf dann:
define my_notify notify Regex {mySub()}
Du kannst auch Werte übergeben, z.B. $NAME (das auslösende Device), $EVENT (der gesamte Event), $EVTPART0, $EVTPART1, ... ("Teile" des Events sofern vorhanden)...
Eine Sub in myUtils alleine ist ziemlich sinnlos, weil nur weil sie "da ist" wird sie ja noch nicht "benutzt"/aufgerufen ;)
EDIT: die Anmerkung von pwlr ist nat. richtig und würde ich auch mal beachten! Vorteil: das funktioniert dann auch, wenn fhem mal grad nicht "will" ;)
EDIT: und es gibt auch noch das Modul DOIF. Damit geht das was du willst nat. auch. Ist aber sehr mächtig und du musst mal die commandref lesen und auch die möglichen Attribute beachten! (ich nutze es aber nicht, kann daher nicht wirklich viel dazu sagen)...
EDIT: noch eine Anmerkung. Ich würde von Value Abstand nehmen! Weil Value den STATE (also das Internal! abfrägt!) und NICHT state das Reading! Und STATE kann z.B. durch stateFormat etc. "beeinflusst" werden und dann liefert Value u.U. etwas "unerwartetes"... Besser: ReadingsVal("Device","Reading","Ersatz") oder ReadingsNum("Device","Reading",Ersatz) (bzw.: AttrVal, InternalVal, ...)
Gruß, Joachim
Nur so aus reiner neugier. Was genau soll denn die Logik eigentlich machen?
if (Value ("TFK.Kueche") eq "open")
{fhem ("set Dunstabzugshaube.Kueche on")}
Du öffnest das Fenster und die Dunstabzugshaube geht an?
Wenn es nur das ist, dann bietet sich das bereits genannte peering (https://wiki.fhem.de/wiki/Homematic_Peering_Beispiele) bestens an.
Der Vorteil ist es funktioniert dann auch ohne FHEM. Der Status wird dann in FHEM nur mitgeplottet.
Genau, ich möchte wenn das Fenster auf ist, dass der Aktor (Dunstabzugshaube) auch eingeschaltet wird, anderfalls aus!
Ok, das mit dem peeren hat seinen Vorteil. Kann ich danach trotzdem noch mit den Readings des Fesnterkontakts andere Dinge auswerten?
Ich möchte später nämlich noch weitere aktoren schalten, wenn das Fenster geöffnet wird. Beispielsweise Fussbodenheizungstermostate usw...
Ja, du kannst den Sensor am Fenster wie gewohnt weiterhin verwenden, da er ja sein Status weiterhin übermittelt.
Anders herum könntest du ihn auch mit anderen Aktoren peeren, die andere Aktionen ausführen sollen.
Z.B sind meine Fenstersensoren mit den HM-Heizungsthermostaten gepeert um diese abzuschalten, wenn die Fenster geöffnet sind.
Du kannst auch einen gepeerten Aktor weiterhin aus FHEM steuern.
Zur Info: Peeren geht aber nur zwischen Homematic-Geräten
EDIT: Ich meine hier die "klassischen" HM-Geräte. Wie das mit HMIP aussieht kann ich dir nichts sagen.
Wie wissen denn beide Geräte, wann Sie ein und wann sie ausschalten sollen, wenn sie gepeert sind?
Sprich wie sage ich dem Aktor er soll einschalten und ausschalten, je nachdem welchen Status der Fensterkontakt hat?
ahh es steht im wiki drin...
Zitat von: darkness am 19 August 2020, 10:43:50
Zur Info: Peeren geht aber nur zwischen Homematic-Geräten
EDIT: Ich meine hier die "klassischen" HM-Geräte. Wie das mit HMIP aussieht kann ich dir nichts sagen.
Es geht mittels PEERING (direkte Verbindung von Sensor/Aktor) nur zwischen:
Homematic "Classic" - Homematic "Classic"
Homematic IP - Homematic IP
"Mischen" geht NICHT!!
(bzw. halt dann nur über eine Zentrale: Ereignis kommt zur Zentrale und diese "steuert" dann den Aktor)
Zitat von: Diamond_72 am 19 August 2020, 10:47:22
Wie wissen denn beide Geräte, wann Sie ein und wann sie ausschalten sollen, wenn sie gepeert sind?
Sprich wie sage ich dem Aktor er soll einschalten und ausschalten, je nachdem welchen Status der Fensterkontakt hat?
Naja:
Der Sensor meldet an alle "PEERs" den Zustand(swechsel) und beim Aktor stellst du dann ein was dort passieren soll...
Es gibt "Standardverhalten", z.B. du drückst einen Lichtschalter und dieser sendet an den "Lichtaktor", Standard: Licht geht an/aus...
Du kannst aber auch beim Aktor einstellen, dass nur für eine bestimmte Zeit an sein soll etc.
Was der jeweilige Aktor "kann" musst du halt sehen (Bedienungsanleitung lesen / Register abfragen)...
Gruß, Joachim
Alle gut, ich habe alles Homematic Classic Geräte. Von daher sollte das Peering kein Problem sein...
Irgendetwas scheint an meinem "Script" oben falsch zu sein. Tut sich nichts...
Ich habe es nun mal mit ReadingsVal probiert und eine Testzeile geschrieben, geht leider auch nicht:
Fenster.Kueche.Auf {if (ReadingsVal ("TFK.Kueche", "state", "undef") eq "open"){fhem ("set Dunstabzugshaube.Kueche on")}else {fhem ("set Dunstabzugshaube.Kueche off")}}
Zitat von: Diamond_72 am 19 August 2020, 12:00:50
Irgendetwas scheint an meinem "Script" oben falsch zu sein. Tut sich nichts...
Tut sich nichts ist nat. eine super Fehlerbeschreibung ;)
NOCH MAL: wie hast du das notify erstellt!!?? Siehe meinen ersten Post!
Ich vermute, dass die RegEx des notify also der "Trigger" nicht stimmt...
Bau doch mal eine Logausgabe ein, dann siehst du was passiert bzw. ob das notify überhaupt auslöst...
Fenster.Kueche.Auf {Log3(undef,1,"KuecheAufNotify");; if (ReadingsVal ("TFK.Kueche", "state", "undef") eq "open"){fhem ("set Dunstabzugshaube.Kueche on")}else {fhem ("set Dunstabzugshaube.Kueche off")}}
Gruß, Joachim
Ich habe das Notify einfach so über die Befehlszeile angelegt.
Hier mal ein Bild.
Aktuell ist das Fenster auf open und der Aktor von der Dunstabzugshaube ist leider immer noch off...
Zitat von: Diamond_72 am 19 August 2020, 12:46:51
Ich habe das Notify einfach so über die Befehlszeile angelegt.
Und warum nicht über den EventMonitor!?
Weil dann würde es verm. gehen/gegangen sein...
Die Logmeldung mal eingebaut!?
EDIT: ok sieht man im Bild ;)
Erscheint der Eintrag im Log!?
Nein -> notify triggert nicht!
EDIT: das Device welches das Event schickt heißt "Fenster.Kueche"!? Und der Event der kommt heißt "Auf"!? Bzw. ist das ja auch schon nicht richtig, weil: define nName notify Device:Event {} bzw. define <name> notify <Suchmuster> <command> siehe: https://wiki.fhem.de/wiki/Notify und https://fhem.de/commandref.html#notify
EDIT: und spätestens wenn du dich mal mit RegEx (und fhem/Perl ist "voll davon" ;) ) beschäftigt hast, wirst du sehen, dass "Punkte" in Namen nicht gut sind... ;)
Zitat von: Diamond_72 am 19 August 2020, 12:46:51
Hier mal ein Bild.
Aktuell ist das Fenster auf open und der Aktor von der Dunstabzugshaube ist leider immer noch off...
KEINE BILDER!!
Wenn dann ein list!
Also:
list DeviceName
in fhemWeb und dann die Ausgabe hier in "code-Tags" (das '#' im "Menü") posten...
Ein list des notify und des auslösenden Fensters würden helfen...
EDIT: bzw. einfach mal irgendwas von dem was hier "angeboten" wird auch "annehmen" ;)
Gruß, Joachim
Also nochmal zur Verständnis, damit das hier kein Salat wird :D
Das Device (Fensterkontakt) heißt TFK.Kueche
Das notify heißt Fenster.Kueche
Hier das List vom notify
Internals:
DEF Fenster.Kueche.Auf {Log3(undef,1,"Fenster.Kueche");; if (ReadingsVal ("TFK.Kueche", "state", "undef") eq "open"){fhem ("set Dunstabzugshaube.Kueche on")}else {fhem ("set Dunstabzugshaube.Kueche off")}}
FUUID 5f3cc5f9-f33f-2c46-df17-81a8ee31ef14b0fc
NAME Fenster.Kueche
NR 105
NTFY_ORDER 50-Fenster.Kueche
REGEXP Fenster.Kueche.Auf
STATE active
TYPE notify
READINGS:
2020-08-19 12:41:33 state active
Attributes:
room Küche
List von TFK.Kueche
Internals:
DEF 6B5A71
FUUID 5f2dc846-f33f-2c46-8606-903a83a066d84519
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 2
NAME TFK.Kueche
NOTIFYDEV global
NR 101
NTFY_ORDER 50-TFK.Kueche
STATE open
TYPE CUL_HM
chanNo 01
lastMsg No:29 - t:10 s:6B5A71 d:B0EF51 0601C800
myHmUART_MSGCNT 2
myHmUART_RAWMSG 0501005429A6106B5A71B0EF510601C800
myHmUART_RSSI -84
myHmUART_TIME 2020-08-19 12:18:01
protCmdPend 6 CMDs_pending
protLastRcv 2020-08-19 12:18:01
protRcv 2 last_at:2020-08-19 12:18:01
protResnd 1 last_at:2020-08-19 12:18:06
protSnd 3 last_at:2020-08-19 12:18:01
protState CMDs_pending
rssi_at_myHmUART cnt:2 min:-85 max:-84 avg:-84.5 lst:-84
READINGS:
2020-08-19 12:09:03 Activity alive
2020-08-19 09:53:57 CommandAccepted no
2020-08-08 00:11:38 D-firmware 1.0
2020-08-08 00:11:38 D-serialNr PEQ2232128
2020-08-19 09:53:56 PairedTo 0xB0EF51
2020-08-08 00:03:39 R-cyclicInfoMsg on
2020-08-08 00:09:45 R-eventDlyTime 0 s
2020-08-08 00:11:39 R-pairCentral 0xB0EF51
2020-08-08 00:03:39 R-sabotageMsg on
2020-08-08 00:09:45 R-sign on
2020-08-08 00:10:41 aesCommToDev ok
2020-08-08 00:10:41 aesKeyNbr 00
2020-08-19 12:18:01 alive yes
2020-08-19 12:18:01 battery ok
2020-08-19 12:18:01 contact open (to myHmUART)
2020-08-19 12:18:01 recentStateType info
2020-08-19 12:18:01 sabotageError off
2020-08-19 12:18:01 state open
2020-08-19 09:54:02 trigDst_B0EF51 noConfig
2020-08-07 23:50:01 trigDst_broadcast noConfig
2020-08-19 09:54:02 trigger_cnt 37
cmdStack:
++A001B0EF516B5A7100040000000000
++A001B0EF516B5A7101040000000001
++A001B0EF516B5A710103
++A001B0EF516B5A7100040000000000
++A001B0EF516B5A7101040000000001
++A001B0EF516B5A710103
helper:
HM_CMDNR 41
cSnd ,01B0EF516B5A7100040000000000
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +6B5A71,02,00,00
nextSend 1597832282.01523
prefIO
rxt 2
vccu
p:
6B5A71
00
00
00
mRssi:
mNo 29
io:
myHmUART:
-82
-82
prt:
bErr 0
sProc 2
sleeping 0
wuReSent 2
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO myHmUART
flg A
ts 1597832281.71997
ack:
HASH(0x39a1fb8)
298002B0EF516B5A7100
rssi:
at_myHmUART:
avg -84.5
cnt 2
lst -84
max -84
min -85
tmpl:
Attributes:
IODev myHmUART
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
icon fts_window_1w_tilt
model HM-SEC-SCO
peerIDs 00000000,
room Küche
serialNr XXXXXXXXXX
subType threeStateSensor
Sorry, ich wusste nicht, dass Punkte im Namen nicht gut sind.... Muss dann wohl meine Devices umbennen. Ich hatte eigentlich die Idee immer dabei erst den Typ und dann den Raum im Namen aufzunehmen, so kann man die Sachen immer gut zuordnen...
Vielleicht noch eine Verständnisfrage, wo findet man das log, wenn man ein Logging an die Definition anhängt (notify)? Wird das in einer einzelnen log Datei geloggt? Ahhh habs im Eventlog sieht man es. 020.08.19 13:13:41 3 : Notify getriggert
Jep, sorry wegen der Namen... ;)
Der Eintrag sollte im ganz normalen fhem Log stehen...
Ich würde trotzdem mal das notify neu anlegen lassen vom EventMonitor.
Du kannst mittels RegEx auch gleich angeben, WAS GENAU "triggern" soll, sollte man immer tun/versuchen: damit das notify nicht ständig auslöst und "berechnen" muss...
Weil dann das notify in etwa so aussehen müsste:
define Fenster.Kueche.Auf notify TFK.Kueche:(open|closed) {}
Dann reagiert es nur, wenn TFK.Kueche auf oder zu geht...
Und in $EVENT oder $EVTPART1 steht dann sogar direkt der Status drin, dann brauchst du gar kein ReadingsVal oder Value mehr...
Also mal:
define Fenster.Kueche.Auf notify TFK.Kueche:(open|closed) {Log3(undef,1,"NeuesNotify $EVENT")}
Dann siehst du was kommt und damit kannst du dann if/else etc. machen.
ABER: besser mal mit dem EventMonitor anlegen lassen...
EDIT: der Punkt hat halt bei RegEx eine "besondere" Bedeutung: er bedeutet "irgendein Zeichen", also: abc.123 "matcht" also auf alles was mit abc anfängt, dann "irgendein Zeichen" hat und mit 123 weiter geht... ;)
EDIT: und aufpassen! nicht "verwechseln" mit "wild card"! Wenn du willst, dass RegEx auf "alles" matcht, dann ist es NICHT * sondern eben .* ;) ("irgendein Zeichen" -> Punkt und das "endlos" -> Stern...)
Gruß, Joachim
Ok, ich werde es ausprobieren und versuchen zu testen.
Habe ich eigentlich die Möglichkeit die Namen in irgendeiner Form in der fhem.cfg oder ähnlichem umzubenennen?
Das wird ja sonst sehr aufwendig...
Moin,
bitte NICHT selbst in der fhem.cfg ändern - NEVER !!!!
Die Commandref ist Dein Freund, siehe rename.
Moin
Bernd
Naja, du kannst das mit dem Punkt im Namen (erst mal) schon lassen.
Wenn dir bewusst ist (und das ist es ja jetzt), dass eben der Punkt bei RegEx eine "Sonderrolle" hat, dann geht das schon.
Wichtig ist das halt "im Auge" zu behalten... ;)
Gruß, Joachim
Wenn du es ändern willst, sind evtl. Unterstriche besser...