Does open hab require raspberry pie or any other device to operate?

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 :smile:

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 :wink:

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. 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.

Is Amanda free for personal use?

Yes. It’s free and open source.

Wait until the Odroid N2 comes out. 2 SATA ports and I like the fact all cables will exit the same side if they keep it similar to the N1.

Just be careful with any ARM processor that has the big little CPUS as there was/is an issue with java VM when the java threads switched between the cores and this caused Openhab to crash. Not sure if this is sorted or if it requires you to still implement a work around to pin the java threads to the big cores. You will find details on this both in this forum and in the odroid forum with a fix outlined in the odroid magazine. If you have a XU4 and openhab please post if this is fixed in a newer kernal/java update.

The C2 does not have the big little cores and this coupled with the fact the Odroid C2 is an excellent kodi device is why I settled for the “older” C2 with the plan to update to the N2 after it is released and is proven. I then move the C2 to kodi tasks.

I wrote this script to get Openhab running on my C2, but it should work with the other Odroid images as well, just note the big little patch mentioned above.

Short answer is it depends on the device. Emmc and sd are best thought of as the same. It is interesting to know that even in uSD cards there is a very tiny ARM processor that handles wear levelling and other features. There are hacks to turn a uSD card into a MP3 player by reprogramming the arm processor inside the card, pretty cool but getting off topic… The main difference is that emmc MUST implement wear levelling as the standard specifies that it must, with uSD the standard does not specify it has to include wear levelling BUT any decent uSD card will do some kind of wear levelling especially if it is 32gb or more in size.

As for reserving power and watching for power issues to then close open BLOCKS back to the flash it depends on the device and it could easily be done with SD cards or any flash device as well. At the end of the day a raspberry Pix (and other clones) are designed to be sold at $35 and hence they make hardware choices to bring out a fantastic product at that price point. Why make the hardware cost more when 98% of users don’t need the feature, or there is another way to achieve the same result? You can add on a UPS that shuts down the PI pretty easily, the same for the odroid range. You can also do software work arounds.

This UPS is designed for the C2 and it is marketed and I quote
*** “It will significantly reduce the risk of data loss by sudden power-down.” ***

Lastly to give a different view on the topic of how to backup, this how to may be of interest…

1 Like

I just want to say that I’ve successfully upgraded to version 2.5 from 2.4 on my pine 64 SBC. A couple items were clobbered but easily reinstated. the upgrade module stated that it wasn’t tested and therefore to proceed with caution. Forced me to make a backup image of my SD card first, which is good practice nonetheless. The only issue I’m dealing with is likely unrelated to the upgrade, my Google mini audio sink is no longer working, but I think that’s a Google mesh wifi issue related to openhab having to connect to mini over different subnets. Google mesh wifi doesn’t allow you to piggy back DCHP onto your existing subnet. Otherwise everything I’ve originally configured, including existing bindings migrated without issue.