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.
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.
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.
Any problem you have like that is almost never going to be caused by hardware but by the operating system. Xubuntu should work just fine. And given your limited experience, I recommend using the manual installation method for openHABian which will install and configure all of that stuff for you so you have a stable and tested configuration without requiring any expertise on your part. It will work on any Debian based Linux.
Recommend what you already have is fine, just untill the user understand, that this system (OH) would need to run 24/7 to make any sense. Then āwhat you already haveā could turn out to be a rather bad idea due to power consumtion as well as other hardware which sometimes isnĀ“t build for running 24/7.
To test OH and get a feeling of what it is, its a good recommendation to start with whatever you already have.
Agree. But then again. It wouldnt matter much to stay with a piece of hardware only to be able to answer questions, if this hardware isnĀ“t capable of running your system.
I dont remember exactlyā¦ I chose the Rpi because I got the impression, it was the easiest way to start due to the SD card imageā¦ I wouldnĀ“t have to fiddle with lots of strange, (stupid) installations, commands ect. in an OS I knew nothing about.
There was a windows version allright, (as far as I remember), which I actually tried first. I gave up because OH was way to much hassle. Then I tried a couple of other systems (Domoticz and HA), but gave up on them as well, only to returned to OH having decided to fight the hassle.
At that time I chose to start off with an Rpi to learn from the bottom, I thought I might as well start off with new hardware as well as a new system, and build my way through to somewhere I had no idea where I would end, except the few goals I had.
I dont think IĀ“m unique in this situation. Infact I think lot of people start like this.
Given that literally no one knows when they first start what they will build their bespoke home automation system to do, what would you have us recommend? No one knows what they need until they get that feeling for what OH is and what they want to do with it. And we canāt foresee what any individual user will need.
Do we recommend only server class machines with 28 gig of RAM just in case the user wants to integrate two dozen video feeds? Do we recommend a RPi Zero W just in case the user only wants to control one light?
No matter what we recommend there will be users who will need to migrate to new hardware at some point. But at that point they will have the experience and knowledge necessary to choose exactly what they need.
So we recommend users use what they already know to minimize what they have to learn to get started. If you donāt want to go that route, we recommend RPi which is one of two SBCs (Pine64 works as well I think) that works with openHABianās SD card image. Will some users need to migrate off of the RPi? Almost certainly. But based on what I see on the forum and that recent survey posting, the majority of users stay on RPis.
Iām sorry you had to move. But your experience was in the minority (a large minority perhaps).
There is no good or final answer to that question, cause it all dependsā¦ And thats why a recommendation is so difficult.
But from a logic aspect, I would say, due to the very low prize - The Rpi and the experiences it can give a new user, would be my first recommendation, unless the user express specific needs, which I know (from my experiences) would be trouble for the Rpi, such as Grafana charts.
This is why I think the recommandation to use Rpi as well as indicating there is an easy way and option to install Grafana from openhabian-config is wrong, cause it sends a signal that the Rpi is capable of handling thisā¦
So if I was in charge, I would either explain very detailed and specific through the docs or huge warnings in openhabian-config, that options like Grafana is not recommended on the Rpi. Or I would simply remove it from the installation (openhabian-config), as well as if there are other stuff which isnt suitable for the Rpi (the recommendation). If/when the user have enough experiences to try with charting, then IĀ“m sure this user would know how to ask or find the answer and whats needed as well.
Recommend to start of with an Rpi to a new user, who has no expectations or specific needs, and the user afterwards finds OH too difficult or lose interest - The worse harm done is the low prize.
I think thats acceptable, and I agree this is the best the team can do. I just dont aprove sending wrong signals from scratch to users who have no chance of knowingā¦ Which is my only appeal against the recommendation today. (I think I have mentioned this quite a few times by now ).
I didnĀ“t mind movingā¦ I gave me enough currage to go for the Rpi at the end. And IĀ“m glad I did, even though there has been some struggle I could have lived withoutā¦ But thats life in this computer world!
How much blame and therefore responsibility does the openHABian project have in this case though? Grafana changed their software, as they are free to do, by removing a library and therefore a feature of Grafana that is useful to OH.
Some users have figured out a way to restore that library by hand only to discovery it all but breaks OH on their RPi. Are we to therefore be responsible for warning users away from RPi because they took an action to modify the software away from what gets installed and configured by openHABian, and away from the recommended configuration of Grafana?
I say no. We canāt be responsible for such issues. Had you not restored that library and used Grafana in an unsupported configuration, you would not have had the problems you did with the RPi. Similarly, OH canāt be held responsible for the decision that Grafana made to remove the library with nothing to replace it (as user hostile as that was).
Indeed, and it was mentioned a whole bunch of times in the thread where the recommendation verbiage was chosen. Your arguments are nothing new. The consensus disagreed and we have the recommendation as it stands.
Doing neither will cause problems for user not knowing.
OH is not to blame nor responsible for whatever changes Grafana do. Thats not what IĀ“m saying.
But doing nothing, knowing the change will cause fatal problems, just because āOH is not to blame for other changesā. Thats wrongā¦
I will never be able to understand this way of thinking
It is not not had it ever been OHās policy or recommendation to manually replace that library file. There are no official docs anywhere in the OH or openHABian docs that promotes or provides insurrections for downloading and installing that missing library. Neither Grafana nor openHABian installs this library automatically.
We didnāt tell you to install this library. We didnāt recommend this library. So why is it or responsibility to warn you and document Anthony itās use? Do we need to document that users shouldnāt drop their RPi in water? Avoid running the command of -rf /?
Even if we just limit ourselves to software there is still an infinity of things you can install or missconfigure that will harm the RPiās ability to run OH. Are we responsible for documenting then all?
The docs for what not to do will far exceed the docs for what to do.
If a user takes it upon themselves to modify their system in a way that deviates from the standard, they are taking upon themselves the responsibility for anything that may go wrong.
We can barely keep up with the docs for a standard OH. You want us to document everything that could go wrong for every random change a user might want to make that deviates from the standard?
True. But I was implicitly comparing any x86 installation with openHABian on a Pi: The latter is simple and can be recommended to anyone who is willing to learn some basic Linux. Contrarily, x86 should be compliant with anything you might plan in terms of drivers, libraries etc. (in contrast to some exotic ARM board), but you should know how to manage problems.
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.
).