Curious, why would one use this one instead of official app?

What they don't mention is most of the 60GHz sensors only have a range of 2m, and an angle range of 60°, meaning it is tough to get full room coverage for living rooms or more open floor plans where the 6-8m range of 24GHz helps a lot.

In general, using cloud stuff for smart home is just a poor experience anyway (latency, outages, etc), so many avoid it already.

Edit: agree with other reply, just buy esp32 based sensors from Ali.

Yah, potential privacy nightmare, but super useful. A quick look on Ali turned this up, which uses ESPHome (open source) firmware for < $AU50. As long as it's in an internet disconnected IoT WLAN network (you do have one of those, right?) I see little risk. The risk will come with phone app enabled crapware versions that are incoming right now I expect.

I actually have a 24Ghz version waiting to be connected to an ESP32 in my to be done drawer, but I may well leapfrog it and grab this instead.

So, basically, if you are sending your sensor data to random cloud APIs, vendors can track your exact position at any time. Combined with different sensors, they can probably track most of your daily habits and pipe you ads for whatever it is you are doing at that moment through audio, TV or phone ads.

It's a phased array radar and that can actively scan a room, ffs. If the sensors are on a 2D grid, say, like a 16x16 array, the radar beam can be pointed in just about any direction.

Keep that data private, or don't use it at all. It absolutely isn't video camera quality, but it doesn't need to be.

This is super cool stuff though. If used properly and privately, the possibilities are endless for home security and home automation. Just don't hand the controls to someone else and pay a monthly fee so they can.

Pretty much every ZigBee hub will lock out third party devices, because due to how ZigBee works, either you need to provide a raw API to endpoints (which can be dangerous for the average person), or carry the device definitions yourself (some of those are covered by the standard Zigbee endpoint assignments per spec, but not all manufacturers follow them, many extend them - looking at you, Philips - or completely ignore them).

Allowing third party devices is also a security and stability risk. A good example would be the handful of cheap Tuya presence sensors based on cheap 5/16/24GHz mmWave radar tech. They're really inexpensive, small, and work over ZigBee. Awesome, right? Well, no. They literally spam the network with unnecessary updates. A single one of those was responsible for ~30% of all messages on my ZigBee mesh of over 30 devices. It literally sent as many messages as ~14 other devices (many of them relays, this Tuya sensor is endpoint).

Now imagine if Aqara allowed their hubs to connect with any ZigBee device. Imagine if someone bought a dozen of these presence sensors and installed them... And the ZigBee network immediately became so overloaded that a simple light switch event takes minutes to trigger. People would be upset with Aqara, not the manufacturer of the sensor.

Simply said it's easier to exclude third parties for sake of user experience that can be guaranteed.

However that doesn't mean Aqara isn't shitty about ZigBee. Most of their non-hub devices for example simply refuse to join other ZigBee networks because they use a proprietary pairing method that first talks to the device, phone, and hub via Bluetooth, exchange pairing keys and only then will it allow pairing between device and hub. And of course the phone app won't let you add a third party hub to do this with, so any Aqara ZigBee device that uses this approach (e.g. their T2 bulbs) won't work with third party Zigbee hubs.

(Fortunately the T2 is a dual mode bulb that can use Matter over Thread which I opted for in my installs)

This would be cool but my car doesn't have an ODB II port

Dubious open-source practices on the part of Ollama devs. Other than that, LM Studio is using the latest stable llama.cpp rather than the one developed by Ollama, which brings significant speed improvements. You also have a better understanding of what model you're deploying by not using Ollama, and instead looking into the HF repository. For example, Ollama states that they're serving DeepSeek-R1, but pulling this one gives you a distilled 8B billion version that is not actually the DeepSeek-R1 (671B parameters) that one would have expected.

I get it that it might make it easier to use, but you will not learn much by using it. Even worse, competition is even better with performance and similar out-of-the-box capabilities.

Why is it better?

Integrate a rear facing camera. Might help you to look back /s

That was an interesting read. I've been against personal assistants/smarthome/etc., but your comment might have brought me around. Thank you for sharing your setup.

Thanks. I saved your comment to look into this. Running a local Alexa is a dream of mine.

https://community.home-assistant.io/t/local-llm-for-dummies/769407 For the llm part

https://www.home-assistant.io/voice_control/voice_remote_local_assistant/ For the speech transcription part

VRAM is more important. If the model can fit in vram a slower gpu is workable. Gpu determines speed of token generation but if model is too big for vram and is partially offloaded to ram/cpu performance drops considerably. A 13 billion parameter llm will run significantly better on a slower gpu with 12gb vram than a faster gpu with 6gb. 7B models are pretty capable (6-8gb vram) but going to 13b (8-10gb) or 32b (20+ gb) are each a notably better improvement in capability though 32b is largely impractical for this use case (unless you don’t mind dropping $1300-$2500 on a 24gb 3090 or 4090 and paying to power it)

This was the greatest thing for my home.

Privacy concerns abound with google/amazon/apple obviously but the bigger thing from a day to day perspective was the lack of control

I used siri for awhile and it was frustrating because it lagged behind tremendously. I tried alexa and google at friends and families houses and while they were notably better they were still awful. Ads were obviously the worst part, with Alexa especially there was so much fluff to try and sell shit. A voice assistant should be as unobtrusive as possible and the second it says extra bullshit it’s doing a shitty job. Poor query handling happened with all three to varying degrees but the worse issue was not having queries locally processed.

This meant 3 major deal breaking issues: the assistants needed a constant internet connection (so outages meant your “smart” home was now objectively worse than before), the internet connection was a key factor so if there was bandwidth saturation, dns issues, etc latency would notably increase or timeout query processing, and because the processing is server sided and not controlled by you query response can suddenly change: where a macro would work one day and stop the next or asking a question might work one day and then not next week.

With whisper and qwen I am entirely local and have control of the entire process. If a query is processed poorly or not at all I can create intent scripts to shift the behavior as I please. I can have the entire smart home cordoned into an isolated vlan or separate switch with only intranet access so the possibly of data collection is impossible and external intrusion is extremely unlikely. I can bridge key components around this with something like headscale so I can still check my cameras or whatever remotely.

It’s not all roses: the latency can still occur depending on demand and hardware. If you’re like me and have 100+ entities that the llm can interact with things can slow down a bit. VRAM matters more than gpu in my experience. The speech transcription is fairly lightweight and can occur in sub 1 second timing but the query processing can take a few moments if hardware isn’t beefy enough. This also means a server that is more of a power hog, sometimes significantly so (relative to something like an rpi4).

Biggest hurdle is that because it is so controllable, so open, and relatively new setup can be a pain. There are several guides on github and the HA forums that are very helpful, but this is definitely in the space of “tinkerer who is comfortable with yaml and docker”. Additionally the other parts of the hardware can be a pain. Where in other ecosystems you can just spend $80-100 on an echo or homepod or whatever here you have to figure out a speaker and microphone. This can be very cheap (literally an esp32 with a cheap mic and speaker attached) but this typically doesn’t give you the “smart speaker” functionality which can be nice to have. If you like the idea of music wherever in your house those devices have really improved the concept of “multi room audio”, which can be an absurdly expensive nightmare otherwise.

The other pain point is that if you truly want local only for iot devices you either have to accept that there will be some unknowns (mainly new and time sensitive data, eg “what was the score of the game”, stock prices, etc) or use another system as a bridge to run something like searxng then set it up so that the llm invokes this bridge upon unknowns. This adds several seconds of latency but honestly 95% of queries exist within the LLMs model so asking for general info is usually entirely local (eg “who wrote flowers for algernon”)

I know there can be a lot of hate for smarthome stuff, which is often justified, but if you set it up correctly there’s no internet access and it just kind of works. With presence sensors I don’t even do much voice command of devices. Lighting and hvac are all automated. The voice stuff is for incidentals: playing music, searching for info, setting timers, etc. it’s handy most of the time and it’s especially helpful when my hands are full, when my elderly family members visit, when I’m working on something and can’t move away to adjust lighting, etc. but it is frivolous for sure

Don't use Ollama. If you're on Windows, better try LM Studio and look into HuggingFace models rather than relying on the Ollama repository. Much better.

Local LLM hardware requirements highly depends on the model. You should try out Ollama and see which models work well on whatever hardware you're testing it on.

You will want to look up what quantized models are too.

My smoke detectors don't need metrics. They don't need an app. They just need to indicate the battery is low, without squawking at full volume every thirty seconds at four in the goddamn morning.

I am most interested in how to set up and integrate the local LLM for this, particularly the hardware requirements. Sadly, the article doesn't have any details on that.

Ive got 3 google nests that are gathering dust. The electrical connection is not standard. I moved house and now cant usw them. Google washed their hands of it as they have declared them obsolete. Its a $2 plastic part. They have done similar with other hardware and software before. Ill never buy another googke product.

Might as well. It’s not like google is making these anymore.

It’s a shame the part that expires isn’t just a module that can be swapped/replaced.

Hell yeah. Love HomeAssistant even without the LLM. Local control forever.

This article doesn't tell you how to do anything. It just says buy an rs232 adaptor and search github. Totally useless.

HD video feed via RS/232? Dream on kids

So good to see the industry - as in, the ones actually interested in producing useful long-term kit, not just data-slurping slop - supporting Home Assistant. Ubisys kit already works really well so this is a no-brainer.

This is great news, and they have some cool products to boot, namely the heating regulator which seems like a good replacement for the discontinued shelly TRV (which was also way more expensive)