Am I doing something wrong or is openhab2 on a raspi super slow

I’ve been trying to get it moved off my server and I had an extra pi2 around so I spent the last two days getting it setup. First, the setup was super slow. It probably took over an hour to finally boot up and get running. I thought something was broken and tried fixing/reinstalling but it seems it just takes that long to start up. Now I’m having issues where there is a 3-5s delay between when I issue a command and it executes. Top shows load very high(3-4) most of the time. What am I doing wrong or is the pi just underpowered for this job?

Running OH2 on a RPi just fine here. Less than 2% CPU and 24% MEM for my java process.

Can you tell what is consuming your cycles?

Command line “top”.

Are you running headless?

I’m using the default openhabian, I don’t think it’s headless by default. Top just shows java

Is there a way I can find out what’s causing it, maybe it’s a binding?

What Java VM are you using on your Pi, openJDK or Oracle?

I also had big performance issues on my RPi3 when using openJDK which got resolved when switching to the Oracle 1.8.0 JVM. If I remember correctly the performance boost was due to the Oracle JVM using hardware for floating point operations whereas the openJDK used software floating point operations.

1 Like

openJDK, is there an easy way to change it? I haven’t found a simple tutorial online and I’d hate to bring down my system over a screwed up java install.

I’ve also read that you use openHABian. The newer versions use the Zulu JVM. That one should also have the optimizations. It then does not make sense to change your JVM.

Can you see if the output of the command java -version contains references to Zulu, e.g. something like this:

openjdk version "1.8.0_121"
OpenJDK Runtime Environment (Zulu (build 1.8.0_121-b15)
OpenJDK 64-Bit Server VM (Zulu (build 25.121-b15, mixed mode)

If you are on the Zulu JVM you could try to stop/deinstall all bindings you use and then start/install them one by one to pin point which binding is causing the load.

On my Pi3 starting openHAB may take a couple of minutes. The first time big (modified) rule files are triggered may also take some time.

It does.

OpenJDK Runtime Environment (Zulu Embedded (build 1.8.0_121-b42)

I tried the oracle version and it didn’t help so I switched back because the cloud connector doesn’t work with the older oracle version. I might have to start disabling bindings to see if it’s one of those. Would moving it off and SD card help or is most of it loaded into memory?

I think the RPi2 is really a bit underpowered. I tried it some time ago on a RPi 2 and I can remember that openHAB needed some minutes to start.
Now I am using a RPi3 and I am happy with it. openHAB starts within some seconds and performance is absolutely sufficient (I am using InfluxDB and Grafana on the same Raspi).

I don’t think that will help according to your top screen shots. At the top it says 94.6% us. See this explanation of the abbreviations:

us: user cpu time (or) % CPU time spent in user space

If the SD card would be the bottleneck it would spent time in wa:

wa: io wait cpu time (or) % CPU time spent in wait (on disk)

Also after files have initially been loaded from the SD card they will be cached in memory.

So checking the bindings would be useful. You could also check if it is caused by rules by commenting/uncommenting them or moving them temporarily to another directory.

That’s what I’m thinking, everything I’ve read showed only small gains in performance for the 3 but maybe that’s just enough to help. Startup (when I can start using it) takes 5-10 minutes easy right now.

I’m going to try to overclock it, see if that helps and if it does maybe I’ll just upgrade.

That should not be an issue.
openHAB / openHABian works just fine on both my old RPi 1B+ and the RPi0W. The Pi will idle at ~10% (out of my head). I’d probably still not recommend them for a bigger setup though (especially if there’s also InfluxDB and Grafana in the game).

@ryandetzel could a part of your configuration be the culprit? Wrongly configured rule, malfunctioning binding?

Regarding Java: Do not use OpenJDK! Oracle or Zulu are both fine.

Maybe I’ve overlooked that above, why didn’t/don’t you use openHABian?

I’m using openhabian. I’m using the same setup that I was using on the VM and nothing was (that I know of) wrong when it was running on there. It’s really noticeable when there is a delay, like right now I issued the Bedtime command it took over 20 seconds to actually execute the rule.

2017-04-25 21:19:26.291 [ItemStateChangedEvent     ] - Bedtime changed from NULL to ON
2017-04-25 21:19:26.353 [ItemCommandEvent          ] - Item 'Bedtime' received command ON

2017-04-25 21:19:48.340 [ItemCommandEvent          ] - Item 'Cabinet_Lights' received command OFF
2017-04-25 21:19:48.404 [ItemStateChangedEvent     ] - Cabinet_Lights changed from ON to OFF
2017-04-25 21:19:48.674 [ItemCommandEvent          ] - Item 'DiningLight_Dimmer' received command OFF
2017-04-25 21:19:48.695 [ItemStateChangedEvent     ] - DiningLight_Dimmer changed from 100 to 0
2017-04-25 21:19:48.773 [ItemCommandEvent          ] - Item 'EntryLight_Switch' received command OFF
2017-04-25 21:19:48.830 [ItemCommandEvent          ] - Item 'HallwayLight_Switch' received command ON
2017-04-25 21:19:49.078 [ItemCommandEvent          ] - Item 'IslandLights_Dimmer' received command OFF
2017-04-25 21:19:49.304 [ItemCommandEvent          ] - Item 'FireplaceLeftLight_Color' received command 0

I don’t think this is a zwave issue because the OH logs don’t even show it issuing the commands until after a long delay. The rule is pretty basic and again this was working fine on the VM. It’s as if everything is in queue to execute and it just takes a while which is odd.

rule "Bedtime"
  Item Bedtime received command
    logInfo("FILE", "It's Bedtime " + receivedCommand)

    sendCommand(Cabinet_Lights, OFF)
    sendCommand(DiningLight_Dimmer, OFF)
    sendCommand(EntryLight_Switch, OFF)
    sendCommand(HallwayLight_Switch, ON)
    sendCommand(IslandLights_Dimmer, OFF)

    sendCommand(FireplaceLeftLight_Color, 0)
    sendCommand(FireplaceRightLight_Color, 0)
    sendCommand(LivingRoomLight_Color, 0)

Also, that log in the rule prints out at 21:19:48.261 which is right when everything is executed so that seems fine it’s just why is there such a delay from when OH gets the command until the rule fires?

I have a significant delay on my Pi3 as well. But only the first time an event is triggered from a rule file. Thereafter things are normal. My guess is that initial delay is due to lazy loading and just-in-time compilation.

Does the load go away when you run OH on your Pi with no bindings/rules? The problem with performance issues is that all threads want to use the same limited CPU resource. So even if just one openHAB thread is keeping your CPU busy, the performance of all other threads will suffer. Very simple code/rules may thus also start performing slow due to this.

Hey guys

same here, my setup is super slow as well (RPi3, latest version ob openHabian and OH2.1, 3 bindings (KNX, Hue, Zwave) installed, 1 persistence service (mysql).

Some examples (rough measures, just counting seconds):

  • opening Paper UI: up to 10 seconds
  • opening habmin: up to 120 seconds, any click there at least 5 seconds
  • opening classic UI: 5 seconds
  • click in classic UI to go to sub-section: 2-3 seconds
  • basic UI: charts loading takes up to 60min, sometimes I lost patience to wait…

Tasks: 127 total, 1 running, 126 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.7 us, 0.3 sy, 0.0 ni, 96.8 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 994232 total, 609764 used, 384468 free, 31672 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 168456 cached Mem

openjdk version "1.8.0_121"
OpenJDK Runtime Environment (Zulu Embedded (build 1.8.0_121-b42)
OpenJDK Client VM (Zulu Embedded (build 25.121-b42, mixed mode, Evaluation)

What is wrong here? Any ideas how I can improve?