AAARRRRGGGGGGHHHH!!!
So, I finally got the conbee 2 to show up after several reboots and plugging directly into the pi3. I copied the id to the config page of the addon and nothing (bad gateway).
So, I went back into hardware and…the device has disappeared again! What the hell? This is getting ridiculous!
Had some issues with the HA addon in the past (now still on 5.3.3 which runs stable) so looking into this. Did you install Deconz on Ubuntu (ConBee Installation) or are you using the Marthoc Docker image?
Hi.
I installed Deconz on my Ubuntu on bare metal using apt. No Docker.
I prefer running software as close to the way the original developers runs it.
Is the stick physically close to the ssd drive? If it is, move it as far away as possible.
The stick being close to the SSD can cause RF interference.
But it cannot cause the device to disappear.
@arm1e sorry I missed you had already said that you were on a RPi 3. The USB3 issue is naturally related to Rpi 4
I am out of ideas why your stick looses connection.
I gave up on Rpi for HA the first week of using HA because I wanted a machine with more performance and I did not want to run with SD card either (seen several of those die in RPis). I now run on a Celeron based NUC (dual core) and love the performance and stability that gives me
Have you tried with SD card instead of USB?
What else can it be. Marginal power supply? I have seen a Pi perform like shit when I powered a touch screen from USB. When I moved the screen to the 5V pins on the Rpi all the trouble with power went away. The SSD you have may pull a lot of power and starve the stick. You could try a powered USB hub.
That release (V2_05_80) is flagged as a “Pre-release” version. The deCONZ add-on gets updated to the newest stable releases typically, so I doubt it will be bumped to Iko Iko until it’s released as stable.
Thanks for reply.
I saw the change log on the deconz plugin which ver 6.0.0 also using pre-release deconz version 2.05.79.
All I can tell you is that someone already submitted a PR to bump the version, it wasn’t accepted, and the reason given by the developer is that it’s pre-release.
Yea, just saw that. Not sure if it’s reject as the PR still opened. Will see if deconz can do a stable release. Thanks.
What a monster thread 
So I´m having a version of the problem with devices not avaible to HA but I can connect and see the devices reporting correctly in the Deconz addon.
My setup is running supervised in docker on ubuntu 20.04 LTS on a RPI4 8gb.
The problem occours after host restart or if I do a docker -restart.
The workaround with removing/ adding the integration solves the problem but adds another, I lose my custom names and custom Entity id on all the enities and it´s a pain in *ss goin through all of them.
Core-log after restart:
2020-08-19 05:47:03 ERROR (MainThread) [homeassistant.components.deconz] Error connecting to deCONZ gateway at 172.30.33.4
2020-08-19 05:47:03 WARNING (MainThread) [homeassistant.config_entries] Config entry for deconz not ready yet. Retrying in 10 seconds
2020-08-19 05:47:13 ERROR (MainThread) [homeassistant.components.deconz] Error connecting to deCONZ gateway at 172.30.33.4
2020-08-19 05:47:13 WARNING (MainThread) [homeassistant.config_entries] Config entry for deconz not ready yet. Retrying in 20 seconds
If I use the VNC-plugin to the Deconz server I can see that the IP of the Deconz server has changed from 172.30.33.4 to 172.30.33.6.
Is there any way I can update the Integration automatic or manually?
/Cheers
Hello,
I’m using Deconz ConBee II since january 2020.
My hardware configuration is:
Software configuration:
I have read there were an issue with the deconz home assistant add-on since version 6.0.22, because of an unsupported linux kernel version.
In my case, kernel seems to be old (3.10.105).
I wonder if I can upgrade the firmware of my conBee II dongle and/or the deconz docker container ?
For those who follow. - Solution below.
I found the configuration file for the intergrations in config/.storage/core.config_entries.
The file had several Deconz entries that had the key “source”: “ignore”, it seems like the IP had been updated on of those but not in the actual Deconz entry that is used by HA.
I updated the IP on all entries and the Intergration came back to live after a HA restart.
I then deleted all the Deconz entries except one ( the one without ignore ).
After a Host reboot the Deconz integration updates the IP accordingly.
Happy camper again.
From: /config/.storage/core.config_entries
{
"data": {
"entries": [
...
{
"connection_class": "local_push",
"data": {},
"domain": "deconz",
"entry_id": "5526147b228741d9a79f750c169dd628",
"options": {},
"source": "ignore",
"system_options": {
"disable_new_entities": false
},
"title": "Ignored",
"unique_id": "000000000000",
"version": 1
},
{
"connection_class": "local_push",
"data": {
"api_key": "XXXXXXXXX",
"host": "172.30.33.6",
"port": 40850
},
"domain": "deconz",
"entry_id": "22020d2f536c457b909da9c473c142b6",
"options": {},
"source": "ignore",
"system_options": {
"disable_new_entities": false
},
"title": "Ignored",
"unique_id": "00212E05A3AC",
"version": 1
},
{
"connection_class": "local_push",
"data": {
"api_key": "XXXXXXXXX",
"host": "172.30.33.6",
"port": 40850
},
"domain": "deconz",
"entry_id": "c61966a2c7154a99b8978dda70b0aecd",
"options": {
"allow_clip_sensor": false,
"allow_deconz_groups": true,
"master": true
},
"source": "user",
"system_options": {
"disable_new_entities": false
},
"title": "00212E05A3AC",
"unique_id": "00212E05A3AC",
"version": 1
}
...
]
},
"key": "core.config_entries",
"version": 1
}
To: /config/.storage/core.config_entries
{
"data": {
"entries": [
...
{
"connection_class": "local_push",
"data": {
"api_key": "XXXXXXXXX",
"host": "172.30.33.6",
"port": 40850
},
"domain": "deconz",
"entry_id": "c61966a2c7154a99b8978dda70b0aecd",
"options": {
"allow_clip_sensor": false,
"allow_deconz_groups": true,
"master": true
},
"source": "user",
"system_options": {
"disable_new_entities": false
},
"title": "00212E05A3AC",
"unique_id": "00212E05A3AC",
"version": 1
}
...
]
},
"key": "core.config_entries",
"version": 1
}
Hi all,
What could cause that the deconz addin just stops? Almost every other week the addon just stops. I can manually start it again without issues.
Hi all,
It seems the random stops keeps happening. Also ocurred to me with the same logs like any other else. I’m on supervised vm under proxmox. If I click start runs without problems for some time, less than a week.
My Deconz is rock solid. And it runs installed with apt (what people call on “bare metal”) in an Ubuntu 20.04. I have never seen it crash since I moved away from running it as HA Addon.
I am not saying that Addons are a bad thing. But each time you layer something on top of something else, wheater it is Docker or VMs or anything else you put your service on top of a software with probably 500-1000 known bugs (open or closed unresolved by a stale bot). This is not putting blame on anyone. It is just a fact.
The issue with bare metal is that if you run multiple services, and they have common dependencies, then you can have instability related to the different libraries and different versions. There is not a specific way that is the best on all parameters.
My personal experience is
When you run in a VM ,then the VM layer itself is a source of bugs. Proxmox has at least 1000 open bugs. Docker has its own huge bug database. 1000s
You end with a tall software stack. A tall house of cards.
Software running on an Alpine Linux, in Docker container, inside a VM running on a Linux OS. That is a lot of layers. I prefer reducing that to the running software on Linux. My experience is much more stability.
But it is also much more a pain to keep backups and get up again if the disk crashes. There are pros and cons and the best is often a compromize and mix of solutions.
So you guys that are happy with Proxmox. You could try to replace Deconz as an addon in the Home Assistant VM and move it to a Debian running in a Proxmox VM installed using apt. It may turn out to be more stable. It may be worth a try.
Just woke up to deCONZ stopped again.
And again the logs don’t show anything unusual, it was running fine, then just stopped.
As for not using Docker or VMs and just running on bare metal, that’s like recommending a car that has no ECU and the only “electronics” are the distributor and an AM radio. Sure it maybe more reliable in a sense under certain conditions, but it’s far less practical and has many more downsides than modern solutions. VMs and containerization are industry best-practices for good reason and aren’t going away anytime soon.
Just an alternate view on that:
I’m on deConz as AddOn on Hassio from the beginning with no major issues exept some connection fails may be due to interferrence with the W-Lans in my area.
I updated until 5.3.4 which I still use and it is rock solid.
I’m a standard user with affinity to software development but I’m always careful these days and read threads before updating. The reason is, and that is good in priciple, that my family doesn’t accept any longer that the Home Assistant makes trouble instead to assist our lives. And thats exacltly what I wanted to achieve.
We should keep into consideration, that the target market are people, who have fun to automate their house but are not developers or experienced it-freaks. They just want to customize their routines and then have fun on its results. The only solution can be a modular, supervised system with reliable addons or interfaces in order to enhence the standard with some individual solutions. More or less complicated architectures doesn’t fit to these requirements i.m.o. That means in the end, the user wants to enter amazon and buy a Home Assistant, pre installed on a cheap hardware and maybe pre configured with some standard interfaces to weather providers or hue.
PS: Supporting many (hardware)configurations can not be the goal as well. We have learned from google/android how complicated it is, to manage a lot of setups by keeping the quality on a high level.
It is ok, that there are some freaks, who run an own core installation on a certain os for what reason ever. But the major use case, will be the configuration described above.
Your cars ECU in your car runs on a Linux, running on a container, that runs in a proxmox VM installed on a Linux server? I think not. Poor analogy
You’ll find its actually a USB3 issue not the pi in general. There are a number of articles about USB3 and the 2.4g wifi/zigbee spectrum. https://www.intel.com.au/content/www/au/en/products/docs/io/universal-serial-bus/usb3-frequency-interference-paper.html
Thata why the whole adding the usb extension comes into play get it as far away from the usb3 port
Please do not make this a religious principal discussion pro or con VMs and containers.
I offered my experience about my very stable Deconz system. And my experience with running stable software in general. And as I wrote there are advantages and disadvantages. If your Deconz is unstable and your wife hates you because she can never turn the lights on and off then it may be worth rediscovering the good old way of doing things.
And it is not even more complicated.