Rolladen-Funk-Aktor mit Gedächtnis?

[Beta-User]

(@Otto, sorry, hat sich in Teilen überschnitten; ansonsten: Geduld... )

Ok, deine Erläuterungen machen die Wirkung klar, aber den Sinn kann ich dahinter nicht sehen.

Mein Eindruck: du "denkst" immer noch in Abfrage statt in Event.

Ich habe noch keine Idee, wie ich dir ggf. den Unterschied klarmachen soll und empfehle mal folgendes: Mach einfach bei allen Aktionen, die du an FHEM ausführst nebenbei ein weiteres Browserfenster mit dem Event-Monitor (siehe auch https://wiki.fhem.de/wiki/Event_monitor) auf und beobachte, was da passiert. Falls es zu viel ist, schränke das ganze auf die für dich grade relevanten Geräte ein (devspec, siehe auch unten).

Gibt es eine Möglichkeit mit einem Notify oder anderem Modul beide Trigger und beide Bedingungen in einem Befehl unterzubringen?
Also nach dem Motto "Wenn Ereignis 1 oder Ereignis 2 eintritt, dann schalte, wenn Bedingung "a" und Bedingung "b" erfüllt sind, das zugehörige Licht ein. Eventuell auch mit einem DOIF.

Ja, man kann das machen.

Hier mal die DEF von einem notify, das auf 3 verschiedene Taster/Ereignisse hört und den eigentlichen set-Befehl nur ausführt, wenn eine Bedingung erfüllt ist:

Code Auswählen Erweitern

Licht_Bad_Spiegel:on|Taster_SZ_Btn_06:short|Taster_Spuele:6004 { fhem("set MYSENSOR_96 status1 on") if ReadingsVal("MYSENSOR_96","temperature21","20") < 35 }
ad b)
Die Bedingungen (und der auszuführende Code) lassen sich auch bei notify beliebig erweitern, dafür braucht man kein DOIF. 
Dazu vielleicht noch eine Anmerkung: ich würde empfehlen, erst die Denkweise von FHEM allgemein zu verstehen. Das geht einfacher, wenn man erst mal nur "Rudi's Kernmodule" intensiver anschaut, und auch etwas Perl-Übung kann nicht schaden, bevor du dich mit allen möglichen anderen Modulen beschäftigst. Grade DOIF ist "schiwerig", weil es - je nachdem, wie bestimmte Attribute gesetzt sind oder die DEF gestaltet ist - entweder "pure Event-basiert" wie notify arbeitet oder eher als "state machine". Letzteres scheint da der default zu sein und käme deiner "Abfrage-Denkweise" entgegen, aber nochmal: Ohne grundlegendes Verständnis, wie FHEM "eigentlich tickt", wirst du früher oder später dann doch darüber stolpern, dass nicht das passiert, was du erwartest...

ad a) das mit dieser Kombi von mehreren möglichen Events von mehreren Geräten ist, was devspec meint. Das klappt an vielen Stellen in FHEM und wäre z.B. auch was für den Event-Monitor. "Gute" FHEM-regex für notifyfn-Geräte wäre mit notifyRegexpCheck() zu überprüfen, siehe den betreffenden Unterabschnitt in https://svn.fhem.de/fhem/branches/epdf2020/frame.adoc#_perl_regex_und_co

Und zweitens einige Fragen zu Watchdog:
Verstehe ich es richtig, dass wenn Regexp 1 eintritt, der Befehl erst ausgeführt wird, wenn innerhalb der angegebenen Zeit nicht der Regexp2 eintritt?

Genau das ist es, was ganz allgemein in der IT unter einem watchdog verstanden wird, siehe auch https://de.wikipedia.org/wiki/Watchdog

Was ist wenn Regexp1 innerhalb der Zeit noch einmal eintritt?

Das Verhalten ist einstellbar. Siehe commandref:

Code Auswählen Erweitern

regexp1WontReactivate
Wenn ein Watchdog aktiv ist, wird ein zweites Ereignis das auf regexp1 passt normalerweise den Timer zurücksetzen. Dieses Attribut wird das verhindern.

Kann man den Trigger des Watchdog auch mit einem "externen" Notify zurücksetzen?

Ich würde das anders formulieren: Man kann den Watchdog durch passende FHEM-Anweisungen zurücksetzen, aktivieren, ...
("Dooferweise" ist es sogar so, dass man nach dem Auslösen entscheiden muß, ob man ihn gleich wieder aktivieren will. Das ist die "komische Sache mit dem Punkt".)
Insgesamt ist es so, dass Rudi bei seinen Modulen in der Regel eine sehr knappe commandref liefert, die aber die wesentlichen Prinzipien sehr klar rausarbeitet, (jedenfalls, wenn man die entsprechend liest und v.a. auch die Abschnitte über devspec und Perl immer gedanklich dazu parat hat oder nochmal ansieht). https://fhem.de/commandref_modular_DE.html#watchdog hat ausgedruckt vermutlich nur ca. 1 A4-Seite. Bitte daher jetzt nochmal kritisch gegenlesen .

[MarkoP]

@Otto123
Sorry, 3x gelesen und doch nicht verstanden bzw. überlesen. Mit dem Hintergrundwissen von Beta-User habe ich es jetzt auch verstanden, aber vorher eben nicht.

@Beta-User

auch die Abschnitte über devspec und Perl immer gedanklich dazu parat hat oder nochmal ansieht

Das ist genau das Problem das ich habe. Es gibt so viele Querverweise und Dokumentquellen, dass ich es einfach oft nicht raffe, egal wie oft ich es lese. Deine Infos gespickt mit Erläuterungen sind drei mal verständlicher für mich. Das Problem ist einfach, dass man von Hölzchen auf Stöckchen springt da oftmals auf andere Module verwiesen wird oder Querverweise existieren. Fhem ist halt einfach extrem variable und umfangreich. Wenn man einmal den Einstieg geschafft hat, ist es sicherlich verständlich, aber am Anfang eine wahre Katastrophe.

Das mit dem Event ist mir schon klar, ich gehe nur eben davon aus, dass ich nur auf eine Veränderung reagieren will. Meiner Denkweise nach bringt es nichts dutzende Male den gleichen Wert zu bearbeiten. In einer Metapher gesprochen: Es bringt mir nichts wenn ich hundert mal nachschaue ob eine Motto aus ihrem Kokon geschlüpft ist, erst wenn es passiert ist muss ich die Fliegenklatsche holen 
Ich will damit sagen, es macht ja nur Sinn auf Veränderungen zu reagieren und nicht auf "Nicht Veränderungen".

Aber ich glaube das spielt auch keine Rolle, ich verstehe jetzt beide Anwendungsfälle und welche Konsequenzen die jeweiligen Einstellungen haben. Kann sein, dass ich den heutigen Ansatz nächsten Monat aufgrund von neuem Wissen ändere. Das ist ja bei jeder Weiterentwicklung so - und dazu zählt für mich auch das Lernen. Im Moment jedoch versuche ich erstmal einfach nur die Events bei allen Devices aufs Notwendigste zu reduzieren um den Überblick nicht zu verlieren und da hilft die Einschränkung auf reine "Changes" schon sehr gut. In dem Zusammenhang suche ich auch eine Möglichkeit die Polling-Abfrage an meine Fritzbox zu unterdrücken, da es auch eine erhebliche Menge an Events sind und ich die Häufigkeit aus anderen Gründen nicht reduzieren kann. Beim Polling nützt ja das event-on-change-reading nichts.

Zurück zum Problem mit dem Shelly:
Bei einem notify sehe ich das Problem, dass ich die Dauer der Pausierung nicht vorhersehen kann. Ich weiß ja nicht wann ich am nächsten Morgen aufstehe.
Ich könnte also höchstens mit einem watchdog prüfen ob auf die Abschaltung der Leistungsaufnahme innerhalb einer gewisssen Zeit wieder eine Leistungsaufnahme einsetzt. Doch dabei ist a) auch hier die Zeit ein das Problem und b) die Tatsache, dass das Kommando dann erst nach der Wartezeit ausgeführt wird.
Als Beispiel: Das Handy liegt auf der Ladeschale und hat nur Erhaltungsstrom, also abwechselnd in max. 2 Minuten Intervallen (soweit ich das aus dem Logfile erkennen konnte) 0W und ca. 2,25W. Damit der Watchdog in diesem Zustand nicht auslöst, müsste ich also im Regexp1 die 0W erkennen und mit einer Zeitangabe von 2 Minuten und zweiten Regexp ein größer 1W (da ich nicht weiß ob  die 2,25W vielleicht doch mal geringer ausfallen) angeben. Dabei entsteht aber dann das Problem, dass wenn ich das Handy von der Ladeschale nehme, die Leistungsaufnahme also dauerhaft auf 0W gesetzt wird, der Watchdog erst die 2 Minuten abwartet ob wieder eine Leistungsaufnahme einsetzt ehe das Kommando ausgeführt wird. Es würde also nach dem herunternehmen des Handys 2 Minuten nichts passieren. Oder habe ich etwas falsch verstanden?

Mit dem angesprochenen SVG-Plot wollte ich die Zeit zwischen den Leistungswechseln genauer einschränken. Das ist im Log aufgrund der vielen anderen Werte ziemlich schwer.

Mein Lösungsansatz wäre eventuell so:
Ein Notify das erkennt, dass die Leistungsaufnahme größer 4W ist (normaler Lademodus) und dann ein zweites Notify, das die Reduzierung der Leistungsaufnahme unter 3W triggert,  für ca. 6 Stunden deaktiviert.
Innerhalb dieser 6 Stunden sollte das Handy vom normalen Laden aus die 100% erreicht haben und in den Erhaltungsmodus (also den Wechsel zwischen 0W und 2,5W) gewechselt haben und das hin und her wechseln doch eigentlich nicht mehr als Event betrachten.

Alternativ dazu fällt mir nur die Kombination aus Leistungsaufnahme und Temperatur des Aktors ein. Dabei muss ich aber erst mal eine Auswertung der Temperatur ansehen. Habe nur wahrgenommen, dass diese nicht so oft wechselt wie die Leistungsaufnahme.

[Beta-User]

  FHEM folgt halt einfach einem der wesentlichen Grundgedanken von Perl:  TIMTOWTDI (https://de.wikipedia.org/wiki/Perl_(Programmiersprache)#Mehrere_Wege). Daher gibt es eben nicht den einen Weg, das macht es unübersichtlich.

Daher auch der Versuch von meiner Seite, das irgendwie (wieder) etwas mehr "der Reihe nach" zu erläutern bzw. im Gesamtzusammenhang. Es war aber schon immer so, dass man nicht mit einem Mal Einsteigerdoku lesen weit gekommen ist. Ich habe das "Einsteiger-pdf" von UliM auch bestimmt 10x oder mehr gelesen bzw. immer wieder zur Hand genommen.
Heute schaue ich am liebsten erst mal im "Rahmen" der commandref_modular, was da steht. Die habe ich bestimmt schon 20x durch, in Auszügen sicher ein Vielfaches davon. Da stehen die Grundzüge drin, und immer, wenn man den Wald vor Bäumen ... sollte man genau das wieder zur Hand nehmen. (nur meine Meinung).

Und die Doku ist keine "Katastrophe", sondern vermutlich einfach adäquat komplex zu den Möglichkeiten, die man mit FHEM hat. (Außerdem: Wer motzt, muß beweisen, dass er es besser kann ).

Das mit dem Event ist mir schon klar, ich gehe nur eben davon aus, dass ich nur auf eine Veränderung reagieren will.

Das ist oft richtig, aber bei weitem nicht immer: Ich will auch gleichbleibende Temperaturwerte früher oder später in meinen Logs haben, also werde ich die Events nicht alle unterdrücken. (Basta! Ach so, das sollte man ggf. noch klarstellen: FileLog bzw. DBLog sind auch Event-Handler, die darauf angewiesen sind, dass Events kommen. Sonst wird eben nicht reagiert, also in diesen Fällen: keine Daten aufgezeichnet...)

Im Falle eines notify (es handelt sich dem Namen nach um eine BENACHRICHTIGUNG) kann man immer noch prüfen, ob (und ggf. wie) denn reagiert werden soll, weil (k)eine Änderung vorliegt. Ggf. kann man sich auch an dem Device den vorigen Wert merken (Stichwort: OldReadings) und dann den aktuellen mit dem vorigen Wert vergleichen (oder userReadings mit Trends oä. definieren, mal wieder  TIMTOWTDI).

Meiner Denkweise nach bringt es nichts dutzende Male den gleichen Wert zu bearbeiten. In einer Metapher gesprochen: Es bringt mir nichts wenn ich hundert mal nachschaue ob eine Motto aus ihrem Kokon geschlüpft ist, erst wenn es passiert ist muss ich die Fliegenklatsche holen 
Ich will damit sagen, es macht ja nur Sinn auf Veränderungen zu reagieren und nicht auf "Nicht Veränderungen".

Es kommt immer darauf an. watchdog kennt z.B. SAME, mit sequence kann man auch entscheiden, dass man 3x denselben Tastendruck haben muß, damit ein weiteres Event ausgelöst wird, ...

TIMTOWTDI eben!

Daher meine Bitte: Du darfst deinen Weg gerne finden, aber für's erste halte dich mit pauschalen Lösungen zurück und betrachte insbesondere "eocr .*" nicht als die ultimative Lösung aller eventuellen Verständnisprobleme. Wohldosiert eingesetzt ist es hilfreich, aber ich habe z.B. trotz CUL_HM-Verwendung erst bei meinen jüngsten Überarbeitungen (v.a. wg. dieser bescheuerten "ich sende immer alles"-MQTT-firmwares) verstärkt Gebrauch von eocr&Co gemacht. Geht auch (häufig) ohne...

In dem Zusammenhang suche ich auch eine Möglichkeit die Polling-Abfrage an meine Fritzbox zu unterdrücken, da es auch eine erhebliche Menge an Events sind und ich die Häufigkeit aus anderen Gründen nicht reduzieren kann. Beim Polling nützt ja das event-on-change-reading nichts.

Kapiere ich nicht. eocr hat mMn. dieselbe Auswirkung, ob das Device jetzt von sich aus sendet oder du die betreffenden Werte in einem polling-Verfahren abholst. (Falls du das Polling-Intervall an der Fritte hochgedreht haben solltest: Überlegen, ob das eine gute Idee war... Grundsätzlich wäre meine Empfehlung, an irgendwelchen defaults nur dann was zu ändern, wenn du wirklich (!!!) sicher bist, dass das eine gute Idee ist. Wieder nur meine 2ct.)

Zurück zum Problem mit dem Shelly:
Bei einem notify sehe ich das Problem, dass ich die Dauer der Pausierung nicht vorhersehen kann. Ich weiß ja nicht wann ich am nächsten Morgen aufstehe.

(Sollten wir hier nicht vertiefen, aber bei einem entsprechend gestellten Wecker würdest du ggf. wissen können, wann du planst aufzustehen und dann erst den betreffenden Code um diese Zeit herum scharf schalten...)

Ich könnte also höchstens mit einem watchdog prüfen ob auf die Abschaltung der Leistungsaufnahme innerhalb einer gewisssen Zeit wieder eine Leistungsaufnahme einsetzt. Doch dabei ist a) auch hier die Zeit ein das Problem und b) die Tatsache, dass das Kommando dann erst nach der Wartezeit ausgeführt wird.

Genau. Aber grundsätzlich kannst du mit der Methode immer erst nach Ablauf der (längsten) Frist für das Einschalten des Erhaltungsstroms wissen, ob das Handy denn nun noch/wieder auf der Ladeschale liegt oder nicht. (Hatte da nicht jemand schon sehr früh darauf hingewiesen, dass er das für eine zweifelhafte Methode hält...? )

Kurz: Mit gewissen Restrisiken wirst du immer leben müssen, und wenn es ausschließlich die Ladeschale sein soll, dann führt mMn. kein Weg an einem entsprechenden Delay vorbei. Ist bei der Fritte mit WLAN-Presence übrigens auch nicht anders, es wirkt nur ggf. nicht so...
"Besser" wird das ganze nur dann, wenn du entweder weitere Events auswertest ("oh, da hat jemand das Licht in der Küche angemacht, und der Ladestrom ist 0? Da scheint jemand aufgestanden zu sein....")

Mit dem angesprochenen SVG-Plot wollte ich die Zeit zwischen den Leistungswechseln genauer einschränken. Das ist im Log aufgrund der vielen anderen Werte ziemlich schwer.

Mit der passenden Regex und/oder einem 2. Log kann man das umgehen, oder das Log mit grep (auf der Linux-Kommandozeile) auf die relevanten Daten reduzieren?

Mein Lösungsansatz wäre eventuell so:
Ein Notify das erkennt, dass die Leistungsaufnahme größer 4W ist (normaler Lademodus) und dann ein zweites Notify, das die Reduzierung der Leistungsaufnahme unter 3W triggert,  für ca. 6 Stunden deaktiviert.
Innerhalb dieser 6 Stunden sollte das Handy vom normalen Laden aus die 100% erreicht haben und in den Erhaltungsmodus (also den Wechsel zwischen 0W und 2,5W) gewechselt haben und das hin und her wechseln doch eigentlich nicht mehr als Event betrachten.

Kapiere ich auch nicht. Dass die ca. 2.5W (oder allgemeiner: irgendwas anderes wie 0W) gemeldet werden, ist doch grade der Indikator, dass das Handy noch auf der Ladeschale ist? Erst wenn das länger nicht der Fall ist, ist das Handy woanders (ergo der Bewohner aufgestanden).

Aber evtl. verstehe ich das Problem nicht oder falsch...

[TomLee]

Hallo,

sind das Android oder IOS Handys ? Erhaltungsmodus lässt Android vermuten ?

Es gibt das Modul AMAD für Android-Geräte, welches das Reading powerPlugged bereitstellt (Netzteil angeschlossen oder nicht).

Hab keine QI-Ladeschalen und weiß nicht wie sich das Reading dann verhält (ob das vom USB-Anschluss abhängig ist), aber wenn genauso, dann gäbe es ein Event beim auflegen und abnehmen des Handy, das mit der Leistungsmessung wie ich es bisher mit einem Auge verfolgt habe obsolet oder nicht ?

Kann mit meiner Vermutung aber auch schlicht daneben liegen so genau hab ich nicht alles verfolgt ?

Gruß

Thomas

[Prof. Dr. Peter Henning]

@TomLee: So ist es. Mit AMAD kann man wunderbar überprüfen, ob das Handy geladen wird (Reading powerPlugged).

@MarkoP: Was ist denn der Use Case dafür, einen Rollladen (bitte mit drei "l", sonst schmerzen meine Augen) durch einen Ladestrom zu steuern? Mir scheint das ganze System viel zu kompliziert für einen Anfänger zu sein. Wenn man so etwas aufbaut, kommt man um die Programmierung eines Zustandsautomaten nicht herum. Das geht zwar mit ein paar Zeilen in Perl, aber man muss wenigstens verstehen, was man tut. In den SmartHome Hacks habe ich mehrere Beispiele für solche Zustandsautomaten beschrieben, alle nutzbar für FHEM.

Das mit den Qi-Ladeschalen ist eine Sackgasse, weil man eben nicht kontrollieren kann, wie irgendeine chinesische Hinterhoffirma das mit den Erhaltungsladungen löst. Im Standard steckt das auch nicht drin.

Finally:

Und die Doku ist keine "Katastrophe", sondern vermutlich einfach adäquat komplex zu den Möglichkeiten, die man mit FHEM hat. (Außerdem: Wer motzt, muß beweisen, dass er es besser kann ).

Stimmt. Darum habe ich ja auch schon zwei Bücher darüber geschrieben...

LG

pah

[MarkoP]

Also erst mal mit Katastrophe meinte ich nicht den Aufbau, sondern das es einfach unübersichtlich und zu viel mit zu vielen Querverweisen ist für Neulinge.

Vielleicht mal zu meiner Idee und einigen Anwendungsfällen die mir vorschweben:

• Beim Aufstehen - also dem Abnehmen des Handys von der Ladeschale - geht ein "Nachtlicht" an, um der Person den Weg zu weisen (da sind die 2 Minuten Wartezeit für den Regexp2 des Watchdog das Problem).
• Die Heizung soll hochfahren sobald ein Handy getrennt wird (Hier sollte der Effekt wieder umgehend ausgelöst werden)
• Wenn ALLE Bewohner aufgestanden sind, soll der Rollladen hoch gehen (Hier wäre eine Verzögerung ja akzeptabel).

@Beta-User

Falls du das Polling-Intervall an der Fritte hochgedreht haben solltest

Ja habe ich, da sonst die Anwesenheitserkennung nicht wirklich funktioniert. Normal sind für die Abfrage ja 5 Minuten. Damit schneller registriert wird wenn jemand das Haus verlässt (und damit ggf. später eine Alarmanlage scharf schaltet) habe ich das Intervall auf 1 Minuten herabgesetzt. Ich versuche meine Programmierungen ja direkt so zu gestalten, dass ich spätere Zusatzsachen direkt mit abdecken kann ohne dann alles umzuprogrammieren.

Sollten wir hier nicht vertiefen, aber bei einem entsprechend gestellten Wecker würdest du ggf. wissen können, wann du planst aufzustehen und dann erst den betreffenden Code um diese Zeit herum scharf schalten...

Klar weiß ich das für den nächsten Tag, aber durch WE, Urlaub, HomeOffice etc. ändert es sich von Tag zu Tag und ich kann somit auch kein stabiles Wochenschema "programmieren". Ich müsste es jeden Tag anpassen was nicht sinnvoll ist.

Kapiere ich auch nicht. Dass die ca. 2.5W (oder allgemeiner: irgendwas anderes wie 0W) gemeldet werden, ist doch grade der Indikator, dass das Handy noch auf der Ladeschale ist? Erst wenn das länger nicht der Fall ist, ist das Handy woanders (ergo der Bewohner aufgestanden).

Das liegt daran, dass ich hier einen Denkfehler hatte. Ich bin vom Gegenteiligen Effekt beim Schlafengehen ausgegangen, der entsprechend umgekehrt schalten soll, also Licht aus, Rollladen zu etc.. Mein ursprünglicher Denkansatz war durch die Unterscheidung der 2,5W und der 4W eben auch zwischen aktiver Ladung und Erhaltungsladung zu differenzieren. So dass die 2,5W ignoriert werden, da ansonsten das Event fürs Zubettgehen jedes mal ausgelöst wird wenn von 0W auf 2,5W gewechselt wird.

@TomLee
Ist ein Samsung, also angepasstes Android. AMAD habe ich probiert, bekomme es aber leider nicht ans laufen. Liegt wahrscheinlich an meiner Konstellation mit dem Docker im NAS. Jedenfalls hat es mir immer mit der Verbindung zum Server bzw. dem Port Probleme gemacht.

@Prof. Dr. Peter Henning

Das mit den Qi-Ladeschalen ist eine Sackgasse, weil man eben nicht kontrollieren kann, wie irgendeine chinesische Hinterhoffirma das mit den Erhaltungsladungen löst. Im Standard steckt das auch nicht drin.

Das Problem ist ja nicht die "Hinterhoffirma" aus China (keine Ahnung woher Sie diese Info beziehen), sondern Samsung, die die Erhaltung des Ladestroms nicht kontinuierlich sondern in einer Intervalllösung umgesetzt haben.

[Beta-User]

Also erst mal mit Katastrophe meinte ich nicht den Aufbau, sondern das es einfach unübersichtlich und zu viel mit zu vielen Querverweisen ist für Neulinge.

"Zu viel Querverweise" ist relativ. Sicher ist der Einstieg in FHEM nicht einfach. Das war er bereits vor Jahren nicht, und mit der zunehmenden Zahl von Modulen und Lösungen für "alles mögliche" ist es auch nicht einfacher geworden. Aber andere haben das auch geschafft, (andere haben aus guten Gründen aufgegeben), es ist also nicht "zu viel", sondern möglich. Wenn es dir "zu viel" ist, solltest du über aufgeben nachdenken.

Meine Einschätzung: Du willst "zu viel auf einmal" und versuchst daher, die ersten Schritte "zu schnell" zu gehen. (Es ist etwas besser geworden, aber das Nachdenken über einzelne Aspekte ist immer noch deutlich verbesserungsfähig, und du solltest auch die bereits gegebenen Hinweise häufiger lesen).

Vielleicht mal zu meiner Idee und einigen Anwendungsfällen die mir vorschweben:

   
• Beim Aufstehen - also dem Abnehmen des Handys von der Ladeschale - geht ein "Nachtlicht" an, um der Person den Weg zu weisen (da sind die 2 Minuten Wartezeit für den Regexp2 des Watchdog das Problem).
• Die Heizung soll hochfahren sobald ein Handy getrennt wird (Hier sollte der Effekt wieder umgehend ausgelöst werden)
• Wenn ALLE Bewohner aufgestanden sind, soll der Rollladen hoch gehen (Hier wäre eine Verzögerung ja akzeptabel).

Wenn du eine unmittelbare Reaktion brauchst, ist die Methode (nur) mit der Ladeschale untauglich. Die liefert nur ein Indiz, nicht mehr, aber auch nicht weniger.
Ergo: Arbeite (erst mal) mit einem Taster und stelle den Status der Bewohner damit um, und zwar erst mal dadurch, dass der betreffende Taster auch eindeutige Events liefert, die du nicht weiter interpretieren mußt (oder für Fortgeschrittene: einer Gewichtserkennung an der Ladeschale oder dem Bett, einer Infrarotkamera, ...).

... habe ich das Intervall auf 1 Minuten herabgesetzt...

Auch hier nochmal: defaults haben ihren Sinn, daher solltest du das ganze erst mal einfacher halten, also z.B. einen Taster neben dem Ausgang verwenden, der die Alarmanlage scharf schaltet (später: es gäbe auch andere Lösungen, z.B. BT-Tags oder geofancy, oder ... aber erst mal einfach anfangen. Und für die Konsolidierung mehrerer Bewohner wäre dann wieder RESIDENTS eine Vereinfachung, aber das hast du ja bereits mehrfach ignoriert, weil du unbedingt gleich die Welt insgesamt neu erfinden willst...).

...Ich müsste es jeden Tag anpassen was nicht sinnvoll ist.

Auch hier: AMAD (?) müßte in der Lage sein, einen gestellten Android-Wecker an FHEM zu melden, es gibt Möglichkeiten, Kalender (auch für Abwesenheiten) auszuwerten, und und und.... Geht dann alles ggf. automatisch, aber eben nicht am ersten Tag (oder dem 10.).

Das Problem ist ja nicht die "Hinterhoffirma" aus China (keine Ahnung woher Sie diese Info beziehen), sondern Samsung, die die Erhaltung des Ladestroms nicht kontinuierlich sondern in einer Intervalllösung umgesetzt haben.

Das Problem ist eher, dass es für diese Art Equipment eben noch keine wirkliche Musterlösung gibt und du unbedingt versuchen willst, eine neue Lösung aus dem Boden zu stampfen, ohne die grundlegenden Mechanismen soweit verstanden zu haben, dass ein solches Unterfangen wirklich Sinn macht. (qed)

[MarkoP]

Grundsätzlich: Ich gebe NIEMALS auf! Ich brauche höchstens länger.

Das mit dem zu viel wollen mag sein, ich habe bestimmte Vorstellungen und Ziele die ich Stück für Stück umsetzen will. Vielleicht lassen Sie sich nicht in der geplanten Reihenfolge abarbeiten oder bedürfen mehr Zeit als geplant, aber das heißt nicht, dass ich sie aus dem Auge verlieren darf/will. Dazu zählen auch Zwischenlösungen wie von dir mit dem Schalter genannt. Sicher ist es richtig, erst mal simple anzufangen, aber wenn man weiß, das diese Zwischenlösung mit den späteren Zielen nicht vereinbar ist... . Es ist im Prinzip das gleiche wie mit dem generischen Aufbau der einzelnen Devices/Notifys etc., da lehnst du doch gerade den Dummy (also den Zwischenschritt) ab. Ein späteres umbauen ist ja auch in der Regel wesentlich aufwendiger als vorher zu überlegen und auszutesten.

Und auch wenn es für dich so aussieht als wenn ich etwas ignoriere, dann kann ich dir versichern, dass dem nicht so ist. Ich bewerte alles gelesene für mich und beurteile den Nutzen. Und wenn ich das mit den Notify's nicht sauber kapiere, was nutzt es mir dann mit RESIDENTS oder anderen Modulen anzufangen. Völlig davon abgesehen, dass ich es mir gar nicht leisten kann mal eben so einen Taster zu kaufen und den irgendwo hinzuhängen, immerhin kostet ein Taster mal schnell 50-70€. Ich habe in den letzten 5-6 Monaten bereits mehr als 1000€ für die Automation ausgegeben, irgendwann muss ich das auch mal eingrenzen.

Auch hier: AMAD (?) müßte in der Lage sein, einen gestellten Android-Wecker an FHEM zu melden, es gibt Möglichkeiten, Kalender (auch für Abwesenheiten) auszuwerten, und und und.... Geht dann alles ggf. automatisch, aber eben nicht am ersten Tag (oder dem 10.).

Das mag ja alles sein, nur was nützt mir ein Tool/Modul, dass den Wecker auslesen kann wenn es nicht funktioniert/läuft? Was denkst du warum habe ich mich mit AMAD beschäftigt? Aus Spaß? Es gibt auch einen eigenen Threat ohne endgütige Problemlösung.

Ich will nichts zwingend aus dem Boden stampfen, da schätzt du mich völlig falsch ein. Ich muss nur einfach mit den Mitteln arbeiten, die ich habe. Ich kann nicht mal eben so einen neuen Schalter oder gar was noch teureres wie eine Infrarotkamera kaufen. Ich bin auf das angewiesen was ich besitze und leisten kann, und dazu zählt nun mal einfach, dass ich nicht ständig neue Sachen kaufen kann.

Bitte verstehe das nicht falsch. Ich habe nur eben nicht unendlich viele Aktoren/Sensoren rumliegen und möchte auch nicht nach einem halben Jahr alles neu machen was ich jetzt mühsam erarbeitet habe obwohl ich weiß, dass es später nicht funktioniert.

[Beta-User]

Grundsätzlich: Ich gebe NIEMALS auf! Ich brauche höchstens länger.

Willkommen im Club!
(wobei ich auch schon Zeug wieder auf die Seite gelegt habe, weil es mir zu kompliziert war oder ich nicht die Zeit gefunden hatte, mich ausgiebig damit zu beschäftigen oder es sich rausgestellt hat, dass es bessere/einfachere/billigere Lösungen für das angedachte Problem gab....).

Das mit dem zu viel wollen mag sein, ich habe bestimmte Vorstellungen und Ziele die ich Stück für Stück umsetzen will. Vielleicht lassen Sie sich nicht in der geplanten Reihenfolge abarbeiten oder bedürfen mehr Zeit als geplant, aber das heißt nicht, dass ich sie aus dem Auge verlieren darf/will.

Behalte das mit der Zeit im Auge!
Und achte eher auf "das große Ganze", das Beharren auf Detaillösungen, in die du ggf. schon viel Zeit und Geld investiert hast ist uU. kontraproduktiv.

Dazu zählen auch Zwischenlösungen wie von dir mit dem Schalter genannt. Sicher ist es richtig, erst mal simple anzufangen, aber wenn man weiß, das diese Zwischenlösung mit den späteren Zielen nicht vereinbar ist... . Es ist im Prinzip das gleiche wie mit dem generischen Aufbau der einzelnen Devices/Notifys etc., da lehnst du doch gerade den Dummy (also den Zwischenschritt) ab. Ein späteres umbauen ist ja auch in der Regel wesentlich aufwendiger als vorher zu überlegen und auszutesten.

Die Frage ist aber immer, wie leicht sich Zwischenlösungen wieder in die richtige Richtung weiterentwickeln lassen. Den späteren Umbau im Auge zu haben, ist dabei wichtig. Dass eine einfache Taster-Event-Auswertung statt einer hieraus entwickelten Vielfach-Event-Eventauswertungs-Orgie irgendwie später im Weg sein könnte, erschließt sich mir nicht, von daher ist der Vergleich mit "dummy" aus meiner Sicht kontraproduktives "Äpfel mit Birnen-Bewerfe".

Du wirst viele Stellen finden, an denen du erst mal Grundzüge entwickelst und das dann später verfeinerst.

Und auch wenn es für dich so aussieht als wenn ich etwas ignoriere, dann kann ich dir versichern, dass dem nicht so ist. Ich bewerte alles gelesene für mich und beurteile den Nutzen. Und wenn ich das mit den Notify's nicht sauber kapiere, was nutzt es mir dann mit RESIDENTS oder anderen Modulen anzufangen.

Wenn du Bewohner-Status-Infos direkt mit RESIDENTS "abfackelst", wirst du später feststellen, dass sich viele Elemente relativ natlos ineinanderfügen. Nutzt du stattdessen eine eigene dummy-basierte Logik, wirst du früher oder später an der Stelle genau das machen, wovor du dich fürchtest: Umbauen.

Du darfst mir glauben, dass ich nicht ohne Grund einerseits die Empfehlung gebe, in der Modulauswahl erst mal sehr beschränkt vorzugehen, andererseits aber an der einen oder anderen Stelle dann doch genau den "Spezialisten" einzusetzen, den es dafür gibt.
Oder willst du mir unterstellen, ich würde dich absichtlich (zu sehr) in die Irre führen? (An der einen oder anderen Stelle macht es ggf. Sinn, kurz mal einen Umweg zu gehen, wie mit dem Thema "createGroupReadings" in HUEDevice - da wirst du hoffentlich bereits festgestellt haben, dass das sowieso der default ist, wenn du nichts anderes am HUEBridge-Device eingestellt hast ...)

Völlig davon abgesehen, dass ich es mir gar nicht leisten kann mal eben so einen Taster zu kaufen und den irgendwo hinzuhängen, immerhin kostet ein Taster mal schnell 50-70€. Ich habe in den letzten 5-6 Monaten bereits mehr als 1000€ für die Automation ausgegeben, irgendwann muss ich das auch mal eingrenzen.

Also einen Tradfri-on/off-Taster gibt es am ca. 10 Euro, und für um die 20-25 Euro bekommst du z.B. einen "opple" mit bis zu 6 Tasten und je 4-5 Events/Taste... (Ist ok, ich verstehe, wenn deine bessere Hälfte meint, es muß auch mal gut sein.)

Das mag ja alles sein, nur was nützt mir ein Tool/Modul, dass den Wecker auslesen kann wenn es nicht funktioniert/läuft? Was denkst du warum habe ich mich mit AMAD beschäftigt? Aus Spaß? Es gibt auch einen eigenen Threat ohne endgütige Problemlösung.

AMAD kenne ich selbst nur als Stichwort und meine Empfehlung war auch nicht, auch damit noch gleich anzufangen, sondern dich erst mal auf bestimmte Module zu fokussieren und z.B. dieses Modul dann "für später" auf die Liste zu schreiben.
(Ich bin ziemlich sicher, dass hier einige erfahrene User mitlesen, und erfahrungsgemäß scheiben die dann schon was, wenn ich großen Mist verzapfe, was auch hin und wieder vorkommt... Also jetzt: AMAD: nein, RESIDENTS&Co: ja).

Ich will nichts zwingend aus dem Boden stampfen, da schätzt du mich völlig falsch ein. Ich muss nur einfach mit den Mitteln arbeiten, die ich habe. Ich kann nicht mal eben so einen neuen Schalter oder gar was noch teureres wie eine Infrarotkamera kaufen. Ich bin auf das angewiesen was ich besitze und leisten kann, und dazu zählt nun mal einfach, dass ich nicht ständig neue Sachen kaufen kann.

Ich kann nur beurteilen, was du hier schreibst und tust, und da sieht es nach "ich mache das auf meine Weise oder gar nicht" aus.

Und meine Empfehlung war auch hier: Nicht gleich irgendwas kaufen, sondern: die Welt ist größer, als du das im Moment ggf. überblicken kannst (und evtl. sogar günstiger, aber ich will dich nicht gleich in die Welt der Microcontroller-Programmierung und eigengestrickten Lösungen schicken...)! Also: KISS für den Anfang...

Bitte verstehe das nicht falsch. Ich habe nur eben nicht unendlich viele Aktoren/Sensoren rumliegen und möchte auch nicht nach einem halben Jahr alles neu machen was ich jetzt mühsam erarbeitet habe obwohl ich weiß, dass es später nicht funktioniert.

Ich glaube, genügend andere User hier erlebt zu haben, die vor genau diesem Problem standen: einen ungeordneten Wust an (teils sehr teurem) Krimskrams vor sich, der irgendwie "verarbeitet" sein will und die Erwartung, dass das alles doch "einfach" wäre...

Es ist mitnichten einfach, und es gibt hier im Forum ausreichend Expertise um Lösungen zu erarbeiten, die dauerhaft funktionieren. "Dauerhaft funktionieren" kann aber auch heißen, es so zu machen wie manche Entwickler von teils sehr komplexen Modulen (die also mehr drauf haben wie ich), die kundgeben, dass sie den Bewohnerstatus schlicht und ergreifend mit einem Taster oder einer Telegram-Anweisung oä. von "schlafend" auf "aufgewacht" bzw. auf "gehe jetzt schlafen" stellen...

Vielleicht noch ein Aspekt: Du kannst davon ausgehen, dass das ganze weiter Geld kosten wird, weil eben viele Dinge dann doch "Nacharbeit" bedürfen, wenn man sie näher ansieht. Das kann man minimieren, wenn man entsprechend Zeit in eigene Lösungen steckt, ganz vermeiden läßt es sich leider nicht, und es ist öfter die Frage, was man eher hat: Zeit oder Geld...

[Prof. Dr. Peter Henning]

Hm. Hier sollen (schwierige) Probleme der Anwesenheits- und Verhaltenserkennung gelöst werden durch Erkennung eines Ladestroms? Das ist m.E. zum Scheitern verurteilt.

LG

pah

[MarkoP]

@Beta-User
Gut das du das ganze nicht Missverstehst.
Ich werde mir das Residents auf jeden Fall mal ansehen wenn ich dazu komme, doch dass kann eventuell einige Zeit dauern. Da ich für die Anwesenheitserkennung ja eine funktionierende Lösung über die WLan-Einbuchung in der fritzbox habe hat das für mich eine niedrigere Priorität. Erst mal muss davor die Lichtsteuerung, und die zwei Google Nest Mini vernünftig eingebunden werden, aber eins nach dem anderen.
Und ich zahle wirklich mein  Lehrgeld. Erst diese Nacht noch, da ich auf die Schnelle den Off-for-Timer-Befehl falsch interpretiert hatte. Hatte es auf die schnelle so verstanden, dass er nach einer gewissen Zeit erst abschaltet. Doch Nein, falsch gedacht und so ging heute Nacht ständig das Licht im Schlafzimmer an bis ich den Fehler gefunden habe.

Man soll halt nichts zwischen Tür und Angel machen. Aber wenn man halt nicht wirklich Zeit findet, macht man so einen Blödsinn obwohl man es Besser weiß trotzdem. 

Damit wir auf dem gleichen Infostand sind:
Bei mir läuft aktuell eine Fritzbox mit 6 Actoren (Zwischenstecker) und einem nicht aktiven Thermostat
Homematic mit einem magnettürkontakt, einem UP-Rolladenschaltaktor und einem bis lang nicht verbautem Thermostat über ein Funk-Gateway, also keine CCU
die 4 Shelly's 2.5 über WLAN
und Phillips HUE mit insgesamt 9 Lampen (4 Kerzen, der Rest GU10). Dazu besitze ich noch zwei weitere Kerzen, 3 GU10 und einen Bewegungs-Helligkeitssensor die aktuell nicht verbaut sind.

Verbunden sind mein PC über WinConnect, zwei Dreamboxen und ein Samsung-Fernseher C-Serie (der B-Serie ist wohl zu alt um ihn zu verbinden, jedenfalls schaffe ich es nicht)
Zusätzlich per Webabruf 4 Tankstellen-Preise, FTUI ist in arbeit

[Beta-User]

Hm. Hier sollen (schwierige) Probleme der Anwesenheits- und Verhaltenserkennung gelöst werden durch Erkennung eines Ladestroms? Das ist m.E. zum Scheitern verurteilt.

Da sind wir schon zwei, aber mal schauen, ob es sich für den TE und eventuelle Mitleser gelohnt hat zu verstehen, warum das so ist...

@MarkoP:
Falls du erwartest, dass ich mir das mit dem Gerätepark irgendwie auch nur ansatzweise merken kann: Vergiss es...
Den FB-DECT-Thermostaten (?) solltest du mMn. direkt wieder verkaufen, die Dinger sind dem Vernehmen nach kompletter Murks, und ob die Zwischenstecker besser sind, kann ich nicht beurteilen. Ich würde  dafür (Zwischenstecker) tendenziell eher Richtung ZigBee gehen (aber nur, wenn nicht zu viel Verkehr auf 2.4GHz drumrum ist) - mit einer Fritte als Basis sind übrigens auch weitere ESP8266-basierte Geräte eine "no-go-zone".
Die Philips-Bridge (?) ist auch afaik keine gute Basis für Bewegungsmelder, weil die nicht pusht (=> deconz, zigbee2mqtt oder tasmota2mqtt wären diesbezüglich bessere Alternativen; ich würde zu ConBee II mit zigbee2mqtt tendieren).

Den Multimedia-Sch... würde ich erst mal auf der Seite lassen, wenn er nicht direkt so einbindbar ist, wie du dir das vorstellst.

Thermostate...: Machen die überhaupt Sinn? In Neubauten ggf. nämlich nicht.

Grundsätzlich: diese "Mischerei" von verschiedenen Technologien ist für FHEM an sich kein Problem. Problematisch ist es allerdings für den Anwender, weil sich jedes Ding eben anders verhält und die commandref intensiv studiert sein will, und problematisch ist es für den Funkverkehr, weil der sich ggf. in die Quere kommt (WLAN(-ESP), BT, DECT, ZigBee, MySensors@nRF24 => alles 2.4 GHz)...

Kurz: Dein Gerätepark ist ziemlich unstrukturiert und daher auch nicht unbedingt eine gute Basis für eine einfache Einarbeitung...

Das ist hier aber insgesamt wieder bzw. noch weiter OT.

[Prof. Dr. Peter Henning]

Problematisch ist es allerdings für den Anwender,

Zumindest für den Anfänger.

Und noch ein Tipp: Wer gleich damit anfängt, das auf einem Docker-Container in einer NAS laufen zu lassen, wird irgendwann frustriert aufgeben. Unbedingt einen einfachen Raspberry Pi 3 für 30 € beschaffen und damit beginnen.

LG

pah

[Beta-User]

Und noch ein Tipp: Wer gleich damit anfängt, das auf einem Docker-Container in einer NAS laufen zu lassen, wird irgendwann frustriert aufgeben. Unbedingt einen einfachen Raspberry Pi 3 für 30 € beschaffen und damit beginnen.

...auch hier: +1 (ich meine, das hätte ich an anderer Stelle auch schon mal mit der Antwort: "zu teuer" von mir gegeben...)

Im Bild gesprochen: bevor man einen frisch gefangenen Drachen mit vielen Köpfen reiten will, sollte man schon mal ein gut eingerittenes Pony gestriegelt und gesattelt haben und damit ein paar Mal im Kreis geritten sein... (Die Zwischenstufe mit einem ordentlichen Roß kann dann auch nicht schaden ).

[MarkoP]

Mir ist schon klar, dass es sich nicht um eine einfach Ausgangssituation geht, doch hier die goldene Frage an euch:
Was denkt ihr wie ich zu diesem Sammelsorium gekommen bin?

Genau, solche Hinweise ala:

Unbedingt einen einfachen Raspberry Pi 3 für 30 € beschaffen und damit beginnen.

sind daran schuld, denn jeder macht andere Vorschläge, jeder hat andere Preferenzen.
Ich hatte ursprünglich auf die AVM-Sachen gesetzt, da die Fritzbox eh schon da gewesen ist. Dann kamen User an und meinten damit wirst du nicht glücklich, schau lieber nach ein richtiges SmartHome-System an.
Daraufhin habe ich mich nach langer Suche für Homematic entschieden, da ich da die größte Abdeckung vorgefunden habe. Lediglich die Lampen waren von Anfang an über Phillips als Ausnahme klar.
Was kam dann? Genau, der nächste der plötzlich meinte Homematic, vergiss es, da hast du nur Probleme mit, zu Groß, zu Teuer, etc. Nimm doch Shelly-Aktoren. So geht es weiter und weiter bis man eben so ein Chaos hat wie ich jetzt.

...auch hier: +1 (ich meine, das hätte ich an anderer Stelle auch schon mal mit der Antwort: "zu teuer" von mir gegeben...)

Doch es ist zu teuer, denn es ist ja nicht nur der Raspi, dazu kommen ja immer noch Anschlussteile, Verkabelungen und ob es örtlich überhaupt möglich ist ohne Tapete und Wand aufzureißen ist auch noch eine Frage (Ja, es gibt tatsächlich Wohnungen die noch nicht auf jeder Wand 8 Steckdosen und 3-4 Netzwerkanschlüsse haben).
Nichts für Ungut, aber es ist immer leicht gesagt: kauf dies, nutz jenes. Die Realität sieht oft halt anders aus, deshalb sage ich, dass ich jetzt mit dem Leben muss was ich habe und erst mal nichts Neues (kein neues System) anschaffen werde. Vielleicht wenn ich mal weiter bin, dann kann man darüber nachdenken, aber im Moment erst mal nicht. Wenn sich deshalb jetzt jemand abwenden möchte kann ich das nicht ändern, auch wenn es sicherlich schade wäre.