Geofencing Modul für Geofency.com und Geofancy.com

Begonnen von Loredo, 07 Januar 2014, 16:57:26

Vorheriges Thema - Nächstes Thema

raspklaus

Danach bin ich ja vorgegangen, aber es wird nichts geschrieben:

define FileLog_LocationK FileLog ./log/LokationK-%Y-%m.log geofancy:currLoc_Klaus:.*
attr FileLog_LocationK logtype text

Loredo

Schließt event-on-change-reading "currLoc_Klaus" ein? Ohne Event kann FileLog nichts protokollieren.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

raspklaus

Ist gesetzt:

define rr_Klaus ROOMMATE Hauptstr
attr rr_Klaus alias Klaus
attr rr_Klaus 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
attr rr_Klaus event-on-change-reading currLoc_Klaus:.*
attr rr_Klaus group Bewohner
attr rr_Klaus icon people_sensor
attr rr_Klaus room Hauptstrasse
attr rr_Klaus rr_locationHome home
attr rr_Klaus rr_realname group
attr rr_Klaus sortby 0
attr rr_Klaus webCmd state:mood

Loredo

Zitat von: raspklaus am 01 Januar 2016, 18:05:37
Ist gesetzt:


attr rr_Klaus event-on-change-reading currLoc_Klaus:.*



Die Notation von event-on-change-reading ist falsch.


http://fhem.de/commandref.html#readingFnAttributes:


Zitat
The attribute takes a comma-separated list of readings.


Richtig ist also:



attr rr_Klaus event-on-change-reading currLoc_Klaus

Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

raspklaus

Probiere das jetzt mal aus, sehe das Ergebnis erst morgen, da ich heute nicht mehr weggehe.

Danke erst mal für die Hilfe

Loredo

Übrigens muss event-on-change-reading natürlich beim geofancy Device gesetzt sein und nicht beim ROOMMATE Device...
Aber ich vermute das war nur ein versehen von dir.

Man kann auch ohne sich zu bewegen testen:



setreading geofancy currLoc_Klaus Testlokation
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

#411
Ich habe gerade ein Update des GEOFANCY Moduls sowie damit zusammenhängende Updates für ROOMMATE und GUEST eingecheckt:



       
  • Das Attribut devAlias ist nun Voraussetzung dafür, dass die meisten Readings erzeugt werden. Ohne wird nur das Reading lastDevice und das neue Reading lastDeviceUUID aktualisiert. Dies stellt sicher, dass keine ungewollten Readings (massenweise) angelegt werden können und ist somit eine Verbesserung der Sicherheit des Moduls.
  • Wer ROOMMATE oder GUEST zusammen mit GEOFANCY einsetzt, hat dafür zumeist einen Haufen von Notify/watchdog/DOIF Devices, welche die ROOMMATE/GUEST Devices mit der geänderten Location updaten. Oftmals ist dabei Code doppelt oder die Behandlung in einem einzigen Notify*-Device ist unübersichtlich/umständlich. Die UUID eines Devices kann deshalb jetzt direkt als Attribut r*_geofenceUUIDs bei ROOMMATE und GUEST hinterlegt werden. Das GEOFANCY Device findet das richtige Device dann selbstständig und aktualisiert den Standort automatisch. Die UUID bekommt damit einen engeren Bezug zum ROOMMATE/GUEST Device, mit dem das mobile Endgerät interagiert, und trägt zur Übersicht bei. Zusätzliche Location-Readings, die die Werte aus dem GEOFANCY Modul widerspiegeln (zB Breitengrad/Längengrad, Adresse), sind in Vorbereitung. Auch soll ein Entprell-Mechanismus dazukommen. Die Nutzung von r*_geofenceUUIDs hat Vorrang vor Aliasen, die über das GEOFANCY Attribut devAlias definiert wurden.
Ich würde mich freuen, wenn die Änderungen getestet werden und ich hier Feedback erhalten würde, wenn es eine Konstellation bei einer bestehenden Installation gibt, die ich nicht bedacht habe.




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Masterfunk

#412
Erste Tests verlaufen ohne Fehler/Probleme.

Gruß Detlef

FunkOdyssey

Ich hab direkt mal ne Frage. Seit gestern probiere ich diese neuen Features aus. Übrigens: Super Idee.

Jetzt lese ich hier nur gerade, dass die meisten Readings nur erzeugt werden, wenn DevAlias genutzt wird. Ich habe in den Roommate die UUIDs (je 2) hinterlegt. Und in Geofancy habe ich insgesamt vier DevAliase für zwei Personen hinterlegt. Ich sehe jedoch nur zwei Readings: lastDevice und lastDeviceUUID.

Vorher waren das mehr Readings. Und eigentlich habe ich doch alles richtig gemacht, oder?

Loredo

Das ist schon richtig so, die Readings werden bei setzen der UUID in ROOMMATE nicht mehr redundant im GEOFANCY Device angezeigt (wozu auch, sie sind ja im ROOMMATE Device verfügbar). Wenn die UUID in ROOMMATE hinterlegt ist, dann wird sie im GEOFANCY Device ignoriert und kann dort auch gelöscht werden (muss/soll nicht doppelt hinterlegt werden).


Die Readings in GEOFANCY werden erstellt, wenn dort im devAlias Attribut eine UUID hinterlegt ist, die sonst nirgends zugeordnert ist. Es ist dann das bisher bekannte Verhalten. Es werden nur keine Readings mehr bei unbekannten UUIDs angelegt, wie es bisher der Fall war.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

det.

Hallo Julian,
Vielen Dank für Deine prima Entwicklung und Weiterentwicklung der Module rund um geofency. Habe es versucht in meinem Construct anzupassen. Die Änderungen erscheinen sehr sinnvoll und haben eine Menge notify und dummy überflüssig gemacht. Bei mir gab es auch keine Abstürze etc.
Ich bitte um Hilfe/Anregungen zu folgender Sache, die nach der Änderung nicht mehr wie vorher funktioniert: Zur Hochreglung der Heizung nach Verlassen der Arbeitsstellen hatte ich den Arbeitsort meiner Frau und meinen in der IOS Geofency APP work genannt und folgendes notify reagierte auf left work:

geofancy:.*left.work.* {fhem "set CUL_EG_Clima_.* controlMode auto"}

Aktuell finde ich in keinem der Module ein vergleichbares reading. Wie kann ich das anders umsetzen?
LG
det.

det.

Hallo,
ich versuche die Frage noch mal hochzuholen. Habe eben versuchsweise meine location work in wayhome umbenannt - verstehe aber das Kapitel zu ROMMATE in der commandref offenbar nicht:
ZitatImmer wenn eine Lokation mit dem Namen 'wayhome' gesetzt wird, wird das Reading 'wayhome' auf '1' gesetzt, sofern die Anwesenheit zu diesem Zeitpunkt 'absent' ist. Sofern das Attribut rr_locationWayhome gesetzt wurde, so führt das VERLASSEN einer dort aufgeführten Lokation ebenfalls dazu, dass das Reading 'wayhome' auf '1' gesetzt wird. Es gibt also 2 Möglichkeiten den Nach-Hause-Weg-Indikator zu beeinflussen (implizit und explizit).
Die Ankunft zu Hause setzt den Wert von 'wayhome' zurück auf '0'.
Wenn ich jetzt testweise über webhook wayhome verlasse (ohne das Ankommen vorher an FHEM zu senden) - bleibt wayhome auf 0, das geht nur auf 1, wenn ich wayhome betrete und bleibt dann nach verlassen auf 1. Ich möchte aber meine Heizung nicht hochregeln, wenn ich auf Arbeit ankomme, sondern wenn ich sie verlasse.
Sorry, ich steh da total auf dem Schlauch....
LG
det.

Loredo

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.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

det.

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.
Danke, das lässt hoffen! Mit der Lösung, dass Büro beim Verlassen wayhome auf 1 setzt, wäre ich sehr zufrieden. Dann könnte ich die Heizungsreglung mit einer Befehlszeile für verschiedene Arbeitsorte erschlagen. Das wird eine echte Neuerung und Erleichterung. Wünsche Dir viel Freizeit, damit Du das noch vor Ende der kalten Jahreszeit schaffst.
LG
det.

det.

Vielen Dank Loredo,
im ROOMMATE device funktioniert wayhome nach dem heutigen update wie erwartet - bei Verlassen wird wayhome zu 1, beim Betreten home wieder zu 0. Wenn das im nächsten Step auch noch im RESIDENTS Modul unter residentsTotalWayhome erscheinen würde, wäre die Begeisterung nahezu grenzenlos.
LG
det.