Dear all, after upgrade from 4.1.1 to 4.1.2-1 openhab is total instable.
It needs frequently restart because the GUI freez!
Other issues:
sonoff device stop reporting (works with 4.1.1)
z-wave devices go to sleep after a while. Shown red in Things… but working: you have to wake them up repeating several time orders. not acceptable
Sorry I didn´t report that i closed round about 100 sessions in 4.1.1 during the fix: after a while z-wave start working? Don´t know if it depends on the closings but I think for all others it should be reported!
I thing: now for me it´s finish.
I start with 1.17! and I finish mo with 4.1.2-1
There where textual definitions… everbody could see what was given … now everthing is going into darkness : some mous klicks and entries iin not visiable database: can work or not, but not seen to controll!
and so on and on…
Support for text file based configs has not and will not be removed from OH. If you don’t like using managed configs, don’t use them. You don’t have to.
And you can see everything that is configured through the UI. They are all located in text based, human readable files in $OH_USERDATA/config and $OH_USERDATA/jsondb. Whether you configure through XTend based config files or the UI you can examine every byte of that config with a simple text editor.
Not that that is relevant to your current experiences. There isn’t anything that you can configure to cause these problems. By all appearances you are seeing a bug or an external problem (based on this thread and the last I’m certain it’s the latter). Maybe one of the add-ons has a memory leak. There have been several that have been fixed since OH 4.1.2 was released.
Given the number of changes between 4.1.1 and 4.1.2 are extremely small (Release openHAB 4.1.2 · openhab/openhab-distro · GitHub) it should be relatively straight forward to identify which add-on is causing problems. Neither of the changes to core would be relevant to this.
But since you are running OH 4 on an RPi 3 I’m almost certain that the root cause to all your problems is that you’ve run out of RAM. You have too much running on that machine for the amount of RAM available. The UI freezes and sessions are left open because OH (and everything else) is stuck waiting around for stuff that should be in RAM to be retrieved from SWAP. That would explain all the behaviors you describe on both threads.
Sadly, Java 17 requires more RAM than Java 11 did which means that OH 4 requires more RAM than OH 3 did. And on an RPi 3 there was already just barely enough RAM to run OH 3.
And that’s not an openHAB problem, it’s a hardware problem.
I hate to see anyone go away mad but based on your replies on the thread you linked to and this post I suspect you’ll be much happier with a commercial home automation solution, one where you can pay someone to help you since this forum doesn’t count as support in your book.
As a warning to anyone else who comes along, I don’t want this to turn into another “openHAB sucks! No it doesn’t!” thread. We’ve had one not too long ago and I see no need to rehash the same old stuff again so soon since the last one.
Please do respond if you have productive things to discuss for the specific behaviors described in the first post.
Well, again, you’d probably have a more enjoyable time with a commercial solution. When you have a DIY solution, it’s up to you to keep it up.
Never run updates. Simple as that. Never run apt upgrade, never run upgrades from openhaban-config. You can freeze the version of OH. There are several tutorials on the forum for how to do that so you can upgrade everything but openHAB. But that’s just asking for trouble by increasing the likelihood that something outside of OH is going to break something.
That can keep you going for a good long time. At some point something outside your control will break (e.g. an API you depend on is going to shut down or change) and you’ll either have a broken system or have to upgrade then. And because you waited that’s going to be a lot more work as there will be more changes to deal with all at once.
There’s no such thing as a free lunch. You can do the work now, or you can do the work later but at some point the work must be done or the project needs to be abandoned.
But of course, if your root problem is lack of RAM, installing 4.1.1 isn’t going to fix anything. You need to free up RAM or move everything to a machine with more RAM.
As @rlkoshak said correctly, there is no such thing as a free lunch.
If you want someone to take care of your private productive setup, please go find someone willing to and pay him.
But if even you are not willing to spend any time on this, do not expect any volunteer here to do it for your private benefit.
While totally uncommon to expect that from a software - remember you are not buying a service here - it’s documented in several places including the release notes. At a minimum, you should have read those before upgrading. I even told you in some other thread to keep your old SD to that purpose.
@sjheinz
Dude, I guess you’re frustrated. Been there.
If you do want to switch versions, easiest way to do this is use OH as docker container.
I run it on a RPI5 / 64 bit BullsEye headless. Runs
vpiccu (homematic server)
docker
containers are:
openHAB
code server (to edit textual config with VSC in browser)
Influx
Pihole
coronograf
cadvisor
prometheus
mosquitto
grafana
frontail
samba
Got a couple of scripts to set up my whole system. Basicly you have to figure out
docker compose file with port mappings
where to map which container folder on the host
users
permissions.
Then you copy your old config to the new machine and thats about it.
Maybe you need two new tokens (one from influx for OH and one from OH for the VSC OH extension)
If there is much interest in how to set up a docker based system, I would be willing to write a tutorial. If that is then proof-read by some of the Pros around here that would be ideal.
Once you got that running, switching versions is nothing more than stating the version number of the docker container in the docker compose file.
Anyway, @rlkoshak is right when he points at your RPI3 memory. If you are low on memory, anything can happen. Sooner or later. Totally unpredictable.
Get yourself a RPI4/5 with 4GB and you’re good to go.
I migrated my docker system from RPI4 to RPI5 just yesterday. Took me just under two hours. Runs flawlessly.
There are several docker based tutorials posted to the forum but I would not object to another one. There are lots of ways to set up a system using docker.
