Websocket issues in docker installation

Home Assistant OS
#1

I use HASS installed in docker (homeassistant/home-assistant:latest), which I thought would relieve me of problems like this:

My Z-Wave.Me integration stopped after 4 days of operating fine, like described in this github issue.

Today i updated my docker to the latest issue, and I still get the same issue.

I had this problem previously when trying to add the z-way integration, and a completely fresh install of HASS (setting everything back up from scratch) starting with the z-way integration fixed it… for 4 days…

Any suggestions/ideas on whats wrong is greatly appreciated!

#2

Maybe there is an issue with your container options. You can try posting your run command/compose to see if that is creating some sort of issue.

Are they running on the same machine? Its possible you have something creating a port or ip conflict. It looks like zwave.me needs port 8083 open and reserved for it.

Also, are you running docker on a Linux machine? If using Mac or windows docker you’ll have problems.

#3

Below is my docker-compose. (it’s also setting up HASS Configurator, and a link to the setup volume for Multi-System Reactor)

All dockers are running on a Chromebox running Debian, and communication is in an internal docker network (HAnett). The link with z-wave.me is set up using the z-wave.me docker IP wss://192.168.0.2:8083.

It did work for days, thats whats strange?

version: "3.9"
services:
  HASS:
    container_name: HASS
    restart: always
    image: homeassistant/home-assistant:latest
    networks:
      HAnett:
        ipv4_address: 192.168.0.10
    ports:
      - "8123:8123"
    volumes:
      - type: bind
        source: /etc/localtime
        target: /etc/localtime
      - type: volume
        source: HASSconfig
        target: /config
    logging:
        driver: "json-file"
        options:
            max-file: "5"
            max-size: 10m
  HASSconfigurator:
    container_name: HASSconfigurator
    image: causticlab/hass-configurator-docker:x86_64
    networks:
      HAnett:
        ipv4_address: 192.168.0.11
    restart: always
    ports:
      - "3218:3218/tcp"
    volumes:
      - type: bind
        source: /etc/localtime
        target: /etc/localtime
      - type: volume
        source: HASSconfig
        target: /config
      - type: volume
        source: MSR-config
        target: /ReactorConfig
    environment:
      - HC_BASEPATH=/config
      - HC_HASS_API_PASSWORD=eyJ0eXAiOiJKV1***
      - HC_IGNORE_SSL=True
networks:
      - HC_HASS_API_PASSWORD=eyJ**
      - HC_IGNORE_SSL=True
networks:
    HAnett:
        name: HAnett
        driver: bridge
        ipam:
            config:
                - subnet: 192.168.0.0/16
volumes:
  HASSconfig:
    name: HASSconfig
  MSR-config:
    name: MSR-config
    external: true
#4

The documentation advises Home assistant container needs host networking mode to work properly.

Without host networking mode, and just opening 8123 with the ports option, you won’t have discovery and necessary ports left open, and are creating network isolation between the host and docker container. With other docker containers that’s desired, but with Home Assistant that network isolation likely will create problems like the one you are experiencing. Is there a reason you can’t use host networking mode? I would at least try it temporarily to see if it solves your issue.

I run container and dont use the configurator. I’m not that familiarwith it, but its image is over a year old. Not sure if that’s causing issues for you either. An alternative to configurator could be portainer to manage the home assistant container in a UI and installing samba on the host os so you can view and edit the config files easily on a windows laptop.

#5

Host networking mode is news to me, thanks!

When i started setting up my dockers it seemed like a good idea to isolate all internal network communication in order to have a peaceful network interface on the host, with my limited knowledge in IP networks… Another benifit is that I can replace the host IP (and the host HW itself) without changing interconnecting IPs in my configuration files…
I’ll try to change to host mode and report results. :slight_smile:

The configurator is a simple separate container providing an explorer window for the yaml files (i have it in an iframe in HASS), can’t really see how that would affect HASS negatively?
I also use portainer for container control, love it. :slight_smile:

#6

Ok I looked into the configurator a bit more. I thought it only worked as an addon with supervised/HAOS installs. Appears custom (image not part of Home-assistant repo) for container installs. Doubtful it would create a conflict, but being “custom” I suppose it’s possible.

I would definitely try the host networking option first, assuming you are running a Linux os on the host machine. Host networking mode doesn’t work on windows or Mac docker installs, which is why docker is not recommended when the host OS is windows or mac.

#7

Host network seems to work, the connection is up again. :slight_smile: Hopefully it will stay ok too. Thats what threw me, it actually worked for a long while…

Thanks, @mwav3!

1 Like
#8

It looks like it’s websocket so always needs to stay open. The host network mode will remove some extra layers that could be closing the socket.

Hopefully it stays open now.

#9

Well, it stayed OK until a few hours ago, now i’m back at the same “missing 1 required positional argument: ‘utf’”, and all z-way entities show unavailable…

Guess the host network didn’t do the trick, any other suggestions? Really don’t know where to start looking here…

#10

I’m not really sure what else could be wrong. Everything else on your Home Assistant docker install looks correct to me. According to the integration page the analytics show zwave.me is only used by 12 active installations, so there aren’t a lot of others using this unfortunately so a problem in the integration itself might not be getting picked up, or a fix might not get prioritized. It seems something is closing after a period of time (probably the websocket) and it can’t re-establish itself. That github issue links to a change with a python package that might be responsible, but as you mentioned there, Home Assistant container should have all packages and dependencies in there and up to date. If it doesn’t, then there is a problem with the docker build for Home Assistant container where it is not using the current/correct package.

I have not used zwave.me, but how is your zwave.me installed? What hardware/os is it running on? Is it the same machine?

Is there any reason you don’t want to switch over to the more popular and better supported zwavejs2mqtt option? That’s what I use and it runs in docker, and connects to home assistant by websocket just fine (you don’t have to use the mqtt part). I have not had issues with it and closing websockets.

https://zwave-js.github.io/zwavejs2mqtt/#/getting-started/docker

#11

z-wave.me is in a docker on the same host, and I’ve had a websocket connection from openLuup to it for two years with no problems… So, I doubt that the z-wave.me install or container is at fault, but the HASS integration is as you know quite new.
I really can’t see how this could be because of an old websocket version either, as it actually works for days before caving? if the integration uses a feature in a newer package it wouldnt work to begin with right?

Main reason for sticking with z-wave.me is it’s expert panel. I think its still unmatched in terms of z-wave network control and monitoring, and its always been stable and fast. re-including 50ish units is no picnic either, so it would need to be for some very good reasons!

#12

I just updated websocket-client from 0.54.0 to 1.3.2 in the docker, and z-wave.me is operational again. lets see if it stays up!

#13

This still works, so mabye it just needed this update. But what’s the system for the HASS core regarding the websocket version? Seems like they stopped on .54 for the docker at least, how do I go about notifying about the need for a newer version? Is this something included in the specific integration?

#14

Short of a new github issue, I would try to raise the issue on discord. The developers more frequently monitor that then the community here.

If that package doesn’t get updated in the core docker image, you’ll have to manually update it every time you update the container to a new version.