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