deCONZ - Official thread

@frenck - It is a fact that two bug reports were closed quickly unresolved. Several people reporting the same problem (plus people here on this forum thread). I have not been able to convince anyone to reopen them since. No dialog with me after they were closed. How else should I interpret the situation?

Why are both issues closed? I summarized what I know in the later of the two bug reports and there is plenty of debug info from me in the first. And as you will see in the reports I got stuck and asked for help. And I have a theory of what is wrong. And actually @frenck you raised a question to the developer on the exact git commit that caused the issue (3 second delay)

Inserting the Conbee stick into another USB-port sometimes solves this problem
I had the same issue when i updated to 3.3 and this solved me problem.

Hi Klumpke. I tried that also. But I could not see an improvement. Note that on my Celeron based NUC the serial/by-id fails about 6 of 10 starts of the deconz addon. I tried restarting more than a 100 times trying many things. I could improve the frequency by moving things around but it never got reliable.

As I write in the bug report I think the issue is this

When you start the deconz docker it runs the udev process first which rediscover the devices and create the serial links in /dev/serial/by-id that points to /dev/ttyACM#.
It then waits 3 seconds
Next it tests if the serial device in the config exists. If not it dies and the container stops. If yes it continues starting deconz. If it passes the test it always succeeds starting up. It always stops the same place.

In a recent deconz update the way udev is invoked what changed and the 3 second delay was added.

My theory is that the the new way takes longer to create the symlinks in /dev/serial/by-id and can fail to finish within the 3 seconds. I got stuck in my debugging because I am too dumb to understand how to change the sources and rebuild the docker image so it starts within Home Assistant realm.

If any of you with the issue is smarter than me - with respect to docker - try and increase the 3 second timeout and see if the issue is resolved.

But I also again want to refer to the possibility to run the addon on “bare metal”. Running deconz on the Linux host OS, or on a different machine (can be a Raspberry Pi) has advantages. You always get the latest version with “apt update” and “apt upgrade” without waiting for the addon to catch up. Deconz and your zigbee network does not restart when you restart HA. But it is naturally not as easy as clicking the install button in the HA addon store. But it is an alternative which is what I chose to go with now.

And I must say that I LOVE deconz. It is rock solid stable for me. I just moved 35 lights, and 15 dimmers, and 2 taps, from Philips Hue to deconz where I already had 20 or so zigbee sensors and sockets. And it is rock solid. I love it. And totally depend on it now which is a bit scary

Incorrect, the question I raised there was to avoid the delay and only induce it if needed.

I did not imply your comment was related to the issue. Sorry if it could be understood that way. Just a reminder to you which 3 seconds we are talking about.

It cannot be the 3 seconds that created the issue. The old code had no delay.
We can see the udev is invoked a different way. Maybe this alternative way does not create the symlinks as fast as the old code which is why the 3 seconds was added? And if that is the case your idea in the comment is interesting. It would run faster if a machine runs udev fast and it will wait if there is something that slows down the udev device discovery. We just cannot wait forever because a typing mistake in the deconz config and thing would hang forever

my 5 cents

well after watching @frenck live show
i got the
dresden elektronik ConBee II The Universal Zigbee USB Gateway

went to our mitre10 kiwi here (home depot)

got the hue light with dimmer Switch

plug the conbee II in with a long lead so not close to computer

when to system

install the deCONZ addon
pasted that long text into the config

plug the hue light in pres the I O at the same time light flash

and it peared happer camper
with the dimmer on back press the setup back to the phoscon app did the added the switch

and that work very happy camper

got some Xiaomi door switch and the Magic Cude (which is f… alsum.)

pair them now this was a couple month ago the next day both Xiaomi stop working :frowning:
re pair same couple days later stop working
googling did nothing gave up
last week sour there was update for the deCONZ addon did the update rebooted everything
hue stuff still work :slight_smile:
repaired the
Xiaomi door switch and the Magic Cude
they have not miss a beat yeat

so thanks guys for the hard work you guys have done

:beers:

2 Likes

Has anyone been able to get xiaomi vibration sensor to work with deconz? Ive added it in phoscon and it appears as a binary_sensor in home assistant but can not use events with it like the other switches.
Advise is appreciated.

Why can’t you use events?

No events shows up.

Hi

Different sensors work different ways and there is a good reason for it. And it is the same in the ZHA implementation after some recent changes

A sensor is represented as a binary_sensor when it has defined states.Examples are

  • A Window/Door sensor is either open or closed. It remains open or closed as long as the door/window is open or closed. A Zigbee sensor can be queried. You can start up HA from cold and it will get the present state of the window from deconz. The cheap 433 sensors cannot do this. They can send an open or close state. Some can only send the open state. You cannot ask the sensor if the window is open or closed and the sensor is not updating its state. It is one shot and if you missed it you will never know. The beauty of the zigbee (and Z-wave) sensors is that they have two static states. They are open or closed. And this fits a binary_sensor in home assistant.
  • A remote control (a dimmer with 4 or 5 buttons or the small 1 or 2 buttons ones) sends a code when you press the button and a code when you release it. But you cannot afterwards say that the dimmer is in “on” mode or “off” mode. A button press or release is an event. If you have a groups of lights and two dimmer remotes and you turn on the light with remote A and turn light off with remote B you cannot say that remote A is still on and remote B is still off. They do not have a steady state. They send a button event and then it is over.
  • Motion sensors are binary_sensors. They go on when they sense motion. And they go off after a short time when no motion has been seen in a given interval. They have two states. Either there is someone moving and there is not. So they are binary_sensors

To trigger automations from binary sensors the trigger is the change of state from on to off or on to off. And you can add delays to that so it becomes a trigger when a motion sensors goes from on to off and has been off for say 2 minutes.

To trigger automations from remotes you use the events as trigger.

A little confusing for beginners but once you get the idea it is actually very logical and simple.

2 Likes

If you mean these:

https://uk.gearbest.com/smart-home-controls/pp_009661787808.html

I use them and get events on deconz_event for vibration, drop and tilt:

  • 1007 - shake;
  • 1008 - drop;
  • 1009 - tilt.

Does anyone knows if a sound sensors exist? With the possibility to listen on s specific sound?

Yes, how have you added it, as a sensor or switch?
I have mine as a sensor but it doesn’t give out any events for me, tried to shake, drop tilt, nothing.

image

Added as a sensor. Didn’t get any binary sensors. Only entity created is the one for battery level.

How did you manage to do that? :frowning:

Just added as a sensor in phoscon

Beta has been cut, if anyone wanna help try out the new device automations for deCONZ you can upgrade to 0.99 beta.

You will then find all your remotes that was previously only available as events easily selectable from a drop down box when selecting device triggers

thats a nice improvement indeed

ah, thats why you wanted that debug earlier :slight_smile:

Yes, I wanted as wide of support as possible

That is strange as hell since I get this when added.