Atom Echo M5 - 13$ Voice assistant tutorial (Issues setting up in Docker)

[galli-miranda (Bruno Galli Miranda)]

Hey there, 1st time poster, hope I’m doing this right
I am super excited about the new assist wake word detection and have bought two M5 Atom Echo devices to play around with, but ran into some issues, which I’ll try and describe as good as I can below, let me know if you need more info.

my HA runs in my homelab, in a docker container, and so do my piper, openwakeword and whisper. They are all properly configured in my Pipeline - Which I successfully tested via the debug options of the pipeline (screeshot below)

Now, while following this 13$ thing tutorial for the AtomEcho I’ve found the first divergence in step 6. it clearly states that the connection setup should not show up - mine does. I never had any ESPhome integration before, so I can’t remove it as the tutorial suggests. I’ve gone and grabbed the IP which was given to the AtomEcho, used that as host and left the door as it was - It worked and I can see this in my settings:

I can play around with the LED colors and I can see when a button was pressed, which I believe means that the device is properly connected.
However, I can’t get it to wake on the hot word, and if I turn it off to test the pipeline using the button, it blinks blue and nothing happens.

What am I missing here ?
hope you can help me out!

[Jojofroyo (Chuck)]

Did you train your own wake word?

[galli-miranda (Bruno Galli Miranda)]

Nope, I’ve used the “hey_jarvis” one.

[zelial]

Hey, I had the same problem, in my case it was caused by the firewall: the Atom Echo needs to be able to opens connections back to the HomeAssistant server. Allowing that fixed it for me.

[derp90]

What do you mean by firewall?
On the atom echo? Router? Host PC?

[galli-miranda (Bruno Galli Miranda)]

Hey, thanks for your reply!
I thought it could be related to that and tried a few things…

Port forwarding port 6053 with UDP protocol, then aloowing the same on my firewall (I am hosting on a Linux server and use ufw - if that makes any difference).
Now, I am by no means a network expert, so I fiddled with this forwarding by changing the ip from my device to my server, allowing all protocols or only udp but nothing seems to fix it. Any idea how I could test if that is in fact the issue ? maybe narrowing it down would be a good idea.

[galli-miranda (Bruno Galli Miranda)]

Hey, more Info: I am using this docker img which requires no config.
which I adapted from here

  openwakeword:
    container_name: openwakeword
    image: rhasspy/wyoming-openwakeword
    user: 1001:1001
    networks:
      - hass
    volumes:
      - ./wakeword:/data
      - ./wakeword:/custom
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    environment:
      - TZ=Europe/Berlin
    command: --preload-model 'ok_nabu' --custom-model-dir /custom
    restart: unless-stopped
    ports:
      - 10400:10400 #i've tried 6053 as the atomEcho too, both here and in the firewall rules 

[derp90]

Can you be more specific on what this means?

[thebradleysanders (Brad Sanders)]

I run Home Assistant in docker swarm for high availability, because of this the container is running in bridge mode/overlay mode. This causes the random UDP port issue to be apparent. It would be nice to see a static UDP port range I can then allow for my container. Currently the ports are so random this is not possible (I tried). Only host networking would work for this.

[galli-miranda (Bruno Galli Miranda)]

Oooh… I thought the UDP port would be fixed…
If I get it right, the ports are randomly asigned in HA…
This might be a stupid question, but how does the HA OS deal with that ? (hosting its own network ?)

I’ll try looking into that, thanks for the insight!

[thebradleysanders (Brad Sanders)]

So far this looks promising:

My docker swarm setup

I’ve been trying to get Homeassistant working on swarm for a few months now, but the thing that was preventing me from moving to swarm was the Homeassistant requirement to use host networking on the container. I had tried many things but I finally got everything to work with the macvlan driver. I configured the homeassistant service with two networks: One macvlan network, giving it an IP address in my iot network One overlay network, giving traefik access to homeassistant The macvlan network…

I have implemented this and now hass has its own ip on my lan while also retaining access via my Traefik load balancer also apart of the same swarm. I can post my Coompose yaml if it helps anyone.

Ill update this if this works.

[derp90]

I was able to get this to work, it required home assistant in host networking mode, and my host system disable the mDNS service.

[roobre]

I run Home Assistant in Kubernetes and I’m also facing this. I believe the underlying problem is the same: Opening a random port and trusting that it will be reachable by external devices doesn’t seem to work outside of flat, non-firewalled networks.

It would be great if Hass could use a different architecture for this, ideally either starting the UDP connection itself to a predictable port on the Esphome device (so NAT can allow audio data to get back to it), or using a multiplexed server on a fixed UDP port.

[galli-miranda (Bruno Galli Miranda)]

I got it!
My Network setup might be a bit convoluted and likely not the best, but I’ll tell you about it and it might help someone.
Basically, I have 2 bridge networks + one ipvlan in my docker, one bridge is for exposing certain services via traefik and one for connecting some stuff to it (like Node-red for example).
Using the ipvlan allowed me to reach HA directly from the local network, which in turn fixes the issue with the random UDP ports!
creating the ipvn : docker network create -d ipvlan --subnet 192.168.1.0/24 --gateway 192.168.1.1 -o parent=eno1 ipvlan_ha
(parent port and subnet must match your settings of course)

my HA network compose setup:

 networks:
      ipvlan_ha:
        ipv4_address: 192.168.1.104
      HA:
        ipv4_address: 172.26.0.4
      proxy:
        ipv4_address: 172.18.0.4

In the end, I didn’t even have to alter much in the firewall. Hope this helps!

[wow79]

Hi, I’m also struggling to get voice from Atom Echo back to HASS presumably due to firewall blocking (see my post here. Has anybody succeeded in predefining the port or port range for such HASS ports to be opened for ESPhome devices?

Thanks
Wolfgang

[vanbrakel.pieter (Pieter van Brakel)]

Hi,

I have got the same problem. They way I went around it was as follows, hope it is useful.
Gave the home assistant a static IP address, for example 192.168.0.12
Gave the atom Echo M5 also a static IP address for example 192.168.0.22

In the terminal I then gave the command
sudo ufw allow all from 192.168.0.12 to 192.168.0.22
sudo ufw allow all from 192.168.0.22 to 192.168.0.12

This opened all ports just between homeassistant and the atom echo m5 and I do not need to worry about random ports between the two being opened and closed.

[Canedje]

I do have exactly the same problem.
I’m running HA and the Wyoming as dockers under Unraid
I’m still not able to get the Atom understand the voice and send something into the pipeline.
HA docker is Host
I tried adding port 6053 UDP and TCP to HA and ESPHome but no succes.

esphome log

Any tips?