#zigpy

1 messages · Page 1 of 1 (latest)

kind heart
weak jackal
#

nice

kind heart
#

zigpy

weak jackal
#

the thing is - it's more of a general question atm, so I don't really feel a github issue would be the right medium. I'm seeing timeouts when executing cluster commands on devices. from what I can tell it basically happens never when I'm only dispatching 1 or 2 cmds at once but gets a lot more frequent when it's ~5 commands

#

so my basic question I guess is: is this to be expected? 😄

kind heart
weak jackal
#

hm, hadn't seen those - good hint!

kind heart
#

Zigpy doesn't really handle transmitting stuff itself, that's delegated to the specific radio library

#

Which coordinator are you using?

weak jackal
#

conbee2

kind heart
#

Are you sending a few requests to many devices at once or many requests to a few devices?

weak jackal
#

usually only 1 cmd per device - like switching a couple of lights off or so

#

fun fact: most of the time it actually works even when I see the timeouts

kind heart
#

What's throwing the timeout exception?

weak jackal
#

give me a minute, need to dig up a trace

#

also fun fact: from a couple of lights I receive the attribute updates, from others I don't.

kind heart
#

Did you setup attribute reporting for the on_off or level attributes? Or is this just a ZHA network that you're directly controlling with zigpy?

weak jackal
#

I'm more or less binding all the clusters I can get tbh X-D

#

the code looks like this:

            if cluster.is_server:
                attributes: Dict[int, Tuple[int, int, int]] = {}
                for attribute in cluster.attributes.keys():
                    attributes[attribute] = (0, 60 * 60, 1)
                await cluster.configure_reporting_multiple(attributes)
#

not really sophisticated I guess

kind heart
#

Do you get SUCCESS for all of the reporting requests?

weak jackal
#

for the lamps in question, yes - and it usually works - it's really pretty random

kind heart
#

So it just doesn't get delivered??

weak jackal
#

looks like that on my end

kind heart
#

Strange. The radio library doesn't really handle low level stuff like that so I guess it's just a Conbee quirk

#

You have it on a USB extension cable and away from sources of interference, like USB 3.0 ports, SSDs, etc?

weak jackal
#

look, I'm a bit surprised to get sb who knows about zigpy that quickly to be honest and I need to run now - can I get back to you another day? I'm reheeeeally greatly appreciating your efforts and don't want to appear ungreatful - I just really need to get going...

kind heart
#

Sure, ping me if you have a question. Or post a discussion on GitHub, it's less real-time and you might get a few more people looking at your question

weak jackal
#

many thanks! such nice!

valid torrent
#

some bulbs also don't follow the spec and wont report status

#

like older hue bulbs that are ZLL need to be polled... we have special handling in ZHA for these cases

#

I think some gledopto and some others do this as well... so they will work but you wont get attr reports

weak jackal
#

I'm more or less confident that the issue is related to how many commands I'm putting on the air simultaneously as it's only happening when I dispatch more than 1 cmd at once and gets worse with the number of simulatenous
commands sent.

#

Here's the exact behavior:

  1. Dispatch a number of commands (e.g. on_off.on) to different devices (1 cmd each)
  2. The devices do successfullly receive the message
  • You can actually see them turning off successfully
  • There are extremely rare (as in: happens once a week or so) instances where one of the bulbs wouldn't turn off
  1. See an exception for a subset of the devices (see trace below)
  2. Receive an attribute update for a subset of the devices
#

Additional info:

  • All devices are the same (for my testing I use IKEA TRADFRI bulb GU10 WW 400lm bulbs)
  • All devices work as expected when being talked to separately (no timeouts, proper attribute reporting)
  • The issue is quite reliably present when I'm sending 5 cmds at once
  • I'm using a Conbee II on a Raspi 2
  • Dependency versions:
    • zigpy-deconz==0.13.0
    • zigpy-znp==0.5.4
    • zha-quirks==0.0.61
#

Traceback:

Sep 30 07:39:18 raspberrypi dahoam.sh[16298]: ERROR:root:Failed to invoke device command: on
Sep 30 07:39:18 raspberrypi dahoam.sh[16298]: Traceback (most recent call last):
Sep 30 07:39:18 raspberrypi dahoam.sh[16298]:   File "/data/friday-zigbee/app/model/device.py", line 185, in invoke_command
Sep 30 07:39:18 raspberrypi dahoam.sh[16298]:     await getattr(cluster, command_name)(*params)
Sep 30 07:39:18 raspberrypi dahoam.sh[16298]:   File "/data/friday-zigbee/venv/lib/python3.7/site-packages/zigpy/device.py", line 296, in request
Sep 30 07:39:18 raspberrypi dahoam.sh[16298]:     result = await asyncio.wait_for(req.result, timeout)
Sep 30 07:39:18 raspberrypi dahoam.sh[16298]:   File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
Sep 30 07:39:18 raspberrypi dahoam.sh[16298]:     raise futures.TimeoutError()
Sep 30 07:39:18 raspberrypi dahoam.sh[16298]: concurrent.futures._base.TimeoutError
valid torrent
#

are you toggling several bulbs at once?

#

if so... add them to a group and issue a group command

#

will cut down on the network traffic

weak jackal
#

yes, I'm toggling multiple bulbs at once. while I agree that putting them in a group might be a solution for static groups of devices to be talked to, I think that'd be just be a workaround for the issue at hand.

I'm really trying to find a cause for the timeouts / missing attribute updates I'm seeing...

valid torrent
#

what kind of bulbs are you using

#

what pi are you using

#

is the stick on an extension cord?

#

what storage type is the pi using?

#

there are so many things that can impact this it's kind of nuts

#

if you wanna rule out everything at once... set wireshark up on another machine w/ a different stick and capture the Zigbee packets

#

if everything in the air looks good it will tell you it is something in your setup

#

if it doesn't... then you know it is some sort of interference in the mesh

#

or something else like that

weak jackal
#

I'm testing w/:

  • 5x IKEA TRADFRI bulb GU10 WW 400lm
  • Raspberry PI 2 B+
  • ConBee 2
  • Storage: SD-Card

just ordered an extension cable - it'll be here on saturday 🙂

valid torrent
#

Raspberry PI 2 B+ and SD are potential issues

#

I would definitely do a wireshark trace... chances are everything is fine and there is an issue w/ your specific setup where it struggles to keep up

#

just a guess

weak jackal
#

I could quite easily switch that for a laptop w/ SSD for verification purposes - great hint! thanks! I'll report back once I know more. should that not shed some lights on the issue I'll check what I'll need for the wireshark trace.

#

no luck, still timeouts on the laptop, so I can more or less rule out the raspi being too slow I guess

valid torrent
#

get the trace going

#

it will help a lot

weak jackal
#

nice, got a couple of those CC2531s lying around accidentally

valid torrent
weak jackal
#

maybe I'll get around to it over the weekend 👍

#

thanks for your input! it's really much appreciated!

valid torrent
#

you bet

weak jackal
kind heart
#

You can use a raspberry pi or an ESP8266 as well

weak jackal
#

nah, I'll just go for the CC Debugger kit - seems to be the easiest way to do it

kind heart