livetracking mit owntracks II

[Beta-User]

Danke. Dazu eine Frage: ich muss

Code Auswählen Erweitern

attr MQTT2_seppmobile autocreate 0 setzen, sonst erzeugt das Ding immer eine weitere Zeile in der readingList. Korrekt ?

Nein. Eine neue Zeile wird nur erzeugt, wenn ein neuer Topic dazukommt. Dann ist es auch sinnvoll, wenn auch ggf. nicht mit json2nameValue, aber das kannst du dann ja auch ändern.

[Beta-User]

Danke vorerst. Ich habe Deine Samples im anderen Thread gesehen und muss das mal "nachbauen". Was mir als Erstes aufgefallen ist: ich habe keinen MQTT2_Client definiert...

Du brauchst vermutlich auch keinen zu definieren, wenn das beim Server ankommt.

Es kann nur ggf. Probleme geben, wenn sich die ClientID ändert.

@statler:
ich antworte auf die spezifischen MQTT-Themen lieber hier, weil mich das "Anschlussmodul" an sich derzeit nicht interessiert (und sich dessen Autor vermutlich nur am Rande für die MQTT-Themen).
Wir können aber gerne das ganze soweit versuchen zu finalisieren, dass es ggf. ein zweites attrTemplate für owntracks gibt, was zu livetracking besser paßt...

[Otto123]

Danke vorerst. Ich habe Deine Samples im anderen Thread gesehen und muss das mal "nachbauen". Was mir als Erstes aufgefallen ist: ich habe keinen MQTT2_Client definiert...

Du brauchst auch keinen MQTT2_Client zu definieren! Du musst in Ruhe lesen, ich habe das Gefühl Du neigst zu Missverständnissen!
Ich habe einfach dokumentiert was ich gemacht habe. Die readingList Zeilen sind doch aber bei den MQTT2_DEVICEs identisch, der IO (ob Server oder Client) spielt dabei keine Rolle.

[Beta-User]

@Otto123:
Falls es richtig sein sollte, dass man für die Weiterverarbeitung in livetracking je ein Reading pro User haben sollte, in dem dann der ganze JSON steht, könnte man $TOPIC per regex analysieren und das ähnlich (aber einfacher) machen wie in tasmota_zigbee2tasmota_bridge:

Code Auswählen Erweitern

  STATTOPIC/RESULT:.* { $EVENT =~ m,(ZbStatus.), ? { $1=>$EVENT } : json2nameValue($EVENT,'',$JSONMAP) }\

Bausteine für das Analysieren des $TOPIC findet man (oh Wunder) in meinem "Lieblingsbeispiel für komplexere Fälle": OpenMQTTGateway (OpenMQTTGateway_BT_scanner, z.b.) .

[Otto123]

Moin Beta-User,

ich werde versuchen deinen Vorschlag zu verstehen - aber wohl eher "allgemein" - soweit ich das livetracking Device verstanden habe:

• ist der Name des json Readings im MQTT Device völlig egal
• gibt es eine 1 zu 1 Zuordnung MQTT Device -> Livetracking Device und dies ist "Single User"
• ergo braucht man für n TrackingDevices auch n MQTT Defines und n livetracking Defines
• braucht man z.B. für Presence Aufgaben mit owntracks nicht unbedingt ein livetracking Device
• Das MQTT2_DEVICE liefert dafür quasi out of the box alle Readings im Klartext
• man bräuchte also als Erstes (mal wieder ein bridge Device welches das autocreate der OwnTracks Devices unterstützt und für die dann ev. noch ein "hübsch" Template

Es ist ein Thema was ich schon immer mal antesten wollte, bis jetzt kann ich sagen:

• Die App ist relativ schlicht, einfach zu konfigurieren und funktioniert offenbar gut
• ich arbeite im "Signifikante Änderungen" Modus
• der kostenfreie MQTT Broker hat keine signifikante "Last", durch diesen habe ich im Netzwerk nach wie vor keinen offenen Zugang
• der Stromverbrauch liegt laut Statistik knapp unter der von WhatsApp - 0,6%
• die Erkennung "kommt nach Hause" und "geht weg" funktioniert zuverlässig. Die Reaktionszeit liegt im Bereich der BT Presence Erkennung
• mal schauen ob man sowas erkennen kann: "ich komme mit dem Auto - mach die Garage auf"
• ich habe damit auch "Status" (Ladezustand, Verbindung Mobil/Wlan) vom Smartphone als Log

Gruß Otto

[Beta-User]

Hi Otto, dann noch ein paar Anmerkungen:

Wenn der Reading-Name egal ist, könnte man auch eine 1:n-Zuordnung machen zwischen 1 MQTT2_DEVICE und n livetracking-Devices. Dafür war das mit den beiden Code-Hinweisen gedacht.

Wenn man für PRESENCE-Zwecke Readings braucht, die "User"-bezogen sind, kann man das auf zwei Wegen erreichen: entweder tatsächlich über eine bridgeRegexp oder - und ich dachte erst, das sei zu bevorzugen, da es sowieso "nur" eine Art "Zwischendevice" ist (also die Readingnamen nicht "hübsch" sein müssen) - man nutzt $1 dann auch noch als "Prefix" für json2NameValue(). Vermutlich wäre es sogar möglich, "alles in eine Zeile" zu schreiben und dann den "vollen $EVENT" einfach noch in den von json2nameValue() gelieferten Hash zu schubsen...

Jetzt habe ich mir das aktuelle template nochmal intensiver angeschaut, und vermutlich hast du recht damit, dass es für die User übersichtlicher wird, wenn man eine bridgeRegexp nutzt und eine (n+bridge):n-Zuordnung macht. Was das aktuelle Template angeht, würde ich dann dazu neigen, hier optional abzufragen, ob man das Device für livetracking vorbereiten will (=zusätzlich den JSON im Ausgangszustand belassen und den dann auch überall gleich benennen) oder nicht (=bisheriger Stand des attrTemplate).
Falls du Beispiele für optionale Konfiguration via attrTemplate suchst (mit RADIO_.*): zwave.template.

Ansonsten weiß ich noch nicht so recht, ob ich auch bzgl. PRESENCE in diese Variante einsteigen will, aber die Rückmeldung, dass das ein guter Weg ist, ist auf alle Fälle interessant! (Wäre ggf. eine Erwähnung im Wiki (Anwesenheitserkennung + "Praxisbeispiele") wert, wenn "wir" fertig sind...

[Otto123]

1 MQTT2_DEVICE und n livetracking-Devices.

Ich wüsste nicht wie. Das livetracking Device hat als Bezugspunkt nur das MQTT Device per Attribute (owntracksDevice - OwnTracks MQTT device to look for notifies from) und wenn ich das richtig beobachte schnappt sich das einen json String aus den Events und schaut ob der passt. Ich habe null in den Code geschaut, nur probiert!

Das nette Feature, welches livetracking neben der Aufbereitung der json Inhalte mMn bietet, ist die Auflösung von Koordinaten in echte Adressen!

ob man das Device für livetracking vorbereiten will (=zusätzlich den JSON im Ausgangszustand belassen und den dann auch überall gleich benennen)

ich finde, das wäre cool!

[Beta-User]

Danke für die Erläuterungen, habe jetzt auch mal in die .pm geschaut; sieht so aus, als dürfte das nur ein readingsSingleUpdate sein, von daher muß das mit dem RAW-JSON auch unbedingt in eine eigene Zeile...

ich finde, das wäre cool!

Ok, dann gehen wir weiter in diese Richtung...

Frage noch: ist der Dienst "geschwätzig" oder sendet er nur Differenzmeldungen. In ersterem Fall würde ich vorschlagen, dass wir (auf jeden der diesbezüglich relevanten Topics) ein pauschales eocr drüberlaufen lassen (ähnlich wie in 6channel_ethernet_board_6input_split):

Code Auswählen Erweitern

attr DEVICE readingList Advantech/DEVNAME/data:.* { $EVENT =~ s/true/"on"/g;; $EVENT =~ s/false/"off"/g;; my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { ReadingsVal($NAME,$_,"unknown") ne $rets->{$_} } keys %{$rets};; return \%cleaned }\
(ohne die replacements in $_EVENT)

Brauchst du für den Moment sonst noch support, oder soll ich dich jetzt erst mal in Ruhe machen lassen?

[Otto123]

ich hoffe statler verzeiht uns, dass wir hier ein bisschen forschen und dokumentieren
bisher sehe ich drei unterschiedliche json Events

Code Auswählen Erweitern

2020-11-11_08:33:22 MQTT2_OwnTracks_mi6 json: {"_type":"lwt","tst":1605079880}
2020-11-11_08:33:23 MQTT2_OwnTracks_mi6 event: {"_type":"transition","acc":42.541,"desc":"zuHause","event":"enter","lat":5x.xxxxxx,"lon":1x.xxxxxx,"t":"l","tid":"hk","tst":1605079996,"wtst":1604958453}
2020-11-11_08:33:24 MQTT2_OwnTracks_mi6 json: {"_type":"location","acc":43,"alt":163,"batt":61,"conn":"w","inregions":["zuHause"],"lat":5x.xxxxxx,"lon":1x.xxxxxx,"tid":"hk","tst":1605079996,"vac":2,"vel":0}
Die kommen für sich immer komplett, aber eigentlich selten. location kommt relativ regelmäßig, lwt kommt offenbar wenn nichts los ist
eocr würde ich machen

Ich schau jetzt mal wie weit ich kommen

[rallye]

ich hoffe statler verzeiht uns, dass wir hier ein bisschen forschen und dokumentieren

Statler verzeiht  !
Geht ja auch leicht, denn jetzt funktionierts bei mir  . Ich möchte nochmals anmerken, dass ich die livetracking-Version OHNE XML::Simple in meiner Bibliothek habe. Danke an Euch beide !

Ich teste gerne mit mit euch wenn ihr es wollt

LG aus Wien

[rallye]

Ich möchte nun noch folgende Erfahrung teilen:
nachdem ich die Parameter & Attribute nach Otto's Anregungen gesetzt habe hat sich in erster Lesung nichts getan - deshalb auch meine ewigen Nachfragen und Missverständnisse. Erst als ich das Device gelöscht und neu angelegt habe hat sich das richtige (gewünschte) Ergebnis eingestellt. Danach habe ich (da ja mehrere Personen im Haushalt leben) ein weiteres Device gelöscht und nicht wieder angelegt, sondern mit rereadcfg wieder hergestellt. Siehe da: auch das hat (natürlich mit den richtigen Parametern) funktioniert. Als Bullet-Proof habe ich das noch mit einem dritten Device gemacht - und war erfolgreich.
Verstehen tue ich es nicht (Device löschen und mit rereadcfg wieder herstellen). Aber es hat jedenfalls funktioniert.

Vielen Dank für Eure Geduld !

Grüße aus Wien

[Beta-User]

So ganz nachvollziehen kann ich nicht, was du schreibst, aber ich habe eine Idee: "copy" statt der Weg über RAW-def beim Anlegen der weiteren Devices?

Rawdef hat einen großen Vorteil gg. copy: Die internen Datenstrukturen werden bei dem neuen Device auch neu aufgebaut .

Ich hatte ein paar Mal "komische" Effekte (bei MQTT2_DEVICE?, aber afaik ist das nicht beschränkt darauf) mit copy, die dann nur durch einen Neustart zu beseitigen waren. Von daher klare Empfehlung: Umlernen!

rereadcfg sollte man nicht nutzen, das kann iVm. manchen Modulen sehr komische Effekte ergeben! Wenn, dann eben gleich neu starten...

[Otto123]

Den Effekt wie statler ihn beschreibt hatte ich gestern auch. Nachdem mein MQTT2 Device das 5te json Komplettreading hatte (durch meine Versuche) ging es nämlich auch gar nicht mehr - das livetracking Device. Ich behaupte mal (bin nur zu 90% sicher) ich hatte dann mit einem disable -> enable Erfolg.

@statler darf ich fragen, was machst Du mit dem livetracking Device dann? Welches Feature nutzt Du dort?

[rallye]

@statler darf ich fragen, was machst Du mit dem livetracking Device dann? Welches Feature nutzt Du dort?

Ich verwende die Readings von livetracking um die Anwesenheiten der Familienmitgkieder (und in weiterer Folge die Heizung bzw. das Licht) zu steuern. Zu diesem Zweck habe ich folgendes DOIF am Laufen

Code Auswählen Erweitern

defmod Sepp_ComingHome_LeavingHome DOIF (["$SELF:switch: enter"] or ["MQTT2_seppmobile:enter"])\
      ({\
        my @pos=split(/,/,ReadingsVal('TrackSepp','location',''));;\
        my $place=ReadingsVal('TrackSepp','place','');;\
        fhem("set rr_Sepp location [TrackSepp:place]");;\
        fhem("setreading rr_Sepp locationLat $pos[0]");;\
        fhem("setreading rr_Sepp locationLong $pos[1]");;\
        Log(3, "Standort-Logik bei enter - Sepp betritt Standort: [TrackSepp:place].");;       \
      })\
DOELSEIF (["$SELF:switch: leave"] or ["MQTT2_seppmobile:leave"])\
      ({\
        my $loc=ReadingsVal('rr_Sepp','location','');;\
        my @pos=split(/,/,ReadingsVal('TrackSepp','location',''));;\
        fhem("set rr_Sepp location underway");;\
        fhem("setreading rr_Sepp lastLocationLat $pos[0]");;\
        fhem("setreading rr_Sepp lastLocationLong $pos[1]");;\
        Log(3, "Standort-Logik bei leave - Sepp verlässt Standort: [TrackSepp:place].");;\
      })
attr Sepp_ComingHome_LeavingHome room Server
attr Sepp_ComingHome_LeavingHome wait 2:2

setstate Sepp_ComingHome_LeavingHome cmd_1
setstate Sepp_ComingHome_LeavingHome 2020-11-17 00:51:55 Device MQTT2_seppmobile
setstate Sepp_ComingHome_LeavingHome 2020-11-17 00:51:57 cmd 1
setstate Sepp_ComingHome_LeavingHome 2020-11-17 00:51:57 cmd_event MQTT2_seppmobile
setstate Sepp_ComingHome_LeavingHome 2020-11-17 00:51:57 cmd_nr 1
setstate Sepp_ComingHome_LeavingHome 2020-11-16 13:57:53 mode enabled
setstate Sepp_ComingHome_LeavingHome 2020-11-17 00:51:57 state cmd_1
setstate Sepp_ComingHome_LeavingHome 2020-11-17 00:51:57 wait_timer no timer

Wobei mein aktuelles livetracking-Device so aussieht:

Code Auswählen Erweitern

defmod TrackSepp livetracking
attr TrackSepp alias GeoInfo Sepp
attr TrackSepp batteryWarning 20
attr TrackSepp comment {(split(' ',ReadingsNum("TrackSepp","distance",0)))[0]}
attr TrackSepp filterAccuracy 100
attr TrackSepp group Anwesenheitserkennung
attr TrackSepp home 48.2106659,16.0860513
attr TrackSepp icon rc_dot@blue
attr TrackSepp owntracksDevice MQTT2_seppmobile
attr TrackSepp room Server
attr TrackSepp roundAltitude 5
attr TrackSepp roundDistance 0.1
attr TrackSepp sortby 04
attr TrackSepp stateFormat distance
attr TrackSepp verbose 2
attr TrackSepp zonename_0 home
attr TrackSepp zonename_1 AKH

setstate TrackSepp 0
setstate TrackSepp 2020-11-17 12:40:29 .lastOwnTracks 1605613227
setstate TrackSepp 2020-11-17 12:40:27 accuracy 13
setstate TrackSepp 2020-11-17 12:40:27 altitude 410
setstate TrackSepp 2020-11-17 12:40:27 batteryPercent 38
setstate TrackSepp 2020-11-17 12:40:27 batteryState ok
setstate TrackSepp 2020-11-17 12:40:27 connection wifi
setstate TrackSepp 2020-11-17 12:40:27 distance 0
setstate TrackSepp 2020-11-17 12:40:27 id SL
setstate TrackSepp 2020-11-17 12:40:27 latitude 48.21066
setstate TrackSepp 2020-11-17 12:40:27 location 48.21066,16.08605
setstate TrackSepp 2020-11-17 12:40:27 longitude 16.08605
setstate TrackSepp 2020-10-31 00:38:22 place home
setstate TrackSepp 2020-11-17 12:40:27 trigger ping
setstate TrackSepp 2020-11-17 12:40:27 velocity 0
setstate TrackSepp 2020-11-17 12:40:27 zone_0 active
setstate TrackSepp 2020-11-17 12:40:27 zone_1 inactive

Das o.a. DOIF hat in der Vergengenheit auch immer zuverlässig funktioniert, doch gestern (wir haben in Österreich gerade Lockdown und Ausgangssperre, wodurch ich mir beim Testen zZt sehr schwer tue, aber als regelmäßiger Besucher im Spital doch mehrmals pro Woche legal raus "darf") hatte ich folgenden "Effekt" (ich möchte explizit darauf hinweisen, dass ich das livetracking-Modul von Beta-User ohne XML::Simple im Einsatz habe);
Beim Verlassen von "home" hat mein  DOIF mich als absent gesetzt (siehe Log):

Code Auswählen Erweitern

2020.11.16 18:39:15 2: ROOMMATE set rr_Sepp location underway
2020.11.16 18:39:15 3: Standort-Logik bei leave - Sepp verlässt Standort: home.

Als ich dann in der zone_1 angekommen bin (enter) hat livetracking alles vom Device richtig übernommen - ausgenommen die Location. Die ist anstall AKH auf home geblieben. Dadurch hat mich die DOIF-Logik wieder auf "home" und somit daheim anwesend gesetzt.
Log:

Code Auswählen Erweitern


2020.11.16 19:18:20 2: ROOMMATE set rr_Sepp location home
2020.11.16 19:18:20 3: Standort-Logik bei enter - Sepp betritt Standort: home.
Die zugehörigen RawDefinitions zum Zeitpunkt meiner Anwesenheit in Zone AKH sehen so aus:

Code Auswählen Erweitern

defmod MQTT2_seppmobile MQTT2_DEVICE seppmobile
attr MQTT2_seppmobile IODev MQTT_Owntracks
attr MQTT2_seppmobile autocreate 1
attr MQTT2_seppmobile event-on-change-reading .*
attr MQTT2_seppmobile icon it_smartphone@blue
attr MQTT2_seppmobile readingList seppmobile:owntracks/otSepp/mobile:.* seppmobile\
seppmobile:owntracks/otSepp/mobile/event:.* { json2nameValue($EVENT) }
attr MQTT2_seppmobile room MQTT
attr MQTT2_seppmobile sortby 1

setstate MQTT2_seppmobile 2020-11-16 19:18:31 _type transition
setstate MQTT2_seppmobile 2020-11-16 19:18:31 acc 50.095
setstate MQTT2_seppmobile 2020-11-16 19:18:31 desc AKH
setstate MQTT2_seppmobile 2020-11-16 19:18:31 event enter
setstate MQTT2_seppmobile 2020-11-16 19:18:31 lat 48.2189714
setstate MQTT2_seppmobile 2020-11-16 19:18:31 lon 16.3472197
setstate MQTT2_seppmobile 2020-11-16 20:57:31 seppmobile {"_type":"location","acc":50,"alt":243,"batt":86,"conn":"w","inregions":["AKH"],"lat":48.2189714,"lon":16.3472197,"t":"p","tid":"SL","tst":1605556647,"vac":17,"vel":0}
setstate MQTT2_seppmobile 2020-11-12 12:40:41 subscriptions owntracks/+/+ owntracks/+/+/event owntracks/+/+/info owntracks/+/+/waypoints owntracks/otSepp/mobile/cmd
setstate MQTT2_seppmobile 2020-11-16 19:18:31 t l
setstate MQTT2_seppmobile 2020-11-16 19:18:31 tid SL
setstate MQTT2_seppmobile 2020-11-16 19:18:31 tst 1605550468
setstate MQTT2_seppmobile 2020-11-16 19:18:31 wtst 1542100178668
bzw, das livetracking;

Code Auswählen Erweitern

defmod TrackSepp livetracking
attr TrackSepp alias GeoInfo Sepp
attr TrackSepp batteryWarning 20
attr TrackSepp comment {(split(' ',ReadingsNum("TrackSepp","distance",0)))[0]}
attr TrackSepp filterAccuracy 100
attr TrackSepp group Anwesenheitserkennung
attr TrackSepp home 48.2106659,16.0860513
attr TrackSepp icon rc_dot@blue
attr TrackSepp owntracksDevice MQTT2_seppmobile
attr TrackSepp room Server
attr TrackSepp roundAltitude 5
attr TrackSepp roundDistance 0.1
attr TrackSepp sortby 04
attr TrackSepp stateFormat distance
attr TrackSepp verbose 2
attr TrackSepp zonename_0 home
attr TrackSepp zonename_1 AKH

setstate TrackSepp 19.4
setstate TrackSepp 2020-11-16 20:57:31 .lastOwnTracks 1605556647
setstate TrackSepp 2020-11-16 20:57:27 accuracy 50
setstate TrackSepp 2020-11-16 20:57:27 altitude 245
setstate TrackSepp 2020-11-16 20:57:27 batteryPercent 86
setstate TrackSepp 2020-11-16 20:57:27 batteryState ok
setstate TrackSepp 2020-11-16 20:57:27 connection wifi
setstate TrackSepp 2020-11-16 20:57:27 distance 19.4
setstate TrackSepp 2020-11-16 20:57:27 id SL
setstate TrackSepp 2020-11-16 20:57:27 latitude 48.21897
setstate TrackSepp 2020-11-16 20:57:27 location 48.21897,16.34722
setstate TrackSepp 2020-11-16 20:57:27 longitude 16.34722
setstate TrackSepp 2020-10-31 00:38:22 place home
setstate TrackSepp 2020-11-16 20:57:27 trigger ping
setstate TrackSepp 2020-11-16 20:57:27 velocity 0
setstate TrackSepp 2020-11-16 20:57:27 zone_0 inactive
setstate TrackSepp 2020-11-16 20:57:27 zone_1 active
Und genau hier, im livetracking ist der Fehler, dass alle Readings richtig sind, ausgenommen "place", welches auf "home" bleibt, anstall auf "AKH" zu gehen. Dadurch denkt mein DOIF, dass ich wieder daheim bin (auch wenn die Koordinaten eben auf die Zune AKH zeigen).

Ich werde heute das livetracking mit XML::Simple aktivieren (und hoffe es hinzubekommen ohne diese Fehlermeldung) und morgen Abend, wenn ich wieder raus muß testen, ob im anderen Modul der Wert für place richtig gesetzt wird.

rereadcfg sollte man nicht nutzen, das kann iVm. manchen Modulen sehr komische Effekte ergeben! Wenn, dann eben gleich neu starten...

Das habe ich gemacht, hat aber leider den gewünschten Effekt (Neuaufbau der Strukturen) nicht gebracht

PS:
Zwei Anmerkungen: so ich etwas wirr schreibe oder schwere Typos drinnen habe: ich hatte Freitag eine Augen-OP und sehe momentan ziemlich verschwommen - bitte um Nachsicht.
Punkt 2: ich habe die echten Koordinaten drinnen gelassen. Wenn also jemand auf die Idee kommt mich zu besuchen: bitte unbedingt eine Flasche mit qualitativ hochwertigem Rotwein mitbringen
Danke

[Beta-User]

Hmm, hatte neulich in den Code von owntracks geschaut und gesehen, dass da jede Reading-Aktualisierung vom "belauschten" Device dazu führt, dass die Analyse losläuft. Daher sollte man entweder den Code so ändern, dass da auch ein ganz bestimmtes Reading benannt werden kann (in dem dann der JSON steht), oder man braucht ein (weiteres) Device, das NUR den JSON enthält (muß triggernd aktualisiert werden, readingsProxy geht dafür also nicht).
Mein Verdacht ist, dass die dieversen "nicht-JSON"-Reading-Werte den owntracks-Code irgendwie verwirren. (Habe das aber nicht vertieft, muß nicht richtig sein).