Cosmetic: Trimmed whitespace

Thanks @xhemart.

README.md

@@ -459,17 +459,19 @@ Check the latest unresolved [issues](https://github.com/house-of-abbey/GarminHom
 
 6. We are unable to support Edge 540, Edge 840 and Edge 1050 devices at this time. The simulation of these devices has two unexpected errors when toggling or executing taps. We get both `Communications.NETWORK_RESPONSE_OUT_OF_MEMORY` and `Communications.BLE_QUEUE_FULL` even though the memory usage is about 6% of the available RAM. Based on a lead from user @Petucky, both devices are being re-enabled as testing on a real Edge 840 device has proven successful, however we remain unable to support either devices until the simulator is fixed. The Edge 850 device has different display update issues but is functional. Again the assumption is the simulation model is buggy. Please [report](https://github.com/house-of-abbey/GarminHomeAssistant/issues) your experience on real devices to us so we can withdraw support or confirm they are working.
 
-7. We are unable to support HTTP natively (without the workaround specified earlier). This is a limitation placed upon us by the Connect IQ API which for security reasons refuses to work with HTTP requests. There is nothing developers can do about this limitation. See the [Trouble Shooting](TroubleShooting.md#do-it-yourself-setup) guide for an example setup. We would appreciate it if users did not leave poor reviews for the lack of this feature which is beyond our control to fix.
+7. We are unable to support HTTP natively (without the workaround specified earlier). This is a limitation placed upon us by the Connect IQ API which for security reasons refuses to work with insecure HTTP requests. There is nothing developers can do about this limitation. See the [Trouble Shooting](TroubleShooting.md#do-it-yourself-setup) guide for an example setup. We would appreciate it if users did not leave poor reviews for the lack of this feature which is beyond our control to fix.
 
 8. There is a [bug in Garmin Express so that when you use that software to amend the application's settings](https://github.com/house-of-abbey/GarminHomeAssistant/issues/194), the page appears in a random language not of your choice. I would like to thank user [heviiguy](https://github.com/heviiguy) for his work researching the issue, leading to these references that indicate the authors of Garmin HomeAssistant cannot resolve this issue as its a bug in Garmin Express that Garmin are refusing to believe exists! See these pages for details:
    - [Garmin Express - Wrong Language](https://forums.garmin.com/developer/connect-iq/i/bug-reports/garmin-express---wrong-language)
    - [Incorrect language displayed for custom data fields](https://forums.garmin.com/developer/connect-iq/f/discussion/388137/incorrect-language-displayed-for-custom-data-fields)
 
-9. When using Wi-Fi or LTE to toggle a light, the `toggle` will fail when the default or current state of the application's menu does not match the state of the light. The same applies to a cover or other thing that can be toggled. This is because the application is unable to initialise the menu with the current state without Bluetooth. Hence the Wi-Fi/LTE functionality is best used with `tap` items only.
+9. Wi-Fi may refuse to work at all for some infrastructures or devices. This problem relates to the implementation of [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) in the Garmin SDK and is beyond our control to fix. See [Wi-Fi "limits of use"](Wi-Fi.md#limits-of-use) for details.
 
-10. There are memory limits, particularly for older devices. Please see the [explanation of the memory limits](Devices.md) and device support.
+10. When using Wi-Fi or LTE to toggle a light, the `toggle` will fail when the default or current state of the application's menu does not match the state of the light. The same applies to a cover or other thing that can be toggled. This is because the application is unable to initialise the menu with the current state without Bluetooth. Hence the Wi-Fi/LTE functionality is best used with `tap` items only.
 
-11. There is a 32 kB memory limit for Glance views on some devices that mean the code and data for the Glance view is too large to load and the Glance view crashes before any code can intervene to prevent the fatal "Out Of Memory Error". Nor is it possible to disable the Glance view in the [application manifest](./manifest.xml) on a per device basis. The simple advice is, for older watches affected, do not try to use the Glance view. To see if your device is affected, please trawl the [devices page](./Devices.md).
+11. There are memory limits, particularly for older devices. Please see the [explanation of the memory limits](Devices.md) and device support.
+
+12. There is a 32 kB memory limit for Glance views on some devices that mean the code and data for the Glance view is too large to load and the Glance view crashes before any code can intervene to prevent the fatal "Out Of Memory Error". Nor is it possible to disable the Glance view in the [application manifest](./manifest.xml) on a per device basis. The simple advice is, for older watches affected, do not try to use the Glance view. To see if your device is affected, please trawl the [devices page](./Devices.md).
 
 # Authors & Contributors
 

TroubleShooting.md

@@ -150,6 +150,10 @@ To verify if you have this issue you can use a tool like [SSL Shoppers's SSL Che
 1. Failure to copy & paste keys and URLs leading to minor and hard to see errors in strings, even with protestations they are the same! (No they weren't...)
 2. Accessibility of URLs, hence the above help guide.
 
+## Wi-Fi Not Working
+
+This is probably a TLS issue associated with HTTPS. Please see [Wi-Fi "limits of use"](Wi-Fi.md#limits-of-use) section. You may be able to amend your server's TLS settings. As the application is dependent on the Garmin SDK, there is no application code that can be changed to fix the TLS version. The problem is external to this application and specific to your IT setup, therefore you are supporting yourself to resolve it.
+
 ## Online Web-based Editor
 
 The [editor](https://house-of-abbey.github.io/GarminHomeAssistant/web/) provides the following functions:
@@ -403,7 +407,7 @@ Store-Id: 61c91d28-ec5e-438d-9f83-39e9f45b199d
 Store-Version: 30
 Filename: DCRL0437
 Appname: HomeAssistant
-Stack: 
+Stack:
   - pc: 0x10003b5e
 ```
 

Wi-Fi.md

@@ -16,17 +16,47 @@ With version 3.0 onwards the application now includes the ability to temporarily
 
 4. Remember that you need to be within range of your watch's configured Wi-Fi access point to utilize this functionality. If supported by your device, LTE offers a longer range, but network charges may apply.
 
-5. On some Garmin devices, the HTTPS handshake is performed using **TLS 1.2**. If your server or proxy enforces a higher minimum (e.g., TLS 1.3), you will encounter an SSL handshake error with the message:  
+5. **Transport Layer Security (TLS) settings.** The following insights have been submitted by App users. The authors cannot verify the details in anyway as we don't have the same infrastructure, but we are very grateful these users took the time to share their solutions for others to benefit from.
+
+   Ali Alaei ([@aalaei](https://github.com/aalaei)), [resolved a Cloudflare TLS issue](https://github.com/house-of-abbey/GarminHomeAssistant/pull/266) as follows:
+
+   <div style="margin:30px;padding:20px;background-color:lightgrey;border:1px solid black;border-radius: 10px;">
+
+   On some Garmin devices, the HTTPS handshake is performed using **TLS 1.2**. If your server or proxy enforces a higher minimum (e.g., TLS 1.3), you will encounter an SSL handshake error with the message:
 
    ```text
    HTTP request returned error code = 0
    ```
 
-   This limitation only affects **Wi-Fi/LTE connections**. When connected over **Bluetooth**, the watch routes requests through the paired phone, which handles the TLS handshake and supports newer TLS versions (such as 1.3) without issue.  
+   This limitation only affects **Wi-Fi/LTE connections**. When connected over **Bluetooth**, the watch routes requests through the paired phone, which handles the TLS handshake and supports newer TLS versions (such as 1.3) without issue.
 
-   To fix this, lower the minimum TLS setting to allow TLS 1.2. For example, if you are using **Cloudflare Tunneling**, go to:  
-   `SSL/TLS → Edge Certificates → Minimum TLS Version`  
+   To fix this, lower the minimum TLS setting to allow TLS 1.2. For example, if you are using **Cloudflare Tunneling**, go to:
+   `SSL/TLS → Edge Certificates → Minimum TLS Version`
    and set it to **at most TLS 1.2**. _Reducing below TLS 1.2 is not recommended due to security risks._
+   </div>
+
+   Another user, [@xhemart](https://github.com/xhemart), [reports some research](https://github.com/house-of-abbey/GarminHomeAssistant/issues/292#issuecomment-5360598790) to further diagnose this issue:
+
+   <div style="margin:30px;padding:20px;background-color:lightgrey;border:1px solid black;border-radius: 10px;">
+
+   I ran a direct test against my own Nabu Casa endpoint with openssl s_client, forcing specific cipher suites, and it turns out **TLS version was never the actual constraint**. My server accepts TLS 1.2 just fine (confirmed with `ECDHE-RSA-AES128-GCM-SHA256`). What it does _not_ accept is any cipher suite using plain RSA key exchange (no forward secrecy) — regardless of whether the bulk cipher is a modern AEAD one or an old CBC/SHA1 one:
+
+   Test                                  | Forced Configuration              | Result
+   :-------------------------------------|:----------------------------------|:-----------------------------------
+   Default negotiation                   | —                                 | ✅ TLS 1.3, TLS_AES_256_GCM_SHA384
+   TLS 1.2, RSA key exchange, CBC/SHA1   | e.g. `AES128-SHA`                 | ❌ Handshake failure
+   TLS 1.2, RSA key exchange, GCM (AEAD) | e.g. `AES256-GCM-SHA384`          | ❌ Handshake failure
+   TLS 1.2, ECDHE, CBC/SHA1              | e.g. `ECDHE-RSA-AES128-SHA`       | ❌ Handshake failure
+   TLS 1.2, ECDHE, GCM (AEAD)            | e.g. `ECDHE-RSA-AES128-GCM-SHA256`| ✅ works
+
+   So the actual server-side requirement is **forward secrecy (ECDHE)** — it rejects any RSA-key-exchange `ClientHello` outright, independent of TLS version or bulk cipher.
+
+   This lines up with a bug Garmin itself has acknowledged for the Epix (Gen 2) / Fenix 7: [TLS Certificate issue with Fenix 7 and Epix (Gen 2)](https://forums.garmin.com/developer/connect-iq/i/bug-reports/tls-certificate-issue-with-fenix-7-and-epix-gen-2). Per that thread, when these watches negotiate TLS directly over Wi-Fi (i.e. without the phone relaying via Bluetooth), they only offer legacy RSA-key-exchange cipher suites with no forward secrecy — exactly the class of suite my server rejects. Over Bluetooth the phone performs the TLS handshake instead, which explains why it always works there. Garmin marked that report "Complete," but the thread has follow-up comments disputing that, and no new cipher suites appear to have shown up on affected devices since.
+   </div>
+
+   So, it's a Garmin device side limitation (in some models) of the Connect IQ TLS stack when negotiating directly over Wi-Fi, that might be fixed by amending the TLS settings on the server if you are fortunate. Some Garmin devices only speak cipher suites without forward secrecy, which most modern TLS termination (Nabu Casa, Cloudflare, current nginx/Apache defaults, etc.) rejects by design for good security reasons. There's no app-side workaround available; it would need a firmware fix from Garmin. By "some models" we mean it is confirmed on Epix (Gen 2); likely related on Fenix 7 Pro and Forerunner 265; possibly related on Forerunner 970 (unconfirmed).
+
+   For anyone on the same models looking for a local-network route, of the options in the [README, only #2](https://github.com/house-of-abbey/GarminHomeAssistant#no-https) (local DNS override to `garmincdn.com` serving plain HTTP) sidesteps the cipher-suite issue entirely, since it avoids TLS altogether. You will still need to verify whether these watches actually honour a local DHCP-provided DNS server for that override, or alternatively hard code public resolvers.
 
 ## Video
 
@@ -40,4 +70,4 @@ We emphasize that the Wi-Fi/LTE functionality should be viewed as a 'last resort
 
 ## Credits
 
-With thanks to Vincent, [@vincentezw](https://github.com/vincentezw) for contributing this solution, and to Ali Alaei, [@aalaei](https://github.com/aalaei) for the finer details on TLS.
+With thanks to Vincent, [@vincentezw](https://github.com/vincentezw) for contributing this solution, and to Ali Alaei, [@aalaei](https://github.com/aalaei), and [@xhemart](https://github.com/xhemart) for the finer details on TLS and resolving issue [292](https://github.com/house-of-abbey/GarminHomeAssistant/issues/292).