I agree.
I only retired mine to a test system because I received a newer Z-Wave only stick. That stick lets me do come Zigbee testing even though I do not use Zigbee in my Production system. Chris said I did not need to do that,
1 Like
I’m all about the path of least resistance, if it works and it’s cheaper, I think it will be a good starting point. I looked at the Zigbee binding readme and found none of the standalone USB sticks on Amazon. Which just shows how unpopular they are apparently. Moving forward I think all of my devices will be Z-Wave +.
Based on your and @Spaceman_Spiff comments I took another look at the Pi4. Comparing apples to apples the Pi4 Kit with 4GB of memory, a case with a fan and a 32GB SD card is only a $20 difference and that doesn’t take in to consideration that the Pi4 case has a fan. My only question, I heard they had a power connector issue, did they fix it?
I can appreciate the start small and use an existing PC, however I’m OK with picking up a Pi, I’ve been wanting one for a while. I’d rather play on it then muddy up my desktop as it’s dedicated to other work.
The other reason, and correct me if I’m wrong, my understanding is that openHABian has a lot of things pre-installed, including the menu system for updates, changes, and moving the file system to a USB drive.
I installed openHAB in a Docker container on my NAS (OMV) and the first thing I noticed was how vanilla it was and said to myself “Now what?”. It also seems most video examples are geared towards openHABian.
As I mentioned earlier the Pi would give me more flexibility to move it around and if I have to do maintenance on my NAS I don’t have to worry about killing my Docker setup. I won’t have all my eggs in one basket…
Thanks in advance for your comments, that goes for anyone else I didn’t specifically name in my response.
Dave
There was an issue with 3rd party USB power supplies. I believe they fixed that hardware error.
Some USB sticks have an issue where they need to be connected to a USB2 hub and then plugged into a USB3 port. I have not heard of that issue with the HUSBZB-1.
1 Like
openHABian comes with most of the non-openHAB stuff that almost everyone also installs on their system pre-installed, or at least install-able as an option. It is a huge time saver for you and for us as you can just say “openHABian” and we know exactly how everything is installed and configured. And it saves you a lot of learning that is required if you were to install and configure everything yourself. It’s a great way to get started.
Also note, with the zram option in openHABian, it’s not nearly as vital to move stuff off of the SD card as most of the stuff that has lots of writes from openHAB gets moved to a RAM disk.
Hence my advice to spend some time with the docs. You kind of need an idea of what you want to do and that will direct the “now what” part. In general though, the first thing to do is install one or two relevant bindings (or if you just want to play a binding that doesn’t require hardware like Network, OpenWeatherMap, Astro, MQTT, Mail, etc.). Then create or discover some Things. Create some Items to link to those Things. Finally, create a Rule or two to react to events from one source and cause an action on another one.
1 Like
Sounds like a plan.
Is there a way to setup openHABian to control my Smartthings controlled devices so I can play and test before moving everything over and abandoning the Smartthings Hub? Is this were MQTT comes in?
Thanks,
Dave
With revision 1.2 they fix that nasty problem, but that’s just nasty ones. Rpi3 had extremely low IO and v4 remains among slowest boards. There is no reliable storage options - USB3 is just a crutch.
Before moving on, check:
This will only replace one low level problems for another - there are many reports, google … also check storage experts forums what do they think about.
But once again I’d be back to a vanilla install of openHAB vs. openHABian?
I assume your referring to something like the following?
Thanks,
Dave
He was referring to competitors to the Pi.
Openhabian is here that also “I am new to Linux” can use OH. I don’t like nor need this additional OS related crap so I use vanilla. I know how to connect to wifi or backup/restore stuff … so its down to personal decision.
IMO that is already an overkill, but for the price, yes. (if we assume Linux just works fine OOB) Could also be ARM based just that it has good sw support (armbian), eMMC and has 1Gb of memory. But you will hardly beat this price …
Welcome to openHAB!
I respect @igorp’s opinions on the RPi (he’s very clear on why he dislikes it), but for me and many other openHAB users it’s perfectly fine. It’s easy to find, easy to work with, and easy to replace if it ever dies. And now that ZRAM is enabled by default, I personally don’t see a need to use an SSD (but can appreciate that others do).
I recently moved up from a 3B to an RPi4 with 2GB of RAM. I don’t perceive a difference in operational speed, but do find that PaperUI is much faster to load. However, I don’t do much with persistence or graphana, so I’m not working my system very hard. I don’t have a fan for either of my RPis, and heat hasn’t been an issue.
Any new RPi4 you buy at this point should have the improved USB-C connector, which was quietly released sometime around December/January. But even with the original release there was only a problem if you didn’t use an official RPi power supply. So, while I think the concerns were overblown, I’m still glad that it was fixed. I bought my RPi4 in March and it had the new connector, so it would be surprising to me if anyone still has the first revision in stock.
Good luck!
3 Likes
Can openHABian be installed in a VM environment for testing?
Sure, while it’s not officially supported, it should work on any Debian based distro. Just follow the manual installation instructions for openHABian and avoid having it set up ZRAM.
2 Likes
Is there any way to install openHABian in a docker container?
openHABian is basically a collection of scripts with a graphic menu which will help you install and setup packages on linux. You’re not missing out on features if you don’t use it, you just will have to install/configure some things by hand.
If you don’t mind the slightly higher power consumption of the T620 (~7W vs ~3W), together with a new Transcend MTS420S it’ll be a 70$ package that’s hard to beat. Just watch out, there is a version of the T620 with a dual core and there is a version with a quad core.
Also you’re massively overthinking things! You already have a nas with a docker set up, so I’d try to offload openhab there. If you are not happy or there are unresolvable problems it’s always easy to buy a another device.
Just get started and try to play around (that’s why I suggested to try it on your main machine, just extract the openhab files in a folder and you can run it).
1 Like
What I did when starting was run OpenHAB (& others I tried) in a VM on my main machine.
This would be a significant abuse of what Docker containers are for. A container is supposed to run one service. openHABian runs a bunch of services. A proper containerized approach would be to run each service as it’s own container (this is what I do actually). But for that you are pretty much on your own to set up each container and/or the Docker Compose file to launch all the different services.
Some feaures like zram would be missing of course. They don’t make sense in a containeried context.
ZRAM is a hack that cheap consumer grade hardware like RPi (that can only have shit storage) is able to run OpenHab with decency. That was my suggestion / urge to OpenHab creators and they needed around 2 years to enable it by default, even this function was successfully in operation on all Armbian for many years. Also on some Androids and other embedded applications …
I have to disagree.
People, me included, are running far more complex applications within Docker. Our CI on a day job is entirely containerized - it is running simultaneously a bunch of Yocto, Buildroot and hundreds of tests cases on Kubernetes cluster. Everything runs inside a Docker image (which development is partially my work). I would not call that abuse, but just a legit use of Docker. OpenHab runs a bunch of services, true, but compared to my experiences or to this setup its just a small utility. Also Armbian build system - which is again a very complex suite - runs just fine inside container.
Docker is IHMO actually a perfect way of deploying OpenHab(ian). It has been months since I recommend you to focus into Docker setup (only). Its for your own and users good - give less trouble to users and minimize support costs you have daily with people. I can only spot benefits.
… or its your policy to align with Canonical Snap instead of Docker? Which is perfectly legit decision, but in technical sense, is more or less the same.
Can be implemented and it make sense.
You do not use Debian or Alpine as base container images? Both OSs run multiple services themselves. I know of no modern OS that does not run multiple services.
I look forward to your alternative implementation. Since openHABian is, as you implied slow to adopt your suggestions and targeting shitty hardware.
And I’m not being glib. You seem to have a whole lot to complain about openHABian. You have what you believe is a better approach. So build that better approach. If it’s better, people will use it.
But what I’m referring to as an abuse is running:
- openHAB
- InfluxDB/MariaSQL/MySQL/etc.
- Grafana
- Mosquitto
- Node Red
- FrontTail
- and more
And not every user of openHAB is going to need or even want all of those running. So then we need to build a whole configuration system for the monolithic Docker image (or build the 10! or so different Images that includes all combinations of all the services) so the users can pick and choose which services are running. If only there were some way to do that (cough cough Docker Compose cough cough).
And everything I’ve read, and everything I’ve been told by Docker reps, Kubernetes experts, and Red Hat OpenShift experts have stated emphatically that in a situation like we have with openHABian, multiple images orchestrated with something like Docker Compose is the “correct” approach. If you want a monolithic solution that includes everything, use a VM, perhaps built up using Vagrant.
I can’t and won’t speak to your specific use case but I still maintain that trying to run everything that openHABian does in a single container is an abuse of containers for which there are lots of superior containerized approaches.
I suggest reading up a little more about how containers actually work. A docker container is not a full OS. There is no initd or systemd running in these images (unless you put it there, though there are lighterweight approaches that tend to be preferred). If you run docker exec -it <openhab container name or ID> ps -elf how many processes do you see? Not many. A call to start.sh, the java process that is openHAB, and stuff that openHAB itself started (e.g. arpings from the Network binding, perhaps other scripts called by the Exec binding and executeCommandLine). Now run ps -elf | less on the host machine. How many pages of processes do you see? How many of those have a PPID of 1, 2, or 3? Those are all the processes that were started by the initialization system and are generally considered part of the OS. NOTE: I’m speaking in vast generalities here, there are exceptions of course.
A container is not a virtual machine. It’s not a full operating system. When you use a debian base image, you are getting many of the base libraries and functions that are configured with the debian distribution. But that doesn’t mean you get everything. I had to file an issue for the openHAB docker image to include ping and arping. Even basic utilities like that are typically missing unless you go out of your way to add them.