What iPhone model and iOS version is he using? I’m currently on an iPhone 15 Pro running iOS 18.3.2, and the Connect app stays active in the background without any issues.
Here’s a screenshot of the app settings—there’s a “Background App Refresh” option that might be relevant to this:
It may be technically possible to add Wi-Fi support for watches that have it, but the user experience would be suboptimal. The connection isn’t persistent, so the app wouldn’t be able to poll the server continuously. Additionally, each command would require establishing a new Wi-Fi connection, which takes time and triggers a full-screen notification, interrupting the app.
Funny enough, the behavior in the simulator is slightly different - it always seems to return to a position about two item heights below where it was. I tried working around it by explicitly saving and restoring the position, but the result is the same. It looks like the function responsible for setting the position might be buggy.
That said, I’ll include this experimental fix in the next release. If you get a chance, it would be great if you could test it on a real device to see if it behaves any better.
After further testing and investigation, it appears there’s no way to fix this - at least not from within the app. On touch devices, the app has no control over the scroll position when returning to a previous menu. We’ll have to accept the default behavior provided by Garmin.
In addition to several minor adjustments and fixes, this release includes a few notable improvements:
Improved touch interface: On touch devices, the settings menu now appears as a separate entry in the homepage menu, rather than as a parallel menu as seen on button-operated devices.
New developer setting: There’s a new toggle in the settings for enabling command sending via the native REST API. This is not yet supported by openHAB and is intended for developer use only (@florian-h05).
Edge device support: The current-generation Edge cycling computers are now supported, including the Edge Explore 2, Edge 540, 840, 1040, and 1050. While the app was working well on these devices overall, several visual adjustments were necessary to ensure proper layout and usability.
Known Issues (Edge Devices)
Focus indicator bugs (Edge 540/840): The focus indicator does not always behave as expected. On initial menu load, the first item is focused but doesn’t show the indicator. In some cases - especially after returning from the settings - two items may appear to be focused simultaneously. If you’re using one of these devices, I’d appreciate feedback on whether these issues also occur on the physical hardware.
Font scaling limitations: The app dynamically adjusts the font size of menu item labels based on their length. However, the Edge devices have a large visual gap between the large and medium fonts, which can make longer labels appear unusually small. Unfortunately, these devices do not support scalable fonts, so there’s currently no workaround.
Note: The app is still in an early stage of development, so while there is a ticket for every change in this release, not all of them are thoroughly documented.
@Ruben_Perez, let me know how well it works on your Edge Explore 2!
I’ve opened a GitHub ticket to investigate this further. Since this behavior could potentially affect other users in the future, it would be valuable to get to the bottom of it. There are also some additional suggestions for resolving the issue posted in the GitHub thread.
I have problem setting the webhook script… I only use DSL for my scripts (and usually on files instead of UI). I have setup all steps, but script rises me an error on openhab log and doesn’t execute.
Well, finally I managed it with some help of IA. The equivalent DSL script to your JavaScript and also suitable for rules in text files is this (there are a lot of debug info, as I have problems before making it to work):
import org.openhab.core.model.script.ScriptServiceUtil
rule "Webhook Handler"
when
Channel "webhook:Webhook:60449f6298:trigger" triggered
then
try {
val jsonRaw = receivedEvent.toString
logInfo("Webhook", "Raw JSON received: " + jsonRaw)
// Extraer los parámetros del objeto parameters
val action = transform("JSONPATH", "$.parameters.action[0]", jsonRaw)
val itemName = transform("JSONPATH", "$.parameters.itemName[0]", jsonRaw)
val command = transform("JSONPATH", "$.parameters.command[0]", jsonRaw)
logInfo("Webhook", "Extracted values - action: " + action +
", itemName: " + itemName +
", command: " + command)
if (action == "sendCommand") {
if (itemName !== null && command !== null) {
sendCommand(itemName, command)
logInfo("Webhook", "Command '" + command + "' sent to item '" + itemName + "'")
} else {
logWarn("Webhook", "sendCommand missing parameters (itemName='" +
itemName + "', command='" + command + "')")
}
} else if (action == "toggle") {
if (itemName !== null) {
val myItem = ScriptServiceUtil.getItemRegistry.getItem(itemName)
val itemState = myItem.state.toString
if (itemState == "ON") {
myItem.sendCommand("OFF")
logInfo("Webhook", "Toggled item '{}' to OFF", itemName)
} else {
myItem.sendCommand("ON")
logInfo("Webhook", "Toggled item '{}' to ON", itemName)
}
} else {
logInfo("Webhook", "toggle missing itemName")
}
} else if (action !== null) {
logInfo("Webhook", "Unsupported action: '" + action + "'")
} else {
logInfo("Webhook", "No action parameter found in request")
}
} catch(Exception e) {
logInfo("Webhook", "Error processing webhook: " + e.message)
}
end
That’s great to hear - thanks for sharing your solution!
Would you mind showing how your sitemap configuration and item definition look for the element Obrir porta [OFF]? I’m still getting familiar with sitemaps, and so far I’ve only seen status values in brackets used with text elements.
I’ve just uploaded v0.1.0 of the app! This release focuses on bug fixes and enhancements to existing features.
@Ruben_Perez – the state is now separated from the label and stored independently, allowing it to be used by the menu entry when applicable, such as in the case of Text elements.
For myopenHAB users:
There’s a new settings option to suppress errors caused by empty responses. When enabled, toast notifications for these errors are hidden. However, if the issue persists for more than 10 seconds, a full-screen error will still be shown. In my testing, this hasn’t occurred yet - typically only a single response is affected, and the next one works as expected.
I’ll be focusing on further stabilizing the app, so please report any issues you encounter.
In parallel, I’m working on the design for supporting additional sitemap elements. Feedback and suggestions are very welcome! To track this design work, I’ve opened a dedicated ticket: https://github.com/TheNinth7/ohg/issues/92
@florian-h05 has completed the implementation of the JSON-based REST API that enables the app to send commands without needing a custom webhook. This API will be included in openHAB 5 and is also available as a backport for openHAB 4.3.x:
I’ve already got it running on my server - installation was straightforward, and after enabling the REST API setting in the app, control commands are now sent directly via the new API.
There’s also a new app release: in v0.1.1 the settings description is updated to reflect the availability of the REST API.
Huge thanks to @florian-h05 for making this happen!
This looks very cool, especially if direct wifi connectivity would be available in some distant future.
On my 4.3.5, I installed the json rest API. I installed the app onto my watch (Fenix 7 Pro).
But, how do I enter the URL?
When I open the app, the only thing I see is “Configuration URL is missing” in red. I tried touch swiping and buttons up/down, but there’s no menu to be seen.
Did you install the openHAB app onto your watch using the Connect IQ phone app? If so, you’ll need to open the Connect IQ app again, navigate to your watch, select the openHAB app, and then go to Settings.
Garmin watches are not designed for continuous WiFi usage. Maintaining a permanent WiFi connection would severely impact battery life, so the device connects to WiFi on demand only.
When a Connect IQ app attempts to make a WiFi request, the watch:
Exits the app and enters a special “sync mode”, displaying a full-screen message.
Performs the network request via WiFi.
Restarts the app in its normal mode.
This flow is disruptive and not suited to use cases requiring frequent interaction or real-time updates.
In the case of the openHAB Garmin app, the app’s interaction model is based on dynamically fetching and rendering a sitemap. To use WiFi for this:
The app would need to trigger a sync mode at startup to fetch the sitemap.
After the app restarts, it could show the UI - but would be unable to perform updates or send commands without triggering another sync cycle.
This would make the user experience cumbersome.
One app that does make use of this WiFi sync mode is APICall. It is designed around a simpler model: the user configures a fixed API endpoint and payload through the app settings, and the app sends requests based on that static configuration. Because it doesn’t rely on dynamically loaded content or require a live UI update cycle, APICall can tolerate the disruption caused by entering and exiting sync mode for each request. This design makes it a better fit for the constraints of WiFi-based communication on Garmin devices.
What would be your use case for having the app connect via WiFi instead of the phone? Could you live with the limitations for your use case?
