According to post 154 from @ysc it should not be needed for OH3.
Habpanel “just” needs to make use of the new feature mentioned above.
1 Like
Thanks for pointing out the post. I guess I’m still unclear as to whether the proposed solution to speed up HabPanel was actually implemented or remained just a proposal. If it was implemented, then what we have is as good as it will get. Maybe time for some new, faster display panels. Lol.
Based on what is on GitHub RFC: flexible API/SSE endpoint for dynamic item state updates · Issue #1363 · openhab/openhab-core · GitHub it seems that this feature has been implemented. The question is now, how to use this feature? Perhaps we would need to wait for @ysc to help us understand how we can use this feature in practice.
That’s the backend support that’s been implemented, so it’s available for use (only the main UI uses it currently), “someone” needs to find the time to implement it in HABPanel.
I never got the patch for OpenHAB 2.x working to solve my sluggish HABPanel. But with OpenHAB3 there is a workaround:
Make a separate OpenHAB3 installation on some available computer. I guess the good solution would be a Docker install on my main house server, while I have until now only tested this on a spare Raspberry PI in the house.
On this extra OH3 installation, install only the new remote binding, and add only those items that you would have (or already) have put in the group Group_HabPanel_dashboard.
In habpanel on your primary OH{2 or 3} install, export the json defining your panels, and upload this to your new OH3 install (this is the same as the recommended upgrade procedure for OH2 to OH3 for habpanel)
I used a lot of grep and awk on the Habpanel json file to go from the json file and into an *items file using the remote binding. Remember also to define the “remote” oh server as a bridge.
If I have text file filtereditems with each item I want on each line, I was able to produce an items file with this bash line:
for item in `cat filtereditems`; do grep -h $item /etc/openhab*/items/*; done | awk '{print $1,$2,"{channel=\"remoteopenhab:server:primaryoh:"$2"\"}"}'
The end result I guess is quite comparable to the filtering patch in this thread would give, and my sluggish tablets around in the house are significantly more responsive (the clock widget is ticking every second!).
(I do note that a timeline widget utilizing influx persistence do not work)
Hi Pavel,
Could you provide the Habpanel-Filter jar-File for this Version again?
I’m running on a 2.5.2-1 release, and tried it with the Habpanel-Filter Version “2.5.0-Snapshot” wich is provided further down (with the .txt ending), but when I try to acces /rest/items-filtered? I only get a 500 (“Problem accessing /rest/items-filtered. Reason:Request failed.”).
I checked the console, the binding is installed and seems to be running. Stopping and restarting it didnt change anything.
So I guess it’s a different version …?
thanks!
Hi,
No, I am running myself the same release, so the problem might be elsewhere. Have you tried clearing up the cache?
BR,
Pavel
yes, have cleared the cache and rebooted - but still the same.
I uninstalled the filter-binding, then I get a 404 (like expected). Cleared the cache again, restarted, reinstalled … and then back to the 500 Error (like at the beginning).
Any other Idea what I could try, or what could be wrong?
Just to get it right:
Items should be in a group called “Group_HabPanel” (put 5 items in that group for a test, created it as a simple group w/o a type or a logic). Then the filter binding should work. - right?
The error I’m getting in the log starts like this:
2021-02-15 23:25:41.144 [WARN ] [org.eclipse.jetty.server.HttpChannel] - /rest/items-filtered
javax.servlet.ServletException: javax.servlet.ServletException: org.glassfish.jersey.server.ContainerException: java.lang.NoSuchFieldError: editable
[…]
cheers,
Korny
correct group name is ‘Group_HabPanel_Dashboard’. i will check later this week.
ok, thx.
I just tried it with this Group name, but unfortunatelly same result (also when clearing cache inbetween).
Won’t be an issue having the standard HabPanel running on the standard API in parallel, right? (currently I’m trying just with Postman and a “HabPanel-Filtered-Edition” in the HTML-Folder, having the standard Habpanel still active, so the “rest/items” is still in use)
yes, there should be no issue having standard habpanel running.
Ok…
Going by the Error “NoSuchFieldError: editable” I guess, there’s some versions missmatch.
Unfortunately I don’t have any experience in maven and the rest of the toolchain, so I don’t think it makes sense for me trying to rebuild it with a newer Version.
I guess you wouldn’t have a newer Version ready compiled either?
@zacofunny I finally have the results of my test using a parellel openHAB Docker container to speed up the panels, as I described way up here:
Good news: it works. It’s much faster to run a second Docker container and use that one only for serving HABpanel (and running the remote openHAB binding to connect to my alpha OH instance).
Bad news: I can’t get HabPanelViewer commands to work. I tried everything I could think of to get the connection fixed, but nothing worked. I tried switching over to the alpha OH instance, and they worked immediately. My best guess is that HPV doesn’t like non-standard port numbers (I was using 8082 and 8444 for the HABPanel instance).
For info, my use case is nearly all SVGs and no actual HABpanel widgets. The main impact for me is in SVG animation and the response to button presses on the screen. It’s painfully slow on the main instance but much snappier on the second one.
I guess this leaves me in a place of really hoping there’s a more elegant solution worked out. Even though I like the new Main UI, I really continue to love the ability to run HABPanel full screen on a tablet and load responsive SVGs.
1 Like
I had a bit of an inspiration. I was carefully reading the HPV wiki and noted that HPV and openHAB have three distinct connections. See here for more info.
What I did was set the base connection URL to my alpha openHAB instance (port 8080), but set the start page to my secondary openHAB instance that is pared down with only the necessary items (port 8082). The early results are very promising: commands are received by HPV and performance is similar to my previous openHAB 2.5 setup with the filter installed. I have animated SVGs running on a Nexus 7 so that is no small feat!
Hopefully this helps someone!
2 Likes
Thank you Pavel for creating the filter. I’m running OH 2.5.5 with hapanelfilter on 3 Fire 10HD 2019 tablets, and the filter was the only solution to make them usable. Love it x3! I have OH 3 in beta, but can’t see moving over till this is fixed.
2 Likes
Hi everyone,
Finally decided to migrate to 3.x line and spent 2 days trying to adapt to new build and dependency system. As a result, 3.x habpanelfilter and habpanel are available to download here: Dropbox - openhab-habpanel-3.1.zip - Simplify your life
4 Likes
Thank you!
Does this require OH3.1 or should it work on 3.0.2?
This should work on 3.0.2 as well.
Just one question.
Why ist the file org.openhab.ui.habpanel-3.1.0-SNAPSHOT.jar over 80MB in size ?
The one for OH2.5 was less than 3MB and the original one from OH3.1 is 3MB.
I have not tested it, just wondering why there is this huge difference.