Hallo zusammen,
eine Lampe (mit Bewegungsmelder ohne Dämmerungsschalter) soll erstmal zeitgeschaltet sein (wenn ein Zwave Bewegungsmelder mit Dämmerungsschalter integriert ist - demnächst abhängig von dessen Dämmerungssensor).
Folgendes (übernommen aus einem funktionierendne CodeSchnipsel für mehrere Bedingungen - die hier ja auch demnächst gelten sollen) macht gar nichts. Auch im Log ist dazu nichts zu finden.
Ein simples manuelle "set GT.Licht.Haustuer on" oder "set GT.Licht.Haustuer off" tuts aber. Der Name stimmt also. On / off tuts auch.
###### Haustür Bewegungssensor Lampe Auto AN und Auto Aus; Zeitsteuerung, später auf Dämmerungssensor umstellen bzw. diesen als Bedingung ergänzen
define HaustuerLichtAn at *16:30:00 { if(("GT.Licht.Haustuer") eq "off") { fhem("set GT.Licht.Haustuer on")}}
setuuid HaustuerLichtAn 5fa04d9e-f33f-826a-6952-e65903bf5d0acf13
define HaustuerLichtAus at *08:30:00 { if(("GT.Licht.Haustuer") eq "on") { fhem("set GT.Licht.Haustuer off") }}
setuuid HaustuerLichtAus 5fa04d9e-f33f-826a-ec45-6f8207db796af16a
###### Haustür Licht Ende
Weil "GT.Licht.Haustuer" ein String ist, das nie gleich "off" oder gleich "on" sein kann, sondern nur gleich... "GT.Licht.Haustuer"
Du brauchst eine Funktion: ReadingsVal() oder schlimmsten Fall Value()
Siehe https://fhem.de/commandref_DE.html#perl , Abschnitt "Um auf die Gerätestatus/Attribute zuzugreifen benutzen Sie bitte die folgenden Funktionen"
Danke für den Tipp! Da hab ich anscheinend echt blöd aus meiner fhem.cfg kopiert.
Hier ist es ja mit "value"
## Wintermodus ANFANG
define QuellsteinUntenAutoAnWT at *16:30:00 { if((Value("GT.Power.Quellstein1_Automation") eq "on") && (Value ("GT.Power.Quellstein1") eq "off") && $we == 0) { fhem("set GT.Power.Quellstein1 on;; set GT.Power.NordPool on;; set Sonos_EZ Speak 20 de Power Quell stein unten eingeschaltet!;; set Power.Mobil.1 on") }}
setuuid QuellsteinUntenAutoAnWT 5ea091dc-f33f-826a-3211-0a1c69bdb05acd70
define QuellsteinUntenAutoAnWE at *16:30:00 { if((Value("GT.Power.Quellstein1_Automation") eq "on") && (Value ("GT.Power.Quellstein1") eq "off") && $we == 1) { fhem("set GT.Power.Quellstein1 on;; set GT.Power.NordPool on;; set Sonos_EZ Speak 20 de Power Quell stein unten eingeschaltet!;; set Power.Mobil.1 on") }}
setuuid QuellsteinUntenAutoAnWE 5d028802-f33f-826a-5bbf-54b7260aba75ca2e
## Wintermodus ENDE
Jetzt wäre ein "list" von GT.Power.Quellstein1_Automation und von GT.Power.Quellstein1 interessant.
Und wenn Du dabei bist, poste bitte zur Sicherheit ein echtes "list" von deinen ATs
Aber wie Amenomade schon angedeutet hat: schlimmstenfalls ein Value!
Also: Value(DeviceName) "frägt" das INTERNAL STATE ab! NICHT das Reading state! STATE wird z.B. durch stateFormat beeinflusst und hat dann (oft) nicht den Wert den man haben möchte...
Daher besser: ReadingsVal / ReadingsNum / AttrVal / InternalVal / ...
Und: besser gar nicht erst angewöhnen in der fhem.cfg zu editieren! Und wenn schon angewöhnt: versuchen abzugewöhnen ;)
(Spätestens wenn du sowas wie alexa-fhem etc. verwendest, dann wirst du mit dem direkten Editieren AUCH mittels Editor der fhem-Oberfläche [Stichwort: Edit Files] "auf die Nase fallen")
Gruß, Joachim
Zitat von: amenomade am 07 November 2020, 23:05:30
Jetzt wäre ein "list" von GT.Power.Quellstein1_Automation und von GT.Power.Quellstein1 interessant.
Und wenn Du dabei bist, poste bitte zur Sicherheit ein echtes "list" von deinen ATs
Die Dinger funktionieren wie sie sollen eigentlich.
Hier die List outputs:
Dummy um die Automatisierung ein/auszuschalten
Internals:
FUUID 5d028802-f33f-826a-152f-ee3465a84f547f1e
NAME GT.Power.Quellstein1_Automation
NR 118
STATE off
TYPE dummy
READINGS:
2020-04-22 19:33:29 state off
Attributes:
alexaName Quellstein Automatik
alias QuellsteinU Automode
devStateIcon on:general_an_fuer_zeit@green off:general_aus_fuer_zeit@red
icon general_an_fuer_zeit
room Garten
setList on off
webCmd on:offZeitsteuerung Quellstein
Internals:
DEF 55533A01
FUUID 5d028801-f33f-826a-3f08-c43659c60ecf4dc9
NAME GT.Power.Quellstein1
NOTIFYDEV global
NR 31
STATE off
TYPE CUL_HM
chanNo 01
device Garten.4Switch.G1
READINGS:
2020-07-17 19:18:03 CommandAccepted yes
2017-09-24 15:50:47 R-powerUpAction off
2017-09-24 15:50:47 R-sign off
2020-06-07 12:53:44 RegL_01. 00:00 08:00 30:06 56:00 57:24
2020-11-08 09:52:31 deviceMsg off (to vccu)
2020-11-08 09:52:31 level 0
2017-09-24 15:49:10 levelMissed desired:100
2020-11-08 09:52:31 pct 0
2020-11-08 09:52:31 recentStateType info
2020-11-08 09:52:31 state off
2020-11-08 09:52:31 timedOn off
2020-07-17 19:18:03 trigLast fhem:02
helper:
peerFriend peerSens,peerVirt
peerOpt 3:switch
regLst 1,3p
cmds:
TmplKey :no:1604825549.98385
TmplTs 1604825549.98385
cmdKey 1:0:0::Garten.4Switch.G1:0003:01:
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
lst:
condition slider,0,1,255
peer
peerOpt
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
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
role:
chn 1
tmpl:
Attributes:
alexaName Quellstein
alias Quellstein unten
devStateIcon on:FS20.on@yellow
group Power
icon sani_garden_pump
model HM-LC-SW4-DR
peerIDs 00000000,
room Garten
sortby 1
webCmd on:off
Zitat von: MadMax-FHEM am 07 November 2020, 23:09:37
Aber wie Amenomade schon angedeutet hat: schlimmstenfalls ein Value!
Also: Value(DeviceName) "frägt" das INTERNAL STATE ab! NICHT das Reading state! STATE wird z.B. durch stateFormat beeinflusst und hat dann (oft) nicht den Wert den man haben möchte...
Daher besser: ReadingsVal / ReadingsNum / AttrVal / InternalVal / ...
Und: besser gar nicht erst angewöhnen in der fhem.cfg zu editieren! Und wenn schon angewöhnt: versuchen abzugewöhnen ;)
(Spätestens wenn du sowas wie alexa-fhem etc. verwendest, dann wirst du mit dem direkten Editieren AUCH mittels Editor der fhem-Oberfläche [Stichwort: Edit Files] "auf die Nase fallen")
Gruß, Joachim
Äh ja .. hab tatsächlich in der fhem.cfg editiert für den ganzen Krempel. Ist total unübersichtlich und überlege schon alles in z.b. notepad++ mal zu sortieren und erweitert zu kommentieren. Für einfacheres edit der fhem.cfg hab ich mal eine formatierte ansicht in fhem davon eingerichtet.
Wie mach ich das denn stattdessen besser? Immerhin scheine ich auch mal ein Auto Backup für jedes Save eingerichtet zu haben:
###### Backup fhem.cfg + fhem.stat at every save ######
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}
setuuid backupCfg 5d028802-f33f-826a-7aaf-81e696387560ecc7
###### Backup Ende ######Simpelzeitsteuerung mit zunächst nur einer Bedingung dann so oder (noch mit der EDIT Variant :( )?
###### Haustür Bewegungssensor Lampe Auto AN und Auto Aus; Zeitsteuerung, später auf Dämmerungssensor umstellen bzw. diesen als Bedingung ergänzen
define HaustuerLichtAn at *16:30:00 { if(value("GT.Licht.Haustuer") eq "off") { fhem("set GT.Licht.Haustuer on")}}
setuuid HaustuerLichtAn 5fa04d9e-f33f-826a-6952-e65903bf5d0acf13
define HaustuerLichtAus at *08:30:00 { if(value("GT.Licht.Haustuer") eq "on") { fhem("set GT.Licht.Haustuer off") }}
setuuid HaustuerLichtAus 5fa04d9e-f33f-826a-ec45-6f8207db796af16a
###### Haustür Licht Ende
Gar NICHT "DIRETKT" editieren!
Übersicht ist doch in fhemWeb gegeben (wenn man entsprechend group, room, etc. nutzt)!
Alles geht (besser!) über die Weboberfläche!
Also entweder die "Knöpfe" (bei jedem Device in der Detail-Ansicht) nutzen oder eben das Web-cmd-Fenster.
Oder (wenn du ganz "tief" rein willst ;) ): raw Definition...
EDIT: zu finden "unter" jedem Device (Detail-Ansicht), damit kann man auch andere Devices bearbeiten/anlegen (z.B. "Code" aus dem Forum, der in rawDef ist einfügen etc.) / Oder (im "neuesten Default-Style") das "Plus-Zeichen" links oben...
Ich habe zu Beginn auch direkt editiert, weil ich dachte mehr Übersicht zu haben und kommentieren zu können etc.
Es gibt übrigens bei jedem Device auch das Attribut comment ;)
Dort trage ich (mittlerweile) "wichtige" Infos etc. ein...
Und wie geschrieben: es gibt Module (alexa-fhem ist nur eins davon), da wird direktes editieren (bzw. die Nutzung von rereadcfg [was dabei "ausgeführt" wird, um die Config wieder zu "laden"]) SCHIEF GEHEN!
(ich wollte es nur [noch mal] angemerkt haben)
So nun zum Code:
Wenn du schon Funktionen verwendest, dann auch richtig schreiben: value != Value
UND: lieber NICHT Value, sondern eben ReadingsVal/ReadingsNum etc. (Erläuterung siehe meine Antwort zuvor)
UND: warum postest du WIEDER Ausschnitte aus der cfg bzgl. der at, wenn amenomade doch ein list haben wollte?! ;)
(wobei nat. in diesem Fall der [verm.] Fehler auch so zu sehen sein dürfte ;) )
Gruß, Joachim
Das muss ich dann noch lernen wo ich klicken muss. Wie erstelle ich z.B. ein "at" dann? Wenn es eins gibt finde ich es und kann es jetzt auch über die weboberfläche bzgl. seiner "DEF" ändern. Wenn das alles über fhem web geht mag das tatsächlich besser sein.
Die angefragten List finden sich oben.
Ein List von HaustuerLichtAn ist dieses:
Internals:
COMMAND { if(Value("GT.Licht.Haustuer") eq "off") { fhem("set GT.Licht.Haustuer on")}}
DEF *16:30:00 { if(Value("GT.Licht.Haustuer") eq "off") { fhem("set GT.Licht.Haustuer on")}}
FUUID 5fa04d9e-f33f-826a-6952-e65903bf5d0acf13
NAME HaustuerLichtAn
NR 102
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 16:30:00
TIMESPEC 16:30:00
TRIGGERTIME 1604849400
TRIGGERTIME_FMT 2020-11-08 16:30:00
TYPE at
READINGS:
2020-11-08 10:23:38 state Next: 16:30:00
Attributes:
Du kannst entweder "leere" Devices erstellen:
define DeviceName Typ "Einstellungen" {}
Also bei einem at:
define DeviceName at *12:00:00 {}
Oder notify:
define DeviceName notify TriggerDevice:TriggerRegEx {}
Und dann in der jeweiligen Device-Ansicht die "leere Ausführung" ( die { } ) bearbeiten.
ODER eben per RawDef.
D.h. unter einem Device (z.B. eines at/notify etc.) auf Raw Definition klicken.
Dann das Device bearbeiten (so als wenn du ein kopiertes Device in der cfg bearbeitet/angelegt hättest), also z.B. den Devicenamen ändern und somit ein "neues" at anlegen, eben mit dem neuen Namen...
Oder auch (was immer häufiger wird) Devices hier aus dem Forum (wenn sie in RawDef gepostet wurden) über dieses "Fenster" dann direkt in die cfg einfügen.
Einfach mal bzgl. Raw-Definition suchen...
Was passiert, wenn du jetzt das at "Zwangsauslöst"? Also exec-now? Dann sollte es funktionieren...
EDIT: also zumindest eines von beiden ;) Weil das Licht ja entweder aus ist und dann an gehen sollte oder eben an ist und aus gehen sollte ;)
Und noch mal: ich würde NICHT Value nehmen...
Gruß, Joachim
Andere Frage: warum frägst du überhaupt den Zustand des Devices ab, den du dann (abhängig ob der andere Zustand) doch (evtl.) eh ein/ausschaltest?
Das was du hier mit if usw. machst geht auch mit Filter.
Also Gerät nur ausschlten, wenn auch an...
(Spart maximal ein Funktelegramm und wird ja nur 2x am Tag ausgeführt, 1x für an und 1x für aus / da ist die vorherige Abfrage naja ;) )
Und zwischendrin war mal eine Variante wo "GT.Power.Quellstein1_Automation" abgefragt wurde...
Jetzt wäre ein list von GT.Licht.Haustuer noch interessant... ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 08 November 2020, 11:51:39
Jetzt wäre ein list von GT.Licht.Haustuer noch interessant... ;)
Wollte ich gerade sagen.
Am Anfang ging es um HaustuerLichtAn mit GT.Licht.Haustuer im Befehl, aber mit falscher Syntax. Wir haben jetzt ein "list" vom at aber kein "list" von GT.Licht.Haustuer
Dann ging es um QuellsteinUntenAutoAnWT mit ...Quellstein... im Befehl. Wir haben ein "list" von den ...Quellstein... Devices, aber kein "list" vom at
Zwischendurch ein Exkurs über backup... und jetzt wieder HaustuerLichtAn
Kann man sich vielleicht auf einem einzigen Ding konzentrieren?
Wie Joachim gefragt hat, was passiert bei "set HaustuerLichtAn execNow"? Wird das Licht eingeschaltet oder nicht?
Zitat von: amenomade am 08 November 2020, 12:43:55
Wollte ich gerade sagen.
Am Anfang ging es um HaustuerLichtAn mit GT.Licht.Haustuer im Befehl, aber mit falscher Syntax. Wir haben jetzt ein "list" vom at aber kein "list" von GT.Licht.Haustuer
Dann ging es um QuellsteinUntenAutoAnWT mit ...Quellstein... im Befehl. Wir haben ein "list" von den ...Quellstein... Devices, aber kein "list" vom at
Zwischendurch ein Exkurs über backup... und jetzt wieder HaustuerLichtAn
Kann man sich vielleicht auf einem einzigen Ding konzentrieren?
Gut, dann bin nicht nur ich durcheinander (gekommen) ;)
Wäre wirklich gut, wenn du schreiben würdest was du (wirklich) willst und von den beteiligten Devices list postest... :)
EDIT: der besseren Übersicht wegen viellleicht durchaus auch "noch mal", selbst wenn es bereits hier irgendwo zu finden ist...
Gruß, Joachim
Richtig - das war ein Missverständnis. Ich habe die list gepostet Die ihr erfragt habt. Das waren aber nicht die problematischen.
Wahrscheinlich habe ich unglücklich formuliert. Alles mit Quellstein funktioniert. Davon habe ich aber falsch übernommen (nämlich ohne Value) für die zunächst nicht funktionierenden AT/IF. HaustuerLichtAn / Aus -- jetzt funktioniert es offenbar :-)
Ihr seid so oder so die Besten und habt super geholfen.
Habe jetzt gelernt:
1.) das ich fhem.cfg nicht editieren soll und wie es grob stattdessen geht
2.) und das ich "Value" mal ersetzen sollte bzw. das mindestens noch benötigt habe
3.) Das derartige code schnipsel sofort getestet werden können mit zum Beispiel: "set HaustuerLichtAn execNow" :-)
Vielen Dank also Euch beiden! Stelle das Thema auf gelöst :-)
Zitat von: MadMax-FHEM am 08 November 2020, 11:51:39
Andere Frage: warum frägst du überhaupt den Zustand des Devices ab, den du dann (abhängig ob der andere Zustand) doch (evtl.) eh ein/ausschaltest?
Das was du hier mit if usw. machst geht auch mit Filter.
Also Gerät nur ausschlten, wenn auch an...
(Spart maximal ein Funktelegramm und wird ja nur 2x am Tag ausgeführt, 1x für an und 1x für aus / da ist die vorherige Abfrage naja ;) )
Gruß, Joachim
Achtung: Zweite Antwort auf Eure Rückfragen und Anmerkungen
Das IF kann ja auch mit mehreren Bedingungen klar kommen Verknüpfung mit && wenn ich mich recht erinnere. Ich will demnächst statt der Uhrzeit oder ergänzend (wenn das geht) den Globalstrahlungswert (oder wie auch immer das heißen mag) von einem anderen Bewegungsmelder mit Dämmerungssensor Verknüpfen.
Ja und es spart ein Funktelegram .. irgendwo hieß es mal damit solle man möglichst sparsam sein. Die BNetzA Vorgaben begrenzen das pro Zeiteinheit - oder?
Beste Grüße
Sammy
Nur mal eine Frage am Rande:
Warum geht Ihr für eine "Kleinigkeit" wie ein pures if gleich in die perl-Ebene? Giebtes nicht sogar ein Modul dafür? https://www.fhem.de/commandref.html#IF (https://www.fhem.de/commandref.html#IF)
Zitat von: Sammy51 am 08 November 2020, 13:50:53
Achtung: Zweite Antwort auf Eure Rückfragen und Anmerkungen
Das IF kann ja auch mit mehreren Bedingungen klar kommen Verknüpfung mit && wenn ich mich recht erinnere. Ich will demnächst statt der Uhrzeit oder ergänzend (wenn das geht) den Globalstrahlungswert (oder wie auch immer das heißen mag) von einem anderen Bewegungsmelder mit Dämmerungssensor Verknüpfen.
Jaja ;)
Zitat von: Sammy51 am 08 November 2020, 13:50:53
Ja und es spart ein Funktelegram .. irgendwo hieß es mal damit solle man möglichst sparsam sein. Die BNetzA Vorgaben begrenzen das pro Zeiteinheit - oder?
Ja im Prinzip schon.
Aber durch diese Abfrage sind es u.U. ZWEI Telegramme am Tag... ;)
Aber klar, wenn es "zum Üben" war bzw. später durch weitere Abfragen ergänzt wird, dann kann man das so tun.
Ansonsten gibt es eben für die Variante "nur Telegramme" (oder Befehle generell) sparen auch die Variante mit Filter: set DeviceName [FILTER=STATE!=off] off
(siehe commandref devSpec / dazu dann eben nicht mal Perl ;) )
Gruß, Joachim
Zitat von: MadMax-FHEM am 08 November 2020, 14:00:06
Ansonsten gibt es eben für die Variante "nur Telegramme" (oder Befehle generell) sparen auch die Variante mit Filter: set DeviceName [FILTER=STATE!=off] off
(siehe commandref devSpec / dazu dann eben nicht mal Perl ;) )
Gruß, Joachim
Das ist auch cool und gut zu wissen - obschon man sich dann fast schon fragen kann weshalb das nicht grundsätzlich so ist - dass ein Befehl nur ausgeführt wird wenn der Status des devices "nicht eh schon so ist". Oder ist das für den Fall das der Status nicht korrekt vorliegt / übermittelt wurde?
Meine neuen düwi zwave Zwischenstecker z.B. übermitteln einen lokal (Button am Gerät) veränderten Status offenbar nicht ::)
Zusätzliche heutige "lessons learned also" ...
4.) set DeviceName + Filter zum Status möglich (s.o.)
5.) Wenn die Kinder schlafen sollte ich mal etwas Zeit investieren die docu zu lesen - dann macht FHEM vermutlich noch mehr Spaß ... und vielleicht kann ich dann demnächst mal eine Anwesenheitssimulation glaubhaft "programmieren"
Danke nochmal für Eure "heutige" Geduld und die Tipps!
Sammy
Weil man manchmal eben trotzdem das Event braucht, dass es ja bei set-Befehlen gibt...
Und bei manchen Geräten (z.B. ohne Rückkanal) manchmal (zur Sicherheit) eben mehrfach durchaus auch gesendet wird/werden will...
Es gibt also durchaus Gründe das nicht einfach zu "unterdrücken".., ;)
Zitat
Meine neuen düwi zwave Zwischenstecker z.B. übermitteln einen lokal (Button am Gerät) veränderten Status offenbar nicht
Kenne die zwar nicht aber ansonsten ist ZWave schon eher mit Statusmeldung etc.
Gruß, Joachim
Ok - die ollen düwi Dinger (kein Statuswechsel bei "lokalem manuellem Schalten") sind ja auch ein Beispiel.
ZitatEDIT: Das die Düwi das nicht können steht in der FHEM zwave doku - und das ist offenbar wirklich so. Es soll wohl baugleiche mit verbesserter Firmware unter anderem Label geben. Die düwi konkret bekommt man auch kaum mehr. War wohl ein Lagerausverkauf aus dem meine sind (10Euro/Stück)
Ein NodOn Enocean Aktor von mir reagiert manchmal auch einfach nicht.
Hab schon überlegt für den das set on / off jeweils 2-3 mal einzubauen in der Hoffnung das es dann zuverlässiger klappt.
EDIT: Noch eine Frage im Gesamtzusammenhang. Da ich bislang die FHEM.CFG ständig editiert habe - sollte ich bevor ich das nun lasse einmal aufräumen und vernünftig sortieren? Oder lasse ich das Ding am besten wie es ist?
Hab jetzt ein erstes leeres device (ein dummy) angelegt via "define test dummy" danach musse ich dann aber jedes nötige atribut einzeln hinzufügen (webcmd, setlist, icon ...) geht das auch praktischer? Habe andere Dummies die genauso sind (hätte ich bislang schlicht dupliziert und umbenannt)?
Kann ich dann ein watchdog an eine bedingung knüpfen? Der Soll das licht nur automatisch nach 10min ausschalten - wenn der Dummy test on ist.
Den Watchdog habe ich schon - er schaltet auch das richtige Licht nach 10min au (früher hat er dann via Sonos gesagt "ist schon 10min an" - das nervt aber meine Frau die es meist anließ ;-) )
Per raw definition kannst du alles eingeben wie du willst und einen bestehenden auch "duplizieren" etc.
EDIT: hatte ich aber ja schon mal ausführlich beschrieben... ;)
Watchdog hab ich noch nicht genutzt, sollte aber ja in commandref und Wiki beschrieben sein...
Gruß, Joachim
Ja die RAW VAriante habe ich nicht ganz verstanden.
Wenn ich diese für ein device öffnen -- kann ich dort in jeder Zeile den Namen ändern und beim speichern ist das ein neues Device? Oder ist das bestehende dann geändert?
Hab ich halt zunächst nicht gefunden in der docu. Jetzt doch gefunden. Evtl. kann im <command> ein if verwendet werden
ZitatDefine
define <name> watchdog <regexp1> <timespec> <regexp2> <command>
Start an arbitrary FHEM command if after <timespec> receiving an event matching <regexp1> no event matching <regexp2> is received.
The syntax for <regexp1> and <regexp2> is the same as the regexp for notify.
<timespec> is HH:MM[:SS]
<command> is a usual fhem command like used in the at or notify
Examples:
# Request data from the FHT80 _once_ if we do not receive any message for
# 15 Minutes.
define w watchdog FHT80 00:15:00 SAME set FHT80 date
# Request data from the FHT80 _each_ time we do not receive any message for
# 15 Minutes, i.e. reactivate the watchdog after it triggered. Might be
# dangerous, as it can trigger in a loop.
define w watchdog FHT80 00:15:00 SAME set FHT80 date;; trigger w .
# Shout once if the HMS100-FIT is not alive
define w watchdog HMS100-FIT 01:00:00 SAME "alarm-fit.sh"
# Send mail if the window is left open
define w watchdog contact1:open 00:15 contact1:closed "mail_me close window1"
attr w regexp1WontReactivate
Notes:
if <regexp1> is . (dot), then activate the watchdog at definition time. Else it will be activated when the first matching event is received.
<regexp1> resets the timer of a running watchdog, to avoid it use the regexp1WontReactivate attribute.
if <regexp2> is SAME, then it will be the same as the first regexp, and it will be reactivated, when it is received.
trigger <watchdogname> . will activate the trigger if its state is defined, and set it into state defined if its state is active (Next:...) or triggered. You always have to reactivate the watchdog with this command once it has triggered (unless you restart fhem)
a generic watchdog (one watchdog responsible for more devices) is currently not p
Wie machst Du ohne Watchdog das nach x-Minuten etwas passieren soll, wenn diese Prüfung aktiv geschaltet ist?
Wenn du den Namen in der Raw Def änderst ist es ein neues Device mit dem neuen Namen...
EDIT: die "setstate-Einträge" kannst du löschen...
Den Namen eines bestehenden Devices änderst du mit rename...
Ich mache das mit einem at...
Aber immer wild zwischen Lösungsmöglichkeiten "hüpfen" bringt dich (verm.) nicht weiter...
Lese dich ein und entscheide...
Gruß, Joachim
Ich muß gestehen, das ich bei mehreren gleichen Devices eines richtig einstelle und dieses dann "nur" copiere und dort partil anpasse. Spart mir dauerndes "neuüberlegen"
Zitat von: Wernieman am 11 November 2020, 09:09:34
Ich muß gestehen, das ich bei mehreren gleichen Devices eines richtig einstelle und dieses dann "nur" copiere und dort partil anpasse. Spart mir dauerndes "neuüberlegen"
Das geht ja per "Raw Def"...
Mache ich auch so: ich nehme eines was schon da ist und tut, klicke auf RawDef und passe es an (also mind. neuer Name, damit es ein neues Device wird ;) ) und fertig :)
Gruß, Joachim
Ich verwende immer ein "copy" ..... gab es schon vor "RAF Def"
Und bin dort "zu faul" zum Umdenken ;o)
Zitat von: Wernieman am 11 November 2020, 09:52:18
Ich verwende immer ein "copy" ..... gab es schon vor "RAF Def"
Und bin dort "zu faul" zum Umdenken ;o)
copy?
Aha, wie das? Kenne ich (noch) nicht...
Aber ich kann auch mit "RawDef" leben.
Ist dem direkten Editieren (das ich noch "kenne" und getan habe) am nächsten :)
Gruß, Joachim
Rawdef hat einen großen Vorteil gg. copy: Die internen Datenstrukturen werden bei dem neuen Device auch neu aufgebaut ;) .
Ich hatte ein paar Mal "komische" Effekte (bei MQTT2_DEVICE?, aber afaik ist das nicht beschränkt darauf) mit copy, die dann nur durch einen Neustart zu beseitigen waren. Von daher klare Empfehlung: Umlernen!
(Ich habe auch mal mit #include angefangen, weil ich das übersichtlich fand. Aber alles via FHEMWEB zu machen (und configdb search nutzen zu können), haben den Abschied von dieser unkomfortabelen Methode deutlich erleichtert. Und "list mit devspec" (samt -r-Option) ist auch einfach nur klasse ;) ).
Vielleicht noch ein paar Anmerkungen zum Thema Generalisierung/Doppelungen von Codestückchen:
- Es gibt mit attrTemplate und archetype auch (mind.) zwei Varianten, wie man Dinge "immer wieder gleich" gestalten kann (attrTemplate sollte bei aktivierten SetExtensions auch mit dummy gehen).
- Oft macht es Sinn, für solche wiederkehrenden Dinge dann auf entsprechende Routinen zurückzugreifen, die es "für alle betreffenden Devices gleich" machen, was die Reaktion etc. angeht. Ist einfacher, wenn man mal was anpassen will... watchdog läßt sich leider schlecht dahingehend generalisieren, dass er auf mehrere Devices gleichzeitig hört, aber was ähnliches macht Benni's generalisierter "Fenster-offen-Code" (zu finden über das Wiki zu 99_myUtils.pm anlegen); sowas sollte man sich mAn. nach der ersten Orientierungsphase zu FHEM dann mal näher ansehen.
just my2ct.
Cool das klingt gut probiere ich bei nächster Gelegenheit :-)
Im Moment stimmt etwas mit meiner Schreibweise nicht nehme ich an.
=> Der simple Watchdog mit dem simplen command "set HW.Licht.Decke off" funktionierte.
=> Mit der IF Variante passiert nun nach Ablauf des Timers nichts mehr (egal ob der "Automation Dummy" den State on oder off hat).
Hier ein List vom Watchdog mit "IF" meiner Theorie nach sollte das gehen. IF ist doch auch ein FHEM Command.
Vermutlich passt nur irgendeine Formalität nicht?
Wenn es läuft müsste man nur den Dummy noch so einrichten das ein Einschalten des Dummys auch ein "set HW.Licht.Decke on" absetzt - damit der Watchdog wieder läuft (ohne manuelles erneutes Lichtschalter Betätigen).
Hier ein list vom Watchdog
Internals:
CMD IF ([HW.Licht_Automation] eq on) (set HW.Licht.Decke off); setstate HW.Licht.Decke_an defined
#set Sonos_EZ Speak 20 de Das Licht im Hauswirtschaftsraum ist bereits seit 10 Minuten an; setstate HW.Licht.Decke_an defined
DEF HW.Licht.Decke:on 00:10:00 HW.Licht.Decke:off IF ([HW.Licht_Automation] eq on) (set HW.Licht.Decke off); setstate HW.Licht.Decke_an defined
#set Sonos_EZ Speak 20 de Das Licht im Hauswirtschaftsraum ist bereits seit 10 Minuten an; setstate HW.Licht.Decke_an defined
FUUID 5d028802-f33f-826a-19f0-c56acff3ae32ebbc
NAME HW.Licht.Decke_an
NOTIFYDEV HW.Licht.Decke_an,HW.Licht.Decke
NR 112
NTFY_ORDER 50-HW.Licht.Decke_an
RE1 HW.Licht.Decke:on
RE2 HW.Licht.Decke:off
STATE defined
TO 600
TYPE watchdog
READINGS:
2020-11-11 18:42:42 Activated activated
2020-11-10 21:40:08 Reset reset
2020-11-11 18:52:42 Triggered triggered
Attributes:
room EG
Hier der Dummy der als Bedingung eingebunden sein soll (on = Auto off durch watchdog)
CFGFN
FUUID 5faaf20a-f33f-826a-d5cb-7c430ad592ce000a
NAME HW.Licht_Automation
NR 226
STATE on
TYPE dummy
READINGS:
2020-11-11 18:57:36 state on
Attributes:
devStateIcon on:general_an_fuer_zeit@green off:general_aus_fuer_zeit@red
icon general_an_fuer_zeit
room EG
setList on off
webCmd on:off
Den Tipp zu Fenster offen (als Alternative zum watchdog) gucke ich mir früher oder später mal an. Zunächst hätte ich gedacht ich nehm auch dafür ein watchdog und ein set sonos für eine Sprachhinweis das das Fenster schon länger als x Minuten offen ist (um nach dem Duschen nicht ungewollt zu lange zu lüften)
Eigentlich sollte da was im Log zu finden sein... on ohne Quotes dürfte nicht klappen...
Als Purist tue ich mich mit diesem ganzen neumodischem Gedönse wie IF und set magic schwer, aber vermutlich geht das hier:
DEF HW.Licht.Decke:on 00:10:00 HW.Licht.Decke:off IF ([HW.Licht_Automation] eq "on") (set HW.Licht.Decke off); setstate HW.Licht.Decke_an defined
Meine Tipps:
- den watchdog zurückzusetzen macht man mAn. besser via Attribut;
- Nutze Perl und zwar in der exakent Form. "[HW.Licht_Automation]" ist afaik eigentlich die Kurzform von 'Value("HW.Licht_Automation")', was auch "schillernd" ist (=>stateFormat). Ich schreibe sowas (fast) immer als "ReadingsVal('HW.Licht_Automation','state','off')". Damit ist klar, was gemeint ist und ich brauche Klammern dann, wenn es (aus Perl-Sicht) sinnvoll ist.
- IF fand ich auch mal cool, zwischenzeitlich/seit eingen Jahren habe ich alle IF ausgebaut und mache nur noch Perl-if (in mancherlei Varianten, aber das ist eine andere Story).
Kurz: früher oder später wirst du Perl-Kenntnisse brauchen, also packe den Stier gleich bei den Hörnern!
Die Minimal Korrektur war "on" statt on -richtig?
Deine Empehlung statt
[HW.Licht_Automation] eq "on")
besser:
ReadingsVal('HW.Licht_Automation','state','off') => oder doch 'on' ?
oder alles in " " so etwa:
"ReadingsVal('HW.Licht_Automation','state','on')"
Wenn ich noch verstehen kann warum '..' gesetzt werden (immerhin hab ich den korrekten Button ' auf dem alten macbook gefunden *g*) kann mir die Schreibweise vielleicht sogar besser merken oder zumindest besser später nachvollziehen. Scheint charmant .. vielleicht sollte ich das perl buch doch wieder aus dem Büro Schrank (nicht Homeoffice) heraussuchen.
EDIT: Warum ist IF neumodisch? Das gabs schon mit qbasic (oder wie hieß das noch) und derartigem 90er Jahre Zeug?
EDIT2: Wie setze ich den Watchdog via attribut auf "timer läuft jetzt" (statt mit einem neuen registriertem "on" signal)?
ReadingsVal('HW.Licht_Automation','state','off') eq 'on'Der Vergleich wäre immer angebracht..., ganz ohne "eq" klappt das nicht, aber eben innerhalb eines Perl - "if" (klein geschrieben!).
Suchbegriff wegen der einfachen Quotes: Quotes in Perl.
IF als _FHEM-Befehl_ ist "neumodisch", weil es ein Wrapper für Perl-if-Strukturierungen ist.
Der watchdog läuft eigentlich nach jedem FHEM-Start nur einmalig. Wenn man ihn immer wieder nach dem Auslösen (Eintritt der 2. regex) "reaktivieren will", muß man was tun. Die eine Variante (in einer nicht in der cref stehenden Form) hast du mit dem setreading drin gehabt, welches Attribut diese Konstruktion ersetzen kann, steht dafür aber in der commandref...
Du solltest diese zu watchdog lesen und die Perl-Specials dazu.
Zitat von: Beta-User am 12 November 2020, 20:58:53
ReadingsVal('HW.Licht_Automation','state','off') eq 'on'Der Vergleich wäre immer angebracht..., ganz ohne "eq" klappt das nicht, aber eben innerhalb eines Perl - "if" (klein geschrieben!).
Das verstehe ich (noch) nicht. Bedeutet das nicht frei übersetzt "wenn HW.% Status aus = an dann ...." Aus ist doch nie An?! Oder was sagt der dritte Teil des ReadingsVal (hier 'off')?
Zitat von: Beta-User am 12 November 2020, 20:58:53
Der watchdog läuft eigentlich nach jedem FHEM-Start nur einmalig. Wenn man ihn immer wieder nach dem Auslösen (Eintritt der 2. regex) "reaktivieren will", muß man was tun. Die eine Variante (in einer nicht in der cref stehenden Form) hast du mit dem setreading drin gehabt, welches Attribut diese Konstruktion ersetzen kann, steht dafür aber in der commandref...
Du solltest diese zu watchdog lesen und die Perl-Specials dazu.
Ich sehe eine andere Herausforderung die mir noch nicht gelöst scheint. Oder ich hab auch das noch nicht richtig verstanden.
Stell Dir vor das Licht ist an seit 20min - weil der "Automation Dummy = off ist".
Wenn ich dann den Automation Dumm wieder auf "on" schalte - dann läuft der Timer des Watchdog niemals an - weil er kein neues "Licht on" gesehen hat. Oder?
Würde ich dann nochmal manuell den Lichtschalter betätigen - dann liefer der Watchdog wieder.
Wäre schick wenn das nicht nötig wäre weil z.B. ein einschalten des "Automation Dummy" ein neues "warten des Watchdog auf "Licht off" startet (z.B. indem er gleichzeitig ein "licht on" sendet (der Watchdog prüft doch die zeit zwischen licht on und licht off - oder?).
ReadingsVal("DeviceName","ReadingName","ERSATZWERT") -> wenn das Reading nicht gelesen werden konnte, dann gib ERSATZWERT zurück...
Gruß, Joachim
Zitat von: Sammy51 am 12 November 2020, 21:12:18
Das verstehe ich (noch) nicht.
Auch wenn es unmodern erscheint: in der commandref ist ReadingsVal() erläutert. Bitte mal die Perl specials überfliegen (am besten die modular-Variante der commandref verwenden, das ist m.E. viel übersichtlicher).
Wäre schick wenn das nicht nötig wäre weil z.B. ein einschalten des "Automation Dummy" ein neues "warten des Watchdog auf "Licht off" startet (z.B. indem er gleichzeitig ein "licht on" sendet (der Watchdog prüft doch die zeit zwischen licht on und licht off - oder?).
Dann ergänze doch einfach den "Ersttrigger" des watchdog um den "dummy wird eingschaltet"-Fall.
(Wobei es mich immer leicht gruselt, wenn ich "dummy" lese. Das mag hier angebracht sein, aber oft werden die inflationär genutzt, was nicht eben zur Übersichtlichkeit der Logiken insgesamt beiträgt)...
Zitat von: Beta-User am 15 November 2020, 08:06:13
Auch wenn es unmodern erscheint: in der commandref ist ReadingsVal() erläutert. Bitte mal die Perl specials überfliegen (am besten die modular-Variante der commandref verwenden, das ist m.E. viel übersichtlicher).
Dann ergänze doch einfach den "Ersttrigger" des watchdog um den "dummy wird eingschaltet"-Fall.
(Wobei es mich immer leicht gruselt, wenn ich "dummy" lese. Das mag hier angebracht sein, aber oft werden die inflationär genutzt, was nicht eben zur Übersichtlichkeit der Logiken insgesamt beiträgt)...
Wie wechselt man zur modular variante? https://commandref.fhem.de/
Gute Idee - cool wenn das geht! Wie ergänze ich den Ersttrigger um ein weiteres event? Klammern und Trennzeichen (wenn ja welche)? OR ? ...?
Habe Dummys um Schalter zu definieren die es physikalisch nicht gibt, um bestimmte Automatisierungen aktivieren zu können.
Licht im "HWR Auto Off" z.B. damit es anbleibt wenn ich länger dort bin. Oder Quellstein Zeisteuerung nur im Sommer aktiv wenn genug Wasser im Becken ist (hab leider kein Sensor dafür).
https://fhem.de/commandref_modular_DE.html
Zitat von: amenomade am 15 November 2020, 10:46:08
https://fhem.de/commandref_modular_DE.html (https://fhem.de/commandref_modular_DE.html)
Oder lokal, indem man in global umstellt: https://fhem.de/commandref_modular_DE.html#global:
Zitat
commandref
Falls der Wert "full" (die Voreinstellung) ist, dann wird nach jedem update ein komplettes commandref.html generiert. Falls der Wert "modular" ist, dann wird die Moduldokumentation erst nach Bedarf waehrend der Laufzeit per JavaScript geladen.
Damit läuft übrigens auch ein update deutlich schneller durch....
Was das mit dem zweiten Event als Eingangsbedingung angeht, gilt dasselbe wie für notify (dort unter "addRegexpPart" in der cref zu finden): Trennzeichen ist eine "Pipe" |. Beispiel für ein "dreifaches notify" (mit Prüfung, ob überhaupt was veranlasst werden soll in Perl):
define Umwaelzpumpe_Schalter notify Licht_Bad_Spiegel:on|Schalter_EZ1_Btn_06:short|Schalter_SZ1_Btn_06:short { fhem "set MYSENSOR_96 status1 on" if (ReadingsVal("MYSENSOR_96","temperature21","20")<35)}Sollte mit watchdog genauso gehen.
Cool hab einiges übernommen (leider noch nichts neu aufgesetzt weder auf dem Pi3 noch auf dem produktivem NUC) und ergänzt. Probleme nur plötzlich mit einem NoDon Enocean Modul (separater Thread).
EDIT - war schwer zu finden aber Platzhalter scheint .* zu sein :-) Geänderte Raumzuordnung hat funktioniert. Dabei frage ich mich nun. Was ist bei den Namen besser "Funktion vor Raum Kürzel" (Licht / Schalter / Steckdose) oder "Raum vor Funktion" .... hmm
attr n_LZ.* room DG (was statt %?)
Oder um Alle Lampen anzuschalten:
set .*Licht.* on ?
Vermutlich "suchst" du nach: Punkt Stern
Namensteil.* "greift" auf alle Devices, die mit Namensteil beginnen...
Aber Achtung!!
Z.B.
attr Namensteil.* room NeuerRaum
Damit sind alle Devices NUR im neuen Raum!
D.h. wenn ein Device in 2 (oder mehr) Räumen war, dann ist es nach dem Aufruf in genau dem einen neuen Raum!
Wenn du sehen willst für welche Devices es treffen würde:
list Namensteil.*
Zu finden in der commandref unter dem Stichwort "devspec"...
Gruß, Joachim
Zitat von: MadMax-FHEM am 18 November 2020, 22:04:50
Aber Achtung!!
Z.B.
attr Namensteil.* room NeuerRaum
Damit sind alle Devices NUR im neuen Raum!
Dann
attr -a Namensteil.* room ,NeuerRaum
Danke - d.h. die ", Variante" ergänzt überall den zusätzlichen Raum?
Kann ich auf die Variante im Nachgang Gruppieren also z.b. "EG => Küche"; "EG => Wohnen" ? Wie würde das gehen?
Bislang hab ich Aufgrund überschaubar vieler Komponenten nur nach EG und DG sowie Garten unterschieden.
Habt Ihr evtl. auch eine Idee woran das Problem hier lag (workaround gefunden aber wäre interessant es zu verstehen)
https://forum.fhem.de/index.php/topic,115919.0.html (https://forum.fhem.de/index.php/topic,115919.0.html)
Zitat von: Sammy51 am 20 November 2020, 21:46:42
Danke - d.h. die ", Variante" ergänzt überall den zusätzlichen Raum?
Ja. das "-a" ist auch entscheidend. Siehe CommandRef https://fhem.de/commandref_DE.html#attr
Zitat von: Sammy51 am 20 November 2020, 21:46:42
Kann ich auf die Variante im Nachgang Gruppieren also z.b. "EG => Küche"; "EG => Wohnen" ? Wie würde das gehen?
room Gruppierung geht mit "->". Siehe CommandRef https://fhem.de/commandref_DE.html#attributes