MTrab/landroid_cloud

Authentication failure

Rom1-B opened this issue Β· 71 comments

Describe the issue

I can't authenticate on Landroid_cloud. According to the logs my mail/password would be wrong, but they work on the Landroid app. So I don't think that's it.

I've tried several times to disconnect my mower from the app and reconnect it, as described in the README, but I'm still stuck.

What version of Home Assistant Core has the issue?

core-2024.3.3

What was the last working version of Home Assistant Core?

core-2024.3.3

What version of the Landroid Cloud integration do you have installed

v4.0.3

What type of installation are you running?

Home Assistant OS

Which make and model is the mower used for this integration?

Landroid WR153E - Firmware 3.32b1 - WORX

Diagnostics information (NOT log entries!)

None

Relevant log entries

2024-03-24 17:09:52.410 DEBUG (MainThread) [custom_components.landroid_cloud.config_flow] (Config) data: {'email': '***@***', 'password': '*****', 'type': 'Worx'}
2024-03-24 17:09:52.411 DEBUG (MainThread) [pyworxcloud] Initializing connector...
2024-03-24 17:09:52.411 DEBUG (MainThread) [pyworxcloud] Try getting correct CloudType from WORX
2024-03-24 17:09:52.412 DEBUG (MainThread) [pyworxcloud] Found cloud type <class 'pyworxcloud.clouds.CloudType.WORX'>
2024-03-24 17:09:52.412 DEBUG (MainThread) [pyworxcloud] Initializing the API connector ...
2024-03-24 17:09:52.412 DEBUG (MainThread) [pyworxcloud] Getting logger ...
2024-03-24 17:09:52.413 DEBUG (MainThread) [pyworxcloud] Initializing EventHandler ...
2024-03-24 17:09:52.414 DEBUG (SyncWorker_13) [pyworxcloud] Authenticating ***@***
2024-03-24 17:09:52.563 DEBUG (SyncWorker_13) [pyworxcloud] Authentication for ***@*** failed!
2024-03-24 17:09:53.716 ERROR (MainThread) [frontend.js.latest.202403070] Uncaught error from Firefox 124.0 on Windows 10
Error: Permission denied to access property "localName"
element (src/blocking-elements.ts:372:56)
sibling (src/blocking-elements.ts:355:34)

Additional information

No response

Perhaps you have some strange character in your password.
Else I cannot say other than what the logs say

It's a 20-character password with uppercase, lowercase and numbers, but no special characters. I should also point out that the same identifiers were working at the end of last year (before winterizing the lawnmower). It's since I woke it up (2-3 weeks ago) that I've had the problem.

Is there anything I can do to get more details?

Unfortunately not. The API only responds with authenticated or not authenticated.

I've got the same issue with my Worx Landroid Plus WR165E. It works last week without any problems. I've got also just a password with uppercase, lowercase and numbers.

I have literally NO idea why you guys can't login.

Can you log in to this site? https://id.worx.com
It should use the same API endpoints

Can you log in to this site? https://id.worx.com

Yes, I can connect without any problem

Very strange then. Got absolutely no clue then.

Perhaps one of you could send your credentials to landroid_cloud (at) trab.dk - then I'll do some tests

Yes, I've just sent it to you

Yes, I've just sent it to you

No issues here on the latest version of the integration

What do you mean?
Were you able to log into HA with my account?
I just tried again, it still fails. Could it be an entity conflict, since I deleted the old one, maybe there are still traces somewhere?

I mean exactly what I wrote - I added the integration with your credentials (copy-paste) and it worked just fine.
So as of now I'd rule the issue to be some kind of error at your side - sorry

I also copy and paste, but I don't have the same success (it's not fair, I feel unloved 😒) And in the logs my mail and password are displayed in clear, so I'm sure they're the right values.
Can it be a country restriction?
Or can I force it, by setting the parameters directly in my config, without going through the GUI? How can I do this?

Try removing and redownload the integration.
I cannot say why it won't work for you.
In a clean installation (dev environment) I works just fine

It's done (several times), but authentication fails every time.

I think it's the registration of my config that's failing. Do I have to go through the GUI or can I save my config directly in configuration.yaml? What's the syntax?

I'd like to avoid redoing all my HA config.

Only GUI config is available

Is it working for you again now? It's still not working for me. I also restored an old backup as a test when it was still working. Unfortunately also without success. As already written in advance. A few weeks ago it still worked without any problems. Now suddenly from one day to the next only the error message. Unfortunately, reinstalling the integration did not help either. However, login works on all other platforms without any problems. I haven't changed anything in Home Assistant recently either...

Does any of you guys have the opportunity to try installing on a clean Home Assistant instance?
Just to try that, as that is working fine here.
Perhaps some of your other integrations are conflicting, but as I cannot recreate it's pretty hard for me to fix.

Perhaps even if you could all attach (NOT copy paste) the diagnostics to compare with my own working installation

No, it still doesn't work. I've made a number of tests (removing other integrations, using older versions) but it's still the same error in the logs.

Hello,
I also have the same problem. I then installed a second home assistant in my home (just for testing purposes) and installed the Landroid integration on it and it works again. But I really don't feel like starting everything all over again on the new ha :-(
I apologize for my bad English as I have it translated via Google

Guess something is conflicting, but I have no idea what

Perhaps if you guys could start listing your integrations (yeah, I know it's a tedeious task), we could find the culprit.
I have no idea what else to do as I cannot replicate this issue, sorry

First of all, thank you for taking the trouble to find out which integration causes conflicts.
Here is a list of my integrations:

  • Distance
  • AVM Fritz!Smart Home
  • Brother Printer
  • DLNA Digital Media Renderer
  • Eufy Security (HACS)
  • Forescast.Solar
  • Google Cast
  • HACS
  • Home Assistant Supervisor
  • Home Connect
  • Internet Printing Protocol (IPP)
  • LG webOS Smart TV
  • Meater
  • Meteorologisk institutt (Met.no)
  • Mobile app
  • MQTT
  • Netatmo
  • Philips Hue
  • Radio Browser
  • Seat Connect (HACS)
  • Sun
  • Sony Songpal
  • Synology DSM
  • Tuya
  • UPnP/IGD

Do you also want to know whether they were installed via HACS? I'll just write that in brackets after it.

Here are mine, I can write the list if it's more convenient?

image

The only one I see, that could do something, and that I don't use myself, is Tuya (I use LocalTuya).
Other than that, that idea looks like a dead end too

Would it also be enough if you just deactivated the integration and then tried Landroid Cloud? or is it best to delete it completely?

Not sure which would be the best - also not even sure it is the conflicting integration :(

I'll switch to localTuya this evening and see if it works. I will report

I just deleted the Tuya integration and restarted HomeAssistant. After that I didn't reinstall tuya but tried landroid cloud first and unfortunately it didn't work 😩

Same problem here. The integration just stops working yesterday. Now I've got an authentification error everytime, no matter what I do.

Really sorry to see y'all having this issue.
But I have no idea what causes this, as it seems like a fresh Home Assistant without other integrations, doesn't have this issue.

You're right, it's a weird behaviour. I've did some debugging with your example code:

from pyworxcloud import WorxCloud
from pprint import pprint

cloud = WorxCloud("my email", "my password", "worx")

auth = cloud.authenticate()

...

On my local machine (same network) its running successful.

My HA instance is running as docker, so I tried the same python script inside the container and got an auth error:

docker exec -it homeassistant-homeassistant-1 python worxtest.py
2024-04-15 11:00:59,074 [__init__.py] [__init__] [DEBUG] [162] Initializing EventHandler ...
2024-04-15 11:00:59,074 [__init__.py] [authenticate] [DEBUG] [191] Authenticating *my email*
2024-04-15 11:00:59,232 [__init__.py] [authenticate] [DEBUG] [197] Authentication for *my email* failed!
Traceback (most recent call last):
  File "/config/worxtest.py", line 7, in <module>
    auth = cloud.authenticate()
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/pyworxcloud/__init__.py", line 198, in authenticate
    raise AuthorizationError("Unauthorized")
pyworxcloud.exceptions.AuthorizationError: Unauthorized

In a fresh HA container (and installed some custom_components from my main instance), It's successful too:

docker exec -it homeassistant2-homeassistant-1 python worxtest.py
2024-04-15 11:53:28,121 [__init__.py] [__init__] [DEBUG] [162] Initializing EventHandler ...
2024-04-15 11:53:28,121 [__init__.py] [authenticate] [DEBUG] [191] Authenticating *my email*
2024-04-15 11:53:28,729 [__init__.py] [authenticate] [DEBUG] [201] Authentication for *my email* successful
2024-04-15 11:53:28,729 [__init__.py] [connect] [DEBUG] [260] Fetching basic API data

Any idea for further debugging?

It makes absolutely NO sense - the authentication is a basic HTTPS request to an authentication endpoint. Should work no matter what.

I have no ide on what the next step could be.

I'd wish I could reproduce the error, then at least I'd have a chance for resolving this :(

Any idea for further debugging?

Could you try running this command in the docker container pip show requests - both on the working and the non working containers, please.

# the broken instance
docker exec -it homeassistant-homeassistant-1 pip show requests
Name: requests
Version: 2.31.0
Summary: Python HTTP for Humans.
Home-page: https://requests.readthedocs.io
Author: Kenneth Reitz
Author-email: me@kennethreitz.org
License: Apache 2.0
Location: /usr/local/lib/python3.12/site-packages
Requires: certifi, charset-normalizer, idna, urllib3
Required-by: acme, agent-py, alpha-vantage, amcrest, apprise, aranet4, azure-core, baidu-aip, blinkpy, boschshcpy, brottsplatskartan, bthomehub5-devicelist, buienradar, caldav, casttube, ciscomobilityexpress, clx-sdk-xms, coinbase, concord232, datadog, datapoint, devolo-home-control-api, discogs-client, DoorBirdPy, dremel3dpy, dwdwfsapi, dweepy, eagle100, epion, fastdotcom, fints, firebase-messaging, fixerio, flipr-api, fortiosapi, freesms, fritzconnection, gassist-text, georss-client, gitterpy, google-api-core, googlemaps, greenwavereality, growattServer, gTTS, habitipy, hkavr, homeassistant, homeconnect, homematicip, httmock, huawei-lte-api, ibmiotf, ihcsdk, influxdb, intellifire4py, jaraco.abode, jaraco.net, jellyfin-apiclient-python, justnimbus, kiwiki-client, krakenex, lakeside, libsoundtouch, linode-api, locationsharinglib, lupupy, Mastodon.py, messagebird, meteoalertapi, meteofrance-api, mficlient, micloud, mullvad-api, neurio, nextcloudmonitor, noaa-coops, notifications-android-tv, notify-events, nsw-fuel-api-client, nuheat, oemthermostat, ondilo, openerz-api, openevsewifi, openwrt-luci-rpc, openwrt-ubus-rpc, oru, pizzapi, PlexAPI, prawcore, prayer_times_calculator, proliphix, pubnub, pushbullet.py, pushover-complete, py-canary, py-melissa-climate, py-sucks, pyatmo, pyAtome, pyatv, pyaussiebb, pybbox, pybotvac, pycarwings2, pychannels, pycketcasts, pycognito, pydexcom, pydrawise, pyedimax, pyephember, pyezviz, pyfibaro, pyfireservicerota, PyFlume, pyfritzhome, pyfttt, pyhiveapi, pyicloud, pyirishrail, pyiss, pyisy, pylgnetcast, pymailgunner, pymitv, pymsteams, PyMVGLive, pynetgear, pynuki, pynx584, pyobihai, pyombi, pyopnsense, pyowm, PyPasser, pyqvrpro, pyqwikswitch, pyrail, pyrainbird, Pyrebase4, pyschlage, pysesame2, pysignalclirestapi, pysmappee, pysmi-lextudio, pysuez, PySwitchbot, pythinkingcleaner, python-blockchain-api, python-digitalocean, python-ecobee-api, python-etherscan-api, python-gitlab, python-join-api, python-mystrom, python-picnic-api, python-qbittorrent, python-ripple-api, python-tado, pythonegardia, pyvera, pyvesync, pyvizio, pywebpush, pywemo, pywilight, pyworxcloud, qnapstats, quantum-gateway, RachioPy, raincloudy, renson-endura-delta, requests-file, requests-futures, requests-oauthlib, requests-toolbelt, ring-doorbell, ritassist, rjpl, rocketchat-API, roonapi, russound, rxv, samsungtvws, sense-energy, sharkiq, shodan, simplehound, simplepush, soco, solaredge, spiderpy, spotipy, srpenergy, starlingbank, stookalert, stookwijzer, streamlabswater, sunwatcher, sunweg, surepy, synology-srm, Tami4EdgeAPI, tank-utility, tapsaff, tellduslive, tellsticknet, thingspeak, tmb, todoist-api-python, transmission-rpc, TravisPy, tuya-device-sharing-sdk, twilio, TwitterAPI, unifiled, upcloud-api, update-checker, uplink, venstarcolortouch, vilfo-api-client, vsure, vtjp, vultr, wallbox, warrant-lite, waterfurnace, wirelesstagpy, xs1-api-client, yalesmartalarmclient, yalexs, yt-dlp, zeep, zeversolar, ziggo-mediabox-xl, zm-py, zwave-me-ws

# the fresh instance
docker exec -it homeassistant2-homeassistant-1 pip show requests
Name: requests
Version: 2.31.0
Summary: Python HTTP for Humans.
Home-page: https://requests.readthedocs.io
Author: Kenneth Reitz
Author-email: me@kennethreitz.org
License: Apache 2.0
Location: /usr/local/lib/python3.12/site-packages
Requires: certifi, charset-normalizer, idna, urllib3
Required-by: acme, agent-py, alpha-vantage, amcrest, apprise, aranet4, azure-core, baidu-aip, blinkpy, boschshcpy, brottsplatskartan, bthomehub5-devicelist, buienradar, caldav, casttube, ciscomobilityexpress, clx-sdk-xms, coinbase, concord232, datadog, datapoint, devolo-home-control-api, discogs-client, DoorBirdPy, dremel3dpy, dwdwfsapi, dweepy, eagle100, epion, fastdotcom, fints, firebase-messaging, fixerio, flipr-api, fortiosapi, freesms, fritzconnection, gassist-text, georss-client, gitterpy, google-api-core, googlemaps, greenwavereality, growattServer, gTTS, habitipy, hkavr, homeassistant, homeconnect, homematicip, httmock, huawei-lte-api, ibmiotf, ihcsdk, influxdb, intellifire4py, jaraco.abode, jaraco.net, jellyfin-apiclient-python, justnimbus, kiwiki-client, krakenex, lakeside, libsoundtouch, linode-api, locationsharinglib, lupupy, Mastodon.py, messagebird, meteoalertapi, meteofrance-api, mficlient, micloud, mullvad-api, neurio, nextcloudmonitor, noaa-coops, notifications-android-tv, notify-events, nsw-fuel-api-client, nuheat, oemthermostat, ondilo, openerz-api, openevsewifi, openwrt-luci-rpc, openwrt-ubus-rpc, oru, pizzapi, PlexAPI, prawcore, prayer_times_calculator, proliphix, pubnub, pushbullet.py, pushover-complete, py-canary, py-melissa-climate, py-sucks, pyatmo, pyAtome, pyatv, pyaussiebb, pybbox, pybotvac, pycarwings2, pychannels, pycketcasts, pycognito, pydexcom, pydrawise, pyedimax, pyephember, pyezviz, pyfibaro, pyfireservicerota, PyFlume, pyfritzhome, pyfttt, pyhiveapi, pyicloud, pyirishrail, pyiss, pyisy, pylgnetcast, pymailgunner, pymitv, pymsteams, PyMVGLive, pynetgear, pynuki, pynx584, pyobihai, pyombi, pyopnsense, pyowm, PyPasser, pyqvrpro, pyqwikswitch, pyrail, pyrainbird, Pyrebase4, pyschlage, pysesame2, pysignalclirestapi, pysmappee, pysmi-lextudio, pysuez, PySwitchbot, pythinkingcleaner, python-blockchain-api, python-digitalocean, python-ecobee-api, python-etherscan-api, python-gitlab, python-join-api, python-mystrom, python-picnic-api, python-qbittorrent, python-ripple-api, python-tado, pythonegardia, pyvera, pyvesync, pyvizio, pywebpush, pywemo, pywilight, pyworxcloud, qnapstats, quantum-gateway, RachioPy, raincloudy, renson-endura-delta, requests-file, requests-futures, requests-oauthlib, requests-toolbelt, ring-doorbell, ritassist, rjpl, rocketchat-API, roonapi, russound, rxv, samsungtvws, sense-energy, sharkiq, shodan, simplehound, simplepush, soco, solaredge, spiderpy, spotipy, srpenergy, starlingbank, stookalert, stookwijzer, streamlabswater, sunwatcher, sunweg, surepy, synology-srm, Tami4EdgeAPI, tank-utility, tapsaff, tellduslive, tellsticknet, thingspeak, tmb, todoist-api-python, transmission-rpc, TravisPy, tuya-device-sharing-sdk, twilio, TwitterAPI, unifiled, upcloud-api, update-checker, uplink, venstarcolortouch, vilfo-api-client, vsure, vtjp, vultr, wallbox, warrant-lite, waterfurnace, wirelesstagpy, xs1-api-client, yalesmartalarmclient, yalexs, yt-dlp, zeep, zeversolar, ziggo-mediabox-xl, zm-py, zwave-me-ws

Seems to be the same...

Damn - dead end too then

What about pip show urllib3 and pip show paho-mqtt
Then we have the 3 requirements covered, version-wise.

I'm completely out of ideas here, so just guessing

I compared all packages with pip list. There was only a few differences (not urllib3 or paho-mqtt) and I installed the same version in the fresh instance as in the broken one. So all python packages should be now on the same version. The landroid integration and my test script are still working...

Seems to be not a dependency problem.

Is there any unique client side ID used for authentification? I mean unique for an HA instance. which might by blocked on server side?

No, no unique ID either

Does this return an access and refresh token?

"""Test file for debugging only."""

import requests


url = "https://id.worx.com/oauth/token"
request_body = {
    "grant_type": "password",
    "client_id": "150da4d2-bb44-433b-9429-3773adc70a2a",
    "scope": "*",
    "username": "ACCOUNT-EMAIL",
    "password": "ACCOUNT-PASSWORD",
}
headers = {
    "Accept": "application/json",
    "Content-Type": "application/x-www-form-urlencoded",
}

req = requests.post(url, request_body, headers=headers)

print(req.json())

nope 429 TOO MANY REQUESTS

With the fresh instance I got an access token.

I've checked the request headers, there is no ID or something else. I don't know if there is anything in the TCP connection... According the response headers, there is a cloudflare server responding. So I think cloudflare is doing some "fingerprinting magic"...

Too many requests?! Interesting πŸ€”
But why?!
Do you have multiple mowers?

I had two mowers in my account for one or two days. A few hours after unlinking one of them, the integrations stops working. So yes, this could be a reason.

Shouldn't trigger at too many requests error though. Very strange.
Might try to build in some backoff logic to a 429 response, like when getting a 504 error.

In 5 minutes or so, please try changing pyworxcloud version 4.1.11 in the landroid_cloud manifest.json file.
This adds progressive backoff to the 429 error response to see if that fixes the issue (might not fix it right away as the block needs to go away first)

I updated to the newer pyworxcloud, but I'm still blocked...

As the integration is not configured for main instance now, I will stop testing for now. I've read about a maximum wait time of 24 hours for cloudflare rate limiting. So I will test again in >= 24 hours. πŸ˜‰

Thanks for your help. I will report tomorrow.

Could you try v5.0.1 to see if it gives better response to the error?

The error became "Too many requests to the API - Try again in 24 hours" on my first attempt and I hadn't tried for several days.

At least more correctly described to the user now. But I have no idea on why the API returns 429 for you guys

I will wait until the 24 hours are over. If I'm still receiving the 429 error, I will try to get around the device fingerprinting...

If I'm not successful, I hope migrating my data to a new HA container instance might be a solutiuon.

I'm still blocked. Recreating container didn't solved it.

I did some research about fingerprinting technologies, but I have no idea why it is working in a fresh container (which seems to have the same fingerprints as the old container). ☹️

I've found a workaround (at least for me with my container setup). Just migrating my data to a new HA container is not enough, as my main HA container is running as network_mode=host (needed for zeroconf broadcasting stuff). So the HA instance and host system has the same IP/MAC address and my whole container host (or its ethernet IP/MAC address, fingerprint, whatever...) is blocked at the Worx services. Any new container with network_mode=host is blocked too.

When testing with a second fresh HA instance, I was using a docker network bridge instead of the host network. So the container has a different IP/MAC address than my host. This seems to be the reason, why it was working for me with "a fresh instance".

So as a workaround, I'm running a https proxy (e.g. squid) as container with a network bridge. In my HA instance I added the proxy as a environment variable (HTTPS_PROXY=http://localhost:3128). Thats it. All outgoinbg https traffic from the container is now proxied trough the proxy container.

I don't know how you other guys in this issue are runnning HA. But using a proxy (container, other host or something else) might also work for you. I hope that waiting a few more days, weeks (or perhaps months πŸ™„) will be enought to get unblocked and I could remove the proxy stuff...

I have been talking to Positec about this issue, and the do indeed block the IP address for a duration between 5 minutes and 24 hours.
But the block is for IP address AND user credentials, so that's not the actual issue here I think, as a fresh HA instance on the same IP and credentials indeed works.

I have NO idea what to do next, for solving this issue.
It seems to be related to some local thing in the Home Assistant instance, but what it is I have no idea to

Just got an idea - could one of you try changing the pyworxcloud version in the manifest.json to read pyworxcloud==4.1.14b1 and see if that changes anything?

But the block is for IP address AND user credentials, so that's not the actual issue here I think, as a fresh HA instance on the same IP and credentials indeed works.

Yes, this isn't the problem. I'm blocked without sending any request data. I think the block is done on a TCP/IP stack fingerprint. So the outgoing (virtual or not) ethernet interface is blocked.

$ curl https://id.worx.com
429 TOO MANY REQUESTS
$ curl -X POST https://id.worx.com
429 TOO MANY REQUESTS

Or with reponse headers:

$ curl -X POST -D - https://id.worx.com
HTTP/2 429
date: Fri, 19 Apr 2024 11:28:23 GMT
content-type: text/plain
content-length: 21
x-ratelimit-throttle: true
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 876c8d02ad496967-FRA
alt-svc: h3=":443"; ma=86400

429 TOO MANY REQUESTS

It seems to be related to some local thing in the Home Assistant instance, but what it is I have no idea to

As written above, I think the block is based on the TCP/IP stack. So this issue is not HA related. Wo can do nothing.

I have NO idea what to do next, for solving this issue.

As you have contact to Positec: They need to check their rate limit throttling settings at cloudflare. There is more than IP address AND user credentials... I'm totally fine with blocking, when there are too much requests (for whatever reason). But there must be a normal wait time. And a Retry-After response header would be very helpful...

Just a short update: my proxy workaround is running over a week now. Everything is fine.

My host machine is still blocked. Same details as in my last comment. I don't why I get blocked so long. There can't be any request from my host for a week now. Really strange...

Is the problem still being worked on, or did I somehow overlook the solution?

"Worked on" as in I have absolutely no clue why this is happening, cannot reproduce and Positec cannot see why the connection isn't sucessful either.
Your guess might be as good as mine

Just got an idea - could one of you try changing the pyworxcloud version in the manifest.json to read pyworxcloud==4.1.14b1 and see if that changes anything?

Yes, it works for me, thanks πŸ₯³ πŸŽ‰

Just got an idea - could one of you try changing the pyworxcloud version in the manifest.json to read pyworxcloud==4.1.14b1 and see if that changes anything?

Yes, it works for me, thanks πŸ₯³ πŸŽ‰

Unfortunately, for me it doesn't work. Went back to 5.0.1 and tried pyworxcloud==4.1.14b1, deleted and re-paired the mower -without any success. Still get "Too many requests to the API - Try again in 24 hours". I'll wait another 24 (or better some hours more) and will try it again.

Problem solved. After update to HA 2024.5.1 login to landroid is possible again. Everything works fine.

Still blocked... I need to stay on my proxy workaround. 😞

Hi, i've got the same problem since HA update 2024.6.0.

Initially the logs indicated IP banned : Too many requests for xxx@xxx.xx at Landroid Cloud. IP address temporary banned.
I deactivated the entity then waited a few days, but same problem.
Yesterday, I uninstall then reinstall landroid_cloud and now I get the following error message when trying to integrate my Worx robot: Too many requests to the API - Try again in 24 hours

Connection via the official application works correctly as well as connection to the id.worx.com site with a browser.

On the other hand, here is a screenshot of the command mentioned above, and I don't understand why I don't get a 429 response using curl:
image

If any of you have an idea that would be great ;)

Thanks

It is an issue between Home Assistant and Landroid Cloud, as if you install a new Home Assistant, then the issue will be gone.
Unfortunately I have absolutely no idea why this is happening :(

I am considering rewriting it all from scratch and see if that will fix this, but that will be a huge task and I won't have time for that within the next few months

Thanks for the response, i'll wait and use the official worx app instead ;)

I have noticed a strange parallel. In the last few days, I encountered the familiar login problem again after the integration had been running smoothly for several weeks. Then suddenly, the problem reappeared. Interestingly, at the same time, the Tuya app also had a login issue. This was also the case with the last Landroid problems. A few weeks ago, the Tuya app was already ruled out as the cause. But maybe both integrations access similar structures in HA that lead to problems after updates.
Perhaps this will help a little bit with troubleshooting.

Both integrations, landroidcloud and tuya, work fine at the moment. There were problems for about 3-4 days.

For me, the problem still exists. I'm blocked since 4 months and I don't know why. 😞 When this happend, I had one HA in my network (with two landroids for around 3 or 4 days) talking to the Worx API.

My HA is using a proxy all the time now, to get around this. (Just tested without proxy today, but still blocked.)
If anyone is interested in my "proxy workaround with docker", I could provide some details.

@MTrab

I am considering rewriting it all from scratch and see if that will fix this, but that will be a huge task and I won't have time for that within the next few months

Are you sure, that would fix it? As the serverside API keeps the same, I think you could trapped into this, anytime again.

if you install a new Home Assistant, then the issue will be gone.

At least for me, this didn't work. As the hardware is the same...

You mentioned a contact to Positec/Worx. I think it would be helpful to know what limiting rules they use. (You already noticed some rules, but I think there is more than this.)
Maybe you can integrate that rules into your project to avoid reaching the limitations. πŸ˜„

I can't get a clear answer as to what the limiting factors is and why (at least for most people) it helps creating a new Home Assistant.

As for rewriting, there's more than this issue for that - it's a mess as I really haven't had the time to make the recent API changes the right way. Alot of code isn't even used anymore.
Perhaps there is something interfering and creating this issue.
Only problem is that I don't know when I have the time to do the rewrite - might not even be this year.

In the meantime, I am completely confused. A few weeks ago, communication between HA and the mower resumed, but then it suddenly stopped again. Last week, everything suddenly worked as desired. The special thing: I was on vacation and did not make any changes to HA for several days. I only occasionally checked the status of the mower with the landroid app. I have no remote-acces to HA. After 4-5 days, the connection was lost again. Also without any changes.

Anyway, take your time… it’s just an integration for a lawn mower robot. There are a thousand more important things.