I echo @rlkoshak here. The ‘perfect’ solution is not just a piece of hardware. It is the combination of:
How capable the hardware is
How capable the software that runs on it
How much support there is behind both
Cost where applicable
With the above 3 requirements, it seems (to me) the Raspberry PI is one of the clear winners.
The RPI has a long history, and if there are many clones out there (BananaPi, DietPi, … ) it is only more justification that the RPI must be ‘good’. Again, I’m open to trying few more ideas/platforms … but I’m no expert in computer science (though I wrote multiple C/Fortran/Matlab/… programs) , and only looking for something I can use.
1 Like
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
77
Just to be ultra clear.
DietPi is NOT hardware, it is Debian Linux, especially constructed to be extremely lightweight, so ideal for use with software like openHAB2, that doesn’t need the extras preloaded.
I guess the name comes from it originally being created to run on Raspberry Pi hardware.
However, there’s an image for other devices, like the ODroid C2, Quad core SBC.
I run on one of those exotic setups, in a VM with Docker (though it’s not really all that exotic, there are lots of people in this forum who do the same). The RPi I do have OH running on is 100 miles away. I’m not going to replace the OS on that machine.
But this does help my point. Those who have the skills and knowledge to support themselves don’t need recommendations from us as to what to run on. And when they run into problems, they can support themselves. So the recommendation from us is going to be for those who most likely can’t support themselves.
We are not saying you shouldn’t ever run OH on anything other than an RPi. But if you do run it outside what is recommended, you are on your own for support.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
79
I understand.
My view point is…
Okay, as long as you “keep it simple”, I’ll help where I can.
I guess the real issue is…
“What are you / we supporting?”
Are we all happy to help people with openHAB2, I’d like to think the answer is a big YES.
However, “are we all skilled enough to help people with underlying OS?”, Then probably not so much.
Will we help anyone to get openHAB2 running, who has a stable OS, ideally Debian based, then probably Yes again.
Agree, it may not switch his light faster… But there are other parameters which involves “faster” rather than state changing and switching on lights. Openhab is so much more.
Loading of openhab (from boot) is VERY fast on a C2 than an Rpi3, (I havn´t tried an Rpi4).
I believe the filesystem itself is much faster as well in the C2, than the Rpi3.
Running persistence and/or Grafana rendering on a Rpi3 can be a huge problem. Though I havn´t tried yet on my C2, I would assume this is way faster as well.
So, there may be quite a few reasons for using another hardware. It all depends on the use.
However, I understand the concern of using a not mainstream OS/Setup, which ofcouse would lead to limited support. Thats an issue to take into consideration as well, for all users.
Glad to hear, but let me make you aware that you’re making a dangerous mistake here.
openHABian, while it might work for you at the moment, does officially not support any non-Raspbian OS. That means it may stop to (fully and correctly) work at any time. That may be as soon as on next patch. That’s not FUD - we recently had a change after which a specific Raspi version stopped working (CM3) although it was not our intention to break that. It happened just because we don’t test against that.
And there’s already parts of openHABian today that are not applicable on non-Raspbian such as e.g. the already mentioned pretty valuable ZRAM feature.
That one is so much half-way between HW, OS and OH that it’s only safe to use/to work on buster with specific configuration to be tailored to match all, HW, OS and openHAB (java) config. One example just to make you understand what I mean by that is partition sizes. Typically an OS-only thing, any user can change it - but now there’s interdependencies with RAM usage, OH (logging now to RAM but also to sync to disk), OH (java cache size) and more.
Not saying you cannot get that to reliably work elsewhere but you need to be a very experienced Linux guy which the majority of OH users clearly is not.
DietPi, in comparison, is used by more people that run whatever on it than by people to run openHAB on there. So unlike openHABian, DietPi will never be tailored to run and tested against openHAB.
For you as an integrator, this is where you are leaving the supported mainstream then and will have to deal with all of this by yourself: development, testing, support - all of which the openHABian people currently do for you. I wonder how that fits with your KISS golden rule.
Note the point is not about HW - frankly I essentially don’t care, however it’s indirectly related:
your problem is you want to stick to the C2 hardware which openHABian as an image/Raspbian does not work on. If you did give up on that and moved to say a RPi4, you could make use of openHABian including all of its features and OH specific optimizations.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
82
Absolutely understood.
I’m happy to do a “manual” installation of OH, so for as long as openhabian works, I’ll keep deploying it.
I may well have just been lucky in that none of my installer’s / distributor’s clients have asked / expected too much from the C2 / OH2 combination.
It’s very possible that this will all come home to roost and I’ll be faced with some very serious issues.
However, I’d like to think that I’ve done enough homework/ groundwork to be able to deliver a solution.
My only point here, which Kim has kindly confirmed, is that “in my opinion”, the C2 platform, with a minimal Linux OS, runs openHAB2 VERY WELL and the end use experience is a pleasant one.
Every one of us is faced with choices, this thread title invited opinions, I feel like I’ve openly (and honestly) given mine, for what it’s worth.
I really did mean openHAB
From what I understand, openhabian is the OS (or part of Rasbian/Debian), right?
openHAB is the smarthome system, right?
But openHAB works and is supported for other OS´s as well, (windows fx). So why not others as well, (could be DietPi or anything else).
I´m just trying to understand whats the catch here. Stuart never claimed his suggestion was the official recommended setup… As far as I read, his was just suggesting alternatives.
I´m not suggesting DietPi or C2 beeing recommened setup. But I see no reason how come it shouldnt work, and again, shouldnt continue to work, even though openhab gets updated.
Yes I already use that(DietPi). You are right about how fast it is compared to all other OS. It is just Debian on Diet(extreme diet). It can make any piece of hardware feel faster than ever before.
Dont want to offend any other gurus over here, you all are right about the support issue and hence new users should always be recommended with RPi.
Hey, you should give this thing a try. Just a couple of 18650 cells in those and your system would last for more than 10 hours with ease.
1 Like
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
87
Hi
Thanks.
That’s a nice little 5v battery pack, but (unless I’m missing something) it’s lacking the UPS signalling that is needed to let the OS know that the main power supply has failed.
I’m sure something could be rigged up, but I’m (always) looking for a complete solution, that I can simply assemble and configure.
Update
I’m not sure how I missed this, but it looks like the Odroid C2 already has a UPS option -
I have a funny feeling that I might not have made that clear, so you thought I meant the flashable / complete Raspberry PI image, which clearly would NEVER work on anything than the intended platform.
Sorry for any confusion.
To be totally inclusive, there is a thread that is asking for votes to add openHAB into the DietPi setup script.
Got that. But what I think what you don’t know is that the openhabian script (which is not a separate version but exactly what is used to configure the ‘raw’ Raspbian that is provided as part of the image, too) has to start somewhere.
So it’s making assumptions what’s already there in terms such as packages, libraries, userids and the like, and even some HW specific stuff such as partition names or drivers.
And it does so based on Raspbian lite. Only Raspbian lite. Not based on stock Debian, not on DietPi, not on Ubuntu. Only buster Raspbian lite as it runs on RPis.
And it does so no matter the platform: on RPi, on C2, on x86.
That’s why it’s so likely/dangerous that any next openHABian code change might break its ability to run on anything but a RPi without that we even are aware of that. Or any change in the OS you chose to use instead which obviously is unaware of openHABian’s needs.
It’s ok if you want it that way, but it’s IMHO very bad advice to recommend this to anyone else which is why I’m so annoyingly tenacious at pointing out that no ‘ordinary’ OH user should take that for a good idea or even a recommendation.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
93
Okay…
We’re on the same page now then
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
94
Hi
You asked that I post some more information, so here goes.
I’ve bitten the bullet and ordered a C2 UPS.
The only minor detail is that I’m told it won’t fit in the standard C1 / C2 case, so I was advised to download the STEP files for the case and modify it to suit.
Wow. Thats nice.
I am myself testing out a 18650 battery pack with a bunch of components like a BMS, power adapter and a buck converter. Essentially a UPS put together by self. Has been working for a month now and is cheap as hell.
