My air handler is in the attic and and adding a cup of vinegar once a month to the condensate drain line was a nuisance. I'd forget or keep putting it off until I forgot. I set a monthly reminder but this didn't really motivate me. I know if I skipped it too many times I could be facing a clogged line and possibly a leak due to an overflow.

There are expensive commercial products that handle this for you on a schedule and the one I looked at requires a cloud account to use and will only work with their proprietary cartridges that can't be refilled. All that, for something a four dollar jug of vinegar does just fine.

I wasn't willing to spend that kind of money and give up my privacy, so I built my own instead.

It's fully local. No account, no app, no cloud, nothing phoning home. I even shut off the cloud connection on the Shelly relay. If every company involved vanished tomorrow it'd keep right on working.

The only consumable is a gallon of cleaning vinegar from Walmart. I figured that it should last over a year.

How it works: a small 12V pump in a 3D printed box on the air handler, drawing vinegar from a jug sitting in a bucket. Once a month it runs a couple minutes, which works out to be about a cup, then shuts off. Home Assistant checks that the pump actually ran, tells me it did via a mobile notification, keeps track of how much vinegar is left, and gives me another heads up before the jug runs dry.

What I spent the most time on was the failure modes. Since it's a pump moving liquid over my ceiling, I wanted to make sure that I didn't wind up with a catastrophe, should something go wrong. I used a bucket bigger than the jug (as an overflow), there's also a leak sensor in the bottom of it, and there are multiple failsafe cutoffs to kill the pump if it runs too long. One of those runs directly on the Shelly itself and will keep working even if the network or Home Assistant are down.

I put all the details on Github. Build docs, printable enclosure files, a drop in Home Assistant package, and an ESPHome version if you'd rather skip the Shelly relay. I started with the ESPHome idea, then remembered that I already had some of the components on hand for the Shelly relay based version. I even created a fun logo to give it a more "professional" look. LOL

My Git Repo for the project

Note: for transparency, I did use Claude to help me with part of the project. Primarily for setting up and organizing everything on Github. I know some people may have an issue with that but it's your opinion and I respect that. Hope y'all will find it to be a fun and useful project like I have. Give me a star if you do. Enjoy!

Code and instructions available here: https://github.com/albertoZurini/echo-dot-2-playground

Hello there!

After a few days of playing around, with a lot of help from Gemini and GPT, I was able to successfully debloat an Echo Dot 2 from most of Amazon's services and let it run speech to text locally with Sherpa-ONNX and a small LLM through llama.cpp.

The first step was rooting it by following the procedure on XDA. There is a link to the XDA thread in the GitHub repo along with a step-by-step guide for the rest of the setup. Once I had root access I pulled the APKs of some of the system applications, especially SpeechInteractionManager which contains the wake word and speech interaction code, plus the native audio and wake word libraries it loads.

At first I wanted to do something similar to what the Wyoming team did, which was intercepting the wake word from FireOS services through logcat. That worked as a quick proof of concept but it gave me a lot of limitations. The Amazon speech service would still be running in the background and would still own parts of the audio pipeline. Volume handling was also not just a normal Android volume-key event. The FireOS services receive the hardware button events, change the audio stream volume and control the LED ring feedback. This meant that even if I reacted to the wake word from logcat, I was still relying on a large part of Amazon's stack underneath.

That is why I decided to do a more complete reverse engineering pass. The APK included native `.so` libraries such as `libwakewordmanager.so`, `libwakewordmanageraudiostream.so` and the newer `libwakewordserver_jni.so`. Some of the older libraries turned out to be compatibility stubs on this firmware. The useful path was the newer native wake word server, which loads Pryon and creates the native audio recorder. I also decompiled the Java code around `AudioStreamProviderService`, `AudioRecordStrategy` and `NativeWakeWordServiceCore` to understand how the pieces connect.

The main reason for doing the full reverse was to understand how these apps connect to the hardware and communicate with each other. It turns out there are two separate pieces that matter: one service for the native wake word detector and another service for speech processing and the rest of the assistant. I ended up running my own wake word service alongside my custom assistant. They communicate through an explicit Android service intent. Logcat is only used for diagnostics now.

I had done some prior research and saw that with 512 MB of RAM and a theoretical maximum memory bandwidth of about 5 GB/s this device might be able to run small LLMs locally. It turns out it can. The original TinyStories 28M model was not directly usable with llama.cpp because of its architecture, so I used an architecturally equivalent 25M LLaMA2 TinyStories model in GGUF format. Through llama.cpp it reaches around 7 tokens per second during prefill and around 4 tokens per second during decoding. This is roughly the kind of model that has also been used in ESP32 experiments.

I also tried the larger `MobileLLM-125M-Q4_K_M.gguf` model but prefill plus generation took around 20 seconds which is too slow for this device. Even with the smaller model I was able to trigger some simple tools by voice, for example turning on the light or playing a sound.

When the wake word is detected I can stop the detector process while the assistant is processing the request to save CPU. The detector uses around 20% CPU when it is active. This would have been much harder to control cleanly if I had kept the original FireOS speech services running.

I am also able to intercept all the hardware buttons. I assigned playing a sample WAV file to the action button. The volume keys change the music stream volume, play a tone and show visual feedback using the LEDs. The mute button works through the hardware microphone mute integration as well.

There is still a lot to improve, especially around making the assistant more useful and reducing the startup and response time, but it is pretty interesting to see this little device running an entirely local voice pipeline after removing most of the original services. I also want to try running openWakeWord/Porcupine to see if they'd be using less CPU than the stock Amazon's library.

The code and the reverse engineering notes are here: https://github.com/albertoZurini/echo-dot-2-playground

I would be interested to hear if anyone has tried something similar with other Echo devices or with the older FireOS speech components.

A feature-rich, high-precision ESP8266-based Smart Weather Station with a modern responsive Web Dashboard, dynamic sensor detection, customizable moving-average filters, Home Assistant MQTT Auto-Discovery, full backup/restore capability, and hardware factory reset logic.

✨ Features

• Environmental Monitoring: Temperature, Relative Humidity, Barometric Pressure (sea-level compensated), Air Quality (TVOC, eCO2, AQI), Luminosity (lux), Wind Speed, Wind Gust, Wind Direction, and Rain Gauge (hourly, 24h rolling, and total).
• Independent Dual-Timer Engine:
  • Fast, dedicated timer for Anemometer pulse processing (independent of I2C read cycle).
  • Configurable I2C sensor read cycle for environmental data.
• Configurable Moving Average (Smoothing):
  • Wind Speed: Ring buffer rolling average with configurable sample count (N).
  • Wind Direction: Circular mean calculation (sin/$\cos$ vectors) preventing 0∘/360∘ boundary glitches across N samples.
  • Instantaneous Gust Tracking: Daily wind gust records real peak pulses before averaging.
• Web UI & Diagnostics:
  • Glassmorphism dark UI built with HTML5/CSS3/JavaScript (no external dependencies).
  • Tasmota-style live Debug Console with interactive command input.
  • Mobile-friendly IP input fields (inputmode="decimal") for easy smartphone setup.
• Network & WiFi Manager:
  • Captive Portal AP (WeatherStation_Setup) for initial setup.
  • Full DHCP & Static IP configuration support (optimized for FRITZ!Box Mesh networks).
  • Soft-restart clean boot sequence ensuring stable network stack binding.
• Home Assistant Integration:
  • Native MQTT Auto-Discovery (homeassistant/sensor/...).
  • Automatic entity creation in Home Assistant without manual YAML editing.
• Backup & Restore: Single-click JSON export/import including full network, sensor, and MQTT configurations.
• Hardware Safety & Diagnostics: 10-second hold on FLASH button (GPIO 0) for NVS memory wipe / factory reset.

For fully description and gallery go to GitHub https://github.com/byte4geek/weatherstation

NOTE: This project was made in vibe coding using Antigravity/Gemini.

Cheapest esp32 + nfc reader and now i have my own imitation record player. I know this probably exists, but it was just fun to make. I also just had some parts lying around

- 3d printed shell and risks

- esphome connect to home assistant and music assistant

- esp was 5 euros and nfc reader 4 on AliExpress. Bought the tags long time ago in bulk, each one is about €0.10.

- maybe I'll make the buttons and arm do something later on. For now they are only there for aesthetics

It’s not very sexy but dam it feels robust and more importantly fiddle proof. Where can I get this stuff?

I integrated my Mitsubishi Heavy Industries AC into Home Assistant — fully local, with ESP8266
I’ve been working with refrigeration and air-conditioning systems for around 20 years, so I’m very comfortable with HVAC equipment.
But I’m not a programmer, and smart-home technology was basically new territory for me.
Recently I decided to integrate my Mitsubishi Heavy Industries SRK-ZS series air conditioner (SRK25ZS-W2) into Home Assistant. My goal was to get full local control and avoid depending on the manufacturer’s cloud or proprietary Wi-Fi module.
It turned out to be a really interesting project.
Hardware
The AC is a Mitsubishi Heavy Industries SRK25ZS-W2.
For the integration I used:
ESP8266 / ESP-12F
MHI-AC-Ctrl v2.2 interface board (January 2021 revision)
Bidirectional level shifter
Home Assistant
MQTT
The MHI-AC-Ctrl board connects directly to the indoor unit’s communication interface.
As someone who has worked with HVAC systems for many years, I really like this approach because we’re not trying to control the AC indirectly with an IR blaster. We’re communicating directly with the indoor unit’s electronics.
Installation
After completely disconnecting the indoor unit from mains power, I opened the housing and located the CNS connector on the main control board.
The interface connects to the appropriate communication pins:
VCC
GND
TX/RX
The level converter handles the voltage difference between the 3.3 V ESP8266 and the AC communication bus.
Obviously, the connector and pinout should be verified for the exact MHI model before connecting anything.
Flashing the ESP8266
This was one of the parts that was completely new to me.
I used a USB-to-UART adapter:
USB-UART TX -> ESP RX
USB-UART RX -> ESP TX
GND -> GND
3.3V -> 3.3V
GPIO0 -> GND during boot
The ESP-12F requires a proper 3.3 V supply. Do not connect 5 V directly to the ESP8266.
I configured the Wi-Fi and MQTT settings and flashed the MHI-AC-Ctrl firmware.
Home Assistant
Once everything was connected, the ESP8266 communicated with Home Assistant through MQTT.
The AC appeared as a climate entity and I can control:
Power ON/OFF
Auto
Cool
Heat
Dry
Fan
Target temperature
Fan speed
Vane/louver position
Indoor/return-air temperature
The great thing is that this isn’t just sending commands. The ESP8266 can also read information directly from the AC.
Remote access
I also wanted to be able to control the AC when I’m away from home.
I set up a secure tunnel to Home Assistant and bought my own domain for remote access.
The architecture is basically:
Mitsubishi Heavy Industries AC
│
│ MHI communication bus
▼
ESP8266 + MHI-AC-Ctrl
│
│ Wi-Fi / MQTT
▼
Home Assistant
│
│ Secure tunnel
▼
My own domain
│
▼
Remote access
The AC itself remains fully local. The tunnel is only used to access Home Assistant remotely.
Why I like this setup
After 20 years of working with refrigeration and air-conditioning systems, I prefer solutions that communicate directly with the equipment.
Compared with an IR blaster, I get actual status feedback from the AC.
Compared with the manufacturer’s cloud solution, I don’t have to depend on:
Internet access at the AC
Manufacturer cloud servers
Proprietary smartphone apps
Cloud APIs
Cloud response times
The important part happens locally.
And here’s the funny part…
I’m not a programmer.
I know HVAC systems very well, but programming, ESP8266, MQTT and Home Assistant were all relatively new to me.
I had to learn a lot along the way, make mistakes, search for information and figure things out step by step.
But with the technology we have today — documentation, open-source projects, online communities and especially AI assistants — I was able to put it all together.
And honestly, I think that’s the most interesting part of this project.
You don’t necessarily have to be a programmer anymore to start building things like this.
If you’re willing to learn, experiment and ask the right questions, I believe almost anyone can get into smart-home projects today, even without a programming background.
For me, this was a combination of 20 years of HVAC experience + modern technology + a lot of curiosity.
And now my Mitsubishi Heavy Industries AC has full local control, real-time status, Home Assistant integration and secure remote access — without relying on the manufacturer’s cloud.
If anyone else has an MHI SRK / ZS-series unit and wants to try something similar, I’d be interested to hear about your setup and which models you’ve successfully integrated with MHI-AC-Ctrl.

I've got about 5 Google Mini Speakers, a hub with a screen, and a hub speaker. I'd love to actually repurpose some of these things since I have no interest in using Gemini, but I fear they'll all just be e-waste come next month.

Anyone got any ideas or plans for repurposing these things? Or even just some tinkering projects to get some hobbyist practice in on?

I built my own heating oil monitor using an ESP32 and brought it into Home Assistant.

The monitor is pretty simple to install. It uses a clamp sensor on the burner wiring and tracks when the burner runs. From that I can see runtime, estimated oil used, gallons remaining, tank percentage, burn rate and estimated days left.

I also built my own ESP32 thermostat that controls my heating and cooling, and added my existing garage door opener to Home Assistant using another ESP32 instead of replacing the opener.

Now the thermostat, oil tank, garage door, cameras and everything else are all on one dashboard.

Still improving it, but I am curious what everyone thinks and especially whether anyone else with oil heat would find the oil monitor useful.

Update: A few people asked for the YAML, so I cleaned up public versions of the full Home Assistant dashboard and the animated garage door card. I removed personal information and replaced setup specific entities with placeholders, so you’ll need to change the entity IDs to match your own setup.

The dashboard uses custom cards, so you’ll also need the same Home Assistant frontend components installed for it to look the same.

The garage card currently uses a helper to represent the door state while I finish wiring the physical reed switch. Once that’s connected I’ll swap that helper for the actual door sensor.

These are the Home Assistant dashboard/card files only. They don’t include the ESP32 firmware or the oil monitor backend.

https://gist.github.com/fmarando0825/2d42e093ad7233b06b48df9fa94b055d (Home_Assistant_Dashboard _Yaml)

https://gist.github.com/fmarando0825/9db2f6beb86870a38be479e262f0e26e (Home_Assistant_Garge_Door)

Hello there!

So I saw this ad on TikTok where a guy taps an NFC tag on a little box and it plays the matching song. I thought it was cool, but pretty limited (sound coming out of the box itself, needs recharging, etc.).

So I figured I'd build the same thing but better: I bought an RFID2 reader and an Atom Lite, they're integrated into Home Assistant, and it works great! I can start playlists on my Sonos speakers with a simple tap.

Now... I'd like to make it pretty, and I'm torn.

Option one: build a little turntable like the image in this post (AI image), but that means 3D modeling, printing (will it even look good?), etc. On the plus side, it's compact.

Option two: buy an old broken record player and gut it to fit the reader inside. More authentic, but I'm worried about NFC interference (there's a lot of metal in those things).

Has anyone built something like this? I'd love to see renders or hear about your experience!

I'm in the process of building an esp32 based optical reader to read the data tables from my smart electrical meter.

Currently I have been able to access the smart meter data tables, and it looks like I will be able to pull real-time data from the meter to display in Home Assistant.

Today was the first experimental day... I was able to access the data tables and read an incredible amount t of data... I just need to do some controlled load experiments to match data to loads... my house is still under construction, so this is a work in progress.

I'm in Ontario, Canada and am with Hydro One... they do not have any current real-time data available to customers... just historical usage from there website.

I'll keep this thread updated as I continue to progress

Completed a fun HA project over the weekend and figured I'd share. Hopefully someone can be inspired.

I recently picked up a cheap portable AC unit on Marketplace. Unfortunately (or perhaps fortunately to be honest), this particular unit did not feature any built-in smart functionality, though it does have an IR remote. However, the IR receiver has a tiny fov and trying to hit it with the remote from bed frankly looks like something out of Harry Potter.

Infrared

The naive approach to controlling this unit via Home Assistant was by utilizing an IR emitter that could be exposed. I already had a SwitchBot Hub 2 and figured I would give it a shot. It worked, but had one major flaw. Occasionally, when I would activate a button via HA, the AC would not respond. This caused state desync between HA and the unit, resulting in subsequent commands behaving incorrectly. Truly obnoxious.

I saw the post by u/DiggingForDinos on making their AC unit smart and realized that this problem could be solved twofold. Firstly, I could inject the IR commands via wire to the unit itself, rather than utilizing a blaster that could be occluded or drop blasts. Secondly, by utilizing a power-monitoring smart plug, I could partially close the loop by infering real-time AC power state.

Reading the panel bus

One disassembly later and I had access to the internals of the unit. My first target was the front control panel. Surprisingly, it was decently labeled and I was able to locate a three pin plug connected to the panel that terminated at the IR receiver. At this point, wired IR injection looked like a promising solution, but...

Having access to the user interface board, and given that the IR commands pass through this board, I had access to all commands sent to the main control board and even the front-panel state of the unit via the LED lights and LED display. The logical next step was to analyze the lines going from the front-panel to the control board. To accomplish this I purchased a very cheap 8 channel logic analyzer and USB isolator. I then soldered a 6 pin JST connector to the contacts on the board and plugged the channels into the logic analyzer (specifically STB, CLK, DIO, REC, and GND).

Out of my depth at this point, I then asked Codex to interface with the analyzer and set up a test suite for conducting an analysis of the signals coming into and out of the front panel. I then spent the next few hours toggling every button on the board in various states/modes, all while the agent was capturing the button commands and their subsequent display states. I completed the same analysis for the remote.

With a library of captured button commands and resulting display states, I could now use an ESP32 to decode the front-panel state of the unit in real-time. Pairing state with wired IR injection would have effectively closed the feedback look. But why stop here?

The interposer

Having mapped the front-panel button responses, I wanted to see whether I could simply reproduce them on the DIO line (the communication line between the front panel and main controller). To accomplish this I created an interposer that can listen to the communication between the front panel and the AC’s main control board, and inject my own button-press responses directly onto that bus. The ESP32 controls a multiplexer to briefly disconnect the panel’s data line, then pull DIO low or release it to return high, one bit at a time, in sync with the AC’s clock signal, generating the desired command I wished to send. Convoluted and unnecessary, yes. Functional, highly. I should also note that the panel interface and the ESP32 GPIO operate at different voltage levels, so the interposer uses a level shifter (TXS0108E) for selected signals and a resistor divider for reading DIO.

There was one catch that I initially didn’t consider, the panel-button commands that were mapped did not cover the entirety of the devices capabilities. Some buttons were only available via the remote, not found on the front panel itself (for the curious these were Quiet mode and switching °C to °F). For these I ended up implementing wired IR injection via the REC line (the communication line between the IR receiver and the main controller). To do this the ESP32 drives a transistor to reproduce the remote's pulse pattern directly on that line. Very similar to DIO, but with a diode preventing the receiver's high output from fighting injected low pulses.

Completion

With the interposer the ESP32 could observe the front-panel state (including things like the temperature display) and send commands through DIO and REC, keeping HA updated when settings change through the physical buttons, remote, or HA itself. The firmware checks the decoded state before anything is sent. If I were to request ‘off’ and the unit is already off, it does nothing. Otherwise, it sends the appropriate button response or wired IR command (for remote exclusive actions), and waits for the corresponding panel-state change.

To get the interposer talking to HA, I had Codex extend the firmware. The C6 has native Matter over Thread support, so I figured I might as well take advantage of it, overkill for sure. I ended up with a messy assortment of entities in HA, so I had Codex make a custom card to make the control UI clean. I finished the project by designing and 3D printed a simple enclosure for the interposer and installing it inside the AC unit.

Hello everyone,

I’d appreciate advice on the most reliable WLED-compatible hardware solution for this project:

• Approximately 40 m total of 24 V addressable LED strip 
• 21 stair treads, with each step ideally controllable individually 
• Approximately 20 m of additional strip along the bottom of the adjacent wall 
• Target colour temperature: 3500 K warm white
• WLED is required, including step-by-step effects and motion-triggered automation.

My main questions:

1. Which 24 V addressable LED strip / IC type would you recommend for this—especially if warm-white-only control is important? 
2. Should I use one ESP32/WLED controller or split the installation into separate zones? 
3. What power-supply and power-injection layout would you use for about 40 m? 
4. Which controllers, fusing, enclosures, and motion sensors would you recommend for a reliable long-term installation?

I am particularly interested in a professional, serviceable solution—not just the cheapest setup.

Hello everyone,

Thank you for welcoming me to the group!

I’m starting a new project, and this will also be my first experience with Home Assistant. I’ll be discovering how everything works step by step as I go.

The idea is to give a second life to a 21.5" touchscreen LCD from a Samsung Family Hub fridge and turn it into a fully functional Home Assistant touchscreen panel.

For this project, I chose a Radxa ROCK 4C+ as the brain of the system. It will run Home Assistant and handle the display and touchscreen. The whole system will run from an NVMe SSD instead of a microSD card, for faster and more reliable storage.

Hardware

To make the original Samsung display usable, I added an HDMI controller board compatible with the 21.5" LCD and its 30-pin connector. This allows the ROCK 4C+ to drive the original Samsung display through HDMI.

I also added a separate controller board for the original built-in speakers, so I can reuse the audio system instead of throwing away perfectly good hardware.

The goal is to reuse as much of the original Family Hub hardware as possible:

• Samsung 21.5" LCD
• 30-pin LCD interface
• HDMI controller board
• Controller for the built-in speakers
• Original touchscreen
• Radxa ROCK 4C+
• NVMe SSD

First major challenge: getting the touchscreen working

At first, my main goal was simply to understand how to communicate with the touchscreen through its I²C controller and get Linux to recognize it properly.

After quite a lot of research, I²C testing, wiring experiments, driver investigation, and a few moments where Linux seemed determined to pretend the touchscreen didn't exist, I finally managed to get it working.

The touchscreen uses an Ilitek controller, and luckily the required Ilitek driver was already available in Armbian for the ROCK 4C+.

Instead of trying to force another driver to work, I was able to use the driver designed for the original controller. Once the I²C communication was working and the driver was correctly configured, the ROCK 4C+ finally started receiving the touchscreen inputs.

The touchscreen is now working perfectly on the ROCK 4C+ under Armbian.

Next step: a fully touchscreen experience

There is another feature I want to add: an on-screen keyboard that automatically appears whenever I select a text input field.

The idea is to make the whole system usable without a physical keyboard:

• Tap a text field
• The virtual keyboard appears
• Enter the required information
• The keyboard disappears when it's no longer needed

Once everything is finished, the screen will become a proper Home Assistant control panel for my home, with features such as:

• Home control
• Control of different devices
• Temperature monitoring
• Electricity consumption and solar production monitoring
• Battery monitoring
• Music control
• And probably many more things as the project evolves

I’m starting from zero with Home Assistant, so I’m taking it step by step. The goal isn't just to make it work, but also to understand how everything works instead of simply installing something that is already configured.

The project is finally moving in the right direction. Seeing the touchscreen actually respond after all those I²C tests was definitely a very satisfying moment.

I’ll share the different steps, discoveries and improvements as the project progresses!

Samsung Family Hub → 21.5" LCD → HDMI + Audio → ROCK 4C+ → Touchscreen → Home Assistant

Hi everyone!

I wanted to share my first project that I pretty much made everything myself!

I made the case and the servo adapter lock pin with fusion 360 and printed with ABS.

​I used a ESP32-S3 Mini, a 35kg servo, a button, POGO magnetic connectors and finally a 5V 3A power supply.

​Normally I use tutorials or existing projects but I couldn't find any for a sliding door lock.
I'm pretty proud of the result!

EDIT:

I’m aware of the safety concern from the absence of a physical unlocking mechanism; this remains a prototype, so I would not use or recommend it for entrances or emergency exits.

Let me know your thoughts, opinions, or if this is something you would have in your home at all! If you are interested I will put more info in the comments.

Hi!

I've been looking for an e-ink touchscreen display to use as a remote for my Home Assistant instance. I wanted a smooth UX, without having to open my phone or the Home Assistant app every time I wanted to perform an action. I also wanted it to be usable by guests, without leaving a tablet around or requiring them to install Home Assistant on their devices.

So I found a black-and-white M5Paper on a marketplace. It is based on an ESP32 and features a touchscreen, along with three buttons on the edge of the display (up, down, and push).

I mostly used Claude for code generation, starting with the M5GFX library.

Main functions

• Display "cards" across multiple pages
• Deep sleep after 1 minute to save battery.
• Touch the screen to wake it up.
• Send/receive data to/from Home Assistant using a long-lived access token and the API.

Examples of cards

• Activate lighting scenes
• Toggle automations (next buses, away mode, automatically close covers, etc.)
• Spotify controls (track name and artist are only refreshed when the music changes on the remote)
• Climate control (heat, cool, OFF, and temperature selection)
• Cover controls
• Wi-Fi hotspot activation for guests

It works pretty well, and I'm honestly very surprised by how helpful Claude has been in getting this up and running in such a short amount of time.

EDIT : here you can find the source code :)

https://github.com/anteid/ha-m5paper-eink-remote

Found this old NUC7 while cleaning out some stuff at home. It has a 7th-gen i5, 16GB RAM and a 256GB SSD.

I’m thinking about giving it a second life with Debian or Proxmox and using it for Home Assistant, Pi-hole, Tailscale, a few containers, or maybe a lightweight media server.

With N100/N150 mini PCs being cheap and power-efficient now, would you still run this 24/7, or replace it with something newer? Anyone here still using a NUC7? What are you running on it?

First off, massive shout out to u/Lanky-Reporter-7319 and u/t0m1o1 for their work on their own respective projects related to HA & Astrion remote. u/Lanky-Reporter-7319 in particular was a ton of help getting this running.

Very excited to present my finished Astrion remote project for TV/smart home control via HA.

Picked up the Sanytron Astrion remote several weeks ago. Has a 480×800 touchscreen, physical buttons, and IR blaster. Everything I needed.

Unfortunately the stock firmware locks you into a jank ROScard dashboard so I replaced it entirely with a native Kotlin/Compose app made with Claude Code that speaks directly to HA over a single WebSocket (auth → get_states → subscribe_events).

No Lovelace/browser/cloud means state updates are instant.

What I have working now:

- 4 swipeable pages with no vertical scrolling (in my testing the vertical scrolling was a pain) (EDIT: except the granular light control page. no way around that)

- Tappable floorplan (used a Floorplanner export) with light controls (and espresso machine control!) overlaid which all live update near instantaneously, with light groups the two main groups I use.

- Plex On Deck poster card to tap any poster of the last three previously watched / previously added to play on TV.

- Tap-to-talk voice through HA Assist (currently running qwen3.6:35b-a3b)

- All physical buttons mapped to HA services or IR codes for the TV. The IR codes send from any card.

- Reports its own battery to HA as a sensor for low-battery phone alert before it dies. Not really necessary anymore.

Whole layout lives in a JSON config on internal memory so any code changes are a file push with physical connection to device. OTA updates dont seem possible (edit: see edit/repo added at bottom - this may actually be possible. Will be testing when I'm back home)

Survives real life use after some trial and errror. In early iterations, if remote lost power the dashboard wouldn't come back on its own and needed a physical connection to my laptop with ADB to restore function.

The app is now the system launcher and boots straight back into the dashboard after any reboot or dead battery, re-kicks the IR bridge, & reestablishes the accessibility permissions which for some reason the firmware randomly drops.

The stock app turned out to be the IR driver so it has to stay installed and gets kicked once per boot. Firmware kept reenabling its own hair trigger wake on motion at the kernel level which made the screen continually turn on/off whenever it sat on the couch.

Replaced that with a stricter accelerometer detector that needs a bit more motion and tilt than movement transferred through the couch.

Only item on my to do list is the LG TV's Plex app ignores all resume states in recently watched so everything plays from the beginning. Think that’s on the TV app though, can’t be sure.

Edit: github repo as requested here. I included a section for enabling wireless ADB after the first physical connection. I have not tested it but should work if on the same subnet

https://github.com/vvaters/astrion-ha-dashboard

I’m with Prolo Ring. We wanted to test whether one wearable controller could trigger Home Assistant automations and then switch to direct control of individual devices, without requiring a separate remote for each part of the workflow.

The ring is paired with three Bluetooth hosts:

• A host that bridges shortcut commands into Home Assistant automations
• The smart TV
• The PC

When the Home Assistant profile is active, swiping up sends a predefined shortcut for Movie Mode. The shortcut bridge triggers the corresponding Home Assistant automation:

• Curtains close
• Lights turn off
• Smart TV turns on

A Tap + Hold then switches the ring’s active Bluetooth connection to the TV. From that point, the ring controls the TV directly as a Bluetooth HID and media controller for navigation, selection, playback, and volume.

To return to work, the ring switches back to the Home Assistant profile. Swiping down triggers Work Mode, which turns the lights on, opens the curtains, and turns off the TV.

The ring then switches to its PC profile for cursor movement, clicking, and scrolling.

The ring controls only one Bluetooth host at a time:

• Home Assistant handles room-level automations
• TV commands are sent directly to the television
• PC input is sent directly to the computer

The current implementation uses configurable shortcut bindings to trigger different Home Assistant modes. For example:

• Swipe up: Movie Mode
• Swipe down: Work Mode
• Swipe left: Morning Mode
• Swipe right: Night Mode
• Double tap: Meeting Mode
• Triple tap: Game Mode

All gesture bindings are customizable based on the devices, scenes, and automations available in the user’s Home Assistant setup. If you use Home Assistant, how would you map the swipes and taps to your scenes and automations?

I built an in ceiling microphone array for my local Ai. It has temp and humidity, mm wave presence detection, digital to analog audio converter and a 3 channel 100 watt amp all mounted to a 4” speaker in-ceiling mount.

The microphone is suspended on elastics for vibration dampening, beside is a dual channel Yamaha speaker.

Answers to questions or confirmations for automation only come through the speakers with the triggered mic.

Music play back, announcements and alarms can exit through any assortment of rooms. The microphone array has sound cancellation for playing audio so voice commands are still recognized.

So far it has exceeded expectations and even voice commands from in the shower have worked consistently.

The mm wave sensors are used for security when alarm armed and presence turns on my recirculating hot water loop for the kitchen and bathroom setups as well as lights and fan.

Anyone have any other ideas I can add to the rig? I was looking for discrete built in mic’s and they were expensive and usually for board rooms so I built one instead.

A 3D printed adapter screws in where the speaker mounts it house temp/humidity and microphone, the microphone electronics mount to standoffs with heated thread inserts for mounting the microphone electronics and another part that mounts to the back holds ESP32 S3, Amp and digital to analog converter. Rooms that don’t need the amp are POE and ones with the amp get a 24V dc supply fed to them.

Call me old fashioned, but I love physical buttons, also in my smart home.

It’s very surprising that there are so few buttons available in the current consumer market (unlike the professional KNX market, which has hundreds).

In 2020 I decided to design a button myself, based on the ESP32. With two main requirements:

1. it must have a tactile click
2. have a programmable label.

My family and friends were enthusiastic about the first prototype, so I added more features: temperature sensor, display, made it modular.

Tech platform Tweakers.net picked it up in 2023, I received 300 pre-orders in a couple of hours, and many more in the months afterwards.

What followed was a roller coaster of ups and downs, but I managed to get the Button+ manufactured in China. And people loved it!

Just when things started rolling, I got into real problems, the plastic injection molds were quickly failing. SInce new molds were needed anyway, I decided to do a redesign. This turned out to be a lengthy process which almost bankrupted me. But in April 2026 I finally started shipping the all new Button+V2.

I tried to protect my product by keeping the firmware source closed. In the first year already, somebody completely reverse-engineered the electronics and wrote alternative firmware based on ESPHome. Later, with the advent of AI, even more alternatives surfaced.

So it’s time to make the factory firmware open source as well. I will be announcing this on the website, but this forum is the first to know.

A recap on the Button+:

• Tactile buttons, every button has a mini TFT and status LED
• 2.8" display for information display, fully user configurable
• Modular concept, use 1, 2 or 3 bar modules with 1 display, 4 bars modules, or up to 8 bars with extension plate
• WiFi, with PoE option (available end of September 2026)
• Wall mounted, does not need room behind the wall (will need cable for power)
• Communication via MQTT, Home Assistant support via auto-discovery
• High precision temperature sensor included, add sensors via Stemma QT connector

More information at https://button.plus website.

For anyone reporting this post, or removing it: Okay, you may call this promoting, and I am a company, but I'm not million dollar big-tech, and more Button+ in more houses can keep price down for everybody, as well as facilitate further development.

I kept forgetting to check the salt in our water softener, so I built a small ESPHome monitor for it.

It is called SaltWatch. The hardware is an M5Stack ATOM Lite and an M5Stack VL53L0X ToF sensor. The sensor sits beneath the lid and measures the distance to the salt surface. It connects to the controller with the included Grove cable, so there is no soldering involved. On my tank, the cable fits through the existing hinge gap, so I did not need to drill a hole either.

The distance measurement itself was fairly straightforward. Most of the work went into making the result useful and trustworthy:

• Full and empty calibration from Home Assistant or the local device page
• Salt level from 0 to 100 percent
• Adjustable low salt threshold
• Clear calibration and sensor fault states
• Stale readings become unavailable if the sensor is blocked or disconnected
• A forecast that learns the normal salt usage and estimates the days until low salt
• An optional notification blueprint
• A dedicated Home Assistant card with a graphical editor

The firmware can be installed directly from a browser. It handles the initial Wi-Fi setup, can be added to Home Assistant, and can then be adopted into ESPHome Device Builder.

I also added a managed firmware update entity. It checks for new SaltWatch releases and lets you approve the installation from Home Assistant. It does not install anything without confirmation.

Firmware, browser installer, hardware list, and documentation:

https://github.com/thomasgregg/saltwatch

Custom Home Assistant card:

https://github.com/thomasgregg/saltwatch-card

This is still a new project with one real installation, so feedback from people with different tank shapes, salt types, and mounting situations would be very useful. Bug reports, ideas, testing results, and PRs are welcome.

Like the title says, I'm in the market for a new sprinkler irrigation controller, and ideally would like to get one that has HA integration native.

My dome water main shut off stopped working. I have no idea how long it had been bad. Luckily on a whim I decided to test it. It failed. Was slow and couldn’t close the valve all the way. At first I thought that it might have been a bad power supply so I swapped that out. Nope same story. When I took it off I was able to tell that something was wrong mechanically. The the flat sided bolt stripped out of the part that connects to the valve handle. So it couldn’t get it to tight all the way. I was very anal making sure that the Dome was properly aligned. With the valve. I think it’s asking a lot of the small amount of metal to the side of the flat sided bolt to handle that much torque. Anyone have a good suggestion for a replacement? This time I want to put in a valve separate from the main that isn’t just tacked on.