u/Internal-Shift-7931

I set up HA notifications to my IM through a small bridge, and now I’m trying to be more selective about what is actually worth sending. Motion alerts are easy to turn on, but after a while most of them become noise.

The alerts that seem more useful are things like:

- package delivered or package no longer visible

- person at the door

- pet doing something unusual

- garage / driveway motion only when nobody is home

- kids or family arriving home

- cameras or devices offline

- anything that uses context instead of just “motion detected”

For people using cameras with Home Assistant, which alerts did you actually keep long-term?And which ones did you turn off?

I think a lot of RLCD reviews are hard to compare because they skip the most important variable: the light. For RLCD, the light is part of the hardware experience. The same screen can look great near a window, okay under a desk lamp, weak under ceiling light, and basically useless in a dark room. So when a review says “too dark” or “surprisingly readable,” I always want to ask: under what light?

This is also where many arguments get weird. Two people can use the same device, both be honest, and still sound like they are describing different products. A useful RLCD review should probably include:

- ceiling light only

- desk lamp / reading lamp

- near a window

- outdoor shade

- direct sun

- night use

- viewing angle

- whether your hand or body blocks the light

- photos from the actual eye position, not only the best camera angle

A lux reading would be nice, but I don’t think it needs to be fancy. Even “small desk lamp on the left side” is already more useful than a perfect-looking photo with no context. My rough rule now: if an RLCD review does not describe the lighting, I treat it as incomplete. For people using RLCD devices daily, what lighting setup made the biggest difference for you?

I am trying to think through where local AI actually fits in home automation. I don’t really want another chatbot or dashboard. The useful version for me would be quiet and practical:

- home looks normal

- the garage has been open longer than usual

- something unusual happened near the front door after 6pm

- a visitor/access action needs confirmation

- nothing needs attention right now

Inputs could be normal home automation stuff:

- Home Assistant state

- camera / NVR events

- sensors

- door / garage / lock events

- local notes or household files

- event history

The hard part is deciding what should stay read-only, what can be suggested, and what needs confirmation. I would not want an LLM directly unlocking doors or changing security states. But I can imagine it summarizing state, finding weird patterns, explaining why something happened, or telling me when the house looks normal.

For people running local LLMs / Ollama / VLMs / Home Assistant: where would you actually put AI in the loop, and where would you keep it completely out?

I’ve been thinking about why RLCD reviews are often hard to compare. The screen is only half of the setup. The other half is the room. For a backlit tablet, lighting still matters, but the display brings its own light. With RLCD, a ceiling light, a desk lamp, a window, outdoor shade, and direct sun can make the same device feel very different.

So when someone says “too dark” or “surprisingly readable,” I think it would help to include the lighting condition. Nothing complicated. Just a few basics:

- indoor ceiling light only

- desk lamp / reading lamp

- near a window

- outdoor shade

- direct sun

- night use

- viewing angle

- whether your hand or body casts shadow on the screen

- photos from the real viewing position, not only the best camera angle

A lux reading would be useful if someone has one, but even a rough description is already much better than nothing.Without lighting context, two honest reviews can disagree and both still be useful. They are just hard to compare. For people here who own RLCD tablets or monitors: what lighting setup changed your opinion the most?

I got a GUNNIR B60 24GB card yesterday and asked for a test.

Test box:

• OS: HarborOS / Debian 13, kernel 6.18.13
• CPU: Ryzen 7 PRO 8845HS, 8C/16T
• RAM: 16GB DDR5-5600 installed, ~12GB visible to OS, no swap
• Boot SSD: 128GB NVMe
• Storage: 3x 500GB SATA HDDs / ZFS
• GPU: Intel Battlemage G21 / B60-class, 8086:e211, 24GiB VRAM
• Driver: Linux xe
• Firmware: GuC 70.65.0

Small PCIe note: lspci reports the GPU endpoint as Gen1 x1, but the upstream bridge reports PCIe 4.0 x8. I also measured SYCL host/device memcpy at ~14.3 GB/s both ways, so I think this is the known Intel Arc PCIe reporting issue, not a real x1 link.

LLM setup:

• Backend: llama.cpp SYCL
• Build: llama.cpp 9209 (0caf2a1d4), IntelLLVM 2025.3.3
• Model: unsloth/Qwen3.6-35B-A3B-GGUF
• Quant: UD-Q4_K_M
• Model file: ~21GB
• All layers on GPU
• Flash attention on
• KV cache: q4_0
• Warmup: 1 run
• Measured: 5 runs

Results:

Scenario	Prompt / Gen	Prefill	Decode	Peak VRAM
8K context	8192 / 1024	327.6 tok/s	50.95 tok/s	21.23 GiB
32K context	32768 / 512	285.0 tok/s	51.20 tok/s	21.76 GiB

The 8K decode result was stable, around 0.7% CV across 5 runs. I did not see CPU fallback.

I also tried image generation through OpenVINO GPU:

Model	Settings	Speed	Peak VRAM
SD 1.5 FP16 OV	512x512, 20 steps	0.883 sec/image	3.12 GiB
SDXL Base FP16 OV	1024x1024, 30 steps	7.14 sec/image	10.53 GiB

For a public reference line, I found an RTX 4090 llama.cpp CUDA result on a Qwen-family 35B-A3B Q4 model at 147.73 tok/s decode. My B60-class result is 50.95 tok/s, about 34.5% of that.

That ratio feels plausible from the hardware:

• B60 memory bandwidth: 456 GB/s
• RTX 4090 memory bandwidth: 1008 GB/s
• B60 INT8: 197 TOPS
• RTX 4090 INT8: 660.6 dense / 1321.2 sparse TOPS
• B60 has 160 XMX engines
• RTX 4090 has 512 Tensor Cores

So the card is not a 4090 replacement. But the 24GB VRAM is real, and it can run a useful 35B MoE Q4 model locally with long context.

I keep thinking RLCD is mostly a lighting problem. A lot of discussion compares it directly with e-ink or normal LCD, but the experience changes too much depending on where the device is used. Same panel, very different result:

- desk near a window

- office with weak ceiling light

- outdoor shade

- direct sun

- car dashboard

- bedside at night

- cafe table

- workshop / warehouse

That is why I don’t think “is RLCD good?” is a precise question.

For RLCD, I would rather see reviews describe the lighting condition first, then judge the device. Indoor room light, window light, outdoor shade, direct sun, frontlight on/off. Without that context, two users can both be telling the truth and still sound like they disagree.

The things I would want measured:

- readability under normal indoor light

- outdoor readability in shade vs direct sun

- frontlight quality

- cover glass reflection

- viewing angle

- color usefulness

- refresh rate in real apps

- battery life with and without frontlight

E-ink still makes more sense to me for pure long reading. Normal LCD still wins when you control the backlight and want strong color. RLCD seems more interesting when the environment already gives you light, and you want something closer to normal tablet behavior without staring into a bright emissive display all day.

It is a more cleaner way to explain reflective displays. A normal LCD or OLED screen is also a light source. You are not only looking at an image. You are looking at an image carried by light coming from the device itself. That is normal now, so we almost stop noticing it. Phone, tablet, laptop, monitor, TV:

the screen is the image surface and the lamp at the same time.

Reflective displays change that relationship. The image is still on the screen, but the light comes from the environment: sunlight, room light, desk lamp, window light.

The device stops adding its own backlight into the viewing path. During the day, this is a big deal. The same light that makes OLED/LCD harder to see can make reflective displays easier to see. At night, the tradeoff moves to the room.

If the room light is harsh, cold, or too bright, the experience will still be bad. If the light is warm, indirect, and low enough, it can feel much closer to reading paper.

RLCD does not solve every eye comfort problem. You still need good lighting, good contrast, reasonable text size, and breaks. But the screen no longer acts like a bright rectangle pushing light at you.

Blue light is not new. Daylight has always had a lot of blue light. The sky is blue. Human eyes and human sleep cycles evolved in a world where blue-rich light was normal during the day. So the interesting question is not: “Why does blue light exist?”

The better question is: “Why did blue light become a modern concern?” My current answer is simple: the light environment changed. For most of human history, blue-rich light mostly meant daytime. At night, light was usually fire, candles, oil lamps, and later incandescent bulbs. These are warm thermal light sources. They still contain some blue wavelengths, but the spectrum is heavily shifted toward warm light and infrared. Not efficient, but also not trying to recreate noon at 11 PM.

Fluorescent lighting was a transition step. It brought gas discharge and phosphors into offices and homes. People complained about flicker, harsh office lighting, glare, color quality, and fatigue. There could be blue content, especially in cooler lamps, but blue light was not yet the everyday consumer-level topic it is now.

LED changed the scale. Most white LEDs are not naturally white. A common design is basically:

blue LED + phosphor = white-looking light

This is a very good engineering tradeoff. LEDs are efficient, small, bright, cheap, durable, and easy to put everywhere. But that is exactly why the exposure model changed. Blue-rich artificial light became cheap and everywhere: ceiling lights, street lights, car headlights, offices, monitors, phones, tablets, TVs, laptops.

Then screens made it personal.

A normal LCD is not just an image surface. It has a backlight pushing light through the panel, and that backlight is usually LED-based. OLED is different, but it is still self-emissive. The pixels generate light directly. QD-OLED also depends heavily on blue emission and conversion. So the modern issue is not simply “blue light is dangerous.”

That is too simple. The issue is that we put blue-rich artificial light into devices, made those devices bright, held them close to our eyes, and used them at night for hours. That is a very different situation from daylight. This is also why I think reflective displays are interesting.

An RLCD is not magic. It is not “zero blue light” in every environment. If you use it under sunlight, sunlight has blue light. If you use it under a cold LED lamp, that lamp has blue light too. So the real benefit is not that blue light disappears.

The real benefit is that the screen stops being the lamp.

A normal screen is: image + built-in light source

An RLCD is closer to: image surface + environment light

That changes the architecture. At night, the lighting problem moves back to the room. You can choose warm light, lower brightness, and indirect illumination. During the day, the same reflective model works with the light that already exists.

This is why I think “blue-light-free” is not the right framing. Backlight-free is the cleaner claim.

It does not solve every eye comfort problem. You still need good lighting, reasonable brightness, and breaks. If you point a cold blue-rich LED lamp at it before bed, you are bringing the same problem back through the lamp. But the display architecture is different. The screen is no longer the light source.

That is the real change.

I’ve been thinking about local VLM/LLM pipelines for camera events, and I’m starting to think the frame-level alert model is not right abstraction. Most “AI camera” systems seem to optimize for immediate per-frame detection:

- person detected

- package detected

- unknown face

- motion zone triggered

That is useful, but it has low context. A single event like “unknown person appeared in the yard” often tells me less than a time-based pattern like: “An unknown person walked around the yard three times this afternoon.”

The second version contains more useful information. It has temporal context, repetition, location pattern, and intent-like signal. It is also much closer to the kind of thing a human would actually care about. This makes me wonder if local camera AI should be less about real-time frame alerts and more about accumulating event history locally, then letting an LLM/VLM reason over compressed evidence asynchronously. Something like:

- cheap local detection creates candidate events

- store snapshots/clips/metadata locally

- group events over time

- run a stronger model asynchronously on the grouped context

- push only when the pattern looks meaningful

- otherwise produce a daily summary / searchable history

This seems like a different tradeoff from both endpoints:

- compared with on-camera AI: less obsession with instant alerts, more temporal reasoning

- compared with cloud AI: better privacy, local evidence retention, lower cost

- compared with raw NVR: more semantic history, less manual review

The interesting part is that this might not require a huge model running in real time. A smaller local pipeline could collect and compress evidence, then a stronger model could reason over batches when latency does not matter. My guess is that a Qwen3.5 4B/9B-class model could be enough for the first-stage “describe/summarize/filter” pass, while a larger Qwen3.5 model or another stronger VLM could handle async review of grouped events.

But I haven’t benchmarked this workflow yet, and I’m not sure if the bottleneck is vision accuracy, temporal reasoning, or just building the right event memory.

Has anyone here experimented with this kind of temporal/event-memory approach for local VLMs?

I’m especially curious about:

- how to represent event history compactly

- whether snapshots + metadata are enough, or short clips are needed

- how to avoid hallucinating “intent”

- what models are good at summarizing repeated visual events

- whether async batch reasoning beats real-time per-frame classification in practice

I’ve been seeing a lot of AI camera marketing lately, and most of it seems focused on real-time notifications. Person detected. Pet detected. Car detected. Package detected. Familiar face. Unknown face. Motion zone. Line crossing.

Maybe it is technically impressive. But I keep thinking: smarter should probably mean more restraint, not more interruptions. Most camera events are not urgent. If I’m working, sleeping, driving, or in a meeting, I don’t need my phone buzzing because a delivery truck passed by or someone walked across the yard.

After enough “correct but not important” alerts, the obvious reaction is to mute the camera. Then the whole system becomes less useful. I think the better model is:

- daily summary for normal activity when we back home

- searchable event history

- local processing by default

- real-time push only for urgent events

- clear image/video evidence attached to every alert

- user-defined rules for what counts as urgent

I’d rather get: “Today: 3 package-like events, 12 front yard motion events, 2 unknown visitors, no unusual overnight activity.”

And only get interrupted immediately for things like:

- person at the door at 2 AM

- garage left open too long

- motion in a restricted area

- smoke / leak / alarm-like event

- camera offline when it should be online

A true alert can still be a bad alert if it doesn’t need my attention right now. Curious how other people handle this.

I am trying to build a local first home agent hub fully by Codex (no single line written by me).

The basic loop I'd build is:

- discover devices on the LAN

- start with RTSP/ONVIF cameras

- grab a snapshot or short stream

- run local AI detection/description first

- send the result to an IM/chat channel

- keep an audit trail so actions are not just “AI did something”

I’m intentionally trying to avoid the common “AI smart home hub” trap where it becomes a chatbot glued onto Home Assistant with no real reliability model. The parts I think matter most are:

- local-first by default, cloud only as fallback

- clear approval levels for actions

- All data saved safety

- device registry instead of hardcoded automations

- useful media artifacts, not just text summaries

- works even when the internet is down

For people who self-host home automation, cameras, media servers, or local AI: what would make this actually useful to you? And what would make you immediately dismiss it as another overhyped AI project?