Hallo,
bei meinen Netzwerkversuchen gestern wurde das NAS inkl. Fhem-Server leider per Kaltstart neu gestartet.
Seit dem wird die Homematic-Bridge als "Disconnected" angezeigt und meine Homematic-Devices funktionieren nicht mehr.
Wie kann ich die Verbindung erneut herstellen, muss ich die Bridge komplett neu pairen?
Ist das ein typisches Verhalten, dass immer bei Stromverlust zu erwarten ist?
Was ist eine Homematic-Bridge ?
Sorry, Funk-Gateway.
Bin davon ausgegangen, da bei allen anderen Sachen von Bridge die Rede ist, wäre das klar gewesen. Mein fehler.
Moin,
und was für ein Funkgateway? Es ist kein typisches Verhalten! Wenn disconnected angezeigt wird und es ein Gerät ist welches vom TYPE HMUARTLGW und über LAN angebunden ist wird wohl keine LAN Verbindung mehr bestehen!?
Du musst, glaube ich, dringend was an Deiner Netzwerksituation ändern ::)
Mögliche Ursache
DHCP, nicht fest reserviert, blöder DHCP Server, neue IP Adresse bekommen.
DNS mit Namen und nicht mit IP eingebunden, Namensauflösung funktioniert nicht mehr.
Netzwerk, anderes Subnetz, nicht mehr erreichbar.
Gruß Otto
Hallo, also meine Netzwerksituation ist so einfach wie möglich aufgebaut.
Für alle Geräte feste IP-Adressen mit strukturierten Bereichen, also nach Gerätegattung von 50-99, 100-149, 150-199 oder halt 200-250.
Keine unterschiedlichen Subnetze, sondern alles in einem Subnetz. DHCP komplett ausgeschaltet, lediglich für das Gast-WLan aktiv.
DNS Auflösung läuft über die Fritzbox, alternativ ist die 8.8.8.8 vom Google-Server.
Da sehe ich eigentlich weniger ein Problem drin.
Hab auch die Lösung heute Morgen gefunden. Das Gateway hatte eine LAN Verbindung, hatte aber die falsche IP-Adresse. Gesehen im Mesh der Fritzbox, da war es mit der IP der Erstanmeldung eingetragen.
Es stimmte also die IP-Adresse im Gerät und in der Fhem Konfiguration nicht mehr. Konnte also gar nicht gehen, obwohl alle Kabelverbindungen korrekt waren.
Irgendwie habe ich wohl unbemerkt mit den ganzen Netzwerk-Versuchen (die ja auch zum Komplettabsturz, also Nicht Erreichbarkeit, vom Fhem-Server und dem NAS geführt haben) auch die IP des Gateways geändert. Keine Ahnung ob da irgendwie also Einstellungen zurückgespielt worden sind. Wäre aber die einfachste Erklärung, da die IP die das Gateway plötzlich hatte, ja die selbe war, wie die, womit es sich bei Inbetriebnahme im Netzwerk per DHCP erstmalig angemeldet hatte.
P.S.:
Meines Wissens gibt es nur ein einziges Funk-Gateway von Homematic. Dazu lediglich noch die CCU2 und CCU3.
Da irrst Du. Es gibt:
- Den "alten" HMLAN Adapter https://wiki.fhem.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter
- Das (eventuell bei Dir vorhandene) aktuelle LAN Gateway https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway
- Diverse Möglichkeiten das Pi Modul über LAN und WLAN anzubinden https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
- Und sicher noch einige mir gar nicht bekannte CUL Derivate die auch über LAN angebunden sein können.
Homematic ist mMn eine Produktbezeichnung, der Hersteller ist eq3. Insofern ist nichts von dem oben genannten
von sondern nur
für Homematic.
Und einfach aufgebaut ist kein Garant für "funktioniert auch", immerhin waren alle Problemdiskussionen mit Dir in den letzten Tagen basierend auf einem nicht funktionierenden Netzwerk.
Auch wenn Du da wenig Probleme siehst :) FHEM hat die Probleme gesehen!
BTW: ein ordentlicher DHCP Server ist viele mal besser als die alte Meinung "alles per Hand zu konfigurieren".
Gruß Otto
OT: Anmerkungen bzw. Anregungungen vor dem Hintergrund der teils bissigen Tonlage an anderer Stelle...
- Es ist gute Tradition hier im Forum, ein "list" der beteiligten Devices zu liefern. Das hat gute Gründe, die man als unerfahrener User nicht kennen kann. Du hättest daher ggf. früher Rückmeldung erhalten, hättest du dich einfach an diese gute Tradition gehalten (ich hätte erst noch einige Zeit gewartet, bis ich die Rückfrage gestellt hätte :P ...)
- Du hast an der einen oder anderen Stelle eine sehr spezielle Ausgangssituation, zum einen, was das Netzwerk an sich anzugehen scheint, zum anderen aber auch mit der von dir eingesezten Plattform. Auch hier wäre es vermutlich hilfreich (für dich) gewesen, klarzumachen, wo ggf. die Schwierigkeiten herkommen können (will sagen: Wichtige Umweltinformationen können Helfer nicht wissen, es sei denn, sie verfolgen alle deine Threads; also liefere sie einfach mit, dann können auch vielleicht mehr Leute was dazu sagen...).
- Generell: Du tust dir mMn. mit der aktuellen Plattform keinen allzugroßen Gefallen, die Docker/QNAP-Kombi vervielfältigt einfach noch die Zahl der möglichen Fehlerursachen, und weniger erfahrene User werden uU. nicht helfen können. Die Investition in einen Pi ist in dem Fall wohl eine sinnvolle... (ich sage das nicht wirklich gerne, denn ein Pi ist mMn. nur ein fader Kompromiss, du solltest dann ggf. schon versuchen, das irgendwie anders zu lösen, aber eben nicht alle Baustellen auf einmal aufreißen!.
Just my2ct.(@Otto: Deine Geduld wollte ich haben, chapeau!)
@Otto123
ZitatDa irrst Du. Es gibt:
Nur zur Richtigstellung, bitte nicht als Angriff werten.
Der alte HMLan Adapter ist meines Wissens nicht mehr erhältlich und alles andere wird nicht als Funk-Gateway bezeichnet. Ein Cul ist kein Gateway, auch wenn es die gleiche Funktion übernimmt. Daher meine Aussage das es nur ein Funk-Gateway gibt. Mit der Firma hast du natürlich recht, war ein Formulierungsfehler. wobei eq3 ja nicht mal der einzige Hersteller von Geräten für den Homematic-Standard ist.
ZitatUnd einfach aufgebaut ist kein Garant für "funktioniert auch", immerhin waren alle Problemdiskussionen mit Dir in den letzten Tagen basierend auf einem nicht funktionierenden Netzwerk.
Die Formulierung "nicht funktionierendes Netzwerk" finde ich sehr grenzwertig. Die Probleme sind nicht dem Netzwerk geschuldet sondern der Konfiguration und die ist immer der Schwachpunkt, egal von welcher Art Netzwerk wir reden. Was DHCP angeht hat wohl jeder seine eigene Meinung. Ich persönlich kann mir nicht vorstellen, dass wildes Chaos einer festen Struktur gegenüber irgendwelche Vorteile bietet. Und mit wildem Chaos meine ich nicht nur das die IP-Adressen wechseln können, sondern auch das sie kreuz und quer durcheinander reichen.
@Beta-User
ZitatEs ist gute Tradition hier im Forum, ein "list" der beteiligten Devices zu liefern.
Ja, das mit dem List muss ich mir angewöhnen. Vergesse ich gerne mal.
ZitatDu hast an der einen oder anderen Stelle eine sehr spezielle Ausgangssituation, zum einen, was das Netzwerk an sich anzugehen scheint, zum anderen aber auch mit der von dir eingesezten Plattform
Das meine Ausgangssituation etwas speziell ist durch die Docker/NAS Kombination ist richtig. Was das Netzwerk an sich angeht würde ich dies aber eher verneinen. Ich habe mich beim Aufbau an diversen größeren und kleineren privaten und geschäftlichen Netzwerken orientiert. Die können wohl kaum alle falsch liegen, oder? Es macht aber mMn Sinn diese Konstellation eventuell in der Signatur mit einzubinden.
ZitatDu tust dir mMn. mit der aktuellen Plattform keinen allzugroßen Gefallen, die Docker/QNAP-Kombi vervielfältigt einfach noch die Zahl der möglichen Fehlerursachen...
Keine Ahnung ob es sinnvoll ist oder nicht. Das Problem ist, dass ich nachdem ich extra ein teures NAS (über 400€ plus Festplatten) angeschafft habe möchte ich natürlich nicht noch mehr Geld ausgeben. Abgesehen davon, dass es auch ein Platzproblem darstellt, da ich nicht wüsste wo ich den Raspi hinstellen sollte. Das soll keine Ausrede sein, ich hoffe nur, dass es meine Situation etwas verständlicher macht.
Mir ist bewusst, dass durch diese (seltene) Kombination die Zahl der Helfenden kleiner ist. Doch ich habe auch nur begrenzt Mittel und Möglichkeiten.
Zitat...aber eben nicht alle Baustellen auf einmal aufreißen!
Das mit den vielen Baustellen ist wohl unumgänglich wenn man beginnt ein Projekt aufzubauen. Man hat sehr viele Ideen, die man am liebsten auch gleichzeitig verwirklichen will.
Speziell wenn wie bei mir eine aktuelle Renovierung ein Zeitfenster öffnet und man während dessen den Zugang zu Stellen hat die sonst nicht einfach erreichbar sind. Da versucht man halt so viel wie möglich in so kürzester Zeit wie möglich durchzubekommen.
Das soll keine Rechtfertigung sein, sondern vielmehr eine Erklärung für viele Umstände. Ich bin auch nur ein normaler Kerl am Anfang einer Lernphase und werde deshalb wahrscheinlich auch noch viele Fehler machen. Ich kann nur hoffen, dass ich aus den Fehlern lernen kann und mit der Zeit immer mehr Verständnis der Materie bekommen werde. Doch das wird sicher viel Zeit kosten. Beschäftige mich ja auch erst seit ein paar Monaten mit dem Ganzen. In diesem Stadium habt ihr sicherlich auch Fehler gemacht und weiter gelernt. Leider weiß ich als Anfänger oft gar nicht wonach ich suchen muss bzw. welche Möglichkeiten es überhaupt gibt, deshalb ist es für mich wichtig manchmal auch mal ein praktisches Beispiel zu sehen statt nur Links zu irgendwelchen Artikeln, die ich zwar lese, aber oft nur teilweise oder gar nicht verstehe. Das Template für die Clever-Tanken Sache beispielweise, dass konnte ich mir ansehen und analysieren, es dann verstehen und daraus lernen wie das ganze funktioniert.
Als nächstes muss ich versuchen die Shelly's über MQTT statt dem Shelly-Modul anzusprechen, den Saugroboter einzubinden und mich mit DoIf beschäftigen. Dabei werde ich sicher Fragen haben und hier im Forum nachfragen. Ich kann nur hoffen, dass sich jemand findet, der mir auch dann so hilfreich zur Seite steht.
Zitat von: MarkoP am 27 August 2020, 12:21:44
Keine Ahnung ob es sinnvoll ist oder nicht. Das Problem ist, dass ich nachdem ich extra ein teures NAS (über 400€ plus Festplatten) angeschafft habe möchte ich natürlich nicht noch mehr Geld ausgeben. Abgesehen davon, dass es auch ein Platzproblem darstellt, da ich nicht wüsste wo ich den Raspi hinstellen sollte. Das soll keine Ausrede sein, ich hoffe nur, dass es meine Situation etwas verständlicher macht.
Dass das ärgerlich ist, ist mir klar, aber du hast es tatsächlich geschafft, mit dem Hinweis auf den immensen Platz- und Finanzaufwand für einen Pi (das kann auch ein älteres Modell sein...) ein Lächeln in mein Grinsen zu zaubern ;D .
ZitatMir ist bewusst, dass durch diese (seltene) Kombination die Zahl der Helfenden kleiner ist. Doch ich habe auch nur begrenzt Mittel und Möglichkeiten.Das mit den vielen Baustellen ist wohl unumgänglich wenn man beginnt ein Projekt aufzubauen. Man hat sehr viele Ideen, die man am liebsten auch gleichzeitig verwirklichen will.
Das Problem ist _auch_, dass du hier im Ausgangspost nicht klar mitgeteilt hast, dass du ein "spezielles" Umfeld hast - ich habe ehrlich gesagt nicht schlecht gestaunt, als du nach dem x-ten Post in dem anderen Thread dann irgendwann rausgelassen hast, mit was wir es zu tun haben. Da wäre es sehr wichtig gewesen, und auch die Reaktion von manchem "alten Hasen" wäre mit hoher Wahrscheinlichkeit deutlich anders ausgefallen. Als ich den Post hier gesehen habe, hatte ich nämlich erst die Vermutung, dass es - im Prinzip - um dasselbe Problem wie bei dem HTTPMOD, nicht um einen simplen Konfigurationsfehler...
Ansonsten: Mach es dir ruhig so schwer wie möglich, aber erwarte dann eben auch nicht, dass du viele Helfer findest. (Ich betreibe kein Firmen-like Netzwerk, sowas könnte ich gar nicht konfigurieren bzw. müßte mich einarbeiten => kein Bock; daher nutze ich auch eher einfachere Techniken und so wenig wie geht (W)LAN-Gedöns).
BTW: das einfache "Mache wenn" in FHEM heiß "notify". Lerne erst dessen Syntax, bevor du mit DOIF (das ist die korrekte Schreibweise!) anfängst (falls du das dann noch willst). Das mit der DOIF-Syntax ist nämlich wieder eine größere Baustelle, und du wirst dich auch da einfacher tun, wenn du die Basics zu FHEM allg. mal intus hast...
Wieder nur meine 2ct.
DHCP ist die Abkürzung für Dynamic Host Configuration Protocol - wildes Chaos kommt da Apriori nicht vor - es sei denn man lässt es zu. Ich sehe keinen Unterschied zwischen manuell angerichteten und automatisch konfiguriertem Chaos - beides ist möglich. Das meine ich ganz allgemein und auf niemanden persönlich bezogen.
Ist Chaos nicht die Grundlage für Evolution? :)
"nicht funktionierend" ist vielleicht ein relativer Begriff, da kann man philosophieren. Aus Sicht Deiner Netzwerkkabel war die Welt Ordnung, Dein HTTPMOD Device konnte das Internet nicht erreichen. Aus Deiner Sicht hat es nicht funktioniert.
Du machst es Dir unnötig schwer :-X
Ihr habt beide Recht mit dem schwermachen, ich wollte auch nur aufzeigen, dass es eben manchmal nicht ganz so einfach ist alles was man aufgebaut hat über den Haufen zu werfen und zu sagen nur weil die Menge es so macht muss ich jetzt auch so. Ich hatte mir ja was dabei gedacht als ich das NAS angeschafft habe. sicher nicht nur um darauf Fhem zu betreiben. Da sollen noch ganz andere Sachen/Server drauf laufen, dafür ist das Ding ja ausgelegt.
@Beta-User
Ich habe Erfahrungen mit einigen Programmiersprachen und auch viel damit gemacht. Von daher erwarte ich in meinen Abläufen viel Wenn, dann Situationen.
Und mir wurde in einem anderen Threat gesagt, dass für Bedingungen das DOIF wesentlich besser geeignet ist als dies in Pearl zu machen. Daher wollte ich mich mit DOIF auseinander setzen. Notifys habe ich schon einige, aber mehr als eine Bedingung bekomme ich damit nicht wirklich realisiert, geschweige denn aufeinander aufbauende Abhängigkeiten.
@Otto123
Du hast es ja eigentlich selbst beantwortet. Dynamic = Wechselhaft und Host Configuration = Fremdbestimmt (In dem Fall der Router).
Das bedeutet letztendlich doch nichts anderes, als dass der Host (in meinem Fall wäre das wohl die Fritzbox als Router) die IP's bei jeder Verbindung wechselnd der Reihenfolge nach neu vergibt.
Das bedeutet ich muss jedesmal feststellen, welches Gerät welche IP aktuell hat. Und da die IP's nach der Reihenfolge der Erstkommunikation vergeben werden, kann selbst die Reihenfolge untereinander wechseln.
Klar gibt es Möglichkeiten das einzuschränken, doch dann kann man auch direkt feste IP's vergeben und sich vorher Gedanken machen.
Aber ja, in einem stimmen wir diesbezüglich überein. Auch in einem statischen Netzwerk mit festvergebenen IP's kann man Chaos schaffen wenn man sich keine Gedanken über eine Struktur macht
Zitat von: MarkoP am 27 August 2020, 13:20:17
Ich habe Erfahrungen mit einigen Programmiersprachen und auch viel damit gemacht. Von daher erwarte ich in meinen Abläufen viel Wenn, dann Situationen.
Und mir wurde in einem anderen Threat gesagt, dass für Bedingungen das DOIF wesentlich besser geeignet ist als dies in Pearl zu machen. Daher wollte ich mich mit DOIF auseinander setzen. Notifys habe ich schon einige, aber mehr als eine Bedingung bekomme ich damit nicht wirklich realisiert, geschweige denn aufeinander aufbauende Abhängigkeiten.
...mir wurde auch irgendwann von irgendwem ins Ohr gepustet, dass das der Stein der Weisen wäre :P . Aktueller Stand hier ist: Ich habe irgendwann alle DOIF abgebaut, _nachdem_ ich in Perl einigermaßen eingearbeitet war (ich bin kein Programmierer oder ITler und war irgendwann ziemlich angenervt davon, dass selbst die DOIF-Experten immer am Rätseln waren, wie man denn nun bestimmte Probleme sinnvollerweise löst; ein Attribut anders, und das ganze verhält sich komplett anders...).
Gerade wenn du bereits programmieren kannst, ist eventuell das Stichwort myUtils hilfreich: Du gehst aus einem notify direkt auf die Perl-Ebene; da stehen dir dann alle Möglichkeiten offen... (Übrigens: auch der DOIF-Entwickler empfiehlt für komplexe Probleme, DOIF im perl-Modus zu betreiben, was im Prinzip fast auf dasselbe rauszulaufen scheint, wenn man mal davon absieht, dass die betreffende DOIF-Instanz dann auch dazu dienen kann, Informationen oder Zustände zwischenzuspeichern ;) .)
Auf der Perl-Ebene kannst du dann komplette Dispatch-Funktionen erstellen und Unterprogramme aufrufen, if-elsif-Ketten von beliebiger Länge und Verschachtelung basteln, und und und... (das mit den elsif-Ketten ist keine allzugute Praxis, aber es geht).
Zitat von: MarkoP am 27 August 2020, 13:20:17
@Otto123
Du hast es ja eigentlich selbst beantwortet. Dynamic = Wechselhaft und Host Configuration = Fremdbestimmt (In dem Fall der Router).
Das bedeutet letztendlich doch nichts anderes, als dass der Host (in meinem Fall wäre das wohl die Fritzbox als Router) die IP's bei jeder Verbindung wechselnd der Reihenfolge nach neu vergibt.
Das bedeutet ich muss jedesmal feststellen, welches Gerät welche IP aktuell hat. Und da die IP's nach der Reihenfolge der Erstkommunikation vergeben werden, kann selbst die Reihenfolge untereinander wechseln.
Nein - damit liegst Du komplett daneben, das sind Behauptungen :o :o :o - Ich weiß gar nicht warum sich so ein Quatsch in den Köpfen festsetzt und kein Schlauberger sich damit beschäftigt was wirklich passiert und möglich ist. Wie man die Geräte aufwendig und fehlerbehaftet per Hand "vor Ort" konfiguriert wird ja auch nachgelesen. Gerüchte verbreiten sich eben besser als Wahrheiten.
--- aber ich höre auf jetzt. Viel Erfolg mit ordentlichen IP Adressen. :P
@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.
Offtopik-Frage:
Habe mal keine Konfiguration in meine Signatur reingeschrieben. Reicht das so für einen ersten Überblick oder fehlt etwas?
@Otto123
Ich habe meine eigenen Erfahrungen mit DHCP gemacht und die waren durchweg negativ. Du wirst auch keinen vernünftigen IT'ler finden, der ein Netzwerk mit mehr als 50 Geräten mit DHCP betreut. Aber jedem steht es frei seinen eigenen Weg zu gehen und seine Meinung zu haben.
Dann sind die Admins die große Netzwerke mit hunderten und tausenden von Servern betreuen alle unvernünftige IT'ler - OT: fehlt in Deiner Signatur: Ich bin vernünftig
Zitat von: MarkoP am 27 August 2020, 14:15:32
@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).
ZitatOfftopik-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 ;) .
@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.
War mir jetzt nicht so direkt aufgefallen, aber wenn dem so ist, hast Du es immerhin geschafft sogar mich aus der Ruhe zu bringen :)
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)
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:
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:
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.
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
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 :P ...)
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 ;) ).
@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.
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
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
@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.
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...)
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.
Zitat von: MarkoP am 28 August 2020, 11:27:01
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
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).
Zitat von: Beta-User am 27 August 2020, 14:39:07Perl ist immer noch die Programmiersprache Perl und kein Versandunternehmen, keine Schallplatte von ...
... Zeiiiiiiiiiiiiiiiit die nieeeeeeeeeeeeeeeeee vergeht... ;D
Zitat von: MarkoP am 28 August 2020, 10:34:42
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.
Dazu packt man alle Auslöser in ein Notify und regelt dann intern per "if" was passieren soll. Hier mal meine alte Home- Funktion die auch noch ein Dummy als Statusanzeige nutzt (der Perl- Teil wäre auch hier besser in der myUtils aufgehoben, aber das konnte ich früher noch nicht):
Haus_Status|Zirk.*|Go_Out.*|Sleep.*|Garden.* {
my $aufruf1 = "$EVTPART0" ;
my $aufruf2 = "$NAME" ;
my $h_state = Value("Haus_Status") ;
my $h_state_o = OldValue("Haus_Status") ;
#Log 1, "Aufruf1:$aufruf1 ; Aufruf2:$aufruf2 ; h_state:$h_state ; h_state_o:$h_state_o" ;
if ($aufruf2 eq "Zirk") {
fhem("set Haus_Status Anwesend ; set OWA_HWR_SS_0 on ; sleep 90 ; set OWA_HWR_SS_0 off")
} ;
if ($aufruf2 eq "Go_Out") {fhem("set Haus_Status Haus_verlassen")} ;
if ($aufruf2 eq "Sleep") {fhem("set Haus_Status Schlafen")} ;
if ($aufruf2 eq "Garden") {fhem("set Haus_Status Garten")} ;
if ($aufruf1 eq "Anwesend" and $h_state_o ne "Anwesend") {
fhem("set TTS tts :Status_Anwesend.mp3:") ;
fhem("set FB_Control tam 1 off") ;
Log 1, 'Haus Status -> "Anwesend", TAM ausgeschaltet' ;
}
if ($aufruf1 eq "Haus_verlassen" and $h_state_o ne "Haus_verlassen") {
fhem("set Radio STOP") ;
fhem("set TTS tts :Status_Haus_verlassen.mp3:") ;
Log 1, 'Haus Status -> "Haus_verlassen", Tür Wählscript -> Handy, Radio aus';
}
if ($aufruf1 eq "Schlafen" and $h_state_o ne "Schlafen") {
fhem("set Radio STOP") ;
fhem("set TTS tts :Status_schlafen_gehen.mp3:") ;
fhem("set FB_Control tam 1 on") ;
Log 1, 'Haus Status -> "Schlafen", TAM eingeschaltet, Klingel stumm (TODO)' ;
}
if ($aufruf1 eq "Garten" and $h_state_o ne "Garten") {
fhem("set Radio STOP") ;
fhem("set TTS tts Status, bin im Garten") ;
Log 1, 'Haus Status -> "Bin im Garten", DECT Ein, Tür -> DECT Mobilteil' ;
system("/usr/bin/php /media/sd_intern/fhem/fritzbox_api/fritzbox_dect_on_off.php 1") ;
}
}Und der Dummy als List:
Internals:
FUUID 5cc16da4-f33f-fd76-51cf-04d078d4504b625b
NAME Haus_Status
NR 1088
STATE Anwesend
TYPE dummy
READINGS:
2020-08-30 08:43:50 state Anwesend
Attributes:
alias Anwesenheit
devStateIcon Anwesend:Haus_Status.Anwesend:Haus_verlassen Haus_verlassen:Haus_Status.Haus_verlassen:Schlafen Schlafen:Haus_Status.Schlafen:Garten Garten:Haus_Status.Garten:Anwesend
fp_0_Hauptbildschirm 182,47,2,Haus Status,
group 0_Status
room 0_ÜberblickGruß
Frank
...so, jetzt hat mich das mit PRESENCE doch interessiert in der nicht-pollenden FritzBox-Variante. Folgendes klappt:
defmod Android_Phone_presence PRESENCE event Fritzbox:mac_12_34_56_78_AB_CD:.inactive Fritzbox:mac_12_34_56_78_AB_CD:.A.*
attr Android_Phone_presence room Steuerung->Presence
setstate Android_Phone_presence present
setstate Android_Phone_presence 2020-08-30 07:22:04 .absenceThresholdCounter 0
setstate Android_Phone_presence 2020-08-30 07:22:04 .presenceThresholdCounter 0
setstate Android_Phone_presence 2020-08-30 07:49:54 model event
setstate Android_Phone_presence 2020-08-30 14:18:57 presence present
setstate Android_Phone_presence 2020-08-30 14:18:57 state present
(das Anwesenheit-Event muß man ggf. mit dem Event-Monitor auf den Hostnamen anpassen.). Und dann gibt es - Überraschung - ein entsprechendes Attribut beim ROOMMATE, in das man das eintragen kann.
So, habe die beiden Shelly, Aktoren samt den UP-USB-Dosen eingebaut.
Habs erstmal zum Testen über die Shelly-App (ich weiß Cloud-basiert) geprüft.
Der Aktor selbst wird nicht geschaltet und steht so ein, dass er nach einer Trennung vom Stromnetz automatisch auf "ein" geht.
Am USB-Anschluss ist ganz normal ein USB-Kabel an einer QI-Ladeschale angesteckt, die also wie normal unter Dauerstrom steht.
Wenn jetzt ein Handy auf die Ladeschale aufgelegt wird, wird der Verbrauch von 0W auf ca. 4,5W im Mittelwert verändert.
Darauf lässt sich mit einem Notify reagieren, wobei ich noch nicht weiß wie ich als Wert >0 bei einem Notify verwenden kann. Muss ich noch nachlesen.
Zumindest über das Shelly-Modul wurde der Verbrauch auch angezeigt, will es aber noch auf MQTT2-Server anpassen.
Dies in Kombination mit der Presence-Anwesenheitskontrolle lässt mich drei Zustände für mein Dummy abbilden: Zu Hause, Schlafend und Unterwegs.
Diese Zustände kann ich dann in allen Notify's, At's und und und abfragen und/oder darauf reagieren.
P.S.
Aufgrund eines vergessenen Config-Saves musste ich heute die Notify neu schreiben und siehe da, die gleichen Notify wie Freitag funktionieren jetzt tadellos. Muss irgendwo ein minimaler Schreibfehler drin gewesen sein den ich nicht gesehen habe.