Hauptmenü

DOIF bremst FHEM extrem

Begonnen von dt2510, 20 April 2018, 14:35:42

Vorheriges Thema - Nächstes Thema

dt2510

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.

CoolTux

Du triggerst auf alle Events. Das dürfte bisschen viel sein denke ich.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

dt2510

Wie kann ich das einschränken ?

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

dt2510

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.

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Wernieman

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.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dt2510

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.

Damian

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 #)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

dt2510

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 ?

betateilchen

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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

dt2510

Und wie bekomme ich diese Anzahl (in Echtzeit) in ein Dummy, welches ich in TABLETUI anzeigen kann ?

Beta-User

Wie wäre es mit einem notify, das auf on- und off-commands bei den Lichtern reagiert und dann den count absetzt?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dt2510

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 ?

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

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 ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dt2510

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

eisman

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
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

dt2510

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


Otto123

#22
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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

dt2510

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

CoolTux

#24
Mach es mit structure. Glaube mir das ist total einfach.

Anbei mal ein Beispiel in FHEMWEB
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Otto123

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 :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

dt2510

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 😉

Damian

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. ;)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

dt2510

Structure und ReadingsGroup werd' ich mir auf jeden Fall nochmal genauer ansehen.

dt2510

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.