1. attribute is option, so needs a different template in the API call when absent.
2. Automatically derive the format string from the picker step value for any precision of step.
3. Changed all Lang.String representations of numbers to Lang.Number or Lang.Float. I'm keen to remove the use of strings to hold a numeric value.
4. Tidied up and completed some code comments.
5. Adjusted the JSON schema definition. This is still not finished as the 'picker' object is required for 'numeric' menu items and must not be present for the others. Additional schema changes are required for greater precision.
6. Moved fields over from 'data' to 'picker'.
The SDK upgrade called for more careful specification of "or Null" on some fields in classes. The new devices have been added with their resource needs. Need to check if there's an issue with Edge 850 device.
Three bug fixes.
1. Fixed a bug where templates failed to display in toggle menu items
(at least on some devices).
2. Fixed a bug where a menu item requesting to exit on completion
appeared to indicate failure when using Wi-Fi or LTE. The fix uses a
delay in exiting the application modelled as sufficient for a Venu 2
device, so this might need tweaking for other devices. Closes#283.
3. Attempt to fixed an "Out of Memory" bug caused by v3.3 by making
automatic checking for menu updates both optional and automatically
turned off when insufficient memory is available. This last bug is
device dependent and may require another attempt. Closes#284.
1. Fixed a bug where templates failed to display in toggle menu items (at least on some devices).
2. Fixed a bug where a menu item requesting to exit on completion appeared to indicate failure when using Wi-Fi or LTE. The fix uses a delay in exiting the application modelled as sufficient for a Venu 2 device, so this might need tweaking for other devices.
Changed the function parameters on WebhookManager.onReturnRegisterWebhookSensor() to remove the last optional parameter that was causing the error message and this appears to keep the application happy on start up. Looks like an API request race between the glance's last call and the app first call.
Co-Authored-By: __JosephAbbey <me@josephabbey.dev>
HTTP-Headers settings no longer crash the application on the device. Group settings removed as they could be be changed a second time due to a bug in the SDK.
This update adds a note to the “Limits of Use” section explaining that
some Garmin devices use TLS 1.2 for HTTPS handshakes. If a server or
proxy enforces a minimum TLS version of 1.3 or higher, users may
experience SSL handshake errors with the message HTTP request returned
error code = 0.
The documentation now includes:
An explanation of the issue
How to identify the error
A practical solution example for Cloudflare Tunneling users to lower the
minimum TLS version to 1.2
A security note advising against lowering TLS below 1.2
This helps users troubleshoot connectivity problems when using Wi-Fi or
LTE features on Garmin watches with Home Assistant.
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
Philip Abbey
philipabbey
