livetracking mit owntracks II

Begonnen von rallye, 06 November 2020, 11:07:32

Vorheriges Thema - Nächstes Thema

rallye

In Anlehnung an dieses Topic https://forum.fhem.de/index.php/topic,99666.0.html habe ich bei meiner Neuinstallation meines Systems von mosquitto auf MQTT2 umgestellt. Ich habe einen MQTT2_Server definiert
Internals:
   AuthenticationDeniedBy MQTT_sec
   CONNECTS   600
   DEF        8883 global
   FD         31
   FUUID      5fa2a6c4-f33f-55a1-4fd6-657034382d3efb57
   NAME       MQTT_Owntracks
   NR         261
   PORT       8883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   .attraggr:
   .attrminint:
   .clientArray:
     MQTT2_DEVICE
   READINGS:
     2020-11-06 10:15:49   nrclients       3
     2020-11-04 18:03:53   state           Initialized
   clients:
     MQTT_Owntracks_91.115.215.96_40571 1
     MQTT_Owntracks_91.115.215.96_45992 1
     MQTT_Owntracks_91.115.215.96_46806 1
   retain:
     owntracks/Nici/mobile:
       ts         1604641362.19579
       val        {"_type":"location","acc":26,"alt":412,"batt":94,"conn":"w","inregions":["home"],"lat":xx.xxx6639,"lon":xx.xxx0345,"t":"p","tid":"NL","tst":1604641358,"vac":9,"vel":0}
     owntracks/Sepp/mobile:
       ts         1604650070.7533
       val        {"_type":"location","acc":1200,"alt":0,"batt":75,"conn":"w","inregions":["home"],"lat":xx.xxx376,"lon":xx.xxx4574,"t":"u","tid":"SL","tst":1604650069,"vac":0,"vel":0}
     owntracks/owntracks/mobile:
       ts         1604655489.66864
       val        {"_type":"location","acc":14,"alt":406,"batt":89,"conn":"w","inregions":["home"],"lat":xx.xxx6781,"lon":xx.xxx0498,"t":"p","tid":"NL","tst":1604655486,"vac":116,"vel":0}
Attributes:
   autocreate simple
   room       MQTT

der aus dem WAN erreichbar ist (allowed ist entsprechend definiert)
Internals:
   CFGFN     
   FUUID      5fa5015b-f33f-55a1-c79e-2a430c782610658c
   NAME       MQTT_sec
   NR         419
   STATE      validFor:MQTT_Owntracks
   TYPE       allowed
   validFor   MQTT_Owntracks
   .attraggr:
   .attrminint:
   READINGS:
     2020-11-06 08:55:26   state           validFor:MQTT_Owntracks
Attributes:
   basicAuth  hier steht meine verschlüsselte Eingabe für user pwd
   room       MQTT
   validFor   MQTT_Owntracks

und stellvertretend ein von FHEM generiertes Device (Android Phone)
Internals:
   CID        seppmobile
   DEF        seppmobile
   DEVICETOPIC MQTT2_seppmobile
   FUUID      5fa2b93e-f33f-55a1-079c-094ceed909e58d68
   IODev      MQTT_Owntracks
   LASTInputDev MQTT_Owntracks
   MQTT_Owntracks_MSGCNT 144
   MQTT_Owntracks_TIME 2020-11-06 10:32:01
   MSGCNT     144
   NAME       MQTT2_seppmobile
   NR         262
   STATE      ???
   TYPE       MQTT2_DEVICE
   .attraggr:
   .attrminint:
   READINGS:
     2020-11-06 10:32:01   _type           location
     2020-11-06 10:32:01   acc             1200
     2020-11-06 10:32:01   alt             0
     2020-11-06 10:32:01   batt            68
     2020-11-06 10:32:01   conn            w
     2020-11-05 12:59:45   desc            home
     2020-11-05 12:59:45   event           enter
     2020-11-06 10:32:01   inregions_1     home
     2020-11-06 10:32:01   lat             xx.xxx1376
     2020-11-06 10:32:01   lon             xx.xxx4574
     2020-11-06 10:12:11   subscriptions   owntracks/+/mobile owntracks/+/mobile/event owntracks/+/mobile/info owntracks/+/mobile/waypoints owntracks/owntracks/mobile/cmd
     2020-11-06 10:32:01   t               p
     2020-11-06 10:32:01   tid             SL
     2020-11-06 10:32:01   tst             1604655120
     2020-11-06 10:32:01   vac             0
     2020-11-06 10:32:01   vel             0
     2020-11-05 12:59:45   wtst            1541593407564
Attributes:
   IODev      MQTT_Owntracks
   icon       it_smartphone@blue
   readingList seppmobile:owntracks/Sepp/mobile:.* { json2nameValue($EVENT) }
seppmobile:owntracks/Sepp/mobile/event:.* { json2nameValue($EVENT) }
seppmobile:owntracks/owntracks/mobile:.* { json2nameValue($EVENT) }
   room       MQTT
   sortby     1

Nun zu meinem Problem: ich habe ein livetracking definiert und mit dem Mobiltelefon verknüpft, bekomme aber keine vernünftigen Daten, sondern lediglich einen Status "XML::Simple is required!"
Internals:
   CFGFN     
   FUUID      5fa51541-f33f-55a1-7f80-3e5ddf69737aa8b9
   NAME       LT_Sepp
   NOTIFYDEV  MQTT2_seppmobile
   NR         662
   NTFY_ORDER 999-LT_Sepp
   STATE      XML::Simple is required!
   TYPE       livetracking
   helper:
Attributes:
   disable    1
   owntracksDevice MQTT2_seppmobile
   room       MQTT


Irgendwie hat das bei der alten mosquitto-Installation funktioniert - jetzt bekomme ich das nicht hin. Bitte um Unterstützung !
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

Otto123

Hi,

na dann wird es wohl so sein :) -> das Modul XML::Simple fehlt?

https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html

debian paket libxml-simple-perl

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rallye

Danke Otto! Bis heute wusste ich nicht dass XML::simple etwas zum installieren ist (bin an dieser Ecke ein absolut Unwissender). Ich dachte nach etwas lesen das wird einfach. Ein sudo apt -y install libxml-simple-perl und das wär's gewesen. Leider ist es nicht so. Nach Restart von fhem aber auch nach reboot kommt die msg immer noch. Hab versucht um im Forum aber auch Netz Infos zu bekommen, dich ist das alles ein spanisches Dorf für mich. Bitte um eine Hilfe für complete idiots (an dieser Stelle). Danke
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

Otto123

Moin,

"-y " is ein böser Schalter! Vor allem "for complete idiots" (wie Du Dich selbst bezeichnest) :)
Der verhindert das Du Fehler siehst. Hast Du anhand von meinem Artikel mal geschaut ob die Installation des Paketes jetzt erfolgt ist?
s='XML::Simple'
perl -M$s -e '' 2>/dev/null &&echo "Modul $s ist vorhanden"


Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rallye

Danke Otto. Na soooo "Complete Idiot", dass ich beim install kein -y machen kann bin ich auch nicht  ;) Bei Perl allerdings schon  :-[
Ja, ich hab deinen Blog nachvollzogen. Hatte libxml-simple-perl wieder deinstalliert... Mit deiner Abfrage
s='XML::Simple'
perl -M$s -e '' 2>/dev/null &&echo "Modul $s ist vorhanden"

war keine Ausgabe. Hab das Paket danach wieder installiert und die Abfrage ergab
mod@RasPi-Server:~ $ perl -M$s -e '' 2>/dev/null &&echo "Modul $s ist vorhanden"
Modul XML::Simple ist vorhanden

Trotzdem hab ich (natürlich nach Restart von FHEM) den Status "XML::Simple is required!" im Livetracking
defmod LT_Sepp livetracking
attr LT_Sepp disable 1
attr LT_Sepp owntracksDevice MQTT2_seppmobile
attr LT_Sepp room MQTT
attr LT_Sepp stateFormat location

setstate LT_Sepp XML::Simple is required!

Bin nach wie vor ratlos, möchte dennoch nicht auf mosquitto zurücksteigen

Danke
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

Otto123

Kann zu dem owntracks nicht viel sagen-aber an mqtt2 liegt das nicht. Das braucht für sich kein XML::Simple.

Hast Du mehrere Perls am laufen?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rallye

Nein, ist eine Greenfield-Installation.
Also in anderen Worten kann ich das libxml-simple-perl wieder deinstallieren ... ?

Soll ich in ein anderes sub-Forum ?
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

Otto123

Guten Morgen,

das Unterforum wäre das Richtige: FHEM/98_livetracking.pm      markus-m             Unterstützende Dienste
MQTT2 braucht kein XML::Simple, livetracking scheint es ja zu brauchen - sonst würde es nicht als Fehler erscheinen. Die Doku vom Modul selbst sagt leider nichts zu Abhängigkeiten aus: https://fhem.de/commandref.html#livetracking

Hab nochmal darübernachgedacht:
ZitatTrotzdem hab ich (natürlich nach Restart von FHEM) den Status "XML::Simple is required!" im Livetracking
Nach dem Restart von FHEM wird aus fhem.save der letzte Status wiederhergestellt. (setstate LT_Sepp XML::Simple is required!) Wenn der also kein aktueller ist, kann es auch eine alte Meldung sein.
Hast Du denn beim livetracking Modul den Loglevel (verbose) hochgedreht und ins Log geschaut?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Interessehalber: ist das livetracking-Device denn jetzt aktiviert? In dem list im ersten Beitrag war es noch per Attribut auf disable.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rallye

Mahlzeit !
Zitat von: Otto123 am 09 November 2020, 09:41:30
das Unterforum wäre das Richtige: FHEM/98_livetracking.pm      markus-m             Unterstützende Dienste

Danke, dann werd ich mich dorthin begeben ...
Zitat von: Otto123 am 09 November 2020, 09:41:30
Hab nochmal darübernachgedacht:Nach dem Restart von FHEM wird aus fhem.save der letzte Status wiederhergestellt. (setstate LT_Sepp XML::Simple is required!) Wenn der also kein aktueller ist, kann es auch eine alte Meldung sein.
Hast Du denn beim livetracking Modul den Loglevel (verbose) hochgedreht und ins Log geschaut?
Der Status ist aktuell und sieht derzeit so aus:
defmod LT_Sepp livetracking
attr LT_Sepp owntracksDevice MQTT2_seppmobile
attr LT_Sepp room MQTT
attr LT_Sepp stateFormat location
attr LT_Sepp verbose 5

setstate LT_Sepp XML::Simple is required!


Zitat von: Beta-User am 09 November 2020, 09:56:31
Interessehalber: ist das livetracking-Device denn jetzt aktiviert? In dem list im ersten Beitrag war es noch per Attribut auf disable.
Ja, ich habe ein "Test-livetracking" (siehe oben) welches aktiviert ist. Im Log finde ich folgende Infos
2020.11.09 14:17:06 4: MQTT2_DEVICE_Parse: MQTT2_alexandermobile owntracks/owntracks/mobile => { json2nameValue($EVENT) }
2020.11.09 14:23:58 2: AttrTemplates: got 189 entries
2020.11.09 14:24:30 3: Login denied via MQTT_Owntracks
2020.11.09 14:24:30 4: MQTT2_DEVICE_Parse: MQTT2_seppmobile owntracks/otSepp/mobile => { json2nameValue($EVENT) }
2020.11.09 14:24:30 4: WRONG MQTT TYPE $VAR1 = 't: p';

2020.11.09 14:25:27 4: MQTT2_DEVICE_Parse: MQTT2_seppmobile owntracks/otSepp/mobile => { json2nameValue($EVENT) }
2020.11.09 14:25:27 4: WRONG MQTT TYPE $VAR1 = 't: u';


NB: alexandermobile ist ein anderes Mobiltelefon.....

Werde mich später ins vorgeschlagene Forum begeben. Danke !
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

Otto123

#10
Zitat von: statler am 09 November 2020, 14:34:57
Werde mich später ins vorgeschlagene Forum begeben. Danke !
Du bist "verpeilt" :) Du bist doch schon in dem (richtigen) Forum. Ich habe doch nix anderes gesagt ;)
Aber ich sehe Du bist direkt in  den Support Thread gewechselt und hast auch direkt ne Antwort bekommen 👍

ZitatLogin denied via MQTT_Owntracks
Das ist doch Dein Problem?

Was ist MQTT_Owntracks für ein Device (am einfachsten ein list davon)?
Ich lese in dem anderen Thread aus Interesse mit :)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Otto123

Hi,

ich weiß nicht ob statler jetzt schon weiter gekommen ist, aber ich habe das testhalber aufgebaut und bin relativ weit.
     BTW: Das sollte dann ein/zwei attrTemplate werden ;)
Ich habe folgendes Scenario:

  • "eigene" MQTT Cloud Broker Instanz
  • owntracks auf dem Android Phone
  • MQTT2_CLIENT - Bridge regExp fehlt noch, autocreate simple
  • MQTT2_DEVICE - das automatisch angelegt ist so nicht für livetracking brauchbar
  • readingList angepasst, so das der komplette json String in ein Reading kommt
  • livetracking definiert - braucht XML::Simple
Mein Vorteil: MQTT Port im eigene Netzwerk offen.

Statler hat den MQTT2_SERVER freigeben und geschützt.
Vorteil: Keine MQTT Instanz in der Cloud und anstatt MQTT2_CLIENT - MQTT2_SERVER. Etwas einfacher?
Alles relativ :)

Aus meiner Sicht hat das livetracking Device hier nur den zusätzlichen Nutzen, dass man die Location zu einer Adresse auflösen/abfragen kann. Sehe ich da was nicht?
Ansonsten sieht das ganz gut aus. Man kann in owntracks Areale definieren und bekommt im MQTT2_DEVICE einen Event beim Betreten und Verlassen!

Mein MQTT2_DEVICE (auf die Schnelle)
defmod MQTT_OwnTracks MQTT2_DEVICE mqtt2Cloud
attr MQTT_OwnTracks IODev mqtt2Cloud
attr MQTT_OwnTracks readingList mqtt2Cloud:owntracks/clouduser/mi6:.* mi6\
mqtt2Cloud:owntracks/clouduser/mi6:.* { json2nameValue($EVENT) }\
mqtt2Cloud:owntracks/clouduser/mi6/waypoints:.* { json2nameValue($EVENT) }\
mqtt2Cloud:owntracks/clouduser/mi6/event:.* { json2nameValue($EVENT) }
attr MQTT_OwnTracks room MQTT2_DEVICE



Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Das Problem scheint zu sein, dass das "Anschlussmodul" die JSON-Daten als JSON-Blob haben will und nicht als Einzelreadings.

Sowas könnte weiterhelfen, ggf. bitte in dem anderen Thread nochmal nachhaken, ob da ein bestimmter Readingname erforderlich ist bzw. wie es angegeben werden muss:
attr MQTT_OwnTracks readingList mqtt2Cloud:owntracks/clouduser/mi6:.* mi6\
mqtt2Cloud:owntracks/clouduser/mi6:.* json_mi6\
mqtt2Cloud:owntracks/clouduser/mi6:.* { json2nameValue($EVENT) }\
mqtt2Cloud:owntracks/clouduser/mi6/waypoints:.* json_waypoints\
mqtt2Cloud:owntracks/clouduser/mi6/waypoints:.* { json2nameValue($EVENT) }\
mqtt2Cloud:owntracks/clouduser/mi6/event:.* json_event\
mqtt2Cloud:owntracks/clouduser/mi6/event:.* { json2nameValue($EVENT) }
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Zitat von: Beta-User am 10 November 2020, 11:57:46
Das Problem scheint zu sein, dass das "Anschlussmodul" die JSON-Daten als JSON-Blob haben will und nicht als Einzelreadings.
Ist so :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

ok, aber der "json-Eintrag" war ja auch (für den relevanten Teil (?) mi6) schon vorhanden, hatte ich leider übersehen... ::)

Bin grade dabei, was dazu ins Wiki/Praxisbeispiele/allgemeine hinweise einzuarbeiten, kommt doch hin und wieder vor...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: statler am 10 November 2020, 16:29:21
Danke. Dazu eine Frage: ich muss 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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: statler am 10 November 2020, 18:03:16
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Zitat von: statler am 10 November 2020, 18:03:16
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! ;D
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.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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:
  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.) ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Zitat1 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!

Zitatob 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!
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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...
Zitat von: Otto123 am 11 November 2020, 10:23:42
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):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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

ich hoffe statler verzeiht uns, dass wir hier ein bisschen forschen und dokumentieren :)
bisher sehe ich drei unterschiedliche json Events
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 ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rallye

Zitat von: Otto123 am 11 November 2020, 12:06:40
ich hoffe statler verzeiht uns, dass wir hier ein bisschen forschen und dokumentieren :)
Statler verzeiht  ;D !
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
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

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
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

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?

Zitat von: Beta-User am 11 November 2020, 10:17:49
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rallye

Zitat von: Otto123 am 12 November 2020, 16:50:02
@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
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:
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):
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:
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:
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;
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.

Zitat von: Beta-User am 12 November 2020, 14:44:51
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
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rallye

Ich habe das nun in den anderen Post verlagert um parallele Posts zu verhindern https://forum.fhem.de/index.php/topic,37412.msg1102579.html#msg1102579. Allerdings werde ich aus Deiner Antwort leider nicht sehr schlau ... Was kann ICH machen ?

Ich werde das Topic hier schließen, lass uns bitte im anderen Post weitermachen.

Danke !!
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

rallye

RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor