That's what Amazon's IoT button is. A more expensive Dash button that you can control.

https://aws.amazon.com/iotbutton/

"Control", though, doesn't mean source code for the device, but rather, programmatic control over the endpoint (Lambda, etc). "You can code the button's logic in the cloud "

The first gen STM32 based Dash buttons were hackable[1], but Amazon changed to a different platform (ATMEL[2]) and locked them down.

[1]https://learn.adafruit.com/dash-hacking-bare-metal-stm32-pro...

[2]https://mpetroff.net/2016/07/new-amazon-dash-button-teardown...

Supposedly, though, you can associate your existing, regular Dash button to a different product: https://www.amazon.com/gp/aw/help/id=201730790

You could use https://metacpan.org/pod/Amazon::Dash::Button, and write your own handler in Perl using an ordinary Dash button.

But why would you ever use such an awkward language to do this task?

Perl is actually not a bad choice for matching a Mac address, and invoking some external event. Why would it be awkward?

Well it's more about the language being needlessly complicated and having 10x different ways to do the same thing, not to mention the language (Perl 5 that is - 6 is a different story) lacks essential concepts like object orientation and exceptions (you have to get "shims" like Moose or Try::Tiny from CPAN to fill those gaps). Why would you choose something like this instead of Python or Ruby?

>lacks essential concepts like object orientation and exceptions

Perl does OO without Moose. There is a tiny bit of boilerplate, but it's essentially bless() and 1 or 2 lines in the constructor.

Try/catch blocks are indeed an add on. The traditional pattern is more golang like, returning an error code, then using Carp or similar for stack traces.

>Why would you choose something like this instead of Python or Ruby?

That might be an interesting discussion for a large codebase, but for something limited in scope like this, I just don't see the problem.