I believe the issue is likely the Mobvoi, it has has other issues similar to this and I believe it relates to it not handling certain error events which should point you to security/login and other issues. In the case of the Mobvoi the app just closes instantly.
I’m going to assume I have to log in to HA via the watch app? I don’t see how.
Does it require it be a public instance or using the online portal?
Im just curious if it might be useful for turning lights on/off etc.
Update. For some reason it does now present the “Instances” and “Enter server manually”
If I enter the local url: http://10.0.0.199:8123/ it tells me to continue on the phone, where it spawns a browser to login to my HA which works. It then asks if I want to allow the watch to stay signed in and I say “ALLOW”.
Then nothing happens. Once a little cloud popped up, too fast to read, but I think it was a Could not connect. Then it just forgets everything and goes back to blank.
It should be obvious to anyone, but asking for a full protocol HTTP url on a watch screen is akin to “User torture”. Things like :// is a pin to find and use. So I’m less keen to try it again now.
If you have teh phone app installed and logged in then the phone app will push the URL to the device
use external URL so the watch app can work everywhere
Any HA core errors at the time of signing in? If not then we may need you to get the logcat logs.
install the phone app so it enters the URL for you, you can also complete the sign in process using the android app on your phone by going to Settings > Companion App > Wear OS
However I wonder if the problem is more fundamental than that. I haven’t confirmed the watch actually has local network access. The phone does, but the watch prefers to ask the phone to do networking via BT and only turns on the Wifi if it really has to. It’s hard to force it to put the Wifi on. I do know when it does it does get a local IP from DHCP.
I don’t expose the external IP. I have a VPN on the phone which maps me onto my LAN.
Already tried. Actually my new phone hasn’t it setup. So everyone should be on the flat LAN 10.0.0.0/24
I’ll give it another go tomorrow.
I have wider plans to bring some device-device integration into local and out of cloud, so I have a feeling I’m about to become a lot more familar with Android and WearOS. I want my own sensor data! and I don’t want to have to download it from Google Takeout!
If the tunneling network through BT involves a new private IP on the watch, it is likely it’s request gets dumped by my firewall if it tries to come through the default gateway. But the phone should masq the private IP surely?
The original issue with the MobVoi seems to have been fixed.
It was the phone browser pop that wasn’t working in some apps. So any app that needed to pop a browser window on the phone (for login, setup etc.) was not working.
My banking “Quick balance” app is still broken that way.
what device is this on? make sure that wear OS, android system webview and/or chrome are all up to date because this is standard behavior that should be working.
I was listening to spotify on wired headphones. Put on wireless headphones, launched spotify on the phone and took the audio over. This instantly worked and hte watch lit up showing my spofity control card. (only proving the media inter-operation works, still need to prove the network connectivity from the watch).
Notifications and GA works (well when the phone is on me it does).
I guess I might be experiencing similar issues as OP with a similar setup:
Mobvoi TicWatch Pro 3 GPS
Samsung Galaxy S20, android 12
Locally run HASS (vanilla) instance in a docker container on NAS inside my LAN
both internal and external URLs set to the same: http://192.168.1.4:8123
using permanent VPN connection from my phone to my LAN (ovpn)
Now, after opening the companion app on my watch, i can choose between the pre-filled instance (showing just the ip of my hass) or enter the server addr. manually.
I choose the pre-filled one and am prompted to finish the setup on my mobile - this automatically opens my hass app on phone and prompts me to enter login creds. This then asks me to save the watch device and give it a name (with Ticwatch name pre-filled nicely). After saving, I am at the wear device settings, where i can only see “Manage device Ticwatch…”
And another login wear os device button, which leads to a login form again.
On the watch, i’m thrown back to “choose instance” dialog and choosing the instance opens up another login dialog on my phone and so on and so on.
This is the loop i’m stuck in.
I have exactly the same situation except my Android 12 phone is from different brand. Latest HA on server, latest app on the phone, latest app on the watch. All this combination does is giving me The Loop like yours.
I had this issue but in my case I had configured my reverse proxy to only allow TLS 1.3, but Wear OS 2 does not seem to support TLS 1.3 yet, after relaxing the restriction to TLS 1.2 it works as expected.
What do I have to think about when you say reverse proxy?
Are you running on nginx?
At this moment I’m using Zerotier on my phone to enter my local network. I may switch to another VPN for some other reasons. Like @paulcam I’m also trying to get things out of the cloud. Am I correct I don’t need a proxy when I use a VPN?
I’m using traefik as a reverse proxy, love managing my https endpoints using docker labels.
You can use the IP directly if you use a VPN no reverse proxy needed.
But i prefer a https with a real cert instead of a self signed one.
I am on the same boat here with a recent TicWatch Pro 3 Ultra acquisition.
My HA install is pretty simple, only local usage from home, don’t expose it to the web.
It was working fine with my previous garmin venu 2 plus, the only catch is I had to use httpS, so I used the let’s encrypt certificate with duckdns and just used my internal dns to resolve this A record providing a private IP.
I’ve tested everything with my ticwatch, even disabling https and going back to http but even like this… the authentication goes in loop as described in this post. Actually it behaves the same using the FQDN than using the local IP.
Don’t know what to do…any help please?