I think this captures the essence of the "IoT" trend - take a function accomplished by a simple existing device, and do it using mindboggling amounts of hardware and software complexity.

Especially after watching the demo video, I'm still very confused as to how making the RPi play something upon receiving a signal somehow involves a web server and browser. It also apparently requires JavaScript[1] and even Google Cloud Messaging...

[1] https://github.com/teozkr/klocka/blob/master/web-client/inde...

Yeah. I hear ya.

I completely appreciate the spirit of projects of like this. I doubt this dude is trying to "disrupt" the doorbell industry. It's just a fun challenge to solve.

I dunno. I kinda look at it like modern art. You might walk through a gallery and say, "Pfft. I could do that." But you didn't. And that's why it's not your work on the wall.

Make more shit. Shit on other's work less.

> I doubt this dude is trying to "disrupt" the doorbell industry. It's just a fun challenge to solve.

Pretty much. :p

At the same time, I'll probably keep using this, since it does sort of fulfil a real need that I had (a doorbell that would actually take power without having to squeeze in too-large batteries).

"Make more shit. Shit on other's work less."

One of the best quotes I've seen this month.

The cool thing though is the flexibility it gives you. Want to get an mobile notification when someone rings the door? Easy! Want to add a morse code to unlock the door? No problem! Want to have a personalized ring tone? Sure, just trigger the camera, do some face recognition and send a custom sound to the speakers. Want to disable the bell after 11pm except on weekends and holidays? Just a small patch!

> Want to get an mobile notification when someone rings the door?

That one already works. And yes, that was part of the motivation. :p

Now I just need to figure out how to make Chrome Android consistently play sounds...

> Want to add a morse code to unlock the door? No problem!

That one probably wouldn't work. :/

The receiver is junk, so it's rate-limited to roughly the time between presses that there was in the video. Anything in between just gets ignored by the hardware.

I think what it does is forward the signal as a GCM event which is then played in your browser. RPi itself doesn't play the sound in this case.

But yes, it's strongly in the Rube Goldberg territory.

> I think what it does is forward the signal as a GCM event which is then played in your browser. RPi itself doesn't play the sound in this case.

Yup. I usually have headphones on, so I wanted it to play the sound where I'll actually hear it.

GCM was so I wouldn't have to bother with disconnection/reconnection logic with individial browsers (especially phones...) myself. Then again, the GCM API seems so incredibly unreliable that that might actually have been a net improvement.

we bought the same horrible door bell to our office. couldn't stand the sound either. hooked it up to a wind chime and slack in a similar way. http://labs.earthpeople.se/2015/01/how-to-make-a-wind-chime-...

That one's way more awesome!

About a year ago I was living in a place with a broken doorbell so I wrote a web page that would send me a text when it was loaded (hosted on my Pi). I then printed a QR code for the page that stated clearly "To ring bell, scan code". Users would scan the code which would immediately text "Ding Dong!", the page would let them enter their name. If they did I would receive a follow up text "It's [name]". Sadly in my year of living there only a handful of people ever used it.

That sounds cool! And I know it also seems pretty easy to do, but care to share the project? I'd love to take a look at it.

Note that it's written in Rust - the title or even the README.md doesn't say.

Is this a joke?

Partially. I'll probably keep using it, though.