From a45785cd88c148e01f48423242b82ad1c5f051cf Mon Sep 17 00:00:00 2001 From: Philip Abbey Date: Sun, 28 Jan 2024 13:16:57 +0000 Subject: [PATCH 1/2] Update Templates.md Added template example with float number formatting. --- examples/Templates.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/examples/Templates.md b/examples/Templates.md index 8c78fe2..da09712 100644 --- a/examples/Templates.md +++ b/examples/Templates.md @@ -45,6 +45,16 @@ The first two keep to the simple proposal above. The last combines them into a s } ``` +In order to keep the formatting of floating point numbers under control, you might also like to include a format string as follows. `states()` seems to return a `string` that needs converting to a `float` before the `format()` call can manage the conversion to the required number fo decimal places. + +```json +{ + "name": "Hallway", + "type": "template", + "content": "T:{{ '%.1f'|format(states('sensor.hallway_temperature')|float) }}°C, H:{{ '%.1f'|format(states('sensor.hallway_humidity')|float) }}%" +}, +``` + ## Conditionals Anything between `{%` and `%}` is a directive (`if`, `else`, `elif`, `endif`, etc.). Conditionals are used to dynamically change the content based on the state of the entity. From 5de67382bce46e8e3a6f0b15199b664a2aff64ff Mon Sep 17 00:00:00 2001 From: Philip Abbey Date: Sun, 28 Jan 2024 13:37:54 +0000 Subject: [PATCH 2/2] Update README.md More explanation on the polling chain for status updates. --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 87c73ff..43263de 100644 --- a/README.md +++ b/README.md @@ -249,7 +249,9 @@ Home Assistant will inevitably change the state of devices you are also controll The per toggle item delay is caused by a queue of responses to web requests. The responses fill up a buffer and in early testing we observed [`Communications.BLE_QUEUE_FULL`](https://developer.garmin.com/connect-iq/api-docs/Toybox/Communications.html) response codes. For a Venu 2 Garmin watch an API call delay of 600 ms was found to be sustainable (500 ms was still too fast). The code now chains a sequence of updates, so as one finishes it invokes the next item's update. **The more items requiring a status update that you pack into your dashboard, the slower each individual item will be updated!** -The thinking here is that the watch application will only ever be open briefly not persistently, so the delay in picking up state changes won't be observed often for any race condition between two controllers. As a consequence of this update mechanism, if you request changes too quickly you will be notified that your device cannot keep up with the rate of API responses and you will have to dismiss the error in order to continue. The is a _feature not a bug_! +The thinking here is that the watch application will only ever be open briefly not persistently, so the delay in picking up state changes won't be observed often for any race condition between two controllers. As a consequence of this update mechanism, if you request changes too quickly you will be notified that your device cannot keep up with the rate of API responses and you will have to dismiss the error in order to continue. This is a _feature not a bug_! If the application reduces the rate of "round robin" status update requests it becomes less responsive to external changes. + +To prevent excessive battery usage, set the application timeout in the settings. This will prevent you from leaving the application open and forgotten when not being used, and the polling mechanism will then cease, saving battery life. Again, the thinking here is that the watch application will only ever be open briefly not persistently, and hence not be a constant source of battery usage unless the [background service](BackgroundService.md) for sending any watch status is used aggressively fast. ## Changes to the (JSON) Dashboard Definition