Would be easier if there were some ready to buy solutions and an adapted Download Page:
One of the options could be “DIY Pi-Box” which links to a page with a complete set of items to buy (with working Links!), and how to flash an sd-card with openhabian. And how to connect the boy to the local network via wires or via wifi. openhabian should have an access point configured by default for this to work, of course,
Best would be of course if the foundation could sell pre-flashed SD-cards.
Now there’s a thought.
I’ll happily offer pre-flashed ODroid C2 eMMC cards.
Well Grafana is a memory heavyweight and OH is, too, so I wouldn’t recommend to run both on the same machine unless you really really know how to optimize both of them and their memory consumption. Running on separate Pis should do, though.
But Grafana is no recommendation for first time users anyway, and of course you can always build an application landscape or rules that will exceed any Pi’s or even any other computer’s capabilities. But that’s corner cases.
This thread is about a recommendation to the average beginner what to use to start with OH.
I dont agree on this…Rpi is recommened as well as influxdb persistens and grafana for charts, according to the docs. All mentioned in the openhabian (hassle-free) setup:
Precise… openhabian hassle-free… Look at the page jump to Optional Components… There you´ll se both influxdb and Granafa.
"openHABian comes with a number of additional routines to quickly install and set up home automation related software. "
We can argue all night wether this is misleading or not having resommended an Rpi first.
Point is, it´s part of the recommendation!
Totally agree Kim as documentation is not just for new/first time users. We all have different approaches and requirements so one size does not fit everyone.
An example is how Kodi displays the information as clearly with Kodi one platform does not fit everyone’s needs. Openhab should not need to be anywhere as complex as this, but it could be just a few lines when recommending a few example systems… If you want a system that can handle this, we recommend this. If you want a cheap system you can use this, but it will be limited in these ways…
https://forum.kodi.tv/showthread.php?tid=252916&pid=2192251#pid2192251
No it is not. The openHABian docs do not “recommend” neither Pis nor Grafana. Remind you openHABian is not openHAB and Grafana is not part of openHAB an even in openHABian it’s just an option.
Also remind you we’re talking about the recommendation to go into NEW openHAB docs in this thread, it is not about existing docs, not about openHABian or any optional complementary software or combination of any of these.
And the Pi recommendation isn’t to cover all use cases. It’s not even a “recommendation” but a suggestion, and written for the user to try out OH for the first time.
Read the text.
I understand you’re annoyed because you understood it that way and now you have problems, but that doesn’t entitle you to go cherry-picking only those parts and interpretations of the docs that made you select this combo.
I wish @ThomDietrich hadn’t written that slogan to contain “hassle-free” long ago because ever since a lot of people with problems come along and complain “hey, but you promised no hassles” regardless of whether their problems really can be attributed to openHABian. Most cannot, and any interpretation to go like that is naive on the user part anyway.
Arrrr yes, managing people’s expectations…
That’s the hardest part of any project.
No, the foundation can‘t sell anything, as we would put our non-profit (charity) status at risk!
Does the foundation need to setup a “Non-profit” company with a web shop, that donates it’s excess to the charity?
I’d happily list ‘official openHAB2’ products on my company eBay page, and donate all profits to the charity.
Sorry, charity was the wrong word, so in fact, openHAB foundation is a non-profit organisation, therefore we are not paying taxes in Germany.
For that reason, it is difficult to sell goods, as the tax authority and the rules are quite complicated.
But some non-profit organisations do that. They distribute their work as cd/dvds and you can order those online for free distribution and you are paying transport and a little fee.
I think that is allowed but of course German paper work, so I can understand if you reject this idea.
The question was: Should we recommend a hardware platform?
I’m saying right now: NO
Why?
This question should be answered by users for themselves and to use hardware or operating system with which they feel most comfortable and most familiar.
Next you should suggest in the introduction, however, a useful solution, but not recommend! One could point out the many advantages of Openhabian and / or Raspberry. However, it must never give the impression that this is an absolute requirement for Openhab.
I think, most of this is still in current introduction.
But in my opinion, however, in the mentioned documentation too often referred to said Raspberry or Openhabian. All links point there, but not to the other systems (macOS/Linux/Windows), at least much later. So the impression arises, without RaspBerry/Openhabian an Openhab is running badly. Certainly Raspberry/ Openhabian are good choices, so I have no reservations.
If you want to make newcomers curious about Openhab, but those newcomers first have to wait for their newly ordered RaspBerryPi, how exactly should they stay on the hook? If they’re also willing to buy something unknown, even before Openhab starts!
Does anyone have any suggestions on how to achieve this (acquisition) easiest?
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:
Failing to do either, it will fall back onto the docs/the recommendations.
EDIT - Just tried webview and it crash openhab as well.
