

I don’t think I’ve ever heard strimmer, though it does seem to be a thing when I search it up. I would say Weed eater, weed whacker, or line trimmer.
I don’t think I’ve ever heard strimmer, though it does seem to be a thing when I search it up. I would say Weed eater, weed whacker, or line trimmer.
The back calls it “Tasty cheddar cheese”:
Other types of cheese are available, it’s just that cheddar is not clearly labeled as such since it’s kind of the “default”.
E.g.
In NZ English… “Cheese”. Though we do have a term “tasty” for a 12-18 month aged cheddar cheese that I don’t think is commonly used elsewhere. At the supermarket you’re likely to see “mild” or “tasty” not “cheddar”.
In Māori, “tīhi”. It’s a transliteration of “cheese” into a language that has neither a “ch” nor a “s” sound.
It says
As these installation methods are used for the development of Home Assistant, it will still be technically possible to update them. We still would recommend migrating to a supported method, but that’s your choice.
And then towards the end:
Will the developer documentation on these things remain?
Yes, those will remain. The developer documentation for running Home Assistant’s Core Python application directly in a Python virtual environment will remain. This is how we develop. This proposal is about removing end-user documentation and support.
How I read it is that these methods are actively used for development so will still be maintained and updated, including developer documentation because developers will continue to need to use these methods.
If you read the Home Assistant official announcement, it basically says all the different methods were confusing to new people so they will remove them from end user support documentation and won’t take support questions from people using these methods.
However, outside the deprecation of 32bit OSs (which they point out a large portion are on 64bit capable hardware), they are still going to be documenting the other methods in the developer documentation.
I honestly think this is the right move. Their time is being wasted by confusing new users, and supporting 32 bit OSs is literally preventing the development of new functionality. If you want to use a Python environment instead of docker, the developer documentation is there to support advanced users.
Everything is exposed through a reverse proxy. E.g. homeassistant.mydomain.nz
However, I have DNS rewriting set in Adguard that does *.mydomain.nz -> 192.168.1.XX
This means a) things don’t need to go external if I’m at home, and b) I have many things only accessible internally, which rely on this otherwise they won’t work at all.
It’s all HTTPS, I just use a cloudflare integration in Traefik to do the Let’s Encrypt validation for domains not accessible externally.
It’s an LLM that has access to run commands. It’s a major bug by design 😅. But it does do a decent job if I keep tweaking after thing kind of thing happens.
Without the LLM you have to phrase things very specifically, or it will say it doesn’t understand. With the LLM the kids can do things like ask for “the song that goes [lyrics here]” and it can play it. It’s a very cool thing to play with, e.g. “can you tell me what the weather will be like today, phrased as a haiku”, but it’s full of traps as well. I have a “Home Assistant Voice Preview”, the “Preview” bit is to make it clear this is not ready for the general public yet 🙂
P.S. if you’re wondering, the weather today:
Showers grace the sky,
Rain will fall, then clear away,
Gentle winds will sigh.
I have definitely done similar things. Now you mention it, I remember adding a hosts file entry for testing recently and can’t remember if I removed it. I just checked my laptop and two servers and didn’t find anything weird so now it’s gonna bug me.
Haha I guess I should be grateful for that, though I do host another dozen or more services at home so a lot of things broke!
Haha it’s a fine balance between preventing this sort of craziness and having a voice assistant that is actually useful because it can do things.
I want to figure out how to disable these two voice commands, and how to completely disable turning off the smart plug my server rack uses.
In the settings->voice assistants page you can see exposed entities. Review them and remove anything you don’t want it to be able to control.
You can also set up custom commands as an automation. You could probably set up an automation trigger to pick up on the phrases you want to block and respond with “I’m sorry Dave, I’m afraid I can’t do that” (or something boring).
I think that setting has been there as long as I’ve had a voice assistant (since I got my HA Voice Preview in January). I knew it existed but I let it expose them. I probably shouldn’t, because I always have to review it after adding anything new since it normally doesn’t get what I wanted exposed/not exposed.
I’m surprised it didn’t turn off the voice assistant. It does have the ability to mute itself (for when the kids are using it when they are supposed to be doing something else or are just generally annoying).
Ok thanks, I’ll have to be extra careful deploying any changes.
Thanks! I did see there’s a docker format and a podman format which I assume is what this difference is about. I’m not against discord but I’ve never really used it. I’ll check it out if I get desperate 🙂
Thanks, I had already played a bit with distrobox and hadn’t worked that out either. It seems adding a Z flag to my bind mount to keep SELinux happy is all that was needed.
I seem to have got it working using podman, adding a Z flag to the bind mount to make SELinux happy.
Oh shit I think that’s it! I’ve added that Z flag to each bind mount declaration in compose.yaml, and it seems to be running properly now. Thanks!
Any idea what the implications are of this transferring to an ubuntu based distro?
Can you really? Your internal body temp? Around 37C or under 100F? I can’t find any sous vide recipes that low. I can’t find anything under 50C, which would kill you if it was your internal body temperature.