Wifi audible alerter

This is a long shot, but… does anyone know of a battery powered box that can be used to generate an audible alert in response to a message that I send to it over wi-fi?

The context is making my front door bell audible when I’m in the garden. I’ve got the door bell interfaced to my old BeagleBoard, and thence to Pushover, so I get an audible notification on my mobile phone. This is very good, most of the time – the notification is usually audible about 1 second after the door bell button is pushed. Occasionally, though, the Pushover notification can be delayed by minutes or hours. We have reasonable wifi coverage in the garden, so I could well imagine sending a message from the BeagleBoard over wifi to an alerter in the garden.

Clearly this isn’t an emergency alert, so it doesn’t have to be hugely loud.

I could make myself something with an ESP12F and an LPC1114, for example, but when all the programming is done and the box cut and filed, etc… it makes me want to buy something off the shelf. If such a thing exists.

I would imagine if such a thing exists, it’s probably tied to some sort of service trying to push a “cloud” subscription, like so many of those little surveillance cameras these days…

If you have custom software on your Beagle, then it shouldn’t be hard to add a quick (can fail) fetch of http://192.168.1.x/notify to wake up a device based upon an ESP32 or 8266, which will simply sit awaiting somebody fetching /notify and when that happens, wiggle a GPIO to make a noise audible.

Building and uploading the firmware will likely take an order of magnitude more time than writing it in the first place ☺, plus you can later add all sorts of clever as you so desire (such as an answer back to acknowledge the notification).

Yes, but this involves building and prgramming the hardware, which I could perfectly well do, but I’m trying to avoid.

The BB is running RISC OS, and all the software involved is by me. Adding more is dead easy and I’d have to do that anyway, wherever the hardware comes from.

Messaging to other apps in the same system and other systems is something that was explored by Jaffasoft some years ago, the page referencing the ActiveApps implementation references the cross-platform 0MQ (aka ZeroMQ) – quite extensive use it seems.

Sort of follows the line from Rick, but in a more platform agnostic fashion.

Excuse me please. I am finding it very interesting that you are trying to solve all this using RISC OS. But what about using Smart-Home-Products for this purpose in parallel to your existing solution. E.g. I know that there is a bell ring detector for HomeMatic products. Of course you will also need an according alert device. At Homematic there is no according device AFAIK but you can build one quite easily from available other components. And there might be some electronic solutions which can be easily controlled via IO of the Beabgle Board.

The Beagle Board is in the computer room. The bell receiver is directly attached to it via short wires. Clearly the bell receiver has to be within a short range of the transmitter (which is at the front door). The computer room is almost above the front door.

So the detection is already there, and interfaced to the LAN through the BB and RISC OS. All the software was written by me, so it will be dead easy to add software to drive something else – in this case an audible alerter.

It’s the audible alerter that’s missing.

Yes, I could make one, I’ve done projects like that many times in the past… but I just don’t want to spend all that time doing it…

Having said that, I may have already started; I ordered a DC-DC converter that will convert the output of 4 cells and drop it to 3.3V for the electronics that I know will be required…

I don’t see the benefit of adding HomeMatic or any other Smart Home products, as all the software infrastructure is already there, up and running, and has been for a long time now. It’s easy for me to add to it, and nothing else to learn, no extra platform to run other software on, etc.

What about something like this?

Use output from beagle board, relay to operate button contact. Can probably use power from board for transmitter too.

Surely the relay should operate a powerful solenoid that fires a finger-shaped device at the button?

Another advantage of wifi is that the target device can perform a continual check that it’s within coverage, and give an alert if it’s not.

Plus you can add logic like if the signal to the AP gets weak or is lost, look to see what AP has the best signal.

I’ve built this into my ESP32 camera firmware, as in the living room the Livebox is the best signal, while in the bedroom it’s the Vonets. So when starting it will pick which gives the best signal.
I’ve not yet added detection for connection dropouts and a rescan to change. It’s probably a dozen lines of code, but it’s far simpler to just prod the reset button. ;) One day I’ll get around to it…

I wonder how feasible it is to use a mobile phone, perhaps KDE Connect or something similar.

perhaps KDE Connect or something similar

A cursory glance at KDE Connect’s docs suggests that I would need something like a Linux box between the BeagleBoard and the phone.

perhaps KDE Connect

Can’t help but feel that sort of thing is vastly overkill.

The beauty of rolling your own solution is that it can be as simple as it needs to be, doesn’t have to rely on brokers, third party servers, or the cloud… and can maybe even do something sensible in the event of a connection failure (unlike, say, those smart door locks that failed when the server crashed).

The unbeautiful part is, of course, rolling your own means building it and coding it, but, then again, you know what is going on so your hardware isn’t a data collection point for a Chinese company, and it won’t be feeding your SSID and password to the mothership (cheap cameras are notorious for doing stuff like this, as an http connection too!).

There’s also the little matter of working out how to interface into the sending end of KDE Connect, to get it to do something that it wasn’t designed to do.

A casual glance at the spec docs suggests it’s a more platform specific implementation of the same device to device comms idea as in ZeroMQ
Any good idea will happen repeatedly until someone’s brain takes notice :) Each brain will translate differently.