Job #1175: Bundle Size — 15.79MiB (+0.18%).

732170a(current) vs b7270d2 main#1158(baseline)

View job #1175 report View digitaldan:command-item branch activity

Thanks @digitaldan, this seems like a useful feature.

My main worry is the new SSE connection dedicated to it.

As you might know (https://news.ycombinator.com/item?id=30313844) there's a 4-connections limit per domain (not per tab) on these so as the Main UI uses two for normal operation (one for state updates and one for relevant event updates dependent on the current page), then there's the webaudio one (#1422) and now this would potentially introduce another one. So that's up to 4 connections just for one tab of the Main UI, and in that case, if you open another tab (even if it's Basic UI or HABPanel) then it'll start to fail. Won't happen if you dedicate a tablet to displaying the UI but still.

I would suggest trying to try to mitigate that by refactoring these two features (webaudio and UI commands) which rely on a permanent connection so they can share a single one (you can check which features are enabled in localCache and tweak the topics parameter according to it with comma-separated topics in case both are enabled; so it could be e.g.
topics=openhab/webaudio/playurl,openhab/items/${itemName}/command.
Of course all this would become a moot point when/if we eventually switch to a websocket.

This could be a good opportunity to move all this logic to other file(s) (either imported or a mixin) dedicated to these permanent listeners as app.vue is becoming quite messy IMO.

Update, I re-checked and apparently it's 6 concurrent EventSource connections, not 4 per domain like I always thought:

https://bugs.chromium.org/p/chromium/issues/detail?id=275955
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#listening_for_custom_events

Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, which means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com (per Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).

Yeah, the additional connection seems wasteful, i did not think about combining it with the audio sink one, thats a good idea until we can move to a websocket model. Agreed also to look at moving code outside of app.vue.

I still need to test that audio continues to work, but this is ready to be looked at for code review. I also will need to add documentation about these new features. I updated my first post with all supported commands and more examples.

Confirmed that the audio sink works as well

LGTM, and works fine! Really good idea, probably you got inspired by HABPanel's "Switch dashboard with item value"?

Actually, i use https://github.com/vbier/habpanelviewer (well, a slightly modified version), but for our Main UI only, on a bunch of tablets around the house and use it's built in command item functionality extensively for reloading and navigating to pages on events, but this would replace most of that with the benefit of allowing me to use iPads if i need to ( my android tablets are very sluggish with our main UI).

Thank @florian-h05 for the review !

Also, i probably need to write some documentation up on this, I guess adding this to https://github.com/openhab/openhab-docs/blob/main/ui/index.md would be the best path forward?

Given that the title is "User Interface Design Overview", I would not expect the command Item there, however if the title is changed to "User Interface Overview", it could fit in there. If the docs are long, I would say introduce a new page.

I think https://www.openhab.org/docs/settings/aboutpage.html would probably be a better location

Yeah, there already is a section about Web Audio sink support.
However IMHO the command Item should be promoted somewhere else - would be sad if no one notices it.

I noticed that the Audio Sink dosent work after a "Navigate to Page" Command UI is done after a short period of time, unless you manually click the new page. Its like the Audio Sink times out after a while when the Command UI is done (unless you click the page somewhere). This time-out dosent happen with the normal Navigate to Page or after you click somewhere on the screen "After" the Command UI navigated to a new page.

Server Side:
OpenHab: 4.2.0 M1
Ubuntu 22.04.4 LTS

Client/Web Side:
Windows 10
Chrome Browser

That's a limitation of modern browsers:

Please note that due to limitations in Safari (and possibly Chrome as well), a user interaction is required after the first audio stream has been sent to actually play it. This means, that after opening Main UI, the first audio that should be played on the web audio sink is only played after the user interacts with Main UI in any way (i.e. touching the screen is enough). For subsequent audio playback the above is not required anymore and the audio is played immediately.

(https://next.openhab.org/docs/mainui/about.html#web-audio-sink)

In case the command Item tells the UI to navigate to a different page, I guess the same happens.

But it also does it with Edge

I guess it is the same in all modern browsers.
And Edge is Chromium based, if it doesn’t work in Chrome, it likely also won’t work in Edge.