Can you share a screenshot of how the testing version looks on CarPlay, please? (Via DM is fine to not sidetrack this thread)
Not entirely. There are 3 options (it is a global sitemaps setting):
- No sorting
- Sort on name
- Sort on label
I agree this is limited. But you can always handcraft the list of items in the group and it gives much more control.
Well, this is not unrealistic.
E.g; My Kids should get a different UI to ensure they do not break things. Not security, but obfuscation, I know.
But compare me and my wife:
Different things are important to us, we drive different cars, relevance of items if not the same as we have different workflows over the day.
So having a tailored UI per user makes sense, especially for such tiny screens as on a watch.
I do not mind starting the AC in my wife’s car, where she’s not interested in SOC of my car. Same for controlling things on the more technical side of life like the solar production - my home turf, she does care much less. Kids are more interested in opening the garage to get their bikes - there are many reasons to have it personalized.
On the other hand:
A real user-profile driven UI in openHAB? As there is no real authorization/role concept on OH itself why force the watch app to come up with it. As soon as this becomes available on openHAB itself we could adjust - for the time being I can live without. A workaround might be to be able to select the root item/tile when setting up the device. Based on that different UI navigation trees could be shown.
Configuration
To some extend this leads to the way configuration is currently handled and the resulting limitations / usability problems (See my post above):
Going for metadata leads to creation of multiple items just as carriers for the metadata.
I’d prefer to have a central YAML configuration - this would be easier to work on, more flexible and would cause less overhead. No need to walk through multiple items and change configs or even create dummy items as carriers for config only.
Question is what is possible with the current OH Cloud connnection. To my understanding it was for sure the easiest thing to query for items with metadata - but that comes with some tradeoffs.
Utilizing the native UI style and technology on a device makes much sense for usability. So please let us not try to display and use sitmap UI on a watch. The interface of a watch does not fit well to a sitemap (why is in my opinion a legacy thing and should not be basis for this approach).
I know you said it’s your opinion, but just to make sure a fellow reader gets this correct: sitemaps are not a legacy thing in the view of the OH maintainers, who mostly agree with what @Mherwege summarized a few posts above.
Nevertheless, nobody suggested that we should/want to use a full blown sitemap (including WebView or map widgets and whatnot) on a watch. What was suggested is to use a sitemap definition as ‘carrier’ for item/label/icon combinations to be included in the watch UI. I do think, though, that in general a sitemap could work, though, in a limited implementation. Why would a list of text, switch, rollershutter etc. widgets not work if the switch or rollershutter opened a separate page to do the control, similarly to how @gbicskei’s app does dimmer/setpoint control?
It will show the metadata on the code tab so, I would expect the metadata to be included in a copy/duplicate also. I think this is either a regression or an omission. An issue should be filed on openhab-webui I think, as I think that’s where that is implemented.
I was wondering about that myself and it’s one of the things I wanted to try and measure. How much of a battery drain would having a constant SSE connection open put on the watch?
I had not considered that. It is an omission for sure.
One can set visibility based on user role or individual users. It’s not quite the same as having a separate sitemap per user but it comes close.
And it points to one potential solution where the metadata could still be used but there can be a visible to property added to the metadata. But in the end, I wonder if having a way to create a wholly separate config for each user would not be more appropriate and I love consistency. Everything else uses sitemaps so that would be more consistent.
I would not characterize it like that. Others have already said what I was going to. Sitemaps are still maintained, new features are being added, and improvements made on every OH version. It is not legacy, it is an alternative UI.
This is not the intent of the project I think. Sitemaps are not going anywhere and they have a very large user base.
Sitemaps can be created in MainUI. No separate file to maintain even with sitemaps.
Nice to meet you! The Items my wife and child are interested in are different from mine. There is overlap (e.g. controlling the garages) but, for example, she doesn’t need to see my bedside lamp and I don’t need to see hers.
I thought sitemaps followed the Default Widget Order Index metadata. If not that could be used. That should probably be implemented in sitemaps anyway. But that doesn’t help with the per-user configs.
Having gone through the tagging of a few Items I agree. From a UX perspective, I’d prefer to be able to set up the watch widgets in one place, not by going to each Item individually. Though this was addressed in the roadmap in the OC that talks about a UI configuration page in MainUI to set it up.
I tried not to overlap with what’s already been said. I agree with @maniac103 and @Mherwege regarding sitemaps not being legacy and demphasized.
Apologies for the “legacy” wording, been on openHAB since v2, used sitemaps for years myself, no offense intended.
The reason I went with metadata: the tile needs things like commandItem, valueItem, commandValue, needsConfirmation. I borrowed these from MainUI’s oh-cell widget, which already has actionItem, actionCommand, confirmation dialogs, etc. While I used sitemaps I missed these capabilities (e.g. show sensor state, command a different switch, require confirmation), or maybe I used them wrong. When I started this watch project it was natural to carry them over, stored on items so the watch can fetch everything in one REST call.
Happy to explore a hybrid or alternative if there’s a better way.
Regarding the SSE connection: it is opened only when the tile is active. In case of the complications I believe the OS queries them every ~15min. Or if you tap on them and the details activity opens it will also fetch a fresh value…
Per-user configuration: in our household we use one account for the family. I’ve tried the other way but ended up maintaining all the phones… Maybe you did something better…
It’s kind of set it and forget it. I created everyone their own account to log in to, and configured their initial screens. Haven’t needed to do anything since then. Most of the house runs itself in the background and someone only mentions something when it doesn’t work (why are the lights not on?). So there isn’t much that needs to be manually controlled, just a couple of lights and the garage door openers. But which lights each individual cares about will be different.
@gbicskei I can report, the app is working on a Google Pixel Watch. Thanks for the work!
One thing i don’t get: To control a roller shutter I would need three buttons: Up, Down, Stop. But I have only one item for the roller shuter. Where do I put the Metadata for the remaining two Buttons?
that is not supported yet…
Similar thing as for my fan example from above.
I managed it by having a technical “fan” navigation tile pointing to a screen showing command tiles.
Unfortunately this requires to have n (in your case 3) “technical” items not linked to anything just to carry the metadata as a workaround.
An idea would be groups: If we could use a group item as navigational tile that in the target shows the contained command items (tiles), taking the order from e.g. the ordering defined for lists. But even there you likely require some technical-only items.
Overall this shows the limitations of the item-metadata-tile linkage, a central definition of the watch UI where tiles as primary elements get linked to items and are put into an hierarchy might solve these dependencies.
openHAB Wear OS App 1.0.0 — now with a Phone Companion
The openHAB Wear OS app just hit 1.0. The headline: a full phone companion app so you can configure your watch tiles without squinting at a tiny screen.
What’s new since the last beta (0.9.0-6):
Phone Companion App
- Visual Tile Design editor — pick icons (MDI / Material / openHAB), arrange items, preview the layout
- Complication editor — per-type config with pattern validation and metadata import from your openHAB server
- Theme selector — choose a color theme on your phone and push it to the watch
- Connection setup with encrypted credential storage + sync to watch via Data Layer
Watch Improvements
- Watch face complications — display item values directly on your watch face (SHORT_TEXT, LONG_TEXT, RANGED_VALUE, MONOCHROMATIC_IMAGE)
stateDisplay: nonemode — icon-only items without text clutter- Dedicated control screens for color picker, roller shutter, and choice lists
- Improved tile rendering, SSE reconnection, and disk caching for faster starts
Configuration
- Tile config moved from item metadata to JsonDB — configuration is now managed entirely through the phone companion editor and stored server-side, no more manual metadata editing
Download: Playstore
The link did not work for me, nor did searching for habdroid or openhab.
OK maybe a dumb question - but what’s the config server meant to be? is that the local URL of the openhab server?
This is in internal testing phase. Let me know your email in PM and I’ll add you to the testers list.
Throwing in the Garmin app:
It also uses Sitemaps and only supported a subset of Sitemap widgets.
I was not clear enough… the main server is what the watch uses at runtime - it can be myopenhab.org or your local instance if it’s exposed to the internet. the config server is used by the phone app when you’re configuring tiles and complications. it should be your local openHAB server, because myopenhab.org doesn’t support the REST write operations needed to save the configuration.
Thanks for the feedback. I’ve already moved away from item metadata. The config now lives in JsonDB as UI components (wear:tile-page:{uid}), same pattern MainUI uses for other pages.
With a sitemap approach I’d lose some features I dreamed into this app (complications, separate command/state items, confirmation dialogs, inverted state display, aggregate state, etc.)
The phone companion is a temporary solution on my side for editing this config. The proper home for it would be mainui - same as other page types. For credential sync, the official Android app would be the natural place.
If we can align on the architectural approach, this gets integrated and config moves to mainui where it belongs. if not, a sitemap-based alternative will emerge eventually by someone else and this remains my petproject with the companion app. Both are fine - i’m doing this for fun and i’m happy to share with others.
Thanks for letting me test the WearOS app! I’m really glad there is now an option for my Pixel Watch.
Tested Setup:
-
Pixel Watch 4 45mm running openHAB WearOS app v1.0.6 (20)
-
Phone Companion App v1.0.5 (19)
Observations & Feedback:
-
Missing App Error: If the WearOS app isn’t installed, the companion app displays an “Out of sync” error. A hint explicitly stating that the WearOS app is missing would be much clearer.
-
Configuration Fields: Passwords are hidden, but the field stays visible, making it look empty. Clicking “Test connection” shows it was actually saved in the background. It looks a bit confusing, but works fine.
-
Tile Design (Default Page): If no additional page has been created yet, “Main” is displayed as default. However, I can’t edit anything on “Main”—it always shows “Save failed:”, even if I just try to change the layout (e.g., from 6 slots to 1 slot).
-
Tile Design (Renaming): It would be great to be able to rename pages later on.
-
Tile Design (Casing Inconsistency): Page names are always capitalized in the UI regardless of what was entered, but in the deletion confirmation pop-up, the page name appears entirely in lowercase.
-
Tiles (Item Display): Opening the openHAB widget initially only gives a “No items configured.” error, even after creating a page, adding an item, saving, and syncing. I found the root cause: the watch always expects “Main”. If I create a new page in Tile Design, exit, and re-open it, I can create another page called “Main” (which wasn’t possible initially because “Main” was default). Configuring items on this newly created “Main” page makes them display properly.
-
Tiles (State/Icon Sync): Button clicks toggle state and icon out of sync: Click 1 changes the state (e.g., Shelly light: off → on), Click 2 updates the tile icon (inactive → active), Click 3 changes the state again (on → off), Click 4 updates the icon again (active → inactive).
-
Complications: I couldn’t get anything to display. Selecting an openHAB item as a complication on the watch displays “SETUP”. Tapping it allows me to pick from the items created in the companion app, but the complication stays stuck on “SETUP”.
On the Configuration Discussion: From a regular user perspective, I understand that keeping apps consistent is ideal from a developer standpoint (which speaks in favor of using Sitemaps). However, I really enjoy using complications (once they work). If that isn’t feasible with Sitemaps, WearOS wouldn’t be used to its full potential, which would be a real shame.
Gave the companion app approach a try … unfortunately I don’t get past the server configuration screen. ‘Main server’ is fine. For ‘configuration server’ I entered my local one:
- In the form
http://<myserver>:8080I getCLEARTEXT communication to <myserver> not permitted by network security policy(probably need to update policy to allow cleartext traffic) - In the form
https://<myserver>:8443I getjava.security.cert.CertPathValidatorException: Trust anchor for certification path not found(probably need to implement some way to accept self-signed certs)
I could get past this by copying over the network security policy of the OH app, but I’m not sure what I am missing here. Are you all using Let’s Encrypt certificates (or something) for your local server?
I’ll share some more feedback once I get the watch APK deployed (ADB connection times out currently).
From the developer perspective it doesn’t matter much. I see it rather as an issue from the user’s side: we currently have 2 mobile apps (iOS and Android), Apple Watch, Apple CarPlay, plus upcoming Android Auto. All of them use sitemaps, which is why I think having a completely different UX for setting up the Wear OS tile doesn’t make much sense.
Complications are unrelated to this, those always will require a separate setup, similarly to how the OH app already handles tiles for the quick settings on the phone.
As mentioned, complications are unrelated. I’m curious why you’d need separate command/state items, inverted state display or the like, though. Since you (rightfully) mentioned the config should live on the server, isn’t that kind of backend <->UI conversion even more prone for being handled server side?
Edit: Got the watch APK installed now. Did some tile setup and saved it. The phone app now offers syncing it to the watch, which I did; app says ‘Credentials & tile config synced’. I’ve assigned 3/5 slots for now:
But tile arrangement on watch looks both different and wrong (labels don’t match up, one ‘Tor klein’ became ‘Tor groß’):
(Also the icon + label on top look a bit off?)
When tapping either of the 3 items (one is a roller shutter, the other two just execute a command) nothing seems to happen: no UI feedback, no action is performed.