gesucht Präsensmelder fürs Badezimmer

[Prof. Dr. Peter Henning]

Nun, die Alternative ist klar: Wer selber nichts beitragen möchte, bekommt auch keine Hilfe.

LG

pah

[Der_Tom]

Nun, die Alternative ist klar: Wer selber nichts beitragen möchte, bekommt auch keine Hilfe.

LG

pah

jetzt wird es lächerlich .... ich denke nicht das ich hilfe benötige und weiterhin habe ich mehr beigetragen als manch anderer !

gruss Thomas

edit: .... im übrigen würde mir eher die Zunge abfallen bevor ich in Forum noch nach Hilfe Fragen würde

[Damian]

Zum ursprünglichen Thema:

Ich mache das mit DOIF, für jeden Raum eins, da sich die Sensoren und Wartezeiten etc. jeweils unterscheiden. Beispiel für das Bad mit Dusche, ich hoffe die Devicenamen sind selbsterklärend:

Es ist natürlich mit entsprechendem Aufwand verbunden für jedes Zimmer ein Modul zu definieren und noch aufwendiger dauerhaft zu pflegen. Wenn sich dein Algorithmus aufgrund deiner Erfahrungen als weitgehend zuverlässig bewährt hat, dann kann man über Parametrisierung der veränderlichen Kenngrößen der Steuerung nachdenken und ein templatebasiertes Modul definieren. Hierbei gibt es nur eine zentrale generalisierte Steuerung - eine bestimmte Raumsteuerung wird dann durch ein einfaches Hinzufügen einer Parameterzeile definiert.

https://wiki.fhem.de/wiki/DOIF/Templates

[Prof. Dr. Peter Henning]

die Zunge abfallen

Ich habe noch niemanden gesehen, der hier im Forum die Zunge zum Formulieren einer Frage benutzt hätte 
Im Übrigen sollte man den Begriff "Modul" nur verwenden, wenn es den Modulrichtlinien von FHEM genügt - sonst ist es einfach eine Sammlung von Unterprogrammen.

Es ist natürlich mit entsprechendem Aufwand verbunden für jedes Zimmer ein Modul zu definieren

Wir hatten mal die Initiative, ein Modul zu definieren, mit dem man ohne großen Aufwand einen Zustandsautomaten definieren kann. Das wäre hier ein generischer Ansatz, ohne speziellen Code für jedes Zimmer - ich bin aber nicht im Bild über den aktuellen Stand.


LG

pah

[TomLee]

Im Übrigen sollte man den Begriff "Modul" nur verwenden, wenn es den Modulrichtlinien von FHEM genügt - sonst ist es einfach eine Sammlung von Unterprogrammen.

kopfschüttel


Hab es bisher nicht genutzt, bis vor kurzem (aus anderen Gründen, kann man nachlesen) hat sein Modul diesen Richtlinien noch genügt. Jahre.

[alanblack]

Ich habe noch niemanden gesehen, der hier im Forum die Zunge zum Formulieren einer Frage benutzt hätte 
Im Übrigen sollte man den Begriff "Modul" nur verwenden, wenn es den Modulrichtlinien von FHEM genügt - sonst ist es einfach eine Sammlung von Unterprogrammen.
Wir hatten mal die Initiative, ein Modul zu definieren, mit dem man ohne großen Aufwand einen Zustandsautomaten definieren kann. Das wäre hier ein generischer Ansatz, ohne speziellen Code für jedes Zimmer - ich bin aber nicht im Bild über den aktuellen Stand.

[Einmal OT bitte]
Der generische Zustandsautomat ist - nach letzter Lektüre vor wenigen Wochen - irgendwo zwischen Testumgebung und Erweiterung von DOIF hängen geblieben; leider. Schade, weil ich gehofft hatte, genau für diesem Anwendungzweck einen hier zu finden. Ich bin versucht, hier ein Modul im Sinne von FHEM zu bauen, komme aber aus Zeitmangel nicht weiter.

Allerdings ist dann das Eingabealphabet für Räume meist nicht sehr groß die Zustandsmenge mitunter aber schon - was "normale Benutzer" schon oft abhalten könnte.

Just my 2 cents!
[/OT]

[Der_Tom]

Ich habe noch niemanden gesehen, der hier im Forum die Zunge zum Formulieren einer Frage benutzt hätte 
Im Übrigen sollte man den Begriff "Modul" nur verwenden, wenn es den Modulrichtlinien von FHEM genügt - sonst ist es

wenn du hier die definierende instanz bist bin ich aber froh , das ich meine 3 "Sammlung von Unterprogrammen" vom Server hier entfernt habe

LG

.... gott sei dank bist du es nicht und wirst es wohl auch nie werden

[Prof. Dr. Peter Henning]

froh, dass ich meine 3 "Sammlung von Unterprogrammen" vom Server hier entfernt habe

Dem kann ich nur zustimmen, danke.

LG

pah

[Der_Tom]

Dem kann ich nur zustimmen, danke.

LG

pah

[Edit Amenophis86: Beleidigung gelöscht] , unfassbar. Ich bin dann mal wieder bedient

[Prof. Dr. Peter Henning]

Allerdings ist dann das Eingabealphabet für Räume meist nicht sehr groß die Zustandsmenge mitunter aber schon

Hmmm - das kommt auf die Definition typischer Tätigkeiten an. ich tendiere nicht zu der grobschlächtigen Beschreibung des Typs von oben, aber für ein typsches Badezimmer komme ich auf 4-5 Tätigkeiten plus einen Zustand "unspezifizierter Aufenthalt". Diesen letzten Zustand könnte man mit einer Zeitkonstante von 5 Minuten "zerfallen" lassen.

LG

pah

[peterk_de]

Es ist natürlich mit entsprechendem Aufwand verbunden für jedes Zimmer ein Modul zu definieren und noch aufwendiger dauerhaft zu pflegen. Wenn sich dein Algorithmus aufgrund deiner Erfahrungen als weitgehend zuverlässig bewährt hat, dann kann man über Parametrisierung der veränderlichen Kenngrößen der Steuerung nachdenken und ein templatebasiertes Modul definieren. Hierbei gibt es nur eine zentrale generalisierte Steuerung - eine bestimmte Raumsteuerung wird dann durch ein einfaches Hinzufügen einer Parameterzeile definiert.

https://wiki.fhem.de/wiki/DOIF/Templates

Hi Damian,

danke für den Tipp! Aber dazu wären, so ich die Templates auf die schnelle Überblicke, bei mir die Gemeinsamkeiten zwischen den einzelnen Raum-DOIFS ein bisschen zu gering, als dass ich dieses "Running System" dahingehend so massiv "touchen" würde Denn eigentlich ist nur cmd_1, der grundlegende Algorithmus und ein paar Attribute überall relativ gleich, der Rest ist wirklich extrem unterschiedlich und lässt sich schlecht verallgemeinern. Aber die Templates lösen ein anderes Problem was ich grad im Kopf habe, daher danke für den Hinweis, ich kannte sie tatsächlich noch nicht

LG!

[Damian]

Hi Damian,

danke für den Tipp! Aber dazu wären, so ich die Templates auf die schnelle Überblicke, bei mir die Gemeinsamkeiten zwischen den einzelnen Raum-DOIFS ein bisschen zu gering, als dass ich dieses "Running System" dahingehend so massiv "touchen" würde Denn eigentlich ist nur cmd_1, der grundlegende Algorithmus und ein paar Attribute überall relativ gleich, der Rest ist wirklich extrem unterschiedlich und lässt sich schlecht verallgemeinern. Aber die Templates lösen ein anderes Problem was ich grad im Kopf habe, daher danke für den Hinweis, ich kannte sie tatsächlich noch nicht

LG!

ja, es macht natürlich nur Sinn etwas zu generalisieren, wenn es mehr Gemeinsamkeiten, als Unterschiede aufweist.

Templates kann man übrigens nur im DOIF-Perlmodus nutzen. Wenn man die allerdings noch mit einer Visualisierung kombiniert, dann lässt sich mit gemeinsamen Parametern sowohl die Steuerung als auch ein passendes GUI mit jeweils einer Zeile (FOR-Befehl) für beliebig viele Szenarien generieren.

https://wiki.fhem.de/wiki/DOIF/Automatisierung 

[alanblack]

Hmmm - das kommt auf die Definition typischer Tätigkeiten an. ich tendiere nicht zu der grobschlächtigen Beschreibung des Typs von oben, aber für ein typsches Badezimmer komme ich auf 4-5 Tätigkeiten plus einen Zustand "unspezifizierter Aufenthalt". Diesen letzten Zustand könnte man mit einer Zeitkonstante von 5 Minuten "zerfallen" lassen.

Ich gebe Dir insoweit Recht, dass ein Bad über die Tätigkeiten eher kleine Zustandsmengen hat als andere Räume. Dennoch denke ich kommt es hier stark auf die Einstellung der Bewohner an. Es gibt Familien, da ist immer eine Person alleine im Bad - teilweise mit verschlossener Tür. Dann sind es recht wenige: Duschen, Baden, Toilettengang, Rasieren, Schminken... da fehlt nicht mehr viel, außer vielleicht noch eine Unterscheidung nach Tageszeiten oder Wochentagen. Mit morgens, tagsüber und abends sowie Werktag und Wochenende sind es gerade einmal gut dreißig Elemente. Der minimale endlich erkennende Automat (eeA) kommt dann vielleicht mit fünfzehn bis zwanzig aus.
In anderen Familien mit mehreren Personen kommen da mit "gemeinsame Dusche", "Rasieren+Toilettengang",... noch einige Kombinationen zu. Wenn dann wegen Schichtarbeit oder Wochenendarbeit nicht nur nach Zeiten und Tagen unterschieden werden kann, hat die Zustandsmenge schnell ein reichlich dreistellige Mächtigkeit. Der minimale eeA ist dann auch hier schon nicht mehr trivial.
Die Tätigkeiten oder gar die Kombinationen daraus in FHEM automatisch zu erkennen, ist mit den vorhandenen Sensoren (Bewegung, Tür, Fenster, Luftfeuchte, Druck) noch ein ganz anderes Problem.
Aber ein eeA ist für eine Zustandsmenge mit sechs Elementen auch eher "oversized". 

[Prof. Dr. Peter Henning]

Ich räume ja gerne ein, dass "gemeinsame Dusche" etwas länger dauern kann - das ist bei uns auch so  .

Aber die Frage "Licht an" oder "Licht aus" würde ich nun nicht davon abhängig machen, ob eine, zwei oder mehr Personen unter der Dusche stehen, hier wäre also eine Zusammenfassung in Zustandsklassen möglich.

Außerdem ist es möglich, einen hybriden Automaten zu definieren und mit bedingten Zustandsübergängen zu arbeiten - damit ließen sich externe Parameter, wie "Wochentag" etc. einbinden. Eine Google-Suche "zustandsautomaten mit bedingten übergängen" liefert dazu eine ganze Menge gut verständlicher Erklärungen.

Aber ein eeA ist für eine Zustandsmenge mit sechs Elementen auch eher "oversized"

Finde ich nicht. Anbei eine Abbildung aus den SmartHome Hacks

LG

pah

[maci]

Habe den Beitrag mit Interesse gelesen, denn ich stand auch vor einem ähnlichem Problem.
Bei ging es zwar nicht um Licht an oder aus, sondern um Rollade auf oder zu lassen.
Das Problem war, dass ich meine Rolladen eine bestimmte Zeit nach Sonnenaufgang öffne. Natürlich über Fhem gesteuert. Da ist auch der Bad Rolladen dabei.
Nun war einmal das Problem, dass meine Frau mal später aufgestanden ist. Sie hat das Licht aufgedreht und war dann am WC. Genau in dieser Zeit hat sich dann der Rolladen geöffnet.
Sie hat sich dann bei mir beschwert, weil sich der Rolladen geöffnet hat, während sie am WC war und das Licht an war.

Also suchte ich nach einer Lösung. Die erste Maßnahme war mal die Zeit zu verschieben. Die Automatik komplett rausnehmen wollte ich nicht, denn meine Frau hat sich schon daran gewöhnt, dass die Rolladen automatisch auf und zu gehen.

Meine Lösung bestand nun daran, dass ich den Rolladen an das Licht, das normal mechanisch geschaltet wird zu koppeln.
Ich habe dieses Problem mit einer Shelly gelöst. Lichtschalter schaltet Shelly, dieser schaltet dann das Licht.
Die Shelly meldet dies an Fhem.
Nun ist es so, wenn Licht an, bleibt Rollade wie er ist. Erst 30 sec. nach Licht aus, öffnet dieser.
Die Shelly konnte ich in der Schalterdose unterbringen.