deCONZ - Official thread

[KennethLavrsen]

It is actually a good feature to turn off. Before it was added as a config, all new devices added in Phoscon were sucked into Home Assistant the minute it was discovered and before you had the chance to rename the default name to something useful.

By turning this off, you can pair new devices and rename then first, and then pull them into Home Assistant so you avoid having to rename the devices and their entities in Home Assistant.

To pull devices in you go to developer tools > services and key in deconz.device_refresh and submit it with no data. That makes HA pull in new devices when you decide you are ready for it

[ekt]

thanks @KennethLavrsen
i might submit this to the deconz integration documentation page in github
And CLIP sensors is that daylight sensor tha deconz generates automatically?

[martinst (Martin)]

I have a conbee II stick with several zigbee sensors like the aqara motion/temperature/door sensors and some lux sensors (from AliExpress).

They are all at the same place and I’m still in testing mode to see if everything is reliable. I noticed that one temperature sensor and one lux sensor were not updating anymore (after some days) for a period of 16 hours. I have pressed the buttons on the devices to reconnect them and now they are working correctly.

What could be the reason for this? All the sensors are on the same table, so they are all at the same distance.For me this is a serious issue because you don’t know if all sensors are still working. So you have to check them the whole time?

Is z-wave more reliable or must be the conclusion that you should only have wired sensors for reliable working?

I noticed also that when you stop deconz software, you change some states of the sensors, so for example open the door/window or close it ==> then you restart deconz, the states of the sensors are not always correctly. I think this is because of the battery sensors are one way sending the information and that deconz software cannot poll the information. So you have to wait till a change of the state of the sensor is pushed to the zigbee network. Is that correct?

[PluM59]

Hello
I have a conbee II stick with several zigbee sensors like the aqara motion/temperature/door sensors
and many light like hue, osram, and legrand netatmo roller cover switch.
I use rasperry pi 4 with hassio.

My problem is about :
when a power cut occurs and my rasperry restart, the xiaomi sensors and only them become not working in home assistant.
In the phoscon application they are ok, change state correctly but in ha they no longer change state.
I tried to use the deconz_refresh_device service in ha but it is the same. I tried to restart ha then start deconz , same issu .
To solve it I have to remove all of them from phoscon, restart ha and then put them back in part one.

thx a lot for help

[boelle (Bo Herrmannsen)]

just got things working, but i have noted that phoscon drops outs a lot where it says “not reachable”

otherwise very easy to config things

EDIT: adding the ikea trådfri lights and the puck remote, i can turn the brightness up and down, but change of color temperature only works from within phoscon, not from the remote. brightness from the remote do work and on/off

[jonasgustavsson (Jonas)]

Hi,
After an upgrade of HA and HA OS I got complete radio silence for my Conbee II. Any ideas?

Conbee II + deconz in docker on raspberry 4 - cannot detect zigbee devices

I have just installed a CombeeII stick on my raspberry 4 and installed Deconz in a docker. From the web GUI I can see usb stick as it detects the firmware version, but when I try to scan for zigbee devices (I have tried with Aqara sensors and Ikea sensors) I am not able to find anything, there are no errors in the deconz logs…please help

[Mariusthvdb (Marius)]

sorry to bump this question, but I am out of my options … I have only 1 (the Daylight CLIP) sensor in my new Deconz setup, after having had a Tradfri option sensor for half a day. I took that out, and after restart, the integration still showed 4 devices:

The Daylight sensor and the Deconz Phoscon-Gw, which are supposed to be there I guess.

It did however also show the Tradfri motion sensor. Since no Delete button was available, I had to edit the .storage core.device_registry file, and delete it from there. Which, after 3! attempts finally worked.

There’s still this odd unnamed/unknown device, registered to the same Deconz config_entry, which keeps returning. I can even see it being restored in real time after deleting the entry in the core.device_registry file.

Do we have any clue what this might be, and how to get rid of it?

            {
                "config_entries": [
                    "a0redactedcfa"
                ],
                "connections": [
                    [
                        "mac",
                        "02:42:ac:1e:21:06"
                    ]
                ],
                "identifiers": [],
                "manufacturer": null,
                "model": null,
                "name": null,
                "sw_version": null,
                "entry_type": null,
                "id": "fec62ac3595cb23a78ff29f941ea2607",
                "via_device_id": null,
                "area_id": null,
                "name_by_user": null,
                "disabled_by": null
            }

thanks for any help you can lend me.

Btw, why does the CLip Daylight sensor show

                "manufacturer": "Philips",
                "model": "PHDL00",
                "name": "Daylight",
                "sw_version": "1.0",

while I havent even enabled my Hue Hubs on this instance? Is that available without even doing so? Which would seem an unwanted Hue leakage to the Zigbee network to be honest. It doesnt even show up on my Production system with 2 Hue registered hubs …

[sjee]

@Mariusthvdb

Btw, why does the CLip Daylight sensor show while I havent even enabled my Hue Hubs on this instance? Is that available without even doing so?

It’s a sensor built into deCONZ as explained in the docs (allmost at the end of the page)

[Robban]

You can use the service remove orphaned devices to clean up stuff

[B4kken (Andreas Bakken)]

This is probably a dumb question but I haven’t been able to find an answer myself (noob as I am).
Love the integration btw!

When a new update to Home Assistant is released there seems to be a 50/50% chans that Deconz changes the signal channel, giving me logs saying something like “channel is 22 should be 11”. After having tried to revert the Channel manually I still have to add my lights and sensors again. Could there be something in my setup that is wrong?
I’m holding off on the january update since I just added my hallway lights (IKEA) again.

[Mariusthvdb (Marius)]

@sjee

It’s a sensor built into deCONZ as explained in the docs (allmost at the end of the page)

A yes, I. use admit I went al the way down there before, I think deCONZ - Home Assistant

Still, it doesn’t explain why it is called a Philips sensor PHDL sensor. IN fact, I would feel this needed to be changed, because it simply isn’t a Philips Hue Daylight Sensor…

Is this done in the implementation of the Home Assistant integration, or in the Deconz library. Maybe I can ask the dev’s about that.

this is a true PHDL sensor:

and the Deconz is clearly copied from that, even its attributes are named like the PHDL.

‘door Philips’ …

Btw, its workings are rather useless, since it was Golden Hour until midnight, and the same for the morning golden hour. Same goes for the midnight state itself, but I think that has been touched somewhere else already.

seems to be defined here: Sensors - deCONZ REST-API

and calculated according to deconz/pydeconz/sensor.py at c89a33b0f72216567209a8cab1e0ebd65111d1d6 · Kane610/deconz · GitHub

so, all based on offset minutes, which is surprising to me because I had understood it to be calculated based on the elevation of the sun as explained here GitHub - mourner/suncalc: A tiny JavaScript library for calculating sun/moon positions and phases.

[Mariusthvdb (Marius)]

@Robban

you can use the service remove orphaned devices to clean up stuff

Yes, thanks, I did that (should have mentioned it, sorry), but it doesnt take out the unknown sensor.

Is there a spot in a config file somewhere we can see which are these orphaned devices? Doesn’t seem to be in the .storage files, because everything I edit there simply gets restored…

[sjee]

@Mariusthvdb

Is this done in the implementation of the Home Assistant integration, or in the Deconz library. Maybe I can ask the dev’s about that.

As written… and you can also read this in the Phoscon documentation is it from the deCONZ software. It is not added by HA.

@Mariusthvdb

Still, it doesn’t explain why it is called a Philips sensor PHDL sensor. IN fact, I would feel this needed to be changed, because it simply isn’t a Philips Hue Daylight Sensor…

I guess you need to convince the people at Dresden Elektronik to make that change.

[Robban]

Do you mean upgrading the addon changes channel? Or ha core? Because core doesn’t care about what zigbee channel you use.

[Robban]

It calculates what devices are orphaned on the fly here https://github.com/home-assistant/core/blob/ab25c5a2bdb010fc9ae68bdc0eb5a96dc461e46d/homeassistant/components/deconz/services.py#L155

[Mariusthvdb (Marius)]

thanks!
must study that some more, but up to now, it doesnt take away this orphaned device:

Unless this is yet another device enabled by default in the Deconz, which I simply dont know of…

btw, Ive disabled the Clip sensors in the Deconz setting, but the daylight sensor is still there as you can see, and Verwijderen (delete) is greyed out:

[Robban]

You should try to find which device has that serial number, the daylight sensor isn’t a clip sensor (now a days it’s disabled by default though)

[Mariusthvdb (Marius)]

@Robban

You should try to find which device has that serial number

yeah, but where to look? the mac is only in this device_registry file. I take it,
with serial number you mean the Mac-address in

                "connections": [
                    [
                        "mac",
                        "02:42:ac:1e:21:06"
                    ]

? Of course I have tried to find any mentioning of this anywhere in my network/system, but there’s no clue whatsoever… I wonder if “mac” in fact is referencing the Mac_address? the Daylight sensor has “zigbee”, while the deconz itself has no connection (to itself? so that would seem logical…)

If mac is indeed the Mac_address, and it doesnt come from a Zigbee device, whence could it come from (trying to narrow down the search here)? Could it be a networked device? Its not mentioned in the routers database.

If nothing seems to help solve this mystery, can’t I unplug/plug the Conbee II maybe, to have it recreate its database somehow?

With only 1 sensor, I am really starting to dread the user friendliness/maturity of this little piece of hardware. I do like some heavy tinkering, but this goes beyond that. Talking about the User Acceptance Factor, it would be real low on the scale…

[Robban]

It could be the machine that hosts deconz Mac aswell

[Mariusthvdb (Marius)]

Ok thanks, yes, that would seem logical somehow. Otoh, I only know of a Lan Mac address of that Pi and that isnt the same. Could it be its usb address maybe? (believed USB not to have a Mac address only lan and wifi) and if so, how to identify that, because in Supervisor/Hardware, all I can see is:

one more thought: I did try to register a Hue bulb on the deconz, but it failed (as in never showed up any success after the 3 minutes wait)
Could it somehow be the remnants of an unregistered bulb I am seeing here?