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
Comeone Markus! At least give the users some credit. They´re not all that stupid. There is a specific reason why they´re even suppose to be reading the doc about an computer based Smart Home System. They have an interest even before they start to read the doc. Othweise they would never have come this far.
Lots of people are used to add USB devices and/or external storage to their workstation. Adding a SSD/external storage to Rpi is no different. Infact I would say, users beeing more used to USB/external storage devices rather than SD cards.
Second - It´s the exact same procedure the user will be doing, when copyíng the image to an SD card or an SSD. So no need to add extra explanation in how to.
The benefits are huge!
(The Rpi 3B+ will boot from external storage devices by default. Rpi 3B and older wont).
My question was a suggestion, a tip section for optimizing specially for the Rpi. It´s not something I´m going to argue about.
I would prefer this phrasing. Reccommends Pi 3 but leaves the possibility for using an older one at hand.
No, Jerome, I was talking about several folks in this thread that considered other platforms a better choice, such as windows. I know nothing about Pi so can not comment on suitability at all.
1 Like
Be careful with your quotes, I never said that and never would.
We’re discussing the introductory documentation page here which is meant to address the maximum number of people with recommendations that all power users to contribute here (or at least a great majority of them) agrees with - both of which does not apply to your proposal.