Zuletzt angesehen: • grannophone

Inhaltsverzeichnis

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 an einen Anbieter gebunden
    • offener Standards → Kann später auch mit anderen Endgeräten (Smartphone-App, PC) genutzt werden
    • 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 Ostern 2021, aber für Weihnachten 2021 dann, wenn da immer noch Pandemie ist?

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) Dazu könnte https://github.com/showmewebcam/showmewebcam geeignet sein

Videovortrag:

Auf der Pi and More 12 1/4 hat Stefan Baur einen Vortrag zum aktuellen Entwicklungsstand des Grannophones gehalten. Das Video findet man vorerst hier (an der Verbesserung der Tonqualität wird noch gearbeitet): https://youtu.be/XFxt89oy5Tc?t=15975

Weitere Anmeldungen:

Maker Faire Hannover Digital 18. Juni 2021, 11 - 16 Uhr

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.
              -> 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?
         -> 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)
         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
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?)
         -> 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.)
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.
         Interessante 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
               https://github.com/baresip/baresip/issues/965 -> Selbes Problem hier
          - 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
         Ebenso interessant:
         - https://kivy.org/ 
         - https://github.com/alandmoore/KiLauncher
         - https://github.com/splitbrain/pimenu

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 man doch nicht ohne Lüfter auskommt, findet sich hier eine Anleitung, wie er sich bei Bedarf schalten lässt.
  2. 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.
  3. Plasterouter haben eventuell UPnP offen, dafür gibt es Tools, um geskriptet Ports freizuschalten, das ließe sich zu unserem Vorteil nutzen.
  4. 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.
  5. Lötfreier Anschluss eines Lautsprechers z.B. mittels „GOOBAY 76745“ von Reichelt o.ä.
  6. Jumper-Kabel (Female-Female und Male-Female) ersparen evtl. auch die eine oder andere Lötarbeit.
  7. 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?
  8. https://euroelectronics.eu/de/products/kompakt-mini-stereo-lautsprecher-pc-computer-laptop-usb-paar-boxen-schwarz-rot ist ein Lautsprecherset, was per USB mit Strom versorgt wird. Könnte man für Klingeln und Lauthören nutzen versuchen. Macht halt einen Port dicht.
  9. Wenn USB-Soundkarte zum Einsatz kommt: Ausgänge umdrehen! Raspi-Ausgang für Hörer, Soundkartenausgang für Klingellautsprecher!
  10. Klingelton abspielen geht z.B. mit „AUDIODEV=hw:<device> sox -v 27.0 ringbell.wav -t alsa“ (27 ist die Verstärkung)
  11. Alternative: Fürs Telefonieren braucht man keinen Stereoton. Ein Kanal treibt den Hörer, der andere den Klingellautsprecher. Aufspalten in zwei Pseudo-Devices könnte so gehen wie hier beschrieben: https://wiki.archlinux.org/index.php/PulseAudio/Examples#Remap_left_or_right_to_mono
  12. Lötfreier Hörer: Mikrofon und Lautsprecher mit freien Kabelenden; Schraubstecker TRRS, Adapterkabel TRRS auf 2 x TRS oder USB-Soundkarte mit TRRS-Eingang; Hörerkabel kann dann USB-Kabel werden, Karte kommt in den Hörer. Nachteil bei TRRS-Karte/Hörereinbau: Klingelton muss der Raspi abspielen.
  13. Lötfreie Verbindungen, egal ob gecrimpt oder gesteckt, immer mit Heisskleber fixieren, geht sonst schief! Und keinesfalls vor dem Crimpen verdrillen!
  14. Display rotieren:
    1. xrandr -o [0|1|2|3] schaltet Orientierungen durch - wichtig für Hochkantdisplays
      1. 0 ist Querformat, Folienkabel unten
      2. 1 ist Hochformat, Folienkabel Blickrichtung aufs Display links
      3. 2 ist Querformat, Folienkabel oben
      4. 3 ist Hochformat, Folienkabel Blickrichtung aufs Display rechts
    2. gesamtes Display um 180° rotieren: lcd_rotate=2 in /boot/config.txt (geht nicht für 90/270)
    3. Mit Framebuffer gesamtes Display um 270° rotieren: display_lcd_rotate=3 in /boot/config.txt
    4. Mit (Fake)KMS - erkennt man an dtoverlay=vc4-fkms-v3d in /boot/config.txt - gesamtes Display um 90° (Achtung: Drehrichtung umgekehrt zu Framebuffer) rotieren: video=DSI-1:800×480@60,rotate=90 in /boot/cmdline.txt
    5. /usr/share/dispsetup.sh prüfen - wird beim Start von X aufgerufen und enthält einen rotate-Befehl, der ggf. angepasst werden muss (an 2 Stellen), und zwar „right“ für Hochformat, „normal“ für Querformat
  15. Touchscreen an 90°/270°-Rotation anpassen
    1. /etc/X11/xorg.conf.d/99-calibration.conf mit folgendem Inhalt anlegen:
      1. Section „InputClass“
      2. Identifier „calibration“
      3. MatchProduct „raspberrypi-ts“
      4. Option „SwapAxes“ „1“
      5. Option „InvertX“ „1“
      6. EndSection
    2. sudo service lightdm restart
    3. Angeblich auch per dtoverlay=rpi-ft5406,touchscreen-swapped-x-y=1,touchscreen-inverted-x=1 in /boot/config.txt möglich
  16. Bei Performance-Problemen des Pis schauen, ob /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor den richtigen Wert enthält
  17. hier ist noch ein Hinweis, warum ein Pi vielleicht schon bei 60 Grad langsam heruntertaktet, und wie man das umgehen kann
  18. https://www.raspberrypi.org/forums/viewtopic.php?t=224896 erklärt die Ausgabe von vcgencmd get_throttled
  19. Das Paket „unclutter“ versteckt den Mauszeiger auf den Videodisplays (falls er stört), lässt aber Touch aktiv.
    1. Mauszeigeranzeige komplett deaktivieren (Touch aber weiterhin möglich): „xserver-command=X -nocursor“ in /etc/lightdm/lightdm.conf ergänzen
    2. Touch deaktivieren: disable_touchscreen=1 in /boot/config.txt
  20. „motion“ startet nicht automatisch, weil Permissions auf /var/log/motion falsch. Fix: sudo chown -R motion: /var/log/motion
  21. zu Fernwartungszwecken sollte auch immer ein Wifi nutzbar sein. Entweder eigener Hotspot/AP oder ein voreingestelltes verschlüsseltes Wifi. Dann kann man notfalls mit der Pringles-Cantenna vorm Pflegeheim stehen, wenn man nicht rein darf.
  22. zufälligen IPv6-Netzwerkbereich generieren:
echo "$(echo "fd$(uuid | tr -d '-' | cut -c 1-27)" | \
  sed 's/.\{4\}/&:/g')$(printf '%x\n' $((4*(RANDOM%4))))00/118"
Erklärung:
fd00: bis fdff: als Präfix (privater IPv6-Range)
wir stellen daher fd voran
uuid spuckt ausreichend lange Hexadezimalzahl aus
Bindestriche entfernen
Zeichenkettenlänge (inkl. "fd") auf 27 reduzieren
Alle 4 Zeichen einen Doppelpunkt setzen
Eine Zufallszahl [0-3] generieren, mal 4 nehmen und zu hex wandeln,
da wir bei der geplanten Netzmaske nur 0,4,8 und c "brauchen" können
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

Cave: RFC4193 sagt, dass man einen anderen Mechanismus für random ranges verwenden soll.

Linkliste

Hier sammeln wir nützliche Links.

DualBoot

Prinzipiell kann man den Raspi dualbooten.

Dafür gibt es mehrere Methoden. Schwierigkeit bei uns ist, dass man geskriptet statt interaktiv umschalten können muss.

Die „HardCore“-Methode verwendet zwei USB-Medien und entfernt start*.elf aus dem /boot, welches nicht verwendet werden soll.

Mit der „BruteForce“-Methode hat man nur genau 2 Umgebungen, weil man 4 primäre Partitionen braucht. Umschalten zwischen den beiden Umgebungen geht dann, indem man die Partitionstabellen neu schreibt: 

/dev/sda1         532480  1056767   524288  256M  c W95 FAT32 (LBA) #boot2
/dev/sda2           8192   532479   524288  256M  c W95 FAT32 (LBA) #boot1
/dev/sda3        1056768 15544319 14487552  6.9G 83 Linux           #rootfs1
/dev/sda4       15544320 30031871 14487552  6.9G 83 Linux           #rootfs2
vs:
/dev/sda1           8192   532479   524288  256M  c W95 FAT32 (LBA) #boot1
/dev/sda2         532480  1056767   524288  256M  c W95 FAT32 (LBA) #boot2
/dev/sda3        1056768 15544319 14487552  6.9G 83 Linux           #rootfs1
/dev/sda4       15544320 30031871 14487552  6.9G 83 Linux           #rootfs2
# Dabei muss man aufpassen, dass in [rootfs2] die /boot-Partition
# als PARTUUID=xxxxxxxx-01 eingetragen wird, denn wenn rootfs2
# gebootet wird, hält sich /boot natürlich aufgrund der fstab für
# -01, obwohl es strenggenommen -02 wäre.
# In [boot2] muss dagegen unbedingt in der cmdline.txt die PARTUUID
# für / auf -04 gesetzt werden (und in [boot1] auf -03).

Mit -05, -06, etc. darf rootfs auch auf logischer Partition liegen! 3 primäre /boot, 1 extended, 3 logische / (und ggf. noch separate Datenpartition) sind also möglich!

Um außer PARTUUID auch LABEL etc. verwenden zu können, braucht man eine initrd. Die wird automatisch erstellt, wenn man das Overlay File System benutzt; manuell geht es so wie hier beschrieben. Damit sollte auch LVM unterstützt werden, was die Sache noch bequemer machen würde.

Laut diesem Text sei es möglich, in der config.txt einen Parameter os_prefix zu setzen, der ein Unterverzeichnis in /boot/ darstellen kann. Dann werden cmdline.txt, kernel, overlays etc. aus diesem Unterverzeichnis gezogen. Das wäre eine sehr schicke Methode. Man braucht nur genug Platz in der 1. Partition für mehrere Umgebungen. Dieses Script geht so ähnlich vor, movet aber jedes Mal die Inhalte hin und her, statt die config.txt zu ändern. Mit bindmounts sollten sich die Unterverzeichnisse auf /boot „hochmappen“ lassen, falls das notwendig ist, um Updates zu fahren. Aber vielleicht ist der Updater ja auch schlau genug, ein Prefix zu beachten?

Nota bene: Laut diesem Text kann man die config.txt-Optionen davon abhängig machen, welcher GPIO in welchem Zustand ist. Das würde einen Hardware-Taster für einen Recovery-Mode erlauben.

Pi-Boot-Switch ist einen Blick wert.

Raspi-Konfiguration

  • Neueste Firmware muss geflasht werden (per SD)
  • Anleitung von hier befolgen, um BOOT_ORDER=0xf41 zu setzen
  • FAT-Partitons-Label setzen mit sudo fatlabel /dev/sdxy NEUES_LABEL
  • EXT-Partitons-Label setzen mit sudo tune2fs -L NEUES_LABEL /dev/sdxy
  • Falls SPI-Display verwendet wird:
    • fbcon=map:1 in der cmdline.txt ausprobieren - ist je nach Szenario erforderlich oder nicht
      • con2fbmap kann hier noch nachträglich im laufenden System Dinge bewirken
    • dtoverlay=piscreen,speed=16000000,rotate=270 oder auch mit 32000000, wenn es keine Störungen verursacht, in der config.txt setzen
    • Bei der X-Konfiguration scheint es je nach Modell zu schwanken, welches fb-Device und welche Achsen-Inversion man braucht
      • sudo fbi -noverbose -T 1 -a -d /dev/fb_ image-test.[gif|png] kann genutzt werden, um von der Kommandozeile aus das richtige fbdev zu ermitteln
    • wichtig ist das Paket xserver-xorg-input-evdev, sonst haut das mit Kalibrierung und Achsen nicht hin

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?

Bestellzettel

Was als nächstes bestellt werden sollte

Was schon bestellt, aber noch nicht geliefert ist

-Aktuell nichts-

Was schon alles da ist

  • Arlt
    1. Netzteil für Raspberry Pi 4B
    2. Raspberry Pi 4B 2GB
    3. Speicherstick USB3 32GB SanDisk Ultra Luxe
    4. Speicherstick USB3 128GB SanDisk Extreme Pro!
    5. Speicherstick USB 3.1 16gb SanDisk Ultra Fit
  • Bauhaus:
    1. Bessey Druckguss-Schraubzwinge LM 30/8
    2. Cartrend Flachsteckhülsen
    3. Cartrend Kabel-Quetschverbinder
    4. Sperrholzplatten DIN A5
    5. Kantoflex Glattblech Kupfer
    6. Quadratleisten in 10×10, 20×20, 30×30
    7. Laubsägeblatt-Set (Holz und Metall)
    8. Heißklebepistole
    9. Heissklebepatronen
    10. Spaxschrauben verschiedener Länge
    11. Tesa Moll E-Profil- und Premiumdichtungen als Durchführungs-/Kantenschutz und Rutschstopp
  • Conrad:
    1. 1 x MH HI-SPEED USB 3D SOUND ADAPTER (USB-Soundkarte)
    2. KY-024 Hall-Sensor-Module
    3. Kabeltülle als Durchführungs-/Kantenschutz
    4. je 1 Packung Jumperkabel M/F und F/F
    5. Klinkenstecker TRRS mit Schraubanschluss
    6. Klinkenstecker TRS mit Schraubanschluss
    7. Kabel mit TRS-Klinkenstecker
    8. Miniatur-Lautsprecher K50 FL 16 Ohm
    9. Miniatur-Lautsprecher K16 50 Ohm
  • eBay:
    1. Digitus USB-Telefonhörer
  • Eigener Bestand
    1. Elektret-Mikro mit 3,5mm-Stereoklinkenstecker
    2. Kupfer-Doppelader
    3. Lötkolben/Lötzinn
    4. Quetschverbinder-Crimp- und Abisolierzange
    5. Schraubenzieherset
    6. Schraubzwinge
    7. Raspi4B-Gehäuse mit 3.5-Zoll-SPI-Touchscreen
  • Elektromax24:
    1. 2 x Siedle Ersatzlautsprecher fuer BTLE050-04 und TLE061-01
    2. 1 x Siedle CTB 711-…/SET 711-… Elektret-Kondensator-Mikrofonkapsel (Kabelvariante)
  • Reichelt:
    1. 2 x Dünnschichtwiderstand, axial, 0,6 W, 10 kOhm, 1%
    2. 1 x Drucktaster 0,1A-24VAC 1x (Ein) Ø11/9,1mm rot - getestet, nicht lötfrei verwendbar, dafür sehr leichtgängig und klein
    3. 1 x Drucktaster 0,7A-250VAC 1x (Ein) Ø19/15,2mm schwarz - getestet, lötfrei verwendbar mit kleinen oder grossen Kabelschuhen, dafür nicht so leichtgängig und grosser Durchmesser → sollte auch in anderer Farbe gekauft werden, Schwarz zu unauffällig
    4. 1 x Raspberry Pi Shield - Display LCD-Touch, 7 Zoll, 800×480 Pixel - getestet, funktioniert; für Rotation muss man kalibrieren
    5. 1 x Elektret-Kondensator-Mikrofonkapsel (Lötvariante)
    6. 2 x Montageclip für 10 mm LEDs
    7. 2 x Dünnschichtwiderstand, axial, 0,6 W, 150 Ohm, 1%
    8. 2 x LED, 10 mm, bedrahtet, rot, 100 mcd, 60°
    9. 1 x dynamische Hörkapsel, Lötanschluss - getestet, Lötfahnen sind auch für Kabelschuhe geeignet → Lötfrei verwendbar, Lautstärke für Hörer ausreichend
    10. 1 x Headset Adapter 3,5 mm 4 Pin Klinkenbuchse > 2x 3 Pin Klinkenstecker - getestet, Länge ausreichend für Split Mic → USB-Sound-In/Spk → PiAudio (USB-Sound-Out → Klingel)

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: 2021/02/23 15:39 von sbaur

Übersicht

Dies ist eine Übersicht über alle vorhandenen Seiten und Namensräume.

 
 
Recent changes RSS feed Creative Commons License Donate Minima Template by Wikidesign Driven by DokuWiki