Does OpenHab require raspberry pie or any other device to operate? or can it operated through Server only?
Start here, bottom right
Raspberry pi is popular because it doesnāt consume much power and you will want your home automation to be working 24/7. You can install openhab on most any device. If you have a NAS system like Synology thats already running 24/7 you can install openhab on your NAS.
Iām seeing a lot of success with the ODroid XU4 mini computers.
https://www.liymo.com/index.php?route=mc-odroid/odroid-xu4-starter-set
They are all kinda similar. Thor ODroid XU4 has more memory and 2 USB 3.0 ports but the cost is double compared to the raspberry pi.
You just need to ask yourself how you plan to use the device and select the best one that suits your needs.
1 Like
It can run on just about anything that can run Java. Some intrepid users have even made it run on FreeBSD.
Also note that you can use openHABian on any Debian based Linux distro, not just on an RPi or Pine64. Just use the manual install.
Finally, there is an official Docker image you can use if you prefer.
I myself run on an Ubuntu Server 18 VM running on an ESXi 6.7 server using Docker.
Now thatās interestingā¦
I assume that would include the NodeRed setup too ???
(Not something that Iāve used previously, or had intended to use, but it keeps cropping up when Iām researching)
openHABian, at its core, is just a bunch of scripts. The SD card version of it just kicks off the scripts you can run from openhabian-config. Just follow the manual instructions. Node-Red is under 20 Optional Components along with mosquitto, influxdb+grafana, homegear, etc.
I havenāt used Node-Red nor set up any of the other optional components through openhabian-config so I canāt say to what extent they are configured to work with OH beyond just being installed. But they are there. I do know that with frontail at least, it installs it, configures it to tail openhab.log, and adds an entry to the OH dashboard.
1 Like
Thanksā¦ Sounds intriguingā¦
The next time Iām setting up a machine, Iāll give it a try 
FYI, The SD version is very easy and quick to install and get openhab up and running.
Since you were asking about a RPI and the ODroid I wanted to point out that you can install the SD card version on more than an SD card. Iām using a RPI 3 B+ with a 128G SSD hard drive and no SD card. I simply used etcher to flash the SD card image to the hard drive and no problems thus far. (knock on wood)
1 Like
On a similar note may I ask if anyone had a better experience with boards having builtin memory, e.g orange pi pc plus? I read somewhere those are much faster (70MBps r/w speeds) and reliable than external SD cards. External SD cards have tendency to be duplicated and cloned by fraud companies. The internal memory is reliable because the supplier cannot fool an OEM.
Thatās why I opted for the ODroid 
It has a choice of SD card or Emmc.
Yes thats the word eMMC. They have their own controller and all, they relieve burden from OS driver etc. Technical details aside, I feel the only reason they are reliable is āno one can fool an OEM but its easy to fool a retail customerā.
My sis got 64gb and 128gb cards from a deal, both fake. I advised her to stick with internal memory or buy an SD card from brand showroom even if its slightly expensive.
That is an assertion not born out by the past. How a stolen capacitor formula ended up costing Dell $300m | Dell | The Guardian for one infamous example. An OEM may be more able to avoid being fooled by counterfeits, but they too can be fooled. Supply chain management is a HUGE problem these days and counterfeits are rampant, even with the OEMs.
There are lots of technical reasons why eMMC will potentially be a better choice compared to an SD card. But both use NAND and therefore both are susceptible to wearing out (a NAND cell can only be written to a finite number of times). Pulling the power on eMCC, SD, or any type of storage really with Linux computers, can also cause file system corruption. SD cards are really bad in this regard. HDDs and SDDs and maybe eMMC devices will have a little bit of backup power though to finish some or all of the outstanding write operations after power to the computer was lost which mitigates the potential for corruption some. I donāt know for sure that eMMC does have this, it may depend on the device.
SD card is a mass market. Even the genuine manufacturers may forgo certain quality tests in order to reduce costs and compete and survive. OEMs have always a better understanding of parts they receive than retail customer. There are good batches, bad batches, gray batches of electronics components. They all have their place in the market.
The real question is how painful it is to restore an OH configuration from earlier backup, when a card gets corrupted? At least on same OH version. The Linux and OH software itself can be restored easily from standard images like openhabian or raspbian.
In idea world, the backup should be version agnostic. e.g A 2.1 config backup should still be restorable on a 2.9 system. Because there could be a lot of human effort went through making that config work at certain site. I feel the platform has the responsibility to honor its own config files or even binary bindings from previous stable releases
.
- backup:
openhab-cli backup [filename] - restore:
openhab-cli restore [filename]
For the most part, assuming you have not modified āsystemā files like those in /var/lib/openhab2 you should be able to restore across versions at least as far back as OH 2.1. If you have modified files in /var/lib/openhab2 by hand (e.g. modified the log4j2 config) you might need to double check that those files have not changed.
You would probably want to Clear the Cache after the restore after the restore if you are restoring from an older OH version.
We do not live in an ideal world. To meet that requirement we would have to basically freeze OH as it is now. No new features, no significant bug fixes, no moving forward. Ultimately the problem is we donāt have enough volunteers who are both willing and able to put forth the effort that meeting this would require.
But I can say that for the files that are officially sanctioned to be edited by the users (i.e. those files in /etc/openhab2) for the most part they can be ported from at least as far back as 2.1 with little to no required changes. Whether or not there are changes required depends on whether there were problems with Rules syntax that were not properly detected in the earlier versions (the Rules syntax checker got more strict which is a good thing) or if there were significant additions or changes to a given binding and you have text based Things.
Will openhab-cli backup/restore work on new json store as well? userdata/jsondb. I hear they use jsondb for thing config, bridge config, item channel links etc. I hope I can take a system restore point like in windows.
Of course.
Furthermore, OH takes backups of the JSONDB on its own. You can find those in userdata/jsondb/backup. I donāt know how frequently (on every change probably) it makes the backups but the number of backups to keep is configurable. I also donāt know if the JSONDB backups are saved when openhab-cli does the backup, but it probably does.
openhab-cli will only backup/restore OH configuration. It will not backup and restore the configs for any of your other services like external databases, MQTT brokers, etc. If you want a full system backup, taking images of the SD card or even better using Amanda will address that. Amanda config is available through openHABian or you can install and configure it manually.
Does this mean that openhab-cli backup will not restore my mqtt setting in /etc/openhab2/services mqtt.cfg
Yes, it will restore everything in /etc/openhab2. It will not restore /etc/mosquitto/mosquitto.conf if you are using mosquitto as your MQTT broker on that same machine though.