Running room-assistant.service results in packet loss/poor network perf

Describe the bug Having established 5 Pis with room-assistant (using ansible-playbooks) in a cluster, I was finding a majority of them to be very slow/unresponsive to SSH. I dug deeper and found that pinging each Pi in turn, I had packet loss hovering between ~25-50% while room-assistant was running as a service.

I confirmed that there was no issue with packet loss from other computers on the network, nor by pinging my router. The issue only manifests itself as below:

To reproduce Install room-assistant on a number of nodes, and start the room-assistant.service

This occurred with both RPi 3B and RPi Zero W (although interestingly not on my RPi 3B+ - possibly because it was the delegated leader of my cluster)

Stopping the service, and instead running the package with room-assistant -v, I no longer had any issues with SSH or with packet loss when pinging each RPi, either from my laptop, or SSHing into a Pi and pinging one of the other Pis from that system.

No errors reported via room-assistant -v

Relevant logs Example of packet loss. First ping is while room assistant is running in terminal from ‘room-assistant’ command, second ping is after running ‘sudo systemctl start room-assistant.service’ (with a few second delay to allow the service to establish itself before testing, probs should have waited a little longer)

readeral@readeral ansible-playbooks % ping 10.0.1.10
PING 10.0.1.10 (10.0.1.10): 56 data bytes
64 bytes from 10.0.1.10: icmp_seq=0 ttl=64 time=6.585 ms
64 bytes from 10.0.1.10: icmp_seq=1 ttl=64 time=7.124 ms
64 bytes from 10.0.1.10: icmp_seq=2 ttl=64 time=6.728 ms
64 bytes from 10.0.1.10: icmp_seq=3 ttl=64 time=6.761 ms
64 bytes from 10.0.1.10: icmp_seq=4 ttl=64 time=6.563 ms
64 bytes from 10.0.1.10: icmp_seq=5 ttl=64 time=8.789 ms
64 bytes from 10.0.1.10: icmp_seq=6 ttl=64 time=6.647 ms
64 bytes from 10.0.1.10: icmp_seq=7 ttl=64 time=7.113 ms
64 bytes from 10.0.1.10: icmp_seq=8 ttl=64 time=6.437 ms
64 bytes from 10.0.1.10: icmp_seq=9 ttl=64 time=9.329 ms
^C
--- 10.0.1.10 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.437/7.208/9.329/0.957 ms
readeral@readeral ansible-playbooks % ping 10.0.1.10
PING 10.0.1.10 (10.0.1.10): 56 data bytes
64 bytes from 10.0.1.10: icmp_seq=0 ttl=64 time=6.178 ms
64 bytes from 10.0.1.10: icmp_seq=1 ttl=64 time=6.366 ms
64 bytes from 10.0.1.10: icmp_seq=2 ttl=64 time=8.175 ms
64 bytes from 10.0.1.10: icmp_seq=3 ttl=64 time=6.925 ms
64 bytes from 10.0.1.10: icmp_seq=4 ttl=64 time=7.285 ms
64 bytes from 10.0.1.10: icmp_seq=5 ttl=64 time=6.321 ms
64 bytes from 10.0.1.10: icmp_seq=6 ttl=64 time=748.689 ms
64 bytes from 10.0.1.10: icmp_seq=7 ttl=64 time=3.974 ms
64 bytes from 10.0.1.10: icmp_seq=8 ttl=64 time=7.310 ms
64 bytes from 10.0.1.10: icmp_seq=9 ttl=64 time=7.239 ms
64 bytes from 10.0.1.10: icmp_seq=10 ttl=64 time=8.940 ms
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
64 bytes from 10.0.1.10: icmp_seq=12 ttl=64 time=2195.001 ms
64 bytes from 10.0.1.10: icmp_seq=15 ttl=64 time=830.814 ms
64 bytes from 10.0.1.10: icmp_seq=16 ttl=64 time=651.128 ms
64 bytes from 10.0.1.10: icmp_seq=17 ttl=64 time=6.460 ms
64 bytes from 10.0.1.10: icmp_seq=18 ttl=64 time=17.882 ms
64 bytes from 10.0.1.10: icmp_seq=19 ttl=64 time=6.610 ms
64 bytes from 10.0.1.10: icmp_seq=20 ttl=64 time=6.509 ms
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
64 bytes from 10.0.1.10: icmp_seq=23 ttl=64 time=1621.412 ms
^C
--- 10.0.1.10 ping statistics ---
26 packets transmitted, 19 packets received, 26.9% packet loss
round-trip min/avg/max/stddev = 3.974/323.854/2195.001/612.585 ms

Relevant configuration Paste the relevant parts of your configuration below.

all:
  hosts:
    'zero-hub.local':
      room_assistant_config: 
        global:
          instanceName: hub
          integrations:
            - homeAssistant
            - bluetoothClassic
        cluster:
          weight: 6
    'zero-kitchen.local':
      room_assistant_config: 
        global:
          instanceName: kitchen
          integrations:
            - homeAssistant
            - bluetoothClassic
        cluster:
          weight: 4
    'zero-dining.local':
      room_assistant_config: 
        global:
          instanceName: dining
          integrations:
            - homeAssistant
            - bluetoothClassic
        cluster:
          weight: 3
    'zero-bedroom.local':
      room_assistant_config: 
        global:
          instanceName: bedroom
          integrations:
            - homeAssistant
            - bluetoothClassic
        cluster:
          weight: 5
    'zero-spareroom.local':
      room_assistant_config: 
        global:
          instanceName: spareroom
          integrations:
            - homeAssistant
            - bluetoothClassic
        cluster:
          weight: 5
  vars:
    room_assistant_global_config:
      global:
        integrations:
          - homeAssistant
          - bluetoothClassic
      homeAssistant:
        mqttUrl: mqtt://10.0.1.30:1883
        mqttOptions:
          username: room-assistant
          password: secretpass
      bluetoothClassic:
        interval: 5
        timeoutCycles: 2
        addresses:
          - '9C:E3:3F:2C:E4:D9' #Alan Phone
          - '00:DB:70:20:FF:BD' #Alan Watch
          - 'D4:61:DA:13:B8:6F' #Angie Phone
          - '14:C2:13:24:D4:08' #Angie Watch

Expected behavior A clear and concise description of what you expected to happen.

For my network experience to not have packet loss…

Environment

• room-assistant version: 2.4.0
• installation type: NodeJS (via ansible-playbook)
• hardware: Raspberry Pi Zero W, Raspberry Pi 3B
• OS: Raspbian
• Node: v10.20.1 (RPi zero) v12.16.2 (RPi 3B)

Additional context I did have issues with mdns installing - but that seems unrelated as the problem persisted once I’d manually reinstalled room assistant without the help of ansible (see this issue for the mdns problem)

[ragenhe]

I noticed the same behavior on my zero w (2) and 3b+ (2). Going down the rabbit hole, I chalked it up to a wireless issue and positioned them with that in mind, which isn’t always ideal to be honest. I also moved my interval to 30 seconds and that helped with the responsiveness. I’m going to run the same test, service vs non-service and see what I get.

[readeral]

Ah I didn’t realise that there was a separate Troubleshooting on the BT integration page. Might be worth moving that to be top level? Unlikely I’d go looking for troubleshooting on a per-integration basis (well… I didn’t!)