ConBee ZigBee Stick and HA, will this work together?

In my experience Hassio can be a bit finicky about hardware, like it doesn’t always show up in the container as it should? I honestly haven’t played with it much though so maybe it’s different now.

If that is the case it might have to do with moving to a different dev right? Might need a mechanism to create unique device for conbee and other serial devices

I’ve build an image that works with hassio and the Raspbee, but I don’t have the hardware to validate that it also works with Conbee. It is based upon the debian-base image provided by @frenck and still needs a lot of work in cleaning up, but it does function within the Hassio addon page and can be managed through the addon utility of home assistant. You can find the code https://bitbucket.org/jongsoftdev/hassio-addon/src and if it helps to create a proper setup version then take as much as needed from it.

1 Like

Thought I’d give this a go with my conbee. My addons now contains a folder named dresden-deconz, which contains several files (eg build.json, Dockerfile etc). I’m not able to see anything in the hassio addon page though. Any obious errors I’m making? It’s a fresh install of hass.io.

In hassio part of your installation you should be able to see addon store. Under local addons you should see any addon you manually added to the /addons directory.

Oh, I see it now! Must have been a delay in the system for some reason.

For others, this is what my folder structure looks like:
image

Add-on store:

Getting these errors when installing though:

18-03-03 10:38:00 INFO (MainThread) [hassio.addons.addon] Create Home-Assistant addon data folder /data/addons/data/local_deconz
18-03-03 10:38:00 ERROR (SyncWorker_8) [hassio.utils.json] Can't parse /data/addons/local/dresden-deconz/build.json: does not match regular expression for dictionary value @ data['build_from']['aarch64']. Got 'hassioaddons/debian-base-aarch64'
does not match regular expression for dictionary value @ data['build_from']['amd64']. Got 'hassioaddons/debian-base-amd64'
does not match regular expression for dictionary value @ data['build_from']['i386']. Got 'hassioaddons/debian-base-i386'
18-03-03 10:38:00 WARNING (SyncWorker_8) [hassio.utils.json] Reset /data/addons/local/dresden-deconz/build.json to default
18-03-03 10:38:00 INFO (SyncWorker_8) [hassio.docker.addon] Start build local/amd64-addon-deconz:1.1
18-03-03 10:38:09 ERROR (SyncWorker_8) [hassio.docker.addon] Can't build local/amd64-addon-deconz:1.1: The command '/bin/sh -c chmod +x /start.sh' returned a non-zero code: 1

As this is a test before I deploy it on my father’s Raspberry PI, I’m running hass.io from ubuntu in a virtual machine on w10. Also tried an install on my production Raspberry Pi with the same result. I’m happy to do any test required to make this work. :slight_smile:

Hi Robban,

editing the entity_registry.yaml was the thing that perfectly works for me.
After renaming lamps in deconz it can just be adapted accordingly (or deleted and restarted) in the entity_registry.yaml.

Thank you very much for your help!

1 Like

@Robban Noticed a quirk with the new renaming feature in 0.65’s frontend - I can rename lights but not groups of lights created in deconz. The gear icon doesn’t appear.

I noticed that they are not listed in the entity registry.yaml. That would mean that they don’t have a unique id reported from Deconz.

A solution to this would be to generate something based on the group name. But that is a quite volatile resource and could possibly put a lot of Crap in to the registry file

@Robban, since the upgrade to 65.6 I’m seeing this error in the logs:

Unhandled error in exception handler
context: {'exception': AttributeError("'NoneType' object has no attribute 'async_update'",)}
Traceback (most recent call last):
  File "uvloop/handles/stream.pyx", line 784, in uvloop.loop.__uv_stream_on_read_impl
  File "uvloop/handles/stream.pyx", line 563, in uvloop.loop.UVStream._on_read
  File "/usr/local/lib/python3.6/site-packages/pydeconz/websocket.py", line 98, in data_received
    self.async_callback(payload)
  File "/usr/local/lib/python3.6/site-packages/pydeconz/__init__.py", line 159, in async_event_handler
    self.sensors[event['id']].async_update(event)
AttributeError: 'NoneType' object has no attribute 'async_update'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "uvloop/loop.pyx", line 2062, in uvloop.loop.Loop.call_exception_handler
  File "/usr/src/app/homeassistant/core.py", line 94, in async_loop_exception_handler
    _LOGGER.error("Error doing job: %s", context['message'], **kwargs)
KeyError: 'message'

@marthocoo This means a sensor type in your system isn’t supported by the component yet. Do you know which one?

0.66 should bring improvements to not generate these errors.

I will look into your PR tonight :+1:t2:

Same here:

2018-03-25 15:34:21 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type ZHAPower (Power 51)
2018-03-25 15:34:21 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type Daylight (Daylight)
2018-03-25 15:34:22 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type ZHAPower (Zwischenstecker)

ZHAPower support is added in 0.66, right? Thanks already! What about Daylight?

@Skorfulose @marthocoo has a PR on the library to add support to daylight. I will look at it later tonight

OK it must be the Daylight sensor then. I pushed a commit this aft to the PR that changes it from the binary_sensor approach I originally took to a sensor whose state is a string corresponding to the phase of daylight. I think that’s much more useful from an automation point of view. If you’re good with that then there’s only a small PR needed against HA to add “daylight” (true/false) as an attribute to the sensor.

@martikainen
Did you ever try to re-pair or reset this xiaomi aqara smoke detector ? For me the initially pairing worked out of the box. First attempt worked. As shown in reply to REST GET. After a reset of the ConBee from Phoscon App any attempt to re-pair fails. All other devices re-paired ok but the xiaomi aqara smoke detector. Most hints suggest to press the push button 3x in a row to initiate a re-pairing.
By now tried all kind of mumbo-jumbo already. Power cycles of ConBee, multiple sequences of 3x, many-times push button. Does not get re-connected.
Using a deCONZ ConBee (2.05.21, FW 261F0500).
Any help very much appreciated.

Nope, lucky enough I’ve never had to reset my conbee, when that day comes I’ll have a weekend of pushing buttons to do (about 100 zigbee devices around the house… )

But I have 1 water sensor that I can’t add to conbee, I’ve tried everything and must have pushed the damn button at least 500 times by now.

Just now managed to re-connect the thing. It appears the sequence of 3x push button needs to be very quick. Ea subsequent push before the beep of previous ends.

1 Like

Just a reply to anyone who is having the same issue with a xiaomi sensor, I gave this another shot yesterday and spent 30 minutes trying to push that damn button… All of a sudden the sensor didn’t light up, so I changed the battery and after that I added it at the first try…

Sooo… change batteries! :slight_smile:

Good day. What would be required to extend area coverage? Xiaomi zigbee plug?
Thank you.