livetracking mit owntracks

[TWART016]

Hallo,

ich würde gerne owntracks mit livetracking konfigurieren. Die App ist installiert und sendet die Nachrichten an MQTT (Mosquitto). Leider habe ich in keinem Wiki / Forum gefunden wie die Struktur aussehen muss.

Wo muss MQTT Subscript werden? Wie ist die Verbindung zu livetracking, z.B. welche Attribute.


Gruß
TWART016

[Markus M.]

Du brauchst ein MQTT Server Device:

Code Auswählen Erweitern

define mqtt MQTT 127.0.0.1:1883

Und ein MQTT Device für die Subscriptions:
(OwnTracks UserID -> fhem / DeviceID -> iphone)

Code Auswählen Erweitern

define owntracks MQTT_DEVICE
attr owntracks IODev mqtt
attr owntracks publishSet_cmd owntracks/fhem/iphone/cmd
attr owntracks publishSet_msg owntracks/fhem/iphone/msg
attr owntracks qos at-least-once
attr owntracks subscribeReading_beacon owntracks/fhem/iphone/beacon
attr owntracks subscribeReading_cmd owntracks/fhem/iphone/cmd
attr owntracks subscribeReading_dump owntracks/fhem/iphone/dump
attr owntracks subscribeReading_event owntracks/fhem/iphone/event
attr owntracks subscribeReading_iphone owntracks/fhem/iphone
attr owntracks subscribeReading_msg owntracks/fhem/iphone/msg
attr owntracks subscribeReading_step owntracks/fhem/iphone/step
attr owntracks subscribeReading_waypoints owntracks/fhem/iphone/waypoints

Und im Livetracking Device weist du es dann zu:

Code Auswählen Erweitern

define livetracking livetracking
attr livetracking owntracksDevice owntracks


Das war's eigentlich auch schon, danach solltest du die Daten in Livetracking haben.

M

[TWART016]

Bei mir tauchen die Event in MQTT aber anders auf

Code Auswählen Erweitern

owntracks/fhem/iphone
also ohne ein /xxx

In den Daten steht dann

Code Auswählen Erweitern

{"tst":467854548,"acc":65,"_type":"location","alt":295,"lon":9.95784644786,"vac":10,"p":98.4472872434,"lat":48.46812144755,"batt":24,"conn":"w","tid":"5B"}

[tomleitner]

Hallo, ich versuche grade ebensolches.

Mosquitto läuft, die Owntracks Daten tauchen dort auf. Habe ein MQTT2 Device mit Autocreate anlegen lassen und bekomme readings.

Allerdings klappt die Verbindung mit dem "livetracks" device nicht!

Aktuell schaut das Ganze so aus:

Code Auswählen Erweitern

define MQTT_OwnTracks MQTT2_CLIENT fhem-if:1883
attr MQTT_OwnTracks autocreate yes
attr MQTT_OwnTracks clientId LiveTracking
attr MQTT_OwnTracks disable 0
attr MQTT_OwnTracks room MQTT,Live Tracking
attr MQTT_OwnTracks username fhem

define OwnTracks MQTT2_DEVICE LiveTracking
attr OwnTracks IODev MQTT_OwnTracks
attr OwnTracks readingList LiveTracking:owntracks/USERNAME/XXXXXXXXXXXXXXXX:.* { json2nameValue($EVENT, 'XXXXXXXXXXXXXXXX', $JSONMAP) }\
LiveTracking:owntracks/USERNAME/XXXXXXXXXXXXXXXX/dump:.* { json2nameValue($EVENT, 'dump_', $JSONMAP) }\
LiveTracking:owntracks/USERNAME/XXXXXXXXXXXXXXXX/waypoints:.* { json2nameValue($EVENT, 'waypoints_', $JSONMAP) }
attr OwnTracks room Live Tracking,MQTT

define LiveTracking livetracking
setuuid LiveTracking 5cee5656-f33f-44cf-05c2-27859a250f1e5025
attr LiveTracking owntracksDevice OwnTracks
attr LiveTracking room Live Tracking
attr LiveTracking stateFormat location

Das Passwort für das MQTT_OwnTracks device habe ich natürlich gesetzt und es klappt auch. USERNAME und XXXXXXXXXXXXX sind meine Daten bei OwnTracks -- hier ausgeblendet.

Was mache ich falsch?

Danke // Tom

[Beta-User]

Vorneweg: Besser lists oder RAW-Definitionen liefern. Da sieht man dann nämlich auch, wie die Readings ausschauen, und die sind hier evtl. das Problem (genauer: deren Namen).

Mach' mal einen gültigen Wert für autocreate an das IO und bau die json2nameValue-Anweisungen auf die einfache Form um (nur ein Argument), lösche die vorhandenen Readings am MQTT2_DEVICE.

Dann waren, bis neue Werte reinkommen, dann könnte es schon passen.

[tomleitner]

Danke hier .. hier die Raw Defs:

Code Auswählen Erweitern

defmod MQTT_OwnTracks MQTT2_CLIENT fhem-if:1883
attr MQTT_OwnTracks autocreate yes
attr MQTT_OwnTracks clientId LiveTracking
attr MQTT_OwnTracks disable 0
attr MQTT_OwnTracks room MQTT,Live Tracking
attr MQTT_OwnTracks username fhem

setstate MQTT_OwnTracks opened
setstate MQTT_OwnTracks 2019-05-29 12:23:01 state opened

dann:

Code Auswählen Erweitern

defmod OwnTracks MQTT2_DEVICE LiveTracking
attr OwnTracks IODev MQTT_OwnTracks
attr OwnTracks readingList LiveTracking:owntracks/USERNAME/XXXXXXXXXXXXXXXXXXXXXXXXXX:.* { json2nameValue($EVENT, 'XXXXXXXXXXXXXXXXXXXXXXXXXX', $JSONMAP) }\
LiveTracking:owntracks/USERNAME/XXXXXXXXXXXXXXXXXXXXXXXXXX/dump:.* { json2nameValue($EVENT, 'dump_', $JSONMAP) }\
LiveTracking:owntracks/USERNAME/XXXXXXXXXXXXXXXXXXXXXXXXXX/waypoints:.* { json2nameValue($EVENT, 'waypoints_', $JSONMAP) }
attr OwnTracks room Live Tracking,MQTT

setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX__type location
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_acc 65
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_alt 344
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_batt 99
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_conn w
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_inregions_1 Work
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_lat  xxxxxxxxx
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_lon xxxxxxxxx
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_t t
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_tid T
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_tst 1xxxx3826
setstate OwnTracks 2019-05-29 12:30:07 XXXXXXXXXXXXXXXXXXXXXXXXXX_vac 10
setstate OwnTracks 2019-05-29 11:57:07 dump__type dump
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration__type configuration
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_allowRemoteLocation true
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_allowinvalidcerts true
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_auth true
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_cleanSession false
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_clientId
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_clientpkcs
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_cmd false
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_deviceId
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_extendedData true
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_host XXXXXXXXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_ignoreInaccurateLocations 0
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_ignoreStaleLocations 0
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_keepalive 60
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_locatorDisplacement 200
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_locatorInterval 180
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_locked false
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_mode 0
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_monitoring 2
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_mqttProtocolLevel 3
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_passphrase
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_password XXXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_policymode 0
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_port XXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_positions 50
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_pubQos 1
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_pubRetain true
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_pubTopicBase
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_ranging false
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_servercer
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_sub false
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_subQos 1
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_subTopic
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_tid T
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_tls true
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_url
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_usePassword true
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_usepolicy true
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_username XXXXXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_validatecertificatechain false
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_validatedomainname false
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_1__type waypoint
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_1_desc Work
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_1_lat XXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_1_lon XXXXXXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_1_rad 50
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_1_tst XXXXX2
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_2__type waypoint
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_2_desc Zuhause
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_2_lat XXXXXXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_2_lon XXXXXXXXXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_2_rad 30
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_waypoints_2_tst XXXXXX
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_willQos 1
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_willRetain false
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_willTopic
setstate OwnTracks 2019-05-29 11:57:07 dump_configuration_ws false
setstate OwnTracks 2019-05-29 11:56:31 waypoints__type waypoints
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_1__type waypoint
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_1_desc Work
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_1_lat XXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_1_lon XXXXXXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_1_rad 50
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_1_tst 1XXXXXXXXXX662
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_2__type waypoint
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_2_desc Zuhause
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_2_lat XXXXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_2_lon XXXXXXXXXXXXXXXX
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_2_rad 30
setstate OwnTracks 2019-05-29 11:56:31 waypoints_waypoints_2_tst XXXXXXXXXXXXX


sowie:

Code Auswählen Erweitern

defmod LiveTracking livetracking
attr LiveTracking owntracksDevice OwnTracks
attr LiveTracking room Live Tracking
attr LiveTracking stateFormat location


Persönlche Daten ausgeXXXXt.  Was meinst Du mit "json2nameValue" auf einfache Form? Gibts kein Beispiel was das livetracking Modul alles an readings erwartet? Hier ist die Doku leider recht dürftig ...

Danke Dir!

[Beta-User]

Mach' mal einen gültigen Wert für autocreate an das IO

"yes" ist nach wie vor kein gültiger Wert! Bitte in die cref zu MQTT2_CLIENT schauen. Da steht:

autocreate [no|simple|complex]
if set to simple/complex, at least one MQTT2_DEVICE will be created, and its readingsList will be expanded upon reception of published messages. Note: this is slightly different from MQTT2_SERVER, where each connection has its own clientId.  This parameter is sadly not transferred via the MQTT protocol, so the clientId of this MQTT2_CLIENT instance will be used.
With simple the one-argument version of json2nameValue is added: json2nameValue($EVENT), with complex the full version: json2nameValue($EVENT, 'SENSOR_', $JSONMAP). Which one is better depends on the attached devices and on the personal taste, and it is only relevant for json payload. For non-json payload there is no difference between simple and complex.

Hier scheint es so zu sein, das "yes" mit "complex" gleichgesetzt wird...

Damit sollte sich diese Frage eigentlich gar nicht mehr stellen:

Was meinst Du mit "json2nameValue" auf einfache Form?

Jedenfalls würde ich davon ausgehen, dass owntracks eine einfache Form des Auspackens des JSON bevorzugt...


Ergänzend würde ich vorschlagen, dass du dir mal das Wiki zu MQTT2_CLIENT anschaust und ein GeneraBridge-MQTT2_DEVICE anlegst. Dabei evtl. die dortige bridgeRegepx so erweitern, dass die Owntracks-Infos jeweils auch in diesem (bzw. ggf. weiteren sinnvollen Devices) landen. Ich kenne Owntracks nicht, daher kann ich von hier aus auch nicht beurteilen, was Sinn macht (v.a. nicht anonymisiert).

[tomleitner]

Danke ... nun klappt es. In meinem OwnTracks device habe ich nun lediglich folgendes als readingList:

Code Auswählen Erweitern

LiveTracking:owntracks/USERNAME/XXXXXXXXXXXXXXXXX:.* OWNTRACKS

Damit wird das JSON nicht entpackt. Sonst gibts es KEIN anderes reading. Die anderen Readings scheint das livetracking Modul nicht zu mögen.

Nun habe ich Daten im "livetracking" Device. Was mir noch abgeht ist die OwnTracks "inregions" ... d.h. ich definiere im OwnTracks schöne Regions nur im livetracking Modul wird der Zustand in welche Region ich bin nicht übermittelt.

In meinem früheren Owntracks modul wo der JSON geparst wurde, war das schon drinnen ...

Danke jedenfals ... Tom

[Beta-User]

Hmmm, ich kann da jetzt mangels eigenem Owntracks nicht ganz folgen, aber erst mal schön, dass das klappt.

Wenn du den JSON nur in bestimmten Fällen ausgepackt haben willst (z.B., wenn die inregions kommen), kann man auch sowas mit MQTT2_DEVICE anstellen. Wenn dich das interessiert, such im MQTT-Bereich mal nach den sonoff-IR und -RF-template-Threads, da gibt es (allerdings eher nicht selbsterklärende) Codeschnipsel dazu.

PS: wenn das mit owntracks in der bridgeRegexp paßt, wäre ich für eine Rückmeldung dankbar, dann kann ich das ggf. in das allgemeine Template einpflegen...

[Loredo]

PS: wenn das mit owntracks in der bridgeRegexp paßt, wäre ich für eine Rückmeldung dankbar, dann kann ich das ggf. in das allgemeine Template einpflegen...

Ich hätte hier glaub ich was für den Anfang:

Code Auswählen Erweitern


# an owntracks device
name:owntracks_device
desc: A device tracked with OwnTracks
filter:TYPE=MQTT2_DEVICE:FILTER=CID=owntracks.*
order:O_02
par:TRACKER_ID;TrackerID;{ AttrVal("DEVICE","readingList","") =~ m,[^/:]+[/]([^/:]+).*:, ? $1 : undef }
par:DEV_ID;DeviceID;{ AttrVal("DEVICE","readingList","") =~ m,[^/:]+[/][^/:]+[/]([^/:]+).*:, ? $1 : undef }
attr DEVICE icon location_sign
attr DEVICE jsonMap\
  _type:lastUpdateType\
  acc:accuracy\
  alt:altitude\
  batt:batteryPercent\
  bs:batteryState\
  cog:direction\
  conn:connection\
  lat:latitude\
  lon:longitude\
  rad:radius\
  p:pressure\
  t:trigger\
  tid:trackerId\
  tst:timestamp\
  vac:accuracyVertical\
  vel:velocity\
  event__type:lastUpdateType\
  event_acc:event_accuracy\
  event_lat:event_latitude\
  event_lon:event_longitude\
  event_t:event_trigger\
  event_tid:event_trackerId\
  event_tst:event_timestamp\
  event_wtst:event_waypointCreationTimestamp\
  step__type:lastUpdateType\
  step_steps:steps_count\
  step_from:steps_timestampBegin\
  step_to:steps_timestampEnd\
  step_tst:steps_timestampReq\
  beacon__type:lastUpdateType\
  beacon_acc:beacon_accuracy\
  beacon_prox:beacon_proximity\
  beacon_tst:beacon_timestampReq\
  waypoints__type:lastUpdateType\
  waypoints__creator:waypoints_creator\
  config__type:lastUpdateType
attr DEVICE readingList\
  owntracks/TRACKER_ID/DEV_ID:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  owntracks/TRACKER_ID/DEV_ID/event:.* { json2nameValue($EVENT,'event_',$JSONMAP) }\
  owntracks/TRACKER_ID/DEV_ID/step:.* { json2nameValue($EVENT,'step_',$JSONMAP) }\
  owntracks/TRACKER_ID/DEV_ID/beacon:.* { json2nameValue($EVENT,'beacon_',$JSONMAP) }\
  owntracks/TRACKER_ID/DEV_ID/waypoints:.* { json2nameValue($EVENT,'waypoints_',$JSONMAP) }\
  owntracks/TRACKER_ID/DEV_ID/dump:.* { json2nameValue($EVENT,'config_',$JSONMAP) }
attr DEVICE getList\
  location:noArg raw owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"reportLocation"}\
  steps:noArg raw owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"reportSteps"}\
  config:noArg raw owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"dump"}\
  waypoints:noArg raw owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"waypoints"}
attr DEVICE setList\
  config owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"setConfiguration","configuration":$EVTPART1}\
  waypoints owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"setWaypoints","waypoints":{"_type":"waypoints","waypoints":$EVTPART1}\
  action owntracks/TRACKER_ID/DEV_ID/cmd {"_type":"cmd","action":"action",$EVTPART1}
attr DEVICE model owntracks_device
attr DEVICE room OwnTracks


Allerdings klappt kein autocreate. Auch nicht, wenn ich dies als bridgeRegexp hinzufüge:

Code Auswählen Erweitern


(owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"


Wahrscheinlich kappiere ich aber einfach nicht, wie autocreate überhaupt funktioniert...

[andre07]

Hallo
Kann man das auch mit MQTT2 Server nutzen ich bekomme leider wenn ich unterwegs bin keine Verbindung
zu Fhem in der Owntracks App steht Verbindung wurde getrennt java.io.EOFEException. Port ist natürlich
freigegeben. Habe die Devices local angelegt verbindung da aber sobald auswärts geht es nicht mehr

Andre

[Beta-User]

Port ist natürlich freigegeben.

Das ist eine sehr kurze Kurzfassung...

1. Ohne Portfreigabe dürfte das gar nicht gehen, und mit nur, wenn du
2. für "externe Netze" ein "allowed" definiert hast, das auch was anderes als das lokale Netz zuläßt.

Bitte bei direkter Weiterleitung von irgendwelchen FHEM-Ports UNBEDINGT auf eine saubere Absicherung achten, in der Regel bedeutet das: auch SSL aktivieren; wenn dir nicht klar ist, wie es "richtig" geht: Einfach lassen. Und für von außen zugängliche Dinge: autocreate abschalten.

(@Experten: Sollte ich da was wichtiges vergessen habe: bitte ausdrücklich um Klarstellung!)

[rudolfkoenig]

Habe die Devices local angelegt verbindung da aber sobald auswärts geht es nicht mehr

Wenn unsere Vermutung stimmt, dann sollte eine entsprechende Nachricht im Log zu sehen sein:

Code Auswählen Erweitern

Connection refused from the non-local address $caddr:$port as there is no working allowed instance defined for it

2. für "externe Netze" ein "allowed" definiert hast, das auch was anderes als das lokale Netz zuläßt.

Das ist mAn missverstaendlich, ich versuche es detaillierter:
- ich empfehle eine allowed Instanz anzulegen, was diesem MQTT_SERVER zugewiesen ist, und Benutzer/Passwort gesetzt hat. Auf der anderen Seite muss man Benutzer/Passwort dann auch setzen.
- man kann das umgehen, indem man das allowfrom Attribut setzt, hier sollte man aber ueber die Folgen unbedingt im klaren sein(!)
- weiterhin sollte man das SSL Attribut der MQTT_SERVER setzen, das muss dann auch auf der anderen Seite aktiviert werden.

[andre07]

Zugriff von aussen habe ich bei mir mit ssl und reverse Proxy
realisiert (passwort geschützt).
Das ich dazu auch noch eine allowed Instanz benötige war mir
nicht klar da ich ja den port auf dem der Mqtt2 Server lauscht nach
aussen freigegeben hatte.
Probier das jetzt mal aus ob dann klappt.
Owntrack versucht eine Verbindung über
tcp://dyn.mynetz.com:1883 aufzubauen ,was ich nicht
ganz verstehe ist warum ich dazu ein allowed
benötige...und wie muss diese konfiguriert sein.
So in etwa
define allowedmqtt2server allowed
attr allowedmqtt2server validFor mqtt2server



Andre

[rudolfkoenig]

Zugriff von aussen habe ich bei mir mit ssl und reverse Proxy realisiert (passwort geschützt).

Wenn das auch fuer MQTT gilt, dann vergiss alles, was wir gesagt haben, und was ich in den folgenden Zeilen schreibe.

Ich vermute aber, du meinst damit den WEB Zugang fuer FHEMWEB, und das ist fuer den MQTT_SERVER irrelevant.

Um diesen zu sichern musst du (ich wiederhole mich irgendwie):
- eine allowed Instanz anlegen (oder eine Vorhandene verwenden)
- diese mit dem Attribut validFor der MQTT2_SERVER Instanz zuweisen
- hier Benutzer und Passwort setzen
- beim MQTT2_SERVER SSL setzen

=> Damit ist die FHEM-Seite gesichert.

Fehlt noch in Owntrack Benutzername, Passwort und SSL zu aktivieren, laut https://owntracks.org/booklet/features/security/ ist das moeglich (SSL in FHEMWEB entspricht bei Owntrack dem TLS)

Warum das Ganze: Ohne Passwort kann jeder, der dein MQTT Port findet (und danach wird permanent aktiv gesucht, siehe https://www.shodan.io/), bei Dir Aktionen ausloesen. Den meisten geht es dabei nicht mal um deine Daten, sondern man verwendet deine Rechner als Mittel zum naechsten Straftat.
Damit FHEM nach einer Hack-Aktion in den Medien nicht als Sicherheitloch gebrandmarkt wird, und ich als Autor der Module zur Verantwortung gezogen werde, weigern sich bestimmte FHEM Dienste ohne Passwort-Sicherung direkt aus dem Internet erreichbar zu sein.

[andre07]

Den Mqtt2 Server habe ich jetzt per allowed abgesichert mußte noch all mein Devices
entsprechend auf user/password umstellen.

Code Auswählen Erweitern


defmod allowedmqtt2 allowed
attr allowedmqtt2 DbLogExclude .*
attr allowedmqtt2 basicAuth SHA256:4363AAD8:Tbb4L2Vf0fj1kEv5bnFF2EyqAoUZxZSxxxxxxxxxxx/Q
attr allowedmqtt2 room System
attr allowedmqtt2 validFor MQTTServer



Versucht per Owntracks eine Verbindung zu bekommen
im log von owntracks steht Benutzer oder password falsch.
(definitiv nicht falsch das andere Zeug funktioniert ja)
Wenn ich jetzt noch ssl aktiviere müßte bekämen meine anderen
clients Probleme da nicht alle das unterstützen.
Wahrscheinlich wäre es besser es per http in Verbindung mit osmand Server
zu realisieren wird ja von lifetracking mit unterstützt.

Andre

[rudolfkoenig]

im log von owntracks steht Benutzer oder password falsch.

Du kannst pruefen, was owntracks schickt, indem du beim MQTT2_SERVER verbose auf 5 stellst, und das Log pruefst.

Eine Option mit MQTT waere zwei MQTT2_SERVER Instanzen zu definieren, eine fuer den externen Zugriff mit Passwort und SSL, und eine fuer den internen Gebrauch, ohne Sicherung. "Bridging" kann mit dem rawEvents Attribut und zwei trivialen notifies (set other_server publish $EVENT) bauen.

[andre07]

Danke werde jetzt erst mal das log prüfen.
Mit dem rawEvents Attribut meinst du
Mqtt2  rawEvents  auf 1 setzen im Server, hab mich schon
gefragt wozu das gut sein soll.
Ich schicke also alles was von owntrack reinkommt
von Server1 zu Server2 und  der versorgt dann meine
Clients.Muss mir dann nur noch überlegen wie ich das
am besten konfiguriere.

Andre

[andre07]

Im log von Fhem findet sich dieses wenn ich versuche per ssl mich zu verbinden

Code Auswählen Erweitern

2020.03.04 10:23:31 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
2020.03.04 10:23:32 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
2020.03.04 10:23:33 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
2020.03.04 10:23:33 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
2020.03.04 10:23:33 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
2020.03.04 10:23:33 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
2020.03.04 10:23:34 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
2020.03.04 10:23:35 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
2020.03.04 10:23:35 1: MQTT2_SERVER SSL/HTTPS error: No such file or directory  (peer: 192.168.178.42)
hier versucht mich local zu verbinden.
Was sucht er da wohl meine Certifikate ? keinen zugriff oder warum schreibt er das.

Andre

[rudolfkoenig]

Klingt so, als ob in /opt/fhem/certs kein Zertfikat liegt. Es braucht zwei Dateien, server-cert.pm und server-key.pm.
Die aktuelle Version von TcpServerUtils.pm versucht mit openssl ein selbstsigniertes Zertifikat anzulegen, falls keins gefunden wurde.

[Otto123]

Ich mache mal einen neuen Template Vorschlag.
ich habe Android - der Funktionsumfang für Android und IOS ist unterschiedlich - deswegen schlage ich zwei Templates vor.
Das erste sozusagen als Basis

Edit Copy&Paste Fehler bereinigt

Code Auswählen Erweitern

name:owntracks_device
desc:A device tracked by OwnTracks, basic Device for support Android and IOS
filter:TYPE=MQTT2_DEVICE:FILTER=CID~owntracks.*
order:O_01
par:TRACKER_ID;TrackerID;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,/([^/]+)/, ? $1 : undef }
par:DEV_ID;DeviceID;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,/[^/]+/([^/:]+), ? $1 : undef }
par:WHICHROOM;Actual room of the device, defaults to OwnTracks; {AttrVal("DEVICE","room","OwnTracks" )}
attr DEVICE room WHICHROOM
attr DEVICE icon location_sign
attr DEVICE devicetopic owntracks/TRACKER_ID/DEV_ID
attr DEVICE jsonMap\
  acc:accuracy alt:altitude batt:batteryPercent lat:latitude lon:longitude vac:accuracyVertical vel:velocity\
  _type:lastUpdateType tst:timestamp tid:trackerId
attr DEVICE readingList\
  $\DEVICETOPIC.* raw\
  $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $\DEVICETOPIC/event:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $\DEVICETOPIC/waypoints:.* { my (%h,$cnt); $EVENT=~ s/(\{[^[]*?})/$h{"waypoint_".++$cnt}=$1/ge; \%h }
attr DEVICE getList\
  location:noArg raw $\DEVICETOPIC/cmd {"_type":"cmd","action":"reportLocation"}\
  waypoints:noArg raw $\DEVICETOPIC/cmd {"_type":"cmd","action":"waypoints"}
attr DEVICE setList  action:textField $\DEVICETOPIC/cmd {"_type":"cmd","action":$EVTPART1}\
  config:textField $\DEVICETOPIC/cmd {"_type":"cmd","action":"setConfiguration","configuration":$EVTPART1}\
  waypoints:textField $\DEVICETOPIC/cmd {"_type":"cmd","action":"setWaypoints","waypoints":{"_type":"waypoints","waypoints":[$EVTPART1]}}\
  mode:Quite,Manual,Significant,Move {my %h=(Quite=>'-1',Manual=>'0',Significant=>'1',Move=>'2');fhem("set $NAME config ".qq({"_type":"configuration","monitoring":$h{$EVTPART1}}))}\
x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //; qq($\DEVICETOPIC/cmd $payload)}
attr DEVICE userReadings\
  location:lat.* {ReadingsNum($name,'latitude',0).','.ReadingsNum($name,'longitude',0)},\
  connection:conn.* {my %h=(m=>'mobil',w=>'wifi',o=>'offline'); return $h{ReadingsVal('MQTT2_owntracks_mi6','conn','error')}},\
  place:event.* {ReadingsVal($name,'event','') eq 'leave'?'away':(ReadingsVal($name,'desc','nowhere'))}
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model owntracks_device
attr DEVICE comment https://owntracks.org/booklet/tech/json/
Das zweite als Erweiterung. Ich lese hier als erstes die bereits existierenden Inhalte von jsonMap readingList und setList aus und ergänze diese. Wenn das mittels - par - so nicht gedacht war und es eine anderen Weg gibt, wäre es schön es zu wissen
Was damit nicht geht, ist vorher bei Bedarf das Basis Template zu setzen. Die par Zeilen werden offenbar immer am Anfang abgearbeitet, egal wo sie wirklich stehen. Aber das ist eben so.

Was ich nicht verstehe ist der filter ich versteh nicht wann der wirkt und wann nicht. Gibt es dazu irgendwo noch eine Erklärung? Ich habe da viel probiert und war hinterher nicht schlau.

Code Auswählen Erweitern

name:owntracks_extend_IOS
desc:Extend the owntracks device for IOS Readings, use owntracks_device first
filter:TYPE=MQTT2_DEVICE:FILTER=model=owntracks_.*
order:O_02
par:JMAP;jsonMap;{my $s=AttrVal("DEVICE","jsonMap","");$s=~s/\n/\\\n/g;return $s}
par:READINGLIST;ReadingList;{my $s=AttrVal("DEVICE","readingList","");$s=~s/\n/\\\n/g;return $s}
par:GETLIST;GetList;{my $s=AttrVal("DEVICE","getList","");$s=~s/\n/\\\n/g;return $s}
attr DEVICE jsonMap JMAP\
  config__type:lastUpdateType event__type:lastUpdateType step__type:lastUpdateType beacon__type:lastUpdateType\
  bs:batteryState p:pressure t:trigger cog:direction\
  event_acc:event_accuracy event_lat:event_latitude event_lon:event_longitude\
  event_t:event_trigger event_tid:event_trackerId event_tst:event_timestamp\
  event_wtst:event_waypointCreationTimestamp\
  step_steps:steps_count step_from:steps_timestampBegin step_to:steps_timestampEnd step_tst:steps_timestampReq\
  beacon_acc:beacon_accuracy beacon_prox:beacon_proximity beacon_tst:beacon_timestampReq
attr DEVICE readingList READINGLIST\
  $\DEVICETOPIC/step:.* { json2nameValue($EVENT,'step_',$JSONMAP) }\
  $\DEVICETOPIC/beacon:.* { json2nameValue($EVENT,'beacon_',$JSONMAP) }\
  $\DEVICETOPIC/dump:.* { json2nameValue($EVENT,'config_',$JSONMAP) }
attr DEVICE getList GETLIST\
  steps:noArg raw $\DEVICETOPIC/cmd {"_type":"cmd","action":"reportSteps"}\
  config:noArg raw $\DEVICETOPIC/cmd {"_type":"cmd","action":"dump"}

Im Gegensatz zum Template von Loredo, schlage ich damit vor: die Waypoints (Standorte) in sich je Standort komplett als json String zu speichern. Genauso wären sie über set waypoint auch zu setzen.
Außerdem ist die Funktion eingebaut, die Betriebsart der App auf dem Smartphone verändern zu können.
Über ein userreading wird die Anwesenheit an einem Standort (Waypoint) gesetzt: place Damit hat man quasi die Anwesenheitserkennung und braucht dazu kein separates Device.
Man müsste das Log noch beeinflussen, das wird schnell groß wenn man nicht eingreift.

Mit dem raw Reading bin ich noch nicht glücklich.

Da das jetzt ein MQTT2 Template Thema wird, sollte ich das in MQTT2 neu anlegen?

[Beta-User]

Das zweite als Erweiterung. Ich lese hier als erstes die bereits existierenden Inhalte von jsonMap readingList und setList aus und ergänze diese. Wenn das mittels - par - so nicht gedacht war und es eine anderen Weg gibt, wäre es schön es zu wissen

..gelobt sei, was funktioniert...

Bedenken habe ich allerdings in die Richtung, dass bestimmt irgendeiner auf die Idee kommt, das mehrfach zu machen .

Was damit nicht geht, ist vorher bei Bedarf das Basis Template zu setzen. Die par Zeilen werden offenbar immer am Anfang abgearbeitet, egal wo sie wirklich stehen. Aber das ist eben so.

Ja, jedes attrTemplate hat seine eigene "Kapsel"

Was ich nicht verstehe ist der filter ich versteh nicht wann der wirkt und wann nicht. Gibt es dazu irgendwo noch eine Erklärung? Ich habe da viel probiert und war hinterher nicht schlau.

Er wirkt "immer". Das ganze hat aber nur Auswirkungen darauf, was du jeweils in der ?-Liste angezeigt bekommst, setzen (via Kommandozeile) geht immer. Wenn es "härter" sein soll, ist "prereq" das Mittel der Wahl, allerdings wird das nur ausgewertet, wenn AttrTemplate_Initialize() aufgerufen wird (typ.: einmalig bei FHEM-Start).
Daher klappt das auch mit den "versteckten" Sprachsteuerungstemplates...

Da das jetzt ein MQTT2 Template Thema wird, sollte ich das in MQTT2 neu anlegen?

...mir ist das egal, ich lese auch hier mit; wer ist denn TE?

Generell fände ich in diesem Fall eine Lösung via RADIO_.* innerhalb eines attrTemplate passender. Der User muss dann auswählen, ob er das für Andoid (=> "kurze Konfiguration") oder IOS (lange) einrichten will, es wird dann eben so oder anders parametriert.
Kurz gesucht: auch in mqtt2.template gibt es was, das ggf. für einen nicht-ZWave-User einfacher zu verstehen ist: shelly1_w_energy_measuring. Da wird halt je nach Wahl des Users ein userReadings-Eintrag gemacht oder nicht. "option" ist eine Art "if"-Steuerung, "option:global" beendet den Modus.

Mit dem raw Reading bin ich noch nicht glücklich.

Habe noch keine Idee, ob das besser ist, aber man könnte genausogut das erwünschte Hauptreading (z.B. waypoint_1 (?))in getList schreiben und auf raw verzichten (falls man es nicht für was anderes braucht). Kommt auch darauf an, was der "Schmerz" ist (mit dem Vorschlag würde z.B. halt in FHEMWEB nur der erste zurückgemeldet, statt das komplette Array).

Eines ist mir noch aufgefallen:

Code Auswählen Erweitern

connection:conn.* {my %h=(m=>'mobil',w=>'wifi',o=>'offline'); return $h{ReadingsVal('MQTT2_owntracks_mi6','conn','error')}}
Müßte das nicht sein:

Code Auswählen Erweitern

connection:conn.* {my %h=(m=>'mobil',w=>'wifi',o=>'offline',e=>'unknown'); return $h{ReadingsVal('MQTT2_owntracks_mi6','conn','e')}}

[Otto123]

Deine Lösung zum Userreading ist besser! bau die bitte ein.

Den Rest schau ich mir noch in Ruhe an. Vor allem RADIO
Aber ich war jetzt stolz auf die "Extension", die schwebt schon seit dem Sonos Thema in meinem Kopf

Bedenken habe ich allerdings in die Richtung, dass bestimmt irgendeiner auf die Idee kommt, das mehrfach zu machen .

Sind alle Templates gegen Missverständliche Anwendung geschützt?  Aber ich habe da schon eine Idee

[Beta-User]

Den Rest schau ich mir noch in Ruhe an. Vor allem RADIO

Kein Ding, und keine Eile!

Aber ich war jetzt stolz auf die "Extension", die schwebt schon seit dem Sonos Thema in meinem Kopf

Die ist auch prinzipiell ok (zumindest, soweit ich das ungetesten beurteilen kann, oft steckt der Teufel ja im Detail...).

Aber du glaubst gar nicht, wie viele - im Prinzip funktionierende - Lösungen ich jetzt über die Zeit, in der ich an dem ganzen rumbastle, dann auch wieder verworfen oder radikal geändet habe...?
Aber erst mal was umsetzen, bis es funktioniert, wenn man es schon im Kopf hat, ist auf alle Fälle eine gute Vorgehensweise. Nur dann sieht man die Vor- und Nachteile ggf. wirklich.

Sind alle Templates gegen Missverständliche Anwendung geschützt? 

Nö. Aber "am Anfang" glaubt man noch, irgendwer würde die Beschreibung lesen oder auch nur rudimentär mitdenken. Gibt sich irgendwann...
Im Ernst: Was falsch gemacht werden kann, wird irgendwann falsch gemacht!

[Otto123]

Ich hatte oben im Template irgendwie einen Copy & Paste Fehler.
tut mir leid 
Anbei ein Patch

[Beta-User]

...ist drin .

[Otto123]

Danke, das sieht jetzt erstmal gut aus, ich habe alles nochmal geprüft.
Und einen Wikieintrag gemacht: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Owntracks_GPS_Tracking_in_FHEM

Ich feile noch an der Anwesenheitserkennung, die jetzt eingebaute Verwendung der Events von Owntracks ist nicht so ganz Fehlertolerant. Ich teste bei mir eine Alternative im userReadings:

Code Auswählen Erweitern

place1:lastUpdateType:.location {ReadingsAge($name,'inregions_1',0) > 2 ?'away':(ReadingsVal($name,'inregions_1','nowhere'))}
Hier wird das location Update ausgewertet. Falls jemand dazu Ideen hat
Für die weitere Auswertung gibt es wieder viele Möglichkeiten, ich nehme derzeit ein PRESENCE Device im event Modus - der war für mich neu und ich wollte es mal probieren

Code Auswählen Erweitern

defmod OT_Mi6 PRESENCE event MQTT2_owntracks_mi6:place1:.away MQTT2_owntracks_mi6:place1:.zuHause
attr OT_Mi6 event-on-change-reading .*
attr OT_Mi6 room Status


[TomLee]

Hallo Otto,

seit gestern beschäftigt mich irgendwie die Frage ob ich nicht nur auf Owntracks setzen soll was die Anwesenheit zu Hause betrifft, ich meine das klappt bisher sehr gut und halt zeitiger wie die Rückmeldungen aus FRITZBOX und Unifi.

Jetzt les ich gerade nochmal den letzten Beitrag, warum hast du damals überhaupt ein zusätzliches PRESENCE-Device genutzt ?

Was spricht gegen einfach nur ein userReading ?

Code Auswählen Erweitern

presence:lastUpdateType:.location {ReadingsAge($name,'inregions_1',0) > 2 ?'absent':'present'}

Hast du mittlerweile vlt. sogar noch eine andere Variante am laufen ?

Ich will auf jedenfall ein presence-Reading für ein ROOMMATE-Device und sparen natürlich auch, nicht nur hier das PRESENCE-Device, ich würd dann, wenn sie wirklich ersetzbar sind, auch auf die bisherigen FRITZBOX und Unifi-PRESENCE-Devices verzichten in Zukunft, so meine Gedanken zur Zeit, kann gut sein ich übersehe auch noch was  .

[Otto123]

Hallo Thomas,

es läuft bei mir alle noch so wie im letzten Beitrag und auch immer noch so "nebenher". Das presence Device hatte keinen besonderen Grund, ich habe halt alle solchen presence Dinge in presence Devices
Sicher geht das auch in einem userReadings, Roommate habe ich nicht.
Ich bin seit einiger Zeit am Überlegen eine andere App zu testen, bin aber noch nicht dazu gekommen. owntracks hängt auf meinem Smartfone ab und an, dann muss ich es abschießen.
Die BT Erkennung läuft bei mir zu gut, da gibt es keinen Druck etwas zu ändern.

Gruß Otto

[TomLee]

Hi, kurz, ist mir eben nebenbei so aufgefallen:

4804     connection:conn.* {my %h=(m=>'mobil',w=>'wifi',o=>'offline',e=>'unknown'); return $h{ReadingsVal('MQTT2_owntracks_mi6','conn','e')}},\

[Otto123]

So ein Mist 
Danke, habe es gefixed und eingecheckt

[Sailor]

Ein herzerfrischendes "Moin" vom achtern Diek vorweg.

Ich möchte nochmal auf auf die Verwendung von SSL beim MQTT2_SERVER sowie bei aktiviertem TLS seitens owntracks kommen.

Ich habe fhem - seitig die Zertifikate wie folgt erstellt:
https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle
Diese dann in fhem eingebunden => FHEMWEB funktioniert schon mal mit diesem neuen Zertifikat.

Daraufhin habe ich den MQTT2_SERVER zunächst nur mit allowed abgesichert und dort ein Username & Passwort vergeben.
Die Verbindung kommt zustande und die Daten werden erfolgreich übermittelt.

Anschliessend aktiviere ich auf seiten des MQTT2_SERVER das Attribut SSL sowie in der owntrack-APP den TLS Balken.

Leider bekomme ich dann sofort die folgende Fehlermeldung (verbose = 5):

Code Auswählen Erweitern


2022.11.18 20:54:54.324 3: Login denied via MQTTBroker_extern
2022.11.18 20:54:54.446 5: MQTT2_SERVER SSL/HTTPS error:  SSL accept attempt failed error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown (peer: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx)


Ich habe auch versucht das oben erstellte CA - Zertifikat in der owntracks-APP einzubinden.

Das Resultat ist das gleiche.

Die Konfiguration (list) meiner Devices findet Ihr übrigens hier:
https://forum.fhem.de/index.php/topic,37412.msg1246208.html#msg1246208

Wenn Jemand die Erfahrung gemacht hat, wie ich die SSL / TLS Verbindung zwischen dem MQTT2_SERVER und der owntracks - APP zum Laufen bekomme, dann bin ich für jeden Hinweis dankbar.

Gruß
    Sailor

[Otto123]

Hi,

hast Du alle Attribute gesetzt? https://fhem.de/commandref_modular.html#MQTT2_SERVER

sslCertPrefix
Set the prefix for the SSL certificate, default is certs/server-, see also the SSL attribute.

Gruß Otto

[Jamo]

Hi Sailor, in der Owntracks app auf dem iPhone, in den Einstellungen rechts neben dem TLS Schiebeschalter ist das runde blaue i, wenn du da draufklicks kommt ein Menue, wo man "Allo Untrusted Certificates" auswaehlen kann. Kannst Du das mal probieren?
Gruss, Jamo

[rudolfkoenig]

Falls MQTT2_SERVER (oder FHEMWEB) kein Zertifikat findet, dann versucht er ein self-signed Zertifikat mit openssl zu erzeugen.

Ansonsten wenn ich die Ergebnisse der Internet-Suche verstehe (und da bin ich nicht sicher), bedeutet die Fehlermeldung dass das Zertifkat des Clients nicht akzeptiert wird. Auch wenn SSL_verify_mode nicht gesetzt wird, und damit SSL_VERIFY_NONE ist, gibt es angeblich Faelle, wo ein Client Zertifikat diese Meldung beim Server erzeugt.

Nachtrag: der Vorschlag von @Jamo klingt logischer. In diesem Fall wuerde der Client dem Server diese Meldung mitteilen. Ich wuenschte mir, dass die openssl Meldungen verstaendlicher waeren.

[Sailor]

Hallo Otto

hast Du alle Attribute gesetzt? https://fhem.de/commandref_modular.html#MQTT2_SERVER

da wären aus meinem Verstaendnis nur "SSL" auf "1".
Das Attribut "sslCertPrefix" ist mit dem Default "certs/server-" schon korrekt.
Habe ich jetzt aber dennoch gesetzt.

Leider ohne Erfolg.

Gruß
    Sailor

[Sailor]

Hallo Jamo

in der Owntracks app auf dem iPhone, in den Einstellungen rechts neben dem TLS Schiebeschalter ist das runde blaue i, wenn du da draufklicks kommt ein Menue, wo man "Allo Untrusted Certificates" auswaehlen kann. Kannst Du das mal probieren?

Leider nicht, weil ich da kein "i" habe.
Oder ich bin im falschen Menü gelandet?

Ich habe owntracks Version 2.4.10 (20410051) auf Android

Gruß
    Sailor

[Sailor]

Hallo Rudi

Nachtrag: der Vorschlag von @Jamo klingt logischer. In diesem Fall wuerde der Client dem Server diese Meldung mitteilen. Ich wuenschte mir, dass die openssl Meldungen verstaendlicher waeren.

Aha, das bedeutet also, dass diese Fehlermeldung nicht vom MQTT_SERVER stammt sondern von der APP, welche dann zurück gesendet wurde.
Das ergibt irgendwie Sinn.

Eine wie auch immer geartete Lösung müsste demnach auf der APP anzuwenden sein.
Nur welche... 

Frage @Jamo: Kannst du mir den genauen Eintrag aus deinem Config-File der APP übermitteln, damit ich ihn händisch einfügen kann?
Die findest du unter "Konfigurationseinstellungen".
Der Eintrag muss ja irgendwie das Schlüsselwort "Untrusted" und "allow" enthalten.

Danke!

Gruß
    Sailor

[Otto123]

Moin,

hast Du das Zertifikat in der App richtig implementiert?
https://owntracks.org/booklet/features/tlscert/

Gruß Otto

[Jamo]

Hallo Sailor,
ok Du hast Die Android App, ich habe ja ein iPhone / iOS, wie geschrieben. Hier der Screenshot von den Settings aus der iPhone config.otrc, ich weiss aber nicht ob das bei Android equivalent ist.

[Sailor]

Hallo Sailor,
Hier der Screenshot von den Settings aus der config.otrc, ich weiss aber nicht ob das bei Android equivalent ist.

Leider ein Fehlschlag.
Die App ist so schlau diesen als ungültigen Eintrag zu erkennen.

Gruß
    Sailor

[Sailor]

Hallo Otto

hast Du das Zertifikat in der App richtig implementiert?
https://owntracks.org/booklet/features/tlscert/

Habe ich jetzt mal ganz genau so gemacht aber ich weiß nicht, wie ich dem MQTT_Server mitteile, diese Zertifikate auch zu verwenden.
Immerhin haben diese andere Endungen (.crt und .key anstatt -key.pem und -cert.pem) und somit haut das mit dem sslCertPrefix nicht hin.

Mir raucht der Kopf. Aber aufgeben ist nicht.

Gruß
    Sailor

[Otto123]

Hi,

ich bin noch nicht dazu gekommen das auch mal zu probieren, aber ich habe mal verstanden:
pkcs12 ist ein transportables Containerformat. Das will die owntracks App?
Man kann das Format aus cer und key Dateien erzeugen oder auch pkcs12 in key und cer wandeln.
Sieh mal hier habe ich sowas mal gemacht: https://forum.fhem.de/index.php/topic,111959.0.html

Mein Ansatz wäre: Die Dateien die der MQTT2 Server verwendet bzw. selbst erzeugt in pkcs12 wandeln und dann in die owntracks App importieren?

Gruß Otto

[Sailor]

Hall Otto

ich bin noch nicht dazu gekommen das auch mal zu probieren, aber ich habe mal verstanden:
pkcs12 ist ein transportables Containerformat. Das will die owntracks App?
Man kann das Format aus cer und key Dateien erzeugen oder auch pkcs12 in key und cer wandeln.
Sieh mal hier habe ich sowas mal gemacht: https://forum.fhem.de/index.php/topic,111959.0.html
Mein Ansatz wäre: Die Dateien die der MQTT2 Server verwendet bzw. selbst erzeugt in pkcs12 wandeln und dann in die owntracks App importieren?

Die Zertifikate habe ich mittels
https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle
erzeugt und wie hier beschrieben https://wiki.fhem.de/wiki/Raspberry_Pi_%26_HTTPS in fhem eingebunden.

Der https:// - FHEMWEB - Zugang des fhem-Servers funktioniert darueber.

Anschliessend mit

Code Auswählen Erweitern


sudo openssl pkcs12 -export -out server-cert.p12 -inkey server-key.pem -in server-cert.pem
sudo openssl x509 -outform der -in cacert.pem -out cacert.crt

das .p12 und .crt erzeugt und in owntracks eingebunden.
Fhem Server neu gestartet und leider immer noch ein

Code Auswählen Erweitern


2022.11.19 16:10:34.332 3: Login denied via MQTTBroker_extern
2022.11.19 16:10:34.432 5: MQTT2_SERVER SSL/HTTPS error:  SSL accept attempt failed error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown (peer: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx)




Gruß
    Sailor

[Otto123]

Sorry ich war ein wenig auf dem Holzweg.
Ich habe mal mit dem Tool getestet: http://mqtt-explorer.com/
in FHEM habe ich einfach einen Server definiert

Code Auswählen Erweitern

defmod mqtt2ssl MQTT2_SERVER 8883 global
attr mqtt2ssl SSL 1
Der nimmt die key und cert aus dem Pfad certs.
1. Versuch
mit mqtt explorer die Verbindung getestet - Verbindung funktioniert erst wenn validate certificate ausgeschaltet (war zu erwarten)
2. Versuch
Die Datei certs/server-cert.pem habe ich mir ins Windows geholt

Code Auswählen Erweitern

scp pi@192.168.56.187:/opt/fhem/certs/server-cert.pem .
Dann im mqtt explorer unter advanced / certificates / server certificate  eingelesen. (Die Stelle sieht exakt so aus wie bei owntracks)
Im Hauptfenster validate certificate angelassen.
Verbindung funktioniert.

Die nächste Möglichkeit wäre noch Clientcertificate - aber das wolltest Du ja erstmal gar nicht.

[Sailor]

Hallo Otto

Sorry ich war ein wenig auf dem Holzweg.
Ich habe mal mit dem Tool getestet: http://mqtt-explorer.com/
in FHEM habe ich einfach einen Server definiert

Code Auswählen Erweitern

defmod mqtt2ssl MQTT2_SERVER 8883 global
attr mqtt2ssl SSL 1
Der nimmt die key und cert aus dem Pfad certs.
1. Versuch
mit mqtt explorer die Verbindung getestet - Verbindung funktioniert erst wenn validate certificate ausgeschaltet (war zu erwarten)

Was ist bei dir der MQTT - Explorer? Habe ich was vergessen einzurichten?
Wo hast du das "validate certificate" ausgeschaltet?

2. Versuch
Die Datei certs/server-cert.pem habe ich mir ins Windows geholt

Code Auswählen Erweitern

scp pi@192.168.56.187:/opt/fhem/certs/server-cert.pem .
Dann im mqtt explorer unter advanced / certificates / server certificate  eingelesen. (Die Stelle sieht exakt so aus wie bei owntracks)
Im Hauptfenster validate certificate angelassen.
Verbindung funktioniert.

Das lässt doch hoffen!

Die nächste Möglichkeit wäre noch Clientcertificate - aber das wolltest Du ja erstmal gar nicht.

Hab ich das gesagt?   
Also ich nehme jede Loesung! Haupsache die Verbindung ist abgesichert und kann nicht belauscht werden.

[Nachtrag]
Frage nach dem MQTT-Explorer hat sich erledigt. Scheint eine gute Software zum finden von Fehlern und Daten zu sein.

Ich frage mich langsam, ob es nicht besser ist, auf dem gleichen Server wo fhem läuft, noch einen MOSQUITTO - Server laufen zu lassen.
Wollte ich eigentlich vermeiden wenn es sich über fhem realisieren lässt, aber zumindest eine Alternative.
So wie ich das gelesen habe, kann man dann zwischen fhem und dem MOSQUITTO - Server eine Bruecke schlagen.

Gruß
    Sailor

[OdfFhem]

So wie ich das gelesen habe, kann man dann zwischen fhem und dem MOSQUITTO - Server eine Bruecke schlagen.

In dem Fall käme MQTT2_CLIENT zum Einsatz ...

[Otto123]

Moin,

das mit dem mosquitto würde ich nicht machen. Aus meiner Sicht bringt das keinen Sicherheitsgewinn. Ein mqtt Server separat von deinem Netz im Internet, das wäre sinnvoll.
Wenn sich Server und Client über ssl unterhalten ist es erstmal sicher. Client Zertifikat wäre eine zusätzliche Autorisierung.
Zu dem Thema gibt es diesen alten Beitrag https://forum.fhem.de/index.php?topic=27171.0
Der dort erwähnte Reverse-Proxy wäre auf alle Fälle empfehlenswert und ein echter Sicherheitsgewinn!

Gruß Otto

[Sailor]

Hallo Otto

Danke Dir und auch Rudi , Jamo und Odf für das "am Ball bleiben"!

das mit dem mosquitto würde ich nicht machen. Aus meiner Sicht bringt das keinen Sicherheitsgewinn.

Bedeutet dies, dass der lokale MOSQUITTO auch keine SSL Verbindung mit owntracks herstellen kann?

Ein mqtt Server separat von deinem Netz im Internet, das wäre sinnvoll.

Du schlägst also einen Cloud-Dienst wie beispielsweise diesen hier vor?
https://www.hivemq.com/mqtt-cloud-broker/

Eigentlich möchte ich auf Cloud-Dienste verzichten.
Meiner Erfahrung nach ist nach einer Weile Schluss mit kostenlosem Service und dann stehe ich wieder am Anfang.
Davon hatte ich in der Vergangenheit nun wirklich genug.
Einzige Alternative: Ein eigener Prozess bei meinem Webhoster IONOS. Wenn es das denn gaebe...

Wenn sich Server und Client über ssl unterhalten ist es erstmal sicher. Client Zertifikat wäre eine zusätzliche Autorisierung.

Genau das hatte ich ja gehofft mit dem MQTT - Server herstellen zu koennen.
Meine nächste Hoffnung war, dies mit mit dem MOSQUITTO - Server auf dem gleichen Raspi herstellen zu können.
Meinen Recherchen zur Folge gibt es hierzu (owntracks <-> MOSQUITTO)  ja bereits Erfolge.

Zu dem Thema gibt es diesen alten Beitrag https://forum.fhem.de/index.php?topic=27171.0
Der dort erwähnte Reverse-Proxy wäre auf alle Fälle empfehlenswert und ein echter Sicherheitsgewinn!

Auhauerha. Jetzt komme ich von den Hunderten in die Tausende... 

Mein Ziel ist Authorisierung (Klappt schon mit MQTT_SERVER in Kombination mit allowed.)
sowie Abhörsicherheit via SSL/TLS.

Sicherlich könnte ein Reverse-Proxy den Stand der Sicherheit noch erhöhen - Allerdings habe ich noch nicht verstanden in welchen Punkten.

Wie aufwendig ist es überhaupt noch einen Reverse-Proxy auf dem gleichen Raspi zu installieren?
Und ergibt dies überhaupt Sinn - Sollten diese nicht von der Hardware getrennt sein um Sinn zu ergeben?
Ich möchte nämlich vermeiden, eine ganze Server-Farm an Raspis in der Wohnung herumliegen zu haben. 

Schritt für Schritt.

Gruß
    Sailor

PS: Sobald wir das hier zum Laufen bekommen haben, schreibe ich einen Wiki - Eintrag. Das kann ja nicht nur mir so ergehen!

[Otto123]

Hallo Sailor,

irgendwie redest Du jetzt um den heißen Brei

Also jetzt mein dritter Versuch:
Mein Tablet geschnappt owntracks drauf installiert.
MQTT eingerichtet:
Hostname 192.168.56.187  (der wo ich gestern den MQTT2 Server mit SSL definiert habe
Port 8883
Client ID gid
Identifikation 
Geräte ID gid
Tracker ID ti
Sicherheit TLS aktiviert
CA Zertifikat server-cert.pem importiert

Fertig und schwups hatte ich ein owntracks MQTT2 Device

Also was gestern mit dem MQTT Explorer funktioniert hat und ich vermutet habe "sieht genauso aus" - funktioniert auch mit owntracks.

Eigentlich ganz easy

Gruß Otto

[Sailor]

Blutige Hölle ich hab es endlich hinbekommen!

Es war in der Tat ganz einfach, wenn man es denn konsequent richtig macht!

Die Lösung lag in der Kombination von:
[1]https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle
insbesondere in dem Absatz in:
[2]https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle#Bekannte_Probleme
sowie unter Zuhilfenahme von:
[3]https://forum.fhem.de/index.php/topic,97177.msg909085.html#msg909085
als auch
[4]https://mkyong.com/linux/ssl-convert-pem-and-private-key-to-pkcs12/

Mit kurzen Worten
Die Zertifikate müssen unbedingt mit "Subject Alternative Names (SAN)" versehen werden die dem Internet-Namen entsprechen, ansonsten fliegt einem das mit den bekannten Fehlermeldung um die Ohren.
Ich habe also die unter [1] beschriebene Datei "oats.extensions.cnf" wie folgt codiert:

Code Auswählen Erweitern


basicConstraints=CA:FALSE
subjectAltName=@my_subject_alt_names
subjectKeyIdentifier = hash

[ my_subject_alt_names ]
DNS.1 = localhost
DNS.2 = localhost.local
DNS.3 = localhost.fritz.box

DNS.4 = HomeServer
DNS.5 = HomeServer.local
DNS.6 = HomeServer.fritz.box

# Address of your dynamic DNS subdomain
DNS.7 = homeserver.domain.de

# IPv4 local host
IP.1  = 127.0.0.1

# your local IPv4 address of your fhem Server
IP.2  = 192.168.178.200

# local network IPv6 address of your fhem Server
IP.3  = fe80::dea1:dea2:dea3:dead

# local IPv6 address of your fhem Server without network prefix
IP.4  = ::dea1:dea2:dea3:dead


Damit habe ich anschließend die servercert.pem und serverkey.pem erstellt bzw. in  server-cert.pem und server-key.pem umbenannt, damit das auch mit dem sslCertPrefix funktioniert.

Abschließend habe ich aus server-cert.pem und server-key.pem mittels der Anleitung unter [4] das entsprechende server-cert.p12 erstellt.
Achtung! Hierbei unbedingt ein Passwort vergeben, da owntracks keine .p12 - Zertifikate ohne Passwort aktzeptiert - und zwar ohne eine Fehlermeldung zu erstellen. 

Die unter [1] erstellte Datei cacert.pem und die server-cert.p12 habe ich anschließend in owntracks eingebunden und et - voila - Es funzt!

Boah ey - Wat fuern aufriss!

Gruß
    Sailor

[Sailor]

Ein herzerfrischendes "Moin" vom achtern Diek vorweg.

Wie versprochen, die erweiterten Wiki Einträge:

https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Owntracks_GPS_Tracking_in_FHEM_direkt_an_den_eigenen_Fhem-Server

Dieser Wiki - Eintrag verweist auf den ebenfalls erweiterten Wiki - Eintrag
https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle#Schl.C3.BCsselcontainer_erstellen

Mögt Ihr bitte kurz drauf schauen und prüfen, ob ich mir irgendwelche dummen Schnitzer geleistet habe?

Die fhem-Gemeinde wird es Euch danken. 

Gruß
    Sailor