Using openHAB4.0.3 and I’m thinking of splitting my openHAB-instance to more servers (having to to with having one OH with all the physical devices (RS232, USB, …) and one for all the logic.
What does make this a bit weary is, that I’m using solely UI-configuration and I can only export the whole configuration. I could go into the JSON-DB files and delete some from the items and metadata, but that’s even more weary.
Is there a “trick” or something to export the JSONDB into “old” .items .things files and then re-import those somehow?
While it’s true that you all the Items are saved in one file, each entity in OH are saved in different files. So, if you want to separate the logic from the devices (I’m not sure what problem that solves for you and I’m skeptical doing this actually does solve a problem) you’d import the Things and Items and Links to one instance and the widgets and rules to a different one.
You’ll need a copy of the Items on both instances, though those might be easier to recreate assuming you are planning on using the Remote openHAB binding to link the two.
Rules:
Filename
Purpose
automation_rules_disabled.json
rules that have been disabled
automation_rules.json
rules: rules, scripts, and scenes
marketplace_ruletemplates.json
rule templates installed from a marketplace
UI:
Filename
Purpose
habot_cards.json
saved UI elements created through HABot
uicomponents_system_sitemap.json
UI created sitemaps
uicomponents_ui_blocks.json
Block libraries
uicomponents_ui_page.json
MainUI Page configurations including customizations to the Overview page
thanks again for that answer, Rich!
My use case is simply to move all things and items from my central instance to another, to be able to have the RaspberryPi for that appliances directly next to the physical devices (as there’s mostly hardware already in one room or at least next to another). So I can freely move the central instance to whatever place I like to be able to possibly shift it to a docker or more potent machine (rpi 5?, intel NUC, …). My feeling is, that I’ve reached a sheer value of items and things, that even my rpi4 (4GB) is sometimes a bit slow.
the above mentioned tool from Hans-Jörg is kinda what I was looking for, as it allows readouts and updates of merely all OH-entities.
I have to play around a bit, but thanks for your help, both of you.
It is rarely the case where randomly attempting to solve performance problems with “this seems like a good idea” actually works. It really does pay to spend a little bit to determine why it’s a bit slow. Items, by themselves, impose minimal load on OH. The load Things impose depend on the binding implementation. And the overall load may not even be what’s causing the slowness.
There is a known issue with JS Scripting rules on 32-bit ARM where the first run of a rule after it’s loaded/reloaded, can take an unusual amount of time. If this is the case, moving everything to a 64-bit OS/JVM might be all you need to do.
Another source of slowdowns is an overloaded system, usually caused by a lack of RAM. You can easily see if this is the problem by running top or htop on the machine. If you see any SWAP in use and an average system load > 1 that means you’ve outgrown your machine. Maybe moving something like InfluxDB to another machine would be sufficient. That certainly would be simpler than splitting your OH.
Splitting your OH into two instances though is going to be some bit of work, greatly increase the complexity of your deployment, increase the number of points of failure, and may not even address the root problem and you are back where you started.
You’re absolutely right. On the one hand, having items “as is” isn’t that costly.
On my Raspi4, there’s only “pure” openHAB. Meaning, there’s not much other stuff like InfluxDB or other services running. I don’t even have other cronjobs or scripts running outside of OH4.
just to move a bit further away from my own topic!
it just “feels” slow, and sometimes I have to wait for like 30secs or more to have the items listed in the UI or the rule loaded. Even for the cronjob-based rules, I notice some delays after writing the logs regarding the rules to disc (no, not the 20sec delay after each first start - even later on: rule supposed to start every 2mins at 15secs, but logs are only written at 16 or even 17 secs)…
If I compare this to a vanilla installation, then there’s room for more. But yeah, perhaps it’s just a slow SDCard or some other low-level cause…? on the other hand, there’s spikes like this:
…but still, there is something holding back. If it’s the “constant” changing of items? I have around 80 or more items, which change constantly, sometimes every second at least every 5 or 10 secs… Of course it won’t change I guess, it the items are filled via MQTT or via the “native” binding. But still…
back to topic: it would be much easier, to export and import items, or at least have some kind of multi-editing feature in the UI…
CPU is almost never the limiting factor. It should be the last thing to look into.
The primary limitations tend to be RAM, Network, and file IO. And it’s not the overall speed that is the major concern, it’s whether processes have to sit around and wait for a shared resource that they need. In those cases, your CPU use will be low because nothing’s happening. Programs are stuck waiting.
This would qualify to as a relatively modest OH instance. Just based on the Items alone, this should run decently even on an RPi 2. And these rates are pretty reasonable as well. Items is not your limiting factor.
Whats the RAM and system load (system load is how many programs are stuck waiting around and you’ll see it listed in htop)?
OK. Assuming you are using either JS Scripting or Blockly (which uses JS Scripting under the covers), your problem is almost certainly one that is being investigated.
The first time a rule loads it takes an extended amount of time for the helper library to be injected into the rule. We are seeing times of 20-30 seconds for that first run after a load on RPi 3s and 4s running 32-bit Java.
There is preliminary evidence that switching to 64-bit Java (which also requires 64-bit OS) or to the GraalVM JRE as opposed to OpenJDK drops that initial load time down by 10x (e.g. 20 seconds down to 2).
Assuming that this is your root cause, splitting your OH instances isn’t going to improve anything on it’s own unless your “rules” OH instance is a different architecture. Your machine is currently adequate to run OH.
Potential solutions include:
Get in the habit of running all your rules manually after modifying them. Create a rule to trigger all your other rules during startup and possible once a day. You’ll likely need to modify your rules so they recognize when they are manually triggered and don’t do anything to avoid errors.
Test to see how it works on 64-bit OS and 64-bit OpenJDK. Note, 64-bit will require more RAM but you appear to have plenty of room to grow on that front. (Not guaranteed to work. There is only preliminary evidence this works with some reporting success and others no change).
Try using the GraalVM JRE. There is only a 64-bit version of this so 64-bit OS will also be required. (Not guaranteed to work. There is only preliminary evidence this works with some reporting success and others no change).
Move to jRuby which does not have this issue.
Move to an Intel or AMD based OS (the major delay seems to primarily be on ARM processors).
Splitting your OH instances is also viable only if the rules version is 64-bit or running Intel or AMD processors. It would be less work over all though to move everything to this instead of splitting.
