You can install it from npm.

$ yarn global add whistle-switch

Fire it up on the same network as you homekit setup, and it should work right out of the box.

$ whistle-switch
🚧 starting listener...
🦾 starting controller!
Sun Jan 16 2022 15:56:42 GMT-0500 (Eastern Standard Time) | [vite] connecting...
Sun Jan 16 2022 15:56:42 GMT-0500 (Eastern Standard Time) | [vite] connected.
Sun Jan 16 2022 15:56:42 GMT-0500 (Eastern Standard Time) | %c * Tone.js v14.7.77 *  background: #000; color: #fff
Sun Jan 16 2022 15:56:42 GMT-0500 (Eastern Standard Time) | The ScriptProcessorNode is deprecated. Use AudioWorkletNode instead. (https://bit.ly/audio-worklet)

If you're trying to run whistle-switch on a Raspberry Pi, you need to tell it where to find chromium.

$ WHISTLE_SWITCH_CHROME_EXECUTABLE_PATH=$(which chromium-browser) whistle-switch

Then you should be able to connect the switch to your Homekit setup!

Check it out on Github for more interesting configuration options and trouble shooting.

But alas, there's still some tweeters I wish I could keep up with. Talking with a couple friends whose tweets I regularly miss, I found myself wondering if I could get their posts into Reeder. There are some services that do it already, like feeder and rss.app, but they cost $$$.

Those services seem to work just fine, but since I'm at RC, I figured I'd take a crack a building something like that myself. I might as well spend a few dollars on a Digital Ocean VM and and learn something along the way. So here it is...

Introducing tweed.systems

It'll give you an RSS feed for a public twitter account to use with your feed reader of choice!

For example, you can find @recursecenter at https://tweed.systems/recursecenter/tweets.rss.

I'm planning to keep this running in a low-key fashion unless I exhaust my Twitter API rate limit. You can use it at tweed.systems or host your own instance if you're feeling DIY.

So far I've done most of my work with Web Audio. It was really helpful to work in a familiar language like JS so I could focus on learning about audio. Alas, Web Audio is really only available in browser. There's an incomplete node implementation and plenty of other audio libraries in JS and languages, but I didn't really want to rebuild what I have. At least not right now. So I got to thinking, maybe I could run the prototype in a "headless" browser environment.

Headless Chromium and Puppeteer

Nowadays Chromium (and Chrome and Firefox) can run in "headless" mode. The browser runs like normal, it just doesn't show any UI on the screen. Instead, you can interact with the browser programatically through the DevTools protocol.

I decided to try using puppeteer to automate a headless instance of Chromium with JS. It's pretty fun.

// puppeteer-test.js
const puppeteer = require("puppeteer")

;(async () => {
  const browser = await puppeteer.launch({
    // If you disable the `headless` option, you can watch your script control the browser.
    headless: false,
  })
  const [page] = await browser.pages()
  await page.goto("https://pptr.dev/")
})()

👀 Check it out.

I disabled headless to create that GIF. It makes for easier debugging, but beware! Some APIs behave differently in headless mode.

Headless recording

My whistle detector uses getUserMedia to access the computer's microphone and listen for whistles.

const micStream = await navigator.mediaDevices.getUserMedia({ audio: true })

With the UI on, you see a permissions dialog when a new site requests access to your mic.

Unforunately you can't interact with those dialogs in headless mode, so getUserMedia fails with an error like this.

Uncaught (in promise) NotSupportedError: Not supported

Luckily, we can override those permission dialogs by passing the --use-fake-ui-for-media-stream flag to puppeteer's instance of Chromium (this list of Chromium flags came in real handy).

const browser = await puppeteer.launch({
  args: ["--use-fake-ui-for-media-stream"],
  headless: true,
})

With that flag enabled, microphone access works without user interaction. Probably don't pass that flag to your everyday browser. 🤪

Running on the Raspberry PI

At that point, everything seemed to be working on my laptop, so it was time to try it out on the PI! Alas, it failed immediately.

(node:906) UnhandledPromiseRejectionWarning: Error: Failed to launch the browser process!
/home/pi/rc-playground/whistlee-headless/node_modules/puppeteer/.local-chromium/linux-901912/chrome-linux/chrome: 1: /home/pi/rc-playground/whistlee-headless/node_modules/puppeteer/.local-chromium/linux-901912/chrome-linux/chrome: Syntax error: ")" unexpected

It turns out puppeteer comes with a version of Chromium built for x86 architectures, but the Pi has an ARM processor. To run puppeteer on the Pi, you need to tell it where to find an ARM compatible version of Chromium.

Nowadays, the Raspberry Pi OS comes bundled with already Chromium installed. You can find it's path using the which command in the Pi's terminal.

~ ➜ which chromium-browser
/usr/bin/chromium-browser

Then pass that path into puppeteer's executablePath option.

const browser = await puppeteer.launch({
  args: ["--use-fake-ui-for-media-stream"],
  executablePath: "/usr/bin/chromium-browser",
  headless: true,
})

It's alive!

That's it! With those options, you should be able to run a webpage headlessly on a Raspberry Pi with access to the mic.

If you want to try the whistle detector:

1. clone my rc-playground project
2. run yarn at the root
3. run yarn in whistlee-headless run ./bin/start-headless.sh from the root

The first version of the code was a bunch of canvas instructions one after the other.

const ctx = canvasElement.getContext("2d")
ctx.fillStyle = "white"
ctx.fillRect(0, 0, canvasElement.width, canvasElement.height)
ctx.fillStyle = "black"
ctx.fillRect(10, 290, 280, 80)
ctx.fillRect(30, 270, 240, 20)
// and so on and so forth...

I wanted a simple animation to illustrate the steps of the program. I split the logic up into an array of functions and called each one in sequence using setInterval.

const instructions = [
  () => {
    ctx.fillStyle = "white"
    ctx.fillRect(0, 0, canvasElement.width, canvasElement.height)
  },
  () => {
    ctx.fillStyle = "black"
    ctx.fillRect(10, 290, 280, 80)
  },
  () => {
    ctx.fillRect(30, 270, 240, 20)
  },
  // ...
]

let step = 0
let intervalId = setInterval(() => {
  if (step < instructions.length) {
    instructions[step]()
    step++
  } else {
    clearInterval(intervalId)
  }
}, 500)

That worked just fine. I guess I had to type "() => {}," a lot but it did the job. Then it occured to me: maybe instead of a list of functions I could use a generator.

Generators

A generator function is a special syntax for creating objects that implement the iterable protocol.

function* makeGenerator() {
  yield 1
  yield 2
  yield 3
}
const generator = makeGenerator()

The yield keyword works like return, but each time we call generator.next() the program starts after the previous yield.

generator.next() // {value: 1, done: false}
generator.next() // {value: 2, done: false}
generator.next() // {value: 3, done: false}

Onces you've made it through all the yields, you can keep calling generate.next() but done will always true and nothing else will happen.

generator.next() // {value: undefined, done: true}
generator.next() // {value: undefined, done: true}
generator.next() // {value: undefined, done: true}

Putting it together

Getting back to the logo animation, I put my canvas instructions into a generator with a yield between each step.

function* makeLogoGenerator() {
  ctx.fillStyle = "white"
  ctx.fillRect(0, 0, canvasElement.width, canvasElement.height)
  yield
  ctx.fillStyle = "black"
  ctx.fillRect(10, 290, 280, 80)
  yield
  ctx.fillRect(30, 270, 240, 20)
  yield
  // ...
}

Then I call logoGen.next() in setInterval, until the generator is done.

const logoGen = makeLogoGenerator()
const intervalId = setInterval(() => {
  if (logoGen.next().done) clearInterval(intervalId)
}, 500)

Calling generator.next() over time creates a simple animation effect on the canvas. It works pretty well!

The working demo is here and the source is on GitHub.

Erlang/OTP 24 [erts-12.0.3] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit] [dtrace]

Eshell V12.0.3  (abort with ^G)
1>

It might feel familiar if you've used the console in a web browser or a REPL in another language. Like the browser console, Erlang's shell environment includes handy shortcuts for shell-related activities. These are their stories.

"b" as in "bindings"

Variables in Erlang are immutable. You can't change 'em. I knew that going in, but it often trips me up in the shell.

1> One = 1.
1
2> Two = One + One.
2
3> One = 2.
** exception error: no match of right hand side value 2

Once you define a variable, you can't set it again. Immutable. Right. But sometimes, in a long shell session, I clear my screen or just forgot what variables I set.

Try b/0. It prints out all the variables defined in the current session along with their assigned values.

4> b().
One = 1
Two = 2
ok```

## "f" as in "forget"

Even better, `f/1` will _unbind_ a variable you want to reuse.

```erl-repl
12> b().
One = 1
Two = 2
ok
13> f(One).
ok
14> One = 2.
2

And if you need a clean slate, f/0 removes all variable bindings in the session.

16> b().
One = 2
Two = 2
ok
17> f().
ok
18> b().
ok

That's all for now. To learn more about the erlang shell, get straight into the docs.

It's a concrete idea. I think it's achievable with wiggle room for exploration. Apparently it's been done before more than once.

I can imagine the steps to get there: record things, identify a whistle, make a request to the HomeKit API, turn on the lights. The good news is that I have no idea how to do any of that. It's good news from an "I'm trying to learn things" perspective anyways. I can also imagine plenty of ways to take it further if I finish. Like what if the program whistles back?

I want to give Erlang a try for this project. Last week, I read through some of Learn You Some Erlang for Great Good!. The syntax is funky, but I feel I've already learned a lot from reading through some of the chapters on concurrency and distribution. I'm not sure it's the most practical choice, but I think it'll be fun. I have a couple of Raspberry Pis gathering dust in my closet, so maybe I can set up a lil cluster.

I'll continue writing about what I'm up to at RC, so you can look forward to updates soon. Keep an eye on my projects at rc.colbyr.com.