Ich hätte gerne eine Änderung am RESIDENTS-Modul. Ich weiß nicht, ob das viel Aufwand wäre, könnte aber in der Benutzung (mir) einige Mühe sparen und manches erst ermöglichen.
Und zwar gibt es ja schon "gotosleep" bzw. "awoken" als Übergänge zwischen "asleep" und "home". Mir fehlt jetzt das "leaving" bzw. "arriving" als Übergänge von "home" von und zu "absent/gone".
Allerdings bin ich mir bei manchen Konstellationen der ROOMMATE-Stati noch nicht ganz schlüssig, welchen Status dann das RESIDENTS haben müsste. Wenn dies Feature aber eh viel Programmieraufwand beduten würde, brauche ich nicht weiter zu knobeln und bilde dies anders ab.
Danke für eine Rückmeldung!
Es gibt doch wayhome das sollte zu mindest Dein arriving abdecken.
Bleibt ja auch die Frage wie Du das leaving automatisiert einstellen willst.
Zitat von: CoolTux am 27 Oktober 2018, 12:03:20
Es gibt doch wayhome das sollte zu mindest Dein arriving abdecken.
Ja, kenne ich. Aber erstens gibt es das nur beim ROOMMATE und zweitens muss ich dann immer bei absent/gone auch noch das wayhome zusätzlich abfragen.
Zitat
Bleibt ja auch die Frage wie Du das leaving automatisiert einstellen willst.
Ironische Gegenfrage: wie automatisierst Du gotosleep oder asleep? ;)
Ernsthaft: da ich Zugriff auf unsere Terminkalender habe, würde ich bei außer-Haus-Terminen von der letzten Erinnerung (= Fahr mal los!) noch wahrscheinlich 15 Minuten abziehen. Bzw. an Arbeitstagen weiß "das Haus", wann wir jeweils los müssen. Hier könnte ich ähnlich drauf reagieren. Zudem wäre das manuelle Setzen über ein Frontend auch einfacher.
Zitat von: alanblack am 27 Oktober 2018, 12:16:56
Ja, kenne ich. Aber erstens gibt es das nur beim ROOMMATE und zweitens muss ich dann immer bei absent/gone auch noch das wayhome zusätzlich abfragen.
Das ist nicht ganz zutreffend. Es gibt etwas ähnliches in Residents. residentsTotalWayhome
Zitat von: alanblack am 27 Oktober 2018, 12:16:56
Ironische Gegenfrage: wie automatisierst Du gotosleep oder asleep? ;)
Das wird pro Person unterschiedlich gesetzt. Meine Freundin stellt sich ihr Handywecker darauf reagier ein Notify und legt sie schlafen. Meine Tochter legt ihr Handy am Nachttisch ab und darauf reagiert NFC und darauf dann wieder ein Notify. Mein Sohn ist 5 der hat einen Taster mit Feuerwehrmann Sam drauf wo er drücken darf und so weiter.
ZitatMeine Freundin stellt sich ihr Handywecker darauf reagier ein Notify und legt sie schlafen.
Soein Notify, das meine Frau/Freundin schlafen legt, würde ich auch gerne haben ;)
Zitat von: dev0 am 27 Oktober 2018, 12:39:26
Soein Notify, das meine Frau/Freundin schlafen legt, würde ich auch gerne haben ;)
Nur schlafen, leider nicht ruhig ;D
Zitat von: CoolTux am 27 Oktober 2018, 12:23:55
Das ist nicht ganz zutreffend. Es gibt etwas ähnliches in Residents. residentsTotalWayhome
Hm... okay, habe ich übersehen. Hilft mir aber trotzdem nicht wirklich weiter. Die Geschichte mit rr_locations, rr_locationWayhome und Co. ist für meine Begriffe zu strikt. Abgesehen davon, dass ich "leaving" damit eh nicht abbilden kann, ist das Verfahren rr_locations e.al. passend zu füllen, schwierig und langwierig:
a) ich bin bei Freunden (rr_locations = ...,Freunde,... / rr_locationUnderway = ...,Freunde,...)
Setze ich "Freunde" auch in (rr_locationWayhome = ... Freunde ...) und gehe dort weg (BT-Verbindung im Auto => location = Auto), geht wayhome auf 1
- ich gehe von Freunden weg aber auf dem Weg - was weiß ich - ins Kino, bin ich die ganze Zeit wayhome auf 1
b) ich bin bei Freunden (rr_locations = ...,Freunde,FreundeNichtNachHause,... / rr_locationUnderway = ...,Freunde,FreundeNachHause,FreundeNichtNachHause,...) dann kann ich das abbilden
rr_locationWayhome = ... FreundeNachHause ... => ich setze also erst manuell die location = FreundeNachHause damit danach "das Auto" automatisch wayhome auf 1 setzt?
Vielleicht denke ich zu kompliziert oder habe die location-wayhome-home-underway-Logik noch nicht verstanden.
Ich würde eher per Telegram eine Nachricht an mein Haus schicken "Ich komme nach Hause", was zum Status "arriving" ausgewertet werden könnte.
Folge bspw.: falls das Haus leer ist, wird schon einmal die Heizung hochgeregelt und wenn der Bewegungsmelder an der Hofeinfahrt auslöst, geht auch gleich das Garagentor auf.
Bin ich "absent", ist es vielleicht der Briefträger, der den Melder auslöst => Garagentor bleibt zu.
Ich könnte in dem Moment natürlich das Reading "wayhome" auf 1 setzen. Das widerspricht IMHO aber dem Sinn eines zum Device gehörenden Readings.
Es kommt halt immer drauf an wie Du wayhome verwendest oder besser setzt.
Ich habe Automagic, wenn das merkt das ich in den 3km Kreis um mein zu Hause eintrette werde ich wayhome 1 gesetzt, dazu muss ich aber vorher raus gekommen sein aus den 3 km. Dein Freunde Beispiel ist vielleicht etwas arg weit her.
Wobei es bei mir auch noch klappen würde. Aber ich gebe Dir da Recht, wenn ich von einem Freund komme und nur zum Kino will fahre ich am zu Hause vorbei und wenn meine Heizung so funktionieren würde wie bei Dir würde ich "umsonst" heizen.
Ich habe da eine eher strikte Regelung für die Heizung, es gibt festgelegte Schaltpunkte und nur beim verlassen oder kommen werden diese Schaltungen überschrieben. Aber hier wird es auch nir so arg kalt. Unsere Wohlfühltemperatur liegt bei 19 Grad und ich setzte die Heizung beim verlassen auf 17.
Ein interessantes Beispiel wäre aber sicherlich mein verlassen der Arbeit. Denn nur wenn ich von der Arbeit komme und mein Roommate auf müde steht geht die Kaffeemaschine an sobald ich in den 3km Kreis meiner Wohnung eintrete. Bin ich zu Hause werde ich von Kaffeeduft begrüßt.
Zitat von: CoolTux am 27 Oktober 2018, 19:53:25
Es kommt halt immer drauf an wie Du wayhome verwendest oder besser setzt.
Eben! Gar nicht! Ein Reading ist die AUSGABE des dahinter liegenden Gerätes. Bei einem Dummy kann ich die selbst setzen, weil kein Gerät dahinter ist. Nicht vorhandene Readings kann ich vielleicht selbst setzen; auch wenn das grenzwertig ist. Aber ein vorhandenes und funktionierendes Reading selbst setzen? Irgendwann wird der Modulcode geändert, wayhome funktioniert mit den Werten 0 und 2 und bei wayhome =1 wird sudo rm -R * ausgeführt. Dann kommst du in deinen 3km Kreis...
Okay, dass ist arg konstruiert, aber es gibt Dinge, die man nicht programmieren sollte.
Meine Frage nach dieser Änderung war nicht getrieben von dem Gedanken, ob es irgendeine mögliche Lösung bereits gibt. Die Motivation dahinter ist die Konsequenz beim Verhalten des Moduls und mögliche Vereinfachung des nutzenden Codes unter Vermeidung von Spielereien.
Keine Ahnung was Du bei Deinem Roommate hast.
Aber ich kann bei meinem ein
set rr_NAME location wayhome
setzen. Und genau das macht mein Automagic. Ich gebe zu das mit dem Automatic ist selbst entwickelt und wird über ein webhook vom Handy an mein FHEM gesendet. Aber der set Befehl ist von Hause aus da.
Zitat von: CoolTux am 27 Oktober 2018, 22:50:59
Keine Ahnung was Du bei Deinem Roommate hast.
Aber ich kann bei meinem ein
set rr_NAME location wayhome
setzen. Und genau das macht mein Automagic. Ich gebe zu das mit dem Automatic ist selbst entwickelt und wird über ein webhook vom Handy an mein FHEM gesendet. Aber der set Befehl ist von Hause aus da.
Jetzt frage ich mich, was Du für eine Version benutzt. Egal welchen Status das ROOMMATE-Device hat, ein
set rr_ROOMMATE location wayhome
setzt bei mir nicht das Reading wayhome auf etwas anderes als 0. Es sei denn, ich pflege entsprechende rr_locations und rr_locationWayhome. Damit bin ich aber wieder bei der aufwändigen Liste von rr_locations, die ich eigentlich nicht pflegen möchte.
Dir ist aber schon klar das Dein state dafür absent oder gone sein muss?
Zitat von: CoolTux am 27 Oktober 2018, 23:38:02
Dir ist aber schon klar das Dein state dafür absent oder gone sein muss?
Dazu schrieb ich:
Zitat von: alanblack am 27 Oktober 2018, 23:26:04
Jetzt frage ich mich, was Du für eine Version benutzt. Egal welchen Status das ROOMMATE-Device hat, ein
Dazu:
set rr_NAME absent
set rr_NAME location wayhome
list rr_NAME wayhome
liefert
rr_NAME 2017-02-16 20:58:16 0
???
Habe gerade mal nachgeschaut. Ich habe noch ein Attribut gesetzt
attr NAME rr_locations atwork,home,wayhome,underway
Ich fände 2 neue states "leaving" bzw. "arriving" als Übergänge von "home" von und zu "absent/gone" ebenfalls gut. WayHome ist eine Location, und wird gesetzt wenn man von der Arbei losfährt.
"leaving" bzw. "arriving" dagagen, benutze ich wie folgt:
1) Arriving ist der Zustand, wo meine Anwesenheit erkannt wird (über bluetooth/wlan/Gtag), ich aber noch ausserhalb der verschlossenen Wohnung bin. Erst wenn die Wohnungstuer aufgeschlossen wird, bin ich wirklich 'zu Hause'.
2) Leaving ist der Zustand, nach schliessen der Wohnungstuer (und keine Bewegung mehr innerhalb der Wohnung), bis die Tuer verschlossen (lock) wird. Nur in diesem Zeitraum werte ich ein iBeacon aus, was dann zum 'lock' der Tuer führt. Ansonsten kam es schonmal vor, das die Tuer gelockt wurde, wenn man aber noch innerhalb der Wohnung war. Ähnlich wie bei 1) ist es der Zustand, wo meine Anwesenheit noch erkannt wird, bis ich wirklich die Wohnung verlassen habe (Tuer wird verschlossen).
Ja, man kann das auch über seperate Readings lösen, aber wenn ich den State im rr_* sichtbar hätte, würde mir das zumindest helfen.
Eventuell wuerde es ja helfen, wenn man einfach zusätzliche user-states definieren könnte.
Zitat von: CoolTux am 28 Oktober 2018, 08:03:02
Habe gerade mal nachgeschaut. Ich habe noch ein Attribut gesetzt
attr NAME rr_locations atwork,home,wayhome,underway
Ja, es geht ja. Aber wenn ich es so nutze, wie es die Doku vom RESIDENTS/ROOMMATE nahelegt, bin ich quasi wieder bei
Zitat
Die Geschichte mit rr_locations, rr_locationWayhome und Co. ist für meine Begriffe zu strikt. Abgesehen davon, dass ich "leaving" damit eh nicht abbilden kann, ist das Verfahren rr_locations e.al. passend zu füllen, schwierig und langwierig:
Denn die 3 km-Lösung von Dir ist mir zu statisch. Erstens bin ich mit dem Auto zu schnell da durch, dass es steuerungstechnisch für mein Haus Sinn ergibt, und zweitens habe ich Freunde und Verwandte innerhalb der näheren Umgebung, wo ich dann gar nicht erst raus wäre aus so einem Umkreis.
Ich hätte halt gerne nur die ganz einfache Lösung mit "leaving" und "arriving". Die kann ich - in seltenen Fällen - automatisch durch unsere Handys (hier mit Tasker, aber das nur am Rande), automatisch über die Terminkalender etc. oder teilautomatisch (Handy raus, das richtige Icon antippen, fertig) setzen kann.
Noch einmal: ich weiß, dass zumindest das "arriving" jetzt prinzipiell schon abbildbar ist. Das nervigste dabei ist einfach nur, dass ich an vielen Stellen nicht nur den State auswerten muss, sondern
...
elseif $state eq "absent" {
if $wayhome = 1 {
...
}
else
{
...
einbauen muss.
Ich kann das auch in eine sub packen. Es ist für mich nur logischer und konsequenter, wenn es ein "asleep => awoken => home" und ein "home => gotosleep => asleep" gibt, dass es dann auch sowohl ein "home => leaving => absent" als auch ein "absent => arriving => home" gäbe.
Ich habe es oben schon gesagt, dass es nur Sinn macht, das ins RESIDENTS-Modul einzubauen, wenn es einfach zu lösen ist. Ich könnte es auch selbst in eine Kopie des RESIDENTS-Moduls einbauen. Dann fehlen mir darin aber in Zukunft die Updates.
Vielleicht meldet sich der Maintainer ja mal dazu. Wäre ich dankbar für.
Zitat von: alanblack am 28 Oktober 2018, 14:12:50
Ich habe es oben schon gesagt, dass es nur Sinn macht, das ins RESIDENTS-Modul einzubauen, wenn es einfach zu lösen ist. Ich könnte es auch selbst in eine Kopie des RESIDENTS-Moduls einbauen. Dann fehlen mir darin aber in Zukunft die Updates.
Vielleicht meldet sich der Maintainer ja mal dazu. Wäre ich dankbar für.
Vorschlag. Julian ist immer recht beschäftigt. Daher meine Empfehlung, implementiere Deine Idee als Code ins Modul und erstelle einen Patch den Du Julian zu Diskussion anbietest.
Denke bitte daran wenn Du es so machst das Du die Commandref auch erweiterst.
Grüße
Zitat von: CoolTux am 28 Oktober 2018, 14:43:21
Vorschlag. Julian ist immer recht beschäftigt.
Abgesehen davon, dass ich auch alles andere als Langeweile habe, dürfte Julian die Änderungen mit seiner Kenntnis des Codes schneller fehlerfrei implementiert haben - oder zumindest mal vorab den Zeitbedarf bzw. den Aufwand abschätzen können. (Warum auch immer Du für ihn sprichst.)
Für mich ist es wahrscheinlich mehr Arbeit, die beiden Module zu ändern, als wenn ich die beiden Stati in meinem Code abfange - zumindest für den Moment. Langfristig ist es wahrscheinlich verkehrt, aber das weiß ich eh erst hinterher.
Nachtrag: ich habe mal in den Sourcecode geschaut. Zum Glück ist Perl meist leicht lesbar, denn die Inline-Doku ist "spärlich". :o
Also bis vor 3 Stunden warst Du der einzige mit dem Wunsch und daher erwarte, zu mindest ich, das der jenige wenn er schon von eigener Anpassung spricht ein Patch bereit stellt. Aber das ist meine Meinung.
Der Code wie du sagst gut lesbar ist, wieso sollte er dann noch mal Dokumentiert sein. Was bringt ein Kommentar welches das sagt was man im Code eh sieht.
Aber wie auch immer. Du machst das schon.
Ach und ich spreche nicht für ihn sondern mein Vorschlag ist einer der gängigen Wege im Open Source Bereich.
Grüße