Message during upgrade and later message if ignored are shown in this example:
Deconz Service doesn’t detect the Conbee II Stick on Debian Bullseye
Symptom
The conbee II isn’t detected in the Gateway
As I have a feeling that a lot of us are using the at Zigbee stick, there is actually pitfall on the latest bullseye that breaks it finding the stick.
Mitigation
Patch like /usr/lib/udev/rules.d described here and change via
sudo nano /lib/systemd/system/deconz.service
the following line by adding your device at which the stick is connected to
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8070 --ws-port=8070 --dev=/dev/ttyACM0
2 Likes
Do you know how/when this was introduced? For example, if already running openHABian 1.8 and then upgrading to 4.0, will the suddenly trigger this? Or was it a package upgrade that caused this to happen some time ago when already running openHABian 1.8?
Maybe I wasn’t too clear above: It is NOT an openHAB issue it is Debian bug where someone introduced a wrong symlink behavior as far as I understand. It seems it was fixed in April but I also have the feeling that this is still the part of the openhaben bullseye version - at least I still have the problem.
See the details linked about it here
So, It isn’t an openHAB issue per se but rather part of the bullseye that comes with openhabian. Maybe someone has an idea how we can update bullseye to a point where we know this is not an issue anymore (I currently don’t have the time to do so and try it out as I am happy that my complex OH4 production setup finally runs almost everything like before).
2 Likes
Jacob, do we want to add it into your great list above? How about adding an index above that description that gives a quick overview on all topics like
- Upgrade to 4.0 using openHABian doesn’t seem to work at all.
- TransformationService of type ‘JS’ is unavailable
- ScriptEngine for language ‘application/javascript’ not found
- Blocky rules not working: PolyglotException: ReferenceError
- High CPU usage
- Channel types or config descriptions are missing in the respective registry
- Rule does not trigger on Astro event
- Shelly: Incompatible units
- EnOcean: Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
- openJDK17 fails due top dependencies when you are still in Theo Buster Release of Debian or openHABian
- Deconz Conbee II stick not detected on Debian bullseye
I had this issue with 4.0.0 M1 as soon as I upgraded way back in April first reported here
On several occasions I thought I had tracked it down but it is still a problem for me. (happen yesterday) currently running 4.0.0 snapshot 3460
Sure - done! 
1 Like
In openHABian 1.8 release - #2 by mstormi
was mentioned:
Memory usage
The Java upgrade seems to be using quite some more memory than before and memory reserves are tight particularly if you are on on Raspberry. See corresponding question in the FAQ .
But I couldn’t find the corresponding question here…
BTW: I set
EXTRA_JAVA_OPTS="-XX:+ExitOnOutOfMemoryError -Xms900m -Xmx2500m"
in /etc/default/openhab
And CPU Usage and RAM USAGE looks good in my opinion:
Another work around is to link the equivalent State Channel to a DateTime Item and use the Time is Item trigger for the rule. That works in the UI as well as file based.
Great initiative!
I would suggest to also add this thread to the FAQ:
1 Like
Hi to All,
I’m also facing very high CPU loads. Before Upgrading to 4.0.1 I was running OH3.4.1 without any issues @ average CPU Load ~15-20%.
Running on, Raspberry PI 4, 8GB, Samsung 890 M.2 500GB
BTW: for OH4.0.1 I made a complete new Setup up on a new Harddrive, but I “configured” OH with a Backup.
Can you change the display option in htop to show the thread names?
That makes it easier to figure out what is causing the load.
See:
It could be event handling related based on those thread names.
There have been a few PRs regarding event handling which may have caused performance issues:
#3141, #3299, #3523, #3533, #3702
I was reading the PR’s, but reading does not mean understanding - thats too complex for my simple mind 
Is there a way to check those EventTrigger-Issue for simple “end-users”?
Im running OH with 442 things, 1839 items, 322 rules (all in DSL)… I’ll have a horrible night, thinking of maybe checking everything or maybe updating a massive portion of my configuration…
I also seem to have this issue now (with 4.0.1):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5147 openhab 20 0 887048 581872 4768 R 98.7 58.5 102:08.36 upnp-main-queue
Is it necessary to also remove the comment in the line
# initialconfig=/boot/initial.zip
in openhabian.conf?
Yes, in openhabian.conf