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.
After using it for a while today, I felt that the colored connection indicators were somewhat cluttered and not as readable as they should be. Therefore, in v1.2.0-rc7, I switched to monochrome icons, using only a red slash to indicate a missing Bluetooth connection.
I was still not fully satisfied with the Wi-Fi implementation, so I moved the development back to beta stage and revised a few things.
v1.2.0-beta12 is now available with the following changes:
The full-screen views for Wi-Fi search and offline mode have been replaced by the regular menu structure with limited functionality. This simplifies the implementation and also improves usability: when starting the app without Bluetooth, the time spent searching for Wi-Fi can already be used to navigate the menu.
A full-screen offline error is now only shown if no cached sitemap is available.
For better clarity, a new three-color connection status indicator has been introduced:
Here are some screenshots:
On Bluetooth connection:
Searching for Wi-Fi:
In Wi-Fi mode:
Offline:
@mvbergen, if you have a moment, could you please test this again? Of course, everyone else is welcome to test and share feedback as well.
Hi Robert, I did as much testing as I could. Switching to WiFi without a Bluetooth connection (use-case when you arrive back home after an exercise without smartphone), vise-versa, and other conditions with losing or gaining connectivity. All of this works fine and I could not yet find any issues related to the new WiFi option.
During testing I ran into a bug where the app would crash if for a “Slider” or “Setpoint” item a fractional step value is set in the sitemap (e.g. 0.5 which is a frequently used step for a thermostat). This happens both in the stable and beta versions.
I think the visual indicators on the top of the screen or when opening the app are logical and clear and vastly superior to the previous “No phone (-104)” error messages. The functionality you envisaged is there and I am actively using it and very happy with it (and hopefully many other users with me). Objectively (
) speaking Garmin has the best watches considering functionality and battery life and openHAB is the only platform that I can deploy to get the home automation functionality that I need, so I can highly recommend the app to anyone!
As mentioned before I have one functionality that I think would be of value still, but just for consideration, and I understand your reservations. I often check my watch for the status of read-only items such as the inside temperature or the presence of people logged into the WiFi network and these are item values that do not need to be updated very often. Perhaps “Text” items could still be shown or a label can be introduced to specifically show read-only items. But again, not a big deal. I currently can see the presence switches by setting a visibility condition so the item is shown if the switch is on.
I hope my feedback is helpful and again my appreciation for the great app!
Thank you for all the positive feedback, I really appreciate it.
Thanks, I believe I know the cause and will fix it.
Crash when sitemap contains fractional values for Slider or Setpoint items #257
I have created a ticket to collect ideas and continue the discussion.
Has anyone encountered a problem where the Robert app works normally when the phone (Android) is unlocked, but when you launch it while the phone is locked, the attached icon appears on the watch?
Whatever the underlying issue is, the crash definitively should not happen, I need to fix that.
Are you on the stable version or the beta version?
Which watch is this?
Edit: created a ticket for this, if you are on GitHub you could also post details there:
Hmm, that’s strange, but sometimes it loads normally (even when the phone’s screen is locked), so it’s probably not related to the locked screen.
App version v1.1.3 on Fenix 8Pro watch - if generating some JSON or other diagnostics would help, I’d be happy to do so.
Please find video below. Watch is very responsive but once when get out of app with BACK button then opening again didnt work
I’ve just uploaded v1.2.0-beta15.
This version introduces support for color themes, which enables light and dark mode on Edge devices. It also includes a few additional improvements specifically for Edge devices.
The connection mode indicator has been enlarged and is now centered below the menu title to avoid overlapping with the red frame when an activity is stopped.
@g_g_rich could you test this on your device? It would be especially helpful to know whether the new design integrates well with the native focus indicator and if the rendering of the toggle switches has improved.
Floating-point values are now supported for the Setpoint and Slider elements.
This implementation comes with the following limitations:
The reason for the last limitation is that the app must format values locally for this widget and cannot rely on the server-side state pattern. While Monkey C provides basic printf-style formatting, it only supports a subset of the formatting capabilities available in openHAB. It may be possible to implement an openHAB-compatible formatter in the future, but that is for another day.
@mvbergen could you test whether this now works with your temperature items?
@stonke thanks for the video! Could you install the beta version and see whether the issue still occurs? A few things changed in the v1.2.0 betas that also affect the startup routine, so I’d like to use the beta as the baseline for investigating the issue you reported. Here is the link to the beta app: https://apps.garmin.com/apps/b55277ba-9ecd-4082-8b80-692426241291.
First video on 1.2.0beta15 with same sitemap like yesterday
Second video with same app same map(after crash above)
Last video on same beta app but light sitemap (as we have had previously problem with memory on my old venu2)- as you see 4seconds after map loaded Garmin error appear(without any touch(
Thank you very much.
I investigated the issue further and reviewed the anonymized crash reports I received. This is the same problem I mentioned as unresolved when I released v1.1.3. Since then, I have added additional diagnostic code to the app, which has helped me confirm more precisely where the crash occurs.
At this point, it appears to be caused by a bug in the Garmin API rather than in my own code. Other developers on the Garmin forum have reported similar crashes in their apps. The issue seems to be limited to the newest generation of devices. I am seeing reports from Vivoactive 6, Forerunner 970, Fenix 8 and 8 Pro, as well as Venu 4, but none from older devices such as my own Epix Pro Gen 2.
The good news is that I believe I can implement a workaround by replacing the affected API call with my own implementation. This should be possible without too much effort. Unfortunately, Garmin does not have a strong track record when it comes to resolving such issues quickly, so waiting for an official fix may not be very productive. Nevertheless, I have submitted a detailed bug report to Garmin, including source code and error logs.
