Your binary sensor might by off sooner, but they won’t go on again after 2 min… So the binary is not the live status of the hardware… So it won’t go on again anyway in 2 min
Do you mean this below - this is one example of Aqara with deconz.configure adjustment -> time to detect again is one minute here?
Yeah, but that’s only the binary sensor, not the hardware, its false
Thanks for your response! Please educate me here - I am maybe totally lost here 
?
What hardware we are talking about here - my only statement is that with this deconz. configure feature you are able to let’s say roughly cut detect cycle to half. So in my example if motion for instance turns the light on now - it can do it again in a minute (instead of 2 minutes with original settings - roughly) Are we talking about something else what I do not quite understand here?
I am talking about the aqara xiaomi sensors, it will stay updating only after 2 min, so if you binary sensor is changing after 1 min… You still need to wait 1 extra min before it goes to the ON state again
Not with my Xiaomi Aqara motion sensor. The picture was one of them:
Detects 5:55:57 (State on)
Clears 5:56:07 (ten seconds after, state off)
Detects again 5:56:57 (one minute after the first detection, state on again)
Take a look of my picture I just showed you. Is there still something I do not understand?
From what I know, deCONZ has a default blind time for these sensors of 2 minutes, which you can adjust setting the duration parameter. This isn’t based on the hardware (see below), but some internal timer that deCONZ uses. If you change the duration to 10 seconds, then 10 seconds after motion was detected it will tell HA to clear the sensor. This doesn’t mean that the sensor is ready to detect motion again, though.
The sensors themselves (the hardware) have a blind time of 60 seconds, which aligns with that you’re seeing. If you don’t have a modified sensor this time is fixed, regardless of what you set duration to.
Regarding the modification: it puts the device in “test mode” permanently, which means it changes the blind time from 60 seconds to 5 seconds. You can make a solder connection, or use some conductive paint, or even just use a pencil (which I used). Matched with a duration for deCONZ this works very well, and I’ve been running about 8 of these sensors in test mode for over a year now, including in ‘heavy traffic’ parts of my house, without having changed batteries.
3 Likes
Thanks for excellent explanation! I agree 100 %.
All I am saying is that with this deconz.configure you are able to cut that “detection cycle” roughly to half - from 2 minutes to one minute (like you explained), which for me was good enough. Sure if you need better “detection cycle” you need also that hardware hack you are talking about.
So it is also fair to say this deconz.configure alone improves this “detection cycle”, because it does.
In practice it means for example movement in room will be reported to HA once in a minute instead of once in every 2 minutes - doesn’t it?
Yes, it does.
This should be added to a wiki.
I recently restored my HA instance to a VM from my original pi deployment. After reconfiguring deCONZ I’ve been having a lot of unreliable response from my devices. The logs seem clean with the exception of the following:
20-12-29 13:17:31 WARNING (MainThread) [supervisor.store.data] Can't read /data/addons/local/conbee/config.json: required key not provided @ data['arch']. Got None
I’ve removed deCONZ completely from my system and have rebooted a couple of times yet this error still comes up in the system logs. Any idea what could be causing this ?
1 Like
Hi maybe a known issue but since version 6.6.0 I got the same error when trying to update the addon from the GUI:
ERROR (SyncWorker_1) [supervisor.docker.interface] Can’t install homeassistant/armhf-addon-deconz:6.6.2 → 500 Server Error for http+docker://localhost/v1.40/images/create?tag=6.6.2&fromImage=homeassistant%2Farmhf-addon-deconz: Internal Server Error (“Get “https://registry-1.docker.io/v2/”: dial tcp: lookup registry-1.docker.io: no such host”).
Any Ideas how to solve it?
Someone else had issues with a docker URL.
Have you tried pinging that address to see if it’s up?
This component is driving me insane… Since I started using it, it made my RPI 3B+ crash every few days… I tinkered with the logging config for HA, that seemed to help a bit, but it would still crash every week or so…
The Conbee II i have used firmware 264A070 for months, I tried updating it at one point after buying it, but updating caused the component to not be able to find the device anymore… I recently moved my setup to a 10th gen NUC, the NUC doesn’t crash, but I see that Deconz looses connection with the Conbee II device every couple of days / a week, at a very similar frequency to how the RPI crashed.
So I thought I should try updating again, so I updated the device to latest (from the component’s UI, it showed 26660700 and disconnected after updating, I tried updating manually to newest (on their site, this was 26680700), the component still doesn’t find the device, I then tried 26670700, then tried 26660700, then tried 26650700, none of them worked.
My logs:
20:21:30:810 , 08:48:53
20:21:32:804 COM check bootloader
20:21:32:815
R21B18 Bootloader
20:21:32:816 Vers: 2.07
20:21:32:816 build: Jun 17 2019
20:21:32:816 , 08:48:53
20:21:32:818 device disconnected reason: 5, index: 0
20:21:33:741 wait reconnect 15 seconds
20:21:33:778 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_[censored]-if00 / serialno: [censored], ConBee II
20:21:34:741 wait reconnect 14 seconds
172.30.32.2 - - [04/Jan/2021:20:21:35 +0200] "GET /api/config?_=1609784496290 HTTP/1.1" 200 263 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
172.30.32.2 - - [04/Jan/2021:20:21:35 +0200] "GET /api/hassio_ingress/[censored]/api/config?_=1609784496309 HTTP/1.1" 403 140 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
20:21:35:741 failed to reconnect to network try=2
20:21:35:742 wait reconnect 13 seconds
20:21:36:742 wait reconnect 12 seconds
20:21:37:741 wait reconnect 11 seconds
20:21:38:741 wait reconnect 10 seconds
20:21:39:741 wait reconnect 9 seconds
20:21:40:741 failed to reconnect to network try=3
20:21:40:742 wait reconnect 8 seconds
20:21:41:741 wait reconnect 7 seconds
172.30.32.2 - - [04/Jan/2021:20:21:42 +0200] "GET /api/config?_=1609784503388 HTTP/1.1" 200 263 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
20:21:42:742 wait reconnect 6 seconds
172.30.32.2 - - [04/Jan/2021:20:21:42 +0200] "GET /api/hassio_ingress/[censored]/api/config?_=1609784503410 HTTP/1.1" 403 140 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
20:21:43:741 wait reconnect 5 seconds
20:21:44:741 wait reconnect 4 seconds
20:21:45:742 failed to reconnect to network try=4
20:21:45:742 wait reconnect 3 seconds
20:21:46:742 wait reconnect 2 seconds
20:21:47:741 wait reconnect 1 seconds
20:21:47:777 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_[censored]-if00 / serialno: [censored], ConBee II
20:21:47:789 COM check bootloader
20:21:47:801
R21B18 Bootloader
20:21:47:801 Vers: 2.07
20:21:47:801 build: Jun 17 2019
20:21:47:801 , 08:48:53
20:21:49:796 COM check bootloader
20:21:49:809
R21B18 Bootloader
20:21:49:809 Vers: 2.07
20:21:49:809 build: Jun 17 2019
20:21:49:809 , 08:48:53
172.30.32.2 - - [04/Jan/2021:20:21:49 +0200] "GET /api/config?_=1609784510486 HTTP/1.1" 200 263 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
172.30.32.2 - - [04/Jan/2021:20:21:49 +0200] "GET /api/hassio_ingress/[censored]/api/config?_=1609784510507 HTTP/1.1" 403 140 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
20:21:50:741 failed to reconnect to network try=5
20:21:51:798 COM check bootloader
20:21:51:809
R21B18 Bootloader
20:21:51:809 Vers: 2.07
20:21:51:809 build: Jun 17 2019
20:21:51:809 , 08:48:53
20:21:53:803 COM check bootloader
20:21:53:815
R21B18 Bootloader
20:21:53:815 Vers: 2.07
20:21:53:815 build: Jun 17 2019
20:21:53:815 , 08:48:53
20:21:55:742 failed to reconnect to network try=6
20:21:55:807 COM check bootloader
20:21:55:818
R21B18 Bootloader
20:21:55:818 Vers: 2.07
20:21:55:818 build: Jun 17 2019
20:21:55:819 , 08:48:53
172.30.32.2 - - [04/Jan/2021:20:21:56 +0200] "GET /api/config?_=1609784517598 HTTP/1.1" 200 263 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
172.30.32.2 - - [04/Jan/2021:20:21:56 +0200] "GET /api/hassio_ingress/[censored]/api/config?_=1609784517617 HTTP/1.1" 403 140 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
20:21:57:810 COM check bootloader
20:21:57:821
R21B18 Bootloader
20:21:57:821 Vers: 2.07
20:21:57:821 build: Jun 17 2019
20:21:57:821 , 08:48:53
20:21:59:816 COM check bootloader
20:21:59:828
R21B18 Bootloader
20:21:59:828 Vers: 2.07
20:21:59:828 build: Jun 17 2019
20:21:59:829 , 08:48:53
20:21:59:831 device disconnected reason: 5, index: 0
20:22:00:742 failed to reconnect to network try=7
20:22:00:743 wait reconnect 15 seconds
20:22:00:758 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_[censored]-if00 / serialno: [censored], ConBee II
20:22:01:741 wait reconnect 14 seconds
20:22:02:741 wait reconnect 13 seconds
20:22:03:741 wait reconnect 12 seconds
172.30.32.2 - - [04/Jan/2021:20:22:04 +0200] "GET /api/config?_=1609784524690 HTTP/1.1" 200 263 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
172.30.32.2 - - [04/Jan/2021:20:22:04 +0200] "GET /api/hassio_ingress/[censored]/api/config?_=1609784524707 HTTP/1.1" 403 140 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
20:22:04:742 wait reconnect 11 seconds
20:22:05:742 failed to reconnect to network try=8
20:22:05:742 wait reconnect 10 seconds
20:22:06:741 wait reconnect 9 seconds
20:22:07:741 wait reconnect 8 seconds
20:22:08:741 wait reconnect 7 seconds
20:22:09:741 wait reconnect 6 seconds
20:22:10:741 failed to reconnect to network try=9
20:22:10:741 wait reconnect 5 seconds
172.30.32.2 - - [04/Jan/2021:20:22:11 +0200] "GET /api/config?_=1609784531771 HTTP/1.1" 200 263 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
172.30.32.2 - - [04/Jan/2021:20:22:11 +0200] "GET /api/hassio_ingress/[censored]/api/config?_=1609784531780 HTTP/1.1" 403 140 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
(using latest component version) As far as I can tell it just looks like it tries to reconnect and fails in a loop.
One weird thing is that i don’t see the /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_[censored]-if00 device exposed in the Docker container, /dev/ttyACM0 is exposed though.
But if I change the Docker container settings to add that device, the new container fails to connect to HA, then if I restart the NUC, HA just recreates the old container that doesn’t have the device exposed.
I’m unsure if adding the device will fix it or not, but I’ve seen this suggested in a issue in github…
Any thoughts would be greatly appreciated, I can probably get it running again with the original version (264A070), but I’d prefer not getting stuck with such an old version, especially considering I think that version is majorly bugged.
If anyone has any hint of how to fix this thing, I’d greatly appreciate it at this point.
Edit: It seems that the last version that works for me is 26570700 (from 27th April 2020), everything after that (5 versions) don’t work. By this I mean the Conbee II device cannot connect in the Deconz component.
If you run deconz as a Home Assistant addon then there is an unresolved issue using the /dev/serial/by-id… type device names. It sometimes work but often it does not.
It works with simple /dev/ttyACM0 devices.
Problem is if you have both Deconz and a Z-wave stick from Aeotec then they both want to be ttyACM# and it will be random who wins. If you have this situation then I advice to move one of the sticks out of the Home Assistant realm. Either on different computer or if you run supervised - run Deconz in the host OS. See earlier posts about the subject in this mega thread.
The only other USB dongle that I have plugged in is for a wireless keyboard with a touchpad.
General info:
- HA 2020.12.2
- Supervisor 2020.12.7
- Deconz 6.6.2 (as a HA addon)
- Docker 20.10.1 (HA + Supervisor also running in Docker)
- Ubuntu 20.04.1 LTS
- Device:
NUC10i5FNH2
My config for the Deconz component is:
device: >-
/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE[censored]-if00
I’m not sure what other info could be helpful… I added the logs in the previous comment.
Oh wow. I wish I would have seen this before purchasing a conbee and wasting time troubleshooting it. Now I’m not sure what I should do with it… I lose connection once a week and am tired of messing with it. Is there any timeline on when a fix could possibly be implemented?
Why don’t you just address it the traditional way (IE /dev/ttyACMx) instead of by-id ?
It works fine the traditional way; the bug is only when addressed by-id.
Oh, I guess I didn’t realize it only affected addressing by id. I will have to give that a try. Thanks!
The only downside, as Kenneth mentioned, is that if you have multiple USB stick radios (IE Zigbee & ZWave) then it’s possible for them to swap locations on a host restart (IE ACM0 becomes ACM1 and vice versa) however that’s a “YMMV” situation. The names are stable for me across reboots.