Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST

[Loredo]

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.

[oberlon]

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. 

[Loredo]

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

[Per]

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

Code Auswählen Erweitern

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.

[Loredo]

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.

Den Großteil der "Eventflut" konnte ich erfolgreich mit

Code Auswählen Erweitern

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.

[Per]

Allerdings ä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.

Der 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.

[oberlon]

@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.

[oberlon]

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.

[Phiolin]

Für dieses Problem gibt es im DOIF das Attribut "checkReadingEvent". Damit wird das DOIF nur aktualisiert, wenn genau die im DOIF angegebenen Readings aktualisiert werden.

[Loredo]

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




Gruß
Julian

[acw81]

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

[Loredo]

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.

[acw81]

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.

[Amenophis86]

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:

Code Auswählen Erweitern

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.

[ThiemoSt]

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:

Code Auswählen Erweitern

##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?