Hi Chris, in version 0.1.1 the updating worked fine. It is when you introduced the 30-60-90 second choice and the four commands that updating stopped working. Perhaps there is a limit on the number of calls and we have exceeded it.
I reverted the v1.0 releases to pre-releases. So the latest “stable” version is now again 0.1.1 until the problems in the beta channel are solved.
I just releases the v1.0.0rc12 where the update mechanism is mainly re-structured. Working fine for me so far, but found another issue related, currently working on it.
I released the RC as a normal release. That means your HACS update Dialog prints something like v1.0.2 → v1.0.0rc12. This is on purpose.
@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)