unpredictable behavior when executing commands

[Thomas Delaet]

Where are you using pytradfri (eg stand-alone, Home Assistant etc)

As part of home assistant

Version of pytradfri

7.0.2

Backend used (aiocoap, libcoap)

aiocoap (async)

Expected behaviour

Understand cause of errors and what needs to be done to fix it.

Actual behaviour

I observe a couple of issues which I have no way of debugging. More than a solution, I'm looking for some tips on how to debug these.

• I get regular messages like this in my home assistant logs without any error from pytradfri library (logging is at warn level):

2020-10-26 00:14:21 ERROR (MainThread) [homeassistant.components.tradfri.base_class] Unable to execute command <Command put ['15001', 65721]: {'3311': [{'5851': 50, '5712': 10}]}>: {"r":"09"}
2020-10-26 00:14:40 ERROR (MainThread) [homeassistant.components.tradfri.base_class] Unable to execute command <Command put ['15001', 65687]: {'3311': [{'5850': 0}]}>: {"r":"09"}

These seem to occur whenever there is a "batch" of commands being executed but not always. Sometimes this means that afterwards everything works perfectly again when I try to switch on/off individual lights. Sometimes this is the start of a lot of error messages where eventually the only solution is to stop home assistant. power off tradfri gateway and then back on in reverse order.

• I also sporadically observe a TimeoutError when trying to put lights on or off in appdaemon, without any error/warning being thrown in homeassistant or pytradfri.

Would also love to understand if it's possible to use sync version of pytradfri in homeassistant and whether this would make a difference.

Thanks a ton for any pointers! I've tried using zigbee2mqtt instead of ikea gateway. This worked more reliably but the issue was that with every run 1 or 2 lights where not reachable.

[Patrik Lindgren]

Does it work if you send the commands using the pytradfri lib as a stand-alone library?

Regarding your questions on home assistant, please use the repo for core instead.

[Thomas Delaet]

Thanks for your response!

I haven't tried that yet. Do you think it will make a difference? The issue is that it only seems to occur after prolonged use so not sure how I can simulate that. Shoud I use sync or async version?

[Patrik Lindgren]

Not sure but it could be helpful finding out where the error lies. Shouldn't matter which version you use.

[Thomas Delaet]

I've been debugging this quite a bit. The issue is that observation is super-unreliable in my setup and causes the gateway to behave in unpredictable ways. I assume this is due to the large number of lights in my setup (I have 70+ Ikea lights connected).

How I solve this:

• Given that all changes to the lights happen in any way through home assistant, I don't really need the permanent observation
• I disabled the home assistant tradfri integration and wrote my own pytradfri-mqtt.py script that does the following:
  => On startup, it connects to the tradfri gateway and exposes all lights through mqtt with configuration discovery
  => Whenever it receives a command from home assistant to modify state, it executes that command
  => Right afterwards, it retrieves state from the gateway and publishes that on mqtt
  => Between all commands send to the tradfri gateway is a minimal delay of 0.05 seconds (time.sleep).
  => Whenever an error is encountered, the pytradfri-mqtt.py script quits and restarts (I use daemontools).

Has been working now for two weeks in a more reliable way than I have ever experienced with the home assistant tradfri integration due to the lack of observation load and the introduction of minimal delay between commands to the gateway.

Happy to help anybody who has a similar problem.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days