I’m guessing you’re on the current beta build. The device_tracker
is currently not using the device ID but a UUID. Have a look in known_devices.yaml
to find it. It’s a 32-character (I may have miscounted) string. This will change in the next build of the beta.
Ahh I may have been a build or two off. It’s certainly around there somewhere. That’s a few builds old now, current build is 40 with 41 expected soon after 0.92’s release.
I just figured that 30 seconds ago too. It seems to be working though and tracked me for all of yesterday.
However, it’s also creating a device tracker named ash_x_beta (for my iphone X - same device as the 32 character device) but this one doesn’t record the tracking data.
Additionally, my zones show on the map but not my location. Does that need to be enabled somewhere?
Great news. The device_tracker.ash_x_beta
is leftover from a previous beta build.
You location won’t be shown on the map if you’re inside the home zone. If you’ve got a few days of tracking I’m assuming you already have track: true
on the new device (with the UUID). Probably just inside the home zone.
I’m stuck with this 404 error as well. It happened after I removed the version(39 maybe 38 iirc?) that created all the erroneous sensor data and went back to the previous that used the ios notify still. Even after removing the app(ios and mobile app) completely from HA and re-installing I haven’t been able to get it working properly.
Ooh you might be right. I’ve got a device named 63c5760aeeb94f7fbf016b2c51058030
in there. I usually get quite a few in there that I set to ignore because I use bluetooth and end up picking up guests that I set to ignore. I didn’t realise that one was me
That looks like it. As I say, I believe this will revert to using the Device ID specified in the app in the next build. So expect it to break again with 41 but it should just be a case of repeating the same changes you’re going to make now.
Not a problem. Happy to work around any breaking changes if I knew about them - must have just missed this one
I have the same issues with 39 and 40. Went back to 36 and that seems to work just fine.
I should have clarified. The app works if I use an earlier version before it went to the mobile component. However any version that depends on the mobile app component will not work(tracking sensors, etc.) and load that part of it. I can still view the front end from the app, but the mobile app features just don’t load.
I’ve just driven up my driveway and realised that if the app supported Apple Car Play I could have opened my garage door from the dash.
I may have missed a decision on this but Car Play support would be excellent for many things, not just garage doors.
This would be an awesome feature.
Apple only supports a few different app “types” for CarPlay: Audio, Messaging, VOIP, and Navigation.
So there isn’t a possibility of a “Remote Control” style app
Not able to find anyone mentioning this, but I have a strange error when using the beta build 40
Mostly I get a ssl error like the one below
Apart from that, I also get an API error. I don’t have a screenshot of that though. The old app works, and going through Safari/Chrome browser on the phone works as well.
Anyone who knows what the problem might be?
No idea what the issue is, but I get the API error as well as the one I posted above…ugh
silly question: check if your port forward is working. My router (Xiaomi R3P) loses the port forward every so often. I simply save the port forward settings then it works again
Should not have anything to do with the port forwarding, afaik. Otherwise the old app would also fail to connect. And that one is working just fine.
Could try to investigate if something is blocking, though.
Yet!
Anyone know how to tweak the radius/accuracy of the iOS 2.0 beta app? I’m testing Life360 and the iOS app against each other and the iOS app is full of false positives. It’s over eager.
The SSL error is likely that you have the Cloud Component signed in but Remote UI not enabled. Known issue, should be fixed in next beta release.
-Jan