546
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 14 Feb 2024
546 points (97.4% liked)
Technology
59583 readers
3487 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
I have this setup and using the esp my stack device mentioned in the article. The biggest problem with it is esphome and home assistant expect home assistant to be running in a dedicated device for this to work. The integration uses a random UDP port to communicate with the M5 stack device. I had to resort to patching the Integration to use a couple specific ports to work properly.
Unfortunately the fix didn't last long and a update to home assistant updated the integration and now the text to search response fails for esphome devices. My next plan is to try to downgrade esphome integration to the old one that was patched / working and call it a day.
I run HassOS virtualized and have had no issues getting it to use the Atom Echos with ESPhome flashed to them, I have 3 of them in use and a wyoming install on one desktop that communicates as well. Not sure what you might have different. I can certainly see that patching the integration would go badly as a Supervised install will probably lose any patching on container restarts or upgrade.
If your setup allows random udp ports from home assistant out to your network it works fine. Mines running in a kurbenetes cluster.
I used a configmap that mounts the code to patch the integration so it doesn't get overwritten. I haven't had time to troubleshoot more though I don't see why the patch would stop text to speak from working on the esphome devices. The code changed significantly and uses raw audio files now and the only thing I am changing is making the ports not random, but a range instead. The M5 stack firmware appears to be up-to-date too.
Issue on GitHub with all of this is here