I don’t see this happening on my watch with simple switches and a relatively light sitemap. I have the 1.2.0-beta8 and 1.1.3 installed, running openHAB 5.1.1.
Still testing the WiFi version btw, get’s me in the house without phone :-), I will provide more feedback, seems mostly cosmetic.
It really looks like my openHAB instance has slowed down recently. I now found another issue that has actually been present for a long time but becomes much more likely when openHAB responses take longer.
I have just uploaded v1.2.0-beta9, which includes fixes and improvements addressing these issues.
Implement post-command hold time #229
After a command is sent, a sitemap request is executed immediately. If openHAB is slow to process the command, this request may still return the old state, causing switches in the UI to flip back and forth. To address this, you can now configure a post-command hold time in the app settings. After a command is sent, the item state is locked for the configured duration. The default hold time is 0, so if you do not change this setting, the app behaves exactly as before.
Sitemap updates stop after sending a command #230
If a command was sent while a sitemap request was still pending, the sitemap request was cancelled but not restarted correctly. This could cause further sitemap updates to stop being processed. This issue has now been fixed.
Is anyone here using a pure touch device (such as the Venu or Vivoactive series) and able to test the latest beta or stable app version?
I have upgraded to the latest Garmin SDK 8.4, and at least in the simulator there appears to be an issue on these devices that prevents menu items from being selected, meaning the associated action is not triggered, such as opening a submenu or sending a command. When it occurs, the problem is very obvious and effectively renders the app unusable.
The main question is whether this is a simulator-only issue or if it also affects real devices.
This issue does not affect button-based devices (Fenix, Epix, Forerunner, etc.), even when using touch on those devices.
I have just uploaded v1.2.0-beta10 with the following changes:
v1.2.0-beta11 is now available, with various small layout improvements for Edge devices:
Any feedback from actual users of these devices is appreciated. In particular, the focus indicator on the Edge 540 and 840 is not visible at all in the simulator, and on the Edge 550 and 850 it is only a crude placeholder. As a result, I cannot be sure how well the layout works on those devices.
The beta app is now at v1.2.0-rc1, the first release candidate for this version. This is a version bump only, with no changes compared to the previous beta.
I will keep this version available for about a week and, if no new issues are reported, release it as v1.2.0 in the stable app.
1.2.0 beta/rc1 is working fine for me, I can operate the controls (switches) of my sitemap without phone connectivity.
I was wondering however what the purpose is of the “Update Sitemap or Wi-Fi” as the states are not presented on the Garmin sitemap / app. I was expecting that at least the last state would be displayed after loading the sitemap so I can see the last value of items. I understand that these states could be inaccurate, but after loading the sitemap I would expect them to be displayed at least for some time.
My intention behind this update is simply to allow downloading a new sitemap whenever structural changes occur, such as renamed, added, or removed items. The overall idea is that the app should be able to operate entirely over a Wi-Fi connection.
The update is also triggered automatically on app startup if no sitemap is found in local storage. This can happen after configuration changes or following a fatal error.
I intentionally chose not to display item states in Wi-Fi mode, even immediately after an update. Changes can be triggered externally, and sending a command may also affect states in ways that are unpredictable for the app. The state of the item that receives the command may revert or transition to a different value, and other related items may also change their state.
For example, consider a light switch and a separate group switch that includes that light. The app could assume that the individual light switch changes state after a command is sent, but it cannot anticipate the resulting change to the group item.
For this reason, I concluded that the most consistent and reliable approach is to never display states in Wi-Fi mode, even if the data appears to be relatively fresh.
Coincidentally, there was also a small bug in the sitemap update menu item. Even when it was disabled because the app was connected via phone, selecting it still triggered a Wi-Fi sync. This issue has been fixed in v1.2.0-rc2.
Another question: what do you think about using the Wi-Fi symbol as an indicator for Wi-Fi mode?
I am not entirely sure whether it might be misleading. It does not simply indicate that Wi-Fi is available. Instead, it actually means that there is no phone connection and Wi-Fi is being used. That distinction may not be obvious to users.
I am considering replacing it with a crossed-out Bluetooth symbol combined with the Wi-Fi icon to make this clearer. Another option would be to display a Bluetooth icon whenever the app is connected via phone.
However, I tend to see the phone connection as the default situation that most users will be in most of the time. For that reason, I originally decided not to show any icon in that case to avoid unnecessary visual clutter.
Sure makes sense. I have some read-only items in my sitemap (temperature, presence, etc.) where it would be nice to show the status, but I think there is no way in a sitemap to distinguish or tag read-only items, and even then the state may be outdated.
If you ask me I would show a crossed-out Bluetooth symbol with the Wi-Fi icon when opening the app. Alternatively a “no phone” icon could be shown, this may be less “technical”. Inside the app the little Wi-Fi icon on top looks very nice on my round watch screen and a small Bluetooth icon would be nice as well. No icon could mean no Wi-Fi and no Bluetooth?
I have just uploaded v1.2.0-rc6, which introduces a permanent connection mode indicator. It uses a Bluetooth icon for phone connections. When the app switches to Wi-Fi mode, the Bluetooth icon turns red and is complemented by a blue Wi-Fi icon.
I also experimented with phone-shaped icons, but they did not work well within the limited screen space. Even the Bluetooth symbol is not immediately recognizable at this size, but I believe it performs well enough in context.
An interesting challenge was the visual alignment of the Bluetooth and Wi-Fi icons. Because of their different shapes and colors, they appeared clearly misaligned when positioned using purely geometric alignment. I therefore adjusted them visually instead. The result looks balanced to me, although perception still varies slightly depending on the viewing distance.
The screen displayed during the initial Wi-Fi search has also been improved.
If no connectivity is available, the app now switches to a full-screen error view. Previously, this state was indicated by a text message only. It is now presented using aligned status icons for clearer visual feedback.
Let me know what you think.
