Hallo,
ich habe damit begonnen meine ganzen Dummy-Definitionen in eine Gruppe von Modulen zu gießen.
Die Module beziehen sich alle aufeinander, können teilweise aber auch unabhängig eingesetzt werden.
Vorgesehen sind:
00_HOMESTATE
10_RESIDENTS
20_ROOMMATE
20_GUEST
Anbei ein erster Wurf der Module 10_RESIDENTS, 20_ROOMMATE und 20_GUEST.
Damit kann man die Bewohner und deren Status auf einfache Weise definieren und verwalten.
EDIT: Die Module 10_RESIDENTS, 20_ROOMMATE und 20_GUEST sind ab sofort im SVN eingecheckt. Die hier ggf. ladbaren Versionen sind Betas zukünftiger Versionen.
Beispiel:
define SesamStreet19 RESIDENTS
set SesamStreet19 addRoommate Oscer
set SesamStreet19 addRoommate Tiffy
set SesamStreet19 addGuest Guest
Damit werden die Bewohnergruppe "SesamStreet19" und deren Bewohner Oscer und Tiffy jeweils als Device angelegt.
Die Bewohner Oscer und Tiffy können entsprechende (Anwesenheit)Stati und Gemütszustände haben:
home = generell Zuhause
gotosleep = auf dem Weg ins Bett
asleep = schlafend
awoken = aufgewacht
absent = nicht Zuhause
gone = längere Zeit weg
Außerdem wird das Reading "mood" beim Wechsel zwischen den Stati automatisch geändert, wo es sinnvoll erscheint. Ansonsten kann das mood-Reading nach Lust und Laune einfach benutzt werden, um eigene Schaltungen entsprechend davon abhängig zu machen.
Je nach Anwesenheitsstatus ändert sich der Status von "SesamStreet19" entsprechend und kann folgende Stati haben:
present = einer oder mehrere Bewohner sind Zuhause und mindestens einer davon schläft nicht
gotosleep = (die letzten) Bewohner sind auf dem Weg ins Bett, während andere ggf. schon schlafen
asleep = alle Bewohner schlafen
awoken = mindestens ein Bewohner ist aufgewacht, andere schlafen noch oder gehen gerade ins Bett
absent = kein Bewohner ist Zuhause, mindestens einer ist aber bald zurück
gone = kein Bewohner ist Zuhause und alle sind längere Zeit weg
Ich würde mich freuen, wenn Interessierte die Module schonmal vorab testen würden. Das Modul 00_HOMESTATE wird nachgereicht, sobald es soweit ist ;)
Außerdem ist geplant, dass man für die Bewohner-Objekte durch einfache Befehle Vorlagen für sowas wie Wecker, Geolokation und generell Notifies und Watchdogs anlegen kann, die dann auch auf die Module entsprechend abgestimmt sind.
Gruß
Julian
hallo julian,
die idee finde ich klasse.
was mich auf den ersten blick stört ist das die zustände nicht 'logisch' und hierarchisch aufeinander aufbauen.
ich bin mir aber nicht sicher wie sich das am besten erreichen lässt. vielleicht ist es geschickter nicht nur ein reading zu verenden sondern mehrere und statt dessen zugriffsfunktionen zu haben.
wenn ich wissen möchte ob jemand anwesend ist sollte das true liefern egal ob er wach ist oder schläft, erst wenn ich wissen möchte ob jemand schläft sollte das true liefern wenn er schläft. false immer sonst. auch wenn er gar nicht anwesend ist.
das gleiche für den 'zustand' der ganzen wohnung: niemand da, einer da, alle da. egal ob schlafend oder wach. none sleeping, some sleeping, all sleeping.
mit readings/funktionen die den zustand so zurückliefen ist es denke ich einfacher etwas zu steuern: heizung auf frostschutz bei gone, aber ein bei anwesend egal ob schlafend oder nicht. zirkulation aus bei gone und schlafend und sobald einer anwesend ist zeit oder temperaturgesteuert.
gruss
andre
Ich werde noch ein Reading "presence" wie bei dem Media Modulen hinzufügen. Das ist dann entsprechend konsistent, Der Status sollte entsprechend dynamisch bleiben, siehe devIconState etc.
Achso noch als Nachtrag: Wieviele im jeweiligen Zustand sind, gibt es bereits als Reading. Dahinter steht eine Zahl 0 bis <Anzahl der Bewohner>. Darauf kann man auch Notifies setzen ;)
hab grad die screenshots gesehen. die gab es noch nicht als ich geschrieben hatte :)
gruss
andre
Zitat von: justme1968 am 19 Januar 2014, 23:54:55
hab grad die screenshots gesehen. die gab es noch nicht als ich geschrieben hatte :)
Tjaaaa Augen auf 8)
Finde die Idee auch klasse.
Ich überlege nämlich grade an der anderen Seite des Problems, nämlich wie man mit Zuständen übersichtlich die Schaltungen in der Wohnung ändern kann.
Äh, den Satz versteht jetzt keiner, gell ;)
So:
Anwesend, Tag
- Telefonanrufe laut mit TTS ansagen
- Bewegungen in der Hofeinfahrt laut ansagen
- Bewegungsmelder im Haus haben keine Funktion
- Lichtschalter im Haus schalten normal das Licht
- Heizung nach Wochenplan
Anwesend, Nacht
- Telefonanrufe TTS leise ansagen
- BewegungsmelderHofeinfahrt laut ansagen
- Bewegungsmelder im Haus machen gedimmtes Licht
- Lichtschalter schalten normal
Anwesend, Party
- Bewegungsmelder ohne Funktion,
Alarmanlage scharf
- Bewegungsmelder Hofeinfahrt startet Videoaufzeichnung
- Bewegungsmelder im Haus lösen Alarm aus
(- Schaltvorgänge im Haus lösen Alarm aus)
- Türklingel ohne Funktion
- Bewegungssimulation aktiv
Alarm
- Schalter lösen TTS Ansage aus, welcher Schalter betätigt wurde
- eMail wird verschickt
- Alle Lichter sind an
- Lichter lassen sich nicht ausschalten
So in etwa.
Was ich dazu brauche, ist eine gute Logik, wie man automatisch die Zustände umschalten kann.
Da wären deine Module vermutlich sehr praktisch :)
PS:
Du solltest evtl. oben deine Adresse entfernen?
So weiß ich, dass du 15 Autominuten weg wohnst ;)
Hallo Loredo,
Prima Sache! Wollte eigentlich Dein geofancy Modul loben und bin dabei auf Dein neues Projekt gestoßen. Sitze schon in der Stube und sehe das meine Frau gerade WORK verlassen hat... wenn ich ihr das erzählen würde wäre der WAF von FHEM mal wieder ganz unten.... von wegen Dauerüberwachung.
Da warte ich mal mit der Auswertung der geofency Daten und teste Deine neuen Module.
Zitat von: Rince am 20 Januar 2014, 10:33:09
Ich überlege nämlich grade an der anderen Seite des Problems, nämlich wie man mit Zuständen übersichtlich die Schaltungen in der Wohnung ändern kann.
Hi,
ich hab mir diesbezüglich mal das Modul LightScene angeschaut - sieht sehr nach dem aus, was man dafür so bräuchte.
Man kann für eine Liste von Geräten unterschiedliche "Scenes" speichern und abrufen. Das muss sich ja nicht auf Lichter beziehen, können wohl auch Solltemperaturen etc sein.
Werd mal damit rumprobieren.
Grüßle,
Uli
LightScene funktioniert für alles bei dem du mit einem get oder aus einem reading den aktuellen status abfragen und mit einem set wieder herstellen kannst.
im einfachsten fall ist es einfach state. aber du kannst konfigurieren welches reading oder welches get zum 'merken' und welches set zum wieder herstellen verwendet wird.
wenn das nicht reicht kannst du auch noch eine kleine funktion einhängen die den wert der gespeichert werden soll noch mal etwas aufbereitet (z.b. dim status aus einem reading holen, mit der funktion ein % zeichen entfernen damit es später bei set nicht im weg ist).
wenn auch das nicht reicht kannst du auch noch von hand das/die kommandos setzen die beim aktivieren einer szene für ein bestimmtest device verwendet werden sollen.
in der detail ansicht der szene kann man eigentlich auch in der ersten zeile den zustand zusammen klicken den man haben möchte und dann einfach save sagen und die näcshte szene zusammen klicken. da gibt es aber nach der letzten änderung von rudi leider gerade ein problem mit longpoll. das muss ich erst wieder reparieren.
gruss
andre
Eine kreative Idee :)
Aber wir laufen Gefahr den Thread zu kapern ;)
Hi,
stimmt - aber vielleicht verhinderts ja ne Doppelentwicklung.
Zu Lightscene also ggf weitere posts im Ordner "Automatisierung" - einen hab ich schon angelegt :)
=8-)
Nee Doppelentwicklung wird das hier nicht. ich merk schon, offenbar versteht ihr es noch nicht :-/
Dabei nehme ich an, dass das doch etwas ist, was wirklich jeder bei sich daheim haben will. Den Status der Bewohner möglichst automatisiert verfolgen und das Haus davon abhängig unterschiedlich zu steuern.
Die Module können hervorragend als Eingangsgröße verwendet werden, um dann bestimmte LightScenes (um die Brücke zu eurem Thema zu schlagen) zu schalten.
Zitat von: Loredo am 20 Januar 2014, 23:53:26
offenbar versteht ihr es noch nicht :-/
Mag sein :)
Kannst ja mal querchecken: http://www.fhemwiki.de/wiki/Zuhause-Status#Umsetzung_mit_LightScene
Gruß, Uli
ich weiss doch das es was anderes ist. ich hab es sogar probiert :)
und ich warte auf die fehlenden beiden.
gruss
andre
Zitat von: justme1968 am 25 Januar 2014, 13:05:38ich weiss doch das es was anderes ist. ich hab es sogar probiert :)
Na Gott sei Dank ;D Das demotiviert nicht mehr ganz so stark 8) Aber ich würde es so oder so für mich machen weil mir meine Konstruktion aus zusammengewürfelten Modulen viel zu instabil ist und langsam echt auf den Zeiger geht (besonders, wenn man mehr als nur ein Haus oder eine Wohnung zu administrieren hat).
Zitat von: justme1968 am 25 Januar 2014, 13:05:38
und ich warte auf die fehlenden beiden.
Ich verbringe gerade jeden Wochentag 11-12h im Büro und komme leider nicht so voran, wie ich es manchmal gerne hätte :-\
So, nachdem ich Geofancy nun teste, habe ich auch Deine Module installiert und mal eingerichtet.
Muss noch einen Zusammenhang mit Geofancy "basteln".
Noch steige ich noch nicht ganz durch ;)
Ich möchte mit Geofancy den HomeStatus auf Da oder weg tranken und dementsprechend eine Dinge schalten.
Im Moment mache ich das über WLAN und BT, ist aber nicht immer 100%tig.
Vielleicht magst Du mal eine kleine Doku zu Deinen Modulen schreiben und/oder ein paar Codeschnippsel dazu posten?
Zitat von: Mitch am 25 Januar 2014, 14:26:26
So, nachdem ich Geofancy nun teste, habe ich auch Deine Module installiert und mal eingerichtet.
Muss noch einen Zusammenhang mit Geofancy "basteln".
Noch steige ich noch nicht ganz durch ;)
Ich möchte mit Geofancy den HomeStatus auf Da oder weg tranken und dementsprechend eine Dinge schalten.
Im Moment mache ich das über WLAN und BT, ist aber nicht immer 100%tig.
Vielleicht magst Du mal eine kleine Doku zu Deinen Modulen schreiben und/oder ein paar Codeschnippsel dazu posten?
Wenn die Module mal fertig sind, gibts auch Doku ;)
Grundsätzlich werde ich eine Verknüpfung zu GEOFANCY herstellen, um die Integration einfacher zu machen.
Gruß
Julian
Ich dachte ich hätte es genau so geschrieben wie du es siehst.
Deine Module sind schlau den Status zu erkennen, Lightscene dann damit Dinge schalten lassen. Wir haben es nie anders gesehen :)
Leider bin ich immer noch relativ netzlos, sonst hätte ich es bestimmt schon probiert.
Mein Problem ist, dass ich nicht im Apple Biotop bin und das auch nicht möchte. Drum halte ich mich aus Geofancy raus. Werde das wohl mit Tasker und dem Google Kalender lösen müssen für unterwegs. Aber das gehört hier nicht rein :)
Zitat von: Rince am 25 Januar 2014, 18:11:54
Ich dachte ich hätte es genau so geschrieben wie du es siehst.
Deine Module sind schlau den Status zu erkennen, Lightscene dann damit Dinge schalten lassen. Wir haben es nie anders gesehen :)
Ich hatte Uli da schon anders verstanden, dich hingegen richtig ;) Zitat von: Rince am 25 Januar 2014, 18:11:54Mein Problem ist, dass ich nicht im Apple Biotop bin und das auch nicht möchte. Drum halte ich mich aus Geofancy raus. Werde das wohl mit Tasker und dem Google Kalender lösen müssen für unterwegs. Aber das gehört hier nicht rein :)
Der Schwenk zu Geofancy ist auch nur am Rande. Durch welche Ereignisse man den Status seiner Bewohner wiederrum ändert, das bleibt jedem selbst überlassen. Es kann direkt übers Webinterface sein, durch einen physischen Taster oder sonstwas. Ich benutze auch eine Kombination aus mehreren Sachen. Du kannst auch das PRESENCE Modul nehmen z.B., wenn es für dich gut funktioniert (ist ja u.U. so eine Sache).
ZitatDurch welche Ereignisse man den Status seiner Bewohner wiederrum ändert, das bleibt jedem selbst überlassen
Tja, in einigen Jahren sind wir hier bestimmt weiter :)
Erkennung an Hand der Sprache oder Bilderkennung.
Zitat von: Rince am 25 Januar 2014, 18:40:06
Tja, in einigen Jahren sind wir hier bestimmt weiter :)
Erkennung an Hand der Sprache oder Bilderkennung.
Aus FHEM Sicht fände ich das sicher gut ;)
Hallo
ich habe es jetzt auch einmal getestet und mir ist aufgefallen das ich nur folgende Statu habe
home = generell Zuhause
gotosleep = auf dem Weg ins Bett
absent = nicht Zuhause
gone = längere Zeit weg
hast du da etwas geändert oder ist da bei mir etwas falsch gelaufen
Danke
Zitat von: extraem am 25 Januar 2014, 22:38:04
Hallo
ich habe es jetzt auch einmal getestet und mir ist aufgefallen das ich nur folgende Statu habe
home = generell Zuhause
gotosleep = auf dem Weg ins Bett
absent = nicht Zuhause
gone = längere Zeit weg
hast du da etwas geändert oder ist da bei mir etwas falsch gelaufen
Das ist Absicht.
In der Webansicht werden nicht alle Stati angezeigt. Es fehlen die Zwischenstati "asleep" und "awoken", weil es für diese keinen Sinn macht, diese direkt auswählen zu können, wenn man nicht zuvor "gotosleep" als Status hatte. Man kann sie per Kommandozeile trotzdem setzen, das bleibt erhalten. Aber über die Weboberfläche ist quasi ein kleiner "Workflow" vorgesehen: Setzt man den Status auf "gotosleep", dann kann man den nächsten sinnvollen Status per Klick auf das Status-Icon erreichen (ist über das Attribut devStateIcon auch einsehbar).
Ich lade gleich mal eine neue Version hoch. Dort kann man alle Stati einblenden oder auch nur ganz bestimmte anzeigen lassen.
Gruß
Julian
Ich habe jetzt gerade im ersten Post http://forum.fhem.de/index.php/topic,19040.msg127329.html#msg127329 (http://forum.fhem.de/index.php/topic,19040.msg127329.html#msg127329) eine neue Version der Module 10_RESIDENTS und 10_ROOMMATE sowie die erste Version von 10_GUEST hochgeladen.
Unter der Haube hat sich eine ganze Menge getan:
- Man kann jetzt Mitbewohner/ROOMMATES und Gäste/GUESTS alleine unabhängig von der Bewohnergruppe/RESIDENTS betreiben.
- Man kann Mitbewohnern/Gästen auch mehr als eine Bewohnergruppe zuweisen.
- Man kann Mitbewohner und Gäste auch per normalem Define-Kommando anlegen
- eine ganze Menge neuer Readings
Die create-Funktionen funktionieren noch nicht. Auch sind einige Attribute noch ohne Funktion.
Ich mache mich jetzt zunächst ans 10_HOMESTATE Modul, um die Familie zu komplettieren.
Also irgendwie läuft es bei mir noch nicht rund.
Ich erhalten alle paar Stunden folgene Logmeldung üfr alle Anwohner:
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'alias'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'rr_autoGoneAfter'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'devStateIcon'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'group'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'icon'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'rr_locationHome'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'rr_locationOffice'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'room'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'sortby'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'webCmd'
kurz danach startet FHEM neu.
Das klingt jetzt eher nach einer lokalen Besonderheit deiner FHEM Installation.
Es gibt keine Funktion in den Modulen, die zeitgesteuert alle Bewohner löscht und wieder anlegt. Danach sieht es allerdings aus, denn die Attribute werden nur angelegt, wenn sie noch nicht vorhanden sind (was wiederum nur bei einem ganz frisch angelegten Bewohner der Fall ist).
Nachdem heute der 29. Januar und es dieses Jahr keinen 29. Februar gibt, habe ich gerade eine neue Version der Module hochgeladen ;D
(wer diese Nachricht entschlüsseln kann weiß, wovon er spricht ;) )
Hallo Loredo,
ich bin gerade damit beschäftigt einige Schaltzustände zu automatisieren bezogen auf die Anwesenheit..
Ich habe bereits zwei Dummys die mitsamt watchdog und Bluetooth Anwesenheit present und absent sauber arbeiten.
Deine Module habe ich eingefügt und die Wohnung RESIDENTS definiert.
Die beiden Dummys habe ich per addRoommate hinzugefügt...
Der Raum Residents wurde erstellt, soweit alles toll - aber...
sollte jetzt nicht wenn sich der state des Dummys ändert von present auf absent oder umgekehrt eine Reaktion innerhalb Residents kommen?
Zitat von: der-Lolo am 02 Februar 2014, 12:26:33
Hallo Loredo,
ich bin gerade damit beschäftigt einige Schaltzustände zu automatisieren bezogen auf die Anwesenheit..
Ich habe bereits zwei Dummys die mitsamt watchdog und Bluetooth Anwesenheit present und absent sauber arbeiten.
Deine Module habe ich eingefügt und die Wohnung RESIDENTS definiert.
Die beiden Dummys habe ich per addRoommate hinzugefügt...
Der Raum Residents wurde erstellt, soweit alles toll - aber...
sollte jetzt nicht wenn sich der state des Dummys ändert von present auf absent oder umgekehrt eine Reaktion innerhalb Residents kommen?
Dummy ist nicht der richtige Ausdruck, das sind auch eigene Module. Und ja, wenn sich an den Objekten vom Typ GUEST oder ROOMMATE etwas ändert, dann spiegelt sich das im zugewiesenen Eltern-Objekt (RESIDENTS) wieder und umgekehrt. Ob die Module sich gegenseitig richtig registriert haben, siehst du über den Readings in den Internals. Dort steht, welche Eltern- bzw. Kindobjekte registriert sind.
Gruß
Julian
PS: Notifies funktionieren gerade in der Version noch nicht. Ich habe gestern aber extrem lange daran getüftelt, um Beschränkungen von FHEM zu umgehen. Ich denke ich habe es jetzt soweit und werde später eine neue Version hochladen.
Hm - haben wir aneinander vorbei geredet?
Ich habe bereits zwei dummys gesetzt -
define wd_iPhone_away watchdog iPhone:absent 00:03 iPhone:present setstate wd_iPhone_here defined ;; setstate Micha absent ;; {Log 1, "Micha ist gegangen..."}
attr wd_iPhone_away regexp1WontReactivate 1
define wd_iPhone_here watchdog iPhone:present 00:00 iPhone:absent setstate wd_iPhone_away defined ;; setstate Micha present ;; {Log 1, "Micha ist nach Hause gekommen..."}
attr wd_iPhone_here regexp1WontReactivate 1
define Micha dummy
attr Micha event-on-change-reading state
attr Micha room develop
Roommate Micha reagiert aber nicht auf Änderung des Bluetooth Zustandes.
Als schnellschuss versuchte ich gerade setstate Micha in setstate rr_Micha zu ändern - aber auch das brachte keine Veränderung in der Ansicht Residents
Dein Dummy musst du durch ein ROOMMATE Objekt ersetzen, denn es ist überflüssig. rr_Micha wurde ja bei dir schon angelegt. Änderungen dort werden im RESIDENTS Objekt wiedergegeben.
Notifies kann man in der aktuell öffentlichen Version noch nicht zuverlässig auf die RESIDENTS/ROOMMATE/GUEST Objekte setzen (siehe http://forum.fhem.de/index.php/topic,19518.0.html). Ich habe in meiner Entwicklerversion das Problem schon gelöst, muss aber noch ein paar Bugs fixen, bevor ich die hoch lade.
Ok - wie gebe ich den Bluetooth zustand an das Roommate Objekt weiter?
setstate rr_Micha present funktioniert nicht - setpresence kann ich ja sicher nicht verwenden - oder?
Zitat von: der-Lolo am 02 Februar 2014, 13:00:19
Ok - wie gebe ich den Bluetooth zustand an das Roommate Objekt weiter?
setstate rr_Micha present funktioniert nicht - setpresent kann ich ja sicher nicht verwenden - oder?
Ganz einfach:
set rr_Micha home
set rr_Micha absent
Es ist ein eigenes, richtiges Modul und so will es auch behandelt werden. Es ist kein doofes Dummy Device ;-)
ok - das funktioniert...
gibst Du hier kurz bescheid wenn ich auf abwesend beider Bewohner per notify die Heizung regeln kann?
Ich habe jetzt Version 0.0.5 hochgeladen:
http://forum.fhem.de/index.php/topic,19040.msg127329.html#msg127329 (http://forum.fhem.de/index.php/topic,19040.msg127329.html#msg127329)
Neuerungen überschlagen:
- Trigger über Notify- oder Watchdog-Modul werden korrekt ausgelöst
- implizite Änderung der Location bei Statuswechsel zu home, absent oder gone
- konfigurierbar über Attribute r*_locationHome, r*_locationUnderway - implizite Änderung des Status bei Lokationswechsel:
- Lokation "underway" setzt den Status automatisch auf "absent", wenn der Status nicht bereits "gone" ist
- Lokation "home" setzt den Status automatisch auf "home", wenn "presence" zuvor "absent" war
- konfigurierbar über Attribute r*_locationHome, r*_locationUnderway - lastLocation wird nur aktualisiert, wenn diese Lokation nicht "underway" ist bzw. im Attribut r*_locationUnderway aufgeführt ist. Somit bleibt die tatsächlich zuletzt besuchte Lokation erhalten und der Status "unterwegs" wird nicht historisch behalten
- "Auf dem Weg nach Hause"-Tracker
- das Verlassen bestimmter Lokationen führt dazu, dass das Reading "wayhome" auf 1 gesetzt wird; auf welche Lokationen reagiert werden soll, kann mit Attribut r*_locationWayhome gesteuert werden
- das explizite setzen der Lokation auf "wayhome" hat den gleichen Effekt - lastMood wird nur aktualisiert, wenn mood nicht "-" ist
- "set device mood toggle" führt jetzt dazu, dass der aktuelle Mood mit dem vorherigen Mood getauscht wird
- Diverse Statistik-Readings
- letzte Ankunft (lastArrival)
- letztes Verlassen (lastDeparture)
- letztes Schlafengehen (lastSleep)
- letztes Aufwachen (lastAwake)
- letzte Dauer der Abwesenheit (lastDurAbsence)
- letzte Dauer der Anwesenheit (lastDurPresence)
- letzte Schlafdauer (lastDurSleep)
Die Statistiken lastDur* kann man sicherlich gut loggen und einen entsprechenden Plot daraus bauen. Da bin ich aber nicht so der Experte. Wer also Lust hat, darf hier sehr gerne unterstützen!GrußJulian
Zitat von: der-Lolo am 02 Februar 2014, 13:26:04
ok - das funktioniert...
gibst Du hier kurz bescheid wenn ich auf abwesend beider Bewohner per notify die Heizung regeln kann?
Bescheid.
Achso:
Wer das Geofancy-Modul einsetzt, braucht jetzt nur noch ein ganz einfaches Notify - z.B.
define n_rr_Julian notify geofancy:currLoc_Julian.* set rr_Julian location $EVTPART1
Ich habe meine Heimat-Lokation in der Geofancy.app mit dem ID-Namen "home" versehen. Der Status wird dann automatisch auf "home" gesetzt, wenn ich diese Lokation erreiche. Das Geofancy-Modul schickt als Lokation beim Verlassen "underway" und auch damit wird der Status automatisch auf "absent" gesetzt.
Über das Attribut r*_locationHome kann man mehrere Orte durch Leerzeichen getrennt eingeben, bei dessen erreichen der Status automatisch auf "home" gesetzt werden soll.
Über das Attribut r*_locationUnderway kann man mehrere Orte durch Leerzeichen getrennt eingeben, bei dessen verlassen der Status automatisch auf "absent" gesetzt werden soll.
Hallo zusammen,
ich habe mich entschieden, die aktuellen Versionen von 10_RESIDENTS, 20_ROOMMATE und 20_GUEST ins SVN als Version 1.0 einzuchecken 8)
Momentan überlege ich mir noch viele Details für das HOMESTATE Modul und ich dachte mir, vielleicht kommt auch noch mehr Input von euch, wenn ich die anderen Module schonmal offiziell bereit stelle. Sie sind ja auch in der aktuellen Form bereits sehr nützlich wie ich finde ;)
Gruß
Julian
Hallo Loredo,
Habe gestern Dein GEOFANCY mit Deinen neuen Modulen gekoppelt. Ist wirklich sehr gelungen und klappt auf Anhieb - erster live Test heute morgen beim Brötchen holen. Vorteil sehe ich u.a. im Wegfall der Bluetooth Lösung zur Ermittlung der iPhone Anwesenheit, die ja ohne Verrenkungen durch mailcheck über Freunde App oder zusätzlichen Einsatz von GEOFANCY erst merkt dass man daheim ist, wenn man bereits drin ist. D.h. Mail kommt, da die Eingangstür geöffnet wurde ( nervig ).
Was meinem Spieltrieb noch Grenzen setzt, sind die mood Attribute und der gotosleep State. Kannst Du bitte dazu mal ein Beispiel geben, wie das zu verwenden ist - speziell eine Idee wie FHEM merkt, dass ich auf dem Weg ins Bett bin. Was ich mit Letzterem schalten könnte ist mir klar, aber einen Drucksensor unter ein Bettbein konnte ich meiner Frau noch nicht unterschieben ( Schlafzimmer ist bei uns sensorfreie Zone ).
Zitat von: det. am 09 Februar 2014, 11:10:29...aber einen Drucksensor unter ein Bettbein konnte ich meiner Frau noch nicht unterschieben ( Schlafzimmer ist bei uns sensorfreie Zone ).
Ich konnte mir ein Grinsen nicht verkneifen ;D
Zitat von: det. am 09 Februar 2014, 11:10:29Habe gestern Dein GEOFANCY mit Deinen neuen Modulen gekoppelt. Ist wirklich sehr gelungen und klappt auf Anhieb - erster live Test heute morgen beim Brötchen holen. Vorteil sehe ich u.a. im Wegfall der Bluetooth Lösung zur Ermittlung der iPhone Anwesenheit, die ja ohne Verrenkungen durch mailcheck über Freunde App oder zusätzlichen Einsatz von GEOFANCY erst merkt dass man daheim ist, wenn man bereits drin ist. D.h. Mail kommt, da die Eingangstür geöffnet wurde ( nervig ).
Ich überlege auch grad, ob ich die wackelige WLAN Konstruktion bei mir ganz abschaffe (nutze keine Fritzbox als AP und frage daher meinen TomatoUSB AccessPoint via SNMP ab und leider verschwindet das iPhone trotz aktiviertem WLAN Sync viel zu häufig und zu lange, so dass selbst Watchdog statt Notify als Trigger oftmals nicht genügt). Hab mich bisher nicht getraut, weil die Geofancy.app so unzuverlässig war. Die Geofency.app muss ich erstmal noch länger testen. Es kommt beispielsweise häufiger vor, dass ich beim Verlassen oder Betreten der Zone telefoniere und je nach Netzempfang bin ich dann ggf. im GSM Netz eingebucht, so dass parallel keine Internetverbindung via EDGE möglich ist und der Webhook in dem Moment nicht abgesetzt werden kann. Dem Entwickler von Geofancy.app hatte ich das bereits gesagt, er wollte Abhilfe schaffen, hat aber alles nur verschlimmbessert. Dem Geofency.app Entwickler muss ich das erst noch sagen ;)
Aber ich schweife ab...
Zitat von: det. am 09 Februar 2014, 11:10:29Was meinem Spieltrieb noch Grenzen setzt, sind die mood Attribute und der gotosleep State. Kannst Du bitte dazu mal ein Beispiel geben, wie das zu verwenden ist - speziell eine Idee wie FHEM merkt, dass ich auf dem Weg ins Bett bin. Was ich mit Letzterem schalten könnte ist mir klar, aber einen Drucksensor unter ein Bettbein konnte ich meiner Frau noch nicht unterschieben ( Schlafzimmer ist bei uns sensorfreie Zone ).
Also gedacht habe ich mir bisher folgendes:
Mood kann man eigentlich als universelles Leerfeld ansehen. Es muss nicht zwingend den Gemütszustand widergeben, man kann die Liste ja anpassen und da alles reinschreiben, was man möchte.
Die Grundidee war die, dass jeder Mitbewohner dem Haus mitteilen kann, wie es zum aktuellen Zeitpunkt auf ihn reagieren soll. Der Gemütszustand erschien mir da sinnvoll. Beispielsweise könnten die HUE LED Lampen entsprechend andere Farben annehmen, wenn ich gestresst bin oder wenn ich mich entspannen möchte. Ebenso wäre es denkbar, dass die Farben sich entsprechend verändern, wenn ich einen bestimmten Raum betrete oder verlasse (wobei das automatische Tracking da wohl noch schwierig ist; iBeacons könnten hier die Lösung sein, aber ich hab noch nichts damit probiert). Man kann aber auch die Heizung unterschiedlich warm stellen; wenn mir kalt ist, wird die Heizung eben höher gestellt und die LEDs werden etwas 'wärmer' gestellt oder so 8)
Wenn ein Mitbewohner noch "sleepy" ist könnte man genauso das Licht anders dimmen, als wenn er bereits voll wach ist. Ich glaub da kann man noch lange drüber nachdenken und irgendwem wird immer etwas Neues einfallen. Ich bin da sehr gespannt auf die Kreativität anderer!
Der State gotosleep ist sinnvollerweise nicht automatisch zu setzen (mir fällt keine zuverlässige Methode ein; Drucksensoren sind wirklich extremer overkill und außerdem bin ich ja dann schon am/im Bett...).
Gedacht ist, dass man den Status gotosleep manuell dann setzt (über Handy, Tablet, gekoppelte Fernbedienung, Taster oder whatever), wenn man beispielsweise im Wohnzimmer sitzt und sich bettfein machen will. Die technischen Geräte (TV etc) könnten ausgeschaltet werden und eine bettfreundliche Lichtstimmung könnte abgerufen werden (bei mir wird die HUE Lampe am Nachttisch auf 2000 Kelvin gestellt), die einen zunächst ins Bad und anschließend ins Bett weiter trägt. Je nach Lebensgewohnheit kann man das unterschiedlich handhaben; wenn man immer zusammen ins Bett geht, kann man das auf Grundlage einer RESIDENTS Gruppe schalten, man kann aber auch pro Mitbewohner entsprechend etwas schalten. Der TV sollte vielleicht an bleiben, wenn man schonmal vor geht und die Lichtstimmung sollte nur außerhalb vom Wohnzimmer angepasst werden etc....
Im Bett angekommen habe ich rechts und links jeweils einen Funk-Taster installiert. Die obere Taste steuert die HUE Nachttischlampe (welche mich morgens auch mit 5300 Kelvin weckt). Die untere Taste schaltet vom Status gotosleep weiter zu asleep. Danach geht per Watchdog nach 5 Sekunden das Licht aus und der MP3 Funkgong wünscht mir eine gute Nacht. Morgens wird der gleiche Schalter betätigt, sobald ich am Aufwachen bin und der Status wechselt zu "awoken". Das wäre der Zeitpunkt Kaffeemaschine zu starten, die Lichtstimmung etwas vom Aufwachlicht anzupassen, Musik einzuschalten oder was auch immer. Nach 75 Minuten wechselt der Status bei mir dann automatisch nach "home" weil ich annehme, dass ich dann "betriebsbereit" bin ;)
Darin hinein spielt bei mir auch noch der Haus-Status. Das Modul dafür schreibe ich gerade noch, es wird wohl umfangreicher als ich zunächst dachte. Grundsätzlich unterscheide ich bei mir jetzt schon zwischen Morgen, Tag, Abend und Nacht. Die Stati werden teilweise durch Weckprogramme beeinflusst. Das erkläre ich aber ein andermal und vor allem dann, wenn ich das HOMESTATE Modul entsprechend so habe. Mein eigener Workflow wird sich da wohl auch nochmal ändern. Wie das so ist, man muss sich erstmal selbst klar werden, bevor man es dann in ein Modul (was ja auch andere Wünsche als nur meine berücksichtigen können muss) gießt und es der Weltöffentlichkeit preis gibt ;D
das mit dem drucksensor ist gar nicht zum grinsen. ich denke das ist eine sehr einfache methode automatisch rauszufinden ob jemand im bett liegt. ich hab schon ein paar mal gelesen das dazu z.b. eine sitzbelegungsmatte aus einem autositz verwendet wird.
gruss
andre
Sowas hab ich mir auch schon überlegt. Ich denke da eher an einen endschalter der an den lattenrost montiert wird.
Zitat von: justme1968 am 09 Februar 2014, 13:28:23
das mit dem drucksensor ist gar nicht zum grinsen. ich denke das ist eine sehr einfache methode automatisch rauszufinden ob jemand im bett liegt. ich hab schon ein paar mal gelesen das dazu z.b. eine sitzbelegungsmatte aus einem autositz verwendet wird.
Das kommt wohl drauf an, ob man sich im Schlafzimmer nur zum Schlafen aufhält (und ich meine nichtmals unbedingt zwischenmenschliche Aktivitäten ;) ). In meinem Münchner Apartment nutze ich effizienterweise das Schlafzimmer tagsüber auch als Arbeitszimmer. Da kommt es auch mal vor, dass man sich einfach so aufs Bett setzt oder dort Dinge ablegt. Eine Druckmatte ist also nicht für jeden etwas denke ich 8)
nicht alleine. aber mit fhem zusammen. ich mache z.b. nachts meine handy aus. mit der matte und dem handyzustand könnte ich perfekt zwischen nicht zu hause und schlafen unterscheiden.
alleine nützt es also nicht unbedingt aber in kombination mit tageszeit oder helligkeit.
und mir fällt noch einiges ein. von licht/radio im bad einschalten beim aufstehen, ...
gruss
andre
Die Anwesenheit funktioniert bei uns mit Bluetooth sehr gut, der watchdog steht auf 4 Minuten und es gibt keine unberechtigten schaltvorgänge... Problematisch ist vielleicht wenn mal der Akku leer geht...
Als nächstes möchte ich die Heizung mit ins Spiel bringen, mir per Speak verpasste Anrufe sagen lassen und den Anrufbeantworter aktiv schalten wenn ich nicht da bin. Ein Mood Sport wäre noch toll, wenn ich nach dem joggen oder Radfahrern heimkomme kann das Bad ja schon dusch temperiert sein.
Unterschiedlich playlisten je nachdem wer heimkommt... Tolle Möglichkeiten gibt es...
Wenn André eh gerade mitliest... Gibt es eine Möglichkeit HUE Dummys zu erstellen? Ich habe eine logitech harmony ultimate - die kann HUE schalten - jeder Aktion einen Dummy zuweisen um FHEM darüber zu informieren was Multimedial gerade läuft wäre cool.
Ich glaube aber ich komme einfach nicht drumrum in irgendeiner weise noch IR schalten ins FHEM zu bringen. Dann könnte ich ja auch direkt auf die harmony lauschen und die Aktionen mitlesen.
Zitat von: justme1968 am 09 Februar 2014, 13:37:50
nicht alleine. aber mit fhem zusammen. ich mache z.b. nachts meine handy aus. mit der matte und dem handyzustand könnte ich perfekt zwischen nicht zu hause und schlafen unterscheiden.
alleine nützt es also nicht unbedingt aber in kombination mit tageszeit oder helligkeit.
Mein Leben ist da leider nicht so geregelt, als dass ich alle Eventualitäten in FHEM einprogrammieren könnte ;)
Ich arbeite eben selbst und ständig, wie man so schön sagt...
eben weil es nicht geregelt ist reicht ja ein input nicht. aber wenn man mehrere zusammen fasst kann man doch einiges abdecken. mal so als gedankenanstoss weil es mir gerade einfällt: vielleicht wäre das überhaupt noch etwas für diese module. meherer solcher inputs für eine person zusammen fassen. vielleicht mit gewichtung und daraus einen gesamt zustand zu machen. also z.b. die matte und das handy und den taster an der wand plus tageszeit plus zustand in der nacht davor.
@der-Lolo: das mit dem dummy verstehe ich nicht. wenn die harmony deine hue lampen schaltet kannst du das über notifys an den ganz normalen hue devices feststellen. devices die nicht wirklich vorhanden sind kann auch die harmony nicht schalten. der knackpnkt ist aber das die rückmeldung von der bridge asynchron ist. es dauert also immer das polling intervall bis du den status in fhem siehst.
das mit ir ist nicht so schwierig: das geht z.b. auch mit einem panstamp.
gruss
andre
Die ultimate triggert Aktionen, Fernsehen z.b. Ist tv an Verstärker an, dreambox an hdmi2 wählen.
Bluray ist z.b. TV an Verstärker an, dreambox an HDMI 3 wählen.
Jeder Aktion kann hue zugeordnet werden - wenn ich nun bluray wähle und hue Dummyxx dieser Aktion hinzufüge wüsste fhem was gerade abgeht.
Ok, beim Fernsehen oder bluray ist es nicht relevant weil ich ja auf PRESENCE der Geräte gehen kann...
Aber bei cd oder lp hören bekommt fhem davon nichts mit...
IR ist mir zu bastellastig - oder hast du etwas verkaufsbereites in der Schublade? ;-)
das mit dem dummy verstehe ich immer noch nicht. fhem kann keine events für nicht vorhandene hue geräte empfangen. und die vorhandenen kannst du ganz normal per notify überwachen.
gruss
andre
Hallo Loredo,
Danke für Deine ausführliche Antwort. Eines ist mir da erneut klar geworden, die Menschen sind verschieden. Ich stamme noch von der Sorte ab, wo Weckerklingeln bedeutet, rausspringen - waschen - schwarzen Kaffee hinterkippen und spätestens 10 min nach dem Klingeln im Auto auf Arbeit fahren. Snozzeln kam Jahrzehnte später und Umwelt hatten wir da auch keine, da hieß das noch einfach Natur. (O.T.)
Ich denke aber, hier entspinnt sich eine interessante Diskussion, was man alles machen kann. Bin sehr gespannt, da fällt mir gerade ein - die Nutzung der Withings Waage nach 22 Uhr ist ein sicheres. Indiez, dass es nach einem ausgiebigen Wannenbad gotosleep geht. Kann ich in meiner Familie also doch automatisch schalten und wenn GUEST ( zB. die Kinder ) da sind deaktivieren.
Ich habe die PRESENCE übrigens nicht auf der FB, sondern mit Bluetooth 4 Stick im Cubie2. Funktioniert bis auf die Erkennungshysterese beim Heimkommen prima. Das Problem mit gleichzeitigem Telefonieren beim Zonenwechsel hatte ich noch nicht, mglw. weil ich im Auto über Multicard mit dem Autotelefon telefoniere. Kann sein, das iPhone sendet da parallel.
Zitat von: der-Lolo am 09 Februar 2014, 14:31:20
Die ultimate triggert Aktionen, Fernsehen z.b. Ist tv an Verstärker an, dreambox an hdmi2 wählen.
Bluray ist z.b. TV an Verstärker an, dreambox an HDMI 3 wählen.
Jeder Aktion kann hue zugeordnet werden - wenn ich nun bluray wähle und hue Dummyxx dieser Aktion hinzufüge wüsste fhem was gerade abgeht.
Ok, beim Fernsehen oder bluray ist es nicht relevant weil ich ja auf PRESENCE der Geräte gehen kann...
Aber bei cd oder lp hören bekommt fhem davon nichts mit...
IR ist mir zu bastellastig - oder hast du etwas verkaufsbereites in der Schublade? ;-)
Klingt aber ehrlich gesagt eher ein wenig so, als wolltest du die Harmony bald mal durch FHEM ersetzen ;)
(ok, zugegeben, dafür muss optimaler Weise alles per Netzwerk erreichbar sein...)
Zitat von: det. am 09 Februar 2014, 15:51:13
Danke für Deine ausführliche Antwort. Eines ist mir da erneut klar geworden, die Menschen sind verschieden. Ich stamme noch von der Sorte ab, wo Weckerklingeln bedeutet, rausspringen - waschen - schwarzen Kaffee hinterkippen und spätestens 10 min nach dem Klingeln im Auto auf Arbeit fahren. Snozzeln kam Jahrzehnte später und Umwelt hatten wir da auch keine, da hieß das noch einfach Natur. (O.T.)
Naja, wenn auf mich ein 12h Stresstag wartet (und das ist momentan täglich der Fall...), dann will ich wenigstens noch angenehm geweckt werden und mich nicht schon am frühen morgen stressen lassen :D
Wenn ich den Status "awoken" setze heißt das ja nicht, dass ich da nicht aufstehe. Es ist bei mir der Status "ich bin jetzt aufgestanden, Haus mach mal was!". Da ich aber nicht fix und fertig wie aus dem Ei gepellt aufstehe, bleibt der Status bei mir noch eine Weile auf "awoken", während ich Kaffee trinke und News lese. Auch bleibt der Rollladen solange noch halb geschlossen, damit ich mich unbeobachtet von der Dusche zum Schrank bewegen kann ;D
ZitatÜber das Attribut r*_locationHome kann man mehrere Orte durch Leerzeichen getrennt eingeben, bei dessen erreichen der Status automatisch auf "home" gesetzt werden soll.
Über das Attribut r*_locationUnderway kann man mehrere Orte durch Leerzeichen getrennt eingeben, bei dessen verlassen der Status automatisch auf "absent" gesetzt werden soll.
Kann diese Attribute im Webinterface weder bei Geofancy noch bei Residents finden...gibts die noch?
(http://forum.fhem.de/webkit-fake-url://9FADD6CA-ADC8-4C14-B006-36A83AE1DC3F/imagejpeg)
Zitat von: HolyMoly am 11 Februar 2014, 17:34:12
Kann diese Attribute im Webinterface weder bei Geofancy noch bei Residents finden...gibts die noch?
Die Attribute machen nur bei ROOMMATE und GUEST Objekten Sinn, daher gibt es sie in RESIDENTS nicht.
Hallo Julian,
ich hab gedacht ROOMMATE ist für Mitbewohner d.h. weniger Rechte, weniger Daten sammeln etc. und GUESTS noch eine Stufe drunter.
Daher habe ich keine Roommates angelegt, nur Residents=Bewohner. Dabei macht es eigentlich nur Sinn eine Residents Instanz zu haben pro Haushalt. Irgendwie ist da die Namensgebung nicht intuitiv. Vielleicht sollte Residents Household heißen und Roommate Resident.
Lg Julian
Zitat von: HolyMoly am 12 Februar 2014, 08:31:58
ich hab gedacht ROOMMATE ist für Mitbewohner d.h. weniger Rechte, weniger Daten sammeln etc. und GUESTS noch eine Stufe drunter.
Daher habe ich keine Roommates angelegt, nur Residents=Bewohner. Dabei macht es eigentlich nur Sinn eine Residents Instanz zu haben pro Haushalt. Irgendwie ist da die Namensgebung nicht intuitiv. Vielleicht sollte Residents Household heißen und Roommate Resident.
Das geht eigentlich aus der Dokumentation klar hervor. RESIDENTS heißt übersetzt Bewohner und stellt somit die Summe aller Bewohner dar (bzw. eine Bewohnergruppe). ROOMMATE heißt Mitbewohner und ist also die tatsächliche Person, die dauerhaft hier wohnt. Sie kann Mitglied einer oder mehrerer Bewohnergruppen sein. GUEST Objekte sind ähnlich zu ROOMMATE Objekten, verhalten sich aber in einigen Punkten unterschiedlich.
Die Verwirrung kommt wohl auch daher, dass wir im Deutschen nicht so genau zwischen Bewohner und Mitbewohner und deren Ein- und Mehrzahl unterscheiden... ich hoffe aber es ist nun klarer :-)
Wenn ich die nächsten Tage mal dazu komme wollte ich deine Module mal für meinen Gebrauch testen, das könnte genau das sein was ich suche/benötige.
Eine Bitte, oder eine Idee von mir. Könntest du evtl eine Muster Konfiguration bauen die in die Fhem.Demo.cfg übernommen werden könnte? Das macht es viele nicht nur transparenter.
Zitat von: svenson08 am 15 Februar 2014, 15:06:42
Eine Bitte, oder eine Idee von mir. Könntest du evtl eine Muster Konfiguration bauen die in die Fhem.Demo.cfg übernommen werden könnte? Das macht es viele nicht nur transparenter.
Meinst du zusätzlich zu den Beispielen in der Kommando-Referenz?
http://fhem.de/commandref.html#ROOMMATE (http://fhem.de/commandref.html#ROOMMATE)
Was schwebt dir denn vor?
Das Beispiel "Complex family structure" sollte eigentlich schon alles abdecken (zusätzlich zum Beispiel aus dem RESIDENTS Modul, aber das sollte wohl jeder hinbekommen). Oder sprichst du vom Zusammenspiel mit GEOFANCY? Auch da muss man eigentlich nur Copy&Paste das Beispiel kopieren und ggf. mal den Wiki Artikel dazu lesen ;-)
Das folgende Beispiel zeigt eine 4-köpfige (potentiell durchschnittliche) Familie :-)
#----------------------
# Define groups Residents, Parents, Children and Guests
define rgr_Residents RESIDENTS
attr rgr_Residents alias Residents
attr rgr_Residents sortby 1
define rgr_Parents RESIDENTS
attr rgr_Parents alias Parents
attr rgr_Parents sortby 2
define rgr_Children RESIDENTS
attr rgr_Children alias Children
attr rgr_Children sortby 3
define rgr_Guests RESIDENTS
attr rgr_Guests alias Guests
attr rgr_Guests sortby 4
#----------------------
# Add residents to groups
define rr_Manfred ROOMMATE rgr_Residents,rgr_Parents
attr rr_Manfred rr_locationHome Living Bedroom Kitchen Bathroom
attr rr_Manfred rr_locationWayhome Work Sport Parents herParents
attr rr_Manfred rr_passPresenceTo rg_Guest1
define rr_Lisa ROOMMATE rgr_Residents,rgr_Parents
attr rr_Lisa rr_locationHome Living Bedroom Kitchen Bathroom
attr rr_Lisa rr_locationWayhome Work Sport Parents hisParents
attr rr_Lisa rr_passPresenceTo rg_Guest2
define rr_Rick ROOMMATE rgr_Residents,rgr_Children
attr rr_Rick rr_locationHome Living Kitchen Bathroom myroom
attr rr_Rick rr_locationWayhome School Sport GrandparentsMom GrandparentsDad
define rr_Alex ROOMMATE rgr_Residents,rgr_Children
attr rr_Alex rr_locationHome Living Kitchen Bathroom myroom
attr rr_Alex rr_locationWayhome School Sport GrandparentsMom GrandparentsDad
define rg_Guest1 GUEST rgr_Residents,rgr_Guests
define rg_Guest2 GUEST rgr_Residents,rgr_Guests
#----------------------
# Define geofancy device and rename iPhone UUIDs to Usernames
# Geofency Webhhook address: http://myhome.dyndns.org:8083/fhem/geodefine geofancy GEOFANCY geo
attr geofancy devAlias A1234567-1234-ABCD-FFFF-123456789ABC:Manfred B1234567-1234-ABCD-FFFF-123456789ABC:Lisa C1234567-1234-ABCD-FFFF-123456789ABC:Rick D1234567-1234-ABCD-FFFF-123456789ABC:Alex
attr geofancy room System
#----------------------
# Notifies for roommate location updates via GEOFANCY
define n_rr_Manfred.location notify geofancy:currLoc_Manfred.* set rr_Manfred location $EVTPART1
define n_rr_Lisa.location notify geofancy:currLoc_Lisa.* set rr_Lisa location $EVTPART1
define n_rr_Rick.location notify geofancy:currLoc_Rick.* set rr_Rick location $EVTPART1
define n_rr_Alex.location notify geofancy:currLoc_Alex.* set rr_Alex location $EVTPART1
#----------------------
# iPhone Geofency.app webhook definitions:
#
# Manfred:
# - home > home address with low radius 100m
# - wayhome > home address with high radius of 5000m
# - Work > work address with low radius 200m
# - Sport > sport club address with low radius 100m
# - Parents > parents home address with low radius 100m
# - herParents > home address of Lisa's parents with low radius 100m
# - Living > Living room's iBeacon (with webhook for entry only)
# - Bedroom > Bedroom's iBeacon (with webhook for entry only)
# - Kitchen > Kitchen's iBeacon (with webhook for entry only)
# - Bathroom > Bathroom's iBeacon (with webhook for entry only)
#
# Lisa:
# - home > home address with low radius 100m
# - wayhome > home address with high radius of 5000m
# - Work > work address with low radius 200m
# - Sport > sport club address with low radius 100m
# - Parents > parents home address with low radius 100m
# - hisParents > home address of Manfred's parents with low radius 100m
# - Living > Living room's iBeacon (with webhook for entry only)
# - Bedroom > Bedroom's iBeacon (with webhook for entry only)
# - Kitchen > Kitchen's iBeacon (with webhook for entry only)
# - Bathroom > Bathroom's iBeacon (with webhook for entry only)
#
# Rick:
# - home > home address with low radius 100m
# - wayhome > home address with high radius of 5000m
# - School > School address with low radius 200m
# - Sport > sport club address with low radius 100m
# - GrandparentsMom > mom's parents home address with low radius 100m
# - GrandparentsDad > dad's parents home address with low radius 100m
# - Living > Living room's iBeacon (with webhook for entry only)
# - Bedroom > Bedroom's iBeacon (with webhook for entry only)
# - Kitchen > Kitchen's iBeacon (with webhook for entry only)
# - Bathroom > Bathroom's iBeacon (with webhook for entry only)
# - myroom > Rick's room iBeacon (with webhook for entry only)
#
# Alex:
# - home > home address with low radius 100m# - wayhome > home address with high radius of 5000m# - School > School address with low radius 200m# - Sport > sport club address with low radius 100m# - GrandparentsMom > mom's parents home address with low radius 100m# - GrandparentsDad > dad's parents home address with low radius 100m# - Living > Living room's iBeacon (with webhook for entry only)# - Bedroom > Bedroom's iBeacon (with webhook for entry only)# - Kitchen > Kitchen's iBeacon (with webhook for entry only)# - Bathroom > Bathroom's iBeacon (with webhook for entry only)# - myroom > Alex' room iBeacon (with webhook for entry only)
Folgende Annahmen sind darin berücksichtigt:
- Manfred und Lisa sind die Eltern und haben 2 Kinder, Rick und Alex
- alle 4 wohnen permanent in einem Haus(halt)
- alle 4 besitzen ein iPhone und tragen dieses eigentlich immer beisich
- in Wohnzimmer, Schlafzimmer, Küche, Badezimmer und den 2 Kinderzimmern sind iBeacons platziert
- Manfred und Lisa sind beide berufstätig, die beiden Jungs gehen zur Schule
- alle besuchen häufig die Großeltern sowohl mütterlicher- als auch väterlicherseits und fahren danach in der Regel wieder nach Hause
- alle Bewohner sind gerne beim Sport und kommen in der Regel direkt danach nach Hause
- nach der Arbeit oder der Schule kommen die Bewohner in der Regel direkt nach Hause
- es gibt zwei Gästezimmer
- Manfred kümmert sich um einen Gast, Lisa um den anderen Gast und Manfred und Lisa verlassen in der Regel gemeinsam mit ihrem Gast das Haus
Über den Status der Gruppen-Objekte rgr_Residents, rgr_Parents, rgr_Children und rgr_Guests lassen sich dann über entsprechende Trigger verschiedene Aktionen in FHEM anstoßen. Beispielsweise kann die Heizung heruntergefahren werden, wenn rgr_Residents auf absent ist bzw. wieder hochgefahren werden, sobald das Reading "wayhome" auf 1 springt. Auch könnte der Fernseher nur funktionieren, wenn die Eltern zu Hause sind. Die Heizung könnte wärmer eingestellt sein, wenn Gäste im Haus sind, damit sich diese wohler fühlen. Etc etc ...
Außerdem werden über die Readings natürlich auch verschiedene Statistiken bereitgestellt wie Dauer der Abwesenheit (pro Person, pro Personengruppe und generell wie lange das Haus verlassen war). Umgekehrt das gleiche für die Anwesenheitsdauer. Wenn die Bewohner zusätzlich (z.B. über einen Taster oder eben übers iPhone per Weboberfläche) anzeigen, wann sie schlafen gehen und wann sie aufgewacht sind, steht auch die Schlafdauer entsprechend zur Verfügung. Die ganzen Statistiken können natürlich per Plot ausgewertet werden (wobei ich das noch nicht gemacht habe).
Sehr schön. So was in der Richtung hab ich gemeint. Kannst evtl. Mal Rudi darauf ansprechen eine solche Musterkonfiguration in die fhem.Demo.cfg zu übernehmen. Das halte ich für wichtig, da sich damit anderen, Neulingen, leicht zeigen lässt was mit fhem alles möglich ist.
Ich habe mal drauf hingewiesen.
Was das gerade noch in Vorbereitung befindliche Modul HOMESTATE dann z.B. noch bieten wird ist, dass man sehen kann, welche Person sich in welchem Raum aufhält bzw. wie viele Personen sich in dem jeweiligen Raum aufhalten.
Ansonsten habe ich gerade noch folgendes für HOMESTATE gesammelt:
# season:spring,summer,autumn,winter
# mode:morning,day,evening,night
# shadowing:auto,on,manual,off
# heating:auto,on,manual,off
# ventilation:auto,on,manual,off
# cooling:auto,on,manual,off
# presenceSim:auto,on,off
# durPresence:TIME
# durAbsence:TIME
# durSleep:TIME
# roomXYZ: NUMBER
# roomXYZ_presence: present|absent
# roomXYZ_residents: Res1,Res2,Res3
# secSmoke:alarm,none
# secBurglary:alarm,none
# secDoors:secure,insecure
# secWindows:secure,insecure
# secShutters:secure,insecure
# secLights:on,off
# residentsPresence:present,absent
# residentsState:home,gotosleep,asleep,awoken,absent,gone
# state:?
Wie ich den Status aus diesen Werten berechne weiß ich noch nicht genau.
Sicher ist aber schon, dass ich wohl für die bessere Darstellung und Bedienbarkeit einzelne Readings direkt mit einem normalen Dummy-Device verknüpfen werde. Man kann dann in der Webdarstellung unter dem eigentlichen HOMESTATE Eintrag auch die einzelnen Punkte wie Modus etc. einzeln sehen und einstellen.
schau dir mal readingsProxy an. vielleicht ist das besser geeignet als ein dummy. das von hand hin und her kopieren per notify entfällt damit.
gruss
andre
Zitat von: justme1968 am 15 Februar 2014, 18:14:20
schau dir mal readingsProxy an. vielleicht ist das besser geeignet als ein dummy. das von hand hin und her kopieren per notify entfällt damit.
Ja, readingsGroup und readingsProxy wollte ich mir dafür anschauen. Bin aber nicht sicher, ob sich das so direkt eignet, damit es sich optisch auch so einbindet, wie ich mir das vorstelle (ohne es mir angesehen zu haben). Externe Notifies brauche ich auch bei den Dummies nicht; die kann ich zentral aus dem HOMESTATE Modul beobachten und entsprechend fernsteuern. Ich würde sie quasi nur als leere Hülle missbrauchen ;-)
Ähnlich würde ich wenn dann auch mit readingsProxy/readingsGroup verfahren wollen, damit es sich gut integriert. Wenn das nicht so geht, werde ich es lieber anders umsetzen.
ZitatIch habe mal drauf hingewiesen.
Stimmt.
Fuer fhem.demo.cfg brauche ich etwas, was ohne Hardware und zusaetzlichen Perl-Modulen auskommt, und idealerweise Lampen/Raeume/etc der bisherigen demo Konfiguration verwendet. Und dem Benutzer im Frontend ausser der puren Definition irgendetwas zeigt.
Idealerweise koennte diese Konfiguration auf fhem.de laufen, so dass jeder ein bisschen damit herumspielen kann.
Zitat von: rudolfkoenig am 16 Februar 2014, 10:37:13
Stimmt.
Das war vielleicht etwas forsch es über die Moderator-Funktion zu tun, andererseits wollte ich dich nicht privat anschreiben. Ein Dilemma, dass es keinen roten "Rudi" Knopf gibt (und ja, er würde sicherlich missbraucht werden :-\ )
Zitat von: rudolfkoenig am 16 Februar 2014, 10:37:13Fuer fhem.demo.cfg brauche ich etwas, was ohne Hardware und zusaetzlichen Perl-Modulen auskommt, und idealerweise Lampen/Raeume/etc der bisherigen demo Konfiguration verwendet. Und dem Benutzer im Frontend ausser der puren Definition irgendetwas zeigt.
Idealerweise koennte diese Konfiguration auf fhem.de laufen, so dass jeder ein bisschen damit herumspielen kann.
Mein Beispiel funktioniert ohne Hardware und auch ohne zusätzliche Perl-Module. Bleibt vielleicht dann nur noch die Verknüpfung mit den anderen Demo-Devices.
Was man leider nicht simulieren kann ist die Schaltung über ein iPhone, das man mit sich herum trägt. Aber man kann natürlich die Anwesenheit der Bewohner verändern und schauen was passiert. Ich würde folgendes einbauen:
- alles ausschalten, sobald kein Bewohner mehr zuhause ist
- einschalten einer Lampe, sobald einer der Bewohner nach Hause kommt
Das zweite Beispiel ist natürlich nicht wirklich aus der Praxis. Wenn wir noch eine Heizung hätten, die an und aus ginge, dann wäre das wohl etwas näher an der Wirklichkeit. Ich weiß aber nicht, ob man das sinnvoll simuliert bekommt ???
Vorschlag: Ich erweitere die fhem.demo.cfg einmal und du schaust dir hinterher an, ob du das Beispiel für sinnvoll hältst?
Gruß
Julian
Im Zusammenhang mit dem Callmonitor ist mir noch was eingefallen - wenn der Nachwuchs schläft - blinken statt klingeln...
Schade das unsere Sprechanlage nicht in FHEM integriert ist...
Ich bin fleißig mit deinen Modulen am experimentieren. Eins finde ich nicht ganz so schön. Dem Umstand geschuldet das nicht alle in meinem Haushalt Englisch können, wäre es schön es gäbe ein Attribut mit dem eigene Übersetzungen möglich wären um den Status entsprechend einzudeutschen. Schließlich möchte das alle Bewohner etwas von FHEM haben und nicht nur ich....
Mein Nachbar, den ich zu meinem leidwesen von FHEM begeistern konnte, hat das Problem das dessen Frau kein Englisch kann und dort wäre auch eine rein deutsche Übersetzung nicht zielführend.
Ich finde es allgemein schade das in FHEM keine Übersetzungsmöglichkeiten in andere Sprachen vorhanden sind, aber das gehört hier nicht hin.
Gruß Svenson
Ich bin begeistert! Gestern die Modulgruppe entdeckt und gleich damit rumgespielt. Bisher hatte ich das alles über Dummys, Notifier und LightScene gemacht. War ziemlich umständlich und alles andere als praktikabel.
Ein fettes Danke für die Arbeit!
Freut mich, wenn es auch andere nützlich finden :-)
jetzt musst Du nur noch die commandref zu Deinen Modulen in Ordnung bringen ;)
http://forum.fhem.de/index.php/topic,20752.0.html
Zitat von: svenson08 am 16 Februar 2014, 23:04:27
Ich bin fleißig mit deinen Modulen am experimentieren. Eins finde ich nicht ganz so schön. Dem Umstand geschuldet das nicht alle in meinem Haushalt Englisch können, wäre es schön es gäbe ein Attribut mit dem eigene Übersetzungen möglich wären um den Status entsprechend einzudeutschen. Schließlich möchte das alle Bewohner etwas von FHEM haben und nicht nur ich....
Mein Nachbar, den ich zu meinem leidwesen von FHEM begeistern konnte, hat das Problem das dessen Frau kein Englisch kann und dort wäre auch eine rein deutsche Übersetzung nicht zielführend.
Ich finde es allgemein schade das in FHEM keine Übersetzungsmöglichkeiten in andere Sprachen vorhanden sind, aber das gehört hier nicht hin.
Ja, für meine zweite Installation bei meinen Eltern hätte ich auch gerne möglichst viel eingedeutscht. Bei den Stati scheitert es allerdings, ja. Ich überlege mir bei Gelegenheit mal, wie man das am klügsten löst. Ich denke ich werde schauen, ob ich global für alle Module etwas direkt in FHEM hinzufügen kann, so dass man bei jedem Modul ein Attribut hat, mit dem man Aliase verwalten kann (ähnlich dem, wie sich die Kanal-Eingänge beim ONKYO_AVR Modul umbenennen lassen).
Zitat von: betateilchen am 28 Februar 2014, 11:37:04
jetzt musst Du nur noch die commandref zu Deinen Modulen in Ordnung bringen ;)
http://forum.fhem.de/index.php/topic,20752.0.html (http://forum.fhem.de/index.php/topic,20752.0.html)
Oh, danke. Darüber habe ich gar keine Mail-Benachrichtigung bekommen.
Puuuh. Also nach vielem Herumprobieren komme ich nicht weiter. Eigentlich wollte ich mit einem Notify eine bestimmet Lichtszene setzen, wenn sich der STATE einer Residentsgroop geändert hat.
Im Moment probiere es mit diesem Code:
#damit ich überprüfen kann, ob der Statusänderung wirklich kam, erst mal ein Dummy anlegen
define Testdummy dummy
#Residentgroop
define rgrBewohner RESIDENTS
#einen Bewohner anlegen
define Karsten ROOMMATE
#nun das Notify
define notiWohnungStatus rgrBewohner:state.* set Testdummy $EVTPART1
Allerdings kommt das Event scheinbar gar nicht an...
Das hier funktioniert auch nur bedingt. Es liefert nämlich alles mögliche zurück, aber nicht den state:
define notiWohnungStatus rgrBewohner.*:.* set Testdummy $EVENT
Wo liegt denn hier mein Fehler?
Ich fürchte du hast die Kommando-Referenz nicht genau gelesen :)
Daraus ist ersichtlich, dass du einem ROOMMATE Device auch sagen musst, ob und in welche Gruppe(n) es denn dazu gehört. Das fehlt bei dir, deshalb wird der Status auch nicht hoch aggregiert und dein RESIDENTS Device ist nutzlos.
Der Sinn dahinter ist, dass man ROOMMATE autark betreiben kann (machst du gerade), oder aber das Device auch Mitglied in mehreren Gruppen gleichzeitig sein kann. Dazu gibt es weiter oben auch ein komplexes Beispiel einer Familie.
#Residentgroop
define rgrBewohner RESIDENTS
#einen Bewohner anlegen
define Karsten ROOMMATE rgrBewohner
Das RESIDENTS Modul macht es dir eigentlich einfach, über die Oberfläche direkt einen neuen Bewohner hinzuzufügen. Schau mal nach dem Befehl addRoommate.
Verzeih, diesen Schritt hatte ich nicht gepostet, ihn aber durchgeführt. In der FHEM Config ist er eingetragen. Und das RESIDENTS Modul zeigt mir seine Kindobjekte auch an. Das RESIDENTS Modul bekommt auch den Status in Abhängigkeit des Bewohners den Status korrekt gesetzt. Es sieht nur so aus als ob ich ihn nicht auslesen kann.
So sieht es bei mir aus:
Ich glaube du möchtest nochmals die Kommando-Referenz für das NOTIFY Modul lesen ;)
define n_rgrBewohner.present notify rgrBewohner:presence:.present set Testdummy "Bewohner sind da!"
oder
define n_rgrBewohner notify rgrBewohner:state:.* set Testdummy $EVTPART1
Hallo Loredo,
darf ich fragen, wo man die iBeacons kaufen kann? Im Code Antwort #60 ist davon die Rede.
LG
/robin
Hallo Loredo,
ich hatte auch den Wikiartikel zum Notify-Modul "verspeist" und war mir relativ sicher, dass ich das richtig mache.
Leider funktionieren auch Deine beiden Vorschläge nicht. Was ich durch Herumprobieren herausgefunden habe ist, dass zum Beispiel der Status "lastState" sehr wohl an das Dummyobjekt übergeben wird. Wohl aber nicht der "state". Nun bin ich vollends verwirrt. Haut bei mir in der Installation einfach etwas nicht hin?
define n_rgrBewohner notify rgrBewohner:lastState:.* set Testdummy %EVTPART1
Ich bin völlig ratlos.
Zusatz:
Mit einer einfachen ReadingsGroup bekomme ich den Status von rgrBewohner allerdings zuverlässig ausgelesen.
define rgBewohner readingsgroup rgrBewohner:state
Vielen Dank für dieses geniale Modul! Zu Beginn dachte ich, dass es für mich zu speziell und zu sehr in die Tiefe geht, aber seit gestern weiß ich, dass es fast genau das ich was ich für mich realisieren wollte. ^^
Habe gestern und heute ein wenig rum probiert und es funktioniert wirklich gut. Ich habe die Anwesenheit von 2 Personen per Bluetooth gekloppt und schalte damit die Alarmanlage scharf sobald der Home State von "home" auf "absent" umspringt. Das klappt soweit sehr gut. Ich würde dies jedoch noch ein wenig erweitern. Die Alarmanlage sollte nämlich auch scharf sein, wenn der Status auf "gone" übergeht.
Außerdem sollte sich Abends zu einer bestimmten Uhrzeit der Status automatisch auf "gotosleep" stellen und damit wieder die Alarmanlage scharf stellen.
Hier ist ein Auszug meines Code:
define Alarmanlage dummy
attr Alarmanlage group Status der Alarmanlage
attr Alarmanlage room Alarmanlage
define Alarmanlage_Scharf notify Home:absent.* { fhem ("set Alarmanlage on") if (Value("Alarmanlage") ne "on") }
attr Alarmanlage_Scharf room Alarmanlage
define Alarmanlage_Unscharf notify Home:home.* { fhem ("set Alarmanlage off") }
attr Alarmanlage_Unscharf room Alarmanlage
Muss ich nun für jeden einzelne Status des Home States einen neues Notify anlegen oder lässt sich das irgendwie eleganter lösen?
Kurzer Zusammenfassung der Schaltstände:
home - Schaltung per Bluetooth - Alarmanlage AUS
gotosleep - Schaltung per Uhrzeit - Alarmanlage AN
absent - Schaltung per Bluetooth - Alarmanlage AN
gone - Schaltung per Uhrzeit - Alarmanlage AN
Vorab. Das Modul ist sehr hilfreich und erspart mir einiges an Ärger mit Dummys. Danke dafür.
Aus welchem Grund können Gäste nicht den Status "gone" haben? Es gibt jedoch das AutoGoneAfter Attribut. Schon dass ein Gast nicht "gone" sein kann ist in sich unlogisch, oder verstehe ich das falsch?
Kann es sein, dass der state nicht korrekt gemeldet wird?
Ich habe mal auf der Telnetkonsole ein inform on gemacht und vom Roommate Karsten den Status nach gotosleep, absent und home verändert.
Folgendes wirft inform on aus:
inform on
RESIDENTS rgrBewohner residentsHome: 0
RESIDENTS rgrBewohner residentsGotosleep: 1
RESIDENTS rgrBewohner lastState: home
RESIDENTS rgrBewohner gotosleep
RESIDENTS rgrBewohner lastActivity: gotosleep
RESIDENTS rgrBewohner lastActivityBy: Karsten
ROOMMATE rr_Karsten lastState: home
ROOMMATE rr_Karsten gotosleep
ROOMMATE rr_Karsten lastMood: calm
ROOMMATE rr_Karsten mood: sleepy
dummy Testdummy "Keiner da!"
RESIDENTS rgrBewohner residentsTotalPresent: 0
RESIDENTS rgrBewohner residentsTotalAbsent: 1
RESIDENTS rgrBewohner residentsGotosleep: 0
RESIDENTS rgrBewohner residentsAbsent: 1
RESIDENTS rgrBewohner lastState: gotosleep
RESIDENTS rgrBewohner absent
RESIDENTS rgrBewohner presence: absent
RESIDENTS rgrBewohner lastDeparture: 2014-03-02 20:37:31
RESIDENTS rgrBewohner lastDurPresence: 00:01:35
RESIDENTS rgrBewohner lastActivity: absent
RESIDENTS rgrBewohner lastActivityBy: Karsten
ROOMMATE rr_Karsten lastState: gotosleep
ROOMMATE rr_Karsten absent
ROOMMATE rr_Karsten lastMood: sleepy
ROOMMATE rr_Karsten mood: -
ROOMMATE rr_Karsten presence: absent
ROOMMATE rr_Karsten lastLocation: home
ROOMMATE rr_Karsten location: underway
ROOMMATE rr_Karsten lastDeparture: 2014-03-02 20:37:31
ROOMMATE rr_Karsten lastDurPresence: 00:01:35
Die Zeilen
RESIDENTS rgrBewohner gotosleep
RESIDENTS rgrBewohner absent
ROOMMATE rr_Karsten absent
fallen mir auf.
In allen anderen Zeilen steht immer das Attribut des Objektes vor der Eigenschaft. Ist das so korrekt?
Ich nehme nun statt des Attributes "state" das Attribut "lastActivity". Das hat die gleichen Werte und tut's auch.
Viele Grüße
Zephyr
Zitat von: Zephyr am 02 März 2014, 20:45:59
Die Zeilen
RESIDENTS rgrBewohner gotosleep
RESIDENTS rgrBewohner absent
ROOMMATE rr_Karsten absent
fallen mir auf.
In allen anderen Zeilen steht immer das Attribut des Objektes vor der Eigenschaft. Ist das so korrekt?
Ja, ist es. Das ist eine Besonderheit von FHEM selbst, das Reading "state" wird gleichzeitig auch als STATE interpretiert, also der Gesamtstatus, den du oben in den Internals siehst. Keine Ahnung, warum Rudi das so umgesetzt hat, er hat sicher seine Gründe.Du kannst ein Notify deshalb nicht auf das Reading "state" setzen, sondern nur direkt auf den Objekt-Status. Insofern war mein Beispiel nicht ganz akkurat.Das ist verwirrend, ich weiß. Kannst das ja mal in einem separaten Thread erfragen.Zitat von: marvin78 am 02 März 2014, 08:44:24
Aus welchem Grund können Gäste nicht den Status "gone" haben? Es gibt jedoch das AutoGoneAfter Attribut. Schon dass ein Gast nicht "gone" sein kann ist in sich unlogisch, oder verstehe ich das falsch?
Das ist schon logisch. Bei einem Gast macht es keinen Sinn, dass er längere Zeit abwesend ist, denn dann ist er tatsächlich einfach nicht vorhanden.
Ganz im Gegensatz zu einem dauerhaften Bewohner, der irgend wann auch wieder zurück kommt, wird ein Gast nicht notwendigerweise zurück kehren. Vielleicht wird es dir klarer, wenn du einmal die Beschreibung in der Kommando-Referenz für die beiden Stati "absent" und "gone" liest. Das Attribut AutoGoneAfter heißt bei allen Module so, damit es konsistent ist.
Zitat von: Spezialtrick am 01 März 2014, 21:34:14
Habe gestern und heute ein wenig rum probiert und es funktioniert wirklich gut. Ich habe die Anwesenheit von 2 Personen per Bluetooth gekloppt und schalte damit die Alarmanlage scharf sobald der Home State von "home" auf "absent" umspringt. Das klappt soweit sehr gut. Ich würde dies jedoch noch ein wenig erweitern. Die Alarmanlage sollte nämlich auch scharf sein, wenn der Status auf "gone" übergeht.
Außerdem sollte sich Abends zu einer bestimmten Uhrzeit der Status automatisch auf "gotosleep" stellen und damit wieder die Alarmanlage scharf stellen.
Hier ist ein Auszug meines Code:
define Alarmanlage dummy
attr Alarmanlage group Status der Alarmanlage
attr Alarmanlage room Alarmanlage
define Alarmanlage_Scharf notify Home:absent.* { fhem ("set Alarmanlage on") if (Value("Alarmanlage") ne "on") }
attr Alarmanlage_Scharf room Alarmanlage
define Alarmanlage_Unscharf notify Home:home.* { fhem ("set Alarmanlage off") }
attr Alarmanlage_Unscharf room Alarmanlage
Muss ich nun für jeden einzelne Status des Home States einen neues Notify anlegen oder lässt sich das irgendwie eleganter lösen?
Kurzer Zusammenfassung der Schaltstände:
home - Schaltung per Bluetooth - Alarmanlage AUS
gotosleep - Schaltung per Uhrzeit - Alarmanlage AN
absent - Schaltung per Bluetooth - Alarmanlage AN
gone - Schaltung per Uhrzeit - Alarmanlage AN
Ich bin ehrlich gesagt nicht ganz sicher, ob ich das so sinnvoll fände. Der Sinn dahinter, einfach zu einer bestimmten Uhrzeit auf "gotosleep" zu schalten, nur weil deine Alarmanlage eingeschaltet werden soll, erscheint mir falsch.
Ich fände es prima, wenn du für dieses Thema einen eigenen Thread aufmachst, denn im Grunde geht es hier um eine spezielle Automation, die mit den Modulen nichts zu tun hat.
Zitat von: fh168 am 01 März 2014, 17:52:31
darf ich fragen, wo man die iBeacons kaufen kann? Im Code Antwort #60 ist davon die Rede.
Wir haben uns diese hier bestellt:http://estimote.com
Zitat von: Loredo am 02 März 2014, 21:55:27
Das ist schon logisch. Bei einem Gast macht es keinen Sinn, dass er längere Zeit abwesend ist, denn dann ist er tatsächlich einfach nicht vorhanden.
Ganz im Gegensatz zu einem dauerhaften Bewohner, der irgend wann auch wieder zurück kommt, wird ein Gast nicht notwendigerweise zurück kehren. Vielleicht wird es dir klarer, wenn du einmal die Beschreibung in der Kommando-Referenz für die beiden Stati "absent" und "gone" liest. Das Attribut AutoGoneAfter heißt bei allen Module so, damit es konsistent ist.
Natürlich habe ich gelesen. Das macht es aber nicht logischer. Das Wort "gone" beschreibst genau das, was der Gast ist, wenn er nicht wieder kommt, nämlich "gone". Sollte er doch wieder kommen, war jedoch der Status "gone" auch richtig. Im Grunde ist es auch egal. Für mich bleibt es jedoch unlogisch und es beinhaltet eine gewisse inkonsistenz. Und logisch wird es nicht, weil man es als logisch definiert ;)
Zitat von: marvin78 am 03 März 2014, 06:41:30
Natürlich habe ich gelesen. Das macht es aber nicht logischer. Das Wort "gone" beschreibst genau das, was der Gast ist, wenn er nicht wieder kommt, nämlich "gone". Sollte er doch wieder kommen, war jedoch der Status "gone" auch richtig. Im Grunde ist es auch egal. Für mich bleibt es jedoch unlogisch und es beinhaltet eine gewisse inkonsistenz. Und logisch wird es nicht, weil man es als logisch definiert ;)
Letztendlich eine Frage der Definition. Ich habe sie eben so festgelegt. Dafür musst du meine Logik nicht nachvollziehen können, nur eben akzeptieren :)
Hallo Loredo,
ich möchte mich auch erst mal für das tolle Modul bedanken, habe aber auch ein Problem mit einem Notify.
Du schreibst als Beispiel:
Zitat
define n_rgrBewohner notify rgrBewohner:state:.* set Testdummy $EVTPART1
Damit funktioniert bei mir das Notify nicht.
Bei mir hatte ich es geändert in
define n_ANWESEND_R notify rgrResidents:presence:.* set ANWESEND_R $EVTPART1
Hinbekommen habe ich es jetzt weniger elegant mit
define n_ANWESEND_R notify rgr_Residents.presence.* {my $temp=ReadingsVal("rgr_Residents", "presence", "unknown");; fhem("set ANWESEND_R $temp") ;;}
Hast du eine Idee, warum das Notify nach deinem Beispiel nicht funktioniert? Zephyr scheint da ja auch ein Problem mit zu haben.
Gruß
Urga
Ja, es ist eine Eigenart von FHEM, dass für state kein Trigger ausgelöst wird.
Mein Beispiel war nicht ganz richtig, siehe oben.
Probiert
define n_rgrBewohner notify rgrBewohner:.(absent|gone) set Testdummy $EVTPART1
state erzeugt sehr wohl events. aber ohne reading namen und somit ohne ':'.
wenn man die regex anpasst kann man sehr wohl notifys darauf definieren. man muss nur aufapssen das diese nicht so generell sind das sie auch auf andere readings matchen.
gruss
andre
Zitat von: justme1968 am 04 März 2014, 21:43:06
state erzeugt sehr wohl events. aber ohne reading namen und somit ohne ':'.
wenn man die regex anpasst kann man sehr wohl notifys darauf definieren. man muss nur aufapssen das diese nicht so generell sind das sie auch auf andere readings matchen.
Das versteht aber kein Mensch, der nicht Modul-Maintainer ist. Das Beispiel gerade macht aber genau das, was du beschreibst :D Ich für meine Begriffe habe schon oft gedacht, dass es eigentlich so UND so gehen müsste bei State. Weiß wieder nur Rudi, was er sich da gedacht hat.
der ärgert sich glaube ich das er vielleicht nicht genug gedacht hat und es nicht mehr ändern kann ohne das es kompatibilitätsprobleme gibt :)
Ok. Das ist mir für heute Abend zu kompliziert. ;)
Das obige Beispiel funktioniert bei mir leider auch nicht. Vielleicht mach ich mich da noch mal dran wenn ich etwas Ruhe habe. Mein Code macht ja das, was er soll.
Trotzdem danke.
Zitat von: justme1968 am 04 März 2014, 22:00:50
der ärgert sich glaube ich das er vielleicht nicht genug gedacht hat und es nicht mehr ändern kann ohne das es kompatibilitätsprobleme gibt :)
Das ist die typische MS Denke, die wir Mac Jünger so gar nicht verstehen ^^
Altlasten gehören raus, auf Teufel komm raus. Scheiß auf die Abwärtskompatibilität ^^
Puuuuhh, ich fühle mich so langsam wie die Nervensäge vom Dienst...
Ich habe hier 'ne Konfiguration, die reproduzierbar zu einem Absturz von FHEM führt.
Zuerst einmal meine Config:
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define rgrBewohner RESIDENTS
attr rgrBewohner alias Residents
attr rgrBewohner devStateIcon .*home:status_available:absent .*absent:status_away_1:home .*gone:status_standby:home .*none:control_building_empty .*gotosleep:status_night:asleep .*asleep:status_night:awoken .*awoken:status_available:home
attr rgrBewohner group Home State
attr rgrBewohner icon control_building_filled
attr rgrBewohner room Residents
attr rgrBewohner webCmd state
define rr_Karsten ROOMMATE rgrBewohner
attr rr_Karsten alias Karsten
attr rr_Karsten devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown
attr rr_Karsten group Karsten
attr rr_Karsten icon people_sensor
attr rr_Karsten room Residents
attr rr_Karsten rr_showAllStates 1
attr rr_Karsten sortby 0
attr rr_Karsten webCmd state:mood
define rg_Dominik GUEST rgrBewohner
attr rg_Dominik alias Dominik
attr rg_Dominik devStateIcon .*home:user_available:absent .*absent:user_away:home .*none:control_building_empty:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown
attr rg_Dominik group Guests
attr rg_Dominik icon scene_visit_guests
attr rg_Dominik rg_realname alias
attr rg_Dominik rg_showAllStates 1
attr rg_Dominik room Residents
attr rg_Dominik sortby 1
attr rg_Dominik webCmd state:mood
define logLastDurSleep FileLog ./log/logLastDurSleep.log rr_.*:lastDurSleep:.*
define notiKarstenLastDurSleep notify rr_Karsten:lastDurSleep.* {Log 1, $NAME.":".$EVENT}
Mir ist klar, dass es eigentlich so gedacht ist, dass die Guests in eine eigene RESIDENTSGROUP gehören. Mir kam es aber darauf an, dass ich Licht und Heizung in Abhängigkeit des Status der gesamten Wohnung -in diesem Fall der rgrBewohner- schalten kann. Und wenn alle Gäste und so im Bett sind, geht die Wohnung in einen bestimmten Status über.
Der Fehler tritt immer dann auf, wenn ich beim GUEST Dominik den Status auf "asleep" umstelle.
Im Terminal des Linuxservers erhalte ich dann folgende Fehlermeldung:
Month '-1' out of range 0..11 at ./FHEM/20_GUEST.pm line 839
Und zwar zum einen auf meinem Produktivsystem und zum anderen auf meiner Debian Testinstallation.
Hab ich was kaputt gemacht? ^^
Zitat von: Zephyr am 05 März 2014, 21:17:31
Mir ist klar, dass es eigentlich so gedacht ist, dass die Guests in eine eigene RESIDENTSGROUP gehören.
Keineswegs, wie kommst du denn darauf?
Zitat von: Zephyr am 05 März 2014, 21:17:31Der Fehler tritt immer dann auf, wenn ich beim GUEST Dominik den Status auf "asleep" umstelle.Im Terminal des Linuxservers erhalte ich dann folgende Fehlermeldung:Month '-1' out of range 0..11 at ./FHEM/20_GUEST.pm line 839
Ich kann den Fehler bei mir nicht reproduzieren. Sicher, dass du die aktuelle Version aus dem SVN verwendest?
Hmmmmm... Auf dem Debian Testrechner sollte sie aktuell sein.
1.0.2 steht in dem Perldateien der Module.
Zitat von: Zephyr am 06 März 2014, 21:38:44
Hmmmmm... Auf dem Debian Testrechner sollte sie aktuell sein.
1.0.2 steht in dem Perldateien der Module.
Ich kann nur vermuten, dass es mit deiner Perl Version zu tun hat.
An Zeile 839 findet sich folgende. Prozedur:
sub GUEST_Datetime2Timestamp($) {
my ($datetime) = @_;
my ( $date, $time, $y, $m, $d, $hour, $min, $sec, $timestamp );
( $date, $time ) = split( ' ', $datetime );
( $y, $m, $d ) = split( '-', $date );
( $hour, $min, $sec ) = split( ':', $time );
$m -= 01;
$timestamp = timelocal( $sec, $min, $hour, $d, $m, $y );
return $timestamp;
}
Ich habe mit ein paar Zeilen Perl mal nachgestellt, was passiert:
my ($datetime) = @_;
my ( $date, $time, $y, $m, $d, $hour, $min, $sec, $timestamp );
( $date, $time ) = split( ' ', $datetime );
( $y, $m, $d ) = split( '-', $date );
print "Datum: ".$date."\n";
print "Vorher: ".$m."\n";
$m -= 01;
print "nachher: ".$m."\n";
Als Ergebnis bekomme ich folgendes:
Datum:
Vorher:
nachher: -1
Sieht mir verdächtig nach dem "Month '-1'" aus der Fehlermeldung aus. Kann es sein, dass die Variable $date nicht gesetzt worden ist?
Meine Perlversion ist 5.14.2 auf dem Debian.
P.S. Die Rechtschreibkorrektur von OS X macht aus "Perlversion" konsequent "Perversion". :D
Zitat von: Zephyr am 07 März 2014, 23:24:32
Ich habe mit ein paar Zeilen Perl mal nachgestellt, was passiert:
my ($datetime) = @_;
my ( $date, $time, $y, $m, $d, $hour, $min, $sec, $timestamp );
( $date, $time ) = split( ' ', $datetime );
( $y, $m, $d ) = split( '-', $date );
print "Datum: ".$date."\n";
print "Vorher: ".$m."\n";
$m -= 01;
print "nachher: ".$m."\n";
Als Ergebnis bekomme ich folgendes:
Datum:
Vorher:
nachher: -1
Dein Test ist fehlerhaft.Mach es so und du stellst wirklich nach, was passiert:my ($datetime) = "2014-03-07 23:31:23";
my ( $date, $time, $y, $m, $d, $hour, $min, $sec, $timestamp );
( $date, $time ) = split( ' ', $datetime );
( $y, $m, $d ) = split( '-', $date );
print "Datum: ".$date."\n";
print "Vorher: ".$m."\n";
$m -= 01;
print "nachher: ".$m."\n";
Ah, ich verstehe. :)
Jetzt wo $datetime einen Wert erhalten hat, funktioniert's natürlich. An der Funktion an sich scheint alles gut zu sein.
Heißt das nicht im Umkehrschluss, dass $datetime innerhalb der Funktion keinen Wert hat, wenn als Monat "-1" herauskommt? Da muss doch irgendwo das Problem liegen, oder?
Versteh mich nicht falsch, ich möchte hier nicht klugscheißen oder so.
Ich habe von Programmieren im Allgemeinen nur noch Informatikunterrichtskenntnisse und versuche so gut wie es geht mein Problem einzukreisen.
Woher bekommt denn $datetime seinen Wert, wenn der Status eines Gastes von "home" auf "asleep" wechselt?
Vielleicht finde ich dort ja das Problem.
Verzeih, wenn ich so nervig bin. :-/
Zitat von: Zephyr am 08 März 2014, 00:21:45
Woher bekommt denn $datetime seinen Wert, wenn der Status eines Gastes von "home" auf "asleep" wechselt?
Vielleicht finde ich dort ja das Problem.
Zeile 778-790 wird der Sleeptimer gesetzt.Ich bin mir eigentlich ganz sicher, dass kein Fehler im Code ist. Vielleicht ist deine Datei nur irgendwie korrupt. Lade sie doch mal neu von hier:http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/20_GUEST.pm?format=raw
Hallo,
ich habe die Datei nochmal runtergeladen. Leider besteht das Problem nach wie vor.
Ich schätze, dass die Zeilen, in denen der Sleeptimer gesetzt wird nicht ausschlaggebend sind.
Nach wie vor gehe ich davon aus, dass die Variable $datetime in der Funktion Datetime2Timestamp keinen Wert erhält und daher die gesamte Funktion als Monatsangabe "-1" ausspuckt.
In den Zeilen 778-790 keinen Wert.
Die Variable $datetime erhält nur ein einziges Mal im gesamten Script einen Wert zugewiesen.
Und zwar so:
my $datetime = TimeNow();
Ich habe versucht diese Funktion in einer Testdatei zu benutzen. Aber Perl bricht mit der Fehlermeldung ab, dass es die Subroutine nicht kennt:
Undefined subroutine &main::TimeNow called at
Vermutlich wird TimeNow an einer ganz anderen Stelle in FHEM definiert und daher funktioniert es in einem Testscript nicht.
Na ich suche mal weiter...
Viele Grüße
Zephyr
Man möge mich bitte steinigen.
Aus welchem Grund auch immer funktioniert es inzwischen auf der Debiantestinstallation. Nach noch zweimaligem Herunterladen der 20_GUEST.pm, einfügen von Logzeilen in der Hoffnung, zu erfahren was genau im Script passiert, versauen der 20_GUEST.pm und so weiter und so fort... funktioniert es einfach. ???
Entschuldige den Aufwand.
#edit vom 09.03.2014, 14:06
Nein, zu früh gefreut. Auch die Debiantestinstallation hat immernoch die gleichen Probleme. :(
In VirtualBox erhalte ich stattdessen beim Login die Absturzmeldung von unten:
Zitat von: Zephyr am 09 März 2014, 11:50:19
Nein, zu früh gefreut. Auch die Debiantestinstallation hat immernoch die gleichen Probleme. :(
Auch wenn das von dir beschriebene Verhalten bei mir absolut nicht reproduzierbar ist, so habe ich nach langem Suchen doch noch was entdeckt. Ich lade es gleich als Update ins SVN.
Gruß
Julian
Ist es der fehlende Start des sleep timers bei den Guests? :D
Bei Roommate die Zeilen 400 - 416 und bei Guest fehlt der Teil ab Zeile 405? ;)
Das habe ich nämlich gerade in diesen Minuten bei mir hinzugefügt. Und im Moment funktioniert es erst mal. Aber mal abwarten.
Zitat von: Zephyr am 09 März 2014, 21:42:13
Ist es der fehlende Start des sleep timers bei den Guests? :D
Bei Roommate die Zeilen 400 - 416 und bei Guest fehlt der Teil ab Zeile 405? ;)
Das habe ich nämlich gerade in diesen Minuten bei mir hinzugefügt. Und im Moment funktioniert es erst mal. Aber mal abwarten.
Exakt.
Oh wow! Und das hast du rausbekommen ohne meine Probleme direkt bei Dir nachvollziehen zu können?
Respekt! :D
Herzlichen Dank!
Zitat von: Zephyr am 09 März 2014, 22:34:40
Oh wow! Und das hast du rausbekommen ohne meine Probleme direkt bei Dir nachvollziehen zu können?
Respekt! :D
Naja, ist ja mein Modul. Da kenn ich mich schon ein wenig aus was da wo an welcher Stelle ist ;)
Hallo Loredo,
danke erstmal für Dein Modul, ich finde es toll und benutze es zur erkennung der anwesenheit mithilfe unsere handys (bluetooth) - ich möchte nun erweitern, im zimmer vom nachwuchs wird ein taster installiert, dieser soll erstmal den state schläft - oder ist wach einstellen... hierüber möchte ich die anrufbeantworter steuern und evtl. Sonos in der lautstärke begrenzen... ein asleep und woke up gibt es so aber ja noch nicht... wie würdest du das integrieren?
eine kleine frage noch - ich kämpfe eh schon mit freeze meldungen vom perfmon <3sek. , wenn aber jemand von uns das haus betritt oder verlässt sind es teilweise >12sek.
hängt das ausschliesslich mit Max zusammen - die heizköroer sind zur zeit das einzige was geschaltet wird in verbindung mit anwesenheit... oder liegt es auch vielleicht am Modul - verarbeitung und loggen der infos..?
Zitat von: der-Lolo am 17 März 2014, 12:36:11
ein asleep und woke up gibt es so aber ja noch nicht...
Doch, die Stati gibt es so wie auch in der CommandRef beschrieben!
Sie werden im Webinterface per Default ausgeblendet, können aber trotzdem gesetzt werden. Mit dem Attribut r*_showAllStates kann man im Webinterface auch asleep und awoken einblenden.
Der Hintergrund ist ganz einfach: Normalerweise geht man in einer bestimmten Reihenfolge schlafen ;-)
Und dieser Prozess soll dadurch unterstützt werden, dass nur gotosleep als Start im Webinterface angezeigt wird. Danach kann man mit einem Klick auf das devIcon den jeweils nächsten Status setzen (also asleep > awoken > home).
Das wird aber irrelevant, wenn man den Status ohnehin über einen Taster setzen möchte, so wie du es vor hast.
Ich mache das bei mir auch über einen Taster und kann es daher nur empfehlen.
Zitat von: der-Lolo am 17 März 2014, 12:36:11
eine kleine frage noch - ich kämpfe eh schon mit freeze meldungen vom perfmon <3sek. , wenn aber jemand von uns das haus betritt oder verlässt sind es teilweise >12sek.
hängt das ausschliesslich mit Max zusammen - die heizköroer sind zur zeit das einzige was geschaltet wird in verbindung mit anwesenheit... oder liegt es auch vielleicht am Modul - verarbeitung und loggen der infos..?
Das hängt wohl nur mit deinen Max Devices zusammen. Die RESIDENTS Modulgruppe verbraucht keine nennenswerten Ressourcen. Ich vermute, du hast bei keinem deiner Max Devices bisher das Attribut event-on-change-reading auf ".*" gesetzt. Das würde ich dir unbedingt empfehlen, es mindert die Last bei Trigger Events enorm.
Gruß
Julian
Hallo zusammen,
erstmal ein Dankeschön für das klasse Modul, mir gefällt es sehr gut und wenn ich dies nun noch mit meiner Bluetooth Abfrage verbunden bekomme, dann habe ich fast das was ich gesucht habe :-)
Nun sitze ich jedoch seit Tagen an einem Problem. Ich habe fast alles in eigene XX.cfg s ausgelagert. Nach anlegen der resident.cfg und übernehmen vom Beispielcode im ersten Post ist fhem nach einem rereadconfig.cfg nicht mehr gestartet. Ich bin also hingegangen und habe einen Teilvode irgendwann dann direkt in die fhem.cfg eingetragen um zu schauen was los ist. Erst dachte ich es liegt an der resident.cfg, weil wenn ich das include auskommentiert habe lief alles wieder.
Soeben bemerkte ich das follgender Code mein FHEM "tötet"
# Standalone
define rgr_Bewohner RESIDENTS
attr rgr_Bewohner alias Bewohner
attr rgr_Bewohner devStateIcon .*home:status_available:absent .*absent:status_away_1:home .*gone:status_standby:home .*none:control_building_empty .*gotosleep:status_night:asleep .*asleep:status_night:awoken .*awoken:status_available:home
attr rgr_Bewohner group Home State
attr rgr_Bewohner icon control_building_filled
attr rgr_Bewohner room Residents
attr rgr_Bewohner webCmd state
set rgr_Bewohner addRoommate Ralf
set rgr_Bewohner addRoommate Nina
set rgr_Bewohner addGuest Gast
nehme ich hier nun follgendes RAUS:
set rgr_Bewohner addRoommate Ralf
set rgr_Bewohner addRoommate Nina
set rgr_Bewohner addGuest Gast
kann ich fhem nach einem reboot von meinem BBB (wheezy) wieder starten bzw startet wieder automatisch. Updates sind auf dem aktuellen Stand. Aus der log erhalte ich lediglich als letzten Einträge:
2014.03.20 11:34:17 3: WEBhook: port 8088 opened
2014.03.20 11:34:17 1: Including FHEM/licht.cfg
2014.03.20 11:34:17 1: Including FHEM/light_scene.cfg
2014.03.20 11:34:17 1: Including FHEM/structure.cfg
2014.03.20 11:34:17 1: Including FHEM/bluetooth.cfg
2014.03.20 11:34:17 1: Including FHEM/radio.cfg
2014.03.20 11:34:17 1: Including FHEM/viewControl.cfg
2014.03.20 11:34:17 1: Including FHEM/ttsRec.cfg
2014.03.20 11:34:17 2: RESIDENTS set rgr_Bewohner addRoommate Ralf
2014.03.20 11:40:20 1: Including FHEM/licht.cfg
2014.03.20 11:40:20 1: Including FHEM/light_scene.cfg
2014.03.20 11:40:20 1: Including FHEM/structure.cfg
2014.03.20 11:40:20 1: Including FHEM/bluetooth.cfg
2014.03.20 11:40:21 1: Including FHEM/radio.cfg
2014.03.20 11:40:21 1: Including FHEM/viewControl.cfg
2014.03.20 11:40:21 1: Including FHEM/ttsRec.cfg
2014.03.20 11:40:21 1: Including ./log/fhem.save
da ich hier von einem Denkfehler bei mir ausgehe, hoffe ich auf Hilfe, denn so fit bin ich immer noch nicht mit fhem und so langsam auch am verzweifeln :-(
Hoffe doch das an so einem Sonnigen Tag jemand hier rein schaut :-)
Grüsse, Ralf
Zitat von: Kakaomonster am 20 März 2014, 11:43:05nehme ich hier nun follgendes RAUS:set rgr_Bewohner addRoommate Ralfset rgr_Bewohner addRoommate Ninaset rgr_Bewohner addGuest Gast
Set-Befehle gehören niemals direkt in eine cfg-Datei. Die Befehle müssen nur einmalig über das Web-Frontend ausgeführt werden und erzeugen dann die eigentlichen Objekte, die bei einem "save" auch ordnungsgemäß in der fhem.cfg abgespeichert werden. Natürlich kannst du sie anschließend von dort auch in deine gesonderte Datei verschieben. Wichtig dabei ist nur, dass die Reihenfolge der Objekte so bestehen bleibt (erst RESIDENTS Objekt, dann ROOMMATE und GUEST Objekte).Das wäre dir nicht passiert, wenn du die Config-Dateien nicht manuell editiert hättest. Dabei muss man schon genau wissen, was man tut. Ansonsten lautet die Empfehlung, alles ausschließlich über das Web-Frontend zu machen.GrußJulian
Hallo Julian,
danke für die schnelle Hilfe... UND...
MAAAANNNNN wie dumm kann man sein. Ist ja logisch :o ich glaube das wäre mir in den nächsten Tagen genau so wenig aufgefallen wie jetzt das ich die set Befehle drinnen hatte wo sie nicht hingehören :-( *grrrrrr*
Danke erst mal. Nun kann ich mir wieder an mein Bluetooth dran geben, damit dadurch der Status geändert wird :-)
Ich wünsche Dir noch einen schönen Tag,
Grüsse, Ralf
Hallo zusammen,
nach meinem dummen Fehler von oben komme ich nun auch weiter und natürlich, wie soll es anders sein hänge ich da auch wieder. Aber naja, learning by doing, so kam ich wenigstens zum aktuellen stand :-)
Vielleicht kann mir hier auch jemand schnell behilflich sein.
Aktuell ist es so, wenn mein BT nicht mehr erreichbar ist, geht mein Status auf "gone", wenn es daheim ist dann auf "Home", dass klappt auch super, auch wenn die Anzeige leider nicht automatisch aktualisiert, so klappt es jedenfalls.
Dies habe ich mit diesem Code hinbekommen:
define BT_abwesend notify BT_Anwesenheit:0 set rr_Ralf state gone;; set androidTablet ttsSay Ralf ist Abwesend, Licht wurde ausgeschaltet. Bitte manuelle Schaltung übernehmen!
define BT_anwesend notify BT_Anwesenheit:1 set rr_Ralf state home;; set androidTablet ttsSay Hallo Ralf, willkommen zurück
Sicherlich nicht die beste Lösung so wie ich bisher lesen konnte, aber anders konnte ich es aus eigener Kraft noch (NOCH) nicht umsetzen :-)
Nun möchte ich aber, dass von Status "Home" erstmal auf "Absent" gesetzt wird. Bin ich dann x Minuten später immer noch absent, dann soll es auf "gone" gesetzt werden. Ich bin der Meinung das schon gesehen zu haben, aber ich habe das Forum nun 2 mal hoch und runter gesucht, ich finde es nicht mehr.
Jemand einen schnellen Tip? Mit sleep geht es wohl scheinbar nicht (sleep und erneut prüfen) Habe auch diverse schnippsel aus der Anwesenheitserkennung versucht "umzubasteln" aber auch da komme ich nicht weiter.
Grüsse, Ralf
Hallo zusammen,
ich hab da mal ne Frage zum Roommate Modul.. Generell funktioniert das Modul ziemlich gut bei mir, der Status wird über Geofency aktualisiert und ich hab ein Reading gesetzt, was auf die Änderung in Status auf Home eine Lampe einschaltet. Soweit, so gut. Was ich aber gerne zusätzlich integrieren würde ist eine weitere Bedingung welche das Licht nur dann schaltet, wenn es dunkel ist.
Sprich: Wenn Home UND Dunkel dann an.
Was hätten wir auf Verfügung:
- das Twilight Modul mit den einzelnen Statu
- einen Dummy der dunkel bzw. hell ausgibt und auf 2 weitere Dummys referenziert welche aufgrund von sunrise / sunset die Ausgabe des Dummy´s auf Hell/dunkel stellt
Leider will das Roommate Modul aber leider keine Bedingung akzeptieren und weigert sich, die 2.te Bedingung neben dem Home status zu akzeptieren..
Jemand eine Idee wie ich das umsetzen kann bzw. ob das Roommate Modul das vllt. einfach garnicht kann?
Hallo Alex,
vielleicht hilft Dir hier mein Code weiter. Erklärung darunter.
define BT_Anwesenheit dummy
attr BT_Anwesenheit room BT_Anwesenheit
define BT_Anwesendcheck at +*00:00:01 {\
\
if (Value("BT_iPhone5") eq "absent" && Value("BT_iPhone5") eq "absent") {\
fhem("set BT_Anwesenheit 0") if (Value("BT_Anwesenheit") ne "0")\
}\
else {\
fhem ("set BT_Anwesenheit 1") if (Value("BT_Anwesenheit") eq "0");;;;\
}\
}
attr BT_Anwesendcheck room BT_Anwesenheit
#define BT_abwesend notify BT_Anwesenheit:0 set rr_Ralf state gone;; set androidTablet ttsSay Ralf ist Abwesend, Licht wurde ausgeschaltet. Bitte manuelle Schaltung übernehmen!
# Schaltung auf Abwesend und Anwesend WENN Tag oder Nacht mit Sprachnaricht
define BT_abwesend_Say_Tag notify BT_Anwesenheit:0 { if (isday()) { fhem("set androidTablet ttsSay Ralf ist verschwunden.") }}
define BT_abwesend_Say_Abend notify BT_Anwesenheit:0 { if (!isday()) { fhem("set androidTablet ttsSay Ralf ist weg.Licht wird ausgeschaltet.") }}
define BT_abwesend_liAus notify BT_Anwesenheit:0 set rr_Ralf state gone ;; set ambiEG_Wohnzimmer off
define BT_anwesend_Say_Tag notify BT_Anwesenheit:1 { if (isday()) { fhem("set androidTablet ttsSay Willkommen Ralf.Guten Tag.") }}
define BT_anwesend_Say_Abend notify BT_Anwesenheit:1 { if (!isday()) { fhem("set androidTablet ttsSay Willkommen Ralf.Guten Abend. Ambiente Licht eingeschaltet.") }}
define BT_anwesend_liAus notify BT_Anwesenheit:1 { if (!isday()) { fhem("set ambiEG_Wohnzimmer on") }}
define BT_anwesend_BTda notify BT_Anwesenheit:1 set rr_Ralf state home
Erklärung:
Ich komme nach Hause, per Bluetooth wird festgestellt das ich anwesend bin. Der Status wird auf HOME gesetzt, Sprachansage begrüsst mich je nach Tageszeit, ebenso wird Ambiente Licht eingeschaltet, aber nur wenn es dunkel ist. Umgestzt mit isday und !isday.
Ebenso wird beim verlassen eine Ansage durchgeführt und alles wird ausgeschaltet, egal ob Tag oder Nacht, da man ja ab und an auch am Tage Licht an macht und es vergisst auszumachen. Der Status wechselt auf GONE
Was mir fehlt ist, dass der Status ERSTMAl für x Minuten auf ABSENT wechselt und danach dann wenn ich nicht zurück komme auf gone.
Es wurde halt mit presence BT und isday bzw !isday umgesetzt. mit Sunrise/Twighlight bin ich noch dran, dass hat bei mir noch nicht so geklappt wie es soll.
Ich hoffe es ist das was Du meinst und es hilft ein wenig.
Grüsse, Ralf
PS: Das der Code nicht der schönste ist, weiß ich. Auch sicherlich nicht der Sinnvollste, aber erstmal funktioniert es. Vielleicht erbarmt sich ja einer der developer das in Kurzform SINNVOLL zu ändern :-)
Da fällt mir ein, wäre es nicht sogar eine möglichkeit sowas in ein eigenes Modul zu packen, indem man sowas als ungeübter per Dropdown lösen könnte? Ich habe mich mal daran versucht, es jedoch schnell wieder verworfen, da ich davon noch mehr als nur lichtjahre entfernt bin. Als Idee fände ich dies jedoch ganz gut, denn ich denke auch nicht coder sollten fhem doch in Zukunft einsetzen können. Dies ist im moment ja fast unmöglich. Also für jemanden der code noch niemals gesehen hat oder soll fhem auf dieser Basis auch in Zukunft laufen?
Das wäre eine Sinnvolle Frage an rudolf ob da schon was in Planung ist, wie es später weiter geht oder ob ich hier viel zu weit denke.
Oha, das ist irgendwie deutlich mehr als ich eigentlich möchte. Und um ehrlich zu sein ist der Code fast nicht umschreibbar da einfach zu viele Dinge enthalten sind, die bei mir nicht so umgesetzt sind.
aktuell sieht mein Code so aus:
rr_Alex:home set ku_Lampe_gross on-for-timer 576
[/size]
Das Thema ist halt die zweite Prüfung mit einzubauen, also z.B. Tageslicht:dunkel
Hallo Alex,
ok, ich habe grade wenig Zeit um es selbst durchzuspielen.
Da ich aktuell auch noch nicht so erfahren bin, würde ich es nun auf 2 Abfragen referenzieren, einmal das Du daheim bist mit Geaofancy Status auf Home setzen und dann dieses hier, wenn Status home UND NICHT TAG, dann lampe an. Keine Garantie!!!
define rr_Alex_home HomeStatus:home { if (!isday()) { fhem("set ku_Lampe_gross on-for-timer 576") }}
Ein Versuch ist es evtl,. Wert
Viel Glück, Ralf
@Alex : als alternative zur oft irre führenden syntax kannst du dir mal hier im forum unter automatisierung das IF-modul anschauen.
Danke für die Tips, ich probier das heute mal aus.
mit dem syntax funktioniert es schon einmal nicht...
hm schade, aber ok ... ich schaue morgen auch noch mal bei mir nach, da ich es ähnlich möchte. Bin aber grade noch dabei es hin zu biegen, dass die gone zeit verlängert wird auf X minuten bis es von away auf gone springt, da hier mein licht im mom noch an und aus geht, wenn mal BT beim prüfen versagt... passiert ab und an, wenn ich das hinbekommen habe schaue ich noch mal nach Deinem Problem. Scheint ja im moment niemand Hilfestellung sonst zu geben
Schönen Abend erstmal, Grüsse, Ralf
Zitat von: Kakaomonster am 20 März 2014, 12:33:56
Aktuell ist es so, wenn mein BT nicht mehr erreichbar ist, geht mein Status auf "gone", wenn es daheim ist dann auf "Home"
Das wäre aber nicht ganz korrekt. Es sei denn du fährst ständig für längere Zeit in den Urlaub. Wenn du nur ins Büro gehst oder zum Einkaufen, dann wäre eher der Status "absent" der richtige. Durch das autoGone wird ohnehin nach (unvorhergesehener) längerer Abwesenheit nach "gone" gewechselt. Man sollte "gone" nur direkt setzen, wenn man von vornherein weiß, dass man länger weg ist.Zitat von: Kakaomonster am 20 März 2014, 12:33:56dass klappt auch super, auch wenn die Anzeige leider nicht automatisch aktualisiert
Das ist ein FHEM Problem. Lässt sich laut Rudi auch nicht lösen, genaueres kann ich dazu aber auch nicht ausführen.Zitat von: Kakaomonster am 20 März 2014, 12:33:56Nun möchte ich aber, dass von Status "Home" erstmal auf "Absent" gesetzt wird. Bin ich dann x Minuten später immer noch absent, dann soll es auf "gone" gesetzt werden. Ich bin der Meinung das schon gesehen zu haben, aber ich habe das Forum nun 2 mal hoch und runter gesucht, ich finde es nicht mehr.
Das ist wie gesagt schon von Haus aus eingebaut. Du musst oben in deinem Code einfach nur auf "absent" setzen statt auf "gone". Über das Attribut r*_autoGoneAfter kannst du beeinflussen, wann auf "gone" gegangen wird. Bei ROOMMATE ist der Default Wert 36h, bei GUEST 16h.Zitat von: Alex_E am 21 März 2014, 07:22:16
Was ich aber gerne zusätzlich integrieren würde ist eine weitere Bedingung welche das Licht nur dann schaltet, wenn es dunkel ist.
Sprich: Wenn Home UND Dunkel dann an.
Was hätten wir auf Verfügung:
- das Twilight Modul mit den einzelnen Statu
- einen Dummy der dunkel bzw. hell ausgibt und auf 2 weitere Dummys referenziert welche aufgrund von sunrise / sunset die Ausgabe des Dummy´s auf Hell/dunkel stellt
Leider will das Roommate Modul aber leider keine Bedingung akzeptieren und weigert sich, die 2.te Bedingung neben dem Home status zu akzeptieren..
Jemand eine Idee wie ich das umsetzen kann bzw. ob das Roommate Modul das vllt. einfach garnicht kann?
Diese Bedingungen gehören auch nicht in das ROOMATE Modul, sondern sind eine Bedingung, die du im Notify mit abfragen musst.Es macht keinen Sinn dein ROOMMATE Objekt nur auf "home" zu setzen, wenn es dunkel ist, nur damit deine Lampe sich nur dann schaltet. Das ist falsch gedacht. Du willst eigentlich immer, wenn du zu Hause bist, dein Objekt auf "home" setzen und das Notify, was dann auslöst, muss prüfen, ob es dunkel ist oder nicht.Ich möchte hier eine Hilfestellung für die Definition zu einem Notify geben, da es eher themenfremd ist. Falls ihr mit der komplexen Definition von Bedingungen bei Notifies noch nicht fit seid, macht doch bitte einen separaten Thread im Forum "Anfängerfragen" auf.
Zitat von: Loredo am 23 März 2014, 13:21:36
Das wäre aber nicht ganz korrekt. Es sei denn du fährst ständig für längere Zeit in den Urlaub. Wenn du nur ins Büro gehst oder zum Einkaufen, dann wäre eher der Status "absent" der richtige. Durch das autoGone wird ohnehin nach (unvorhergesehener) längerer Abwesenheit nach "gone" gewechselt. Man sollte "gone" nur direkt setzen, wenn man von vornherein weiß, dass man länger weg ist.
Das ist ein FHEM Problem. Lässt sich laut Rudi auch nicht lösen, genaueres kann ich dazu aber auch nicht ausführen.
Das ist wie gesagt schon von Haus aus eingebaut. Du musst oben in deinem Code einfach nur auf "absent" setzen statt auf "gone". Über das Attribut r*_autoGoneAfter kannst du beeinflussen, wann auf "gone" gegangen wird. Bei ROOMMATE ist der Default Wert 36h, bei GUEST 16h.
Hallo Loredo,
danke erstmal für die richtige definition :-) Ich habe in der Tat gone und absent völlig falsch verstanden, so kann mein Vorhaben dann ja auch nicht funktionieren, auch wenn ich es inzwischen über andere notifys gelöst hatte.
Nun werde ich dies erstmal ändern, dass ich absent und nicht gone bin, dann sollte alles so laufen wie ich mir das vorstelle.
Jedoch noch eine kurze Frage zu dem AutoGone, ich habe zwar meinen Freund google befragt und auch das Forum, zur comandref bin ich grade unterwegs
attr r*_autoGoneAfter 20Sind das 20 sekunden, minuten oder Stunden? Laut Deiner Ausführung wie es default ist, gehe ich von Stunden aus. Wie kann ich dann als Beispiel 20 Minuten angeben`?
Grüsse und schönen Sonntag, Ralf
EDIT: Glaube es gefunden zu haben. Es sind Stunden, dennoch bleibt die Frage, ist es dennoch möglich als Beispiel die 20 Minuten irgendwie einzutragen?
Zitat von: Kakaomonster am 23 März 2014, 13:38:52
Jedoch noch eine kurze Frage zu dem AutoGone, ich habe zwar meinen Freund google befragt und auch das Forum, zur comandref bin ich grade unterwegs
attr r*_autoGoneAfter 20
Sind das 20 sekunden, minuten oder Stunden? Laut Deiner Ausführung wie es default ist, gehe ich von Stunden aus. Wie kann ich dann als Beispiel 20 Minuten angeben`?
Grüsse und schönen Sonntag, Ralf
EDIT: Glaube es gefunden zu haben. Es sind Stunden, dennoch bleibt die Frage, ist es dennoch möglich als Beispiel die 20 Minuten irgendwie einzutragen?
Die Kommando-Referenz gibt die Größe in Stunden an, ja :-)
Auch wenn ich finde, dass ein "gone" keinen Sinn nach 20 Minuten macht... du kannst natürlich auch 0.333 angeben. Das entspricht annähernd 20 Minuten ;-)
Zitat von: Loredo am 23 März 2014, 14:01:54
Die Kommando-Referenz gibt die Größe in Stunden an, ja :-)
Ich wenn ich finde, dass ein "gone" keinen Sinn nach 20 Minuten macht... du kannst natürlich auch 0.333 angeben. Das entspricht annähernd 20 Minuten ;-)
Super, danke für die schnelle Hilfe, ich werde es sofort testen.
Der Sinn dahinter... Sicherlich habe ich noch einen denkfehler, aber wenn ich nur mein BT überwache und ich absent bin, dann wird sofort das Licht ausgeschaltet. Da es aktuell im Test ist nur das Ambiente Licht.
Dies nerft, da ab und an BT absent ist für einen testzyklus, dass Licht dann aus und kurz drauf wieder an geht (wenn es bereits dunkel ist, soweit konnte ich es schon umsetzen)
absent ist für mich nur ein moment wie mal zum Auto gehen, schnell mal bei den Nachbarn Hallo sagen, brötchenholfunktion (da soll ja alles so bleiben wie es ist :-) )usw... nach in diesem Fall 20 Minuten ist aber entweder was dazwischen gekommen das es länger dauert oder ich bin bewust wirklich gegangen. In dem Fall wird erst wenn ich gone bin überprüft ob sich noch jemand mit precence im haus aufhält ODER der TV an ist (wenn der an ist bin ich daheim oder jemand schaut fern, sodass sich auf jedenfall noch jemand oder etwas im haus befindet :-) und wenn es nur ein gast ist, den ich nicht eingetragen habe (bin haltvergesslich). Ist TV noch an, alles ok, ist er aus und ich bin nach 20 min auf gone, dann schalte alles im haus ab.
Schaut der Gast nun kein TV, nundenn... dann sitzt er eben im dunkeln :-)
Eigentlich wollte ich es ursprünglich mit meiner BT abfrage lösen, dass ich erst nach 20 min auf absent gesetzt werde, wenn ich innerhalb von 20 Min nach dem ersten absent nicht wieder present bin, aber da komme ich bis jetzt nicht weiter das es funktioniert.
Bitte dabei bedenken, so fit bin ich ja noch nicht und daher suche ich auch andere wege um das umsetzen zu können wwas ich benötige :-)
Zitat von: Kakaomonster am 23 März 2014, 14:15:17
Der Sinn dahinter... Sicherlich habe ich noch einen denkfehler, aber wenn ich nur mein BT überwache und ich absent bin, dann wird sofort das Licht ausgeschaltet. Da es aktuell im Test ist nur das Ambiente Licht.
Dies nerft, da ab und an BT absent ist für einen testzyklus, dass Licht dann aus und kurz drauf wieder an geht (wenn es bereits dunkel ist, soweit konnte ich es schon umsetzen)
Ich würde deshalb eher empfehlen, dass du statt Notify einen Watchdog nimmst. Damit kannst du dann den Status erst nach einer bestimmten Auszeit wirklich setzen. Wenn also einmal eine BT Abfrage bei dir "abwesend" ergibt, ist das dann nicht mehr so schlimm. Erst wenn wenn du dann wirklich beim 2. oder 3. Zyklus immer noch nicht wieder per BT auffindbar bist, dann löst der Watchdog wirklich aus (und setzt den Status auf "absent" und löst entsprechend die Folgeaktionen aus).Das ist die Standard-Empfehlung, wenn man ein Gerät zur Anwesenheitserkennung benutzt, was gepollt werden muss.Alternativ kann man mit dem GEOFANCY Modul (bei Besitz eines iPhones) das Verlassen genauer veranlassen (wobei das Definitionssache ist; bei mir ist ein 5min beim Tengelmann nebenan ne Kleinigkeit holen nicht wirklich weg, da muss das Geofencing gar nicht unbedingt auslösen; ähnliches Beispiel wie du mit deinem Nachbarn ;))
Zitat von: Loredo am 23 März 2014, 17:25:48
Ich würde deshalb eher empfehlen, dass du statt Notify einen Watchdog nimmst. Damit kannst du dann den Status erst nach einer bestimmten Auszeit wirklich setzen. Wenn also einmal eine BT Abfrage bei dir "abwesend" ergibt, ist das dann nicht mehr so schlimm. Erst wenn wenn du dann wirklich beim 2. oder 3. Zyklus immer noch nicht wieder per BT auffindbar bist, dann löst der Watchdog wirklich aus (und setzt den Status auf "absent" und löst entsprechend die Folgeaktionen aus).
Das ist die Standard-Empfehlung, wenn man ein Gerät zur Anwesenheitserkennung benutzt, was gepollt werden muss.
Alternativ kann man mit dem GEOFANCY Modul (bei Besitz eines iPhones) das Verlassen genauer veranlassen (wobei das Definitionssache ist; bei mir ist ein 5min beim Tengelmann nebenan ne Kleinigkeit holen nicht wirklich weg, da muss das Geofencing gar nicht unbedingt auslösen; ähnliches Beispiel wie du mit deinem Nachbarn ;))
Wie war das? Vor lauter Bäume sieht man den Wald nicht mehr? Hm ... stimmt mit dem Watchdog hätte ich ja dann letztendlich alles was ich möchte. Darauf kam ich mal wieder nicht. Ist wohl zu einfach gewesen in meinen Augen oder weiß der Geier warum ich da nicht drauf kam.
Danke Dir noch mal für die Idee, werde mich da mal dran machen.
Grüsse, Ralf
PS: Das Geofancy Modul habe ich auch bereits drinnen, aber ich bin aktuell der einzige mit iPhone von daher habe ich da noch nicht weiter gemacht, da ich am Anfang nicht wirklich damit klar gekommen bin. Nun mache ich mich aber wieder zurück zum Residents und Roommate Module :-)
Zitat von: Loredo am 23 März 2014, 14:01:54
Die Kommando-Referenz gibt die Größe in Stunden an, ja :-)
Auch wenn ich finde, dass ein "gone" keinen Sinn nach 20 Minuten macht... du kannst natürlich auch 0.333 angeben. Das entspricht annähernd 20 Minuten ;-)
Guten Morgen Loredo,
so nun läuft mein fhem wieder, watchdog eingebaut und alles umgebastelt nach Deinen Tips. Also annähernd, bin noch dran :-)
Nun habe ich aber immer noch das Problem mit dem autogone atribute. Kannst Du mir da weiterhelfen? Irgendwie verstehe ich nicht ganz, wie ich das einbauen soll.
Ein einfaches
attr r*_autoGoneAfter 20reagiert nicht
Ein
attr rr_Ralf_autoGoneAfter 20funktioniert auch nicht
und ein paar andere Ideen hatte ich auch noch die nicht funktioniert haben. Also lediglich fehlermeldungen habe ich erhalten beim neu einlesen der fhem.cfg Was mache ich hier falsch oder habe ich das ganze falsch verstanden? In der commandref konnte ich auch kein Beispiel dafür finden das ich meinen Fehler erkennen kann.
Danke erste mal,
Grüsse, Ralf
PS: Mit Deinen Tips klappt es nun wirklich viel besser :-) *freu*
Warum setzt du das Attribut rr_autoGoneAfter nicht einfach im Frontend?
Einfach in der Kommandozeile eingeben:
attr rr_.* autoGoneAfter 20
Noch einfacher geht es im Device selbst.
Zitat von: marvin78 am 25 März 2014, 09:09:43
Warum setzt du das Attribut rr_autoGoneAfter nicht einfach im Frontend?
Einfach in der Kommandozeile eingeben:
attr rr_.* autoGoneAfter 20
Noch einfacher geht es im Device selbst.
Guten Morgen Marvin,
danke für die schnelle Antwort.
wenn ich Deinen Code von oben so übernehme, erhalte ich den Fehler
rr_Ralf: unknown attribute autoGoneAfter. Type 'attr rr_.* ?' for a detailed list.Ich habe wie Du geschrieben hast
attr rr_.* autoGoneAfter 20 eingegeben
Auch
attr rr.* autoGoneAfter 20 oder
attr rr_Ralf* autoGoneAfter 20gibt mir die Fehlermeldung zurück. Stimmt da vielleicht was mit meiner fhem.cfg nicht?
Mein Fehler. Das Attribut heißt
rr_autoGoneAfter
Also:
attr rr_.* rr_autoGoneAfter 20
Wenn du es in den Devices machst (Dropdownbox) kannst du aber auch bei der Schreibweise nichts falsch machen.
Super, danke das hat so fubnktioniert.
In den devices finde ich es irgendwie nicht. SCheinbar habe ich da noch was falsch, aber das macht ja nun erstmal NOCH nichts. Da ich alles am umbauen bin, finde ich es vielleicht später wieder. Jetzt hat es zumindest geklappt, dass ich dies so eingeben konnte
Danke noch mal,
Grüsse, Ralf
Kleiner Tipp:
Mit den Grundlagen von FHEM beschäftigen!
Habe ich viel bevor ich begonnen habe :-)
ABER Du hast recht, sollte ich noch ein bisschen (viel,viel) mehr und alles mal wiederholen :-) Scheint nur die hälfte hängen geblieben zu sein :-)
Mein Problem dabei war wohl, dass ich dies gemacht habe, bevor ich fhem installiert und die nötige HW hatte. Danach habe ich mich erst dazu entschossen es zu versuchen. Und ohne ab und an direkt etwas umsetzen zu können, vergisst man schnell wieder. Nun sollte ich es mir aber so langsam wirklich nochmal zu gemüte führen ;-)
Hallo,
ich bin FHEM-Einsteiger und habe zugegebenermaßen vermutlich eine Anfängerfrage. Da diese sich jedoch auf die Roommates bezieht, stelle ich sie einmal hier in der Hoffnung, nicht zu sehr beschimpft zu werden. Zunächst möchte ich jedoch einmal meinen Respekt für die Arbeit an den Modulen für Bewohne und dem GEOFANCY-Modul zum ausdruck bringen: Vielen Dank für die Arbeit, ich werde darauf wohl meine Anweisenheitsauswertung aufbauen.
Nun zu meiner Frage: Ich möchte jeweils eine andere Aktion ausführen, wenn ein ROOMMATE (z.B. rr_Ronny) home (oder einen anderen Ort) erreicht bzw. verlässt. Aktuell habe ich Notifies auf mein Handy, welches die Positionsänderung meldet:
define nf.Ronny.Abwesend notify geofancy.*HandyRonny.*left.home.* "wget -O /dev/nul -q 'adresse1'"
attr nf.Ronny.Abwesend room Handys
define nf.Ronny.Anwesend notify geofancy.*HandyRonny.*arrived.home.* set Test Anwesend;;"wget -O /dev/nul -q 'adresse2'"
Da das GEOFANCY-Modul auch den ROOMMATE rr_Ronny auf home bzw. absent setzt, würde ich das Notify lieber darauf setzen, um auch auf Änderungen der location von rr_Ronny zu reagieren, die nicht von GEOFANCY kommen. Irgendwie bekomme ich das aber nicht hin :-(
Könnte mir jemand auf die Sprünge helfen, wie die Notifies für nach Hause kommen und zu Hause verlassen für einen ROOMMATE auszusehen haben?
Viele Dank
Ronny
[EDIT:] Ich hab's hinbekommen :-)
Mit Verweis auf den Thread
Zeitdauern der RESIDENTS-Module in der Form HH:MM:ss plotten (http://forum.fhem.de/index.php/topic,22204.msg156147.html#msg156147)
habe ich gerade eine neue Version eingecheckt.
# -- new readings in computer readable format (*_cr)
# -- format of readings durTimer readings changes from minutes to HH:MM:ss
Neue Readings:
durTimerAbsence_cr
durTimerPresence_cr
durTimerSleep_cr
lastDurAbsence_cr
lastDurPresence_cr
lastDurSleep_cr
Die neuen Readings geben die Dauer in Minuten an (Sekunden erschien mir für's Plotten dann doch zu fein).Wie man sieht habe ich auch die DurationTimer angepasst. Um die Benennung einheitlich zu haben, musste deshalb das Format der vorhandenen Readings durTimerAbsence und durTimerPresence von Minuten auf HH:MM:ss umgeändert werden.
Hallo,
ich möchte gerade mein FHEM ein bisschen erweitern und für die neue "Funktion" die Modulfamilie für Bewohner nutzen:
Wenn wir unseren Sohn ins Bett gebracht haben, möchte ich dessen Status auf asleep setzen und damit eine Art Babyalarm scharfschalten: wenn der Bewegungsmelder auf dem Flur vor dem Kinderzimmer eine Bewegung erfasst, wollen wir solange wir nicht schlafen im Wohnzimmer und wenn wir dann schlafen im Schlafzimmer durch eine blinkende Lampe benachrichtigt werden.
Soweit zur Rahmengeschichte. Mein Problem ist nun, dass der Status der Residents auf asleep gesetzt wird, sobald der erste Bewohner (unser Sohn) schläft. Mir wäre es lieber, wenn der Status der Residents asleep wird, sobald alle schlafen - gibt es da eine Möglichkeit?
Vielen Dank
Ronny
Zitat von: RoBra81 am 11 April 2014, 10:47:21
ich möchte gerade mein FHEM ein bisschen erweitern und für die neue "Funktion" die Modulfamilie für Bewohner nutzen:
Wenn wir unseren Sohn ins Bett gebracht haben, möchte ich dessen Status auf asleep setzen und damit eine Art Babyalarm scharfschalten: wenn der Bewegungsmelder auf dem Flur vor dem Kinderzimmer eine Bewegung erfasst, wollen wir solange wir nicht schlafen im Wohnzimmer und wenn wir dann schlafen im Schlafzimmer durch eine blinkende Lampe benachrichtigt werden.
Soweit zur Rahmengeschichte. Mein Problem ist nun, dass der Status der Residents auf asleep gesetzt wird, sobald der erste Bewohner (unser Sohn) schläft. Mir wäre es lieber, wenn der Status der Residents asleep wird, sobald alle schlafen - gibt es da eine Möglichkeit?
Genau so sollte auch das Standardverhalten sein (wird in der Doku ja auch so beschrieben).Ich kann es gerade nicht nachvollziehen, aber hast du mal geschaut, ob das bei dir wirklich so ist oder ob nicht andere Umstände dazu führen?
Kompliment: Das ging ja schnell!
Ich habe den "Fehler" (meinen) gefunden und muss noch ein Kompliment aussprechen: Du hast bei der Logik ja wirklich an alles gedacht: Ich bin zur Zeit nicht zu Hause und test remote. Da meine Frau auch nicht zu Hause ist, sind wir beide absent und nur unser Sohn ist virtuell zu Hause. Und wenn der einzige anwesende Bewohner auf asleep geht, geht auch Residents auf asleep. Ist noch jemand anderes zu Hause, bleibt der Status auf home.
Super!!
Vielen Dank
Ganz genau ;-)
Hallo Loredo,
ich spiele gerade mit einem nagelneuem feature welches Andre heute nacht Programmiert hat.
Das ganze nennt sich readingsHistory der thread dazu ist hier http://forum.fhem.de/index.php/topic,23148.0.html (http://forum.fhem.de/index.php/topic,23148.0.html)
Ich möchte nun gerne in diesem Monitor eine Ausgabe haben wenn niemand mehr zuhause ist.
Ich habe auf das Residents Modul gesetzt und versucht per
define EventAnwesend notify XXXXX IF ([XXXXX] eq "home") (set Events add es ist jemand zuhause...)
ELSE (set Events add es ist niemand mehr zuhause...)einen sinnvollen Eintrag zu bekommen. IF triggert wenn nichts weiter angegeben ist auf das Internal STATE. Ausserdem habe ich schon versucht auf das Reading presence zu triggern - beide male bekomme ich eine menge an einträgen in den Monitor.
Zitat13:49:21 Micha ist gegangen...
13:49:21 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:49:20 es ist niemand mehr zuhause...
13:41:56 Micha ist nach Hause gekommen...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:41:56 es ist jemand zuhause...
13:39:19 Micha ist gegangen...
13:39:19 es ist niemand mehr zuhause...
13:39:19 es ist niemand mehr zuhause...
13:39:19 es ist niemand mehr zuhause...
13:39:19 es ist niemand mehr zuhause...
13:39:19 es ist niemand mehr zuhause...
13:39:19 es ist niemand mehr zuhause...
13:39:19 es ist niemand mehr zuhause...
13:39:19 es ist niemand mehr zuhause...
13:39:19 es ist niemand mehr zuhause...
13:39:18 es ist niemand mehr zuhause...
13:39:18 es ist niemand mehr zuhause...
13:39:18 es ist niemand mehr zuhause...
event-on-change-reading have ich aug .* gesetzt.
Was kann ich tun um nur einen Eintrag zu bekommen?
Zitat von: der-Lolo am 04 Mai 2014, 14:02:35
event-on-change-reading have ich aug .* gesetzt.
Versuch mal *.*
Danke fhainz - gerade versucht... Es hilft nicht...
Zitat14:05:38 Micha ist nach Hause gekommen...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
14:05:38 es ist jemand zuhause...
Ok komisch.. *.* funktioniert bei mir bei einigen devices problemlos.
*.* hat aber nix mit Regex zu tun, da kommt wohl noch die DOS Erinnerung bei dir hoch ;-)
Die Module lösen kein Event aus, ohne dass sich ein Status tatsächlich ändert. Demnach wird die Notify Schleife auch nur dann entsprechend aufgerufen. Was aktualisiert wird, ist das Reading für den An-/Abwesenheitscounter.
Leider hast du den entscheidenden Part deines Notify verstümmelt. ich kann daher nur vermuten, dass du dein Notify nicht auf das Reading "state" beschränkt hast und es daher dauernd auslöst.
Danke Loredo - fhainz und Andre haben mir gerade gewaltig auf die Sprünge geholfen, nun habe ich schon fast ein Jahr FHEM aktiv - aber REGEX und wie man sauber in ein notify hineintriggert hatte ich nie verstanden...
Jetzt gerade in der letzten viertel Stunde habe ich deutlich mehr verstanden als im ganzem letztem Jahr...
Das ist mir schon fast peinlich.
Da empfehle ich:
http://www.regexr.com/
Nette Seite, danke!
Danke auch von mir...
Hallo,
ich komme endlich dazu das Modul RESIDENTS einmal auszuprobieren. In Kombination mit dem GEOFANCY-Modul klappt die Anwesenheitserkennung ja hervorragend!!! Danke dafür!!!!!!!
Meine Frage:
Kann man den ROOMATES eine Sublocation zuordnen? Also z.B. location ist home; sublocation ist kitchen, bedroom...
Wäre doch im Zusammenhang mit den iBeacons ne tolle Sache.
Liebe Grüsse
Matzel
Zitat von: matzel am 16 September 2014, 11:58:37
Kann man den ROOMATES eine Sublocation zuordnen? Also z.B. location ist home; sublocation ist kitchen, bedroom...
Wäre doch im Zusammenhang mit den iBeacons ne tolle Sache.
Dafür brauchst du keine Sub-Lokation. Du kannst einfach die Location wie sie ist auf "Bedroom" oder was auch immer setzen (über Geof[e|a]ncy auch via iBeacon, klappt problemlos). Wenn zuvor einmal die Location "home" gesetzt wurde, bleibt der Status ja solange darauf, bis der home-Radius verlassen wird. Wenn du sicher sein willst, auch im Bedroom etc auf "Zuhause" zu bleiben, dann kannst du das Attribut rr_locationHome setzen (mehrere Locations dort einfach mit Komma trennen, siehe Kommando-Referenz). Der erste Eintrag dort sollte allerdings "home" bleiben, wenn du das als Schlüsselwort in der Geo-App eingetragen hast, um das Standardverhalten zu behalten.
Oh je!!!
DANKE!!!
Hab das völlig überlesen - sorry ;P
Hallo Loredo,
vielen Dank Für die Module - die machen das Leben wirklich einfacher.
Allerdings hätte ich ein paar Wünsche:
- Im define werden die Attribute alias und sortby gesetzt. Der check auf "exists( $attr{$name}{$name_attr}" zieht da aber leider nicht: Attribute werden ja erst nach dem define gesetzt. Damit ist es unmöglich, diese Attribute zu löschen: Spätestens nach dem nächsten Start von fhem sind die wieder da.
- die residents* readings von RESIDENTS erzeugen keine events - die kann man also auch nicht per notify oder userReadings abfrühstücken
- anders herum nerven die dur* events der ROOMMATES - besonders weil man mit event-on-$something nicht einfach nur "dur.*" verbieten kann (oder doch???)
- damit sich ROOMMATES + RESIDENTS gleich behandeln lassen können wäre cool, wenn auch RESIDENTS ein "wayhome" reading hätten das auch events erzeugt.
Das sind eigentlich alles Kleinigkeiten... aber ... Wünschen kann man ja mal ;)
danke
Rainer
Zitat von: geek am 04 Dezember 2014, 22:40:49
vielen Dank Für die Module - die machen das Leben wirklich einfacher.
Danke. Freut mich, dass sie auch für andere hilfreich sind ;)
Zitat von: geek am 04 Dezember 2014, 22:40:49
Allerdings hätte ich ein paar Wünsche:
- Im define werden die Attribute alias und sortby gesetzt. Der check auf "exists( $attr{$name}{$name_attr}" zieht da aber leider nicht: Attribute werden ja erst nach dem define gesetzt. Damit ist es unmöglich, diese Attribute zu löschen: Spätestens nach dem nächsten Start von fhem sind die wieder da.
Das ist wahr. Ich sehe allerdings auch keine andere Möglichkeit, da ich gerne die Einfachheit für die Nutzung der Module so erhalten wollen würde.
Aus der Praxis heraus sehe ich aber auch kein wirkliches Problem, denn auch wenn man die Attribute nicht löschen kann, so kann man deren Wert sehr wohl anpassen. Wer (aus mir unerfindlichen Gründen) kein Alias setzen möchte, kann den Alias ja auch auf den gleichen Namen wie das Device selbst setzen. Von der Anzeige her ist es dann identisch.
Das sortby Attribut sollte ebenso wenig stören. Wer bei der Sortierreihenfolge keinen besonderen Wert darauf legt, ignoriert es einfach. Und wer die Sortierung ändern möchte, der ändert eben den Wert entsprechend ab.
Zitat von: geek am 04 Dezember 2014, 22:40:49
- die residents* readings von RESIDENTS erzeugen keine events - die kann man also auch nicht per notify oder userReadings abfrühstücken
Die entsprechenden FHEM Funktionen, um die Trigger auszulösen, werden entsprechend benutzt. Entweder liegt hier dann ein Problem mit der Notify-Definition vor oder es ist ein FHEM eigenes Problem. Das kann ich so aus dem Bauch heraus nicht sagen. Hast du eine Beispiel-Definition, um das nachzustellen, was du erreichen wolltest?
Zitat von: geek am 04 Dezember 2014, 22:40:49
- anders herum nerven die dur* events der ROOMMATES - besonders weil man mit event-on-$something nicht einfach nur "dur.*" verbieten kann (oder doch???)
Eigentlich sollten sie nur wenig stören. Für's Logging kann man entsprechende Ausnahmen definieren genauso wie für Trigger ansich auch. Wie du richtig schreibst kann man es entweder über event-on-* lösen oder aber einfach seine Notifies entsprechend korrekt definieren, so dass sie nicht bei dur* anspringen.
Du könntest mal probieren, das Attribut event-on-change-reading so zu setzen, dass es eine explizite Lister aller Readings enthält, für die du einen Trigger erhalten möchtest. Alles andere wird dann ignoriert. Die Readings werden natürlich weiterhin aktualisiert, lösen eben halt nur kein Event mehr aus. So ist es dann auch gedacht.
Zitat von: geek am 04 Dezember 2014, 22:40:49
- damit sich ROOMMATES + RESIDENTS gleich behandeln lassen können wäre cool, wenn auch RESIDENTS ein "wayhome" reading hätten das auch events erzeugt.
Es hat einen Grund, weshalb die Readings hier unterschiedlich benannt sind. Es macht keinen Sinn die zwei Module über einen Kamm zu scheren, denn sie haben beide unterschiedliche Funktionen.
Beim Beispiel "wayhome" ist es so, dass das Reading bei einem ROOMMATE Device nur 0 oder 1 sein kann. Das RESIDENTS Modul bildet jedoch eine Summe über alle seine zugeordneten ROOMMATE Devices. Daher kann das Reading "residentsTotalWayhome" dort nicht nur 0 oder 1 sein, sondern auch 2, 3, 4 usw... Da hier ein unterschiedliches Verhalten besteht, sind die Readings entsprechend auch deutlich anders benannt, um sich absichtlich entsprechend abzusetzen.
Gruß
Julian
Hi,
so, habe noch ein bischen geschaut gehabt und meine Wunschliste mal abgearbeitet. Anbei ist ein Patch der alles addressiert - nur als Beispiel - ich erwarte nicht, daß du den (komplett) übernimmst. Wie gesagt - waren nur Wünsche - und die werden nicht immer erfüllt. Kann Deine Argumentation auch voll verstehen und akzeptieren. :D
Bei den fehlenden Events von RESIDENTS fehlte ein readingsEndUpdate am Ende von RESIDENTS_UpdateReadings.
Danach konnte ich mir auch ein wayhome reading mittels userReadings bauen... der Vollständigkeit halber ist aber auch die Alternative im Patch. Mir ist klar, daß die Module was anderes beschreiben - aber handlicher ist schon, wenn state und wayhome bei beiden existieren ... zb. um mit dem gleichen Satz von Funktionen Status LEDs ohne weitere Sonderbehandlung zu setzen.
alias hatte ich schon wie vorgeschlagen gelöst... sortby ist lästig, weil ich normal nach den Namen sortiere.
mittels event-on-* nur die gewünschten readings filtern geht... ist aber etwas das potentiell bei jedem update angefasst werden muss. Deswegen hab' ich mir das periodischen Berechnen der Durations abschaltbar gemacht mit "attr $name noDuration 1".
Rainer
Zitat von: geek am 05 Dezember 2014, 17:10:26
Bei den fehlenden Events von RESIDENTS fehlte ein readingsEndUpdate am Ende von RESIDENTS_UpdateReadings.
Vielen Dank für den wertvollen Hinweis! Habe ich soeben korrigiert und eingecheckt.Zitat von: geek am 05 Dezember 2014, 17:10:26Deswegen hab' ich mir das periodischen Berechnen der Durations abschaltbar gemacht mit "attr $name noDuration 1".
Habe ich in abgewandelter Form in 20_ROOMMATE und 20_GUEST übernommen und eingecheckt.
Hallo zusammen,
ich habe bisher bereits ROOMMATE genutzt und wollte jetzt auch RESIDENTS nutzen. Ich bekomme es allerdings nicht hin.
Ich habe Residents mit
define rgr_Residents RESIDENTS
angelegt.
dann habe ich versucht mittels addRoommate einen existierenden Roommate hinzuzufügen. Leider meckert er immer, das er bereits existiert und packt ihn auch nicht rein. Einen nicht existierenden kann ich anlegen und der ist auch eingebunden, aber das hilft mir grade mal nicht weiter.
Mache ich was falsch?
Gruß
Veit
Du musst das existierenden ROOMMATE Device einfach editieren und gemäß der Commrandref das Define so abändern, dass sich das Gerät beim RESIDENTS Gerät entsprechend anmeldet.
Aus
define rr_Veit ROOMMATE
wird dann also z.B.
define rr_Veit ROOMMATE rgr_Residents
Alternativ: ROOMMATE Device einfach löschen und mit gleichem Namen wieder anlegen ;)
Das hat es getan. Manchmal muss man eben rückwärts denken. ;)
Variante 2 wäre bei rund 30 existierenden Notify's und Watchdogs nicht so toll gewesen.
Danke für die schnelle Hilfe.
Zitat von: volschin am 09 Januar 2015, 13:16:56
Variante 2 wäre bei rund 30 existierenden Notify's und Watchdogs nicht so toll gewesen.
Die bleiben dabei doch erhalten und sind davon vollkommen unberührt. Während des kurzen Moments, wo das ROOMMATE Gerät nicht mehr existiert, triggern die Notifies und Watchdogs halt nur nicht, das ist alles 8)
Hallo Loredo,
ich habe GUESTs definiert und frage mich gerade wo ich auf Anwesenheit einer dieser Gäste triggern kann, um das GästeWlan zu schalten.
Ich hatte vermutet das das reading von RESIDENTS residentsGuests hier hilft, das reading scheint aber "nur" eine summe aller definierten GUEST Devices zu sein. Ein GuestsHome gibt es nicht - oder übersehe ich was?
Wenn du Gäste definiert hast, dann kannst du doch einfach auf die guest-Devices triggern. Sowas wie:
define guestWlan notify GASTDEVICEREGEX:.home {schalteGastWlanan()}
richtig, aber so muss ich da jeder Gast seinen eigenen Namen hat ne ganze menge Devices eingeben..
Ich würde gerne wissen ob irgendein Gast da ist, egal welcher und nicht alle Namen im REGEX auflisten.
Edit:
ich könnte ja die Gäste in eine structure packen.
du kannst auch einfach die Gäste in ein einzelnes Residents Device packen ;-)
Die können nämlich auch in mehreren Residents Gruppen gleichzeitig Mitglied sein. Siehe Beispiel in der Commandref.
Ich nehme es aber mal als Anregung einen generellen Gäste-Indikator in die Readings mit aufzunehmen.
Ich glaube mit der structure habe ich das jetzt ganz gut hinbekommen
- das ein weiteres Residents genauso geholfen hätte war mir klar. Für mich stellt Residents aber die Wohnung da, und wir haben nunmal "nur" eine Wohnung ;-)
Hallo zusammen,
mein rgr_Residents verliert anscheinend nach jedem Restart den ROOMMATES-Eintrag in den Internals. Im ROOMMATE selbst ist der Eintrag im define für die Residents-Group aber vorhanden. Wenn ich einfach ein modify im ROOMMATE mache wird er auch sofort wieder hinzugefügt. Ich habe sowohl ein save der config gemacht als auch ein halbstündliches Sichern der fhem.save per at eingebaut. Daran liegt es also nicht.
Jemand eine Idee?
Gruß
Veit
Stimmt die Reihenfolge in der gespeicherten Config Datei? Zuerst alle RESIDENTS Devices, erst dann die ROOMMATE Devices.
Nein, der ROOMMATE steht zuerst. Das hat FHEM selbst so eingetragen. Ich halte meine Finger da typischerweise raus.
Es war aber auch die Anlagereihenfolge, da ich zuerst ROOMMATE ohne RESIDENTS benutzt habe. Soll ich die Reihenfolge manuell ändern?
Ja. Es ist normalerweise vorgesehen erst ein RESIDENTS Device anzulegen.
Wenn man einmal ans Sortieren kommt, wird's interessant. Ich habe jetzt rund eine Stunde gebraucht, meine config so umzustellen, dass sie lauffähig ist.
Aber jetzt funktioniert es so, wie es soll.
Scheint so, dass mit zunehmender Komplexität der fhem.cfg die Probleme durch die vernetzten Abhängigkeiten der Initialisierungsreihenfolge exponentiell zunehmen.
Danke für den Hinweis.
Ich versuchte nun mehrfach das Icon des Resident devices zu löschen - dann passt es für mich optisch besser.
Allerdings kommt das Icon immer wieder ?
@Loredo: kannst Du das Icon attr von Residents nicht einfach dem Nutzer überlassen?
Diese Nutzer bevormundenen Module scheinen in Mode zu kommen...
Du kannst das icon-Attribut nach belieben abändern, jedoch nicht löschen.
Wenn jemand eine Möglichkeit kennt, Voreinstellungen mitzugeben, die nur beim initialen/manuellen define wirken, so bin ich offen für Änderungen. Ansonsten möchte ich es aus Convenience Gründen so beibehalten, wie es ist.
Zur not hilft mir sicher ein delattr nach global:Ini.
Oder ein Icon mit 1x1 Pixel Transparent.
"Convenience" ist im Übrigen nicht FHEM. Und das ist gut so. FHEM zeichnet sich dadurch aus, dass ich alle Möglichkeiten habe, meine Hausautomation zusammen zu stellenwie ich es möchte. Aus diesem Grund sollten ALLE Module den Usern die Möglichkeit geben, Dinge selbst zu entscheiden. Die einzig sinnvolle Maßnahme wäre also, keine Icons vorzugeben. Aber ich weiß, dass ich hier gegen eine Wand rede...
Zitat von: marvin78 am 18 Januar 2015, 16:25:04
Aber ich weiß, dass ich hier gegen eine Wand rede...
Ich bin eben anderer Ansicht. Ich möchte gerne eine Voreinstellung mitgeben, die der Nutzer dann nach seinem Gusto abändern kann, wenn er möchte (aber eben nicht muss). Dass man die Voreinstellung nur abändern, nicht aber löschen kann, liegt am Design von FHEM.
Diese Module hier wurden (und werden) von vielen sowieso als überflüssig bezeichnet, da man sich eine ähnliche Funktionalität auch mit Boardmitteln zusammenschustern kann. Die Module ansich sind deshalb ohnehin insgesamt schon der Convenience gewidmet.
Die Möglichkeit die gleiche Funktionalität mit Dummys, Structures oder sonstwie nachzubauen, steht dir natürlich auch offen; schließlich ist FHEM wie du sagst ein offenes System, was es dir ermöglicht deine Hausautomation so zu gestalten, wie du es möchtest.
Ich habe jetzt einen Weg gefunden, wie sich die Attribute dauerhaft löschen lassen. Im morgigen Update ist der entsprechende Code enthalten.
Hi zusammen,
seit zwei Tagen nutze ich nun auch - testweise - RESIDENTS und ROOMMATE und habe einen interessanten Effekt (höchstwahrscheinlich ein dummer Zufall, aber wer weiss):
Geofancy nutze ich schon länger (allerdings ohne irgendwas damit zu schalten)
Montag abends habe ich RESIDENTS und ROOMMATES defined, ein bisschen herumgespielt. Um den "wayhome" Status zu testen habe ich zusätzlich einen neuen Geofence in Geofancy definiert und in das wayHome Attribut geschrieben:
attr rr_oli rr_locationWayhome office
Als ich gestern dann wiede aus dem Büro nach Hause kam, war mein FHEM tot. Letzter Log-Eintrag:
2015.01.20 08:45:59 3: GEOFANCY geofancy: Oli arrived at office
2015.01.20 08:46:00 2: ROOMMATE set rr_Oli location office
Komisch denke ich mir, aber kann schonmal vorkommen, heute:
2015.01.21 08:41:12 3: GEOFANCY geofancy: Oli arrived at office
2015.01.21 08:41:12 2: ROOMMATE set rr_Oli location office
danach... nichts mehr, FHEM tot bis zum Neustart. Irgendjemand eine Idee, wieso FHEM stirbt, wenn ich im Office ankomme? Mir ist klar, dass die Wahrscheinlichkeit, dass es mit ROOMMATES zusammenhängt eher gering ist, aber wer weiss... Location auf "home" lässt FHEM übrigens am Leben.
Grüße,
Oli
Ich habe ein Problem mit "mood". Wenn ich versuche über diesen Reading etwas zu steuern, z.B. die beleuchtung wird er einfach nicht ausgelesen. Erscheint auch nicht im Log. oder Event Monitor.
Um sicher zu sein das ich nichts falsch mache, habe ich das Notify mit Reasings anderer Sensoren probiert. Da kein Problem. habe es mit DOIF IF usw versucht, keine Reaktion. Hat jemand eine Lösung?
probiert habe ich:
(rr_Sommer)
IF ([rr_Sommer:rr_mood] = "relaxed") (set test off)
(rr_Sommer)
IF ([rr_Sommer:rr_mood] eq "relaxed") (set test off)
(rr_Sommer)
IF ([rr_Sommer:mood] = "relaxed") (set test off)
(rr_Sommer)
IF ([rr_Sommer:mood] eq "relaxed") (set test off)
Wieso geht das nicht?
ich machs sowas mit ReadingsVal, zB.:
define nt_test notify rr_Andy:.* {if (ReadingsVal("rr_Andy","mood",0) eq "happy") {fhem("set WZ_Stehlampe on")}}
Das Beispiel funktioniert bei mir^^
bei mir leider nicht
define nt_test notify rr_Sommer:.* {if (ReadingsVal("rr_Sommer","mood",0) eq "happy") {fhem("set test off")}}
Zitat von: noanda am 01 Februar 2015, 13:00:51
bei mir leider nicht
so kann dir wohl keiner helfen :D
was sagt denn das logfile dazu?^^
sorry ist der Frust .-)
2015.02.01 13:05:02 2: ROOMMATE set rr_Sommer mood happy
2015.02.01 13:05:02 5: ROOMMATE rr_Sommer: called function ROOMMATE_Set()
Zitat von: noanda am 01 Februar 2015, 13:07:05
sorry ist der Frust .-)
2015.02.01 13:05:02 2: ROOMMATE set rr_Sommer mood happy
2015.02.01 13:05:02 5: ROOMMATE rr_Sommer: called function ROOMMATE_Set()
Das ist sicherlich ein Problem mit deiner Notify-Deklaration. Du solltest in dieser Hinsicht einmal schauen.
Ein Hinweis für diejenigen, die das Modul gerne in deutscher Sprache in der Oberfläche haben möchten:
http://forum.fhem.de/index.php/topic,33613.msg259937.html#msg259937
Dort ist beschrieben, wie man das mit Hilfe von eventMap und widgetOverride erreichen kann.
Hallo zusammen,
ist im Modul Residents eine einfache Möglichkeit vorgesehen festzustellen, ob Bewohner im Haus oder nicht im Haus sind?
Ein bewohntes Haus kann ja die Stati home, gotosleep, asleep und awoken haben.
Ein umbewohntes Haus die Stati absent und gone.
Wenn ich nun wissen möchte, ob das Haus unbewohnt ist, muss ich dann immer auf (absent oder gone) testen, oder gibt es dafür ein eigenes Attribut?
Ich bin darauf gestoßen, weil ich in meiner Rolladensteuerung bisher immer nur auf "absent" getestet habe, aber das Modul Residents ja nach einiger Zeit automatisch auf "gone" wechselt. Das hat meine Rolladenlogik dann durcheinander gebracht.
Vielen Dank für die Hilfe!
Gruß,
Bernd
Du kannst ja einfach auf Residents total Home triggern...
Zitat2015-03-27 09:31:21 lastState absent
2015-03-27 09:31:21 presence present
2015-03-30 07:47:50 residentsAbsent 1
2014-10-11 18:47:19 residentsAsleep 0
2014-10-11 18:47:19 residentsAwoken 0
2015-02-26 17:15:46 residentsGone 0
2014-10-11 18:48:34 residentsGotosleep 0
2015-03-18 01:02:44 residentsGuests 0
2015-03-30 07:47:50 residentsHome 1
2015-03-18 01:02:44 residentsTotal 2
2015-03-30 07:47:50 residentsTotalAbsent 1
2015-03-30 07:47:50 residentsTotalPresent 1
2014-10-11 18:47:19 residentsTotalWayhome 0
2015-03-27 09:31:21 state home
so mache ich es jedenfalls.
Residents total home gibt es nicht. Meinst Du residentsTotalPresent?
Das müsste klappen, probiere ich mal aus.
Vielen Dank!
da gibt es mehrere Wege.
Bei der Frage "anwesend" oder "nicht anwesend", also einer Schwarz/Weiß Sicht, macht das Reading "presence" Sinn, denn es kann nur 2 Status haben.
Wenn man aber genauer differenzieren möchte, ob eine kurze oder längere Abwesenheit vorliegt, dann ist das Reading "state" genau dafür da und man wertet dort eben die Values "absent" bei kurzer und "gone" bei längerer Abwesenheit aus.
Auf die Total-Werte zu triggern kann man machen, ist aber nicht unbedingt zielführend in diesem Fall, weil euch die eigentliche Anzahl der anwesenden Personen ja egal ist.
Übrigens ist es nicht unbedingt richtig auf "totalHome" zu triggern, denn man kann auch zuhause sein und nicht den Status "home" haben, sondern z.B. "gotosleep,asleep,awoken". Man gilt dann natürlich immer noch als zuhause. Kommt aber drauf an, ob ihr diesen Workflow verwendet (siehe neuer Wiki Artikel Weckautomation (http://www.fhemwiki.de/wiki/Weckautomation)). Richtiger wäre da das Reading residentsTotalPresent oder residentsTotalAbsent. Aber wie gesagt, ganz korrekt sind nur "presence" und "state".
Vielen Dank Loredo!
Dann ist presence genau das wonach ich gesucht hatte.
Hallo zusammen,
ich habe versucht über die PING Erkennung meines Handys die Anwesenheit festzustellen. Dies habe ich mit dem Module PRESENCE gemacht - die Rückmeldung present und absent ist erfolgreich. Diesen State möchte ich gerne an den Roommate rr_Markus übergeben.
Dazu habe ich einen Watchdog wie folgt angelegt
setstate rr_Markus absent; setstate wd.rr.Markus.presence defined
Def: Markus.Handy:absent 00:03:15 Markus.Handy:present setstate rr_Markus absent; setstate wd.rr.Markus.presence defined
Dieser Watchdog erkennt wenn die Bedingung "absent" des Handys zutrifft, jedoch ändert sich der State von rr_Markus nicht.
Was mache ich falsch?
Der Befehl muss nicht
setstate rr_Markus absent
heißen, sondern stattdessen
set rr_Markus absent
Cmd angepasst aber es tut sich immer noch nichts. :(
Markus.Handy:absent 00:03:15 Markus.Handy:present set rr_Markus absent;; setstate wd.rr.Markus.presence defined
attr wd.rr.Markus.presence regexp1WontReactivate 1
Das Log habe ich auf verbose=4 gesetzt; dennoch kommt keine Hinweismeldung
Markus.Handy = absent
wd.rr.Markus.presence = Next: 17:35:15
state von rr_Markus = home
Gebe ich den Befehl set rr_Markus absent in der Kommandzeile ein wird der Status erfolgreich umgesetzt.
Ich habe eben mal den Teil set rr_Markus absent auf set 44.sz.RO.Rolladen down geändert... auch dieser Befehl wird nach Erkennung der Abwesenheit nicht durchgeführt. Woran könnte das liegen? Hier nochmal der komplette String:
Markus.Handy:absent 00:01:00 Markus.Handy:present set 44.sz.RO.Rolladen down ;; setstate wd.rr.Markus.presence defined
attr wd.rr.Markus.presence regexp1WontReactivate 1
Ich kann nur vermuten, dass es am doppelten ;; liegt. Eigentlich müsste es wohl eher so aussehen:
define wd.rr.Markus.presence watchdog Markus.Handy:absent 00:01:00 Markus.Handy:present set rr_Markus absent; setstate wd.rr.Markus.presence defined
Ansonsten empfehle ich dir einen eigenen Thread dafür zu eröffnen, es scheint eher ein Watchdog Problem zu sein.
Diese Module sind eine tolle Sache!!!
Aber ein paar Fragen habe ich noch zum Status und dem Wechsel desselben. Beispiel:
- Ich bin weit (und damit längere Zeit) weg von Zuhause und mein Zustand ist "gone"
- Auf meinem Android-Telefon ist Egigeozone installiert und wenn ich in den Umkreis von einem Kilometer meines Hauses komme, setze ich den Zustand auf "absent"
- Wenn ich dann wirklich zu Hause bin (aktuell noch über einen Taster neben der Haustüre manuell ausgelöst), setze ich den Zustand auf "home"
- Wenn ich dann wieder weggehe, drücke ich den Taster und der Zustand wechselt auf "absent". Über Egigeozone will ich dann auf "gone" wechseln. Der 36-Stunden-Timer wäre dann nur noch für den Fall, dass das Mobiltelefon ausfällt, richtig?
- "gotosleep" setze ich (wie auch immer) explizit.
- Muss ich "asleep" auch explizit setzen? Das kann ich ja ggf. über einen Timer von 10 Minuten machen - oder über den oben erwähnten Drucksensor unter dem Bett ;)
- Wenn der Wecker klingelt, setze ich wieder händisch auf "awoken", richtig? Wenn ich den integrierten Wecker nutze funktioniert das dann automatisch?
- Der Wechsel von "awoken" nach "home" muss auch händisch erfolgen. Gibt es einen integrierten Timer wie bei "absent"?
- Was passiert, wenn (warum auch immer) ein Wechsel von "asleep" nach "gone" erfolgt? Oder irgendein anderer inkonsistenter Wechsel.
- Ist "mood" zur freien Verwendung oder sollen da auch noch Funktionen kommen?
Sobald ich "mich" da richtig implementiert habe, werde ich es auch für meine Ehefrau tun - dann wird es spannend. Wenn dann etwas schief geht... :'(
Was sich mir noch nicht erschlossen hat, ist wie man mit den Gästen umgeht und was da Sinn macht. Und "Homestatus" habe ich noch nicht gelesen, kommt jetzt als nächstes.
Nachtrag: wie kann ich genau die Grafik (das Icon) des Homestatus anzeigen?
Das sind aber eine Menge...
Zitat von: ujaudio am 15 August 2015, 08:39:43
Ich bin weit (und damit längere Zeit) weg von Zuhause und mein Zustand ist "gone"
Auf meinem Android-Telefon ist Egigeozone installiert und wenn ich in den Umkreis von einem Kilometer meines Hauses komme, setze ich den Zustand auf "absent"
Warum? Also du meinst wenn du den 1km Radius verlässt? 1km ist ein sehr großer Radius für den Homestatus.
Hast du den Wiki Artikel gelesen? Vorgesehen ist eher, dass du die location über "set rr_Juergen location ..." setzt, den Rest erledigt das Modul und setzt dann je nach Location verlassen oder ankommen den Status entsprechend.
Zitat
Wenn ich dann wirklich zu Hause bin (aktuell noch über einen Taster neben der Haustüre manuell ausgelöst), setze ich den Zustand auf "home"
Wenn man nur mit Taster arbeitet, die richtige Vorgehensweise. Zusammen mit Geofencing ist es falsch, dort wird nur die Location gesetzt, nicht der Status.
Dein Status wird über die Geofencing Location bereits vor Betreten des Hauses auf "home" gesetzt, also je nach Radius wenn du im 100m Umkreis bist.
Zitat
Wenn ich dann wieder weggehe, drücke ich den Taster und der Zustand wechselt auf "absent". Über Egigeozone will ich dann auf "gone" wechseln.
Gedacht ist das so nicht. Du kannst die Events, die in GEOFANCY aber so auswerten und verwenden, wie du sie möchtest.
Zitat
Der 36-Stunden-Timer wäre dann nur noch für den Fall, dass das Mobiltelefon ausfällt, richtig?
In deinem Fall wohl ja.
Zitat
"gotosleep" setze ich (wie auch immer) explizit.
Ich mache das über einen mehrfach belegten Homematic Taster neben meinem Bett:
Lange den Ausschaltknopf nach unten gedrückt halten heißt "gotosleep", lange den Ausschaltknopf nach oben gedrückt halten heißt "asleep". Wenn der Status bereits auf "gotosleep" ist, genügt auch ein einfaches Licht ausschalten mit kurzem Druck auf den oberen Taster, um auf "asleep" zu schalten. Fürs aufwachen ist es ähnlich, je nachdem ob das Weckprogramm schon/noch läuft oder nicht.
Zitat
Muss ich "asleep" auch explizit setzen? Das kann ich ja ggf. über einen Timer von 10 Minuten machen - oder über den oben erwähnten Drucksensor unter dem Bett
Die Frage haben wohl viele. Ich finde ja immer ich weiß selbst am besten, wann ich die Augen zumachen will und ein Buch, das iPhone oder was auch immer zur Seite lege (siehe oben). Aber da hat jeder andere Gewohnheiten, auch das mit einem 10min Timer kann praktikabel sein. Muss jeder selbst für sich überlegen.
Zitat
Wenn der Wecker klingelt, setze ich wieder händisch auf "awoken", richtig? Wenn ich den integrierten Wecker nutze funktioniert das dann automatisch?
Ja. Auch ohne so ein Weckprogramm würdest du ja sehr wahrscheinlich auch irgend ein Licht als erstes einschalten. Hier schaltest du mit dem Taster eben den Status auf "awoken" und dadurch wird indirekt dein Licht (und alles andere) geschaltet. Praktikabel wie ich finde.
Zitat
Der Wechsel von "awoken" nach "home" muss auch händisch erfolgen. Gibt es einen integrierten Timer wie bei "absent"?
Jaein. Im Beispiel-Weckprogramm ist es so vorgestellt, dass es nach wenigen Sekunden automatisch passiert. Dafür ist das Notify, welches auf "awoken" triggert, zuständig.
Zitat
Was passiert, wenn (warum auch immer) ein Wechsel von "asleep" nach "gone" erfolgt? Oder irgendein anderer inkonsistenter Wechsel.
Das kommt einzig auf deine Automation drum herum an. Von Modulseite aus passiert da nichts inkonsistentes oder unerwartetes. Der Presence-State wird auf "absent" gesetzt und das wars. Ein Wecker würde nicht mehr auslösen. FHEM ist grundsätzlich ja Event gesteuert: Ist nichts für das Event "gone" definiert, passiert auch nix weiter.
Ich würde vorschlagen du spielst deine Fälle einfach mal durch und schaust was passiert. Ich kann dir hier nicht sämtliche Vorgänge aufzählen, denke aber sie passieren so wie man es erwarten darf.
An den Modulen ist da nix weiter unerwartet, es werden hauptsächlich die Status kumuliert und die abhängigen Readings aktualisiert.
Zitat
Ist "mood" zur freien Verwendung oder sollen da auch noch Funktionen kommen?
Es war/ist dafür vorgesehen, dass jemand händisch (oder durch eine was-auch-immer-Steuerung) angeben kann, wie der Gemütszustand gerade ist. Davon abhängig kann dann z.B. die Farbe einer Leuchte bestimmt werden o.ä., da ist der Kreativität keine Grenze gesetzt. In gewisser Weise kann man das auch zweckentfremden, da man die Moods ja selbstständig festlegen kann. Ist aber auch nichts anderes als das, was man mit einem Dummy nicht auch machen könnte. Ist hier halt nur mit im gleichen Device mit drin. Das einzige ist halt, dass der Mood beim Schlafengehen entsprechend wechselt, das ist alles.
Zitat
Was sich mir noch nicht erschlossen hat, ist wie man mit den Gästen umgeht und was da Sinn macht.
Das kommt auf deine Fantasie an. Sie könnten ihren Status manuell über ein Tablet setzen oder übers Gäste WLAN oder über einen Handsender... up to you.
Das ist vor allem Sinnvoll, wenn Gäste ein eigenes Weckprogramm bekommen sollen oder sie z.B. im Wohnzimmer übernachten, was du sonst aber in deinem eigenen Weckprogramm komplett ausschaltest. Bei Anwesenheit eines Gastes könnte das dann von deinem Zubettgeh-Programm ausgenommen werden. Etc etc... da muss man selbst drüber nachdenken, jeder hat andere Umstände.
Zitat
Und "Homestatus" habe ich noch nicht gelesen, kommt jetzt als nächstes.
Keine Ahnung, was du mit Homestatus meinst. Das Modul HOMESTATE gibt es noch nicht bisher, daran tüftel ich noch.
Zitat
Nachtrag: wie kann ich genau die Grafik (das Icon) des Homestatus anzeigen?
Wie ist Homestatus jetzt hier gemeint/definiert?
Welche Grafik meinst du? Das Attribut devIconState ist entsprechend vorbelegt und kann nach belieben geändert werden.
Zuerst einmal VIELEN DANK für die ausgiebigen Antworten.
Zitat von: Loredo am 16 August 2015, 03:29:29
Hast du den Wiki Artikel gelesen? Vorgesehen ist eher, dass du die location über "set rr_Juergen location ..." setzt, den Rest erledigt das Modul und setzt dann je nach Location verlassen oder ankommen den Status entsprechend.
Welchen Wiki-Artikel? Der über Anwesenheitserkennung hilft mir hier irgendwie nicht so recht. Wo kann ich genauer erfahren wie der Zusammenhang location - status ist? Momentan setze ich den Status, nicht die Location.
Mein Verständnis:
home = ich bin im Haus
absent = ich bin im Umkreis von ca. 1km, ich muss ja nicht jedesmal das WLAN ausschalten, blos weil ich in die Garage gehe :)
gone = ich bin weg und WLAN, alle Lichter und die Stereoanlage sind aus
Und aus der Commandref entnehme ich:
ZitatUnter bestimmten Umständen führt der Wechsel des Status auch zu einer Änderung des Readings 'location'.
Also ich ändere den Status und die Location wechslt automatisch mit. Unter Location könnte ich mir ja auch Haus, Garten, Balkon, ggf. sogar die Zimmer vorstellen - oder auch die Koordination, wo ich mich befinde.
Zitat von: Loredo am 16 August 2015, 03:29:29
Keine Ahnung, was du mit Homestatus meinst. Das Modul HOMESTATE gibt es noch nicht bisher, daran tüftel ich noch.
...
Welche Grafik meinst du? Das Attribut devIconState ist entsprechend vorbelegt und kann nach belieben geändert werden.
Es geht um das Device Residents in der Gruppe Home State. Das Device hat ein festes Icon (blaues, ausgefülltes Haus), der Status wird mit weiteren Icons angezeigt. Letztere meinte ich.
Wenn ich die SVG durch PNG ersetze, dann bekomme ich im Floorplan eine Anzeige - das habe ich mittlerweile herausbekommen. Muss mal suchen, ob ich dazu etwas finde, denn im FHEM Webfrontend ist ja alles bestens, warum es im Floorplan nicht geht??!?
Kannst du bitte nochmals erklären, was es mit dem Attribut "wakeupResetdays" auf sich hat? Ich habe wohl einen Knoten im Hirn, aber der Reset eines Weckers ist mir einfach nicht klar. DIe Erklärung aus dem Wiki habe ich einfach nicht verstanden. Und was bedeutet ein deaktiviertes, resp. ein aktiviertes Reset?
Ich habe zwar noch mehr Fragen, aber das reicht für's erste.
Zitat von: Loredo am 16 August 2015, 03:29:29
Keine Ahnung, was du mit Homestatus meinst. Das Modul HOMESTATE gibt es noch nicht bisher, daran tüftel ich noch.
vielleicht ist da ja http://siio.de/lichtschatten/die-perfekte-lichtsteuerung-mit-fibaro-lua-teil-1/ eine Inspiration für
Zitat von: ujaudio am 16 August 2015, 08:20:21
Welchen Wiki-Artikel? Der über Anwesenheitserkennung hilft mir hier irgendwie nicht so recht. Wo kann ich genauer erfahren wie der Zusammenhang location - status ist?
Genau den Artikel. Der Zusammenhang location<>state und state<>location wird in der Commandref erklärt.
"Zusammenhang zwischen Anwesenheit/Presence und Aufenthaltsort/Location" beschreibt dabei das Verhalten, dass man manuell den Status ändert. "Zusammenhang zwischen Aufenthaltsort/Location und Anwesenheit/Presence" beschreibt den Fall, dass man über die Änderung der Location steuert.
Eine Mischung daraus ist explizit vorgesehen. Bei Nutzung des GEOFANCY Moduls macht es aber keinen Sinn, über GEOFANCY den Status zu ändern; es ist dafür vorgesehen die Location zu ändern.
Ansonsten findest du das Verhalten entweder durch lesen des Source-Code oder durch ausprobieren und beobachten der Readings heraus.
Zitat von: ujaudio am 16 August 2015, 08:20:21
home = ich bin im Haus
absent = ich bin im Umkreis von ca. 1km, ich muss ja nicht jedesmal das WLAN ausschalten, blos weil ich in die Garage gehe :)
gone = ich bin weg und WLAN, alle Lichter und die Stereoanlage sind aus
Die Bedeutung von "absent" wird beschrieben als:
"Mitbewohner ist momentan nicht zu Hause, wird aber bald zurück sein".
Damit ist keine räumliche Nähe wie 1km Radius gemeint, sondern ganz einfach, dass du in der Regel am gleichen Tag wieder zurück bist. Trotzdem sollten nach meinem Verständnis bei diesem Status alle Verbraucher (wo es Sinn macht) ausgeschaltet werden (bezogen auf den Gesamtstatus über alle Bewohner im RESIDENTS Device natürlich, sprich also wenn wirklich alle Bewohner auf der Arbeit, in der Schule, beim Einkauf, etc sind.).
"gone" bedeutet eine längere Abwesenheit im Sinne von ich bin verreist, ich mache Urlaub, ich bin auf Geschäftsreise und ich komme nicht am gleichen oder nächsten Tag zurück. Hier könnte man z.B. die Heizung deutlich weiter runterregeln oder die Alarmanlage anders schalten. Bei mir ist es so, dass ich da alle Rollläden dauerhaft nach unten fahre und keine Beschattungsprogramme mehr laufen, die aber ansonsten bei "absent" noch während meiner kurzen Abwesenheit aktiv werden können.
Ich gehöre nicht zu denjenigen, die WLAN oder sowas ausschalten, sowas halte ich für nicht sinnvoll (Infrastruktur ist Infrastruktur; ich drehe ja auch nicht den Wasser-Haupthahn zu oder schalte alle Sicherungen aus, wenn ich das Haus verlasse ;-)). Aber was man alles wann schaltet, das bleibt jedem selbst überlassen. Das schreibt einem kein Modul vor.
Zusammengefasst: "absent" sagt generell aus, dass man nicht da ist. "gone" sagt aus, dass das Haus nicht damit rechnen muss, dass man am gleichen oder darauf folgenden Tag wieder zu Hause sein wird.
Wie groß dein "Anwesen" ist und was du als Radius einstellst, ist natürlich individuell. Wenn deine Garage fast 1km weit weg ist, kann das Sinn machen. Ansonsten sollten auch 100m gut funktionieren. Wenn da schon ausgelöst wird, obwohl deine Garage 10m neben der Haustür ist, stimmt was mit dem Geofency Nachbau deiner Android App nicht und der Entwickler sollte sich an die Nase fassen.
Zitat von: ujaudio am 16 August 2015, 08:20:21
Und aus der Commandref entnehme ich:Also ich ändere den Status und die Location wechslt automatisch mit. Unter Location könnte ich mir ja auch Haus, Garten, Balkon, ggf. sogar die Zimmer vorstellen - oder auch die Koordination, wo ich mich befinde.
Das ist richtig. Die Location nimmt auf den Status so Einfluss, wie es über die Attribute rr_location* eingestellt ist. Alle Locations, die dort nicht konfiguriert sind, ändern auch den Status nicht und können dann z.B. für Schaltungen innerhalb des Hauses genutzt werden. Ich setze dazu iBeacons ein und kann daraufhin bei betreten oder verlassen eines Raumes etwas schalten. Aktuell entwickle ich darauf basierend ein Routing für Audio-Benachrichtigungen, so dass mir Mitteilungen über Sonos immer in dem Raum "zugestellt" werden, in dem ich mich gerade befinde, statt sie im ganzen Haus durchzusagen (siehe hier (http://forum.fhem.de/index.php/topic,39983.0.html)).
Zitat von: ujaudio am 16 August 2015, 08:20:21
Es geht um das Device Residents in der Gruppe Home State. Das Device hat ein festes Icon (blaues, ausgefülltes Haus), der Status wird mit weiteren Icons angezeigt. Letztere meinte ich.
Wenn ich die SVG durch PNG ersetze, dann bekomme ich im Floorplan eine Anzeige - das habe ich mittlerweile herausbekommen. Muss mal suchen, ob ich dazu etwas finde, denn im FHEM Webfrontend ist ja alles bestens, warum es im Floorplan nicht geht??!?
Ich nutze den Floorplan nicht. Das ist eine reine Floorplan Geschichte, bitte dazu im Floorplan Thread nachfragen.
Zitat von: ujaudio am 16 August 2015, 08:20:21
Kannst du bitte nochmals erklären, was es mit dem Attribut "wakeupResetdays" auf sich hat? Ich habe wohl einen Knoten im Hirn, aber der Reset eines Weckers ist mir einfach nicht klar. DIe Erklärung aus dem Wiki habe ich einfach nicht verstanden. Und was bedeutet ein deaktiviertes, resp. ein aktiviertes Reset?
Das Attribut ist dafür da automatisch auf eine bestimmte Weckzeit zu stellen (=Reset auf eine Standard Weckzeit).
Bei mir steht die Zeit auf 07:30. Wenn ich dann mal zu einer früheren Zeit geweckt werden will/muss, dann stelle ich sie am Abend individuell über die Auswahlbox entsprechend. Ich möchte aber in der Regel am übernächsten Tag nicht wieder so früh geweckt werden. Bei gesetztem Attribut wakeupResetdays kann ich dann steuern, an welchen Wochentag nach dem Wecken wieder auf 07:30 gestellt werden soll. Bei meinem Mo-Fr Wecker steht das Reading auch auf Mo-Fr, sprich der wird immer sofort zurückgesetzt. Für diesen Wecker habe ich auch den Reset-Switcher konfiguriert, damit ich das Zurücksetzen des Weckers auch mal für ein paar Tage ausschalten kann, falls ich weiß, dass ich doch ein paar Tage hintereinander früher aufstehen muss. Jeden Sonntag morgen setze ich dann diesen Reset Switcher auf "auto", da ich bei mir davon ausgehe, dass ich in einer neuen Woche wieder zur gewohnten Zeit aufstehen kann. Ansonsten stelle ich Sonntag Abend ohnehin den Wecker für Montag früh anders. Es ist doch so: An Ausnahmen der Regel denkt man immer, aber wenn alles so ist wie immer denkt man nicht daran, das man den Wecker wieder auf die gewohnte Zeit stellen muss und ärgert sich, plötzlich 2h früher geweckt zu werden (vor allem, weil Samstag und Sonntag andere Wecker zu einer anderen Zeit geweckt haben und man dort noch nicht bemerkt hat, dass der Wecker noch so früh eingestellt ist).
Das hängt bei mir auch damit zusammen, dass die Wecker generell immer wecken, wenn ich zuhause bin. Egal ob ich vorher den Status auf "asleep" gesetzt habe oder nicht. "asleep" steuert bei mir nur das ausschalten der Geräte, nicht wie das Weckprogramm läuft. Hintergrund: Wenn ich mal auf dem Sofa einschlafe oder aus sonst einem Grund nicht auf "asleep" schalte, dann möchte ich trotzdem geweckt werden. Sonst brauche ich kein Weckprogramm, wenn ich mich nicht darauf verlassen kann, dass ich auch immer zuverlässig geweckt werde...
Bei meinem Samstag oder Sonntags Wecker steht der Wert nur auf jeweils Samstag oder Sonntag. So kann ich auch während der Woche schon eine Weckzeit vorher einstellen, bin aber trotzdem sicher, dass an dem darauf folgenden Wochenende wieder zu meiner gewohnten Zeit geweckt wird, ohne dass ich daran denken müsste die Weckzeit zuvor einmal verändert zu haben.
Diese Funktion ist generell ein Angebot (wie so vieles), man kann seine Automation drum herum auch selbst so schreiben, wie man es will. Niemand wird gezwungen es zu verwenden, darf aber überlegen, ob er es für sich sinnvoll einsetzen oder erweitern kann.
Zitat von: kjmEjfu am 16 August 2015, 12:40:53
vielleicht ist da ja http://siio.de/lichtschatten/die-perfekte-lichtsteuerung-mit-fibaro-lua-teil-1/ (http://siio.de/lichtschatten/die-perfekte-lichtsteuerung-mit-fibaro-lua-teil-1/) eine Inspiration für
Die Tageszeit spielt beim geplanten HOMESTATE Modul eine Rolle, ja.
Ich habe die Modulfunktion auch schon in Dummys und jeder Menge DOIFs nachgebaut, feile aber noch an Details bevor ich weiß, wie ich das in ein Modul gießen möchte. Es kann sogar sein, dass es ähnlich wie der Wecker auch nur als eine Art Vorlage mit in das RESIDENTS Modul kommt, mal sehen.
Danke, jetzt habe ich wohl die wsentliche Philosophie dahinter verstanden!
Wie kann ich bspw. einen zusätzlichen Status "returnToHome" einstellen?
Ich möchte wenn ich auf dem Weg nach Hause bin, bereits die Klimaanlage und/oder Heizung laufen lassen.
Zitat von: rrr am 22 August 2015, 22:17:56
Wie kann ich bspw. einen zusätzlichen Status "returnToHome" einstellen?
Ich möchte wenn ich auf dem Weg nach Hause bin, bereits die Klimaanlage und/oder Heizung laufen lassen.
In der commandref (http://fhem.de/commandref.html#ROOMMATE (http://fhem.de/commandref.html#ROOMMATE)) steht:
Whenever location is set to 'wayhome', the reading 'wayhome' is set to '1' if current presence state is 'absent'. If attribute rr_locationWayhome was defined, LEAVING one of those locations will set reading 'wayhome' to '1' as well. So you actually have implicit and explicit options to trigger wayhome.
Arriving at home will reset the value of 'wayhome' to '0'.Damit müsste deine Anforderung doch erfüllbar sein.
Darf ich noch eine Frage stellen?
Es gibt vordefinierte notify für gotosleep, asleep und awoken. Warum (nur) diese? Ich werde mir nun auch notify für home, gone und absent erstellen... Und warum gibt es die zusätzlichen watchdogs?
Du spricht von der Wecker Vorlage?
Ganz einfach, weil die Vorlage eben nur ein Beispiel sein kann und man es ohnehin anpassen muss. Daher ist es minimal gehalten, erweitern kann man immer ;)
Die definierten Watchdogs sind Teil der Weckautomations-Vorlage und dienen dazu, dass die Ausführung der Macro-Notifies verzögert wird, um z.B. bei einem versehentlichen Statuswechsel (und wieder zurück) nicht direkt auszulösen.
Die Status home, gone und absent haben nichts mit dem Weckprogramm zu tun, sondern sind Teil der generell immer individuelle Automatisierung, die jeder für sich und seine Anforderungen/Vorstellungen selbst in FHEM definiert.
Ok, soweit klar, jetzt habe ich mir eine LightScene erstellt, deren Szenen genau so heißen, wie der Status von Residents (bei mir heißt das Device "menschen") sein kann. Insbesondere eben home, abesnt und gone. Die LightScene funktioniert perfekt, solange ich sie über die Kommandozeile anspreche, z.B. set myLS scene home
Nun wollte ich ein einfaches notify mit folgender Definition machen:
menschen set myLS scene $EVENT
Immer wenn sich der Status von menschen ändert, wird das notify getriggert und myLS gesetzt. Leider funktioniert das nicht, ich bekomme in myLS als Status nicht die neue Szene sondern "lastActivityBy:"
Anfängerdoku sagt mir aber, dass das so richtig sein sollte - oder habe ich einen Knoten im Kopf?
Wenn hier falsch aufgehängt, dann bitte kurze Info, dann poste ich es an anderer Stelle und lösche es hier.
du musst das Event auf :state einschränken. Es werden mehrere Events zusammen ausgelöst, wenn du menschen veränderst. oder du setzt hei menschen das Attribut event-on-change-reading=state. Sind aber alles FHEM Basics, da solltest du dich nochmals einlesen ;-)
Dein Weckprogramm hat mir schon jede Menge Arbeti erspart, Dinge selbst auszutüfteln. Für eine Kleinigkeit suche ich noch einen eleganten Weg: Es kommt ein paar Mal im Jahr vor, dass ich am nächsten tag keinen Wecker haben will. Ich möchte demzufolge am Vorabend, wenn ich schlafen gehe, einmalig den Wecker ausschalten, am nächsten Morgen kann ich dann bis in ide Puppen schlafen - aber am Folgetag soll er wieder ganz normal klingeln. Hast du eine gute Idee? Ich würde ihn über Tastendruck ganz ausschalten und mit dem nächsten "gotosleep" wieder einschalten.
Genau dafür ist eigentlich die Reset-Funktion gedacht.
Der Wecker wird dann am Folgetag zu der Zeit, zu der er zuletzt aktiv war, automatisch wieder mit der im Attribut wakeupDefaultTime hinterlegten Zeit aktiviert. Die Funktion ist also sowohl für das Zurücksetzen kurzzeitig veränderter Wecker gedacht als auch für das erneute Aktivieren kurzzeitig deaktivierter Wecker. Wenn das Attribut wakeupResetdays nicht gesetzt ist, wird der Wecker täglich entsprechend auf die Default-Zeit gesetzt.
Das Modul funktioniert erstklassig (DANKE!), auch der Wecker!
Aber gestern ist bei uns folgendes passiert: weil Sonntag ist, klingelt der Wecker um 9 Uhr. Allerdings sind wir um 8 Uhr aufgestandenund haben den Status der Person auf Home gestellt. Die Erwartung war, dass der Wecker nicht klingelt, wenn man nicht "asleep" ist. Er hat aber dennoch "geklingelt" - und man konnte ihn nicht wie gewohnt durch Druck auf die Taste, die den Staus der Person auf "Home" stellt, abschalten. Mhm ??!?
Es ist absicht, dass der Wecker "klingelt", egal wie der Status des Bewohners dabei ist (beispielsweise weil man aus welchem Grund auch immer abends vergessen sollte sich "schlafend" zu stellen). Ansonsten würde man Gefahr laufen, dass der Wecker nicht klingelt und man verschläft. Für ein früheres Aufstehen ist das grundsätzlich noch ein Problem. Zwar wird bereits berücksichtigt, dass bei Nutzung der Reset Funktion der Wecker bei einer späteren Default-Zeit nicht erneut auslöst. Für ein früheres Aufstehen fehlt allerdings eine Abfrage noch, wann der Status des Bewohners sich zuletzt geändert hat. Ich schaue mal, dass ich das bei Gelegenheit mit einbaue.
Ansonsten ist für das explizite Unterbrechen eines Weckprogramms nicht vorgesehen, dass man den Status des Bewohners wechselt (auch wenn das implizit beim aufstehen passiert). Vielmehr soll beim entsprechenden Wecker ein stop-Befehl geschickt werden. devStateIcon ist dafür bereits so vordefiniert, dass der Wecker ein blaues Icon hat, wenn er gerade aktiv ist und man nur dort drauf drücken muss, um ihn zu unterbrechen (entspricht einem set-Befehl "stop").
Gruß
Julian
Hallo Leute,
ersteinmal danke für dieses tolle Modul.
Leider schaffe ich es bislang noch nicht, den Status von Geräten die ich mit PRESENCE erfolgreich überwache an die Residents weiter zu geben. Wie mache ich das? Mit notifies oder watchdogs? Bislang werden folgende Geräte mit PRESENCE überwacht:
mako_bluetooth
Wlan_Device_klte
Wlan_Device_mako
mako_bluetooth und Wlan_Device_mako sollen dem Resident rr_Leo zugeordnet werden, Wlan_Device_klte dem Resident rr_Peter.
Bislang habe ich foldendes probiert aber es klappt einfach nicht:
define mako_WLAN_home notify Wlan_Device_mako:present set rr_Leo home
define mako_Bluetooth_home notify Bluetooth_Device_mako:present set rr_Leo home
define mako_WLAN_absent notify Wlan_Device_mako:absent set rr_Leo absent
define klte_WLAN_home notify Wlan_Device_klte:present set rr_Peter home
define klte_WLAN_absent notify Wlan_Device_klte:absent set rr_Peter absent
Leider tut sich da aber nix. Die PRESENCE devices spiegeln den Status korrekt wieder, aber die Residents bleiben immer auf dem Status "home".
Die PRESENCE devices haben alle das attribut "event-on-change-reading state"
Weiß jemand Rat?
es muss heißen
set rr_Peter state absent
usw.
Da bin ich auch darüber gestolpert ;)
Wie ich ein notify baue, welches triggert, sobald der Status auf "home" geht, weiß ich. Aber ich möchte unterscheiden ob es von "absent nach home" gewechselt hat oder ob es von "asleep nach home" gewechselt hat. Kann mir bitte jemand mal einen Tipp geben?
Danke ujaudio! Jetzt klappt es!
Als nächstes möchte ich natürlich basierend auf den Stati der Residents Aktionen durchführen. Alles ausschalten wenn keiner zu Hause ist ist glaub ich einfach (Wohnung1 ist mein Residents device):
define watchdog_Anwesenheit watchdog Wohnung1:absent 00:15 Wohnung1:home set Gesamte_Wohnung off ;; setstate watchdog_Anwesenheit defined
attr watchdog_Anwesenheit regexp1WontReactivate 1Aber wie kann ich lösen, dass wenn Leo nach hause kommt, das Licht in der Küche angeht, aber nur wenn Peter nicht da ist? Kann das Event für das Notify irgendwie eine "&"-Verknüpfung sein oder kann man das ganze in eine If bedingung packen? Wie würde so ein Notify aussehen?
ZitatAber ich möchte unterscheiden ob es von "absent nach home" gewechselt hat oder ob es von "asleep nach home" gewechselt hat. Kann mir bitte jemand mal einen Tipp geben?
Kann man hierzu nicht irgendwie das Reading "lastState" über eine "&" Verknüpfung mit einbeziehen? Ich blicke leider durch die FHEM/Perl Syntax nicht durch, sodass das Programmieren hier eher zum Ratespiel wird. Irgendwie gibt es zu den Residents auch keine "get" Methode...
schau Dir mal das DOIF Modul an...
Danke für den Hinweis. Es funtkioniert schon fast:
define Leo_coming_home_di DOIF ([rr_Peter] eq "absent" and [rr_Leo] eq "home") (set SqueezeKueche volume 90; sleep 0.5; set SqueezeKueche playlists Metal; sleep 0.5; set SqueezeKueche shuffle song; sleep 0.5; set SqueezeKueche play)
lässt die Squeezebox losspielen wenn Leo heimkommt und Peter weg ist. Allerdings spielt sie auch los, sobald Peter das Haus verlässt. Das möchte ich nicht. Wie setze ich das mit DOIF um?
Normalerweise würde ich zwei verschachtelte If-Bedinungen verwenden, wobei der trigger die äußere wäre. Mit DOIF geht das aber scheinbar nicht.
Die Definition:
define Leo_coming_home_di DOIF ([rr_Leo] eq "home") DOIF ([rr_Peter] eq "absent") (set SqueezeKueche volume 90; sleep 0.5; set SqueezeKueche playlists Metal; sleep 0.5; set SqueezeKueche shuffle song; sleep 0.5; set SqueezeKueche play)
gibt den Fehler im Logfile:
2015.09.19 17:11:59 2: Leo_coming_home_di: DOIF (home eq "absent") (set SqueezeKueche volume 90; sleep 0.5; set SqueezeKueche playlists Metal; sleep 0.5; set SqueezeKueche shuffle song; sleep 0.5; set SqueezeKueche play): Unknown command DOIF, try help.
Jemand eine Idee wie ich das hinbekommen kann?
EDIT:
In Anlehnung hieran habe ich es jetzt hinbekommen: http://www.fhemwiki.de/wiki/Schalten_mit_mehreren_Bedingungen#Script
define Leo_coming_home_notify rr_Leo:home {if ($value{rr_Peter} eq "absent") {fhem "set SqueezeKueche volume 80; sleep 0.5; set SqueezeKueche playlists Metal; sleep 0.5; set SqueezeKueche shuffle song; sleep 0.5; set SqueezeKueche play"}}
Nur auf den Zustand eines devices zu reagieren und beim umschalten nicht zu triggern funktioniert mit dem ? Schau Dir mal die Comandref an, DOIF ist ausgezeichnet dokumentiert - ansonsten hilft Dir sicher der zugehörige Support Thread...
Ich habe gerade eine neue Version des RESIDENTS Moduls eingecheckt, welches nun neben den nummerischen Readings auch welche mit den Device und Alias Namen erzeugt. Hilfreich, wenn man den Klarnamen z.B. in einer Audio Ansage verwenden oder die Devices anderweitig im Code weiterverarbeiten möchte.
Moin,
ich habe mich jetzt mal etwas intensiver mit dem Residents Tool Kit beschäftigt und habe etwas Probleme damit, die ich bisher nicht lösen konnte.
Zum einen sind die einzigen Modi, die ich für einen Roommate auswählen kann home, gotosleep, absent und gone. Asleep oder awoken werden in dem Dropdown nicht angezeigt.
Zum anderen wird mir der Resetswitcher nicht angezeigt, obwohl ich im Wakeuptimer das Attribut definiert habe.
Mein FHEM ist auf dem aktuellen Stand. Hat jemand nen Tip wo der Fehler liegen kann? Oder habe ich vielleicht eine Einstellung vergessen? (Wahrscheinlich sitzt der Fehler wieder vor dem Monitor ;))
Besten Dank.
Gruß
Robert
Hallo Robert,
du meinst nicht das RESIDENTStoolkit, dieser Begriff ist anders belegt ;)
Du sprichst von der RESIDENTS Modulfamilie (also RESIDENTS, ROOMMATE, GUEST).
Wie in der Commandref beschrieben werden die Status asleep und awoken nur dann aufgeführt, wenn der aktuelle Status entweder gotosleep oder asleep ist. Der Grund ist einfach, dass hier eine Art Mini-Prozess abgebildet ist: Du wachst vermutlich nicht auf, wenn du nicht vorher geschlafen hast... Die Status direkt anzuspringen macht daher eigentlich keinen Sinn. Wenn du anderer Meinung bist, kannst du die Status über das Attribut "rr_showAllStates" einblenden. Alternativ kannst du auch nur ganz gezielte Status über das Attribut "rr_states" einblenden (widgetOverride sollte auch funktionieren, wer es bevorzugt).
Der Resetswitcher ist wiederrum korrekterweise Teil des RESIDENTStoolkit :D
Der Resetswitcher wird automatisch angelegt, wenn du im Wecker-Device ein Attribut mit dem Namen wakeupResetSwitcher anlegst. Das Attribut muss den Namen des Gerätes enthalten, welches als Resetswitcher angelegt werden soll. Es darf unter dem Namen kein anderes Gerät geben und es darf kein Leerzeichen oder so im Namen geben.
Du kannst das Attribut auch nochmals löschen und wieder neu anlegen. Ein ggf. bereits erzeugtes Device muss zuvor manuell wieder gelöscht werden.
Zitat von: Loredo am 31 Oktober 2015, 13:15:33
Wie in der Commandref beschrieben werden die Status asleep und awoken nur dann aufgeführt, wenn der aktuelle Status entweder gotosleep oder asleep ist.
Sowas dachte ich mir schon. Allerdings wird mir asleep auch nicht angezeigt wenn ich gotosleep ausgewählt habe.
Zitat von: Loredo am 31 Oktober 2015, 13:15:33
Der Resetswitcher wird automatisch angelegt, wenn du im Wecker-Device ein Attribut mit dem Namen wakeupResetSwitcher anlegst. Das Attribut muss den Namen des Gerätes enthalten, welches als Resetswitcher angelegt werden soll. Es darf unter dem Namen kein anderes Gerät geben und es darf kein Leerzeichen oder so im Namen geben.
Habe ihn nochmal neu angelegt. Tut trotzdem nicht.
Der Wecker heißt rr_Robert_wakeuptimer1 und der Resetswitcher dazu heißt rr_Robert_wakeuptimer1_ResetSwitcher.
Sollte doch so richtig sein. Oder habe ich das doch falsch verstanden?
Zitat von: r_knipp am 31 Oktober 2015, 15:47:47
Sowas dachte ich mir schon. Allerdings wird mir asleep auch nicht angezeigt wenn ich gotosleep ausgewählt habe.
Das liegt daran, dass FHEMWEB das Auswahlmenü nicht aktualisiert, dafür musst du die Seite manuell neu laden. Rudi hatte das glaube ich mal irgendwann gefixt, ist vermutlich dann wieder kaputt gegangen bei irgend einer Änderung in FHEMWEB.
Was aber aktualisiert wird ist das devStateIcon, weshalb darüber ein Wechsel vom Status "gotosleep" zu "asleep" dann problemlos funktioniert. Die Bedienung über das Icon ist ohnehin bequemer.
Zitat von: r_knipp am 31 Oktober 2015, 15:47:47
Habe ihn nochmal neu angelegt. Tut trotzdem nicht.
Der Wecker heißt rr_Robert_wakeuptimer1 und der Resetswitcher dazu heißt rr_Robert_wakeuptimer1_ResetSwitcher.
Sollte doch so richtig sein. Oder habe ich das doch falsch verstanden?
Du kannst das Device nennen wie du willst. Wenn das automatische Anlegen nicht funktioniert ist es wahrscheinlich, dass rr_Robert_wakeuptimer1 nicht richtig vom Vatergerät rr_Robert überwacht wird. In diesem Fall fehlt in rr_Robert dann der Verweis auf rr_Robert_wakeuptimer1 im Attribut "rr_wakeupDevice".
Zitat von: Loredo am 31 Oktober 2015, 15:53:04
Was aber aktualisiert wird ist das devStateIcon, weshalb darüber ein Wechsel vom Status "gotosleep" zu "asleep" dann problemlos funktioniert. Die Bedienung über das Icon ist ohnehin bequemer.
Danke für den Hinweis. Über das Icon funktioniert es.
Zitat von: Loredo am 31 Oktober 2015, 15:53:04
Du kannst das Device nennen wie du willst. Wenn das automatische Anlegen nicht funktioniert ist es wahrscheinlich, dass rr_Robert_wakeuptimer1 nicht richtig vom Vatergerät rr_Robert überwacht wird. In diesem Fall fehlt in rr_Robert dann der Verweis auf rr_Robert_wakeuptimer1 im Attribut "rr_wakeupDevice".
Das Attribut in rr_Robert ist angelegt und verweist definitiv auch auf den richtigen timer. Der ResetSwitcher wird trotzdem nicht angelegt.
Kann man den auch manuell anlegen?
Zitat von: r_knipp am 01 November 2015, 13:52:58
Das Attribut in rr_Robert ist angelegt und verweist definitiv auch auf den richtigen timer. Der ResetSwitcher wird trotzdem nicht angelegt.
Kann man den auch manuell anlegen?
rr_Robert und rr_Robert_wakeuptimer1 sind dann richtig verbunden, wenn du in rr_Robert beim Attribut rr_wakeupDevice den Namen rr_Robert_wakeuptimer1 mit einem Link versehen hast, auf den du drauf klicken und dann zu dem Gerät gelangen kannst.
Du kannst den Dummy auch manuell anlegen. Es ist aber wahrscheinlich, dass er nicht beachtet wird, wenn das automatische Anlegen schon nicht funktioniert.
define rr_Robert_wakeuptimer1_resetswitcher dummy
attr rr_Robert_wakeuptimer1_resetswitcher alias Wake-up time Reset
attr rr_Robert_wakeuptimer1_resetswitcher devStateIcon auto:time_automatic:off off:time_manual_mode:auto
attr rr_Robert_wakeuptimer1_resetswitcher icon refresh
attr rr_Robert_wakeuptimer1_resetswitcher setList state:auto,off
attr rr_Robert_wakeuptimer1_resetswitcher webCmd state
set rr_Robert_wakeuptimer1_resetswitcher auto
Zitat von: Loredo am 01 November 2015, 14:11:51
rr_Robert und rr_Robert_wakeuptimer1 sind dann richtig verbunden, wenn du in rr_Robert beim Attribut rr_wakeupDevice den Namen rr_Robert_wakeuptimer1 mit einem Link versehen hast, auf den du drauf klicken und dann zu dem Gerät gelangen kannst.
Genau so sieht es aus und das wurde ja auch automatisch angelegt.
Hast Du noch eine Idee woran es liegen kann?
Ich habe auch mal im global device und im Timer verbose auf 5 gestellt. Habe im Log aber nichts gefunden, was auf einen Fehler hinweist.
Das Device jetzt manuell anzulegen, wenn es dann nicht beachtet wird, macht dann ja auch keinen Sinn.
Zitat von: r_knipp am 02 November 2015, 13:41:04
Hast Du noch eine Idee woran es liegen kann?
Ich habe auch mal im global device und im Timer verbose auf 5 gestellt. Habe im Log aber nichts gefunden, was auf einen Fehler hinweist.
Das Device jetzt manuell anzulegen, wenn es dann nicht beachtet wird, macht dann ja auch keinen Sinn.
Habe sonst keine Idee. Was sagt das Log bei verbose=5 sowohl beim Wakeuptimer als auch beim RESIDENTS-Device, wenn du da das Attribut wakeupResetSwitcher beim Wakeuptimer löscht und wieder hinzufügst?
Mit dem manuellen anlegen solltest du trotzdem probieren.
Hier erstmal der Log bei verbose auf 5 im global und timer device mit Löschen und gleich darauf wieder Anlegen des Attributs.
[code]
2015.11.02 19:26:05 5: Triggering global (1 changes)
2015.11.02 19:26:05 5: Notify loop for global ATTR global verbose 5
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem?detail=global; BUFLEN:0
2015.11.02 19:26:05 4: name: /fhem?detail=global / RL:3305 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:05 4: Connection accepted from FHEMWEB:192.168.1.123:50020
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem?cmd={AttrVal(%22global%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:05 5: Cmd: >{AttrVal("global","room","")}<
2015.11.02 19:26:05 4: name: /fhem?cmd={AttrVal(%22global%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem?XHR=1&inform=type=status;filter=global;since=1446488764;fmt=JSON×tamp=1446488765827; BUFLEN:0
2015.11.02 19:26:08 4: FHEMWEB:192.168.1.123:50014 POST /fhem?cmd=save&XHR=1; BUFLEN:0
2015.11.02 19:26:08 5: Cmd: >save<
2015.11.02 19:26:08 5: Triggering global (1 changes)
2015.11.02 19:26:08 5: Notify loop for global SAVE
2015.11.02 19:26:08 4: name: /fhem?cmd=save&XHR=1 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_GetStatus()
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ powerstate
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/powerstate (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/powerstate
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/powerstate: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/powerstate: Got data, length: 106
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV powerstate
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES powerstate
<?xml version="1.0" encoding="UTF-8"?>
<e2powerstate>
<e2instandby>
false </e2instandby>
</e2powerstate>
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/getservices?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet& (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ getcurrent
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/getcurrent (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/getcurrent
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ timerlist
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/timerlist (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/timerlist
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ vol
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/vol (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/vol
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ signal
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/signal (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/signal
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/getcurrent: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/getcurrent: Got data, length: 3260
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV getcurrent
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES getcurrent
<?xml version="1.0" encoding="UTF-8"?>
<e2currentserviceinformation>
<e2service>
<e2servicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2servicereference>
<e2servicename>ProSieben</e2servicename>
<e2providername>Digital Free</e2providername>
<e2videowidth>720</e2videowidth>
<e2videoheight>576</e2videoheight>
<e2servicevideosize>720x576</e2servicevideosize>
<e2iswidescreen>
1 </e2iswidescreen>
<e2apid>2202</e2apid>
<e2vpid>2201</e2vpid>
<e2pcrpid>2201</e2pcrpid>
<e2pmtpid>101</e2pmtpid>
<e2txtpid>2204</e2txtpid>
<e2tsid>10008</e2tsid>
<e2onid>61441</e2onid>
<e2sid>53621</e2sid>
</e2service>
<e2eventlist>
<e2event>
<e2eventservicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2eventservicereference>
<e2eventservicename>ProSieben</e2eventservicename>
<e2eventprovidername>Digital Free</e2eventprovidername>
<e2eventid>25698</e2eventid>
<e2eventname>Galileo</e2eventname>
<e2eventtitle>Galileo</e2eventtitle>
<e2eventdescription>Thema u. a.: "Galileo"-Trip zur NSA-Zentrale, Information, D 2015</e2eventdescription>
<e2eventstart>1446487511</e2eventstart>
<e2eventduration>4149</e2eventduration>
<e2eventremaining>2890</e2eventremaining>
<e2eventcurrenttime>1446488770</e2eventcurrenttime>
<e2eventdescriptionextended>Moderation: Stefan Gödde
Edward Snowden gilt als der bekannteste Whistleblower unserer Zeit. Bis zu seinen Enthüllungen im Jahr 2013 wusste kaum jemand über die Machenschaften der NSA Bescheid. Jetzt ist der amerikanische Abhördienst in aller Munde. Doch was macht die National Security Agency genau? "Galileo" ist nach Washington gereist, um einen Einblick in die Arbeit des größten Auslandsgeheimdienstes zu bekommen.</e2eventdescriptionextended>
</e2event>
<e2event>
<e2eventservicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2eventservicereference>
<e2eventservicename>ProSieben</e2eventservicename>
<e2eventprovidername>Digital Free</e2eventprovidername>
<e2eventid>25699</e2eventid>
<e2eventname>The Big Bang Theory</e2eventname>
<e2eventtitle>The Big Bang Theory</e2eventtitle>
<e2eventdescription>Über Nacht im Fort, Sitcom, USA 2014</e2eventdescription>
<e2eventstart>1446491660</e2eventstart>
<e2eventduration>1757</e2eventduration>
<e2eventremaining>4647</e2eventremaining>
<e2eventcurrenttime>1446488770</e2eventcurrenttime>
<e2eventdescriptionextended>Penny wird von Will Wheaton für seinen Podcast interviewt. Während der Show ruft der Regisseur Kevin Smith an und möchte sie für seinen neuen Film casten. Leonard ist von der Idee wenig begeistert ... Howard steht kurz davor, das Haus seiner Mutter zu erben, es fehlt nur noch eine Formalität. Dann taucht plötzlich sein bislang unbekannter Halbbruder Josh auf ...
Gast: Wil Wheaton
Regie: Mark Cendrowski
Drehbuch: Steven Molaro
Kamera: Steven V. Silver
Schnitt: Peter Chakos
Darsteller:
Johnny Galecki (Leonard Hofstadter)
Jim Parsons (Sheldon Cooper)
Simon Helberg (Howard Wolowitz)
Kunal Nayyar (Rajesh Koothrappali)
Kaley Cuoco (Penny)
Mayim Bialik (Amy Farrah Fowler)
Melissa Rauch (Bernadette Rostenkowski)
Matt Bennett (Josh Wolowitz)</e2eventdescriptionextended>
</e2event>
</e2eventlist>
</e2currentserviceinformation>
2015.11.02 19:26:12 5: Triggering VUUno (8 changes)
2015.11.02 19:26:12 5: Notify loop for VUUno eventremaining: 2890
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/signal: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/signal: Got data, length: 179
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV signal
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES signal
<?xml version="1.0" encoding="UTF-8"?>
<e2frontendstatus>
<e2snrdb> 65 dB </e2snrdb>
<e2snr> 65 % </e2snr>
<e2ber> -1245813 </e2ber>
<e2acg> 76 % </e2acg>
</e2frontendstatus>
2015.11.02 19:26:12 5: Triggering VUUno (4 changes)
2015.11.02 19:26:12 5: Notify loop for VUUno snrdb: 65
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&: Got data, length: 72
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
<?xml version="1.0" encoding="UTF-8"?>
<e2servicelist>
</e2servicelist>
2015.11.02 19:26:12 4: ENIGMA2 VUUno: ERROR: Unable to read radio bouquet '1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet' from device
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/timerlist: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/timerlist: Got data, length: 68
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV timerlist
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES timerlist
<?xml version="1.0" encoding="UTF-8"?>
<e2timerlist>
</e2timerlist>
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/vol: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/vol: Got data, length: 184
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV vol
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES vol
<?xml version="1.0" encoding="utf-8"?>
<e2volume>
<e2result>True</e2result>
<e2resulttext>Status</e2resulttext>
<e2current>30</e2current>
<e2ismuted>False</e2ismuted>
</e2volume>
2015.11.02 19:26:17 5: HMLAN_Send: hmusb I:K
2015.11.02 19:26:17 5: HMLAN/RAW: /HHM-LAN-IF,03C4,KEQ1111221,2633D6,ABC123,01786608,0003
2015.11.02 19:26:17 5: HMLAN_Parse: hmusb V:03C4 sNo:KEQ1111221 d:2633D6 O:ABC123 t:01786608 IDcnt:0003 L:0 %
2015.11.02 19:26:17 5: Triggering hmusb (1 changes)
2015.11.02 19:26:17 5: Notify loop for hmusb loadLvl: low
2015.11.02 19:26:21 4: Connection closed for FHEMWEB:192.168.1.123:50013: EOF
2015.11.02 19:26:21 4: FHEMWEB:192.168.1.123:50014 GET /fhem?room=all; BUFLEN:0
2015.11.02 19:26:21 5: ENIGMA2 VUUno: called function ENIGMA2_Set()
2015.11.02 19:26:21 5: GEOFANCY geofancy: called function GEOFANCY_Set()
2015.11.02 19:26:21 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2015.11.02 19:26:21 5: ROOMMATE rr_Robert: called function ROOMMATE_Set()
2015.11.02 19:26:21 5: SYSMON sysmon_Main: Set.744 sysmon_Main ?
2015.11.02 19:26:21 5: ROOMMATE rr_Sandra: called function ROOMMATE_Set()
2015.11.02 19:26:21 4: name: /fhem?room=all / RL:13595 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: Connection accepted from FHEMWEB:192.168.1.123:50021
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/svg.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/Zoom-in.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 GET /fhem/icons/weather/cloudy; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem/images/default/Zoom-out.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/icons/weather/partly_cloudy; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 GET /fhem/images/default/Prev.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 GET /fhem/SVG_showLog?dev=SVG_log_temps_Aquarium_1&logdev=log_temps_Aquarium&gplotfile=SVG_log_temps_Aquarium_1&logfile=CURRENT&pos=; BUFLEN:0
2015.11.02 19:26:22 5: plotcommand: get log_temps_Aquarium CURRENT INT 2015-11-01_19:30:00 2015-11-02_19:30:01 4:temp_Aquarium.T\x3a::
2015.11.02 19:26:22 5: Cmd: >get log_temps_Aquarium CURRENT INT 2015-11-01_19:30:00 2015-11-02_19:30:01 4:temp_Aquarium.T\x3a::<
2015.11.02 19:26:22 4: log_temps_Aquarium get: Input file ./log/log_temps_Aquarium_11.log, from:2015-11-01_19:30:00 to:2015-11-02_19:30:01
2015.11.02 19:26:22 4: log_temps_Aquarium get: line 1, regexp:temp_Aquarium.T\x3a, col:3, output lines:undef
2015.11.02 19:26:22 5: Cmd: >{ "log_temps_Aquarium_11.log" }<
2015.11.02 19:26:22 4: name: /fhem/SVG_showLog?dev=SVG_log_temps_Aquarium_1&logdev=log_temps_Aquarium&gplotfile=SVG_log_temps_Aquarium_1&logfile=CURRENT&pos= / RL:2071 / image/svg+xml / Content-Encoding: gzip
/
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/icons/weather/mostly_sunny; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem?XHR=1&inform=type=status;filter=room=all;since=1446488780;fmt=JSON×tamp=1446488782322; BUFLEN:0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: updateReadings.1053
2015.11.02 19:26:33 5: Triggering sysmon_Main (4 changes)
2015.11.02 19:26:33 5: Notify loop for sysmon_Main cpu_freq: 700
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Set.744 sysmon_Main ?
2015.11.02 19:26:33 4: BlockingCall created child (11997), uses telnetForBlockingFn to connect back
2015.11.02 19:26:33 5: Triggering rr_Sandra (2 changes)
2015.11.02 19:26:33 5: Notify loop for rr_Sandra durTimerAbsence_cr: 6836
2015.11.02 19:26:33 5: SYSMON sysmon_Main: blockingCall.947 sysmon_Main,
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -d /proc/ ] && echo 1 || echo 0'
2015.11.02 19:26:33 5: RESIDENTS rr_Sandra: processing change durTimerAbsence_cr: 6836
2015.11.02 19:26:33 5: RESIDENTS rr_Sandra: processing change durTimerAbsence: 113:55:55
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '1'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /proc/uptime'
2015.11.02 19:26:33 5: ROOMMATE rr_Sandra: called function ROOMMATE_Set()
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '8572124.67 8483884.66'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -f /sys/devices/system/cpu/kernel_max ] && echo 1 || echo 0'
2015.11.02 19:26:33 5: Triggering rr_Robert (2 changes)
2015.11.02 19:26:33 5: Notify loop for rr_Robert durTimerPresence_cr: 149
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '1'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /sys/devices/system/cpu/kernel_max'
2015.11.02 19:26:33 5: RESIDENTS rr_Robert: processing change durTimerPresence_cr: 149
2015.11.02 19:26:33 5: RESIDENTS rr_Robert: processing change durTimerPresence: 02:29:25
2015.11.02 19:26:33 5: ROOMMATE rr_Robert: called function ROOMMATE_Set()
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '0'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /sys/class/thermal/thermal_zone0/temp 2>&1'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '43312'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -f /sys/class/hwmon/hwmon0/device/temp1_input ] && echo 1 || echo 0'
2015.11.02 19:26:33 4: Connection closed for FHEMWEB:192.168.1.123:50018: EOF
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem?detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '0'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /proc/loadavg'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '0.03 0.03 0.05 3/71 12004'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /proc/stat'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4095 Result '$VAR1 = 'cpu 4639549 0 3780298 842181125 264461 3267 71154 0 0 0
';
$VAR2 = 'cpu0 4639549 0 3780298 842181125 264461 3267 71154 0 0 0
';
$VAR3 = 'intr 3207117959 0 0 0 157343914 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3036804125 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 91013 1 0 0 0 0 0 0 0 0 1 0 1013428 0 0 0 0 0 64 11865413 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
';
$VAR4 = 'ctxt 405764610
';
$VAR5 = 'btime 1437916668
';
$VAR6 = 'processes 1698077
';
$VAR7 = 'procs_running 2
';
$VAR8 = 'procs_blocked 0
';
$VAR9 = 'softirq 204954440 81924887 95149086 1700286 3590363 0 0 13087054 0 87935 9414829
';
'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'free'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4095 Result '$VAR1 = ' total used free shared buffers cached
';
$VAR2 = 'Mem: 188284 165112 23172 0 30928 67380
';
$VAR3 = '-/+ buffers/cache: 66804 121480
';
$VAR4 = 'Swap: 102396 0 102396
';
'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: getNetworkInfo.2650 get eth0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'ifconfig eth0 2>&1'
2015.11.02 19:26:33 4: name: /fhem?detail=rr_Robert_wakeuptimer1 / RL:3335 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4095 Result '$VAR1 = 'eth0 Link encap:Ethernet HWaddr b8:27:eb:4d:76:a7
';
$VAR2 = ' inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
';
$VAR3 = ' UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
';
$VAR4 = ' RX packets:1551178 errors:0 dropped:0 overruns:0 frame:0
';
$VAR5 = ' TX packets:1893449 errors:0 dropped:0 overruns:0 carrier:0
';
$VAR6 = ' collisions:0 txqueuelen:1000
';
$VAR7 = ' RX bytes:409157070 (390.2 MiB) TX bytes:312638533 (298.1 MiB)
';
$VAR8 = '
';
'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: getNetworkInfo.2662 SYSMON_getNetworkInfo>>>>>>>>>>>>>>>>$VAR1 = 'eth0 Link encap:Ethernet HWaddr b8:27:eb:4d:76:a7
';
$VAR2 = ' inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
';
$VAR3 = ' UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
';
$VAR4 = ' RX packets:1551178 errors:0 dropped:0 overruns:0 frame:0
';
$VAR5 = ' TX packets:1893449 errors:0 dropped:0 overruns:0 carrier:0
';
$VAR6 = ' collisions:0 txqueuelen:1000
';
$VAR7 = ' RX bytes:409157070 (390.2 MiB) TX bytes:312638533 (298.1 MiB)
';
$VAR8 = '
';
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -f /sys/class/net/eth0/statistics/rx_bytes ] && echo 1 || echo 0'
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '1'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /sys/class/net/eth0/statistics/rx_bytes'
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '409161772'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /sys/class/net/eth0/statistics/tx_bytes'
2015.11.02 19:26:33 4: Connection accepted from FHEMWEB:192.168.1.123:50022
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '312643803'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -f /sys/class/net/eth0/speed ] && cat /sys/class/net/eth0/speed 2>/dev/null || echo not available'
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '100'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: getNetworkInfo.2650 get wlan0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'ifconfig wlan0 2>&1'
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50022 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50022 => 304 Not Modified
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result 'wlan0: error fetching interface information: Device not found'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: getNetworkInfo.2662 SYSMON_getNetworkInfo>>>>>>>>>>>>>>>>$VAR1 = 'wlan0: error fetching interface information: Device not found';
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 4: Connection accepted from telnet:127.0.0.1:34250
2015.11.02 19:26:33 5: Cmd: >{SYSMON_blockingFinish('name|sysmon_Main|eth0|RX: 390.21 MB, TX: 298.16 MB, Total: 688.37 MB|eth0_rx|409161772|cpu_temp_stat|40.08 54.07 43.42|starttime|1437916668|swap|Total: 100.00 MB, Used: 0.00 MB, 0.00 %, Free: 100.00 MB|cpu_temp_avg|43.5|uptime|8572124|cpu_temp|43.31|stat_cpu|4639549 0 3780298 842181125 264461 3267 71154|stat_cpu_diff|437 0 53 6028 0 0 9|eth0_ip|192.168.1.20|stat_cpu_percent|6.70 0.00 0.81 92.35 0.00 0.00 0.14|fhemstarttime_text|31.10.2015 12:34:48|cpu_core_count|1|eth0_tx|312643803|ram|Total: 183.87 MB, Used: 65.24 MB, 35.48 %, Free: 118.63 MB|starttime_text|26.07.2015 15:17:48|fhemuptime|197505|fhemstarttime|1446291288|eth0_diff|RX: 0.08 MB, TX: 0.09 MB, Total: 0.17 MB|uptime_text|99 days, 05 hours, 08 minutes|idletime_text|98 days, 04 hours, 38 minutes (98.97 %)|wlan0_diff|not available|stat_cpu_text|user: 6.70 %, nice: 0.00 %, sys: 0.81 %, idle: 92.35 %, io: 0.00 %, irq: 0.00 %, sirq: 0.14 %|cpu_idle_stat|0.00 99.16 96.42|swap_used_stat|0.00 0.00 0.00|wlan0|not available|loadavg|0.03 0.03 0.05|idletime|8483884 98.97 %|fhemuptime_text|2 days, 06 hours, 51 minutes|eth0_speed|100|ram_used_stat|56.73 83.19 64.73')}<
2015.11.02 19:26:33 5: SYSMON sysmon_Main: blockingFinish.1034 name|sysmon_Main|eth0|RX: 390.21 MB, TX: 298.16 MB, Total: 688.37 MB|eth0_rx|409161772|cpu_temp_stat|40.08 54.07 43.42|starttime|1437916668|swap|Total: 100.00 MB, Used: 0.00 MB, 0.00 %, Free: 100.00 MB|cpu_temp_avg|43.5|uptime|8572124|cpu_temp|43.31|stat_cpu|4639549 0 3780298 842181125 264461 3267 71154|stat_cpu_diff|437 0 53 6028 0 0 9|eth0_ip|192.168.1.20|stat_cpu_percent|6.70 0.00 0.81 92.35 0.00 0.00 0.14|fhemstarttime_text|31.10.2015 12:34:48|cpu_core_count|1|eth0_tx|312643803|ram|Total: 183.87 MB, Used: 65.24 MB, 35.48 %, Free: 118.63 MB|starttime_text|26.07.2015 15:17:48|fhemuptime|197505|fhemstarttime|1446291288|eth0_diff|RX: 0.08 MB, TX: 0.09 MB, Total: 0.17 MB|uptime_text|99 days, 05 hours, 08 minutes|idletime_text|98 days, 04 hours, 38 minutes (98.97 %)|wlan0_diff|not available|stat_cpu_text|user: 6.70 %, nice: 0.00 %, sys: 0.81 %, idle: 92.35 %, io: 0.00 %, irq: 0.00 %, sirq: 0.14 %|cpu_idle_stat|0.00 99.16 96.42|swap_used_stat|0.00 0.00 0.00|wlan0|not available|loadavg|0.03 0.03 0.05|idletime|8483884 98.97 %|fhemuptime_text|2 days, 06 hours, 51 minutes|eth0_speed|100|ram_used_stat|56.73 83.19 64.73
2015.11.02 19:26:33 5: SYSMON sysmon_Main: updateReadings.1053
2015.11.02 19:26:33 5: Triggering sysmon_Main (32 changes)
2015.11.02 19:26:33 5: Notify loop for sysmon_Main eth0: RX: 390.21 MB, TX: 298.16 MB, Total: 688.37 MB
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:33 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","room","")}<
2015.11.02 19:26:33 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1 / RL:33 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 GET /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:33 5: Cmd: >{ReadingsVal("rr_Robert_wakeuptimer1","end","")}<
2015.11.02 19:26:34 4: name: /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50019 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50022 GET /fhem?XHR=1&inform=type=status;filter=rr_Robert_wakeuptimer1;since=1446488792;fmt=JSON×tamp=1446488793976; BUFLEN:0
2015.11.02 19:26:41 4: Connection closed for FHEMWEB:192.168.1.123:50022: EOF
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem?cmd.rr_Robert_wakeuptimer1=deleteattr%20rr_Robert_wakeuptimer1%20wakeupResetSwitcher&detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:26:41 5: Cmd: >deleteattr rr_Robert_wakeuptimer1 wakeupResetSwitcher<
2015.11.02 19:26:41 5: Triggering global (1 changes)
2015.11.02 19:26:41 5: Notify loop for global DELETEATTR rr_Robert_wakeuptimer1 wakeupResetSwitcher
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem?detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:26:41 4: name: /fhem?detail=rr_Robert_wakeuptimer1 / RL:3322 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:41 4: Connection accepted from FHEMWEB:192.168.1.123:50023
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:41 5: Cmd: >{ReadingsVal("rr_Robert_wakeuptimer1","end","")}<
2015.11.02 19:26:41 4: name: /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:41 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","room","")}<
2015.11.02 19:26:41 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1 / RL:33 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem?XHR=1&inform=type=status;filter=rr_Robert_wakeuptimer1;since=1446488800;fmt=JSON×tamp=1446488801775; BUFLEN:0
2015.11.02 19:26:42 5: HMLAN_Send: hmusb I:K
2015.11.02 19:26:42 5: HMLAN/RAW: /HHM-LAN-IF,03C4,KEQ1111221,2633D6,ABC123,0178C7A9,0003
2015.11.02 19:26:42 5: HMLAN_Parse: hmusb V:03C4 sNo:KEQ1111221 d:2633D6 O:ABC123 t:0178C7A9 IDcnt:0003 L:0 %
2015.11.02 19:26:42 5: Triggering hmusb (1 changes)
2015.11.02 19:26:42 5: Notify loop for hmusb loadLvl: low
2015.11.02 19:26:43 4: FHEMWEB:192.168.1.123:50019 POST /fhem?cmd=save&XHR=1; BUFLEN:0
2015.11.02 19:26:43 5: Cmd: >save<
2015.11.02 19:26:43 5: Triggering global (1 changes)
2015.11.02 19:26:43 5: Notify loop for global SAVE
2015.11.02 19:26:43 4: name: /fhem?cmd=save&XHR=1 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:55 4: FHEMWEB:192.168.1.123:50019 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22wakeupResetSwitcher%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:55 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","wakeupResetSwitcher","")}<
2015.11.02 19:26:55 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22wakeupResetSwitcher%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_GetStatus()
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ powerstate
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/powerstate (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/powerstate
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/powerstate: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/powerstate: Got data, length: 106
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV powerstate
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES powerstate
<?xml version="1.0" encoding="UTF-8"?>
<e2powerstate>
<e2instandby>
false </e2instandby>
</e2powerstate>
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/getservices?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet& (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ getcurrent
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/getcurrent (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/getcurrent
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ timerlist
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/timerlist (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/timerlist
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ vol
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/vol (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/vol
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ signal
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/signal (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/signal
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/timerlist: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/timerlist: Got data, length: 68
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV timerlist
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES timerlist
<?xml version="1.0" encoding="UTF-8"?>
<e2timerlist>
</e2timerlist>
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&: Got data, length: 72
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
<?xml version="1.0" encoding="UTF-8"?>
<e2servicelist>
</e2servicelist>
2015.11.02 19:26:57 4: ENIGMA2 VUUno: ERROR: Unable to read radio bouquet '1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet' from device
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/vol: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/vol: Got data, length: 184
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV vol
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES vol
<?xml version="1.0" encoding="utf-8"?>
<e2volume>
<e2result>True</e2result>
<e2resulttext>Status</e2resulttext>
<e2current>30</e2current>
<e2ismuted>False</e2ismuted>
</e2volume>
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/signal: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/signal: Got data, length: 178
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV signal
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES signal
<?xml version="1.0" encoding="UTF-8"?>
<e2frontendstatus>
<e2snrdb> 65 dB </e2snrdb>
<e2snr> 65 % </e2snr>
<e2ber> 1643001 </e2ber>
<e2acg> 76 % </e2acg>
</e2frontendstatus>
2015.11.02 19:26:57 5: Triggering VUUno (4 changes)
2015.11.02 19:26:57 5: Notify loop for VUUno snrdb: 65
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/getcurrent: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/getcurrent: Got data, length: 3260
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV getcurrent
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES getcurrent
<?xml version="1.0" encoding="UTF-8"?>
<e2currentserviceinformation>
<e2service>
<e2servicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2servicereference>
<e2servicename>ProSieben</e2servicename>
<e2providername>Digital Free</e2providername>
<e2videowidth>720</e2videowidth>
<e2videoheight>576</e2videoheight>
<e2servicevideosize>720x576</e2servicevideosize>
<e2iswidescreen>
1 </e2iswidescreen>
<e2apid>2202</e2apid>
<e2vpid>2201</e2vpid>
<e2pcrpid>2201</e2pcrpid>
<e2pmtpid>101</e2pmtpid>
<e2txtpid>2204</e2txtpid>
<e2tsid>10008</e2tsid>
<e2onid>61441</e2onid>
<e2sid>53621</e2sid>
</e2service>
<e2eventlist>
<e2event>
<e2eventservicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2eventservicereference>
<e2eventservicename>ProSieben</e2eventservicename>
<e2eventprovidername>Digital Free</e2eventprovidername>
<e2eventid>25698</e2eventid>
<e2eventname>Galileo</e2eventname>
<e2eventtitle>Galileo</e2eventtitle>
<e2eventdescription>Thema u. a.: "Galileo"-Trip zur NSA-Zentrale, Information, D 2015</e2eventdescription>
<e2eventstart>1446487511</e2eventstart>
<e2eventduration>4149</e2eventduration>
<e2eventremaining>2844</e2eventremaining>
<e2eventcurrenttime>1446488816</e2eventcurrenttime>
<e2eventdescriptionextended>Moderation: Stefan Gödde
Edward Snowden gilt als der bekannteste Whistleblower unserer Zeit. Bis zu seinen Enthüllungen im Jahr 2013 wusste kaum jemand über die Machenschaften der NSA Bescheid. Jetzt ist der amerikanische Abhördienst in aller Munde. Doch was macht die National Security Agency genau? "Galileo" ist nach Washington gereist, um einen Einblick in die Arbeit des größten Auslandsgeheimdienstes zu bekommen.</e2eventdescriptionextended>
</e2event>
<e2event>
<e2eventservicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2eventservicereference>
<e2eventservicename>ProSieben</e2eventservicename>
<e2eventprovidername>Digital Free</e2eventprovidername>
<e2eventid>25699</e2eventid>
<e2eventname>The Big Bang Theory</e2eventname>
<e2eventtitle>The Big Bang Theory</e2eventtitle>
<e2eventdescription>Über Nacht im Fort, Sitcom, USA 2014</e2eventdescription>
<e2eventstart>1446491660</e2eventstart>
<e2eventduration>1757</e2eventduration>
<e2eventremaining>4601</e2eventremaining>
<e2eventcurrenttime>1446488816</e2eventcurrenttime>
<e2eventdescriptionextended>Penny wird von Will Wheaton für seinen Podcast interviewt. Während der Show ruft der Regisseur Kevin Smith an und möchte sie für seinen neuen Film casten. Leonard ist von der Idee wenig begeistert ... Howard steht kurz davor, das Haus seiner Mutter zu erben, es fehlt nur noch eine Formalität. Dann taucht plötzlich sein bislang unbekannter Halbbruder Josh auf ...
Gast: Wil Wheaton
Regie: Mark Cendrowski
Drehbuch: Steven Molaro
Kamera: Steven V. Silver
Schnitt: Peter Chakos
Darsteller:
Johnny Galecki (Leonard Hofstadter)
Jim Parsons (Sheldon Cooper)
Simon Helberg (Howard Wolowitz)
Kunal Nayyar (Rajesh Koothrappali)
Kaley Cuoco (Penny)
Mayim Bialik (Amy Farrah Fowler)
Melissa Rauch (Bernadette Rostenkowski)
Matt Bennett (Josh Wolowitz)</e2eventdescriptionextended>
</e2event>
</e2eventlist>
</e2currentserviceinformation>
2015.11.02 19:26:58 5: Triggering VUUno (8 changes)
2015.11.02 19:26:58 5: Notify loop for VUUno eventremaining: 2844
2015.11.02 19:27:02 4: Connection closed for FHEMWEB:192.168.1.123:50014: EOF
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 POST /fhem&detail=rr_Robert_wakeuptimer1&dev.attrrr_Robert_wakeuptimer1=rr_Robert_wakeuptimer1&cmd.attrrr_Robert_wakeuptimer1=attr&arg.attrrr_Robert_wakeuptimer1=wakeupResetSwitcher&val.attrrr_Robert_wakeuptimer1=ResetOff; BUFLEN:0
2015.11.02 19:27:02 5: Cmd: >attr rr_Robert_wakeuptimer1 wakeupResetSwitcher ResetOff<
2015.11.02 19:27:02 5: Triggering global (1 changes)
2015.11.02 19:27:02 5: Notify loop for global ATTR rr_Robert_wakeuptimer1 wakeupResetSwitcher ResetOff
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem?detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:27:02 4: name: /fhem?detail=rr_Robert_wakeuptimer1 / RL:3344 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:02 4: Connection accepted from FHEMWEB:192.168.1.123:50024
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50024 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50024 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50024 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50024 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:27:02 5: Cmd: >{ReadingsVal("rr_Robert_wakeuptimer1","end","")}<
2015.11.02 19:27:02 4: name: /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:27:02 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","room","")}<
2015.11.02 19:27:02 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1 / RL:33 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem?XHR=1&inform=type=status;filter=rr_Robert_wakeuptimer1;since=1446488821;fmt=JSON×tamp=1446488822479; BUFLEN:0
2015.11.02 19:27:04 4: FHEMWEB:192.168.1.123:50020 POST /fhem?cmd=save&XHR=1; BUFLEN:0
2015.11.02 19:27:04 5: Cmd: >save<
2015.11.02 19:27:04 5: Triggering global (1 changes)
2015.11.02 19:27:04 5: Notify loop for global SAVE
2015.11.02 19:27:04 4: name: /fhem?cmd=save&XHR=1 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:27:07 5: HMLAN_Send: hmusb I:K
2015.11.02 19:27:07 5: HMLAN/RAW: /HHM-LAN-IF,03C4,KEQ1111221,2633D6,ABC123,0179295D,0003
2015.11.02 19:27:07 5: HMLAN_Parse: hmusb V:03C4 sNo:KEQ1111221 d:2633D6 O:ABC123 t:0179295D IDcnt:0003 L:0 %
2015.11.02 19:27:07 5: Triggering hmusb (1 changes)
2015.11.02 19:27:07 5: Notify loop for hmusb loadLvl: low
2015.11.02 19:27:12 4: FHEMWEB:192.168.1.123:50020 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22verbose%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:27:12 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","verbose","")}<
2015.11.02 19:27:12 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22verbose%22,%22%22)}&XHR=1 / RL:22 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:27:16 4: Connection closed for FHEMWEB:192.168.1.123:50019: EOF
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 POST /fhem&detail=rr_Robert_wakeuptimer1&dev.attrrr_Robert_wakeuptimer1=rr_Robert_wakeuptimer1&cmd.attrrr_Robert_wakeuptimer1=attr&arg.attrrr_Robert_wakeuptimer1=verbose&val.attrrr_Robert_wakeuptimer1=3; BUFLEN:0
2015.11.02 19:27:16 5: Cmd: >attr rr_Robert_wakeuptimer1 verbose 3<
2015.11.02 19:27:16 5: Triggering global (1 changes)
2015.11.02 19:27:16 5: Notify loop for global ATTR rr_Robert_wakeuptimer1 verbose 3
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem?detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:27:16 4: name: /fhem?detail=rr_Robert_wakeuptimer1 / RL:3345 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: Connection accepted from FHEMWEB:192.168.1.123:50025
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50024 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50024 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50025 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50025 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50024 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50024 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50025 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50025 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:19
Die Funktion wird beim Anlegen des Attributs tatsächlich nicht aufgerufen.
Dafür gibt es wohl nur den Grund, dass bei dir das Dummy-Modul nicht "gehighjackt" werden konnte, da schon ein anderes Modul für das DUMMY-Modul eine Funktion für das Überwachen von Attributen registriert hat.
In diesem Fall kann der ResetSwitcher nicht automatisch angelegt werden, eine entsprechende Meldung siehst du auch beim Neustart, wenn für ein ROOMMATE Device verbose=5 gesetzt ist:
"concurrent AttrFn already defined for dummy module. Some attribute based functions like auto-creations will not be available."
Heißt dann aber, dass ein manuelles anlegen des Dummys genügt und es dann auch entsprechend ausgewertet werden kann.
Ich habe es jetzt mal manuell angelegt und dann das entsprechende Attribut im Timer gesetzt. Nun hat es auch einen Link auf den ResetSwitcher. Habe dann mal die Weckzeit von Standard 0600 auf 0630 gestellt, den ResetSwitcher auf Off gestellt und das Weckprogramm durchlaufen lassen.
Hier der Log.
2015.11.02 19:39:36 4: dummy set rr_Robert_wakeuptimer1 nextRun 06:30
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: New wake-up time: 06:30
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: wakeupGetBegin source: nextRun
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: wakeupGetBegin result: 06:30 = 22500 s - 15 m = 06:15:00
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: wakeupGetBegin source: nextRun
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: wakeupGetBegin result: 06:30 = 22500 s - 15 m = 06:15:00
2015.11.02 19:40:24 4: dummy set rr_Robert_wakeuptimer1 start
2015.11.02 19:40:24 4: RESIDENTStk rr_Robert_wakeuptimer1: lastRun != nextRun = 19:55
2015.11.02 19:40:24 4: RESIDENTStk rr_Robert_wakeuptimer1: trigger Macro_rr_Robert_wakeuptimer1 (running=1)
2015.11.02 19:40:24 3: Macro_rr_Robert_wakeuptimer1: Wake-up program started for rr_Robert with target time 19:55. Current state: home
2015.11.02 19:40:24 3: CUL_HM set sz_Dimmer_channel_01 pct 50 0 900
2015.11.02 19:40:24 4: RESIDENTStk rr_Robert_wakeuptimer1: created at-device at_rr_Robert_wakeuptimer1_stop to stop wake-up program in 15 minutes
2015.11.02 19:40:31 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:42:32 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:44:33 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:46:34 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:48:36 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:50:37 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:52:39 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:54:46 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:55:25 4: dummy set rr_Robert_wakeuptimer1 stop triggerpost
2015.11.02 19:55:25 4: RESIDENTStk rr_Robert_wakeuptimer1: stopping wake-up program
2015.11.02 19:55:25 4: dummy set rr_Robert_wakeuptimer1 nextRun 06:30
2015.11.02 19:55:25 4: RESIDENTStk rr_Robert_wakeuptimer1: trigger Macro_rr_Robert_wakeuptimer1 stop 19:55 15 1 rr_Robert home
2015.11.02 19:55:25 3: Macro_rr_Robert_wakeuptimer1: Wake-up program ended for rr_Robert with target time 19:55. Current state: home
heißt nextRun 06:30 dann, dass es jetzt funktioniert?
Was hat es denn mit Dummy-Modul highjacken auf sich? Das sagt mir leider gar nichts.
Zitat
Some attribute based functions like auto-creations will not be available.
Kann man da etwas gegen tun? Das könnte in anderen Fällen doch bestimmt auch zu Problemen führen, oder?
Zitat von: r_knipp am 02 November 2015, 20:13:37
heißt nextRun 06:30 dann, dass es jetzt funktioniert?
Sieht danach aus.
Testen kannst du das am besten so:
1. Standard-Weckzeit auf 06:30 definieren.
2. Weckzeit manuell auf etwas anderes stellen.
3. Den ResetSwitcher aus und wieder einschalten.
Danach sollte der Wecker von der manuell verstellten Weckzeit auf die vordefinierte Standard-Weckzeit wechseln.
Mit Hilfe des ResetSwitchers kannst du nun komfortabel einstellen, ob tatsächlich ein Reset der Weckzeit gemacht werden soll oder nicht.
Zitat von: r_knipp am 02 November 2015, 20:13:37
Was hat es denn mit Dummy-Modul highjacken auf sich? Das sagt mir leider gar nichts.
Das bedeutet nur, dass ich dort in Code eingreife, der eigentlich zum DUMMY Modul gehören müsste, damit ich das DUMMY-Modul soweit "fernsteuern" kann, dass ich auf das Event beim Anlegen des Attributes reagieren kann.
Das mache ich aber "gentle": Wenn irgendwer oder irgendwas bereits das gleiche tut, gebe ich dem den Vortritt. Um zu wissen wer oder was das ist, habe ich das Logging erweitert. Bei einem Neustart mit verbose=4 kann man in der Meldung jetzt auch sehen welche Funktion sich hier bereits vorher registriert hat.
Zitat von: r_knipp am 02 November 2015, 20:13:37Kann man da etwas gegen tun? Das könnte in anderen Fällen doch bestimmt auch zu Problemen führen, oder?
Nein man kann und soll nichts dagegen tun. Das automatische Anlegen des DUMMY Devices in der richtigen Konfiguration ist lediglich ein "Service", um einem etwas Arbeit abzunehmen, spielt aber ansonsten keine große Rolle.
Dann ist ja so alles in Ordnung :)
Hab vielen Dank für Deine Hilfe und Erklärungen.
Nachdem ich jetzt in den letzten Wochen einige Erweiterungen auch bei der RESIDENTS Modulfamilie vorgenommen habe und das (noch als Beta zu betrachtende) msg-Kommando (http://forum.fhem.de/index.php/topic,39983.0.html) nun per Update ausgerollt wurde, kann ich hier einmal ein kurzes Anwendungsbeispiel geben.
Wenn ein Bewohner das Haus betritt oder verlässt, soll er/sie per Push eine Nachricht darüber bekommen (bei mir kommt diese entsprechend unauffällig auf meine Apple Watch mit Taptic Engine ;) ), dass er/sie erfolgreich am Haus an- bzw abgemeldet wurde. Außerdem soll dabei genannt werden, wer schon bzw. noch zu Hause ist. Das kann man nun mit einem sehr simplen DOIF sehr übersichtlich lösen, anstatt hier Unmengen an eigenem Code zu fabrizieren:
define di_Residents_presence_push DOIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "home" and
[?rgr_Residents:residentsGotosleep:sec] > 1 and
[?rgr_Residents:residentsAsleep:sec] > 1 and
[?rgr_Residents:residentsAwoken:sec] > 1
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:residentsTotalPresent] Bewohner zuhause: [rgr_Residents:residentsTotalPresentNames])
)
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present"
)
(
(msg push @[rgr_Residents:lastActivityByDev] -1 |Anwesenheit| [rgr_Residents:lastActivityBy] erfolgreich abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "absent" and
[?rgr_Residents:presence:sec] < 1
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] erfolgreich abgemeldet. Alle Bewohner sind nun abwesend. Sicherheitsprotokolle werden etabliert.)
)
Gesetzte Attribute:
attr di_Residents_presence_push do always
Zusätzlich muss natürlich bei jedem ROOMMATE (oder GUEST) Device, welche ein kommen und gehen auslösen können, ein msgContactPush Attribut vorhanden sein, damit das msg-Kommando weiß wie es den ROOMMATE Bewohner erreichen kann. Bei mir ist das einfach ein Verweis auf ein Pushover Device, da am schicksten auf der Apple Watch darstellbar. Es kann aber auch ein Telegram Kontakt sein (dann muss das Attribut neben dem Devicenamen für den TelegramBot auch noch mit Doppelpunkt getrennt den Empfängernamen im Telegram Format enthalten; also z.B. "Telegram:@@USERNAME").
Für das automatische kommen und gehen wird bei mir das GEOFANCY Modul (http://www.fhemwiki.de/wiki/Anwesenheitserkennung#Das_GEOFANCY_Modul) zusammen mit der iOS-App Geofency (http://www.geofency.com/) verwendet.
Moin,
ich wollte heute ein DOIF programmieren, welches mir eine Pushnachricht sendet, wenn meine Frau und ich das Haus verlassen und noch Fenster offen sind. Dabei sollte es egal sein, wenn bei unserem Verlassen noch Gäste da sind.
Irgendwie hab ich mich zu blöd angestellt, mit den gegebenen Readings eines zu identifizieren, welches die An-/Abwesenheit der Roommates von den Guests unterscheidet. Die residents - Readings werden immer gemeinsam angegeben (Roommates + Guests). Möglicherweise habe ich da was übersehen, bis dahin habe ich per userReadings folgende Ergänzungen vorgenommen und die Roomates als Owner betitelt.
residentsTotalOwners { ReadingsVal("Mittelstr","residentsTotal",0) - ReadingsVal("Mittelstr","residentsTotalGuests",0); },
residentsTotalOwnersPresent { ReadingsVal("Mittelstr","residentsTotalOwners",0) - ReadingsVal("Mittelstr","residentsTotalAbsent",0) + ReadingsVal("Mittelstr","residentsTotalGuestsAbsent",0); }
Die übrigen Reading wie Geräte oder Anwesenheit hab ich nicht gebraucht und deswegen nicht angelegt.
Vielleicht kann sowas (anders benannt?) ins Modul übernommen werden.
Gruß
Michael
Ich habe gerade folgendes DOIF bei mir im Test, welches auch zwischen Bewohnern und Gästen unterscheidet:
## ROOMMATE arrives at home
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
$devType eq "ROOMMATE" and
($lastState eq "absent" or $lastState eq "gone")
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:residentsTotalPresent] Bewohner zuhause: [rgr_Residents:residentsTotalPresentNames])
)
## ROOMMATE leaves home but residents are still present
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present" and
$devType eq "ROOMMATE"
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)
## ROOMMATE is absent for longer period but others are still nearby
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "gone" and
[?rgr_Residents:state] ne "gone"
)
(
(msg push @[rgr_Residents:lastActivityByDev]! -2 |Anwesenheit| Längere Abwesenheit für [rgr_Residents:lastActivityBy] wurde vermerkt.)
)
## all residents are absent for longer period
DOELSEIF
(
[rgr_Residents:?state] and
[?rgr_Residents:state] eq "gone"
)
(
(msg push @rgr_Residents! -1 |Anwesenheit| Längere Abwesenheit aller Bewohner registriert. Erweitere Sicherheitsprotokolle wurden etabliert.)
)
## ROOMMATE leaves home and all residents are absent now
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:state] eq "absent" and
$devType eq "ROOMMATE"
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. Alle Bewohner sind abwesend, Sicherheitsprotokolle wurden etabliert.)
)
## GUEST control enabled
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
(([?rgr_Residents:lastActivity] ne "absent" and [?rgr_Residents:residentsHome] > 1) or ([?rgr_Residents:lastActivity] eq "absent" and [?rgr_Residents:residentsHome] == 0)) and
$devType eq "GUEST" and
$lastState eq "none"
)
(
(msg push @rgr_Residents -1 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde aktiviert)
)
## GUEST control enabled while no resident present (EXCEPTION!)
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] ne "absent" and
[?rgr_Residents:residentsHome] == 1 and
$devType eq "GUEST" and
$lastState eq "none"
)
(
(msg push @rgr_Residents! 2 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde aktiviert, obwohl kein Bewohner zuhause ist!)
)
## GUEST control was disabled
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "none" and
[?rgr_Residents:state] ne "gone"
)
(
(msg push @rgr_Residents -1 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde deaktiviert)
)
## GUEST arrives at home while residents are present
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:residentsHome] > 1 and
$devType eq "GUEST" and
$lastState eq "absent"
)
(
(msg push @rgr_Residents -2 |Anwesenheit| [rgr_Residents:lastActivityBy] ist jetzt zuhause. Anwesende Bewohner: [rgr_Residents:residentsTotalPresentNames])
)
## GUEST arrives at home while he is the only one (EXCEPTION!)
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:residentsHome] == 1 and
$devType eq "GUEST" and
$lastState eq "absent"
)
(
(msg push @rgr_Residents! 2 |Anwesenheit| [rgr_Residents:lastActivityBy] ist jetzt alleine zuhause!)
)
## GUEST leaves home while others are still at home
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present" and
$devType eq "GUEST"
)
(
(msg push @rgr_Residents -2 |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)
## GUEST leaves home after all residents
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "absent" and
$devType eq "GUEST"
)
(
(msg push @rgr_Residents! |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. Alle Bewohner sind jetzt abwesend, Sicherheitsprotokolle werden etabliert.)
)
Zitat von: Loredo am 14 November 2015, 15:32:17
Ich habe gerade folgendes DOIF bei mir im Test, welches auch zwischen Bewohnern und Gästen unterscheidet:
Ja, das geht auch. Ich wollte es in der Nutzung in weiteren DOIF aber lieber übersichtlicher haben und deswegen das Reading dahin packen, wohin es gehört (und universell nutzbar ist). Im Ergebnis verwende ich es dann zb so:
## wenn die Hoftuer geoeffnet wird und außer Gästen keiner zu Hause ist
([AU_FK_Hoftuer:?contact] and [?AU_FK_Hoftuer] eq "open" and [?Mittelstr:residentsTotalOwnersPresent] == 0)
## Nachricht per pushmsg
(set pushmsg msg 'ACHTUNG!' 'Die Hoftür wurde geöffnet!' '' 2 'siren' 30 3600)Ich finde dann den Code des DOIF auch wesentlich lesbarer. Kann aber auch Geschmackssache sein.
Aber noch der Nachtrag genereller Natur:
residentsTotalGuestsPresent gibt an wieviele Gäste gerade anwesend sind.
residentsTotalPresent gibt an wieviele Bewohner insgesamt anwesend sind.
Gäste werden auch gastlich behandelt und entsprechend während ihrer Anwesenheit als vollwertige Bewohner gezählt.
;)
Es ist also richtig, dass man über ([rgr_Residents:residentsTotalPresent] eq [rgr_Residents: residentsTotalGuestsPresent]) erkennen kann, wenn nur noch Gäste zu Hause sind.
In meinem DOIF habe ich das allerdings etwas komplexer gelöst. Warum kann man denke ich bei genauerem hinsehen auch verstehen.
EDIT: Ich ergänze bei Gelegenheit mal residentsTotalOwners*.
Habe gerade eine aktualisierte Version mit residentsTotalOwners* Readings eingecheckt.
Danke für's Einchecken, dann fliegen meine userReadings morgen raus. Es führen sicherlich viele Wege nach Rom und bei der ganzen Programmiererei übersieht man auch einige Möglichkeiten.
Danke nochmal!
Hallo
ich bin seit ein paar Wochen begeisterter FHEM-Bastler. Meine ROOMMATE's schalte ich mit 2 IT-Fernbedienungen am Bett (awoken:asleep) und Wohnungstür (home:absent). Zusätzlich habe ich noch einige notifies auf pingbare Geräte zur Plausibilisierung, falls man einen Status nicht schaltet. Funktioniert soweit ganz gut. :)
Was mir auffällt: Bei den automatisch erzeugten Makros fehlt irgendwie Macro_RESIDENTS_absent und Macro_RESIDENTS_home? Ist das Absicht, oder habe ich ausversehen etwas gelöscht?
Grüße Ralf
Ich habe gerade eine Änderung beim Reading lastActivity des RESIDENTS Moduls eingecheckt.
Das betrifft diejenigen, die in einem ROOMMATE oder GUEST Device eventMap verwenden. Bisher wurde dann in lastActivity der übersetzte Wert angezeigt statt dem originalen state des Devices. Nun wird in RESIDENTS ebenfalls der originale Wert angezeigt und nicht der durch eventMap übersetzte. Wer also darauf triggert, muss diese ggf. anpassen oder eventMap auch für das RESIDENTS Device definieren.
Zitat von: ralfix am 19 November 2015, 22:39:38
Was mir auffällt: Bei den automatisch erzeugten Makros fehlt irgendwie Macro_RESIDENTS_absent und Macro_RESIDENTS_home? Ist das Absicht, oder habe ich ausversehen etwas gelöscht?
Nein. Du sprichst vermutlich vom Wakeuptimer, welcher jedoch nur zu einem ROOMMATE oder GUEST Device gehört.
Es macht daher keinen Sinn für ein RESIDENTS Device etwas anzulegen, wenn dies für den Wakeuptimer gar nicht benötigt wird. Wenn du ein Notify auf ein RESIDENTS Device brauchst, musst du ihn selbst anlegen.
Zitat von: Loredo am 21 November 2015, 14:36:21
Nein. Du sprichst vermutlich vom Wakeuptimer, welcher jedoch nur zu einem ROOMMATE oder GUEST Device gehört.
Es macht daher keinen Sinn für ein RESIDENTS Device etwas anzulegen, wenn dies für den Wakeuptimer gar nicht benötigt wird. Wenn du ein Notify auf ein RESIDENTS Device brauchst, musst du ihn selbst anlegen.
Die Macros Macro_rr_Ralf_asleep , -_awoken und -_gotosleep wurden mir automatisch erzeugt, aber eben nicht Macro_rr_Ralf_absent und Macro_rr_Ralf_home.
Das finde ich etwas unlogisch.
Ist aber kein Problem, die notwendigen Aktionen habe alle per NOTIFY und DOIF eingestellt. :)
So, nachdem mich die Arbeit nun wieder einige Minuten ans System lässt, ist mit bei den Readings
residentsTotalOwners*
aufgefallen, dass ich da beim Namensvorschlag wohl blockierte Denke hatte. Ich hatte nach einer Bezeichnung analog zu "Guests" gesucht und völlig daneben gegriffen. Eigentlich wäre es doch korrekter, die Readings als
residentsTotalRoommates*
zu bezeichnen. :( Wäre es blöd, das jetzt noch zu ändern?
Dann noch eine Frage... ich komm vor lauter Readings nicht drauf. Wenn ich etwas genau einmal machen möchte, wenn der erste Bewohner nach Hause kommt, wie setze ich das in einem DOIF um? Das Haus auf "present" zu prüfen dürfte hier nicht gehen, oder... jede Statusänderung eines Bewohners würde doch einen Trigger auslösen und damit die Prüfung auf "present" wieder auslösen. Ich steht vor dem Wald und seh grad nix.
Danke
Michael
Hallo Micha,
Bitte schau Die doch mal genau an was bei den DeviceInstanzen passiert. Versuche zu verstehen wie was genau abgebildet wird. Dann erkennst Du das die Residents auf den Zustand des ersten oder letzten Roommates an nimmt. Die Residents kann nur einmal den Status Home annehmen, nämlich vom ersten Roommate. Und dem zu Folge kannst Du auch ein DOIF auf home der Residents machen wenn der erste Bewohner der nach Hause kommt etwas auslösen soll.
Grüße
Leon
Zitat von: MichaelO am 13 Dezember 2015, 19:31:12
So, nachdem mich die Arbeit nun wieder einige Minuten ans System lässt, ist mit bei den Readings
residentsTotalOwners*
aufgefallen, dass ich da beim Namensvorschlag wohl blockierte Denke hatte.
Das ist schon in Ordnung so, sonst hätte ich das selbst entsprechend anders benannt.
Es geht ja vornehmlich um Bewohner, daher wird auch sonst in keinem Reading explizit von "roommates" gesprochen. Nur dort, wo es sich um temporäre Bewohner handelt, wird ein Reading dann mit "guests" im Namen bezeichnet.
Zitat von: MichaelO am 13 Dezember 2015, 19:31:12
Dann noch eine Frage... ich komm vor lauter Readings nicht drauf. Wenn ich etwas genau einmal machen möchte, wenn der erste Bewohner nach Hause kommt, wie setze ich das in einem DOIF um? Das Haus auf "present" zu prüfen dürfte hier nicht gehen, oder... jede Statusänderung eines Bewohners würde doch einen Trigger auslösen und damit die Prüfung auf "present" wieder auslösen. Ich steht vor dem Wald und seh grad nix.[size=78%] [/size]
Wie CoolTux richtig schrieb, die Readings triggern nur wenn sich etwas verändert. Sprich nur wenn der erste Bewohner nach Hause kommt ändert sich das Reading "presence" von "absent" auf "present", danach bleibt es natürlich so, weil es den Gesamtstatus über alle Mitglieder dieser RESIDENTS Gruppe repräsentiert. Du kannst also in einem DOIF einfach auf [rgr_Residents:?presence] triggern.
Zitat von: CoolTux am 13 Dezember 2015, 20:08:50
Die Residents kann nur einmal den Status Home annehmen, nämlich vom ersten Roommate. Und dem zu Folge kannst Du auch ein DOIF auf home der Residents machen wenn der erste Bewohner der nach Hause kommt etwas auslösen soll.
Das funktioniert nur solange man keinen der anderen Status wie "asleep" verwendet. Ansonsten wechselt der Gesamtstatus natürlich irgendwann auch auf "asleep" wenn alle Bewohner schlafen und nach dem aufstehen dann wieder auf "awoken" oder sofort auf "home", sobald der erste aufgestanden ist (je nachdem wie man das in seiner Automation verwendet). Dann würde auf "home" erneut getriggert werden, obwohl die Bewohner gar nicht weg waren. Für diesen Fall ist das Reading "presence" deshalb besser geeignet.
Zitat von: MichaelO am 13 Dezember 2015, 19:31:12
Ich hatte nach einer Bezeichnung analog zu "Guests" gesucht und völlig daneben gegriffen. Eigentlich wäre es doch korrekter, die Readings als
residentsTotalRoommates*
zu bezeichnen. :( Wäre es blöd, das jetzt noch zu ändern?[size=78%] [/size]
Hm, jetzt verstehe ich deine Denkweise. Ich kam auch naheliegenderweise zunächst auf "Owners", aber "Guests" ähnelt der Bezeichnung des GUEST-Moduls natürlich und demnach wäre es in der Tat sinnvoller die Readings mit "Roommates" zu bezeichnen, damit man den Zusammenhang direkt herstellen kann.
Ich werde die Readings umbenennen. Ich denke die sind noch nicht allzu verbreitet im Einsatz und eine Änderung des Namens ist für die bisherigen Verwender kein großes Problem.
Ab morgen dann per Update.
läuft soweit.
Sry für die vllt. doofe Frage, aber gibt's irgendeinen Befehl zum "aufräumen" der Readings? Ähnlich wie bei der msg-Funktion?
Gruß Michael
Zitat von: l2r am 15 Dezember 2015, 13:33:22
Sry für die vllt. doofe Frage, aber gibt's irgendeinen Befehl zum "aufräumen" der Readings? Ähnlich wie bei der msg-Funktion?
Da das kein häufiger Task ist, lohnt dafür kein eigener Setter.
Man kann einfach das Kommando deletereading entsprechend benutzen:
deletereading .* residentsTotalOwners.*
alles klar,
danke!
Hallo, wir haben mit dem Wecker ein "Problem". Die Grundfunktion ist perfekt, da darf man wiederholt nochmals DANKE sagen.
:) Wenn ich nun ins Bett gehe, drücke ich auf einen Knopf, ich nehme den Status "asleep" ein - alles bestens.
:) Drücke ich den Knopf lange, wird der Wecker ausgeschaltet, ich kann lange schlafen, am nächsten Tag ist der Wecker automatisch wieder eingeschaltet - alles bestens.
:) Will ich 2 Stunden später aufstehen, stelle ich die Zeit, alles klappt, auch am Folgetag wieder normale Weckzeit - alles bestens.
:( Will ich früher aufstehen, stelle ich die Zeit, ich werde pünktlich geweckt, sobald die Kaffeemaschine läuft habe ich den Status "home" - soweit alles ok. Aber dann klingelt der Wecker zur Standardzeit wieder, und wei ich nicht "asleep" bin, sondern "home" kommt natürlich einiges bei mir durcheinander. Gibt es irgendeine Idee, wo ich meinen Fehler suchen muss?
Hi. Wie kann ich mehrere zu einer Gruppe Familie zusammen fassen oder die Kinder zur Gruppe Kinder bündeln damit ich darauf abfragen machen kann.
Gesendet von meinem Huawei Honor 7
Zitat von: ujaudio am 19 Dezember 2015, 10:18:24
Hallo, wir haben mit dem Wecker ein "Problem". Die Grundfunktion ist perfekt, da darf man wiederholt nochmals DANKE sagen.
:) Wenn ich nun ins Bett gehe, drücke ich auf einen Knopf, ich nehme den Status "asleep" ein - alles bestens.
:) Drücke ich den Knopf lange, wird der Wecker ausgeschaltet, ich kann lange schlafen, am nächsten Tag ist der Wecker automatisch wieder eingeschaltet - alles bestens.
:) Will ich 2 Stunden später aufstehen, stelle ich die Zeit, alles klappt, auch am Folgetag wieder normale Weckzeit - alles bestens.
:( Will ich früher aufstehen, stelle ich die Zeit, ich werde pünktlich geweckt, sobald die Kaffeemaschine läuft habe ich den Status "home" - soweit alles ok. Aber dann klingelt der Wecker zur Standardzeit wieder, und wei ich nicht "asleep" bin, sondern "home" kommt natürlich einiges bei mir durcheinander. Gibt es irgendeine Idee, wo ich meinen Fehler suchen muss?
Da kannst Du nichts machen. Stell Dir doch einfach vor was genau passiert.
Du hast eine default Zeit auf die jeden Tag gestellt wird, und zwar immer nach dem Stoppen des Weckers beim letzten Weckprozess. So und nun überlege mal was wohl passiert wenn Deine default Zeit 5 Uhr ist, Du Dich aber mal um 4 Uhr wecken lässt.
Das ist nicht gegen Dich so der an alle User gerichtet. Wenn Ihr ein Modul verwendet, versucht bitte zu verstehen wo die Zusammenhänge sind und wie das Modul funktioniert. Logik.
Grüße
Leon
Zitat von: CoolTux am 19 Dezember 2015, 11:16:06
Da kannst Du nichts machen. Stell Dir doch einfach vor was genau passiert.
Du hast eine default Zeit auf die jeden Tag gestellt wird, und zwar immer nach dem Stoppen des Weckers beim letzten Weckprozess. So und nun überlege mal was wohl passiert wenn Deine default Zeit 5 Uhr ist, Du Dich aber mal um 4 Uhr wecken lässt.
Das ist nicht gegen Dich so der an alle User gerichtet. Wenn Ihr ein Modul verwendet, versucht bitte zu verstehen wo die Zusammenhänge sind und wie das Modul funktioniert. Logik.
Grüße
Leon
Ok, soweit klar, aber wie funktioniert das dann bei "Wecker aus"? Wann wird da wieder die Defaultzeit eingestellt?
Weil eine Zeit immer eingestellt wird/ist. Und wenn Du eine default Zeit hast dann wird die auch gesetzt. ABER, wenn Dein Wecker auf OFF steht, werden die entsprechenden Skripte nicht ausgeführt.
Grüße
Zitat von: masterpete23 am 19 Dezember 2015, 10:49:24
Hi. Wie kann ich mehrere zu einer Gruppe Familie zusammen fassen oder die Kinder zur Gruppe Kinder bündeln damit ich darauf abfragen machen kann.
Dazu gibt es ein Beispiel in der Commandref von ROOMMATE (http://fhem.de/commandref.html#ROOMMATE) und GUEST (http://fhem.de/commandref.html#GUEST):
# Complex family structure
define rr_Manfred ROOMMATE rgr_Residents,rgr_Parents # Parent
define rr_Lisa ROOMMATE rgr_Residents,rgr_Parents # Parent
define rr_Rick ROOMMATE rgr_Residents,rgr_Children # Child1
define rr_Alex ROOMMATE rgr_Residents,rgr_Children # Child2
- Der Vater "Manfred" und die Mutter "Lisa" sind dabei beide Mitglied des RESIDENTS Device "rgr_Parents"
- Die Kinder "Rick" und "Alex" sind beide Mitglied des RESIDENTS Device "rgr_Children"
- Alle Bewohner sind Mitglied des RESIDENTS Device "rgr_Residents"
Wichtig ist dabei, dass alle 3 RESIDENTS Devices vor den ROOMMATE Devices angelegt sind.
Zitat von: ujaudio am 19 Dezember 2015, 10:18:24
:( Will ich früher aufstehen, stelle ich die Zeit, ich werde pünktlich geweckt, sobald die Kaffeemaschine läuft habe ich den Status "home" - soweit alles ok. Aber dann klingelt der Wecker zur Standardzeit wieder, und wei ich nicht "asleep" bin, sondern "home" kommt natürlich einiges bei mir durcheinander. Gibt es irgendeine Idee, wo ich meinen Fehler suchen muss?
Ja das ist ein bekannter Fehler, für den ich noch keine Zeit hatte ihn genauer zu untersuchen.
Es gibt eigentlich eine Art Karenzzeit, in der der Wecker kein zweites Mal auslösen sollte (siehe Attribut wakeupWaitPeriod mit Default Wert = 6h). Sprich, wenn z.B. die Default-Time auf 7:00 steht und ich den Wecker ausnahmsweise früher auf 5:00 gestellt habe, sollte er um 7:00 nicht nochmals ausgelöst werden, obwohl nach dem Wecken um 5:00 die Uhrzeit wieder automatisch auf 7:00 gestellt worden ist, damit am nächsten Tag wieder zur Standardzeit geweckt wird.
Leider sind Tests und Debugging-Sessions da immer sehr aufwändig, weil man eben dauernd einen Timer setzen und 1-2 Minuten warten muss, bis dieser dann ausgeführt wird. Daher habe ich das noch nicht gemacht, auch weil es bei mir nicht so häufig vorkommt, dass ich früher als normal aufstehe.
Spontan könnte es damit zu tun haben (Auszug Commandref): "Does not apply in case wake-up time was changed during this period".
Das muss ich aber wie gesagt erstmal ausprobieren.
-----
Es bleibt auch noch der Anwendungsfall, dass ich von alleine früher aufwache und mich auf "awoken" etc. setze. Dabei sollte der Wecker dann eigentlich auch nicht mehr auslösen. Das ist auch noch nicht berücksichtigt, aber eben auch ein seltener, jedoch realistischer Anwendungsfall.
Zitat von: CoolTux am 19 Dezember 2015, 11:16:06
Das ist nicht gegen Dich so der an alle User gerichtet. Wenn Ihr ein Modul verwendet, versucht bitte zu verstehen wo die Zusammenhänge sind und wie das Modul funktioniert. Logik.
Grundsätzlich richtige Schlussfolgerung, das Modul versucht dem aber wie oben beschrieben durchaus entgegenzuwirken (bzw. soll es) ;)
Zitat von: ujaudio am 19 Dezember 2015, 11:37:21
Ok, soweit klar, aber wie funktioniert das dann bei "Wecker aus"? Wann wird da wieder die Defaultzeit eingestellt?
Das zum Wecker dazugehörige at-Device bleibt immer aktiv und löst trotzdem aus. Wenn man also den Wecker einmal auf OFF stellt, dann wird die Default-Time am nächsten Tag zur gewohnten Weckzeit wieder eingeschaltet, so dass am übernächsten Tag wieder geweckt wird (u.U. je nach Einstellung von wakeupResetdays).
Zitat von: CoolTux am 19 Dezember 2015, 12:13:49
Weil eine Zeit immer eingestellt wird/ist. Und wenn Du eine default Zeit hast dann wird die auch gesetzt. ABER, wenn Dein Wecker auf OFF steht, werden die entsprechenden Skripte nicht ausgeführt.
Richtig.
Zitat von: ujaudio am 19 Dezember 2015, 10:18:24
:( Will ich früher aufstehen, stelle ich die Zeit, ich werde pünktlich geweckt, sobald die Kaffeemaschine läuft habe ich den Status "home" - soweit alles ok. Aber dann klingelt der Wecker zur Standardzeit wieder, und wei ich nicht "asleep" bin, sondern "home" kommt natürlich einiges bei mir durcheinander. Gibt es irgendeine Idee, wo ich meinen Fehler suchen muss?
Eine Überlegung, mit der ich immer wieder ringe, ist auch:
Momentan wird ein Wecker IMMER ausgelöst, unabhängig vom Status des Bewohners (solange er nur zu Hause ist). Das soll vermeiden, dass man ggf. einmal vergisst über die Hausautomation schlafen zu gehen (sprich sich nicht in den Status "asleep" schaltet) und dann eben nicht geweckt würde. Wie man hier merkt kann es jedoch auch Vorteile haben, dass ein Wecker wirklich nur auslöst, wenn man tatsächlich "asleep" ist. Ich kenne es aber von mir selbst, dass ich z.B. auf dem Sofa einschlafe und dann nur noch im Halbschlaf ins Schlafzimmer wanke ohne mich in den Status "asleep" zu schalten und einfach nur jeden Lichtschalter betätige, der mir begegnet. Das kann man sicher auch mit einer feiner ausgeklügelten Automation auffangen, dennoch bleibt immer ein "Restrisiko". Da ist es mir bisher immer wichtiger gewesen am nächsten Morgen zuverlässig geweckt zu werden und eben mit der Komplexität umzugehen, dass der Wecker implizit schauen muss nicht doppelt auszulösen.
Wenn da jemand eine bessere Logik für erfinden kann, bitte gerne ;)
Hallo Loredo,
ich finde deine Logik ok, habe es soweit verstanden und muss doch jetzt nur noch "meinen Laden aufräumen". Mir ist es auch lieber 2x geweckt zu werden als gar nicht! Wenn das Attribut wakeupWaitPeriod richtig tut, wäre es doch schon prima. Die ganz Vorsichtigen können das Attribut auf 0 setzen, dein Default von 6 Stunden erscheint mir ganz ok.
Wenn man dann noch das genannte Attribut immer beim Übergang auf den Status "home" nutzt, dann hätte man auch den Fall des freiwillig früheren Aufstehens ohne Wecker erschlagen.
Sicherlich gibt es noch weitere Meinungen, ich kann auch mit den jetzigen Zustand leben.
könnt mich bitte einer in die richtige Richtung Schubsen
Möchte die residents zu eltern zusammen fassen.
und dort dann auch den status anzeigt
über presence zieh ich mir das .
BIn ich hier überhaupt korrekt?
Zitat von: masterpete23 am 19 Dezember 2015, 23:23:50
könnt mich bitte einer in die richtige Richtung Schubsen
Möchte die residents zu eltern zusammen fassen.
und dort dann auch den status anzeigt
über presence zieh ich mir das .
BIn ich hier überhaupt korrekt?
Ich verstehe irgendwie gar nicht, was du hier schreibst, deine Worte ergeben für mich keinen Sinn.
Du musst doch quasi nur die Beispiele von oben nachempfinden. Was fehlt dir da?
Du kannst RESIDENTS nicht gruppieren, du kannst ROOMMATE und GUEST in einer oder mehreren RESIDENTS Gruppen zusammenfassen.
Also wie oben beschrieben:
Eltern (Type: RESIDENTS)
|--Vater (Type: ROOMMATE)
|--Mutter (Type: ROOMMATE)
Kinder (Type: RESIDENTS)
|--Kind1 (Type: ROOMMATE)
|--Kind2 (Type: ROOMMATE)
Bewohner (Type: RESIDENTS)
|--Vater (Type: ROOMMATE)
|--Mutter (Type: ROOMMATE)
|--Kind1 (Type: ROOMMATE)
|--Kind2 (Type: ROOMMATE)
Das definiert sich dann so:
define Bewohner RESIDENTS
define Eltern RESIDENTS
define Kinder RESIDENTS
define Vater ROOMMATE Bewohner,Eltern
define Mutter ROOMMATE Bewohner,Eltern
define Kind1 ROOMMATE Bewohner,Kinder
define Kind2 ROOMMATE Bewohner,Kinder
Moin,
ich hätte eine Frage zu den Reading "*Names":
residentsHomeNames
residentsTotalPresentNames
residentsTotalRoommatesPresentNames
Ich habe alle Roomates gruppiert zu "Status Hausbewohner". Nun fiel mir auf, dass alle Readings, wo die Namen der Roomates auftauchen sollten, als "Status Hausbewohner" angezeigt werden.
residentsTotalRoommatesPresentNames
Status Hausbewohner, Status Hausbewohner
2015-12-21 18:58:42
Hab ich da was falsch gemacht, oder kann/sollte das im Modul geändert werden?
Gruß
Michael
Hallo Loredo,
habe gerade auch ein wenig mit dem RESIDENTS Toolkit wakeuptimer gespielt, was mir aber nicht gefällt ist, dass man nur Weckezeiten im 15min Abstand wählen kann.
Deshalb habe ich die "setlist" wie folgt angepasst:
setList state:time reset:noArg trigger:noArg start:noArg stop:noArg end:noArg
und das "webcmd" entsprechend
webCmd state
Könnte diese eine Beeinträchtigung der Funktion zur folge haben?
Gruß,
Stefan
Zitat von: Haecksler am 22 Dezember 2015, 21:43:09
Deshalb habe ich die "setlist" wie folgt angepasst:
setList state:time reset:noArg trigger:noArg start:noArg stop:noArg end:noArg
und das "webcmd" entsprechend
webCmd state
Könnte diese eine Beeinträchtigung der Funktion zur folge haben?
Grundsätzlich ist es auch so gedacht, dass man die Zeiten in setList anpasst, wenn man das möchte (z.B. wenn man während eines Zeitraums 5min Schritte ö.ä. möchte).
Wenn du dabei auf das Widget "time" umstellst, kannst du den Wecker nicht mehr auf OFF setzen (ok, wenn man drauf verzichten möchte).
Es ist allerdings falsch "state" zu setzen, es muss bei nextRun bleiben:
attr rr_Julian_wakeuptimer1 setList nextRun:time reset:noArg start:noArg trigger:noArg stop:noArg
attr rr_Julian_wakeuptimer1 webCmd nextRun
Das Reading state wird indirekt durch den wakeuptimer gestellt. Es sieht nur so aus, als wenn man state direkt stellen könnte.
Zitat von: Loredo am 22 Dezember 2015, 22:16:55
Das Reading state wird indirekt durch den wakeuptimer gestellt. Es sieht nur so aus, als wenn man state direkt stellen könnte.
Heißt das, dass
set rr_Julian_wakeuptimer1 08:37nicht funktioniert?
Oder muss man
set rr_Julian_wakeuptimer1 nextRun 08:37 schreiben?
Zitat von: Haecksler am 22 Dezember 2015, 22:38:07
Heißt das, dass
set rr_Julian_wakeuptimer1 08:37
nicht funktioniert?
Richtig.
Geht
set rr_Julian_wakeuptimer1 nextRun 08:37
?
Zitat von: Loredo am 22 Dezember 2015, 22:16:55
Grundsätzlich ist es auch so gedacht, dass man die Zeiten in setList anpasst, wenn man das möchte (z.B. wenn man während eines Zeitraums 5min Schritte ö.ä. möchte).
Wenn du dabei auf das Widget "time" umstellst, kannst du den Wecker nicht mehr auf OFF setzen (ok, wenn man drauf verzichten möchte).
OFF geht doch wenn ich auf das
devStateIcon OFF:general_aus@red:reset running:general_an@blue:stop .*:general_an@green:nextRun%20OFFklicke...oder stehe ich immer noch auf dem Schlauch?
jemand bei http://forum.fhem.de/index.php/topic,46021.0.html eine Idee?
ROOMMATE und GUEST bieten jetzt direkte Unterstützung bei der Nutzung zusammen mit GEOFANCY:
http://forum.fhem.de/index.php/topic,18485.msg382980.html#msg382980
Ich habe seit kurzem mehrere Warnungen. Eine davon
2016.01.03 05:30:00 1: PERL WARNING: Odd number of elements in anonymous hash at (eval 108531) line 1.
Die fast immer auf die Sekunde genau (manchmal 1 Sekunde später) mit meinen programmierten Weckzeiten auftritt. Ich konnte bei mir aber nichts finden, obschon der Fehler vermutlich schon bei mir liegt. Kann ich da vielleicht einen Hinweis bekommen, in welche Richtung ich bei mir suchen sollte?
Die andere Warnung
2016.01.03 05:54:32 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 109037) line 2.
kommt, wenn ich aufgestanden bin und meinen Status wieder auf "home" setze (was ich ganz einfach mit "set rr_Juergen status home" mache).
Seit dem letzten Update gibt es (wieder) folgende Meldungen im Log:
2016.01.03 09:01:43.849 1: readingsUpdate(rr_XXX,lastDurAbsence_cr,638) missed to call readingsBeginUpdate first.
2016.01.03 09:01:43.849 1: readingsUpdate(rr_XXX,lastDurAbsence,10:37:35) missed to call readingsBeginUpdate first.
2016.01.03 09:01:43.849 1: readingsUpdate(rr_XXX,lastArrival,2016-01-03 09:01:43) missed to call readingsBeginUpdate first.
2016.01.03 08:57:56.337 1: readingsUpdate(rr_XXX,lastDurPresence_cr,633) missed to call readingsBeginUpdate first.
2016.01.03 08:57:56.337 1: readingsUpdate(rr_XXX,lastDurPresence,10:33:01) missed to call readingsBeginUpdate first.
2016.01.03 08:57:56.337 1: readingsUpdate(rr_XXX,lastDeparture,2016-01-03 08:57:56) missed to call readingsBeginUpdate first.
Restore der älteren Versionen behebt das Problem.
Zitat von: marvin78 am 03 Januar 2016, 09:11:24
Seit dem letzten Update gibt es (wieder) folgende Meldungen im Log.
Genau das wollte grad melden. Habe es gerade kurz auf einem jungfräulichen FHEM nachgestellt. Wenn man FHEM 5.7 von der Homepage runterlädt, geht es noch - nach einem update & shutdown restart nicht mehr. Leider stürzt dann bei mir bei Nutzung des Moduls (Hatte Notifies von Geofancy zu RESIDENTS eingerichtet) auch noch FHEM komplett mit dem Fehler "month "-1" out of range" aus Zeile 1581 der RESIDENTStk.pm ab. Ich dachte erst, es liegt am
$m -= 01; aber es dann kommt es klarer im Log: Anscheinend wird da ein leerer Timestamp übergeben.
Puh, ich dachte schon ich kapiers nicht :D
Habe gerade damit begonnen dieses Modul auszuprobieren. Nach dem anlegen von RESIDENTS hab ich einen ROOMATE hinzugefügt und als ich dann zB auf "Everything" ging (wo der Roomate dann ja angezeigt wird) stürtzt FHEM ab.
Hier meine (teilweise schon bekannten) Logs nach dem Anlegen eines Roomates. Der Fehler ohne Zeitstempel am Ende kommt erst, wenn ich Everything oder den Roomate direkt aufrufe:
2016.01.04 12:28:52 1: PERL WARNING: Use of uninitialized value $time in concatenation (.) or string at ./FHEM/20_ROOMMATE.pm line 911.
2016.01.04 12:28:52 1: PERL WARNING: Use of uninitialized value $device in concatenation (.) or string at ./FHEM/20_ROOMMATE.pm line 911.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,wayhome,0) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,lastArrival,2016-01-04 12:28:52) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerPresence_cr,0) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerPresence,00:00:00) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerAbsence_cr,0) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerAbsence,00:00:00) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerSleep_cr,0) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerSleep,00:00:00) missed to call readingsBeginUpdate first.
2016.01.04 12:29:06 1: readingsUpdate(rr_XXX,wayhome,0) missed to call readingsBeginUpdate first.
2016.01.04 12:29:06 1: readingsUpdate(rr_XXX,lastDeparture,2016-01-04 12:29:06) missed to call readingsBeginUpdate first.
Month '-1' out of range 0..11 at FHEM/RESIDENTStk.pm line 1581
Hab gerade einen vorübergehenden Patch dafür eingecheckt.
Wo bekomme ich den Patch denn her? Bei update check wird mit nichts angezeigt. Hast du nen repo oder wird der patch verzögert verteilt?
wie üblich bei FHEM immer über Nacht am nächsten Morgen oder manuell aus dem Subversion Repo bei Sourceforge.
Na gut, ich warte lieber auf das FHEM update, kenne mich mit subversion nicht so aus. Nich dass ich mir da noch was zerschiesse.
Muss mich mal damit beschäftigen, habe da nur noch nicht ganz durchgeblickt wie git und/oder subversion prinzipiell funktionieren.
Läuft jetzt wieder!
Danke Loredo für den Patch und für die tolle Modulfamilie. Ist ein wirklich mächtiges Ding, dass sehr viele Möglichkeit bietet!
Zitat von: Loredo am 06 Januar 2016, 18:13:01
Die wayhome-Logik ist bei Nutzung des r*_geofenceUUIDs Attributs noch nicht richtig, ich muss die noch überarbeiten.
Generell soll es so sein, dass eine Lokation mit Namen "wayhome" eine besondere Rolle spielt: Beim betreten des Radius wird wayhome auf 1 gesetzt, wenn man zu Hause angekommen ist wieder auf 0.
Alle anderen Lokationen, die in r*_locationWayhome gesetzt sind, wirken sich anders aus: Nur bei deren VERLASSEN wird wayhome auf 1 gesetzt. Man kann dort also zB das Büro reinschreiben, wenn man in der Regel von dort direkt nach Hause fährt.
Moin, ich habe mehrere Orte in meine geofancy app angelegt. Folgende Orte habe ich jetzt drin: Schule, Arbeit, wayhome und home. Ich habe die UUID jetzt aus dem geofancy gelöscht und dafür das ROOMMATE device angelegt. Als ich vorhin den Bereich "Arbeit" verlassen habe, ist die Location nicht automatisch auf "underway" und auch nicht auf "wayhome" gewechselt. In der App wurde mir auf jeden fall das betreten und verlassen der bereiche angezeigt.
Wird "wayhome" und "underway" generell (noch) nicht von ROOMMATE berücksichtigt?
"underway wäre jetzt nicht so wichtig, aber "wayhome" schon.
Für den Fall dass es (noch) nicht berücksichtigt wird, würde es vorerst reichen (bis zur richtigen implementierung der "wayhome"-funktionen in dem Modul), wenn ich den ort "wayhome" in meine Stadt umbenenne, dass das device dann meine Stadt als aktuelle location erkennt? Damit könnte ich zumindest schonmal solche Dinge wie Heizungssteuerung realisieren.
Was ich noch suche sind genaue beschreibungen der neuen Attribute, ich schaue mal den Thread hier durch.
Vielleicht liegt ja auch einfach ein Fehler meinerseits vor.
Ich habe gerade ein Update eingecheckt, welches jetzt in Verbindung mit GEOFANCY ein verbessertes wayhome Handling beinhaltet.
@Lars: es gibt keine neuen Attribute, es sind nach wie vor die selben. Die Beschreibung steht in der Commandref zu ROOMMATE.
Gruß
Julian
Hmm okay!
Das heißt, ich kann mir jetzt in der App einen Bereich bon 15km um meine Wohnung einrichten. Der sollte dann wahrscheinlich am besten "wayhome" heissen?
Danke für deine mühen, dann kann ich ab morgen das ganze mal "live" testen. Habe das ganze bisher nur beobachtet um die verhaltensweise der Module kennenzulernen.
Ab morgen, wenn du das Update installiert hast, ja.
Wenn du die Umkreis-Funktion nutzen möchtest, muss die Lokation "wayhome" heißen, ja.
Wenn du möchtest, dass bei Verlassen einer bestimmten Lokation auf wayhome geschaltet wird, kann sie beliebig heißen, muss aber dann im Attribut locationsWayhome definiert sein, damit das erkannt wird.
Neu ist insgesamt noch, dass wayhome auf 2 wechselt, sofern wayhome einmal auf 1 gesetzt wurde. Nämlich dann, wenn man auf dem Heimweg nochmals woanders hält (und dafür dann natürlich ein entsprechender Ort definiert ist). Beim verlassen dieses Ortes wird dann wieder auf 1 geschaltet. Erst bei der Ankunft zu Hause endet das wayhome-Tracing dann und wayhome wird wieder auf 0 gesetzt. Während des wayhome-Tracing bleibt wayhome beim RESIDENTS Device nach wie vor auf 1. Ich überlege noch ein weiteres Reading für das RESIDENTS Device, welches dann "sich verspätende" Bewohner anzeigt.
Außerdem gibt es noch ein neues ROOMMATE Reading "locationPresence" welches "present" oder "absent" sein kann.
Bei Eintreffen an einer Lokation steht es auf "present", wenn man die Lokation verlassen hat auf "absent". Hintergrund ist, dass die anderen location-Readings nach wie vor bleiben, bis man eine andere Lokation erreicht hat. Mit locationPresence lässt sich dann also unterscheiden, ob das wirklich der aktuelle Aufenthaltsort ist oder nur der zuletzt bekannte Ort.
Ich betone nochmals, dass diese Verhalten nur bei direkter Nutzung mit GEOFANCY zutreffen. Wer in seiner Automation den location-Setter nutzt, um selbst die Lokation zu setzen, hat nach wie vor das alte Verhalten, da dabei keine Geo-Koordination übergeben werden und man immer davon ausgehen muss, dass es sich lediglich um die zuletzt bekannte Position handelt.
Gruß
Julian
Guten Morgen Loredo
Heute Nacht hat sich schon zum zweiten mal diese Woche mein Roommate auf 'home gesetzt. Dies wurde aber von keinem mehr bekannten Notify oder DOIF ausgelöst. Es hat nicht mit der presentserkennung zu tun weil ich keine Notify oder so habe was von asleep auf home setzt. Hier mal ein list.
Internals:
CHANGED
DEF AnniKraussStr
NAME rr_Marko
NR 30
NTFY_ORDER 50-rr_Marko
RESIDENTGROUPS AnniKraussStr,
STATE home
TYPE ROOMMATE
Readings:
2016-01-08 22:45:25 durTimerAbsence 00:00:00
2016-01-08 22:45:25 durTimerAbsence_cr 0
2016-01-09 06:35:08 durTimerPresence 07:50:06
2016-01-09 06:35:08 durTimerPresence_cr 470
2016-01-09 02:12:02 durTimerSleep 00:00:00
2016-01-09 02:12:02 durTimerSleep_cr 0
2016-01-08 22:45:24 lastArrival 2016-01-08 22:45:24
2016-01-09 02:12:02 lastAwake 2016-01-09 02:12:02
2016-01-08 22:13:11 lastDeparture 2016-01-08 22:13:11
2016-01-08 22:45:24 lastDurAbsence 00:32:01
2016-01-08 22:45:24 lastDurAbsence_cr 32
2016-01-08 22:13:11 lastDurPresence 05:24:00
2016-01-08 22:13:11 lastDurPresence_cr 324
2016-01-09 02:12:02 lastDurSleep 02:06:00
2016-01-09 02:12:02 lastDurSleep_cr 126
2016-01-08 22:13:11 lastLocation home
2016-01-08 07:14:55 lastLocationAddr -
2016-01-08 07:14:55 lastLocationLat -
2016-01-08 07:14:55 lastLocationLong -
2016-01-09 00:06:08 lastMood sleepy
2016-01-09 00:06:08 lastSleep 2016-01-09 00:06:08
2016-01-09 02:12:02 lastState asleep
2016-01-08 04:00:05 lastWakeup 05:00
2016-01-08 04:00:05 lastWakeupDev rr_Marko_wakeuptimer1
2016-01-08 22:45:24 location home
2016-01-08 07:14:55 locationAddr -
2016-01-08 07:14:55 locationLat -
2016-01-08 07:14:55 locationLong -
2016-01-09 02:12:02 mood calm
2016-01-09 04:00:00 nextWakeup OFF
2016-01-09 04:00:00 nextWakeupDev none
2016-01-08 22:45:24 presence present
2016-01-09 02:12:02 state home
2016-01-08 05:00:11 wakeup 0
2016-01-08 22:45:24 wayhome 0
Timer:
Rr_marko_durationtimer:
HASH rr_Marko
MODIFIER DurationTimer
NAME rr_Marko_DurationTimer
Attributes:
alias Marko
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown
event-on-change-reading state,presence,wayhome,location
group Marko
icon people_sensor
room AnniKraussStr
rr_locations atwork,home,wayhome,underway
rr_passPresenceTo rr_Steven rg_Anna
rr_realname alias
rr_states home,gotosleep,asleep,awoken,absent,gone
rr_wakeupDevice rr_Marko_wakeuptimer1
sortby 0
webCmd state:mood
Im log selber steht leider nur das gewechselt wird auf 'home und dann halt die damit in Verbindung stehenden Aktionen weil mein Roommate den Residents Status auf 'home gesetzt hat.
Vielleicht fällt Dir ja was auf.
Interessant ist noch das ich an beiden Tagen ein neu starten von FHEM gemacht habe. Also am Tag oder Abends. Beim ersten auftreffen schaltete sich mein Bewohner um 23:07 von asleep auf home und heute um 2:38.
Grüße
Der Wecker funktioniert nicht mehr!
Im Log steht:
2016.01.08 22:09:09 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 21822) line 2.
2016.01.08 22:24:15 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 22109) line 2.
Genau zum ersten Zeitpunkt wurde das notify getriggert, dessen Code wie folgt ist:
{
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
if ($wday == 1 || $wday == 3) {
fhem("set rr_Ursula state gotosleep; set wk_infoMP3 playTone 003,015,004")}
elsif ($wday == 2 || $wday == 4) {
fhem("set rr_Ursula state gotosleep; set wk_infoMP3 playTone 003,016,004")}
else {
fhem("set rr_Ursula state gotosleep; set wk_infoMP3 playTone 003,018,004")}
}
Genau zum ersten Zeitpunkt wurde das notify getriggert, dessen Code wie folgt ist:
{if ($EVENT eq "toggle") {
fhem("set rr_Ursula state asleep")
} else {
fhem("set rr_Ursula state asleep;
sleep 5;
set or_nachttischlampe on-for-timer 1")
}
}
Bitte im zweiten Fall nicht wundern, das ist der Code und dieser soll später noch erweitert werden...
Ich habe an diesen Codes seit Monaten nichts mehr geändert, auch nicht an irgendetwas anderem der Residents/Roommates. Aktuell stehen die Verbosewerte alle auf 0 (es hat ja alles zur besten Zufriedenheit getan).
Mich würde interessieren, wo ich genauer hinschauen muss, sofern der Fehler bei mir liegt (davon ist erst einmal auszugehen). Vielleicht gibt die Warnung im Log einen Hinweise, der sich mir nicht erschließt.
Edit: gerade nochmals nachvollzogen:
2016.01.09 13:03:37 2: ROOMMATE set rr_Ursula gotosleep
2016.01.09 13:03:38 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35044) line 2.
2016.01.09 13:05:11 2: ROOMMATE set rr_Ursula asleep
2016.01.09 13:05:14 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35085) line 2.
2016.01.09 13:05:49 2: ROOMMATE set rr_Ursula home
2016.01.09 13:05:50 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35113) line 2.
Ich bekomme den Fehler auch, wennich den Status ohne notify manuell ändere:
2016.01.09 13:09:08 2: ROOMMATE set rr_Ursula gotosleep
2016.01.09 13:09:09 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35173) line 2.
2016.01.09 13:09:25 2: ROOMMATE set rr_Ursula home
2016.01.09 13:09:26 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35195) line 2.
Also ich bekomme mittlerweile grundsätzlich bei jeder Änderung des "state" eines Roommate eine Warnung im log:
2016.01.09 22:35:46 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 3363) line 2.
und eine Konsequenz ist, dass der Wecker nicht mehr funktioniert.
Ich habe gerade nochmals ein Update gemacht, inkl. Restart von FHEM: hat nicht geholfen!
Ich ändere den Status direkt im Browser (siehe Screenshot) von gone auf gotosleep und wieder auf gone (ich bin gerade unterwegs, meine Frau ist aber zu Hause, da passiert das gleiche), das Ergebnis im Log:
2016.01.09 22:45:39 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 176) line 2.
2016.01.09 22:45:58 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 193) line 2.
Ok, muss uns halt wieder der gute alte Tick-Tack wecken. Gut, dass man so etwas noch im Haus findet.
Was kann ich beitragen, damit wir das Problem lösen? Denn ansonsten ist das genial und wir würden nur ungern darauf verzichten.
Solange die Fehler nicht auftreten, wenn ein ganz frisch angelegtes ROOMMATE Device nebst Wecker diese Warnungen produzieren, ist es wahrscheinlich, dass es einen Fehler in den selbst abgeänderten Notifies gibt. Ich bekomme das mit einem Dummy-Device zumindest nicht reproduziert.
Zitat von: CoolTux am 09 Januar 2016, 06:45:44
Heute Nacht hat sich schon zum zweiten mal diese Woche mein Roommate auf 'home gesetzt. Dies wurde aber von keinem mehr bekannten Notify oder DOIF ausgelöst. Es hat nicht mit der presentserkennung zu tun weil ich keine Notify oder so habe was von asleep auf home setzt. Hier mal ein list.
Ich kann mir nur vorstellen, dass du ein übrig gebliebenes at oder Watchdog Device hast, welches herrenlos ist und nicht mehr (richtig) einem ROOMMATE Device zugeordnet. Du solltest prüfen, ob alle involvierten Attribute für die Verweise zwischen den DUMMY, Notify, at und watchdog Devices und dem ROOMMATE Device stimmen.
Grundsätzlich gab es am Wakeuptimer seit Monaten keinerlei Änderungen. Die hier jüngst durchgeführten Verbesserungen können damit also nicht in Zusammenhang stehen, dass ein Status sich ändert.
Hallo Loredo,
Vielen Dank für Deine Antwort. Ich werde es mir mal genauer anschauen. Bis jetzt kam es nicht wieder vor. Ich werde das mal im Auge behalten und versuchen es näher zu analysieren. Kann schon sein das es eine nicht mehr korrekte Zuordnung ist. Bei mir ist in den letzten Wochen einiges dazu gekommen ;D
Grüße
Leon
Zitat von: Loredo am 10 Januar 2016, 19:37:31
Solange die Fehler nicht auftreten, wenn ein ganz frisch angelegtes ROOMMATE Device nebst Wecker diese Warnungen produzieren, Es ist wahrscheinlich, dass es einen Fehler in den selbst abgeänderten Notifies gibt. Ich bekomme das mit einem Dummy-Device zumindest nicht reproduziert.
Das heißt also löschen und komplett neu anlegen...ok, werde ich mal machen.
Alternativ parallel eine Dummy-Familie aus RESIDENTS und ROOMMATE zum testen anlegen und dafür den Wakeuptimer anlegen. Wenn man das RESIDENTS Device zuerst anlegt und in einen Raum "Test" verlegt und anschließend über das set-Kommando die Bewohner anlegt, hat man auch alles in einem Testraum zusammen.
Gruß
Julian
@Loredo
Ich denke mal ich habe meinen Fehler gefunden. Hat was mit meinem presence notify zu tun. Hoffe mal das es das war.
Grüße
Zitat von: ujaudio am 11 Januar 2016, 17:41:39
Das heißt also löschen und komplett neu anlegen...ok, werde ich mal machen.
Alles komplett gelöscght und wieder sorgfältigst angelegt - gleiches Fehlverhalten.
Morgen wieder, jetzt bin ich fertig.
Für diejenigen, die die Location Funktion mit GEOFANCY via dem Attribut r*_geofenceUUIDs benutzen gibt es ab morgen einen neuen Setter, der auf einfache Weise einen Google Maps Weblink anlegt, damit die aktuelle Position in einer Karte angezeigt wird.
Obwohl es auch ne allgemeine RegEx-Frage, stelle ich sie mal gezielt hier ein:
Mit attr rr_noDuration 1 stelle ich die ganze Duration-Geschichte auf aus.
Könnte ich event-on-change-reading so einstellen, dass ich zwar die Zeiten abfragen kann, aber dennoch keine Events generiere?
"event-on-change-reading durTimer.*"geht ja nicht, man bräuchte das "Gegenteil".
Zweite Frage: ich habe das Glück, im Normalfall keinen Wecker zu brauchen. Funktioniert der Resetswitcher dafür auch, oder muss ich mir einfach eine einzelne Weckzeit definieren? Denn dann würde ich ja auch auf die integrierten Prozesse verzichten müssen, oder?
Zitat von: Per am 31 Januar 2016, 22:10:59
Mit attr rr_noDuration 1 stelle ich die ganze Duration-Geschichte auf aus.
Könnte ich event-on-change-reading so einstellen, dass ich zwar die Zeiten abfragen kann, aber dennoch keine Events generiere?
"event-on-change-reading durTimer.*"geht ja nicht, man bräuchte das "Gegenteil".
Das ist in der Tat keine Frage für diesen Thread hier.
Vielleicht mit sowas hier (ungetestet):
event-on-change-reading ^(?!(?:durTimer.*)).*$
Zitat von: Per am 31 Januar 2016, 22:10:59
Zweite Frage: ich habe das Glück, im Normalfall keinen Wecker zu brauchen. Funktioniert der Resetswitcher dafür auch, oder muss ich mir einfach eine einzelne Weckzeit definieren? Denn dann würde ich ja auch auf die integrierten Prozesse verzichten müssen, oder?
Sicher, du kannst das Attribut wakeupDefaultTime einfach auf OFF setzen. Dann wird nach einmaligem wecken der Wecker deaktiviert.
Das hat aber mit dem Resetswitcher direkt nichts zu tun, denn der ist nur dafür da, dass man den automatischen Reset schnell ein und aus schalten kann.
Zitat von: Loredo am 07 Februar 2016, 14:12:52
Vielleicht mit sowas hier (ungetestet):
event-on-change-reading ^(?!(?:durTimer.*)).*$
lässt fhem abstürzen.
Ich habe gerade den Wakeuptimer dahingehend erweitert, dass wakeupWaitPeriod jetzt nicht mehr den letzten Lauf des jeweiligen Weckers berücksichtigt, sondern generell jeden Wecker, der einem ROOMMATE/GUEST Device zugeordnet ist. Außerdem wird zusätzlich neu geschaut, ob die Person bereits innerhalb der letzten Stunden aufgewacht ist. Das hilft dagegen, dass der Wecker auslöst, wenn man z.B. bereits vor dem Wecker von selbst wach geworden ist und sich manuell auf "awoken" geschaltet hat. Der Zeitraum dafür ist momentan identisch mit wakeupWaitPeriod ansich, da mir gerade kein Grund einfiel dafür ein extra Attribut einzuführen.
Ab morgen dann per Update.
Gruß
Julian
Hallo,
ich habe hier folgende Konfiguration:
EgiGeoZone mit GPS und Beacons
Eine Work und eine Wayhome Zone ist mit GPS Erkennung eingerichtet.
Meine Home Zone habe ich mit Beacons eingerichtet.
1. Beacon Zone: home Reichweite gesamtes Haus
2. Beacon Zone: Wohnzimmer aktiv nur im Wohnzimmer
3. Beacon Zone: Schlafzimmer aktiv nur im Schlafzimmer
EgiGeoZone meldet zuverlässig ein Verlassen jeder Zone. Das hat aber den Nachteil, wenn ich das Wohnzimmer Beacon verlasse bin ich underway und nicht home obwohl ich die ganze Zeit im Bereich des Home Beacons bin.
im Attribut rr_locationHome habe ich alle Beacon Zonen erfasst.
Gibts dafür eine Lösung ?
Andreas
Zitat von: knochenmuehle am 14 Februar 2016, 13:01:43
Gibts dafür eine Lösung ?
Ja, du scheinst die Funktion falsch zu nutzen bzw. nicht korrekt eingerichtet zu haben:
1. Das Attribut rr_locationHome ist nur für Lokationen vorgesehen, für die ein kommen/gehen dann auch den tatsächlichen Anwesenheitsstatus verändern soll (siehe Beschreibung in der CommandRef). iBeacons sollte man hier nur eintragen, wenn diese iBeacon ID auch dauerhaft im gesamten Wohnbereich empfangen wird. iBeacons für einzelne Zonen sollte man hier nicht eintragen, da es auch nicht notwendig ist.
2. In der Geofencing App sollte man für iBeacons nur einen Event-Trigger fürs
betreten aktivieren, nicht aber fürs verlassen. Dadurch relativiert sich auch die Aussage unter Punkt 1 und man kann unter rr_locationHome genannte iBeacons dafür nutzen sich als "zu Hause" zu schalten, sofern das über Geofencing noch nicht ausgelöst hat. Gleichzeitig wird verhindert, dass man als "abwesend" erkannt wird. Der Wechsel zwischen den Räumen findet dann ausschließlich über das Entering-Event statt. Somit wird auch verhindert, dass man zwar zu Hause ist, aber in FHEM der aktuelle Raum "unbekannt" ist (bzw. das Reading locationPresence auf "absent" steht, was eben gleichbedeutend ist mit "ich weiß grad nicht wo du bist").
Ich habe gerade einen weiteren Fix für den Wakeuptimer eingecheckt.
Ab morgen werden noch laufende Weckprogramme durch einen Statuswechsel ordnungsgemäß frühzeitig gestoppt. Das war im Code zwar schon drin, hatte bisher aber nicht gegriffen.
Wer also vor Ende des Weckprogrammes auf "awoken" schaltet, beendet damit ab sofort das Weckprogramm auch entsprechend.
Na das nenne ich doch mal eine saubere Lösung. Vielen Dank Julian.
Hallo Julian,
Hast Du in letzter Zeit was am Guest Modul gemacht? Irgendwie fehlt mir der Status none für dauerhaft weg. Also kein Guest im Haus.
Grüße
Leon
Hi Leon,
nein, da gab es keine Änderung in der Richtung.
Ich kann bei mir auch "none" ganz normal auswählen. Hast du die angezeigten Werte mittels Attributen abgeändert? (z.B. widgetOverride oder rg_states)
Hallo Julian,
Nein habe nichts geändert. Muss auch erst vor kurzem passiert sein. Kann aber mit meinen Dilemma von gestern zu tun haben, habe bei einem Set Befehl mit FILTER statt = ein : hinter FILTER gemacht und somit alle states auf nextRun gesetzt ;D
Habe jetzt den Guest gelöscht und neu angelegt und siehe da, none ist wieder da. Hatte da zum Glück noch keine weiteren Verknüpfungen.
Vielen Dank für die floltte Antwort.
Grüße
Zitat von: CoolTux am 18 Februar 2016, 10:55:31
Habe jetzt den Guest gelöscht und neu angelegt und siehe da, none ist wieder da. Hatte da zum Glück noch keine weiteren Verknüpfungen.
Selbst wenn: Löschen und unter dem selben Namen wieder neu anlegen ist überhaupt gar kein Problem :-)
Hallo,
ich habe bei mir ein notify auf das state-Reading eines RESIDENTS-Device, in dem ich dann per Push den Auslöser der Änderung verschicken möchte:
rgr_residents:state:.(home|absent|gone) {
my $lastActivity = ReadingsVal("rgr_residents", "lastActivityBy", "unbekannt");
fhem("set sys_pushbullet message $lastActivity | Homestatus: $EVTPART1", 1);
}
Das funktionierte bei mir nicht (ich bekomme das vorletzte aktive Device und nicht den eigentlichen Auslöser), da im Modul erst der state geändert wird und erst anschließend die entsprechenden Readings gesetzt werden, allerdings in unterschiedlichen Updates. Mit dem folgenden Patch hab ich das mal umgedreht, negative Auswirkungen konnte ich keine feststellen:
--- a/FHEM/10_RESIDENTS.pm
+++ b/FHEM/10_RESIDENTS.pm
@@ -154,20 +154,6 @@ sub RESIDENTS_Notify($$) {
Log3 $hash, 5,
"RESIDENTS " . $hashName . ": processing change $change";
- # state changed
- if ( $change !~ /:/
- || $change =~ /wayhome:/
- || $change =~ /wakeup:/ )
- {
- Log3 $hash, 4,
- "RESIDENTS "
- . $hashName . ": "
- . $devName
- . ": notify about change to $change";
-
- RESIDENTS_UpdateReadings($hash);
- }
-
# activity
if ( $change !~ /:/ ) {
@@ -205,6 +191,21 @@ sub RESIDENTS_Notify($$) {
readingsBulkUpdate( $hash, "lastActivityByDev", $devName );
readingsEndUpdate( $hash, 1 );
}
+
+ # state changed
+ if ( $change !~ /:/
+ || $change =~ /wayhome:/
+ || $change =~ /wakeup:/ )
+ {
+ Log3 $hash, 4,
+ "RESIDENTS "
+ . $hashName . ": "
+ . $devName
+ . ": notify about change to $change";
+
+ RESIDENTS_UpdateReadings($hash);
+ }
+
}
return;
Spricht was dagegen das allgemein zu übernehmen, evtl. übersehe ich ja was?
Wolfgang
Ich habe gerade eine Erweiterung des Wakeuptimers eingecheckt.
Man kann jetzt bei einem aktiven Wecker dessen Zeit relativ zur bereits gesetzten Weckzeit verändern, also z.B. 10 Minuten früher oder auch später:
set rr_Julian_wakeuptimer1 nextRun +10
set rr_Julian_wakeuptimer1 nextRun -00:10
Man kann die Zeit in Minuten oder im Format HH:MM angeben.
Das kann z.B. dazu verwendet werden, wenn man verkehrsbedingt (Auto oder Bahn) früher geweckt werden möchte. Zusammen mit dem wakeupDefaultTime Attribut wird dann auch sichergestellt, dass die Weckzeit am nächsten Tag wieder zunächst wie gewohnt ist.
Zitat von: wmr72 am 19 Februar 2016, 20:41:55
Das funktionierte bei mir nicht (ich bekomme das vorletzte aktive Device und nicht den eigentlichen Auslöser), da im Modul erst der state geändert wird und erst anschließend die entsprechenden Readings gesetzt werden, allerdings in unterschiedlichen Updates.
Ich habe den Patch abgewandelt; die Readings werden jetzt allesamt zusammen erzeugt und es wird nur noch ein einziges Event ausgelöst.
Ab morgen dann per Update verfügbar.
Hallo Julian,
Ist es Möglich zwei Residents Devices in Abhängigkeit zu einem weiteren Residents Device zu schalten? So wie Roommate zu Residents.
Ich möchte gerne Residents Eltern, Residents Kinder und Residents Wohnung haben. Oder muss ich in Residents Wohnung alle Roommate's von Residents Eltern und Residents Kinder eintragen?
Grüße
Die Möglichkeit gleiche Devices miteinander zu verschachteln habe ich absichtlich verworfen, da es dann zu komplex wird.
Auch wenn der erste Implus ist, dass man mehrere RESIDENTS Devices hintereinander kaskadieren können möchte, so hilft etwas umdenken auch dabei zu sehen, dass man das selbe auch erreichen kann, wenn die ROOMMATE/GUEST Devices einfach in mehreren RESIDENTS Devices gleichzeitig Mitglied sein können.
Ein Beispiel für das, was du möchtest, findet sich sogar in der CommandRef (http://fhem.de/commandref.html#ROOMMATE):
# Complex family structure
define rr_Manfred ROOMMATE rgr_Residents,rgr_Parents # Parent
define rr_Lisa ROOMMATE rgr_Residents,rgr_Parents # Parent
define rr_Rick ROOMMATE rgr_Residents,rgr_Children # Child1
define rr_Alex ROOMMATE rgr_Residents,rgr_Children # Child2
Übrigens nur so rein als Hinweis: Ein RESIDENTS Device als "Wohnung" zu führen ist rein syntaktisch nicht ganz richtig, da es nicht den wirklichen Hausstatus wiedergibt (also z.B. in welchem "Modus" sich das Haus gerade befindet - also sowas wie Morgen/Tag/Abend/Nacht), sondern lediglich den Status seiner Bewohner.
Für den tatsächlichen Hausstatus war/ist noch immer ein Modul "HOMESTATE" o.ä. vorgesehen. Allerdings feile ich da noch immer an vielerlei Logik und schaue auch noch, ob es überhaupt noch ein eigenständiges Modul sein muss. Mit DOIF lässt sich auch sehr viel machen (aber noch nicht 100%ig alles). Ich überlege also mehr ähnlich wie beim Wakeuptimer eine Art Framework/Template bereitzustellen, welches dann eben genauso anpassbar ist und direkt auf die Zusammenarbeit mit RESIDENTS/ROOMMATE/GUEST ausgelegt ist. Das ist aber noch ein langer Weg, ich komme einfach nicht dazu das rund zu machen (auch zum Leidwesen meiner eigenen Hausautomation).
Gruß
Julian
Vielen Dank für Deine ausführliche Antwort. Naja es heißt ja nicht direkt Wohnung bei mir sondern so wie meine Straße ;D
Aber ich weiß was Du meinst und so führe ich es auch Gedanklich.
Grüße
Leon
Zitat von: Per am 31 Januar 2016, 22:10:59Könnte ich event-on-change-reading so einstellen, dass ich zwar die Zeiten abfragen kann, aber dennoch keine Events generiere?
Da ich keine Antwort (https://forum.fhem.de/index.php/topic,49574.msg412813.html#msg412813) bekommen habe, scheint es nicht zu gehen.
Zitat von: Per am 31 Januar 2016, 22:10:59Mit attr rr_noDuration 1 stelle ich die ganze Duration-Geschichte auf aus.
Wäre es möglich, mit
attr rr_noDuration 2 (oder halt einer anderen Syntax) die Abfragen selbst an, aber die Events auszuschalten?
Edit: Jetzt hat sich doch eine Lösung ergeben! Danke.
Kann jemand einem Neuling weiterhelfen?
Möchte gerne bei HomeStatus Änderung "absent" einen Befehl ausführen. Wird das auch über ein Macro geregelt?
Du kannst ein vorhandenes Macro kopieren und für absent anpassen. Denk auch daran den Watchdog mit zu kopieren.
Über DOIF oder Notify. Schau mal in die CommandRef.
Gruß
Julian
Zitat von: CoolTux am 23 April 2016, 17:29:45
Du kannst ein vorhandenes Macro kopieren und für absent anpassen. Denk auch daran den Watchdog mit zu kopieren.
Danke das war die Lösung, manchmal echt einfach ;)
Nun bekomme ich im Log die Meldung
2016.04.23 17:52:29 2: ROOMMATE set rr_Marco absent
2016.04.23 17:52:33 3: Watchdog wd_rr_Marco_absent triggered
2016.04.23 17:52:33 2: IT set Flex_2 off
2016.04.23 17:52:33 3: Please define wd_rr_Marco_absend firstwd_rr_Marco_absend ist die Kopie von wd_rr_Marco_asleep
Die DEF wurden angepasst
rr_Marco:absent 00:00:04 rr_Marco:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rr_Marco_absent; setstate wd_rr_Marco_absend definedWie kann ich prüfen warum der watchdog nicht auf defined zurück gesetzt wird?
Du hast dich verschrieben. Einmal absent und einmal absend
Guten Morgen Julian,
Ich wollte heute mal Dein msg Befehl im wakeuptime Skript aus probieren. Aber irgendwie meckert er wegen dem @
Macro_rr_Thomas_wakeuptimer1 return value: Global symbol "@Sonos_Schlafzimmer" requires explicit package name at (eval 24470) line 55.
So sieht die Zeile im Skript aus
fhem "define atTmp_7_$NAME at +01:00:00 msg audio @Sonos_Schlafzimmer |Hint| Guten Morgen Thomas. Es ist ".$EVTPART1." Uhr, Zeit zum aufstehen!
Irgendwie ja auch verständlich. Für Perl ist das @ ja eigentlich ein Array. Welches aber im Wakeup script global vorhanden sein muß, aber irgendwie ist es das im Script nicht.
Ne Idee?
Grüße
Leon
im Perl Kontext muss ein @ als \@ escaped werden.
Dazu ist auch ein Beispiel im Default-Macro.
Hallo Julian,
Mir war so als hätte ich das auch schon getestet. Mache es aber heute oder morgen noch mal so und teste. Frage ist nur wird das \ dann nicht auch in den define des at mit übertragen und somit dann im FHEM Kontext? Ich schaue mir mal das default Makro an. Muss mal sehen wo das sein soll. Lach.
Es gibt ja ein Beispiel genau so wie ich es habe, daher dachte ich das irgendwas fehlt oder ich übersehen habe.
Die Beispiel-Macros waren da wohl auch nicht ganz korrekt bisher, ich hatte zwei \\ zu wenig im File RESIDENTStk.pm und das gerade korrigiert, damit die Vorlagen auch akkurat sind ;-)
Cool. Firma Dankt.
Ich teste dann die Tage mal.
Beste Grüße
Leon
Gib es eine Möglichkeit den RESIDENTS Status gotosleep nicht zu schalten wenn die ROOMMATES den Status gotosleep und der andere absent haben.
Ich fahre alle Rollos beim RESIDENTS Status gotosleep runter aber ein ROOMMATES ist ja noch absent, und somit sollten die Rollos noch nicht runterfahren.
Zitat von: Otto am 07 Juni 2016, 22:05:53
Gib es eine Möglichkeit den RESIDENTS Status gotosleep nicht zu schalten wenn die ROOMMATES den Status gotosleep und der andere absent haben.
Ich fahre alle Rollos beim RESIDENTS Status gotosleep runter aber ein ROOMMATES ist ja noch absent, und somit sollten die Rollos noch nicht runterfahren.
Soweit mir bekannt nicht. Macht auch irgendwie wenig Sinn. Wenn man ganz böse ist würde ich sagen, während Du unterwegs bist darf Deine Frau nicht in Ruhe schlafen ;D
Was Du machen kannst ist alle Roommates in die Abfrage Deiner Rollos ein zu bauen.
Zitat von: Otto am 07 Juni 2016, 22:05:53
Gib es eine Möglichkeit den RESIDENTS Status gotosleep nicht zu schalten wenn die ROOMMATES den Status gotosleep und der andere absent haben.
Das wäre unlogisch, denn es geht immer in erster Linie um die anwesenden Personen. Zudem kann man nicht logisch voraussagen, ob eine abwesende Person noch nach Hause kommt oder nicht.
Wenn also alle anwesenden Personen bereits schlafen oder den Status "gotosleep" haben, dann wird auch der Gesamtstatus auf "gotosleep" geschaltet. Nur wenn eine Person anwesend ist und wach (=home) bleibt, bleibt auch der Gesamtstatus auf "home".
Zitat von: Otto am 07 Juni 2016, 22:05:53
Ich fahre alle Rollos beim RESIDENTS Status gotosleep runter aber ein ROOMMATES ist ja noch absent, und somit sollten die Rollos noch nicht runterfahren.
Warum denn eigentlich nicht? Hast du ein Rollo vor der Haustür und man kommt sonst nicht ins Haus? Oder steigt der abwesende Bewohner gerne durch die Terrassentür ein ;D
Ich gebe CoolTux recht: Du solltest überlegen, ob du die Rollos der einzelnen Schlafzimmer dann nicht am Status des jeweiligen ROOMMATE Gerätes fest machst. Bei zwei Personen kannst du auch mit einem zusätzlichen RESIDENTS Device nur für den "Pärchenstatus" arbeiten. Ich gehe davon aus, dass der noch abwesende Partner nicht verlangt, dass der andere solange im hellen Schlafzimmer schlafen muss, bis er auch zu Hause ist. ;)
Wenn du aber immer noch Gründe siehst es so zu lösen, wie du es schreibst, dann solltest du dein Notify/DOIF nicht auf das Reading "state" schalten, sondern durch logische Vergleiche+Verknüpfung der Nummern-Readings wie residentsGotosleep, residentsHome und residentsTotal.
Hallo Loredo,
vielen Dank für die Erklärung.
Ich werde mal überlegen wie ich es anstelle.
Hi,
nach Umstellung auf iBeacons hätte ich noch einen kleinen Verbesserungsvorschlag bei Verwendung mit Geofancy / rr_geofenceUUIDs:
Evtl. wäre der Vorschlag auch besser im Geofancy Thread platziert?
Weiss nicht wie die beiden Module intern genau zusammenspielen.
Selbst mit mehreren Beacons und höchster Sendeleistung + Häufigkeit hat man ab und an (alle paar Tage) bei jedem Gerät mal kurze Aussetzer.
Nicht zur selben Zeit, scheint also kein Problem der Beacons zu sein sondern eher Systembedingt.
Sprich sehr selten sendet Geofency vom iPhone ein "Home Verlassen" und 2-3 Sekunden später wieder ein "Home Betreten" obwohl man die ganze Zeit in der Wohnung war.
Könnte man hier eine Art Delay in Sekunden als Option für Location-Änderungen einbauen?
Kleines Beispiel:
- Home Betreten -> Timer startet aber Status bleibt weiter auf Absent
- Wartezeit läuft ab -> Status geht auf Home
- Fehlerhafterweise tritt nun "Home verlassen" auf -> Timer startet aber Status bleibt auf Home
- Innerhalb des Timers tritt nun wieder "Home betreten" auf -> Timer startet von vorne, Status ist immer noch Home
- Timer läuft ab -> aktueller Status wieder (oder immer noch) Home
- "Home verlassen" tritt nun berechtigterweise auf -> Timer startet
- Timer läuft ab -> Status auf Absent
Delay für die Kombination mit GEOFANCY steht bereits auf der Todo Liste.
Wer statt dem UUID Attribut manuell über DOIF oder watchdog verknüpft, kann dies auch jetzt bereits haben (mit einigen Einschränkungen in der Weitergabe der Readings).
Achso: Ein Delay ansich kann man im übrigen auch direkt in der Geofency App einstellen (sogar je Location).
Der Grund weshalb das on ROOMMATE noch nicht drin ist liegt auf der Hand: Ein einfaches Delay alleine reicht nicht unbedingt, da muss etwas mehr Intelligenz mit hinein. Insbesondere beim Betreten der Homezone möchte ich persönlich nämlich keinerlei Verzögerung haben, da ich z.B. durch Empfang in der Tiefgarage womöglich ohnehin eher spät erkannt werde oder der Webhook spät abgesetzt werden kann. Erst in der Wohnung erkannt zu werden ist zu spät; insbesondere auch wenn jemand einen Beacon einsetzt will man eigentlich, dass der Status sofort auf "anwesend" geht.
Beim Thema Abwesend sieht es wieder anders aus: Da darf es ruhig länger dauern. Mein Tipp für die Beacon Fetischisten ist daher: Nutzt die Beacons nur für den Entry und deaktiviert das Exit Event. Nutzt für den Exit stattdessen Geofencing.
Gute Idee dein letzer Abschnitt. :)
Und ja, die Logik mit Verzögerung nur bei Verlassen klingt nach dem richtigen Ansatz.
Wie kann ich ein Logfile für den rr_Markus erstellen? Ich habe ein Log anlegen können, es wurden allerdings die Statuswechsel nicht dokumentiert.
Zudem möchte ich gerne über einen 6-er Schalter die Anwesenheit/Abwesenheit/GoToSleep auslösen.
Für einen kurzen Tastendruck, die des Bewohners; ein langer Tastendruck für die eines Gastes.
Das habe ich bisher mit einem notify gemacht, der dann über die Sonos die mit Sprachausgabe bestätigt.
Der Statuswechsel triggert anschließend die den Status zugehörigen Aktionen.
Auf den erfolgreichen GoToSleep Statuswechsel bei rr_Markus soll nach 10 Minuten (Einschlafvorbereitung) der Status automatisch auf Asleep springen.
Wie kann ich das triggern? fhem "sleep 600; set rr_Markus:state=asleep"
Du kannst im gotosleep Script den Code einfach eintragen. Dann wechselt er nach 10 min in den asleep Status
fhem "sleep 600; set rr_Markus:FILTER=STATE=gotosleep asleep"
Und für Dein Log Problem mach mal bitte ein list vom Logdevice
Grüße
Guten Morgen,
Wenn ich da mal ganz kurz die Aufmerksamkeit drauf lenken darf.
https://forum.fhem.de/index.php/topic,58114.msg495234.html#msg495234
Da gibt es wohl seit neustem Probleme mit automatischen Statuswechsel.
Danke, ist wohl deshalb (https://forum.fhem.de/index.php/topic,58354.0.html) durchgerutscht.
Habe im anderen Thread geantwortet.
Zitat von: Loredo am 17 Januar 2016, 17:34:06
Für diejenigen, die die Location Funktion mit GEOFANCY via dem Attribut r*_geofenceUUIDs benutzen gibt es ab morgen einen neuen Setter, der auf einfache Weise einen Google Maps Weblink anlegt, damit die aktuelle Position in einer Karte angezeigt wird.
Welchen Namen trägt denn der neue Setter?
Die Auswahlliste in Fhemweb verrät es: create locationMap
Sent from my iPad using Tapatalk
Zitat von: Loredo am 19 Oktober 2016, 01:23:13
Die Auswahlliste in Fhemweb verrät es: create locationMap
Sent from my iPad using Tapatalk
Ahh! Vielen Dank!
Ich hatte vergebens, Google, FHEM Forum, FHEM Wiki und Dokumentation danach durchsucht, hätte ich mal im Code geschaut... *koppkratz*
PS: Was auch noch cool wäre, wenn man änliches im Device Type RESIDENTS einbaut, dass dann alle Bewohner die zugeordnet sind, zeigt.
hi zusammen,
kurze Frage:
Wann wird das Reading nextWakeup und nextWakeupDev im Roommate gesetzt und ist dafür ein trigger notwendig?
aktuell steht das Reading auf 7:00 Uhr und rr_Michael_wakeuptimer1, was dem Wecker für die Wochentage entspricht. Morgen ist aber Samstag und somit müsste dort eig. wakeuptimer2 genutzt werden.
Wakeupresetdays ist passend gesetzt.
Gruß Michael
Kommando zurück!
Ich hatte ein event-on-change-reading für location,mood,presence,state gesetzt. Dadurch konnte wohl irgendein Trigger nicht mehr greifen. Habs wieder rausgenommen und es läuft wieder.
Gruß Michael
Moin moin,
kann es sein das die Timer trotz rr_noDuration im Hintergrund noch laufen? Weil bei mir werden die lastDur* immernoch fleißig weiter erzeugt. Hätte erwartet das sie durch rr_noDuration ebenfalls deaktiviert werden. Falls das Verhalten so beabsichtigt ist, wäre es möglich ein Attribut zu bekommen welches alle Timer irgendwie abschaltet? Ich brauch die ganze Timer Geschichte z.B. nicht und es würde mir Ressourcen schonen.
Gruß
Oliver
Absolut, denn wenn man das Attribut wieder entfernte, dann soll der Timer ja wieder anlaufen. Das Attribut sorgt lediglich für einen sofortigen Ausstieg aus der entsprechenden Funktion. Dieses wiederum frisst so marginal Ressourcen, dass ich keinen Grund sehe es anders zu handhaben.
Das heißt das Attribut unterbindet im Grunde nur dur* Readings? Wäre es dann möglich auch die lastDur* Readings zu unterbinden oder braucht er die intern?
Zitat von: Bootscreen am 24 November 2016, 14:18:53
Das heißt das Attribut unterbindet im Grunde nur dur* Readings?
Korrekt.
Zitat von: Bootscreen am 24 November 2016, 14:18:53
Wäre es dann möglich auch die lastDur* Readings zu unterbinden
Diese Readings sind vollkommen anders und werden sinnvollerweise nur eventbasiert berechnet, also zu dem Zeitpunkt, bei dem am Objekt ohnehin eine Statusänderung erfolgt. Ich werde auch sicherlich kein Cherry Picking für einzelne Readings implementieren, das macht einfach keinen Sinn. Wenn du mit einem Reading nichts anfangen kannst, dann kannst du es doch einfach ignorieren und nicht verwenden.
hallo,
so ganz rund läuft mein nextWakeup und nextWakeupDev immer noch nicht. Ich habe 4 WakeUpTimer, wobei für den konkreten Fall nur 2 wichtig sind. rr_Michael_wakeuptimer1 für werktags und rr_Michael_wakeuptimer2 für samstags.
Beide nutzen das gleiche notify für die Weckeraufgaben Macro_rr_Michael_wakeuptimer1
Der Wecker ist heute morgen durchgelaufen. Und wenn ich das richtig verstanden habe, dann wird sobald der Wecker gestartet wurde nextWakeup und nextWakeupDev für den nächsten Wecker gesetzt. Als ich vorhin in rr_Michael geschaut habe, standen die beiden Readings allerdings noch auf 07:00 Uhr für wochentags und rr_Michael_wakeuptimer1, obwohl sie eigentlich auf 09:15 und rr_Michael_wakeuptimer2 stehen sollten.
Anschließend habe ich bei rr_Michael verbose auf 5 gesetzt und set rr_Michael_wakeuptimer start ausgeführt.
hier das Log dazu:
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 00 - checking for next wake-up candidate rr_Michael_wakeuptimer1
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=0
2016.11.25 11:00:40 4: RESIDENTStk : 02rr_Michael_wakeuptimer1 - possible candidate found
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=06:43 wakeupOffset=17
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 04 - this is a candidate for tomorrow
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 05 - won't be running tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 00 - checking for next wake-up candidate rr_Michael_wakeuptimer2
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 01 - Holidays to be considered - today=0 tomorrow=0
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 02 - possible candidate found
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 03 - considering at-device value wakeupAtNTM=08:58 wakeupOffset=17
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 04 - this is a candidate for tomorrow
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 05 - until now, will be NEXT WAKE-UP RUN tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 00 - checking for next wake-up candidate rr_Michael_wakeuptimer3
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 01 - Holidays to be considered - today=0 tomorrow=0
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 02 - possible candidate found
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 03 - considering at-device value wakeupAtNTM=09:58 wakeupOffset=17
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 04 - this is a candidate for tomorrow
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 05 - won't be running tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=orHoliday)
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 00 - checking for next wake-up candidate rr_Michael_wakeuptimer4
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 01 - Holidays to be considered - today=0 tomorrow=0
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 02 - possible candidate found
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 03 - considering at-device value wakeupAtNTM=05:43 wakeupOffset=17
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 04 - this is a candidate for tomorrow
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 05 - won't be running tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 07 - next wake-up result: tomorrow at 09:15:00, wakeupDevice=rr_Michael_wakeuptimer2
und das list von rr_Michael_wakeuptimer2
Internals:
NAME rr_Michael_wakeuptimer2
NR 276
STATE 09:15
TYPE dummy
Readings:
2016-11-19 19:34:05 lastRun 19:51
2016-11-19 19:34:06 nextRun 09:15
2016-11-19 19:38:08 running 0
2016-11-25 08:58:00 state 09:15
Attributes:
alias Wecker Samstag
comment Auto-created by ROOMMATE module for use with RESIDENTS Toolkit
devStateIcon OFF:general_aus@red:reset running:general_an@blue:stop .*:general_an@green:nextRun%20OFF
group Michael
icon time_timer
room Residents
setList nextRun:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 reset:noArg trigger:noArg start:noArg stop:noArg end:noArg
sortby 4
userattr wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupMacro wakeupUserdevice wakeupAtdevice wakeupResetSwitcher wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2 wakeupWaitPeriod:slider,0,1,360
wakeupAtdevice at_rr_Michael_wakeuptimer2
wakeupDays 6
wakeupDefaultTime 09:15
wakeupEnforced 0
wakeupHolidays andNoHoliday
wakeupMacro Macro_rr_Michael_wakeuptimer1
wakeupOffset 17
wakeupResetdays 6
wakeupUserdevice rr_Michael
webCmd nextRun
nach kurzer Zeit haben ich den Wecker dann mit
set rr_Michael_wakeuptimer end wieder beendet.
Interessanterweise stimmen jetzt die Readings in rr_Michael
beim durchsehen der Logs ist mir folgende Zeile aufgefallen als rr_Michael_wakeuptimer2 ausgewertet wurde:
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 05 - until now, will be NEXT WAKE-UP RUN tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)
morgen ist doch kein Feiertag? und in meiner Holiday-Definition habe ich auch nichts dergleichen eingetragen:
# Format für einzelne Tage: 1 MM
1 01-01 Neujahr
1 05-01 Tag der Arbeit
1 10-03 Tag der deutschen Einheit
1 11-01 Allerheiligen
1 12-25 1. Weihnachtstag
1 12-26 2. Weihnachtstag
# Osterbezogene Feiertage
# Format: 2 <relative Tage von Ostern> <Text>
2 -2 Karfreitag
2 1 Ostermontag
2 39 Christi Himmelfahrt
2 50 Pfingsten
2 60 Fronleichnam
# Intervall.
#Format: 4 <MM-TT> <MM-TT> <Feiertag-Name>
4 12-24 12-31 Weihnachtsurlaub
Und warum kommt er trotzdem zu dem Schluss, dass rr_Michael_wakeuptimer2 der richtige ist, obwohl laut Log dieser ja eig. verworfen wurde?
RESIDENTStk rr_Michael: 07 - next wake-up result: tomorrow at 09:15:00, wakeupDevice=rr_Michael_wakeuptimer2
Ich hoffe ich habe das jetzt einigermaßen verständlich erklärt. Außerdem schalte ich jetzt mal ein FileLog für weitere Analysen auf den passenden Devices ein.
@Loredo: Sollte ich dir damit auf die Nerven gehen, dann sag es und ich bin in Zukunft ruhig.
Gruß Michael
Zitat von: l2r am 25 November 2016, 11:28:56
Der Wecker ist heute morgen durchgelaufen. Und wenn ich das richtig verstanden habe, dann wird sobald der Wecker gestartet wurde nextWakeup und nextWakeupDev für den nächsten Wecker gesetzt. Als ich vorhin in rr_Michael geschaut habe, standen die beiden Readings allerdings noch auf 07:00 Uhr für wochentags und rr_Michael_wakeuptimer1, obwohl sie eigentlich auf 09:15 und rr_Michael_wakeuptimer2 stehen sollten.
Ja, die Vorhersage wann das nächste Mal ausgelöst werden wird ist da etwas wackelig und ich hatte noch keine Zeit/Muße mich da nochmals reinzudenken (der Code für Vorhersage und während der tatsächlichen Ausführung sind getrennt).
Das ist aber auch nur halb tragisch, denn es ist wie gesagt nur eine Vorhersage und zum Zeitpunkt des tatsächlichen Auslösens werden die Parameter korrekt beachtet. Es ist also derzeit mehr ein Schönheitsfehler, wenn man den Wert nicht gerade abends zur Ansage der nächsten Weckzeit über Sonos verwendet (so wie ich). Wenn man den Wecker übrigens neu stellt (auch auf die selbe Zeit), dann ist die Berechnung korrekt. Das tritt also aktuell nur so auf, wenn der Wecker nach beenden eines Zyklus die Voraussage gesetzt hat. Vermutlich ist es deshalb auch nur ein Timer-Problem, dass die Berechnung erst angeworfen werden kann, wenn der letzte Zyklus beendet wurde und das in der Reihenfolge im Code nicht ganz passt. Aber wie gesagt, die Muße war bisher dazu nicht da und du bist der erste, dem es auffällt :-)
Zitat von: l2r am 25 November 2016, 11:28:56
beim durchsehen der Logs ist mir folgende Zeile aufgefallen als rr_Michael_wakeuptimer2 ausgewertet wurde:
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 05 - until now, will be NEXT WAKE-UP RUN tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)
Dieses Finding ist in der Tat bemerkenswert, aber so konkret kann ich spontan da auch nichts drauf antworten.
Zitat von: Loredo am 25 November 2016, 12:14:33
Es ist also derzeit mehr ein Schönheitsfehler, wenn man den Wert nicht gerade abends zur Ansage der nächsten Weckzeit über Sonos verwendet (so wie ich).
Bei mir ist es ein Push mit der nächsten Weckerzeit, Sonos ist in Planung. Aber dann müsstest du das Problem ja auch haben?
Zitat von: Loredo am 25 November 2016, 12:14:33
Wenn man den Wecker übrigens neu stellt (auch auf die selbe Zeit), dann ist die Berechnung korrekt. Das tritt also aktuell nur so auf, wenn der Wecker nach beenden eines Zyklus die Voraussage gesetzt hat.
Kann ich auch so bestätigen. Falsch geweckt wurde ich noch nicht;)
Gruß Michael
Ich habe gerade mal mein Wecker für die Wochentage auf heute 18:00h gestellt. 17 Min offset.
Somit ist um 17:43 der wakeuptimer gestartet.
2016-11-25_17:43:21 rr_Michael nextWakeupDev: rr_Michael_wakeuptimer1
2016-11-25_17:43:21 rr_Michael nextWakeup: 18:00
2016-11-25_17:43:21 at_rr_Michael_wakeuptimer1 Next: 06:43:00
2016-11-25_17:43:21 rr_Michael nextWakeupDev: rr_Michael_wakeuptimer2
2016-11-25_17:43:21 rr_Michael nextWakeup: 09:15
Also das sieht so aus, dass die Prozedur zum setzten von nextWakeupDev und von dem Timer 2 mal aufgerufen wird. Am Ende, nachdem der Wecker durchgelaufen ist, wird die Prozedur wieder 2 mal ausgeführt:
2016-11-25_18:00:22 rr_Michael nextWakeupDev: rr_Michael_wakeuptimer2
2016-11-25_18:00:22 rr_Michael nextWakeup: 09:15
2016-11-25_18:00:22 rr_Michael nextWakeupDev: rr_Michael_wakeuptimer2
2016-11-25_18:00:22 rr_Michael nextWakeup: 09:15
Also jetzt scheint alles zu laufen. Bleibt die Frage, warum das heute morgen nicht der Fall war und warum die Prozedur 2Mal 2Mal ausgeführt wird.
Gruß Michael
Ich hab da nochma ne Frage, ich hab ein ROOMMATE Device für meine Frau und ein GEOFANCY Device. Das presence, state und location reading werden auch auf present, home und home bei betreten der Home Zone gesetzt, bei verlassen werden presence und state ebenfalls korrekt auf absent gesetzt, nur die location bleibt auf home stehn. Setze ich den Status manuell auf absent wird auch location auf underway gesetzt. Jetzt ist die frage wo liegt da das Problem? Bekomm ich das selbst gefixt oder ist das ein Modul Problem?
Works as designed/ intended. Die Adresse aus GEOFANCY bleibt absichtlich erhalten, um den letzten bekannten Aufenthaltsort zu erinnern. Die Unterscheidung ob man dort noch anwesend ist oder es die zuletzt bekannte Stelle ist macht das Reading locationPresence.
Gruß
Julian
ok, aber dann versteh ich nicht warum dort Underway steht wenn ich den Status manuell auf absent setze und wo dann der Unterschied zwischen location / lastLocation ist. Doof ist halt auch das bei andFhem aufm Handy in der Übersicht die Location angezeigt wird und die ja dann bei verlassen durch geofancy die "falsche" Location enthält. Jemand eine Idee wie ich das dann am besten Löse?
Hallo,
ich habe auch seit längerem das Problem, dass der Status der Roommates nicht mehr gewechselt wird. Habe Geofancy eingerichtet, da funktioniert die Erkennung bzw. der Wechsel des Standortes ohne Probleme. Ich habe auch schon geofancy und Resident gelöscht und komplett neu eingerichtet. Aber es bleibt immer bei present=home.
Habe mal ein List von meinem Residentsmodul angehängt, vielleicht hilft das??
ZitatInternals:
CFGFN
CHANGED
NAME Bielefeld
NR 242
NTFY_ORDER 50-Bielefeld
ROOMMATES rr_Tom
STATE home
TYPE RESIDENTS
Readings:
2016-12-13 11:26:10 lastActivity home
2016-12-13 11:26:10 lastActivityBy Tom
2016-12-13 11:26:10 lastActivityByDev rr_Tom
2016-12-13 11:26:10 lastArrival 2016-12-13 11:26:10
2016-12-13 11:26:10 lastState initialized
2016-12-13 11:26:10 presence present
2016-12-13 11:26:10 residentsAbsent 0
2016-12-13 11:26:10 residentsAbsentDevs -
2016-12-13 11:26:10 residentsAbsentNames -
2016-12-13 11:26:10 residentsAsleep 0
2016-12-13 11:26:10 residentsAsleepDevs -
2016-12-13 11:26:10 residentsAsleepNames -
2016-12-13 11:26:10 residentsAwoken 0
2016-12-13 11:26:10 residentsAwokenDevs -
2016-12-13 11:26:10 residentsAwokenNames -
2016-12-13 11:26:10 residentsGone 0
2016-12-13 11:26:10 residentsGoneDevs -
2016-12-13 11:26:10 residentsGoneNames -
2016-12-13 11:26:10 residentsGotosleep 0
2016-12-13 11:26:10 residentsGotosleepDevs -
2016-12-13 11:26:10 residentsGotosleepNames -
2016-12-13 11:26:10 residentsHome 1
2016-12-13 11:26:10 residentsHomeDevs rr_Tom
2016-12-13 11:26:10 residentsHomeNames Tom
2016-12-13 11:26:10 residentsTotal 1
2016-12-13 11:26:10 residentsTotalAbsent 0
2016-12-13 11:26:10 residentsTotalAbsentDevs -
2016-12-13 11:26:10 residentsTotalAbsentNames -
2016-12-13 11:26:10 residentsTotalGuests 0
2016-12-13 11:26:10 residentsTotalGuestsAbsent 0
2016-12-13 11:26:10 residentsTotalGuestsAbsentDevs -
2016-12-13 11:26:10 residentsTotalGuestsAbsentNames -
2016-12-13 11:26:10 residentsTotalGuestsPresent 0
2016-12-13 11:26:10 residentsTotalGuestsPresentDevs -
2016-12-13 11:26:10 residentsTotalGuestsPresentNames -
2016-12-13 11:26:10 residentsTotalPresent 1
2016-12-13 11:26:10 residentsTotalPresentDevs rr_Tom
2016-12-13 11:26:10 residentsTotalPresentNames Tom
2016-12-13 11:26:10 residentsTotalRoommates 1
2016-12-13 11:26:10 residentsTotalRoommatesAbsent 0
2016-12-13 11:26:10 residentsTotalRoommatesAbsentDevs -
2016-12-13 11:26:10 residentsTotalRoommatesAbsentNames -
2016-12-13 11:26:10 residentsTotalRoommatesPresent 1
2016-12-13 11:26:10 residentsTotalRoommatesPresentDevs rr_Tom
2016-12-13 11:26:10 residentsTotalRoommatesPresentNames Tom
2016-12-13 11:26:10 residentsTotalWakeup 0
2016-12-13 11:26:10 residentsTotalWakeupDevs -
2016-12-13 11:26:10 residentsTotalWakeupNames -
2016-12-13 11:26:10 residentsTotalWayhome 0
2016-12-13 11:26:10 residentsTotalWayhomeDelayed 0
2016-12-13 11:26:10 residentsTotalWayhomeDelayedDevs -
2016-12-13 11:26:10 residentsTotalWayhomeDelayedNames -
2016-12-13 11:26:10 residentsTotalWayhomeDevs -
2016-12-13 11:26:10 residentsTotalWayhomeNames -
2016-12-13 11:26:10 state home
Attributes:
alias Residents
devStateIcon .*home:status_available:absent .*absent:status_away_1:home .*gone:status_standby:home .*none:control_building_empty .*gotosleep:status_night:asleep .*asleep:status_night:awoken .*awoken:status_available:home .*:user_unknown:home
group Home State
icon control_building_filled
room Residents
webCmd state
Leider habe ich echt keine Plan was das falsch läuft. Eine Suche hier im Forum hat für mich auch keine wirkliche Lösung aufgezeigt...
Vielen Dank für die Hilfe
Gruß Thommy
Es besteht derzeit noch die Abhängigkeit, dass die Reihenfolge in der fhem.cfg Datei so lauten müssen: Erst das RESIDENTS Device, dann die ROOMMATE Devices.
Bei dir sieht man jedoch am INTERNAL "ROOMMATES", dass rr_Tom erfolgreich erkannt wurde und somit berücksichtigt wird.
Ich kann an den Readings jetzt nicht erkennen, dass nicht alle korrekt aktualisiert würden, denn sie haben alle den gleichen Zeitstempel.
Ansonsten bitte beachten, dass es keinen Sinn macht die Events mittels event-on-* Attributen einzuschränken. Sie werden benötigt, damit die Updates richtig übermittelt werden und wenn man die falschen Events abdreht, geht es eben nicht mehr.
Zitat von: Loredo am 13 Dezember 2016, 12:01:20
Es besteht derzeit noch die Abhängigkeit, dass die Reihenfolge in der fhem.cfg Datei so lauten müssen: Erst das RESIDENTS Device, dann die ROOMMATE Devices.
Bei dir sieht man jedoch am INTERNAL "ROOMMATES", dass rr_Tom erfolgreich erkannt wurde und somit berücksichtigt wird.
Ich kann an den Readings jetzt nicht erkennen, dass nicht alle korrekt aktualisiert würden, denn sie haben alle den gleichen Zeitstempel.
Ansonsten bitte beachten, dass es keinen Sinn macht die Events mittels event-on-* Attributen einzuschränken. Sie werden benötigt, damit die Updates richtig übermittelt werden und wenn man die falschen Events abdreht, geht es eben nicht mehr.
Danke Loredo für Deine Hilfe.
Ich habe jetzt Geofancy, Residents und Roommates frisch eingepflegt. Habe auch darauf geachtet, dass zuerst Residents und dann Roommates in der fhem.cfg kommt. Leider passiert aber nichts...
Als ich das erste Mal Residents aktiviert habe, so vor ca. 10 Monaten, lief es auch ohne Probleme. Alles strikt nach Wiki eingerichtet!
Nur von jetzt auf gleich funktioniert es nicht mehr. Habe auch schon ein frisches FHEM versucht....
Hmm, was würdest du denn noch benötigen, um evtl einen Blick auf meine Config zu werfen? Vielleicht siehst Du ja was??
Gruß Thommy
Nachtrag: Keine Ahnung wieso und warum, aber jetzt läuft es wieder!? Komisch, komisch....
Hallo,
ich habe alles wie im Beispiel der Weckautomation im WIKI beschrieben ist installiert. Alles funktioniert auch wie es sein soll und ich will nun immer mehr Dinge dazu bauen. Daher habe ich 2 Fragen:
1. Kann man in das Macro auch Code schreiben wie in einem DOIF ? Ich möchte z.B. gerne realisieren das Licht angeschaltet wird, aber nur wenn ein bestimmter LUX Wert von der Wetterstation unterschritten ist. Ich hab noch nicht ganz verstanden wie da dann der Code aufgebaut werden müsste ?
2. Gibt es eine geschickte Lösung Sonos einen Sleeptimer zu verpassen ? Nicht nur das die Box im Schlafzimmer nach XY aus geht, sondern das z.B. alle 3 Minuten die Lautstärke langsam runtergefahren wird, bis es dann ganz auf NULL ist ? So eine Art Fading über einen gewissen Zeitraum ? Sicherlich kann man das mit "Setze Lautstärke auf XY" und dann sleep 3 Minuten und den Befehl noch mal usw. Aber gibt es eine bessere Lösung ?
Ich wünsche einen guten Rutsch.
Visionsurfer
Hallo,
ich habe noch eine Frage an der ich gerade hänge.
Gibt es eine einfache Möglichkeit die Macros, also die Notifys und Watchdogs für die anderen Statusse zu installieren ? Also kann man die vorhandenen Beispiele irgendwie kopieren und umbennen ?
Ich würde gerne auch gone und absent einbauen, bzw. ein Notify Macro haben wollen. Muss ich das alles von Hand anlegen ? Oder gibt es eine andere Möglichkeit ?
Grüße,
Visionsurfer
einfach kopieren und anpassen
copy macro_absent macro_asleep
und dann den kopf des Notifys anpassen und bei den watchdogs genau das selbe
Hallo,
ist hier jemand der sich mit SONOS auskennt ?
Ich nutze aus den Macros die Beispiele und wollte auch mein Sonos einbauen.
Ich habe aus dem Macro folgende Code aktiviert, bzw. mit meinem Geräten umgeschrieben:
## Stop playback bedroom's Sonos device might be involved in
fhem "set Sonos_Schlafzimmer:transportState=PLAYING stop;";
## Make Bedroom's and Bathroom's Sonos devices a single device
## and do not touch other Sonos devices (this is why we use RemoveMember!)
fhem "sleep 10; set Sonos_Schlafzimmer RemoveMember Sonos_Schlafzimmer";
fhem "sleep 11; set Sonos_Bad RemoveMember Sonos_Bad";
## Group Bedroom's and Bathroom's Sonos devices with Bedroom as master
fhem "sleep 12; set Sonos_Bad AddMember Sonos_Schlafzimmer; set Sonos_Schlafzimmer:FILTER=Shuffle!=1 Shuffle 1; set Sonos_Schlafzimmer,Sonos_Bad:FILTER=Volume!=12 Volume 12";
## Start music from playlist
fhem "sleep 13; set Sonos_Schlafzimmer StartPlaylist Abendentspannung";
Wenn ich nun den Status aktiviere, fängt meine Sonos im Schlafzimmer auch an zu spielen. Nur meine Sonos im Bad bleibt ruhig.
Ist an dem Code was falsch ? Weil die sollen doch eigentlich gekoppelt werden und dann beide spielen, oder nicht ?
Grüße,
Visionsurfer
Kommt mir komisch vor
set Sonos_Schlafzimmer,Sonos_Bad:FILTER=Volume!=12 Volume 12"
set (Sonos_Schlafzimmer,Sonos_Bad):FILTER=Volume!=12 Volume 12"
Wenn dann so
ok. Muss ich probieren.
So steht es halt im mitgeliefertem Beispiel Macro :)
Ich denke Loredo ist wahrscheinlich im Winterurlaub :)
Grüße,
Visionsurfer
Das oder arbeiten. Julian hat meist nur am WE wirklich Zeit.
@Visionsurfer
Dreh das mal um:
set Sonos_Bad AddMember Sonos_Schlafzimmer
in:
set Sonos_Schlafzimmer AddMember Sonos_Bad
Dann sollte es klappen.
Du gibst ja in deinem Code an dass die Sonos im Bad das Haupgerät ist und gibst weiter unten an dass die Sonos im Schlafzimmer Musik abspielen soll.
Gruß Cobra
Zitat von: visionsurfer am 31 Dezember 2016, 17:49:03
1. Kann man in das Macro auch Code schreiben wie in einem DOIF ? Ich möchte z.B. gerne realisieren das Licht angeschaltet wird, aber nur wenn ein bestimmter LUX Wert von der Wetterstation unterschritten ist. Ich hab noch nicht ganz verstanden wie da dann der Code aufgebaut werden müsste ?
Wie man sieht sind die Macros einfach Devices vom Typ "notify". Es gilt also alles, was für das Notify Modul gilt. Die DOIF Notation wird darin nicht unterstützt.
Die Beispiel Macros sind in reinem Perl geschrieben. DOIF hat IMHO keinen Macro Modus, der mit Notify vergleichbar wäre.
Zitat von: CoolTux am 02 Januar 2017, 22:36:02einfach kopieren und anpassen
So ist es gedacht. Alles FHEM 1x1 und Boardmittel.
Zitat von: CoolTux am 03 Januar 2017, 16:30:51
Kommt mir komisch vor
set Sonos_Schlafzimmer,Sonos_Bad:FILTER=Volume!=12 Volume 12"
set (Sonos_Schlafzimmer,Sonos_Bad):FILTER=Volume!=12 Volume 12"
Wenn dann so
Nee, geht auch nicht. :FILTER muss für jedes Device separat gesetzt werden, habe das im Beispielcode gerade korrigiert.
Dennoch ist das nicht tragisch, der Befehl wird halt nur ggf. unnötigerweise geschickt und hat mit sonstigen Schwierigkeiten dann nichts zu tun.
Zitat von: Cobra am 03 Januar 2017, 23:18:22
@Visionsurfer
Dreh das mal um:
set Sonos_Bad AddMember Sonos_Schlafzimmer
in:
set Sonos_Schlafzimmer AddMember Sonos_Bad
Dann sollte es klappen.
Du gibst ja in deinem Code an dass die Sonos im Bad das Haupgerät ist und gibst weiter unten an dass die Sonos im Schlafzimmer Musik abspielen soll.
Exakt, auch meine Vermutung. Ansonsten mal Reinerlein in einem separaten Thread zu seinem SONOS Modul befragen.
Hey,
Danke für eure Hilfe. Mit dem umdrehen funktioniert es nun wunderbar. So wie gewünscht. Man es wird immer geiler bei mir :)
Jetzt muss ich die Macros noch kopieren für absend und home und dann kann ich weiter basteln.
Tausend Dank.
Grüße,
Visionsurfer
Ich habe gerade eine aktualisierte Version von ROOMMATE und GUEST eingecheckt.
Über das neue Attribut r*_presenceDevices kann man jetzt ähnlich wie mit r*_geofenceUUIDs vereinfacht auf andere FHEM Geräte verweisen, die einen Wechsel absent->home oder home->absent auslösen. Es können auch mehrere Devices mit Komma getrennt angegeben werden. Erst wenn alle Geräte den selben Status haben wird der Status auch in ROOMMATE/GUEST übernommen. Das ganze funktioniert mit jedem FHEM Device, welches entweder ein Reading "presence" oder "state" mit dem folgenden Status hat:
absent ODER disappeared ODER unavailable
present ODER appeared ODER available
Ein Beispiel dafür ist der Einsatz zusammen mit dem PRESENCE Modul.
Wie immer ab morgen per Update verfügbar.
Hallo zusammen,
habe gerade gestern begonnen, das residents Modul einzurichten und bin ganz begeistert. Mit der letzten Änderung kann ich mir dann auch das notify meines G-Tags sparen - echt genial.
Beim wakeuptimer habe ich aber das Problem, dass ich auch Zeiten wie z.B. 04:20 Uhr bräuchte. Soweit ich mich jetzt durch die Doku und das Forum gesucht habe, finde ich aber nicht zu beliebigen Weckzeiten oder einem Art Offset zu den "festen" Zeiten.
Sehe ich das richtig, dass ich dann im wakeup-Device setlist bzw. das userattr wakeupdefaulttime ändern muss? Übersteht so eine Änderung ein Update des Moduls? Könnte man auch das neue DateTimePicker Widget zum Einstellen der Uhrzeit verwenden?
Beste Grüße
Torsten
Zitat von: ToKa am 10 Januar 2017, 20:05:14
Sehe ich das richtig, dass ich dann im wakeup-Device setlist bzw. das userattr wakeupdefaulttime ändern muss? Übersteht so eine Änderung ein Update des Moduls?
Es ist vorgesehen setlist abzuändern. userattr wird bei einem Neustart wieder neu gesetzt.
Zitat von: ToKa am 10 Januar 2017, 20:05:14
Könnte man auch das neue DateTimePicker Widget zum Einstellen der Uhrzeit verwenden?
Das kommt darauf an, ob du das Dummy Device entsprechend umgebogen bekommst, so dass hinterher trotzdem das Uhrzeitformat 12:00 erhalten bleibt.
Zitatuserattr wird bei einem Neustart wieder neu gesetzt.
Bedeutet also, dass man wakeupDefaultTime nicht beliebig setzen kann? Oder wie verhält sich der Wecker, wenn man mit dem attr Befehl wakeupDefaultTime auf einen beliebigen Wert setzt?
Doch selbstverständlich. setlist ist rein optisch für FHEMWEB und komplett unabhängig, genauso wie wakeupDefaultTime.
Gruß
Julian
@Loredo: Ich hab nur eine rein informative Frage. Hattest du dir bei dem Update auch das Timingproblem bei der Vorhersage von NextWakeUp angeschaut?
Aktuell behelfe ich mir, indem ich beim asleep-Makro die Funktion RESIDENTStk_wakeupGetNext(<ROOMMATE>) aufrufe und damit die Variablen nextWakeupDev und nextWakeup belege und bei der Durchsage nutze. Seit dem habe ich keine falschen Zeiten mehr angesagt bekommen.
Besten Dank für deinen tolle Arbeit und noch einen schönen Abend!
Gruß Michael
Zitat von: Loredo am 10 Januar 2017, 18:28:06
Ich habe gerade eine aktualisierte Version von ROOMMATE und GUEST eingecheckt.
Über das neue Attribut r*_presenceDevices kann man jetzt ähnlich wie mit r*_geofenceUUIDs vereinfacht auf andere FHEM Geräte verweisen, die einen Wechsel absent->home oder home->absent auslösen. Es können auch mehrere Devices mit Komma getrennt angegeben werden. Erst wenn alle Geräte den selben Status haben wird der Status auch in ROOMMATE/GUEST übernommen. Das ganze funktioniert mit jedem FHEM Device, welches entweder ein Reading "presence" oder "state" mit dem folgenden Status hat:
absent ODER disappeared ODER unavailable
present ODER appeared ODER available
Ein Beispiel dafür ist der Einsatz zusammen mit dem PRESENCE Modul.
Wie immer ab morgen per Update verfügbar.
Hi Loredo, danke für diese Vereinfachung. Gefällt mir sehr gut.
Ich hatte sonst immer ein DOIF dazwischen. Hatte dann aber auch die Möglichkeit ein paar weitere Bedingungen einzubauen.
So habe ich (ganz individuell) eine Statusänderung durch Presence nur von 10:00 bis 22:00 Uhr zugelassen, da außerhalb des Zeitraum ja theoretisch die Handys auch ausgeschaltet sein können. Dann wären die Bewohne absent, obwohl die ruhig im Bett liegen. Wenn ich deine "Abkürzung" nutze, dann kann ich dies nicht mehr steuern, oder?
Weiterhin habe ich auch manuell "gotosleep" gesetzt, wenn gewissen Kriterien zutrafen (Licht aus, Rolladen runter, etc.).
Zitat von: FunkOdyssey am 11 Januar 2017, 09:52:07
Ich hatte sonst immer ein DOIF dazwischen. Hatte dann aber auch die Möglichkeit ein paar weitere Bedingungen einzubauen.
So habe ich (ganz individuell) eine Statusänderung durch Presence nur von 10:00 bis 22:00 Uhr zugelassen, da außerhalb des Zeitraum ja theoretisch die Handys auch ausgeschaltet sein können. Dann wären die Bewohne absent, obwohl die ruhig im Bett liegen. Wenn ich deine "Abkürzung" nutze, dann kann ich dies nicht mehr steuern, oder?
Nein. Für solch außergewöhnliche Anwendungsfälle ist die Vereinfachung nicht gedacht. Es kann aber weiterhin DOIF, Notify etc. statt dem Attribut genutzt werden. Daran ändert sich nichts.
Zitat von: l2r am 10 Januar 2017, 22:01:27
@Loredo: Ich hab nur eine rein informative Frage. Hattest du dir bei dem Update auch das Timingproblem bei der Vorhersage von NextWakeUp angeschaut?
Nein, dafür war und ist keine Zeit.
Zitat von: Loredo am 10 Januar 2017, 18:28:06
Ich habe gerade eine aktualisierte Version von ROOMMATE und GUEST eingecheckt.
Über das neue Attribut r*_presenceDevices kann man jetzt ähnlich wie mit r*_geofenceUUIDs vereinfacht auf andere FHEM Geräte verweisen, die einen Wechsel absent->home oder home->absent auslösen. Es können auch mehrere Devices mit Komma getrennt angegeben werden. Erst wenn alle Geräte den selben Status haben wird der Status auch in ROOMMATE/GUEST übernommen. Das ganze funktioniert mit jedem FHEM Device, welches entweder ein Reading "presence" oder "state" mit dem folgenden Status hat:
absent ODER disappeared ODER unavailable
present ODER appeared ODER available
Ein Beispiel dafür ist der Einsatz zusammen mit dem PRESENCE Modul.
Wie immer ab morgen per Update verfügbar.
Hallo Julian,
Wird hier auf beides getriggert? Sowohl dem Reading presence als auch dem Reading state. Ich habe es eben mal kurz mit dem Reading presence ausprobiert, da hat es leider nicht geklappt. Habe jetzt mal auf state umgestellt. Mal schauen.
Ach so, umstellen heißt das ich event-on-change-reading state jetzt stehen habe, hatte da vorher presence stehe.
Grüße
Leon
Zitat von: CoolTux am 11 Januar 2017, 13:40:04
Wird hier auf beides getriggert? Sowohl dem Reading presence als auch dem Reading state. Ich habe es eben mal kurz mit dem Reading presence ausprobiert, da hat es leider nicht geklappt. Habe jetzt mal auf state umgestellt. Mal schauen.
Es wird zunächst auf das Vorhandensein von presence geprüft und ansonsten auf state.
Zitat von: CoolTux am 11 Januar 2017, 13:40:04
Ach so, umstellen heißt das ich event-on-change-reading state jetzt stehen habe, hatte da vorher presence stehe.
Beim angegebenen FHEM-Drittgerät nehme ich an, bei ROOMMATE macht es wenig Sinn ;-)
Hallo Julian
event-on-change-reading beim presence Device meine ich. Auch bei state hatte ich kein Erfolg. Das Reading im presence Device wird korrekt geändert aber das rommate Device stellt sich nicht um.
Internals:
CFGFN
CHANGED
DEF AnniKraussStr,Eltern
NAME rr_Marko
NR 16
NTFY_ORDER 50-rr_Marko
RESIDENTGROUPS AnniKraussStr,Eltern,
STATE home
TYPE ROOMMATE
Helper:
Dblog:
Presence:
Logdb:
TIME 1484148504.74305
VALUE present
Readings:
2017-01-11 16:28:24 durTimerAbsence 00:00:00
2017-01-11 16:28:24 durTimerAbsence_cr 0
2017-01-11 19:38:25 durTimerPresence 03:10:01
2017-01-11 19:38:25 durTimerPresence_cr 190
2017-01-11 07:02:02 durTimerSleep 00:00:00
2017-01-11 07:02:02 durTimerSleep_cr 0
2017-01-11 16:28:24 lastArrival 2017-01-11 16:28:24
2017-01-11 07:02:02 lastAwake 2017-01-11 07:02:02
2017-01-11 13:26:32 lastDeparture 2017-01-11 13:26:32
2017-01-11 16:28:24 lastDurAbsence 03:01:52
2017-01-11 16:28:24 lastDurAbsence_cr 182
2017-01-11 13:26:32 lastDurPresence 03:45:15
2017-01-11 13:26:32 lastDurPresence_cr 225
2017-01-11 07:02:02 lastDurSleep 08:22:13
2017-01-11 07:02:02 lastDurSleep_cr 502
2017-01-11 13:26:32 lastLocation home
2017-01-11 13:26:32 lastMood calm
2017-01-10 22:39:49 lastSleep 2017-01-10 22:39:49
2017-01-11 16:28:24 lastState absent
2017-01-11 06:00:01 lastWakeup 07:00
2017-01-11 06:00:01 lastWakeupDev rr_Marko_wakeuptimer1
2017-01-11 16:28:24 location home
2017-01-11 16:28:24 mood calm
2017-01-11 07:00:04 nextWakeup 07:00
2017-01-11 07:00:04 nextWakeupDev rr_Marko_wakeuptimer1
2017-01-11 16:28:24 presence present
2016-04-21 07:34:58 pushDev nexus5-marko
2017-01-11 16:28:24 state home
2017-01-11 07:00:04 wakeup 0
2016-05-03 17:09:02 wayhome 0
Timer:
Rr_marko_durationtimer:
HASH rr_Marko
MODIFIER DurationTimer
NAME rr_Marko_DurationTimer
Attributes:
alias Marko
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
event-on-change-reading state,userState,presence,wayhome,location
group Marko
icon people_sensor
room AnniKraussStr
rr_locations atwork,home,wayhome,underway
rr_presenceDevices presenceMarko
rr_realname group
rr_states home,gotosleep,asleep,awoken,absent,gone
rr_wakeupDevice rr_Marko_wakeuptimer1
sortby 0
webCmd state
Internals:
ADDRESS 7C:2F:80:98:B8:3D
CFGFN
CHANGED
DEF lan-bluetooth TAG-MAC IP-ADRESSE:5333 10 60
DeviceName 10.6.6.20:5333
FD 24
MODE lan-bluetooth
NAME presenceMarko
NOTIFYDEV global
NR 177
NTFY_ORDER 50-presenceMarko
PARTIAL
STATE present
TIMEOUT_NORMAL 10
TIMEOUT_PRESENT 60
TYPE PRESENCE
Helper:
Dblog:
Presence:
Logdb:
TIME 1484136534.11303
VALUE absent
Readings:
2017-01-11 17:14:44 command_accepted yes
2017-01-10 16:12:25 device_battery ok
2017-01-10 16:12:25 device_batteryLevel 26
2017-01-11 19:38:44 device_name Gigaset G-tag
2016-06-11 22:57:12 lastStatusRequestState statusRequest_done
2017-01-11 13:08:54 presence absent
2017-01-11 19:38:44 state present
Helper:
CURRENT_TIMEOUT present
Attributes:
absenceThreshold 36
alias G-tag
event-on-change-reading presence,device_battery,device_batteryLevel
group Marko
room AnniKraussStr
timestamp-on-change-reading presence
Hallo zusammen,
ich kann das Verhalten bestätigen. Leider wird beim roommate device der presence Wert nicht aus dem presence Device übernommen. Mit verbose 5 ist roommate leider auch nicht sehr gesprächig und es wird auch im Eventmonitor nichts ausgegeben.
Gruß
Torsten
Hier kein Problem. Das klappt einwandfrei. Habt ihr eventuell noch die ein oder anderen notify/DOIF Leiche, die den Status beeinflusst?
Das trat in Verbindung mit der gleichzeitigen Nutzung von Wakeuptimer auf. Habe gerade einen fix eingecheckt.
Hallo zusammen,
habe gerade mal getestet, ob man das DateTimePickerWidget für den wakeuptimer verwenden kann. Es funktioniert prima mit der aktuellen svn Version des Widgets. Als Einstellungen habe ich im setlist des wakeuptimer folgende Einstellungen vorgenommen:
nextRun:datetime,theme:default,datepicker:false,format:H:i,step:5
Gruß Torsten
Zitat von: Loredo am 11 Januar 2017, 20:52:40
Das trat in Verbindung mit der gleichzeitigen Nutzung von Wakeuptimer auf. Habe gerade einen fix eingecheckt.
Update gemacht und getestet. Funktioniert. Das ist eine super Idee gewesen Julian. Danke. Geht aber richtig sauber nur mit presence/absentsThreshold daher war es auch der richtige Zeitpunkt, vor einem halben Jahr hätte es noch kein Sinn gemacht.
Danke
Leon
Zitat von: CoolTux am 12 Januar 2017, 11:04:36
Geht aber richtig sauber nur mit presence/absentsThreshold daher war es auch der richtige Zeitpunkt, vor einem halben Jahr hätte es noch kein Sinn gemacht.
Ganze genau :-)
@Cooltux: sry, dass ich so doof nachfrage, Aber: presence/absentsThreshold ??? habe ich da was nicht auf dem Schirm oder im letzten halben Jahr nicht mitbekommen?
Gruß Michael
Siehe commandref zu PRESENCE.
jo .... man sollte auch bis zum Ende lesen ;D
Danke!
Ich habe noch einmal eine Frage:
Ich setze über ein DOIF das Roommate-Device manuell auf "gotosleep".
Nun dachte ich, dass durch das Einschalten des Handy (Presence-Device = present) das Roommate-Device auch wieder auf "present" gesetzt werden würde.
Leider ist dies nicht der Fall.
Ist das korrekt?
Sollte die Änderung im Presence-Device von "absent" zu "present" am frühen morgen das Roommate-Device nicht eigentlich wieder anpassen?
Oder muss ich das auch per DOIF nachkorrigieren?
Vielleicht hat ja jemand einen Tipp für mich. Danke.
grundsätzlich wird davon ausgegangen, dass du wenn du gotosleep bist auch gleichzeitig present bist. Da du durch ausschalten des Handys nicht auf absent gesetzt wirst, gehe ich davon aus, dass wenn du im Status gotosleep /asleep /awoken bist dein Presence-Status nicht aktualisiert wird?! oder habe ich da was falsch verstanden?
Gruß Michael
Zitat von: l2r am 13 Januar 2017, 14:44:48
grundsätzlich wird davon ausgegangen, dass du wenn du gotosleep bist auch gleichzeitig present bist. Da du durch ausschalten des Handys nicht auf absent gesetzt wirst, gehe ich davon aus, dass wenn du im Status gotosleep /asleep /awoken bist dein Presence-Status nicht aktualisiert wird?! oder habe ich da was falsch verstanden?
Gruß Michael
Das Problem Nr.1 ist, dass das Presence-Device den "rrBewohner:presence" auf "absent" wie auch "rrBewohner:state" auf "absent" setzt.
Und das obwohl ich daheim bin. Die Presence-Integration übernimmt ein wenig zu viele Einstellungen.
Die Reihenfolge:1)Bewohner daheim: state=home / presence=present
2)Handy aus: state=absent / presence=absent (grundsätzlich auch okay)
3)Dann folgt evtl. folgendes DOIF:
(
[rr_Bewohner:state] eq "absent" and
[rr_Bewohner:lastState] eq "home" and
[rr_Bewohner:lastState:sec] < 60 and
[23:00-09:00] and
[rolladen:level] < 15
)
(set rr_Bewohner state gotosleep)4)Am frühen morgen wir das Handy wieder eingeschaltet.
Das Presence-Device geht auf "present".
rrBewohner hat sich heute morgen jedoch nicht aktualisiert.
Ich habe nun einiges geändert und warte zu diesem Thema den morgigen Tag mal ab.
Am Rande:
Hat jemand einen Tipp, woran man zuverlässig erkennen kann, dass im Roommate-Device die Abwesenheit durch ein Presence-Device gesetzt wurde?
Wenn die Handys in der Nacht ausgeschaltet sind, werden die Roommates auf "absent" geschaltet. Dann setze ich unter Prüfung weitere Bedingungen (Licht aus, Jalousien runter, Türen zu) den "gotosleep"-Status. Jedoch könnte der Bewohner das Haus auch verlassen haben und über Geofancy auf "absent" gesetzt worden sein.
Ich suche also die Unterscheidung zwischen "absent" durch Presence oder "absent" durch Geofancy/manuell.
Zitat von: FunkOdyssey am 13 Januar 2017, 14:32:28
Leider ist dies nicht der Fall.
Ist das korrekt?
Ja. Diese Vereinfachung ist nur für einfache Anwendungsfälle gedacht, um die generelle Anwesenheit zu steuern. Deshalb wird ein Wechsel zwischen absent/present bei einem PRESENCE Device nur abhängig vom presence-Reading in ROOMMATE/GUEST weitergegeben. Stimmen die beiden Zustände bereits überein, passiert gar nichts.
Spezialfälle wie "ich schalte mein Handy aus und eigentlich bin ich aber noch zu Hause, das muss man sich aber denken und kann das nicht von normaler Abwesenheit unterscheiden" lassen sich mit keiner generellen Logik definieren, die auf alle passen würde. Dafür bleibt ja wie gehabt die Freiheit das flexibel über Notify und DOIF so zu definieren, wie man es haben möchte.
Zitat von: l2r am 13 Januar 2017, 14:44:48
grundsätzlich wird davon ausgegangen, dass du wenn du gotosleep bist auch gleichzeitig present bist.
Korrekt. Siehe auch das reading "presence" in einem ROOMMATE/GUEST Device.
Zitat von: l2r am 13 Januar 2017, 14:44:48
Da du durch ausschalten des Handys nicht auf absent gesetzt wirst
Bei Verwendung des r*_presenceDevices Attributs würde ein ROOMMATE/GUEST Device definitiv auch immer auf absent wechseln. Das ist so gewollt.
Wer sein Handy nachts so ausschaltet, dass es nicht mehr als Anwesenheitsindikator dienen kann, braucht mindestens einen anderen parallel dazu (mehrere PRESENCE Devices lassen sich ja im Attribut gemeinsam koppeln) oder muss sich generell eine andere Methode überlegen die Anwesenheit zu steuern (Bluetooth Beacons am Schlüsselbund, manuelle Schalter, etc.). Eine Kopplung mit GEOFANCY brächte hier keine Besserung, weil GEOFANCY rein eventbasiert arbeitet. Man kann zwar beides gemeinsam einsetzen, es schalten aber beide unabhängig voneinander den Status (wer zuerst An- oder Abwesenheit erkennt, schaltet diese dann).
Zitat von: FunkOdyssey am 13 Januar 2017, 15:07:05
Das Problem Nr.1 ist, dass das Presence-Device den "rrBewohner:presence" auf "absent" wie auch "rrBewohner:state" auf "absent" setzt.
Works as designed/intended.
Zitat von: FunkOdyssey am 13 Januar 2017, 15:07:05
Und das obwohl ich daheim bin. Die Presence-Integration übernimmt ein wenig zu viele Einstellungen.
Im Gegenteil, es wird nur ganz wenig übernommen. Ganz einfach gesprochen: Es wird nur der Status des einen presence-Readings in einem PRESENCE Device auf as Reading "presence" eines ROOMMATE/GUEST Devices übertragen. Anders ausgedrückt: Es wird das kommen und gehen übernommen, mehr nicht.
Ich glaube du verwendest die unterschiedlichen Status nicht so wie sie gedacht sind. In den Status "gotosleep" zu wechseln, indem man das Handy ausschaltet kann man zwar machen, ist aber doch IMHO höchst ungewöhnlich/eigensinnig (is dann eben halt Kacke ;) ).
Vorab erst einmal vielen Dank für die ausführliche Erklärung.
Ich werden die Vereinfachung dann bei mir besser wieder deaktivieren und zurück zu einem DOIF gehen.
Darüber steuere ich dann vollständig die Verknüpfung zwischen PRESENCE und ROOMMATE.
Damit kann ich leben. Ich wollte nur wissen, ob ich nicht beides nutzen könnte.
Danke dennoch.
Zitat von: Loredo am 13 Januar 2017, 15:24:24
Ich glaube du verwendest die unterschiedlichen Status nicht so wie sie gedacht sind. In den Status "gotosleep" zu wechseln, indem man das Handy ausschaltet kann man zwar machen, ist aber doch IMHO höchst ungewöhnlich/eigensinnig (is dann eben halt Kacke ;) ).
Okay, zugegeben. Erst einmal ist "gotosleep" vollkommen unsinnig, weil es eigentlich "asleep" sein sollte. Ich war halt zu faul, die anderen States über "r*_showAllStates" freizuschalten. :-)
Aber ansonsten verstehe ich deine Aussage nicht. Ist das nicht legitim, den Schlafensstatus über eigene Regeln zu setzen?
(Das DOIF überprüft in Wirklichkeit auch noch mehr Parameter).
Zitat von: FunkOdyssey am 13 Januar 2017, 15:07:05
Hat jemand einen Tipp, woran man zuverlässig erkennen kann, dass im Roommate-Device die Abwesenheit durch ein Presence-Device gesetzt wurde?
Derzeit nein, dafür wäre ein eigenes Reading erforderlich, bei dem ich aber irgendwie den Sinn und Zweck nicht ganz verstehen würde. Der Status wird ja 1-zu-1 ins ROOMMATE Device übernommen und der Sinn dahinter ist, dass du sämtliche Automationen dann nicht mehr von PRESENCE abhängig machst, sondern von ROOMMATE und RESIDENTS. Ansonsten erhältst du keinen Vorteil.
Zitat von: FunkOdyssey am 13 Januar 2017, 15:07:05
Wenn die Handys in der Nacht ausgeschaltet sind, werden die Roommates auf "absent" geschaltet. Dann setze ich unter Prüfung weitere Bedingungen (Licht aus, Jalousien runter, Türen zu) den "gotosleep"-Status.
Sowas macht man ja in der Regel eher abhängig von einem RESIDENTS Device und nicht einem einzelnen ROOMMATE. Dafür ist es da und es bietet auch Readings dafür, welches ROOMMATE Device zuletzt seinen Status geändert hat, um das z.B. in DOIF entsprechend mit auswerten zu können.
Zitat von: FunkOdyssey am 13 Januar 2017, 15:07:05
Ich suche also die Unterscheidung zwischen "absent" durch Presence oder "absent" durch Geofancy/manuell.
Hm, dafür ließe sich vielleicht ein zusätzliches Reading rechtfertigen. Ich baue das bei Gelegenheit mit ein und denke auch nochmal darüber nach, wie man ggf. sinnvoll beinflussen kann in welchen Status das ROOMMATE/GUEST Device bei present/absent eines PRESENCE Devices wechseln soll.
Zitat von: Loredo am 13 Januar 2017, 15:37:35
Sowas macht man ja in der Regel eher abhängig von einem RESIDENTS Device und nicht einem einzelnen ROOMMATE. Dafür ist es da und es bietet auch Readings dafür, welches ROOMMATE Device zuletzt seinen Status geändert hat, um das z.B. in DOIF entsprechend mit auswerten zu können.
Hier muss ich noch einmal nachkorrigieren.
Jeder Bewohner hat sein eigenes Handy. Ich habe vielleicht den Plural oben benutzt, aber jedes ausgeschaltete Handy schaltet das dazugehörige ROOMMATE-Device. Schlussendlich landen die Ergebnisse natürlich in RESIDENTS.
Zitat von: FunkOdyssey am 13 Januar 2017, 15:32:29
Okay, zugegeben. Erst einmal ist "gotosleep" vollkommen unsinnig, weil es eigentlich "asleep" sein sollte.
Nee, gar nicht. Es macht ja Sinn, wenn man sich auf den Weg ins Bett begibt und man entsprechend die Lichtstimmung anpassen will und TV aus, Schlummermusik im Bad einschalten etc.
Danach den Status auf "asleep" zu setzen ist dann auch richtig, z.B. über einen Schalter am Bett oder das ausschalten der Nachttischlampe (die man vorher bei "gotosleep" eingeschaltet hat ;) ).
Zitat von: FunkOdyssey am 13 Januar 2017, 15:32:29
Ich war halt zu faul, die anderen States über "r*_showAllStates" freizuschalten. :-)
Man muss da nix "freischalten", um diesen oder andere Status zu nutzen. Es geht dabei rein um die visuelle Einblendung in FHEMWEB; den Status kann man jederzeit und immer so setzen, wie man das will. "Show" in der Bezeichnung des Attributes ist also durchaus wörtlich zu nehmen.
"asleep" ist per Default ausgeblendet, weil der Standardprozess eigentlich ist, dass zunächst "gotosleep" ausgewählt werden sollte. Dann wird auch "asleep" in der Liste aufgeführt bzw. alternativ der Status über die Nutzung dev devStateIcons entsprechend zum nächsten Status gewechselt. Wer das anders möchte, kann r*_showAllStates verwenden und jemand, der FHEMWEB gar nicht benutzt, sondern z.B. TabletUI, muss gar nichts tun.
Zitat von: FunkOdyssey am 13 Januar 2017, 15:32:29
Aber ansonsten verstehe ich deine Aussage nicht. Ist das nicht legitim, den Schlafensstatus über eigene Regeln zu setzen?
(Das DOIF überprüft in Wirklichkeit auch noch mehr Parameter).
Doch natürlich. Wie man von einem Status in den anderen geht ist ganz egal und das Modul interessiert sich auch nicht dafür. Man kann auch jeden Status so nutzen, wie man ihn möchte.
Die einzige Abhängigkeit besteht zum Reading "presence", welches durch den Wechsel zu bestimmten Status eben dann auf "absent" oder "present" wechselt.
Man muss also unterscheiden zwischen dem Anwesenheitsstatus (im Reading "presence") und dem Aktivitätsstatus (im Reading "state"). Außerdem muss man sich bewusst machen, dass man nur den Aktivitätsstatus selbst setzt (oder mit Hilfe von GEOFANCY/PRESENCE) und davon dann indirekt der Anwesenheitsstatus von abgeleitet wird.
Wenn man das einmal verinnerlicht hat, ist es eigentlich ganz einfach.
In https://sourceforge.net/p/fhem/code/9978/ (https://sourceforge.net/p/fhem/code/9978/) steht:
ZitatRESIDENTStk.pm: make Wakeuptimer compatible with Tablet UI settimer widget:
<div data-type="settimer"
data-device="rr_Firstname_wakeuptimer1"
data-get="nextRun"
data-set="nextRun"></div>
Damit kann ich den Wecker grundsätzlich auch stellen, aber die eingestellte Zeit wird nicht angezeigt, insbesondere kommt beim Aufruf die Anzeige "NaN"
Auch wenn ich die Zeit in FHEM setze wird sie auf dem Tablet nicht aktualisiert - sollte ja aber sein, weil am nächsten Tag bei mir die Standard-Weckzeit wieder verwendet wird, wenn ich am Tag zuvor mal extra früher aufstehen musste.
Ungünstig ist auch, dass man nicht erkennen kann, ob der Wecker an oder aus ist. Vielleicht muss ich es doch anders lösen, aber das Widget schien so praktisch...
Ich habe immer die zulässigen Zeiten ("alle 15 Minuten") mit dem Widget eingestellt, wie ich ihm die unzulässigen abgewöhne muss ich noch herausfinden.
Zitat von: ujaudio am 24 Januar 2017, 21:57:36
Damit kann ich den Wecker grundsätzlich auch stellen, aber die eingestellte Zeit wird nicht angezeigt, insbesondere kommt beim Aufruf die Anzeige "NaN"
Für TabletUI kann hier keine Unterstützung gegeben werden, dafür solltest du hier (https://forum.fhem.de/index.php/board,71.0.html) einen separaten Thread starten. Deine Schwierigkeit hat nichts mit dieser Modulfamilie zu tun.
Zitat von: ujaudio am 24 Januar 2017, 21:57:36
Ich habe immer die zulässigen Zeiten ("alle 15 Minuten") mit dem Widget eingestellt, wie ich ihm die unzulässigen abgewöhne muss ich noch herausfinden.
Es kann jede beliebige Uhrzeit minutengenau gesetzt werden. Die 15min Abschnitte sind nur für die Anzeige in FHEMWEB so hinterlegt und können auch beliebig angepasst werden.
Zitat von: ujaudio am 24 Januar 2017, 21:57:36
In https://sourceforge.net/p/fhem/code/9978/ (https://sourceforge.net/p/fhem/code/9978/) steht:
Damit kann ich den Wecker grundsätzlich auch stellen, aber die eingestellte Zeit wird nicht angezeigt, insbesondere kommt beim Aufruf die Anzeige "NaN"
Auch wenn ich die Zeit in FHEM setze wird sie auf dem Tablet nicht aktualisiert - sollte ja aber sein, weil am nächsten Tag bei mir die Standard-Weckzeit wieder verwendet wird, wenn ich am Tag zuvor mal extra früher aufstehen musste.
Ungünstig ist auch, dass man nicht erkennen kann, ob der Wecker an oder aus ist. Vielleicht muss ich es doch anders lösen, aber das Widget schien so praktisch...
Ich habe immer die zulässigen Zeiten ("alle 15 Minuten") mit dem Widget eingestellt, wie ich ihm die unzulässigen abgewöhne muss ich noch herausfinden.
<div data-type="settimer" data-device="rr_Marko_wakeuptimer1"
data-get="nextRun"
data-set="nextRun"
data-off="OFF"
data-running-set-off="stop"
class="cell top-space">
</div>
Klappt ohne Probleme
Ich finde gerade irgendwie nicht was ich suche!
Gab es nicht mal eine Möglichkeit RESIDENTS auf Deutsch zu stellen, oder habe ich das nur geträumt?
Bin ich schon geistesgestört? ??? ??? ???
Danke.
Gruß
Dan
Die Vorlage dazu gibt es in GEOFANCY als Setter.
Gruß
Julian
Zitat von: Loredo am 27 Januar 2017, 17:33:06
Die Vorlage dazu gibt es in GEOFANCY als Setter.
Gruß
Julian
Ich benutze aber kein GEOFANCY und habe es auch noch nie benutzt!
Geht das noch woanders?
Danke.
Gruß
Dan
Jetzt sitze ich vorm Rechner.
Hier der Artikel, wie man generell Devices in Fhem übersetzen kann:
Frontend übersetzen mit widgetOverride und eventMap (am Beispiel ROOMMATE) (https://forum.fhem.de/index.php/topic,33613.0.html)
msgConfig hat einen Setter "createResidentsDev" (https://fhem.de/commandref.html#msgConfigset), der RESIDENTS Devices in Deutsch oder Englisch vorkonfiguriert.
Zitat von: Loredo am 28 Januar 2017, 15:51:10
Jetzt sitze ich vorm Rechner.
Hier der Artikel, wie man generell Devices in Fhem übersetzen kann:
Frontend übersetzen mit widgetOverride und eventMap (am Beispiel ROOMMATE) (https://forum.fhem.de/index.php/topic,33613.0.html)
msgConfig hat einen Setter "createResidentsDev" (https://fhem.de/commandref.html#msgConfigset), der RESIDENTS Devices in Deutsch oder Englisch vorkonfiguriert.
Danke Julian für die nachgereichte Info.
Ich hatte es zwischenzeitlich selbst in msgConfig wieder gefunden.
Irgendwo hatte ich es gesehen, wusste nur nicht mehr wo und fing an an mir selbst zu zweifeln. ::)
Gruß
Dan
Ich habe jetzt mal versucht, das Presence-Device direkt im ROOMMATE einzutragen und nicht mehr über Watchdog zu setzen. Leider funktioniert das nur unzuverlässig, da es immer wieder mal vorkommt, dass für kurze Zeit das Bluetooth-Signal abhanden kommt. Der Watchdog hat das kompensiert. Gibt es etwas ähnliches doch auch im ROOMMATE?
absenceThreshold im PRESENCE Device?
Gruß
Dan
Danke, man muss nur im richtigen Device schauen. :-[
Zitat von: volschin am 03 Februar 2017, 13:12:39
Danke, man muss nur im richtigen Device schauen. :-[
Macht aber auch nur da Sinn wenn man mal genau drüber nachdenkt. ;)
Gruß
Dan
hallo Julian,
ich habe vorhin versucht mit das Attribut wakeupOffset in meinen WakeupTimern zu ändern. Das ist ja ein Slider
Wenn ich den gewünschten Wert eingestellt habe und auf attr klicke, dann wird anstatt des eingestellten Wertes der String WakeupOffset bei dem Attribut eingetragen.
Kann das sonst noch jemand bestätigen?
über die Kommandozeile habe ich es dann manuell eingetragen.
Bei mir läuft FHEM 5.8
Gruß Michael
Das wäre ein genereller FHEM Bug.
Gruß
Julian
Ich habe gerade ein kleines Update eingecheckt. Damit spielt die Reihenfolge keine Rolle mehr, in der RESIDENT/ROOMMATE/GUEST Devices definiert werden.
Es sollte dabei eigentlich keine Verhaltensänderung auftreten. Falls doch, bitte hier melden.
Ich habe gleich noch einen weiteren Patch hinterher geschoben:
1. Das globale Attribut "language" wird jetzt berücksichtigt und neu angelegte Devices werden automatisch in deutscher Anzeigesprache vorkonfiguriert, wenn die Sprache entsprechend gesetzt ist
2. Mittels neuem Attribut r*_lang lässt sich die globale Spracheinstellung übersteuern und zwischen deutscher und englischer Anzeigesprache umschalten
3. Das Attribut "disable" wird unterstützt
4. Bei Verwendung der Attribute r*_autoGoneAfter oder r_noDuration wird der interne Timer jetzt gestoppt
hallo loredo,
könntest du bitte für RESIDENTS die gleichen durTimer.* readings einbauen wie für ROOMMATE?
ich bin gerade dabei in der willkommens nachricht beim tür öffnen mit anzusagen ob schon jemand anders zuhause ist. je nach dem wie schnell sich jemand genähert hat kann es aber sein das er schon im wlan eingebaucht ist und selber auf present springt bevor er die tür auf macht. ein einfacher vergleich auf durTimerPresence < 15 sekunden direkt auf das RESIDENTS device wäre deutlich einfacher als von hand alle ROOMMATEs durch zu gehen oder irgendwie anders selber zu zählen.
danke
andre
hi Loredo,
ich hab eine kleine Frage zu deinem DOIF. Und zwar verwendest du bei manchen msg-Befehlen ein ! hinter dem Empfänger
msg push @rgr_Residents! -1 |Anwesenheit| Längere Abwesenheit aller Bewohner registriert. Erweitere Sicherheitsprotokolle wurden etabliert.Was bewirkt das
! ?
Gruß Michael
Zitat von: Loredo am 14 November 2015, 15:32:17
Ich habe gerade folgendes DOIF bei mir im Test, welches auch zwischen Bewohnern und Gästen unterscheidet:
## ROOMMATE arrives at home
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
$devType eq "ROOMMATE" and
($lastState eq "absent" or $lastState eq "gone")
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:residentsTotalPresent] Bewohner zuhause: [rgr_Residents:residentsTotalPresentNames])
)
## ROOMMATE leaves home but residents are still present
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present" and
$devType eq "ROOMMATE"
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)
## ROOMMATE is absent for longer period but others are still nearby
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "gone" and
[?rgr_Residents:state] ne "gone"
)
(
(msg push @[rgr_Residents:lastActivityByDev]! -2 |Anwesenheit| Längere Abwesenheit für [rgr_Residents:lastActivityBy] wurde vermerkt.)
)
## all residents are absent for longer period
DOELSEIF
(
[rgr_Residents:?state] and
[?rgr_Residents:state] eq "gone"
)
(
(msg push @rgr_Residents! -1 |Anwesenheit| Längere Abwesenheit aller Bewohner registriert. Erweitere Sicherheitsprotokolle wurden etabliert.)
)
## ROOMMATE leaves home and all residents are absent now
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:state] eq "absent" and
$devType eq "ROOMMATE"
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. Alle Bewohner sind abwesend, Sicherheitsprotokolle wurden etabliert.)
)
## GUEST control enabled
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
(([?rgr_Residents:lastActivity] ne "absent" and [?rgr_Residents:residentsHome] > 1) or ([?rgr_Residents:lastActivity] eq "absent" and [?rgr_Residents:residentsHome] == 0)) and
$devType eq "GUEST" and
$lastState eq "none"
)
(
(msg push @rgr_Residents -1 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde aktiviert)
)
## GUEST control enabled while no resident present (EXCEPTION!)
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] ne "absent" and
[?rgr_Residents:residentsHome] == 1 and
$devType eq "GUEST" and
$lastState eq "none"
)
(
(msg push @rgr_Residents! 2 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde aktiviert, obwohl kein Bewohner zuhause ist!)
)
## GUEST control was disabled
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "none" and
[?rgr_Residents:state] ne "gone"
)
(
(msg push @rgr_Residents -1 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde deaktiviert)
)
## GUEST arrives at home while residents are present
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:residentsHome] > 1 and
$devType eq "GUEST" and
$lastState eq "absent"
)
(
(msg push @rgr_Residents -2 |Anwesenheit| [rgr_Residents:lastActivityBy] ist jetzt zuhause. Anwesende Bewohner: [rgr_Residents:residentsTotalPresentNames])
)
## GUEST arrives at home while he is the only one (EXCEPTION!)
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:residentsHome] == 1 and
$devType eq "GUEST" and
$lastState eq "absent"
)
(
(msg push @rgr_Residents! 2 |Anwesenheit| [rgr_Residents:lastActivityBy] ist jetzt alleine zuhause!)
)
## GUEST leaves home while others are still at home
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present" and
$devType eq "GUEST"
)
(
(msg push @rgr_Residents -2 |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)
## GUEST leaves home after all residents
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "absent" and
$devType eq "GUEST"
)
(
(msg push @rgr_Residents! |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. Alle Bewohner sind jetzt abwesend, Sicherheitsprotokolle werden etabliert.)
)
Ich habe an dem Attribut rr_presenceDevices meines ROOMATE eine PRESENCE Gerät verknüpft das über Events meines AccessPoints getriggert wird. Leider kommen die Änderungen vom PRESENCE Geräte nicht beim ROOMATE Geräte an. Liegt es daran das ich das PRESENCE über Events aktualisiere?
Zitat von: acw81 am 23 März 2017, 12:27:48
Ich habe an dem Attribut rr_presenceDevices meines ROOMATE eine PRESENCE Gerät verknüpft das über Events meines AccessPoints getriggert wird. Leider kommen die Änderungen vom PRESENCE Geräte nicht beim ROOMATE Geräte an. Liegt es daran das ich das PRESENCE über Events aktualisiere?
Bei mir funktioniert das in die andere Richtung. Ich habe ROOMMATES definiert, die durch Sensoren einen bestimmten Status erhalten (Tags, Bewegung, Strom usw.) und den Gesamtstatus der sich daraus ergibt, finde ich im PRESENCE. Nur wenn alle ROOMMATES auf absent geschaltet sind, dann springt PRESENCE auf absent, ansonsten steht es auf present.
Zitat von: mumpitzstuff am 24 März 2017, 15:46:07
Bei mir funktioniert das in die andere Richtung. Ich habe ROOMMATES definiert, die durch Sensoren einen bestimmten Status erhalten (Tags, Bewegung, Strom usw.) und den Gesamtstatus der sich daraus ergibt, finde ich im PRESENCE. Nur wenn alle ROOMMATES auf absent geschaltet sind, dann springt PRESENCE auf absent, ansonsten steht es auf present.
Verwechselst du PRESENCE und RESIDENTS?
Ups sry du hast natürlich recht. Ich nehme alles zurück.
Zitat von: acw81 am 23 März 2017, 12:27:48
Ich habe an dem Attribut rr_presenceDevices meines ROOMATE eine PRESENCE Gerät verknüpft das über Events meines AccessPoints getriggert wird. Leider kommen die Änderungen vom PRESENCE Geräte nicht beim ROOMATE Geräte an. Liegt es daran das ich das PRESENCE über Events aktualisiere?
Poste mal ein list des PRESENCE devices. Was genau meinst du mir "das PRESENCE über events aktualisieren"?
Zitat von: justme1968 am 20 März 2017, 13:43:35
könntest du bitte für RESIDENTS die gleichen durTimer.* readings einbauen wie für ROOMMATE?
Habe ich gerade eingebaut.
danke!
Zitat von: l2r am 22 März 2017, 10:33:56
ich hab eine kleine Frage zu deinem DOIF. Und zwar verwendest du bei manchen msg-Befehlen ein ! hinter dem Empfänger msg push @rgr_Residents! -1 |Anwesenheit| Längere Abwesenheit aller Bewohner registriert. Erweitere Sicherheitsprotokolle wurden etabliert.
Was bewirkt das ! ?
Das Ausrufezeichen bewirkt, dass trotz der niedrigen Priorität die Nachricht verschickt wird, obwohl die Bewohner abwesend sind. Normalerweise wird ansonsten die Nachricht bei Abwesenheit nicht zugestellt, wenn sie keine hohe Priorität hat.
Zitat von: acw81 am 23 März 2017, 12:27:48
Ich habe an dem Attribut rr_presenceDevices meines ROOMATE eine PRESENCE Gerät verknüpft das über Events meines AccessPoints getriggert wird. Leider kommen die Änderungen vom PRESENCE Geräte nicht beim ROOMATE Geräte an. Liegt es daran das ich das PRESENCE über Events aktualisiere?
Sofern du kein falsch definiertes event-on-* Attribut verwendest, ist das vermutlich der Fall und eine Schutzvorrichtung vor Loops von FHEM selbst.
@Loredo: Danke für die Aufklärung!
Hattest du auch noch an den WakeUpTimern rumgeschraubt?
Ich habe einen Wecker für Mo-FR außer Donnerstags um 7 Uhr. Der Wecker am Donnerstag steht auf 6 Uhr. Heute morgen, bin ich allerdings auch um 6 Uhr gewecket worden. An der Config habe ich nichts geändert und diese lief auch die letzte Zeit wunderbar. Gestern Abend beim zuBett gehen habe ich auch die Ansage bekommen, dass mein Wecker auf 7 Uhr steht.
Gruß Michael
Zitat von: KernSani am 24 März 2017, 18:28:18
Poste mal ein list des PRESENCE devices. Was genau meinst du mir "das PRESENCE über events aktualisieren"?
Internals:
DEF event ak_accesspoint:metal:.disconnected ak_accesspoint:metal:.connected
EVENT_ABSENT ak_accesspoint:metal:.disconnected
EVENT_PRESENT ak_accesspoint:metal:.connected
MODE event
NAME Andreas
NOTIFYDEV global,ak_accesspoint
NR 101
NTFY_ORDER 50-Andreas
STATE present
TYPE PRESENCE
Readings:
2017-03-27 20:07:45 presence present
2017-03-27 20:07:45 state present
Helper:
CURRENT_STATE present
Attributes:
devStateIcon Initialized:10px-kreis-rot absent:10px-kreis-rot present:10px-kreis-gruen
group Anwesenheit
icon it_smartphone
room Info
stateFormat presence
Das PRESENCE Gerät wird über die Events connected/disconnected von meinem Smartphone am AP aktualisiert ...
Hallo liebe Fhemler,
ich bin gerade dabei das Resident-Modul zu entdecken und schaue, was ich davon wie gebrauchen kann.
Jetzt bin ich dabei es auf dem Floorplan abzulegen und frage mich gerade wie ich die Dropdown-Menüs des ROOMMATE und der Wakeuptimer auf den Floorplan bekomme? Die Icons erscheinen dort, aber nicht die Dropdowns.
Ich hoffe, ich bin hier richtig und freue mich auf eure Hilfe.
Viele Grüße
bastelf(r)eak
EDIT: Habe es gefunden, eine Option im floorplan richtet es.
Zitat von: acw81 am 27 März 2017, 20:11:31
Internals:
DEF event ak_accesspoint:metal:.disconnected ak_accesspoint:metal:.connected
EVENT_ABSENT ak_accesspoint:metal:.disconnected
EVENT_PRESENT ak_accesspoint:metal:.connected
MODE event
NAME Andreas
NOTIFYDEV global,ak_accesspoint
NR 101
NTFY_ORDER 50-Andreas
STATE present
TYPE PRESENCE
Readings:
2017-03-27 20:07:45 presence present
2017-03-27 20:07:45 state present
Helper:
CURRENT_STATE present
Attributes:
devStateIcon Initialized:10px-kreis-rot absent:10px-kreis-rot present:10px-kreis-gruen
group Anwesenheit
icon it_smartphone
room Info
stateFormat presence
Das PRESENCE Gerät wird über die Events connected/disconnected von meinem Smartphone am AP aktualisiert ...
Ich habe gerade ein Update eingecheckt, damit du dir das PRESENCE Device sparen und direkt den AccessPoint als Quelle für die Präsenz angeben kannst.
Dem Attribut r*_presenceDevices kann dafür jetzt optional einen Readingnamen übergeben bekommen. In deinem Fall also:
attr rr_Bewohner1 rr_presenceDevices ak_accesspoint:metal
Gruß
Julian
Zitat von: Loredo am 28 März 2017, 13:42:58
Ich habe gerade ein Update eingecheckt, damit du dir das PRESENCE Device sparen und direkt den AccessPoint als Quelle für die Präsenz angeben kannst.
Dem Attribut r*_presenceDevices kann dafür jetzt optional einen Readingnamen übergeben bekommen. In deinem Fall also:
attr rr_Bewohner1 rr_presenceDevices ak_accesspoint:metal
@Loredo: Kann das funktionieren? Das reading ak_accesspoint:metal liefert doch nur connected und disconnected.
BTW, das ROOMMATE Gerät scheint nun zu funktionieren (zumindest mit meinem bisherigen PRESENCE Gerät). Ich glaube es lag daran, dass es noch keinen gültigen STATE gehabt hatte. Kann das sein?
Trotzdem vielen Dank für das neue Feature ...
Grüße Andreas
Zitat von: acw81 am 28 März 2017, 15:30:55
@Loredo: Kann das funktionieren? Das reading ak_accesspoint:metal liefert doch nur connected und disconnected.
Ja, die möglichen Values sind in ROOMMATE/GUEST bereits hinterlegt.
Zitat von: acw81 am 28 März 2017, 15:30:55
BTW, das ROOMMATE Gerät scheint nun zu funktionieren (zumindest mit meinem bisherigen PRESENCE Gerät). Ich glaube es lag daran, dass es noch keinen gültigen STATE gehabt hatte. Kann das sein?
Jaein, du meinst vermutlich das Reading state (STATE ist ein INTERNAL). Wenn also noch keine Veränderung deiner Anwesenheit ein Event ausgelöst hat, ändert sich auch das Reading nicht und solange kann auch keine andere Aktion erfolgen.
Hallo Loredo,
seit ein paar Tagen funktioniert mein Wecker nicht mehr, wurde hier etwas geändert?
Im Log steht folgendes:
2017.03.29 05:20:00.040 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.03.29 05:20:00.041 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=0
2017.03.29 05:20:00.042 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found
2017.03.29 05:20:00.042 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=05:20 wakeupOffset=30
2017.03.29 05:20:00.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today
2017.03.29 05:20:00.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2017.03.29 05:20:00.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 06 - won't be running today based on holiday decision (wakeupHolidays=andNoHoliday)
2017.03.29 05:20:00.044 4: RESIDENTStk rgr_Bewohner: 07 - next wake-up result: today at 05:50:00, wakeupDevice=rgr_Bewohner_wakeuptimer1
2017.03.29 05:20:00.072 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.03.29 05:20:00.072 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=0
2017.03.29 05:20:00.073 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found
2017.03.29 05:20:00.073 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=05:20 wakeupOffset=30
2017.03.29 05:20:00.074 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today
2017.03.29 05:20:00.074 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2017.03.29 05:20:00.074 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 06 - won't be running today based on holiday decision (wakeupHolidays=andNoHoliday)
2017.03.29 05:20:00.075 4: RESIDENTStk rgr_Bewohner: 07 - next wake-up result: today at 05:50:00, wakeupDevice=rgr_Bewohner_wakeuptimer1
So wie ich das verstehe startet der Wecker aufgrund des "holiday" checks nicht:
2017.03.29 05:20:00.074 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 06 - won't be running today based on holiday decision (wakeupHolidays=andNoHoliday)
Mein holiday Device hat aber für heute keinen Eintrag.
Gruß Schlimbo
kann ich bestätigen. Nachdem ich Montag zu früh geweckt wurde werde ich aktuell gar nicht mehr geweckt... :-[
Gruß Michael
Hallo Loredo,
bei mir das Gleiche. Am Montag ging es los, habe natürlich prompt verschlafen.
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: lastRun = nextRun = 06:00
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: weekday restriction in conjunction with andNoHoliday in use - not triggering wake-up program this time
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: Wakeuptime recalculation triggered by at-device at_rr_Peter_wakeuptimer1
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: wakeupGetBegin source: nextRun
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: wakeupGetBegin result: 06:00 = 20700 s - 15 m = 05:45:00
Holiday Datei ist ok
Gruß
Peter
Muss ich mir genauer ansehen, auf den ersten Blick ist nichts zu finden.
Auch bei mir meldet das Modul die "weekday restriction" - sogar wenn ich die Attribute "wakeupDays" und "wakeupHolidays" entferne.
Gruß
Danny
Hallo zusammen,
auch bei mir funktionieren seit Montag die WakeUp-Timer nicht mehr. Habe gestern extra zum Test einen neuen zusätzlichen WakeUp-Timer erstellt, da ich hier im Forum noch nichts zu diesem Fehler gefunden hatte. Egal was ich auch mache, ich erhalte immer wieder den Fehler "weekday restriction in use - not triggering wake-up program this time".
Anbei ein Auszug aus dem Log mit Verbose 5:
2017.03.28 19:39:00 4: dummy set rr_Christian_wakeuptimer3 trigger
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: lastRun = nextRun = 19:40
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: weekday restriction in use - not triggering wake-up program this time
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: Wakeuptime recalculation triggered by at-device at_rr_Christian_wakeuptimer3
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: wakeupGetBegin source: nextRun
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: wakeupGetBegin result: 19:40 = 70740 s - 1 m = 19:39:00
Viele Grüße, Chris
Hi zusammen,
habe mir im SVN mal die letzten Änderungen angesehen und bin auf folgende Syntax gestoßen:
!grep { $wday eq $_ } @days (kommt in Summe 3x vor).
Dies habe ich nun bei mir im Modul RESIDENTStk.pm ersetzt durch
!( grep { $wday eq $_ } @days ).
Und siehe da, es funktioniert :)
@Loredo: vielleicht solltest Du Dir die Zeilen 1052, 1062 und 1077 nochmal anschauen ;)
Viele Grüße, Chris
Zitat von: Chris76FiSi am 29 März 2017, 18:31:41
@Loredo: vielleicht solltest Du Dir die Zeilen 1052, 1062 und 1077 nochmal anschauen ;)
Danke, das sowas aber auch an Klammern scheitern muss... ::)
Habe inzwischen eine etwas andere Variante implementiert.
Außerdem konnte ich bei dem Deep-Dive jetzt auch herausfinden, weshalb Sonntags die Vorhersage für den nächsten Wecker am Montag nicht stimmt. Das sollte jetzt auch behoben sein.
Außerdem behoben: Wenn der nächste Wecker nicht innerhalb der nächsten 24 Stunden gesetzt ist, werden die Readings nextWakeup und nextWakeupDev jetzt korrekt auf "OFF" respektive "" gesetzt.
Wer morgen wieder richtig geweckt werden will und nicht auf das morgige Update warten möchte:
https://svn.fhem.de/trac/export/13851/trunk/fhem/FHEM/RESIDENTStk.pm (https://svn.fhem.de/trac/export/13851/trunk/fhem/FHEM/RESIDENTStk.pm)
Gruß
Julian
Danke fürs schnelle ändern.habe mir die aktuelle Version aus dem SVN gezogen. Gerade als ich schlafen gehen wollte habe ich die Weckzeit minus dem eingestellten Offset angesagt bekommen. Gewollt oder bug?
Ich werde morgen früh berichten, wann ich geweckt wurde.
Gruß Michael
Da warst du etwas zu schnell, ist bereits gefixt. Habe den DL-Link aktualisiert.
alles klar, danke ;-)
Gruß Michael
Bei der Untersuchung des Wakeuptimers ist mir aufgefallen, dass "setstate watchdog defined" wohl nicht mehr dafür funktioniert, um die für die Weckfunktion verwendeten Watchdogs wieder zurückzusetzen. Das führt (bei mir) dazu, dass die Statuswechsel der ROOMMATE und GUEST Geräte nicht mehr richtig vom Weckprogramm gesteuert werden und das ROOMMATE Device z.B. im Status "awoken" hängen bleibt statt auf "home" zu wechseln.
Da es laut diesem Beitrag (https://forum.fhem.de/index.php/topic,65406.msg567704.html#msg567704) keine offizielle Funktion zu sein scheint und es inzwischen das Attribut autoReset gibt, habe ich die Templates entsprechend umgebaut. Bestehende Watchdogs, die für den Wakeuptimer bereits erstellt wurden, muss man allerdings einmalig händisch entsprechend anpassen.
Hallo Julian,
Welche genau sind das?
wd_rr_Steven_asleep
wd_rr_Steven_gotosleep
wd_rr_Steven_awoken
Und so???
Ja genau die.
Ich traue mich gerade nicht daran die ganzen Watchdog- und at-Devices alle in ein einzelnes DOIF zusammenzufassen. DamalsTM gab es noch kein DOIF ;)
Das steht schon länger auf der Todo Liste, aber bedarf halt doch einiger Tests und vermutlich auch einiger Änderungen. Da die Tests für den Wecker aber so langwierig und aufwändig sind, ist das bisher noch so geblieben. Aber wenn sich jemand berufen fühlt hier ein DOIF zu basteln, was alles ersetzen und zusammenfassen kann... :-)
Bitte bitte kein DOIF. Das tut nicht Not
Hallo Loredo,
hab ich das richtig verstanden, ich muß bei
wd_rr_Peter_asleep
wd_rr_Peter_gotosleep
wd_rr_Peter_awoken
das attr. autoRestart auf 1 setzen ?
Viele Grüße Peter
Genau. Optimalerweise änderst du die DEF noch so um, dass der setstate Befehl am Ende wegfällt.
Also aus
defmod wd_rr_Son_asleep watchdog rr_Son:asleep 00:00:04 rr_Son:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rr_Son_asleep; setstate wd_rr_Son_asleep defined
wird
defmod wd_rr_Son_asleep watchdog rr_Son:asleep 00:00:04 rr_Son:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rr_Son_asleep
attr wd_rr_Son_asleep autoRestart 1
Hallo Loredo,
vielen Dank für Deine tolle Unterstützung.
Gruß
Peter
Man kann es sich übrigens auch einfacher machen und alle at_r.* und wd_r.* Devices löschen. Sie werden beim nächsten stellen des Timers dann neu angelegt.
Wer das vor hat, dem sei geraten auf das morgige Update zu warten. Dort sind Anpassungen für die Unterstützung der deutschen Sprache enthalten, sofern man seine Devices über das r*_lang Attribut eingedeutscht hat.
Zitat von: CoolTux am 01 April 2017, 12:21:01
Bitte bitte kein DOIF. Das tut nicht Not
Warum denn nicht? Ist so schön übersichtlich... und viel intuitiver für Anfänger, besonders bei komplexeren Dingen... ;-)
Du bist ja fähig, es Dir nach belieben umzuändern....
Vermutlich weil DOIF eine eierlegende Wollmilchsau ist und nur bei wirklich einfachen Dingen intuitiv erscheint.
Bei komplexeren Angelegenheiten wird es schnell so unübersichtlich, dass man sehr einfach graue Haare kriegen kann, nur weil eine der vielen Optionen an der falschen Stelle steht oder ein einzelner Buchstabe falsch steht. Von der Performance ganz zu schweigen ;-)
Ich habe auch extrem viel auf DOIF umgestellt vor über einem Jahr, irgendwann haben Dinge nicht mehr funktioniert (Änderungen sind wohl teils nicht rückwärts kompatibel) und die habe ich bis heute noch nicht gefixt, weil die DOIFs ein dermaßen Wirrwahr sind und man zudem die Millionen von Threads gelesen haben muss um zu verstehen, was sich jetzt an der Notation in welchem Detailgrad wieder geändert hat. Es mag sein, dass es inzwischen eine stabilere Basis hat. Aber wenn man einmal Tage Arbeit reingesteckt hat und es dann nicht mehr geht und man wieder Tage bräuchte um den Fehler zu finden, ist man wohl ein gebranntes Kind.
Ich vermute Heiko hat ähnliche Erfahrungen und ist deshalb nicht so gut auf DOIF zu sprechen ;-)
Nichts desto trotz: Das DOIF für den Wecker sähe vermutlich eher einfach aus und würde im Grunde das at und den watchdog zusammenfassen. Man sparte sich also lediglich ein einzelnes Device, denn pro Wecker bräuchte man wahrscheinlich doch auch ein eigenes DOIF, wenn man es nicht wieder verkomplizieren wollen würde und mit einem einzigen DOIF alle Wecker erschlagen wollen würde. Das sind dann nämlich wieder so Dinge, bei denen DOIF aus der vergangenen Erfahrung heraus kein Vertrauen genießen würde.
Dennoch habe ich überlegt DOIF zusätzlich einzubauen, damit man zumindest die Wahl hat. Wie gesagt: Wer eins baut, kriegt zwar kein Eis, aber kann danach zwischen at+watchdog und DOIF wählen 8)
Ich habe jetzt für den Wakeuptimer eingebaut, dass das forcierte Wecken nur denn stattfinden kann, wenn die eingestellte Weckzeit früher ist als die Standardweckzeit.
Bisher konnte man wakeupEnforce nur auf 2 setzen, um forciert zu wecken, falls generell von der Standartweckzeit abgewichen wurde. mit der neuen Option wakeupEnforce=3 wird dies weiter eingeschränkt, so dass man z.B. Sonntags nur noch forciert aus dem Bett geworfen wird, wenn die Weckzeit explizit früher eingestellt wurde als die Standardweckzeit. Sinnvoll, wenn man zuvor eine Party Nacht hatte und eigentlich gerne länger schlafen möchte als die Standardweckzeit. Vorher wurde man dann zum eigenen Bedauern sogar noch zum aufstehen gezwungen - das ist nun vorbei :)
Moin,
mir ist da gerade beim durchsehen des Log-Files etwas aufgefallen:
delete atTmp_.*_Macro_rr_XYZ_wakeuptimer1 : Please define atTmp_.*_Macro_rr_XYZ_wakeuptimer1 first
bei früheren Versionen des Moduls wurde in der Macro_rr_XYZ_wakeuptimer1 noch geprüft, ob das AT bereits definiert wurde:
for (my $i=1; $i <= 10; $i++) {
if (defined($defs{"atTmp_".$i."_".$NAME})) {
fhem "delete atTmp_".$i."_".$NAME;
}
}
bei der aktuellen Version nicht:
fhem "delete atTmp_.*_".$NAME;
Gibt es dafür irgendwelche Gründe? Ich habe es selbst wieder hinzugefügt und mir sind dadurch noch keine Fehler aufgefallen.
Des Weiteren ist mir aufgefallen, dass das rr_XYZ_wakeuptimer1_resetswitcher - Device nicht mehr automatisch angelegt wird.
Zitat von: Loredo am 01 April 2017, 11:45:45
Bei der Untersuchung des Wakeuptimers ist mir aufgefallen, dass "setstate watchdog defined" wohl nicht mehr dafür funktioniert, um die für die Weckfunktion verwendeten Watchdogs wieder zurückzusetzen. Das führt (bei mir) dazu, dass die Statuswechsel der ROOMMATE und GUEST Geräte nicht mehr richtig vom Weckprogramm gesteuert werden und das ROOMMATE Device z.B. im Status "awoken" hängen bleibt statt auf "home" zu wechseln.
Da es laut diesem Beitrag (https://forum.fhem.de/index.php/topic,65406.msg567704.html#msg567704) keine offizielle Funktion zu sein scheint und es inzwischen das Attribut autoReset gibt, habe ich die Templates entsprechend umgebaut. Bestehende Watchdogs, die für den Wakeuptimer bereits erstellt wurden, muss man allerdings einmalig händisch entsprechend anpassen.
und folgende....
Hmm,
soll heissen, das ich mir den rr_XYZ_wakeuptimer1_resetswitcher inklusive des wakeupResetSwitcher-Attributs in dem rr_XYZ_wakeuptimer1 sparen kann?
Was hat das mit der Prüfung auf existierende ATs zu tun?
Hallo,
ich hatte auch das Problem, dass der Wecker nach der Umstellung nicht mehr richtig funktioniert hat.
Allerdings ist es bei mir so, dass morgens das Reading "wakeup" in meinem Roommate-Modul erhalten bleibt und der Status nicht auf "home" geändert wird.
ich muss händisch morgens das System auf "home" setzen und ein deletereading rr_Henning wakeup ausführen.
Woran kann das liegen? Mir ist leider aktuell nicht wirklich klar, wo die zwei Aktionen oben eigentlich ausgeführt werden sollten. Der Rest vom Wecker klappt super ;)
Danke euch!
Zitat von: ComputerZOO am 12 April 2017, 12:23:53
Gibt es dafür irgendwelche Gründe?
Ja: Das Kommando ist unabhängig der Anzahl der temporären at-Devices und übersichtlicher/kürzer.
Ich habe im Template gerade eine leichte Abänderung eingecheckt, die die Fehlermeldung unterdrückt, wenn die at-Devices bereits alle abgelaufen sind und nicht mehr existieren:
fhem "delete atTmp_.*_".$NAME.":FILTER=TYPE=at";Zitat von: ComputerZOO am 12 April 2017, 12:23:53
Des Weiteren ist mir aufgefallen, dass das rr_XYZ_wakeuptimer1_resetswitcher - Device nicht mehr automatisch angelegt wird.
Wird es generell seit jeher nur, wenn für das dummy Modul die Attr-Funktion überschrieben werden konnte. Wenn ein anderes Modul das auch macht, dann gibt es einen entsprechenden Hinweis im Log.
Man muss dann eben einfach das Dummy Device selbst anlegen und konfigurieren und auf die Annehmlichkeit verzichten, das ist alles.
Zitat von: ComputerZOO am 12 April 2017, 12:41:42
soll heissen, das ich mir den rr_XYZ_wakeuptimer1_resetswitcher inklusive des wakeupResetSwitcher-Attributs in dem rr_XYZ_wakeuptimer1 sparen kann?
Diese Frage verstehe ich nicht.
Zitat von: heig am 12 April 2017, 18:31:41
ich hatte auch das Problem, dass der Wecker nach der Umstellung nicht mehr richtig funktioniert hat.
Allerdings ist es bei mir so, dass morgens das Reading "wakeup" in meinem Roommate-Modul erhalten bleibt
Bitte FHEM aktualisieren, da ist bereits seit einiger Zeit ein entsprechendes Update dabei.
Zitat von: heig am 12 April 2017, 18:31:41
und der Status nicht auf "home" geändert wird.
ich muss händisch morgens das System auf "home" setzen
Das hängt ganz davon ab, ob du enforced Wakeup aus der Beispiel Konfiguration übernommen hast und wenn ja, ob du die entsprechende Sektion "END WAKE-UP PROGRAM" auch im Macro "Macro_rr_Son_wakeuptimer1" beibehalten hast. Dort wird sonst normal von "asleep" auf "awoken" umgeschaltet. Man kann dann in diesem Status bleiben oder auch über das Macro "Macro_rr_Hening_awoken", welches auf "awoken" triggert, ebenfalls automatisch auf "home" wechseln. Dazu ist diese Beispielzeile dort enthalten:
## change user state to home after 60 seconds
fhem "sleep 60; set rr_Henning:FILTER=state!=home home";
Wenn du sie entfernt hast, ist die Funktion natürlich nicht mehr da.
Hallo Loredo,
ich ändere bei meinem Wecker öfter das Attribut wakeupDays und wakeupHolidays je nach dem wie ich den Wecker gerade verwenden möchte, dabei ist mir aufgefallen dass die Readings nextWakeup und nextWakeupDev bei dieser Art von Änderung nicht aktualisiert werden und somit falsche Werte anzeigen. Ist es möglich hier noch etwas einzubauen, damit die Readings auch bei Änderung der beiden Attribute aktualisiert werden?
Gruß Schlimbo
Zitat von: Schlimbo am 14 April 2017, 21:45:43
ich ändere bei meinem Wecker öfter das Attribut wakeupDays und wakeupHolidays je nach dem wie ich den Wecker gerade verwenden möchte, dabei ist mir aufgefallen dass die Readings nextWakeup und nextWakeupDev bei dieser Art von Änderung nicht aktualisiert werden und somit falsche Werte anzeigen. Ist es möglich hier noch etwas einzubauen, damit die Readings auch bei Änderung der beiden Attribute aktualisiert werden?
Über Attribute geht das leider nicht zuverlässig, da die Events dazu ggf. nicht zuverlässig abzufangen sind (gleicher Grund wie für den gerade erst beschriebenen Resetswitcher, der u.U. nicht automatisch angelegt wird).
Ich habe das ganze deshalb als Setter implementiert. Ist ohnehin schicker, weil das nicht als Änderungen an der Struktur von FHEM erkannt wird.
Die Setter werden nur zu neu angelegten Wakeuptimern automatisch hinzugefügt. Zu bestehenden Timern muss man manuell das setList Attribut entsprechend erweitern:
attr rr_Julian_wakeuptimer1 setList nextRun:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 reset:noArg trigger:noArg start:noArg stop:noArg end:noArg wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:,andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3
Ist eines der Readings wakeupDefaultTime, wakeupResetdays, wakeupDays, wakeupHolidays oder wakeupEnforced gesetzt, hat es Vorrang vor einem evtl. noch gesetzten Attribut.
Möchte man wieder die Attribute verwenden, muss man das Reading mittels deletereading löschen.
Der Patch, den ich gerade eingecheckt habe, ist recht umfangreich. Es ist leider immer schwer das ganze vorher trocken zu testen, deshalb will ich nicht ausschließen, dass es zu Seiteneffekten kommt und empfehle ggf. das Update erst in einigen Tagen vorzunehmen, wenn Erfahrungswerte vorliegen. Natürlich würde ich mich freuen, wenn einige das Update trotzdem wagen und dann berichten :-)
Viele Grüße
Julian
Vielen Dank, werde ich gerne testen und dann berichtigen.
Hallo Loredo,
ich habe die Attribute wakeupDays und wakeupHolidays gelöscht und stattdessen als Readings angelegt.
list rgr_Bewohner_wakeuptimer1:
Internals:
NAME rgr_Bewohner_wakeuptimer1
NR 584
STATE 09:55
TYPE dummy
Readings:
2017-04-13 04:48:00 lastRun 05:18
2017-04-16 09:50:34 nextRun 09:55
2017-04-13 05:18:01 running 0
2017-04-16 10:22:08 state 09:55
2017-04-15 18:22:19 wakeupDays 0,1,2,3,4,5,6
2017-04-16 10:22:07 wakeupHolidays andHoliday
Attributes:
alexaName wecker
alexaRoom wohnzimmer
alias Wake-up Timer 1
comment Auto-created by RESIDENTS module for use with RESIDENTS Toolkit
devStateIcon OFF:general_aus@red:reset running:general_an@green:stop .*:general_an@orange:nextRun%20OFF
genericDeviceType wecker
group Home State
homebridgeMapping Weckzeit=nextRun,cmd=nextRun
icon time_timer
room Residents,alexa
setList nextRun:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 reset:noArg trigger:noArg start:noArg stop:noArg end:noArg wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:,andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3
userattr wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupMacro wakeupUserdevice wakeupAtdevice wakeupResetSwitcher wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3 wakeupWaitPeriod:slider,0,1,360
verbose 5
wakeupAtdevice at_rgr_Bewohner_wakeuptimer1
wakeupMacro Macro_rgr_Bewohner_wakeuptimer1
wakeupOffset 4
wakeupUserdevice rgr_Bewohner
wakeupWaitPeriod 0
webCmd nextRun
Der Wecker wird aber nicht ausgelöst.
Im Log steht folgendes:
2017.04.16 09:51:00.005 4: dummy set rgr_Bewohner_wakeuptimer1 trigger
2017.04.16 09:51:00.029 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: lastRun = nextRun = 09:55
2017.04.16 09:51:00.030 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: weekday restriction in conjunction with andHoliday in use - not triggering wake-up program this time
2017.04.16 09:51:00.031 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 09:51:00.032 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 09:51:00.033 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 09:51:00.033 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=09:51 wakeupOffset=4 nextRunSec=35460 nextRunSecTarget=35700
2017.04.16 09:51:00.034 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 09:51:00.034 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 09:51:00.039 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 09:51:00.040 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 09:51:00.040 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 09:51:00.041 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=09:51 wakeupOffset=4 nextRunSec=35460 nextRunSecTarget=35700
2017.04.16 09:51:00.041 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 09:51:00.041 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 09:51:00.058 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: Wakeuptime recalculation triggered by at-device at_rgr_Bewohner_wakeuptimer1
2017.04.16 09:51:00.059 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin source: nextRun
2017.04.16 09:51:00.059 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin result: 09:55 = 35460 s - 4 m = 09:51:00
Und noch eine Bitte:
Könntest du das wakeupOffset auch noch als Setter umsetzten?
Da ich möchte, dass der Wecker immer funktioniert, auch wenn ich nur ein 15 Minuten Powernap mache, berechne ich mir die wakeupOffset Zeit bei jedem Wecker stellen neu, ist die Weckzeit > 30 min wird sie auf 30min gesetzt, bei Weckzeit < 30 min wird sie verringert.
Beispiel:
Um 14:00 Uhr stelle ich den Wecker auf 14:20 Uhr
Der standard Offset von 30 würde bewirken, dass der Wecker erst am nächsten Tag klingelt.
Deswegen rechne ich mir den maximal möglichen Offset aus, in diesem Beispiel 19 min.
Im Macro_wakeuptimer werden dann die "atTmp_" Timer auch im Bezug auf die offset Zeit berechnet:
my $wakeupOffset = AttrVal($EVTPART[4]."_wakeuptimer1", "wakeupOffset",30);
my $offset1 =sprintf("%02.0f", (max(0,($wakeupOffset - 0))));
my $offset2 =sprintf("%02.0f", (max(0,($wakeupOffset - 5))));
fhem 'define atTmp_1_'.$NAME.' at +00:'.$offset1.':00 set ....
Gruß Schlimbo
Hallo Loredo,
habe gerade noch etwas getestet.
Wenn das Reading wakeupHolidays auf "andNoHoliday" steht wurde der Wecker getriggert, bei dem Test heute morgen stand das Reading auf "andHoliday" und da wurde er nicht getriggert, solange aber wakeupDays auf "0,1,2,3,4,5,6" steht sollte es doch mit beiden Varianten funktionieren, oder?
Beim ausführen des Weckers ist jetzt aber noch ein weiteres Probleme aufgetreten:
Das FHEM Webinterface war nicht mehr erreichbar, das Log ist voll mit Einträgen, die sich ständig wiederholen:
17.04.16 21:16:25.795 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:16:25.819 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: New wake-up time: 21:20
2017.04.16 21:16:25.823 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: Wakeuptime recalculation triggered by at-device at_rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.823 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin source: nextRun
2017.04.16 21:16:25.824 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin result: 21:20 = 76620 s - 3 m = 21:17:00
2017.04.16 21:16:25.827 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: Wakeuptime recalculation triggered by at-device at_rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.828 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin source: nextRun
2017.04.16 21:16:25.828 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin result: 21:20 = 76620 s - 3 m = 21:17:00
2017.04.16 21:16:25.859 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.860 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:25.861 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:25.861 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:25.862 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:25.862 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 21:16:25.913 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:16:25.921 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:16:25.926 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.927 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:25.928 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:25.929 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:25.929 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:25.929 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 21:16:25.933 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.934 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:25.935 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:25.935 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:25.935 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:25.936 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 21:16:25.940 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.940 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:25.941 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:25.942 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:25.942 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:25.942 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 21:16:26.516 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:16:29.371 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:16:29.376 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:29.377 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:29.378 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:29.379 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:29.379 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:29.379 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2017.04.16 21:16:29.380 4: RESIDENTStk rgr_Bewohner: 07 - next wake-up result: today at 21:20:00, wakeupDevice=rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:29.429 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:16:29.440 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:29.441 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:29.441 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:29.442 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:29.442 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:29.442 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2017.04.16 21:16:29.443 4: RESIDENTStk rgr_Bewohner: 07 - next wake-up result: today at 21:20:00, wakeupDevice=rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:32.123 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:16:39.809 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:17:00.016 4: dummy set rgr_Bewohner_wakeuptimer1 trigger
2017.04.16 21:17:00.045 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: lastRun = nextRun = 21:20
2017.04.16 21:17:00.047 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: trigger Macro_rgr_Bewohner_wakeuptimer1 (running=1)
2017.04.16 21:17:00.057 3: Macro_rgr_Bewohner_wakeuptimer1: Wake-up program start for rgr_Bewohner with target time 21:20. Current state: home
2017.04.16 21:17:00.057 3: Macro_rgr_Bewohner_wakeuptimer1: Wake-up program started for rgr_Bewohner with target time 21:20. Current state: home
2017.04.16 21:17:00.059 3: Macro_rgr_Bewohner_wakeuptimer1: wakeupOffset: 3, offset1: 03, offset2: 00, wakeupLight: off, wakeupHeat: on
2017.04.16 21:17:00.608 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:17:00.618 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: created at-device at_rgr_Bewohner_wakeuptimer1_stop to stop wake-up program in 3 minutes
2017.04.16 21:17:00.902 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:00.903 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:00.904 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:00.905 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:00.905 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:00.905 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:00.968 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:17:00.978 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:00.981 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:00.984 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:00.990 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:00.991 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:00.991 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:00.992 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:00.992 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:00.993 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:00.998 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:00.999 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.000 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.000 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.001 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.001 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.006 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.007 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.008 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.008 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.009 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.009 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.011 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.017 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.018 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.019 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.020 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.020 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.021 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.023 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.029 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.030 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.031 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.032 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.032 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.033 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.035 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.041 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.042 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.044 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.044 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.046 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.052 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.054 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.054 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.055 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.055 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.056 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.058 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.064 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.065 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.066 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.066 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.067 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.067 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.069 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.075 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.076 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.077 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.078 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.078 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.079 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.081 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.087 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.088 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.089 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.090 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.090 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.090 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.092 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.098 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.100 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.100 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.101 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.101 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.102 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.104 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.110 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.111 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.112 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.112 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.113 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.113 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.115 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.121 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.122 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.123 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.124 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.124 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.125 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.127 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.133 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.134 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.135 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.135 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.136 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.136 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.139 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.144 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.146 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.146 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.147 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.148 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.148 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.150 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.156 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.158 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.158 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.159 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.160 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.160 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.162 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.168 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.169 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.170 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.171 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.171 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.171 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.173 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.179 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.181 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.181 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.182 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.182 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.183 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.185 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.191 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.192 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.193 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.193 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.194 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.194 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.196 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.202 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.203 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.204 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.205 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.205 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.205 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.209 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.217 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.218 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.220 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.221 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.221 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.222 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.224 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.234 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.236 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.237 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.238 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.239 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.239 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.242 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.254 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.260 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.261 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.262 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.262 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.263 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.266 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.274 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.275 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.276 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.277 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.278 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.278 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.281 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.289 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.290 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.291 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.292 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.292 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.293 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.296 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.303 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.305 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.305 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.306 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.307 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.307 4: RESIDENTStk rgr_Bewohn...
Erst nach einem Neustart von FHEM war das Webinterface wieder erreichbar.
Gruß
Schlimbo
Das gleiche Problem hier heute morgen auch. FHEM nicht erreichbar , Wecker hat nicht ausgelöst.
Logfile ist voll mit Einträgen und CPU auf 100%.
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
Moin >:(
Bei mir ist der Wecker zusammen mit FHEM auch abgekackt!!
Zitat von: ComputerZOO am 17 April 2017, 09:43:24
Moin >:(
Siehe Warnung vor dem Update hier (https://forum.fhem.de/index.php/topic,19040.msg620900.html#msg620900).
Zitat von: Schlimbo am 16 April 2017, 22:15:56
Beim ausführen des Weckers ist jetzt aber noch ein weiteres Probleme aufgetreten:
Das FHEM Webinterface war nicht mehr erreichbar, das Log ist voll mit Einträgen, die sich ständig wiederholen:
...
Erst nach einem Neustart von FHEM war das Webinterface wieder erreichbar.
Zitat von: Phiolin am 17 April 2017, 07:58:24
Das gleiche Problem hier heute morgen auch. FHEM nicht erreichbar , Wecker hat nicht ausgelöst.
Logfile ist voll mit Einträgen und CPU auf 100%.
Ich habe das jetzt zum Anlass genommen die ohnehin fällige Überarbeitung des Notification Systems vorzunehmen. Dafür habe ich gerade einen abermals recht großen Patch eingespielt, der auch den berichteten Loop korrigiert.
Zitat von: Schlimbo am 16 April 2017, 11:01:12
Der Wecker wird aber nicht ausgelöst.
Ich bin nicht sicher, woher dieser Fehler sich eingeschlichen hat. Ich habe auch die gesamte Und/Oder Logik für die Einschränkung auf Tage und Feiertage überarbeitet.
Den gesamten Patch habe ich so gut es eben geht trocken durchgetestet. Jedoch zunächst ohne Gewähr, bis hier keine Fehlermeldungen auftauchen.Vielleicht mag ja auch jemand einmal trocken durchtesten, bevor er sich wieder am Morgen wundert. ::) Wer heute blind updated, muss damit rechnen, dass morgen etwas nicht funktionieren könnte!Zitat von: Schlimbo am 16 April 2017, 11:01:12
Und noch eine Bitte:
Könntest du das wakeupOffset auch noch als Setter umsetzten?
Ist ebenfalls eingebaut. Ggf. erweitere ich die interne Logik noch um eine eigene Schlummer-Funktion, dass dein Vorhaben nicht im Macro platziert sein muss. Danke für die Inspiration.
Hallo Loredo,
erst mal danke für deine Mühe, bin gerade dabei die neue Version zu testen:
Für den neuen Setter wakeupOffset muss ich dann das setList Attribut wieder anpassen, oder?
(+ wakeupOffset:slider,0,1,120):
nextRun:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 reset:noArg trigger:noArg start:noArg stop:noArg end:noArg wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:,andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3 wakeupOffset:slider,0,1,120
Bei einem neu erstellten wakeuptimer fehlt wakeupOffset auch noch im setList Attribut.
Was mir noch aufgefallen ist, bei einem neu erstellten wakeuptimer steht im Attribut userattr nur noch "wakeupUserdevice", hier musste doch auch noch "wakeupMacro wakeupAtdevice wakeupResetSwitcher" stehen, oder?
Bei der neuen Version funktionieren die Setter nicht mehr.
Bei Eingabe von
set rgr_Bewohner_wakeuptimer1 wakeupHolidays andNoHoliday
Sollte doch eigentlich das Reading wakeupHolidays angelegt werden, jedoch wird nur das Reading state auf "wakeupHolidays andNoHoliday" gesetzt.
Im UserDevice werden bei mir jetzt die Readings "nextWakeup" und "nextWakeupDev" nicht mehr angelegt.
Gruß Schlimbo
Danke dir!
Da fehlte noch eine Aktualisierung der NOTIFYDEV Definition nachdem ein Wecker neu angelegt wurde, habe ich gerade hinzugefügt.
Guten Morgen,
Nachdem ich heute zuverlässig geweckt wurde, kann ich wohl sagen, dass das Gröbste überstanden zu sein scheint :-)
Die aktuelle Version sollte bei großen Installationen auch durch den Einsatz von NOTIFYDEV performanter laufen.
Happy updating...
Gruß
Julian
Guten Morgen Julian,
kann ich bestätigen, auch ich wurde heute wieder richtig geweckt :)
Die beiden Punkte sind aber immer noch vorhanden:
Zitat von: Schlimbo am 17 April 2017, 16:28:24
Was mir noch aufgefallen ist, bei einem neu erstellten wakeuptimer steht im Attribut userattr nur noch "wakeupUserdevice", hier musste doch auch noch "wakeupMacro wakeupAtdevice wakeupResetSwitcher" stehen, oder?
Bei der neuen Version funktionieren die Setter nicht mehr.
Bei Eingabe von
set rgr_Bewohner_wakeuptimer1 wakeupHolidays andNoHoliday
Sollte doch eigentlich das Reading wakeupHolidays angelegt werden, jedoch wird nur das Reading state auf "wakeupHolidays andNoHoliday" gesetzt.
Gruß Schlimbo
Hallo,
ich nutze das Residents Modul in Verbindung mit Geofency. Bisher war ich als einzige Bewohner angelegt. Funktioniert auch alles perfekt. Wenn ich weg bin und z.B. die Homezone verlasse, dann meldet Geofency das und FHEM schaltet auf Absent.
Nun hab ich meine Frau hinzugefügt und auch soweit alles eingerichtet. Die App auf Ihrem Handy meldet auch sauber, wenn sie zu Hause verlassen hat. In FHEM steht auch in den Readings unter "location", das Sie nun im Büro ist. Aber der Status bleibt weiterhin auf "zu Hause".
Muss ich noch irgendwas machen ? Muss noch irgendwo was eingerichtet werden, das der Status automatisch auf abwesend wechselt ?
Grüße,
Visionsurfer
Zitat von: Schlimbo am 18 April 2017, 09:53:25
Die beiden Punkte sind aber immer noch vorhanden:Gruß Schlimbo
Das kann ich bei mir nicht nachvollziehen, weder mit der Test noch Live Umgebung. Vielleicht hast du nicht alle Dateien aktualisiert?
Nach wie vor ist es wichtig zu betonen, dass die Events nicht ankommen, wenn man event-on-* Attribute verwendet und diese falsch gesetzt sind. Sie sollten für keines der involvierten Geräte gesetzt sein.
Zitat von: visionsurfer am 18 April 2017, 10:33:26
Muss ich noch irgendwas machen ? Muss noch irgendwo was eingerichtet werden, das der Status automatisch auf abwesend wechselt ?
Der automatische Wechsel passiert nur, wenn die Location "home" heißt. Andere Namen funktionieren nur, wenn sie im Attribut rr_locationHome angegeben sind.
Okay, hab jetzt den Wecker noch mal komplett gelöscht und über create wakeuptimer neu angelegt.
Jetzt funktioniert es auch bei mir wie es soll. :)
Danke
@Loredo
Hmmm. Ok. Ich hatte mich schon gewundert. Als ich damals das Modul installiert habe, war bei mir alles auf englisch. Also home, absent, gosleep usw.
Als ich nun meine Frau hinzugefügt habe, war bei der alles auf deutsch. Dort steht jetzt "zu Hause".
Also trage ich bei ihr im attr. "rr_locationHome" dann einfach den Wert "zu Hause" ein ? Dann geht es automatisch ?
Grüße,
Visionsurfer
Zitat von: visionsurfer am 18 April 2017, 14:15:59
Hmmm. Ok. Ich hatte mich schon gewundert. Als ich damals das Modul installiert habe, war bei mir alles auf englisch. Also home, absent, gosleep usw.
Als ich nun meine Frau hinzugefügt habe, war bei der alles auf deutsch. Dort steht jetzt "zu Hause".
Das liegt daran, dass du als globales Attribut wohl language=DE gesetzt hast. Es werde dann entsprechende Attribute gesetzt, um die Anzeige von RESIDENTS/ROOMMATE/GUEST für diese Sprache vorzubelegen. Es ist aber nur die FHEMWEB Anzeige davon betroffen, intern wird weiterhin mit home, absent etc gearbeitet (siehst du auch an den Readings). Über das Attribut r*_lang an den Bewohner-Devices kann das übersteuert werden und die Vorbelegung wird entsprechend umgeändert.
Zitat von: visionsurfer am 18 April 2017, 14:15:59
Also trage ich bei ihr im attr. "rr_locationHome" dann einfach den Wert "zu Hause" ein ? Dann geht es automatisch ?
Nein. Entscheidend ist, was du in der Geofency.app als Namen für die Lokation angegeben hast. Der Name dort darf kein Leerzeichen beinhalten und sollte "home" lauten. Nur wenn der Name davon abweicht musst du das in rr_locationHome entsprechend setzen.
Hi,
ah ok. Jetzt hab ich es verstanden. Ja ich hab in der App auch "zu Hause" eingetragen. Bei mir in meiner App steht noch home. Daher funktioniert es auch sehr gut.
Dann ändere ich das bei meiner Frau und dann sollte es ja funktionieren.
Grüße,
Visionsurfer
Zitat von: Loredo am 14 April 2017, 12:11:16fhem "delete atTmp_.*_".$NAME.":FILTER=TYPE=at";
Das ist ja mal genial! Muss ich glatt mal verinnerlichen...
Hallo Julian,
folgendes scheint nicht mehr zu funktionieren:
Zitat
Ich habe gerade ein Update eingecheckt, damit du dir das PRESENCE Device sparen und direkt den AccessPoint als Quelle für die Präsenz angeben kannst.
Dem Attribut r*_presenceDevices kann dafür jetzt optional einen Readingnamen übergeben bekommen. In deinem Fall also:
attr rr_Bewohner1 rr_presenceDevices ak_accesspoint:metal
Ich bekomme das nur folgendes zurückgeliefert:
Value for rr_presenceDevices has invalid formatMir ist das aufgefallen, da das Attribut komplett gefehlt hatte. Ist das bekannt?
Grüße
Andreas
Zitat von: acw81 am 18 April 2017, 17:38:01
Mir ist das aufgefallen, da das Attribut komplett gefehlt hatte. Ist das bekannt?
Danke, hatte ich nicht berücksichtigt und ist nun gefixt.
Zitat von: Schlimbo am 18 April 2017, 13:54:20
Okay, hab jetzt den Wecker noch mal komplett gelöscht und über create wakeuptimer neu angelegt.
Jetzt funktioniert es auch bei mir wie es soll. :)
Danke
Mist, zu früh gefreut. Das Phänomen ist wieder da.
Zitat von: Schlimbo am 17 April 2017, 16:28:24
Bei der neuen Version funktionieren die Setter nicht mehr.
Bei Eingabe von
set rgr_Bewohner_wakeuptimer1 wakeupHolidays andNoHoliday
Sollte doch eigentlich das Reading wakeupHolidays angelegt werden, jedoch wird nur das Reading state auf "wakeupHolidays andNoHoliday" gesetzt.
Der dummy "rgr_Bewohner_wakeuptimer1" verhält sich bei mir wie ein "normaler" Dummy.
Wenn ich
set rgr_Bewohner_wakeuptimer1 nextRun 07:00 eingebe ändert sich nur "state".
Konnte leider noch nicht herausfinden durch was dieses Phänomen ausgelöst wird.
Wie ist der Dummy mit dem Wecker verknüpft?
List von rgr_Bewohner_wakeuptimer1:
Internals:
NAME rgr_Bewohner_wakeuptimer1
NR 619
STATE nextRun 07:30
TYPE dummy
Readings:
2017-04-18 18:15:44 state nextRun 07:30
Attributes:
alexaName wecker
alexaRoom wohnzimmer
alias Wake-up Timer 1
comment Auto-created by RESIDENTS module for use with RESIDENTS Toolkit
devStateIcon OFF:general_aus@red:reset running:general_an@green:stop .*:general_an@orange:nextRun%20OFF
genericDeviceType wecker
group Home State
homebridgeMapping Weckzeit=nextRun,cmd=nextRun
icon time_timer
room Residents,alexa
setList nextRun:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 reset:noArg trigger:noArg start:noArg stop:noArg end:noArg wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:,andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3
userattr wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupMacro wakeupUserdevice wakeupAtdevice wakeupResetSwitcher wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3 wakeupWaitPeriod:slider,0,1,360
wakeupAtdevice at_rgr_Bewohner_wakeuptimer1
wakeupMacro Macro_rgr_Bewohner_wakeuptimer1
wakeupUserdevice rgr_Bewohner
wakeupWaitPeriod 0
webCmd nextRun Am RESIDENTS Device rgr_Bewohner ist das Attribut
attr rgr_Bewohner rgr_wakeupDevice rgr_Bewohner_wakeuptimer1gesetzt.
Gibt es eine Möglichkeit die Verbindung vom Dummy zum Wecker zu erneuern ohne alles zu löschen und neu anzulegen?
Beim Versuch den Wecker komplett zu Löschen und neu anzulegen bekomme ich beim Löschversuch des Attribut rgr_wakeupDevice die Meldung:
Value for rgr_wakeupDevice has invalid formatGibt es auch eine einfache Möglichkeit einen kompletten Wecker zu löschen, inklusive aller automatisch angelegten Devices?:
Macro_rgr_Bewohner_asleep
Macro_rgr_Bewohner_awoken
Macro_rgr_Bewohner_gotosleep
Macro_rgr_Bewohner_wakeuptimer1
wd_rgr_Bewohner_asleep
wd_rgr_Bewohner_awoken
wd_rgr_Bewohner_gotosleep,
at_rgr_Bewohner_wakeuptimer1Schön wäre ein Befehl ähnlich dem removeRoommate Befehl --> removeWakeuptimer
Bin etwas weiter gekommen:
habe einen zweiten wekeuptimer über create angelegt.
Und jetzt funktioniert der erste auch wieder.
Seltsam sieht aber jetzt das NOTIFYDEV von rgr_Bewohner aus:
NOTIFYDEV rr_Hans,rr_Sina,,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2
Als ich nur einen wakeuptimer hatte sah es so aus:
NOTIFYDEV rr_Hans,rr_Sina
Nach einem Neustart von FHEM gehen dann bei beiden Weckern die Setter nicht mehr und das NOTIFYDEV von rgr_Bewohner sieht wieder so aus:
NOTIFYDEV rr_Hans,rr_Sina
(save config habe ich vor dem Neustart natürlich ausgeführt)
Edit:
noch zur Info: Da ich möchte, dass der Wecker klingelt, sobald irgendjemand Anwesend ist läuft mein wakeuptimer auf dem RESIDENTS Device und nicht auf ROOMMATE, dies sollte aber doch keinen unterschied machen, oder?
Du bist der erste, der den Wecker mit einem RESIDENTS Device statt ROOMMATE verwendet. Kannst du mal damit testen?
Zitat von: Schlimbo am 18 April 2017, 20:25:50
noch zur Info: Da ich möchte, dass der Wecker klingelt, sobald irgendjemand Anwesend ist läuft mein wakeuptimer auf dem RESIDENTS Device und nicht auf ROOMMATE, dies sollte aber doch keinen unterschied machen, oder?
Doch, selbstverständlich.
Okay, gerade mit ROOMMATE getestet, hier funktionieren die Setter auch nach Neustart.
Habe den Wecker aber seit langer Zeit ohne Probleme auf RESIDENTS laufen, da es für mich keinen Sinn macht für ein gemeinsames Schlafzimmer zwei unterschiedliche Wecker anzulegen. Wenn im Schlafzimmer meine "aufwachsen"-Szene gestartet wird (Licht,Radio,Charlousie...) werden zwangsläufig sowieso beide geweckt ;D. Deswegen erschien mir hier das RESIDENTS Device geeigneter.
Könnte bis jetzt auch nirgends lesen dass es hierfür nicht vorgesehen ist, aus welchem Grunde sollte es sonst am RESIDENTS Device den "create wakeuptimer" Befehl geben?
Gruß Schlimbo
Wie du merkst ist es halt der Vollständigkeit halber drin, erfuhr aber keiner besonderen Beachtung bei der Pflege. Von daher wird ein Fix etwas dauern.
Alles klar, dann warte ich.
Gutem Morgen,
nach dem ich mit meinem neuen Wecker (ROOMMATE-Wecker ;)) mal wieder in die wakeupWaitPeriod Falle getappt bin :-\
2017.04.19 05:00:00.041 3: RESIDENTStk rr_Simon_wakeuptimer1: won't trigger wake-up program due to non-expired wakeupWaitPeriod threshold since lastAwake (expLastAwake=1492577457 > nowRunSec=1492572600)
Ist mir beim setzen von wakeupWaitPeriod ein weiters Problem aufgefallen:
Beim ersten erstellen des Attributs wakeupWaitPeriod wird das Attribut richtig gesetzt.
Beim anschließenden Änderungsversuch über den slider wird es immer auf den Wert "wakeupWaitPeriod" gesetzt.
Erst durch löschen und neu setzten kann der Werte geändert werden.
Manuelles setzen über
attr rr_Simon_wakeuptimer1 wakeupWaitPeriod 0
Funktioniert.
Das gleich ist auch bei dem Attribut wakeupOffset, wenn es über den slider verändert wird.
Gruß Schlimbo
Edit: Da dieses Verhalten auch mit "normalen" Dummys auftritt, ist das denke ich ein globales Problem und hat erst mal nichts mit ROOMMATE zu tun.
Hat das sonst noch jemand beobachtet?
Ja das Verhalten habe ich auch und hatte ich auch schon mal in diesem Thread erwähnt...
scheint aber ein globales Problemen zu sein.
Gruß Michael
Zitat von: Schlimbo am 19 April 2017, 08:01:55
Ist mir beim setzen von wakeupWaitPeriod ein weiters Problem aufgefallen:
Beim ersten erstellen des Attributs wakeupWaitPeriod wird das Attribut richtig gesetzt.
Beim anschließenden Änderungsversuch über den slider wird es immer auf den Wert "wakeupWaitPeriod" gesetzt.
Erst durch löschen und neu setzten kann der Werte geändert werden.
Das scheint ein Problem mit dem Widget selbst zu sein, nicht mit dem Modul. Sollte man ggf. einmal Rudi oder André sagen.
Nichtsdestotrotz habe ich gerade einen sehr umfangreichen Patch eingecheckt, der alle Module auf eine gemeinsame Codebasis hebt (in RESIDENTS/ROOMMATE/GUEST steht demnach nur noch die Commandref und die Initialize Funktion drin).
Auch das Notification System wurde weiter verbessert, so dass jetzt eigentlich alles immer zuverlässig (und deutlich schneller, zumindest auf dem Papier...) aktualisiert werden sollte.
Wie immer: Tester vor! :)
Danke.
Erste Tests verliefen gut, mein RESIDENTS-Wecker funktioniert wieder :)
Das Slider Problem habe ich hier mal gemeldet:
https://forum.fhem.de/index.php/topic,70813.msg623077.html#msg623077 (https://forum.fhem.de/index.php/topic,70813.msg623077.html#msg623077)
Zitat von: Loredo am 19 April 2017, 19:56:56
Nichtsdestotrotz habe ich gerade einen sehr umfangreichen Patch eingecheckt, der alle Module auf eine gemeinsame Codebasis hebt (in RESIDENTS/ROOMMATE/GUEST steht demnach nur noch die Commandref und die Initialize Funktion drin).
Auch das Notification System wurde weiter verbessert, so dass jetzt eigentlich alles immer zuverlässig (und deutlich schneller, zumindest auf dem Papier...) aktualisiert werden sollte.
Moin,
wie ist denn bei einem Update eigentlich die beste Herangehensweise? Update durchführen (inkl. shutdown restart) und warten was passiert,
oder am besten vorher alle Wecker löschen und wieder neu zusammenschnurzeln?
Ich frage deshalb, weil bei mir die
rr_XYZ_wakeuptimerX (Montag bis Sonntag je einen) immer sehr umfangreiche Änderungen enthalten
wie z.B. die Wecknachricht, die Lichtszene, den Radiosender, andere Zeitvorgaben etc., die dann im
Macro_rr_XYZ_wakeuptimer eingelesen und ausgewertet werden.
Ich würde mir dann nen eigenes Makro erstellen, das dann nach dem Anlegen der Wecker diese attr und readings wieder einfügt.
Zitat von: ComputerZOO am 19 April 2017, 22:15:21
wie ist denn bei einem Update eigentlich die beste Herangehensweise? Update durchführen (inkl. shutdown restart)
Genau so. Bestehende Automationen bleiben einfach wie sie sind. Es hat sich ja auch an der eigentlichen Funktionsweise nichts geändert.
hi,
folgendes hatte ich vorhin nach dem Update im Log:
Use of uninitialized value $definitiveNextToday in numeric ge (>=) at FHEM/RESIDENTStk.pm line 3272.
Use of uninitialized value $definitiveNextToday in numeric lt (<) at FHEM/RESIDENTStk.pm line 3275.
Use of uninitialized value $definitiveNextToday in numeric ge (>=) at FHEM/RESIDENTStk.pm line 3272.
Use of uninitialized value $definitiveNextToday in numeric lt (<) at FHEM/RESIDENTStk.pm line 3275.
Nix dramatisches, nur zur Info.
Gruß Michael
Hallo Julian,
Ich habe gestern Abend ein Update gemacht. Seit dem schalten meine Roommates nicht mehr entsprechend des presence Devices. Events werden vom present Device erzeugt, aber dem Roommate scheint das nicht zu jucken. Hat vorher super funktioniert. Auch das heutige Update bringt keine Verbesserung.
Hast Du eine Idee?
Grüße
Internals:
AUTOGONE 1492840392
CFGFN
CHANGED
DEF AnniKraussStr,Eltern
DURATIONTIMER 1492714573.26375
NAME rr_Marko
NOTIFYDEV global,rr_Marko_wakeuptimer1,presenceMarko
NR 16
NTFY_ORDER 50-rr_Marko
RESIDENTGROUPS AnniKraussStr,Eltern
STATE absent
TYPE ROOMMATE
Helper:
Dblog:
Presence:
Logdbcurrent:
TIME 1492710793.29799
VALUE absent
Readings:
2017-04-20 20:55:13 durTimerAbsence 01:02:01
2017-04-20 20:55:13 durTimerAbsence_cr 62
2017-04-20 19:53:12 durTimerPresence 00:00:00
2017-04-20 19:53:12 durTimerPresence_cr 0
2017-04-20 05:02:01 durTimerSleep 00:00:00
2017-04-20 05:02:01 durTimerSleep_cr 0
2017-04-20 18:44:40 lastArrival 2017-04-20 18:44:40
2017-04-20 05:02:01 lastAwake 2017-04-20 05:02:01
2017-04-20 19:53:12 lastDeparture 2017-04-20 19:53:12
2017-04-20 18:44:40 lastDurAbsence 11:36:46
2017-04-20 18:44:40 lastDurAbsence_cr 697
2017-04-20 19:53:12 lastDurPresence 01:08:32
2017-04-20 19:53:12 lastDurPresence_cr 69
2017-04-20 05:02:01 lastDurSleep 07:33:19
2017-04-20 05:02:01 lastDurSleep_cr 453
2017-04-20 19:53:12 lastLocation home
2017-04-20 19:53:12 lastMood calm
2017-04-19 21:28:42 lastSleep 2017-04-19 21:28:42
2017-04-20 19:53:12 lastState home
2017-04-20 04:00:00 lastWakeup 05:00
2017-04-20 04:00:00 lastWakeupDev rr_Marko_wakeuptimer1
2017-04-20 19:53:12 location underway
2017-04-20 19:53:12 mood -
2017-04-17 23:59:04 nextWakeup 05:00
2017-04-17 23:59:04 nextWakeupDev rr_Marko_wakeuptimer1
2017-04-20 19:53:12 presence absent
2016-04-21 07:34:58 pushDev nexus5-marko
2017-04-20 19:53:12 state absent
2017-04-20 05:00:01 wakeup 0
2017-04-20 18:44:40 wayhome 0
Timer:
Rr_marko_autogone:
HASH rr_Marko
MODIFIER AutoGone
NAME rr_Marko_AutoGone
Rr_marko_durationtimer:
HASH rr_Marko
MODIFIER DurationTimer
NAME rr_Marko_DurationTimer
Attributes:
alias Marko
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
event-on-change-reading state,userState,presence,wayhome,location
group Marko
icon people_sensor
room AnniKraussStr
rr_locations atwork,home,wayhome,underway
rr_presenceDevices presenceMarko
rr_realname group
rr_states home,gotosleep,asleep,awoken,absent,gone
rr_wakeupDevice rr_Marko_wakeuptimer1
sortby 0
webCmd state
nternals:
ADDRESS 7C:2F:80:98:B8:3D
CFGFN
CHANGED
DEF lan-bluetooth 7C:2F:80:98:B8:3D 10.6.6.20:5333 10 60
DeviceName 10.6.6.20:5333
FD 27
MODE lan-bluetooth
NAME presenceMarko
NOTIFYDEV global
NR 177
NTFY_ORDER 50-presenceMarko
PARTIAL
STATE present
TIMEOUT_NORMAL 10
TIMEOUT_PRESENT 60
TYPE PRESENCE
Helper:
Dblog:
Presence:
Logdbcurrent:
TIME 1492710860.21439
VALUE present
Readings:
2017-04-20 19:54:20 command_accepted yes
2017-04-20 20:56:21 daemon lepresenced V0.8
2017-04-20 19:59:48 device_battery ok
2017-04-20 19:59:48 device_batteryLevel 85
2017-04-20 20:56:21 device_name Gigaset G-tag
2016-06-11 22:57:12 lastStatusRequestState statusRequest_done
2017-04-20 19:54:20 presence present
2017-04-20 20:56:21 rssi -67
2017-04-20 20:56:21 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT present
Attributes:
absenceThreshold 24
alias G-tag
comment Batteriewechsel am 03.03.2017
event-on-change-reading presence,device_battery,device_batteryLevel
group Marko
room AnniKraussStr
stateFormat presence
timestamp-on-change-reading presence
Zitat von: CoolTux am 20 April 2017, 20:59:06
Hallo Julian,
Ich habe gestern Abend ein Update gemacht. Seit dem schalten meine Roommates nicht mehr entsprechend des presence Devices. Events werden vom present Device erzeugt, aber dem Roommate scheint das nicht zu jucken. Hat vorher super funktioniert. Auch das heutige Update bringt keine Verbesserung.
Hast Du eine Idee?
Grüße
Internals:
AUTOGONE 1492840392
CFGFN
CHANGED
DEF AnniKraussStr,Eltern
DURATIONTIMER 1492714573.26375
NAME rr_Marko
NOTIFYDEV global,rr_Marko_wakeuptimer1,presenceMarko
NR 16
NTFY_ORDER 50-rr_Marko
RESIDENTGROUPS AnniKraussStr,Eltern
STATE absent
TYPE ROOMMATE
Helper:
Dblog:
Presence:
Logdbcurrent:
TIME 1492710793.29799
VALUE absent
Readings:
2017-04-20 20:55:13 durTimerAbsence 01:02:01
2017-04-20 20:55:13 durTimerAbsence_cr 62
2017-04-20 19:53:12 durTimerPresence 00:00:00
2017-04-20 19:53:12 durTimerPresence_cr 0
2017-04-20 05:02:01 durTimerSleep 00:00:00
2017-04-20 05:02:01 durTimerSleep_cr 0
2017-04-20 18:44:40 lastArrival 2017-04-20 18:44:40
2017-04-20 05:02:01 lastAwake 2017-04-20 05:02:01
2017-04-20 19:53:12 lastDeparture 2017-04-20 19:53:12
2017-04-20 18:44:40 lastDurAbsence 11:36:46
2017-04-20 18:44:40 lastDurAbsence_cr 697
2017-04-20 19:53:12 lastDurPresence 01:08:32
2017-04-20 19:53:12 lastDurPresence_cr 69
2017-04-20 05:02:01 lastDurSleep 07:33:19
2017-04-20 05:02:01 lastDurSleep_cr 453
2017-04-20 19:53:12 lastLocation home
2017-04-20 19:53:12 lastMood calm
2017-04-19 21:28:42 lastSleep 2017-04-19 21:28:42
2017-04-20 19:53:12 lastState home
2017-04-20 04:00:00 lastWakeup 05:00
2017-04-20 04:00:00 lastWakeupDev rr_Marko_wakeuptimer1
2017-04-20 19:53:12 location underway
2017-04-20 19:53:12 mood -
2017-04-17 23:59:04 nextWakeup 05:00
2017-04-17 23:59:04 nextWakeupDev rr_Marko_wakeuptimer1
2017-04-20 19:53:12 presence absent
2016-04-21 07:34:58 pushDev nexus5-marko
2017-04-20 19:53:12 state absent
2017-04-20 05:00:01 wakeup 0
2017-04-20 18:44:40 wayhome 0
Timer:
Rr_marko_autogone:
HASH rr_Marko
MODIFIER AutoGone
NAME rr_Marko_AutoGone
Rr_marko_durationtimer:
HASH rr_Marko
MODIFIER DurationTimer
NAME rr_Marko_DurationTimer
Attributes:
alias Marko
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
event-on-change-reading state,userState,presence,wayhome,location
group Marko
icon people_sensor
room AnniKraussStr
rr_locations atwork,home,wayhome,underway
rr_presenceDevices presenceMarko
rr_realname group
rr_states home,gotosleep,asleep,awoken,absent,gone
rr_wakeupDevice rr_Marko_wakeuptimer1
sortby 0
webCmd state
nternals:
ADDRESS 7C:2F:80:98:B8:3D
CFGFN
CHANGED
DEF lan-bluetooth 7C:2F:80:98:B8:3D 10.6.6.20:5333 10 60
DeviceName 10.6.6.20:5333
FD 27
MODE lan-bluetooth
NAME presenceMarko
NOTIFYDEV global
NR 177
NTFY_ORDER 50-presenceMarko
PARTIAL
STATE present
TIMEOUT_NORMAL 10
TIMEOUT_PRESENT 60
TYPE PRESENCE
Helper:
Dblog:
Presence:
Logdbcurrent:
TIME 1492710860.21439
VALUE present
Readings:
2017-04-20 19:54:20 command_accepted yes
2017-04-20 20:56:21 daemon lepresenced V0.8
2017-04-20 19:59:48 device_battery ok
2017-04-20 19:59:48 device_batteryLevel 85
2017-04-20 20:56:21 device_name Gigaset G-tag
2016-06-11 22:57:12 lastStatusRequestState statusRequest_done
2017-04-20 19:54:20 presence present
2017-04-20 20:56:21 rssi -67
2017-04-20 20:56:21 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT present
Attributes:
absenceThreshold 24
alias G-tag
comment Batteriewechsel am 03.03.2017
event-on-change-reading presence,device_battery,device_batteryLevel
group Marko
room AnniKraussStr
stateFormat presence
timestamp-on-change-reading presence
Das kann ich leider auch nur bestätigen. Das Attribut rr_presenceDevices lässt sich nun zwar wieder mit Readings von meinem Unify AP verknüpfen, aber das Roommate Device bekommt davon nichts mit. Verknüpfe ich ein PRESENCE Device ändert dies leider auch nichts. Hatte bei mir vorher auch super funktioniert und ich habe damit sogar die Haustür auf- und zugeschlossen.
Grüße
Andreas
Supi. Haben vielen Dank. Werde ich dann gleich mal einspielen um morgen früh zu testen.
Habe gerade mal geschaut. Einzig und allein ein fehlendes s. Das ist hart ;D
Guts Nächtle
Jepp kann ich bestättigen. Heute Morgen wieder super geschalten.
Grüße
Hallo Julian,
hat sich in den letzten Updates von RESIDENTS der Initialisierungsprozess verändert?
Bis zum Update war immer sichergestellt dass nach global:INITIALIZED auch die ROOMMATE/GUEST im Hash von RESIDENTS verfügbar sind.
Das ist nun leider nicht mehr so.
Siehe: https://forum.fhem.de/index.php/topic,70882.msg623997.html#msg623997
Ich bin nun am Grübeln wie ich das vernünftig lösen kann... ???
Gruß
Dan
Zitat von: DeeSPe am 21 April 2017, 15:00:49
hat sich in den letzten Updates von RESIDENTS der Initialisierungsprozess verändert?
Wesentlich:
https://forum.fhem.de/index.php/topic,19040.msg621738.html#msg621738 (https://forum.fhem.de/index.php/topic,19040.msg621738.html#msg621738)
https://forum.fhem.de/index.php/topic,19040.msg623008.html#msg623008
Zitat von: DeeSPe am 21 April 2017, 15:00:49
Ich bin nun am Grübeln wie ich das vernünftig lösen kann... ???
NotifyOrderPrefix
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify)
Hi,
Ich hätte da auch nochmal ne Frage:
Wie füllst du das Reading lastActivityBy vom Resident?
Bei mir steht dort aktuell der Wert Anwesenheit,Michael drin.
Jetzt stellt sich bei mir die Frage ob ich da bei mir was verbogen habe oder ob das ein bug ist.
Gruß Michael
Danke Julian für die Hinweise.
Mit
$hash->{NotifyOrderPrefix} = "51-";
sind die ROOMMATE/GUEST Devices wieder da.
Muss mal schauen wie sich das evtl. noch auswirkt auf mein Modul.
Gruß
Dan
Zitat von: l2r am 21 April 2017, 18:55:12
Wie füllst du das Reading lastActivityBy vom Resident?
Bei mir steht dort aktuell der Wert Anwesenheit,Michael drin.
Jetzt stellt sich bei mir die Frage ob ich da bei mir was verbogen habe oder ob das ein bug ist.
Das liegt daran, dass du bei dem dazugehörigen ROOMMATE oder GUEST Gerät das Attribut r*_realname nicht richtig gesetzt hast.
Dort wird angegeben aus welchem Attribut der echte Name geholt werden soll. Bei einem ROOMMATE Device ist das standardmäßig das group-Attribut, bei einem GUEST Device das alias-Attribut. Wenn r*_realname nicht gesetzt ist, gilt der Default Wert.
EDIT:Ich habe das glaube ich mal vor längerer Zeit wie oben geändert, aber ich denke es macht Sinn das einheitlich auf "group" als Default zu setzen. Ich habe dafür gerade einen Patch eingecheckt.
Mein Wecker hat heute morgen leider nicht ausgelöst.
Wie kann ich das am besten nachvollziehen/debuggen?
Code-Stand ist der vom gestrigen Update - heutiges Update ist noch nicht drin.
Sollte um 08:30 auslösen (nextRun 08:45 abzüglich 15 Minuten WakeUpOffset).
Internals:
NAME rr_Andreas_wakeuptimer2
NR 158
STATE 08:45
TYPE dummy
Readings:
2017-04-22 08:26:00 nextRun 08:45
2017-04-22 08:26:00 state 08:45
Attributes:
alias Wake-up Timer 2
comment Auto-created by ROOMMATE module for use with RESIDENTS Toolkit
devStateIcon OFF:general_aus@red:reset running:general_an@green:stop .*:general_an@orange:nextRun%20OFF
group Andreas
icon time_timer
room Residents
setList nextRun:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 reset:noArg trigger:noArg start:noArg stop:noArg end:noArg wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:,andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3
sortby 2
userattr wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupMacro wakeupUserdevice wakeupAtdevice wakeupResetSwitcher wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3 wakeupWaitPeriod:slider,0,1,360
wakeupAtdevice at_rr_Andreas_wakeuptimer2
wakeupDays 0,6
wakeupDefaultTime 08:15
wakeupEnforced 0
wakeupHolidays orHoliday
wakeupMacro Macro_rr_Andreas_wakeuptimer1
wakeupOffset 15
wakeupResetdays 0,6
wakeupUserdevice rr_Andreas
webCmd nextRun
Internals:
COMMAND set rr_Andreas_wakeuptimer2 trigger
DEF *{RESIDENTStk_wakeupGetBegin("rr_Andreas_wakeuptimer2","at_rr_Andreas_wakeuptimer2")} set rr_Andreas_wakeuptimer2 trigger
NAME at_rr_Andreas_wakeuptimer2
NR 159
NTM 08:30:00
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 08:30:00
TIMESPEC {RESIDENTStk_wakeupGetBegin("rr_Andreas_wakeuptimer2","at_rr_Andreas_wakeuptimer2")}
TRIGGERTIME 1492842600
TRIGGERTIME_FMT 2017-04-22 08:30:00
TYPE at
Readings:
2017-04-22 08:26:00 state Next: 08:30:00
Attributes:
comment Auto-created by RESIDENTS Toolkit: trigger wake-up timer at specific time
computeAfterInit 1
room Residents
Laut Eventlog löst das at device pünktlich den Trigger aus, aber das war es dann auch schon...
2017-04-22 08:30:00 at at_rr_Andreas_wakeuptimer2 Next: 08:00:00
2017-04-22 08:30:00 ROOMMATE rr_Andreas nextWakeup: 08:15
2017-04-22 08:30:00 dummy rr_Andreas_wakeuptimer2 trigger
2017-04-22 08:30:00 dummy rr_Andreas_wakeuptimer2 nextRun 08:15
2017-04-22 08:30:00 dummy rr_Andreas_wakeuptimer2 nextRun: 08:15
2017-04-22 08:30:00 dummy rr_Andreas_wakeuptimer2 08:15
Ah, ok. Ich habs auf alias stehen, er scheint das aber zu ignorieren und Group zu nehmen. Den Patch teste ich nachher mal
Gesendet mit Tapatalk
Du setzt verbose auf 5 und schickst dann den set-Befehl "set rr_Andreas_wakeuptimer1 trigger". Im Logfile steht dann, weshalb der Wecker nicht ausgelöst wird.
Gruß
Julian
Hi gerade hab ich das Update gemacht und egal ob ich group oder alias auswähle. Es wird immer noch Group genommen für das Reading.
Gruß Michael
Gesendet von iPad mit Tapatalk Pro
Zitat von: l2r am 22 April 2017, 12:59:47
Hi gerade hab ich das Update gemacht und egal ob ich group oder alias auswähle. Es wird immer noch Group genommen für das Reading.
Und von welchem Modul reden wir hier?
Ich hab ein normales FHEM update gemacht da wurde ja auch Residents und ResidentStk aktualisiert
Das Attribut habe ich im Roommate auf alias gesetzt
Gruß Michael
2017.04.22 13:45:00 4: dummy set rr_Andreas_wakeuptimer2 trigger
2017.04.22 13:45:00 4: RESIDENTStk rr_Andreas_wakeuptimer2: lastRun = nextRun = 14:00
2017.04.22 13:45:00 4: RESIDENTStk rr_Andreas_wakeuptimer2: holiday restriction orHoliday in use - not triggering wake-up program this time
2017.04.22 13:45:00 4: RESIDENTStk rr_Andreas_wakeuptimer2: Resetting based on wakeupDefaultTime
Angeblich wird der Wecker wegen dem "orHoliday" Attribut nicht ausgeführt.
Das ist aber nicht korrekt, oder?
WakeupDays 0,6 or Holiday müsste für heute "true" sein.
Der Check um Zeile 2797 in RESIDENTStk.pm scheint mir nicht korrekt zu sein.
elsif (
!$forceRun
&& (
( $wakeupHolidays eq "andHoliday" && !$holidayToday )
|| ( $wakeupHolidays eq "andNoHoliday"
&& $holidayToday )
|| ( $wakeupHolidays eq "orHoliday" && !$holidayToday )
|| ( $wakeupHolidays eq "orNoHoliday"
&& $holidayToday )
)
)
Hier wird ja offenbar dann ausgestiegen, wenn "orHoliday" gesetzt ist und heute kein Holiday ist. Hier fehlt glaube ich ein Check auf !$days{$today}
Der war in einer früheren Version an dieser Stelle noch drin.
Wenn ich den bei mir an dieser Stelle einfüge, wird der Wecker ordentlich ausgeführt:
elsif (
!$forceRun
&& !$days{$today}
&& (
( $wakeupHolidays eq "andHoliday" && !$holidayToday )
|| ( $wakeupHolidays eq "andNoHoliday"
&& $holidayToday )
|| ( $wakeupHolidays eq "orHoliday" && !$holidayToday )
|| ( $wakeupHolidays eq "orNoHoliday"
&& $holidayToday )
)
)
Zitat von: l2r am 22 April 2017, 13:30:55
Ich hab ein normales FHEM update gemacht da wurde ja auch Residents und ResidentStk aktualisiert
Das Attribut habe ich im Roommate auf alias gesetzt
Ich kann das bei mir nicht nachvollziehen. Was steht denn im Attribut "alias" bei dir? Genau das wird übernommen, sofern rr_realname auf "alias" steht. Damit sich das Reading ändert, musst du aber auch einen Statuswechsel vornehmen. Die Module sind rein Event gesteuert, das einfache ändern des Attributs alleine bewirkt erstmal gar nichts, bis das nächste Event stattfindet.
Zitat von: Phiolin am 22 April 2017, 13:51:30
Der Check um Zeile 2797 in RESIDENTStk.pm scheint mir nicht korrekt zu sein.
Danke, ich habe das mal so übernommen.
Das ist klar. Bei mir ist der roommate in der Gruppe Michael und Anwesenheit drin. Bei alias steht nur Michael.
Somit möchte ich gerne alias uns nicht group verwenden.
Dass das Reading nur bei Events aktualisiert wird ist klar.ich teste das immer in dem ich mich von absent auf Home setzte oder anders rum.
Ich werde das morgen bei mir nochmal genauer unter die Lupe nehmen und versuchen dir mehr Infos zu geben
Gruß Michael
Heute hat der Wecker fast wie geplant ausgelöst.
Fast, weil wir zu der Zeit schon wach und Status "Home" waren. Sollte der Wecker nicht eigentlich nur bei "asleep" auslösen? War das nicht ursprünglich mal so?🤔
Guten Morgen,
ich habe heute ein fhem-Update durchgeführt und leider ist danach fhem beim Starten hängen geblieben. Nachdem ich die verbosity von global auf 5 gesetzt hab, kam dann zu Tage, dass folgende Logzeile mein Logfile vollmüllt:
2017.04.23 08:53:02 5: RESIDENTS [...]: device re-configuration completed
# grep 'device re-configuration completed' fhem-2017-04-23.log |wc -l
58495
Ich habe jetzt zunächst mal die alte Version (ca. 2 Wochen) von 10_RESIDENTS.pm, 20_ROOMMATE.pm , 20_GUEST.pm und RESIDENTStk.pm eingespielt und jetzt startet fhem immerhin wieder.
Wie kann ich bei der Problemfindung weiterhelfen?
LG
Christian
Zitat von: Phiolin am 23 April 2017, 08:02:32
Heute hat der Wecker fast wie geplant ausgelöst.
Fast, weil wir zu der Zeit schon wach und Status "Home" waren. Sollte der Wecker nicht eigentlich nur bei "asleep" auslösen? War das nicht ursprünglich mal so?🤔
Das ist schon immer so, da davon ausgegangen wird, dass man auch mal vergisst sich explizit schlafend zu melden (bzw. dann damit explizit den Wecker zu stellen) und man ansonsten nicht geweckt würde. Das ist bei dir wohl der Fall gewesen, ansonsten hätte die wakeupWaitPeriod bei dir gegriffen, wenn du über Nacht "asleep" warst und dich morgens vor auslösen des Weckers auf "home" gesetzt hättest. So gibt es dann allerdings keine Möglichkeit zu erkennen, ob du am letzten Abend vergessen hast dich schlafend zu schalten oder ob du bereits vor dem Wecker aufgestanden bist. Es sei denn du hättest deinen Prozess so eingestellt, dass du nach dem aufstehen in jedem Fall auch von "home" auf "awoken" oder nochmals explizit auf "home" wechselst. Dann hat ein Statuswechsel stattgefunden und wakeupWaitPeriod kann erkennen, dass du früher aufgestanden bist als der Wecker dich geweckt hätte.
Zitat von: choenig am 23 April 2017, 09:14:30
ich habe heute ein fhem-Update durchgeführt und leider ist danach fhem beim Starten hängen geblieben. Nachdem ich die verbosity von global auf 5 gesetzt hab, kam dann zu Tage, dass folgende Logzeile mein Logfile vollmüllt:
2017.04.23 08:53:02 5: RESIDENTS [...]: device re-configuration completed
# grep 'device re-configuration completed' fhem-2017-04-23.log |wc -l
58495
Das kann ich hier nicht nachvollziehen, auch nicht in meiner Produktivumgebung.
Ich vermute du setzt ein Modul ein, was auf das globale Event INITIALIZED triggert oder du hast selbst etwas dafür programmiert. Dabei wird das Event unsauber gefiltert und es wird nicht beachtet, dass das FHEM-globale Event mit dem Regex /^INITIALIZED$/ zu identifizieren ist und nicht mit /INITIALIZED/.
Mögliche Kandidaten, die ich sehe:
DUOFERNSTICK
pilight_ctrl
DOIFtools
weekprofile
Diese Modulautoren müssen ihren Code entsprechend korrigieren und die Events strikter trennen.
Zitat von: Loredo am 23 April 2017, 11:05:54
Das ist schon immer so, da davon ausgegangen wird, dass man auch mal vergisst sich explizit schlafend zu melden (bzw. dann damit explizit den Wecker zu stellen) und man ansonsten nicht geweckt würde. Das ist bei dir wohl der Fall gewesen, ansonsten hätte die wakeupWaitPeriod bei dir gegriffen, wenn du über Nacht "asleep" warst und dich morgens vor auslösen des Weckers auf "home" gesetzt hättest. So gibt es dann allerdings keine Möglichkeit zu erkennen, ob du am letzten Abend vergessen hast dich schlafend zu schalten oder ob du bereits vor dem Wecker aufgestanden bist. Es sei denn du hättest deinen Prozess so eingestellt, dass du nach dem aufstehen in jedem Fall auch von "home" auf "awoken" oder nochmals explizit auf "home" wechselst. Dann hat ein Statuswechsel stattgefunden und wakeupWaitPeriod kann erkennen, dass du früher aufgestanden bist als der Wecker dich geweckt hätte.
Tatsächlich hatte ich gestern zum testen bei diesem Wecker die wakeupWaitperiod auf 0 gesetzt und dann wohl vergessen wieder zu löschen.
Wir hatten uns gestern ordnungsgemäß "asleep" gemeldet. Heute morgen habe ich aber etwa 1 Stunde vor dem Wecker schon das "home" Setting eingestellt und der Wecker lief dann aber trotzdem planmäßig los. Hatte mich gewundert, weil ich meine, dass das früher nicht so war.
Habe jetzt das wakeupWaitPeriod Setting wieder gelöscht, bzw. auf Default gesetzt. Mal gucken, ob dass dann jetzt wieder wie vorher funktioniert. :)
Hallo zusammen,
seit einem FHEM-Update am 21.04.2017 um 10:13 Uhr bekomme ich leider regelmäßig folgende Meldung im Log-File:
Use of uninitialized value $n in hash element at fhem.pl line 3970.
Seit ich attr global verbose 5 gesetzt habe, sieht die Umgebung der Log-Meldung wie folgt aus:
2017.04.23 12:40:36 5: PRESENCE (G_Tag_Sven) - received data: present;device_name=Gigaset G-tag;rssi=-76;daemon=lepresenced V0.81
2017.04.23 12:40:36 5: Starting notify loop for G_Tag_Sven, 5 event(s), first is present
2017.04.23 12:40:36 5: statistics Statistik: Notify.266 Notification of 'G_Tag_Sven' received. Device not monitored.
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
2017.04.23 12:40:36 5: End notify loop for G_Tag_Sven
Aufgrund der Nähe zu den ROOMMATE-Meldungen könnte man die Ursache der Meldung im ROOMMATE-Modul vermuten. Dieses wurde aber zu dem oben genannten Termin bei mir nicht aktuslisiert, sondern nur das damit in Zusammenhang stehende Modul RESIDENTStk.pm.
Ggf. liegt die Ursache der Meldung aber auch im PRESENCE-Modul, das ja im oben eingefügten Log-Abschnitt Quelle des Events ist.
Ich habe auch
attr global stacktrace 1 gesetzt. Leider scheint das Attribut in diesem Fall nicht zu greifen. Vielleicht weiß ja jemand, warum das so ist oder hat einen Tipp wie ich die Ursache finden kann? Ich möchte zunächst gar nicht von einem Bug in einem der von mir verwendeten Module ausgehen, sondern kann mir vorstellen, dass evtl. auch ein Konfigurationsproblem in meiner gewachsenen FHEM-Installation besteht.
Hier ein Listing des Device rr_Sven:
Internals:
DEF rgr_Residents
DURATIONTIMER 1492945807.10855
NAME rr_Sven
NOTIFYDEV global,G_Tag_Sven
NR 113
NTFY_ORDER 40-rr_Sven
RESIDENTGROUPS rgr_Residents
STATE home
TYPE ROOMMATE
Readings:
2017-04-23 12:05:06 durTimerAbsence 00:00:00
2017-04-23 12:05:06 durTimerAbsence_cr 0
2017-04-23 13:09:07 durTimerPresence 01:04:01
2017-04-23 13:09:07 durTimerPresence_cr 64
2017-01-07 12:18:24 durTimerSleep 00:00:00
2017-01-07 12:18:24 durTimerSleep_cr 0
2017-04-23 12:05:06 lastArrival 2017-04-23 12:05:06
2017-04-23 09:25:47 lastDeparture 2017-04-23 09:25:47
2017-04-23 12:05:06 lastDurAbsence 02:39:19
2017-04-23 12:05:06 lastDurAbsence_cr 159
2017-04-23 09:25:47 lastDurPresence 14:35:56
2017-04-23 09:25:47 lastDurPresence_cr 876
2017-04-23 09:25:47 lastLocation home
2017-04-23 09:25:47 lastMood calm
2017-04-23 12:05:06 lastState absent
2017-04-23 12:05:06 location home
2017-04-23 12:05:06 mood calm
2017-04-23 12:05:06 presence present
2017-04-23 12:05:06 state home
2017-01-07 12:18:24 wayhome 0
Timer:
Rr_sven_durationtimer:
HASH rr_Sven
MODIFIER DurationTimer
NAME rr_Sven_DurationTimer
Attributes:
alias Status
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
genericDeviceType switch
group Sven
homebridgeMapping On=state,valueOn=/home|awoken|asleep|gotosleep/,valueOff=/gone|absent/,cmdOn=home,cmdOff=absent
icon people_sensor
room Homekit,Residents
rr_presenceDevices G_Tag_Sven
rr_realname group
sortby 1
webCmd state
Falls weitere Listings gebraucht werden, liefere ich diese gerne nach.
Viele Grüße
Sven
Hey,
vielen Dank für die ausführliche Antwort!
Zitat von: Loredo am 23 April 2017, 11:05:54
Das kann ich hier nicht nachvollziehen, auch nicht in meiner Produktivumgebung.
Ich vermute du setzt ein Modul ein, was auf das globale Event INITIALIZED triggert oder du hast selbst etwas dafür programmiert. Dabei wird das Event unsauber gefiltert und es wird nicht beachtet, dass das FHEM-globale Event mit dem Regex /^INITIALIZED$/ zu identifizieren ist und nicht mit /INITIALIZED/.
Mögliche Kandidaten, die ich sehe:
DUOFERNSTICK
pilight_ctrl
DOIFtools
weekprofile
Diese Modulautoren müssen ihren Code entsprechend korrigieren und die Events strikter trennen.
Von den gelisteten Modulen nutze ich 50% :-).
Ich habe mal im FHEM-Verzeichnis nach INITIALIZED ge'grep't und habe da noch ein paar andere Kandidaten gefunden, die auch nicht nach ^INITIALIZED$ filtern.
Um das ganze zu verstehen und dann auch die anderen Autoren zu informieren: Kannst Du mir kurz erklären, was hier zu der (vermutlich) Endlosschleife bei Deinem Modul führt, wenn ein anderer Modulautor da 'nen Fehler macht?
LG
Christian
hi,
ich hab nach einem shutdown restart folgendes im Log stehen:
main::RESIDENTStk_findDummySlaves() called too early to check prototype at FHEM/RESIDENTStk.pm line 3568, <$fh> line 712.
Gruß Michael
Zitat von: choenig am 23 April 2017, 15:23:50
Ich habe mal im FHEM-Verzeichnis nach INITIALIZED ge'grep't und habe da noch ein paar andere Kandidaten gefunden, die auch nicht nach ^INITIALIZED$ filtern.
Um das ganze zu verstehen und dann auch die anderen Autoren zu informieren
Ich glaube ich habe in der Liste nur Damians 98_DOIF und Martins 98_HMinfo vergessen.
Ich habe alle Modulautoren per PM angeschrieben.
Zitat von: choenig am 23 April 2017, 15:23:50
Kannst Du mir kurz erklären, was hier zu der (vermutlich) Endlosschleife bei Deinem Modul führt, wenn ein anderer Modulautor da 'nen Fehler macht?
Das lässt sich pauschal nicht sagen, da es vom jeweiligen Modul abhängt.
Grundsätzlich filtern die Module globale Events nicht streng genug.
hi Loredo,
schau dir mal bitte Zeile 1224-1230 im ResidentStk an.
Anscheinend bekommt er da das passende Attribut bzw. den Inhalt nicht korrekt ausgelesen und nimmt dann den Fallback. Wenn ich den Defaultwert auf alias setze, dann passt alles.
hier noch ein List vom meinem ROOMMATE:
Internals:
DEF rgr_Bewohner
DURATIONTIMER 1493020845.07472
NAME rr_Michael
NOTIFYDEV global,rr_Michael_wakeuptimer1,rr_Michael_wakeuptimer2,rr_Michael_wakeuptimer3,rr_Michael_wakeuptimer4,rr_Michael_wakeuptimer1_resetswitcher,rr_Michael_wakeuptimer1_resetswitcher
NR 235
NTFY_ORDER 40-rr_Michael
READY 1
RESIDENTGROUPS rgr_Bewohner
STATE home
TYPE ROOMMATE
Readings:
2017-04-24 09:58:45 durTimerAbsence 00:00:00
2017-04-24 09:58:45 durTimerAbsence_cr 0
2017-04-24 09:59:45 durTimerPresence 00:01:00
2017-04-24 09:59:45 durTimerPresence_cr 1
2017-04-24 07:16:05 durTimerSleep 00:00:00
2017-04-24 07:16:05 durTimerSleep_cr 0
2017-04-24 09:58:47 fhemMsgMail Michael angemeldet. 3 Bewohner zuhause: Carolin, Michael, Ursula
2017-04-24 09:58:47 fhemMsgMailGw mail@mail.com:OK
2017-04-24 09:58:47 fhemMsgMailPrio -1
2017-04-24 09:58:47 fhemMsgMailState 1
2017-04-24 09:58:47 fhemMsgMailTitle Anwesenheit
2017-04-24 09:58:45 fhemMsgPush Michael angemeldet. 3 Bewohner zuhause: Carolin, Michael, Ursula
2017-04-24 09:58:45 fhemMsgPushGw PushMichael:UNAVAILABLE
2017-04-24 09:58:45 fhemMsgPushPrio -1
2017-04-24 09:58:45 fhemMsgPushState 0
2017-04-24 09:58:45 fhemMsgPushTitle Anwesenheit
2017-04-24 09:58:47 fhemMsgState 1
2017-04-24 09:58:47 fhemMsgStateTypes push:0 mail:1 forwards:push>mail
2017-04-24 09:58:45 lastArrival 2017-04-24 09:58:45
2017-04-24 07:16:05 lastAwake 2017-04-24 07:16:05
2017-04-24 09:54:10 lastDeparture 2017-04-24 09:54:10
2017-04-24 09:58:45 lastDurAbsence 00:04:35
2017-04-24 09:58:45 lastDurAbsence_cr 5
2017-04-24 09:54:10 lastDurPresence 00:00:08
2017-04-24 09:54:10 lastDurPresence_cr 0
2017-04-24 07:16:05 lastDurSleep 08:42:43
2017-04-24 07:16:05 lastDurSleep_cr 523
2017-04-24 09:54:10 lastLocation home
2017-04-24 09:54:10 lastMood calm
2017-04-23 22:33:22 lastSleep 2017-04-23 22:33:22
2017-04-24 09:58:45 lastState absent
2017-04-24 06:43:04 lastWakeup 07:15
2017-04-24 06:43:04 lastWakeupDev rr_Michael_wakeuptimer1
2017-04-24 09:58:45 location home
2017-04-24 09:58:45 mood calm
2017-04-23 22:33:27 nextWakeup 07:15
2017-04-23 22:33:27 nextWakeupDev rr_Michael_wakeuptimer1
2017-04-24 09:58:45 presence present
2017-04-23 22:33:27 snooze 0
2017-04-24 09:58:45 state home
2017-04-24 07:15:06 wakeup 0
2017-03-22 15:38:18 wayhome 0
Timer:
Rr_michael_durationtimer:
HASH rr_Michael
MODIFIER DurationTimer
NAME rr_Michael_DurationTimer
Attributes:
alias Michael
devStateIcon .*home:user_available@green:gotosleep .*absent:user_away@red:home .*gone:user_ext_away@red:home .*gotosleep:scene_toilet@lightblue:asleep .*asleep:scene_sleeping@blue:awoken .*awoken:scene_sleeping_alternat@lightblue:home .*:user_unknown:home
group Anwesenheit,Michael
homebridgeMapping clear
On=state,subtype=home,valueOn=/home/,valueOff=/awoken|asleep|gotosleep|gone|absent/,cmdOn=home,cmdOff=absent
On=state,subtype=asleep,valueOn=/asleep/,valueOff=/awoken|home|gotosleep|gone|absent/,cmdOn=asleep,cmdOff=absent
On=state,subtype=awoken,valueOn=/awoken/,valueOff=/home|asleep|gotosleep|gone|absent/,cmdOn=awoken,cmdOff=absent
On=state,subtype=gotosleep,valueOn=/gotosleep/,valueOff=/home|asleep|awoken|gone|absent/,cmdOn=gotosleep,cmdOff=absent
icon people_sensor
msgContactAudio GALAXY_TAB,Sonos_Bad,Sonos_Raum,Sonos_Michael
msgContactLight HUEDevice4
msgContactMail mail@mail.com
msgContactPush PushMichael
room Homekit,Residents
rr_locationHome home 1.OG Raum Hof
rr_locations home,1.OG,Raum,Hof,underway
rr_realname alias
rr_showAllStates 1
rr_wakeupDevice rr_Michael_wakeuptimer1,rr_Michael_wakeuptimer2,rr_Michael_wakeuptimer3,rr_Michael_wakeuptimer4
sortby 1
userattr presenceDevice
webCmd state:location
Gruß Michael
EDIT: setzte ich
attr rr_realname group
dann wird dieses auch ignoriert und der Wert aus Zeile 1225 genommen. Da ich diesen von group auf alias geändert habe, wird bei mit alias genommen.
Also scheint es Probleme beim Auslesen der Werte zu geben.
Danke, ich hatte irgendwie überlesen, dass es dir um lastActivityBy geht und nicht um die Listen in residentsTotal*.
Damit ist das nun auch gefixt ;-)
alles klar,
wollte dir gerade schreiben, dass ich herausgefunden habe, dass $prefix wohl den Wert rgr_ hatte und nicht rr_
Aber wenn du es gefixt hast, dann ist alles gut.
Besten Dank!
Hi,
Zitat von: Loredo am 23 April 2017, 21:57:01
Ich habe alle Modulautoren per PM angeschrieben.
Das lässt sich pauschal nicht sagen, da es vom jeweiligen Modul abhängt.
Grundsätzlich filtern die Module globale Events nicht streng genug.
Ok, vielen Dank :)
Zitat von: Loredo am 23 April 2017, 21:57:01
Ich habe alle Modulautoren per PM angeschrieben.
Und besonders Cool: Sie haben es alle schon gefixt :)
LG
Christian
Nabend,
nach dem heutigen Update deiner Module wird bei mir der Status vom GEOFANCY nicht mehr von RESIDENTS übernommen. Kann ich das selber irgendwie beheben, oder ist da etwas schiefgelaufen? GEOFANCY zeigt den richtigen Status an, der ihm vom iPhone übermittelt wird.
EDIT: "hold the horses"... Es könnte auch sein, dass das HomeMode-Modul den Status nicht übernimmt, ich schaue mir das mal etwas genauer an.
Mea culpa, ich hatte das GEOFANCY Modul nicht auf eine interne Änderung bei ROOMMATE/GUEST angepasst. Patch ist eingecheckt.
Hallo loredo,
könntest Du evtl. mal kurz auf meinen Beitrag schauen und sagen, ob ich mit meiner Vermutung auf dem richtigen Weg bin? Oder muss ich ganz woanders schauen?
Danke und Gruß
Sven
Zitat von: cheanrod am 23 April 2017, 13:18:24
Hallo zusammen,
seit einem FHEM-Update am 21.04.2017 um 10:13 Uhr bekomme ich leider regelmäßig folgende Meldung im Log-File:
Use of uninitialized value $n in hash element at fhem.pl line 3970.
Seit ich attr global verbose 5 gesetzt habe, sieht die Umgebung der Log-Meldung wie folgt aus:
2017.04.23 12:40:36 5: PRESENCE (G_Tag_Sven) - received data: present;device_name=Gigaset G-tag;rssi=-76;daemon=lepresenced V0.81
2017.04.23 12:40:36 5: Starting notify loop for G_Tag_Sven, 5 event(s), first is present
2017.04.23 12:40:36 5: statistics Statistik: Notify.266 Notification of 'G_Tag_Sven' received. Device not monitored.
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
2017.04.23 12:40:36 5: End notify loop for G_Tag_Sven
Aufgrund der Nähe zu den ROOMMATE-Meldungen könnte man die Ursache der Meldung im ROOMMATE-Modul vermuten. Dieses wurde aber zu dem oben genannten Termin bei mir nicht aktuslisiert, sondern nur das damit in Zusammenhang stehende Modul RESIDENTStk.pm.
Ggf. liegt die Ursache der Meldung aber auch im PRESENCE-Modul, das ja im oben eingefügten Log-Abschnitt Quelle des Events ist.
Ich habe auch
attr global stacktrace 1 gesetzt. Leider scheint das Attribut in diesem Fall nicht zu greifen. Vielleicht weiß ja jemand, warum das so ist oder hat einen Tipp wie ich die Ursache finden kann? Ich möchte zunächst gar nicht von einem Bug in einem der von mir verwendeten Module ausgehen, sondern kann mir vorstellen, dass evtl. auch ein Konfigurationsproblem in meiner gewachsenen FHEM-Installation besteht.
Hier ein Listing des Device rr_Sven:
Internals:
DEF rgr_Residents
DURATIONTIMER 1492945807.10855
NAME rr_Sven
NOTIFYDEV global,G_Tag_Sven
NR 113
NTFY_ORDER 40-rr_Sven
RESIDENTGROUPS rgr_Residents
STATE home
TYPE ROOMMATE
Readings:
2017-04-23 12:05:06 durTimerAbsence 00:00:00
2017-04-23 12:05:06 durTimerAbsence_cr 0
2017-04-23 13:09:07 durTimerPresence 01:04:01
2017-04-23 13:09:07 durTimerPresence_cr 64
2017-01-07 12:18:24 durTimerSleep 00:00:00
2017-01-07 12:18:24 durTimerSleep_cr 0
2017-04-23 12:05:06 lastArrival 2017-04-23 12:05:06
2017-04-23 09:25:47 lastDeparture 2017-04-23 09:25:47
2017-04-23 12:05:06 lastDurAbsence 02:39:19
2017-04-23 12:05:06 lastDurAbsence_cr 159
2017-04-23 09:25:47 lastDurPresence 14:35:56
2017-04-23 09:25:47 lastDurPresence_cr 876
2017-04-23 09:25:47 lastLocation home
2017-04-23 09:25:47 lastMood calm
2017-04-23 12:05:06 lastState absent
2017-04-23 12:05:06 location home
2017-04-23 12:05:06 mood calm
2017-04-23 12:05:06 presence present
2017-04-23 12:05:06 state home
2017-01-07 12:18:24 wayhome 0
Timer:
Rr_sven_durationtimer:
HASH rr_Sven
MODIFIER DurationTimer
NAME rr_Sven_DurationTimer
Attributes:
alias Status
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
genericDeviceType switch
group Sven
homebridgeMapping On=state,valueOn=/home|awoken|asleep|gotosleep/,valueOff=/gone|absent/,cmdOn=home,cmdOff=absent
icon people_sensor
room Homekit,Residents
rr_presenceDevices G_Tag_Sven
rr_realname group
sortby 1
webCmd state
Falls weitere Listings gebraucht werden, liefere ich diese gerne nach.
Viele Grüße
Sven
Zitat von: cheanrod am 27 April 2017, 07:10:50
könntest Du evtl. mal kurz auf meinen Beitrag schauen und sagen, ob ich mit meiner Vermutung auf dem richtigen Weg bin? Oder muss ich ganz woanders schauen?
Vielleicht habe ich was gefunden, habe eine Änderung eingecheckt.
Zitat von: Loredo am 27 April 2017, 09:45:44
Vielleicht habe ich was gefunden, habe eine Änderung eingecheckt.
Danke, ich probiere es heute Abend aus und gebe Rückmeldung.
Viele Grüße
Sven
ZitatDanke, ich probiere es heute Abend aus und gebe Rückmeldung.
Die Änderung scheint geholfen zu haben. Ich habe keine Warnings mehr im Log-File. Vielen Dank, loredo!
Viele Grüße
Sven
Guten Morgen,
heute morgen (1.Mai) hat mich mein Wecker geweckt, obwohl ich
wakeupHolidays andNoHoliday
gesetzt habe und mein FHEM auch korrekterweise heute einen Feiertag erkennt.
Darauf hin habe ich mir mal den Code angesehen und bin der Meinung, dass da ein Fehler drin ist.
Im Folgenden ist ein ungetesteter Patch (!) von mir, der meiner Meinung nach das Logik-Problem behen sollte.
--- /tmp/RESIDENTStk.pm 2017-05-01 08:43:32.530310503 +0200
+++ RESIDENTStk.pm 2017-05-01 08:51:41.747744202 +0200
@@ -2802,15 +2800,16 @@
}
elsif (
!$forceRun
- && !$days{$today}
- && (
- ( $wakeupHolidays eq "andHoliday" && !$holidayToday )
- || ( $wakeupHolidays eq "andNoHoliday"
- && $holidayToday )
- || ( $wakeupHolidays eq "orHoliday" && !$holidayToday )
- || ( $wakeupHolidays eq "orNoHoliday"
- && $holidayToday )
- )
+ && (( $days{$today} &&
+ (( $wakeupHolidays eq "andHoliday" && !$holidayToday ) ||
+ ( $wakeupHolidays eq "andNoHoliday" && $holidayToday ))
+ )
+ ||
+ ( !$days{$today} &&
+ (( $wakeupHolidays eq "orHoliday" && !$holidayToday ) ||
+ ( $wakeupHolidays eq "orNoHoliday" && $holidayToday ))
+ )
+ )
)
{
Log3 $NAME, 4,
Im duplizierten Code im Bereich der Zeilen 3165ff sieht es richtig aus.
LG
Christian
P.S.: Ich habe den Patch auf Lesbarkeit optimiert, nicht auf die Perl-typische Kompaktheit ;-).
Genau das ist mir heute auch passiert und ich bin auf genau die gleiche Anpassung gekommen wie du, hatte den Post auch schon fertig. :)
Werde das bei mir jetzt auch so testen.
Dito, 04:55 Uhr war die Nacht (vorerst) zu Ende.
Ich denke, dass ist nen Feature, ist ja schließlich "Tag der Arbeit", das hat das Modul wohl erkannt und automatisch auf Werktag geschaltet.
Hallo Julian,
Ich habe da noch ein Problem in Verbindung mit Presence. Wenn das Presence Device für eine Sekunde auf disconnected geht und danach korrekt wieder absent erkennt, wird der Status des Roommate dennoch auf home gestellt. Solltest Du da noch fragen haben, kann ich das gerne nachstellen.
Grüße
Leon
Zitat von: choenig am 01 Mai 2017, 09:22:34
Im Folgenden ist ein ungetesteter Patch (!) von mir, der meiner Meinung nach das Logik-Problem behen sollte.
Danke, ich habe den Patch so übernommen.
Zitat von: CoolTux am 01 Mai 2017, 11:30:54
Ich habe da noch ein Problem in Verbindung mit Presence. Wenn das Presence Device für eine Sekunde auf disconnected geht und danach korrekt wieder absent erkennt, wird der Status des Roommate dennoch auf home gestellt. Solltest Du da noch fragen haben, kann ich das gerne nachstellen.
Das müsste im PRESENCE Modul abgefangen werden. Dort gibt es ein Attribut, welches das Event verzögert. Offenbar funktioniert es dann wohl nicht richtig, wenn der Status auf disconnected wechselt. Die IMHO übermäßige und unnütze Event-Wut vom PRESENCE Modul begegnet man übrigens am besten mit dem Attribut "event-on-change-reading presence".
Gruß
Julian
Hallo,
seitdem ich das letzte Mal upgedated habe ist mir aufgefallen das der STATE jede Minute neu gesetzt wird.
Das verträgt sich mit meinem DOIF nicht so richtig.
Gibt es einen Grund STATE neu zu setzten obwohl sich nichts geändert hat? Gibt es einen Workaround oder so?
Zitat von: oberlon am 01 Mai 2017, 21:51:35
seitdem ich das letzte Mal upgedated habe ist mir aufgefallen das der STATE jede Minute neu gesetzt wird.
Das verträgt sich mit meinem DOIF nicht so richtig.
Gibt es einen Grund STATE neu zu setzten obwohl sich nichts geändert hat? Gibt es einen Workaround oder so?
Das Modul setzt STATE überhaupt gar nicht selbst. Die Readings werden außerdem nur bei einer Änderung aktualisiert. Es ist also vermutlich in deiner Automation ein Fehler, der den Status schnell hintereinander ändert.
Am DOIF hat sich nichts geändert. Sieht ca so aus:
([rgr_Bewohner] eq 'home' and [?Twilight:twilight_weather] <= 60) (set lightscene scene lichtAn)
Im DOIF wird ein Reading mit dem Namen e_rgr_Bewohner_STATE erstellt und jede Minute aktualisiert.
Im Event-Monitor dazu
2017-05-01 22:57:58.354 RESIDENTS rgr_Bewohner durTimerPresence_cr: 594
2017-05-01 22:57:58.354 RESIDENTS rgr_Bewohner durTimerPresence: 09:54:03
Das DOIF löst also jedes mal aus wenn durTimerPresence_cr und durTimerPresence auftauchen.
Das war bis vor kurzem noch nicht so das STATE dadurch angefasst wird.
Sicher das es nicht an RESIDENTS liegt?
Das ist schonmal nicht STATE ;-)
Das RESIDENTS Modul unterstützt seit einiger Zeit ebenfalls den Duration Timer.
Die Filterung in einem DOIF ist zu ungenau und reagiert auf sämtliche Reading Änderungen, nicht nur der Duration Readings, das solltest du einschränken. Alternativ kannst du den Duration Timer mit dem Attribut rgr_noDuration abschalten.
Auf STATE bin ich nur gekommen weil DOIF ein Reading anlegt mit e_rgr_Bewohner_STATE.
Vorerst nutze ich jetzt ([rgr_Bewohner:residentsTotalPresent] != 0).
Das verhalten war dennoch mal anders. ???
DOIF gibt ofter mal Rätsel auf. Mir persönlich ist es inzwischen zu komplex. Hatte auch schon Änderungen und vertraue dem Modul deshalb nicht mehr bei wichtigen Sachen.
Gruß
Julian
Zitat von: Loredo am 01 Mai 2017, 23:45:56
DOIF gibt ofter mal Rätsel auf. Mir persönlich ist es inzwischen zu komplex.
Hm, über RESIDENTS könnte man gleiches sagen!
Den Großteil der "Eventflut" konnte ich erfolgreich mit
attr rr.* event-on-change-reading (?!(durTimer|lastActivity)).*eindämmen. Ich will ja die durTimer nicht loswerden, sie sollen sich halt nur melden, wenn sie gefragt werden.
Zitat von: Per am 02 Mai 2017, 10:18:31
Hm, über RESIDENTS könnte man gleiches sagen!
Touché ;)
Da bin ich allerdings nicht neutral, denn da habe ich es zumindest selbst in der Hand und kann aktiv Einfluss nehmen.
Zitat von: Per am 02 Mai 2017, 10:18:31
Den Großteil der "Eventflut" konnte ich erfolgreich mit
attr rr.* event-on-change-reading (?!(durTimer|lastActivity)).*
eindämmen. Ich will ja die durTimer nicht loswerden, sie sollen sich halt nur melden, wenn sie gefragt werden.
Kann man so machen. Allerdings ändern sich die Zahlen beim Duration Timer ja tatsächlich auch, deshalb wird es so nichts helfen.
Der richtige Ansatz ist das DOIF richtig zu definieren, so dass dort auch nur auf das Event reagiert wird, welches beabsichtigt ist.
Zitat von: Loredo am 02 Mai 2017, 10:33:40Allerdings ändern sich die Zahlen beim Duration Timer ja tatsächlich auch, deshalb wird es so nichts helfen.
Dürfen sie ja auch. Ich (!) brauche nur keinen Event dafür, deshalb der o.a. Filter.
Zitat von: Loredo am 02 Mai 2017, 10:33:40Der richtige Ansatz ist das DOIF richtig zu definieren, so dass dort auch nur auf das Event reagiert wird, welches beabsichtigt ist.
Ja, wenn man an anderer Stelle auf ein Event des DT (z.B. seit 3 Stunden keiner zu Hause...) reagieren will, muss man das so machen, ansonsten hilft der Filter schon für Platz im EventLog.
@Per
Danke für den Regex. Gleich mal mit aufgenommen.
Ansonsten konnte ich jetzt mein Problem lösen indem ich im DOIF direkt auf das Reading [rgr_Bewohner:state] lausche. Zusätzlich ist das Attribut checkReadingEvent notwendig damit e_rgr_Bewohner_state im DOIF nicht bei jedem Event von rgr_Bewohner aktualisiert wird.
Fehlt checkReadingEvent wird durch durTimer* das Reading e_rgr_Bewohner_state jede Minute aktualisiert und führt dann bei mir in Verbindung mit Twilight zu einem schalten des Lichts obwohl ich lange daheim bin.
Warum der alte Ausdruck im DOIF lange Zeit funktioniert hat... Keine Ahnung.
Zitat von: Loredo am 02 Mai 2017, 10:33:40
Der richtige Ansatz ist das DOIF richtig zu definieren, so dass dort auch nur auf das Event reagiert wird, welches beabsichtigt ist.
Damit hast du recht.
Mir war bis jetzt nur nicht bewusst, dass egal welches Event vom Device kommt alle Readings im DOIF aktualisiert werden. Und da geht es mir bestimmt nicht als einzigen so.
z.B. wird [rgr_Bewohner:presence] auch dann im DOIF aktualisiert wenn sich nur durTimerAbsence ändert. In Kombination mit anderen Devices (Twilight oder Zeit) können da komische Dinge bei rum kommen.
Für dieses Problem gibt es im DOIF das Attribut "checkReadingEvent (https://fhem.de/commandref_DE.html#DOIF_checkReadingEvent)". Damit wird das DOIF nur aktualisiert, wenn genau die im DOIF angegebenen Readings aktualisiert werden.
Für Interessierte:
Für das hier einmal vor Zeiten angekündigte, ergänzende Modul 00_HOMESTATE habe ich gerade eine separate Diskussion eröffnet:
https://forum.fhem.de/index.php/topic,71692.0.html (https://forum.fhem.de/index.php/topic,71692.0.html)
Gruß
Julian
Hallo,
ich verwende bei meinen ROOMMATE Geräten als rr_presenceDevices Attribut, Readings von WLAN meinem AccessPoint. Ist in den Readings nun das entsprechende Gerät nicht vorhanden steht der ROOMMATE Status auf "home". Wäre es nicht sinnvoller diesen auf "absent" zu stellen, falls das Reading nicht existiert. Zumindest bei mir bereitet das im Moment leichte Probleme.
Grüße
Andreas
Zitat von: acw81 am 21 Mai 2017, 14:46:50
ich verwende bei meinen ROOMMATE Geräten als rr_presenceDevices Attribut, Readings von WLAN meinem AccessPoint. Ist in den Readings nun das entsprechende Gerät nicht vorhanden steht der ROOMMATE Status auf "home". Wäre es nicht sinnvoller diesen auf "absent" zu stellen, falls das Reading nicht existiert. Zumindest bei mir bereitet das im Moment leichte Probleme.
Eher anders herum: Die meisten Nutzer werden Probleme haben, wenn sie plötzlich aufgrund einer irrtümlichen Annahme oder eines Fehler als "abwesend" bewertet werden, weil ein Reading fehlt. Da stehen dann Leute im dunkeln und können womöglich nichtmal mehr was schalten ;)
Der Sinn dieses Attributes ist, dass nur dann auf abwesend geschaltet wird, wenn dies mit hoher Wahrscheinlichkeit auch die richtige Annahme ist. Für jemanden, der eine andere Logik benötigt, ist dieses Attribut nichts und man kann das ganze problemlos über Notify, DOIF oder Watchdog nach der Logik lösen, wie man es selbst braucht.
Ja, muss ich dann wohl so lösen. Bei mir war das Problem, dass trotz Anwesenheit die Haustür nicht abgeschlossen wurde und das Licht an war.
Ich habe folgende Art der Schaltung:
- Ich habe die Geo Überwachung und einen Schalter, welcher gedrückt wird für an und Abwesenheit.
- Ein Dummy erhält sowohl für Geo, als auch für den Schalter das Reading absent / present
- Ein DOIF setzt den Status des Dummy auf absent bzw present (priorisiert wird der Schalter)
- Roommate schaltet die Anwesenheit unter Bezug auf den Dummy (rr_presenceDevices -> AE.Dummy.Etienne)
Früher war es so, dass ich darüber informiert wurde, wenn Schalter und Geo unterschiedliche Zustände haben. Nun ist mir aufgefallen, dass automatisch mit dem Drücken des Schalters auch die Location verändert wird. Loredo hast du was am Code geändert? Ein Verbose 5 hat mir im Log folgendes gezeigt:
ROOMMATE rr_Etienne: implicit location change caused by state absent
Soll heißen, wird nun die Location automatisch geändert, wenn das presenceDevice sich ändert? Ich dachte Location steht wird immer über die Geolocation geholt? Ist es möglich dann noch das Reading GeoLocation einzuführen, welches sich nur über den Geo Status ändert? Sonst bekomme ich keine Erinnerung mehr, wenn jemand zuhause ist und den Schalter nicht gedrückt hat bzw. Abwesend und den Schalter vergessen hat.
Hallo Zusammen,
ich habe eine Frage die ich durch suchen noch nicht beantworten konnte. Eventuell auch weil ich nicht weiß nach was ich genau suchen muss.
Die Module sind eine große Hilfe um nicht alles händisch zu machen. Daher steuere ich über die Anwesenheit auch alle Rolladen.
Jedoch hätte ich gerne eine "Sonderlösung":
In der Nacht ist der Status des Resident Device asleep. Sobald morgens der Wecker für den ersten Bewohner geht wird dieser auf home gesetzt. Und jetzt kommt die Frage:
Wie kann ich dies am besten Abfangen das in dem Moment mindestens eine Rollade nicht geöffnet wird? Ich löse das aktuell mit einem Doif:
##3 - Rollo hoch wenn zu Hause
DOELSEIF
([K29a:state] eq "home"
and [$SELF:Automatik] eq "an")
(set OG.wz.RO.FensterTerrasse:FILTER=pct!=100 pct 100)
Hat da jemand noch eine andere Idee wo ich gerade blind für bin? Vielleicht mit anderen Funktionen aus dem Modul?
Hallo Leute
Ich habe ein Problem mit Roommate und Geofancy.
Hardware: S7 Edge, Android 7, Egigeo (Ausnahme bei den Energiesparmaßnahmen). Raspbi 3, Zugang per SSL über Port 8083. Ubee Router der kein NAT Loopback unterstützt.
Eine Zone (mein Zuhause)+150Meter, ich Roommate mit der UUID. Keine notifys, schleifen, dummys oder sonst irgendwas. Ich möchte einfach nur "home" bei betreten der Zone und "absent" beim Verlassen der Zone haben.
Zwei Serverprofile eingerichtet, einmal mit der internen IP meines Pi im Wlan und eine mit meiner externen IP. Serverprofil mit Wifi-IP verwende ich als Ausfallserver, sofern das Betreten der Zone noch nicht über 3G/Lte gesendet wurde, bevor ich das Wlan betreten habe.
Mit beiden Serverprofilen erreiche ich im Wlan bzw. Internet meinen Pi. Auch das Betreten und Verlassen der Zonen wird mir am Handy unter den Notifications richtig gezeigt. Aber das Roommatedevice tut IRGENDWAS.
Gerade eben heimgekommen, und war mehr als 10h außer Haus:
lastArrival
2017-06-09 19:54:56
lastDeparture
2017-06-09 19:52:29
Heute morgen schon wieder. EgiGeoZone meldet um 8:40Uhr korrekt, dass ich die Zone verlassen habe. FHEM meint dazu:
lastArrival
2017-06-12 08:20:19
2017-06-12 08:20:19
lastDeparture
2017-06-12 08:15:23
2017-06-12 08:15:23
Ich werde nicht schlau aus der Sache.
Hallo,
ich habe eine Frage zum Reading "location". Lt. Beschreibung "location - the current location".
Ich habe 2 Zonen. Home + Work. Home ist auch status home zugeordnet und State presence oder absent / gone funktioniert alles wunderbar.
Das Reading location wird gesetzt wenn ich home oder work betrete. Es bleibt aber gesetzt solange bis ich eine andere Zone betrete. Kann ich das irgendwie beeinflussen? Ich würde erwarten, dass es auf away oder woanders hin wechselt wenn ich die Zone verlasse.
Ich habe aktuell ein userreading in dem ich locationpresence + location kombiniert auswerte, ich sehe dort, dass die Information an Fhem geliefert werden.
Ist das gewolltes Verhalten? Wenn ja, wofür ist das so eingebaut worden, ich möchte nicht kritisieren, würde es halt gerne verstehen.
Danke!
Ist-Verhalten
Event | Reading location | Reading location - erwarteter Status | Reading locationPresence |
Home betreten | home | home (OK) | present |
Home verlassen | home | away | away |
Work betreten | work | work (OK) | present |
Work verlassen | work | away | away |
]
Internals:
DEF Residents
NAME rr_S6
NOTIFYDEV global,
NR 622
NTFY_ORDER 50-rr_S6
READY 1
RESIDENTGROUPS Residents
STATE home
TYPE ROOMMATE
Helper:
DBLOG:
location_real:
myDbLog:
TIME 1501834840.41013
VALUE home
READINGS:
2017-08-03 20:28:35 lastArrival 2017-08-03 20:28:35
2017-08-01 19:41:37 lastDeparture 2017-08-01 19:41:37
2017-08-03 20:28:35 lastDurAbsence 48:46:58
2017-08-03 20:28:35 lastDurAbsence_cr 2927
2017-08-01 19:41:37 lastDurPresence 00:00:04
2017-08-01 19:41:37 lastDurPresence_cr 0
2017-08-03 20:28:35 lastLocation work
2017-08-03 20:28:35 lastLocationAddr -
2017-08-03 20:28:35 lastLocationLat xxxx
2017-08-03 20:28:35 lastLocationLong xxx
2017-08-01 19:41:37 lastMood calm
2017-08-03 20:28:35 lastState gone
2017-08-03 20:28:35 location home
2017-08-03 20:28:35 locationAddr -
2017-08-03 20:28:35 locationLat 4xxxx
2017-08-03 20:28:35 locationLong 1xxxx
2017-08-03 20:28:35 locationPresence present
2017-08-03 20:28:35 location_real home
2017-08-03 20:28:35 mood calm
2017-08-03 20:28:35 presence present
2017-08-03 20:28:35 state home
2017-07-14 19:27:29 wayhome 0
TIMER:
Attributes:
alias Galaxy S6
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
event-on-change-reading location_real,state
group Home Status
icon people_sensor
room Status
rr_autoGoneAfter 0.25
rr_geofenceUUIDs 82c29acf-xxxxx
rr_locationHome home
rr_noDuration 1
rr_realname alias
rr_states home,absent
sortby 2
userReadings location_real { if( ReadingsVal("rr_S6","locationPresence","err") ne "present" ) { sprintf("away")} else { ReadingsVal("rr_S6","location","err");; } }
webCmd state
setz mal das Attribut rr_locations home, away, work
dann kennt er auch away.
Gruß Michael
Zitat von: l2r am 04 August 2017, 13:03:12
setz mal das Attribut rr_locations home, away, work
dann kennt er auch away.
Gruß Michael
werde ich mal testen ... thx
Hallo,
ich würde gerne beim "rr_Inoma" Device als 4-tes Feld / Setter die Weckzeit einstellen können, also etwa so
attr rr_Inoma webCmd state:location:mood:nextRunwobei "nextRun" dann das nextRun vom rr_Inoma_wakeuptimer1 einstellen würde, damit ich alle 4 setter für rr_Inoma einer Zeile habe, sonst brauche ich für den Wecker im Frontend eine eigene Zeile.
Leider hat das Device "rr_Inoma" kein Attribut setList, so dass ich keinen neuen Setter definieren kann. Hat einer eine Idee?
Danke und Gruss!
Hallo,
ich habe G-Tags am Schlüssel für die Steuerung (PRESENCE) des Status Home|Absent - das klappt soweit so gut.
Jetzt kommt es aber vor, dass meine Freundin Ihre Schlüssel in der Wohnung lässt und mit mir zusammen weg geht. Bei mir geht der Status ja automatisch auf Absent, aber wie mache ich es mit dem G-Tag meiner Freundin. Der meldet ja Home.
Kann man für diese Sonderfälle einen extra Status einrichten?
Also z.B. den Status auf "tour" setzen und dann das notify bei Status "tour" nicht auslösen...
Mit diesem notify mache ich den Statuswechsel
GTagOrange:present
{if (Value("rr_Peg") ne "gotosleep")
{fhem("set rr_Peg:FILTER=STATE!=home home");}
}
GTagOrange:absent
{if (Value("rr_Peg") ne "gone")
{fhem("set rr_Peg:FILTER=STATE!=absent absent");}
}
Da hilft dann nur über's Handy einwählen und von Hand auf absent setzen oder versuchen der Freundin zu erklären wieso es besser ist wenn sie den Schlüssel immer mit nimmt.
Im übrigen denke ich nicht das Dein "Problem" von einem Modul gelöst werden sollte. Man kann und sollte keine speziellen Situationen abbilden in einem Modul.
Zitat von: CoolTux am 14 August 2017, 17:47:26
Da hilft dann nur über's Handy einwählen und von Hand auf absent setzen oder versuchen der Freundin zu erklären wieso es besser ist wenn sie den Schlüssel immer mit nimmt.
Im übrigen denke ich nicht das Dein "Problem" von einem Modul gelöst werden sollte. Man kann und sollte keine speziellen Situationen abbilden in einem Modul.
Naja, der Status wird vom Modul vermutlich wieder zurück gesetzt bei der nächsten Abfrage der G-Tags, daher wird ein Ändern von Hand nicht wirklich sinnvoll sein. Kann mich aber irren. Somit wäre die Idee einen "manuelle Änderung", welche nicht durch die G-Tags / Geofence / etc geändert werden kann schon nicht verkehrt.
Zitat von: Amenophis86 am 14 August 2017, 17:54:32
Naja, der Status wird vom Modul vermutlich wieder zurück gesetzt bei der nächsten Abfrage der G-Tags, daher wird ein Ändern von Hand nicht wirklich sinnvoll sein. Kann mich aber irren. Somit wäre die Idee einen "manuelle Änderung", welche nicht durch die G-Tags / Geofence / etc geändert werden kann schon nicht verkehrt.
Wenn man es richtig macht wird nichts zurück gesetzt. Meine Freundin ist seit heute Morgen im Urlaub, GTab ist hier geblieben und sie ist auf absent gestellt. Alles schick.
Das heißt lepresenced setzt bei dir den Status nicht wieder zurück. Und wie macht man es richtig? :)
event-on-change-reading presence,device_battery,device_batteryLevel
Oder disbale des Gtag habe ich gerade überlegt. Aber deine Version geht auch, stimmt. Danke
Hallo zusammen,
ich habe ein Problem und finde einfach nicht die Lösung.
Ich habe 2 Dummys, die jeweils 2 Readings haben (Key und Mobile). Das Reading Key wird vom jeweiligen iButton auf present/absent, das gleiche passiert über ein Presence Device, der mit der Fritzbox verknüpft ist.
Ich habe nun 2 Roommates, die mit dem jeweiligen Dummy und dessen Readings verknüpft sind (attr roommate1 rr_presenceDevices dummy1:Key,dummy1:Mobile).
Und nun zu meinem Problem:
Bei dem einen Roommate funktioniert das ganze einwandfrei. Sobald eines der Readings auf "present" steht, wird der Status geändert. Genauso umgekehrt, wenn alle Readings auf "absent" stehen.
Bei dem 2. Roommate allerdings passiert gar nichts.
Ich habe den 2. Roommate schon automatisch über den Resident-Device erzeugt und auch schon manuell angelegt. Die Readings, Attribute und Settings habe ich auch schon alle verglichen.
Ich könnte ja einfach mit Notifys arbeiten, aber wenn ich das richtig verstanden habe, brauche ich ja durch das Attribut "rr_presenceDevices" eigentlich kein Notify. Oder habe ich da was falsch verstanden?
Danke schonmal für eure Hilfe.
Hallo,
Du hast das schon richtig verstanden und Dein einer Roommate macht es ja auch korrekt.
Am Ende macht der Roommate nichts anderes wie ein Notify, er reagiert auf Events. Schau Mal im Eventmonitor was für Events Dein Dummy wirft. Und stell man ein liest von den beiden Roommates ein und eines vom Dummy der zum nicht funktionierenden Roommate gehört.
Grüße
Ich verstehe nicht, was die ganze Zeit das Problem war, aber als ich eben die Events abgefragt habe, funktionierte es jetzt plötzlich mit beiden Roommates.
Naja, Hauptsache es funktioniert jetzt. Sollte ich noch dahinterkommen, was schlussendlich die Ursache war, melde ich mich wieder :)
Danke schonmal :)
Hallo alle zusammen,
anbei ein Bild was ich gerne machen möchte, vielleicht kann mir jemand einen Schubs in die richtige Richtung geben.
Ich würde gerne beim "rr_Inoma" Device, als 4-tes Feld/Setter die Weckzeit einstellen können, also etwa so, wie auch im angehängten Bild unter "Nachher"
attr rr_Inoma webCmd state:location:mood:nextRun
wobei "nextRun" dann das nextRun vom rr_Inoma_wakeuptimer1 einstellen würde, damit ich alles für rr_Inoma einer Zeile habe, sonst brauche ich für den Wecker im Frontend eine eigene Zeile.
Hast Jemand eine Idee, wie man das einfach machen kann, ohne alles mit einem Dummy umständlich zu verdoppeln?
Danke und Gruss!
schau dir cmdalias und widgetOverride an. oder readingsGroup.
Hallo Justme,
für "cmdalias und widgetOverride" brauche ich aber das attribut "setList", das gibts im rr_Inoma aber nicht.
Dann nur Readingsgroup, oder?
nein. brauchst du nicht. beides hat nichts mit setList zu otun.
Hallo Andre,
Zitatnein. brauchst du nicht. beides hat nichts mit setList zu otun.
Ich habe jetzt folgendes:
attr rr_Inoma webCmd state:location:mood:nextRun
attr rr_Inoma widgetOverride nextRun:OFF,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00damit siehts schon so aus wie ich es haben möchte (siehe Bild), allerdings kommt dann beim setzten immer
ZitatUnknown argument nextRun, choose one of state:home,gotosleep,asleep,awoken,absent,gone mood:.......... create:wakeuptimer,locationMap
Wie verknüpfe ich das jetzt mit dem wakeuptimer?
Hallo Andre,
danke! Ich habs jetzt gelöst, wie im unten im Bild. Das funktioniert auch.
Aber, nach einem 'refresh' oder 're-load' der fhem website wird das drop-down vom nextRun menu 'leer' (ich weiss nicht wie ich es anders beschreiben soll).
Kann man das ändern, dass das drop-down menue vom nextRun die eingestellte Zeit behält?
attr rr_Inoma webCmd state:location:mood:nextRun
attr rr_Inoma widgetOverride nextRun:OFF,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00
und das cmdaliasInternals:
ALIAS set
CFGFN
DEF set rr_Inoma nextRun .* AS {fhem ("set rr_Inoma_wakeuptimer1 nextRun $EVTPART2")}
NAME c_rr_Inoma
NEWCMD {fhem ("set rr_Inoma_wakeuptimer1 nextRun $EVTPART2")}
NR 5237
PARAM rr_Inoma nextRun .*
STATE defined
TYPE cmdalias
Attributes:
Moin,
versuch mal das attr readingList auf nextRun zu setzen.
Mmmh, das Device rr_Inoma hat kein 'attr readingList'. Oder habe ich das falsch verstanden?
Stimmt, sorry, hatte ich übersehen
So, ist gelöst, wie folgt. Ich habe dem cmdalias noch ein 'setreading rr_Inoma nextRun $EVTPART2' mitgegeben, und dem 'rr_Inoma' ein 'attr userReadings nextRun'. Damit funktionierts!
Mein dank an Andre!!!
attr rr_Inoma userReadings nextRun
attr rr_Inoma webCmd state:location:mood:nextRun
attr rr_Inoma widgetOverride nextRun:OFF,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00
und das cmdaliasInternals:
ALIAS set
CFGFN
DEF set rr_Inoma nextRun .* AS {fhem ("set rr_Inoma_wakeuptimer1 nextRun $EVTPART2;setreading rr_Inoma nextRun $EVTPART2")}
NAME c_rr_Inoma
NEWCMD {fhem ("set rr_Inoma_wakeuptimer1 nextRun $EVTPART2;setreading rr_Inoma nextRun $EVTPART2")}
NR 5237
PARAM rr_Inoma nextRun .*
STATE defined
TYPE cmdalias
Attributes:
Hallo.
Danke für das Modul, bin grad am einrichten, aber als Anfänger sehr viele Fragen:
Habe es vor einer Woche nie zusammengebracht dass sich der Status der Roommates ändert.
Nun wieder Zeit, weiter zu experimentieren ;)
Bei den roommates waren die richtigen Presences hinterlegt: "rr_presenceDevices P_BT_Tobias,P_WIFI_Tobias", diese Presences änderten sich auch, aber nicht der Roommate.
Folgende Fragen habe ich nicht dazu:
- Muss ich mittels Notify wie in https://wiki.fhem.de/wiki/PRESENCE Beschrieben unter Punkt "Mit Notify und Integration des RESIDENTS-MODUL" das Residents Modul über die Änderungen informieren?
- Oder sollte das automatisch gehen wenn die rr_presenceDevices zugeordnet sind?
- Übernimmt das Roommate Modul auch die location automatisch, oder muss das auch mit Notify gemacht werden.
- Habe jetzt ein "event-on-change-reading state" in den Presences, liege ich Richtig der Annahme dass dies ein Update z.B.: der Location verhindern würde?
Fragen über Fragen :-)
Danke pOpY
Von den unter rr_presenceDevices angegebenen Geräten sollte das Reading "presence" automatisch auf das Roommate Device übernommen werden.
Für den "absent" Status bedeutet das übrigens, dass ALLE angegebenen Geräte "absent" sein müssen, um den Roommate auf "absent" zu setzen. Umgekehrt reicht es für den Status "present" aus, wenn ein Gerät wieder erreichbar ist um den Roommate auch auf "present" zu setzen.
Bezüglich event-on-change-reading, würde ich vermuten, dass du zumindest auch das "presence" Reading dort aufnehmen musst, damit das funktioniert. Bei mir habe ich jeweils state,presence und room im event-on-change-reading bei den Presence Devices.
Die Location des Roommate Devices musst du selber z.B. über ein Notify setzen. Das bringt dir auch entsprechende Flexibilität, z.B. wenn ein Presence Device eine höhere Priorität bei der Location haben soll als ein anderes.
Ich hatte bei mir z.B. die Apple Watch entsprechend höher priorisiert als das iPhone, da es wahrscheinlicher ist, dass ich mit der Uhr durch das Haus laufe, als mit dem Handy. Lasse ich also mein Handy irgendwo liegen, wird meine Location primär basierend auf der Location der Uhr gesetzt. Ist die Uhr nicht erreichbar, wird die Location vom Handy genommen. Hier musst du also etwas für dich passendes selber programmieren.
Zitat von: Phiolin am 31 Oktober 2017, 16:42:35
Von den unter rr_presenceDevices angegebenen Geräten sollte das Reading "presence" automatisch auf das Roommate Device übernommen werden.
Für den "absent" Status bedeutet das übrigens, dass ALLE angegebenen Geräte "absent" sein müssen, um den Roommate auf "absent" zu setzen. Umgekehrt reicht es für den Status "present" aus, wenn ein Gerät wieder erreichbar ist um den Roommate auch auf "present" zu setzen.
Bezüglich event-on-change-reading, würde ich vermuten, dass du zumindest auch das "presence" Reading dort aufnehmen musst, damit das funktioniert. Bei mir habe ich jeweils state,presence und room im event-on-change-reading bei den Presence Devices.
Die Location des Roommate Devices musst du selber z.B. über ein Notify setzen. Das bringt dir auch entsprechende Flexibilität, z.B. wenn ein Presence Device eine höhere Priorität bei der Location haben soll als ein anderes.
Ich hatte bei mir z.B. die Apple Watch entsprechend höher priorisiert als das iPhone, da es wahrscheinlicher ist, dass ich mit der Uhr durch das Haus laufe, als mit dem Handy. Lasse ich also mein Handy irgendwo liegen, wird meine Location primär basierend auf der Location der Uhr gesetzt. Ist die Uhr nicht erreichbar, wird die Location vom Handy genommen. Hier musst du also etwas für dich passendes selber programmieren.
Danke für deine Hilfe, nun wird absent und home/present der ROOMMATES von je 2x PRESENCES übertragen. Der Clou war dass ich zuerst mal selbst jeden ROOMMATE auf absent setzten musste, ansonsten wurde der Status nicht übernommen. Durch das richtige setzen von event-on-change-reading auf "state, presence, room"veringere ich nun auch die umherschirrenden events, Danke Vielmals für Deine Hilfe.
Wie du schon sagtest wird der room nicht automatisch auf die location übernommen und muss ich noch selbst per notify machen.
Könntest du mir Bitte ein Beispiel Notify von deinem System posten?
Ziel wäre es mit einem notify jeweils den rr_ zu setzen.
Meine Bluetooth presences wo ich den room nun mitbekomme heissen alle "P_BT_<NAME>" und meine ROOMMATES "rr_<NAME>".
Bin leider nicht so fit mit Perl und RegEx, vermute das geht irgendwie?
Danke Vielmals
pOpY
Ich verwende wie gesagt hauptsächlich DOIF, deshalb kann ich spontan auch nur ein DOIF Beispiel geben.
Als Presence Device wird hier ein "MyName_iPhone" angenommen, dass zum Bewohner rr_MyName gehört.
Was das macht:
Wenn das Presence Device "present" ist und ein Event generiert, bei dem sich das "room" Reading ändert, wird der neue Wert des "room" Readings als Location für den Bewohner gesetzt. Damit nicht unnötig Daten geändert werden, wird das Location Reading zudem auch nur dann gesetzt, wenn sich der neue Raum vom vorherigen Raum unterscheidet.
(
[MyName_iPhone:presence] eq "present"
and ["^MyName_iPhone$:room"]
) (
set rr_MyName:FILTER=location!=[MyName_iPhone:room] location [MyName_iPhone:room]
) DOELSEIF (
[MyName_iPhone:room] ne ""
and [MyName_iPhone:presence] eq "present"
) (
set rr_MyName:FILTER=location!=[MyName_iPhone:room] location [MyName_iPhone:room]
)
Und die Attribute vom DOIF:
Attributes:
checkReadingEvent 1
checkall event
do always
Danke für die Infos.
Habe es jetzt mit einem Notify gemacht damit der room in die location übernommen wird, mit folgendem code:
P_BT.*.room:.* {
my $roommate = "rr_".substr($NAME,5);
my $room = ReadingsVal($NAME,"room","");
if ($room eq "")
{
$room = "unbekannt";
}
Log 1, "act_set_rr_location: Bluetooth Gerät ".$NAME." ist jetzt im Raum ".$room;
fhem "setreading ".$roommate." location ".$room;
}
Funktioniert 1a, es wird in location der room gesetzt oder sonst unbekannt.
Weiters setzte ich mir jetzt einen Dummy Alias "Jemand im Wohnzimmer" mit folgendem DOIF:
([#"^rr_.*":location:$_ eq "Wohnzimmer"] > 0) (set P_WZ present) DOELSE (set P_WZ absent)
Danke Deiner Hilfe im anderen Thread ::)
Und zu Guter letzt kann ich nun meinen "Niemand mehr im Wohnzimmer" Watchdog drauf aufsetzen:
P_WZ:absent 00:15 P_WZ:present {evtWZBTAbsentHandler()} ; setstate watchdog_Niemand_im_WZ defined
und das Wohnzimmer nach 15 Minuten ausschalten.
Funktioniert soweit alles, muss sich noch in der Praxis beweisen.
Danke Jedenfalls für Deine Unterstützung und Deine Code Schnippsel, diese helfen ungemein.
pOpY
Eine Frage noch zum Modul.
Derzeit habe ich als webcmd "state" gesetzt und somit eine Combobox mit dem aktuellen state & Dazu passende devStateIcon's (Siehe Bild).
Ich möchte Gerne neben der state combobox noch die location anzeigen und aber das devSTateIcon behalten.
Alle meine Versuche mit setzen von "stateformat" und entfernen von devStateIcon waren nur semi-erfolgreich.
Sprich ich kann die icons entfernen und mittels stateformat ausgeben was ich will, beides (icon & stateformat) geht aber nicht!?
Hoffe ich habe mich verständlich ausgedrückt ::)
Würde mich über jeden Hinweis freuen.
Danke pOpY
webCmd state:location
Zitat von: CoolTux am 03 November 2017, 03:02:35
webCmd state:location
Danke für die Antwort.
Leider funktioniert es nicht ganz mit:
webCmd state:locationRaus kommt das wie im Bild im Anhang.
pOpY
Dann stimmt irgendwas nicht. Gerade getestet. Bei mir geht das.
@popy
schau mal ob das Attribut rr_locations existiert und dort Werte eingetragen sind
Gruß
Danny
Zitat von: moskito am 03 November 2017, 09:28:59
@popy
schau mal ob das Attribut rr_locations existiert und dort Werte eingetragen sind
Gruß
Danny
Nun klappts, habe bei rr_locations nun "home,gotosleep,asleep,awoken,absent,Wohnzimmer,Schlafzimmer,unbekannt" eingetragen.
Danke
pOpY
bisschen übereifrig. es geht um location. asleep ist keine location
atwork,home,wayhome,underway
wegen meiner noch Bahnhof oder so. aber nicht asleep oder gotosleep
Bekomme nach dem ich ein "userReadings" Attribut
attr rr_Lisa userReadings image {((ReadingsVal("rr_Lisa","state","absent") eq "home" ) ? "/fhemcommands/images/residents/lisa-farbe.png" : "/fhemcommands/images/residents/lisa-grau.png");;}\
angelegt habe immer folgenden Fehler:
readingsUpdate(rr_Lisa,image,/fhemcommands/images/residents/lisa-farbe.png) missed to call readingsBeginUpdate first.
Ich denke das hat irgendwas mit readingsSingleUpdate und readingsBeginUpdate zu tun, aber das übersteigt meine Fähigkeiten bei weitem, hat jemand eine Idee?
Gruß Christian
Hi Loredo,
mir ist aufgefallen, dass das reading 'presence' im RESIDENTS modul für rgr_Guests überhaupt erst dann erzeugt wird, wenn man den 'state' von rgr_Guests einmal auf 'present' setzt. Vorher gibt es das reading gar nicht.
Was war mein Problem? Nun ich hatte ich mir irgendwie den fhem statefile zerschossen nachdem ich meine CCU2 gelöscht hatte (FHEM hatte sich aufgehängt). Danach war der Status von rgr_Guests kaputt. Viele meiner Abfragen verwenden (Readingsval ("rgr_Guests","presence","na") eq "present"), deswegen funktionierte nichts nehr so wie vorher. Ich habe dann mit set rgr_Guests state absent den status auf 'absent' gesetzt, trotzdem funktionierten meine Abfragen nicht. Ich habe dann festgestellt, das es das reading 'presence' im RESIDENTS modul für rgr_Guests gar nicht gibt. Erst mit einem set rgr_Guests state present wurde dieses reading dann letztendlich angelegt.
Falls Du das nachvollziehen kannst, könnte man das in der Art fixen das es ein reading present immer gibt, dann eben mit einem 'none' oder so als startwert?
Meine definition von rgr_Guests defmod rgr_Guests RESIDENTS
Alternativ ist mir beim schreiben dieses Textes eingefallen, das es schlauer wäre, auf (Readingsval ("rgr_Guests","presence","absent") eq "present") anstatt auf (Readingsval ("rgr_Guests","presence","na") eq "present") abzufragen :-(
Danke fürs lesen!
Nabend,
ROOMMATE schaltet "Nias" nicht auf state=home zurück und ich weiss nicht mehr weiter...
RAW-Block:
defmod Nias ROOMMATE Bewohner
attr Nias alias Status
attr Nias devStateIcon .*zuhause:user_available:absent .*anwesend:user_available:absent .*abwesend:user_away:home .*verreist:user_ext_away:home .*bettfertig:scene_toilet:asleep .*schlaeft:scene_sleeping:awoken .*schläft:scene_sleeping:awoken .*aufgestanden:scene_sleeping_alternat:home .*:user_unknown:home
attr Nias eventMap home:zuhause absent:abwesend gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
attr Nias group Nias
attr Nias icon people_sensor
attr Nias room Residents
attr Nias rr_geofenceUUIDs xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
attr Nias rr_lang DE
attr Nias rr_realname group
attr Nias sortby 1
attr Nias verbose 5
attr Nias webCmd state
attr Nias widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist
setstate Nias zuhause
setstate Nias 2017-12-14 18:59:34 durTimerAbsence 00:00:00
setstate Nias 2017-12-14 18:59:34 durTimerAbsence_cr 0
setstate Nias 2017-12-14 18:50:22 durTimerPresence 00:00:00
setstate Nias 2017-12-14 18:50:22 durTimerPresence_cr 0
setstate Nias 2017-12-11 22:20:51 durTimerSleep 00:00:00
setstate Nias 2017-12-11 22:20:51 durTimerSleep_cr 0
setstate Nias 2017-12-14 18:59:34 lastArrival 2017-12-14 18:59:34
setstate Nias 2017-12-14 18:50:22 lastDeparture 2017-12-14 18:50:22
setstate Nias 2017-12-14 18:59:34 lastDurAbsence 00:09:12
setstate Nias 2017-12-14 18:59:34 lastDurAbsence_cr 9
setstate Nias 2017-12-14 18:50:22 lastDurPresence 00:01:19
setstate Nias 2017-12-14 18:50:22 lastDurPresence_cr 1
setstate Nias 2017-12-14 18:31:19 lastLocation Zuhause
setstate Nias 2017-12-14 17:29:00 lastLocationAddr -
setstate Nias 2017-12-14 17:29:00 lastLocationLat XXX
setstate Nias 2017-12-14 17:29:00 lastLocationLong YYY
setstate Nias 2017-12-14 18:50:22 lastMood calm
setstate Nias 2017-12-14 18:59:34 lastState absent
setstate Nias 2017-12-14 18:57:26 location home
setstate Nias 2017-12-14 18:57:26 locationAddr -
setstate Nias 2017-12-14 18:57:26 locationLat -
setstate Nias 2017-12-14 18:57:26 locationLong -
setstate Nias 2017-12-14 18:57:26 locationPresence absent
setstate Nias 2017-12-14 18:59:34 mood calm
setstate Nias 2017-12-14 18:59:34 presence present
setstate Nias 2017-12-14 18:59:34 state home
setstate Nias 2017-12-14 17:10:59 wayhome 0
Nun simuliere ich mit wget die GeofancyApp:
# sim_geo.sh wayhome
2017.12.14 19:03:41 5: GEOFANCY geofancy: detected data format: Geofency.app
2017.12.14 19:03:41 5: GEOFANCY geofancy: Checking rr_geofenceUUIDs for Nias
2017.12.14 19:03:41 4: GEOFANCY geofancy: Found matching UUID at ROOMMATE device Nias
2017.12.14 19:03:41 4: GEOFANCY geofancy: id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name=wayhome trig=0 date=1513274621 lat= long= address:- dev=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx devAlias=Nias
2017.12.14 19:03:41 5: ROOMMATE Nias: received location information: id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name=wayhome trig=0 date=2017-12-14 19:03:41 lat=- long=- address:- device=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
2017.12.14 19:03:41 5: ROOMMATE Nias: received signal from underway location
2017.12.14 19:03:41 5: ROOMMATE Nias: wayhome signal received
2017.12.14 19:03:41 4: ROOMMATE Nias: implicit state change caused by location wayhome
2017.12.14 19:03:41 4: ROOMMATE Nias: implicit mood change caused by state absent
2017.12.14 19:03:41 4: ROOMMATE Nias: AutoGone timer scheduled: 1513404221
Das klappt *prima*!
Aber leider gehts nicht mehr zurück...
# sim_geo.sh home
2017.12.14 19:05:14 5: GEOFANCY geofancy: detected data format: Geofency.app
2017.12.14 19:05:14 5: GEOFANCY geofancy: Checking rr_geofenceUUIDs for Nias
2017.12.14 19:05:14 4: GEOFANCY geofancy: Found matching UUID at ROOMMATE device Nias
2017.12.14 19:05:14 4: GEOFANCY geofancy: id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name=home trig=0 date=1513274714 lat= long= address:- dev=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx devAlias=Nias
2017.12.14 19:05:14 5: ROOMMATE Nias: received location information: id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name=home trig=0 date=2017-12-14 19:05:14 lat=- long=- address:- device=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
2017.12.14 19:05:14 5: ROOMMATE Nias: received signal from home location
Die "location" steht danach auf "home", aber der state/presence bleiben auf "absent".
Jemand eine Idee wo es hier hakt?
okay, hat sich erledigt.
Hab in meiner Simulation den "entry" Parameter an die URL falsch verfüttert...
Möchte das noch mal nach vorne holen, spamt mir das ganze log zu. Das ist doch kein normales Verhalten des Moduls?
Keiner einen Tip, was da falsch läuft?
Gruß Christian
Zitat von: mrbreil am 07 Dezember 2017, 14:25:45
Bekomme nach dem ich ein "userReadings" Attribut
attr rr_Lisa userReadings image {((ReadingsVal("rr_Lisa","state","absent") eq "home" ) ? "/fhemcommands/images/residents/lisa-farbe.png" : "/fhemcommands/images/residents/lisa-grau.png");;}\
angelegt habe immer folgenden Fehler:
readingsUpdate(rr_Lisa,image,/fhemcommands/images/residents/lisa-farbe.png) missed to call readingsBeginUpdate first.
Ich denke das hat irgendwas mit readingsSingleUpdate und readingsBeginUpdate zu tun, aber das übersteigt meine Fähigkeiten bei weitem, hat jemand eine Idee?
Gruß Christian
Zitat von: mrbreil am 20 Dezember 2017, 09:14:02
Möchte das noch mal nach vorne holen, spamt mir das ganze log zu. Das ist doch kein normales Verhalten des Moduls?
Keiner einen Tip, was da falsch läuft?
Gruß Christian
Ich sehe im userReading zu viele Klammer und einen Trigger gibt es auch nicht.
Mit einem angegebenen Trigger wären es auch weniger Log Ausgaben.
Gruß
Dan
Ich hätte da noch einen Wunsch zum neuen Jahr.
Im Log habe ich viele Meldungen der Art
2017.12.31 10:43:29 2: ROOMMATE set Michael_P home
2017.12.31 10:43:29 2: ROOMMATE set Michael_P location arrival
Diese werden mit verbose 2 gelogt. Laut der Definition in der commandref
Zitat
verbose
Set the verbosity level. Possible values:
0 - server start/stop
1 - error messages or unknown packets
2 - major events/alarms.
3 - commands sent out will be logged.
4 - you'll see whats received by the different devices.
5 - debugging.
sollten diese aber mit verbose 3 gelogt werden.
Ich bitte um Hilfe zur Selbsthilfe: seit einiger Zeit läuft mein System relativ instabil, weil die HomeMatic-Kommunikation Problem macht. Apptime liefert mir aber Zeitbedarfe bei ROOMMATE. Deswegen zuerst mal die Frage hier: ist dieses Verhalten normal?
name function max count total average maxDly
tmr-ROOMMATE_DurationTimer HASH(0x2d15c60) 868 1 868 868.00 4 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2d07680) 658 1 658 658.00 6 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2e59828) 655 1 655 655.00 9 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2c82a28) 653 1 653 653.00 58 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2d17300) 652 1 652 652.00 5 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2c8aae0) 651 1 651 651.00 5 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2d3d4f8) 651 1 651 651.00 9 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2d59fa0) 649 1 649 649.00 5 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2d3d6c0) 613 1 613 613.00 5 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2cb6638) 607 1 607 607.00 6 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2276878) 606 1 606 606.00 406 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2cd4648) 603 1 603 603.00 5 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2a4f298) 595 1 595 595.00 9 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x2c8bef0) 595 1 595 595.00 8 HASH(rr_Ursula_DurationTimer)
Das sind die Appliaktionen mit dem größten Zeitbedarf, alles andere liegt um Faktoren darunter. Was kann ich da durch mein Verwenden des Moduls falsch gemacht haben? Oder soll ich zuerst einfach mal auf gut Glück ein Update machen?
Ich möchte gerne den Status der Presence devices als auch des daraus resultierenden Residents status aufzeichnen und in einem LogFile zusammenfassen. Für die Presence devices funktioniert das auch prima. Beim Residends device habe ich Probleme.
define PRESENCE.File FileLog ./log/presence-%Y-%m.log andrea_handy:presence.*|armin_handy:presence.*|christof_handy:presence.*|Familie:state.* mit attr PRESENCE.File addStateEvent 1
Der State des Residents Devices wird korrekt gemeldet/erfasst, wenn er sich ändert, aber, obwohl ich attr Familie event-min-interval state:900 für das Device gesetzt habe, bekomme ich nicht die erwarteten Log Einträge im 15 min Takt.
Ist in diesem Modul etwas anders als in anderen, das ich übersehen habe?
Ich glaube Du interpretierst das Attribut "event-min-interval" falsch.
Zitatevent-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind. Falls event-on-change-reading auch spezifiziert ist, dann werden sie mit ODER kombiniert, d.h. wenn einer der beiden Bedingungen wahr ist.
Ich hatte mal etwas ähnliches für Rollläden in Betrieb, evtl. hilft Dir das weiter:
### jede 1/2 Stunde einen Eintrag für Rollläden
define roll_log notify roll_log {addLog("Roll_Kinderzimmer","position")}
define roll_log_hour at +*00:30:00 trigger roll_logGruß
Danny
Danke für den Hinweis. Also kommt es offensichtlich auf das Zusammenspile zwischen event-min-interval und event-on-change-reading an. Wenn das Modul gar keine events generiert, bewegt sich also auch nichts. Insofern verhält es sich hier schon anders als andere Module, wo das Vorgehen mit event-min-interval und event-on-change-reading sehr gut funktioniert. Ich habe addlog daher sonst nicht mehr im Einsatz.
Mit dieser Variante bekomme ich aber auch was ich brauche.
Kann ich irgendwie neue Stati (neben home zum Beispiel homeoffice) einfügen und wie kann ich die dann einbinden ?
Zitat von: en-trust am 16 Februar 2018, 15:54:12
Kann ich irgendwie neue Stati (neben home zum Beispiel homeoffice) einfügen und wie kann ich die dann einbinden ?
rr_locations?
Ich meinte eher eine Art 2.Status. Folgendes Szenario stellt sich dar. Ich habe eine Awesenheitsprüfung über wlan. Allerdings Meldet sich das Handy öfters ab (ist wohl ein Bug in der letzten HandyFirmware). Dies hat zur Folge, dass meine Jalousie dann automatisch runter fährt. Nun würde ich gerne eine Funktion haben, wo ich manuell fhem mitteile, dass ich jetzt 'manuell' zu Hause bin und er die Prüfung hinten anstellen kann.
Zweites anwesenheitsdevice und mit dem ersten zusammen ein Structuredevice erstellen und das dann halt abfragen wegen Abwesenheit
Oje... hast Du ein Beispiel ?
verrate erstmal wie du es bis jetzt machst.
Gib bitte ein list von Deinem presence device und Deinem Roommate Device. Ich gehe davon aus das Du das presence Attribut Deines Roomates verwendest.
Hier die beiden Lists welche ich parallel abfrage.
Internals:
CFGFN ./FHEM/fhem_residents.cfg
CHANGED
DEF function {CheckiPhone("ip","mac")} 60 120
INTERVAL_NORMAL 60
INTERVAL_PRESENT 120
MODE function
NAME Galaxy.A5.Wlan
NOTIFYDEV global
NR 916
NTFY_ORDER 50-Galaxy.A5.Wlan
STATE present
TYPE PRESENCE
Helper:
DBLOG:
presence:
logdb:
TIME 1518891868.75429
VALUE present
state:
logdb:
TIME 1518892726.06711
VALUE present
READINGS:
2018-02-16 13:42:42 model function
2018-02-17 19:51:44 presence present
2018-02-17 19:51:44 state present
helper:
CURRENT_STATE present
call {CheckiPhone("ip","mac")}
Attributes:
Bewohner_structure Bewohner
Handys alleHandys
event-on-change-reading state,presence
group Anwesenheit
room 3.2_Anwesenheit,Fritzbox,Status,System
userattr Bewohner_structure Bewohner_structure_map Handys Handys_map structexclude
Internals:
ADDRESS ip
CFGFN ./FHEM/fhem_residents.cfg
CHANGED
DEF lan-ping ip 60
INTERVAL_NORMAL 60
INTERVAL_PRESENT 60
MODE lan-ping
NAME HA.SvenWlan
NOTIFYDEV global
NR 910
NTFY_ORDER 50-HA.SvenWlan
STATE absent
TYPE PRESENCE
Helper:
DBLOG:
presence:
logdb:
TIME 1518892601.37061
VALUE absent
state:
logdb:
TIME 1518892601.37061
VALUE absent
READINGS:
2018-02-16 13:42:42 model lan-ping
2018-02-17 19:52:44 presence absent
2018-02-17 19:52:44 state absent
helper:
CURRENT_STATE present
RUNNING_PID:
abortFn PRESENCE_ProcessAbortedScan
arg HA.SvenWlan|ip|0|4
bc_pid 46927
finishFn PRESENCE_ProcessLocalScan
fn PRESENCE_DoLocalPingScan
pid 22934
timeout 60
abortArg:
Attributes:
event-on-change-reading state,presence
group Anwesenheit
pingCount 4
presence Anwesenheit
room 3.2_Anwesenheit,Fritzbox,Status,System
userattr presence presence_map structexclude
und das Roommate...
Internals:
CFGFN ./FHEM/fhem_residents.cfg
DEF residents
DURATIONTIMER 1518893783.03789
NAME rr_Sven
NOTIFYDEV global,Galaxy.A5.Wlan
NR 954
NTFY_ORDER 50-rr_Sven
READY 1
RESIDENTGROUPS residents
STATE home
TYPE ROOMMATE
Helper:
DBLOG:
durTimerAbsence:
logdb:
TIME 1518891868.83542
VALUE 00:00:00
durTimerAbsence_cr:
logdb:
TIME 1518891868.83542
VALUE 0
durTimerPresence:
logdb:
TIME 1518893723.07864
VALUE 00:30:55
durTimerPresence_cr:
logdb:
TIME 1518893723.07864
VALUE 31
lastArrival:
logdb:
TIME 1518891868.83542
VALUE 2018-02-17 19:24:28
lastDeparture:
logdb:
TIME 1518891535.14473
VALUE 2018-02-17 19:18:55
lastDurAbsence:
logdb:
TIME 1518891868.83542
VALUE 00:05:33
lastDurAbsence_cr:
logdb:
TIME 1518891868.83542
VALUE 6
lastDurPresence:
logdb:
TIME 1518891535.14473
VALUE 01:05:57
lastDurPresence_cr:
logdb:
TIME 1518891535.14473
VALUE 66
lastState:
logdb:
TIME 1518891868.83542
VALUE absent
location:
logdb:
TIME 1518891868.83542
VALUE home
mood:
logdb:
TIME 1518891868.83542
VALUE calm
presence:
logdb:
TIME 1518891868.83542
VALUE present
state:
logdb:
TIME 1518891868.83542
VALUE home
READINGS:
2018-02-17 19:24:28 durTimerAbsence 00:00:00
2018-02-17 19:24:28 durTimerAbsence_cr 0
2018-02-17 19:55:23 durTimerPresence 00:30:55
2018-02-17 19:55:23 durTimerPresence_cr 31
2018-02-10 20:43:34 durTimerSleep 00:00:00
2018-02-10 20:43:34 durTimerSleep_cr 0
2018-02-17 19:24:28 lastArrival 2018-02-17 19:24:28
2018-02-10 20:43:34 lastAwake 2018-02-10 20:43:34
2018-02-17 19:18:55 lastDeparture 2018-02-17 19:18:55
2018-02-17 19:24:28 lastDurAbsence 00:05:33
2018-02-17 19:24:28 lastDurAbsence_cr 6
2018-02-17 19:18:55 lastDurPresence 01:05:57
2018-02-17 19:18:55 lastDurPresence_cr 66
2018-02-10 20:43:34 lastDurSleep 00:02:33
2018-02-10 20:43:34 lastDurSleep_cr 3
2018-02-17 19:18:55 lastLocation home
2018-02-17 19:18:55 lastMood calm
2018-02-10 20:41:01 lastSleep 2018-02-10 20:41:01
2018-02-17 19:24:28 lastState absent
2018-02-17 19:24:28 location home
2018-02-17 19:24:28 mood calm
2018-02-17 19:24:28 presence present
2018-02-17 19:24:28 state home
2018-02-07 20:07:19 wayhome 0
TIMER:
rr_Sven_DurationTimer:
HASH rr_Sven
MODIFIER DurationTimer
NAME rr_Sven_DurationTimer
Attributes:
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
event-on-change-reading .*
group Anwesenheit,Personen
icon people_sensor
room 3.2_Anwesenheit,Flur
rr_autoGoneAfter 24
rr_presenceDevices Galaxy.A5.Wlan
rr_realname group
rr_states home,asleep,absent,gone,homeoffice
sortby 1
webCmd state
Das passt doch gut. Du hast also 2 presence Devices, da machst du nun ein Dummy Device dazu mit state present absent für die manuelle Geschichte.
Nun fügst Du alle 3 Devices in eine structure zusammen, und beim Roommate Device gibst Du das structure Device als rr_presenceDevices an.
Morgen gibt es ein Update des RESIDENTS Toolkit und somit auch von ROOMMATE und GUEST, um Funktionen des aktualisierten GEOFANCY Moduls (https://forum.fhem.de/index.php/topic,18485.msg847898.html#msg847898) zu unterstützen.
Habe seit neuestem dauernd sowas im Logfile:
2018.10.22 05:44:54 3: PRESENCE (GTAG_A) - collectord lost connection to room RPI2
2018.10.22 05:44:57 3: PRESENCE (GTAG_A) - collectord lost connection to room RPI0
2018.10.22 05:44:57 3: PRESENCE (GTAG_A) - collectord reconnected to room RPI0
2018.10.22 05:45:01 3: PRESENCE (GTAG_A) - collectord reconnected to room RPI2
Der GTAG ist eigentlich fast nie da, sondern nur wenn die Großeltern zu Besuch sind. Bis vor kurzem auch kein Problem und jetzt sehe ich laufend diese Meldungen im Logfile.
Kann ich was dagegen tun?
Beim heutigen Update hat sich noch ein Fehler eingeschlichen. Besser erst morgen FHEM updaten.
Zitat von: mumpitzstuff am 22 Oktober 2018, 22:44:31
Habe seit neuestem dauernd sowas im Logfile:
Das ist aber ein Thema für das PRESENCE Modul bzw. dem dazugehörigen collectord.
Stimmt. Jetzt wo du es sagst...
roommate macht seit neuestem auch sowas:
2018.10.23 17:16:26 2: ROOMMATE set rr_A home
2018.10.23 18:00:39 2: ROOMMATE set rr_A absent
2018.10.23 18:04:09 2: ROOMMATE set rr_B absent
Oder kommt das auch woanders her?
Das ist nicht neu, setter werden schon immer geloggt
ja, leider... Mir wäre es auch lieber wenn diese "events" nicht im Log auftauchen würden... Ein set vorgang ist doch eine normale aktion.
verbose=1 ist dein Freund.
Zitat von: der-Lolo am 24 Oktober 2018, 08:46:46
ja, leider... Mir wäre es auch lieber wenn diese "events" nicht im Log auftauchen würden... Ein set vorgang ist doch eine normale aktion.
Ich finde sie sehr hilfreich. Und sie erscheinen wenn dann ja eh nur 3-4 mal pro Tag. Also nichts was das Log zu müllt.
Ich bin halt der meinung das nur etwas im Log auftauchen soll wenn was nicht planmässig läuft.
Aber das gehört hier nicht her.
Wenn ich einen Lichtschalter betätige ist das ja auch ein set -> taucht aber Gott sei Dank nicht im Log auf.
Zitat von: der-Lolo am 24 Oktober 2018, 10:18:57
Ich bin halt der meinung das nur etwas im Log auftauchen soll wenn was nicht planmässig läuft.
Aber das gehört hier nicht her.
Wenn ich einen Lichtschalter betätige ist das ja auch ein set -> taucht aber Gott sei Dank nicht im Log auf.
Das darf ja gerne der Entwickler selber entscheiden. Und so lange er die Möglichkeit gibt das es auch abstellbar ist, ist es ok.
Ach, das ist abstellbar..? Wie denn?
Naja Fehler will ich ja eigentlich sehen und soweit ich das verstanden haben sollten Fehler im Bereich von 1 - 3 gemeldet werden. 4 sind dann Meldungen die etwas mehr Informationen preisgeben und 5 ist z.b. für die Fehleranalyse, wo dann ganz viel im Logfile erscheint.
Wenn man die Meldungen da mit Level 4 loggen würde, dann kann derjenige der das sehen will auf dieses Level gehen und bei allen anderen bleibt das Logfile sauber und nur Fehler tauchen darin auf.
Und bei mir tauchen die Meldungen im Log erst seit kurzem auf. Mir ist nicht bewusst, dass ich da irgendwas geändert habe...
Level 3 steht für Informationen, ab Level 4 für Fehler und Debug.
Ich finde schon das die Ausgabe eine Information ist. Wer sie nicht haben will stellt auf 2 oder 1
Zwei reicht nicht, hatte ich schon probiert - eins war mir auch zu sehr mit der keule...
Das Loglevel ist aktuell 2.
Man mag es kaum glauben, aber die Module sind so alt, damals gab es keine (schriftlich) festgehaltenen Orientierungswerte was die Loglevel angeht. Ich habe mich an den vorhandenen Modulen orientiert (glaube war CUL_HM) und damals war es normal, dass man die Setter als Level 2 ausgegeben hat.
Passt schon, die Roommates und Guests stehen jetzt auf 1.
Bastelst Du eigentlich noch weiter am Homestate?
Bei mir hab ich auch alles auf Verbose 1 gesetzt.
Keine Ahnung warum mein Logfile seit neuestem mit diesen Meldungen überschwemmt wird und das früher nicht der Fall war. Wenn ich raten müsste, würde ich sagen, dass das PRESENCE Modul seit neuestem irgend was anders macht und deshalb auch diese Meldungen von den ROOMMATES bei mir im Log auftauchen (erscheinen immer direkt nach den neuen Meldungen des PRESENCE Moduls). Die Zusammenhänge sind mir hierzu leider nicht bekannt.
Ich habe in meiner Geofancy App den Status home und work, welcher auch korrekt an das Residence Modul übertragen wird.
Wie bekomme ich es hin, dass es ein Event gibt, wenn ich diese Zone verlasse?
Edit: Ziel ist ein Event beim Verlassen von Work
In der Geofency App gibt es zwei Slider, einen für das Event "ankommen" und einen für "verlassen". Du solltest beide einschalten und dann gibts auch beide Events in FHEM.
Ich habe bei beiden den Button aktiviert.
In geofancy Modul erscheint auch ein underway Event (Reading: currLoc_rr_Name). Dieses wird jedoch nicht ins das Roommate Modul übernommen.
Du musst rr_geofenceUUIDs beim ROOMMATE Device setzen, wenn du den Status automatisch übernehmen willst.
Ansonsten musst du selbst mit entsprechenden Notify/DOIF Regeln arbeiten.
Hallo Julian,
ich bin dabei, für das livetracking Modul einen connector für die ROOMMATE/GUEST Module (via RESIDENTStk_SetLocation) zu bauen.
Dabei sind ein paar Fragen aufgetreten:
livetracking gibt zum einen den Abstand zur Home Position aus.
Mit diesem Abstand und zwei Attributen (homeradius uns wayhomeradius) setze ich über RESIDENTStk_SetLocation die $location abhängig von den eben genannten Werten auf
home|wayhome|underway
Je nach Einstellung kommen die Positionsdaten recht häufig. Für home und underway scheint das kein Problem zu sein.
Für wayhome schon.
Ein Wechsel von home nach wayhome funktioniert ohne Probleme
Wenn ich jetzt aber noch einmal wayhome über RESIDENTStk_SetLocation setze wird das Reading wayhome auf 1 gesetzt ($trigger ist immer 1).
Das ganze würde funktionieren, wenn ich $trigger beim wiederholten setzen von wayhome auf 0 setze. Dann geht allerdings locationPresence auf abwesend (aber ich bin ja noch in dieser location)
Habe ich einen Denkfehler drin?
Klaus
Ich kann dir da glaube ich nicht ganz folgen.
Ein direkter Wechsel von home nach wayhome macht irgendwie keinen Sinn, dazwischen wird der Logik nach immer ein "underway" erwartet.
"wayhome" ist eigentlich nur eine spezielle Unterart von "underway", bei der das _verlassen_ eines speziellen Ortes so gewertet wird, dass man sich anschließend auf dem (mehr oder weniger) direkten Weg nach Hause befindet. Dann wird das Reading "wayhome" auf 1 gesetzt, bis man durch ein "home" Event tatsächlich zuhause ankommt (egal, ob man noch Zwischenstationen macht).
So sollte sich das ganze auch aktuell mit dem GEOFANCY Modul verhalten.
Hast du mal ins Log geschaut? RESIDENTStk ist da sehr gesprächig ab verbose level 3.
Ich überwache 2 Smartphones. Beide sind in geofancy und Residents integriert. Ein Smartphone hat 2 Zonen, home und work. Sobald ich work oder home verlasse, wird der Status korrekterweise im geofancy Modul auf underway gesetzt. Nur ins Roommate Device wird das nicht übernommen.
Edit: rr_geofenceUUIDs habe ich gesetzt, work und home wird auch korrekt übertragen.
Ich habe das Roommate Device mal auf verbose 3 gestellt.
ich denke es geht um das verhalten von location und presence
| <Aktion> | <Wert location> | <Wert presence> | <gewünschter wert eines Readings> |
| Home betreten | home | presence | home |
| Home verlassen | home | absence | away |
| Work betreten | work | absence | work |
| Work verlassen | work | absence | away |
Ich hatte mir das Verhalten mit einem User-Readings gebaut.
https://forum.fhem.de/index.php/topic,98015.msg916438.html#msg916438
Wenn es um was anderes geht ... List der Devices und gewünschtes Verhalten dokumentieren
Zitat von: Loredo am 08 März 2019, 19:43:02
Ein direkter Wechsel von home nach wayhome macht irgendwie keinen Sinn, dazwischen wird der Logik nach immer ein "underway" erwartet.
"wayhome" ist eigentlich nur eine spezielle Unterart von "underway", bei der das _verlassen_ eines speziellen Ortes so gewertet wird, dass man sich anschließend auf dem (mehr oder weniger) direkten Weg nach Hause befindet. Dann wird das Reading "wayhome" auf 1 gesetzt, bis man durch ein "home" Event tatsächlich zuhause ankommt (egal, ob man noch Zwischenstationen macht).
So sollte sich das ganze auch aktuell mit dem GEOFANCY Modul verhalten.
Hast du mal ins Log geschaut? RESIDENTStk ist da sehr gesprächig ab verbose level 3.
Prinzipiell hast du recht.
Wayhome war für mich ein Bereich, der Home in größerem Radius umschließt und bei dem das Wayhome Reading gesetzt wird, sobald man den von "außen" betritt. Also nicht mal, das es als Location angezeigt wird.
Ich hatte die logik dazu im RESIDENTStk vermutet (aufgrund dieses Satzes: "Immer wenn eine Lokation mit dem Namen 'wayhome' gesetzt wird, wird das Reading 'wayhome' auf '1' gesetzt, sofern die Anwesenheit zu diesem Zeitpunkt 'absent' ist.").
Ins Log habe ich nicht geschaut, Deine Erklärung lässt im Moment sowieso keine Fragen offen ;)
Das kann ich aber ebenso in den connector einbauen.
Zwei Fragen habe ich noch:
- Ich würde gern, Abhängig von der Entfernung zu Home, den Status direkt auf verreist setzen. Also ohne Wartezeit. Ab 300km ist ein Tagesausflug nicht mehr so üblich 8)
Gibt der RESIDENTStk das her?
- position.* und lastPosition.* sind klar für mich
wann sollten die location.* Readings gesetzt werden?
nur bei betreten oder verlassen einer location? Oder auch bei Aktualisierung innerhalb einer Location?
Danke
Klaus
Hi Klaus,
für deinen ersten Punkt, probier mal das hier:
##########################################################
# Calculate distance between two geocoordinates
##########################################################
sub calcDistkm ($$$$) {
my($latNew,$lonNew,$latOld,$lonOld) = @_;
#Entfernung zur Home-Koordinate (Luftlinie)
#Berechnung nach: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kompf.de_gps_distcalc.html&d=DwICAg&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=fjkjtP90XwgwsFiC-zb01AeZ1ffjVVSXDnDyxQOtlCw&m=2E21LZkstx_fHrSuJ14UVHFNwuqW_c-9POHdUq-QuGI&s=h4xM_iBweT-_GlHSZVvpQiGevgDfVaUY4w0hHv_Vs3o&e=
# Verbesserte Methode
my $lat = ($latNew + $latOld) / 2 * 0.01745;
my $dx = 111.3 * cos($lat) * abs($lonNew - $lonOld);
my $dy = 111.3 * abs($latNew - $latOld);
#Einfache Variante
#my $dx = 71.5 * abs($lonNew - $lonNew);
#my $dy = 111.3 * abs($latNew - $latOld);
my $distance = sprintf("%.2f",sqrt($dx * $dx + $dy * $dy));
return $distance;
}
Hi inoma
Zitat von: inoma am 12 März 2019, 14:28:10
für deinen ersten Punkt, probier mal das hier:
danke Dir, das kommt in meine Codesammlung
Hat aber nix mit meiner Frage zu tun 8)
Die Entfernung habe ich. Ich möchte nur den Status auf verreist (gone) setzen.
Derzeit mache ich das mit
fhem "set $deviceAlias gone";Funktioniert, ist aber nicht die sauberste Lösung
Klaus
Zitat von: klausw am 11 März 2019, 10:06:40
- Ich würde gern, Abhängig von der Entfernung zu Home, den Status direkt auf verreist setzen. Also ohne Wartezeit. Ab 300km ist ein Tagesausflug nicht mehr so üblich 8)
Gibt der RESIDENTStk das her?
Derzeit nicht. Es gibt ja aber das Reading positionDistHome und das ist genau dafür gedacht.
Von der Entfernung abhängige Aktionen sind bisher nicht geplant, dafür gibt es ja DOIF und notify, um dann beispielsweise auf ein Reading mit der Entfernung entsprechend zu reagieren. Da kannst du selbstverständlich auch von away auf gone wechseln, wenn du das willst. Das ist Teil deiner eigenen Automatisierung, nicht der von RESIDENTS.
Zitat von: klausw am 11 März 2019, 10:06:40[size=78%] [/size]
- position.* und lastPosition.* sind klar für mich
wann sollten die location.* Readings gesetzt werden?
nur bei betreten oder verlassen einer location? Oder auch bei Aktualisierung innerhalb einer Location?
Der Unterschied zwischen Location und Position ergibt sich darauf, wie Geofency die Daten liefert.
Dort wird beim ankommen/verlassen einer Location zusätzlich die aktuelle Position und auch deren Adresse übermittelt. Wenn ich also beispielsweise in den Radius von "home" eintrete und damit "home" feuert, dann unterscheidet sich die tatsächliche Position von der eigentlichen Location. Position ist also immer mein tatsächlicher Aufenthaltsort und Location der gewollte Ort, an dem das Geofencing eingestellt wurde. Für einen Vergleich schlage ich vor, dass du dir Geofency einmal installierst.
Zitat von: Loredo am 13 März 2019, 22:49:45
Derzeit nicht. Es gibt ja aber das Reading positionDistHome und das ist genau dafür gedacht.
Von der Entfernung abhängige Aktionen sind bisher nicht geplant, dafür gibt es ja DOIF und notify, um dann beispielsweise auf ein Reading mit der Entfernung entsprechend zu reagieren. Da kannst du selbstverständlich auch von away auf gone wechseln, wenn du das willst. Das ist Teil deiner eigenen Automatisierung, nicht der von RESIDENTS.
Ok, habe es erstmal anderweitig gelöst.
Ein zu autoGoneAfter adäquates Attribut für die Entfernung wäre Grundsätzlich vielleicht doch keine Schlechte Idee
Zitat von: Loredo am 13 März 2019, 22:49:45
Der Unterschied zwischen Location und Position ergibt sich darauf, wie Geofency die Daten liefert.
Dort wird beim ankommen/verlassen einer Location zusätzlich die aktuelle Position und auch deren Adresse übermittelt. Wenn ich also beispielsweise in den Radius von "home" eintrete und damit "home" feuert, dann unterscheidet sich die tatsächliche Position von der eigentlichen Location. Position ist also immer mein tatsächlicher Aufenthaltsort und Location der gewollte Ort, an dem das Geofencing eingestellt wurde. Für einen Vergleich schlage ich vor, dass du dir Geofency einmal installierst.
Verstanden. Das gibt Owntracks so nicht her. Da gibt es nur die Position oder Betreten/Verlassen einer Zone als Nachricht. Demzufolge sind Location und Position identisch. Das ist meiner Meinung nach aber kein Problem.
Danke für die Infos
Klaus
Ich habe gerade analog zu ROOMMATE und GUEST noch einen dritten Bewohnertyp namens PET eingecheckt.
Ab morgen kann man also Haustiere wie beispielsweise einen Hund explizit als solchen führen. Dafür gibt es auch entsprechend neue Readings.
Außerdem gibt es ein neues Attribut r*_passStateTo, welches ähnlich wie r*_passPresenceTo nun den Status während man zuhause ist mit einem anderen Gerät abgleichen kann.
Das ist zum Beispiel bei einem Hund sinnvoll, der ja aller Wahrscheinlichkeit nach immer mit Herrchen und/oder Frauchen schlafen geht und aufsteht ;-)
Ich überlege noch, ob nun im RESIDENTS Modul noch neue Status sinnvoll wären, die nur dann eintreten, wenn ein Haustier allein zuhause ist. Ich denke da an ein Präfix "pet_" vor dem eigentlichen Status. Da ich aber weiß, dass es so einige Module und persönliche Automationen gibt, wollte ich vorher einmal horchen, wie dazu so die Meinung ist. Sicherlich kann man das als Attribut erst einschaltbar machen, aber selbst wenn man das tut, werden diejenigen, die das gerne möchten, vielleicht hier und dort auf Probleme stoßen. Und dafür müssten dann wahrscheinlich Module wie HOMEMODE oder AutoShuttersControl etc gewappnet sein.
Hallo Loredo,
Für meine 2 Siamkatzen fällt mir für den neuen Bewohnertyp kein Sinn noch Nutzen ein. Aber für die Putzfrau, auch wenn das schon diskriminierend ist, sie unter PET einzugruppieren. Die Möglichkeit abhängig von deren " Alleinzuhause Status " anders zu schalten als bei ROMMATE oder GUEST macht aber schon Sinn. Das Gleiche trifft auf die Freunde (GTag) zu, die während unseres Urlaubs die Biester füttern und die Katzenklo's reinigen.
Meine Frage dazu also - könntest Du den 3ten Bewohnertyp nicht z.b. SERVICE nennen oder den Namen konfigurierbar machen?
Zitat von: Loredo am 04 Mai 2019, 13:56:26
Ich habe gerade analog zu ROOMMATE und GUEST noch einen dritten Bewohnertyp namens PET eingecheckt.
Ab morgen kann man also Haustiere wie beispielsweise einen Hund explizit als solchen führen. Dafür gibt es auch entsprechend neue Readings.
Finde ich ziemlich cool :)
Dann mach ich den Hundi direkt zum PET, zur Zeit ist er noch ein GUEST 8)
LG
Christian
Zitat von: Loredo am 04 Mai 2019, 13:56:26
Ich überlege noch, ob nun im RESIDENTS Modul noch neue Status sinnvoll wären, die nur dann eintreten, wenn ein Haustier allein zuhause ist. Ich denke da an ein Präfix "pet_" vor dem eigentlichen Status. Da ich aber weiß, dass es so einige Module und persönliche Automationen gibt, wollte ich vorher einmal horchen, wie dazu so die Meinung ist. Sicherlich kann man das als Attribut erst einschaltbar machen, aber selbst wenn man das tut, werden diejenigen, die das gerne möchten, vielleicht hier und dort auf Probleme stoßen. Und dafür müssten dann wahrscheinlich Module wie HOMEMODE oder AutoShuttersControl etc gewappnet sein.
Ich habe jetzt gerade noch eine neue Version aller Module eingecheckt, die einen "Home Alone" Modus mitbringt.
Dabei werden für alle RESIDENTS Sub-Module auch subTypes eingeführt (über Attribute). Diese basieren bei ROOMMATE auf der Altersklasse ('baby', 'toddler', 'child', 'teenager', 'adult', 'senior'). Bei GUEST gibt es 'generic', 'minor', 'domesticWorker', 'vacationer'. Und bei PET kann man (eher spaßeshalber) auch angeben, um welche Art von Tier es sich handelt ('generic', 'bird', 'cat', 'dog', 'monkey', 'pig').
Aus dem subType wird dann errechnet, ob diese Person (oder das Tier) als unselbstständig angesehen wird und somit als "allein zu Hause" gilt. Dafür werden dann 3 neue Readings im RESIDENTS Device erstellt. Über ein weiteres Attribut kann man dann den RESIDENTS Gerätestatus mit einem Präfix versehen, welcher dem subType entspricht.
Bei der Ermittlung, welcher subType jetzt derjenige "in Verantwortung" ist, wird eine Reihenfolge beachtet, die über ein Attribut verändert werden kann. Die Reihenfolge ist dabei so gewählt, dass der "älteste" Mensch den Home Alone Status bestimmt (in der Annahme, dass dieser auf jüngere aufpasst, die auch anwesend sein könnten). Eine Ausnahme ist per Default der subType "senior", welcher für Erwachsene vergeben werden kann, die hilfebedürftig sind.
Der Home Alone Status ist beendet, sobald ein 'adult' zu Hause anwesend ist oder alle Bewohner außer Haus sind.
@det.: Schau doch mal, ob du mit dem subType domesticWorker jetzt weiter kommst.
Guten Morgen Julian,
ich habe jetzt unseren Brandy als PET statt vorher als GUEST eingerichtet und alles umgestellt und mal aufgeräumt :). Hat alles geklappt, ziemlich Cool!
Verstehe ich es richtig, dass der 'homealone'-Status dadurch ausgedrückt wird, dass
homealoneType (bzw.
homealoneSubtype) gesetzt werden? (Ich habe
rgr_homealoneInStatus nicht gesetzt.)
Das einzige, was mir jetzt fehlt, sind readings, die mir anzeigen, wie viele
Personen anwesend sind, also ROOMMATE + GUEST 8)
Zitat
residentsTotalPresent = ROOMMATES + PETS + GUEST
residentsTotalPeoplePresent = ROOMMATES + GUEST
residentsTotalRoommatesPresent = ROOMMATES
residentsTotalPetsPresent = PETS
residentsTotalGuestsPresent = GUEST
LG und vielen Dank :)
Christian
Ja das macht wohl Sinn - habe ich gerade eingecheckt.
Zitat von: choenig am 05 Mai 2019, 10:08:50
Verstehe ich es richtig, dass der 'homealone'-Status dadurch ausgedrückt wird, dass homealoneType (bzw. homealoneSubtype) gesetzt werden? (Ich habe rgr_homealoneInStatus nicht gesetzt.)
Ja, das sind die beiden Readings. Wenn sie etwas anderes als "-" enthalten, ist der homealone Status aktiv und man kann ableiten, welche "Form" von Allein Zuhause das ist. Entweder recht allgemein über Type oder etwas genauer über SubType.
Zitat von: Loredo am 05 Mai 2019, 13:24:08
Ja das macht wohl Sinn - habe ich gerade eingecheckt.
Ich konnte es nicht abwarten, hab' schonmal upgedated :)
So sehen meine DOIFs jetzt ein wenig aufgeräumter aus :D
LG
Christian
Ich habe einige kleinere Fixes zum homealone Status eingecheckt.
Geändert hat sich dabei ein subType für GUEST: Aus "minor" (Minderjährig) wurde nun "childcare" (Kinderbetreuung).
Außerdem hat das bisher nicht vollständig veröffentlichte HOMESTATE (https://forum.fhem.de/index.php/topic,71692.0.html) Modul nun support für homealone erhalten.
Seit einem Update heute bin ich auf dieser Version:
Zitat20_ROOMMATE.pm 19386 2019-05-14 16:47:14Z loredo
Nach einem Neustart von FHEM wurde in der fhem.cfg alle ROOMATEs gelöscht. Das log hat diese Fehlermeldung
ZitatCan't use an undefined value as an ARRAY reference at ./FHEM/20_ROOMMATE.pm line 29.
Auch wenn ich diese Roommates danach wieder neu anlegen will, kommt diese Fehlermeldung, und keine Roommates werden angelegt.
Kann ich noch was prüfen?
gruß
Nur zur Info: bin bei den drei Modulen (Residents, Roomate und Guest) wieder zurück zur Version 18995 vom 22.03.2019
Damit kann ich meine Roommates wieder herstellen.
Selbst wenn ich mit der aktuellen Version 19386 ein Roommate über Residents anlegen wollte, kam im Log diese Meldung:
Zitat2019.06.01 17:36:03 0: Can't use an undefined value as an ARRAY reference at ./FHEM/20_ROOMMATE.pm line 29.
2019.06.01 17:36:03 3: define rr_Peter ROOMMATE rgr_myHome : Cannot load module ROOMMATE
gruß
Zitat von: thegimliboy am 31 Mai 2019, 19:59:42
Seit einem Update heute bin ich auf dieser Version:
Nach einem Neustart von FHEM wurde in der fhem.cfg alle ROOMATEs gelöscht. Das log hat diese Fehlermeldung
Auch wenn ich diese Roommates danach wieder neu anlegen will, kommt diese Fehlermeldung, und keine Roommates werden angelegt.
Kann ich noch was prüfen?
Du machst offenbar nur selektive Updates von einzelnen FHEM Dateien, das ist nicht gut.
Dir fehlt eine aktuelle Version von RESIDENTStk.pm.
Ich hatte vorgestern ein "update all" gemacht. Da war Nichts selektiv.
OK. Beim zurückgehen auf eine ältere Version war ich selektiv vorgegangen. Mir ist kein Befehl bekannt, mit dem man das geregelt machen kann. Geht so etwas wirklich?
Für mich war erst mal wichtig, dass es wieder funktioniert.
Die Residentsk.pm war auch auf 19386. Ich habe diese Datei jetzt auch auf den älteren Stand gebracht. Die Störung wurde durch die 20_ROOMMATE.pm mit der Version 19386 verursacht. Zumindest bei mir, und ich hatte keine Idee mehr, wo ich noch schauen kann.
Trotzdem besagt die Fehlermeldung, dass er eine Variable, die in RESIDENTStk erst neu hinzugekommen ist, nicht finden kann.
Hast du FHEM auch neu gestartet? Welche Perl Version?
ich kann bei dieser Fehlermeldung
Zitat2019.06.01 17:36:03 0: Can't use an undefined value as an ARRAY reference at ./FHEM/20_ROOMMATE.pm line 29.
2019.06.01 17:36:03 3: define rr_Peter ROOMMATE rgr_myHome : Cannot load module ROOMMATE
beim besten Willen nicht herauslesen, dass er eine Variable, die in RESIDENTStk erst neu hinzugekommen ist, nicht finden kann.
Wo steht da was von RESIDENTStk.pm ?
Ich habe gerade Stunden von Recherche hinter mir, wofür die RESIDENTStk.pm überhaupt da ist. Im Wiki konnte ich nichts finden, und in diesem Thread auch nicht. Schade.
Gerne hätte ich die Ursache gefunden, aber trotz LogLevel 5 war nichts beim Starten zu finden.
Zitat von: thegimliboy am 02 Juni 2019, 17:55:07
ich kann bei dieser Fehlermeldungbeim besten Willen nicht herauslesen, dass er eine Variable, die in RESIDENTStk erst neu hinzugekommen ist, nicht finden kann.
Wo steht da was von RESIDENTStk.pm ?
Dort steht eine Codezeile und in dieser Codezeile wird auf eine Variable verwiesen, die aus RESIDENTStk exportiert wird. Das weiß ich als Modulautor natürlich und kann es dir deshalb sagen.
RESIDENTStk beinhaltet den eigentlichen Code der Module RESIDENTS, ROOMMATE, PET und GUEST (kann dir im übrigen auch der FHEM Installer (https://forum.fhem.de/index.php/topic,98381.0.html) sagen). Das muss man aber gar nicht wissen, wenn man immer brav alle Dateien gemeinsam aktualisiert. Du schreibst zwar, dass das bei dir der Fall wäre, jedoch kann ich dann eben nicht erklären wie es zu dem Fehler bei dir kommt, da ich ihn absolut nicht nachstellen kann.
Hallo zusammen,
ich habe ein Problem mit den Residents bzw. mit der Benachrichtungsmöglichkeit.
Ich habe alle Familienmitglieder als Residents angelegt, aber nicht alle haben einen Pushdevice (msgContactPush) angehängt. Wenn ich nun ein Push Message per "msg push @[dev_residents:residentsTotalAbsentDevs] |FHEM| test" sende, kommt folgendes zurück:
ERROR: Could not find any Push contact for device rr_Name1 - set attributes: msgContactPush | msgRecipientPush | msgRecipient
ERROR: Could not find any Push contact for device rr_Name2 - set attributes: msgContactPush | msgRecipientPush | msgRecipient
ERROR: Could not find any Push contact for device rr_Name3 - set attributes: msgContactPush | msgRecipientPush | msgRecipient
Kann ich für die Bewohner, der keinen Pushdienst haben, den Aufruf unterbinden?
Ich hoffe, dass das Thema hier richtig ist ???
Gruß
Patrick
Nein, das geht nicht. Wenn du das Reading so wie es ist benutzen willst, dann müssen alle Empfänger bzw. deren Empfangsmöglichkeiten auch existieren.
Hello Loredo, could you take a look at the following post?
https://forum.fhem.de/index.php/topic,84372.msg962588.html#msg962588
It seems tmr-RESIDENTStk_DurationTimer does not get cleaned up in defs::global::helper::bm and account for a daily memory increase in Fhem.
I will, probably not today.
%defs{global}->{helper}->{bm} is created by 98_apptime so I guess the mem. leak is not with your module. I will post the issue in the apptime thread also.
You should always restart fhem after using apptime. It is nothing which should run the whole time. It will definitly reduce your free memory. May be the command:
apptime clear
could help if you want to run a long time analysis. Analyse the data and clear it afterwards.
Where is it the documentation that apptime can not run the whole time? (in the ref. is only stated that it adds about 1% CPU time).
The problem remains that RESIDENTStk_DurationTimer is aggregated incorrectly in 98_apptime. It creates a new entry for each RESIDENTStk_DurationTimer, instead it should increase the counter for the entry.
Also apptime clear clears the hash, but memory is not decreased. Only after Fhem restart.
The reason you get to see the function name several times is simply because there are indeed several executions of it - one per defined device (and you probably have defined several ROOMMATE/GUEST/PET accounts).
Yes, but I don't have 2091 presence devices running. :)
I have 3 different presence devices (Rm_Heidi, Rm_Sen, Res_Landsroem) but they are not aggregated correctly. Apptime creates a new entry for every RESIDENTStk_DurationTimer instead of increasing the count for each of the 3 devices.
active-timers: 53; max-active timers: 60; max-timer-load: 8 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 347.1ms; totAvgDly: 0.5ms
------ apptime PAUSED data collection ----------
name function max count total average maxDly avgDly TS Max call param Max call
tmr-freezemon_ProcessTimer HASH(0x55ecadcf2650) 0 1087 159.07 0.15 41.35 0.62 30.07. 14:40:59 HASH(freezemon)
tmr-VIERA_GetStatus HASH(0x55ecaf87cab0) 7 18 122.13 6.79 13.46 1.42 30.07. 14:28:24 HASH(Viera)
tmr-Modbus_ProcessRequestQueue queue 2 1728 2486.96 1.44 13.20 0.38 30.07. 14:30:24 queue:Modbus_USB
tmr-BlockingKill HASH_unnamed 0 18 0.44 0.02 9.82 0.84 30.07. 14:33:34 HASH(0x55ecb01a7c90)
tmr-ModbusLD_GetUpdate update 13 108 997.91 9.24 8.87 0.56 30.07. 14:24:44 update:iEM3155
tmr-Unifi_DoUpdate HASH(0x55ecaf87bd00) 1 18 24.73 1.37 0.92 0.49 30.07. 14:36:29 HASH(Unifi)
tmr-Aqicn::Timer_GetData HASH(0x55ecae3dc5d0) 1 2 2.34 1.17 0.92 0.63 30.07. 14:32:52 HASH(Aqicn_Brussels)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb1a24428) 0 1 0.48 0.48 0.81 0.81 30.07. 14:30:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb1da61a0) 0 1 0.49 0.49 0.80 0.80 30.07. 14:27:42 HASH(Rm_Heidi_DurationTimer)
tmr-FW_closeInactiveClients 0 0 18 9.07 0.50 0.76 0.41 30.07. 14:28:21 0
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb1e98d78) 0 1 0.52 0.52 0.75 0.75 30.07. 14:25:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb22d6aa0) 0 1 0.52 0.52 0.71 0.71 30.07. 14:35:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb1262e78) 0 1 0.48 0.48 0.70 0.70 30.07. 14:34:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb0231388) 0 1 0.42 0.42 0.70 0.70 30.07. 14:25:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb19e4b48) 0 1 0.53 0.53 0.69 0.69 30.07. 14:34:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25fb180) 0 1 0.60 0.60 0.68 0.68 30.07. 14:30:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25c9b18) 0 1 0.58 0.58 0.68 0.68 30.07. 14:27:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb23e0410) 0 1 0.75 0.75 0.68 0.68 30.07. 14:25:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb0fdcda0) 0 1 0.75 0.75 0.68 0.68 30.07. 14:34:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25d8ce0) 0 1 0.51 0.51 0.68 0.68 30.07. 14:35:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb04d7c00) 0 1 0.50 0.50 0.66 0.66 30.07. 14:31:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb22748e0) 0 1 0.57 0.57 0.66 0.66 30.07. 14:31:42 HASH(Rm_Sen_DurationTimer)
tmr-MQTT::Timer HASH(0x55ecaf648c90) 1 18 29.29 1.63 0.64 0.57 30.07. 14:26:29 HASH(Mosquitto)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25b20b0) 0 1 0.74 0.74 0.64 0.64 30.07. 14:35:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb229aad8) 0 1 0.52 0.52 0.64 0.64 30.07. 14:28:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb21fd368) 0 1 0.53 0.53 0.62 0.62 30.07. 14:38:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25b67c0) 0 1 0.75 0.75 0.62 0.62 30.07. 14:27:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb259bed0) 0 1 0.81 0.81 0.62 0.62 30.07. 14:31:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb1915228) 0 1 0.48 0.48 0.61 0.61 30.07. 14:38:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25ad688) 0 1 0.75 0.75 0.60 0.60 30.07. 14:32:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25ef5a8) 0 1 0.76 0.76 0.59 0.59 30.07. 14:28:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb2571418) 0 1 0.51 0.51 0.58 0.58 30.07. 14:29:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb048b218) 0 1 0.46 0.46 0.58 0.58 30.07. 14:29:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb13224e8) 0 1 0.61 0.61 0.58 0.58 30.07. 14:37:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25abd40) 0 1 0.75 0.75 0.58 0.58 30.07. 14:29:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25ec2d0) 0 1 0.52 0.52 0.56 0.56 30.07. 14:26:42 HASH(Rm_Heidi_DurationTimer)
tmr-Weather_GetUpdate HASH(0x55ecade83268) 1 2 2.12 1.06 0.55 0.39 30.07. 14:41:43 HASH(Weather_Ganshoren)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb25b85b8) 0 1 0.47 0.47 0.55 0.55 30.07. 14:28:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb1e6b700) 0 1 0.51 0.51 0.55 0.55 30.07. 14:39:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb209bc60) 0 1 0.74 0.74 0.54 0.54 30.07. 14:30:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer HASH(0x55ecb196b3c8) 0 1 0.74 0.74 0.54 0.54 30.07. 14:38:42 HASH(Res_Landsroem_DurationTimer)
Hallo zusammen,
ich steige gerade neu mit dem Residence Modul ein und habe da eine Merkwürdigkeit bei meinen Gästen entdeckt. Okay, die sind merkwürdig, aber das ist ein anderes Thema :-)
Der Status der guest devices ist nicht stabil.
set rg_<name> gone
Wird der Status gesetzt, so steht bei "state" ein "none"
define rg_<name> GUEST
erzeugt das device
Internals:
CFGFN
DEF Bewohner
DURATIONTIMER 1565768259.85002
FUUID 5d53b7e7-f33f-81e9-30d0-01d9a78003d7914b
FVERSION 20_GUEST.pm:0.195330/2019-06-02
NAME rg_<name>
NOTIFYDEV global,gast_<name>
NR 26039
NTFY_ORDER 50-rg_<name>
READY 1
RESIDENTGROUPS Bewohner
STATE none
SUBTYPE generic
TYPE GUEST
READINGS:
2019-08-14 09:36:39 durTimerAbsence 00:07:22
2019-08-14 09:36:39 durTimerAbsence_cr 7
2019-08-14 09:27:50 durTimerPresence 00:00:00
2019-08-14 09:27:50 durTimerPresence_cr 0
2019-08-14 09:27:50 durTimerSleep 00:00:00
2019-08-14 09:27:50 durTimerSleep_cr 0
2019-08-14 09:29:17 lastDeparture 2019-08-14 09:29:17
2019-08-14 09:29:17 lastLocation -
2019-08-14 09:29:17 lastState initialized
2019-08-14 09:29:17 location -
2019-08-14 09:29:17 presence absent
2019-08-14 09:29:17 state none
2019-08-14 09:29:17 wayhome 0
TIMER:
rg_<name>_DurationTimer:
HASH rg_<name>
MODIFIER DurationTimer
NAME rg_<name>_DurationTimer
Attributes:
alias <name>
devStateIcon .*zuhause:user_available:absent .*anwesend:user_available:absent .*abwesend:user_away:home .*verreist:user_ext_away:home .*bettfertig:scene_toilet:asleep .*schlaeft:scene_sleeping:awoken .*schläft:scene_sleeping:awoken .*aufgestanden:scene_sleeping_alternat:home .*:user_unknown:home
eventMap home:zuhause absent:abwesend gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
group Gaeste
icon scene_visit_guests
rg_presenceDevices gast_<name>:state
rg_realname alias
room Residents,Rollos
sortby 2
webCmd state
widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist
Der Besucher wird durch das rg_presenceDevice bei Anwesenheit erkannt und der Status "home" auch dem residence device übergeben. Dieser Status wird dann auch korrekt gehalten, jedoch erscheint dann nach der Abreise der Status "none", der sich auch nicht überschreiben lässt.
Dieses Symptom habe ich bei allen Type: GUEST .
Das Attribut rg_autoGoneAfter 12 habe ich bereits ebenfalls ausprobiert.
Die devices mit "Type: ROOMMATE" funktionieren indies korrekt.
Dann noch eine Frage zu den anderen Stati:
Wie schaltet Ihr zb. auf gotosleep, asleep oder awoken ? Für awoken habe ich schon mal etwas über einen Taster am Bett gelesen. Gibt es da auch noch andere Lösungen?
Viele Grüße
Christian
Works as designed, das soll so sein bei Gästen.
Ansonsten schalte ich die Schlafstatus per Alexa.
Zitat von: Loredo am 14 August 2019, 10:00:24
Works as designed, das soll so sein bei Gästen.
Okay, also gibt es bei Gästen nur den Status "home" oder "none" ?
Sollte man dann nicht die anderen Stati aus der device Definition bereinigen? Mich hat es so etwas verwirrt.
Viele Grüße
Christian
Es gibt alle Status, aber "gone" heißt hier eben sinnvollerweise "none", weil es keinen Gast gibt, der für längere Zeit verreist ist, sondern nur welche, die kurz mal außer Haus sind.
Zitat von: Loredo am 14 August 2019, 10:35:44
Es gibt alle Status, aber "gone" heißt hier eben sinnvollerweise "none", weil es keinen Gast gibt, der für längere Zeit verreist ist, sondern nur welche, die kurz mal außer Haus sind.
Ahhh, jetzt wird nen Schuh draus. Vielen Dank für die Hilfestellung.
Hallöchen,
Zunächst einmal Danke für dieses tolle Modul. Die Möglichkeiten die sich hier ergeben, sind schon weitreichend :)
Ich hab jetzt zum ersten mal auf einer zweiten Istallation damit ein wenig rum gespielt und direkt mal zwei Fragen dazu:
- Sobald ich ein PET angebe, ändert sich die ReadingsGroup für anwesende Bewohner NIE auf absent - Außer eben man setzt das Tier auf Abwesend. Es ist später so gedacht, dass der kleine Flohtransporter keine Events Bewegungsmelder etc mehr auslösen soll, dafür wäre für mich die einfachste Erkennung wenn die RG - Residents tatsächlich auch anzeigen würde, dass die angegebenen Bewohner weg sind und nur noch Tiere zu Hause sind ? - Oder hab ich hier was falsch verstanden ?
- Gibt es eine Möglichkeit die Zeitspanne der An(ab)wesenheit etwas anzupassen ? Also zB 1-10 Min => jede Minute, 5-90 Min => alle 5 Min, danach alle => 30 Min (um das Ganze etwas übersichtlicher zu gestalten und auch ein mögliches Eventgespamme ein wenig zu verringern ? )
Zu guter Letzte (glaube ich) habe ich noch einen kleinen Bug gefunden:
Edith sagt: Doch kein Bug, nur n feature;)
Ich habe zwei identische Bewohner angelegt:
Internals:
CFGFN
DEF RESIDENT_ALL
DURATIONTIMER 1568641594.22403
FUUID 5d7f8a92-f33f-8d79-f56d-c0f56ca9bd77ac3c
FVERSION 20_ROOMMATE.pm:0.195330/2019-06-02
NAME rr_Andreas
NOTIFYDEV global,
NR 130
NTFY_ORDER 50-rr_Andreas
READY 1
RESIDENTGROUPS RESIDENT_ALL
STATE zuhause
SUBTYPE adult
TYPE ROOMMATE
READINGS:
2019-09-16 15:33:38 durTimerAbsence 00:00:00
2019-09-16 15:33:38 durTimerAbsence_cr 0
2019-09-16 15:45:34 durTimerPresence 00:10:00
2019-09-16 15:45:34 durTimerPresence_cr 10
2019-09-16 15:13:55 durTimerSleep 00:00:00
2019-09-16 15:13:55 durTimerSleep_cr 0
2019-09-16 15:35:34 lastArrival 2019-09-16 15:35:34
2019-09-16 15:35:08 lastDeparture 2019-09-16 15:35:08
2019-09-16 15:35:34 lastDurAbsence 00:00:26
2019-09-16 15:35:34 lastDurAbsence_cr 0
2019-09-16 15:35:08 lastDurPresence 00:01:30
2019-09-16 15:35:08 lastDurPresence_cr 2
2019-09-16 15:35:08 lastLocation home
2019-09-16 15:35:08 lastMood calm
2019-09-16 15:35:34 lastState absent
2019-09-16 15:35:34 location home
2019-09-16 15:35:34 mood calm
2019-09-16 15:35:34 presence present
2019-09-16 15:35:34 state home
2019-09-16 15:13:55 wayhome 0
TIMER:
rr_Andreas_DurationTimer:
HASH rr_Andreas
MODIFIER DurationTimer
NAME rr_Andreas_DurationTimer
Attributes:
alias Andreas
comment Auto-created by RESIDENT_ALL
devStateIcon .*zuhause:user_available:absent .*anwesend:user_available:absent .*abwesend:user_away:home .*verreist:user_ext_away:home .*bettfertig:scene_toilet:asleep .*schlaeft:scene_sleeping:awoken .*schläft:scene_sleeping:awoken .*aufgestanden:scene_sleeping_alternat:home .*:user_unknown:home
eventMap home:zuhause absent:abwesend gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
group Bewohner
icon people_sensor
room Residents
rr_realname group
sortby 1
webCmd state
widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist
Wie man sieht , ist der Alias: Andreas (bzw vom zweiten Anwesenden Yvonne). Ändere ich jetzt irgendwo den Status, dann steht im Eventlog:
2019-09-16 15:35:08 RESIDENTS RESIDENT_ALL residentsAbsentDevs: rr_Andreas,rr_Yvonne
2019-09-16 15:35:08 RESIDENTS RESIDENT_ALL residentsAbsentNames: Bewohner, Bewohner (statt Andreas,Yvonne)
oder
2019-09-16 15:35:08 RESIDENTS RESIDENT_ALL lastActivityBy: Bewohner(statt Andreas)
2019-09-16 15:35:08 RESIDENTS RESIDENT_ALL lastActivityByDev: rr_Andreas
Ich denke mal, dass es sich hier um einen kleinen Bug handelt und es wird das Attribut "Group" (die heißt nämlich bei mir Bewohner) statt des Attributes "Alias". Ursprünglich nach dem Erstellen der jeweiligen Bewohner hieß die Gruppe nämlich auch wie der Alias Name. Ich denke dadurch war es schwerer das zu entdecken oder habe ich auch hier was falsch gemacht ?
Vielen Dank für alle erdenklichen Antworten, schon im Voraus :)
viele Grüße
Andreas
Hallo,
bzgl. des vermeintlichen Bug solltest du das Attribut rr_realname nicht auf group sondern auf alias stellen. Dann funktioniert es denke ich wie du möchtest. Somit wird der reale Name nicht aus der Gruppe sondern aus dem Attribut Alias genommen.
Hai trinitywhm,
danke für den schnellen Hinweis: Der Sinn dahinter ist mir jetzt nicht so ganz klar, aber so funktioniert es natürlich richtig :)
Grüße
Andreas
Zitat von: flummy1978 am 16 September 2019, 15:54:17
- Gibt es eine Möglichkeit die Zeitspanne der An(ab)wesenheit etwas anzupassen ? Also zB 1-10 Min => jede Minute, 5-90 Min => alle 5 Min, danach alle => 30 Min (um das Ganze etwas übersichtlicher zu gestalten und auch ein mögliches Eventgespamme ein wenig zu verringern ? )
Events reduzieren ... event-on-change-reading
wenn du die Timer-Werte nicht brauchst Attribut rr_noDuration 1
Danke auch dir für die schnelle Antwort kadettilac89,
Zitat von: kadettilac89 am 16 September 2019, 18:22:39
Events reduzieren ... event-on-change-reading
wenn du die Timer-Werte nicht brauchst Attribut rr_noDuration 1
Mir ging es in erster Linie um eine Moduleigene Möglichkeit, die allgemeinen kenne ich natürlich:
event-on-change-reading würde hier nichts ändern (das Event ändert sich ja immer). Außerdem wäre es hier nicht wie gewünscht statisch bei entsprechend langer / kurzer Abwesenheit die Abfrage zu erhöhen / verringern.
No duration habe ich bereits entdeckt, wäre jetzt für mich nicht so die optimale Lösung, weil es ja dadurch viele Möglichkeiten gibt :)
Grüße
Andreas
Zitat von: Loredo am 04 Mai 2019, 21:09:45
Ich habe jetzt gerade noch eine neue Version aller Module eingecheckt, die einen "Home Alone" Modus mitbringt.
Dabei werden für alle RESIDENTS Sub-Module auch subTypes eingeführt (über Attribute). Diese basieren bei ROOMMATE auf der Altersklasse ('baby', 'toddler', 'child', 'teenager', 'adult', 'senior'). Bei GUEST gibt es 'generic', 'minor', 'domesticWorker', 'vacationer'. Und bei PET kann man (eher spaßeshalber) auch angeben, um welche Art von Tier es sich handelt ('generic', 'bird', 'cat', 'dog', 'monkey', 'pig').
Aus dem subType wird dann errechnet, ob diese Person (oder das Tier) als unselbstständig angesehen wird und somit als "allein zu Hause" gilt. Dafür werden dann 3 neue Readings im RESIDENTS Device erstellt. Über ein weiteres Attribut kann man dann den RESIDENTS Gerätestatus mit einem Präfix versehen, welcher dem subType entspricht.
Also entweder hab ich Tomaten auf den Augen, oder ich blick gerade überhaupt nicht durch:
Wo finde ich die Einstellung des Alters eines ROOMMATES, so dass sich der SubType von 'adult' auf 'child' ändert???
Eine altersabhängige Einstufung wäre sicherlich wünschenswert, aber für die einen beginnen Teenager ab 12 und für die anderen ab 14.
Du kannst zur Zeit im Residents/Roommate-Device deiner Person das Attribut "subType" mit den passenden Einstellungen definieren.
Gruß
Danny
Achso dann hab ich das total falsch verstanden. Danke für Hilfe.
Zitat von: flummy1978 am 16 September 2019, 18:35:39
Danke auch dir für die schnelle Antwort kadettilac89,
Mir ging es in erster Linie um eine Moduleigene Möglichkeit, die allgemeinen kenne ich natürlich:
event-on-change-reading würde hier nichts ändern (das Event ändert sich ja immer). Außerdem wäre es hier nicht wie gewünscht statisch bei entsprechend langer / kurzer Abwesenheit die Abfrage zu erhöhen / verringern.
No duration habe ich bereits entdeckt, wäre jetzt für mich nicht so die optimale Lösung, weil es ja dadurch viele Möglichkeiten gibt :)
Grüße
Andreas
Ich fände das auch gut, alle 60 Sekunden Log-Einträge für drei Residents sind für mich relativ überflüssig.
Wenn ich das richtig verstehe, kann man aber nur entweder ganz darauf verzichten oder es so lassen? Nicht einmal abhängig von der Dauer, aber generell sagen zu können, dass presence auch auf 15 min. genau und damit Log-Einträge nur alle 15 Minuten benötigt werden, wäre auch schon prima.
Aloha,
wie passend, dass ich gerade hier eh am surfen und basteln bin, somit auch Zeit hab zu antworten ::)
Zitat von: johndoe am 10 Januar 2020, 20:29:21
Wenn ich das richtig verstehe, kann man aber nur entweder ganz darauf verzichten oder es so lassen? Nicht einmal abhängig von der Dauer, aber generell sagen zu können, dass presence auch auf 15 min. genau und damit Log-Einträge nur alle 15 Minuten benötigt werden, wäre auch schon prima.
Genau das kannst Du aber mit der Beschränkung machen. Ich habe es jetzt so gelöst:
Residents Device:
event-on-change-reading durTimerPresence.*:150,.*
event-on-update-reading presence
Residents:
event-on-change-reading lastDeparture,lastArrival,lastState,lastLocation,presence,state,location
Geloggt wird bei mir nur noch gezielt, weil ich die Sachen ja doch nicht anschaue, die sich da ewig sammeln. Ich möchte nicht zwingend mitloggen wann meine Frau genau wie lange warum zu Hause war oder eben nicht ;D
Aber mit eingem Beispiel wie oben bei durTimerPresence.*:150,.* kannst Du es dennoch ja selbst beschränken, wann welche Wertänderungen ein Event auslösen sollen (hier ist es ja so beschränkt, dass es erst ein Event gibt, wenn der Wert von durTimerPresence sich um 150 geändert hat.
Hoffe geholfen zu haben.
Grüße
Andreas
Zitat von: flummy1978 am 10 Januar 2020, 20:44:00
Aloha,
wie passend, dass ich gerade hier eh am surfen und basteln bin, somit auch Zeit hab zu antworten ::)
Genau das kannst Du aber mit der Beschränkung machen. Ich habe es jetzt so gelöst:
Residents Device:
event-on-change-reading durTimerPresence.*:150,.*
event-on-update-reading presence
Residents:
event-on-change-reading lastDeparture,lastArrival,lastState,lastLocation,presence,state,location
Geloggt wird bei mir nur noch gezielt, weil ich die Sachen ja doch nicht anschaue, die sich da ewig sammeln. Ich möchte nicht zwingend mitloggen wann meine Frau genau wie lange warum zu Hause war oder eben nicht ;D
Aber mit eingem Beispiel wie oben bei durTimerPresence.*:150,.* kannst Du es dennoch ja selbst beschränken, wann welche Wertänderungen ein Event auslösen sollen (hier ist es ja so beschränkt, dass es erst ein Event gibt, wenn der Wert von durTimerPresence sich um 150 geändert hat.
Hoffe geholfen zu haben.
Grüße
Andreas
Cool, danke, funktioniert! :)
Bitte auch nicht Events mit Logeinträgen gleichsetzen, das sind zwei unterschiedliche Paar Schuhe.
Absolut OT aber
Zitat von: Loredo am 10 Januar 2020, 22:38:58
Bitte auch nicht Events mit Logeinträgen gleichsetzen, das sind zwei unterschiedliche Paar Schuhe.
Ich kann da nur aus meiner vollkommenen Anfängerzeit (Auch wenn ich mich jetzt maximal als Durchschnitt mit ein wenig Perl Erfahrung bezeichnen würde) sprechen:
(Fast) jedes Gerät (oder zumindest sehr viele von den, die ich bisher erstellt habe) erzeugen bei der Erstellung ein Log Device. Dieses wird am Anfang erstmal stehen gelassen (weil könnte man ja gebrauchen)... irgendwann stellt man fest, man hat viel zu viele und verbindet diese mit Fhem .... irgendwann hat man die Kinderkrankheiten im Griff, so dass man das Meiste davon nicht mehr braucht und dennoch sind die Logs noch da. Und eben um DIESE Logs zu sparen, versucht man (so ging es mir zumindest) auf die Masse an Event zu unterbinden die
man persönlich nicht benötigt.
Ich für meinen Teil mache das jetzt so, dass ich alle Tage (oder wenn ich wenig gebastelt habe Wochen) für 1-3 Tage ein .* Log erstelle und kontrolliere damit ob ich irgendwo Events hab, die vollkommen unnötig sind, diese aber aktiv sind. So kann ich den Teil dann den letzten Teil, den ich vielleicht übersehen hab dann ausmerzen.... Bisher fahre ich damit ganz gut ;)
Grüße
Andreas
Zitat von: flummy1978 am 11 Januar 2020, 01:31:34
(Fast) jedes Gerät (oder zumindest sehr viele von den, die ich bisher erstellt habe) erzeugen bei der Erstellung ein Log Device.
Ich kenne da ehrlich gesagt kein einziges Modul, was das tut.
Zitat von: Loredo am 11 Januar 2020, 11:47:51
Ich kenne da ehrlich gesagt kein einziges Modul, was das tut.
Ähem... wenn ein MQTT oder Homematic Gerät erstelle wird doch immer ein FileLog erstellt? (oder reden wir da grad an einander vorbei?)
Grüße
Andreas
Mag sein, nutze ich beides nicht. Eigentlich gilt es als verpönt Geräte automatisch anzulegen, die für den Betrieb nicht zwingend erforderlich sind. ¯\_(ツ)_/¯
Ist aber Sache des jeweiligen Modulautors. Ich würde alle Geräte, die mir automatisch angelegt werden, mit denen ich aber nix anfangen kann, direkt wieder löschen. Welche Events auch als Daten geloggt werden sollen, ist eben eine explizite Entscheidung (und damit auch Konfiguration), wie ihr ja gerade auch selbst festgestellt habt ;-)
Hallo,
ich kämpfe gerade mit den möglichen Zuständen meiner Roommates und den Guests.
Eigentlich benötige ich derzeit nur "home", "absent" und "gone" bzw. halt alles auf Deutsch.
Daher habe ich im Residents-Device das Attribut "rr_lang=DE" gesetzt und das Attribut "rr_states=home,absent,gone".
Das Attribut "widgetOverride=state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist" blieb dann aber wie es war.
Muss ich widgetOverride selbst anpassen?
Dann habe ich einen Guest angelegt, der hat nun auch das Attribut "widgetOverride=state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist" besitzt.
Muss ich auch dort das widgetOverride selbst anpassen?
Danke, lg, Gerhard
Ja, du musst die Attribute selbst anpassen, dafür sind sie da.
Verstehe. Danke.
Eine Frage bitte noch zu den Guests.
Dort gibt es ja nur die Zustände ,,home/none".
Das widgetOverride steht auf "widgetOverride=state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist".
Home=zuhause, absent=adwesend, gone=verreist.
Aber wie übersetze ich none?
Wahrscheinlich stehe ich nur gerade am Schlauch.
Danke im Voraus
Lg, Gerhard
Hallo Gerhard,
ganz einfach entweder sind Gäste da, oder none = keine Gäste, ...zero, Gerhard allein zu Hause! Alle möglichen Verdächtigen nicht da. Dort macht das widgetOverride wenig Sinn.
Hallo det.,
Danke. Soweit hatte ich es verstanden und so möchte ich es auch.
Ich versuche es nochmal zu erklären:
In meinem Zuhause-Device habe ich soeben einen neuen Gast (=rg_Gast2) angelegt.
Auswahlmöglichkeiten beim Setzen des Zustands: zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist
Aber ich hätte mir erwartet, dass dort nur "zuhause,none" steht. Warum also so viele?
Gut, lösche ich widgetOverride halt raus.
Dann gibt es die Auswahlmöglichkeiten: "home,gotosleep,absent,none"
Was muss ich im widgetOverride eintragen?
Danke, lg, Gerhard
p.s.: Hier das "list rg_Gast2":
Internals:
CFGFN
DEF Zuhause
DURATIONTIMER 1579814974.70318
FUUID 5e2a0f35-f33f-0b7a-0805-b7f4b910dcbcb942
FVERSION 20_GUEST.pm:0.195330/2019-06-02
NAME rg_Gast2
NOTIFYDEV global,
NR 48337
NTFY_ORDER 50-rg_Gast2
READY 1
RESIDENTGROUPS Zuhause
STATE zuhause
SUBTYPE generic
TYPE GUEST
READINGS:
2020-01-23 22:25:11 durTimerAbsence 00:00:00
2020-01-23 22:25:11 durTimerAbsence_cr 0
2020-01-23 22:28:34 durTimerPresence 00:03:23
2020-01-23 22:28:34 durTimerPresence_cr 3
2020-01-23 22:25:11 durTimerSleep 00:00:00
2020-01-23 22:25:11 durTimerSleep_cr 0
2020-01-23 22:25:11 lastArrival 2020-01-23 22:25:11
2020-01-23 22:25:11 lastState initialized
2020-01-23 22:25:11 mood calm
2020-01-23 22:25:11 presence present
2020-01-23 22:25:11 state home
2020-01-23 22:25:11 wayhome 0
TIMER:
rg_Gast2_DurationTimer:
HASH rg_Gast2
MODIFIER DurationTimer
NAME rg_Gast2_DurationTimer
helper:
bm:
RESIDENTStk_Attr:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 23.01. 22:25:10
max 7.29560852050781e-05
tot 7.29560852050781e-05
mAr:
set
rg_Gast2
rg_lang
DE
RESIDENTStk_Define:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 23.01. 22:25:09
max 0.00249886512756348
tot 0.00249886512756348
mAr:
HASH(0x10d351d0)
rg_Gast2 GUEST Zuhause
RESIDENTStk_InitializeDev:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 23.01. 22:25:10
max 3.00407409667969e-05
tot 3.00407409667969e-05
mAr:
HASH(0x10d351d0)
RESIDENTStk_Notify:
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 23.01. 22:25:10
max 0.0116620063781738
tot 0.0117061138153076
mAr:
HASH(0x10d351d0)
HASH(0x15eca68)
RESIDENTStk_Set:
cnt 8
dmx -1000
dtot 0
dtotcnt 0
mTS 23.01. 22:25:11
max 0.173048973083496
tot 0.176970720291138
mAr:
HASH(0x10d351d0)
rg_Gast2
silentSet
state
home
Attributes:
alias Gast2
comment Auto-created by Zuhause
devStateIcon .*zuhause:user_available:absent .*anwesend:user_available:absent .*abwesend:user_away:home .*verreist:user_ext_away:home .*bettfertig:scene_toilet:asleep .*schlaeft:scene_sleeping:awoken .*schläft:scene_sleeping:awoken .*aufgestanden:scene_sleeping_alternat:home .*:user_unknown:home
eventMap home:zuhause absent:abwesend gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
group Guests
icon scene_visit_guests
rg_lang DE
rg_realname alias
room Anwesenheiten
sortby 1
webCmd state
widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist
Hallo,
eine vielleicht dumme Frage... Aber wie bekomme ich den Status asleep in die Auswahl. Bisher ist dort nur home, gotosleep, absent, none eingetragen.
Vielen Dank und viele Grüße
attr rr_showAllStates
Gruß Michael
Besten Dank!
Ich bin gerade auf RESIDENTS/ROOMMATE umgestiegen. Es klappt alles recht gut.
Allerdings kämpfe ich etwas mit dem Sprach-Mischmasch:
Das RESIDENTS Device heißt bei mir rgr_Familie. Ich habe ein notify auf rgr_Familie:presence.* definiert.
Wenn ich den Status von rgr_Familie auf "zuhause" setze, kommt in $EVTPART1 "present".
Setze ich den Status auf "abwesend" oder "verreist", kommt in $EVTPART1 "abwesend".
Ich habe jetzt mal rgr_lang auf "EN" gesetzt, dann ist es wenigstens konsistent Englisch.
Ergänzung: So ganz konsistent ist es auch dann nicht. Auch bei dieser Einstellung stehen im Dropdown-Menü bei "set" deutsche Bezeichnungen.
Ich nutze Roommate und Residents in Verbindung mit HOMEMODE schon sehr lange und es schnurrt wie ein Uhrwerk. Zum setzen von Locations nutze ich eine GEOFANCY App in Verbindung mit GPS und iBeacons, auch das klappt prima und völlig stabil.
Ich hätte aber mal eine "kosmetische" Frage. Wenn ich in FHEM einen Roommate der zu Hause ist manuell auf "absent" schalte springt seine Location auf "unterwegs". So soll es sein und so habe ich es konfiguriert aber natürlich setzt keiner seinen Status manuell in FHEM. Im normalen Leben verlässt der Roommate die Home Location und sein GEOFANCY App sendet ein "EXIT" wenn der den GPS Bereich verlässt. FHEM setzt dann auch richtigerweise den entsprechenden ROOMMATE auf absent, die Location bleibt aber unverändert. Das passiert auch bei externen Locations.
Im Augenblick helfe ich mir damit das ich in der GEOFANCY App, pro Location 2 Einträge machen. Einer für das Erreichen z.B. Office und einen für das Verlassen, der heist dann "unterwegs". Das funktioniert zwar problemlos, ist aber nicht im Sinne des Erfinders. So kann ich nämlich die Funktion "Wayhome" nicht nutzen. Dafür müsste ich ja z.B. die Location "Office" auch tatsächlich verlassen werden und nicht die Location "unterwegs". Ich hoffe Ihr könnt mir folgen ;D
Details und Logs stelle ich gerne bereit, wollte aber erst mal fragen ob ich einen Denkfehler habe?
hi,
ich nutze kein Geofancing, sondern 3 im Haus verteilte Unify Access-Points. Dadurch kann ich grob den Aufenthaltsort der einzelnen Personen bestimmen. Und zwar setzt bei mir ein DOIF die location der Roommates, je nachdem an welchem AP der Roommate angemeldet ist. (Alle 3 Locations sind unter rr_LocationHome angegeben).
Wenn ein Roommate nicht mehr mit deinem der Accesspoints verbunden ist, dann stellt das DOIF die Location von diesem Roommate auf underway. Dadurch wird auch presence auf absensece gestellt und der state vom Roommate auch passend gesetzt.
Ich ändere also nicht den State sondern die location. Funktioniert sehr gut bei mir.
Gruß Michael
Zitat von: l2r am 19 März 2020, 21:56:57
hi,
ich nutze kein Geofancing, sondern 3 im Haus verteilte Unify Access-Points. Dadurch kann ich grob den Aufenthaltsort der einzelnen Personen bestimmen. Und zwar setzt bei mir ein DOIF die location der Roommates, je nachdem an welchem AP der Roommate angemeldet ist. (Alle 3 Locations sind unter rr_LocationHome angegeben).
Wenn ein Roommate nicht mehr mit deinem der Accesspoints verbunden ist, dann stellt das DOIF die Location von diesem Roommate auf underway. Dadurch wird auch presence auf absensece gestellt und der state vom Roommate auch passend gesetzt.
Ich ändere also nicht den State sondern die location. Funktioniert sehr gut bei mir.
Gruß Michael
Ich ändere auch nur die Location. Dabei geht mir nicht um Locations innerhalb meiner Wohnung, sondern um externe (Office, usw). Wenn du geofancing nutzt, braucht man keine DOIF o.ä. Das macht Roommate alles "out of the box". Halt nur mit dem kleinen kosmetischen "Fehler" den ich beschrieben habe.
Im Grunde ist meine Erwartung, das wenn man in keiner Location anwesend ist, Roommate auf "underway" steht.
Hallo,
wäre es möglich im Modul Roommate ein zusätzliches Attribut für "Geschlecht" einzufügen?
Damit könnte ich die richtigen Anreden im msgdialog und Telegramm leichter umsetzen.
Man kann es zwar auch mit userattr bzw. userreadings machen, aber so wäre es einheitlich.
lg, Gerhard
Bzgl. der Einheitlichkeit: Wozu um Himmels Willen braucht der Roommate in FHEM ein Geschlecht? ::)
Da macht man dann ein weites Feld auf:
https://genderdings.de/gender/geschlechtsidentitaet/ (https://genderdings.de/gender/geschlechtsidentitaet/)
;)
Zitat von: volschin am 28 September 2020, 12:27:06
Bzgl. der Einheitlichkeit: Wozu um Himmels Willen braucht der Roommate in FHEM ein Geschlecht? ::)
Alle Roommates in msg-Nachrichten immer mit "es" anreden passt auch nicht ;-)
Und alles neutral zu formulieren, ist auch nicht immer das Wahre.
Aber es stimmt schon, damit macht man sich ein weites Feld auf ;-)
Vielleicht bleibe ich besser bei meinem User-Attribut.
lg, Gerhard
Following patch fixes an issue upon parsing ROOMMATE rr_presenceDevices reading value.
The second regex matches 'maybe present' but not 'maybe absent'. In fact it matches '.* present'. Maybe this is intentional, but it disables the usage of the presenceTimeout attribute in ROOMMATE.
The first regex has similar issue (start of string is only enforced with value 0).
--- - 2020-12-12 00:08:37.369875325 +0100
+++ /srv/fhem/FHEM/RESIDENTStk.pm 2020-12-12 00:08:33.188543696 +0100
@@ -1514,7 +1514,7 @@
# early exit if unexpected event value
next
unless ( $value =~
-m/^0|false|absent|disappeared|unavailable|unreachable|disconnected|1|true|present|appeared|available|reachable|connected$/i
+m/^(?:0|false|absent|disappeared|unavailable|unreachable|disconnected|1|true|present|appeared|available|reachable|connected)$/i
);
my $counter = {
@@ -1536,7 +1536,7 @@
# ignore device if it has unexpected state
next
unless ( $presenceState =~
-m/^(0|false|absent|disappeared|unavailable|unreachable|disconnected)|(1|true|present|appeared|available|reachable|connected|)$/i
+m/^(?:(0|false|absent|disappeared|unavailable|unreachable|disconnected)|(1|true|present|appeared|available|reachable|connected|))$/i
);
$counter->{absent}++ if ( defined($1) );
Hallo Loredo,
ich glaube ich habe einen Fehler gefunden:
Das GUEST device schaltet den guest nach Ablauf der "rg_autoGoneAfter" Zeit nicht auf 'gone', wie in der Dokumentation, sondern auf 'none' (das attribut ''rg_states'' erlaubt auch gar kein 'gone' als Auswahl). Dadurch passiert dann folgendes:
Ich habe ein rgr_Residents device, das hat genau einen ROOMMATE und genau einen GUESTS. Wenn der GUEST state auf 'none' steht, und der ROOMMATE state von 'absent' auf 'home' wechselt, bleibt das rgr Residents device auf 'absent'.
Nur wenn der GUEST state auf 'absent' steht, und der ROOMMATE state von 'absent' auf 'home' wechselt, wechselt auch das rgr Residents device auf 'home'.
Magst Du Dir das mal anschauen?
Zitat von: Jamo am 29 Oktober 2021, 13:40:24
Hallo Loredo,
ich glaube ich habe einen Fehler gefunden:
Das GUEST device schaltet den guest nach Ablauf der "rg_autoGoneAfter" Zeit nicht auf 'gone', wie in der Dokumentation, sondern auf 'none' (das attribut ''rg_states'' erlaubt auch gar kein 'gone' als Auswahl). Dadurch passiert dann folgendes:
Ich habe ein rgr_Residents device, das hat genau einen ROOMMATE und genau einen GUESTS. Wenn der GUEST state auf 'none' steht, und der ROOMMATE state von 'absent' auf 'home' wechselt, bleibt das rgr Residents device auf 'absent'.
Nur wenn der GUEST state auf 'absent' steht, und der ROOMMATE state von 'absent' auf 'home' wechselt, wechselt auch das rgr Residents device auf 'home'.
Magst Du Dir das mal anschauen?
Hallo Jamo,
das ist normal dass GUEST auf "none" statt auf "gone" wechseln, denn wenn der/die Gäste ganz weg sind, dann sind sie weg und es gibt eben keinen Gast mehr. Sobald es ein regelmäßiger Gast ist, so würde ich ihn als ROOMMATE anlegen.
Deine Beobachtung mit dem RESIDENTS Device sind mir bisher in den letzten Jahren nicht aufgefallen. Allerdings habe ich auch mehr als ein ROOMMATE und mehr als einen GUEST.
Gruß
Dan
Hallo Dan,
das komische ist ja das der Fehler nur auftritt, nachdem der rg_autogone timer gegriffen hat und das state vom rg_ device von 'absent' auf 'none' gestellt hat. Mit einem manuellen einstellen des guest auf none kann ich den Fehler nicht nachstellen.
Ich hab jetzt das rg_ device geloescht und genau mit den selbe attribute als rr_ roommate angelegt. Ich werde berichten.
PS:Zumindest ist die device specific help oder Dokumentation nicht richtig, da steht das 'none' das guest devise 'disabled', und 'gone' der state nach dem timeout des autogone timer ist.
Danke!
Hallo Loredo && Dan,
ich ziehe meinen Fehlerbericht zurück. Der Fehler liegt in meinem perl Code, ich habe wohl irgendeine Schleife im Code, die verhindert das sich der Roomate selber triggert. Nachdem ich ein "sleep 1;" vor die Ausführung des "set roomate home" eingebaut habe, also "sleep 1;set roomate home", funktionierts.
Danke fürs mitdenken, beste Grüsse Jamo
Hallo zusammen,
ich hätte eine Frage zur wakeupWaitPeriod. Grundsätzlich verstehe ich die Funktion dahinter und alles ist wunderbar.
Aber, ab und zu, kommt es bei mir vor das jemand vor der Weckzeit, z.B. eine Stunde vorher, kurz aufsteht (awoken->home) und sich wieder hinlegt (asleep).
Scheinbar greift dann auch die wakeupWaitPeriod und der Wecker klingelt eine Stunde später nicht mehr.
Ist das möglicherweise ein Bug? Die Person hat sich ja wieder "ordentlich" auf asleep gesetzt und daher würde ich erwarten, dass der Wecker dann klingelt.
Beispielhafte Daten:
Asleep 22:30
Toilettengang 04:00 -> awoken
Wieder hinlegen 04:15 -> asleep
Weckzeit 07:00
In diesem Beispielszenario klingt bei mir der Wecker nicht und im Log finde ich den entsprechenden Verweis auf wakeupWaitPeriod
Kann mich jemand aufklären? Alternativ kann ich natürlich verhindern, dass man bei dem Toilettengang überhaupt als awoken/home gemeldet wird. Aber trotzdem wollt ich mal fragen.
hi,
deine Frage kann ich dir leider nicht beantworten. Mich würde aber interessieren, wie du den Toilettengang tracst.
Gruß Michael