Wandern Notfallmeldung

Weil ich oft alleine auf Wanderungen gehe und dabei natürlich verunglücken könnte, hatte ich schon öfter das Bedürfnis, für so einen "Fall" vorzusorgen. Allerdings habe ich bislang kein geeignetes Service dafür am Internet gefunden, auch nicht beim Alpenverein oder den Naturfreunden, wo man so eine Möglichkeit ja am ehesten vermuten könnte. Darum halte ich hier nun einfach die Spezifikation davon fest, die mir vorschwebt. Vielleicht ergibt sich ja irgendwann die Möglichkeit, so ein Web-Service zu implementieren und dann irgendwo zu installieren. Immer mehr Wanderer gehen verloren und werden, wenn überhaupt, erst Tage später aufgefunden. Am Tiroler Stubaigletscher stürzen angeblich jedes Jahr etwa 15 Menschen in Gletscherspalten.

Wer glaubt, dass es "heutzutage" reicht, ein Smartphone mit Internet dabeizuhaben, der irrt sich. In vielen Regionen in den Bergen hat man keine Verbindung, das nennen die Experten "Funkloch". Wenn es kalt ist, geben Batterien, die ohnehin meist nur zwei Tage halten, recht schnell auf, und gegen Nässe sind die Geräte auch nicht immer ausreichend abgedichtet, abgesehen davon, dass sie beim Unfall kaputt werden könnten. Also braucht es eine Absicherung, die unabhängig von Standort, Ausrüstung und Wetter ist, die sozusagen "von außen" zusieht.
Übrigens, falls ihr Telefon-Glück im Unglück habt: die europaweite Notfallnummer ist 112, in Österreich 140. Die E-Mail Adresse der niederösterreichischen Bergrettung ist office@bergrettung-nw.at .

Spezifikation

Das Konzept: von einem immer laufenden Web-Service soll eine E-Mail gesandt werden an eine Person oder Organisation, wenn der Ersteller dieser Notfallmeldung sie nicht bis zu einem bestimmten Endzeitpunkt am Web-Service deaktiviert. Der Ersteller muss also

vor seiner Wanderung eine Meldung aktivieren und
nach seiner Wanderung diese Meldung deaktivieren, wenn es keinen Unfall gab.

Die Meldung soll für viele Wandertermine wiederverwendbar sein und wird bei jeder Aktivierung mit neuem Beginn- und Endzeitpunkt und neuer Wegbeschreibung versehen. Jeder Benutzer des Web-Services hat seine eigene Notfallmeldung.

Teilnehmende Akteure sind:

Wanderer (muss vor und nach der Wanderung Internetzugang haben)
Web-Service (sendet und empfängt E-Mails, stellt Notfallmeldungsformular zur Verfügung)
Kontaktperson und 0-n Stellvertreter, inklusive Rettung (treten in Aktion wenn Notfall eintritt)

1 Anwendungsfälle

1.1 Wanderung ohne Unfall

Am Tag vor meiner Wanderung gehe ich ins Internet und aktiviere eine Notfallmeldung. Die Meldung ist an die E-Mail meines Onkels adressiert, der über Smartphone immer erreichbar ist. Ich trage als Endzeitpunkt den nächsten Tag 6 Uhr abends ein, weil ich sicher bin, dass ich dann schon wieder zuhause sein werde und die Meldung vorher deaktivieren kann. Ich gebe meinen Ausgangspunkt und mein Ziel an und beschreibe den Weg dazwischen, den zu nehmen ich beabsichtige. Dann sichere ich die Meldung und aktiviere sie dadurch. Der Text der Meldung beschreibt, wie der Empfänger zu reagieren hat, wenn er sie erhält, und diverse Notfallnummern. Auch die gemachten Ortsangaben werden enthalten sein.

Am nächsten Tag komme ich um 4 Uhr nachmittags zurück und deaktiviere die Meldung, bevor sie an meinen Onkel gesandt wird. Er wird also durch meine Maßnahme in keiner Weise belästigt.

1.2 Unfall bei Wanderung in Funkloch

Ich habe am Tag vorher eine Notfallmeldung aktiviert und verletze mich bei der Wanderung so übel, dass ich nicht mehr weiter gehen kann. Mein Smartphone hat keine Verbindung zur Außenwelt oder ist kaputt, ich bin außer Rufweite jeder Siedlung.

Mein Onkel erhält um 6 Uhr abends die Notfallmeldung an seine E-Mail Adresse und sieht sie auch gleich. Die Meldung fordert ihn auf, eine Kontaktaufnahme mit mir zu versuchen. Er ruft mich an, erreicht mich aber nicht. Wie in der Meldung angegeben verständigt er dann die Rettung und leitet ihnen auch meine Wegbeschreibung weiter, die in seiner E-Mail enthalten ist. Die Meldung fordert ihn auch dazu auf, eine RE-Mail zu senden, dass eine Maßnahme ergriffen wurde. Durch das Absenden dieser verhindert mein Onkel, dass nach 1 Stunde die nächste stellvertretende Kontaktperson benachrichtigt wird.

Die Rettung findet mich (spät aber doch) und transportiert mich ab.

1.3 Unfall bei Wanderung ohne Funkloch

Ich habe am Tag vorher eine Notfallmeldung aktiviert und verletze mich bei der Wanderung. Allerdings kann ich telefonieren und benachrichtige selbst die Rettung. Ich deaktiviere die Notfallmeldung über mein Smartphone, um meinen Onkel nicht zu belästigen. Sollte das nicht funktionieren, kann ich meinen Onkel auch anrufen und vor der Notfallmeldung warnen.

Die Rettung findet mich bald nach dem Unfall.

1.4 Kontaktperson reagiert nicht

Ich bin in einem Funkloch verunglückt und die Notfallmeldung wird an meinen Onkel versandt, aber er reagiert aus irgendeinem Grund nicht.

1 Stunde nach dem Absenden der E-Mail an meinen Onkel stellt das Web-Service fest, dass keine Bestätigung von meinem Onkel eingetroffen ist. Es sucht daher nach stellvertretenden Kontaktpersonen und probiert eine nach der anderen, wobei immer 1 Stunde gewartet wird, ob jemand reagiert. Wenn niemand reagiert, wird nach dem letztem Stellvertreter die Rettung direkt benachrichtigt. Nachdem jemand nicht reagiert hat, wird ihm eine zweite E-Mail gesandt mit der Mitteilung, dass nun der nächste Stellvertreter kontaktiert wurde, ansonst könnte es geschehen, dass mehrere Kontaktpersonen gleichzeitig aktiv werden.

1.5 Zu spät von der Wanderung heimgekommen

Meine Wanderung war ohne Unfall, aber ich habe den Zug nach Hause verpasst. Ich hatte mich selbst bei der Notfallmeldung als erste Kontaktperson eingetragen, sodass das Web-Service als erstes an mich eine E-Mail sendet. Dadurch kann ich mit der E-Mail Anwendung auf meinem Smartphone beim Warten am Bahnsteig die Deaktivierung selbst vornehmen, indem ich darauf antworte und dabei sicherstelle, dass die "MAIL-ID" (uniqueMessageIdentifier) im Text enthalten ist, oder die empfangen Mail als "Anhang" bei der Antwort mitgesandt wird. Dadurch breche ich die Sendeschleife an alle Kontakte ab und verhindere, dass weitere Personen unnötig beunruhigt werden.

1.6 Deaktivierung vergessen

Meine Wanderung war ohne Unfall, aber wieder zuhause angekommen habe ich vergessen die Notfallmeldung zu deaktivieren. Da mein Onkel in der E-Mail angewiesen wird, zuerst mit mir Kontakt aufzunehmen, kann ich mich nun bei seinem Anruf entschuldigen, dass ich die Deaktivierung vergessen habe.

Ich hätte auch mich selbst bei der Notfallmeldung als erste Kontaktperson eintragen können, sodass das Web-Service als erstes an mich eine Notfallmeldung gesandt hätte, bevor es als Stellvertreter nach 1 Stunde meinen Onkel verständigt hätte. Durch diese Verständigung wäre ich rechtzeitig an die Deaktivierung erinnert worden, bevor mein Onkel beunruhigt worden wäre.

2 Daten einer Notfallmeldung

2.1 Wiederverwendbar für beliebig viele Wanderungen: Contact, Alert

Eine Kontaktperson und 0 - n Stellvertreter
- E-Mail Adresse (Pflichtfeld)
- Name
Text mit Name und Adresse des Wanderers, Mitteilung des Notfalles und schrittweiser Beschreibung der Vorgangsweise bei Erhalt der Meldung

2.2 Spezifisch für eine Wanderung: Hike

Start, Ziel und Wegbeschreibung der Wanderung, für Retter gedacht
Datum und Uhrzeit, wann die Notfallmeldung abgeschickt werden soll
Anzahl der Stunden und Minuten, nach denen die nächste Kontaktperson angeschrieben werden soll, wenn keine Rückmeldung eintrifft, Standard ist 1 Stunde

2.3 UML Klassendiagramm

(Click arrow to see Plant-UML code)

@startuml

title Hiking Emergency Data

class Hike {
  +String uniqueMessageIdentifier
  +String route
  +Date plannedBegin
  +Date plannedHome
  +Integer messageIntervalMinutes
  +Alert alert
  +List contacts
}

class Alert {
  +String helpRequestText
  +String procedureTodos
  +String passingToNextText
  +String addressOfHiker
  +Contact hikerContact
}

class Contact {
  +String eMail
  +String name
}

Hike "0..*" -- "1" Alert
Alert "1" -right- "1" Contact
Contact "1" -- "0..n" Contact: hiker contacts

@enduml

3 Zustände

3.1 UML Aktivitätsdiagramm

(Click arrow to see Plant-UML code)

@startuml
Title Hiking Emergency States

State HikerRegistered
State HikeActivated
State OnTheWay
State HomeAgain
State OverdueAlert
State AlertConfirmed

HikerRegistered -right-> HikeActivated : activation
HikeActivated --> OnTheWay : setting off
OnTheWay --> HomeAgain : coming home
OnTheWay --> OverdueAlert : overdue-alert
OverdueAlert --> OverdueAlert
OverdueAlert -down-> AlertConfirmed : alert confirmed

note top of HikerRegistered
    The hike has been
    described in a reusable
    emergency message and
    a list of alert contacts
    was connected.
end note

note right of HikeActivated
    The hike's planned begin 
    and home time was given, 
    typically done before
    leaving home.
end note

note right of OnTheWay
    The hike's planned
    begin time is over.
end note

note bottom of HomeAgain
    The hiker deactivated
    the emergency alert, 
    or was the first alert
    contact and answered
    the emergency message.
end note

note left of OverdueAlert
    The hike's planned home time
    is over.
    
    An emergency message gets sent 
    to the first/second/.../last
    alert contact, with 1 hour delay
    between each attempt. 
    
    When a contact did not answer
    after that delay, a second message
    is sent to him, saying that the
    next contact already was notified.
end note

note left of AlertConfirmed
    One of the alert contacts
    answered the emergency message.
end note

@enduml

3.2 Zustand-Übergang Tabelle

→ State ↓ Event	HikerRegistered	HikeActivated	OnTheWay	OverdueAlert	HomeAgain / AlertConfirmed
REGISTRATION (user)	→ HikerRegistered (or update)	🚫	🚫	🚫	→ HikerRegistered
ACTIVATION (user)	→ HikeActivated	→ HikeActivated (update)	🚫	🚫	→ HikeActivated
SETTING_OFF (timer)	🚫	→ OnTheWay	🚫	🚫	🚫
COMING_HOME (user)	🚫	→ HomeAgain	→ HomeAgain	→ HomeAgain	👍
OVERDUE_ALERT (timer)	🚫	🚫	→ OverdueAlert	→ OverdueAlert	🚫
ALERT_CONFIRMED (user)	🚫	🚫	🚫	→ AlertConfirmed	👍 / 👎

Legende:

🚫	Illegaler Zustand, Implementierungsfehler
👍 / 👎	Legaler Endzustand
→ Xxx	Folgezustand

Fazit

Ich denke so ein Service sollte in 5 Tagen implementiert sein. Als Basis könnte man den source-code eines open-source E-Mail Servers nehmen. Wenn sich also irgendeine Institution angesprochen fühlt: damit kann man sein öffentliches Image aufbessern und möglicherweise sogar Menschenleben retten!

UPDATE 2025-12-15:
Habe am Internet dieselbe Idee in Indien entdeckt. Diese Lösung baut allerdings auf Whatsapp und schließt daher alle aus, die entweder kein Smartphone oder kein Whatsapp haben. Außerdem saugt sie Benutzerdaten bis auf die Blutgruppe und Gesichtserkennung. Einmal ein Benutzerkonto erstellt kannst du es nicht mehr löschen.

UPDATE 2025-12-28:
Ich habe den source-code des Java Mail-Servers "James" heruntergeladen, der POP3, IMAP, SMTP und einige andere Mail-Protokolle unterstützt. Aber das ist ein Monster. Auch wenn "modular" aufgebaut glaub ich nicht, dass das das geeignete Mittel für meine Notfallmeldung ist. Da gibt es noch einige andere Mail-Lösungen in Java:

SubEthaSMTP sieht ganz brauchbar aus.
Aspirin sieht nicht sehr brauchbar aus, SMTP senden ohne externen Mail-Server, sonst nichts. Auch scheint nicht jede gesendete Mail anzukommen, weil bestimmte Sicherheitsdaten nicht vorhanden sind (SPF mail authorization). Ist auch ein eingefrorenes Projekt.

Theoretisch könnte ich auch eine simple Java/Swing Anwendung schreiben, die jedermann benutzen könnte, der Mail senden und empfangen kann. In diesem Fall müsste jeder Benutzer selbst den von ihm benutzten Mail-Server einmal konfigurieren, wenn er die Anwendung in Betrieb nimmt. Der workflow könnte dann über mail-polling (alle X Minuten) und eine Notfall-Mailadressliste abgehandelt werden.
Allerdings muss diese Anwendung vor der Wanderung gestartet werden, und sie muss dann (inklusive Internetanschluss) laufen bis der Wanderer zurückkommt. Für mehrtägige Wanderungen, bei denen man zwischendurch nicht nach Hause kommt, ist das nicht so gut, es sei denn, man registriert vor der Wanderung alle Tage einzeln. Es sollte sich ja jede einzelne Notfallmeldung über eine OK-Mail deaktivieren lassen. Für diesen Fall bräuchte man nicht einmal Persistenz zu implementieren, die Notfallmeldung könnte einfach im Hauptspeicher gehalten werden.

Da filebrowser10 bereits über mail-packages und einen Mail-Server Konfigurationsdialog verfügt, könnte man das dort als toolbar-button implementieren.

Statt des Home-Computers könnte man die Server-Arbeit vielleicht einen raspberry machen lassen? Interessant wäre es auch, eine Notfallmeldung über eine Mail aktivieren zu können, d.h. alle für die Notfallmeldung notwendigen Daten treffen über ein "Mail-Formular" ein und können vom Mail-Server interpretiert werden.

UPDATE 2026-01-01:
Ich habe ein Zustandsdiagramm hinzugefügt, inklusive Plant-UML code.

→ Hallo, dieses Blog zeigt HTML Element <summary> (Sub-Element von <details>) nicht richtig an, das expand-control Pfeilchen fehlt! Man muss extra die CSS-property display:list-item setzen, damit es funktioniert!

UPDATE 2026-02-03:
Die Anwendung steht nun zur Verfügung auf github. Das ist ein "Home-Server", implementiert in der plattformunabhängigen Programmiersprache Java, die Oberfläche ist Swing.

Durchsuchen

Mein Ruhestand Weblog