You have an item that updates this often. HABPanel is watching for those changes in the EventSource, and logs every change to console before parsing it.
It’s not trying to load. It’s working as expected. It reacts to the changes published by the event source. Your item is changing that often, so habPanel reacts that often also.
Here’s a quick test. Open a new browser window, point it to http://YOUROH:PORT/rest/events
Watch how often your item state changes. This would be just as often HabPanel will parse them accordingly.
Jersey is not ready yet is expected. Habpanel resources (html/css/js/etc) are cached and also uses service workers, which means HABPanel will RUN even in offline mode even when server is not yet ready.
Read my comment about the event source above. It does not matter if the item is configured in HABPanel or not. If you have an item, it will be published through the event source, and publishing those changes are done my OH itself, not HABPanel.
Because that’s how it works. Without the event source, how would HABPanel know anything about your item state changes. Instead of using websockets, HABPanel is using EventSource . It’s a REST call but the connection is kept alive so clients can remain and “subscribe” to those events.
FYI… Im running one HABPanel instance on a chromium browser on a tiny orange pi zero h2 with only 512 RAM, 1.2ghz CPU and I have zero issues with performance.
A dumb question here . . . a 2 word response will suffice.
I run my OH on a raspberry pi 3.
I have a fairly large number of items / rules etc .
If I were to run my OH installation off of a more powerful platform (e.g. I have an old i5 desktop lying at home doing nothing) would the response times in HabPanel be noticably quicker, or will render times still be slow?
At the moment, a page change to a different panel on my MacBook takes a couple of seconds.
The same page change on a wall mount panel (4 year Galaxy Tab) can take 4 or 5 seconds.
I am just trying to figure out whether is worth the effort replacing my OH hardware.
happanel is mainly javascript driven which your browser downloads then runs. This is why you see the performance difference between your mac and tablet.
A more powerful OH server will maybe improve download time but the running and rendering of the pages is dependent on the hardware the browser is running in.
Thanks - I thought this might be the case.
I suspect I’ll potentially see updates to items in OH a little quicker, since some rules may process a little quicker (especially when I have multiple concurrent rules fire off.
I realise that some of my processes on the OH server are inefficient (e.g. I poll the Spotify Web API manually every 10 seconds, I update 4 image items from webcams every few seconds . . each consuming resources and so on)
Irrespective, that was a useful response.
A couple of further questions I have though.
When HabPanel renders a page, I am guessing it gathers ALL item states from the API (irrespective of whether it uses them) - so if I have 1000 items, all 1000 states are ripped as one json packet?
Do tabs, other than the one I am loading, cause any rendering, or is rendering limited to widgets on the current tab only?
If by tabs you mean dashboards, no only the visible widgets are rendered.
To debug performance problems, open the developer tools in Chrome, go to the Network tab and refresh the page. Check the Waterfall column.
If there’s a request, for instance “items”, taking a long time to complete (i.e. a long bar, disregard “events” because it’s a long-running SSE connection as explained above), that might be the cause of your dashboard taking a long time to appear.
That’s definitely too long - what are you running the openHAB server on? I’ve encountered slowdowns like this, and this was caused by something in openHAB (don’t know exactly what, might be the UPnP discovery service) hogging my RPi CPU to 100% and slowing down everything. Even with a few hundred items and half a dozen panel configurations, these requests should take well under 1 second on a RPi, check the CPU utilization and restart openHAB or reboot if necessary.
I still have performance issues with my install… Both chrome and safari tell me continually that the page is consuming too many resources… Look at the Javascript console and I see
Lots of updates for the CPU load state… Anyone know how to throttle that? Especially since I’m not graphing the Cpu load state (But am graphing the memory consumed… But that’s a 2W graph so the updates would seem to be a tad fast)
I have similair issue’s. Not sure what component of habpanel is causing the trouble. I don’t experience this when using basicui or paperui and as far as i know it uses the same rest api. Maybe you could change some update interval setting in the systeminfo binding, not sure if that is supported.
@vzorglub Vincent that’s also what I experience, HabPanel works fluently on my iPad Pro and Ipad mini4 but the iPad mini2 used as wall mount is really struggling. So it does require a powerfull end device
Just an idea but is it correct that habpanel receives updates on all items that are present in the OpenHAB installation?
When I looked at the basic ui it looks like this is using some subscription service instead of receiving all updates.
Correct me if I’m wrong but wouldn’t it be something useful for habpanel too, to make it perform better and let it use less cpu?
I can’t judge on the performance of your setup but what I want to point out is; is it necessary to receive all updates of all items from openhab in habpanel.
Random example: let’s say I use 40 items in my habpanel and my installation contains 400 items.
That means that I receive 90% on overhead on item updates that habpanel doesn’t need.
That’s why I’m curious if it is not possible to work with some kind of subscription service so you only receive updates of items that you have present in your habpanel.
I’m using habpanel on a tablet (Lenovo Tab 4) and the battery drains way faster when habpanel is opened compared to when basicui is open.
You’re right, but that’s because sitemaps are designed on the server so the system knows exactly which items are in it and can prepare a subscription accordingly. HABPanel works only on the client side, so the only way to have a complete state of the system is to retrieve all the items then update them using the rest/events endpoint. There’s no way to filter events with the current API.
I spoke a little too soon. My items are still taking 3500 ms to load, locally.
How do I dig deeper into the items to determine why? if I rename the echodot.items file, it loads fast so its something within this file but how do I work out which item?
I also have a performance issue on Habpanel.
I am running OH2.4 (openhabian) on a Raspi3.
Habpanel is displayed via Fully Kiosk browser on a ACER tablet, Android 6.0, 2GB RAM.
On Habpanel I show besides some Buttons a chart with solar power gains, my power consumption and what I get or put ito the public power network. These are 5 lines displayed. I also have a clock with seconds in the display.
After startup everything works fine, sometimes the clock looses one second, but response on buttons is ok. RAM usage of the tablet is at 1.2GB of 1.9GB total usable.
After a day or so the display gets more or less stuck, the 1.9GB RAM are fully used, the clock ist jumping in 30…40 sec steps.
Next step I decided to remove 3 items from the graph, so having only 2 in display.
With this setup I have no problem, maybe time is max jumping 2…3 sec.
So somehow the graph is eating up memory until game over. Is this a known issue? What can be done?
After a restart of the tablet everything is ok again.
On a WIN10 PC with old Core i5 and 4GB RAM I observe the same behavior.
Running Habpanel in Firefox (and some other open tabs) I started with Firefox consuming 900MB and after 2h it was 2.9GB! So same issue.