The second idea I had for the usb
relays I bought was to
turn my printer on and off automatically, as is is located in a place
where access to the power button means getting on the floor and twisting
underneath a desk. Also the printer lights that are annoying, even when
it goes into "hibernation" mode, so I want it turned off when not in
I have an access point which has a usb
port, and since the access point is always on and it is in the vicinity
of the printer, it's a good candidate for controlling the relay.
I connected the usb-cable to the access point and installed the
package, which supports my usb controlled relay, and then I connected
the power cable to the printer. The access point runs
OpenWrt so packages like this are readily
So now I can turn the printer on by ssh'ing to the access point and
running the command
crelay 1 ON. Turning it off is similarly simple. I
copied the contents of
/root/.ssh/id_rsa.pub on my computer to
/etc/dropbear/authorized_keys on the access point to allow
non-interactive ssh access.
On my computer, I'm using CUPS for printing;
after a bit of searching I found and installed the
package, and added these two
prehook_power : ssh accesspoint.koldfront.dk crelay 1 ON
posthook_power : echo /usr/local/bin/printer_off "$TEAPRINTERNAME" | at now + 5 minutes
tea4cups: to the
The prehook runs when a new print jobs enters the queue, and turns the
printer on (if the printer is already on, there is no change).
The posthook runs every time a print job finishes, so what I have it do
is to run a little script 5 minutes later. The script checks if the
print queue is empty and if it is, it turns the printer off. If it
isn't, it uses
at(1) to run itself after 5 more minutes, and so on,
until the print queue finally is empty. This is the script:
# printer_off - Turn printer off if queue is empty. If not, try again
# in 5 minutes.
if lpq -P "$1" | grep -q 'no entries'; then
ssh accesspoint.koldfront.dk crelay 1 OFF
echo "$*" | at now + 5 minues
What I like about this hook solution is that the printer is turned off
when a job is created, and there is no polling/busy looping to detect
jobs appearing in the print queue.
Recently an article on this subject caught my eye: "Home Assistant
It might be interesting to contrast the two solutions.
What I didn't do: run things in docker containers, run a message queue,
run a script that calls
lpq every minute. Not to mention setting up
My script is 10 lines + 3 config lines for the hooks, compared to 104
lines of script + 25 lines of YAML.
If you are already running HomeAssistant, it might be nicer to integrate
the printer into it. But also a lot more complicated, it seems.
Something is, anyway.
A while back I set up a system that triggered a door bell and a rotary
light when Motion detected somebody
at a gate.
This was straightforward to implement, as usb controlled relays are
readily available, and a command line utility to control it,
usbrelay, is only an "apt
install usbrelay" away.
After setting that up, I started thinking about where I could use such
relays at home.
The first idea was to automatically turn on and off the two lamps that are
connected to the same power strip as my jukebox and stereo. If I turn
the system on during the day, I have to turn off the lights, and when it
gets dark, I have to turn them on again. Very work, much tedious.
This was quite easily solved - after writing a tiny pair of commands,
sunrise and sunset, I could write a
script that, depending on the time and the sun, switches the lights on or
if expr "$now" \>= "$sunset" > /dev/null; then
echo "After sunset, on"
if expr "$now" \<= "$sunrise" > /dev/null; then
echo "Before sunrise, on"
if [ $wanted = 0 ]; then
echo "Daytime, off"
usbrelay 0_1=$wanted 2> /dev/null
Another shell script runs on boot - after ntpdate has set the time on
the jukebox (it's a Raspberry Pi and doesn't have a battery) - from my
crontab. It runs the
handle_lights script above, to make sure the
lights are in the correct state, and then it queues up the script to be
run again at the next sunrise and sunset:
handle_lights > /dev/null
echo handle_lights | at -M $(sunrise | sed 's/:..$//') + 2 minutes 2> /dev/null
echo handle_lights | at -M $(sunset | sed 's/:..$//') + 2 minutes 2> /dev/null
Originally I tried using systemd timers instead of
at(1), because they disappear after a
reboot, and I wouldn't have to worry about multiple runs when the
jukebox is rebooted, but the timers kept firing early - like 10 seconds
early when I specified
AccuracySec=1s, so I gave up on that and I am
The Danish police have some horses. Not because they need them, but
because of, frankly, sad political grandstanding. Previously the horses
were borrowed from the Swedish police, I'm not sure if that is still the
Anyway, on the picture above, you can see what the police leaves on the
streets of Copenhagen.
Help some ducks across the street if you want to seem cute, rather than
literally dropping shit on it, come on!
Good catch by a reader of Private Eye - Peppa Pig is inspired by
To save you time, I have taken it upon myself to watch all the dash
camera vidoes on YouTube, and I can now summarize driving in various
The USA: You own the lane in which you drive. If somebody wants to
drive in the same lane, they had better wait until you have passed them
by a mile; if not, honk at them, repeatedly and for a long time. Also,
if somebody honks at you, the appropriate response is to get in front of
them and randomly hitting the brakes. This is called "brake checking",
and often spelt "break". Most accidents happen when people change lane
without looking first, and channels habitually recommend driving your
car into another car instead of leaving room or avoiding contact, for
insurance reasons. Most overtaking is done on the right.
The UK: Most problems happen in roundabouts when people either don't
manage to be in the correct lane, or they fail to enter the roundabout
at the right time, or they fail to speed up quickly enough.
Australia: drivers turning off at exits too late; the comment is
invariably: "What a dickhead!"
Russia: On two-lane snow covered roads head-on collisions during
overtaking are popular. Otherwise most accidents are cars turning left
on six lane wide streets lined with tall concrete buildings, into cars
running red lights.
Germany: Most dash camera videoes are of cars driving through red
lights or over lines they aren't supposed to. The camera operator will
berate they driver not following the rules loudly; "Junge!". Every video
of a cyclist invariably includes some minor offense and the dash camera
driver yelling at the offender.
I have a new pet peeve (or hobby horse?) - the verbal tic when people
introduce an explanation of something with "For those who don't know…"
I think I can see why the speaker would say so - it is used as a sort of
acknowledgement that you're now explaining something to people that they
already know. Sort of "Sorry, but here I go anyway, just to be on the
However, to the person listening, it easily sounds very different
If you are one of the people who know, then getting a relevant
introduction to something you already know as part of a story isn't
something the speaker has to make excuses for. The introduction will serve
as a reminder, the person who knows can check that they remember the
basics right, and it will also serve to align terminology. As the
speaker has prepared, the speaker will almost always know the specific
subject the best.
If you are one of the people who don't know, then it is easy to hear
"but you should" and "but you don't, so now I'm going to waste
everybody's time to bring you up to speed," even if it wasn't meant
that way. Learning something when you've just been singled out as behind
and lacking is not effective.
If the introduction is relevant, short, precise, and fits the narrative,
include it without a disclaimer.
If the introduction isn't necessary, skip it.
Don't make listeners feel bad.