komplexe Situationen - Wie löst ihr das?

[DanielGab]

Hallo lieber Leser
ich hab da mal ne allgemeine Frage an FHEM-Nutzer:

Momentan benutze ich verschiedene Bereich in meinem FHEM und habe verschiedene DOIF-Gruppen. Eigentlich funktioniert alles ganz gut, aber manchmal kaufe ich doch ein neues Gerät und das will dann natürlich auch in meine Befehle eingepflegt werden.

Ich werde mal konkret:
Grundsteuerung regelt je ein DOIF für Rollos, Licht und Heizung
Dummysteuerung regelt die Dummies
Feinsteuerung regelt Kleinigkeiten, wie angelernte Fernbedienungen, Mail-Notifies usw.
Sonos regelt mit verschiedenen DOIFs alles rund um Sonos (Anrufe, Wecker, Gruppierungen usw)

Die Grundsteuerung regelt also mit einem DOIF die Rollos. Dieses DOIF hat nun seine 43 CMDs und funktioniert eigentlich recht gut. Ich habe die CMDs in einer Tabelle in Word erfasst. In der ersten Spalte sind die WAITs, in der zweiten die DEF.

Nun habe ein neues Gerät, einen Fenster-Drehgriff-Schalter. Also muss die DOIF Rollos angepasst werden. Damit vergrößert sie sich gleich mal um den Faktor 2., also 86 CMDs und ich will gar nicht drüber nachdenken, was passiert wenn mein Garten Smart wird...exponentielles Wachstum eben  Da sind Fehler bei mir vorprogrammiert

Nun habe ich über eine Excel-Tabelle nachgedacht, mit der ich einfach über Word und einen Serienbrief neue DOIFs erstellten kann...aber das war auch nur ein Gedanke. Ich weiß nicht ganz genau, ob das klappt könnte. Muss da mal weiter drüber nachdenken. Ein paar Kleinigkeiten habe ich wohl mit PERL realisieren können, aber das fällt mir doch sehr sehr schwer.

Nun zu meiner Frage an die Leser
Wie regelt ihr denn komplexe Situationen und behaltet damit den Überblick über DOIFs?
Welche Tricks bzw. Programme habt Ihr dafür?

Viele Grüße,
Daniel

[rabehd]

  Es gibt Bereiche? Bei mir nur Räume.

Mir scheint das Konzept/Verständnis passt nicht.

Die Grundsteuerung regelt also mit einem DOIF die Rollos. Dieses DOIF hat nun seine 43 CMDs

Für mich ist jedes CMD ein Zustand und da fallen mir keine 43 Verschiedenen ein.

Meine Empfehlung: Lesen, Konzept überdenken, Strukturen nutzen.

Ein Tip aus der Softwareentwicklung: Schreibe mal die einzelnen UseCase auf und setzte die nacheinander um.

[DeeSPe]

Bei mir regeln so wenig wie möglich notify(s) so viel wie nur geht.
Generische Namen helfen mir dabei den Überblick zu behalten und nicht immer wieder neu programmieren zu müssen.

Alle meine "echten" Geräte beginnen immer mit dem Kürzel für den Raum:

• bz - Badezimmer
• ku - Küche
• fl - Flur
• sz - Schlafzimmer
• wz - Wohnzimmer
• bk - Balkon
• ga - Garten

Danach folgt ein Unterstrich und danach eine Bezeichnung für die Art des Devices, gefolgt von einer hochzählenden Nummer (falls mehrere Geräte der selben Art vorhanden sind):

• SD - Steckdosen
• Licht - Lichter
• Sensor - Sensoren

Zusammen ergibt das dann Geräte nach dem folgenden Namensschema:

Code Auswählen Erweitern

bz_SD1
ku_Licht1
wz_Sensor1

Bei meinen Bewegungsmeldern weiß ich z.B. dass diese alle "_Sensor1" mit vorangestelltem Raumkürzel heißen.
Der Trigger für ein notify, welches alle BWMs abdeckt, könnte dann so aussehen:

Code Auswählen Erweitern

([bsw]z|fl|ku)_Sensor1:state:.*

Wenn bei mir ein neues Gerät einer bereits vorhandenen Art dazu kommt, so wird der Zähler einen hochgezählt! Alle anderen notify/readingsGroup/usw. sind bereits so generisch aufgebaut dass die hinzugekommenen Devices automatisch mit abgedeckt werden.

Gruß
Dan

[DanielGab]

Es gibt Bereiche? Bei mir nur Räume.

Mir scheint das Konzept/Verständnis passt nicht.Für mich ist jedes CMD ein Zustand und da fallen mir keine 43 Verschiedenen ein.

Meine Empfehlung: Lesen, Konzept überdenken, Strukturen nutzen.

Ein Tip aus der Softwareentwicklung: Schreibe mal die einzelnen UseCase auf und setzte die nacheinander um.

Ja, der Raum heisst Steuerung 
Und von da aus werden dann die Rollos, das Licht usw. gesteuert.

Ich meine mit den CMDs die 43 möglichen Bedingungskombinationen, die momentan in der Rollo-DOIF eintreten können. Meinst Du das mit UseCase?

Code Auswählen Erweitern

Status: home short long schlafen aufstehen schlummern Frühdienst
Helligkeit: hell dunkel dämmer Mdämmer
Sonnenstand: Küche Garten Dunkel
Beschattung: Sun noSun
TV: on off
Aussentemperatur: warm kühl
Terasse: auf zu kipp

klar überschneidet sich da einiges, aber doch nicht so viel wie ich mir wünschen würde.

[DanielGab]

Bei mir regeln so wenig wie möglich notify(s) so viel wie nur geht.
Generische Namen helfen mir dabei den Überblick zu behalten und nicht immer wieder neu programmieren zu müssen.

find ich gut, habe ich auch so gemacht.

Wenn bei mir ein neues Gerät einer bereits vorhandenen Art dazu kommt, so wird der Zähler einen hochgezählt! Alle anderen notify/readingsGroup/usw. sind bereits so generisch aufgebaut dass die hinzugekommenen Devices automatisch mit abgedeckt werden.

Wie genau sieht das dann bei Dir aus? Bei mir sind hinzukommende Devices auch so abgedeckt, aber Ich habe eigentlich gar keine notifies oder readingGroups. Alles ist mit DOIF geregelt.

z.B.

Code Auswählen Erweitern


(([Status] eq "schlummern" or [Status] eq "Frühdienst") and
   [Sonnenschutz] eq "Küche" and [OGRollo] eq "off")
(set RolloEG scene Sun_Küche)
(set RolloUG scene auf)

DOELSEIF (([Status] eq "schlummern" or [Status] eq "Frühdienst") and
   [Sonnenschutz] eq "Küche" and [OGRollo] ne "off")
(set RolloOG scene zu)
(set RolloEG scene Sun_Küche)

DOELSEIF (([Status] eq "schlummern" or [Status] eq "Frühdienst") and
   [Sonnenschutz] eq "Garten" and [OGRollo] eq "off" and [EG_Tuer_Zustand] eq "auf")
(set RolloEG scene Sun_Garten_Home)
(set RolloUG Schlitze)

DOELSEIF (([Status] eq "schlummern" or [Status] eq "Frühdienst") and
   [Sonnenschutz] eq "Garten" and [OGRollo] eq "off" and [EG_Tuer_Zustand] ne "auf")
(set RolloEG scene Sun_Garten_Home_Tuer_zu)
(set RolloUG Schlitze)

usw. usw.

[DeeSPe]

Für r

Wie genau sieht das dann bei Dir aus? Bei mir sind hinzukommende Devices auch so abgedeckt, aber Ich habe eigentlich gar keine notifies oder readingGroups. Alles ist mit DOIF geregelt.

Für readingsGroup benutze ich z.B. statt der Namen der Devices einen Devspec anhand der modelId.

Der Trigger für ein notify welches alle Steckdosen abdeckt könnte z.B. so aussehen:

Code Auswählen Erweitern

([bsw]z|fl|ku)_SD[1-9]:state:.*

Kommt dann eine bisher nicht vorhandene Steckdose mit Namen wz_SD8 hinzu, so wird diese bereits von dem Trigger mit abgedeckt.

Gruß
Dan

Gruß
Dan

[rabehd]

Aus Deinen Parametern läßt sich was vermuten, fürs Verständnis müßte ich mehr wissen.

Du machst es Dir wohl etwas kompliziert und das wird schwierig zu warten.
Vielleicht mal: Denk einfach.

Status: home short long schlafen aufstehen schlummern Frühdienst

Wenn sich das auf die Anwesenheit von Personen bezieht, dann wäre mir das zu differenziert, hat sich bei mir nicht bewährt.

....

[DanielGab]

Status: home short long schlafen aufstehen schlummern Frühdienst
Wenn sich das auf die Anwesenheit von Personen bezieht, dann wäre mir das zu differenziert, hat sich bei mir nicht bewährt.

Das hat eigentlich nix mit der Anwesenheit der Personen zu tun.

home: irgendjemand ist zu Hause.
schlafen: alle schlafen
schlummern: einer schläft
aufstehen: alle stehen gleichzeitig auf
Frühdienst: einer steht alleine auf
Short/Long: Sehr ähnlich, überschneidet sich fast immer

Und danach richtet sich dann das Verhalten der Rollos, in welchen Räumen Rollos, Licht, Heizung geschaltet oder Sprachnachrichten kommen, wer denn anruft oder wie das Wetter wird.

Aus Deinen Parametern läßt sich was vermuten, fürs Verständnis müßte ich mehr wissen.

Was lässt sich da denn vermuten? Und was musst Du denn da noch wissen?

[rabehd]

Das hat eigentlich nix mit der Anwesenheit der Personen zu tun.

home: irgendjemand ist zu Hause.
schlafen: alle schlafen
schlummern: einer schläft
aufstehen: alle stehen gleichzeitig auf
Frühdienst: einer steht alleine auf
Short/Long: Sehr ähnlich, überschneidet sich fast immer

Für mich sind das Anwesenheits-Stati der Personen. Bei Dir von Deiner Katze?

Ich verstehe es so, dass Du bei Short/Long selbst schon nicht mehr weisst, was es bedeutet 

Ich würde es Raumbezogen aufbauen, also je Raum oder sogar Rollo ein DOIF...

[Beta-User]

Für (HM-) Rolläden gäbe es z.B. auch andere Lösungen als ein (vermutlich schlecht wartbares) Bandwurm-DOIF.

Auch für die Anwesenheitsthemen gäbe es evtl. Module, die man einsetzen könnte.

Dass jemand zwar DOIF's mit 34 Zweigen hat, aber keine notify, finde ich auch bemwerkenswert. Da erscheint mir perl-Lernen eigentlich leichter, verbunden mit einigen wenigen generischen perl-Funktionen, aber das ist Geschmackssache.

[DanielGab]

Für mich sind das Anwesenheits-Stati der Personen. Bei Dir von Deiner Katze?

Ich verstehe es so, dass Du bei Short/Long selbst schon nicht mehr weisst, was es bedeutet 

Ich würde es Raumbezogen aufbauen, also je Raum oder sogar Rollo ein DOIF...

Aber zum Status kommt ja dann noch der Sonnenstand, Wetter, Helligkeit, TV,
So nach dem Motto: Wenn einer schläft, dann ist das OG immer dunkel und es wird nixmehr geschaltet, aber unten wird weiter normal alles gesteuert, je nachdem wie das mit den anderen Variablen ist
Und wenn alle schlafen, dann bleiben die Rollos solange unten, bis man aufsteht, egal obs hell ist oder nicht, die Klingel bleibt aus und das Telefon leise. usw usw

Short/Long unterscheidet sich nur bei der Heizungssteuerung.

Hehe, jetzt weiß ich was mit einfach denken gemeint ist. Das fällt mir oft schwer
Ich denke - soviele Möglichkeiten, die wollen auch alle genannt werden - und ab damit in die DOIF

[rabehd]

  Du bist schon ein besonderer Fall.

Zu den Bereichen äußere ich mich nicht mehr, das ist egal.

Ich würde überlegen was geschalten werden soll ("Rollo-Küche"). Darauf sollte man sich konzentrieren. Die nächste Überlegung welche Änderung eines Status hat darauf Einfluß (Anwesenheit (welche), Fenster, Temperatur...). Dafür wurde ich eine Steuerung bauen, das kann ein notify sein, mir gefällt ein DOIF besser.
Im nächsten Schritt kann man überlegen welche Devices immer gemeinsam beeinflusst werden.

Das ganze Haus mit allen Devices in einem DOIF steuern kann man machen, aber warum? Wartbar ist das irgendwann nicht mehr.

[DanielGab]

Für (HM-) Rolläden gäbe es z.B. auch andere Lösungen

Das finde ich sehr toll! Nur ohne Perl-Kentnisse kann ich die .pm leider nicht anpassen
Ich sollte da doch mal nen Crashkurs machen!

Du bist schon ein besonderer Fall.
Ich würde überlegen was sich schalten will ("Rollo-Küche"). Darauf sollte man sich konzentrieren. Die nächste Überlegung welche Änderung eines Status hat darauf Einfluß (Anwesenheit (welche), Fenster, Temperatur...). Dafür wurde ich eine Steuerung bauen, das kann ein notify sein, mir gefällt ein DOIF besser.
Im nächsten Schritt kann man überlegen welche Devices immer gemeinsam beeinflusst werden.
Das ganze Haus mit allen Devices in einem DOIF steuern kann man machen, aber warum? Wartbar ist das irgendwann nicht mehr.

Hmm, vielleicht sollte ich da mal genauer drüber nachdenken, die einzelnen Devices mit je einem DOIF versorgen. Die UseCase dürften damit sicherlich deutlich weniger werden. Aber dann habe ich so viele DOIFs

Aber bin ich so eigenartig, ich dachte das ist ganz normal, so wie ich das hier bisher geregelt habe. Und es funktioniert auch alles sehr gut und zuverlässig. Machen das wirklich alle anders? Man sagt ja, wenn alle um einen herum komisch sind, ist man es vielleicht nur selbst?

Ich hatte so die Idee, dass alle das allermeiste mit sowenigen DOIFs wie möglich regeln und dazu auch ein einfaches Wartungskonzept haben.

[DeeSPe]

Das finde ich sehr toll! Nur ohne Perl-Kentnisse kann ich die .pm leider nicht anpassen
Ich sollte da doch mal nen Crashkurs machen!


Hmm, vielleicht sollte ich da mal genauer drüber nachdenken, die einzelnen Devices mit je einem DOIF versorgen. Die UseCase dürften damit sicherlich deutlich weniger werden. Aber dann habe ich so viele DOIFs

Aber bin ich so eigenartig, ich dachte das ist ganz normal, so wie ich das hier bisher geregelt habe. Und es funktioniert auch alles sehr gut und zuverlässig. Machen das wirklich alle anders? Man sagt ja, wenn alle um einen herum komisch sind, ist man es vielleicht nur selbst?

Ich hatte so die Idee, dass alle das allermeiste mit sowenigen DOIFs wie möglich regeln und dazu auch ein einfaches Wartungskonzept haben.

Machen kann das prinzipiell jeder so wie er/sie mag/kann!
Gefragt wurde aber:

Wie löst ihr das?

Ein paar Beispiele dazu hast Du genannt bekommen.

Ich habe beispielsweise (fast) meine ganzen notify(s) und at(s) in ein Modul gesteckt welches sich HOMEMODE nennt. Dadurch waren/sind 90% meiner notify(s) obsolet geworden.

Gruß
Dan

[rabehd]

dass alle das allermeiste mit sowenigen DOIFs wie möglich regeln

Von dem Wettbewerb wußte ich noch gar nichts  .

Es soll für den Eigentümer übersichtlich, verständlich und wartbar sein. Wenn man bei 20 DOIFs einen besseren Überblick hat, dann ist es ebenso ok wie ein einzelnes, welche gut kommentiert ist.
Du musst es warten und Dein erster Post hier läßt anderes vermuten.

Ich finde es auf jeden Fall gut, dass Du Dir da Gedanken machst.

[Damian]

Aus meiner bescheidenen Erfahrung:

- je schaltbarer Aktor ein DOIF

- Generalisierung von Abfragen, wo es möglich und sinnvoll ist, z. B.

statt:

Code Auswählen Erweitern

DOIF (T_Keller:temperature] > 21] and [T_Bad:temperatur] > 21 and [T_Wohnzimmer:temperature] > 21 ...) (set ...

z. B.       

Code Auswählen Erweitern

DOIF ([#"^T_:temperature":temperature:$_ > 21] == 6) (set ...

Ausnahmen bestätigen wie immer die Regel

Irgendwie haben meine DOIF Module selten mehr als drei Zweige - vielleicht bin einfach nicht so anspruchsvoll, was die Automatisation angeht

Und für alles, was komplexer ist, gibt es schon ein Modul oder ich bastele mir eins

[rabehd]

je schaltbarer Aktor ein DOIF

Ich wurde bestätigt 

Code Auswählen Erweitern

DOIF ([#"^T_:temperature":temperature:$_ > 21] == 6) (set ...   Wahnsinn was es gibt, wieder was gelernt

[CoolTux]

Komplexe Geschichten landen bei mir in eine 99_myUtils.

[DanielGab]

Ich finde es echt interessant, dass jeder seine Wege hat...
ich hab vor 3 Jahren mit fhem angefangen, da kam gerade das DOIF Modul dazu.
Darauf habe ich mich dann total eingefahren und eben alles damit geregelt.
Und weil es immer funktionierte, hab ich da auch nie weiter gedacht... aber es ist immer dieser große Aufwand, wenn sich was ändert.
Ich probiere jetzt mal etwas anderes aus, gerade was hier vorgeschlagen wurde, ein Device - ein DOIF und auch die Schreibweise von Damian gefällt mir.

Ich sollte mich mal weiter entwickeln [emoji2]

Gesendet von meinem MI 5s mit Tapatalk

[Damian]

Ich finde es echt interessant, dass jeder seine Wege hat...
ich hab vor 3 Jahren mit fhem angefangen, da kam gerade das DOIF Modul dazu.
Darauf habe ich mich dann total eingefahren und eben alles damit geregelt.
Und weil es immer funktionierte, hab ich da auch nie weiter gedacht... aber es ist immer dieser große Aufwand, wenn sich was ändert.
Ich probiere jetzt mal etwas anderes aus, gerade was hier vorgeschlagen wurde, ein Device - ein DOIF und auch die Schreibweise von Damian gefällt mir.

Ich sollte mich mal weiter entwickeln [emoji2]

Gesendet von meinem MI 5s mit Tapatalk

Auch DOIF entwickelt sich weiter, die https://fhem.de/commandref_DE.html#DOIF_aggregation ist noch relativ neu und vermutlich für viele DOIF-Nutzer noch unbekannt.

Und demnächst werden DOIF-Module vermutlich tatsächlich komplexer und mächtiger werden: mit myReadings und eigener WEBUI

[DanielGab]

Erstmal danke für die vielen Inputs, die ich hier bekommen habe. Nun habe ich doch einiges, eigentlich so gut wie die ganze Steuerung umgestellt und bin echt happy!

Ich habe eigentlich für jedes Device ein eigenes DOIF angelegt, und jetzt habe ich total viele DOIFs, aber die lassen sich doch viel viel leichter pflegen! Und wenn ich einen Fehler im Betrieb bemerke, dann finde ich den meistens auch gleich und kann ihn ausbessern

Ich freue mich!! Danke

[Damian]

Erstmal danke für die vielen Inputs, die ich hier bekommen habe. Nun habe ich doch einiges, eigentlich so gut wie die ganze Steuerung umgestellt und bin echt happy!

Ich habe eigentlich für jedes Device ein eigenes DOIF angelegt, und jetzt habe ich total viele DOIFs, aber die lassen sich doch viel viel leichter pflegen! Und wenn ich einen Fehler im Betrieb bemerke, dann finde ich den meistens auch gleich und kann ihn ausbessern

Ich freue mich!! Danke

Wenn die Definitionen sich von Device zu Device etwas unterscheiden, dann ist das vermutlich die einfachste Variante, solange man nicht die einzelnen Definitionen wegen einer globalen Änderung alle anpassen muss.

[Prof. Dr. Peter Henning]

Egal, ob es nun ein DOIF mit Unmengen an Fallunterscheidungen ist, oder "total viele DOIFS": So etwas ist einfach keine gute Praxis - und deshalb kann ich echt nur empfehlen, sich endlich etwas mit Perl zu befassen.

Ausnahmen bestätigen wie immer die Regel

Hm, da schau Dir aber mal die zweite Hälfte des Zitates an, die kehrt seine Bedeutung nämlich um:
Ausnahmen bestätigen die Regel in den nicht ausgenommenen Fällen. (Marcus Tullius Cicero).

LG

pah

[rabehd]

kann ich echt nur empfehlen, sich endlich etwas mit Perl zu befassen.

Man könnte auch fordern, dass sich die Leute mit anderen (Kauf-)Lösungen beschäftigen und für FHEM eine Zugangsprüfung eingeführt wird.
Klar macht ein wenig Perl vieles schöner, aber ich finde es gut wenn viele Leute sich mit fhem beschäfigen. Überheblichheit schafft keine Verbreitung.

Außerdem möchte ich hier mal den Leuten danken, die Module entwickeln, hier Hilfe geben und auch weiterentwickeln, wenn ihr eigenes Ziel schon erreicht ist.

[Fritz Muster]

So etwas ist einfach keine gute Praxis - und deshalb kann ich echt nur empfehlen, sich endlich etwas mit Perl zu befassen.

Mangels Perl Kenntnisse verstehe ich das leider nicht. Was wäre denn anders/übersichtlicher wenn ich anstatt DOIF`s, notify`s, usw. alles in Perl machen würde?

Danke und Grüße
Fritz

[Prof. Dr. Peter Henning]

Außerdem möchte ich hier mal den Leuten danken, die Module entwickeln, hier Hilfe geben und auch weiterentwickeln, wenn ihr eigenes Ziel schon erreicht ist.

Nur zur Erläuterung: Damit meint er mich, weil ich ihm nicht das Modul 95_Astro.pm wunschgemäß geändert habe. Aber gut: Ich kann ihm ja gerne mal meinen Honorarsatz per PM zukommen lassen.

Mangels Perl Kenntnisse verstehe ich das leider nicht

Perl ist aber einfacher zu lernen und logisch konsistenter, als die Syntax der DOIFs.

Was wäre denn anders/übersichtlicher wenn ich anstatt DOIF`s, notify`s, usw. alles in Perl machen würde

Alles sicher nicht. Aber alles, was komplexer ist:

- mehrfache Bedingungen, kompliziertere Bedingungen mit UND / ODER
- Schleifen und Wiederholungen
- Bearbeitung von Strings

Weitere Vorteile: Offline (außerhalb von FHEM) editierbar, auch mit einem Syntax-empfindlichen Editor. Testbarkeit außerhalb von FHEM. Modularisierbarkeit. Objektorientierung.

usw.

Ich habe hier im Forum irgendwo (und irgendwann) schon einmal als PDF-Datei ein Kapitel über Perl aus dem "Handbuch Programmiersprachen" bereit gestellt. In dem Buch habe ich vor mehr als 10 Jahren zusammen mit einem Kollegen 26 Programmiersprachen kompakt dargestellt. Die Datei müsste mit der Suchfunktion zu finden sein

.
LG

pah

[rabehd]

... weil ich ihm nicht das Modul 95_Astro.pm wunschgemäß geändert habe. Aber gut: Ich kann ihm ja gerne mal meinen Honorarsatz per PM zukommen lassen.

Danke, nicht nötig. Meine Programmierkenntnisse reichten bisher aus.