Thanks for checking. So I’m still too scared at the moment. :)
I want to flash my vac with Valetudo - my goal is to run-only, no cloud. But I read through Valetudo’s instructions and it’s too scary for me. I don’t think I have the skills to solder a board together and I barely understand all the steps. I can follow instructions, but there’s one point where they say something like “do these few steps within 180 seconds or you may brick your vacuum” - that’s too much risk for a ~$1000 vacuum. I didn’t upgrade the firmware on my vac, so maybe someday the process will be slightly easier and I’ll take the risk.
Will the valetudo vacuum card/integration work with an un-valetudo-ed vacuum?
Also, while this integration recognizes the mopping capability of the vacuum (it shows the status of the mop heads in terms of dry or moist), it doesn’t seem to offer the ability to control the mopping functionality (I can’t see a way to change the mop settings like I can with the vacuum’s fan speed). Interesting.
That worked wonderfully! Thanks, @ipp0@lemmy.world.
I had originally tried this HACS integration when I was first setting up my vacuum and it failed. The reason turned out to be a subnet issue, but by the time I figured that out, I had forgotten about the Dreame Vacuum integration.
Do you know if the Dreame Vacuum integration supports the video camera on the vacuum? Or is there another way to view the vacuum’s camera in HA?
I enabled the assist_pipeline and retrieved and listened to the audio files from my Echos, but when I tried to look at the esphome/m5stack-atom-echo-wake-word.yaml
file to edit the values for noise_suppression_level
, auto_gain
, or volume_multiplier
, the file doesn’t exist. I do have an esphome
directory and it contains m5stack-atom-echo-xxxxxx.yaml
files for each of my echos, but inside those .yaml files there is no voice_assistant
section.
Can you please paste the contents of your m5stack-atom-echo-wake-word.yaml
file (obfuscating anything private, of course)? I’ll try manually creating this file to see if the Echos recognize it.
ABS works pretty well for me. Thanks!
The only way I see to sync play-state is if you use the ABS app or the web page. In ABS you can create an RSS feed for a podcast and you can subscribe to that feed in Antennapod, and the podcasts sync but their play-state doesn’t. So I’ll use the ABS on my phone instead of Antennapod. ABS is missing some nice features common in good podcast players, but it works well enough for me.
I checked out ABS a while ago, but i t didn’t fit my needs. I don’t remember why, now, though. I’ll check it out again. Thanks.
I should add that I’m not sold on AntennaPod, Podfetch, and GPodder. I think AntennaPod is a great app and I hope I can use it to do what I want here. Podfetch seems nice, with room to grow in terms of features and Ux. GPodder seems pretty terrible (though I hardly know it) but also seems to be the defacto standard in syncing podcasts and play-states (or perhaps the only game in town?).
But I’d ditch any or all of them if I was able to sync podcasts and play-states between devices. My only caveat is that the solution needs to be FOSS and self-host-able.
Thanks!
I changed the VM’s CPU type in Proxmox and gave the VM more resources (most of the hosts’s RAM and CPU cores) and the delays cut in half to around 16 seconds. So I know what’s causing my delay (or probably most of it). I guess I need a beefier box.
Good questions. I haven’t talked to the assistant through the browser or phone yet -that’s a good way to help narrow down what process might be causing delay.
I’m running HAOS in proxmox on a mini PC with a celeron. A couple people have said they’re using beefy hardware, so I might need a new box.
I don’t yet know the range of these Echoes, but they seem to do a great job listening. They also have a speaker but it sounds super wuiet, not really useful. If I want a verbal response I’ll have to push it through other speakers via an automation.
Excellent troubleshooting tip. Thanks.
Good to know!I’m running HAOS on proxmox, too. I’ll look into CPU types.
create a separate key and provide that public key to keep it separate from your user account.
I agree this is a better method.
I’m having trouble figuring out which user or container HA is using to execute the shell command. I docker exec -it homeassistant /bin/bash
, ran ssh-keygen
, and copied the pubkey into gitea, but it had no effect. I tried to run ssh-keygen in the hassio-cli
container but ssh-keygen
isn’t installed (so my assumption is that this isn’t a container that would do something that might need a key, because HA didn’t pre-load ssh-keygen - maybe I’m wrong). When I docker inspect
the HA containers and grep for “User” or “UID”, there is no result.
So now I have a probably-related question: the script runs, but it won’t authenticate with my gitea repo:
stderr: "Host key verification failed.\r\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists."
returncode: 128
Again, when I run the script while ssh-ed into HAOS, it works fine. So I suspect that when HA runs the shell script (e.g., via Developer Tools or an Automation), it’s doing it as a different user, or perhaps from a different container from which I haven’t yet copied the pubkey into gitea. What do you think?
That did it. Thanks, @CondorWonder@lemmy.ca!
I had tried backup.sh
thinking HAOS might map the config
dir to /
, and I obviously tried /root/config/backup.sh
, but I didn’t try the middle ground. :)
Thanks for the explanation!
I intend to isolate the subnets once I figure out this issue.
I don’t understand static routes yet, but this sounds like a good way to go. I use pfsense.