Firstly, thank you to all the maintainers for your work on this very
useful application.
This PR adds the ability to execute Home Assistant commands over Wi-Fi
or LTE, behind an opt-in setting. While not a full "Wi-Fi mode," this
feature allows the app to function in limited scenarios where the phone
is unavailable but the device still has a direct network connection
(e.g. Wi-Fi or LTE).
When enabled:
- The app can launch with a cached menu without phone connection.
- On command execution, the user is prompted to confirm.
- Upon confirmation, a bulk sync is triggered to send the request to
Home Assistant.
This enables basic control even without Bluetooth connectivity — so I
can switch off that pesky bathroom light late at night when I don't have
my phone nearby.
I’ve seen a few issues suggesting similar functionality, and I believe
this strikes a useful balance between functionality and simplicity. That
said, I understand if this doesn't align with the intended featureset —
feel free to close if so.
This PR also adds a few string resources without translations. I'm not
sure if those are autogenerated or user-provided — happy to adjust if
needed.
Requirement for use of the PIN was not being correctly extracted from the options. Goes to show why the security features should not be relied on! A recent compilation fix created this breaking change.
This is the fix to an annoying problem I faced as I was about to compile
the final v2.31 release. Please approve, but **don't merge** just yet.
I'll do that once the full device list compilation succeeds, just to
check if there are any residual issues.
Thanks
This required an update to the SDK to version 8.1.0. The new SDK found some new code warnings for unreachable code previously known to be reached based on stricter type checking, so fixed in this commit too.
Not as the issue requested, but instead pulling the settings from
persistent storage before checking the URL status, preventing
"Unconfigured" being initially displayed when it should be "Checking..."
as coded.
## About this PR:
Being one of those incorrigible fools who want to open and unlock stuff
using my watch, I thought of a way to improve security when calling a
HomeAssistant service from the Garmin App.
This change adds a PIN confirmation dialog that is displayed whenever a
`pin` property has been set in the `tap_action`. Because of the size of
the screen, PINs consist of a sequence of abritrary length using the
digits 1-4.
Due to public visibility of the dashboard config, a pin mask can be
configured in the app's settings to transcode the PIN on the watch for
additional security. Using a cipher for PIN encryption has been
discarded due to the complexity involved in generating the encrypted
PINs for the end user.
The PIN dialog is configured to allow up to 4 erraneous PIN inputs in 2
minutes, a 5th failure will lock the PIN dialog (for all actions) for 10
minutes. Entering a correct PIN will reset the failure count.
## Changes included in this PR:
- PIN confirmation screen
- called whenever a `pin` has been configured in a `tap_action`. This
overrides the `confirm` property. Users without a touchscreen will be
routed to the regular confirmation dialog.
- optional `pin_mask` configuration setting, which will be used to
transcode the digits of the PIN (see documentation change)
- german translation of the `pin_mask` label
- failed attemps and PIN lock are stored in application storage
- Addition of `pin` field to the JSON Schema
- Additions to the docs
Tested on a few devices in the simulator, tested and running as a beta
on a Venu 2 Sq Music.
## Disclaimer:
This is my first attempt at a Monkey C project.
I probably learned more from looking at the existing app than from the
sdk samples. Awesome work!
I added this mainly because I wanted a feature like that for myself,
thought it is a good thing to add and because I was interested in
developing for Garmin devices.
I would be glad if you like the idea and are open to review it and
include it in the app.
I have tried to use coding style and conventions from the existing
project as far as I could see them.
Solution to a race condition with starting updates and amendment to error message presentation on Webhook ID creation failure.
Co-Authored-By: Joseph Abbey <me@josephabbey.dev>
Position.getInfo().* might return null sometimes, so best check and
avoid a numerical error.
@KPWhiver My co-author is away presently, would you mind giving this
simple change the once over? Thanks!
Added 'has' clauses around additional ActivityMonitor.Info fields that
are not present on all devices. I have also checked the other reporting
fields to ensure they are not device dependent.
This change sends the heartrate, respiration rate, stepcount, and floors
climbed/descended to Home Assistant as mobile app entities. There are a
lot more sensors that could potentially be added.
I have only tested this on a Vivoactive 4s as that is the only device I
own.
Let me know what you think and if there are any changes you would like
to see.
Philip Abbey
