HABmin2 in multiple tabs breaks.

[polarathene]

This issue has been discussed thoroughly here and was also reported to openhab/openhab and redirected to kaikreuzer/openhab-core , both state their repos are not responsible and to forward the issue to HABmin2 and Paper UI repos. I've not been able to recreate the issue with other standard UIs provided in OH2.

[cdjackson]

I don't really plan to do anything about this. There shouldn't be any reason to have two copies open and the fact that it works if you have two different browsers leads me to believe that the issue is somehow in the browser itself.

[polarathene]

@cdjackson That's unfortunate but I understand. The issue is present on all browsers, I've also run into HABmin2(with only one tab) breaking Classic and Basic UI, but only when both are open, closing any UI corrects the issue for any UI.

A simple switch while not appearing to do anything, does eventually trigger the action after 15-20 seconds. I've also done a pure REST request to change the state and it was also delayed unless I close one of the UI tabs which removes whatever delay/blocker was occurring.

I've not confirmed if the multiple UI issue is isolated to tabs in a browser, or that HABmin is responsible for breaking the other UI as it could just be number of UI. It's a concern for users that might have multiple clients to openHAB like a family with iOS/Android app clients as well as a browser dashboard or other clients.

I've brought this up at the kaikreuzer/openhab-core as well where I think it belongs. Thought I'd let you and any other visitors know.

[cdjackson]

That's unfortunate

Why? I'm not sure of the use case for multiple copies of HABmin, or PaperUI in the same browser for the same server at the same time?

The issue is present on all browsers

That's not surprising. Most browsers come from two sources I think.

I've also run into HABmin2(with only one tab) breaking Classic and Basic UI, but only when both are open, closing any UI corrects the issue for any UI.

Really? I don't think that the problem is with HABmin. There are (I believe) two problems. Firstly, running multiple versions of the same app (be it HABmin, or PaperUI) doesn't work. This clearly isn't a HABmin issue since it also happens with PaperUI and HABmin not running.

Secondly, there is a known issue with OH in that it only allows a certain number of connections at once. Therefore, if you run up multiple UIs, then you will hit this limit. This is something I've seen raised as an issue under ESH or OH2. Again, this isn't a HABmin problem.

So, do you think that this is actually a HABmin issue? I don't think there's anything I can do to change this.

[polarathene]

there is a known issue with OH in that it only allows a certain number of connections at once.

I think that was fixed with the PR for this issue which was to do with a low Web Pool Thread size. As I'm running OH2-b3 on the Docker image, I don't have this update yet. It presumably fixes the problem.

So, do you think that this is actually a HABmin issue?

Unlikely. HABmin does seem to cause it more easily than the other UIs, I've been using various ones as each has their own issues(though unrelated to this issue):

• ClassicUI is causing exceptions with certain UI elements/Rules that control items via Groups
• BasicUI doesn't handle UI state that doesn't directly map the value types for item types, such as Color should use Colorpicker. Slider or Switch although supported types get their UI state messed up).
• PaperUI doesn't seem to support sitemaps at all, which makes working with bindings that don't support things generation difficult. I've not found documentation on .things file configuration.
• HABmin has it's own UI issues but as you've said you don't plan to continue support for sitemaps.