Changes the server name row into an editable one, persists along with the server and uses it everywhere. Basically identical to 'device name' in functionality there.
Also hides the 'activate' button if there's only one server.
Fixes regression from #1941.
## Summary
The default value of `.max` isn't adjusted to a real one until after onboarding is finished, but we do a model fetch _during_ onboarding to test that it works.
## Summary
Stores a zone from s1 in Realm like `s1/zone.name` rather than `zone.name` so it's distinct from `s2/zone.name`. This is most apparent for `zone.home` which universally conflicts.
## Any other notes
This does not yet extend to the other synced models as we use their identifier in persisted locations that aren't programmatically changeable (e.g. action IDs are stored in intents). Zones don't pose such a problem, and are the most likely suspect to even have duplicates right now; scenes, actions, and deprecated notification categories can be done after an external beta.
## Summary
Fixes receiving "Alamofire.AFError 9" with a response status code of 404 during onboarding when a URL like `http://192.168.1.3:8123/` (with trailing slash) is provided.
## Any other notes
The real crux of this issue is that ConnectionInfo strips it, but the connectivity check in onboarding does not, giving us a URL like `http://92.168.1.3:8123//auth/authorize` which errors with a status code of 404.
Fixes a crash where activeURL stack overflows itself when overriding active URL type without sufficient location privacy permission.
## Summary
Pulls the ConnectionInfo activeURL changes from multi-server back to 2021.11.
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a corresponding pull request in the Companion App Documentation repository (https://github.com/home-assistant/companion.home-assistant). Please add the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull Request is part of a bigger change, please include it here. -->
- Updates several dependencies
- Removes Lokalise -- if we can't do it on Catalyst, it doesn't feel worth it to do it elsewhere
- Migrates the NotificationTestCases from a Podspec that keeps having issues to a fastlane script which copies in the latest ones
Fixes#380. Fixes#1794. Fixes#350. Fixes#722.
## Summary
- Pulls all of the onboarding steps out of segue-based storyboards and into code.
- Merges authentication with scanning/manual, reducing steps in auth.
- Removes the "checklist" final screen.
- Supports going 'back' through onboarding steps, e.g. an error after entering a URL.
- Moves permissions from an opt-in "which would you like?" to a required "you must accept/decline this permission" for each permission. See notes below for why.
- Removes the team migration warning from last year.
- Adds landscape & dynamic type support to onboarding. I didn't bother to make the DT do live-updating though.
- Fills in internal & external URL, sets active SSID if possible after location permission.
- Connects to internal URL from discovery instead of base (external) URL.
- Allows onboarding to a server which requests, but does not require, client certificates.
- Allows starting Onboarding skipping the Welcome screen, connects this to the 'add server' row in app configuration when in debug mode.
- Stops calling api/discovery_info for testing connectivity.
- Handles Bonjour updates and removals in the scanning screen.
## Any other notes
Apple is actively blocking 2021.10 (only on iOS) because of an unwritten part of [rule 5.1.1](https://developer.apple.com/app-store/review/guidelines/#5.1.1), saying:
> **Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage**
>
> We noticed your app encourages or directs users to allow the app to access the location. Specifically, your app directs the user to grant permission in the following way(s):
>
> - A message appears before the permission request, and the user can close the message and delay the permission request with the "Continue" button. The user should always proceed to the permission request after the message.
>
> Permission requests give users control of their personal information. It is important to respect their decision about how their data is used.
This is of course referring to our screen which looks like this:
<img width="200" src="https://user-images.githubusercontent.com/74188/136716566-349558d4-d343-4ede-acd6-83b4e66742bc.png">
I love that they're cherry-picking the location part of this when we allow users to do a number of things on this screen. I believe the part of 5.1.1 that they are alluding to here is:
> (iv) Access: Apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that include the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos. Where possible, provide alternative solutions for users who don’t grant consent. For example, if a user declines to share Location, offer the ability to manually enter an address.
They do link to the Human Interface Guidelines' [Accessing User Data](https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/) whose section "Displaying Custom Messaging Before the Alert" says:
> **Make it clear that opening the system alert is the only action people can take in your custom-messaging screen.** People can interpret a pre-alert message as a delaying tactic, so it’s critical to let them quickly dismiss the message and view the system alert. If you display a custom screen that precedes a privacy-related permission request, it must offer only one action, which must display the system alert. Use a word like "Continue" to title the action; don’t use "Allow" or other terms that might make people think they’re granting their permission or performing other actions within your custom screen.
I do not believe that we're showing a pre-alert message since we're showing numerous options and allowing the user to pick and choose. Oh well. This new onboarding has improvements in other ways, and maybe is _more_ clear about permissions and what they do, so lemons into lemonade I guess.
Starting in iOS 15, there's a number of crashes happening in the background with Realm. They don't appear to be due to the file lock in the shared app container, but this may help resolve them either way -- easy to see if the next beta doesn't crash a bunch.
## Summary
- Fixes e.g. HACS (which is `hacs:hacs`) icons showing the A/B icon. We now fall back to the outline cog.
- Hide panels without the "show in sidebar" option. We get them in the response, but e.g. the title is incorrect.
- Changes sort order in the automatic version to more closely align with the frontend.
- Fixes a case where chosen panels in the past would fail to be updated due to being at the tail end of the array in the API response, due to truncating to widget size _before_ updating.
## Screenshots
## Summary
Fixes unnecessarily doing a sensor update pass when launching in the background, as well as an occasional crash talking to UIApplication's applicationState off the main thread.
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a corresponding pull request in the Companion App Documentation repository (https://github.com/home-assistant/companion.home-assistant). Please add the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull Request is part of a bigger change, please include it here. -->
Fixes#1657.
## Summary
Adds the `icon` key to actionable notifications' actions, which must be `sfsymbols:`-prefixed strings of SFSymbols names.
## Screenshots
With a payload that looks like…
```js
{
/* … */
"actions": [
{
"action": "SOUND_ALARM",
"title": "Sound Alarm",
"icon": "sfsymbols:bell",
},
{
"action": "SILENCE_ALARM",
"title": "Silence Alarm",
"icon": "sfsymbols:bell.slash",
}
]
}
```
| Dark | Light |
| -- | -- |
|  |  |
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a corresponding pull request in the Companion App Documentation repository (https://github.com/home-assistant/companion.home-assistant). Please add the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#577
## Any other notes
Apple requires that these icons either be pre-baked asset catalog assets, or part of the SFSymbols library (FB9149810), so these are prefixed with `sfsymbols:` to future-proof it.
## Summary
Fires a sensor update pass if the app is running when the focus status changes.
## Any other notes
The focus sensor _always_ live-updates, but it does so in the Intents extension. This allows the Intents extension to inform the app that it did an update, which (unfortunately, for now) fires a sensor update pass in the app. So we're over-updating the sensors, but we're keeping the in-app sensor list updated. Worth the cost, I think, since the app running when focus changes happening feels rare unless the user's playing with the sensor.
## Summary
- Upgrades the font, config, and adds a migration for renamed/removed icons.
- Migrates the one use of a renamed/removed one: `laptop-mac` -> `laptop`
## Any other notes
This change should also make it a little easier to do the migrations, since the Realm+Initialization part won't need to be touched, probably.
## Summary
Fixes the insta-updating of the focus sensor on iOS 15.
## Any other notes
`INFocusStatusCenter.default.focusStatus` always returns isFocused=false in the extension, but the intent provides the correct focus status for each update -- so we need to cache this value in the extension, and not trust the focus center state.
## Summary
Fixes a crash caused by infinitely recursing the value change.
## Any other notes
This also allows setting fractional minute values, every 15 seconds. The minimum timer which we check is 5 seconds, and that low means we won't detect changes if they occur in a 10 second period which feels too low.
Fixes#1693.
## Summary
When we fuzz the coordinate to deal with zone overlap issues in core, we need to also take into account whether we're actually in the zone we'd be fuzzing coordinate to. For zones >=100m, this is the region, but for smaller zones we need to make sure all of the monitored regions agree before changing coordinate.
Refs #1570 and home-assistant/core#50750. Fixes#1382.
## Summary
Adds a new app extension to do local push notifications on iOS 14 when connected to internal SSIDs.
## Screenshots
Adds a default-on setting to Internal URL:
| Light | Dark |
| -- | -- |
|  |  |
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#539
## Any other notes
- Updates the "you need always permission" warning in Internal URL editing to be vibrantly red, to really point out its importance.
- Sets the code signing for the app and the push target to 'manual' on device, hopefully for our internal team only. Special entitlements really do not play well with open source. Worth noting that it is not possible to test this feature without being on the HA team since it does not work in simulator (as far as I can tell) and running on-device requires entitlements.
- Moves commands into Shared in a slightly-easier registration mechanism, so we can share them in the local push extension.
Refs #945. This will not be available until we switch to compiling builds with Xcode 13, regardless of when it is merged.
## Summary
Adds a "Focus" binary sensor which is on when focus is enabled. This updates live, even when the app isn't running, via Intents.
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#543
## Any other notes
Followup is needed for onboarding to prompt for this permission.
Resolves#1542.
## Summary
Logs the error code we get when refreshing a token and log out if we encounter a 403 during token refresh.
## Any other notes
- Fixes an auth handling issue where the WebSocket connection doesn't connect initially.
- Logs out when we encounter a 403 during token refresh. Only a few auth providers do this; specifically, the `trusted_networks` one will reject token refreshes for auth tokens it vends when not on the trusted network. Otherwise, we'll keep retrying and end up getting banned (if enabled).
- Includes the error that we get into the event log so we can trace back the failure easily.
Fixes#1604.
## Summary
Dynamic actions -- unlike category-based -- appear to never forward their action handling to the iOS app, despite what the documentation says. Adds tooling to do call it manually.
## Any other notes
Not setting the notification delegate doesn't resolve this, either -- it doesn't appear we're doing anything unexpected, this is just an undocumented/rarely-used area, I guess.
Depends on home-assistant/mobile-apps-fcm-push#47 which allows the actions to be included in the notification data, and also on-the-fly silently sets the category to `DYNAMIC` which this requires.
## Summary
Allows for specifying the actions for a notification on-the-fly without defining a category. This should allow us to make all of the category config and setup unnecessary, so I'll probably consider marking it as deprecated in this release.
## Screenshots
For a notification that looks like…
```yaml
service: notify.mobile_app_iphone
data:
title: title here
message: body here
data:
actions:
- action: "id1"
title: "id1 title"
# this mirrors the action definition in yaml now, it just _also_ supports what android
- identifier: "id2"
title: "id2 title"
```
## Link to pull request in Documentation repository
- Documentation: home-assistant/companion.home-assistant#496
## Any other notes
- Dynamic actions are visual - we provide custom UI on both iOS and watchOS for the additional actions, which does require we run the app on the given platform; for example, this doesn't yet work on macOS [I need to figure out how to make Catalyst notification content work, if it is] and if you uninstall the watch app these actions will not show up.
- Allows `map` and `camera`-esque notification content on any category. In other words, if you send a notification with `map` it'll still prefer the camera `entity_id` if present. This is largely to continue in the direction of making category deprecated; as long as the content extension launches, it'll figure out what to display.
All of the normal action configuration is allowed in these actions:
- action or identifier
- title
- authenticationRequired (default: false)
- behavior (default: default, aka not textinput)
- activationMode (default: background)
- destructive (default: false)
- textInputButtonTitle (default: nil)
- textInputPlaceholder (default: nil)
Some additional things occur to match existing Android functionality:
- `uri` (or `url`) being provided in the action makes it a 'foreground' action
- action/identifier of `REPLY` changes the behavior to textinput
- `mobile_app_notification_action` is now fired with data that looks like theirs:
```
Sending action: mobile_app_notification_action
payload: ["action": "REPLY", "reply_text": "Reply text"]
```
and
```
Sending action: mobile_app_notification_action
payload: ["action": "id1"]
```
Fixes#1552.
## Summary
Only fires on the watch if sending via phone is not an option, and only allows ephemerally sending an action.
## Any other notes
Ephemerally sending doesn't retry nearly as much, and doesn't enter into any background URL session for possible persistent retry.
## Summary
Moves over the directly-render templates. Complications can never be moved over because they need to work cleanly with the background session logic on the watch.
## Any other notes
Slightly poorly ergonomic about subscribing and then cancelling; might be nice to provide a "send this subscription and unsubscribe after the first event" flag, but nothing great for how to do that comes to mind.
## Summary
- Moves a few uses of `states` in the REST API into the WebSocket API.
- Zones and Scenes now update instantly as we're updated via the WebSocket subscription.
## Any other notes
- Moves the account row in Settings to be fully self-contained on user and avatar lookup, both through the same WebSocket API call for finding out what to show.
- Moves zone fetching's `get_zones` WebHook call into the WebSocket API cache for `get_states`.
- Moves scene's fetching `get_states` into the same WebSocket API cache.
- Moves Camera ID intents lookup.
## Summary
Moves the one instance of this call (Intents) to using the WebSocket API.
## Any other notes
- Updates to use the new PromiseKit extensions and automatic connection handling in HAKit.
- Removes now-unused models for Services and already-unused Events.
## Summary
Adds [HAKit](https://github.com/home-assistant/HAKit) to connect to the WebSocket API.
## Any other notes
Currently not used for anything other than showing the status of its connection.
Fixes regression in #1487.
## Summary
Ephemeral webhook sends do not have any persisted info on them, and that's to be expected.
## Any other notes
None.
Fixes#1473. Again.
## Summary
When we issue webhook requests, we were failing to cancel any previous requests (which want to be cancelled) that were executed on not-the-background session. This moves to now checking both the background and non-background for cancellable requests.
## Any other notes
- Moves to explicitly cancelling, rather than silently replacing and succeeding, replaced requests. For example, a sensor update will now be explicitly cancelled if a new sensor update comes through, rather than following the success path.
- This resolves an issue where a sensor update occurs, fails on the non-background session, and retries with the same request data on the background session. This can lead to an older sensor update request, with outdated information, happening long after the most recent and correct one finishing.
Fixes#1473.
Refs #1460/#1467.
## Summary
When an earlier request gets applied later than we expect, we also need to assume it has replaced values similar to the transient update case fixed before.
## Any other notes
I am going to keep telling myself that the long-term benefit of the sensor caching outweighs having to figure out all of these real-world edge cases the hard way. In this case, I already expected it, I just did not fully think through the ramifications of the edge case and how it would look from the server perspective.
Fixes#1460.
## Summary
Fixes our internal cache being out of sync with the sensor values on the server.
## Any other notes
This issue occurs when, for example, we transition from value1 -> value2 -> value1. If the value2 update fails from our perspective, but successfully hits the server, we may not realize that we need to send value1 up again in the future.
