Most software packages do not recommend X brand and model hardware, instead they recommend minimum specs that need to be met and sometimes different tiers of specs for better performance. This approach could be used and keep the main openhab project truely hardware agnostic. Possibly some specs like ram may need to be higher for a normal desktop windows system compared to a minimal Linux build.
That was the question and for exactly all the reasons Alex is pointing out. My mind has been changed on this once already as I came in this room agreeing with his opiniion
As said, we can argue this all night (day if you like). I simply dont agree with you… You seem to be focused on a single word “recommendation”, and fail to read the context, which on the contrary indicate (notice another word which in the context got the same meaning).
When making new docs, it´s fine to look at, whats not to write again, or perhaps write it in some other way/better way.
Ofcouse it does… As you said yourself… I´m not the only person with this opinion. Doesn´t that make you wonder, just a little? (it should 
).
I dont mind the docs says hassle-free. It´s not that part which is wrong…
Whats wrong (ie missing) is whats not written. The case if someone continue to expand the system, sooner or later the Rpi will hit the limit, (ofcouse any hardware got its limits). That part is missing, specially if someone is using the aditional programs like Grafana. This part should be noticed and told, specially when Grafana is part of the openhabian-config and indicate it´s additional and easy to install.
To you, who is highly experienced, you dont need this. But to new users who knows close to nothing, this can be very important knowledgde in the choice of hardware to start or continue to expand the system…
Not strictly only on Pis. openHABian’s manual instructions can be used on and Debian based Linux distro.
To be fair there is a Chocolatey installer for OH that is reasonably well maintained.
One totally dead laptop running something, probably Windows Vista.
Two other old laptops that still work, one running Windows 10 and one running Linux. The Windows 10 one will be running Linux at some point I’m sure.
An old Mac Air.
My wife has an iMac.
My servers run on a Lenovo Desktop format server.
Both my wife an I use Chromebooks for day to day stuff.
4 RPis running Linux that have jobs, 1 BananaPi running Linux that needs a job, and to RPi 0Ws I have jobs for but haven’t implemented yet.
I like this. If you already have a place to run it and try it out that you are comfortable with, choose that. If not, choose openHABian. That is what I’d recommend to a new user if asked.
Actually, what I usually recommend when asked it openHABian on a RPi, or if you already have hardware to run it on, what ever that OS runs. If they are considering a VM, I recommend Ubuntu and the manual install of openHABian.
A RPi 2 has traditionally been considered the minimum. I’d personally recommend a RPi3 and I know many users run very small OH installs on RPi 0s (which are roughly the same specs as an RPi 1).
Thanks for the PR!
I can’t get from point A to point B here. How would recommending openHABian when the usr has no other preference be a really bad idea? That doesn’t negate the fact that Windows is in fact supported and we already do say that OH will run on Windows just fine. We have a whole page dedicated to the docs for that.
But that being said, unless someone takes up the effort to beef up the Windows installation process, it will always be less work over all to get openHABian running and there will be some challenges running on Windows that openHABian users will not face like installing and using Mosquitto, InfluxDB, Grafana, NodeRed, FronTail, et al.
I don’t want to sound too harsh, but despite showing that OH works on Windows having openHABian listed as the recommended installation scares a user off, that user is probably not likely to be successful with openHAB anyway. As we all know, it takes a certain degree of dedication to learning, experimentation, and perseverance to be successful. The docs already make it clear that Windows is supported. Saying that openHABian on an RPi is the preferred solution (if you don’t already have a place to run it) doesn’t take away from that.
Sadly yes.
This actually illustrates why it is so difficult to make a recommended size for a system like this. The problem you describe is one with Grafana, not openHAB. So should we have to take that into account? No one is required to use Grafana. No one is required to use Grafana to render static charts using PhantomJS which you now have to install separately since Grafana dropped support for it. So is this really OH’s problem?
I’m uncomfortable taking on responsibility for things outside our control.
If you use a webview on your sitemap instead of manually modifying Grafana to preserve the static chart rendering then I don’t think you will see any problem. Although I think the way Grafana dropped PhantomJS was kind of jerky, they have a point. Clearly it has some problems that are not going to be fixed. And since you had to go out of your way to install PhantomJS, it’s a non-standard install. So is that really OH’s problem?
But this raises a problem. As a new user, if openHABian were the recommended solution, and openHABian will install and configure InfluxDB and Grafana, then I would assume that running them on all on my RPi is perfectly fine. It’s present and the expectation is using them wouldn’t cause a problem.
Some of these expectations could perhaps be mitigated with warnings in the docs/openhabian-conf might suffice.
But your point is valid. Neither are explicitly recommended. But their mere presence in the configs implies there should’t be a problem installing them.
This sounds like no disagreement at all then. I think pretty much everyone is saying the recommendation would be
“Use what you have and are familiar with. If you don’t have something to run it on we recommend openHABian on an RPi.”
I do not see any distinction between this and what you just suggested.
If you can point to anywhere in the docs that reference any specific operating system (outside of the installation docs) please file an issue on that page as that violates the documentation policy that ALL docs are platform independent.
Now you are indeed correct that on the forum most of the examples and tutorials will be from an openHABian perspective but that’s because that is what the majority of users are using. We cannot and will not impose a “platform independence” policy on the forum.
Rich, I pretty much agree with everything you said but was checking out the Windows installation page a day or two back and noticed Chocolatey installer seems to have gone missing from the windows install page, maybe I’m blind, check yourself
I remember it was broken when I started, then talk of fixing it, got fix, now missing, didn’t that page change?
I haven’t followed Chocolatey that much. I remember pinging the maintainer when OH 2.3 was released to get the upgrade into their repo and haven’t looked at it since. You probably have more information about it than I do at this point.
The italic part is indeed key here, I agree with your statement in that way. And I might have been misinterpreting the discussion at that point in time, but to me it looked like the suggestion was that a new user would be recommended to always go with a Pi and OpenHABian, regardless of where the new user is coming from. As said, that might have been my misinterpretation, and the way it is described in the PR is definitely acceptable to me. (if it hasn’t changed too much since I last checked it 
)
I never said that recommendation is easy. Infact i believe it´s not. But if there is a recommendation, it would be fair to expect that this recommendation will work or at least the limits, if any, beeing mentioned. Isn´t it?
No it´s not openhabs fault if Grafana fails. But why on earth include (and thereby indicate this is good to go) a piece of software which is either faulty or will cause problems for the same platform (Computer) which is recommended for starters?.. This I believe openhab could do better, OR even better - Tell about possible problems/limits if the user choose to use it. Then the user can decide or be prepared if his system expand.
I do have to say openhab is to blame for something though. No outside things/software should be able to crash openhab to an restart like I´m facing here. Mind you, I have a Rpi 3B running my main setup with lots of stuff, and then I have another test Rpi 3B+ running with a fresh openhab 2.4 install and very limited setup (only two bindings). Both setup I can force to crash, just by rendering enough Grafana charts. So this is not just something which happens on rather big systems on a Rpi. Its a combination of openhab 2.4 and Grafana. (I never had any problems with openhab 2.3 and Grafana).
It´s okay if it just failed to render. But it´s not okay to crash openhab like that…
Somewhere there is a fatal problem, either in grafana or openhab 2.4, thats for sure.
(I have given up trying to shout about it, noone seems to care, and blame it on the user who choose to use an Rpi, just like Markus did).
I have tried Webview. It doesn´t refresh the charts. It uses the same amount of CPU and memory so I dont think I can avoid problems. (I havn´t tried push it to its limits with webview though).
But this thread is not really about Grafana. It´s about recommendations or not. I just used Grafana as an example of how things are not suppose to be, in my opinion.
If there is going to be a recommendation in a new Docs, then it´s most important to make sure:
- It will work.
And - If there are known situations which a user should be aware of, then make sure to mention it.
Failing to do either, it will fall back onto the docs/the recommendations.
EDIT - Just tried webview and it crash openhab as well.
“Good to go” is another indicator just on your part. Remember openHABian also runs on x86/debian so having an install routine is beneficial but it doesn’t mean it’s meant to be used on every HW. Guess it should at least put a warning on Pis, though (don’t know if it does). As you found out, please open a Github issue or PR to make that happen.
And it’s not always all that intentional as you seem to think.
Probably by the time it was done it worked, now something changes (such as OH jumped from 2.3 to 2.4, you mentioned yourself that that started your trouble) but noone told openHABian maintainers so it remained like that. We don’t have the ressources to do full regression testing everytime a component changes.
PS: just an idea, you might hit the heap space limit. Check what -Xmx setting java is running with and eventually increase that by 100m (EXTRA_JAVA_OPTS in /etc/default/openhab2). If none it’s 256MB.
But please don’t discuss here but in a new thread if needed.
You and I both know what. But you fail to see this from the new users side…
The new user have just read the docs, and learned Rpi is a good place to start. The new users starts, enters openhabian-config and sees influxdb and Grafana. This new user couldn´t care less what else hardware is suitable. This new users isn´t beeing told otherweise. Why should this new user care?
Thats the wrong part of it.
Most probably, yes. (which I have been trying to mention quite alot of times as you know).
We cant´changed what have already have happened, but when changes are due…
Then please be aware if things has changed. Specially if you (someone) are recommending/indicating/whatever some hardware and/or software. Remember to notice the limits, if any. This goes for all general recommendations, not just openhab/grafana/Rpi.
PS. Thanks for the hint about Java -Xmx… I´ll give it a try.
1 Like
I think my main point was missed in all of this. If I understand correctly:
- Grafana no longer supports generation of static charts
- to restore the ability to generate static charts one must download the PhantomJS library and put it in the right folder within Grafana
- openHABian does not do the previous step
I believe the problem you are seeing is caused by PhantomJS (I’ve seen the problem myself on my VM, so I should warn you that getting better hardware is unlikely to solve your problem). And since downloading it and installing it into Grafana is something you did, not something that openHABian did, it doesn’t make sense to me to blame openHABian. You are running a customized and not supported install for Grafana. We can’t take responsibility for that and it doesn’t make sense to warn users about that. If it did then we need to warn users about EVERYTHING because I’m sure it is even possible to missconfigure Mosquitto to overrun a given machine.
Now, if my last bullet point is wrong and someone has modified openHABian to download PhantomJS and install it into Grafana then yes, this is an openHABian problem. IMHO that should be removed from openHABian if it exists and we should just live without the ability to generate static chart images straight from Grafana. There is a reason Grafana dropped the library and there are other options for putting Grafana charts on a sitemap or HABPanel.
Finally, I think it is worth noting that Markus DID submit adding a warning to the recommendation.
OK… thank you all for a great discussion. We are attempting to get the improved ‘Introduction’ section merged into the documentation. A decision about this issue as to ‘should we recommended a platform?’ is at hand. We need to decide if we should recommend a platform or not in order to include this information in the introduction section.
There were several proponents of including a recommendation and several detractors, the platform itself was also questioned. Does the community have a clear decision on this question?
Should we recommend a platform?
If yes, what platform?
The text about the recommendation has been altered to add a warning about the Pi’s shortcomings, please feel free to review the proposed text here:
1 Like
I think the consensus was:
- First and foremost the recommendation is to use what ever you already have and are already familiar with. OH runs on just about everything and there is enough to learn without forcing new users to learn a new OS if they don’t want to.
- If and only if you do not have a preference or place to run it already the recommendation is to use openHABian on an RPi 3. This is the most common deployment and openHABian will produce a stable and well understood environment to start from.
That is my feel for what the majority of contributors to this thread agreed would be a good recommendation. But that’s my feel. I didn’t go through and count posts or anything like that.
1 Like
I second that. I think we are getting somewhere here
Rich:
Here is the currently proposed text. Would you agree that as written it covers your two bullet points adequately? (last sentence of first posted paragraph starts recommendation text)
OpenHAB runs on most popular platforms such as Linux, Windows and MacOS and on almost any hardware ranging from Raspberry Pis to desktop computers and server PCs. You can find specific installation instructions for these and other platforms in the Installation Overview article. If you have a strong preference towards a particular platform, then that platform is probably your best choice.
You can install openHAB on your desktop computer for evaluation purposes if you already have any of these systems available for use, but we recommend using a dedicated system in the long run. If you feel serious about home automation it may be better to start with a dedicated system right away.
For anyone undecided: many people find that the simplest way to experiment with openHAB is to get a Raspberry Pi (Version 2 or 3) and install openHABian; a “hassle-free openHAB setup”. While openHABian offers a streamlined and simplified way to get up and running quickly, it is a complete openHAB home automation system easily capable of automating your entire home. However, it is worth noting two potential limitations of Raspberry Pis. They are limited in RAM (memory) and may not perform well when additional database and data visualization programs are installed. Running Raspberries from SD-cards only may result in system instabilities as these memory cards can degrade quickly under openHAB’s use conditions.
1 Like
If you are taking about my review comment, you may got me wrong.
It states “PI 2 or 3” and i see no reason for recommending a PI 2, since a PI 3 nearly costs the same.
I wrote that because people might happen to have a Pi 2 at hand and I didn’t want them to think they need to invest in a Pi 3 instead.
Why don’t you write:
For anyone undecided: many people find that the simplest way to experiment with openHAB is to get a Raspberry Pi 3 (or minimum a Pi 2, if at hand) and install openHABian
1 Like
Would it be suitable for an optimze tip section, regarding the use of an Rpi?
This section could be mentioning Rpi 3B+ above Rpi 2. SSD rather than the SD card.
Some days ago I installed a fresh copy of openhab 2.4 (openhabian hassle-free image), directly onto an SSD (USB) plug´d it in my Rpi 3B+. From absolut start till openhab was up and running, it took aprox 15 minutes incl the image copying on a windows 10 using win32diskimager. Doing the same using an SD card takes an hour and more.
If users just want to test openhab, I believe they want to get started as fast as possible, and not sit and wait for one hour doing nothing but waiting for a stupid slow SD card to finish. It wont get any faster than this.
By no means! The vast majority of people either disagrees or is incapable or unwilling to add a SSD, and it would require lots of explanations how to do it.
It’s easiest to stick with off-the-shelf HW order and openHABian image.
2 Likes