Adaptive Lighting via Home Assistant

Intro

As I’ve mentioned previously, we’re using Phillips Hue and Home Assistant for most of our lighting. The Phillips Hue bridge is connected to Home Assistant, and I’m using the HomeKit Bridge integration to add the lights to Apple’s Home app – the bridge is not connected directly to HomeKit. This has been incredibly stable, however, it comes with a downside: we’re unable to use Apple’s adaptive lighting functionality.

Home Assistant, however, has its own integration for Adaptive Lighting. The documentation can be confusing, however, and it took me over six months to get it working the way I wanted to. Hopefully this post saves someone else some time!

Smart Home 2025

Taking a page out of Apple’s book, I realized I’m going to be writing about this regularly, so the naming will reflect that from now on. If you’d like some historical context, please see my previous posts on the subject. If you’d like to see all of the data on a spreadsheet, I recently updated Mike and Joyce’s Smart Home Inventory.

We recently completed a major home renovation, which gave us the chance to rethink everything. For context, we added an addition, completely rebuilt the kitchen, and modernized the existing footprint of the house.

Homelab Authentication

Once you have more than a few Docker containers running in your homelab, you’ll notice some applications have implemented their own authentication, requiring you to keep those credentials organized (hopefully in a password manager like 1Password). However, some applications don’t support authentication at all. What do you do? How do you make it less annoying to access your stuff?

Managing Docker on Unraid

In my last blog post, I detailed how I built myself a beefy file and application server. In this post, I wanted to share how I organize and run Docker containers on Unraid.

My Homelab Hardware Journey

The Beginning

Even before I called it a “homelab,” I found uses for home servers – mostly to replace multiple external USB hard drives. Although I grew up with Mac desktops, I became a laptop user in high school. Imagine being able to access my data from anywhere using my PowerBook G4! Or even better, being able to have tasks running without tying up my main computer. I bought a used Power Mac G3 tower (I later upgraded it to a G4 tower), removed the optical and Zip drives, then added ATA/IDE expansion cards and additional hard drive bays. That worked well for a few years. As a repair technician, I even used this method to build NetBoot and DeployStudio servers at work.

Smart Home, Part 3

I can’t believe it’s been almost 3 years since I wrote about this! Things have settled down a bit, so I figured I’d post another follow-up.

Finding Balance While Working Remotely

Alright, back to the technical stuff. Well, sort of.

Something that’s been new to me is working remotely for a company where many of my coworkers are in different time zones. Although I was fully remote at SJU for the last few years of my time there, everyone I worked with started and ended their day at around the same time. That doesn’t happen when you’re working for a global company! To have a work / life balance these days, I need to be mindful of my own schedule. Here’s how I’ve used technology to help me do that.

July 2024: I’m updating this post without making a new one, just to keep things simple. Below each section, I’ve added some additional tips that I’ve learned since originally publishing this blog post.

Making History

I’ve been super lax about posting here. I wrote something last week about Mr. McCormick’s retirement from the Historical Society of Riverton. I’ve copied it below:

Some personal news

It’s been a while since I’ve posted anything non-technical here, but I have some news! I’m excited to announce that next week, I’ll be joining DoorDash’s IT team! I’ll be working as a Client Platform Engineer, helping to manage all of the devices. I seriously can’t wait!

I was at Saint Joseph’s University for almost nine years, and I couldn’t be more proud of the work I’ve done there. My CIO, Fran DiSanti, sent this to everyone in the Office of Information Technology (and gave permission for me to repost it publicly):

Hello Colleagues,

Many of you may already know that Mike Solin will be leaving SJU this Friday, October 21 to pursue a new job opportunity as a Client Platform Engineer with DoorDash.  Mike is very excited to be joining a new team of client engineers which has been taking shape at DoorDash for the past year.  I’m confident that Mike will do great things for DoorDash just as he has for SJU over the past 9 years. 

Mike started as Technology Support Specialist in OIT and over time was promoted to his current role as Senior Client Platform Engineer.  Throughout his tenure in OIT, Mike has contributed much to our organization and to the University community. He completely reimagined and reengineered the way that we manage our macOS and iOS environments.  When he started at SJU, Mike envisioned a zero-touch, modern approach to device management and he successfully realized this vision by delivering an out-of-the-box deployment experience for Mac users.  His approach was secure, highly automated and allowed users to select and install pre-packaged apps from a software catalog.  In addition to his Mac expertise, Mike became very proficient with our Windows environments and Active Directory.  

Mike has been instrumental in the design, development and deployment of a number of strategic technologies which have had a significant impact on the way in which we manage our endpoint devices, including:

  • An automated data-backup solution (Code42)
  • Endpoint detection and response software (Malwarebytes)
  • Adobe Creative Cloud implementations
  • Mobile Device Management software (Workspace One)
  • Computer encryption
  • Microsoft Azure environment
  • Automated delivery of iPads to users

Clearly, Mike has made many important contributions through the years and along the way, he has continually developed his knowledge and skills.  I am truly grateful for all that Mike has done for our division and the community.  Please join me in thanking Mike and wishing him well in the next chapter of his chapter. 

Fran

Prior to joining SJU, I had moved from Philadelphia to State College, PA, then Richmond, VA. Being a Mac admin is very specialized, and at the time, remote work wasn’t as common as it is now. I missed my family terribly, and regularly used all of my vacation time to drive back for visits. I was incredibly lucky that the opportunity at Saint Joe’s opened up – it brought me home.

Moreover, it gave me the chance to work with a great team. One of the best things about working at SJU was that nothing was off-limits – I was encouraged to learn anything that interested me, and to use those skills to make things better for the university. When the position is posted, I absolutely recommend applying.

Going forward, I’ll still be local to the Philly area! I’m still involved with Greater Philadelphia Mac Admins, and plan on continuing to post to this blog, present at conferences, and participate in the Mac Admins Slack. šŸ˜„

Controlling Munki via Workspace ONE and Active Directory

I got something working recently, and I thought it was interesting enough that it’d be worth sharing.

Our MDM server is a SaaS instance of Workspace ONE UEM, and we have the AirWatch Cloud Connector installed in an on-prem VM to provide integration with Active Directory. Although WS1 bundles its own (modified) version of Munki, we don’t use it – we have a separate on-prem VM for our vanilla Munki server.

Unfortunately, this post is partially about printers (sorry). The challenge with setting up LPD printers on the macOS, is that the drivers need to be installed before the printer is added (or the printer is added with a generic driver, and must be removed and reinstalled). Munki is an excellent use case for this, as the requires and update_for pkginfo keys are perfect for setting up dependencies.

For several years, I used Graham Gilbert’s printer-pkginfo script to deploy printers with Munki. That, combined with my NoMAD group condition script, allowed me to deploy printers to only certain people’s devices – their user accounts in AD needed to be a member of a particular group.

With macOS 12.3 dropping Python 2 from the OS, I needed another solution. I landed on wyncomco’s fork of Nick McSpadden’s PrinterGenerator script. It works well, but with our move from NoMAD to Jamf Connect, how would we be able to leverage our AD groups to deploy these printers?

Thanks to the AirWatch Cloud Connector, I was able to add the AD security group to WS1 (in Accounts > User Groups > List View). The group in WS1 syncs periodically with AD, so users added to AD will appear in the WS1 group after a few hours.

In my case, though, I needed a Smart Group (sometimes called an “Assignment Group”) to actually make use of the user group. In Groups & Settings > Groups > Assignment Groups, add a new Smart Group where the first criteria is the Organization Group that contains your devices. Scroll down to User Group, and select the group you’re synching from AD. Name your Smart Group and click Save.

The last piece was how I’d get the printer to these users. Around the same time, VMware added the ability to run scripts through Workspace ONE. I had remembered Nick McSpadden’s post about Local-Only Manifests in Munki, which was perfect for this. I’d set up a separate manifest for WS1 to write to, and Munki would install the printer driver and the printer automatically.

First, in your Munki configuration profile, add this:

<key>LocalOnlyManifest</key>
<string>LocalOnlyManifest.plist</string>

This tells Munki to check this additional manifest for potential items to install. There’s no need to create the file – if it doesn’t exist, Munki proceeds as normal, without printing any warnings/errors.

Lastly, add this script to WS1 (in Resources > Scripts), and assign it to your Smart Group. Set the language to Bash, and the execution context to System.

#!/bin/bash

defaults="/usr/bin/defaults"
grep="/usr/bin/grep"

printer_installed=$(${defaults} read "/Library/Managed Installs/manifests/LocalOnlyManifest" managed_installs | ${grep} "MyPrinter")

if [ ! "${printer_installed}" ]; then
 ${defaults} write "/Library/Managed Installs/manifests/LocalOnlyManifest" managed_installs -array-add "MyPrinter"
else
    exit 0
fi

exit

In my case, I have it run immediately upon device enrollment, as well as when the network interface changes. The code runs a check to see if the Munki item MyPrinter is in the LocalOnlyManifest, and if not, it adds it. The next time Munki runs a background check, it will install the driver and printer automatically.

The end result is that when a user requires our printer, any AD admin can add the user to a particular group. Some time later, the user will receive the printer without needing to do anything. If the user already has our printer, but receives a new computer, the printer will be added as soon as the computer is set up – no additional admin work necessary.

I hope someone finds this useful for more than just printers!

Page 1 of 5

Powered by WordPress & Theme by Anders Norén