Hello
Did someone tried already running openhab just the core without any UI like sitemaps webui etc. Why? Just for my knowledge.
Thanks
The openHAB core is self sufficient, and can run without UI at all. There are however some parts which might be suboptimal from embedding/reuse perspective. Primary point is xtext and relatives which are big in size and used for text files (things, items) which you might not need for embedded use.
Beyond that its all good, using same tooling as openHAB distro (karaf maven plugin) you can create a dedicated assembly serving your needs.
Cheers,
Łukasz
1 Like
Thank you for the explanation so far!
I know about your work with connectorio but my question is not about using embedded hardware or anything special. I have someone who is running a pi with 1 gig of ram and in it’s setup there are some rules to do some automation and everything is file based. Now with openhab 4 it’s really pushing it and he doesn’t have a need to control anything and ask me how can he run it without all the overhead also he doesn’t need persistance etc nothing fancy just if this then that so in theory just an plc like. So maybe more appropriate question what would be the steps to run just the core on that pi and some bindings ?
By embedding I really mean use of core in another “assembly” beyond openhab-distro. Same procedure apply - you have to repackage core.
You can do it through tooling I mentioned (programmable way) or manually through removal of certain dependencies (in system folder). Both are doable, however what you get then is just smaller distribution. It might be still insufficient for raspberry 1 and its computing power. Are you running out of disk space or cpu power?
Whilst it’s possible, you’d be saving yourself a whole lot of work by just throwing just a bit more money into the project and buy a pi with more RAM.
Main optimizations you can achieve are:
- removal of automation stuff - it will reduce threads which are created.
- adjustment of core pools to smaller sizes - might cause delays in processing of events.
- adjustment of startup elements - the less things your software require at boot time, the faster system warm up is.
- removal of things/items files in favor of jsondb - again xtext stuff and eventual file watches which occupy resources.
The UI itself is one point, if you look at it, it is large in size and has to be copied over (from system to cache runtime folder), but important part on the way is openhab-core-ui which actually pulls in xtext/model stuff.
I made some experiments recently and it is possible to ditch all of xtext stuff without loss of core functionality (it does not influence event processing), cause all configuration mechanisms which require it, can be supplied through alternative ways.
I’ve been running custom assembly such above for several years and it could stay with memory consumption around 500-700 MB. However my system had 2GB of memory, leaving a lot to serve rest of operating system tasks, plus system still had CPU with 2 cores.
I recall that I had OH 2 running with raspberry 2 and it was taking ages to load. 
plus all the float operations are extremely slow on these.
The problem is memory and also processing power. It’s a raspberry pi 3 very anemic.
So actually the ui will make it much faster ? So ditch all file based stuff and switch to UI hmmm…
This is not an option it’s actually the whole point he is running this pi.
It’s not my system. There is no discussion about putting an Intel NUC or anything else.
I have spare raspberry 2b and 3b, so I can test later one and see how it will work with reduced sizes, just by tracing amount of time to be ready - by so I mean start level 100.
It is not about UI but its dependencies, which cause large copy (io operations) during the boot. The dsl which is used to serve sitemaps, items and things files is fairly large binary. Even if xtext/dsl parser is pure java its complex syntax causes additional load. Parsing of json/xml/csv will be less resource hungry.
Historically there was also mapdb storage which was more optimized format, however it was problematic when file got malformed by any reason.
The loading of rules will always slow down boot process. No matter if you rely on dsl or scripting languages such as js/ruby/python. Each will require interpretation of source files which is resource intensive task from memory and cpu point of view.
Rules which I used on constrained systems were implemented using Java (example connectorio-addons/bundles/org.connectorio.addons.norule/src/test/java/org/connectorio/addons/norule/ActualCopRule.java at 3.0.x · ConnectorIO/connectorio-addons · GitHub) and compiled before making assembly. You might have a look at JRule stuff from @Seaside and see if there is an option to keep compiled rules across restarts.
Addressing what @splatch wrote.
JRule can be used in two ways, you can provide the rules as java-source files, then JRule will compile those source files on each startup (or when they are changed). Once compiled you can remove the source file and keep the compiled class-files. The class-files will be read but not recompiled on each start.
Another option is to provide the rules pre-compiled in a jar-file (Might be slightly more overhead), but they will not be recompiled.
The items will also be compiled on each startup (or if there are any items changed, added or removed). There is currently no way to avoid this, but it’s not difficult to add some config parameter that would tell JRule to not recompile items. If you are interested in using JRule for this I would suggest you submit a feature request for that on github.
BR S
guys i am not a java developer i am playing in the week-end with all this … i also dont have a developer background. @Seaside i am still trying to wrap my head on how a binding gets compiled and working my way around eclipse ide to see if i can poll that unifi access api but i am still a long way from there.
If he really want that raspberry pi i will recommend him to hire an developer like @splatch or upgrade. He just asked me because i am the only one he knows that has some knowleadge about openhab and i was also curious and wanted to know for my personal knowleadge. So yeah its good to know there are options out there but i really have to learn java if i want to step up my openhab game right now i am at scripting level like java dsl a little python … so back to the docs and basement trial and error learning 
But overall i start to undestand why openhab is heading also towards more ui defined and database storage for configuration but i also undestand why file based storage is also important but more hungry thanks to splatch wich i am very gratefull.
And it was distressingly common for it to become malformed.
I’d like to add that JS Scripting also currently has a first run delay caused by the time required to inject the helper library. On RPi 3 running 32-bit people are seeing 20-30 seconds for that first run of a rule.
There is preliminary evidence that moving to 64-bit OS and Java or GraalVM instead of OpenJDK shows a 10x improvement (2 seconds). However, that’s going to exacerbate @stamate_viorel’s RAM problems.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.