nuxx.net Posts

Ever since getting my new monitor (a Dell U3225QE — a nice IPS LCD after some OLED issues) I’ve been having problems with it not going to sleep. But that’s not usually a monitor problem, especially as I could manually put it to sleep… So what’s keeping macOS from putting it to sleep?

Well, thankfully with pmset one can see what’s going on:

c0nsumer@mini ~ % pmset -g
System-wide power settings:
Currently in use:
standby 0
Sleep On Power Button 1
autorestart 0
powernap 1
networkoversleep 0
disksleep 10
sleep 0 (sleep prevented by backupd-helper, powerd, backupd, coreaudiod, coreaudiod)
ttyskeepawake 1
displaysleep 10 (display sleep prevented by CEPHtmlEngine)
tcpkeepalive 1
powermode 0
womp 1
c0nsumer@mini ~ %

There we go, seems CEPHtmlEngine is preventing the display from sleeping. So what is it?

c0nsumer@mini ~ % pmset -g assertions | grep CEPHtmlEngine
pid 15995(CEPHtmlEngine): [0x00038aae00059926] 46:44:27 NoDisplaySleepAssertion named: "Video Wake Lock"
c0nsumer@mini ~ % ps aux | grep 15995
c0nsumer 15995 3.4 0.1 412316000 64256 ?? R Sat08AM 128:30.24 /Applications/Adobe Illustrator 2025/Adobe Illustrator.app/Contents/MacOS/CEPHtmlEngine/CEPHtmlEngine.app/Contents/MacOS/CEPHtmlEngine b27716d6-c14c-49e4-8612-b5ab9de9bdf4 1103d4a0-8756-40b2-af81-5646ba80756f ILST 29.8.4 com.adobe.illustrator.OnBoarding 1 /Applications/Adobe Illustrator 2025/Adobe Illustrator.app/Contents/Required/CEP/extensions/com.adobe.illustrator.OnBoarding 32 e30= en_US 1 -11316397 0
c0nsumer 58444 0.0 0.0 410724448 1472 s002 S+ 7:14AM 0:00.00 grep 15995
c0nsumer@mini ~ %

Really? Illustrator? Huh… I have been working on a new map of Bloomer Park (in anticipation of the forthcoming Clinton River Oaks Park changes) for CRAMBA and leaving it open in the background… I guess that’s it.

And strangely, closing and re-launching Illustrator made the assertion go away. And now the problem is gone.

Oh, Adobe…

At least it’s easy to tell why it was happening.

(This is Adobe Illustrator v29.8.4 on macOS Sequoia 15.7.3.)

Comments closed

When I switched from an iMac to a Mac mini in late 2024 I choose an ASUS ProArt 5K PA27JCV (24″, 60 Hz) for the monitor and while it looked great, it died after 14 months, seemingly with a backlight or power supply problem. ASUS’ warranty support requires shipping the monitor back, potentially waiting 3-4 weeks, and then getting a replacement. And worse, the replacement could have dead pixels, as the ASUS warranty doesn’t consider ≤5 dark pixels a problem.

The old HP ZR2440w that I swapped in as a spare wasn’t cutting it, so with an indeterminate wait ahead of me, potentially receiving something with bad pixels, and my being vaguely interested in something larger and with a faster refresh rate I went looking at new monitors.

Coming to the realization that 4K is probably fine I picked up a Dell 32 Plus 4K QD-OLED Monitor – S3225QC from Costco for $499. It was well reviewed online and looked pretty good when I played with one for about 20 minutes at Micro Center. When I got home and sat in front of it doing my normal things it looked a bit… different… almost as if my glasses weren’t working quite right. But I figured new monitor tech just needed some time for me to get accustomed to. After all, it had a very high contrast ratio and sharp pixels; maybe it’s just that?

After a few days it still didn’t feel right, so I began looking for a solution. Costco has a 90-day return window for computer monitors, so I had some time, but this didn’t look good; I wanted an answer soon.

I was fortunate to be able to borrow a Dell UltraSharp 32 4K USB-C Hub Monitor U3223QE for the weekend, which was perfect as being a being a high end display with the same resolution and panel size as the S3225QC I could compare them side by side. And in the end the LCD just looked better.

I took some macro photos of both displays and it turns out that what was bothering me was fringing, a problem common to OLEDs. It was hard to point out during normal use other than text-is-a-bit-blurry-and-weird , or like an oversharpened image, or almost like artifacted text in a JPEG image, but with photos it was much easier to see what’s going on. And better, the cause: the arrangement of the subpixels; the little red/blue/green dots that make up a pixel.

As shown above, the subpixles in the Dell S3225QC QD-OLED form a square with green on the top, a larger red pixel in the lower left, and smaller blue in the lower right. The Dell U3223QE, a typical LCD, has three vertical stripes making a square. The result being that high contrast edges look very different on an OLED, often with a strong off-color border — or fringe — along horizontal and vertical lines.

In the photos above, note the vertical part of the 1 which has red and green dots along its right side, and large red dots along the top of the 6 with green along the bottom. These are the strongly colored fringes. (On the LCD they appear white as the three equal size subpixels pixels act equally.)

This meant that things that I tend to do, text or fine lines in maps or CAD-type drawing, are not right at all on the pixel pattern found in this OLED panel. Beyond the pixel pattern, I also suspect that the much crisper pixels (defined points of light) contribute to the fringing having an artifacting-like effect.

This was much more pronounced when looking at light text on a dark background; the way that I read most websites. Visual Studio Code does a wonderful job demonstrating this problem:

This gets at why OLEDs make great TVs and gaming monitors. The contrast is outstanding, color is excellent, and high refresh rates are ideal for moving images and fast-response games. And there’s no noticeable fringing because edges are constantly moving across pixels; almost nothing is still. They also work great on small devices like phones where the pixel density is so high that fringing is too small to see.

But on desktop monitors for still things — text and fine lines — OLEDs currently just aren’t great; I guess that’s why office and productivity type monitors are still LCDs. Even though I don’t like being that person who returns computer stuff just because they don’t like it, I ended up returning the monitor after only four days of using it. The S3225QC and it’s QD-OLED just doesn’t work for me; it made my eyes feel funny to use.

Within the past few weeks LG has announced RGB stripe OLED panels which will resolve this problem, but there aren’t currently any monitors available using these panels, so back to an LCD I’ll go. (It looks like ASUS and MSI will some them available soon, but only as wide-screen gaming monitors. And I suspect the first ones available will be fairly expensive.)

Whether this’ll be buying my own U3223QE, perhaps a Dell U3225QE (adds 120 Hz scanning, an ambient light sensor, and a Thunderbolt dock), or just waiting for an ASUS PA27JCV to come back, I’m not sure… But whatever I end up using will, for now, will be an LCD, not an OLED.

Comments closed

Part of our Home Assistant (HA) setup uses the Companion Mobile App for easy remote control and to collect data from our devices. The main tracked item is the phone’s location, so HA can tell if we’re home or not, and currently I only use it to change how some lighting automations work.

I also have HA set up to log all device state data (switches, outlets, climate sensors, power consumption) to a local instance of InfluxDB, and then have Grafana installed so I can visualize this data.

My original use for this was long-term logging of temperature and humidity sensor data — which is neat to see — but as I’ve experimented with graphing things like mains voltage. This was neat because it made it easy to see things like how voltage drops and becomes erratic during summertime cooling periods. And showed that grid voltage jumped up by ~2VAC in March 2025, around which time I recall DTE doing utility work on the grid just north of our house. (Yes, evidence of them improving things locally.)

Late on Christmas evening, wanting some time to just sit alone and do things, I put together a map showing where my phone had been. I’m pretty happy with how it came out, as I can now input a time range and dots will appear for each logged location, color-coded with geopositioning accuracy (brighter green is more accurate).

I also used this as another exercise in working with LLM tools like ChatGPT. I’m (finally?) realizing how useful this can be when thought of as a modern search engine. There’s still constant reminders of how imperfect and problematic results can be, but with a domain background it’s helpful. I find that thinking of these tools as tireless (yet emotionless) junior employee who makes lots of mistakes and needs all responses tested and vetted works… decently… in pointing me in a decent direction.

But I digress… Here’s the query that’s the main point of this and makes it all go:

SELECT "latitude", "longitude","gps_accuracy"
FROM "homeassistant"."autogen"."state"
WHERE "entity_id" = 'pixel_8'
AND $timeFilter
AND "gps_accuracy" < 100

It was then simply a matter of putting this into a Geomap that displays a point for each location, and colors it based on gps_accuracy state and looks decent. I was even able to place it all on the Thunderforest Landscape map tiles which shows OSM-mapped trails and has been oh-so-useful on my RAMBA Trails Map.

Initially I looked at a heat map, but it didn’t seem as useful as individual points. I may explore this later, but the device where I’m currently running HA is a bit under-powered for this. And note that the query above excludes records that have a GNSS accuracy worse than 100 meters as this generally means that GPS (et al) wasn’t working at all and geopositioning likely came from local mobile towers (which shows me as being on tall local buildings, in fields I’d never visit, etc).

While obvious in retrospect, the most notable things this shows me is that when I’m driving — typically running OsmAnd+ or Google Maps (or both) — the recorded points are high accuracy and frequent. When riding my bike, carrying my phone idly in a pocket, the GNSS sensor is likely PRIORITY_PASSIVE so the dots are both infrequent and low accuracy.

It’s also just neat to look at. Things jump out like a trip to IKEA in Canton, riding at Island Lake and Holly Wilderness, etc.

I’m curious to see what I can further tease out of the logged data. The HA Companion mobile app can get all sorts of interesting info via its Sensors. For example, the Activity Sensors on iOS automatically detect:

• Stationary
• Walking
• Running
• Automotive
• Cycling

And on Android:

• in_vehicle
• on_bicycle
• on_foot
• running
• still
• tilting
• walking

Plus there’s things like what’s being done with the device, what’s seen about its environment (including visible wireless networks, Bluetooth devices), etc…

It might be neat to see what more I can get out of this. Or it might just end up as a nudge to decrease what HA is collecting (and possibly purge some of it from the db).

Of course, it pales in comparison to what the telcos, device manufacturers, OS vendors, and app vendors can do with their data engineers, massive troves of data and ability to cross-reference, etc. (A bit of a reminder that phones are just behavior-trackers that also make calls and take pictures…)

I hope to soon try migrating this HA instance from a Raspberry Pi 4B to a higher-powered slim PC. While I don’t intend to take this much further, it will provide more power for chewing on data like this and will hopefully let me figure out a disaster recovery plan for HA that includes preserving all logged data. When first setting up this map I tried to draw both a location and heatmap and this was a little too much for the Pi and as it ground to a halt Kristen noticed that the back yard lights weren’t turning on properly. Doh! Or I guess I could just do the processing on another machine…

Comments closed