At the Moment you need a HUB.
I can not say if a firmware in the future fixes this "error
Some updates to the pi4.
- you can overclock your pi. I have one running at 2.147GHz with no heat issues (I have a heatsink) Link
- you can now boot from USB! Link
I’ll be trying the USB boot tomorrow 
Edit: reading the comments it seems the USB boot is almost certainly fake… 
Good news about the heating !
And now that pxe boot is done, they we’ll work on USB boot as promised… let’s hope it won’t take long.
Thanks for sharing!
I think the article is a bit of smoke and mirrors now that I’ve reread it.
What does work, as I have a pi running, is the firmware update and over clocking. Not that OH needs it.
I can argue with this. If you run only openHAB on an older Raspberry it might be enough. However in a lot of cases you need to run additional things for your home automation. Like I need to run a servlet for my Alarm System, Node-RED to work with HomeKit, Docker containers for other home automation things (like TasmoAdmin), etc… If this is the case, I think the 1GB RAM is not enough. I had lot of troubles with freezing up RPis randomly (but not completely just for a few - 20-30 minutes) and it seems that it caused by that the RAM was not enough.
The original question and my response were on performance. CPU that is.
Yes depending on what else you want to run, 1 GB may be enough or not.
Check out ZRAM. It ‘expands’ your RAM to some extent.
Sorry I haven’t seen it, I thought that was a generic (“Is it better in general”) question.
I have tried it earlier, but I had problems with it. Do you think it is worth enabling ZRAM on an RPI 4 with 4 GB? What benefit you can get from ZRAM in this case?
Yes, it’ll greatly reduce writes to SD, avoiding wearout.
I havn´t paied any attention to the ZRAM option… But I wonder if it would do much difference when using an SSD ?
I did read some… I stopped when I noticed, that you wrote something about shutting down the Rpi… I wonder how to deal with a suden power loss, (beside using an UPS ofcouse). I assume the ZRAM is a kinda alike a cache. But I got the impression, it will breake the information on the drive (SD/or whatever), and not just the cached data? Is that correctly understood?
No you can not use USB boot now, but they are working on it. The article is misleading
No, if power is lost before the cache is flushed to disk, the filesystem remains in good order. You just fall back to the contents it had (and still has, unchanged) when you started ZRAM.
My understanding is, and Markus will correct me if I’m wrong, the zram only flushes the changes out to permanent storage (i.e. SD card, SDD, USB thumbdrive, etc.) on a proper system shutdown. If it loses power suddenly it won’t get a chance to initiate that flush so there is no risk to corruption caused by the loss of power, assuming that all changes are written to the zram during normal operation. Thus, there won’t be any writes ongoing when the power was lost and there will be no risk of corruption from a partially written sector.
But, as mentioned, all the changes made since the last boot will be lost.
If you have stuff being written to disk outside of zram (e.g. InfluxDB persistence, Mosquitto logs, etc.) then you still run the risk of corrupting your file system if there is an incomplete write in progress when the power is lost.
Is that since last reboot as Rich mention?
Depends. Usually yes, but if you e.g. use the start/stop script or openhabian menu to enable it and don’t boot thereafter …
I’ve been running a pi4 with docker (mariadb, mqtt, grafana etc) for a while now at 2.1GHz and have now updated my home-auto pi4 to the same. Not had an ounce of trouble from them running at these speeds.
They both running quite a bit cooler than before (part pf the firmware update)
If for no other reason than the heat, it’s worth the update.
sudo apt update
sudo apt dist-upgrade
sudo rpi-update
** Reboot **
sudo sudo nano /boot/config.txt
Find the [pi4] section and add the following:
over_voltage=6
arm_freq=2147
Reboot
1 Like
Hi @CDriver
I recently moved my OH2 to RPi 4 on Docker. But things are slower than what I would expect. Do you have any data on how fast your setup is? For example, for my setup.
- Takes around 10 minutes for OH2 to fully be ready after starting the container
- When editing rules, it takes 5 minutes to parse, and another 5 minutes for the system to be “ready”
- SSH into OH console would take like 2 minutes.
I am using 2.4 alpine on Raspbian. It’s a headless setup, so most RAM goes to OS.
I used to have OH (2.2? can’t remember) on RPi 2 natively, it took around the same time to startup, but it seems to takes less time to change rules and go into console.
Then I moved to a Atom Z8350 system, natively, it takes around 2 minutes to boot and others tasks are much faster.
So I wonder if I should run OH natively.
Thanks,
Joe
I am not yet running my OH in docker - I have a test setup user docker but my “production” system is still native RPi4 2GB.
OH is slow to load rule changes etc if you are using primitives. This is pretty well documented here. Have you a lot of those?
Are you using VS Code and the LSP? I had that, admittedly 2.3ish time, which made rules only respond after 3-4 minutes.
Can you clone your container and strip out all the items and rules bar two or 3 test ones? It seems excessive what you’re experiencing.
In post #38 above, I showed the startup times between the 3B+ and the 4. What is interesting is now the 4 running at 2.1GHZ.
The RPi4 was 111 and 119 seconds over two runs. With the same items and rules (maybe one or two newer rules) the 4 running at 2.1 is now taking around 77 seconds. Quite an improvement.
I can certainly do more testing. But the same set of rules on the Intel Atom native (the machine died, so I can’t run any more test on it) setup parsed and loaded within 10 seconds, compared to 10 minutes in RPi 4 on Docker.
No, I just nano on terminal.
This is close to the Intel Atom native in term of startup time. Maybe I will find another SD and load OH natively and give that a go too.
I’ll setup the docker oh tomorrow and take a look for comparison.
Given the way Docker works, I would no expect you to see a significant speed up running outside of Docker.