| HN Mirror

Baby monitors fundamentally need to be safe and allow parents peace of mind. Knowing they can constantly hear the baby and communicate verbally to soothe, as if you were in the room with them, allows this. It already means you only have to respond and/or get up to tend if they are still unsettled after a period of time. Monitors also have volume control so you can stay alert without being constantly disturbed.

The traditional baby monitor system had three states (ON and functional, ON and non-functional, OFF). It provides a constantly available and instantaneous test for "functional" - as long as you can hear sound from the other unit, it's almost guaranteed to currently be in a safe condition. Monitoring is constant, human-first, and all human. The system is relatively fail-safe.

Your design replaces this with a multi-state system and algorithms (adding ON in listening mode, ON in delay mode with output off, ON and partially-functional etc.). It removes any reliable method to prove an obviously "functional" state at any given time. Monitoring is non-constant (for the human), machine-first, and human as last resort (like corporate customer services). The system is not fail-safe despite being machine-first and at higher risk of error or malfunction due to complexity.

The risks include a few failed notifications or incorrect delay timing leading to early developmental trauma, such as fear of abandonment. It doesn't take much. We are still learning to deal with this human-human, before adding invisible unknowns.

If nothing else, what are babies likely to learn in a pre-verbal state where the days are spent sensing and observing their environment to develop the brain? It'll probably be how to game the baby monitor algorithm.

> Also during the day it's really handy to be notified when baby has woken up from her nap. Let's us be out of the house, or in a distant room, and still keep track of what's going on.

If you are going out of earshot of the baby by doing this, you are fully relying on the technology being functional. That would seem unnecessarily risky, and not nice for the baby (they can sense this stuff). The odds of a catastrophe are low in a singular environment, but still enough to worry. Almost inevitably it would end badly if this were scaled to a mass consumer product.

The idea is interesting from an engineering view, but from a human one it feels dystopian to insert a machine between parent and baby to this extent. It removes/replaces a layer of human-human connection. Where does engineering the natural human experience out of life end? Automated feeding? AI nannies and teachers? Then onto AI therapist?

My suggestion would be to do a lighter version of the features in a system which focuses on safety (always being able to monitor no matter what, for example on the ESP32, you could have the second core independent and direct-output the feed if the first core hangs or crashes). Feature-wise, rather than not alerting for 10 minutes, you could apply a DSP algorithm which reduces harsh frequencies for this period, whilst slowly increasing the output volume of the monitor.

I like the idea of alerts because it expands the base features without risk, and crucially makes the babies life better, as alerts could be sooner for important things that do need attention quickly. As an experiment, you could add an SD card and record snippets of cries which ended up in alerts, tag them with an ordered list of what you did to soothe or what was wrong, and see if AI can make anything of the data. Maybe certain cries can trigger alerts sooner, or cries over an extended period may indicate fever.