jlaur
commented
2 years ago I have now been able to verify that this request indeed does start position tracking:
POST /api/v1/alms/xxxxxxx/requestPosition?count=10&interval=6
Also, longpoll mentioned above has been confirmed to work in the way that it doesn't return until state has changed. When it does, the response is a bit differently structured than usual:
{
"state": 258,
"map_update_available": false,
"charge": 24,
"operate": 30,
"mapsvgcache_ts": 1659036798849,
"svg_xPos": 408,
"svg_yPos": 680
}
BillGOH
In order to:
it would be beneficial to:
As an example, operating data is of most interest when the device is working or charging. Additionally, when this data is requested, the display on the device will turn on, i.e. the device will be woken up. On the other hand, only by performing this call will we actually reach the device, so if we would avoid calling it for several days, the device could have been stolen, and it would still appear online.
The state request:
GET https://api.indego.iot.bosch-si.com/api/v1/alms/xxxxxxxx/statehas some parameters that might be of use:
The longpoll is particularly interesting as this could be a way to get faster updates with fewer calls, i.e. a kind of push mechanism. If this would be implemented as asynchronous HTTP calls using Jetty, that might be a significant improvement.
13158 recently improved update of next planned cutting time, but this could be further improved by separating last and next cutting times. This way one of the two calls could be eliminated in some cases. For example, when time of next planned cutting is hit, next planned cutting needs an update, but last cutting does not. This will only be updated after completing a session - which does not affect next cutting. The calls are inexpensive, but nevertheless.
Last, when making changes to .items files, all items will request REFRESH. Not only will this cause multiple calls, but worse than that, it will cause redundant calls as some channels are updated through the same API calls.