As I said, investigating this.
iOS component status won’t appear in app as its not vital for it to be loaded to use it with the app anymore.
Scroll issues are known, working on a new toolbar design that will fix this. Probably build 43 or 44.
Should be fixed by 0.91.2 or later (0.91.3 preferred for other reasons). If any sensor update fails, I attempt to re-register all the sensors en masse.
1 Like
Okay, tried to reply to everyone 
Sorry for not replying until just now, been very heads down on the next build of the app, 41, which should be out in the next 24-36 hours.
It adds support for connecting to the remote UI, Cloudhook, internal URL and external URL with logic in place to automatically retry requests with the next URL type (in the order I just gave) until it succeeds.
It will also re-add some sensors such as the geolocation geocoded sensor.
Glad to hear 0.91.3 improved things overall for sensors! We are getting close to being out of the woods on the hardest part of 2.0 thus far, migrating to mobile_app.
Here’s issues I am currently aware of:
- If you have cloud but remote UI is off you receive a SSL error
- Performance issues with scrolling
- Scroll issues if the page isn’t longer than the device screen (current workaround is to shake the device a bit to make the toolbar appear)
- Sensor names are bad and not unique enough, will prefix them with Device ID
- Sounds in push notifications are no longer defaulted to enabled (for context, see this GitHub issue). You need to add something like this to your automations:
to get the standard iOS sound.sound: name: default
Just in case anyone else doesn’t like this notification change and uses DND at night (I know some people only selectively want sounds) this in my config restores the normal behaviour of sounds with notifications so you don’t need to add them to the payloads.
- platform: group
name: David iOS Notify
services:
- service: mobile_app_davids_iphone
data:
data:
push:
sound:
name: default
- service: mobile_app_davids_ipad
data:
data:
push:
sound:
name: default
This creates a notify group as well of course.
2 Likes
Appreciate it. Just a heads up, i’ve updated my HASS to the latest version and this seems to have fixed the choppy scrolling through out the app.
1 Like
Can you explain how this is different than the Home Assistant suggested NGINX config? That’s what I use and i’ve never had any issues.
The errors about looking up redirect_uri don’t have anything to do with nginx, it has everything to do with Home Assistant being able to make a outbound connection successfully to one of those URLs to verify the legitimacy of the app’s authentication request. Usually when people report this problem to me, it’s due to a broken IPv6 stack. I did have one case recently where the issue was due to the user not properly installing SSL certificates (there is a less than 1% chance this is your issue, its only a problem for the Python.app install on MacOS).
EDIT: Coincidentally, this GitHub issue has seen some activity recently and describes exactly what the fix was. My suggestion to everyone is that if you are using nginx, only use it with the Home Assistant suggested configuration I linked above to avoid issues like this.
The choppy scrolling issue has disappeared. I did two changes, updating to 0.91.3 and removed the ios integration that I still had active (the one configured in GUI, not configuration.yaml). Hope this helps.
1 Like
Thank you arrrrr this is so confusing!!! Could have sworn @robbiet480 said you DIDN’T need mobile_app: ?!
As it stands right now you need mobile_app:. If you use actionable notifications you need ios: as well. I only have mobile_app: right now.
Thanks. So much misinformation! 
Will have another crack at getting it working.
Hmmm, even with ios AND mobile_app I STILL don’t get any notify devices appearing in dev view (which I gather I should?) and push notifications do not work.
Do you have a push ID showing under notifications? If not, force close the app and open it again and restart home assistant as well
yep, definitely. Have also reset the app and deleted the ios.conf a couple of times.
Always getting this error message when going to app settings and clicking ‘Validate and Save Connection Settings’.
If I click ‘Done’, it still enters HA.
Last beta (40) and last HA version (0.91.3), although app still seems to report 0.91.1 (any idea why?).
I’ve had that a few times. I’ve now deleted my ios.conf and HA has so far not managed to or hasn’t been prompted to create a new one. Have tried reboots, sending a “one shot” from the app, importing push TO the app, nada.
How can we use actionable notifications then?
I have iOS: as well as mobile_app: but I’m not getting the service or the device registering with iOS component
Removed the mobile_app integrations in the web gui.
Stopped HA
Updated to 0.91.3
Reset the app.
Restarted HA.
Configured the app
-
Device tracker is still using a UUID for the name and not the device id specified in the app
-
In the web guy integrations I can see the 6 created sensors all have nondescript names without the UUID or device id. Just sensor.battery, etc. But the history appears correct now.
-
The notification is as it was in 91.2 – notify.mobile_app_johns_iphone (as per the device id in the app)
Note for the notification to show up took a restart after configuring the app and it showing up as in integration.
So still some inconsistencies in the naming. I know you are working that issue from comment above.
I would like to see the device tracker, notification, and derived sensors all have the same naming scheme. I prefer the device id specified in the app; but if it has to be the UUID I’m ok with that too.