## Summary
When set to "None", all sensors sent to the server will be redacted.
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#644
## Any other notes
This also updates location when changing location privacy & sensors when changing sensor privacy, so the data server-side will be most-up-to-date.
## Summary
When a server is deleted, we now update the identifiers of any locally-defined actions or complications to point to the first server. We want to avoid ever having a server identifier pointing to a deleted server so we can trust the identifiers more.
## Any other notes
Deleting in this case would be bad as it's an unexpected data loss. I can imagine someone deletes and re-adds the server (potentially the last one, too), or other maintenance tasks.
Fixes#1955.
## Summary
We were not updating any complications watch-side, so any updates exclusively came from the iOS app's updating them.
## Any other notes
Complications weren't syncing over to the watch with their serverIdentifier value set, so when we went to update none of the API instances thought their server had any complications needing updating.
Fixes bad logic in the "can server identifier be edited?" check, and colors the detail label of the server select row like a field row in other Eureka contexts.
## 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.
- 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
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.
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.
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.
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"]
```
## 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.
Adds new fastlane lanes:
- `fastlane lint` which checks the linters
- `fastlane autocorrect` which applies the linters which can autocorrect (Rubocop, SwiftFormat)
Adds a build step to the Codegen abstract target which runs SwiftFormat in lint mode, pointing out what it's going to change when run.
Applies SwiftFormat to nearly all code -- exempts a few externally-sourced files and generated code.
Fixes#1437.
## Summary
Fixes the optionality on the text providers in these two styles.
## Any other notes
Went through all of the complication definitions, again 😆, and these were incorrect optionality. It will be nice to move these to the watchOS 7 init methods which are less…problematic.
- Bezel Circular Text has its text provider optional, we do not need to force it.
- Rectangular Standard Body has 3 text providers: header, body1 and body2. Only header and body1 are required, body2 is optional.
- Reverts #1418 - there's enough logic that is relying on the single-threadedness of then/map-ing on a shared queue.
- Forces all `Current.api` access to be done not on a queue intentionally, to avoid thread jumping when we don't expect, which is the core crash that this was trying to fix.
Replace #1013.
## Summary
Keeps track of what sensors we've sent up during the session and only pushes up changes.
## Screenshots
Just tabbing around between apps on Mac:
```
14:49:15.876 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
14:49:16.561 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
14:49:17.422 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
14:49:30.550 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
14:49:32.363 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
```
## Link to pull request in Documentation repository
No user-facing changes.
## Any other notes
Unlike #1013, this does not persist the sensor values to disk. This is a place that can be improved, but there are some unanswered questions/complications with storing to disk (especially around migrations and cleaning up the values when upgrading and when hardware devices change and wrong values are shown) that could probably be solved a little cleaner in the future transparently to consumers of these types.
Fixes#1353.
## Summary
This allows you to use a docked ethernet adapter as the thing to decide whether you are currently internal. This will help hardware without Wi-Fi or with Wi-Fi disabled to use the feature.
## Screenshots
<img width="400" alt="Screen Shot 2021-01-12 at 20 26 28" src="https://user-images.githubusercontent.com/74188/104407176-df106580-5515-11eb-82a0-2b5d4eb23694.png"><img width="400" alt="Screen Shot 2021-01-12 at 20 26 23" src="https://user-images.githubusercontent.com/74188/104407181-e0da2900-5515-11eb-9c2c-773c725cb841.png">
## 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
- Removes some "is this internal?" dead code during onboarding. Probably worth doing the internal/external pull in at this point.
- Pulls some of the class method things on ConnectionInfo into the connectivity wrapper in Environment.
* Allow private complications
* Add string
* Add british string, tea and crumpets and what not
* Move row
* Probably want to save setting...
* No idea when this moved...
* Fix logic
* Tweak migration
Forgot to commit this earlier
* Bump schema
* Flip logic
* Add helper
* Change func name
* Use helper in template func
* Update function name
* Tidy up
Co-authored-by: Zac West <74188+zacwest@users.noreply.github.com>
Words cannot describe how bad SPM is. For the future record, here are the big reasons:
- Xcode fails to find Swift Package Manager Binary Target dependency… FB8743041
This manifests as "cannot find module Clibsodium" or "Realm" or whatever.
- Xcode Swift Package Manager checkout retry has 0-second delay FB8742078
Xcode's built-in version of git/curl has bugs with pipelining, forcing us to replace it with another version to get ci to be more reliable.
- xcframework via Swift Package Manager both statically links to library and embeds it FB8721223
This requires us massaging the output build products because Xcode produces invalid binaries, which fail all the validation Apple does on App Store Connect upload and on Developer ID Notarization.
-----
In total, this means using SPM produces invalid builds, often fails to build correctly, and often fails to check out dependencies correctly. What a let-down.
This resolves a crash on watchOS 6 when a Complication Template is missing required fields (e.g. one of the text providers) and instead returns the 'error' template.
watchOS 7 wasn't exactly better as it would not crash but it wouldn't be obvious about the error happening, so this also improves that situation.
This is a half-measure to telling the user which fields are optional or not when editing the complication, but it should be a _lot_ more obvious when we do not have the information necessary to make the template.
In HA versions prior to 0.117, the template rendering returns strings for floats using `.` as the decimal separator. If the user's current locale uses `,` as the separator, our string to number parsing here fails to understand what the number is. Since it's freeform text, this also needs to fall back to using the locale-aware formatter in case they typed manually something like `0,33`.
Fixes#1188.
This allows for configuring more than 1 e.g. Modular Small at a time. This requires watchOS 7; for releases before watchOS 7 we do not allow a secondary template to be created. This could be improved by allowing swapping between one of the multiple for watchOS 6 and earlier, but I didn't implement this.
- Adds a "Display Name" to Complications. This is optional and falls back to the template type. This is primarily to differentiate complications; the underlying unique ID is just a UUID.
- Enable previews of complications, which is used when selecting them. This is a stripped-down version of the items in the template, usually just an icon provider or one of the text providers. This is largely easier now since we're now requesting templates for all complications, even those not actively visible.
This also changes the flow when setting up initially. Instead of a list of families to choose from at the start, the user must tap the 'Add' button and pick one from there.
Fixes#839.
- Converts to String for the API-like things we provide for template rendering: intent handling and x-url-callback.
- Handles various kinds of results for Complication template handling: tries to smooth values to floats for percentile-based rings and gauges, describes via String for anywhere else.
- Adds a small amount of validation when entering templates in a Complication's Configuration.
Fixes#1177. Fixes#1180.
These styles were using the localized strings as options, which were then not equating. The way the current getters work, their failure to exist in the dictionary it would always use 'ring' for Gauge and 'closed' for Ring.
Replaces Row 2 Alignment (which had a similar issue) with Column 2 Alignment, which is what the complications want. This right-aligns the second columns.
- Moves our background refresh timing from every 5 minutes to every 15 minutes. Apple [documents this](https://developer.apple.com/documentation/clockkit/updating_your_complication) as:
> The system carefully budgets background refresh tasks. You can schedule only one refresh task at a time. If you have a complication on the active watch face, you can safely schedule four refresh tasks a hour.
- When we refresh the rendering data backing complications, we now immediately tell ClockKit to invalidate/refresh our active complications. I'm not sure what was triggering refreshes before, but they were highly irregular. With this change, I can reliably see (at the new timing above) my complications update at around :00, :15, :30, and :45 on the hour.
- Stops restricting complication rendering to only the active complication. This makes switching between watch faces have the most accurate data possible, and is a very small increase in the size of this request/response -- we're already doing a network call, and the biggest cost of a network call is doing one more than the JSON payload size (which is small).
- Reduces how often we do complication updates on the iPhone side of thing. This doesn't help as much as I had thought it did; we're restricted in how often we can push watch data updates, and since we're not (yet?) using the "update the complications" WatchConnectivity feature, we're not necessarily directly forcing an update anyway.
- Reduces minorly how often we execute syncs on startup. If there's any synced Actions or NotificationCategory, this ends up doing 2+ syncs on startup; removing this restriction does 0-1, depending on if there's any synced. It always occurs when changes are made.
One of our top crashes (on all platforms) is crashing when completing the background refresh operation of the Watch Extension's update cycle. I believe this is because the task is being called more than once; presumably because we're mixing multiple types of tasks in one pointer -- communication updates and complication updates, and they stomp on each other.
Another issue here is that we're not using Background Sessions to do the complication updates, when we want to -- when I refactored Webhooks out of the HomeAssistantAPI code path, I neglected to update this Webhook call to handle background updating; it now does.
- Updates complication text rendering to go through the background session supporting Webhook update mechanism.
- Adds support for ring and gauge template rendering. Fixes#1127.
- Fixes, in general, any complication involving a Ring -- none of the values were being persisted in a way it could understand and color was missing entirely.
- Fixes Extra Large's "Simple Image", "Stack Image", "Ring Text" and "Ring Image". Fixes#1165.
- Fixes Utility's Small "Square" image (the size name was wrong), "Ring Image" (same as above), "Ring Text". Fixes#1164.
This is somewhat in prep of being able to make the project file generated, but also just organizes things into more concrete directory structures.
This pulls out _all_ of the build settings from the root level, and most from the target level, into xcconfigs.
The new directory structure looks like:
- Sources
- App
- (everything from HomeAssistant/)
- WatchApp
- Shared
- MacBridge
- Extensions
- Intents
- NotificationContent
- NotificationService
- Share
- Today
- Watch
- Widgets
- Tests
- App
- UI
- Shared
Somewhat intentionally, the file structure under these is not yet standardized/organized.
The project targets are now:
- App
- WatchApp
- Shared-iOS
- Shared-watchOS
- MacBridge
- Tests-App
- Tests-UI
- Tests-Shared
- Extension-Intents
- Extension-NotificationContent
- Extension-NotificationService
- Extension-Share
- Extension-Today
- Extension-Widget
- WatchExtension-Watch
This does not yet clean up resources vs. sources, nor does it handle some of the "it's in Sources/App but it's part of Shared" crossover directory issues.
