Frage zu Befehlen

[Superposchi]

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.

[Beta-User]

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

Code Auswählen Erweitern

Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.* set myRealTempSensor=$NAME virtTemp $EVTPART1)

[Superposchi]

Danke für die Antwort.
Hast Recht ich nutze nicht die db sondern die cfg-Variante (soweit weiß ich schon Bescheid,  )

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.

[MadMax-FHEM]

Du kannst dir ja mal alle notify etc. auflisten lassen

Code Auswählen Erweitern


list TYPE=notify


EDIT: geht nat. auch mit anderen "Typen"

Code Auswählen Erweitern


list TYPE=at



Und dann in jedes (zum "Debuggen") erst mal Logeinträge einbauen:

Code Auswählen Erweitern


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

[Superposchi]

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?

[MadMax-FHEM]

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

[Beta-User]

...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 mit

Code Auswählen Erweitern

list 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 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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

{ 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:

Code Auswählen Erweitern

{ notifyRegexpCheck('Kontakte.:closed|Kontakte.:open') }

[Superposchi]

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.

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...

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.

[MadMax-FHEM]

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

[Beta-User]

Na ja, mein "Temperatur-notify" war in "normaler Schreibweise":

Code Auswählen Erweitern

define n_Virtual_Temp_notify notify Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.* set myRealTempSensor=$NAME virtTemp $EVTPART1

Aber 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...):

Code Auswählen Erweitern


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;
}

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...

[MadMax-FHEM]

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

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

[Superposchi]

Aber 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.

[Beta-User]

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.

[betateilchen]

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.

[Superposchi]

Ist noch nicht allzu abstrakt

Du bist offenbar schon zu lange in der Materie drin. Ich finde das sehr abstrakt.