eins der wenigen geräte denen ich erlaube sich in die cloud zu verbinden (nach hause zu telefonieren) ist unser reinigungsroboter markus. damit bekommt man nach jeder „mission“ eine karte in der irobot-app serviert. lokale karten oder sogar „live-maps“ sind über die homeassistant roomba komponente, bzw. die python-bibliothek von nick waterton auch möglich, aber ziemlich resourcen-fressend. der server auf dem die roomba-bibliothek ausgeführt wird, muss ständig ein bild generieren, was bei meinen letzten versuchen zu einer stetigen server-auslastung von 80 prozent geführt hat. das ist nicht wirklich praktikabel.

weil die bibliothek aber die koordinaten des roomba ständig erfasst, dachte ich diese koordinaten könnte man doch auch vielleicht meiner seit jahren auf dem server laufenden owntracks-recorder-instanz übergeben. owntracks läuft immer im hintergrund auf meinem (und dem beifahrerinnen) handy und erfasst unsere position. das nutze ich vor allem für die anwesenheitserkennung der automatischen wohnung. wenn wir beide weg sind, gehen alle lichter aus, die heizung fährt runter und eine kamera, die die balkontür erfasst, schaltet sich ein. mit dem recorder kann man unsere positionsdaten permanent, lokal, speichern. so sieht das für meine positionsdaten der letzten zwei jahre aus:

für meine berlin-daten eignet sich das tool ganz gut, um die schwarzen flecken zu finden, in denen ich mal die stadt kennenlernen könnte oder spazieren gehen könnte.

für ausflüge in fremde städte eignet sich das tool ganz gut, um zu sehen, wo man überall war — und wo nicht.

und warum sollte ich das tool nicht auch benutzen, um die fahrten des putzroboters zu erfassen? die roomba komponnete/bibliothek gibt koordinaten aus, die sich immer relativ zum startpunkt befinden, in millimetern, positiv oder negativ zum startpunkt (oder zur ladestation). die relativen roomba-koordinaten lassen sich relativ leicht in geokoordinaten umrechnen. owntracks erwartet mindestens werte für lon und lat, nimmt aber auch die orientierung dankend an, die der roomba auch liefert. wenn die koordinaten in sensordaten vorhanden sind, kann ich eine automation bauen, die diese daten umrechnet und an den owntracks recorder schickt:


      - service: mqtt.publish
        data_template:
          topic: "owntracks/ix/roomba"
          payload: >-
              {% set dx = states.sensor.roomba_x.state|int %}
              {% set dy = states.sensor.roomba_y.state|int %}
              {% set cog = states.sensor.roomba_theta|int %}
              {% set home_lat = 52.550506591796875 %}
              {% set home_lon = 13.346857977076406 %}
              {% set earth_r_mm = 6378000000 %}
              {% set earth_r_mm = 6378 %}
              {% set lat = (home_lat + (dy/earth_r_mm) * (180 / pi)) %}
              {% set lon = (home_lon + (dx/earth_r_mm) * (180 / pi) / cos(home_lat * pi/180)) %}
              {% set tst = as_timestamp(now()) %}
              {"lon":{{lon}},"lat":{{lat}},"cog": {{cog}},"acc":0.001,"conn":"w","tst":{{tst}},"_type":"location","tid":"roomba"}


(kleines technisches problem: die homeassistant komponente aktualisiert die koordinaten nur alle 20 sekunden. weil die bibliothek von nick waterton aber auch die roomba-daten kontinuierlich per mqtt versenden kann — und da alle 1-2 sekunden aktualisiert — greifen die koordinaten-sensoren die daten dort ab.)

nehme ich die variable, die den radius der erde speichert (earth_r_mm) mit einen millimeter-wert, bekäme ich im recorder eine korrekt skalierte bewegungskarte. ich fand den kilometerwert aber anschaulicher, mit dem aus den roomba millimeter-werten kilometer werden. dann sieht eine „spot-reinigung“ des roomba in owntracks so aus:

normale reinigungsvorgänge sollten dann von schweden, über polen bis nach bayern reichen. das beste ist aber, dass hier zwar sehr viele daten anfallen, aber, soweit ich sehe, passiert das äusserst resourcenschonend — und zur not lässt sich die datenübertragung zum owntracks recorder auch deaktivieren.

* * *

ok, das schlafzimmer reicht nicht ganz bis schweden. aber bis dänemark.

* * *

ups, gerade gemerkt, das bild hatte die falsche zeiteinstellung. markus ist natürlich viel gründlicher, als es auf dem vorherigen bild scheint.