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

[carlos]

Also so funktionierts jetzt.
Per browser werden die Daten auch übertragen, jedoch per traccar client (egal ob IOS oder android) kommt immer "Übertragung fehlerhaft".
Schade, irgendwie scheint der traccar client da ein Problem zu haben.
Ich probiere weiter.
Gruß

[Markus M.]

iOS sollte funktionieren, zumindest tut es das bei mir - allerdings habe ich ohne HTTPS getestet.
Du kannst ja erst mal mit Verbose 5 nachsehen ob überhaupt irgendwas ankommt.
Wenn nicht liegt es vielleicht am SSL Zertifikat.

Zur Not einfach mal OwnTracks im HTTP Modus ausprobieren, wenn du die ankommenden Daten postest, kann ich das gerne noch erweitern.

[binford6000]

Hallo,
ich übertrage die livetracking readings via fhem2fhem in mein Haupt-FHEM. Leider wird bei address nur die erste Zeile (Straße) übertragen.
Der Rest fällt wegen dem NewLine raus:

Code Auswählen Erweitern

Industriestraße ␤56218 Mülheim-Kärlich ␤Deutschland
Würde es auch als userreading lösen aber scheitere am Split auf "␤". 
Irgendwelche Ideen/Vorschläge wie ich das lösen könnte? 
VG Sebastian

[Markus M.]

get address short ?!
Enthält zwar mehr Daten aber keine Newline.
Ein Bugfix für FHEM2FHEM wäre natürlich eleganter.

[binford6000]

get address short ?!

Da bekomme ich aber keine shorte address... 

Code Auswählen Erweitern

Straße, Ort, Kreis, Rheinland-Pfalz, PLZ, Deutschland
Wohingegen get address das gewünschte Ergebnis liefert:

Code Auswählen Erweitern

Straße, PLZ Ort, Deutschland
Wobei Deutschland ja noch zuviel des Guten ist...

Ein Bugfix für FHEM2FHEM wäre natürlich eleganter.

Sehe ich auch so...

VG Sebastian

[binford6000]

Habs jetzt so gelöst:
get address short und dann mit userreadings

Code Auswählen Erweitern

street {(split(/,/,ReadingsVal($name,'address','')))[0];;},
city {(split(/,/,ReadingsVal($name,'address','')))[1];;},
plz {(split(/,/,ReadingsVal($name,'address','')))[4];;}

VG Sebastian

[Jamo]

Code Auswählen Erweitern

{my @addr=(split(/\n/,ReadingsVal("livetracking","address","na"))); return $addr[0] . ", " . $addr[1] . ", " . $addr[2]}
sollte auch mit 'get address' gehen.

[binford6000]

Das hatte ich auch schon probiert auf \n zu splitten - allerdings nicht in ein Array...
Probier ich morgen mal aus.
Danke und VG Sebastian


Gesendet von iPad mit Tapatalk

[Markus M.]

Als Entscheidungshilfe würde ich mich auch anbieten, die restlichen Dienste mit zu implementieren.

Ich sehe das wirklich nicht hier im Code und bin ausdrücklich kein Fan von irgendwelchen Verstrickungen, wie sie bei PRESENCE oder RESIDENTS in Mode gekommen sind. Ich halte das sogar ausdrücklich für kompletten Unsinn, Funktionen komplett fremder Module aufzurufen.
FHEM Module sollten klar voneinander getrennt sein und die Daten sollten mit den dafür vorhandenen Events ausgetauscht werden.

Ich werde also keinen fremden Code mit Abhängigkeiten zu anderen Modulen direkt einbinden.
Wenn ich die Einbindung meiner Module als Datenquelle mit irgendwelchen Readings oder Events erleichtern kann, tue ich das aber natürlich gerne.

[Markus M.]

So, hier mal wieder eine etwas umfangreichere Testversion:
- Life360 ist wieder drin (hat ebenfalls einen Android Client)
- OwnTracks HTTP mode wird unterstützt (über das osmandServer Attribut)
- Ein paar Bugs sind weg

Sollte ich noch irgendwo Logging vergessen haben oder was nicht funktionieren: bitte melden

[binford6000]

Code Auswählen Erweitern

{my @addr=(split(/\n/,ReadingsVal("livetracking","address","na"))); return $addr[0] . ", " . $addr[1] . ", " . $addr[2]}
sollte auch mit 'get address' gehen.

Moin inoma,
super das passt. Danke!
VG Sebastian

[Markus M.]

Moin inoma,
super das passt. Danke!
VG Sebastian

get livetracking address singleline 

[binford6000]

get livetracking address singleline 

Oder so 

[binford6000]

Moin Markus,
erstmal vielen Dank für deine Arbeit!
Ich komme ja kaum noch mit dem Testen hinterher... 

Ich sehe das wirklich nicht hier im Code und bin ausdrücklich kein Fan von irgendwelchen Verstrickungen, wie sie bei PRESENCE oder RESIDENTS in Mode gekommen sind.

Im Fall ROOMMATE und RESIDENTS finde ich die Verknüpfung von PRESENCE schon sehr sinnvoll.
Und dazu gehört dann m.M.n. auch der Aufenthaltsort.

Wenn ich die Einbindung meiner Module als Datenquelle mit irgendwelchen Readings oder Events erleichtern kann, tue ich das aber natürlich gerne.

Schön zu lesen. Es wird aber weiterhin sehr individuell gehandhabt werden.
Ich für meinen Teil könnte mit der Verknüpfung zu ROOMMATE auch nur einen Teil meines Standort.DOIFs erschlagen.
Ich kann also deinen Ansatz "keep it as simple as possible" durchaus verstehen 

VG Sebastian

[klausw]

Ich sehe das wirklich nicht hier im Code und bin ausdrücklich kein Fan von irgendwelchen Verstrickungen, wie sie bei PRESENCE oder RESIDENTS in Mode gekommen sind. Ich halte das sogar ausdrücklich für kompletten Unsinn, Funktionen komplett fremder Module aufzurufen.
FHEM Module sollten klar voneinander getrennt sein und die Daten sollten mit den dafür vorhandenen Events ausgetauscht werden.

Ich werde also keinen fremden Code mit Abhängigkeiten zu anderen Modulen direkt einbinden.
Wenn ich die Einbindung meiner Module als Datenquelle mit irgendwelchen Readings oder Events erleichtern kann, tue ich das aber natürlich gerne.

Kann Deinen Standpunkt verstehen, besonders was modulübergreifenden Code angeht.
Aus Anwendersicht finde ich die Verstrickung recht praktisch, da ich einfach faul bin 

Längen und Breitengrade als separate Readings würde ich super finden. Letztendlich lassen die sich aber auch aus location extrahieren.

- OwnTracks HTTP mode wird unterstützt (über das osmandServer Attribut)

Bedeutet ich nutze das Ganze ohne MQTT?