[gelöst] Bridge disconnected

[Beta-User]

@Beta-User
Also wenn ich dich richtig verstehe, willst du sagen, dass es mehr Sinn macht sich mit Pearl-Code und Programmierung auseinander zu setzen und das DOIF komplett zu ignorieren.

Was für den einzelnen Sinn macht, muß jeder selbst wissen. Ich werde DOIF vermutlich nicht mehr einsetzen, empfinde die Zeit der Beschäftigung damit im Nachhinein als Zeitverschwendung.
Perl ist immer noch die Programmiersprache Perl und kein Versandunternehmen, keine Schallplatte von ... etc. Es macht in jedem Fall Sinn, sich mit Perl etwas vertiefter auseinanderzusetzen, denn auch DOIF ist nur ein "wrapper" für Perl-Code (wie praktisch alle anderen Module auch). Früher oder später kommt dir also irgendeine Warning oä. aus dem "Untergrund" entgegen, mit der du dich dann auseinandersetzen mußt.

Ansonsten wollte ich nur darauf hinweisen, dass deine Begründung mAn. nicht trägt (Mit meiner privaten Skepsis gg. DOIF bin ich ggf. Teil einer kleineren Minderheit, aber eben auch nicht der einzige User hier... DOIF ersetzt jedenfalls keine logische Gedankenführung und auch keine FHEM-Grundlagenkenntnisse, und wer beides hat, hat die freie Auswahl bei den Mitteln, seine Vorstellungen umzusetzen; da gibt es auch durchaus den einen oder anderen Spezialisten unter den Modulen, der für bestimmte Teilaufgaben konzipiert ist, für den man auch DOIF verwenden könnte. Auch die findet man leichter, wenn man nicht gleich auf die "eierlegende Wollmilchsau" setzt und versteht sie besser, wenn man gewohnt ist, ggf. auch mal in den Quelltext zu sehen).

Offtopik-Frage:Habe mal keine Konfiguration in meine Signatur reingeschrieben. Reicht das so für einen ersten Überblick oder fehlt etwas?

Ich kenne mich mit dem Docker-Zeug (fast) nicht aus und kann das daher nur eingeschränkt beurteilen. Mir wäre es zu viel Text, dafür fehlt z.B. die Perl-Version oder CUL_HM (Homematic geht auch über HMCCU.*).

Allg.: Manche Forenuser lassen die signaturen (von anderen) ausblenden, z.B. betateilchen hätte das vermutlich nicht gesehen.
Es kommt hin und wieder auch auf den Gesamtzusammenhang an; ob ein notify tut was es soll, wird in der Regel unabhängig vom Netzwerkumfeld sein (und sogar unabhängig vom OS/Perl, auf dem das ganze läuft). Es macht daher ggf. Sinn, bei Bedarf auch gesondert darauf hinzuweisen, dass da was spezielles läuft; es ist einfach eine Frage der Höflichkeit gg. potentiellen Helfenden, wenn man mitteilt, wie weit man selbst irgendein beliebiges Problem schon durchdacht hat und wie in etwa die eigenen Kenntnisse sind  .

[MarkoP]

@Otto123
Ich kenne keinen einzigen und ich habe Dutzende kennengerlernt.
Aber lassen wir dass, ich merke du wirst ausfallend und beleidigend, also ehe das wieder ausufert ...

@Beta-User
Ok, danke für die Info's.

[Otto123]

War mir jetzt nicht so direkt aufgefallen, aber wenn dem so ist, hast Du es immerhin geschafft sogar mich aus der Ruhe zu bringen

[Wernieman]

Ich kein keine Admin, der aktuell ein Netz mit >50 Geräten NICHT per DHCP konfiguriert ....

Die DHCP-Absage ist älter als 10 Jahre ....

Btw: Wie glaubst Du arbeiten den n die grioßen Hoster? Wie verteilen Sie die Serverips/Netzinformatinen? z.B. hetzner, Strato, HostEurope ... etc. .... und glaube mir, die sind nicht blöde...

Wobei ist zugeben muß, das meine Geräte hier auch zu 50% per "Hand" eingestellt sind. Trotzdem habe ich auch einen DHCP-Server laufen (und das ist NICHT die Fritte)

[MarkoP]

Ich werde das Thema DHCP nicht weiter vertiefen, jeder darf seine Meinung haben und basta. Ich kenne jedenfalls keine Administrator, der DHCP dauerhaft einsetzt, lediglich bei der Geräteeinbindung. Besonders bei Netzwerken >50 Geräten und mehreren Subnetzen.
Also lassen wir es einfach gut sein ehe es wieder ausufern wie bei Ottos stichelkommentar.

@Beta-User
Passend zur Diskussion DOIF vs. Notify habe ich mit letzterem ein Verständnisproblem.
Ich habe gestern für jeden Bewohner (2) einen Homestatus-Dummy angelegt und will den über eine Anwesenheitskontrolle per WLan und Fritzbox mit den Stati 1-4 setzen.
Dazu habe ich 4 Notifys erzeugt, die auf die zwei Kontrollen (Anwesenheit und Schlaf) (beide funktionieren) reagieren.
Hier mal das List eines der Notifys:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        Marko_Anwesenheitskontrolle:absent set Homestatus_Marko 3
   FUUID      5f48103a-f33f-b8b5-de7b-0a80952902fba51e
   NAME       Homestatus_Marko_Away
   NOTIFYDEV  Marko_Anwesenheitskontrolle
   NR         18174
   NTFY_ORDER 50-n_Marko_Away
   REGEXP     Marko_Anwesenheitskontrolle:absent
   STATE      2020-08-28 07:22:50
   TRIGGERTIME 1598592170.02337
   TYPE       notify
   READINGS:
     2020-08-27 21:57:46   state           active
Attributes:
   group      Ereignis (notify)
   room       Schaltzentrale

Der Set Befehl funktioniert, habe ich manuell probiert.
Doch leider wird keins der Notifys automatisch ausgeführt.  Da muss irgendwas mit dem Trigger nicht stimmen.
Dazu das List der Anwesenheitskontrolle:

Code Auswählen Erweitern

Internals:
   DEF        function {checkAllFritzMACpresent("30:07:4D:82:B0:F3")} 60 60
   FUUID      5ddae20b-f33f-b8b5-93ee-a9a97150ac3adaca
   FVERSION   73_PRESENCE.pm:0.207820/2019-12-19
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       function
   NAME       Marko_Anwesenheitskontrolle
   NOTIFYDEV  global
   NR         19
   NTFY_ORDER 50-Marko_Anwesenheitskontrolle
   STATE      absent
   TYPE       PRESENCE
   READINGS:
     2020-08-26 18:47:35   model           function
     2020-08-28 07:33:51   presence        absent
     2020-08-28 07:33:51   state           absent
   helper:
     CURRENT_STATE present
     call       {checkAllFritzMACpresent("30:07:4D:82:B0:F3")}
Attributes:
   group      Anwesenheitskontrolle
   icon       people_sensor
   room       Schaltzentrale
   userattr   Anwesenheitskontrolle Anwesenheitskontrolle_map structexclude

Vielleicht kannst du mir helfen.

[MadMax-FHEM]

Warum 4 notify?

Aber egal...

Lösung für das Trigger-Problem:

Eventmonitor öffnen, dummy der auslösen soll betätigen (oder ist es ein echtes Presence!? Dann halt das "auslösen lassen") auf den Event warten markieren und notify erzeugen lassen...

Gruß, Joachim

[Beta-User]

Ich werde das Thema DHCP auch nicht vertiefen, kann mir aber eine Anmerkung zur Tonlage nicht verkneifen:
Die entsteht nämlich zu einem guten Teil auch im Ohr des Empfängers . Meine Tipps dazu: Gerade wenn sehr erfahrene und kompetente Helfer (vermeintliche?) Spitzen setzen, gibt es in der Regel (aus deren Warte) einen guten Grund dazu; du mußt die Ansichten dazu nicht teilen, aber nicht ganz selten macht es viel Sinn, darüber nachzudenken... Was gar keinen Sinn macht: Experten herabwürdigen.

Ergänzend dazu noch: Mich wundert, dass immer mal wieder (nicht nur hier) in einer öffentlichen Diskussion mit mehreren Beteiligten vom Fragenden dann einer der Helfer speziell angesprochen wird. Für mich - falls ich _nicht angesprochen_ werde - ist das dann in der Regel das Signal, dass meine Meinung nach Ansicht des Fragenden dann ausdrücklich nicht mehr gefragt ist. Daran versuche ich mich dann zu orientieren, es sei denn, die Beteiligten würgen dann eine völlig abstruse Lösung zusammen, die man zum Schutz vor Nachahmung durch unbedarfte Neulinge als Unsinn kennzeichnen muß.
(Der spezielle Punkt hinter dieser Anmerkung ist der: @Otto123 ist der Hauptautor hinter der aktuellen Fassung zum Wiki-Artikel "notify" (ich weiß, dass du lieber ein "hübsches Video" hättest, aber mMn. kann man sowas besser aufschreiben, und diese Fassung ist m.E. auch gut!) und auch beim Thema Fritzbox und Anwesenheitserkennung meine ich mich an mehrere Fälle erinnern zu können, in denen er Anfängern sehr geduldig - und vor allem erfolgreich - geholfen hat, sowas einzurichten. Er wäre daher vermutlich der kompetentere Helfer für deine aktuelle Frage - genauso wie ich z.B. sehr froh wäre, wenn Wernieman sich meldet, falls ich mal ein Problem aus dem Netzwerk- oder Linuxumfeld habe. Das muß nicht heißen, dass wir immer alle zusammen einer Meinung wären oder nicht gelegentlich aneinander vorbeireden oder manchmal miteinander in die falsche Richtung was austesten und dann auch entsprechende Spitzen ihren Platz haben dürfen ...)


Was die Sachfragen angeht:
- Für "Homestatus" würde ich keinen dummy hernehmen (überhaupt sollte man versuchen, dummy zu vermeiden, in >90% der Fälle, die einem praktisch hier begegnen ist ein dummy-TYPE-Device _nicht_ die optimale Lösung...), sondern das über die RESIDENTS-Modulfamilie abbilden.
- "Meine" Lösung findest du hier: https://svn.fhem.de/fhem/branches/epdf2020/frame.adoc#_jemand_zuhause (damit das im Browser hübsch aussieht, brauchst du ggf. ein plugin für asciidoc).
Die kommt auch mit nur einem notify aus, pollt nicht unnötig in der Gegend rum und ist so ein bißchen in die Richtung, wie ich bereits angedeutet hatte: Man kann mit notify+Perl (das Beispiel ist noch ohne myUtils) ohne weiteres schlanke und generalisierte Lösungen basteln... (das geht auch mit DOIF, nur ist es da wie bei Dummy: viele Lösungen hier im Forum sind "doofe" copy/paste-Lösungen, die bezogen auf einen Einzelfalls ok sind, aber den Blick auf alternative generalisierte Lösungen verstellen (die afaik auch mit DOIF möglich wären)...).
- Was das Thema "triggert das Event das notify?" angeht, würde ich die Lektüre des betreffenden Wiki-Artikels empfehlen .


Btw: Wohlwollende und konstruktive (!) Kritik nehmen sowohl Otto123 wie auch ich zu den genannten Doku-Bausteinchen in der Regel gerne entgegen. Das trifft im besonderen Maß auf das Fragment im svn zu, auf das ich oben auszugsweise verlinkt hatte. (Unser Problem: "Richtige" Doku für Anfänger (wie eben derzeit dich) zu schreiben ist immer schwierig, weil man irgendwie verkürzen muß, was es teils mißverständlich macht - die Botschaft entsteht ja erst final im Auge des Betrachters ).

[MarkoP]

@MadMax-FHEM
4 Notify's weil ich theoretisch 4 Auslöser haben kann: Anwesenheit wird auf present gesetzt, Anwesenheit wird auf absent gesetzt, Nachtruhe wird auf present gesetzt und Nachtruhe wird auf absent gesetzt. Wobei der erste und letzte Auslöser das gleiche Ergebnis haben.
Die Anwesenheit ist ein echtes Presence, die Nachtruhe ist ein Dummy, der per Android-Handy und andFhem auf present/absent gesetzt wird (wird in naher Zukunft durch eine Energieüberwachung mit einem der Shellys2.5 abgelöst).
Kann man theoretisch auch mit 2 Notify's erledigen, aber ich versuche aktuell so einfach wie möglich zu bleiben und da sind 4 einzelne für mich einfacher als zwei, die dann entsprechend des Events verschieden reagieren.
Was meinst du mit "erzeugen lassen"? Gibt es einen Automatismus ala autocreate der mir bisher unbekannt ist? Oder meinst du anhand der Eventeinträge manuell erstellen?

@Beta-User
Zum Thema DHCP habe ich nichts anderes getan. Leider ist das Gegenteil hier eher der Fall, da auf meinen Kommentar, dass ich keinen Administrator kenne (und ich kenne eine sehr große Menge), der sein Netzwerk dauerhaft mit DHCP betreibt (speziell je größer das Netzwerk wird und mit steigender Anzahl an Subnetzen). Da wird DHCP lediglich als Einstieg benutzt um ein Gerät bei der Ersteinrichtung anzusprechen und dann zu konfigurieren. Doch auf diesen Kommentar kam einzig die Reaktion, das ich doch in meine Signatur hinzufügen sollte, ich wäre der einzige Vernünftige. Nichts anderes - und ich meine wirklich nichts - konnte man aus der "Spitze" rauslesen. Aber du hast natürlich Recht mit der aussage, dass Interpretation immer zwei Seiten hat, doch in diesem Fall konnte die "Spitze" nicht missverstanden werden. Und wie ich auf solche "Spitzen" reagieren (die ich teilweise als Beleidigung empfinde) ist wohl mehrfach offensichtlich geworden. Ich bin nun mal ein Mensch, der keine Lust auf Sarkasmus und Ironie hat. Menschen habe eben oft andere Auffassungen von Humor und nicht jeder nimmt einen Witz als Witz wahr.

Dass ich dich explizit angesprochen hatte, liegt einfach in dem Fakt begründet, dass ich mit dir vorher dieses Thema angesprochen habe, während der Dialog mit Otto123 einen völlig anderen Inhalt hatte. Dies war also in keiner Weise einschränkend gemeint. Speziell da ich nicht mal weiß, dass Otto123 der Verfasser von einem entsprechenden Wiki-Thema ist - woher soll ich dass auch wissen? Und nein, ich suche nicht zwingend ein hübsches Video, finde diese Art der Anleitung aber besser, da sie eben weniger Interpretationsanfällig ist.

Was die Anwesenheitserkennung angeht, die funktioniert ja. Es geht darum, dass das Notify nicht auf den Trigger reagiert. Ganz ehrlich, ich frage mich schon ob ich mich so ungeschickt ausdrücke oder woran es liegt, dass immer wieder falsche Voraussetzungen angenommen werden. Vielleicht denke ich einfach anders und kann eure Gedankengänge nicht nachvollziehen, ich weiß es nicht. Doch bin ich diesmal deiner Aufforderung nachgekommen direkt ein list und eine Beschreibung der Umstände mitzuliefern und trotzdem wird an anderer Stelle angesetzt. Auch wenn ich es nicht weiß, so habe ich doch Ahnungen wo das Problem zu suchen ist, oder nicht? Warum dann nicht erstmal auf die Ahnung eingehen, ehe man weit ausholt und Dinge ins spielt bringt die längst funktionieren. Versteh mich bitte nicht falsch, aber es kommt mir so vor als wenn ich nach Äpfeln frage und Birnen angeboten bekomme. Frage ist eigentlich doch nur warum der Auslöser im Notify nicht auf den Trigger beim Schalten des Presence/Dummy's reagiert? Ist ein Schreibfehler vorhanden? Ist die Kommunikation nicht korrekt? Was weiß ich.

Was deinen Kommentar bezüglich Dummy angeht, bitte vergiss nicht, dass es speziell für Anfänger oft einfacher ist einfache Einzellösungen zu verstehen als komplexe Universallösungen. Speziell wenn es darum geht im Nachhinein, womöglich Monate später, den Kontext noch einmal ins Gedächtnis zu rufen. Natürlich gebe ich dir Recht, dass Einzellösungen nicht das Ziel sein sollten, doch oft ist es eben einfacher zu verstehen, wenn ein paar mehr Zwischenschritte eingebaut sind. Natürlich lässt sich alles ohne Dummy's lösen, doch es wird dann oft unübersichtlich und sehr komplex. Ist ja in der allgemeinen Programmierung nicht anders.

[Beta-User]

ROOMMATE statt dummy macht das ganze mMn. einfacher, nicht komplexer. Das gilt vor allem, wenn du irgendwann dann weitermachen willst. Da ist es zwar möglich, eine eigengestrickte Lösung ebenfalls einzubauen, aber viele Beispiele setzten eben z.B. funktionierende RESIDENTS voraus.

Bitte entschuldige daher, dass ich mir die Freiheit genommen hatte, einen etwas anderen Ansatz vorzuschlagen. Eine Selbstbeschränkung auf eine ganz bestimmte Antwort zur Lösung des genau gefragten Problems hat m.E. zur Folge, dass hier wieder eine suboptimale Lösung erarbeitet wird, die dann ggf. copy/paste verbreitet wird; das ist nicht mein Ansatz beim Helfen, und wenn du mir jetzt signalisierst, dass du meine Denkweise nicht für hilfreich empfindest, werde ich die Konsequenzen daraus ziehen.

In der Sache:
Ich weiß auch nicht, warum deine notify nicht reagieren, aber in dem genannten Artikelchen zu notify (von dem ich gehofft hatte, du würdest ihn lesen) findet sich afaik auch ein Link auf den Event-Monitor - und das ist der "Automatismus", den FHEM zur Erstellung von Eventhandlern anzubieten hat...

Nachtrag:
(Und user, die für sich in Anspruch nehmen, in mehreren Sprachen Programmieren zu können, braucht man mMn. nicht erst mit umständlichen Detaillösungen unter Verkettung von diversen Dummy&Co-Kaskaden traktieren, sondern die suchen genau nach generalisierten Lösungen - alles andere ist nämlich schwerer zu pflegen und neigt dazu, unwartbar zu werden...).
Just my2ct

[MadMax-FHEM]

Da ich direkt angesprochen wurde:

Was du aufgeführt hast geht auch mit einem notify und etwas Perl (optional, weil übersichtlicher, "ausgelagert" in eine myUtils-Sub)...

Evtl. mal Regex ansehen...
Giltet nicht nur für notify, gilt auch für DOIF (eigentlich für fast alles in fhem   )...

Weil der Trigger (bei notify, ...) ist Regex...

Geeignete Namenwahl vorausgesetzt geht so einiges ("generisch") beim Programmieren (in fhem)...

EDIT: und da muss ich mich Beta-User anschließen. Ich versuche so viel wie möglich "generisch" zu machen. Weil wenn es "überlegt" gemacht wird/wurde ist eine "Erweiterung" einfach. Wenn ich etwas für eine bestimmte Device-Gruppe "programmiere", dann generisch. D.h. ein neues Gerät dieses "Typs" (muss nix mit Device-Type etc. zu tun haben), dann wird es automatisch von dieser Programmierung "erfasst", wenn eben beim Anlegen gewisse "Regeln" beachtet werden (meist reicht bei mir eine bestimmte Namensgebung). Ohne, dass ich die Programmierung oder irgendein notify "anfassen" müsste oder gar ein neues extra anlegen müsste...

EDIT: ja es gibt einen "Automatismus", schau dir halt das Wiki zu Eventmonitor an. Oder: mach wie ich geschrieben hab...

Gruß, Joachim

[MarkoP]

@Beta-User
Nein, selbstverständlich kannst du andere Ansätze vorschlagen, es macht nur für mich - wie vermutlich andere Anfänger auch - die Situation schwieriger. Ich konzentriere mich auf das Problem und wenn dann seinerseits Dinge in den Raum geworfen werden, die erstmal funktionieren muss man jedes mal überlegen was das mit dem Problem zu tun hat. Es ist einfach nicht das Verständnis für die Hintergründe dar.

Wie üblich bin ich auf der Arbeit und daher noch nicht dazu gekommen den Artikel zu lesen. Das erste was ich in einer Unterbrechung mache ist halt auf neue Benachrichtigungen zu checken.
Solche Artikel zu lesen muss ich dann Abend nachholen wenn ich zu Hause bin.

Prinzipiell gebe ich dir mit den generellen Lösungen Recht. Ich bevorzuge auch eine Allround-Lösung wenn es sie gibt. Doch gerade beim Pflegen muss ich dir widersprechen  - zumindest was einen Anfänger angeht.
Und auch wenn ich mich in verschiedenen Programmiersprachen auskenne, bin ich in Fhem und auch Perl ein Anfänger. Und als solcher kann ich nachvollziehen, dass es für viele einfacher ist Schritt-für-Schritt-Einzellösungen zu verstehen, also irgendwelche ineinander verschachtelte Befehlsketten. Darauf zielte mein Kommentar bezüglich der Verwendung von Dummy's ab. Ein Dummy ist ein Zwischenschritt.

Das Roommate und auch Homemode muss ich mir mal in ruhe ansehen, das schaffe ich nicht auf der Arbeit wo alle Nase jemand reinkommt und stört. Muss generell mal wieder 1-2 Lesetage in der Woche einführen.

@MadMax-FHEM
Danke für die Info, werde ich mir ebenfalls ansehen.

[Beta-User]

Dann lies dich in Ruhe ein. Wie hat jemand an anderer Stelle geschrieben: Es gibt keinen Zwang, direkt zu antworten, und nach meinem Gefühl ist es zielführender, Rückmeldungen zu (relativ) konkreten Vorschlägen dann zu geben, wenn man sie "nachgedacht" (und manchmal nachgemacht) hat.


Du darfst mir gerne widersprechen. Was ich hier schreibe, basiert auf meinen eigenen Erfahrungen und dem, was ich so zwischenzeitlich in den letzten Jahren hier so alles zu sehen bekommen habe. Andere haben ggf. andere Erfahrungen gemacht oder "ticken" anders - kein Problem...

Meine Meinung: Ein dummy als Zwischenschritt ist immer Murks!

(Das gilt jedenfalls dann, wenn dieselbe Info (hier: anwesend oder nicht) genausogut in einem passenden "Enddevice" aufgehoben ist (und so ist es mMn. hier gelagert). Mein Erfahrungswert ist nämlich der, dass User dazu neigen, diese Zwischenschritte beizubehalten und den dummy nicht nur übergangsweise zur Anzeige benutzen um zu sehen, ob ihr Code _bis dahin_ tut, was er soll - so verwendet, mache ich das hin und wieder auch; das ganze ist plakativ zu verstehen und eher als Orientierungs- oder Merksatz zur Warnung gedacht...
Und häufig ist es eine Überlegung wert, ob man dauerhaft zur Verfügung zu haltende Zwischenwerte als READING beim eigentlichen Zieldevice (oder dem Event-Handler) hält, statt ein eigenes "Device" dafür zu verwenden - das ist nämlich mMn. auch eine _Möglichkeit_, Infos in FHEM übersichtlich zu strukturieren...)

[MarkoP]

Ich werde es mir auf jeden Fall anschauen wenn ich die Shelly's verbaut habe und die Nachtschaltung statt vom Handy über die Verbrauchsausgabe der Ladeschale direkt steuere. Dann könnte ich den Dummy wahrscheinlich auf jeden Fall eliminieren.
Die Anwesenheitserkennung ist ja ein Presence-Element.

[MadMax-FHEM]

Und auch wenn ich mich in verschiedenen Programmiersprachen auskenne, bin ich in Fhem und auch Perl ein Anfänger. Und als solcher kann ich nachvollziehen, dass es für viele einfacher ist Schritt-für-Schritt-Einzellösungen zu verstehen, also irgendwelche ineinander verschachtelte Befehlsketten. Darauf zielte mein Kommentar bezüglich der Verwendung von Dummy's ab. Ein Dummy ist ein Zwischenschritt.

Also ich kannte vor fhem Perl auch nicht...

Aber meiner Meinung nach ist Software entwickeln in großen Zügen unabhängig von der genutzten Plattform/Programmiersprache.

Weil "Programmieren" weit VOR dem "Reinklopfen von Code" beginnt!

D.h. ich überlege mir (relativ) genau WAS ich WIE gedenke umzusetzen und versuche dabei schon so "generisch" wie möglich zu denken...

Ging bei mir schon los beim wählen der Namen der Devices (geht bestimmt auch besser aber für meine "Generik" reicht es )...

UND: es ist sogar unabhängig ob notify oder DOIF (oder was auch immer)...

(wobei mich bei DOIF die "Mischung" aus "Programmieren" [evtl. dann ja doch mittels DOIF-Perl] und "Parametrieren" [weil manche Attribute das "programmierte Verhalten" beeinflussen] komplett "durcheinander bringt", daher nutze ich praktisch kein DOIF)


Klar beim Umsetzen auf Plattform/Programmiersprache gilt es dann nat. die entsprechend korrekte Syntax zu wählen (einfach: im Internet googeln   ) und evtl. einige "Konstrukte" wegen "Einschränkungen" der jeweiligen Sprache/Plattform noch mal (kurz) überdenken aber ansonsten können meine "Programme" jederzeit in jeder Programmiersprache/Plattform eingesetzt/umgesetzt werden (gut bei anderer Programmiersprache nat. noch Syntax etc. "korrigieren"/"anpassen" ABER: das ist "Umsetzung" nicht "Programmierung"/Software-Entwicklung zumindest in meinen Augen)...

ABER: natürlich jeder wie er kann und will...

Viel Spaß noch, Joachim

[Beta-User]

Bin mal gespannt, ob das mit der Verbrauchsmessung als Indikator für eine Nachtschaltung klappt...

Mit PRESENCE bin ich selbst bisher nicht so richtig warm geworden (ich habe in die Richtung bisher nur einen BT-Tag, den ich eher halbherzig zum Testen verwende), meine aber, dass das ziemlich natlos in RESIDENTS&Co integrierbar ist, ohne dass man da groß was aktiv machen müßte (außer einem passenden Attribut in ROOMMATE zu setzen (vermutlich)).

Meine derzeitige Lösung (und die von andies, der den Teil betreffend Unify und den Rahmen zu "jemand zuhause" geliefert hat) kommt ohne den Zwischenschritt aus - da will ich aber nicht behaupten, dass das "besser" oder schlechter sei als die Lösung mit einem PRESENCE-Device. Ich finde nur das Verarbeiten von Events generell dem Pollen von Informationen vorzugswürdig, und die Fritzbox liefert eben beides (nach meiner bisherigen Erfahrung auch recht zuverlässig); aber auch PRESENCE könnte wohl Event-basiert iVm. der Fritte konfiguriert werden (du verwendest derzeit ein polling-Verfahren, wenn ich das richtig interpretiert habe, und polling vs. push hatten wir doch neulich erst im Zusammenhang mit MQTT, oder?).

[OT]
Ggf. baue ich das mit PRESENCE und Fritten-push (!) auch noch in das epdf rein; falls du copy-paste-Input dazu liefern wolltest .
[/OT]

Ich habe vor FHEM auch weder in Perl noch in C (arduino) programmiert (ggf. sehr gelegentlich mal was in einem C-Progrämmchen umkonfiguriert und dann den Compiler angeworfen, das schon)....

Ich wußte aber noch aus der Schulzeit, wie man Struktogramme malt. Ich kann daher MadMax-FHEM nur zustimmen: Nach der ersten Orientierung über prinzipielle Funktionsweisen erst mal hinsetzen und "malen", das "Coding" kommt dann von alleine...


Vielleicht nochmal der Hinweis: Es gibt in FHEM viele Module oder Modulfamilien, die für bestimmte Teilaufgaben gut aufeinander abgestimmt sind. Es macht wenig Sinn, unbedingt an der Stelle das Rad neu erfinden zu wollen. Da kann man schon darauf setzen, dass andere diese Teilbereiche so konzipiert haben, dass es in der Regel auch auf den eigenen Anwendungsfall anpassbar ist .
(Was anderes ist der Versuch, z.B. die Funktionsweise von einem notify mal generell verstehen zu wollen; das kann man selbstredend gerade mit sowas wie der Anwesenheitserkennung eigentlich ganz gut - nur klang hier der Ansatz nicht danach, als wäre das so zu verstehen).