Home Assistant for iOS 2.0 Beta Testing

Mobile Apps Home Assistant Companion for Apple
324

I’ve heard this report a few times and seen it once myself, still trying to nail this down.

325

As I mentioned earlier, you now need to always set a sound in your payloads. You can use the sound named default to use the built-in iOS sound.

326

Still working out issues with sensor naming. It’s not the final configuration, that’s for sure.

327

Hoping this was fixed for you with build 40 and will get even better in 41 once we have fallback URL types (see later replies for more info on that).

328

It’s probably a little of this and a little of that.

Current state of themes:

I do what essentially is a hack to piggyback on the frontend WebSocket connection and get themes data out of it. I only use very certain keys from the theme, so double check that your theme has these set:

  • sidebar-icon-color for the toolbar icons
  • primary-color for the status bar (where the clock and wifi/cellular icons are)
  • sidebar-background-color for the toolbar background color.
    • If sidebar-background-color isn’t set, I fall back to using primary-background-color. If that doesn’t work I then fall back again to paper-listbox-background-color.

In build 41, maybe 42, I have implemented my own WebSocket client which should improve this situation a bit.

329

As I just mentioned to @terafin, I use specific keys that some themes may not have, so you need to double check your theme configs.

330

Should’ve been fixed via 0.91.3.

331

It was entirely a issue in HA itself, fixed in 0.91.3.

332

Location updates should be working assuming that you are on 0.91.3. I have heard one or two reports of issues with IBeacon updates not working which I’m going to look into, probably around build 42 or 43.

333

Seem my response to @ha_steve about location updates.

334

Background fetch is the most common reason for updates.

335

That Mobile App Component Loaded X line is still a bit buggy, expect a fix in build 41.

336

Spot on. You only need to continue having ios in your config if you want to define actionable notifications via YAML or have devices still on 1.5.

337

Noted, will try to get a fix in to use device ID with the notify entity but will probably require a 0.91.4 (more likely that there won’t be a .4 and you either have to run dev or wait for 0.92).

338

As I said, investigating this.

339

iOS component status won’t appear in app as its not vital for it to be loaded to use it with the app anymore.

340

Scroll issues are known, working on a new toolbar design that will fix this. Probably build 43 or 44.

341

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
342

Okay, tried to reply to everyone :slight_smile:

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:
    sound:
  name: default
    to get the standard iOS sound.
343

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