The BPi 0 does have a BT chip.
How to get going with OpenHabian on RaspberryPi:
This board is not even mentioned so it can’t have a badge “supported” Download – Armbian This usually makes a huge difference. If they gave you some “armbian” they just try to fool you, like they do it with providing “raspbian”. But that is their policy, a way of doing business …
As I already mention, Bluetooth is not well supported in Armbian in general. It doesn’t work on every boards, where hw support exists, since not enough people care about, but wireless is sorted out, where exists.
Sinovoip (Bananapi maker) have a bad reputation for quality of their design and (many times) wrong documentation. Because of that, their hardware is mainly not supported by Armbian. There are other makers, which provide similar hardware, namely FriendlyElec or Xunlong (OrangePi), Olimex, Hardkernel, … which do their job respectfully.
Please provide a source to support that claim.
What docs are you referring to here ?
That’s the openHABian (not openHAB) docs and I see no mention of hassle or mainstream in there.
Don’t put up misleading statements like that please.
- /var/log is mounted under lzo compressed zram device
- there is no swap file, but memory is getting compressed when there is a need (for swapping).
- root file system is mounted with delayed garbage commit which drastically limit small and most deadly operations for SD card mount - Advantages/disadvantages of increasing "commit" in fstab - Unix & Linux Stack Exchange
- I/O scheduler tuning Improving Linux System Performance with I/O Scheduler Tuning
Ubuntu version also provides an easy switching to full virtual read-only mode, where there is absolutely no writings to the SD card.
This is just for saving SD card related with squeezing more power out of the (limited) hardware.
Perhaps you did not clearly understand my point. I find OpenHAB system documentation just fine. Or at least the one I am familiar with - setting up on the application level.
I am only ranting about recommended way - setting up OpenHabian on RPi looks like more work that my recommendation. Which is just that. A recommendation.
Perhaps not here on OpenHAB forum which is anyway a place for supporting something else. In case of troubles with Armbian, there is an fairly active Armbian forum https://forum.armbian.com. Matured boards doesn’t need much if any support anyway.
1 Like
Yes, I believe that was the point Markus was making, support, tutorials and documentation for other boards not being anywhere near as for the recommended platform. Many of our users are not linux folks, don’t know how to find more information and this forum is one of a very few places to get help keeping their OpenHAB installations running
Thank you for that! You seem to really know your stuff and information you have already provided will help some of our more technically crafty users get on
1 Like
I was just responding to your statements. You said
I asked you where in the docs that’s mentioned and you replied with a link to docs where there’s nothing like that contained. So to me that was a false, misleading statement of yours.
You obviously have a strong background in and preference to use Armbian and some SBC you already know to operate - that’s perfectly fine, in fact the official recommendation is not a RPi but to use whatever you feel most comfortable with.
And any opinion and substantial contribution is welcome - thanks for those pointers.
Those optimizations however aren’t exclusive to Armbian and in fact the most important ones are already part of this recommendation (note the post’s creation date).
But by no means we accept ranting or false claims.
Setting up openHABian on RPi means to flash the image to the card, then boot and wait for the installation to finish… I can hardly think of any other method to be even less work for a user - so to me, the “more work” statement is another false, misleading one.
To the average OH user, support is of uttermost importance (@Andrew_Rowe expressed it well).
And the best support you will only get when you stick with the mainstream.
Latest Odroid n2 https://www.hardkernel.com/blog-2/odroid-n2/ (4GB ram) seems to be very nice platform for OH application.
1 Like
Which is why I said I cannot recommend just any SBC and as Markus elaborated, this kind of knowledge and research is beyond what we should be able to expect from the toe of user who would need a hardware recommendation in the first place.
This entire thread is only tangentially about what is the best hardware. It’s about the best hardware to recommend to new users who are not technically proficient enough to figure that out on their own.
With that criteria, market share/mind share both here in these forums and on the internet at large and availability of the hardware will trump technical superiority every time.
And it’s worth noting that openHABian also installs and configures a host of third party applications to work with OH, not just openHAB itself: Mosquitto, InfluxDB, Grafana, NodeRed, Amanda, ngnx reverse proxy, Frontail, Firemotd and more. And many if not most of the optimizations for SD card writes are it could be included in openHABian. But, as I said, weed caused by OH itself and any databases set up for persistence will far outpace the writes Armbian configures to reduce, and the database stuff can’t be reduced. So the optimizations are if limited value in this context anyway.
And for the record, you can install openHABian on Armbian. Just clone the repo and run through openhabian-config. But if course cloning a github repo is beyond the audience this recommendation is directed towards RPi with the openHABian SD image which sets it all up for you.
Not exclusive, but are defaults. Novice users use defaults and yours are actually missing most important ones (according to your research from 2016). Extend them with compression and swap without external media - you will be amazed on results. Even and especially on mainstream RPi which is by far the worse device in term of I/O performance.
According to the wall of text … “there seems to be” … can be classified as a speculation, certainly not a a claim. Are you a native speaker? I am not, but still this should be clear. I am not claiming anything in this regard. I didn’t even try to install it and will skip. I believe you its simple.
Of course, Armbian is 100% Debian compatible and it goes even without git cloning. It can be installed from armbian-config → software menu.
This is why I am writing those few sentences. There are more options which are perfectly fine for new users, performs (much) better and I did show how to find that out - there are people who do that job instead of/for you. If you have official(!) Armbian running on some hardware, that have enough memory, you can expect at least the same level of overall performance as mainstream while most of board will outperform RPi. OH installation is hassle free OOB.
Yes, it has remarkable specs and performance but going for a brand new device and expect that it will work stable is the most typical mistake you can make.
Basic software support / kernel & boot loader usually needs a year or more before it gets to the levels you want to use it to serve you. Before that, you will be the server 
This is a speculation based on past experiences. I seriously doubt it can be any better, contrary due to increased complexity of devices that are coming out today.
First stage of support, after device is launched, where this board is in now, is somewhere on the proof of concept which demonstrate device hardware abilities. You can run this and that, but you will experience crashes and instability here and there, things will not work exactly as advertised …
This is not a platform for running your house. Not today.
You keep missing the point of this thread: It is not about maximising performance or price/perf.
Worst among SBCs or not, no OH users are limited by a RPi’s I/O performance today.
Compressed logs or scheduler tuning will not make a noticeable difference to them.
CPU performance also is well sufficient to run even large OH installations.
There’s only very little benefit in getting a faster box or optimized kernel/OS module/whatever but a number of disadvantages that by far outweigh a couple of seconds startup time you may gain when you get off the RPi/Raspbian mainstream.
Again: performance isn’t the point. But safety is a major one, i.e. reliability, stability.
With OH already typically taking 600+MB on a 1G machine, disabling swap is a hazardous thing especially when you also run additional stuff such as tmpfs, mosquitto or Grafana.
Swapping to an external, expendable medium is a safer thus better option. Same is true for logs.
Marcus, I would have one comment to the RPi, since this SBC has only 100Mbit network card which is not enough for the case of use of e.g. multiple streams of IP cameras with use i.e. IPCamera binding. Also it has only 1GB RAM that is truly not enough for the same application as camera streams or images need fast and high amount of RAM. Certainly it should be enough in terms of performance for typical I/O applications when working as a switch, but when it comes to visualisation it becomes limited.
It depends on number and resolution … and camera streams you wouldn’t direct to the OH server anyway but either to some NAS or similar data sink, or to your browser client, neither of which should be the OH machine.
And as stated multiple times, this thread and the recommendation in the docs are on HW to run OH on. It’s not meant to discuss SBCs or applications beyond OH.
The problem is, this Rpi recommendation is for one type of setup, which probably suits most new starters jus fine. It´s cheap, it´s easy to start off with, which is why it´s good to recommend for new starters…
But it should be consider as a kind of basic/minimum setup.
OH is so much more, including persistens, visuel graphs, video/cam etc… All these will consume alot of resources on the Rpi. I ran into serious problems when having my Rpi dealing with grafana charts. This is not an issue a new users would like to experience, I believe.
This is why a recommendations for HW is so difficult. It all depends on, what kind of system the users want to end up with.
When I started using OH, I didnt know… I just wanted to get started as fast and as easy as possible. Today I have learnt alot and I know, the Rpi will not be able to do what I want to. I had to move Grafana to my windows server, just to mention one task. This seems to do for now. But I guess, when I seriously starts to play with my video cams, the Rpi might end up beeing a bad solution again.
So in short - Recommendations depends on, what tasks the user want OH (and it´s included applications) to do.
I don’t mean to be rude but this tittle replacement is popping in my head: “Best hardware for OH platform Markus knows”
I gave you links with know-how and actual tests. If you don’t trust them, try on your own. You have clearly dug deep into the SD card wear out problem, but not enough since we would not have this conversation. Remember to make use of compressed swap. Only that will save your SD media … and boost performance. Writing less to crap media is improving reliability.
Especially here compression will provide a big difference.
Swapping to compressed memory is safer and much much faster.
You can add a swap file after compressed devices with lower priority but it is in most cases absolutely not needed. Do the math, do some calculation, do some experiments. If in such case, things go to the swap usage, its the time to upgrade since reliability is going down.
I really want to understand what you mean by that? I am all ears.
To help you out a bit: powering is a problem no. 1, where especially mUSB devices “excels”. Then its a SD card, then everything else. One would be enough, but since you said “a number of”, you need to count at least three. Remember to stick in the Armbian badge “supported” circle. I know that there is a lot of garbage on the market, that is not usable at all.
1 Like
Then don’t be.
You keep missing the point. The thread neither is on fastest HW nor on best distro or best OS setup, it’s on best HW. Performance is just of minor importance to the majority of OH users simply because (almost) all SBCs are fast enough for (almost) all OH installations.
For a best HW, however, you need to also factor in things like price, availability, energy & space consumption, HW and SW compatibility, availability of experiences, support and resources on the net and more.
Compression is a different story.
I’m not arguing against using zram but that is unrelated to HW or OS distro selection - you can enable it on RPis and Raspbian as well.
See above. But it’s not fun how you keep provoking. I’ll quit here.
… which is paperweight at least without software support. Namely kernel/loader. User space is generic, the cheap component, but can also be improved to support hardware better. I know. And you know. Don’t know why we are arguing about? Optimizations are an added value … and is not directly relevant in term of comparing hardware platforms, agree.
Compression based optimizations drastically extends your memory. I would not call that minor on hw that only have 1Gb of memory. Performance increase can be classified as a symptom of this improvement.
You need intelligence and experiences to use this principle. At least for the most important ones such as support. Perhaps some warranty that kernel together with easy to install Debian/Ubuntu is matured, is extremely useful to get started. The rest is cheap to obtain.
We welcome the PR.
I think one or the other of us misunderstands what I meant. What I meant is you can install openhabian-config and go through a nice cursers based UI just like what Armbian provides to install and initially configure OH and other related third party applications. It’s the “initially configure … other related third party applications” part that is missing from armbian-config.
For example, openhabian-config will install InfluxDB and create the openhab user and openhab database for you. openhabian-config will install nginx and deploy a reverse proxy configuration that will have it reverse proxy openHAB. oepnhabian-config will install samba and share out the important folders from openHAB so users can access and edit them using VSCode on their Windows, Mac, or Linux workstations. These are not things that armbian-config can or should do. armbian-config should remain much more generic.
Running apt-get install openhab isn’t even a fraction of what openhabian-config does.
I don’t think there is anything about the ultimate recommendation that exists in the docs today implies anything else. From a hardware perspective they are adequate for most users, especially to get started. Some (most?) users will never grow beyond what an RPi provides. Others will quickly out grow this. But, once again, that is why the first recommendation is to use what you already have and are most familiar with. That should cover pretty much all the users who are knowledgeable enough to go out and find the OrangePis and Pine64 and Beagle Boards and what not out there.
For those users who are left, adequate hardware/OS for which there is strong support on this forum and elsewhere on the web and which is easiest to get started with OH (burn the SD card and let it boot, wait, running OH) is going to be more important than having great hardware. These are the users who will be posting “I can figure out X. I don’t know Linux, please help.” Having a larger population of users here on this forum that can help answer those questions is more important.
When you got started I don’t think this thread and the others had happened and the official recommendation had not been added to the docs. Had that occurred, then the recommendation would have been for you to get started with OH on your Windows server in the first place. You already had it and presumably are familiar with working on Windows.
Here’s the deal.
This topic has been litigated to death on this thread and on other threads. We had a very long and involved discussion and covered pretty much all of these topics. Those involved were aware of Armbian and some I believe are even users of Armbian.
The community decided that the recommended hardware will be:
- What ever you have and are familiar with with at least the same or better specs compared to an RPi2
- Or if you don’t have something and have no other preferences, and RPi using openHABian.
NOTE: openHABian is probably half way there to being a software appliance. It’s not just an OS. It installs and configures a whole bunch of stuff outside of OH so that they are up and read to be used by OH.
You are clearly passionate about this topic. So my recommendation is to generate and submit a PR (or a separate repo if necessary) to create an SD card image that will boot and configure Armbian in the exact same way that openHABian does with Raspbian. If we have a boot, wait, now you are up and running process with Armbian, then we can discuss updating the recommendation for those users who fall into that second category above.
Without that I can see changing the recommendation.
1 Like
What about an Intel NUC?
Say, https://www.iacepc.com/acepc-t11-black/. 100€ and quite some power. Plus, x86 should have perfect software support.
Would you expect any trouble with OH? U found out that frontail (for logs display) will not work out of the box, but the rest should be fine. Right?
Why would frontail not work? Many users run on a NUC quite happily.