Hi,
there are several use cases to be able to create “deep links” to something in openHAB, e.g. a subpage of a Sitemap or a tab in Main UI. These use cases include:
While you could use the links that Main UI and Basic UI in the browser use, there are two reasons not to do so:
The host name may change based on the location of the client (e.g. local or via myopenHAB)
AFAIK Android apps cannot register themselves to handle URLs during runtime, but only during compile time.
The Android app already has some kind of deep links for Sitemaps when writing NFC tags: openhab://<sitemap name>/<path in the sitemap>, e.g. openhab:///uicomponents_page_5d51f534ba/0001. I’m not sure if a custom theme suits well for all three platforms (Android, iOS, Desktop), though.
Other advantages of the openhab:// are:
Backwards compatible with written NFC tags.
For Allow for more customization for device controls entries · Issue #3140 · openhab/openhab-android · GitHub it would be good to have some defined metadata field that can contain a link for more information. Examples: For a group item it can be a Sitemap subpage containing the items in the group. For a webcam image it could be the external web UI of the webcam. Clients can then detect if they should handle it internally (scheme openhab://) or open a browser (scheme http(s)://).
The current NFC tag links must be extended to handle other UIs like Main UI. Maybe openhab://(sitemap|mainui)/<ui specific path>?
It would also be nice to have links like this which can be used to link to mainui settings pages or to install add-ons. Then we can add those to the documentation or use them in the community to make it easier for users to find functionality.
In these cases the client that views these pages (docs and community) is a regular browser that cannot handle openhab:// links at all. This would require some native software to be developed.
openhab://sitemap/uicomponents_page_5d51f534ba/0001: Open subpage 0001 of Sitemap uicomponents_page_5d51f534ba
openhab://uicomponents_page_5d51f534ba/0001: Same as above, for backwards compatibility of existing NFC tags. Shouldn’t be used for new links, though.
openhab://mainui/settings/items/: Open /settings/items in Main UI
openhab://mainui/#card=foo: Open card foo on the start page of Main UI
openhab://notifications: Open the list of recent notifications (only if supported by the client)
Poking @digitaldan as you brought up the idea to specify the page that will be opened when pressing on a push notification.
As the IDs of sitemap subpages may change when editing a Sitemap, it might be good to add some kind of tags to subpages that must be unique per Sitemap, but stable:
Text label="Lights" id="light" {
// Here are some items
}
I think it’s a good idea overall to at least properly specify the openhab: URL protocol/scheme (Uniform Resource Identifier - Wikipedia) but there would be some things to take care of - for instance if you want to link to different openHAB instances, then you would have a need to specify the address to it, most likely with openhab://host:port/..., and if you want to authenticate to them then you’ll need openhab://credentials@host:port/....
Now the scheme might be restricted to a single pre-configured instance, for linking to resources themselves. To link to actual HTTP pages, then we might need a service similar to FAQ – My Home Assistant, where the user specifies the address of their instance, then links to the equivalent service would redirect to “internal” links to that instance.
Hosting a webpage similar to my.home-assistant.io is probably a better solution than using the custom scheme openhab://. With that all client platforms can handle these links, either by the browser or by registering the official apps as handler for this website. Then e.g. the Android app can handle the link fully offline (until it needs to load the content).
Sorry, been really distracted lately ! I still like the idea, they only thing that stopped me from pursing is that our Android firebase/messaging account is not in a good state, and while is working, i can’t make any changes to it. I seem to remember i had to do this, but can’t remember why… but we may need to plan a migration to a new GCM/FCM id. I ended up getting a bit discourage and moved on to another project ;-(
FYI i did add something similar to the main UI, which allows programatic control through an item, with a little bit of work, it could be reused i think for this purpose. I am also now remembering i need to open a PR to document this
Just tried it: What a cool feature!
Now I can realize different behavior on different tablets. Another great feature that’s introduced so silently that you can hardly notice…
I’m planning to put in in the release blog post, but in case @digitaldan wants to write about it himself I’m happy to accept a PR to my branch. Just check out the website repo, where I have a PR for the release blog post open.
