Ich habe mal eine Frage zu Fhem allgemein auf die ich in meinen Suchen bisher keine Antwort gefunden habe.
Gibt es in Fhem eine Möglichkeit alle Devices aufzulisten in denen ein bestimmter Begriff im Befehlsteil enthalten ist.
Also beispielsweise ein Notify und ein At, dass beides eine bestimmte Lampe schalten.
Hintergrund ist der, dass ich eine Lampe habe die ungeklärte Schaltaktionen aufweist und ich nicht ergründen kann wo der Auslöser herkommt.
Im Log finde ich auch keinerlei Hinweise die mir weiterhelfen.
Afaik: Jein...
Sowas in die Richtung (aber nicht beschränkt auf den Ausführungsteil) gibt es bei configdb-Nutzung - "configdb search %suchpattern%".
Hast du aber vermutlich nicht im Einsatz.
Für alle anderen müßte ein grep auf der Kommandozeile zielführend sein.
ABER: wenn du generische Eventhandler oä. hast, ist das nur bedingt zielführend, da da der Name des geschalteten Devices uU. gar nicht mehr im Code auftaucht...
("Generisch" meint ist sowas:
define n_Virtual_Temp_notify notify Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.* set myRealTempSensor=$NAME virtTemp $EVTPART1)
Danke für die Antwort.
Hast Recht ich nutze nicht die db sondern die cfg-Variante (soweit weiß ich schon Bescheid, :D)
Auch wenn ich bisher keine generischen Ausdrücke benutzt habe (zumindest nicht aktiv) ist das natürlich ein guter Einwand.
Bin noch ziemlich am Anfang, also eigentlich überschaubar. Aber leider habe ich noch keine klare Struktur, so dass ich mich dumm und dusselig suche wo ein bestimmtes Notify sich gerade befindet. Und ehrlich gesagt habe ich schon bei den wenigen "Befehlen" den Überblick verloren, was von welchem "Befehl" geschaltet wird.
Kannst du den Befehl grep näher erläutern? In der CommandRef finde ich dazu nichts und eine allgemeine Googlesuche hat mir auch nur einen Forumseintrag ausgegeben, wo es aber eigentlich um etwas anderes geht.
Wie sieht das denn bei euch anderen aus was Struktur und Aufteilung bzw. Überblick im Fhem angeht? Bin für Tipps immer offen.
Du kannst dir ja mal alle notify etc. auflisten lassen
list TYPE=notify
EDIT: geht nat. auch mit anderen "Typen" ;)
list TYPE=at
Und dann in jedes (zum "Debuggen") erst mal Logeinträge einbauen:
Log3(undef, 1, "Hier eine Meldung und das war der Event $EVENT")
Bzw. mache ich das beim (ersten) Anlegen immer.
Damit sehe ich, dass und wann das notify ausgelöst hat usw.
Wenn es dann läuft nehme ich das (temporär: Kommentar) raus...
Gruß, Joachim
Sorry wenn ich nachfrage, hab gerade verschiedene Inhalte dazu durchgelesen.
Wenn ich das richtig verstehe ist Log3 kein Attribut, sondern ein Befehl, muss also jeweils in den Commandteil des jeweiligen Notifys/Ats etc. eingetragen werden, richtig?
Wie ist der Zusammenhang von Log3 und dem Attribut Verbose? Hängen die zusammen oder verstehe ich das Richtig, das ich dem Log3 praktisch alles mitgeben kann unabhängig vom Verbose-Attribut und einfach nur bei Ausführung des Notify/At eine Zeile in die Log-Datei geschrieben wird?
Ja ist eine Funktion und muss in einen "Perl-Teil" (also geschweifte Klammer) in den Ausführungsteil...
Siehe u.a. https://forum.fhem.de/index.php/topic,14341.0.html
Gruß, Joachim
...stimmt, "list" kann uU. auch weiterhelfen, v.a., wenn man es mit FILTER kombiniert (dazu steht was in der cref).
Eine durchsuchbare Seite mit allen notify+at bekommst du z.B. auch mitlist TYPE=notify|at DEF
"grep" ist ein shell-Kommando für die Linux-Konsole, Hilfe bekommt man dazu über die betreffende manpage.
Meine Meinung dazu: configdb nutzen, ist für Einsteiger einfacher und enthält gleich eine Versionierung... Kann man aber auch anders sehen, hatten wir jüngst erst hier (https://forum.fhem.de/index.php/topic,114277.0.html) diskutiert.
Ansonsten hätte ich noch folgende Tipps:
- Möglichst generisch arbeiten, und die Abhängigkeiten bei den Geräten verwalten (in meinem Beispiel wird der zugehörige Temp-Sensor über ein userattr namens "myRealTempSensor" verwaltet; entsprechendes gilt für Fensterkontakte:attr Virtueller_Tuerkontakt_WZ userattr myRealFK myTimeout myRealTempsensor
attr Virtueller_Tuerkontakt_WZ myRealFK Balkontuer,Terrassentuer_WZ,Fenster_Wohnzimmer_SSO,Fenster_Wohnzimmer_SSW
Das notify ruft dann myUtils-Code auf, der die zugehörigen Readings der echten Devices der Reihe nach prüft und dann die "passende" Entscheidung trifft, ob der virtualisierte Fensterkontakt jetzt offen oder zu ist...
Ergebnis: Ein notify, das für eine bestimmte Funktionalität zuständig ist. Das kommt in den Raum "Steuerung->Heizung", zusammen mit dem anderen, das die virtuellen Temperatursensoren füllt, und in dem sich z.B. auch die ganzen "unnützen" Kanäle der CUL_HM-Thermostate befinden. Usw...
- Meinen myUtils-Code versuche ich zunehmend auch "anonym" zu gestalten. Der Ausführungsteil des notify sieht so aus: { myWinContactNotify ($NAME, $EVENT, 30)}
Darüber kann dann die Funktion alle erforderlichen Daten zusammenklauben, und ich muss mir - abgesehen von der sinnvollen Benennung der auslösenden Devices, damit es "gute" regexe für die notify werden (daran hapert es hier noch, deswegen zeige ich das auch nicht) - keinen Kopf mehr machen, ob der myUtils-Code angepasst werden muss, wenn ich einen Device-Namen ändere oder ein neues Device dazubringe. Einfach die Attribute entsprechend anpassen und "gut" ist. Ist erst mal deutlich mehr Aufwand, aber dann eben m.E. ziemlich übersichtlich.
- Hat man "gute" regex-Ausdrücke bei den notify-Auslösern, bekommt man die zugehörigen Devices dann auch in der Detailansicht angezeigt. Ob eine regex gut ist, kann man mit notifyRegexpCheck() prüfen. Beispiel:
{ notifyRegexpCheck('Kontakte.:closed|Kontakte.:open') }
Shit, ich nutze bisher bewusst keinen Perl-Code und habe alle Device mit Commandteil in der Fhem-Schreibweise definiert.
Wenn das nur als Perl-Code geht, müsste ich da erst mal alles umarbeiten, mal schauen.
ZitatZitatattr Virtueller_Tuerkontakt_WZ userattr myRealFK myTimeout myRealTempsensor
attr Virtueller_Tuerkontakt_WZ myRealFK Balkontuer,Terrassentuer_WZ,Fenster_Wohnzimmer_SSO,Fenster_Wohnzimmer_SSW
Das notify ruft dann myUtils-Code auf, der die zugehörigen Readings der echten Devices der Reihe nach prüft und dann die "passende" Entscheidung trifft, ob der virtualisierte Fensterkontakt jetzt offen oder zu ist...
Ist mir zu hoch, welchen Vorteil hat es die Werte doppelt vorliegen zu haben? Ob ein Fensterkontakt offen ist oder nicht gibt er doch im STATE zurück. Wahrscheinlich mein Denkfehler, aber aktuell verstehe ich es wie gesagt nicht wirklich.
Zitat von: Superposchi am 03 November 2020, 10:54:57
Shit, ich nutze bisher bewusst keinen Perl-Code und habe alle Device mit Commandteil in der Fhem-Schreibweise definiert.
Wenn das nur als Perl-Code geht, müsste ich da erst mal alles umarbeiten, mal schauen.
Tja, über kurz oder lang (wenn man wirklich viel machen will ;) ) wird es dich treffen ;)
Ich bin gleich den "anderen Weg" gegangen (gut auch u.U. unnötig aber ich habe fast überall irgendwelche "Prüfungen" etc. drin von daher... ;) ):
die Definition landet in der Config, die "Programmierung" bzw. auslösende Kommandos in einer Sub in myUtils.
(bis auf ganz wenige sehr einfache Dinge)
Finde ich übersichtlicher und ich kann (und tue das auch) sofort per Logeintrag sehen, ob (und wann/warum) das notify auslöst und welche Werte zur Verfügung stehen...
Aber klar: jeder wie er will, kann und es nötig ist... ;)
Gruß, Joachim
Na ja, mein "Temperatur-notify" war in "normaler Schreibweise":
define n_Virtual_Temp_notify notify Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.* set myRealTempSensor=$NAME virtTemp $EVTPART1Aber bei den Fensterkontakten ist es "etwas mehr", weil es in dem Beispielraum - wie in anderen auch - nur einen "virtuellen Kontakt" gibt, aber eben mehrere echte. Wird jetzt einer geöffnet oder geschlossen, ist das solange egal, wie noch ein anderer denselben Zustand hat, erst, wenn alle zu sind, darf der virtuelle "geschlossen" melden.
Dazu wird das "offen" noch verzögert...
Aber der Code dazu ist nicht sonderlich komplex, das sieht so aus (wenn ich den so sehe: könnte man optimieren, und evtl. gleich noch so anpassen, dass er auch für eine Mischung mit ZWave-Thermostaten passen würde...):
sub myWinContactNotify { #three parameters, last (timeout) is optional
my ($window, $event, $timeout) = @_;
$timeout = 90 unless $timeout;
my @virtuals = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=myRealFK=.*$window.*");
foreach my $virtual (@virtuals) {
my $myreals = AttrVal($virtual,"myRealFK","");
if ($event =~ /open|tilted/) {
my $checktime = gettimeofday()+$timeout;
InternalTimer($checktime,"myTimeoutWinContact",$virtual);
} else {
my @wcs = split(',',$myreals);
my $openwc = 0;
foreach my $wc (@wcs) {
$openwc++ if (ReadingsVal($wc,"state","closed") ne "closed");
}
CommandSet (undef,"$virtual geschlossen") unless ( $openwc );
}
}
return;
}
sub myTimeoutWinContact {
my $name = shift // return;
#my $name = $hash{NAME};
return unless (ReadingsVal("Heizperiode","state","off") eq "on");
my $myreals = AttrVal($name,"myRealFK","");
my @wcs = split(',',$myreals);
my $openwc = 0;
foreach my $wc (@wcs) {
$openwc++ if (ReadingsVal($wc,"state","closed") ne "closed");
}
CommandSet (undef,"$name offen") if ( $openwc );
return;
}
Zitat von: MadMax-FHEM am 03 November 2020, 11:07:11
Tja, über kurz oder lang (wenn man wirklich viel machen will ;) ) wird es dich treffen ;)
Na ja, es gibt manche, die behaupten was anderes, aber tendenziell kann ich das nur unterstreichen!
Ich habe auch lange einen Bogen um myUtils gemacht, aber ehrlich gesagt ist das viel übersichtlicher wie alles andere und man kann es (so man nicht die Device-Namen da reinverwurstelt) auch gut extern sichern und - wie hier - teilen...
Und vergiss direkt wieder, dass es STATE gibt (und die Funktion Value()). Das ist viel zu unspezifisch; ein stateFormat und nichts funktioniert mehr...
Zitat von: Beta-User am 03 November 2020, 11:15:17
Na ja, es gibt manche, die behaupten was anderes, aber tendenziell kann ich das nur unterstreichen!
Ja, DOIF ging ja lange OHNE aber auch da ist immer öfter: das geht nur in DOIF-Perl ;)
Zitat von: Beta-User am 03 November 2020, 11:15:17
Und vergiss direkt wieder, dass es STATE gibt (und die Funktion Value()). Das ist viel zu unspezifisch; ein stateFormat und nichts funktioniert mehr...
Da MUSS ich ZUSTIMMEN!!!
Es gibt eindeutigere Funktionen: ReadingsVal, ReadingsNum, AttrVal, InternalVal, ...
Da sieht man GENAU WAS man da abfrägt...
...und wenn man die "Ersatzwerte" entsprechend angibt auch SOFORT, dass beim Auslesen wohl was nicht gepasst hat ;)
Beispiel: ReadingsVal("DeviceName","ReadingName","Ersatzwert")
Gruß, Joachim
ZitatAber bei den Fensterkontakten ist es "etwas mehr", weil es in dem Beispielraum - wie in anderen auch - nur einen "virtuellen Kontakt" gibt, aber eben mehrere echte. Wird jetzt einer geöffnet oder geschlossen, ist das solange egal, wie noch ein anderer denselben Zustand hat, erst, wenn alle zu sind, darf der virtuelle "geschlossen" melden.
Das würde ich in meiner Unwissenheit einfach mit einem Structure-Device erledigen.
Du wirst sicher Gründe haben warum du deine Variante bevorzugst, ich muss sie erst noch verstehen um zu bewerten ob es für mich dadurch einfach wird oder nicht - und soweit bin ich glaube ich noch lange nicht.
Werde aber versuchen es im Hinterkopf zu bewahren.
Hmm, vermutlich hatte ich in dem Moment einfach nicht an structure gedacht, als ich das konzipiert habe...
Aber nachdem ich jetzt nochmal kurz darüber nachgedacht habe: ich müßte in jedem betroffenen Raum eine structure anlegen, und dann darüber - quasi "zu Fuß" - den passenden virtuellen Fensterkontakt ermitteln. Ginge auch, kommt mir aber im Moment umständlicher vor, vor allem, weil ich die structure nicht noch für irgendwas anderes brauche. Gäbe es die schon, wäre es eventuell via structure einfacher.
Ansonsten _glaube ich_, dass das eigentlich ein ziemlich gutes Beispiel ist, um sich einzudenken in das Arbeiten mit Arrays in Perl. Ist noch nicht allzu abstrakt.
Zitat von: Superposchi am 03 November 2020, 13:11:57
Das würde ich in meiner Unwissenheit einfach mit einem Structure-Device erledigen.
Ich auch.
Das nutze ich beispielsweise hier, um mit mehreren Bewegungsmeldern im kombinierten Wohn-/Ess-/Küchenbereich zu überprüfen, ob sich
irgendwo jemand in diesem Bereich aufhält.
ZitatIst noch nicht allzu abstrakt
Du bist offenbar schon zu lange in der Materie drin. Ich finde das sehr abstrakt. ;D
Hallo,
die Wissenden hier mögen mich korrigieren.
Wenn ich in die Detailansicht eines Devices (hier Lampe) gehe habe ich ganz unten
ZitatProbably associated with
, dort sind zumindest bei mir alle ats notifys und doifs zu dem Device aufgelistet, at sogar inklusive der nächsten Schaltzeit. Ein Klick auf das jeweilige at/notify/doif führt dann in dessen Detailansicht inklusive weiterer mit diesem Steuerbefehl verknüpften Devices.
Evtl kommt man so auch weiter.
Gruß Thomas
Zitat von: TL60 am 03 November 2020, 13:46:23
Evtl kommt man so auch weiter.
Das ist schon soweit richtig, setzt aber afaik (teilweise) voraus, dass man "sauber" gearbeitet hat:
Zitat von: Beta-User am 03 November 2020, 10:37:32
- Hat man "gute" regex-Ausdrücke bei den notify-Auslösern, bekommt man die zugehörigen Devices dann auch in der Detailansicht angezeigt. Ob eine regex gut ist, kann man mit notifyRegexpCheck() prüfen. Beispiel:
{ notifyRegexpCheck('Kontakte.:closed|Kontakte.:open') }
Will sagen: Solange man alles "hart" verdongelt, ist es richtig, sobald man "schlechte regex" im Auslöseteil oder "erst noch zu konkretisierende" Zieldevices im Ausführungsteil hat, wird es etwas schwieriger (der erste Teil betrifft afail auch alle andere Modul-Typen, die mit notifyRegexpChanged() (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#notifyRegexpChanged) arbeiten)...
Zitat von: Superposchi am 03 November 2020, 13:32:30
Du bist offenbar schon zu lange in der Materie drin. Ich finde das sehr abstrakt. ;D
Na ja, abstrakt schon, aber eben mAn. noch nicht "allzu" ;) . Am Anfang fand ich sowas auch ziemlich schwierig, aber man gewöhnt sich in der Tat irgendwann dran...
Zitat von: betateilchen am 03 November 2020, 13:29:35
Ich auch.
Das nutze ich beispielsweise hier, um mit mehreren Bewegungsmeldern im kombinierten Wohn-/Ess-/Küchenbereich zu überprüfen, ob sich irgendwo jemand in diesem Bereich aufhält.
Na ja, wie gesagt: In dem Moment, in dem ich das entworfen hatte, hatte ich nicht dran gedacht und war mir auch nicht so richtig sicher, wie viele ggf. überschneidende Bereiche am Ende eigentlich gebraucht werden - und ein separates "Anzeige-Device" braucht es eigentlich hier auch nicht. von daher: Viele Wege ... (sonst mache ich eigentlich auch gerne Werbung für structure, das ist wirklich oft ein praktisches Hilfsmittel).