After restarting my OH (3.3) installation faced an error with the deCONZ bridge which showed an error message (destroyed container cannot be restarted…)
There’s already a bug on github on that topic Link
Restarting the deCONZ bridge item using the UI inside OH fixes everything.
Any ideas how do deal with that …any way to restart the bridge item automatically?
Greets,
Matt
PS: under OH 3.2 never faced this issue, so it has to be something which came with the latest release
I have the same problem.
Any progress on this?
Regards,
Herman
Just updated to 3.3 from 3.2 and faced the same issue
Same here. After Updating from 3.2 to 3.3, the deCONZ bridge showed this error message.
Same error message was reported earlier for other versions of OH.
One of these threads is this one:
In that case it was reported that the clock was not synchronized.
Besides that in that thread @J-N-K mentioned:
I have only seen this “destroyed container could not be restarted” error on my test or production system once. That was when I had two openHAB instances running with the same API key. Could that be the case?
Thank you Wolfgang
…the first mentioned case was one I’ve created. It was slightly different from this one …but the hint with the time is something I need to watch for, but now on the side of OH (win) not Pi.
Last time I’ve restarted OH there was no issue at all …will have an eye on that.
The second mentioned case is impossible in this config because OH will get restarted with the VM where it lives …but good to know that there could be issues with two instances of OH. Is there a case where somebody wants to run two instances of OH (except for testing)?
Same issue over here. OH3.3 running in a docker container, Phoscon in a second container. All on a Synologu DS718 NAS. Used to work like a charm, but somehow the OH binding loses the connection to the phoscon app/conbee stick. When this happens, the phoscon docker container app is still responding normally in its web interface.
When pausing/starting the conbee binding everything works again. But next day it is offline again.
Pretty cluless here, must look into logs et all.
Hans
I have started experiencing very much same behavior on RPi 4B with Raspbee 2 hat, after migration from OH 3.2 to OH 3.3. It still applies for OH 3.4 M4, which I did some tests on last night. Deconz app running at 8081 shows “0” (zero) for “zigbee channel” and “unknown” for “network id”. Wonder whether this is a Raspbian, OpenHAB or even Deconz issue? Is there a possible rollback to OH 3.2 as a “safe harbour” until issue resolved?
I did a rollback from OH 3.3 to 3.2. The error disappeared, everything works as expected. Therefore this was the workaround for me
Good to hear and promissing! Do you have a recipe on how you did conduct the rollback? That is something I am looking for. It seems to me that no matter how long back I browse after a 32bit openhabian image, installation seemingly always ends with OH 3.3.
First of all I made a backup - just to be sure.
Then I called the update-script with the 3.2.0-version.
For windows (in my case), that was: update.bat 3.2.0
I guess that the call of update.sh is similar for other OS.
The script warned me, that I’m going to do a rollback to a previous version and that there’s no warranty, but I tried instead and it worked in my case.
Hi,
does anyone have experience if the problem still exists in OH3.4? Or is there a bugfix now for the issue?
Regards,
neuling10
Hi,
I just upgraded from 3.0.2 to the newest 3.4, had the same problem and found this thread. I downgraded to 3.2 and now it works again. Seems to be still existing
Hi there,
I just upgraded to the newest 3.4.2 and my deconz bridge shows no errors anymore and works as expected.