Yes, Bosch changed something. Home Assistant seems to be facing the same issue.
GGGRRRRR.
Well I can’t really make any changes - I have no real idea about how the bindings are done - but I’m willing to do any testing required.
Hi,
is anyone working on a solution?
Probably not. I already spent a lot of time on this binding, but now it seems like Bosch is actively blocking us:
This is not confirmed, but we are exposing ourselves with “openHAB” as user-agent, so if we are blocked, it’s intentionally. We could change the user-agent, but in the long run we’ll lose this game and probably end up with the same faith as:
I’ll monitor other projects and follow up in case of any news. However, since we are using an undocumented cloud API, trying to circumvent their blocking will probably only make things worse.
Thanks @laursen,
this is very unfortunate.
I’ll try to contact some “resources” at BOSCH directly. Maybe we have a chance to get some proper documentation.
The response from the “official” BOSCH support was not helpful at all:
"Bitte haben Sie Verständnis dafür, dass wir ausschließlich Support nur über die allgemein zur Verfügung gestellten Optionen der App leisten."
==
"Please understand that we only support the options made publicly available via our app."
Thanks for your time - I really liked this binding - and it was one reason why I initally bought the Indego.
I’m not very hopeful, but the ideal outcome would be:
- Documentation is made available and official. As part of the rules, it could be stated how many “cheap” and “expensive” calls we are permitted to make per day, and for example if we are allowed to make additional calls while mowing to better track progress. Expensive calls are the ones contacting the mower through the cellular network, whereas cheap calls are just fetching status information already collected by their service. For sure we’ll need to call more often than the average app usage, but at least we would have some ground rules, and they could throw 429 in case of misbehavior.
- Being allowed and able to set up a client id in the SingleKey account. This would also make it easier to authenticate as we could use the standard OAuth2 flow.
One of my reasons for deciding on the Indego was also the integration possibility. Tomorrow I’ll get it back from repair the third time on the guarantee, so if anything similar happens again, I should be able to return it and get my money back. We’ll see who offers an API at that time. 
I can fully agree to the conclusion in this blog post (which is about MyQ), we’ll see if the situation will be the same for Bosch Indego:
1 Like
Hi there 
,
I recently posted an idea for a workaround on GitHub but as I got no response there, I’ll try my luck here 
I am not too deep into the issue, but would it be a “solution” / workaround to use a random user agent?
- a UUID
- a word list for the product (HomeAssistant, OpenHab, ioBroker, …) and a random version number
I assume that the WAF would also block requests, if the user agent changes on every request, but potentially we could perform an automatic retry of requests with a new user agent every time we get a 403.
I also thought about using the same user agent than the official app uses. But yesterday I had the feeling, that the official app also suffers from the 403 problem: I had a large amount of notifications in the app and started to delete them. After deleting 20 notifications or so, the app showed a popup with an error message
15_403(unsure about the15but I definitely saw the403and directly remembered this problem here).
Referring to the last paragraph, I am not sure if Bosch is actively blocking third party integrations. Instead it may be some general configuration in the WAF that fits for “normal app usage” but slightly not when used with integrations like OH or HA.
I’m not too keen on that solution as explained here:
we are exposing ourselves with “openHAB” as user-agent, so if we are blocked, it’s intentionally. We could change the user-agent, but in the long run we’ll lose this game
However, lawn season is about to start here in Denmark, so I’ll use that opportunity to at least try a different user-agent to verify if we are indeed blocked, or if the issue is caused by something else.
Another thing we could do is try to get in touch with Bosch and ask for “permission” to use the API. The risk is of course that they explicitly deny us access, but at this point I’m not sure we have much to lose since the integration is broken anyway.
Did anyone track Home Assistant status recently?
1 Like
Thanks for your effort @laursen , really appreciate your work 
From the comments in the HomeAssistant issue, I assume that changing the user agent works to some extend and the possibility for the users to manually adjust the user agent to work around the 403 also seem to work. At least that’s what I think as no one posted anything there since start of december …
As I can see from the latest posts in the HA issues, they added the user agent as a parameter.
Do you also want to introduce something like this or how can I manually change the user agent?
I just tried “Test/1.0” as user-agent and still got 403.
See here: Connection error bosch indego APi · Issue #204 · jm-73/Indego · GitHub
I’m afraid this prediction might have come true:
and might even have even been accelerated by integrations such as Home Assistant’s trying to get around the blocking by manipulating the user-agent.
Out of curiosity I just downloaded the apk of the bosch app and decompiled it using jadx. They are obfuscating the code (which was kinda to be expected). Yet, a bit of searching around in the code shows that they are using “Indego-Connect_.<BuildNumber?>” (currently “Indego-Connect_4.0.3.12955”) as User Agent.
Not really the nicest solution (and not the really the friendly way), but if the binding would provide the option to configure the User-Agent it would be possible to adapt the User Agent to the latest App Version. Thus giving the WAF the impression that the request is coming from the app and making it hard to block.
1 Like
I can confirm that indeed using this user agent bypasses the WAF, and got the binding back online. Thanks for having a look at the APK.
In the meantime I also reached out to Bosch, but have not yet received a reply.
I’m a bit divided in what to do now. Currently the binding is not working. If we fake the user agent pretending to be the app, the binding will probably work for some time, but eventually it might be blocked in some other way. Since the end result is pretty much the same, I suppose we could give it a try.
The only thing worrying me slightly is the risk of wider blacklisting. Bosch could detect our non-app usage pattern, and block the device or user account entirely, so that it would no longer be possible to use the app either.
I guess faking the user agent would give use a few months before they can do anything about it. They would first have to roll out a new version of the app and make sure it’s widely distributed before they can block the user agent - otherwise they would block legit users of the app.
Yet, if the really mean to block third party clients, they could easily detect the pattern (the app will only do requests while actually running and not all the time) and simply block the user accounts. But that would be a quite harsh step.
Thank you very much for your superb work @laursen!
Would it be possible to provide a jar-file to test the updated binding with the current openHAB version?
Of course: org.openhab.binding.boschindego-4.1.3-SNAPSHOT.jar (it will also be included in next patch release).
3 Likes
You rock, thank you very much for this!!
1 Like
Hello everyone, sorry If I am off-topic. I recently bought a Bosch Indego S+500 and I started to google the errors I received inside the Android app and I reached these topics. I’m really impressed by your accomplishments!
I would like to do, at least try, to get the mower location let’s say from 2 seconds to 2 seconds and draw on a map the traveling he had during it’s mow.
I read your posts, I retrieved the code from the singleid redirect, but I’m stuck at the authentication part, I tried to do it from Postman as a POST:
https://api.indego-cloud.iot.bosch-si.com/api/v1/authenticate
User-Agent: Indego-Connect_4.0.3.12955
Content-Type: application/json
Authorization: Bearer eyJraWQiOiJoYURfVWlBTXE3Q2t4WXpGRUpFNXNYZXdlbmtvQ0poNmJSNzFwUHp1T293IiwidmVyIjoiMS4wIiwiemlwIjoiRGVmbGF0ZSIsInNlciI6IjEuMCJ9.xRMOlwpvKlcvnflUgFxEUQrZKH1jG05bk9vtf0-5IVysqkUsBGbayvff6NB6mqZLcbwsQcpYAkZtTfJnuNDXp_wF2vKeHeFvWXnvQs-YBhpR38oetyr3hmFmdetPTM36hk7FFqvDpdk_6H80MJcqaW4BqZRi1TQTOT6gLDDx1Gfdl6rautfIxbqNr4MyAt2sJ8AI_joTcRDBVXtwQlM8CFYKoflGr4bjnN4eU9n94wfdzjSDhkX3V8JbvFZialTdEAxT2ZpfLkxVqlVOP__st23dvzeClLaz5It7qPetGi8wMdN_NXZV5gevQipKeMYeZqYFyvvjfJeeQ2I8a_X5AA.8jEj9lR7lhy4YT4i.e_L5wO2uK_IS8xEv4rFyMg6l1SZwZYKT3DOVDxm_blaxlGJOLKynL1zpAVbjYkvck4P81_kf0jC4f4w5kk3wEZEoAlAkrW0xzN8Wjqhfed_x7fm5DPumBh5Ta8y2tNuhk-ezM1c_MEKolfSdoPsQt3A709KeNpdhD0j6ale1tXr3EXCirAtG-iMGXdKKRmC4_jkgzlu2gIRDNf5xduSJYas4gu8vxEF2aWnzgRfB_8_x4hno7v_YkFFvD866EbNPTDgiPpDW6dXLIDJkKZrtRLsXW-ynyVPSAm8XVvAwsdPJQF3ZsATX45hujv0jiZYuVV7nyELeOP8DJ3ixGX46G3XQSTXCM_2VX53Hm3_Cschwk7Y4PG7WL7QFehKMnjrycb8M9AZaOClozixA7wtj4hRaDjVy2k03fRoyvfZkCrp_xkRF6rN7gZZ1kP9yoOuwgz38A58CFgZhqvkZbbWGAoCPZDkkkqXWrQ7PncVyUDHaSPtaN8FI_KE2aDQ-EngOGEce2QjzJI7RKojuEnwnVG1cw9PW6TaUn6Da9EtpZDDwPouYtMb027AACgR5mCH-1-2x-VWUr63i3CxzIj3eiyu_xSqphnb1-BmlIk_Vy0kl5WC5oruAMMhPIza-qWVtV25O7apMCVyYB269GV_48u9icYVu9Nptk6pHyVxuf9U4E406jnNzLKuDyTXU0ZuZal4Kns4k_DXSlBNe7ODOCp_8efxmYpHVCtAdaN-UIkcdGuq1w3Z72mIVPp2FiwS5g_24zotacevj_GH2_j57XzL_Mq696MdVXxTkjNE3lhFX.ARnPED2xY_ATPcq_sBU8gA
Accept: */*
Cache-Control: no-cache
Postman-Token: f0731184-68ab-42ba-9dc0-9e58abc48823
Host: api.indego-cloud.iot.bosch-si.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 193
The body of the POST is the following:
{
“acceptTcId”: “1”,
“appVersion”: “4.0.3.12955”,
“device”: “unknown”,
“dvcManuf”: “unknown”,
“dvcType”: “unknown”,
“osType”: “Android”,
“osVersion”: “8.0”
}
And I receive a 401 with the following error:{ "errors": [ { "message": "Cannot convert access token to JSON" } ] }
From what I saw that ‘code’ which I retrieved is not a valid JWT access token. Any ideas what I’m doing wrong? Thank you in advance!
@Leonardocezary The Bearer Token you’re using doesn’t seem to be valid JWT token. Otherwise you should be able to decode it with any online JWT decoder (e.g., jwt.ms). Maybe this is just the Authorization Code received from the web page call? You need to use this to get access token.
I’m using the OAuth2 Authorization in Postman and this works flawlessly.