Grannophone

Namensherkunft:

„Granny“ als Begriff für Senioren, Klang von „Grannophone“ ähnlich „Grammophon“, einem auch schon etwas älteren technischen Gerät.

Grundidee:

  • Videotelefonie auf Basis
    • freier Software → zukunftssicher, nicht Anbietergebunden
    • kostengünstiger, verfügbarer Hardware → deswegen Raspberry Pi
  • ein für Senioren einfach zu bedienendes Endgerät:
    • gar kein oder nur ein Bedienknopf,
    • Telefonhörer als vertrautes Bedienkonzept → selbst mit beginnender Demenz noch bedienbar
  • ein technisch versiertes Familienmitglied betreut die Zentrale/Vermittlung für die ganze Verwandtschaft
  • jeweils ein Familienmitglied/eine Familie ist Kontaktperson für einen Senior/eine Seniorin
  • im Ergebnis hoffentlich ein System, mit dem auch zu Pandemiezeiten Kontakt mit der älteren Generation gehalten werden kann

Konzept/Ausbaustufen:

Anrufe sind in der ersten Ausbaustufe immer nur zwischen einem der Grannophone und der Zentrale/Vermittlung (oder einem festgelegten anderen Grannophone als „designated Contact“) möglich. Die Zentrale/Vermittlung nutzt ein herkömmliches „Softphone“ mit Videosupport, oder ein „aufgebohrtes“ Grannophone.

In einer zweiten Ausbaustufe kann überlegt werden, ein Grannophone mit einem anderen, vielleicht auch „offeneren“ (mehr Zielwahltasten) videofähigen Endgerät zu verbinden, die beide an der Zentrale/Vermittlung eingebucht sind. Damit kann eine Familien-Endstelle mehrere Omas/Opas „bespaßen“, ohne dass sie zwei separate Grannophone braucht. Das wäre z.B. dann interessant, wenn Oma und Opa in unterschiedlichen Heimen untergebracht sind, oder Oma noch eine Schwester hat, die ebenfalls bespasst werden soll/muss, oder so. Und genauso, wenn Oma/Opa noch geistig fit genug ist, das Konzept von Zielwahltasten zu begreifen (kann man ja mit entsprechend großen Schaltern und Fotos versehen) - dann kann Oma auch ihre Schwester damit anrufen und nicht nur die Kinder/Enkel.

Konferenztelefonate aufbauen sollte dagegen nur von der Zentrale/Vermittlung oder von der Familien-Endstelle funktionieren, wenn überhaupt technisch möglich → Ausbaustufe drei. Vielleicht noch nicht für Weihnachten 2020, aber für Ostern 2021 dann?

Fancy und daher auch frühestens für Ausbaustufe drei: Sprachwahl im Stil von Alexa, Siri und Co (vielleicht auch Freisprechen, wenn man das Echo/den Hall in den Griff bekommt) - aber ohne Cloudanbindung. Wird aber nur für die ganz arg fitten Senioren taugen. Oder eben für die Familien-Endstelle.

Weitere optionale Ausbaustufe: Abgesetzter zweiter Raspi (3,3B+,4 oder Zero W), mit Kamera und HDMI, damit Grannophone und TV keine Kabelverbindung brauchen (Kopplung per WLAN oder BT)

Clientseite:

Problem: Hardwareauswahl, Raspi 3B, 3B+, oder 4B? Wenn 4B, wie viel RAM?
Lösung:  Performancetests machen. 3B und 4B mit 8GB RAM sind vorhanden.
         3B+ und 4B mit weniger RAM fehlen noch in der Sammlung.
         Was Webcam und Jitsi angeht, kommt ein 3B arg ins Schwitzen
         und stottern, aber vielleicht ist das ja mit einer
         einzelnen SIP-Verbindung statt Browser mit Jitsi nicht so
         CPU-intensiv?
         4B mit 8GB sollte problemlos gehen. Falls nicht: Irgendwas
         in Richtung APU2, nur mit HDMI-Out Onboard. Braucht dann
         Raspi Zero mit Cam oder klassiche USB-WebCam. NVIDIA Jetson
         Nano 2GB DevKit wäre auch eine Option - oder ein "UP" - die
         packen Intel-Hardware auf Raspi-Platinenformat.
         https://up-board.org/up/specifications/
Problem: Webcams sind derzeit so gut wie ausverkauft.
Lösung:  Das trifft offenbar nur auf klassische USB-Webcams zu. Die
         Raspi-Cams mit dem Folienkabel-Anschluss sind verfügbar.
         Die Clients müssen also mit Raspi-Cams funktionieren.
Problem: Raspi hat kein eingebautes Mikrofon/keinen Mikrofoneingang. 
         USB-Webcam hat zwar meist Mikro, Raspi-Cam aber nicht.
Lösung1: USB-Soundkarten-Adapter und Mikro dort anschliessen.
         - Problem: Echo zwischen TV-Lautsprecher und Mikro
         - Lösung:  Kopfhörer einstecken, Soundkarte und Pi haben
                    Port
                    - Problem: Buchse kann verwechselt werden, wenn
                               versehentlich ausgesteckt
                    - Lösung:  Nur umständlich möglich (verstopfen,
                               verkleben, verdecken), Problem besteht
                               weiter für versehentliches Vertauschen
                               von Mikro und Kopfhörer, wenn beide
                               gleichzeitig ausgesteckt wurden
Lösung2: Es gibt USB-"Telefonhörer" für Skype-Telefonie. Sind aktuell
         auch kurzfristig lieferbar. Diese wären auf ihre Linux-
         tauglichkeit zu testen - vermutlich sind sie nur USB-
         Soundkarten mit fest angeschweißtem Kabel für den Hörer, was
         gut wäre.
         Vorteile der Lösung: - für ältere Leute vertrautes
                                Userinterface
                              - Mit etwas Hardwarebastelei ließe sich
                                eine Gabel für den Hörer basteln,
                                Hörer aus Gabel nehmen -> Automatische
                                Anwahl (außer es war ein eingehender
                                Anruf, dann Rufannahme).
         -> So ein Hörer sollte zeitnah auf Tauglichkeit getestet
            werden.
            Außerdem ist zu testen, ob ein Hall-Sensor die 
            Anwesenheit des Hörer-Lautsprechers erkennen kann
            -> Dann keine bewegliche Gabel und kein Schalter nötig
            - Erster Hörer erfolgreich getestet (das Digitus-
              Billigmodell); Sprachqualität in beide Richtungen gut,
              funktioniert auf Anhieb, Hörkapsel-Magnet bringt
              Handykompass zum Ausschlagen, Hall-Sensor sollte
              also ebenfalls auslösen.
         -> mechanische Befestigung für den Hörer "in Ruhe":
            Mittels Gummimuffe aus dem Sanitärfachhandel, analog
            dem "Datenklo" des CCC aus den 80er Jahren
Problem: Wie den Fernseher passend einschalten und auf HDMI-Quelle
         umstellen (und danach wieder zurück)?
Lösung:  Raspi beherrscht HDMI-CEC über sein HDMI-Out, geht also.
         Alternativ nicht Fernseher, sondern das 7-Zoll-Display
         verwenden, das es für Raspis zu kaufen gibt.
         Nachtrag: Klappt leider nur eingeschränkt. Manche TVs
         sprechen kein HDMI-CEC, manche schalten nicht zurück auf
         das TV-Programm. Evtl. Infrarot-Steuerung notwendig.
         Fokus erst mal auf dediziertes Display (7 Zoll oder alter
         TFT)
Problem: Anrufsignalisierung (eingehender Anruf am Grannophone)
Lösung:  TV/Display aktiviert sich, zeigt "EINGEHENDER ANRUF" in
         großen Buchstaben, dazu akustische Signalisierung
         Gegebenenfalls zusätzlich einen Summer/eine Klingel über
         GPIO? Vor allem bei Displays ohne Lautsprecher notwendig.
         Wenn sich Audio-Out on-the-fly zwischen Klinke und HDMI
         umschalten lässt, könnte man das Klingeln evtl. auch über
         die Klinke ausgeben (wie laut ist ein Lautsprecher ohne
         Verstärker?)
Problem: Auf dem Raspi muss ein SIP-Client laufen, der Videocalls
         unterstützt und der sich von der Kommandozeile aus steuern
         lässt. Denn das Userinterface ist entweder der Hardware-
         Hörer, der abgehoben/aufgelegt ist, oder ein einzelner
         prellfreier Taster an einem GPIO. Zifferntasten scheiden aus,
         eine GUI scheidet aus, alles zu kompliziert für die
         Zielgruppe. In Ausbaustufe 2 wären vielleicht mehrere
         Zielwahltasten denkbar.
Lösung:  Noch offen. Know-How fehlt.
         Interessantee Kandidaten:
          - Baresip
            https://github.com/baresip/baresip
            https://old.reddit.com/r/VOIP/comments/cafkab/baresip_configuration_help/
            -> Angetestet, macht guten Eindruck, lässt sich steuern,
               braucht nicht zwingend Server, sondern kann P2P,
               Videokomponente aber noch frickelig
          - pjsip mit pjsua (kann pjsua videocalls steuern?)
            https://trac.pjsip.org/repos/wiki/Video_Users_Guide
          - Jami (hat eine API, sieht aber ziemlich bloated aus)
            https://jami.net/
          - SIPSimpleClient (ist ein SDK, keine fertige App)
            https://sipsimpleclient.org/
            
Problem: Fehlerdiagnose/-behebung im Störungsfall
Lösung:  Sofern noch IP-Connect besteht und nur kein Call aufgebaut
         werden kann, wäre SSH-Zugriff sinnvoll. Deswegen entweder VPN
         oder Tor, laufenden SSH-Server auf dem Pi und 2-Faktor-
         Authentisierung verwenden. Private Key/Secret liegt bei dem,
         der die Zentrale/Vermittlung betreibt.
Problem: Stromausfall muss "überlebt" werden
Lösung:  Aktuelles Raspberry Pi OS bringt Unterstützung für
         Overlay File System -> Medium bleibt readonly, Changes landen
         nur in Ramdisk -> Kein Checkdisk nach Stromausfall notwendig
Problem: Wenn Overlay File System in Nutzung ist, sind Systemupdates
         nicht persistent.
Lösung:  Noch offen. Wir brauchen irgendeinen Mechanismus, der
         zwischen zwei wechselseitig upgedateten Bootumgebungen
         umschalten kann. Es wird dann immer die aktuell nicht
         gebootete (und daher nicht vom Overlay genutzte) Partition
         upgedatet, eine Prüfsumme verglichen und nur bei OK
         umgebootet.
         Es wäre zu testen, ob man zwei oder gar drei Partitionen im
         Wechsel als /boot mounten kann, indem man die **Nummer**
         der Partition in der Partitionstabelle umschiebt.
         Die Root-Partitionen müssen dann alle als Extended
         Partitions angelegt werden (oder evtl. auch LVM2 - macht
         das Resizen auf unterschiedlich großen Medien einfacher)
Problem: Einspielen der Updates muss kontrolliert werden.
Lösung:  Noch offen. Irgendein Monitoring- und Deploymenttool wird
         benötigt. Irgendjemand hier, der "Ansible!", "Puppet!",
         "Chef!" oder so rufen will?
Problem: WLAN-Konfiguration
Lösung:  Neuestes Raspberry Pi OS erlaubt WLAN-Konfiguration auch an
         der Kommandozeile mittels raspi-config, braucht also kein
         Configfilegefrickel. Außerdem sollte aus Gründen der
         Betriebssicherheit sowieso ein Ethernet-Kabel verwendet
         werden.
Problem: Gehäusewahl
Lösung:  Noch offen, es wären verschiedene Gehäusetypen auf
         Tauglichkeit zu evaluieren, gegebenenfalls muss per CAD ein
         Custom-Gehäuse erstellt und auf einem 3D-Drucker gedruckt
         werden.
         Dieses könnte als Basis dienen:
         https://www.thingiverse.com/thing:1503651
         Dazu muss dann ein "Telefonhörerhalter" her (links/rechts
         andockbar) sowie eine Sicherungsklammer für den USB-Hörer-
         Stecker. Kommt in ihm kein TFT zum Einsatz, wird eine
         Plastikscheibe an seiner Stelle eingesetzt, dahinter kann
         man dann eine Blink-LED für Anrufe anbringen.
         Achtung: Gehäuse muss über der Pi-Platine Platz für
                  mindestens 1 Modul (HAT/Shim) bieten, falls LTE
                  darüber statt über USB realisiert wird
         
Problem: Irgendeine GUI brauchen wir, sie muss halt seniorentauglich sein
Lösung:  Anleihen bei TYOS nehmen - da hat jemand ein angepasstes
         Raspbian für ein Pi-basiertes Mobiltelefon gebaut.
         https://www.instructables.com/Build-Your-Own-Smartphone/
         Doorpi könnte auch einen Blick wert sein:
         https://github.com/motom001/DoorPi

Serverseite:

  • Ausreichend Bandbreite (vielleicht nicht daheim, sondern Rootserver?)
  • Feste IP/DNS oder DynDNS
  • Offener Port mit Portforwarding auf Firewall/NAT-Router
  • VPN mit OpenVPN oder Wireguard
Problem: Wireguard-Know-How fehlt. Wireguard außerdem nur in
         Testing. OpenVPN mit IPv6-Only (2.5) ist auch nur in
         Testing.
         https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos
         hat aber ein Stable-Repo für Debian 10 - vielleicht auch
         für Raspbian tauglich?
Lösung:  Noch offen.
  • Monitoring-/Deploymenttool, um Software- und eventuell auch Konfigurationsupdates auf die Grannophone zu pushen. Genaues Tool noch offen.
Problem: Tool und Tool-Know-How fehlt.
Lösung:  Noch offen.
  • Eine Asterisk-Installation, die für Videocalls konfiguriert ist.
Problem: Asterisk-Know-How fehlt.
Lösung:  Noch offen. RasPBX/FreePBX evaluieren?
         http://www.raspberry-asterisk.org/
         https://magpi.raspberrypi.org/articles/build-your-own-telephone-exchange-with-raspberry-pi
         http://das-asterisk-buch.de/1.6/hello-world-im-cli.html
         http://das-asterisk-buch.de/1.6/apfelmus-exten-var.html
         http://das-asterisk-buch.de/1.6/apfelmus-grundkonfiguration.html

Workarounds, auf die man eventuell zurückgreifen muss:

  1. Falls VPN nicht geht, kein Portforwarding geht, etc. kann man sich mit Tor behelfen versuchen - wobei da die Frage ist, ob die Latenz nicht zu hoch ist. Allerdings könnte die Server-Seite im Non-Anonymous Mode laufen, das nimmt 2 Hops aus der Kette raus.
  2. Plasterouter haben eventuell UPnP offen, dafür gibt es Tools, um geskriptet Ports freizuschalten, das ließe sich zu unserem Vorteil nutzen.
  3. Falls kein Festnetz-Internet via DSL oder Kabel zur Verfügung steht, kann auf einen LTE-Stick zurückgegriffen werden. Dabei ist zu beachten:
    1. Unbedingt Postpaid, sonst hat Ömchen irgendwann keine Verbindung mehr, und nach Murphy im unpassendsten Moment (Röchelruf)
    2. Unbedingt ein Stick, der einen kleinen NAT-Router onboard hat, und USB-Ethernet-Dongle spielt, statt Modem zu spielen → erheblich leichter zu konfigurieren, erheblich stabiler im Betrieb (bei ppp dauert die Anwahl manchmal viel zu lange; die Router-Sticks sind dagegen quasi daueronline - und das will man ja, damit das Gerät auch für eingehende Rufe auf Empfang ist). Achtung: Unbedingt LTE, denn UMTS wird bei sämtlichen deutschen Providern im Laufe des Jahres 2021 abgeschaltet, und EDGE/GSM übertragen mit zu wenig Bandbreite. Beim Test am Installationsort unbedingt sicherstellen, dass kein Fallback in UMTS erfolgt - sonst wählt man sich evtl. über UMTS ein, ohne es zu merken, und hat dann 2021 spontan kein Netz mehr (weil der Standort keinen ausreichenden LTE-Empfang hat, aber gutes UMTS hatte).
    3. Alternativ zu einem Stick kann vielleicht auch etwas wie das Adafruit-FONA-Modul (https://learn.adafruit.com/adafruit-fona-mini-gsm-gprs-cellular-phone-module) genutzt werden.
  4. Lötfreier Anschluss eines Lautsprechers z.B. mittels „GOOBAY 76745“ von Reichelt o.ä.
  5. Jumper-Kabel (Female-Female und Male-Female) ersparen evtl. auch die eine oder andere Lötarbeit.
  6. Für Hörgeräteträger mit modernen Geräten (Bluetooth) kann eine Kopplung überlegt werden. Leider sind die im Raspi eingebauten Bluetooth-Komponenten meist zickig. Es empfiehlt sich daher, einen USB-Hub im Grannophone zu verbauen und dort ein USB-BT-Dongle einzustecken, möglichst nah an der Vorderseite. Andere Option: Die (z.T. deutlich teureren) USB-Hörer von Plathosys unterstützen den HAC-Standard. Für ältere Geräte kann alternativ ein Adapter Klinke→Induktionsschleife in Frage kommen, dann aber ggf. über USB-Soundkarte, da sonst das Klingelsignal nicht ausgegeben werden kann (wir haben nur eine Buchse). Andererseits ist eine „Lautsprecher-Klingel“ für Hörgeschädigte vielleicht eh nicht laut genug → Buzzer per GPIO schalten?
  7. xrandr -o [0|1|2|3] schaltet Orientierungen durch - wichtig für Hochkantdisplays
  8. Bei Performance-Problemen des Pis schauen, ob /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor den richtigen Wert enthält
  9. zufälligen IPv6-Netzwerkbereich generieren:
echo "fd00:$(uuid | tr -d '-' | cut -c 1-25 | \
      sed 's/.\{4\}/&:/g')$(printf '%x\n' $((4*(RANDOM%4))))00/118"
Erklärung:
fd00: als Präfix (privater IPv6-Range)
uuid spuckt ausreichend lange Hexadezimalzahl aus
Bindestriche entfernen
Zeichenkettenlänge auf 25 reduzieren
Alle 4 Zeichen einen Doppelpunkt setzen
Eine Zufallszahl [0-3] generieren, mal 4 nehmen und zu hex wandeln
00 als Suffix
/118 als Netzmaske (1024 IPs pro Range)
Optional kann noch "uuid -v 4" verwendet werden statt "uuid" - sonst
bleiben ein paar Stellen immer (oder zumindest längere Zeit) gleich

Linkliste

Hier sammeln wir nützliche Links.

Endgeräte-Kennungen

Hier sammeln wir Ideen, welche einheitlichen Kennungen die Endgeräte verwenden sollen.

  • Grannophones:
    • Grannophone1 - GrannophoneN für die einzelnen Grannophones
    • Oder einfach nur G1-GN?
  • Kritischer ist der Name der Gegenstelle. Sollte irgendwas internationales sein.
    • Einfach nur ein „F“ für „Familie“, „family“, „famille“?
    • Bei Zentralbetrieb gibt es mehrere Familien-Gegenstellen, also F1-FN?
  • Nummernschema nicht 1-N sondern 100-NNN? Oder 1000-NNNN? Damit man bei Zuwachs auch „dazwischen“ einsortieren kann?
  • Eine Zentrale, wenn vorhanden, braucht auch noch einen international verständlichen Namen/ein solches Kürzel. Für den VPN-Server auf jeden Fall. → Irgendwas mit Clan?

Kontakt

Du möchtest mit der LUGUlm Kontakt aufnehmen, z.B. weil Du hier im Wiki etwas ergänzen möchtest, aber keinen Account hast? Dann melde Dich bei uns unter tux@lugulm.de

grannophone.txt · Zuletzt geändert: 2020/12/04 17:49 von sbaur
Recent changes RSS feed Creative Commons License Donate Minima Template by Wikidesign Driven by DokuWiki