FHEM Forum

FHEM => Automatisierung => DOIF => Thema gestartet von: dt2510 am 20 April 2018, 14:35:42

Titel: DOIF bremst FHEM extrem
Beitrag von: dt2510 am 20 April 2018, 14:35:42
Ich habe ein Paar DOIF's definiert um die Anzahl eingeschalteter Lampen, Steckdosen, geöffnerter Rolläden und Fenster zu ermitteln.
Allerdings ist das System kaum zu bedienen, wenn alle DOIF's enabled sind. Je mehr ich diasable um so schneller wird mein System - vielleicht hab' ich einen Fehler in der Definition ...
Hier mal die Definitionen:

define NumLightsOn DOIF ([""])
attr NumLightsOn state [#""::$STATE ne "off" and $group eq "Beleuchtung"]

define NumPlugsOn DOIF ([""])
attr NumPlugsOn state [#""::$STATE ne "off" and $group eq "Steckdosen"]

define NumShuttersUp DOIF ([""])
attr NumShuttersUp state [#""::$STATE ne "dim 0" and $group eq "Rollladen"]

define NumWindowsOpen DOIF ([""])
attr NumWindowsOpen state [#""::$STATE ne "closed" and $group eq "Fenstersensor"]


Könnte man so auch eine Durchschnittstemperatur ermitteln ? Diese würde im Reading temperature in der Form "xx.x C" stehen.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: CoolTux am 20 April 2018, 14:39:32
Du triggerst auf alle Events. Das dürfte bisschen viel sein denke ich.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 20 April 2018, 14:42:56
Wie kann ich das einschränken ?
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: CoolTux am 20 April 2018, 14:57:12
Hier ein Beispiel aus der Commandref zu DOIF
Zitat
"Fenster offen"-Meldung

define di_window_open (["^window_:open"]) (set Pushover msg 'alarm' 'open windows $DEVICE' '' 2 'persistent' 30 3600)

attr di_window_open do always

Hier werden alle Fenster, die mit dem Device-Namen "window_" beginnen auf "open" im Event überwacht.


Hier für Fenster Status Meldung
Zitat
Fenster Status/Meldung:

define di_Fenster DOIF (["^Window:open"])
(push "Fenster $DEVICE wurde geöffnet. Es sind folgende Fenster offen: [@"^Window":state:"open"]")
DOELSEIF ([#"^Window:closed":state:"open"] == 0)
(push "alle Fenster geschlossen")

attr di_Fenster do always
attr di_Fenster cmdState [$SELF:Device] zuletzt geöffnet|alle geschlossen
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 20 April 2018, 15:09:49
Hmm .. dann müsste ich meinen zu Zählenden Devices eindeutige Präfixes vor den Namen stellen, da ich immer den Aktor-Typ in Verbindung mit der ID als Namen habe (z.B. FGS222_ID13). Das stellt aber kein Problem dar. Im Falle der Beleuchtung würde das dann in etwa so aussehen (?):

define NumLightsOn DOIF (["^light_:on"])
attr NumLightsOn do always
attr NumLightsOn state [#""::$STATE ne "off" and $group eq "Beleuchtung"]


Reagiert DOIF jetzt auf jede Änderung oder nur auf "on" ?
Dummerweise habe ich auch Dimmer (HUE) darunter, die nur "off" liefern oder z.B. "dim06%" (deshalb die Abfrage auf "off"). Es gäbe dort auch noch ein userReading "onoff", welches den Inhalt 0 oder 1 hat.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: CoolTux am 20 April 2018, 15:12:59
Devices die in der Logik Verwendung finden sollten immer vernünftig benannt werden.
FensterWohnzimmerLinks oder so. Da kann man also bei Dir gleich ein bisschen Ordnung machen.
Ich bin kein DOIF Experte, bei den Hue empfehle ich in der Tat das Reading onoff zu nehmen.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Wernieman am 20 April 2018, 15:18:19
Allerdings gilt es nicht nur bei doif, sondern auch bei notify:
Je mehr man schon in der definition einschränkt, desto weniger wird das System belastet.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 20 April 2018, 15:33:29
Ich denke ich muss mir an der Stelle etwas anderes überlegen (z.B. eine Funktion in der 99_MyUtils.pm), da mein System (Intel NUC6 Celeron mit 4GB RAM/SSD - exclusiv für Linux/FHEM) schon bei den 4 DOIF's extrem in die Knie geht. Die Bedienung über TABLETUI ist auch bei einer Einschränkung (hab' jetzt mal nur die betreffenden Aktor-Typen genommen) ab dem 3. DOIF nahezu unmöglich.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Damian am 20 April 2018, 15:37:23
attr NumLightsOn state [#""::$STATE ne "off" and $group eq "Beleuchtung"]

Das dürfte jedes System in die Knie zwingen:

Bei jedem Event  im System (hier: "") werden alle Devices in zwei ineinander geschachtelten Schleifen durchsucht (wegen Aggregation mit #)
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 20 April 2018, 15:56:35
Wie würde ich das "vernünftig" definieren ? Ich hab' DOIF bisher noch nie genutzt und bin mit dem Funktionsumfang und der Definition etwas überfordert ...

Sagen wir, ich möchte die Anzahl der Devices, die mit "light_" beginnen, zählen, die nicht "off" sind. Wie würde ich das machen ?
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: betateilchen am 20 April 2018, 15:57:58
Zitat von: dt2510 am 20 April 2018, 15:56:35
Sagen wir, ich möchte die Anzahl der Devices, die mit "light_" beginnen, zählen, die nicht "off" sind. Wie würde ich das machen ?

mit "count <devspec>"

Dazu braucht es keinerlei trigger auf irgendwelche events. Weder per doif noch sonstwie.

Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 20 April 2018, 16:02:25
Und wie bekomme ich diese Anzahl (in Echtzeit) in ein Dummy, welches ich in TABLETUI anzeigen kann ?
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Beta-User am 20 April 2018, 16:06:58
Wie wäre es mit einem notify, das auf on- und off-commands bei den Lichtern reagiert und dann den count absetzt?
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 20 April 2018, 16:09:32
Die Dokumentation zu "count" ist leider extrem dürftig .. ich hab' keine Ahnung wie ich das überhaupt verwenden soll ...
Klar ich könnte mit notify arbeiten, aber die müsste ich dann bei jedem Aktor definieren. Ob das für die Systemlast unbedingt besser ist ?
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Beta-User am 20 April 2018, 16:19:11
Wieso ein notify pro Device? Du kannst da genausogut mit wildcards arbeiten und auch beliebige alternative Bedingungen definieren (geht auch bei DOIF):

Beispiel:
defmod n_Rolladen_Window notify .*(closed|open|tilted)|(Rolladen_.*|Jalousie_.*).(motor:.stop.*|set_.*|motor..down.*) count <devspec>
Reagiert auf Fenster- und Türkontakte ODER auf Befehle an meine Rolläden/Jalousien bzw. Motorbewegungen, die lokal am Aktor direkt ausgelöst werden...

Am besten mal im Eventmonitor testen, wie sich sowas zusammenbasteln läßt (siehe wiki zu Eventmonitor). Ob deine Ausdrücke dann passen, kannst du z.B. mit http://regex101.com/ prüfen.

Grüße, Beta-User
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: CoolTux am 20 April 2018, 16:28:33
Licht würde ich in structure packen. Man bekommt darüber zwar keine Anzahl, sieht aber wo noch Licht an ist.
Ich mache das pro Raum und mache dann die Raum structureen noch in eine Gesamtstruktur.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Beta-User am 20 April 2018, 16:33:07
Da hast du recht mit dem Hinweis auf structure.
Aber an sich steht alles, was wir hier schreiben ganz ordentlich im Einsteiger-pdf (mit dem habe ich auch die Einstellung der behaviours damals gemacht).

@dt2510: Vielleicht solltest du das bei Gelegenheit mal wieder überfliegen, bin auch immer wieder überrascht, was da alles drinsteht ;) .
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 20 April 2018, 16:36:57
Ich werd' mir heute Abend noch die ein oder andere Dokumentation (auch die Einsteiger pdf) ansehen und etwas rumprobieren.
Es gibt einfach viel zu viel Sachen in FHEM, die ich bis heute (mein System läuft schon seit 2 Jahren) noch nie genutzt habe ...
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: eisman am 20 April 2018, 16:38:33
hi,

für fenster,türen,batterie und cover,

habe ich das so gelöste(umgeschrieben)

sub getFensterStatus($) {
  my ($name) = @_;
  my @list     = devspec2array("model=HM-SEC-RHS");
  my $state    = "closed";
  my $nokCount = 0;
  my $count    = 0;
  my $nokDevs  = "";
  foreach my $dev (@list) {
    $count++;
    if (ReadingsVal($dev,"state","nok") ne "closed" and ReadingsVal($dev,"ignore",0) != 1) {
      $nokCount++;
      $state = "nok";
      $nokDevs .= AttrVal($dev,"alias","-").",";
    }
  }
  if ($nokCount == 0) {$nokDevs = "none"};
  fhem ("setreading " . $name . " totalDev " . $count);
  fhem ("setreading " . $name . " nokDev " . $nokCount);
  fhem ("setreading " . $name . " nokDevs " . $nokDevs);
  fhem ("set " . $name . " " . $state);
}


hatte ich irgend wo im Forum gefunden

gruss
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: betateilchen am 20 April 2018, 23:33:22
Zitat von: dt2510 am 20 April 2018, 16:09:32
Die Dokumentation zu "count" ist leider extrem dürftig .. ich hab' keine Ahnung wie ich das überhaupt verwenden soll ...

count ist genau so ein FHEM Befehl wie "set" oder "attr" und kann an den gleichen Stellen verwendet werden wie jeder andere FHEM Befehl auch.

Und was devspec ist, steht in der commandref beschrieben.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Otto123 am 20 April 2018, 23:47:45
Hi

Zitat von: dt2510 am 20 April 2018, 15:56:35
Sagen wir, ich möchte die Anzahl der Devices, die mit "light_" beginnen, zählen, die nicht "off" sind. Wie würde ich das machen ?
Beispiel für devspec https://fhem.de/commandref_DE.html#devspec
count light_.*:FILTER=STATE!=off

Gruß Otto
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 21 April 2018, 09:39:47
Zitat von: Otto123 am 20 April 2018, 23:47:45
Hi
Beispiel für devspec https://fhem.de/commandref_DE.html#devspec
count light_.*:FILTER=STATE!=off

Gruß Otto

Das sieht ja an sich recht einfach aus. Um die Anzahl aber auch in TABLETUI verwenden zu können, müsste diese in einem Reading stehen. Würde das dann so aussehen ?

define NumLightsOn dummy
attr NumLightsOn stateFormat {count light_.*:FILTER=STATE!=off}


edit:

gerade mal ausprobiert, aber so einfach scheint es dann nicht zu sein ...

Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Otto123 am 21 April 2018, 11:32:52
Moin,

weil Du wieder nicht drüber nachdenkst, ob es Perl oder FHEM ist  :o
ZitatstateFormat
Ändert den Gerätestatus, dies ist z.Bsp. in der Ausgabe des list Kommandos zu sehen, oder in der Raumübersicht von FHEMWEB. Falls nicht gesetzt, dann wird das state Reading übernommen. Sonst werden alle Wörter im Wert des Attributes durch das entsprechende Reading des Gerätes ersetzt (soweit vorhanden). Falls der Wert in {} eingeschlossen ist, dann wird es als Perl Ausdruck ausgewertet. Die Auswertung passiert bei jeder Änderung eines Readings.

Das ist FHEM Code count light_.*:FILTER=STATE!=off
Der funktioniert aber so nicht in stateFormat.
Das ist Perl Code {fhem("count light_.*:FILTER=STATE!=off")}
Der funktioniert, aber ist das Ergebnis sinnvoll? Gut z.B. [NumLightsOn:STATE:d] oder InternalNum() kann dir Dir die Zahl liefern.

Sinn macht das aus meiner Sicht in einem nackten extra Dummy auch nicht, da ändert sich nie ein Reading. (siehe Auszug aus der Doku)

Du musst noch irgendeinen (Zeit?) Trigger finden der dir diesen Wert dann aktualisiert wenn du ihn brauchst (aber nicht bei jedem Event in FHEM  ;D)

Gruß Otto
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 21 April 2018, 12:47:47
Da muss ich mal überlegen ....

Das Ziel ist ja klar und relativ einfach: ich möchte in TABLETUI auf einen Blick (in Echtzeit) sehen, ob noch irgendwo Licht usw. an ist, aber der Weg dortin ....
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: CoolTux am 21 April 2018, 13:02:04
Mach es mit structure. Glaube mir das ist total einfach.

Anbei mal ein Beispiel in FHEMWEB
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Otto123 am 21 April 2018, 13:08:11
Zitat von: dt2510 am 21 April 2018, 12:47:47
Das Ziel ist ja klar und relativ einfach ich möchte in TABLETUI auf einen Blick (in Echtzeit) sehen, ob noch irgendwo Licht usw. an ist, aber der Weg dortin ....
Der Betreff klang aber ganz anders :)
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 21 April 2018, 13:22:25
Zitat von: Otto123 am 21 April 2018, 13:08:11
Der Betreff klang aber ganz anders :)

Der Betreff stimmte schon ... auf die Art hat es ja funktioniert, aber leider nicht performant 😉
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: Damian am 21 April 2018, 13:34:15
Zitat von: dt2510 am 21 April 2018, 13:22:25
Der Betreff stimmte schon ... auf die Art hat es ja funktioniert, aber leider nicht performant 😉

Du musst dir halt im Vorfeld Gedanken machen, wann die Informationen aktualisiert werden sollten - bei jedem Event im System bestimmt nicht.

Entweder packst du deine Lichter in eine Structure, oder überlegst dir ein Namenskonzept und dann ist eine der kürzesten Definitionen für diesen Fall deine bereits definierte, die du nur geringfügig anpassen musst z. B.

attr NumLightsOn state [#"^Licht:on"::$STATE ne "off" and $group eq "Beleuchtung"]

Wenn deine Lichter mit "Licht" anfangen würden. Dann wird auch dein System kaum etwas an Performanceverlust spüren. ;)
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 21 April 2018, 21:25:10
Structure und ReadingsGroup werd' ich mir auf jeden Fall nochmal genauer ansehen.
Titel: Antw:DOIF bremst FHEM extrem
Beitrag von: dt2510 am 25 April 2018, 11:17:27
Ich habe es jetzt erst mal mit structures gelöst. Wenn ich es richtig verstanden habe, wird eine ReadingsGroup nur dann aktualisiert, wenn sie im Browser angezeigt wird - da ich TABLETUI verwende, ist das bei mir nicht der Fall...

Hier die Definitionen:
define Lights structure Lights PowerNode_ID8 PowerNode_ID9 FGS212_ID10 FGS212_ID11 FGS222_ID12 FGS222_ID12.02 FGS222_ID13 FGS222_ID13.02 FGS222_ID14 FGS222_ID13.02 FGS212_ID15
define DimmableLights structure DimmableLights HUEGroup1 HUEGroup2
define Shutters structure Shutters FGR222_ID17 FGR222_ID18 FGR222_ID19 FGR222_ID20
define Plugs structure Plugs Aeotec_Smart_Switch_6_ID27 Aeotec_Smart_Switch_6_ID28 Aeotec_Smart_Switch_6_ID29 Aeotec_Smart_Switch_6_ID30
define Windows structure Windows Hauppauge_4_in_1_ID30


und die Darstellung in TABLETUI:
                    <div data-type="label"
                         data-device="Lights"
                         data-get="state"
                         data-substitution='["off","alle Lampen sind aus","on","alle Lampen sind an","undefined","es sind Lampen an"]'
                         data-colors='["Linen","Yellow","FireBrick"]'
                         data-limits='["off","on","undefined"]'>
                    </div>
                    <div data-type="label"
                         data-device="DimmableLights"
                         data-get="state"
                         data-substitution='["off","alle dimmbaren Lampen sind aus","on","alle dimmbaren Lampen sind an","undefined","es sind dimmbare Lampen an"]'
                         data-colors='["Linen","Yellow","FireBrick"]'
                         data-limits='["off","on","undefined"]'>
                    </div>
                    <div data-type="label"
                         data-device="Plugs"
                         data-get="state"
                         data-substitution='["off","alle Steckdosen sind aus","on","alle Steckdosen sind an","undefined","es sind Steckdosen an"]'
                         data-colors='["Linen","Yellow","FireBrick"]'
                         data-limits='["off","on","undefined"]'>
                    </div>
                    <div data-type="label"
                         data-device="Shutters"
                         data-get="state"
                         data-substitution='["dim 98","alle Roll&auml;den sind offen","dim 0","alle Roll&auml;den sind geschlossen","undefined","es sind Roll&auml;den offen"]'
                         data-colors='["Linen","Yellow","FireBrick"]'
                         data-limits='["dim 98","dim 0","undefined"]'>
                    </div>
                    <div data-type="label"
                         data-device="Windows"
                         data-get="state"
                         data-substitution='["closed","alle Fenster sind geschlossen","open","alle Fenster sind offen","undefined","es sind Fenster offen"]'
                         data-colors='["Linen","Yellow","FireBrick"]'
                         data-limits='["closed","open","undefined"]'>
                    </div>


Das Ergebnis sieht man im angehängten Bild. Den niedrigsten Batteriestatus werde ich wohl in der 99_myUtils.pm ermitteln und per at alle paar Stunden in einem Dummy ablegen, welches ich dann anzeigen kann.