IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: HomeLab (Seite 2 von 2)

QIVICON Home Base 2.0: Migration vom Telekom SmartHome und was dabei schiefgeht

Ich nutze privat das SmartHome-System der Telekom mit der QIVICON Home Base. Die alte Version 1.0 war funktional in Ordnung, aber langsam. Kein WLAN, kein ZigBee ohne USB-Stick, und je mehr Geräte dranhingen desto zäher wurde die Oberfläche. Die neuen HomeMatic IP Geräte von eQ-3 haben den Rest gegeben. Die Home Base 1.0 war damit überfordert.

Die Home Base 2.0

Das Endergebnis vorweg: Die 2.0 ist besser. Kamerastreams laufen flüssig, keine Verbindungsabbrüche mehr zu den Sensoren, die App reagiert spürbar schneller. Soweit die gute Nachricht.

Der Migrationsprozess

Die offizielle Wechselanleitung der Telekom sieht so aus:

1. Alle Geräte auf der Home Base 1.0 löschen
2. Reset der Home Base 1.0
3. Alte abklemmen, neue anklemmen
4. Neue Home Base registrieren und aktivieren
5. Alle Geräte neu einrichten

Punkt 1 und 5 sind das Problem. Jedes Gerät einzeln löschen, über eine App die alle paar Klicks die Verbindung verliert und einen gefühlten Delay von ein bis zwei Sekunden auf jede Aktion hat. Manche Geräte wollen vor dem Löschen eine physische Bestätigung am Gerät selbst. Also knapp eine Stunde durch die Wohnung rennen und Knöpfe drücken. Bei Unterputz-Schaltern besonders viel Freude.

Was bei mir schiefging

Nach dem Löschen aller Geräte und dem Reset der alten Home Base wollte die App keine Verbindung mehr herstellen. Logisch, die alte Base war ja zurückgesetzt. Im QIVICON-Webportal gab es einen Button „Exchange Gateway“ der in der Anleitung nicht vorkam. Seriennummer der neuen Base eingeben, fertig. Die Aktivierung, die laut Anleitung nötig sein soll, war es nicht. In der Anleitung steht man solle die Fehlermeldung bei der Aktivierung ignorieren. Fehlermeldung ignorieren als offizieller Schritt.

Nach dem Gateway-Tausch passierte etwas Unerwartetes: Die neue Home Base hatte meine komplette Konfiguration und alle Geräte. Die ich vorher gelöscht hatte. Die Geräte kannten aber den Funkschlüssel der alten Base und weigerten sich mit der neuen zu reden. Das Ergebnis war ein Dauerbeschuss des Funkmoduls mit ungültigem Traffic. Die Base war alle paar Sekunden überlastet.

Zum Löschen der Geräte brauchte man das Funkmodul. Also hatte man immer ein paar Sekunden Zeit bevor es wieder abschmierte. Ein Neustart der Home Base dauerte 15 Minuten. Das ganze Löschen und Neu-Anlernen hat knapp drei Stunden gedauert, inklusive Geräte die vor dem Neu-Anlernen einen eigenen Factory-Reset brauchten.

Fazit

Die Hardware ist ein klares Upgrade. Der Migrationsprozess ist eine Katastrophe. Ein Gateway-Tausch sollte eine Sache von Minuten sein, nicht von Stunden. Das Telekom SmartHome hat den Vorteil verschiedene Hersteller kombinieren zu können. Das ist nach wie vor der Grund warum ich dabei bleibe. Die Bilder zeigen die alte und neue Home Base, innen und aussen.

Siehe auch: Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base​, Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2, Magenta SmartHome Lüften: Lösung für Android-Probleme gefunden

Fragen? Einfach melden.

Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base​

Das Zeug funktioniert ja zu 85% super… Aber hin und wieder könnte ich das Zeug einfach aus dem Haus treten :-/

Es ist ein Problem aufgetreten (500)

Die gewünschte Seite ist zurzeit nicht erreichbar.

Laden Sie die Seite zunächst bitte neu. Erhalten Sie wiederholt diese Meldung, versuchen Sie es zu einem späteren Zeitpunkt wieder, da evtl. Wartungsarbeiten durchgeführt werden.

Im Falle einer Meldung an den QIVICON Support stets angeben:
Fehlercode 586b87c131d73:0

Es ist ein Problem aufgetreten (500) Die gewünschte Seite ist zurzeit nicht erreichbar. Laden Sie die Seite zunächst bitte neu. Erhalten Sie wiederholt diese Meldung, versuchen Sie es zu einem späteren Zeitpunkt wieder, da evtl. Wartungsarbeiten durchgeführt werden. Im Falle einer Meldung an den QIVICON Support stets angeben: Fehlercode 586b87c131d73:0
QIVICON Telekom SmartHome Error Fehler

Siehe auch: HomeMatic Firmware-Updates, QIVICON Home Base 2.0: Migration vom Telekom SmartHome und was dabei schiefgeht

Fragen? Einfach melden.

Temperatur und Luftfeuchtigkeit mit DHT22 am Raspberry Pi messen

Meine Wetterstation hatte aufgegeben. Wirklich interessiert haben mich aber eh nur Temperatur und Luftfeuchtigkeit draußen. Das sollte ein Raspberry Pi mit einem DHT22 für zwei Euro hinbekommen — und die Daten landen direkt in meinem Cacti.

Update März 2026 — Dieser Beitrag ist von 2014 und einer meiner ältesten hier im Blog. Die Grundidee — DHT22 an den GPIO, Werte per Cron einsammeln, per SNMP an Cacti liefern — funktioniert unverändert. Ich habe den Beitrag komplett überarbeitet und den Software-Teil auf Python aktualisiert. Die ursprünglich verwendete C-Bibliothek wiringPi wurde 2019 vom Autor offline genommen und lol_dht22 wird nicht mehr gepflegt. Der Ansatz selbst ist zeitlos.

Was du brauchst

  • Einen Raspberry Pi — egal welches Modell, solange GPIO-Pins vorhanden sind
  • Einen DHT22 / AM2302 Sensor (2–5 €)
  • Einen 4,7 kΩ Widerstand als Pull-up
  • Drei Kabel

Die Verkabelung ist simpel: VCC an 3,3 V (Pin 1), Data an GPIO 4 (Pin 7), GND an GND (Pin 6). Der 4,7 kΩ Widerstand kommt zwischen VCC und Data. Den handgezeichneten Schaltplan habe ich unten in der Bildergalerie.

Sensor auslesen — Python

Auf einem aktuellen Raspberry Pi OS brauchen wir die Adafruit CircuitPython DHT Bibliothek und libgpiod:

sudo apt install python3-pip libgpiod2
pip3 install adafruit-circuitpython-dht

Dann ein kleines Script /usr/local/bin/read_dht22.py:

#!/usr/bin/env python3
import adafruit_dht
import board
import sys

sensor = adafruit_dht.DHT22(board.D4)
try:
    print(f"{sensor.humidity:.1f}")
    print(f"{sensor.temperature:.1f}")
except RuntimeError:
    sys.exit(1)
finally:
    sensor.exit()

Ausführbar machen und testen:

chmod +x /usr/local/bin/read_dht22.py
/usr/local/bin/read_dht22.py
73.9
9.3

Erste Zeile Luftfeuchtigkeit, zweite Zeile Temperatur. Der DHT22 liefert nicht bei jedem Aufruf saubere Daten — manchmal kommt ein RuntimeError. Das ist normal bei diesem Sensor, deswegen der try/except und der Exit-Code. board.D4 entspricht GPIO 4, also Pin 7 auf dem Board.

Werte per Cron einsammeln

Per Cron-Job jede Minute:

* * * * * /var/scripts/getsensor.sh

Das Script /var/scripts/getsensor.sh:

#!/bin/bash
/usr/local/bin/read_dht22.py > /home/pi/both.txt 2>/dev/null

while [ ! -s "/home/pi/both.txt" ]; do
    sleep 5
    /usr/local/bin/read_dht22.py > /home/pi/both.txt 2>/dev/null
done

sed '2d' /home/pi/both.txt > /home/pi/humid.txt
sed '1d' /home/pi/both.txt > /home/pi/temp.txt

Wenn der Sensor beim ersten Versuch keine Daten liefert, probiert das Script alle fünf Sekunden erneut. Am Ende liegen Luftfeuchtigkeit und Temperatur in separaten Textdateien unter /home/pi/.

Ab in den Cacti — SNMP

Damit Cacti die Werte abfragen kann, brauchen wir SNMP auf dem Pi:

sudo apt install snmpd snmp

In der /etc/snmp/snmpd.conf zwei Pass-through OIDs anlegen. Wird eine dieser OIDs per SNMP abgefragt, führt der snmpd das zugehörige Script aus und liefert dessen Ausgabe als Antwort:

pass .1.3.6.1.2.1.25.1.8.1  /bin/sh  /usr/local/bin/humid
pass .1.3.6.1.2.1.25.1.8.2  /bin/sh  /usr/local/bin/temp

Die beiden Scripts müssen drei Zeilen ausgeben — die OID, den Datentyp und den Wert:

/usr/local/bin/temp:

#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.2
echo gauge
cat /home/pi/temp.txt

/usr/local/bin/humid:

#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.1
echo gauge
cat /home/pi/humid.txt

Test:

snmpget -v2c -c public localhost .1.3.6.1.2.1.25.1.8.1
iso.3.6.1.2.1.25.1.8.1 = Gauge32: 76

snmpget -v2c -c public localhost .1.3.6.1.2.1.25.1.8.2
iso.3.6.1.2.1.25.1.8.2 = Gauge32: 9

Damit lässt sich im Cacti ein Graph anlegen. Etwas von hinten durch die Brust ins Auge — aber es funktioniert seit über elf Jahren zuverlässig. Die Template-Exports für Cacti gibt es hier: cacti-temp.tar.gz


Hinweise

SNMP-Sicherheit — Im Beispiel steht public als Community-String und SNMPv2c. Für ein Heimnetz reicht das. In einem produktiven Umfeld sollte man SNMPv3 mit Authentifizierung verwenden und den Zugriff per Firewall auf den Cacti-Server beschränken.

Alternative zu Cacti — Wer kein Cacti hat: Grafana mit InfluxDB oder Prometheus wäre die modernere Alternative. Der SNMP-Weg funktioniert dort genauso, alternativ kann man die Werte auch direkt per Telegraf oder einen kleinen Python-Exporter einliefern.

Warum kein wiringPi mehr? — Gordon Henderson hat das wiringPi-Repository 2019 offline genommen. Es gibt Forks auf GitHub, die auf neueren Pi-Modellen funktionieren, aber offiziell wird die Bibliothek nicht mehr gepflegt. Für neue Projekte ist Python mit der Adafruit-Bibliothek der bessere Weg — weniger Kompilieraufwand, bessere Fehlerbehandlung und aktive Wartung.


Der Sensor da draußen

Der Sensor muss nach draußen, vor Wasser geschützt sein, aber nicht hermetisch versiegelt — sonst kann er keine Luftfeuchtigkeit messen.

Meine Lösung: Ein PVC-Rohr, den Sensor dort mit etwas Silikon eingeklebt, eine Seite mit Deckel verschlossen. So kann kein Wasser an den Sensor laufen, Luft kommt aber noch ran. Angebracht am Pfosten der Satellitenschüssel — dort oben steht die Luft selten, es kommt niemand ran und es fällt nicht auf.

Das Ding hängt dort seit 2014. Funktioniert.


Siehe auch: Raspberry Pi als Konsolenserver, Stromverbrauch messen mit Raspberry Pi, Eltako DSZ12E und Cacti

Fragen? Einfach melden.

Stromverbrauch messen mit Raspberry Pi, Eltako DSZ12E und Cacti

Im Keller hing ein alter Ferraris-Zähler mit Drehscheibe. Zählt brav für den Energieversorger, liefert aber keine Daten. Ich wollte den Stromverbrauch im Haus grafisch auswerten, am besten mit Cacti. Dafür braucht man einen Zähler mit S0-Schnittstelle.

Der Zähler

Mein Energieversorger wollte für einen digitalen Zähler Fantasiepreise. Also selbst kaufen. Die Wahl fiel auf den Eltako DSZ12E-3x80A, einen Drehstromzähler mit S0-Ausgang. 3 × 80 A reicht für den normalen Hausgebrauch locker. Kostenpunkt damals rund 75 Euro.

Wichtig: Dieser Zähler ersetzt nicht den offiziellen Zähler des Versorgers. Er wird dahinter eingebaut. Das darf nicht jeder machen. Wer nicht weiß ob er es darf, darf es nicht. Ein Elektriker braucht dafür eine halbe bis eine Stunde, mit Anfahrt kommt man auf 100 bis 150 Euro.

Zur Deutlichkeit: Bei 3×80 A reden wir über 400 V Drehstrom. Ein Fehlkontakt ist lebensgefährlich. Selbst einbauen ist keine Option, auch wenn es auf YouTube einfach aussieht. Wer ohne Elektrikerschein bastelt, riskiert nicht nur sich selbst, sondern auch den Versicherungsschutz im Haus. Nebenbei: Für die eigene Auswertung ist der Zähler prima, für Abrechnungszwecke wie WG oder Mieter gelten eichrechtliche Anforderungen, die man vorher klären sollte.

S0-Schnittstelle und Raspberry Pi

Die S0-Schnittstelle ist ein potentialfreier Impulskontakt. Pro verbrauchter Kilowattstunde gibt der Zähler eine bestimmte Anzahl Impulse aus, beim DSZ12E sind es 2000 Impulse pro kWh. Der Raspberry Pi zählt diese Impulse über einen GPIO-Pin.

Die Verkabelung ist simpel: S0-Ausgang des Zählers an einen GPIO-Pin und GND des Raspberry Pi. Ein Pullup-Widerstand sorgt dafür, dass der Pin sauber zwischen High und Low wechselt. Bei jedem Impuls wird ein Zähler hochgezählt und der aktuelle Verbrauch berechnet.

Sauberer: Optokoppler statt direkter GPIO-Anschluss

In der Praxis funktioniert der direkte Anschluss meistens, spezifikationsgerecht ist er aber nicht. Die S0-Schnittstelle ist in DIN 43864 für 27 V DC Nennspannung und 10 bis 27 mA Schleifenstrom definiert. Wer es sauber haben will, baut einen Optokoppler dazwischen, zum Beispiel einen PC817. Die S0-Leitung versorgt man mit 5 oder 12 V über einen Vorwiderstand, der Ausgang des Optokopplers schaltet galvanisch getrennt den GPIO-Pin. Vorteil: kein Potentialproblem, keine Spec-Verletzung, und die Flanken sind sauber genug, dass man auf Software-Entprellung verzichten kann.

Die Auswertung habe ich nach dieser Anleitung aufgebaut: Stromzähler mit S0-Schnittstelle vom Raspberry Pi auswerten (Johannes Weber). Ein Python-Script zählt die Impulse und stellt die Werte per SNMP bereit.

Cacti-Graphen

Cacti fragt den Raspberry Pi per SNMP ab und zeichnet die Graphen. Neben dem aktuellen Verbrauch in Watt lassen sich mit zusätzlichen SNMP-Abfragen auch Tagesverbrauch, Wochenverbrauch und Monatsverbrauch darstellen. Die Berechnung macht das Script auf dem Pi, Cacti muss nur die fertigen Werte abgreifen und zeichnen.

Das Ergebnis: Auf einen Blick sieht man wann die Waschmaschine lief, wann der Herd an war und wie hoch die Grundlast nachts ist. Verbrauchsspitzen fallen sofort auf.

Update 2026: was heute anders wäre

Der Beitrag ist von 2014, und zwölf Jahre sind in der Energiemesstechnik eine halbe Ewigkeit. Inzwischen läuft in Deutschland der Pflichtrollout für intelligente Messsysteme (iMSys) nach dem Messstellenbetriebsgesetz. Wer ein Smart-Meter-Gateway (SMGW) hat, bekommt die Daten ohnehin digital, und über die HAN-Schnittstelle (Controllable Local Systems) lassen sich Verbräuche direkt abholen. Ist der alte Ferraris-Zähler hingegen noch drin, ist ein IR-Lesekopf auf der D0-Schnittstelle (SML-Protokoll) der Weg der Wahl, gut gepflegt im Volkszähler-Projekt oder in Kombination mit Tasmota. Fertige WLAN-Messmodule wie das Shelly 3EM oder Pro 3EM liefern Drehstrommessung direkt per MQTT, ganz ohne GPIO-Basteln. Als Backend wäre heute eher Home Assistant mit dem Energy-Dashboard oder Grafana plus InfluxDB gesetzt, Cacti hat seinen Charme, aber die Zeit der Graphen mit RRDtool ist in der HomeLab-Ecke vorbei.

Siehe auch: Temperatur und Luftfeuchtigkeit mit DHT22 am Raspberry Pi messen

Fragen zum Aufbau? Einfach melden.

Raspberry Pi als FM-Radiosender mit PiFM

Kinder sind etwas Wunderbares, so auch meine beiden. Die Größere hört zum Einschlafen gerne ein Hörspiel, beim Spielen hören und tanzen beide zu Kindermusik. Klar haben sie eine kleine Kompaktanlage im Kinderzimmer. Aber Kinderhörspiele gibt es kaum noch auf Kassette — fast nur noch auf CD oder als MP3. Keine Ahnung wie es bei euren Kindern ist, bei uns leben CDs nicht sonderlich lange. Ich grille in der Woche 3 bis 4 Stück. Noch schlimmer: Die Lieblings-CD trifft nach 38 Minuten auf einen Kratzer und macht nur noch unverständlichen Lärm.

MPD als CD-Ersatz

Ich hatte noch einen Raspberry Pi herumliegen. Den zusammen mit dem Music Player Daemon (MPD) als Musikspieler nutzen — die gekauften MP3-Alben liegen eh auf dem Server und lassen sich per NFS mounten. WLAN ist im ganzen Haus, und wir Eltern steuern alles per Android-App. Das Projekt war in anderthalb Stunden erledigt, getestet und von den Kindern abgenommen.

Seitdem fristet der CD-Spieler ein ungenutztes Leben. Nur das Radio läuft hin und wieder am Abend. Radio… irgendwo hatte ich doch im Zusammenhang mit dem Raspberry Pi etwas zu FM-Radio gelesen.

PiFM — FM-Sender über GPIO

PiFM (mittlerweile weiterentwickelt als rpitx) nutzt den GPIO-Pin 4 des Raspberry Pi, um ein FM-Signal zu erzeugen. Eine ca. 15 cm lange Antenne — ein Stück Draht — reicht. Der Pi generiert per DMA ein Taktsignal auf dem GPIO, das direkt als FM-moduliertes HF-Signal abstrahlt. Kein zusätzlicher Sender-IC nötig.

Eine WAV-Datei auf 90,0 MHz senden:

sudo ./pifm musik.wav 90.0

Einen Web-Stream — zum Beispiel einen Kinderradiosender — per sox umwandeln und direkt an PiFM pipen:

sox -t mp3 http://stream-url -t wav -r 22050 -c 1 - | sudo ./pifm - 90.0

MPD kann auch streamen — so lässt sich die gesamte Musikbibliothek per FM ins Kinderzimmerradio schicken.

Verstärkerschaltung

Das reine GPIO-Signal ist schwach. Um es etwas zu verstärken und sauber zu filtern, habe ich eine kleine Schaltung gebaut — den handgezeichneten Schaltplan mit Bauteileliste findet ihr in den Bildern unten. Mit der Schaltung reicht das Signal für das ganze Haus inklusive Garten.

Oberwellen: der eigentliche Grund für den Filter

Der GPIO liefert kein sauberes Sinussignal, sondern ein Rechteck. Ein Rechteck hat neben der Grundfrequenz eine lange Reihe Oberwellen bei 2f, 3f, 4f und so weiter, und durch die DMA-getaktete Frequenzmodulation entstehen zusätzlich Splatter-Anteile im Nachbarkanal. Bei 90 MHz Grundfrequenz heißt das: 180 MHz, 270 MHz, 360 MHz und höher. Mindestens eine dieser Harmonischen liegt mit Sicherheit in einem Band, das belegt oder sicherheitskritisch ist. Ohne Tiefpass strahlt PiFM also nicht nur auf der gewählten UKW-Frequenz, sondern breitbandig quer durch VHF und UHF. Der Filter in der Verstärkerschaltung ist deshalb nicht Kür, sondern der einzige Grund, warum man keinen Flugfunk, Amateurfunk oder Rundfunk stört. Wer PiFM ohne Filter betreibt, wird im Zweifel nicht nur von der Bundesnetzagentur, sondern auch von jedem Amateurfunker im Umkreis sehr schnell gefunden.

Rechtliches

In Deutschland darf man im FM-Band senden — aber nur mit extrem geringer Leistung. Die Bundesnetzagentur erlaubt ohne Genehmigung Sendeanlagen mit wenigen Nanowatt, was in der Praxis etwa einen Meter Reichweite ergibt. Der Raspberry Pi mit Verstärkerschaltung überschreitet das deutlich. Dieses Projekt bleibt deshalb ein einmaliger Versuchsaufbau.

Schade eigentlich — der WDR-Kinderkanal MausLive (ehemals KiRaKa) ist nur per DAB+ oder Internet-Stream zu empfangen. Per PiFM könnte man den Stream als FM-Signal im Haus verteilen und die Kinder könnten überall mit einem einfachen Radio hören. Aber so ist die Rechtslage.

Update 2026: zeitgemäße Alternativen

Der Beitrag ist von 2014. Heute wäre mein Weg ein anderer: Bluetooth-Audio direkt ans Kinderzimmerradio (falls es Bluetooth kann) oder ein kleiner Multi-Room-Audio-Setup mit Snapcast, squeezelite oder einem fertigen Smart Speaker. DLNA/UPnP und AirPlay decken den Rest ab, alles legal und ohne Frequenz-Diskussion. rpitx gibt es übrigens immer noch, inzwischen mit deutlich mehr Modi (SSB, FSK, LoRa, sogar DVB-T), und ist als Experimentierplattform für die SDR-Ecke weiterhin spannend. Nur eben nichts, was man offen im Wohnzimmer laufen lassen sollte.


Bilder vom Projekt — Platine, Schaltplan mit Bauteileliste und das Ergebnis auf dem Radio:

Fragen? Einfach melden.

ownCloud

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud.

Zur kurzen Beschreibung von ownCloud greife ich jetzt einfach mal ganz faul auf den ersten Absatz aus dem passenden Wikipediaartikel zurück:

### schnipp ###

ownCloud ist eine Software-Suite, die einen ortsunabhängigen Speicherbereich für Daten zur Verfügung stellt. Das Projekt wurde im Januar 2010 vom KDE-Entwickler Frank Karlitschek ins Leben gerufen, um eine freie Alternative zu kommerziellen Cloud-Anbietern zu schaffen. Im Gegensatz zu kommerziellen Speicherdiensten kann ownCloud auf einem privaten Server ohne Zusatzkosten installiert werden. Somit können gerade bei sensiblen Daten die Bedenken gegenüber einer Datenweitergabe und der damit einhergehenden Abgabe der Kontrolle über die Daten zerstreut werden.

Als Grundlage setzt das Projekt auf PHP und einer angebundenen SQLite-, MySQL- oder PostgreSQL-Datenbank. Die ownCloud kann über eine Weboberfläche bedient werden und ist dadurch nicht an ein bestimmtes Betriebssystem gebunden. Aber auch andere Anwendungen, wie beispielsweise Dateimanager oder Groupwares, können die ownCloud über eine Schnittstelle ansprechen und Dateien und Daten lokal bereitstellen.

### schnapp ###

Im Grunde lässt sich ownCloud also mit recht kleinen Grundvoraussetzungen ownCloud in Betrieb nehmen. Selbst die einfache Installation ist nicht weiter aufwendig. Natürlich hängt es immer etwas davon ab, welche Systeme man noch anbinden möchte und wie groß es am Ende wirklich werden soll.

Inzwischen gibt es für alle möglichen Clients auch Software, welche sie an ownCloud anbindet. Evolution, Thunderbird, Kmail (und Anhang), Sync-Clients für Windows/Linux/… Man kann einfach auf seine Dateien per WebDAV zugreifen usw. usw…

Man hat also seine Daten wirklich unter der eigenen Kontrolle und würfelt sie nicht irgendwo hin. Dabei ist die nötige Basis so gering dass es alles sogar über einen Raspberry Pi läuft.

OK… Es hat natürlich einen Haken. Denn es ist wie immer, wenn man selbst dafür verantwortlich ist, dann ist man auch selbst dafür verantwortlich. Alles ist dann nur so sicher wie man es selbst abgesichert hat, sich um die Patchstände kümmert und die Konfiguration vorgenommen hat.

Denn noch bietet man natürlich selbst in der Regel ein nicht ganz so attraktives Ziel wie ein großer Clouddienstleister (ich mag das Wort cloud nicht…).

Siehe auch: ownCloud und Kalender / Kontakte synchronisieren, ownCloud News-App, ownCloud und Mozilla-Sync, Davdroid ownCloud sync

Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑