I’ve just uploaded v0.4.2 with the following changes:
Improved rendering of the light icon on MIP displays (#171).
Enhanced widget handling when no valid state is available (#157, #159).
This update prepares for an upcoming WLAN mode where current states may not be known, and also enables initialization for items in NULL or UNDEF states.
If the state is unknown, toggle switches will now display an action menu with ON/OFF options.
Sliders will automatically switch to releaseOnly mode and start from the middle of the configured range.
Fixed an issue that caused an unexpected return to the root view after loading state (#170).
@florian-h05: Let me know if the fixes work for you!
I’ve just uploaded v0.4.3, which includes two minor changes:
Added a window icon that supports both OPEN/CLOSED states and numeric states (>0 → OPEN, 0 → CLOSED).
Fixed a minor issue where an incorrect error message was shown if a sitemap element had no associated item (typically caused by a typo in the item name within the sitemap definition).
Exciting changes for the Garmin app! The current version has now been released as the first stable and official v1.0.0, published by the openHAB Foundation. The source code repository has also been transferred, and I’ll continue to maintain and develop the app in this new setup.
Important:
Garmin unfortunately doesn’t allow transferring apps between developer accounts. That means you’ll need to reinstall the app from the foundation’s account using the link below:
And while this marks a solid milestone, development will continue – for example, with ideas like Wi-Fi mode and support for larger sitemaps already on the roadmap.
Garmin uses a proprietary programming language and API, so unfortunately, porting this to another platform would require a complete redevelopment from scratch. From my side I‘ll continue to focus on the Garmin app for the foreseeable future.
Hey there, I love to see that there is an GarminIQ app for OpenHAB now. Great work!
But, I’m a little bit sad that it not supports my Edge 1030 plus?
Is there a reason? - I thought it is really close to the Edge 1040.
Is there a possibility to get this app also running on an Edge 1030plus?
An update to the Edge 1050 will be very expensive, only to open the garage door..
In terms of Connect IQ, there’s a significant difference: the x40 series supports the latest API level 5.1, while the x30 series is limited to version 3.3. The app already supports devices with API level 3.4, so I’ll attempt to make it compatible. My initial quick test didn’t compile, but the issues I’ve seen so far appear solvable.
I’ve now removed the legacy apps from my account. If you haven’t done so already, please move over to the official apps under the openHAB account.
@NikM regarding Edge x30 devices: this will take a bit more time. I’ve run into a few additional incompatibilities and need to investigate possible workarounds.
@the-ninth after migration OH4.3.5 to OH5.0.1 (not with upgrade but installation from scratch and moving things/items/maps files) I found that same garmin.sitemap I used before has problem with loading now. There is red sign “Sitemap too large (-402)”.
That’s an interesting observation. The error code -402 indicates that the JSON response exceeded Garmin’s size limit. Since this happens with the same sitemap only after upgrading, it suggests that OH 5 delivers the sitemap JSON differently, possibly with additional attributes.
One workaround you could try is removing a few elements from the sitemap to see if it resolves the issue.
Unfortunately, this is a hard limit on Garmin’s side. On the OH side, I cannot filter out data that the app doesn’t request, so the response stays larger than allowed.
I do have a feature on the roadmap that would allow the app to optionally request pages individually. This would bypass the size limit, although at the cost of slower navigation between pages.
Yes, that could be a way to increase the supported sitemap size. In the other app I’m developing (evcc), the server supports JQ filters in its REST API, which lets the client decide what data to retrieve. I’m not sure, though, how well JQ filters would handle the recursive data structures of the sitemap, or how maintainable that approach would be (developing and testing complex JQ filters is a bit of a pain).
After the summer break, I’ve released version 1.0.2, which adds support for the following devices:
Venu 4 Series
Edge MTB / 550 / 850
Descent G2 / Mk3 Series
Fenix 8 Pro Series
In addition, the frontdoor icon is now supported.
@NikM unfortunately, I don’t have good news regarding support for the Edge x30 devices. During development, further issues arose, and addressing them would significantly increase code complexity while offering little benefit. Only a small number of CIQ < 3.4 devices have the hardware resources to run the app, so for now, support for these devices is not planned.
@the-ninth
I see the problem I reported is a niche one, as no one else has reported it.
Is the problem the structure of the sitemap file itself, or rather the responses generated by the variables contained within it?
As I wrote earlier, in OH4.x, the file worked as expected. It has 61 lines and takes up 2.03 KB (2,081 bytes), which is tiny in my opinion.
For testing purposes, I divided it into four fragments in separate maps – each one worked individually. The next step was to split it in half (about 30 lines each), and that worked as well.
Is there any other way I can help you find the problem? I thought the problem was a single variable that was too long, but looks like the overall size matter.
