Es ist alles noch viel schlimmer. Die Letalitätsrate beträgt 100%. Jedes infizierte Individuum stirbt an diesem Pilz: Batrachochytrium salamandrivorans

Tschüss, freilebende Feuersalamander.

Es ist zum Kotzen.

Aber, es gibt Hoffnung und Bemühungen, diese und weitere Amphibien zu retten – zunächst einmal für die nächsten 100 Jahre. Ja, richtig gelesen, draußen Seuche – nur noch in menschlicher Obhut Überlebensmöglichkeit für eine einheimische Amphibienart. Um halbwegs sicher zu gehen, sind mindestens € 45.288.000,00 für die nächsten 100 Jahre notwendig. Verteilt auf möglichst viele Standorte – und daher kommt jetzt die Anfrage an mich, ob ich nicht wüsste, wie eine Temperatur- und Video-Überwachung für einen Standort möglich wäre.

Ich habe ja schon mit mobilen Standorten für den BirdnetPi experimentiert. Jetzt habe ich PUCs und habe wieder RaspberryPis zum Experimentieren über.

Die Salamander leben alleine oder zu zweit in 60x80x20 cm großen Plastikkisten. Es sind 16 Kisten, die stapelbar sind und aufeinander gestapelt auf Rollwagen in einem Kellerraum gelagert werden.

Aufgaben für die Überwachung:

• die Raumtemperatur soll überwacht werden
• der Salamander-Kistenstapel soll optisch überwacht werden, da die gerne auch mal ausbüchsen und diese Ausbrüche möglichst schnell detektiert werden sollen

Folgende Umgebungsbedingungen:

• Kellerraum mit Mobilfunk-Empfang
• keine Nutzung des vorhandenen WLANs
• Strom 220 V kostenfrei

Nebenbedingung:

• möglichst datensparsam und Bezahl-Cloud-frei

 

Jetzt erst einmal die Liste der Dinge und Konfigurationen, die nicht funktionieren.

Temperatursensoren von Pearl, auch wenn WiFi draufsteht. Ja, die sind im WLAN, fahren da aber scheinbar ein so abgefahrenes Protokoll, dass sie nach der Einrichtung via Bluetooth nicht mehr für den Router sichtbar sind – und für andere Geräte außerhalb der Hersteller-Cloud auch nicht mehr.

Hosentaschen-LTE-Router von D-Link, weil die sich einfach mal innerhalb von 14 Tagen Laufzeit weghängen – also irgendwie nicht dauereinsatzkompatibel sind. Wer die länger hat laufen lassen können, bitte melden.

Aufsteckbare Platine mit – LTE direkt am Raspberry – ich bin nicht unerfahren, aber das Dingen habe ich nicht zum Laufen bekommen – sonst wäre das natürlich super gewesen, alles in einem Gerät konfigurieren zu können.

In das entfernte Netz, in dem die Sensoren sind, sich mit VPN verbinden zu können. Nein. Das geht nicht, ohne zusätzliches Geld den Mobilfunkbetreibern hinterher zu werfen, können keine Verbindungen von außerhalb aufgebaut werden, die zugewiesenen IP-Adressen sind nicht erreichbar, weil die Mobilfunkbetreiber private IP-Adressen zuweisen.

Nun zu dem, was läuft:

Fritzbox 6820 LTE – sieht komisch aus, ist kleiner als angenommen (ich kannte die alten hochkant stehenden Repeater) reicht völlig aus – VPN ist zwar einrichtbar, aber nicht erreichbar von außerhalb des Mobilfunknetzes – vermutlich innerhalb des Mobilfunknetzes auch nicht.

RaspberryPi 4 – 4 GB RAM – ou- werden manche denken, das ist fett und mit Kanonen auf Spatzen geschossen, aber ich möchte flexibel sein bei meiner Datensammelei.

TAPO C100 – € 20 das Stück – das war der ausschlaggebende Punkt für die Kameras. Ich kenn sie, sie lassen sich angenehm konfigurieren, die Bilder lassen sich teilen, lokal auf der Kamera speichern und haben irgendeine Magic, dass sie sich auch ohne fixe Verbindung aufrufen lassen. Vermutlich telefonieren sie permant nach Hause und das zu Hause kann dann den berechtigten Apps den Livestream triggern.

Der Bewegungsmelder in der Kamera ist zuverlässig und teilt auch den Accounts, mit denen die Livebilder geteilt werden, mit, dass eine Bewegung stattgefunden hat. Die allerdings können nur das Livebild sehen und nicht auf die Aufzeichnungen der Kamera zugreifen um zu ermitteln, was denn da die Bewegung ausgelöst hat – im besten Fall läuft der ausgebrochene Salamander noch mal durchs Bild.

Wiederverbinden nach Stromausfall, Wiederanmeldung in der Cloud/ App – alles unproblematisch. Die Auflösung reicht für die Entfernung im Raum völlig aus, scharf sind die Objekte erst ab 40 cm vor der Linse, aber soll ja nicht in einem Nistkasten, sondern auf einem Kistenstapel montiert sein und den umgebenden Fussboden betrachten. Da die Bewegung nicht durch Wärmestrahlung detektiert wird, sondern durch die Bild-Differenz der aufeinanderfolgenden Bilder, lösen auch wechselwarme Tiere den Bewegungsmelder aus.

2. Aufgabe – Umgebungsverhältnisse protokollieren und bei Über- oder Unterschreitung eine Warn-E-Mail verschicken. Erstaunlicher Weise gibt es da Temperaturfühler für 400 Tacken, die direkt sich in die Hersteller-Cloud einwählen wenn ein WLAN vorhanden ist – vielleicht für zertifizierte menschliche Lebensmittel relevant – hier soll ja “nur” die Umgebung von Amphibien geloggt werden.

Als ich mir die MACHBARKEITSSTUDIE ZUR EX-SITU-ERHALTUNGSZUCHT DES FEUERSALAMANDERS zu Gemüte geführt habe, dachte ich mir, dass Luftdruck vielleicht auch noch eine relevante Messgröße für die Haltung sei. Also werde ich den DHT22 Sensor durch einen BME680 ersetzen und noch ein paar mehr Daten mitloggen können – Luft- druck, -feuchte, -temperatur und -qualität anhand von flüchtigen organischen Substanzen.

Das Ganze läuft dann in dem RaspberryPi zusammen – sowohl die externen Sensoren, wie auch der direkt angeschlossene Umgebungssensor. Eine Routine wertet die einlaufenden Daten aus und je nach eingestellten Schwellenwerten benachrichtigt er dann bestimmte E-Mail-Adressen.

So – und um wieder mit Kanonen auf Spatzen zu schießen – das geht bestimmt schlanker, aber ich möchte möglichst flexibel in meiner ersten Umgebung sein – daher setze ich einen ioBroker ein, der einfach ganz viele Datenquellen anzapfen und in eine Datenbank weiterreichen kann. Die verwendete Datenbank ist inFlux. InFlux Datensätze können nicht via UPDATE manipuliert werden und das Löschen von Daten ist ein bisschen tifftelig – aber möglich. Dafür hat jeder Datensatz einen Zeitstempel.

Ich dachte, dass ich auch Grafana bräuchte, um die Daten in der inFlux-Datenbank hübsch anzeigen zu lassen, aber das kann inFlux mit dem influxdb2-client auch. Also: nächste Umgebung kann schon mal etwas schlanker sein – bis dahin habe ich folgenden Befehlstack ausgeführt:

sudo apt-get update
sudo apt-get upgrade

Erst mal das Linux auf aktuellen Stand heben – egal wie alt das Image auf der SD-Karte ist. Da Grafana nicht in meiner Distribution dabei war, wird jetzt die Quelle eingerichtet und dann die Grafana-Umgebung geladen, installiert und eingebunden als Startobjekt

sudo apt-get install -y apt-transport-https software-properties-common wget
sudo mkdir -p /etc/apt/keyrings/
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install grafana
sudo /bin/systemctl enable grafana-server
sudo /bin/systemctl start grafana-server

Nach dem Grafana (unnötiger Weise installiert) durch ist – kommt inFlux

curl -O https://dl.influxdata.com/influxdb/releases/influxdb2_2.7.4-1_arm64.deb
sudo dpkg -i influxdb2_2.7.4-1_arm64.deb
sudo service influxdb start
sudo systemctl unmask influxdb
sudo systemctl enable influxdb
sudo systemctl start influxdb

Und damit ioBroker läuft auch noch NodeJS. Noch ein Quell ewiger Freude und Sicherheitslücken –

curl -sL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs
curl -sL https://iobroker.net/install.sh | bash -

Damit ich die Umgebungs-Sensoren direkt an dem RaspberryPi anschließen kann, noch ein bisschen Python und eine Datei um den angeschlossenen Sensor direkt auszulesen.

sudo apt-get install build-essential python-dev-is-python3 git-core
sudo pigpiod
mkdir DHT22
cd DHT22/
wget https://github.com/joan2937/pigpio/raw/master/EXAMPLES/Python/DHT22_AM2302_SENSOR/DHT22.py

Da ich von außen keine VPN-Verbindung aufbauen kann, muss ich sie von innen initialisieren.

sudo apt-get install vpnc
sudo nano /etc/vpnc/fritzbox.conf
sudo vpnc fritzbox.conf
ls -al
mkdir vpnc
cd vpnc/
sudo nano checkVPN.sh
sudo chmod 755 checkVPN.sh 
cd /usr/local/bin/
sudo ln -s ~/vpnc/checkVPN.sh checkVPN.sh
sudo nano /etc/crontab

Da die heimische Fritzbox aber rumdümpelde VPN-Verbindungen einfach kappt, und der VPN-Dienst auf dem entfernten Gerät nicht sauber beendet wird, verbleibt die DNS-Server-Information des heimischen Routers auf dem entfernten Gerät – ach – noch etwas: wenn mit VPN und Fritzboxen angefangen wird, bitte die 192.168.178.1 ändern. In irgendwas zwischen 0 und 255 – aber nicht 178 oder 179. Fritzboxen mit dem gleichen Subnetz können keine VPN-Verbindungen untereinander aufbauen.

In der crontab steht dann sowas:

*/5 * * * * pi /usr/local/bin/checkVPN.sh &> /dev/null
@reboot root sleep 20 && pigpiod
* * * * * pi python3 /home/pi/DHT22/DHT22.py

Bis ich diese Lösung gefunden habe, sind mir ein paar graue Haare gewachsen:

sudo nano  /etc/vpnc/no_resolverupdate.sh
sudo chmod +x /etc/vpnc/no_resolverupdate.sh
sudo echo 'Script /etc/vpnc/no_resolverupdate.sh' >> /etc/vpnc/fritzbox.conf

Klappt nicht? Dann eben mit sudo su und nano /etc/vpnc/fritzbox.conf in die letzte Zeile `Script /etc/vpnc/no_resolverupdate.sh’` einfügen.
 

So – und demnächst geht es dann hier weiter mit der Einrichtung von inFlux und ioBroker und der Sensorauswertung mit python. Zur Zeit schreibe ich die Sensordaten erstmal mit MQTT weg und lass die dann im ioBroker in inFLux schreiben – geht bestimmt auch eleganter. Durch den ioBroker müssen die ja eh, um einen möglichen Alarm auszulösen.

Auch einfach zu realisieren ist ein Heart-Beat mit ioBroker – sollten regelmäßige Nachrichten aus dem entfernten Standort in meinem ioBroker ausbleiben, löst das Ausbleiben bei mir einen Alarm aus.