I think that ip is normal. On my system i have the same ip as you but deconz is running just fine.
Looking at your log Deconz seems to run fine as well.
Anyway, you switched to z2mqtt but i think there was no need to.
im looking since 4 weeks for a solution. now its time to close this chapter.
after a small problem with my config works zigbee2mqtt now. i love it. all
my devices works fine and the gui is very nice. problem solved. 
Maybe a stupid question that was already answered but I can’t find anything related.
I purchsed the IKEA LED drivers 10W and 30W and connected several of these “Skydrag” lights:
https://www.ikea.com/de/de/p/skydrag-led-lichtleiste-arbpl-klschr-sensor-dimmbar-weiss-30439589/
I saw these lights support white color temperature change and I’m wondering if there will be any update on the LED drivers to support such a thing. At the moment, the only thing supported is on/off and the brightness. Do you know by chance if this will be included at some point?
1 Like
Since they’re powered by an external source that will only provide dimming and on/off control I think not
The description says it’s warm white only.
True! My bad. I somehow overlooked this little detail, since I purchased several other bulbs with white temperature color features, but the Skydrag ar only supporting on/off and dimming.
I had to start over with my setup because there was some entities from deCONZ that I was unable to delete, though removing them from Phoscon.
My question is, there are two unknown devices without any information available from scratch. I guess it is something that deCONZ is making upon installation? Any ideas of what it is?
Hi,
I have core-2021.5.4, supervisor-2021.04.3, Home Assistant OS 5.13 and deCONZ 6.8.0 installed and using a conbee 2 stick with firmware 266D0700. I am able to pair xiaomi door sensors. When I try to connect to Home Assistant I go to gatway-advanced-authenticate App, then do to Integrations - add integration in HomeAssistant and den I choose ‘manually define gateway’. As host I put http://homeassistant.local/ in and as port 80. But I only get ‘No API key could be retrieved.’ error. What I am doing wrong?
hello, I hope someone can help me.
since this morning the deCONZ addon crashes after about 1 minute.
I have already restarted the server (Debian on Intel NUC) and also deleted and reinstalled the ADDON, unfortunately without effect…
Attached are the logs, I can’t find anything noticeable:
09:19:57:958 SensorNode 23 set node 0x00158d0002726cb1
09:19:57:958 SensorNode 24 set node 0x00158d0002726cb1
09:19:57:959 SensorNode 25 set node 0x00158d0002726cb1
09:19:57:959 LightNode 7: OG_Buero added
09:19:57:959 LightNode 8: Dimmable light 8 added
09:19:57:960 SensorNode 28 set node 0x00158d0002726bd0
09:19:57:960 SensorNode 26 set node 0x00158d0002726bd0
09:19:57:960 SensorNode 27 set node 0x00158d0002726bd0
09:19:57:960 SensorNode 29 set node 0x5c0272fffec7242b
09:19:57:960 SensorNode 30 set node 0x5c0272fffec7242b
09:19:57:961 SensorNode 31 set node 0x00158d000272e518
09:19:57:961 SensorNode 32 set node 0x00158d000272e518
09:19:57:961 SensorNode 33 set node 0x00158d000272e518
09:19:57:961 SensorNode 37 set node 0x00158d0002cb4420
09:19:57:961 SensorNode 38 set node 0x00158d0002cb4420
09:19:57:968 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2190940-if00 / serialno: , ConBee II
09:19:58:980 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2190940-if00 / serialno: , ConBee II
QObject::connect: Cannot queue arguments of type 'QTextBlock'
(Make sure 'QTextBlock' is registered using qRegisterMetaType().)
09:19:58:001 COM check bootloader
QObject::connect: Cannot queue arguments of type 'QTextCursor'
(Make sure 'QTextCursor' is registered using qRegisterMetaType().)
09:19:59:012 COM detected application
09:19:59:030 Device firmware version 0x26660700 ConBee II
09:19:59:034 unlocked max nodes: 200
09:19:59:106 Device protocol version: 0x010C
09:19:59:154 Current channel 11
09:19:59:166 CTRL got nwk update id 1
09:19:59:170 CTRL ANT_CTRL 0x03
09:19:59:195 Device protocol version: 0x010C
09:19:59:249 Current channel 11
09:19:59:261 CTRL got nwk update id 1
09:19:59:265 CTRL ANT_CTRL 0x03
09:19:59:306 [INFO] - No button map for: SML001, unicast to: 0x0000, endpoint: 0x02, cluster: 0x0406, command: 0x0A, payload: 00001800, zclSeq: 87
09:19:59:307 ZCL attribute report 0x0017880106F7B85B for cluster: 0x0406, ep: 0x02, frame control: 0x08, mfcode: 0x0000
09:19:59:310 [INFO] - No button map for: SML001, unknown, endpoint: 0x02, cluster: 0x0406, command: 0x0A, payload: 00001800, zclSeq: 88
09:19:59:311 ZCL attribute report 0x0017880106F7B85B for cluster: 0x0406, ep: 0x02, frame control: 0x18, mfcode: 0x0000
09:19:59:313 rule event /sensors/7/state/lastupdated: 0 -> 0
09:19:59:314 [INFO] - No button map for: SP 120, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0B052900000805210000, zclSeq: 45
09:19:59:314 ZCL attribute report 0x00158D0003619ABA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
09:19:59:317 rule event /sensors/7/state/lastupdated: 0 -> 0
[09:20:07] INFO: Successfully send discovery information to Home Assistant.
[09:20:20] INFO: Starting VNC server (local/yes)...
2021/05/17 09:20:20 [notice] 321#321: signal 15 (SIGTERM) received from 315, exiting
2021/05/17 09:20:20 [notice] 1041#1041: exiting
2021/05/17 09:20:20 [notice] 1041#1041: exit
In exit
Closing socket listening at 127.0.0.1:5901
2021/05/17 09:20:20 [notice] 321#321: signal 17 (SIGCHLD) received from 1041
2021/05/17 09:20:20 [notice] 321#321: worker process 1041 exited with code 0
2021/05/17 09:20:20 [notice] 321#321: exit
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.
EDIT:
After restarting the host 3 or 4 times the Add-on ist running now for 5 minutes… I will watch it…
Hi
did you try it using the IP address?
What is difference between light.tun_on/off and light.toggle?
Answer to this question might seems obvious, so let me put it into specific context. I have ~50 Ikea bulbs (different models) and these are managed via deconz/phoscon using Conbee II stick. Works quite well… but only quite. Sometimes bulbs do not turn on or turn off (especially few in one group), which drives me nuts. For example motion sensor on the stairways turn them on using light.turn_on (usually all), but when timer goes off, all but one or two go off - using light.turn_off. I need to wake the sensor again, sometimes few times, before all will be turned off succesfully. Or I can go to HA dashbord and make it manually. Tricky part is that both HA and phoscon integration show that all lights are off, so looks like bulb is not reporting its state properly back to deconz, or deconz is taking some false assumtions about its state without checking actual outcome of command.
Now, going back to my original question; I’ve never, ever noticed this sort of behavior when using light.toggle command. It seems to be 100% reliable. So what is difference between switching the light on or off versus toggle, from deconz perspective?
Or just because I use toggle less frequently, I just missed that it can also fail?
Hi @mirekmal
As far as I know, using the light.turn_on or light.turn_off, HA sends that specific command to your light, putting the light in that state.
Every time light.toggle is used, HA just switches between these states.
In your use case, it could be that for HA the light is in the off state so the off command isn’t sent while the bulb is actually on. This could be caused by miscommunication between HA and the bulb.
While when using toggle, no matter what state is known, it just switches from on to off or from off to on.
Am I making a bit sense? 
By the way, I have a couple of ikea bulbs an a lot of Philips hue ones. The only problems I have is with the ikea ones. Although I must say it’s only with the old gu10 ikea bulbs, the others I have no problem with.
Hope this helps,
Br,
Raymond
It is not HA issue, but rather somethiing between phoscon/conbee/bulb. HA is always properly reflecting bulb status as shown in phoscon.
So then the question is if toggle command is send to bulb and bulb handles it properly based on its real state or this is handled on HA level (e.g. HA checks what is the status of bulb and the sends appropriate on or off command to the bulb). Or this is deconz that handles this logic… The first scenario would explain issues that I see in my system, while the second and third… should not work so reliably 
Important point you made, indeed I see this issue with GU10 bulbs only. E14 and E27 bulbs causes no problem (there were some with E14, but either deconz or firmware updates fixed this some time ago).
It sounds like your problem is related to turning groups of lights on and off simultaneously
Zigbee is a slow protocol and in a mesh there will be a lot of relaying of messages.
When you use groups of lights defined in Home Assistant, HA cannot know which lights are in the same technolody. Your group could be 4 Zigbee lights, 1 Wifi light, and 2 RF plugs. And it cannot know which items may exist as groups defined outside HA. So HA will turn each light on or off one at a time very fast. This creates a load on the Zigbee network and it seems that some bulbs cannot handle the traffic.
The solution is to define light groups in the Zigbee network itself. In Deconz you define a light group in the Phoscon web app. When you do that the group gets imported into HA as a single light entity in addition to the existing individual lights.
In your automations you simply use this zigbee group to turn lights on and off. HA will now send one message to Deconz. In the Zigbee network the turn on messages are now sent to this group. It gives much less traffic on the Zigbee network and you will find that the lights are more likely to turn on and off in sync. It can still go wrong by the probability will be much lower.
4 Likes
Thanks for the info… This explains a lot of issues I have seen with IKEA bulbs and Window covers.
@KennethLavrsen, this is actually what i did. I’m already using deconz light group defined in Phoscon 
Another update… I was wrong with light.toggle working reliably… During weekend I rewrote my automations to use this command and tested it for some time. Unfortunately it turned out to be as unreliable as ordinary turn on/off.
Morning!
I have a question for you guys 
My setting is a pi3 with the Conbee II plugged in one of the USBs, and the ZigBee integration works flawlessly.
Now, I’m trying to ‘upgrade’ to a QNAP, and I’m using the containers in the Container Station app, so I created a container for HA and another one for the Conbee II using marthoc image. I can open the phoscon web and see the firmware of the USB stick. When adding the integration in HA, Zigbee Home Automation is asking me for the radio type (deCONZ) and the serial device path, but that last part is not going through, and I have no idea what to do there. I have followed some webs on the internet but no luck. Also, the Phoscon web is not recognising my plugs when in discovering mode.
Is there anything I’m missing?
Thank you in advance!
You don’t need to use the zigbee home automation integration, you need the deconz one if you are using the marthoc container, ZHA is a different implementation