Modul: 98_livetracking - Geokoordinaten von OwnTracks / Life360 / Swarm (4Sq)

Jamo · 05 Januar 2019, 00:42:24

Hallo Markus,
das Verhalten, was tamash beschrieben hat, ist mir auch schon aufgefallen.

ZitatWas in erster Linie mal fehlt, ist der Leave Event!

Das event kann man so generieren:

define myMQTT_DEVICE MQTT_DEVICE
attr   myMQTT_DEVICE subscribeReading_event myMQTT_DEVICE/fhem/iphone/event

Damit erhält man ein reading 'event' , das wie folgt ausschaut

Code Auswählen

event     {"t":"b","tst":1234567890,"acc":65,"_type":"transition","event":"enter","lon":xx.xxxxxxxx,"lat":xx.xxxxxxxx,"wtst":1234567890,"tid":"NAME","desc":"MY_ZONE"}

Code Auswählen

define n_myMQTT_DEVICE notify (myMQTT_DEVICE:event:.*) { \
  my $evt     = $EVENT;; \
  my $data    = substr($evt,index($evt, ": {")+2);; \
  my $dataset = JSON->new->utf8(0)->decode($data);; \
  my $place   = $dataset->{desc};; \
  my $event   = $dataset->{event};; \
  my $lat         = $dataset->{lat};
  my $lon         = $dataset->{lon};
  setReadingsVal($defs{$NAME}, "Transition", $event, FmtDateTime($dataset->{tst}));; \
  setReadingsVal($defs{$NAME}, "Place", $place, FmtDateTime($dataset->{tst}));; \
}

damit erhält man dann 2 zusätzliche Readings, Transition für das event und Place für die Zone:

Code Auswählen

Transition -> enter
Place -> MY_ZONE

Markus M. · 05 Januar 2019, 01:11:16

Zitat von: inoma am 05 Januar 2019, 00:42:24Das event kann man so generieren:
Code Auswählen Erweitern
define myMQTT_DEVICE MQTT_DEVICE attr myMQTT_DEVICE subscribeReading_event myMQTT_DEVICE/fhem/iphone/event

Also Subscribe vergessen.
Gibt ja auch noch andere (siehe OwnTracks Booklet):

beacon, cmd, dump, event, msg, step, waypoints
Die sollten im OwnTracks Device alle komplett subscribed werden.

Wozu eigentlich dein kompliziertes Notify mit JSON Decoding?
Sobald das event Reading von MQTT im OwnTracks Device generiert wird, macht das Modul das alles automatisch.

tamash · 05 Januar 2019, 14:05:31

Hallo!

Oh, tut mir leid euch damit unnötig genervt zu haben.
Wer lesen kann...

Vielen Dank für den Hinweis.

LG
Tom

triagony · 05 Januar 2019, 18:55:16

Zitat von: carlos am 14 November 2018, 00:48:18
War das ein Kampf, nach langem probieren habe ich es geschaft.
Das Problem war die user/password authentifizierung in FHEM.
Ich muste eine WEB instanz ohne basicauth definieren, dann geht es mit folgendem forwarding in traccar(leider nur lokal, also FHEM und TRACCAR auf dem gleichen Rechner):

Code Auswählen Erweitern
<entry key='forward.url'>http://127.0.0.1:8084/fhem/osmand?id={name}&lat={latitude}&lon={longitude}&timestamp={fixTime}&altitude={altitude}&speed={speed}&accuracy={accuracy}</entry> <entry key='forward.json'>false</entry>

Hi, kannst du mal einen Auszug aus deiner traccar.xml mit den relevanten Parametern posten? Ich bekomme es irgendwie nicht hin, dass fhem/osmand etwas von traccar empfängt - jedenfalls sehe ich in den logs nichts. (ich hatte testweise mal event.forward.url auf fhem/osmand gesetzt; da kam dann etwas an - zwar nur Kraut und Rüben, aber immerhin). Meine Config sieht atm wie folgt aus:

Code Auswählen

    <entry key='osmand.port'>5999</entry>
    <entry key='logger.enable'>true</entry>
    <entry key='forward.enable'>true</entry>
    <entry key='event.forward.enable'>true</entry>
    <entry key='event.forward.header'> Authorization: Basic SuperGeheim</entry>
    <!--    <entry key='event.forward.url'>http://127.0.0.1:8083/fhem/osmand</entry>-->
    <entry key='forward.url'>http://127.0.0.1:8083/fhem/osmand?id={name}&amp;lat={latitude}&amp;lon={longitude}&amp;timestamp={fixTime}&amp;altitude={altitude}&amp;speed={speed}&amp;accuracy={accuracy}</entry>
    <entry key='forward.json'>false</entry>

Danke!

triagony · 06 Januar 2019, 13:03:23

Hi. Ich habe nochmal ein bisschen weiter mit traccar rumgespielt.

1. Das Forwarding von traccar auf 127.0.0.1:PORT/fhem/osmand funktioniert bei mir (auch) nur, wenn die Fhem-Webinstanz nicht per basic auth abgesichert ist. Es kommen im livetracker-Modul die readings longitude, latitude, altitude und velocity an. Der Timestamp des jeweiligen Readings hat aber ein komisches Format und entspricht nicht dem tatsächlichen Zeitpunkt des Readings.

2. Nun habe ich mir mal "from-traccar" angesehen https://github.com/jpmens/from-traccar und auch das Programm dazu bewegen können, mit meinem lokal installiertem mosquitto zu kommunizieren. Auch in fhem kann ich mir den "string", der reinkommt, schon anzeigen lassen. Der Inhalt der Subscribtion sieht wie folgt aus:

Code Auswählen

{"position":{"id":566,"attributes":{"batteryLevel":66,"distance":25.79,"totalDistance":20665.79,"motion":false},"deviceId":1,"type":null,"protocol":"osmand","serverTime":"2019-01-06T11:39:41.279+0000","deviceTime":"2019-01-06T11:39:41.000+0000","fixTime":"2019-01-06T11:39:41.000+0000","outdated":false,"valid":true,"latitude":53.xxxxx,"longitude":8.xxxxx,"altitude":0,"speed":0,"course":0,"address":null,"accuracy":24.04000091552734,"network":null},"device":{"id":1,"attributes":{},"groupId":0,"name":"SomeName","uniqueId":"SomeID,"status":"online","lastUpdate":"2019-01-06T11:39:41.279+0000","positionId":565,"geofenceIds":[],"phone":"","model":"","contact":"","category":null,"disabled":false}}

Nun habe ich als "owntracksDevice" mein from-traccar-mqtt-device definiert. Leider erhalte ich dann hier aber keinerlei Readings. Mir scheint, dass das, was from-traccar an den Mqtt-Broker sendet, nicht "kompatibel" mit dem livetracking-Modul ist (anderes Format?). Kann man das irgendwie "kompatibel" machen? Oder ist das zu viel Aufwand?

Vielen Dank schonmal und

BG
triagony

kadettilac89 · 13 Januar 2019, 13:54:12

Hi,

ich habe OwnTracks mit HTTP-Host mal konfiguriert. Es läuft bei mir aber nicht so wie gewollt. Vielleicht liegt es auch an meiner Config.

Ich hab im Modul livetracking verbose 5 gesetzt. Im Log sind dann auch Requests zu sehen. In der App sehe ich aber laufend timeout-Meldungen.

In Fhem habe ich keine event-on-**-Attribut gesetzt. Ich würde erwarten, dass bei jedem eingehenden Paket auch neue Timestamps zu sehen sind. Leider nicht so. Hier ist mir aufgefallen, dass die Readings erneuert werden (rote Schrift). Beim erneuten Öffnen, oder Seitenrefresh sind wieder alte Timestamps zu sehen. Fhem Log hat Einträge um 13:40, die Readings sind aber über eine Stunde alt.

In den Logs habe ich die Geodaten etwas geändert, man weiß nie was damit gemacht wird

Setup in Fhem:

Code Auswählen


defmod livetrackingdata livetracking
attr livetrackingdata DbLogExclude .*
attr livetrackingdata addressLanguage de
attr livetrackingdata addressReading 1
attr livetrackingdata group livetracking
attr livetrackingdata home 99.665933,99.072536
attr livetrackingdata osmandServer 1
attr livetrackingdata room Status
attr livetrackingdata roundDistance 1
attr livetrackingdata stateFormat distance
attr livetrackingdata verbose 5
attr livetrackingdata zonename_0 home
attr livetrackingdata zonename_1 xxx
attr livetrackingdata zonename_2 work

setstate livetrackingdata 0
setstate livetrackingdata 2019-01-13 13:40:06 .lastOwnTracks 2547379583
setstate livetrackingdata 2019-01-13 12:39:43 accuracy 15
setstate livetrackingdata 2019-01-13 12:39:43 batteryPercent 68
setstate livetrackingdata 2019-01-13 12:39:43 batteryState ok
setstate livetrackingdata 2019-01-13 12:39:43 connection wifi
setstate livetrackingdata 2019-01-13 12:39:43 distance 0
setstate livetrackingdata 2019-01-13 12:39:43 id te
setstate livetrackingdata 2019-01-13 12:39:43 latitude 99.6659182
setstate livetrackingdata 2019-01-13 12:39:43 location 99.6659182,99.072553
setstate livetrackingdata 2019-01-13 12:39:43 longitude 99.072553
setstate livetrackingdata 2019-01-13 12:39:43 trigger automatic
setstate livetrackingdata 2019-01-13 12:39:43 velocity 0
setstate livetrackingdata 2019-01-13 12:39:43 zone_0 active
setstate livetrackingdata 2019-01-13 12:39:43 zone_1 inactive
setstate livetrackingdata 2019-01-13 12:39:43 zone_2 inactive

Log aus Fhem

Code Auswählen


/osmand/
2019.01.13 13:40:56.466 5: OsmAnd webcall request:

2019.01.13 13:40:06.697 4: livetrackingdata OwnTracks region active: $VAR1 = 'home';

2019.01.13 13:40:06.696 4: livetrackingdata OwnTracks region inactive: $VAR1 = 'xxx';

2019.01.13 13:40:06.696 4: livetrackingdata OwnTracks region inactive: $VAR1 = 'work';
2019.01.13 13:40:06.553 4: livetrackingdata OwnTracks: 2019-01-13 12:39:43  {"_type":"location","acc":15,"alt":0,"batt":68,"conn":"w","inregions":["home"],"lat":99.6659182,"lon":99.072553,"tid":"te","tst":1547379583,"vac":0,"vel":0}
{"_type":"location","acc":15,"alt":0,"batt":68,"conn":"w","inregions":["home"],"lat":99.6659182,"lon":99.072553,"tid":"te","tst":1547379583,"vac":0,"vel":0}
2019.01.13 13:40:06.552 4: OwnTracks HTTP request:
/osmand
2019.01.13 13:12:52.179 5: OsmAnd webcall request:

2019.01.13 13:09:26.065 4: livetrackingdata OwnTracks region active: $VAR1 = 'home';

2019.01.13 13:09:26.065 4: livetrackingdata OwnTracks region inactive: $VAR1 = 'xxx';

2019.01.13 13:09:26.064 4: livetrackingdata OwnTracks region inactive: $VAR1 = 'work';
2019.01.13 13:09:26.061 4: livetrackingdata OwnTracks: 2019-01-13 12:39:43  {"_type":"location","acc":15,"alt":0,"batt":68,"conn":"w","inregions":["home"],"lat":99.6659182,"lon":99.072553,"tid":"te","tst":1547379583,"vac":0,"vel":0}
{"_type":"location","acc":15,"alt":0,"batt":68,"conn":"w","inregions":["home"],"lat":99.6659182,"lon":99.072553,"tid":"te","tst":1547379583,"vac":0,"vel":0}
2019.01.13 13:09:26.060 4: OwnTracks HTTP request:

2019.01.13 12:39:49.431 4: livetrackingdata OwnTracks region active: $VAR1 = 'home';

2019.01.13 12:39:49.430 4: livetrackingdata OwnTracks region inactive: $VAR1 = 'xxx';

2019.01.13 12:39:49.430 4: livetrackingdata OwnTracks region inactive: $VAR1 = 'work';
2019.01.13 12:39:49.286 4: livetrackingdata OwnTracks: 2019-01-13 12:39:43  {"_type":"location","acc":15,"alt":0,"batt":68,"conn":"w","inregions":["home"],"lat":99.6659182,"lon":99.072553,"tid":"te","tst":1547379583,"vac":0,"vel":0}
{"_type":"location","acc":15,"alt":0,"batt":68,"conn":"w","inregions":["home"],"lat":99.6659182,"lon":99.072553,"tid":"te","tst":1547379583,"vac":0,"vel":0}
2019.01.13 12:39:49.286 4: OwnTracks HTTP request:

2019.01.13 12:16:34.707 4: livetrackingdata OwnTracks region active: $VAR1 = 'home';

2019.01.13 12:16:34.707 4: livetrackingdata OwnTracks region inactive: $VAR1 = 'xxx';

2019.01.13 12:16:34.706 4: livetrackingdata OwnTracks region inactive: $VAR1 = 'work';
2019.01.13 12:16:34.705 4: livetrackingdata OwnTracks: 2019-01-13 08:16:30  {"_type":"location","acc":17,"alt":0,"batt":86,"conn":"w","inregions":["home"],"lat":99.6659162,"lon":99.0725757,"t":"p","tid":"te","tst":1547363790,"vac":0,"vel":0}
{"_type":"location","acc":17,"alt":0,"batt":86,"conn":"w","inregions":["home"],"lat":99.6659162,"lon":99.0725757,"t":"p","tid":"te","tst":1547363790,"vac":0,"vel":0}
2019.01.13 12:16:34.704 4: OwnTracks HTTP request:

Ich habe einen nginx reverse Proxy. jenkins.access.log zeigt 504 (Gateway timeout) und 499 (Gateway closed). Reagiert der osmand-Server nicht schnell genug?

Code Auswählen


178.27.81.123 - fhem [13/Jan/2019:09:47:34 +0100] "POST /webcmd/osmand HTTP/1.1" 504 176 "-" "Owntracks/21201"
178.27.81.123 - fhem [13/Jan/2019:10:17:37 +0100] "POST /webcmd/osmand HTTP/1.1" 504 176 "-" "Owntracks/21201"
178.27.81.123 - fhem [13/Jan/2019:10:49:45 +0100] "POST /webcmd/osmand HTTP/1.1" 499 0 "-" "Owntracks/21201"
178.27.81.123 - fhem [13/Jan/2019:11:17:33 +0100] "POST /webcmd/osmand HTTP/1.1" 499 0 "-" "Owntracks/21201"
178.27.81.123 - fhem [13/Jan/2019:11:47:14 +0100] "POST /webcmd/osmand HTTP/1.1" 499 0 "-" "Owntracks/21201"
178.27.81.123 - fhem [13/Jan/2019:12:17:34 +0100] "POST /webcmd/osmand HTTP/1.1" 504 176 "-" "Owntracks/21201"

aber auch solche Einträge, die besser aussehen (9999 ... Platzhalter für meine IP)

Code Auswählen


999.99.81.123 - - [13/Jan/2019:13:12:52 +0100] "GET /favicon.ico HTTP/1.1" 444 0 "https://myfhem.dns.de:2560/webcmd/osmand" "Mozilla/5.0 (Linux; Android 9; SAMSUNG SM-G960F Build/PPR1.180610.011) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/9.0 Chrome/67.0.3396.87 Mobile Safari/537.36"

Config in OwnTrack Android app

Code Auswählen


{"_type":"configuration","waypoints":[

{"_type":"waypoint","desc":"home","lat":99.66592749999998,"lon":99.072582031250036,"rad":500,"tst":1547360977},
{"_type":"waypoint","desc":"xxx","lat":99.0988002,"lon":99.5406047,"rad":500,"tst":1547361025},
{"_type":"waypoint","desc":"work","lat":99.0425111,"lon":99.509850099999998,"rad":500,"tst":1547361059}],
"_build":21201,
"auth":true,
"autostartOnBoot":true,
"cleanSession":false,
"cmd":true,"deviceId":
"starlte","fusedRegionDetection":true,
"ignoreInaccurateLocations":0,
"ignoreStaleLocations":0,
"locatorDisplacement":500,
"locatorInterval":900,
"mode":3,
"notificationHigherPriority":false,
"opencageApiKey":"xxxxxxxxxxxxxxxxx",
"password":"xxxxxxxxxxxxxxxxx",
"ping":30,
"pubExtendedData":true,
"remoteConfiguration":true,
"url":"https:/<url:port>/webcmd/osmand/",
"username":"fhem"}

Wenn ich die Url im Browser aufrufe erhalte ich "timestamp missing". Reverse Proxy läuft ... sonst wäre die Seite nicht erreichbar.

Irgendwann kommen aber auch Daten durch ... ich beobachte es mal weiter. Energiesparen ist im Handy deaktiviert, es liegt nicht am Doze von Android.

Ideen, andere Konfiguration?

kadettilac89 · 14 Januar 2019, 23:21:54

Ich habe noch etwas getestet und einen Owntrack Server aufgesetzt. Selber reverse Proxy --> App funktioniert. Im Reverse Proxy nur den Link vom internen Owntrack Server auf interne Fhem-Installation umgeleitet --> Timeout. Im Log sind aber die eingehenden Calls zu sehen.

Weiterer TEst auf https://gurujsonrpc.appspot.com/ meine Url und die gesendeten Daten lt. FHEM Log eingetragen --> in Fhem wird genau das selbe geloggt wie auch durch Owntrack App. Im Browser wird nach ein paar Sekunden eine rote Meldung "Error sending the request." angezeigt.

Meine Vermutung ... kann es sein, dass der Datastream vom Webservice Call kein Returncode erhält (200, OK) und deshalb wartet und irgendwann einen Timeout gibt?

Markus M. · 15 Januar 2019, 23:19:47

Zitat von: kadettilac89 am 15 Januar 2019, 23:02:22Wenn ich den Code richtig verstehe, ist Owntrack HTTP-Server überhaupt nicht implementiert. Oder für IOS und Android hat ein anderes Format.

Falsch verstanden, ich hab's dir aber auch nicht einfach gemacht

ZitatCodeänderung
Zeile 1551

my ($tst) = $request =~ /tamp=(.*?)(&|$)/;
my ($hdop) = $request =~ /hdop=(.*?)(&|$)/ || 0;
...

Das war der Code für Traccar HTTP, den du somit entfernt hast.
Nicht unbedingt gut für diejenigen die das nutzen.

ZitatEine weitere Änderung ... Zeile 1540
Log3 $name, 4, "OwnTracks HTTP request:\n".$request;
livetracking_ParseOwnTracks($hash,$request) if(($request =~ /_type":[ ]?"location/ || $request =~ /_type":[ ]?"position/ || $request =~ /_type":[ ]?"transition/ || $request =~ /_type":[ ]?"steps/ || $request =~ /_type":[ ]?"beacon/ ));
#return undef; <----- return raus

Raus ist auch nicht gut, guck mal eine Zeile drüber.
Das Datenhandling passiert hier schon komplett in livetracking_ParseOwnTracks().

ZitatFrage zum return undef. Warum soll die Sub hier verlassen werden? Wenn ich es richtig verstehe, wird hier location, position ... verarbeitet. Die Bedingung "request enthält type" ist bei jedem korrekten Call wahr. Return würde hier die Verbindung offen lassen, die weitere Verarbeitung der Werte jedoch nicht machen. Oder sehe ich das falsch (rekursiver Aufruf o. ä.)?

Du hast Traccar HTTP vergessen, was das einzige ist das hier unterhalb noch passiert.
Siehe oben, das bringt mich aber auf eine Idee!

Was passiert, wenn du alles andere so lässt, aber das "return undef;" durch folgendes ersetzt:

Code Auswählen

    return ( "text/plain; charset=utf-8",
        "ok" );

Markus

kadettilac89 · 15 Januar 2019, 23:39:06

danke für die Antwort. habe meinen post darüber versehentlich gelöscht. hoffe das wird jetzt nicht unübersichtlich.

in parseowntracks ist er schnell wieder raus. das schau ich mir nochmal an. vielleicht liefert hier android ein feld nicht mit das abgefragt wird. habe mir die sub nicht genauer angesehen, dachte da wird adressermittliung oder sowas gemacht.

vielleicht ist es nur der return undefined der auf einen erfolgreichen code geändert werden müsste.

Markus M. · 15 Januar 2019, 23:44:55

Zitat von: kadettilac89 am 15 Januar 2019, 23:39:06
in parseowntracks ist er schnell wieder raus. das schau ich mir nochmal an. vielleicht liefert hier android ein feld nicht mit das abgefragt wird. habe mir die sub nicht genauer angesehen, dachte da wird adressermittliung oder sowas gemacht.

vielleicht ist es nur der return undefined der auf einen erfolgreichen code geändert werden müsste.

Ich hab OwnTracks HTTP selbst nicht getestet (kann ich mit Android auch nicht), aber es klingt so als fehlt nur der Return.
Wenn der Timeout weg ist, können wir uns den Rest ansehen.

kadettilac89 · 15 Januar 2019, 23:48:48

scheint wirklich nur der return undefined sein ...

Zeile 1545 geändert auf ...s. u. ... und Readings kommen an, kein Fehler mehr in der Owntrack App. Ich habe mir aber den Code nicht mehr angesehen ob auf Fehler, die in der parseowntrack-Sub außerhalb reagiert werden muss.

Code Auswählen


    return ( "application/json; charset=UTF-8",
        "[]" );

danke und schönen Abend

Markus M. · 16 Januar 2019, 00:38:58

Zitat von: kadettilac89 am 15 Januar 2019, 23:48:48
Readings kommen an, kein Fehler mehr in der Owntrack App. Ich habe mir aber den Code nicht mehr angesehen ob auf Fehler, die in der parseowntrack-Sub außerhalb reagiert werden muss.

Normal nicht.
Sollte regulär funktionieren, ansonsten gibt es Log Meldungen.
Der Fix ist dann gleich morgen im Update.

kadettilac89 · 16 Januar 2019, 11:02:27

Zitat von: klausw am 22 November 2018, 09:25:01
Ich habe mir ein Verbindungsmodul gebastelt, welches livetracking mit RESIDENTS verbindet (auf Basis von distance oder zone_* ... könnte aber erweitert werden).
Es muss nur definiert werden, anschließend genügt es, *geofenceUUID* in den RESIDENTS zu setzen.
Wenn Interesse besteht und Markus nix einzuwenden hat kann ich es in einem separaten Thread posten.

Es geht mit Hausmitteln, nur als Hinweis ohne was schlecht reden zu wollen .. wenn entweder nur ein Device überwacht wird, oder alle Device ohne Filter loggen.

Verbindung Onwtracks (livetrancking) und Residents Modul ...

1) userReadings in ownTracks

Basierend auf einer Zone. Im Beispiel ist Zone_0 die Homezone

Code Auswählen


attr livetrackingdata userReadings presence_home { ReadingsVal($name,"zone_0",0) eq "active" ? "present" : "absent" }

Basierend auf distance. Wenn Distanz kleiner 10 km (kann natürlich auch auf kleinere Werte gesetzt werden) wird auf anwesend gesetzt

Code Auswählen


attr livetrackingdata userReadings presence_home { ReadingsVal($name,"distance",999)< 10 ? "present" : "absent" }

2) Presence Device in ROOMMATE Device. Hier wird der Status vom livetrackingdata abgeholt.

Doku:

Code Auswählen


rr_presenceDevices - übernehmen des presence Status von einem anderen FHEM Device. Bei mehreren Devices diese mit Komma trennen, um ein Update 
des ROOMMATE Devices auszulösen, sobald ALLE Devices entweder absent oder present sind. Optional kann auch durch : abgetrennt ein Reading Name 
angegeben werden, ansonsten werden die Readings presence und state berücksichtigt.

Code Auswählen


attr rr_Owntracks rr_presenceDevices livetrackingdata:presence_home

binford6000 · 17 Januar 2019, 14:58:14

Hallo Zusammen,
ich habe auf meinem Testsystem einen livetracking device mit osmand Server angelegt:

Code Auswählen

Internals:
   NAME       iphone5SE
   NOTIFYDEV  owntracks
   NR         35
   NTFY_ORDER 999-iphone5SE
   STATE      ???
   TYPE       livetracking
   helper:
Attributes:
   osmandServer 1
   stateFormat location
   verbose    5

Wenn ich jetzt manuell die Location auf dem Gerät pushe steht folgendes im log:

Code Auswählen

2019.01.17 14:53:52.059 5: OsmAnd webcall request:
/osmand&{"rad":80,"tst":1547733218,"_type":"waypoint","lon":8.123456,"topic":"owntracks\/test\/iphone\/waypoint","lat":50.123456,"desc":"home"}
2019.01.17 14:53:59.183 5: OsmAnd webcall request:
/osmand&{"batt":19,"lon":8.123456,"acc":65,"p":98.343963623046875,"vac":10,"lat":50.123456,"inregions":["home"],"topic":"owntracks\/test\/iphone","t":"u","conn":"w","tst":1547733238,"alt":157,"_type":"location","tid":"SE"}

Im Livetracking regt sich aber nichts (siehe oben). Das Gerät mit owntracks App ist ein iPad. Was mache ich falsch?
VG Sebastian

Markus M. · 17 Januar 2019, 15:44:22

Zitat von: binford6000 am 17 Januar 2019, 14:58:14
Wenn ich jetzt manuell die Location auf dem Gerät pushe steht folgendes im log:
Code Auswählen Erweitern
2019.01.17 14:53:52.059 5: OsmAnd webcall request: /osmand&{"rad":80,"tst":1547733218,"_type":"waypoint","lon":8.123456,"topic":"owntracks\/test\/iphone\/waypoint","lat":50.123456,"desc":"home"} 2019.01.17 14:53:59.183 5: OsmAnd webcall request: /osmand&{"batt":19,"lon":8.123456,"acc":65,"p":98.343963623046875,"vac":10,"lat":50.123456,"inregions":["home"],"topic":"owntracks\/test\/iphone","t":"u","conn":"w","tst":1547733238,"alt":157,"_type":"location","tid":"SE"}

Im Livetracking regt sich aber nichts (siehe oben). Das Gerät mit owntracks App ist ein iPad. Was mache ich falsch?

Wann war dein letztes FHEM Update?
Und was steht sonst noch so im Log?
Mit dem aktuellen Code sollte die Logausgabe die du gepostet hast so überhaupt nicht möglich sein.