Turning on my office lights when I plug in my webcam

Another post in my series of "absurdly specific things no other human will ever find useful, but I'm still writing a blog post about".  I have a USB webcam in my home office on my PC which I use for work meetings.  I only plug that webcam in while I'm working, because I don't trust it otherwise.  Also, I have some lights above my desk that I like to turn on during meetings for better lighting.  The switch for those lights is in the corner behind my desk, and annoying to reach.  I installed a smart switch for them so I could turn them on via Home Assistant, but never got around to creating an easier way to turn them on other than the switch, or doing it via the HA UI.  Most mornings I plug in the webcam and then reach awkwardly over my monitors to hit the light switch.

I decided to automate this.  Now while I've recently acquired a glut of motion sensors, I find they have far too many false positives and false negatives to actually drive most automations with.  Instead I figured I could just detect if my webcam was plugged in and if so, send some signal to HA to turn on the light.  My first instinct was a cron job that checked the output of lsusb, which would have worked, but would have been pretty inefficient running every minute, and would have had a lag.  Instead, I began googling how to trigger an action when plugging in a USB device and discovered udev rules.

udev rules

udev rules are a way to trigger commands when various hardware events happen.  They're commonly used for doing certain things when a USB thumb drive is plugged in.  Anyway, I'm going to skip over a lot of saga here, but if you want to read more about udev rules and how to set them up, you can find a lot of info on Google.  Here is one page that describes some of the details a bit.

With that in mind, what I ended up with was a file named /etc/udev/rules.d/80-logitech-webcam-connect.rules with the following contents:
ACTION=="add"    KERNEL=="video0" SUBSYSTEM=="video4linux" SUBSYSTEMS=="usb" ATTRS{idVendor}=="046d", ATTRS{idProduct}=="082c",  RUN+="/home/me/bin/webcam_alert/webcam_alert.sh connect"
ACTION=="remove" KERNEL=="video0" SUBSYSTEM=="video4linux" SUBSYSTEMS=="usb" ATTRS{idVendor}=="046d", ATTRS{idProduct}=="082c",  RUN+="/home/me/bin/webcam_alert/webcam_alert.sh disconnect"

A couple udev protips I figured out.  I know I didn't explain what any of these lines do, but each all caps word (besides RUN) is a filter, which you'll be looking for and then running the command when they all match.   Note the KERNEL=="video0" portion.  The script works without that, but I was getting duplicate executions, which didn't cause any issues but bothered me.

Another thing is that the longest part, by far, of all this was the point where I had all this working, except my shell script was seemingly just silently failing.  It would log to a file fine, but I slowly realized anything that require network access was just timing out.  Turns out this is due to firewall rules that prevent udev rules from connecting to remote machines.  The command sudo systemctl status systemd-udevd.service helped in debugging this, and then the command sudo systemctl edit systemd-udevd.service allowed me to add an exception for the machine that I have running MQTT.

Shell Script

That command will call this shell script.  You can see there is a connect or disconnect argument that is passed to the script.  The script also logs which argument was passed to it, which helps with debugging a lot.  That script is just taking that connect or disconnect argument and turning it into an ON or OFF payload to send to an MQTT sensor in Home Assistant.

MQTT Auto Discovery Sensors

I am a big fan of MQTT auto discovery sensors in Home Assistant.  If you don't know, MQTT is just a protocol for sending messages around your network, which is used heavily by smart home senors, particularly once you get into more DIY stuff.  You set up a "broker" and then devices can publish JSON messages to "topics", which are just file paths.  Then other devices can subscribe to those topics and receive anything published to them.  If you set up MQTT and want to play around with messages or just see what messages are being sent, I recommend MQTT Explorer as a really good GUI tool.

You can get away without any MQTT for a while, but a lot of the more DIY sensors use it, and once you have it set up it unlocks a lot of capabilities.  For example, I'm using it for both ESPHome and Zigbee2MQTT, where I use it to send all data from my zigbee sensors back to HA.  I was hesitant to do that for a while because I assumed it would introduce lag, but I can't detect any delay in something like a door sensor opening and triggering a light to turn on.

Anyway, once you have MQTT set up, you can use a feature of it in Home Assistant called Auto Discovery.  This has to be enabled, but once you do HA will look for topics matching a certain pattern and when it finds them it'll automatically create a new sensor.  Like I said, I'm a big fan of this, and I've made a project that uses it to grab local weather data and send it to Home Assistant.

You can check out the above shell script if you're interesting in making your own custom MQTT auto discovery sensors, it's the simplest I could set it up.  You need to send two different topics, one to configure the sensor and then another for the data.  The script is a bit inefficient in that it sends both the configuration and data every time it runs, but I can live with that considering it only runs a couple times a day.  The weather data project I linked to is a much better done example of MQTT auto discovery sensors.

Home Assistant

At this point it's simple.  The webcam state gets picked up by HA as a binary sensor with an On and Off state.  I just set up an automation to turn on the light via the Lutron integration whenever it transitions from off to on, and vice versa.

For some reason it detects unplugging faster than plugging in, but it's about a second from plugging in to light being on, and just about instant for unplugging.  The timing is a bit of a moot point as it takes a few seconds for Hangouts to detect the camera before I can join a meeting anyway.

Summary

And there you go.  When I plug in my webcam, a custom udev rule triggers, which runs a custom shell script that publishes a MQTT message to a topic which Home Assistant has been configured to automatically detect and treat as a native sensor, and that sensor then triggers an automation which tells the Lutron integration to turn on the lights, simple.  I've been using this for a week now, and it's performed flawlessly, despite the fact that I'm still shocked anytime anything I make works even once.

DIY emulation in 2023

Intro

I've been told this is currently the 2020s, and so it's time for my decennial post on how to emulate classic games.  I've been chasing the high of modded original Xboxes running XBMC and a collection of emulators since 2006.  The main selling point of that setup was how slick the interface was.  Just turn it on and do everything with the controller on a UI that was clearly designed for a TV.  The main downside was having a huge Xbox in your living room, and having to use wired controllers.

Last decade's solution was a Raspberry Pi running RetroPie, which worked ok, but the interface was never that great and it struggled with N64.

Separately, the Roku I use to watch Plex, Netflix, and other media is starting to show its age, and I wouldn't mind something more open source.

My plan was to buy a mini PC, put linux on it, maybe some HTPC distro, and use that for both media and emulation.

I'll skip over the saga and say that the media playback didn't work out.  I had assumed there would just be native clients for Netflix and others available, but there isn't.  There are the web versions, and maybe something could be done with launching the web versions seemlessly, but it just didn't feel like it'd ever have the slick UI I wanted.

Incidentally, around this time I got an Nvidia Shield donated to me and discovered SmartTubeNext, which is a Youtube player which skips ads, including portions of the videos about sponsors themselves.  That greatly reduced my desire for media playback on the mini PC.  I've also been very happy with pairing the Shield with an Xbox controller to play game via Steam Link on my Desktop PC.

So what did I end up with?

The focus then was just emulation, from N64 and older.  First, I bought this Mini PC for $200.  Note there are a ton of these around this price point, and they all have similar specs.  I sort of regret buying this one because it has a very loud fan, despite the fact that the listing claimed it was silent when I bought it (and later removed that claim), and because this one doesn't support any sort of Wake On LAN or boot on power restore, so there is no way to for me to turn it on remotely, and I can't leave it on 24/7 because of how absurd the fan is.

I also bought this IR USB dongle for $20.  I intended on setting it all up manually, but ended up just installing the FLIRC program from the repos and liking it a lot.  I set up buttons on my remote to map to Alt+F4 (close program), ESC, and a custom shortcut I set up to show the desktop.  Between those and the obvious stuff like arrow keys and enter, I found it pretty easy to use with a remote.  The only things I have on the desktop are Steam and RetroArch, as well as a few useful tools, including a shortcut to power off.

I was using my Logitech Harmony 300 remote until some of the button finally started to give out.  I replaced that with this remote I got for $40, which I like quite a bit.

I also have this wireless N64 controller that I got for $40, and which you can use with actual N64s or via a USB dongle on a PC.

And I found this amazing archive of every ROM ever on Internet Archive.  I got all the N64 and older ROMs from the systems I wanted, and filtered the sets down to the games I had heard of.

I installed Xubuntu on there, although I'm keeping my eye on KDE's Plasma Bigscreen, which looks very promising for what I want to do, but right now is only available on ARM hardware.

So overall I'm happy with this set up.  I have to get up to turn it on, but after that I can control everything with the remote and controller.  I've been playing a lot of N64 games on it, and they generally work well.  Goldeneye's sound stutters, but I googled what to tweak in the setting to get the best performance out of it, and that was enough to play through the campaign.  Mario 64 I'm about halfway through and it's been flawless.

My Youtube earnings - Brick Experiment Channel

https://brickexperimentchannel.wordpress.com/2022/11/19/my-youtube-earnings/ 

My viewership consists of mostly middle-aged males.

Finding the B-21's hangar location from the stars in its press image

 https://twitter.com/johnmcelhone8/status/1600683623250030593

The photo of the U.S. Air Force's new stealth aircraft is on the left, taken at night, with stars in the background.
We can use them to find the exact location of the jet

(thread) https://t.co/aJo9kIPv2l

— John McElhone (@johnmcelhone8) December 8, 2022

From Oscilloscope to Wireshark: A UDP Story

https://www.mattkeeter.com/blog/2022-08-11-udp/

QR codes Share

https://typefully.com/DanHollick/qr-codes-T7tLlNi

Second, the mask - what's that? Well, QR readers work best when there are the same amount of white and black areas. But the data might not play ball so a mask is used to even things out. When a mask is applied to the code anything that falls under the dark part of the mask is inverted. A white area becomes black and black area becomes white.

There are 8 standard patterns which are applied one by one. The pattern that achieves the best result is used and that info is stored so the reader can unapply the mask.

 

Here’s Why Car Wheels Are So Flat These Days

 https://www.theautopian.com/heres-why-car-wheels-are-so-flat-these-days-and-no-its-not-just-aerodynamics-and-styling/

At first, rack and pinion gears were being applied to existing suspension designs but since the tire forces were being “amplified” by the large kingpin offset and scrub radius in those old designs, they were too much for the driver to take and were ripping the steering wheel out of their hands. Something had to be done and since there will always be potholes and braking forces, the only thing that the engineers could do to reduce the forces coming back through the steering system was to reduce the size of the kingpin offset and scrub radius. This meant the lower ball joints had to move outboard, the brakes had to move outboard and all the dominoes started to fall which spelled the end of deep dish wheels.

Why No Roman Industrial Revolution?

https://acoup.blog/2022/08/26/collections-why-no-roman-industrial-revolution/

Eventually in the 1800s, these engines get small enough and fuel efficient enough to be able to move their own fuel over water or rails, collapsing the prohibitive transportation costs that defined pre-industrial economies and in the process breaking the tyranny of the wagon equation, decisively transforming warfare in ways that would not be fully appreciated until 1914.

But the technology could not jump straight to railroads and steam ships because the first steam engines were nowhere near that powerful or efficient: creating steam engines that could drive trains and ships (and thus could move themselves) requires decades of development where existing technology and economic needs created very valuable niches for the technology at each stage. It is particularly remarkable here how much of these conditions are unique to Britain: it has to be coal, coal has to have massive economic demand (to create the demand for pumping water out of coal mines) and then there needs to be massive demand for spinning (so you need a huge textile export industry fueled both by domestic wool production and the cotton spoils of empire) and a device to manage the conversion of rotational energy into spun thread. I’ve left this bit out for space, but you also need a major incentive for the design of pressure-cylinders (which, in the event, was the demand for better siege cannon) because of how that dovetails with developing better cylinders for steam engines.

Is it getting hotter?

I wanted to see what actual data said about how much hotter it has gotten in my area during my lifetime.  I know climate change is going on at a global level, but I just cared about my area, is it actually getting noticeably warmer, or is it just my imagination?

Before we go any further I should stress I'm not trying to prove or disprove climate change, or do any sort of serious climate science here.  I'm just trying to answer the question: Is it actually noticeably hotter here in the Philly area now than it was when I was a kid?

I've seen graphs of average temperature over time for cities before, but I feel like they tend to use average temperature over the year.  Which, I'm sure is a more important data point for climate science, but again, I only care about if I feel hotter here.  I don't really care about days that would have been 50F and now are 60F.  I decided the right metric to use for me is how many days over 90F per year do we see?  Is that number going up?

I won't turn this into a huge post.  I grabbed data from the NOAA here, in a CSV for the Philly airport from 1980 to 2021, which roughly matches the time I've been alive.  I threw that into a database and queried the count of days per year over 80F and over 90F, and graphed both, with trend lines.

Before I put the trendline on there, I have to admit I thought the 90F version didn't show any increase.  But then I noticed how few years had less than 20 days over 90F recently vs the 80s.  We haven't had a year with less than 10 days over 90F since 2014.

The over 80F version is a bit harder to read, but I feel like it shows the upward trend better, particularly if you focus on the 100 days line.  In the 80s there were a few years with more than 100 days over 80F. In the 90s it was about half the years.  In the 2000s it was most, and then in the 2010s it was all but 2, which barely snuck in under the line.

For fun I also looked for number of days where it never went above 30F.  Note this isn't just the daily low, this is the warmest it got on any given day, or in other words, days where it never got above freezing.  Spoiler alert, it's also getting less cold.

I did also pull the lows and looked at those,  they showed similar trends.  The 1980s had an average of 25 days below 20F, the 2010s had an average of 13 days, and 2021 had exactly 1.  The one graph I will post from the lows is this one of the number of days where the low is over 70F.  In other words, days where it never goes below 70F, even over night.  If you're looking to cool your house by opening the windows over night and closing them during the day when it heats up, it's going to be pretty tough to do if it's not going below 70F at all (which probably means it's still over 80F when you're going to bed).

 

I was actually surprised at how clear the trend was in the data, and in every single version of the data I could think of to look at.  There wasn't a single dimension I looked at that didn't show this trend.  Turns out it is hotter now than when I was a kid.  Not a fan.

Mouse Heaven or Mouse Hell?

 https://www.sciencehistory.org/distillations/mouse-heaven-or-mouse-hell

Officially, the colony was called the Mortality-Inhibiting Environment for Mice. Unofficially, it was called mouse heaven.

Biologist John Calhoun built the colony at the National Institute of Mental Health in Maryland in 1968. It was a large pen—a 4½-foot cube—with everything a mouse could ever desire: plenty of food and water; a perfect climate; reams of paper to make cozy nests; and 256 separate apartments, accessible via mesh tubes bolted to the walls. Calhoun also screened the mice to eliminate disease. Free from predators and other worries, a mouse could theoretically live to an extraordinarily old age there, without a single worry.

But the thing is, this wasn’t Calhoun’s first rodent utopia. This was the 25th iteration. And by this point he knew how quickly mouse heaven could deteriorate into mouse hell.