u/CrazyHa1f

▲ 1 r/homeautomation+1 crossposts

Thinking about setting up Home Assistant... sanity check on hardware, Tapo local control, and wall panel use case

Long-time self-hoster, first time seriously looking at Home Assistant. I've got a home server running Ubuntu 24.04 with a Docker stack (Emby, Sonarr/Radarr, Calibre-Web, etc.) and a segregated IoT VLAN already in place to protect my decides from IoT crappy security. Before I dive in I'd like a sense check from people who've actually done this...

My hardware

I've got a Dell OptiPlex 3000 SFF (i5-12500, 8GB RAM) running as my main home server with a full Docker stack on it. I also have a couple of spare Raspberry Pi 3Bs gathering dust.

I've been told that getting Home Assistant working in Docker can be a challenge. My understanding is that this specifically refers to the Supervised install method, which has strict OS-level dependencies and is notoriously fragile on non-standard setups... and that HA Container (standard Docker image, no add-ons supervisor) sidesteps all of that and works fine for anyone who just needs integrations rather than add-ons.

Is that right? Is there any meaningful reason to run HA on dedicated hardware (like a Pi or an official HA Yellow/Green) if I don't need the Supervisor/add-ons ecosystem? Are there major issues with HA Container that I'm not aware of?

My current thinking is: run HA Container on the main server, use the Pi 3Bs purely as kiosk display terminals (Raspberry Pi OS Lite + Chromium in kiosk mode pointing at the HA dashboard). Does this make sense, or is a Pi 3B too underpowered even for that?

Tapo devices local control and reliability

My whole motivation for this is that my Tapo kit drops offline every time there's an internet blip. I have a fairly large spread of it:

P100 and P110 smart plugs

L510 and L430C bulbs

H200 hub

C560WS camera

D100C doorbell

Two Alexa Echo devices (not Tapo but on the same segregated IoT VLAN)

I understand there's a native Tapo integration in HA that supports local control via the KLAP protocol, and that once configured the devices work without cloud dependency. Is this actually reliable in practice? Any devices in that list that are known to be problematic or unsupported locally?

I'm specifically keen to avoid replacing everything with Zigbee or another protocol... I'd rather make what I have work properly first. Is that realistic, or do people find Tapo local control still flaky even through HA?

Wall panels

The main thing I want to build is a Pi-powered kitchen wall terminal that my partner can use.

Ideally I'd want it to do:

- Full control of all smart home devices (Tapo plugs, bulbs, etc.)

- Multi-room music control. I have a WiiM Pro on the network; I understand there's a WiiM integration in HA. How good is it in practice? Can you group rooms and control playback properly from a Lovelace dashboard?

-Access to my Emby media server and live TV channels (running ErsatzTV, fed into Emby as Live TV)

- I'd want to expand to smaller terminals in each room over time, all pointing at the same HA instance.

- Is inline media playback (Emby, live TV) within a Lovelace dashboard actually usable, or is it the kind of thing that sounds good on paper and is a bit crap in practice? Would it be more realistic to have dashboard buttons that launch Emby in a separate browser tab?

Network issue I'm aware of...

My IoT devices are on a segregated VLAN (192.168.20.0/24) and the server is on the main LAN (192.168.8.10). Currently the only rule allowing VLAN 20 traffic to reach the server is on port 8096 (Emby). HA will need to initiate connections to the IoT VLAN to poll devices, which means I'll need a firewall rule allowing that. Planning to sort this before setup... any other cross-VLAN networking considerations I should be aware of with HA?

Appreciate any input, especially from people running HA Container rather than HAOS, and anyone with a Tapo-heavy setup.

reddit.com
u/CrazyHa1f — 4 days ago

New player, returning flight sim fan, worth buying a joystick or just use my Xbox controller? Head tracking advice too

Hey all, just picked up Nuclear Option after years of wanting to get back into flight sims. Last time I played anything like this was as a kid with a cheap joystick. Loved it then, but DCS always seemed too steep a learning curve (especially for someone with a full-time job!) and Ace Combat too arcade-y, so this game feels like a perfect middle ground.

A couple of questions before I invest in any hardware:

Joystick vs controller vs keyboard and mouse

I've got an Xbox controller and I'm comfortable with mouse and keyboard. Is it actually worth buying a joystick for this game, or is that overkill? I've seen a few people mention the Thrustmaster T16000M as a good entry-level option, but I've also read that some people with full HOTAS setups have gone back to using a controller because the game doesn't really need it. Don't want to spend £50-60 on something that doesn't actually improve the experience. What do you genuinely think?

Head tracking on a budget

I've looked at TrackIR, but £100 feels like a lot to spend before I even know if I'll stick with the game. Are there any decent free or cheap alternatives? I'm on Android not iOS, so the iPhone camera-based apps aren't an option for me. I've come across OpenTrack but not sure what the best input method is without spending much. Any setups you'd actually recommend from experience?

Any other tips for someone just starting out would be appreciated. Cheers

reddit.com
u/CrazyHa1f — 15 days ago

Posting this because I nearly missed it entirely and I think people should know about it.

I was doing some maintenance on my NAS, migrating from SMB to NFS, and while SSHing around to find the NFS export path, I noticed two suspicious entries in the shared folder user permissions list. They weren't usernames. They were shell commands.

How it got in

My TOS web UI had been exposed to the internet for a while before I got WireGuard set up (tnas.online). At some point, an automated scanner found it and exploited a command injection vulnerability in the shared folder permissions UI. TOS doesn't sanitise input in the username fields, so the attacker submitted shell commands as fake usernames and the backend executed them when applying the permission configuration.

Two injections were used. The first staged a ransomware binary at `/mnt/te` and an RSA public key at `/mnt/public.key`. The second wrote a PHP file upload web shell to `/usr/www/upp.php`.

How it was designed to work

The binary (`/mnt/te`) was a statically linked, stripped ELF. Strings inside suggest ransomware: Chacha20 key expansion constants, RSA/decryption references, "decryption error" strings. The RSA public key would have been used to encrypt a symmetric key, making decryption impossible without paying. The web shell was the persistence mechanism. It accepts POST requests to write arbitrary files anywhere under `/mnt/` with optional chmod, so the attacker could upload new payloads whenever they wanted.

Why it failed

The binary is x86-64. The F2-210 is aarch64. It cannot execute on this hardware. That's the only reason the NAS wasn't encrypted. The web shell also had no hits in the nginx access logs, so it was never called either, probably because the binary failing meant there was nothing to follow up with.

What I found

- `/mnt/te` - ransomware binary (1.1MB, x86-64 ELF)

- `/mnt/public.key` - 4096-bit RSA public key

- `/usr/www/upp.php` - PHP file upload web shell

- Two malicious rows in `/etc/base/nasdb` (the TOS SQLite config database) injected as fake usernames

How to clean it up if you find the same thing

Deleting the fake users through the TOS UI doesn't work. They come back on every reboot because TOS regenerates its config from the SQLite database at startup. You have to delete them directly via SSH:

```bash

sudo sqlite3 /etc/base/nasdb "DELETE FROM user_table WHERE username='[malicious entry]';"

```

Then delete the binary, public key, and web shell manually, and confirm they're gone after a reboot.

The obvious bit

Don't expose your TOS web UI to the internet. TOS 4 is a 2019 Linux 4.4 kernel and will never get security patches. This vulnerability almost certainly still exists. If you need remote access, put it behind WireGuard or a VPN first.

I'm on TOS 4.2.44, but this looks like a fundamental input sanitisation failure that's probably been there for years, so I wouldn't assume newer TOS 4 versions are safe.

Is there anything else I should be doing?

I think I've got everything, but happy to be told otherwise. Data appears intact, no evidence of lateral movement, SSH logs on my main server look clean. My main worry is whether there are persistence mechanisms I haven't found. The database and filesystem checks came back clean, but this is a black-box proprietary OS and I'm not a security professional.

Happy to share more details if useful.

reddit.com
u/CrazyHa1f — 1 month ago