@Jan_Willem_Maas thank for your testing, i appreciate that a lot. I will look into your other findings in the next days.
Hi @ChrisHaPunkt,
Feedback also from my side. I have also tested the previous (1.x) versions and still had the problem that the sensors did not get updated. With with v0.1.1 the regular updates (10-15 min frequency) are properly working.
Cheers, red
Hi Red, did you experience the not updating sensor errors even with a version > 1.0.0rc14?
Hi @ChrisHaPunkt, let me just test it again. I will send you an update later today or tomorrow morning. Cheers, red
I have installed version 1.0.0.rcv16. Works well with the sensors, but not yet on the two regular mow commands. I have intercepted the data traffic from the iMow app using Burpsuite. I noticed that for the mow command I first get a JSON file with all the sensor data. This might mean something for the authorization issue that I am having. Maybe the app authorises using the data call and then executes the imow intent action and maybe you process is different. Just guessing here. The app gets stuck after it downloads the data JSON, so I cannot tell what happens after the download. The app does not like the interception of data traffic.
Hi @ChrisHaPunkt, I have tested v1.0.0rc15 and it seems that the sensor updates have been improved. Nevertheless, it seems that there are a few problems:
-
GPS position (latitude, longitude) is updated very rarely (only 30-60 minutes, 15 if you are lucky). In v0.1.1 it felt better.
-
Sensors are unavailable from time to time for around 5 minutes. This leads to tiny gaps in the history and of course from time to time the values are not available within the dashboards for several minutes (was much better in v0.1.1).
-
Even if the recorded data sets are granular, the graphic only shows sudden increases (displayed results are very coarse-grained).
I also found the following log entries. Could that be a reason for the gaps?
Cheers, red
Hi all,
thank you all for the provided feedback and information.
Last week I reached out to STIHL. I’m thinking there is a security mechanism on their side kicking in if we (HA) constantly pulling data from the server. Timeouts are common in those scenarios, which then are leading to those “gaps” we see in history. In addition, my Android App is showing the imow as offline, even if the mower itself have valid connection to the server.
I don’t have a response yet, but I will have you updated if there is something new.
I’m going to update the Readme docs and adding a hint about this issue.
Thanks all 
Ahhh interesting information!!
We have the general problem for long time that the mower is shown as offline in the original app. Actually we thought that it is due to bad mobile network coverage at home (which was also the case). But this could be one more reason.
Yeah,the mower is not offline, only the App <-> server Connection seems to. Maybe related to home ip address…
The Bluelinky NodeRed node for Hyundai electric vehicles already limits calls to the server above 4 or so per hour. This is because the traffic between server and car are done via the gsm network, which is paid for by Hyundai (and incorporated in the car price with certain call rate assumptions). For Stihl it is likely similar, but at much lower price point. Maybe we should experiment with significant lower call rate, such as once per hour, to see what happens, if you do not get satisfactory answer from Stihl. We will not be able to gps track the mower, but gps is not accurate enough anyway.
It would be good to get updated data if we change something in HA, but that likely requires a change in the API. If the API was push rather than pull we likely would not have this issue.
I questioned Stihl about this. In energy mode ECO the mower goes offline when home. In energy mode Standard it is online all the time. I have checked this to be right. However, since using the integration the mower is offline again, despite the Standard setting. That is why I believe it has to do with our API call rate.
Hi @Jan_Willem_Maas,
Maybe we should clearly differentiate between two symptoms:
- Sensor(s) show(s) unavailable - grey gaps in HA
- Online status shows “off” (or offline).
For 1) If I am not mistaken, I did not have these gaps in v0.1.1 … only with v1.1.x I experienced this problem (see my post from yesterday).
For 2) seems that we have different potential reasons why the mower goes offline:
A) Security mechanism from STIHL
B) Energy mode ECO
C) Bad mobile network coverage
Do you also have these haps like I have in (1)?
Cheers, red
This is my online availability graph from latest release:
Also quite a few gaps. But I think a lower polling frequency is likely to fix that. The offline issue is much worse, because you do not have access to the machine at all.
Hi @Jan_Willem_Maas,
- For the gaps I will try to use the lowest available polling frequency (just for testing) and increase until there are gaps again
- For the Off states I fully agree and this is really annoying. I have the same issue and no solution. I actually thought that the mobile network connect is too bad or the docking station is somehow broken. But your case confirms somehow that there might be a general issue.
Hi again, for (1) I have set the polling interval to the maximum value 300 now and I still have gaps in all sensors:
As mentioned above, I mean that I didn’t have these gaps in v0.1.1.
In parallel I will test v0.1.1 again in order to confirm.
it seems to be confirmed somehow that the gaps DO NOT happen in v0.1.1, but as of v.1.x.
In version 1.0.0rc I ran with 300s polling interval until this noon (see first screenshot). And yesterday I previously used a higher frequency (20 or 30s polling interval).
I tested for more than a day now - no gaps in v0.1.1:
Regarding the (grey) gaps the older version seems to work better.
Cheers, red
Thank you guys for the insights.
I released a version 0.1.2 with the Home Assistant Services part added (and an updated webapi to 0.7.3)
Looks like I got another hint. With the version 0.1.2 I got the timeout as well. Maybe it’s related to the updated imow-webapi dependency…
Hi Chris,
Not sure what issues you tackled in this release. But the two commands “startMowingFromPoint” still have errors.
Without duration or startpoint, the error I get is:
"Failed to call service stihl_imow.intent. 403, message, ‘Forbidden’, url=URL(‘https://api.imow.stihl.com/mower-actions/’)
With duration and startpoint provided in data, the error I get:
Failed to call service stihl_imow.intent. Expected str for dictionary value @data [‘duration’]. If I put duration in quotes I get “Unknown error” like before.
In the previous version the mower stays online 100% of the time in STD setting which is good. I only get a couple of data gaps, with regular updates of battery level.
Let me know what additional test/debug info I can provide.
In the meantime I have downloaded and installed ChrisHaPunkt/stihl-imow-webapi.
I have run the tests and I get the same error codes. So I guess the problem lies in the webapi, rather than in the integration. I am no expert in python and testing api’s so I will just post one of the logs here:
__________________________________________________ TestIMowApiOnlineIntegration.test_intent_start_mowing_with_defaults ___________________________________________________
self = <tests.test_integration_imow.TestIMowApiOnlineIntegration testMethod=test_intent_start_mowing_with_defaults>
def test_intent_start_mowing_with_defaults(self): result = self.loop.run_until_complete(self.imow.intent(IMowActions.START_MOWING, mower_id=self.test_mower.id))tests/test_integration_imow.py:107:
/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py:587: in run_until_complete
return future.result()
imow/api/init.py:351: in intent
response = await self.api_request(url, “POST”, payload=payload)
imow/api/init.py:289: in api_request
raise e
imow/api/init.py:282: in api_request
method, url, headers=headers_obj, data=payload
…/venv/lib/python3.7/site-packages/aiohttp/client.py:625: in _request
resp.raise_for_status()
self = <ClientResponse(https://api.imow.stihl.com/mower-actions/) [403 Forbidden]>
<CIMultiDictProxy(‘Cache-Control’: ‘no-cac…f’, ‘X-Xss-Protection’: ‘1; mode=block’, ‘Access-Control-Allow-Origin’: ‘*’, ‘Date’: ‘Sun, 18 Jul 2021 15:22:19 GMT’)>def raise_for_status(self) -> None: if 400 <= self.status: # reason should always be not None for a started response assert self.reason is not None self.release() raise ClientResponseError( self.request_info, self.history, status=self.status, message=self.reason,headers=self.headers,)E aiohttp.client_exceptions.ClientResponseError: 403, message=‘Forbidden’, url=URL(‘https://api.imow.stihl.com/mower-actions/’)
…/venv/lib/python3.7/site-packages/aiohttp/client_reqrep.py:1005: ClientResponseError
--------------------------------------------------------------------------- Captured log call ----------------------------------------------------------------------------
DEBUG imow:init.py:443 get_mower_action_id_from_id: 29137
DEBUG imow:init.py:481 receive_mower: 29137
DEBUG imow:init.py:486 <imow.common.mowerstate.MowerState object at 0x10cef95d0>
DEBUG imow:init.py:347 Intend: {‘actionName’: ‘startMowingFromPoint’, ‘actionValue’: ‘0000000441132897,3,0’}
======================================================================== short test summary info =========================================================================
FAILED tests/test_integration_imow.py::TestIMowApiOnlineIntegration::test_intent_start_mowing - aiohttp.client_exceptions.ClientResponseError: 403, message=‘Forbidden’…
FAILED tests/test_integration_imow.py::TestIMowApiOnlineIntegration::test_intent_start_mowing_with_defaults - aiohttp.client_exceptions.ClientResponseError: 403, messa…
====================================================================== 2 failed, 11 passed in 7.52s ================
Is this useful at all?