Issues with Tradfri in the latest versions

Third party integrations
1

Hi,

In the latest versions of H-A I’ve been having some serious issues with Home-Assistant and the Tradfri integration.

Earlier it seemed like it just lost connection due to a time-out in the keep-alive pat of the integration.
Lately it just doesn’t give any error messages, it just becomes unresponsive and nothing happens.

For the first issues with lost connection I created a automation to restart H-A when one of the bulbs became unavailable but this also stopped working with the new issue.

I’ve reinstalled Home-Assistant multiple times now, I have moved it from a rPi to Ubuntu, Ubuntu VM and now finally docker but there is no change in the behavior.

Only thing I’m missing, which I really would prefer not to do is a full factory reset of the tradfri gateway and re-add all the bulbs.

Anyone seen this behavior before or got any tips?

edit: forgot to add:
Tradfri gateway fw: 1.8.26 (all bulbs up to date)
H-A version: 0.96

-Daniel

2

Hi!

I came here just to say that I notice the same behavior on my side. HA runs in docker on a Raspbian system. I configured the gateway using the integrations wizard in the configuration menu of HA (I add nothing in the configuration file of HA).

Also looking for a solution :slight_smile:

3

Same here both the latest version installed.
They just become unavailable after some time restart of ha fixes it for some time

4

See here: https://github.com/home-assistant/home-assistant/issues/14386

5

Tested with the ports opened but the problem resurfaced.
This time with these fat error like this for every single bulb.

Wed Jul 24 2019 18:13:03 GMT+0200 (Central European Summer Time)
Observation failed for Kjokken4
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/pytradfri/api/aiocoap_api.py", line 95, in _get_response
    r = await pr.response
  File "/usr/local/lib/python3.7/site-packages/aiocoap/protocol.py", line 816, in _run_outer
    yield from cls._run(app_request, response, weak_observation, protocol, log, exchange_monitor_factory)
  File "/usr/local/lib/python3.7/site-packages/aiocoap/protocol.py", line 865, in _run
    blockresponse = yield from blockrequest.response
aiocoap.error.RequestTimedOut

rror executing service <ServiceCall light.turn_off (c:9814caedb12147eeb94c96f23f3e71db): entity_id=['light.gjesterom_1']>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/pytradfri/api/aiocoap_api.py", line 95, in _get_response
    r = await pr.response
  File "/usr/local/lib/python3.7/site-packages/aiocoap/protocol.py", line 816, in _run_outer
    yield from cls._run(app_request, response, weak_observation, protocol, log, exchange_monitor_factory)
  File "/usr/local/lib/python3.7/site-packages/aiocoap/protocol.py", line 865, in _run
    blockresponse = yield from blockrequest.response
OSError: [Errno -1] No error information

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/core.py", line 1159, in _safe_execute
    await self._execute_service(handler, service_call)
  File "/usr/src/homeassistant/homeassistant/core.py", line 1172, in _execute_service
    await handler.func(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 194, in handle_service
    required_features
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 316, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 337, in _handle_service_platform_call
    await getattr(entity, func)(**data)
  File "/usr/src/homeassistant/homeassistant/components/tradfri/light.py", line 252, in async_turn_off
    await self._api(self._light_control.set_state(False))
  File "/usr/local/lib/python3.7/site-packages/pytradfri/api/aiocoap_api.py", line 155, in request
    result = await self._execute(api_commands)
  File "/usr/local/lib/python3.7/site-packages/pytradfri/api/aiocoap_api.py", line 146, in _execute
    _, res = await self._get_response(msg)
  File "/usr/local/lib/python3.7/site-packages/pytradfri/api/aiocoap_api.py", line 105, in _get_response
    await self._reset_protocol(e)
  File "/usr/local/lib/python3.7/site-packages/pytradfri/api/aiocoap_api.py", line 78, in _reset_protocol
    await protocol.shutdown()
  File "/usr/local/lib/python3.7/site-packages/aiocoap/protocol.py", line 133, in shutdown
    for exchange_monitor, cancellable in self._active_exchanges.values():
AttributeError: 'NoneType' object has no attribute 'values'
6

@bouwew Thanks for the link to the issue.

So, it seems like this issue exists for a long time and is not totally fixed.
Last comments recommand to configure firewall to specifically open an UDP port.
But, as @DanielM said, it does not seem to be reliable…

On my setup, there is no firewall (it’s no accessible to the public internet), but I don’t know how Docker handles the network and long standing UDP connection… Is ther anything I can try on the docker side?

EDIT: I do have iptables enabled with very simple rules:

*nat
:PREROUTING ACCEPT [762531:54844296]
:INPUT ACCEPT [576982:43332632]
:OUTPUT ACCEPT [285086:24987691]
:POSTROUTING ACCEPT [141096:14636344]
-A POSTROUTING -o enx001e063201e9 -j MASQUERADE
COMMIT
# Completed on Sat Jul 27 18:08:11 2019
# Generated by iptables-save v1.6.0 on Sat Jul 27 18:08:11 2019
*filter
:INPUT ACCEPT [253473869:105926037231]
:FORWARD ACCEPT [1486789:1102235362]
:OUTPUT ACCEPT [228306896:142148378213]
:DOCKER-USER - [0:0]
-A INPUT -p tcp -m tcp --dport 3000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8123 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8083 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8086 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8090 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8123 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8083 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8086 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8090 -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -i docker0 -o enx001e063201e9 -j ACCEPT
-A FORWARD -i enx001e063201e9 -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o enx001e063201e9 -j ACCEPT
-A FORWARD -i enx001e063201e9 -o docker0 -j ACCEPT
-A FORWARD -i wg0 -j ACCEPT
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Sat Jul 27 18:08:11 2019
7

How long does it usually take for bulbs to become unavailable?

I’m also running Firmware: 1.8.26, but no issues for me to far, running HassIO on a RPi 3, but I usually restart HA once every 2 days due to updates/tinkering.