[boschindego] Plot location on map

[jlaur]

Location is now plotted on the received map:

Location is received as coordinates on the map with the state response, which is the most frequent and least expensive call. With default configuration coordinates are therefore received every three minutes.

The map itself is now only requested:

• On binding initialization.
• Once per day.
• After detecting that mower is no longer in "learning lawn" state.

As a result we now have more usable data (current location plotted on map) with fewer calls.

Configuration parameter cuttingTimeMapRefresh has been renamed back to cuttingTimeRefresh as it no longer has any influence on map refresh. This is a change to #13040 which is also for 3.4.

Completes #13017

[jlaur]

Back to draft until I have performed field tests. I just noticed in logs while mowing today:

  "state" : 513,
  "enabled" : true,
  "map_update_available" : true,
  [...]
  "mapsvgcache_ts" : 1658822457148,
  "svg_xPos" : 408,
  "svg_yPos" : 680,

It was running for almost an hour, and constantly having map_update_available set to true while having no changes in svg coordinates. The map itself doesn't change during a normal run, but the position (coordinates) should. So now I'm wondering if the service expects a map request for the session context in order to update the coordinates also. It doesn't make much sense, since this payload seems quite unneeded, but I have to verify how it works (with the app alongside) and fully understand this logic.

One explanation might be that the coordinates are of course useless without the correct map. So this might be server logic simplifying the logic in the app which could simply load the map when requested to do so, and then also start receiving corresponding coordinates hereafter.

[jlaur]

Today I was able to confirm that a new map must be requested when map_update_available is true in state response. However, I also learned that only when entering the map activity in the app, the coordinates start to get updated, and it even says "Indego position updates are active" and "Indego position is updated every 5-6 seconds". I don't know the API call for activating that mode, but once the app has done this, the binding also starts receiving continuously updated coordinates.

[jlaur]

Ready for review. There might be more iterations, at least I hope so, as I learn more, but currently I'm blocked by the API not being documented (and hard to intercept as communication is HTTPS).

Still, although the location is not always updated "live", having the position plotted on the map is still better than just having the raw map, and the optimizations of the request handling is also a step in the right direction.

[jlaur]

Update: Today I decompiled the Android APK and found a class with this list of methods:

static {
    I0 = new x("GET_PUBLIC_ALM_INFO", 14);
    J0 = new d0("GET_STATE", 15);
    K0 = new h1("PUT_STATE", 16);
    L0 = new s("GET_MAP", 17);
    M0 = new n0("POST_MAP", 18);
    N0 = new n("GET_CALENDAR", 19);
    O0 = new w0("PUT_CALENDAR", 20);
    P0 = new y("GET_SECURITY", 21);
    Q0 = new e1("PUT_SECURITY", 22);
    R0 = new y0("PUT_DATE_TIME", 23);
    S0 = new u0("PUT_AUTO_UPDATE", 24);
    T0 = new m("GET_AUTO_UPDATE", 25);
    U0 = new p0("POST_REQUEST_POSITION", 26);
    V0 = new w("GET_OPERATING_DATA", 27);
    W0 = new g0("GET_UPDATES", 28);
    X0 = new i1("PUT_UPDATES", 29);
    Y0 = new b1("PUT_NOTIFICATION_UPDATES", 30);
    Z0 = new f0("GET_SUPPORT", 31);
    a1 = new h("GET_ACCESSORIES", 32);
    b1 = new i("GET_ACCESSORIES_RETAILERS", 33);
    c1 = new j("GET_ALERTS", 34);
    d1 = new s0("PUT_ALERT_READ", 35);
    e1 = new a("DEL_ALERT", 36);
    f1 = new t0("PUT_ALL_ALERTS_READ", 37);
    g1 = new b("DEL_ALL_ALERTS", 38);
    h1 = new e("DEL_MULTIPLE_ALERTS", 39);
    i1 = new e0("GET_STATIC_RESOURCE", 40);
    j1 = new i0("GET_VIDEO", 41);
    k1 = new o("GET_CELLULAR_LOCATION", 42);
    l1 = new q("GET_GARDEN_LOCATION", 43);
    m1 = new z0("PUT_GARDEN_LOCATION", 44);
    n1 = new f1("PUT_SMART_ENABLED", 45);
    o1 = new v("GET_NEXT_CUTTING", 46);
    p1 = new r("GET_LAST_CUTTING", 47);
    q1 = new j0("GET_WEATHER", 48);
    r1 = new a0("GET_SMART_ENABLED", 49);
    s1 = new d1("PUT_RESET_SMART_MODEL", 50);
    t1 = new c1("PUT_REINITIALIZE_SMART", 51);
    u1 = new d("DEL_MAP", 52);
    v1 = new z("GET_SETUP", 53);
    w1 = new p("GET_CONFIG", 54);
    x1 = new x0("PUT_CONFIG", 55);
    y1 = new u("GET_NETWORK", 56);
    z1 = new c0("GET_SMART_SETUP", 57);
    A1 = new g1("PUT_SMART_SETUP", 58);
    B1 = new b0("GET_SMART_SCHEDULE", 59);
    C1 = new v0("PUT_BORDER_CUT", 60);
    D1 = new l0("POST_AUTH_BOSCHID", 61);
    E1 = b();
  } 

POST_REQUEST_POSITION seemed interesting, knowing that the app is able to activate almost real-time position updates:

    public String d(String... param1VarArgs) {
      a32.e(param1VarArgs, "urlComponents");
      StringBuilder stringBuilder = new StringBuilder();
      stringBuilder.append("/api/v1/alms/");
      stringBuilder.append(param1VarArgs[0]);
      stringBuilder.append("/requestPosition");
      return stringBuilder.toString();
    }
  }

So I tried making a POST request for POST /api/v1/alms/xxxxxxxx/requestPosition, and it failed. I then googled "requestposition indego" and found this: https://github.com/Andrek01/indego4shng/blob/f29a7c9f5414d9c999713abc006542e46eeae5bb/__init__.py#L1986

Using the same parameters I was able to succeed with this request:
POST /api/v1/alms/xxxxxxx/requestPosition?count=10&interval=6

Sadly I will not be able to verify results before Friday, but I suspect this could be the API call used by the app to trigger the frequent position updates while looking at the map.

In the meantime I'm working on some API call reductions as I reached out to the boschindego adapter for ioBroker author today and learned that the operatingData call (introduced in #12938) wakes up the robot and turns on the display. I checked just now and observed the display on my robot being on for about 10 minutes after this call. This can be quite annoying since it's currently being called every three minutes (with default settings). I'm currently testing a solution for that where frequent updates are only performed while the robot is actively running or charging. I would prefer to deliver these optimizations in a separate pull request after this one has been merged. Only after that I plan to implement requesting of positions, since I prefer to limit the number of requests before adding a new one.

In other words: Please review this pull request as is, and I will be able to proceed with many more improvements. :-)

[jlaur]

Created #13182 for the next steps, which should also explain why it should be kept separate from this PR.

[lolodomo]

Just one comment about the i18n file.

[lolodomo]

LGTM

[jlaur]

@lolodomo - thanks for quick review.

[jlaur]

Sadly I will not be able to verify results before Friday, but I suspect this could be the API call used by the app to trigger the frequent position updates while looking at the map.

Now confirmed, follow #13182 (comment).