Chromium performance - HABPanel & OH2 on RaspberryPi Zero with a touch screen

We run OH2 (2.1.0 - latest stable) with HABPanel native UI showing around 10 items on a 3.5" LCD touchscreen attached to a RaspberryPi Zero (running Jessie) via a stock Chromium (56.0.2924.84) fullscreen (kiosk mode) window.
All is good but the responsiveness of Chromium for INPUT (buttons/switches) is borderline to useless (3-5 seconds). And I am not talking about rendering the change on the UI but the actual input monitored via SSH.
If the same HABPanel page is accessed from my laptop (served from the same RasPi Zero), responsiveness is instant.
If PaperUI is accessed from my laptop (served from the same RasPi Zero), responsiveness is instant.
If the same HABPanel page is served from a RasPi 3 with a touchscreen attached, responsiveness is almost instant.

Anyone experiencing the same issues or who can suggest any solution???

Well, the Pi Zero just isn’t very powerful. It’s basically the same HW as the original RPi. So simply put, it just doesn’t have enough muscle to run the screen and receive the touch inputs and everything else that’s needed. Your own solution of using a RPi 3 is what I’d recommend (or running it on a tablet).


Well we try and keep this as small as possible and RPi3 is big, consumes more current and hence produces more heat.
What troubles me is that RasPi Zero does not seem too busy. Is the type of processing involved that makes the difference.

Saying that, I will try tonight and load PaperUI instead of HABPanel on the LCD to try and spot any difference in the responsiveness. Thanks :wink:

Also try Googling for a browser that’s lighter. I think Chromium is one of the lightest, but there might be something better. And obviously also prevent everything unnecessary from running to lighten the load.

I 've worked in a CPU optimized Version in the past. I use it on an old nexus 7 2012 tablet.

@mikaelgu Been there, done that (for both) :wink:
Running top, I get 0.20 load which should be fine, but still…
Another light browser I used (can’t remember) was not supported by HABPanel and the UI was not working and couldn’t be fixed.
Maybe downgrade Chromium :slight_smile: or upgrade when available for RasPi to see if anything changes.

@csowada replied at the same time… Reading on your post… I think I have work to do tonight :wink:
THANKS! Will definitely report back here.

A bit confused (or it is just too late) as to how to install that repo.
Are there any “installation instructions” or the steps needed to copy the repo files?

EDIT: OK, the repo are the contents of a jar file. How do I pack it to a jar file and where should I place it?

Simply copy the repo to you oh2 web folder and then open the index.HTML in your Browser. No need to compile a jar file.

So, I copied the dir org.openhab.ui.habpanel-increase_cpu from the zip of the repo to:


and then I visited


from the LCD touchscreen attached to the RasPi Zero. I couldn’t notice any difference in the response times so I thought that I need to uninstall habpanel from PaperUI first. I did uninstall it and I think it is slightly faster but no more than 0.5sec faster. I’ll get my stopwatch later to compare just for the complete list of facts.
I use server-side configuration if it matters.

Any other hints I should try?

No, that’s it. Its only an smaller optimization for slower devices.

Either way, thank you for your help :slight_smile:

My guess would be that running openHAB and the browser on the same RPi Zero is going to eat up all its 512MB of memory and will start swapping to the memory card, hence the delays.

Make sure your swap file/partition is not completely filled up and increase it if necessary.

You could also try reducing openHAB’s memory footprint to leave more for the browser.
Excerpt of the distribution’s runtime/bin/inc file:

setupDefaults() {
    # Set up some easily accessible MIN/MAX params for JVM mem usage
    if [ "x${JAVA_MIN_MEM}" = "x" ]; then
        export JAVA_MIN_MEM
    if [ "x${JAVA_MAX_MEM}" = "x" ]; then
        export JAVA_MAX_MEM

    DEFAULT_JAVA_OPTS="-Xms${JAVA_MIN_MEM} -Xmx${JAVA_MAX_MEM} -XX:+UnlockDiagnosticVMOptions "

you could try to set JAVA_MAX_MEM to 256M or even 128M…?

Could you please specify the file as /usr/share/openhab2/runtime/bin/inc does not exist but I get your excerpt in many other files inside /usr/share/openhab2/runtime/bin/ like client, instance (I guess this is the one you meant), karaf and shell.

I try to set MIN to 64 and MAX to 128 in all the files as a starting point to see if I get any difference restarting the openhab2 service every time but I see no change :frowning:

For the record, in my OH2 version (2.1.0) the
are set outside the setupDefaults() but the
DEFAULT_JAVA_OPTS="-Xms${JAVA_MIN_MEM} -Xmx${JAVA_MAX_MEM} -XX:+UnlockDiagnosticVMOptions "
is called with setupDefaults() function.

Ah yes, I think those scripts were reorganized with the recent Karaf upgrade… if you can confirm the options are applied and it doesn’t change anything, then I’m out of ideas in this area :frowning:

the options are applied and it doesn’t change anything

I can confirm :frowning:
I even rebooted RasPi just to be sure.
Is there a way once rebooted to “query” the JAVA_MIN_MEM and JAVA_MAX_MEM ?

Another test I just thought is to run 2 RasPi Zeros at the same time. RPi-ONE for the OH2 service and RPi-TWO for the Chromium browser to load RPi-ONE’s HabPanel URL.

Good idea.

If you run shell:info in the openHAB console you’ll get info about memory:

  Current heap size           95,669 kbytes
  Maximum heap size           249,472 kbytes
  Committed heap size         172,244 kbytes

Better yet, run the main OpenHAB on a RPi3, if space and power consumption allows. It’s going to be a lot more responsive with the more powerful hardware.

I am not trying to just make it responsive. I have seen everything running off a single RPi 3 and is very smooth.
I want to isolate the 2 processes causing most of the load, Java/OH2 from Chromium Browser, and see if separated are still slow. Trying it in a bit so will report soon…

In using RPI3, 2 and 0 over the past couple years I have found the browser to always be the bottle neck.

Inclusion of Chromium was a GREAT improvement - making it usable on RPI3 for many things that were intolerable previously, but…

I have never found any browser acceptable on the RPI0 except for the very rare websites that are very thin, mostly text and minor formatting and even then its ridiculously slow and “experimental” at best.

Unless there is some browser breakthrough in years to come, I suspect you will never be happy running a browser on RPI0 .

That goes double for doing so with a touch screen.