In Anlehnung an dieses Topic https://forum.fhem.de/index.php/topic,99666.0.html (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 !
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
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
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
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
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?
Nein, ist eine Greenfield-Installation.
Also in anderen Worten kann ich das libxml-simple-perl wieder deinstallieren ... ?
Soll ich in ein anderes sub-Forum ?
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
Interessehalber: ist das livetracking-Device denn jetzt aktiviert? In dem list im ersten Beitrag war es noch per Attribut auf disable.
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 !
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
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
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) }
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 :)
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...
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.
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...
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.
@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.) ;) .
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
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...
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!
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?
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 ;)
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
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
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...
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?
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
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).
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 (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 !!
close