Neues Modul: 22_HOMEMODE.pm - grundlegende Automationen und mehr

[DeeSPe]

Guten Tag Dan,

merci für Deine ausführliche Antwort, ich stehe immer noch  beim regex für HomeSensorsContactValues aufm Schlauch,

im post #1 steht Standardwert: open|tilted|on

wie kann ich den ganz konkret am liebsten  an Hand eines Beispiels mehrere werte für open wie z.b. "open|Open" einsetzen?

für open hätte ich gerne open|Open|on
tilted bleibt
sabotageError on bleibt.



merci für Deine Hilfestellung.

P.S Meine Fensteröffnungswarnungen bleiben dann wohl wie bisher temperaturabhängig: if draussen < -10 grad zu innen wird schneller gewarnt, bei >= garnicht bzw haus verlassen 

HomeSensorsContactValues
Regex der Werte die für offen und sabotiert stehen.
Die hier eingetragenen Werte sind global für alle Kontaktsensoren, können aber durch setzen des Attributs HomeValues in jedem Sensor überschrieben werden.
Werte: frei wählbar
Werteformat: Regex
Standardwert: open|tilted|on

Wie schon beschrieben ist das ein Regex welcher alle Offen-Zustände abdecken muss.
Du könntest also Folgendes setzen:

Code Auswählen Erweitern

open|Open|tilted|on
oder nach Regex Syntax geht auch eleganter:

Code Auswählen Erweitern

[Oo]pen|tilted|on

Gruß
Dan

[alex885]

ich bin doof, habs immer noch nicht kapiert...


das kapier ich:
[Oo]pen|tilted|on ->Trennung der 3 möglichen werte durch |

das nicht:
open|Open|tilted|on -> wie erkennst Du welcher wert für was zuständig ist?

ist aber schon etwas OT. Keine Antwort notwendig.

& Danke fürs elegante und logische Regex - wie Du siehst hab ich da noch gewissen Lernbedarf.

Einen schönen Tag, A.

[DeeSPe]

ich bin doof, habs immer noch nicht kapiert...


das kapier ich:
[Oo]pen|tilted|on ->Trennung der 3 möglichen werte durch |

das nicht:
open|Open|tilted|on -> wie erkennst Du welcher wert für was zuständig ist?

ist aber schon etwas OT. Keine Antwort notwendig.

Das klappt weil ich davon ausgehe dass sich offen und sabotiert im Wert unterscheiden, es wird wohl keinen Wert close(d) geben der anzeigt dass ein Sabotagekontakt ausgelöst wurde.
Wenn ich den RegEx also auf das Reading loslasse welches offen darstellt, matchen die für offen zuständigen Werte (sofern offen).
Lasse ich den selben RegEx auf das Reading welches Sabotage darstellen soll los, so matcht der für sabotiert zuständige Wert (sofern sabotiert).

Gruß
Dan

[alex885]

jetzt hats geklickt

bin davon ausgegangen das 1|2|3 auf 1-open|2-tilted|3-sabotageError angewendet werden ...
nix da eine regex für alles.

merci, A.

[FranzB94]

Hi Dan!

...oder nach Regex Syntax geht auch eleganter:

Code Auswählen Erweitern

[Oo]pen|tilted|on

Dann sagt mit fhem aber:

Code Auswählen Erweitern


Invalid value [Oo]pen|tilted|on for attribute HomeSensorsContactValues. You have to provide at least one value or more values pipe separated, p.e. open|tilted|on]

Gruß Franz

[bastelfeak]

Hallo,
ich bin gerade auch dabei dein Modul zu erproben. Es ist wirklich toll und ich schwer begeistert.
Was mir noch nicht ganz klar ist: Warum diese unflexible Variante für die Fenster/Türkontakte?
Für mich wäre es sinnvoller, es von den Außentemperaturen/Temperaturabfall im Raum, als von Jahreszeiten abhängig zu machen.
Wäre eine Logik auf Temperaturen basierend integrierbar?

Viele Grüße
bastelf(r)eak

[DeeSPe]

Hi Dan!
Dann sagt mit fhem aber:

Code Auswählen Erweitern


Invalid value [Oo]pen|tilted|on for attribute HomeSensorsContactValues. You have to provide at least one value or more values pipe separated, p.e. open|tilted|on]

Gruß Franz

Ups, hab wohl doch nur Wörter für den RegEx erlaubt!
Dann muss ich meine vorherige Aussage wohl (erst einmal) revidieren.

Hallo,
ich bin gerade auch dabei dein Modul zu erproben. Es ist wirklich toll und ich schwer begeistert.
Was mir noch nicht ganz klar ist: Warum diese unflexible Variante für die Fenster/Türkontakte?
Für mich wäre es sinnvoller, es von den Außentemperaturen/Temperaturabfall im Raum, als von Jahreszeiten abhängig zu machen.
Wäre eine Logik auf Temperaturen basierend integrierbar?

Viele Grüße
bastelf(r)eak

Ja, das wäre theoretisch möglich.
Aber das ist mir ehrlich gesagt viel zu komplex weil es doch eben auch immer sehr individuell ist.
Wie viele Aussen und Innen Temperatur-/Luftfeuchtigkeits-/Sonnen-/Sonstnochwas-Sensoren soll ich berücksichtigen? Für jeden ein Attribut? Für jeden ein Attribut mit Schwellwerten, und und und...
M.E. soll sich das jeder selber basteln der/die das anhand so vieler individueller Faktoren auswerten möchte.
Ich möchte ein möglichst allgemeines Modul anbieten! Punkt.

Gruß
Dan

[bastelfeak]

Wenn man im ersten Schritt einfach Schwellwerte für Außentemperatur angeben kann und dazu passend die Lüftungszeiten global und im Zweifelsfall die Lüftungszeiten nochmal separat im Device definiert. Im Frühling können es ja mal gerne an die 20°C werden, da muss ich mich nicht nach 10 Minuten erinnern lassen, aber eben auch -5°C und da sind 10 Minuten bei großen Fenstern schon fast zu lang. Du wertest ja nur eine Außentemperatur aus, daher ist das relativ übersichtlich.
Bei einer Überwachung des Temperaturabfalls muss man dann die Kontakte und die Temperaturen den Räumen zuordnen, dass wird wesentlich aufwändiger, da stimme ich dir zu.

Muss ich so damit leben. Vielen Dank trotzdem für deine tolle Arbeit.

[Martin Fischer]

Hallo Dan,

danke für das Modul. Teste es gerade..

Was das Modul schon kann:

Könntest Du bitte noch in die Dokumentation aufnehmen, welche Konstanten und Automatismen Du intern nutzt.

Konstanten wären z.B. die Zeitfenster für die Tageszeiten. Das hast Du zwar hier im Thread schon geschrieben, jedoch steht es nicht in der Doku. Evtl. gibt es ja auch noch weitere Konstanten die Du nutzt.

Es wäre auch hilfreich, wenn in der Dokumentation noch aufgeführt wird, welche internen "hardcoded" Auslöser, Timer, Entscheidungen, etc. Du nutzt.

Zum Beispiel, das der Alarmmode gesetzt wird, wenn alle Bewohner abwesend sind. Bei der Vielzahl der Möglichkeiten die Dein Modul bietet - und es soll ja nach Möglichkeit verhindern das man notifys, doifs, dummys baut - sollte die Logik gut dokumentiert sein. Sonst definiert man dann doch etwas und das macht Dein Modul eigentlich schon von Haus aus..

Viele Grüße
Martin

[alex885]

Noch vielfältiger nutzbar wäre es, wenn möglichst wenig hardcoded wäre und man z.b. die Tages&Jahreszeiten ändern könnte...


danke für das feine Modul, das dann doch noch mehr Begehrlichkeiten weckt...

Alex

[Martin Fischer]

Noch vielfältiger nutzbar wäre es, wenn möglichst wenig hardcoded wäre und man z.b. die Tages&Jahreszeiten ändern könnte...

Eins nach dem Anderen...

Erst sollten diese bekannt sein und dann könnte man sie konfigurierbar machen

Was aber noch in der Dokumentation Erwähnung finden sollte, ist eine Auflistung der generierten Events.

[DeeSPe]

Hallo Dan,

danke für das Modul. Teste es gerade..

Könntest Du bitte noch in die Dokumentation aufnehmen, welche Konstanten und Automatismen Du intern nutzt.

Konstanten wären z.B. die Zeitfenster für die Tageszeiten. Das hast Du zwar hier im Thread schon geschrieben, jedoch steht es nicht in der Doku. Evtl. gibt es ja auch noch weitere Konstanten die Du nutzt.

Es wäre auch hilfreich, wenn in der Dokumentation noch aufgeführt wird, welche internen "hardcoded" Auslöser, Timer, Entscheidungen, etc. Du nutzt.

Zum Beispiel, das der Alarmmode gesetzt wird, wenn alle Bewohner abwesend sind. Bei der Vielzahl der Möglichkeiten die Dein Modul bietet - und es soll ja nach Möglichkeit verhindern das man notifys, doifs, dummys baut - sollte die Logik gut dokumentiert sein. Sonst definiert man dann doch etwas und das macht Dein Modul eigentlich schon von Haus aus..

Viele Grüße
Martin

Hi Martin,

vielen Dank für Deine sinnvollen kritisierenden Hinweise. Davon gibt es leider immer nur sehr wenige.
Ich werde diese sobald es mir möglich ist berücksichtigen. Leider ist man hier im Forum pro Beitrag auf eine bestimmte Zeichenanzahl begrenzt (ich glaube 5000). Das macht mir jetzt schon Schwierigkeiten bei den Changelogs im ersten Beitrag. Habe schon mehrfach Abschnitte aus dem ersten Beitrag in den zweiten verschoben damit das Changelog wieder in den ersten passt.
Wie schon gesagt, wäre eigentlich mein Endziel das Modul offiziell in SVN einzuchecken. Dazu passend wäre sicher ein Wiki Artikel sehr sinnvoll, der die Möglichkeiten aus den ersten beiden Beiträgen noch einmal darstellt. Im Wiki kann man sich dann auch "austoben" mit der Artikellänge und entsprechend alle gewünschten Informationen unterbringen. Ein weiterer Vorteil des Wiki ist dass ich das nicht alles alleine machen müsste.

Ich denke auch noch darüber nach das Ganze per Github Update anzubieten, zumindest bis das Modul mal offiziell ist.

Noch vielfältiger nutzbar wäre es, wenn möglichst wenig hardcoded wäre und man z.b. die Tages&Jahreszeiten ändern könnte...


danke für das feine Modul, das dann doch noch mehr Begehrlichkeiten weckt...

Alex

Das ist für mich als Entwickler immer eine Gratwanderung!
Einerseits soll so viel wie möglich konfigurierbar sein, andererseits möchte ich das Modul nicht unnötig mit Attributen überfrachten!
Die Vielzahl der Attribute ist selbst für mich mittlerweile schon teilweise etwas unübersichtlich geworden. Ich hatte ja bereits versucht die Attribute nach Namen thematisch zu ordnen, aber irgendwann wird auch das zu viel (siehe HomeCMD Attribute).
Gerade die Tages- und Jahreszeiten denke ich mir ja nicht aus, sondern habe mich da an offizielle Informationen gehalten. Ich sehe da nicht wirklich akuten Verbesserungsbedarf, lasse mich aber gerne auf eine sinnvolle Diskussion darüber ein.

Gruß
Dan

[Martin Fischer]

vielen Dank für Deine sinnvollen kritisierenden Hinweise. Davon gibt es leider immer nur sehr wenige.

Gern.

Ich werde diese sobald es mir möglich ist berücksichtigen. Leider ist man hier im Forum pro Beitrag auf eine bestimmte Zeichenanzahl begrenzt (ich glaube 5000). Das macht mir jetzt schon Schwierigkeiten bei den Changelogs im ersten Beitrag. Habe schon mehrfach Abschnitte aus dem ersten Beitrag in den zweiten verschoben damit das Changelog wieder in den ersten passt.

Ich meinte damit nicht das Forum oder Wiki    Sondern die Dokumentation in der commandref. Ich bin nicht davon überzeugt, das Moduldokumentation "verstreut" mal im Modul, mal im Forum und mal im Wiki steht. Forum und Wiki sind ergänzende Informationen oder beinhalten Beispiele, etc.

Das Modul selber sollte soweit alle Informationen beinhalten um es ohne Wiki / Forum einrichten zu können. Ein "Beispiel" dafür ist z.B. das Modul MSG. Dort steht in der commandref schlicht der Verweis auf das Forum. Ich schätze die Module und Möglichkeiten die Loredo umsetzt aber bei der Konfiguration möchte ich nicht in Foren oder Wikis suchen müssen.

Ich denke auch noch darüber nach das Ganze per Github Update anzubieten, zumindest bis das Modul mal offiziell ist.

Dafür habe ich die Funktion mal in dem Updateprozess bereitgestellt. 
Im Rahmen der Entwicklung und aktuellen Nutzung würdest Du damit sicherlich einige erreichen.

Das ist für mich als Entwickler immer eine Gratwanderung!
Einerseits soll so viel wie möglich konfigurierbar sein, andererseits möchte ich das Modul nicht unnötig mit Attributen überfrachten!
[...]
Gerade die Tages- und Jahreszeiten denke ich mir ja nicht aus, sondern habe mich da an offizielle Informationen gehalten. Ich sehe da nicht wirklich akuten Verbesserungsbedarf, lasse mich aber gerne auf eine sinnvolle Diskussion darüber ein.

Ein klares Jain   Ich stimme Dir voll und ganz zu, wenn es um die Übersichtlichkeit geht. Aber es ist die Philosophie / Stärke von FHEM, das man nur sehr wenig Vorgaben und Einschränkungen hat. Das gewählte Beispiel der Jahreszeiten ist vielleicht ein nicht so treffendes Beispiel. Hier wird es wohl eher kaum Abweichungen geben, da hast Du Recht. Es gibt aber sicherlich Konstanten die man individuell anpassen möchte. Ein Beispiel wären interne Timer oder Zeitfenster. Vielleicht möchte jemand "morning" nicht schon um 5 Uhr starten sondern erst um 7 Uhr.

Auch wenn es mehr Attribute werden, solltest Du den Schritt gehen. Dein Modul "beherbergt" ja nun viele Funktionen / Status und löst bestehende ab. Hier sollte dann nicht die Flexibilität verloren gehen.

Viele Grüße und weiter so

[alex885]

Das gewählte Beispiel der Jahreszeiten ist vielleicht ein nicht so treffendes Beispiel.

Ja, das stimmt wohl.... 

hab aber einen work-around schritt weitergedacht und dachte damit das Thema der FensterOffen-Warnungen die im Modul Jahreszeiten orientiert betrachtet werden anzugehen ...

ein anderer Ansatz, bei den FensterOffen-Warnungen wäre da wohl sinnvoller....

das total simple Modul für Alles&Jeden gibts nicht, Dan hat für sich was tolles gemacht & uns zur Verfügung gestellt, Danke dafür! darüberhinaus mag er sich auch noch unsere Meinung, Wünsche & Verbesserungsvorschläge anhören. Mein  volles Verständnis dafür, dass er davon nur das coded was er für sinnvoll&nützlich erachtet.

schönen Tag, A.

[DeeSPe]

Ich meinte damit nicht das Forum oder Wiki    Sondern die Dokumentation in der commandref. Ich bin nicht davon überzeugt, das Moduldokumentation "verstreut" mal im Modul, mal im Forum und mal im Wiki steht. Forum und Wiki sind ergänzende Informationen oder beinhalten Beispiele, etc.

Das Modul selber sollte soweit alle Informationen beinhalten um es ohne Wiki / Forum einrichten zu können. Ein "Beispiel" dafür ist z.B. das Modul MSG. Dort steht in der commandref schlicht der Verweis auf das Forum. Ich schätze die Module und Möglichkeiten die Loredo umsetzt aber bei der Konfiguration möchte ich nicht in Foren oder Wikis suchen müssen.

Okay, da hatte ich Dich missverstanden.
Ich gebe Dir natürlich Recht, in der commandref sollte natürlich möglichst alles lückenlos dokumentiert sein. Das werde ich nachbessern. Etwas zu programmieren ist Eins, das auch verständlich und möglichst komplett zu dokumentieren etwas ganz Anderes.
Das msg Beispiel ist gut, denn ich habe mich selbst auch darüber geärgert alle Informationen aus einem ellenlangen Thread heraussuchen zu müssen. Ich bekenne mich ja sozusagen als Fan von Loredos Modulen und hatte ihn da auch schon, leider vergebens, um Besserung gebeten.

Ich bin mir nur nicht sicher ob wirklich auch all die hier im ersten Beitrag genannten Beispiele zu den jeweiligen Attributen in die commandref sollten.
Das ist m.E. zu viel und schlecht wart- und erweiterbar da alles an mir liegen würde das zu pflegen.
Ich denke diesbezüglich wäre ein Wikieintrag, an dem alle mitwirken können, wesentlich sinnvoller.

Dafür habe ich die Funktion mal in dem Updateprozess bereitgestellt. 
Im Rahmen der Entwicklung und aktuellen Nutzung würdest Du damit sicherlich einige erreichen.

Wieder eine Stimme dafür.
Ich werde mich mal mit dem Prozess beschäftigen und meinen jahrelang vernachlässigten Github Account reaktivieren.
Von Update über Bugtracking bis Feature-Request ist das denke ich eine gute alternative Möglichkeit der Weiterverbreitung und -entwicklung.

Ein klares Jain   Ich stimme Dir voll und ganz zu, wenn es um die Übersichtlichkeit geht. Aber es ist die Philosophie / Stärke von FHEM, das man nur sehr wenig Vorgaben und Einschränkungen hat. Das gewählte Beispiel der Jahreszeiten ist vielleicht ein nicht so treffendes Beispiel. Hier wird es wohl eher kaum Abweichungen geben, da hast Du Recht. Es gibt aber sicherlich Konstanten die man individuell anpassen möchte. Ein Beispiel wären interne Timer oder Zeitfenster. Vielleicht möchte jemand "morning" nicht schon um 5 Uhr starten sondern erst um 7 Uhr.

Auch wenn es mehr Attribute werden, solltest Du den Schritt gehen. Dein Modul "beherbergt" ja nun viele Funktionen / Status und löst bestehende ab. Hier sollte dann nicht die Flexibilität verloren gehen.

Das klare Jain gefällt mir am Besten!
Ich werde mal schauen wie ich die "Transparenz-Schraube" noch etwas anziehen könnte.
Die Frage die sich mir hier stellt ist nicht ob, sondern wie man es am Besten konfigurierbar macht, so dass es vom Benutzer verstanden wird, aber auch programmtechnisch Sinn macht.
Vorschlag:
Beim Beispiel Tageszeiten könnte ich mir das innerhalb eines Attributes (damit nicht mehrere Attribute benötigt werden) so vorstellen dass die Tageszeiten vollkommen frei konfigurierbar wären in der Form "Text|Startzeit" und diese mit Leerzeichen voneinander getrennt werden, also etwa:

Code Auswählen Erweitern

attr HomeDaytimes Morgen|7:00 Vormittag|10:00 Mittag|12:30 Nachmittag|15:00 Vorabend|17:30 Abend|19:30 Nacht|23:00
Ich denke das könnte in dieser Form Sinn machen und verständlich sein.

Viele Grüße und weiter so

Viele Grüße zurück und danke für Dein tolles Feedback.
Ich werde mir weiterhin Mühe geben.

Gruß
Dan