ebaauw commented 5 years ago

I've been running v2.05.37 and 0x26220500 for over a day now. Yesterday evening, two of my Hue motion sensors were blinking red on detecting motion, but they seem to have recovered automagically. As of this afternoon, deCONZ no longer receives reports from another Hue motion sensor. Tried removing/re-inserting the batteries, as well as a brief press on the reset button, but no joy. I had to reset and re-pair the motion sensor, to solve the situation.

olemr commented 5 years ago

I'm on 2.05.35 and the same thing happened to me with a HUE dimmer that I bought this Saturday. Was working fine then. Now it is blinking red when pressing a button. Last lastupdated was yesterday. Have tried pressing all 4 buttons, but no joy. My 3 mi & Aqara cubes are rock stable. Have not missed a single gesture, ever. 4 Ikea remotes are also OK.

manup commented 5 years ago

The Philips end-devices require that the gateway sends a ZCL default response back and will otherwise indicate error and rejoin after a while which makes it a bit tricky since the device is a moving target with changing parents.

I guess since the packets from the devices are received and that the gateway also sends the response but might not use the correct route back, or a link in between is broken.

I'll need to do more tests on firmware level with sniffer to see what's happening.

ebaauw commented 5 years ago

What I understood from the Hue developers forum, the Hue motion sensor actually re-sends the report attributes command as a broadcast when it doesn’t receive a response to the unicast report attributes. Maybe the Hue bridge uses that to derive the new route?

I’ve never actually sniffed this, nor examined the deCONZ log in detail, but it seems consistent with my experience that sometimes the sensor blinks red, but a couple of seconds after that, the lights turn on anyways.

manup commented 5 years ago

What I understood from the Hue developers forum, the Hue motion sensor actually re-sends the report attributes command as a broadcast when it doesn’t receive a response to the unicast report attributes. Maybe the Hue bridge uses that to derive the new route?

Maybe, further the sensor will also send a device announce after rejoin.

However deriving the correct route based on incoming frames is challenging, the real problem is that the gateway needs to determine the real parent node of the end-device which might not be the last hop from which it received the incoming command.

Krocko commented 5 years ago

With 2.05.37 i have the same Problem with one of my Hue motion sensors. The Problem occurs daily.

nero01 commented 5 years ago

Hello, i have the exact same issue. I tested two different firmwares with my RaspBee module (0x261f0500 0x26210500). The motion sensor shows up in the deconz-gui and is connected to one IKEA E27 bulb and one Philips Hue E27 bulb. The line to the IKEA bulb is yellow and the line to the hue bulb is green. The sensor blinks red when i am in front of it, but the presence and updated times are not updated.

This issue is really annoying, i already moved all my hue dimmer switches to the HUE bridge instead, because deconz always lost the connection to them.

Deconz version: 2.05.35 / 17.8.2018 RaspBee firmwares tested: (0x261f0500 0x26210500)

nero01 commented 5 years ago

Which RaspBee firmware and deconz versions are proofed to be working stable for long time with hue motion sensors?

manup commented 5 years ago

First results of testing with 0x26220500:

One bug found so far, but not sure if related: 22 doesn't respond to ZDP extended and nwk address request (will be fixed in .23 release).

First test setup

Motion sensor parent is a Hue Lux E27, connection is stable and works
reports are sent and zcl default response is returned

1) turn off Hue Lux 2) Sensor searches new parent via beacon request 3) Sensor selects a FLS-PP lp and rejoins 4) FLS-PP lp sends a APS Update Device command (status 0x00, secured join) to ConBee

First gotcha, ConBee doesn't update it's routing table and still tries to reach the sensor via prior parent Hue Lux. (I'll fix this in the .23 release)

however, good thing, after a few attempts ConBee does search a new route
FLS-PP lp responds with route reply that it knows the sensor (and in fact is the parent in this case)
ConBee can now normally reach the sensor
all works again

conclusion It takes a while, ca. 2 minutes, but the sensor comes back to normal operation state when two parents other than ConBee are involved.

The same test case must now be applied with

a) two Hue bulbs, so next parent is a Hue again b) Hue and IKEA, so next parent is a IKEA

After that I'll test what happens when sensor selects ConBee as next parent (something tells me there might be problems).

nero01 commented 5 years ago

Thank you very much for doing the tests, i think a lot of people are using deconz together with hue sensors. As i wrote in my earlier post, the motion sensor is connected to one E27 Hue bulb and one E27 IKEA bulb and does not connect to a parent anymore, even after 10 minutes. The sensor stopped working around 4 hours ago, but still lights up red but no report any stats.

olemr commented 5 years ago

Nice going. Hope this will help the Ikea Bulb issue as well. Please: fill me in on the difference between what you refer to as the upcoming .23 release and the 2.05.37 Ubuntu package (which I am using). Will the .23 release trigger a .38 Ubuntu package?

manup commented 5 years ago

Oh sorry .23 is related to firmware :) 0x26230500, will be part of deCONZ 2.05.38 all platforms.

ebaauw commented 5 years ago

First gotcha, ConBee doesn't update it's routing table and still tries to reach the sensor via prior parent Hue Lux. (I'll fix this in the .23 release)

Cool, that definitely sounds like a problem.

however, good thing, after a few attempts ConBee does search a new route It takes a while, ca. 2 minutes

A few attempts of what, or rather by whom? Attempts by deCONZ to send a default response to the Hue motion sensor? Attempts by deCONZ to poll the sensor after it missed too many reports? Is the "ca. 2 minutes" dependent on the network size?

ConBee can now normally reach the sensor

That's cool, but the issue I'm facing is that the sensor no longer seems to reach the ConBee/RaspBee. It would almost seem that the sensor decides to leave the network after missing too many default responses (cf. the lumi.ctrl_neutral not receiving the report attributes response). This might actually be solved by updating the ConBee/RaspBee routing table.

Is there a sure way to find the parent of an end device, other than sniffing? I find the lines in the deCONZ GUI extremely unreliable for that.

manup commented 5 years ago

A few attempts of what, or rather by whom? Attempts by deCONZ to send a default response to the Hue motion sensor? Attempts by deCONZ to poll the sensor after it missed too many reports? Is the "ca. 2 minutes" dependent on the network size?

ConBee did active endpoints request and ZCL default responses after receiving the device annce, I think it was three different commands until it decided to search a new route.

It would almost seem that the sensor decides to leave the network after missing too many default responses

Digging deeper in the ConBee ZigBee stack code (BitCloud) I might found a serious bug: when a device announce is received and ConBee was the the former parent of the end device — meaning the ED is in the neighbor table marked as child — it will send a Leave command to it and more bummer with rejoin flag disabled.

I need to test it tomorrow, but if it's true it would explain why the sensor will be totally lost.

Is there a sure way to find the parent of an end device, other than sniffing? I find the lines in the deCONZ GUI extremely unreliable for that.

The most reliable way is the reception of the APS Update Device command from the new parent. I think with some small tweaks this can be used to improve initial routing and parent detection a lot.

Query neighbour tables via Mgmt_Lqi_req also brings the information but multiple routers might claim that they are the parent for some time.

manup commented 5 years ago

Digging deeper in the ConBee ZigBee stack code (BitCloud) I might found a serious bug: when a device announce is received and ConBee was the the former parent of the end device — meaning the ED is in the neighbor table marked as child — it will send a Leave command to it and more bummer with rejoin flag disabled.

I think I got it wrong seems to be just a indication to higher layer nothing that is send to the network.

olemr commented 5 years ago

Oh sorry .23 is related to firmware :) 0x26230500, will be part of deCONZ 2.05.38 all platforms.

Is the firmware for the Conbee as well? Is it an automatic update? My current version seems to not find the FW version:

manup commented 5 years ago

More findings, Testing with a Philips Hue dimming switch and development firmware 0x26230500

fixed sending NWK and extended address responses

Philips Hue dimming switch

Date code: 20150408
SW Build ID: 5.45.0.15075

(so maybe bugs are fixed in newer firmware)

pressing the dimm down button quickly 3–4 times triggers a rejoin of the switch. This won't happen always but when it happens it can be reproduced nearly every time.
sometimes in larger intervals the rejoin happens event when the network is stable otherwise

the switch power configuration cluster reports don't ask for APS nor ZCL default response
on/off and level cluster group commands ask for ZCL default response commands (which they shouldn't)
Maybe since we are using the 0xfc00, on/off and level control cluster bindings, this is too much for the device and triggers some errors. I'll need to retest with either just using 0xfc00 or on/off + level control bindings.
When the config.group is empty I figure we don't need on/off + level control bindings at all.

We also need to tune the binding creation, for example every time a battery report is received and the switch wasn't used in a (short) while the 0xfc00 binding creation will be started. After that the switch does poll the gateway many times which surely isn't very battery friendly.

manup commented 5 years ago

To compare differences I've paired the Hue dimmer switch to the Hue bridge.

Same behavior and faults here, ack and zcl default response handling is the same, power descriptor reports won't be answered with zcl default response (seems ok it wasn't requested in the header).

The switch does rejoin the network sometimes when pressing the buttons quickly (only 0xfc00 cluster is bound). So either my switch is in a bad state or there are really issues in the firmware version.

The hue bridge didn't offer a update for the switch yet. Can anybody confirm following Hue dimmer switch firmware is the latest?

Date code: 20150408 SW Build ID: 5.45.0.15075

nero01 commented 5 years ago

Thank you for providing your detailed feedback. My hue dimmer switches 3x RWL021 have the latest firmware version "5.45.1.17846" installed.

olemr commented 5 years ago

I too have 5.45.1.17846 purchased on Saturday. Has never been paired to anything but Conbee/deconz. Tried pressing keys rapidly, and it was online again!

ebaauw commented 5 years ago

Can anybody confirm following Hue dimmer switch firmware is the latest? Date code: 20150408 SW Build ID: 5.45.0.15075

There seem to be different (hardware?) versions of the RWL021 with different latest firmware versions. I have five on 5.45.1.17846 / 20160302, and two on 5.45.1.16265 / 20150918. The five are Non color scene controllers on ZLL endpoint 0x01, the other two are Non color controllers, lacking the Scenes client cluster.
I'm using 0xfc00 and OnOff/Level reports simultaneously (the latter as a backup to control my lights in case deCONZ is down). I've had an occasional network loss of a Hue dimmer switch, but way less often than the Hue motion sensor, and not anytime recent. Also, pressing/holding all four buttons simultaneously most times makes the switch responsive again.

the switch power configuration cluster reports don't ask for APS nor ZCL default response

That's interesting, as this is the only periodic reporting. Otherwise, the switch sends commands only when a button is pressed, held, or released.

on/off and level cluster group commands ask for ZCL default response commands (which they shouldn't)

From the ZCL spec (section 2.5.12.2):

The Default Response command SHALL be generated when all 4 of these criteria are met:

A device receives a unicast command that is not a Default Response command.

No other command is sent in response to the received command, using the same Transaction sequence number as the received command.

The Disable Default Response bit of its Frame control field is set to 0 (see 2.4.1.1.4) or when an error results.

The “Effect on Receipt” clause for the received command does not override the behavior of when a Default Response command is sent. If a device receives a command in error through a broadcast or multicast transmission, the command SHALL be discarded and the Default Response command SHALL not be generated.

They way I read this, setting the No Default Response bit seems redundant/optional for broadcast and multicast transmissions.

Maybe since we are using the 0xfc00, on/off and level control cluster bindings, this is too much for the device and triggers some errors.

Not in my experience.

When the config.group is empty I figure we don't need on/off + level control bindings at all.

Agreed.

manup commented 5 years ago

Maybe since we are using the 0xfc00, on/off and level control cluster bindings, this is too much for the device and triggers some errors.

Not in my experience.

The test with Hue bridge showed that just using 0xfc00 didn't improve situation. So my assumption of using all 4 bindings vs 2 might not make a difference.

My dimmer switch at home which works flawlessly is on RWL021 5.45.0.15075 / 20150408. I'll do some sniffing with that one to compare if the same issues are present.

The switch at work had some total lockups today due heavy testing where only battery pull-out-in helped, didn't test pressing all 4 buttons at the same time though.

manup commented 5 years ago

The tests with the newer Hue dimmer switch firmware RWL021 ( 5.45.1.16265) showed no problems or reconnects, so I guess the issues where fixed after 5.45.0.15075.

New RaspBee/ConBee firmware 0x26230500 fixes:

missing nwk and ieee address request handling
fast route detection when device rejoins (after receiving APS Update Device command) this should fix a lot of the end-device problems.

I've testet end-device handover via rejoin between IKEA, Philips and ConBee and it worked very well without any dead commands inbetween (using old routes which result in many retries until new route will be discovered).

https://www.dresden-elektronik.de/rpi/deconz-firmware/deCONZ_Rpi_0x26230500.bin.GCF

The firmware will also be included in 2.05.38 arriving later today.

ebaauw commented 5 years ago

Thanks for looking into this, @manup !

Did you manage to update the firmware of the old dimmer, or did you use a different, newer dimmer?

manup commented 5 years ago

Did you manage to update the firmware of the old dimmer, or did you use a different, newer dimmer?

I've tried with Hue bridge V1 and V2 but neither of them offered an update — testing with two dimmers.

Currently we're overhauling the documentation including device specific pages, I think it makes sense to document known issues for certain firmware versions.

olemr commented 5 years ago

Currently we're overhauling the documentation including device specific pages, I think it makes sense to document known issues for certain firmware versions.

Good thinking!

About Conbee FW. Did you see this?

manup commented 5 years ago

Good thinking!

About Conbee FW. Did you see this?

Yes, the Phoscon App should offer an firmeware update, however 0x00000000 looks like either no connection is established or the firmware version is determined yet. Note 1: If you're running deCONZ inside a Docker container (?) extra steps must be taken to update the firmware, as described in the deCONZ Docker repo.

Note 2: The Phoscon App currently has sometimes issues showing the most recent data from the API which we will improve very soon.

olemr commented 5 years ago

however 0x00000000 looks like either no connection is established or the firmware version is determined yet.

It is like that all the time on a working system.

I'm running Ubuntu Server on a x64 platform.

Will start with just dpkg the .38 version.

olemr commented 5 years ago

Test started. Will know in a couple of days if all my 32 Ikea lights stay online. Will monitor HUE-1 as well. The date of .38 seems a bit off:

nero01 commented 5 years ago

Thanks a lot i am also running latest: Version 2.05.38 / 1.9.2018 Firmware 26230500

Interesting to see if my hue motion sensors stay alive :)

olemr commented 5 years ago

I'm still unsure if my Conbee Firmware has been updated. Any other way to check on a headless, native Ubuntu system?

ebaauw commented 5 years ago

It’s reported through the REST API: ph get /config/fwversion.

Under 2.05.38, I was able to update th firmware to 0x26230500 using the old web app. It continued so show the Update firmware button until I restarted deCONZ, though. I’m not sure if this is due to the REST API or the web app itself.

olemr commented 5 years ago

Guess this explain why pwa reports firmware 0x00000000

  "devicename": "ConBee",
  "dhcp": true,
  "factorynew": false,
  "fwversion": "0x00000000",
  "gateway": "192.168.1.1",
  "internetservices": {
    "remoteaccess": "disconnected"
  },
  "ipaddress": "192.168.1.7",

ebaauw commented 5 years ago

It does. In that case, you would need to start deCONZ with debug logging enabled and scan the log.

vandalon commented 5 years ago

I'm seeing the same issue with 2 hue dimmers and 1 motion sensor. Pairing works fine , after a few minutes the hue dimmers don't react at all anymore. The motion dimmers blinks red now and then but seems to rejoin again. Running firmware 26220500

olemr commented 5 years ago

@ebaauw could you please point me to a 'how-to'?

ebaauw commented 5 years ago

Start deCONZ with --dbg-info=2. Typically you need to change the service definition file for this. I wouldn't know how that's done on Ubuntu. You could just stop the service and start deCONZ from the command line.

Then scan the output for a line:

Sep  7 12:14:56 pi2 deCONZ[6958]: 12:14:55:820 GW firmware version: 0x26230500

Again, I don't know the setup on Ubuntu; on Raspbian the service logs to syslog. If you start deCONZ from the command line, it's simply the standard output.

vandalon commented 5 years ago

2 out of 3 hue dimmers are detected but don't show a version number. Those are the 2 that don't work (blink red)

vandalon commented 5 years ago

Just confirmed that the switches and sensor all work perfectly fine (after re-adding) with firmware 261E0500.

ebaauw commented 5 years ago

Running v2.05.38 with firmware 0x26230500. So far, so good.

vandalon commented 5 years ago

Is there a 0x26230500? I only see 0x26220500

olemr commented 5 years ago

Thank you @ebaauw . Your instructions were spot on: for others coming here running headless on native Ubuntu:

sudo nano /lib/systemd/system/deconz.service: ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8090 --dbg-info=2 sudo systemctl daemon-reload sudo systemctl restart deconz

Log now available here: less -i /var/log/syslog

Mine showed:

Sep  7 21:44:32 shs2 deCONZ[9242]: 21:44:32:554 GW firmware update not supported on x86 linux headless
Sep  7 21:44:32 shs2 deCONZ[9242]: 21:44:32:916 Device firmware version 0x26210500

So, my Conbee has not been updated so I will try this I found in another post:

# deCONZ must be closed first
$ sudo systemctl stop deconz

# update firmware
$ sudo GCFFlasher_internal -d 0 -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26230500.bin.GCF

Will report back... Success:

sudo GCFFlasher_internal -d 0 -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26
deCONZ_Rpi_0x261f0500.bin.GCF  deCONZ_Rpi_0x26230500.bin.GCF
omr@shs2:~$ sudo GCFFlasher_internal -d 0 -f /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26230500.bin.GCF
GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10
using firmware file: /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26230500.bin.GCF
reset via FTDI

flashing 122894 bytes: |===============================|
verify: ....
SUCCESS

Log: Sep 7 22:42:02 shs2 deCONZ[29210]: 22:42:02:777 Device firmware version 0x26230500

vandalon commented 5 years ago

I Found 0x26230500, and tested. all existing devices work perfectly. But when I add a new philips hue dimmer this one does not work. It is recognised and added correctly but after that it does not work and the light on the remote blinks red when pressing a button instead of green.

vandalon commented 5 years ago

Have been testing some more, also with older firmware, issue stayed the same with 261E0500, but then after deleting and re-adding some times it suddenly worked. Upgraded to 0x26230500 again, still worked, removed and re-added, still works. So not sure what that was about :)

l-mb commented 5 years ago

I'm having a similar issue (I think?). I have a Philips Hue Motion sensor and had to reinstall my gateway. (I moved from running deconz on top of hass.io to running it on a dedicated Raspberry with the published image (which seems to be stuck in May?)).

I was able to re-pair everything; my Hue bulbs and my Osram plugs.

When I try to re-pair the motion sensor though (via the setup button) it flashes a few times and the sensor LED seems to indicate it has joined a ZigBee network. But it doesn't show up in the deconz UX again and that reports that no sensor was found.

Is this a similar issue?

ebaauw commented 5 years ago

Running v2.05.38 with firmware 0x26230500. So far, so good.

Haven't lost a single device for a week. It looks like 0x26230500 does the trick - thanks @manup! Closing this issue.

Is this a similar issue?

Doesn't look like it. Be sure to reset the Hue motion sensor by pushing the reset button (hole) for 10 seconds. Search for new devices from the Phoscon app, or open the network from the old web app. The sensor should appear in the deCONZ GUI. If not, power off all lights (and other ZigBee routers) to force the sensor to pair with the RaspBee/ConBee.

If the resources aren't created, read the attributes from the Basic cluster in the deCONZ GUI, while the network is still open (from Phoscon or the web app).

mansdahlstrom1 commented 5 years ago

Hi!

Im having problems with firmware 0x26230500. In the Phoscon App i get this following information Version 2.05.38 / 01/09/2018 Firmware 00000000

But if i check the logs with cat /var/log/syslog | grep "Device firmware version" i get this. ubuntu deCONZ[19175]: 12:20:19:501 Device firmware version 0x26230500

IS this just a frontend bugg i Phoscan App? Or is this indicating that something is broken in my system?

Im running headless ubuntu server and my setup has been running super smoothly until there was a power outage in the building. When i got booted up again no lights where found anymore, and this resulted in doing firmware updates and updating deconz to the latest version. Now it seems like nothing is working anymore. Any ideas for what problem i'm running into here?

olemr commented 5 years ago

metoo, see my post from 9d ago.

olemr commented 5 years ago

Im running headless ubuntu server and my setup has been running super smoothly until there was a power outage in the building. When i got booted up again no lights where found anymore, and this resulted in doing firmware updates and updating deconz to the latest version. Now it seems like nothing is working anymore. Any ideas for what problem i'm running into here?

I experienced this once. 16 of my lights had no power when deconz restarted. No other lights showed up. As soon as I powered on the 16 lights all of the rest appeared also. Are you sure none of your fuses are OFF after the outage?

It is also a good idea to do a backup from pwa from time-to-time for situations like this..

mansdahlstrom1 commented 5 years ago

@olemr All my lights work by using the manual switch but they can't be found by deconz anymore, I've have mostly IKEA Trådfri and i've even reset them by switching the light on and off 6 times. But somehow it seems like i cannot find them...

Is there an easy way to see if the conbee is actually sending and receiving signals?
How do i test it in that case?

I've set degbug level to 2 in my ExecStart override and im getting spammed in the syslog. Attaching the output of syslog maybe someone can see something abnormal here?

EDIT: Can the ZigBee Channel be the problem maybe?

Output from tail -f /var/log/syslog

Sep 16 16:32:34 ubuntu deCONZ[19175]: 16:32:34:500 DB saved in 15 ms
Sep 16 16:32:34 ubuntu deCONZ[19175]: 16:32:34:500 don't close database yet, keep open for 900 seconds
Sep 16 16:32:36 ubuntu deCONZ[19175]: 16:32:36:481 APS-DATA.request id: 82, addrmode: 0x03, addr: 0x00212effff022e39, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
Sep 16 16:32:36 ubuntu deCONZ[19175]: 16:32:36:539 APS-DATA.confirm id: 82, status: 0x00 SUCCESS
Sep 16 16:32:36 ubuntu deCONZ[19175]: 16:32:36:540 APS-DATA.confirm request id: 82 -> confirmed, timeout 59920
Sep 16 16:32:36 ubuntu deCONZ[19175]: 16:32:36:563 APS-DATA.indication srcAddr: 0x00212effff022e39, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 0, rssi: -31
Sep 16 16:32:36 ubuntu deCONZ[19175]: 16:32:36:564 APS-DATA.indication request id: 82 -> finished
Sep 16 16:32:36 ubuntu deCONZ[19175]: 16:32:36:564 APS-DATA.request id: 82 erase from queue
Sep 16 16:32:36 ubuntu deCONZ[19175]: 16:32:36:564 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
Sep 16 16:32:38 ubuntu deCONZ[19175]: 16:32:38:881 APS-DATA.request id: 84, addrmode: 0x03, addr: 0x00212effff022e39, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
Sep 16 16:32:38 ubuntu deCONZ[19175]: 16:32:38:933 APS-DATA.confirm id: 84, status: 0x00 SUCCESS
Sep 16 16:32:38 ubuntu deCONZ[19175]: 16:32:38:933 APS-DATA.confirm request id: 84 -> confirmed, timeout 59920
Sep 16 16:32:38 ubuntu deCONZ[19175]: 16:32:38:957 APS-DATA.indication srcAddr: 0x00212effff022e39, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 0, rssi: -31
Sep 16 16:32:38 ubuntu deCONZ[19175]: 16:32:38:957 APS-DATA.indication request id: 84 -> finished
Sep 16 16:32:38 ubuntu deCONZ[19175]: 16:32:38:957 APS-DATA.request id: 84 erase from queue
Sep 16 16:32:38 ubuntu deCONZ[19175]: 16:32:38:957 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
Sep 16 16:32:39 ubuntu deCONZ[19175]: 16:32:39:485 Daylight now: solarNoon, status: 170, daylight: 1, dark: 0
Sep 16 16:32:41 ubuntu deCONZ[19175]: 16:32:41:281 APS-DATA.request id: 86, addrmode: 0x03, addr: 0x00212effff022e39, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
Sep 16 16:32:41 ubuntu deCONZ[19175]: 16:32:41:334 APS-DATA.confirm id: 86, status: 0x00 SUCCESS
Sep 16 16:32:41 ubuntu deCONZ[19175]: 16:32:41:334 APS-DATA.confirm request id: 86 -> confirmed, timeout 59920
Sep 16 16:32:41 ubuntu deCONZ[19175]: 16:32:41:358 APS-DATA.indication srcAddr: 0x00212effff022e39, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 0, rssi: -31
Sep 16 16:32:41 ubuntu deCONZ[19175]: 16:32:41:358 APS-DATA.indication request id: 86 -> finished
Sep 16 16:32:41 ubuntu deCONZ[19175]: 16:32:41:358 APS-DATA.request id: 86 erase from queue
Sep 16 16:32:41 ubuntu deCONZ[19175]: 16:32:41:358 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
Sep 16 16:32:41 ubuntu deCONZ-WIFI.sh[24204]: Device "wlan0" does not exist.
Sep 16 16:32:43 ubuntu deCONZ[19175]: 16:32:43:485 Idle timer triggered
Sep 16 16:32:43 ubuntu deCONZ[19175]: 16:32:43:681 APS-DATA.request id: 88, addrmode: 0x03, addr: 0x00212effff022e39, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
Sep 16 16:32:43 ubuntu deCONZ[19175]: 16:32:43:735 APS-DATA.confirm id: 88, status: 0x00 SUCCESS
Sep 16 16:32:43 ubuntu deCONZ[19175]: 16:32:43:735 APS-DATA.confirm request id: 88 -> confirmed, timeout 59920
Sep 16 16:32:43 ubuntu deCONZ[19175]: 16:32:43:759 APS-DATA.indication srcAddr: 0x00212effff022e39, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 0, rssi: -31
Sep 16 16:32:43 ubuntu deCONZ[19175]: 16:32:43:759 APS-DATA.indication request id: 88 -> finished
Sep 16 16:32:43 ubuntu deCONZ[19175]: 16:32:43:759 APS-DATA.request id: 88 erase from queue
Sep 16 16:32:43 ubuntu deCONZ[19175]: 16:32:43:759 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
Sep 16 16:32:46 ubuntu deCONZ[19175]: 16:32:46:081 APS-DATA.request id: 90, addrmode: 0x03, addr: 0x00212effff022e39, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
Sep 16 16:32:46 ubuntu deCONZ[19175]: 16:32:46:136 APS-DATA.confirm id: 90, status: 0x00 SUCCESS
Sep 16 16:32:46 ubuntu deCONZ[19175]: 16:32:46:136 APS-DATA.confirm request id: 90 -> confirmed, timeout 59920
Sep 16 16:32:46 ubuntu deCONZ[19175]: 16:32:46:160 APS-DATA.indication srcAddr: 0x00212effff022e39, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 0, rssi: -31
Sep 16 16:32:46 ubuntu deCONZ[19175]: 16:32:46:160 APS-DATA.indication request id: 90 -> finished
Sep 16 16:32:46 ubuntu deCONZ[19175]: 16:32:46:160 APS-DATA.request id: 90 erase from queue
Sep 16 16:32:46 ubuntu deCONZ[19175]: 16:32:46:160 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
Sep 16 16:32:48 ubuntu deCONZ[19175]: 16:32:48:481 APS-DATA.request id: 92, addrmode: 0x03, addr: 0x00212effff022e39, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
Sep 16 16:32:48 ubuntu deCONZ[19175]: 16:32:48:537 APS-DATA.confirm id: 92, status: 0x00 SUCCESS
Sep 16 16:32:48 ubuntu deCONZ[19175]: 16:32:48:537 APS-DATA.confirm request id: 92 -> confirmed, timeout 59920
Sep 16 16:32:48 ubuntu deCONZ[19175]: 16:32:48:561 APS-DATA.indication srcAddr: 0x00212effff022e39, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 0, rssi: -31
Sep 16 16:32:48 ubuntu deCONZ[19175]: 16:32:48:561 APS-DATA.indication request id: 92 -> finished
Sep 16 16:32:48 ubuntu deCONZ[19175]: 16:32:48:561 APS-DATA.request id: 92 erase from queue
Sep 16 16:32:48 ubuntu deCONZ[19175]: 16:32:48:562 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
Sep 16 16:32:49 ubuntu deCONZ[19175]: 16:32:49:485 Daylight now: solarNoon, status: 170, daylight: 1, dark: 0
Sep 16 16:32:50 ubuntu deCONZ[19175]: 16:32:50:881 APS-DATA.request id: 94, addrmode: 0x03, addr: 0x00212effff022e39, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
Sep 16 16:32:50 ubuntu deCONZ[19175]: 16:32:50:939 APS-DATA.confirm id: 94, status: 0x00 SUCCESS
Sep 16 16:32:50 ubuntu deCONZ[19175]: 16:32:50:939 APS-DATA.confirm request id: 94 -> confirmed, timeout 59920
Sep 16 16:32:50 ubuntu deCONZ[19175]: 16:32:50:963 APS-DATA.indication srcAddr: 0x00212effff022e39, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 0, rssi: -31
Sep 16 16:32:50 ubuntu deCONZ[19175]: 16:32:50:963 APS-DATA.indication request id: 94 -> finished
Sep 16 16:32:50 ubuntu deCONZ[19175]: 16:32:50:963 APS-DATA.request id: 94 erase from queue
Sep 16 16:32:50 ubuntu deCONZ[19175]: 16:32:50:963 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
Sep 16 16:32:53 ubuntu kernel: [175903.633699] [UFW BLOCK] IN=enp0s31f6 OUT= MAC=1c:1b:0d:9c:29:23:38:d5:47:d9:3e:38:08:00 SRC=192.168.1.1 DST=192.168.1.36 LEN=367 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1900 DPT=58975 LEN=347
Sep 16 16:32:53 ubuntu deCONZ[19175]: 16:32:53:281 APS-DATA.request id: 96, addrmode: 0x03, addr: 0x00212effff022e39, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
Sep 16 16:32:53 ubuntu deCONZ[19175]: 16:32:53:332 APS-DATA.confirm id: 96, status: 0x00 SUCCESS
Sep 16 16:32:53 ubuntu deCONZ[19175]: 16:32:53:332 APS-DATA.confirm request id: 96 -> confirmed, timeout 59920
Sep 16 16:32:53 ubuntu deCONZ[19175]: 16:32:53:356 APS-DATA.indication srcAddr: 0x00212effff022e39, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 0, rssi: -31
Sep 16 16:32:53 ubuntu deCONZ[19175]: 16:32:53:356 APS-DATA.indication request id: 96 -> finished
Sep 16 16:32:53 ubuntu deCONZ[19175]: 16:32:53:356 APS-DATA.request id: 96 erase from queue
Sep 16 16:32:53 ubuntu deCONZ[19175]: 16:32:53:356 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000

mansdahlstrom1 commented 5 years ago

Stil no luck here, i've been doing some more debug thou.

[x] Tested all Zigbee Channels (no effect)
[x] Restart router / network

The only clue i found was this piece of info in the logs. GW firmware update not supported on x86 linux headless

Device firmware version 0x26230500`` Deconz version 2.05.38 / 01/09/2018`

dresden-elektronik / deconz-rest-plugin

0x26220500: Hue motion sensor lost #771

Philips Hue dimming switch

metoo, see my post from 9d ago.