but that is the one which gives me the invalid client id error
Yes I restart after changing base_url through the command
sudo systemctl restart home-assistant@homeassistant && sudo journalctl -f -u home-assistant@homeassistant
Regardless of the base_url I set, that redirected URL remains the same: is this expected?
Not sure as I’ve never had to dig this deep.
Have you tried setting up lets encrypt w/ ddns. It’s possible that the app requires SSL. I’ve never used it without SSL to be honest.
It did work in the past, without SSL, with previous versions of HA. If I remember well also with this 0.101.3, but something’s clearly changed, maybe after a reinstall.
Since I’m on a fresh install of HA it is clearly something related to my environment but I don’t know where to look…
I could for example set the logger to DEBUG level for the http component… which would be the syntax in configuration.yaml?
Hi, I have got the same error “Invalid client id or redirect uri”
Everything was OK, but from version 0.100 I can’t login using app. No problem with browser.
Unfortunately I still have to find a solution to this problem, which I don’t know if it’s a bug or not.
I tried reinstalling Home Assistant & iOS app several times; I reset all the python3.7 virtual environment; I tried installing different HA versions.
I got a couple of answers on Discord channel but found it not very responsive to questions outside the topic that is going on in the chat.
The only thing that worked was to downgrade iOS app to v1.1.1, which I guess has a different type of authentication method.
Current v1.5.1 and beta v2.0 give this problem to me, on different devices.
I also have this issue. Can you reach your HA-installation via browser from outside your network? This also doesn’t work for me: “Unable to connect to Home Assistant”.
Update: My last statement was wrong: I actually can reach my home assistant from outside my network.
yes I can. both local and external DDNS IP work correctly if accessed from browser. the problem is only in the iOS app.
After trying to completely disable IPv6 from my network as suggested by the app developer on the Discord channel, without solving the issue, I finally flashed the last version of Raspbian Buster on the Raspberry Pi.
On top of that brand new OS I followed the manual installation instructions (which means I also upgraded to HA v0.102.0), and I can report the issue disappeared on the v2.0beta and v1.5.1 iOS app.
I still don’t know the reason of the problem but I consider the issue closed.
Ran into this problem when upgrading to new iOS 2.0.0 Companion.
Finally got it working after changing server DNS resolver to 8.8.8.8 instead of my internal pihole DNS.
I have the same problem on all IOS devices after updating to Home Assistant Companion Ver. 2.0. Changing DNS resolver to 8.8.8.8 did nothing at all. Disabling ipv6 did nothing. I have installed a fullchain.pem certificate on the IOS devices, nothing helps. How can I downgrade to ver. 1.1?
I have the same problem, I’ve tried everything and nothing to solve
Same thing here. I’ve tried every suggestion, and I get the invalid client ID or redirect URI error every time.
Ultimately the cause for me was my IPv6 network not working but DNS resolution returning IPv6.
In my particular case, I went ahead and fixed the problems with my IPv6 config as my ISP provides IPv6 support, I just needed to reconfigure my network and reset the interface. In my case I’m doing a docker setup on CentOS7 and so I used network manager:
# nmcli c m eno1 ipv6.method auto
Alternatively, I would have tried to disable IPv6 lookup (AAAA records) on my dnsmasq instance, but I didn’t chase this down as I wanted IPv6 to work anyway. If you really don’t want to use IPv6, I would explore removing AAAA records from your local DNS server.
I had the same issue with IOS HA Companion App not working with HA 101.3, RPi3 buster, and NabuCasa cloud. What worked for me was to totally disable the ipV6 on the RPI. Here is one way to disable ipv6: https://gist.github.com/andreibosco/3badaac477446587bcd6751e186df446
Disabling IPv6 didn’t help here, I’m still getting the error within my local network using http://HASS_IP:8123
Hi Everyone,
I too was seeing this issue through docker, and I thought I’d drop a line to help people rule this out (or in).
What was happening for me is that for whatever reason, the app has a really low timeout. If your HA installations DNS isn’t snappy, it’ll spit back the above error.
You can test this by going into the docker container (docker exec -it [container name] bash) and then evaluating how fast the DNS resolution is happening:
time dig home-assistant.io
It should happen very fast. If it returns after a second or two, it’s too slow.
If it is too slow, try switching around DNS servers. If it doesn’t return at all, that’s likely your problem.
I too had this issue when I had to change how my Pi was hooked up to my network. My new router only has one ethernet port, so I had to use a network switch to hook the HA Pi up (along with my IP phone). Seeing the previous posts about DNS lookup issues, I thought the switch might be the issue. I decided to give up the idea of an ethernet connection for my HA Pi and changed it to WiFi, and the mobile app worked like a charm. Maybe having the switch in between the Pi and the router delayed the DNS lookups slightly. It could have been something else I neglected to set up on the WiFi router or switch, but I was tired of messing with them so I just switched over to WiFi on the HA Pi and the app worked.
Oh, the other weird issue I had before I switched it to WiFi - the system time on my Pi wasn’t getting synced correctly. Very strange - when I would reboot, the Pi would have a seemingly random system time. One time it was 15 minutes behind, and then after a reboot it was about an hour and half behind. Very odd. This too went away once I switched to WiFi.
After fresh HA installation 2 iOS devices and an Android gave this error when using app, using with browser ok. All I did was restart my wifi router and the problem is gone.
Thought the root cause of this problem may vary, I found a solution that worked for me. I made a reply in another thread, but thought it might help someone here as well.
Cheers,
Marcus
Had a similar issue. What seemed to work is by setting http in configuration.yaml with the following:
Set ip_ban_enabled to false
Add 127.0.0.1 under trusted_proxies
Set login_attempts_threshold to 500