Hue motion works shortly after being added and then stops

[commandcontrolit]

Hello running deCONZ 2.05 on Raspbian Stretch Lite with hass.io.

Before upgrading to hass.io 0.62, my Hue motion would not show up in hass.io at all. I was over on the community forums working with the dev and a veteran deCONZ user. Eventually they told me that only an upgrade to 0.62 would fix the issue.

Since upgrading, it shows up in hass.io and works, meaning it will trigger events, I can see the icon change, etc, but shortly after it just stops working.

When it stops working, it says "unavailable", but it's still showing what appears to be valid lux, temp and battery level - but I think it's from the last update.

In Phoscon, it demonstrates no issues - I can see the motion and it shows motion, temp, lux, etc.

In Node-Red I added a websocket, connect to deCONZ via ws://10.1.30.191:443 and I can see the light and switch events. No motion events of any type though.

As a side note, though the Hue switch is sending websocket events, it's not showing in hass.io.

Not sure where to go from here.

[wrmulf]

IMHO deconz is totally broken at the moment and I stopped using it at all. I never had any issues with the latest stable 2.04.35, but I was curious and started evaluating the "betas" starting with 2.04.94 and up to 2.05.00. All of them hat the same effect, that after some times some lights (Osram, bug #322) render unavailable and need to be power cycled. Now I'm using an osram gateway and all lights work again. Other people here report issues with different kind of sensors, but nothing happens. And the only guy from dresden-elektronik (manup) stopped answering on github in 2018.

[commandcontrolit]

@wrmulf well this is unfortunate. I had been really hoping to eliminate the Hue gateway and manage it all in HASS directly.

I wonder if there is more reliability using Rassbee. I'm using the Conbee stick, which there seems to be no issue with in regards to range.

What are other folks doing? How are they managing their lights and sensors? Just using the bridge and configuring them that way?

I'm very new to this all :)

[ebaauw]

Please note that deCONZ versions above 2.04.35 are beta. There are stability issues with the interaction with the ZigBee network, mostly introduced in an effort to support the different meshing used by the IKEA Trådfri bulbs, see #195. These issues cause deCONZ to lose connection to devices, see #316, requiring a power-cycle of the device or of the RaspBee / ConBee. I find that firmware version 0x261A0500 runs stable at my home (42 lights, 32 sensors/swiches, but only two IKEA lights).

Technically, there's no difference between the RaspBee and ConBee, both have the same ZigBee hardware and the same firmware. You need to upgrade the RaspBee/ConBee firmware to 0x261A0500 manually, as deCONZ will not prompt you for this version, see: #230 (comment).

@manup is traveling until end of January, but he does answer on occasion.

[commandcontrolit]

@ebaauw thanks. Well it's worth trying to flash my ConBee then I guess. It's useless right now.

What's a little strange to me is how there aren't a significant number of issues like mine being reported. This can't be unique to me.

I'll post back after the flash.

Thanks again.

[commandcontrolit]

That failed. Keep getting the following message. Even with disabling deCONZ on start-up.

pi@raspberrypi:~ $ sudo GCFFlasher_internal -f deCONZ_Rpi_0x261a0500.bin.GCF
GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10
no device specified use RaspBee (/dev/ttyS0)
using firmware file: deCONZ_Rpi_0x261a0500.bin.GCF
reset target

error: bootloader not responding
device used by other application?

[ebaauw]

It seems to try and find a RaspBee, you might need to specify the ConBee explicitly. Does sudo GCFFlasher_internal -l list the ConBee?

[manup]

The fix for motion sensor and hue dimmer switch becoming unresponsive is under investigation now, see #355

pi@raspberrypi:~ $ sudo GCFFlasher_internal -f deCONZ_Rpi_0x261a0500.bin.GCF
GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10
no device specified use RaspBee (/dev/ttyS0)
using firmware file: deCONZ_Rpi_0x261a0500.bin.GCF
reset target

error: bootloader not responding
device used by other application?

Looks like deconz is still running, you can stop it with $ sudo systemctl stop deconz-gui or the $ sudo systemctl stop deconz if you are running the headless version.

[manup]

Upps in case of the ConBee you must specify the device as @ebaauw mentioned, otherwise the RaspBee is selected.

$ sudo GCFFlasher_internal -d 0 -f deCONZ_Rpi_0x261a0500.bin.GCF

[commandcontrolit]

@ebaauw Here is the output

pi@raspberrypi:~ $ sudo GCFFlasher_internal -l
rmmod: ERROR: Module ftdi_sio is in use
rmmod: ERROR: Module usbserial is in use by: ftdi_sio
GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10
RaspBee: /dev/ttyS0 (default)

   1  FTDI device found

device	vendor	product	serial	description
failed to open FTDI device (0) status = 3

[commandcontrolit]

@manup Ok - it flashed after using the $ sudo systemctl stop deconz-gui. I was just using $ sudo systemctl stop deconz initially.

Output is

pi@raspberrypi:~ $ sudo GCFFlasher_internal -d 0 -f deCONZ_Rpi_0x261a0500.bin.GCF
GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10
using firmware file: deCONZ_Rpi_0x261a0500.bin.GCF 
reset via FTDI

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

[commandcontrolit]

OK - same situation - no difference at all. At this point I'll let this go and move onto another way of pulling in and controlling lights. At least until this issue with deCONZ is fixed.

[manup]

By now I have seen two issues:

1. Repeated configuring zcl reporting for power and basic clusters since reports are not received. Due max reporting interval this can take up to 7200 seconds. Early attemp to fix this in commit: a650d37

2. It happens that motion sensor sends successfully reports through multiple hops (in my case IKEA lights) but the required zcl default response won't be routet back through the very same path and is discarded at the first hop. The sensor goes in error state blinks red and rejoins the network, after which the same happens over and over. I guess this is what most people experience.

The following firmware has disabled all source and many-to-one routing as well as enabled route optimization back to a minimum to force searching for a route the standard way, not sure if it solves the issue, needs more testing ...

http://www.dresden-elektronik.de/rpi/deconz-firmware/deCONZ_Rpi_0x261c0500.bin.GCF

[commandcontrolit]

@manup Ok - I will try to find some time and test this.

[manup]

http://www.dresden-elektronik.de/rpi/deconz/beta/deconz-2.05.01-qt5.deb

A new deCONZ version 2.05.01 is available for RPi (Ubuntu/Windows follows).
It includes firmware version 0x261d0500 which further addresses some routing issues.

It's still experimental and needs more testing, I'm building a larger IKEA + Philips end-devices network to
see if there are improvements.

[ErnstEeldert]

I have experienced the same issue a number of times in the past 2 weeks. Today, the Hue motion sensor managed to get in a state on deconz where the ZHALightlevel and ZHATemperature nodes where available, but the ZHAPresence was not. Red light would blink on presence detection.

Upgraded to the 2.0.5.01 and associated firmware, so fingers crossed :)

[ErnstEeldert]

No luck it seems. Motion sensor still failed a number of times, just a red blink, and that’s it. Ideas on how to further diagnose this?

[manup]

It's a really strange issue, in my test setup with 3 hops I could recreate the problem. From what I see in the sniffer logs the IKEA lights seem to depend on NWK route record packets in some cases. The new firmware does spread those, it's not complete yet but should help to mitigate the problem.

Please also make sure that IKEA lights are on the latest firmware version.

http://www.dresden-elektronik.de/rpi/deconz-firmware/deCONZ_Rpi_0x261e0500.bin.GCF

$ sudo GCFFlasher_internal -f deCONZ_Rpi_0x261e0500.bin.GCF

or for ConBee:

$ sudo GCFFlasher_internal -d 0 -f deCONZ_Rpi_0x261e0500.bin.GCF

[ErnstEeldert]

It looks like all my IKEA lights are up to date. I've updated to 0x261e0500 and it seems to have stabilized now (ie. issue doesn't appear any long). It has been just over 24 hours, so will post another update in a few days.

[manup]

Cool thanks for looking into this, fingers crossed.

[ErnstEeldert]

It's hard to quantify, but response is intermittent. I would guess it's 60% of the time motion should be detected the signal actually reaches the lights.

Additionally, I am experiencing fairly random unresponsive devices (switches, sensors and lights). A quick power cycle of the device seems to restore the mesh connection most of the time. On other occasions just a bit of patience seems to resolve it.

[balu-]

whats the proper way to debug the hue motions?
i might have the same problem
(some of my hue motion sensors indicate via red led that they register motion, but cant talk to the network)
running phoscon 2.05.08 / 27.2.2018

[ErnstEeldert]

Still no luck with the Hue Motion sensor. Fails around 30% of the time with a red blink.

[balu-]

i can confirm @ErnstEeldert observation

[manup]

Since a long time I had the same issue overnight – today morning the sensor didn't come through and was trapped in a infinite loop to rejoin and contacting the gateway. I've let it on overnight to see if the problem resolved on it's own — didn't work.

So as a first test I've restarted the ZigBee network by doing a Leave/Join in deCONZ, which clears all runtime neighbour and routing tables in the ConBee/RaspBee firmware. After 10 seconds, the motion sensor did work again flawlessly.

I've an idea what causes this and will investigate it next weekend to provide a firmware fix for at least this issue. I don't think this is the whole story but it should fix at least one-hop issues.

[balu-]

With the new firmeware I watched a new phenomenon,
the hue motion sensor led lights up on motion, but deconz recives the command.
(The ui shows motion and changed light values).

If i can contribute anything to solving this, please let me know

[manup]

Does this happen all the time? Mine works normally the led shows just after parent is changed.

[wvuyk]

does it light up red or green?

Green is ok, ledindication is true. Red would mean the sensor is searching for a parent.

[balu-]

@manup it didn't at first, now it does everytime (but as i mentioned values seem to be registred)
[but I didn't try to reconnect it manualy since it startet flashing red]

@wvuyk it lights up red, i've only seen green light on setup

[balu-]

monitoring this issue over the last weeks,
it seems to me as if it is a combination of the hue motion sensor and ikea FLOALT (at least in my case).

I have two floalts in the corridor of my appartment.
At one end of the corridor there is the raspi with deconz, at the other, the kitchen with the hue motion.
(There are a lot more zigbee devices arround but it seems to me this might be the crucial config).

As I described sometimes the motion sensor starts to show the red led light on motion (also deconz registers the command).
Noticing this, i have switched of the two floalts (disconnected from power).
After some time, some commands from the hue motion sensor, it does no longer show the red led, even if later on the floalts got power again.
So to me, with my limited knowledge, it seems as if the problem occures if commands are relayed via the ikea lights.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[manup]

Closing this for now, Hue motion sensor problems are tracked in newer issues.