Hallo Forum,
ich bin neu hier in der fhem Welt und komme aus der XS1 Welt. Ich hoffe ich bin hier richtig mit meinen Fragen.
Nun versuche ich meine Skripte in eure Welt zu übertagen, an dieser Stelle bin ich mit meiner Weissheit allerdings schon zu ende.
Problem:
Ich möchte, wenn ich das Haus verlasse eine Taste "gehen_melden" drücken
woraufhin eine Routine ablaufen soll ( Türe schliessen, Staus abwesend setzen......)
Türe schliessen soll nach einer Minute stattfinden
daher habe ich in fhem.cfg
define gehen_melden FS20 XXXXX xXX
define HaustuereSchliessen XXXX XX
define NotifyGehen notify gehen_melden:.* {SktGehenMelden("gehen_melden","HaustuereSchliessen");;}
in 99_MyUtils.cfg
sub SktGehenMelden($$){
my ($Ws,$Haustuer) = @_;
#Log 1,"SktGehenMelden*";
if(Value($Ws) ne "off") {
{ fhem( "define test at +00:01:00 set HaustuereSchliessen on-for-timer 2") };
#...........
}
}
das geht nun mehrfach hintereinader gut, aber irgendwann kommt:
2014.03.12 10:10:56 3: define test at +00:01:00 set HaustuereSchliessen on-for-timer 2 : test already defined, delete it first
was mache ich falsch?
Eventuell wird innerhalb der Minute ein zweites mal getriggert? Das at verschwindet ja erst nach der Minute, welche du festgelegt hast, wieder. Ein neues define führt dann zu dem Fehler.
Hallo,
der aber kein Fehler ist sondern nur ein Hinweis das etwas definiert werden soll was bereits existiert.
Nicht schön aber auch nicht schlimm.
Diese Meldung lässt sich umgehen indem man das at nur anlegen lässt wenn es nicht bereits existiert.
fhem("define test at +00:01:00 set HaustuereSchliessen on-for-timer 2") if(Value("test") eq "")
Wie gesagt - kann man machen muss man aber nicht.
Grüsse
Ich finde es ja ratsamer Notifies nicht zu löschen und zu kreieren, sondern mit disabled=0 oder 1 einfach zu aktivieren oder zu deaktivieren wenn man sie braucht.
es geht aber letztendlich nicht um ein notify, sondern um ein at mit einer relativen Zeitangabe. Da nützt Dir das disable nicht besonders viel ;)
ein solches at verschwindet aber doch wenn es die schaltzeit erreicht hat, oder?
Also muss es ja so sein das der trigger mehrfach kommt...
danke Ihr seid klasse :)
-closed-
Hallo,
@der-Lolo
Das at verschwindet wenn es ausgeführt wurde resp. der Zeitpunkt der Ausführung erreicht ist - ja.
Ich weiß jetzt nicht wie das in FHEM gehandelt wird wenn FHEM zum Zeitpunkt der Ausführung nicht läuft und erst danach gestartet wird.
Ich vermute mal das das at dann einfach bis zum nächsten Zeitpunkt erhalten bleibt.
Die Meldung kann in diesem Fall nur kommen wenn innerhalb der einen Minute das notify mit dem innenliegenden at nochmal triggert und FHEM
dann natürlich versucht das bereits bestehende at nochmal anzulegen.
Richtig.
@Sauron
Bitte deinen ersten Beitrag bearbeiten und dem Titel ein gelöst vorne dran stellen.
Danke.
Grüße
wie hast du das jetzt gelöst?
Mit Puschels Code Schnipsel?
Ein event-on-change hätte auch geholfen - denke ich...
Hallo,
event-on-change funktioniert mWn nur bei einem Device aber nicht bei einem notify oder at - wie auch?
Es ändert sich ja kein Event - es wird nur etwas definiert was bereits existiert ;)
Grüsse
natürlich meinte ich ein event-on-change für den Taster den er drückt wenn er geht, oder gab es einen anderen grund für das 2-fache anlegen des at jobs?
falls es einen anderen grund gab - erklär es nochmal bitte, weil dann habe zumindest ich es nicht richtig verstanden...
Danke.
Hallo,
ich hab mir grad den ersten Beitrag nochmal angeschaut.
Stimmt - du hast recht.
Fehler von mir.
Ich weiss nicht ob event-on-change-reading bei einem FS20-Taster funktioniert.
Versuch macht kluch ;D
Das müsste der TE mal ausprobieren ob es dann besser klappt bzw. ohne Abfrage ob das at bereit definiert ist.
Grüsse
Zitat von: der-Lolo am 12 März 2014, 19:05:02
wie hast du das jetzt gelöst?
Mit Puschels Code Schnipsel?
Ein event-on-change hätte auch geholfen - denke ich...
ich habe überall den Code Schnipsel if(Value("Name des define ") eq "") angehängt.
Zitat von: Puschel74 am 13 März 2014, 08:26:42
Hallo,
......
Ich weiss nicht ob event-on-change-reading bei einem FS20-Taster funktioniert.
Versuch macht kluch ;D
Das müsste der TE mal ausprobieren ob es dann besser klappt bzw. ohne Abfrage ob das at bereit definiert ist.
Grüsse
Ich habe den Betrag wie von dir gewünscht auf gelöst gesetzt, da meine Frage super beantwortet ist. Falls sich "TE "auf mich bezieht und ich noch was testen soll, dann mach ich das "gelöst"gerne wieder weg bzw. ein neues Thema auf, da müsstest du mir aber genau beschreiben was gewünscht ist.
Guten Morgen Sauron,
ich fragte mich einfach noch warum es überhaupt zu dem doppeltem anlegen deiner at + definition kam, hier gäbe es zwei möglichkeiten - die erste wäre das der Schalter dir sein event "on" mehrfach liefert - das könntest du unterdrücken wenn du das attribut event-on-change für den schalter setzt. Dann wird wie der name schon sagt nur ein neues event generiert wenn es sich zum vorherigen event geändert hat. Der schalter also seinen state ändert.
Dieses attribut macht oft sinn in FHEM da es einige Sensoren z.b. gibt die innerhalb einer gewissen zeit senden, auch ohne wertänderung. Ein temperatur sensor liefert z.b. alle drei minuten seine temperatur, auch wenn sie sich nicht geändert hat. Wenn du nun auf die temperatur triggerst kommt der trigger eben alle x minuten neu. wenn das attribut aktiv ist kommt das event nur wenn sich der trmperaturwert wirklich geändert hat.
Die zweite möglichkeit wäre das du den Taster innerhalb der definierten zeit mehrfach betätigt hast... dann wärst du die fehlerquelle ;-)
Wenn es doch noch einen anderen grund geben könnte hätte ich das eben gerne für mein verständnis gewusst.
Mit dem Schnipsel vom puschel schipperst du um das problem herum löst es aber meiner meinung nach nicht. Mal davon abgesehen das es ja eh "nur" um einen schönheitsfehler geht.
Zitat von: der-Lolo am 13 März 2014, 09:00:51
Guten Morgen Sauron,
ich fragte mich einfach noch warum es überhaupt zu dem doppeltem anlegen deiner at + definition kam, hier gäbe es zwei möglichkeiten - die erste wäre das der Schalter dir sein event "on" mehrfach liefert - das könntest du unterdrücken wenn du das attribut event-on-change für den schalter setzt. Dann wird wie der name schon sagt nur ein neues event generiert wenn es sich zum vorherigen event geändert hat. Der schalter also seinen state ändert.
......
Die zweite möglichkeit wäre das du den Taster innerhalb der definierten zeit mehrfach betätigt hast... dann wärst du die fehlerquelle ;-).
In dem Fall war es wohl zweitens. Seit ich es auf den Ubuntu umgezogen habe hatte ich das Problem nur noch sehr selten. Am Anfang hatte ich beobachtet als ich auf der Fritzbox war, dass der Druck auf einen Button in der Oberfläche (nicht der physikalische Schalter) immer zwei events auslöste, da hatte ich die Fehlermeldung dann ständig. Dass der define des @ nach der Zeit X wieder verschwindet war der Schlüssel der mir fehlte (hatte mich gewundert, warum es manchmal ging und manchmal nicht). Der Doppelaufruf war interessanter weise auch, wenn ich in einer Routine den set Programmtechnisch { fhem ("set zurueck_melden off") }; setzte, die abhängige Methode wurde doppelt aufgerufen, wollte mich da noch darum kümmern ist aber vermutlich seit es auf Ubuntu läuft weg, zumindest nicht mehr reproduzierbar.
Zitat von: der-Lolo am 13 März 2014, 09:00:51
Dieses attribut macht oft sinn in FHEM da es einige Sensoren z.b. gibt die innerhalb einer gewissen zeit senden, auch ohne wertänderung. Ein temperatur sensor liefert z.b. alle drei minuten seine temperatur, auch wenn sie sich nicht geändert hat. Wenn du nun auf die temperatur triggerst kommt der trigger eben alle x minuten neu. wenn das attribut aktiv ist kommt das event nur wenn sich der trmperaturwert wirklich geändert hat.
Das ist eine Klasse info, das werde ich bei allen Tempertur und Fenstersensoren nachtragen, dann ist auch das ständige Klicken an der Dustabzugshaube gelöst.
Zitat von: der-Lolo am 13 März 2014, 09:00:51
Mit dem Schnipsel vom puschel schipperst du um das problem herum löst es aber meiner meinung nach nicht. Mal davon abgesehen das es ja eh "nur" um einen schönheitsfehler geht.
Das es nur Schönheit ist, wusste ich bis zum Posting noch nicht, der log bleibt so "sauber".
ZitatDas ist eine Klasse info, das werde ich bei allen Tempertur und Fenstersensoren nachtragen, dann ist auch das ständige Klicken an der Dustabzugshaube gelöst.
Das Attribut event-on-change ist für einige geschwätzige Dinge eine nette Sache (z.B. YAMAHA_AVR, FBDECT) aber ich habe es für die Temperatursensoren und Thermostate wieder entfernt. Im Plot sieht es nämlich blöd aus, wenn zwischen zwei geänderten Werten eine direkte Verbindungslinie gemalt wird. Oder gibt es dafür eine andere Abhilfe?
Gruß Deudi
Abhilfe ist einfach - kein event on change benutzen, und stattdessen auf der ausführenden seite einen FILTER nutzen... sodass die schaltung nur anspricht wenn sie auch wirklich einen zustand ändern soll, das würde wahrscheinlich auch beim dunstabzugklicken helfen...
grundsätzlich muss man sich halt entscheiden, brauch man die werte die ein Sensor liefert auch in plots brauch oder eben nicht...
Es wird halt eine linie zwischen den letzten zwei werten erstellt, die dann mehr oder weniger schräg ausschaut...
Manchmal hilft event on change auch bei performance problemen...