Clientseite

Aus Grannophone
Zur Navigation springenZur Suche springen

Hardwareauswahl, Raspi 3B, 3B+, oder 4B? Wenn 4B, wie viel RAM?

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/

Webcams sind derzeit so gut wie ausverkauft oder schweineteuer

Das trifft offenbar nur auf klassische USB-Webcams zu (und hat sich mittlerweile auch wieder gebessert). Die Raspi-Cams mit dem Folienkabel-Anschluss sind verfügbar. Die Clients müssen also mit Raspi-Cams funktionieren.

Raspi hat kein eingebautes Mikrofon/keinen Mikrofoneingang

USB-Webcam hat zwar meist Mikro, Raspi-Cam aber nicht.

Ansatz 1: 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

Ansatz 2: Es gibt USB-"Telefonhörer" für Skype-Telefonie

Sind aktuell auch kurzfristig lieferbar. Diese wären auf ihre Linuxtauglichkeit zu testen - vermutlich sind sie nur USB-Soundkarten mit fest angeschweißtem Kabel für den Hörer, was gut wäre.

Vorteile dieser 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.
      • Tut er aber nicht. :( 2 Hall-Sensor-Module mit A/D-Wandler getestet, offenbar nicht empfindlich genug.
        Einzelne Sensoren oder 3-Achsen-Kompass-Sensor verwenden?
    • Hörergabel per "großem" Mikroschalter (250V/16A-Spec) abtasten geht nicht, zu schwergängig, zumindest ohne Hebel -> Kleinere Ausführung verwenden?
      Idee zur mechanischen Befestigung des Hörers, wenn "in Ruhe": Mittels Gummimuffe aus dem Sanitärfachhandel, analog dem "Datenklo" des CCC aus den 80er Jahren

Wie den Fernseher passend einschalten und auf HDMI-Quelle umstellen (und danach wieder zurück)?

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 daher erst mal auf dediziertes Display (7 Zoll oder alter TFT)

Grundsätzlich: 

          TVID=$(echo 'scan' | \
                 cec-client -s -d 1 | \
                 grep "^device #.* TV$" | \
                 sed -e 's/^.*#\([0-9]*\):.*$/\1/')
          echo "on $TVID" | \
          cec-client -s -d 1; while ! (echo "pow $TVID" | \
          cec-client -s -d 1 | \
          grep -v "transition" | \
          grep "on$" ); do sleep 0.5; done; echo "as" | \
          cec-client -s -d 1

Anrufsignalisierung (eingehender Anruf am Grannophone)

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?) 

          aplay -L | grep '^hw' # wirft die Devices aus
          # z.B.
          hw:CARD=b1,DEV=0 #(HDMI)
          hw:CARD=Headphones,DEV=0 #(Analog)
          hw:CARD=U0x4b40x306,DEV=0 #(USB-Hörer)

          aplay -D hw:CARD=Headphones,DEV=0 ringbell.wav # spielt auf Analog ab
          # Optische Signalisierung auf Display z.B. mit Python/Tkinter (s.u.)

Welchen Videocall-fähigen SIP-Client verwenden?

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 dieZielgruppe. In Ausbaustufe 2 wären vielleicht mehrere Zielwahltasten denkbar.

Lösung noch offen. Know-How fehlt. Interessante Kandidaten:

Fehlerdiagnose/-behebung im Störungsfall

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.

Stromausfall muss "überlebt" werden

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

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) Siehe auch Dualboot.

Einspielen der Updates muss kontrolliert werden

Lösungn och offen. Irgendein Monitoring- und Deploymenttool wird benötigt. Irgendjemand hier, der "Ansible!", "Puppet!", "Chef!" oder so rufen will?

WLAN-Konfiguration

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.

Gehäusewahl

Es sind 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


Irgendeine GUI brauchen wir, sie muss halt seniorentauglich sein

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 Ebenso interessant:

Abgerufen von „http://wiki.grannophone.de/index.php?title=Clientseite&oldid=652“