Hallo zusammen
Der Code läuft nach dem Update von FHEM nicht mehr.
Eine Frage noch vorweg,
Dem Codeschnipsel sollte es doch egal sein ob Logs vorhanden sind? Oder wo die Sind?
Ich finde den Fehler nicht.
Für micht sieht das jetzt erstmal so aus:
Der Prüfdummy
JL_Esszimmer_pruef ist off
Es kommt ein Event von
sens_EzFenster open
Das notify setzt JL_Esszimmer_pruef auf on <- das tut er wirklich
Das scheint aber wiederrum kein Event mehr zu generieren.
So das define JL_Esszimmer_pruef2 notify JL_Esszimmer_pruef:on nicht erfüllt wird.
Den Logeintrag macht er auch nicht.
Die Frage ist warum?
Hier der CODE
define JL_Esszimmer_pruef dummy
attr JL_Esszimmer_pruef eventMap on off
define JL_Esszimmer1 at *{sunset("HORIZON=-5",300,"17:00","23:00")} set JL_Esszimmer_pruef on
define JL_Esszimmer2 notify sens_EzFenster:(open|closed) set JL_Esszimmer_pruef on
define JL_Esszimmer_pruef2 notify JL_Esszimmer_pruef:on {\
my $Zustand =Value("sens_EzFenster");;\
my $Zustandhell =Value("Hell");;\
my $ZustandRollo =Value("JL_Esszimmer");;\
Log 3, "Stunde: $hour, noch Hell draussen: $Zustandhell, EZ_Fenstersensor: $Zustand, Rollo: $ZustandRollo";;\
if(($hour >= 17) && ($hour <= 23) && (Value("sens_EzFenster") eq "closed") && (Value("Hell") eq "Nein")) {\
if (defined($defs{JL_Esszimmer_verzoegert})){fhem('delete JL_Esszimmer_verzoegert')};;\
fhem ("define JL_Esszimmer_verzoegert at +00:01:00 set JL_Esszimmer off");;\
Log 3, "Rollo wird zugefahren 1.Variante";;\
}\
if ((($hour > 22) || ($hour < 7)) && (Value("sens_EzFenster") eq "closed")) {\
if (defined($defs{JL_Esszimmer_verzoegert})){fhem('delete JL_Esszimmer_verzoegert')};;\
fhem ("define JL_Esszimmer_verzoegert at +00:01:00 set JL_Esszimmer off");;\
Log 3, "Rollo wird zugefahren 2.Variante";;\
}\
if ((Value("Anwesend") eq "Ja") && (Value("sens_EzFenster") eq "open") && ReadingsVal("JL_Esszimmer", "state", "") ne "on"){\
fhem ("set JL_Esszimmer on");;\
Log 3, "Rollo wird hochgefahren wenn Anwesend und Fenster offen" .Value("JL_Esszimmer");;\
}\
fhem ("set JL_Esszimmer_pruef off");;\
}
Ich schließe mich dem Fragesteller mal an, ein ähnliches Problem habe ich seit einem Update (vermutlich Ende Juni) auch. Das auf "bla" gesetzte notify funktioniert korrekt, wenn ich direkt ein "set bla on" in der Kommandozeile auführe, aber es funktioniert nicht, wenn ich das gleiche mit einem fhem("set bla on") aus einem anderen notify ausführe. Der Schaltbefehl auf "bla" wird zwar ausgeführt, aber das notify greift in diesem Fall nicht.
Hallo,
Ich hab einen HM-SCI-3-FM Sensor. Wenn ich mit dem einen Schaltvorgang auslöse, wird zwar der Dummy auf on geschaltet, aber der zugehörige notify wird nicht ausgeführt. Folgendes Beispiel hab ich gerade nochmal mit nem Kumpel getestet:
Code:
define JL_Esszimmer_pruef dummy
attr JL_Esszimmer_pruef eventMap on off
define sens_EzFenster CUL_HM 1E4E5902
define JL_Esszimmer2 notify sens_EzFenster:(open|closed) set JL_Esszimmer_pruef on
define JL_Esszimmer_pruef2 notify JL_Esszimmer_pruef:on set JL_Esszimmer_pruef off
Wenn der Sensor sens_EzFenster geöffnet wird, besitzt der Dummy JL_Esszimmer_pruef den Status on, obwohl er sich ja eigentlich direkt wieder auf off setzten müsste. Wenn ich den Dummy von Hand über set Befehl auf on setze, ändert er ordnungsgemäß seinen Status auf off. Das Ganze tritt erst seit einem Update auf.
Ok, nachgestellt wurde es jetzt schon ähnlich von betateilchen.
VG
Andre
Hallo,
ok, der Beitragstitel ist auch etwas "vage" gewählt aber ...
Ich hab jetzt spaßhalber mal einen Dummy und ein notify definiert:
define Test dummy
attr Test webCmd An:Aus
define Versuch notify Test:An {
Log (3,"Notify An");
}
und das attr global verbose steht auf 3.
Da geh ich mal davon aus das wenn ich den Test auf An schalte im LogFile ein Logeintrag erscheinen sollte.
Ist aber nicht - kein Logeintrag.
Was mich aber etwas verwundert ist das ich noch ein notify mit regexp OG_Badezimmer:humidity am laufen habe und das funktioniert einwandfrei.
In diesem notify prüfe ich die Luftfeuchte im Bad und schalte einen Lüfter ein - das klappt wunderbar jedesmal nach (bzw. während) dem duschen.
Grüße
Hallo Puschel74,
der Beitragsname wurde so gewählt bevor ich so schlau war wie jetzt. ;) Ich hatte keinen Schimmer, warum es nicht mehr geht. Deswegen so unpräzise. Geht nicht mehr ;)
Anfänger halt.
Ich hatte später noch ein Thema gepostet wo das Problem explizit angesprochen wurde. Das war dann nicht so erwünscht und sollte hier weiter diskutiert werden.
Eine Lösung hab ich aber dennoch nicht.
Wenn ein Event direkt von einem Gerät gefeuert wird. Dann funktioniert das auch bei einem notify. Nur ein Event das einen Status vom Dummy ändert und dieser dann ein Event generiert, worauf ein notify hört, klappt nicht.
Die Version von fhem.de funktioniert was das angeht super. Nur nach dem Update klappt das nicht mehr.
Gruß Andre
Die Aenderung eines Geraetes innerhalb der notify, was durch Aenderung des gleichen Geraetes ausgeloest wird (== JL_Esszimmer_pruef2) wird in fhem.pl nicht sauber geloest.
Ich habe noch keine Idee, wie man das sauber loest, ich empfehle sowas nicht zu verwenden.
Ich habe trotzdem zwei kleine (aber potentiell weitreichende) Aenderungen in fhem.pl eingefuehrt, dadurch bekomme ich jetzt nach einem "trigger sens_EzFenster open" statt 2-mal off ein on und ein off Event gemeldet, was in diesem Fall korrekt ist. Ob das euer Problem auch loest, ist mir unklar.
Hallo Rudolf,
bei mir ist das so - um mein Problem genau zu beschreiben::
Ein Fernbedienungsbutton wird gedrückt -> das erste notify (wird durch den Fernbedienungsbutton getriggert) legt los und schaltet eine FS20 Steckdose an.
Ein zweites notify wird durch Steckdose:an getriggert und soll dann weitere Schritte ausführen.
Wenn ich "set Steckdose an" direkt in der Kommandzeile ausführe, funktioniert das auch, aber nicht mehr aus dem ersten notify heraus. Da wird lediglich die Steckdose angeschaltet und das wars.
Das alles hat bis vor ca. zwei Wochen perfekt funktioniert - danach aber urplötzlich nicht mehr.
Viele Grüße
Udo
Tritt das Problem mit der geaenderten fhem.pl auch auf?
Bitte ein Problem immer mit einem fhem.cfg Ausschnitt (wie bei AK-868) beschreiben, sonst bleibt mir zu viel Interpreteantionsfreiraum.
Das es "urploetzlich" nicht mehr funktioniert, kann ich mir nicht vorstellen, bestimmt war ein Update dazwischen.
Ja, ich habe unlaengst Probleme behoben, genau in diesen Gegend.
Ich zieh gerade mal ein komplettes Update drüber.
Zuvor Version von fhem.de FB7390 Image.
Bin gespannt.
Das hat es jetzt gefixt. Problem gelöst funktioniert wieder!!
Vielen Dank!!!
Hallo Rudolf,
Zitat von: rudolfkoenig schrieb am Do, 11 Juli 2013 08:08Das es "urploetzlich" nicht mehr funktioniert, kann ich mir nicht vorstellen, bestimmt war ein Update dazwischen.
Naja, mit "urplötzlich" meinte ich auch nicht aus heiterem Himmel, ich gehe auch davon aus, dass es irgendwann nach einem Update passiert ist und ich es aber nicht gleich bemerkt hatte. Neue Version kann ich erst heute abend testen, danke für Deine Unterstützung.
Viele Grüße
Udo
Scheint nach dem Update im Moment auch hier (wieder) zu funktionieren.
Viele Grüße
Udo
*verdächtig*
Seit gestern abend funktionieren meine automatisch über Google Kalender gesteuerten Schaltbefehle (set $actor on) nicht mehr - kann das irgendwie mit dem gestrigen Update von fhem.pl zusammenhängen?
SwitchActorOff return value: Unknown command {, try help
Unknown command 4qjc1sgh9nktiecinkldq68jo4googlecom, try help
Unknown command mv2lkq4g2o5gh038uglg362ba8googlecom";;, try help
Internals:
DEF Kalender_Schalter:modeEnded.* { my $reading="%EVTPART0";; my $uid= "%EVTPART1";; my $actor= fhem("get Kalender_Schalter summary $uid");; if(defined $actor) { fhem("set $actor off") } }
NAME SwitchActorOff
NR 41
NTFY_ORDER 50-SwitchActorOff
REGEXP Kalender_Schalter:modeEnded.*
STATE active
TYPE notify
Das hat bis gestern perfekt funktioniert und ich habe an diesem notify nichts geändert.
Seit gestern ca. 24 Uhr klappt das wie zuvor beschrieben nicht.
Was interessant ist.
Wenn ich jetzt den Sensor trigger X mal. Dann bleibt prüf JL_Esszimmer_pruef on obwohl er auf off gehen müsste.
trigger sens_EzFenster open
trigger sens_EzFenster open
Das komische ist alle aufgelaufenen notifys arbeitet er ab und zwar wenn ich im Webinterface JL_Esszimmer_pruef auf on klicke.
Dann werden alle zuvor generierten Events verarbeitet mit einem mal. Auch ohne meinen kleinen Logeintrag. Der auch irgendwie falsch ist.
Aber zum Ziel führt und aufzeigt das alles angestaute verarbeitet wird.
define JL_Esszimmer_pruef dummy
attr JL_Esszimmer_pruef eventMap on off
define sens_EzFenster CUL_HM 1E4E5902
define JL_Esszimmer2 notify sens_EzFenster:(open|closed) set JL_Esszimmer_pruef on
define JL_Esszimmer_pruef2 notify JL_Esszimmer_pruef:on set JL_Esszimmer_pruef off ;; {\fhem Log 3, "wieder aus"}
Logs:
2013.07.12 13:57:19 3: wieder aus
2013.07.12 13:57:19 3: JL_Esszimmer_pruef2 return value: SCALAR(0x125a720)
2013.07.12 13:57:19 3: wieder aus
2013.07.12 13:57:19 3: JL_Esszimmer_pruef2 return value: SCALAR(0xe737c0)
2013.07.12 13:57:19 3: wieder aus
2013.07.12 13:57:19 3: JL_Esszimmer_pruef2 return value: SCALAR(0xa84300)
2013.07.12 13:57:19 3: wieder aus
2013.07.12 13:57:19 3: JL_Esszimmer_pruef2 return value: SCALAR(0xedddb0)
2013.07.12 13:57:19 3: wieder aus
2013.07.12 13:57:19 3: JL_Esszimmer_pruef2 return value: SCALAR(0xd21b30)
2013.07.12 13:57:19 3: wieder aus
2013.07.12 13:57:19 3: JL_Esszimmer_pruef2 return value: SCALAR(0xb0ade0)
2013.07.12 13:57:19 3: wieder aus
2013.07.12 13:57:19 3: JL_Esszimmer_pruef2 return value: SCALAR(0x12f6648)
1. Bei mir bleibt es off, wenn ich auf on clicke oder im terminal auf on setze
2. Ich wiederhole mich ungern, aber zum letzten mal :) "ich empfehle sowas nicht zu verwenden"
3. Kinder, bitte folgendes
set JL_Esszimmer_pruef off ;; {\fhem Log 3, "wieder aus"}nicht nachmachen, es ist aus mind. 3 Gruenden kaputt:
- FHEM Befehle und Perl Code zu mischen wird nicht unterstuetzt, hier funktioniert es zufaellig
- falls der Perl code nicht undefined zurueckliefert, dann wird es im log ausgegeben
- \fhem ist Unsinn, wundert mich dass es tut.
Ich entschuldige mich für mein Beispiel, ich wusste es nicht besser. Aus Fehlern wird man "Kluk". Ok das mit dem \ hätte ich sehen müssen.
Ich habe verschiedene Kriterien, die Dummy1 einschalten.
Ist es nicht resourcenschonend wenn ich ein Notify auf Dummy1 mache anstatt jedesmal die ganzen zu erfüllenden Kriterien dort wieder abzufragen um Aktion X auszuführen?
Anders herum, wie soll es denn richtig sein?
Kriterium_1 && Kriterium_2 ergeben K12
K12 muss Wert X && Kriterium_3 ensprechen um etwas auszuführen.
K12 muss Wert X && Kriterium_4 ensprechen um etwas auszuführen.
Muss ich dann jedes mal
Kriterium_1 && Kriterium_2 && Kriterum_3 abfragem um etwas auszuführen.
?
Entschuldigung ist nicht notwendig, ich wollte nur nicht, dass hier "dokumentierte" Zeilen von weiteren Benutzern verwendet und weiterverbreitet werden.
> Muss ich dann jedes mal Kriterium_1 && Kriterium_2 && Kriterum_3 abfragem um etwas auszuführen.
Das Problem ist nicht das merken vo K12 in einem dummy , sondern das aendern dieser dummys in einem notify, was von diesem dummy selbst (direkt oder indirekt) ausgeloest wird, also diese Zeile:
define JL_Esszimmer_pruef2 notify JL_Esszimmer_pruef:on set JL_Esszimmer_pruef off
Das funktioniert z.Zt. nicht in allen Kombinationen so, wie man es erwartet.
Solche notifies sollte man vermeiden, bzw. direkt in die anderen einbauen (notfalls ueber Funktion):
define JL_Esszimmer2 notify sens_EzFenster:(open|closed) set JL_Esszimmer_pruef on;;set JL_Esszimmer_pruef off
Danke erstmal.
Ich hab jetzt alle Dummys, die einen Dummy schalten worauf ein Notify läuft, geändert.
Ich hab mir helfen lassen und wir haben das so gelöst, ich hoffe das ist jetzt best practice:
FHEM CFG
define JL_Esszimmer1 at *{sunset("HORIZON=-5",300,"17:00","23:00")} {EzJLschalten()}
define JL_Esszimmer2 notify sens_EzFenster:(open|closed) {EzJLschalten()}
define JL_Wohnzimmer1 at *{sunset("HORIZON=-5",300,"17:00","23:00")} {WzJLschalten()}
define JL_Wohnzimmer2 notify sens_WzFenster:(open|closed) {WzJLschalten()}
99_myUtils.pm
sub
WzJLschalten()
{
my ($sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst) = localtime;
my $Zustand = Value("sens_WzFenster");
my $Zustandhell = Value("Hell");
Log 3, "Stunde: $hour, noch Hell draussen: $Zustandhell, WZ_Fenstersensor: $Zustand";
if(($hour >= 17) && ($hour <= 23) && (Value("sens_WzFenster") eq "closed") && (Value("Hell") eq "Nein")) {
if (defined($defs{JL_Wohnzimmer_verzoegert})){fhem('delete JL_Wohnzimmer_verzoegert')};
fhem ("define JL_Wohnzimmer_verzoegert at +00:01:00 set JL_Wohnzimmer off");
Log 3, "Wohnzimmer Rollo wird zugefahren 1.Variante, $hour";
}
if ((($hour > 22) || ($hour < 7)) && (Value("sens_WzFenster") eq "closed")) {
if (defined($defs{JL_Wohnzimmer_verzoegert})){fhem('delete JL_Wohnzimmer_verzoegert')};
fhem ("define JL_Wohnzimmer_verzoegert at +00:01:00 set JL_Wohnzimmer off");
Log 3, "Wohnzimmer Rollo wird zugefahren 2.Variante, $hour";
}
if ((Value("Anwesend") eq "Ja") && (Value("sens_WzFenster") eq "open") && ReadingsVal("JL_Wohnzimmer", "state", "") ne "on"){
fhem ("set JL_Wohnzimmer on");
Log 3, "Wohnzimmer Rollo wird hochgefahren wenn Anwesend und Fenster offen" .Value("JL_Wohnzimmer");
}
}
sub
EzJLschalten()
{
my ($sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst) = localtime;
my $Zustand =Value("sens_EzFenster");
my $Zustandhell =Value("Hell");
my $ZustandRollo =Value("JL_Esszimmer");
Log 3, "Stunde: $hour, noch Hell draussen: $Zustandhell, EZ_Fenstersensor: $Zustand, Rollo: $ZustandRollo";
if(($hour >= 17) && ($hour <= 23) && (Value("sens_EzFenster") eq "closed") && (Value("Hell") eq "Nein")) {
if (defined($defs{JL_Esszimmer_verzoegert})){fhem('delete JL_Esszimmer_verzoegert')};
fhem ("define JL_Esszimmer_verzoegert at +00:01:00 set JL_Esszimmer off");
Log 3, "Rollo wird zugefahren 1.Variante";
}
if ((($hour > 22) || ($hour < 7)) && (Value("sens_EzFenster") eq "closed")) {
if (defined($defs{JL_Esszimmer_verzoegert})){fhem('delete JL_Esszimmer_verzoegert')};
fhem ("define JL_Esszimmer_verzoegert at +00:01:00 set JL_Esszimmer off");
Log 3, "Rollo wird zugefahren 2.Variante";
}
if ((Value("Anwesend") eq "Ja") && (Value("sens_EzFenster") eq "open") && ReadingsVal("JL_Esszimmer", "state", "") ne "on"){
fhem ("set JL_Esszimmer on");
Log 3, "Rollo wird hochgefahren wenn Anwesend und Fenster offen" .Value("JL_Esszimmer");
}
}
Das funktioniert seit dem heutigen Update schon wieder nicht mehr...
Habe die fhem.pl von vorgestern wieder eingespielt und alles läuft wieder wie es soll.
Was genau ist das?
Und hast du auch die anderen Komponenten (CUL/FHZ/RFR) auf dem aktuellen Version gebracht?
"das" ist das triggern eines notify aus einer Aktion, die durch ein anderes notify ausgeführt wird.
DAS funktioniert:
"set lampe on" in der Kommandozeile bewirkt folgendes:
1.) lampe wird angeschaltet
2.) das Anschalten der Lampe triggert ein notify, das auf dieses Anschalten
DAS funktioniert nicht:
"set lampe on" als Befehl aus einem anderen notify (Fernbedienungsbutton) bewirkt folgendes:
1.) lampe wird angeschaltet
Das zugehörige notify wird NICHT ausgeführt. Das ist genau der Problemfall, um den es hier im Thread schon vor einigen Tagen ging und der dann durch ein Update behoben wurde.
Und JA - ich habe alles aktualisiert.
Hallo zusammen,
ich habe leider auch das Prbl. seit dem Update was ich am 14.07 vorgenommen habe.
Ich dachte schon ich hätte irgend etwas unbewusst geändert. Passiert ja schon mal... Da ich gerade an meinem Markisen Aktor herumdoctor.
Nun habe ich heute ein Restore nach 3075 2013-04-15 gemacht und die Prbl. sind verschwunden. Heutiges Update vorgenommen, Prbl. wieder da.
Äußert sich bei mir wie folgt: Der $value{Markise} ne "open" reagiert nicht , so dass in 1s Intervall der Aktor wiederholt schaltet, sobald er die Daten vom Wetterdienst bekommt, aber das nur am Rande.
Rudold meinte ja man könnte das Prbl. eingrenzen, wenn man in etwa weiß wann das Prbl. erstmalig aufgetreten ist. Also wie gesagt mit
(version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3075 2013-04-15 15:19:48Z rudolfkoenig $, pid 26664) hatte ich das Prbl. nicht.
Anbei meine Markisen.cfg und die Fhem Log´s
Bitte keine Kritik über den Zeitintervall des Yahoo Moduls und der Windstärke, das habe ich nur zu Testzwecken jetzt so gewählt.
Gruss Micha
Bei mir hat definitiv alles funktioniert bis zum Update, das ich durchgeführt habe, nachdem ich heute Abend von Arbeit nach Hause kam. Ich konnte nämlich mit meiner Fernbedienung am Schlüsselbund noch vor dem Betreten problemlos die Einbruchmeldeanlage deaktiveren - was jetzt auch nicht mehr funktioniert.
Die Updates der vergangenen Tage wurden ebenfalls alle täglich durchgeführt.
@Meesus
- ich sehe keinen Unterschied zw. den beiden logs, bis auf die CUL_HM Meldungen: wenn das stoert bitte Martin in der CULHM Gruppe fragen, wieso diese jetzt anders sind
- ich verstehe nicht, was Du mit "Prbl. wieder da." meinst.
- bei mir wird "set Markise 100" aufgerufen. Ich musste natuerlich manche Werte simulieren (Markise zu, Wind 3), sonst passiert ja nix.
- Weather produziert 52 unterschiedliche Events auf einmal, die Verwendung von einem so ungenauen notify regexp ist (Achtung: Euphemismus) ungeschickt, damit wird die Markise 52-mal zugemacht.
- $value{} sollte man nicht mehr verwenden, Value() ist richtig.
@betateilchen
- deine Beschreibung ist mir zu schwammig, bzw. das was ich daraufhin angelegt habe tut bei mir
- die von AK-868 in diesem Thread gepostete Zeilen funktionieren.
- Vorgestern habe ich die DuplikatErkennung mit einem patch von justme1968 modifiziert. Ich habe es aber getestet, und laeuft bei mir.
- Wenn es bei Dir zu Problemen kommt, muss ich wissen, genau welche Events ueber welche IO-Geraete reinkommen, d.h. ich brauche mind. ein Log auf verbose 5 und genaue Definition aller Geraete. Oder wie ich es schon 100+ mal gepredigt habe, eine minimale Konfiguration, mit dem ich das nachspielen kann. Selbst bei einem *bezahlten* Support ist sowas eine Bedingung.
@all
- diese Diskussion wird wegen nichtsagendem Subject zugemacht, sonst kommt noch jeder auf die Idee seine Geschichte hier zu posten.