Ein RasPi, ein Arduino, ein Flusssensor, eine Webcam mit Mikro und etwas Python-Code sowie eine Spracherkennung bilden eine preiswerte, auf dem Wasserverbrauch basierende Aktivitätsüberwachung für alleinstehende Senioren.

Innerhalb der nächsten Jahre wird der Anteil der Menschen über 65 Jahre in unserer Gesellschaft so stark zunehmen, dass böse Zungen bereits von einem “Silbernen Tsunami” sprechen. Das Bundesamt für Statistik geht in seiner 12. koordinierten Bevölkerungsvorausberechnung davon aus, dass der Anteil der über 65-Jährigen im Jahr 2040 rund ein Drittel der deutschen Gesamtbevölkerung ausmacht [1]. In anderen Industrienationen ist eine ähnliche Entwicklung zu erwarten. Von den “jungen Alten” (65 bis 70 Jahre) werden bereits ungefähr 20 Prozent allein leben. Diese Zahl dürfte bei Männern mit zunehmendem Alter fast konstant bleiben. Bei Frauen erhöht sich aufgrund der unterschiedlichen Lebenserwartungen der Anteil der allein Lebenden auf 56 Prozent bei den über 80-Jährigen [2].

Stürze und die Angst vor Stürzen spielen in der Altersgruppe 65+ eine große Rolle. Verschiedene Studien zeigen, dass etwa ein Drittel der Betroffenen mindestens einmal pro Jahr stürzt, wobei fünf bis zehn Prozent der Stürze ernsthafte Folgen nach sich zieht. Das sind neben Knochenbrüchen und Kopfverletzungen lange Krankenhausaufenthalte, bleibende Einschränkungen und Tod, aber auch psychische Probleme.

Die Auslöser für Stürze gestalten sich vielfältig. Die Ursachen können Krankheiten wie Diabetes, Parkinson, Depression, Inkontinenz, Alzheimer oder physische Probleme wie eine schwach ausgeprägte Muskulatur, nachlassende Sehkraft, Verwirrung, Fußprobleme oder Untergewicht sein. Zu den weiteren Risikofaktoren zählen inaktives Verhalten, Medikamenteneinnahme und damit einhergehende Neben- oder Wechselwirkungen (verzögerte Reaktionen, niedriger Blutdruck), übermäßiger Alkoholgenuss, schlechtes Schuhwerk oder ungünstige Umgebungen mit glatten Fußböden beziehungsweise zu wenig Licht.

Allein Lebende, die nach einem Sturz aufgrund ihrer Verletzungen oder körperlichen Gebrechen nicht in der Lage sind, selbst aufzustehen und Hilfe zu holen, bleiben oft mehrere Stunden und länger unentdeckt (“Long Lie”). So werden pro Jahr 3,2 Prozent der allein Lebenden über 65 Jahre tot oder hilflos in ihren Wohnungen aufgefunden. Forscher stellten fest, dass die Hälfte der gestürzten Senioren, die lange hilflos auf dem Boden liegen, innerhalb eines halben Jahres versterben. Auch die psychischen Einschränkungen nehmen proportional zur Dauer der erlebten Hilflosigkeit zu.

An dem Problem tüfteln Wissenschaftler seit mehr als zwei Jahrzehnten. Bereits 1991 entstand ein aus Videoüberwachung und Beschleunigungssensoren bestehendes System, das helfen sollte, Stürze automatisch zu erkennen. In den darauf folgenden Jahren, besonders ab 1998, nahmen sich Wissenschaftler verschiedener Länder des Themas an und entwickelten verschiedene Technologien, die Stürze rechtzeitig erkennen und Helfer alarmieren sollen.

Entsprechende Lösungen setzen meist auf Beschleunigungssensoren, (3D-)Videoüberwachung sowie Bewegungs- und Drucksensoren. Es wurden aber auch schon Systeme mit NFC-Technik, Mikrofon-Arrays oder Sensoren an Gegenständen des täglichen Gebrauchs entwickelt und getestet. Die Verfahren fallen mit den Jahren immer ausgefeilter aus: So lässt sich inzwischen nicht nur feststellen, ob eine alleinstehende Person wohlauf ist, sondern auch, ob sie sich Tee oder Kaffee zum Frühstück kocht oder sich ihr Verhalten innerhalb eines mittelfristigen Zeitraums ändert, was ein Signal für beginnende Demenz sein könnte.

So ausgefeilt die ersonnenen Techniken sind, sie kranken in der Regel an mehreren Problemen: Sie erfordern Laborbedingungen, umfangreiche Umbauten der Wohnung, ein gehöriges Maß an technischem Verständnis oder eine Menge Geld – meist mehrere hundert oder gar tausende Euro. Preiswerte Lösungen, wie um den Hals getragene Alarmgeber oder umzuschnallende Beschleunigungssensoren scheitern oft an der Akzeptanz in der Zielgruppe, werden vergessen oder sind ganz einfach unpraktisch, weil sie etwa beim besonders sturzgefährlichen Duschen abgelegt werden müssen oder aktives Batteriemanagement erfordern.

Seheiah

Das hier vorgestellte System Seheiah [3] entstand im Rahmen eines Forschungsprojekts. Dessen Ziel war es, vor dem Hintergrund zunehmender Altersarmut und dem prognostizierten Mangel an Pflegekräften ein System für weniger als 100 Euro zu entwickeln, das auf dem täglichen Wasserverbrauch basierend diskret, wartungsarm und die Privatsphäre respektierend die Aktivität alleinstehender Personen überwacht und bei einem angenommenen Notfall Angehörige und Freunde informiert.

Es ist auch möglich, andere Ressourcen und Sensoren für die Aktivitätserkennung einzusetzen, aber der Wasserverbrauch scheint am einfachsten zu überwachen und am wenigsten störanfällig zu sein. Bei elektrischer Energie gibt es selbstständige Verbraucher wie Kühlschränke oder Luftentfeuchter, die mühsam herausgefiltert werden müssten. Bewegungsmelder, Lichtschranken oder Drucksensoren könnten durch Haustiere wie Hunde oder Wellensittiche irritiert werden.

Auf Hardwareseite basiert Seheiah auf einem Raspberry Pi Modell B, einem Arduino Uno, einem Flusssensor sowie einer USB-Webcam mit Mikrofon (Abbildung 1). Der Flusssensor wird hinter dem Hauptwasserschieber installiert, sodass sich auf einen Schlag alle Verbrauchsstellen beobachten lassen. Bei einer Wasserentnahme dreht sich innerhalb des Sensors ein kleiner Rotor. Ein integrierter Hall-Sensor registriert die Drehungen, die der Arduino liest und an den RasPi übermittelt. Die erfassten Werte sind dabei nachrangig: Der Flusssensor fungiert lediglich als Status-Sensor, der die Zustände “Wasser fließt” oder “Wasser fließt nicht” kennt.

Abbildung 1: Die Seheiah-Hardware: RasPi, Arduino Uno, Flusssensor und Webcam.

Neben dem Arduino hängt eine USB-Webcam mit integriertem Mikrofon am RasPi. Letztere dient der Sprachsteuerung und erstellt im Alarmfall ein Foto des Lebensraumes der alleinstehenden Person, das zusammen mit der Alarmmeldung versandt wird. Die gesamte Hardware kostet deutlich weniger als 100 Euro – wer kreativ ist und etwa anstelle des Flusssensors eine optische Maus als Sensor auf den Wasserzähler montiert, kann den Preis noch mehr drücken. Dem System liegen mehrere Anforderungen zugrunde:

• die zu überwachende Person lebt in einer Einzimmerwohnung,
• lebt einen geregelten Tagesablauf,
• hat Freunde und Familie, und
• verfügt über einen zuverlässigen Internetzugang.

Die Grundidee basiert darauf, dass Menschen über den Tag verteilt jede Menge Wasser verbrauchen, etwa für Toilettengänge, Körperhygiene, Nahrungszubereitung, Abwaschen, Blumengießen und anderes mehr. Über die mit dem Wasserverbrauch verbundenen Tätigkeiten lässt sich folglich feststellen, ob eine Person aktiv ihrem Tagesrhythmus nachgeht oder handlungsunfähig in der Wohnung liegt.

Um einen Notfall zu erkennen, speichert Seheiah für eine definierte Anzahl von Tagen ein aus Startzeit und Dauer der Wasserentnahmen bestehendes Ereignistupel in einer SQLite-Datenbank und erlernt so den Tagesrhythmus des alleinstehenden Rentners. Dabei akzeptiert es gewisse Toleranzen, sodass der Senior nicht täglich genau um 7 Uhr unter der Dusche stehen muss, um einen Alarm zu vermeiden, sondern beispielsweise zwischen 6:45 und 7:15 Uhr.

Bei der Auswertung unterscheidet Seheiah zudem zwischen Wochentagen sowie Wochenenden. Eine Aufzeichnungszeit von 10 Tagen würde daher zehn Wochentage und fünf Wochenenden umfassen, also insgesamt 20 Tage. Mittels der Anzahl der aufgezeichneten Tage kann Seheiah neues Verhalten schnell lernen, etwa wenn der Senior in der dunklen Jahreszeit eine halbe Stunde länger schläft.

Basierend auf den gespeicherten Werten prüft das System regelmäßig die Wahrscheinlichkeit eines Wasserverbrauchs innerhalb des erwähnten, frei wählbaren Intervalls. Die Höhe der Wahrscheinlichkeit lässt sich ebenfalls frei wählen, sodass selten auftretende Ereignisse nicht berücksichtigt werden.

Bei der Auswertung bildet Seheiah Intervalle mit einer Länge von l Sekunden. Tritt innerhalb eines Intervalls mindestens einmal eines der überwachten Ereignisse ein, gilt dieser Wert für das gesamte Intervall. Auf diesem Weg fasst Seheiah auch viele kurze, rasch aufeinanderfolgende Ereignisse zusammen. Mindestens drei aufeinanderfolgende Intervalle bilden einen “Verhaltensvektor” für die zurückliegenden n mal l Sekunden. Die Anzahl der Intervalle (“Intervallquantum” n) lässt sich prinzipiell frei wählen, sollte aber nicht zu groß ausfallen. Der Faktor n*l bildet auch die oben erwähnte Toleranz ab, indem er das Verhalten in der Vergangenheit mit dem aktuellen Verhalten abgleicht.

Neben dem in der Datenbank abgefragten Verhalten für das letzte Intervallquantum prüft Seheiah auch, ob gerade Wasser fließt. Die Daten schreibt es erst in die Datenbank, wenn der Wasserfluss beendet wurde, weshalb zu prüfen ist, ob und gegebenenfalls wie lange der Sensor bereits eine Aktivität feststellt.

Dazu ein Beispiel: Bei einem Intervall von 300 Sekunden und einem Verhaltensvektor von drei Intervallen prüft Seheiah bei einem möglichen abweichenden Verhalten zum Zeitpunkt t anhand der Aufzeichnungen, mit welcher Wahrscheinlichkeit das Verhalten auftreten kann. Bei der Datenabfrage sucht es jedoch im Zeitraum t ± (n*l) Sekunden – also eine Viertelstunde vor und nach dem aktuellen Zeitpunkt – nach Sensoraktivitäten.

Kritische Ereignisse ausmachen

Entnimmt der Senior innerhalb eines Beobachtungszeitraumes Wasser, lässt dieses aber nicht die ganze Zeit fließen, geht es ihm vermutlich gut. Kritisch sind solche Fälle, in denen kein Wasser fließt oder in denen lange Wasser fließt (etwa, weil der Beobachtete in der Dusche gestürzt ist). Um kritische Fälle zu erkennen, normiert Seheiah den Verhaltensvektor und nimmt anschließend eine Fallunterscheidung vor.

Dazu fragt es für jeden Wert im Verhaltensvektor in der Datenbank ab, wie es zu diesem Zeitpunkt in der Vergangenheit aussah. Dabei berücksichtigt es sowohl die Toleranz als auch den Unterschied zwischen Wochentagen und Wochenenden oder Feiertagen. Alle gefundenen Ereignisse im Zeitraum t ± (n*l) Sekunden summiert Seheiah und teilt den Wert durch die Anzahl beobachteter Tage. So bildet es die Laplace-Wahrscheinlichkeit P(e_t).

Beim “idealen” Rentner, der jeden Tag daheim ist und zur selben Zeit innerhalb des Toleranzzeitraumes Wasser verbraucht, beträgt die Laplace-Wahrscheinlichkeit 1, im wirklichen Leben fällt sie meist geringer aus. Darum nutzt Seheiah einen Schwellwert für ziemlich sicheres Verhalten, der auch berücksichtigt, dass der Senior mal verschläft oder der geregelte Tagesablauf vereinzelt abweicht. Bei einer Wahrscheinlichkeit unterhalb dieses Schwellwerts berücksichtigt Seheiah die Ereignisse nicht. Das unterbindet, dass selten auftretende Ereignisse (Besuch geht auf Toilette, schwitzende Bauarbeiter bitten um ein Glas Wasser etc.) gewertet werden.

Die Wahrscheinlichkeitswerte erfasst Seheiah in einem “historischen Verhaltensvektor”, den es anschließend mittels Kosinus-Ähnlichkeit mit dem normalen Verhaltensvektor vergleicht. Auch hier kommt zur Erkennung unüblichen Verhaltens ein Schwellwert zum Einsatz, der mit der Anzahl der betrachteten Intervalle n korreliert. Für den Standardwert n=3 wäre beispielsweise 0,7 ein guter Ausgangsschwellwert. Tritt mehrmals 3n Intervalle hintereinander eine Laplace-Wahrscheinlichkeit unterhalb des Schwellwerts auf, stößt Seheiah die Alarmkaskade an (Abbildung 2).

Abbildung 2: Das Flussdiagramm der Sturzerkennung von Seheiah.

Es ist möglich, das System über Abwesenheit zu informieren. Verabschiedet sich der Senior beim Verlassen der Wohnung höflich mit “Seheiah bye bye”, wertet das System kritische Ereignisse nicht aus. Jede spätere Wasserentnahme aktiviert es automatisch wieder.

Alarmkaskade

Die Alarmkaskade informiert Angehörige oder Pflegepersonal über einen vermutlichen Sturz. Sie kommuniziert mit der Aktivitätsüberwachung und Spracherkennung über einen Unix-Socket. Alle dort empfangenen Nachrichten (ALARM, UNEXPECTED BEHAVIOR, FINE, WATERFLOW) werden interpretiert. Stellt die Aktivitätserkennung ein abweichendes Verhalten fest, sendet sie die Nachricht UNEXPECTED BEHAVIOR an die Alarmkaskade. Diese spielt eine Audio-Datei ab, die den Senior auffordert, sein Wohlergehen zu bestätigen (Nachricht FINE). Dafür hat er zwei Minuten Zeit.

Fehlalarme können relativ häufig auftreten, je nachdem, welche Werte für Intervalle, Verhaltensvektoren oder Schwellwerte gesetzt wurden. Auch Verhaltensänderungen lösen solche aus, etwa wenn der Sturzgefährdete morgens eine halbe Stunde länger schläft. Geht es dem Senior gut, kann er den Alarm durch ein einfaches Sprachkommando (“Seheiah Alarm aus”) abbrechen. Ein Fehlalarm ist für den Senior nicht mehr als eine lästige Störung, die deutlich weniger kostet als ein (von Angehörigen oder Pflegedienst unbemerkter) Sturz.

Bestätigt der Rentner innerhalb einer vorgegebenen Zeitspanne sein Wohlergehen nicht oder empfängt die Alarmkaskade die Nachricht ALARM, löst dies einen Alarm aus. Dazu macht die Webcam ein Foto, das anschließend zusammen mit der Aufforderung, sich um den Rentner zu kümmern, per E-Mail an eine Empfängerliste versendet wird (Abbildung 3).

Abbildung 3: Das Flussdiagramm der Alarmkaskade von Seheiah.

Installation und Inbetriebnahme

Seheiah [3] selbst ist relativ leicht zu installieren. Dazu laden Sie lediglich die Python-Skripte herunter und installieren die in der Anweisung genannten Pakete mittels apt-get.

Bei Seheiah handelt es sich um einen in Python 2.7 implementierten Daemon, der aus vier nebenläufigen Threads (Datenbank, Verhaltensüberwachung, Alarmkaskade, Spracherkennung) besteht. Die Konfiguration erfolgt über die zentrale Datei seheiah.cfg. Die Datenbank richten Sie über folgenden Befehl ein:

$ sqlite3 Name.db < PfadZuSeheiah/helpers/activity_log.sql

Der Flusssensor erfordert einige Bastelei, denn er muss mit einem Vorwiderstand versehen werden [4]. Den Arduino-Sketch zum Auslesen finden Sie unter PfadZuSeheiah/helpers/flowmeter.c.

Eine Udev-Regel wie in Listing 1 sorgt dafür, dass der Arduino möglichst immer an derselben Schnittstelle auftaucht und nicht mal als /dev/ttyUSB0 und ein anderes Mal als /dev/ttyUSB1 erkannt wird. Die nötigen Parameter liefert der Befehl lsusb, nachdem Sie das Mikroprozessorboard mit dem RasPi verbunden haben. Der ausführende Nutzer sollte tunlichst der Gruppe plugdev angehören, damit später die vom Arduino gesendeten Daten problemlos gelesen werden können.

#/etc/udev/rules.d/70-microcontrollers.rules
#arduino uno
SUBSYSTEMS=="usb", KERNEL=="ttyACM[0-9]*", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0001", SYMLINK+="sensors/arduino_%s{serial}", MODE="660", GROUP="plugdev"
#seeeduino
SUBSYSTEMS=="usb", KERNEL=="ttyUSB[0-9]*", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="sensors/arduino_%s{serial}", MODE="660", GROUP="plugdev"

Spracherkennung

Den meisten Aufwand erfordert die Spracherkennungssoftware. Seheiah verwendet Pocketsphinx [5] und generiert ein eigenes Akustikmodell. Das hat den Vorteil, dass es direkt für den zukünftigen Nutzer optimiert ist und undeutliche Aussprache sowie Dialekte keine Probleme bereiten. Der Nachteil: Das Akustik-Modell muss intensiv trainiert werden.

Nach abgeschlossenem Training genügen die vier Befehle ALARM AUS, BYE BYE, HILFE und TEST, um Seheiah zu steuern. Diesen wird jeweils der Trigger SEHEIAH vorangestellt, um Fehlerkennungen zu vermeiden. Es wäre beispielsweise tragisch, wenn Oma nach einer längeren Reise wieder daheim ist, sich telefonisch bei ihren Lieben zurückmeldet, sich dabei mit “Bye bye” verabschiedet und kurz danach über ihren Koffer stürzt.

Um Seheiah per Zuruf steuern zu können, benötigt man neben Pocketsphinx auch noch Sphinxbase [6] und Sphinxtrain [7]. Hinzu kommen noch eine Reihe Abhängigkeiten, die folgender Befehl nachzieht:

$ sudo apt-get install cython python-gst0.10 python-gst0.10-dev gstreamer-tools gstreamer0.10-plugins-base libpulse-dev gstreamer0.10-pulseaudio

Seheiah ruft Pocketsphinx über eine Gstreamer-Pipeline auf. Die Zeile export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-0.10 in der Datei ~/.profile sorgt dafür, dass das entsprechende Plugin später ohne viel Gefrickel gefunden wird. Ferner sind noch einige Anpassungen nötig, um sich später einige Überraschungen zu ersparen. Im Sphinxbase-Verzeichnis löschen Sie python/sphinxbase.c, im Pocketsphinx-Ordner python/pocketsphinx.c. Beide sind fehlerhaft und werden während des Installationsprozesses von Cython neu generiert.

In den Dateien gstpocketsphinx.c und gstvader.c im Verzeichnis /pocketsphinx-0.8/src/gst-plugin setzen Sie die Sample-Rate von 8000 auf 16000 (rate = (int) 16000). Eine Rate von 8000 Hz eignet sich nur für Spracherkennung via Telefon.

Nach diesen Vorarbeiten installieren Sie Sphinxbase, Pocketsphinx und Sphinxtrain jeweils mit ./configure, make clean all und sudo make install.

Akustikmodell

Für das Training des Akustikmodells bringt Seheiah bereits ein Sprachmodell sowie einige Konfigurationsdateien (PfadZuSeheiah/acoustic_model/) mit. Die lästige Pflicht vor der Kür ist das Aufnehmen von genügend Rohmaterial. Die Sphinx-Entwickler nennen als Basis fünf Stunden Audio-Material bei einem Sprecher und geringem Vokabular.

Im Test ließen sich bereits mit 50 Wiederholungen jedes Kommandos sehr brauchbare Resultate erzielen. Um auf die von den CMU-Sphinx-Entwicklern empfohlene Trainingsmenge von fünf Stunden zu kommen, müssten Sie jedes Kommando rund 500 Mal üben. Die Aufnahmen speichern Sie im Unterverzeichnis wav/ mit folgendem Befehl:

$ arecord -r 16000 -D hw:1,0 -d 5 -f S16_LE -c 1 Name#.wav

Dateinamen der Form Name#.wav dienen für Testzwecke, es gibt je drei Exemplare für alle vollständigen Kommandos mit Trigger (SEHEIAH + Kommando). Die Dateinamen für die einzelnen Kommandos zeigt die Tabelle “Dateinamen und zugehörige Kommandos”. Mit AUS tat sich Pocketsphinx im Test schwer. Das wichtige Kommando HILFE sollten Sie intensiv üben.

Die Anzahl der Dateien können Sie selbst festlegen, indem Sie im Verzeichnis etc/ des Akustik-Modells die Dateien 7646_test.fileids, 7646_test.transcription, 7646_train.fileids und 7646_train.transcription anpassen. Achten Sie dabei peinlich genau darauf, dass der Eintrag in der n-ten Zeile der Datei Name.fileids der Datei Name.transcription entsprechen muss, um einem späteren wunderlichen Verhalten der Spracherkennung vorzubeugen.

Liegen die Dateien vor, stoßen Sie den Trainingsprozess im Verzeichnis PfadZuSeheiah/acoustic_model/ mit dem Kommando sphinxtrain run an. An dessen Ende erfolgt jedes Mal eine Prüfung mithilfe der Testdateien, um den Erkennungsgrad zu ermitteln (Abbildung 4). Während des Trainings bietet es sich an, die Kommandos von verschiedenen Positionen im Zimmer zu geben und dabei den Aufnahmepegel zu optimieren.

Abbildung 4: 20 Übungseinheiten pro Kommando ziehen noch eine hohe Fehlerquote nach sich. Besser sind 50 Trainingssätze pro Kommando, optimal wären 500.

Bei der Spracherkennung selbst meckerte der RasPi in Verbindung mit Alsa permanent, dass der Aufnahme-Stream nicht schnell genug interpretiert werden könne. Abhilfe schaffte ein Wechsel auf Pulseaudio, was mit überraschend vielen Konfigurationsschritten verbunden war, ehe die Spracherkennung reibungslos funktionierte [8]. Zunächst müssen Sie den ausführenden Nutzer der Gruppe pulse-access hinzufügen:

$ sudo adduser username pulse-access

Des Weiteren gilt es, eine /etc/asound.conf zu erstellen (Listing 2), in der /etc/default/pulseaudio müssen Sie den Wert von DISALLOW_MODULE_LOADING auf null setzen. In der Datei /etc/libao.conf geben Sie pulse anstelle von alsa als Standardtreiber an. Weitere Änderungen betreffen das File /etc/pulse/daemon.conf (Listing 3).

#/etc/asound.conf
pcm.pulse {
    type pulse
}
ctl.pulse {
    type pulse
}
pcm.!default {
    type pulse
}
ctl.!default {
    type pulse
}

#/etc/pulse/daemon.conf
daemonize = yes
high-priority = yes
nice-level = 5
exit-idle-time = -1
resample-method = src-sinc-medium-quality
default-sample-format = s16le
default-sample-rate = 48000
default-sample-channels = 2"

Fazit und Ausblick

Seheiah wurde bisher nur in zwei Haushalten installiert und getestet. Hier zeigte sich, dass ein regelmäßiger Tagesablauf die Voraussetzung dafür bildet, Stürze zuverlässig zu erkennen (Abbildung 5). Außerdem gilt es, mit den Schwellwerten zu experimentieren. Das System erkennt Stürze nur dann zeitnah, wenn sie direkt vor einem sich regelmäßig wiederholenden Ereignis eintreten, etwa beim nächtlichen Sprint auf die Toilette, oder wenn sie mit einem ungewöhnlich hohen Wasserverbrauch einhergehen, etwa der Senior unter der laufenden Dusche ausrutscht.

Abbildung 5: Eine Visualisierung der in der Seheiah-Datenbank gespeicherten Tupel in Fünf-Minuten-Intervallen.

Stürzt ein Senior beim Verlassen der Dusche oder auf dem Rückweg ins Bett, dauert es im schlimmsten Fall mehrere Stunden, ehe Seheiah den Sturz erkennt. Im besten Fall bleibt der Gestürzte bei Bewusstsein und verfügt noch über eine klare, vom Schmerz nicht verzerrte Aussprache, sodass er Seheiah anweisen kann, einen Hilferuf abzusetzen.

Das System soll in der nächsten Zeit weiterentwickelt und mit zusätzlichen Funktionen versehen werden. So wollen die Entwickler den Nutzern frei wählbare Kommandos und Trigger ermöglichen und einen VoIP-Client einbinden, sodass Hilfsbedürftiger und Helfer permanent in Kontakt stehen können.

Ferner soll Seheiah auch regelmäßige, aber nicht tägliche Ereignisse erkennen. Denkbar wären auch ein generisches akustisches Modell für die Spracherkennung, das auf den Trainingsdaten vieler verschiedener Sprecher basiert, sowie eine Hilfsanwendung, mit der sich sinnvolle Werte für Intervalle und Schwellwerte ermitteln lassen.